Dreadknux

Hoooooold on @Matt

I was told that setting past dates on Pages wasn't happening anymore after my own bug report here. I just bought a plugin to sort the issue out for me 😅

Am I right in assuming that with the March update, we can set past dates on already-published records as well as set past dates on new records being created? I just want to make triple-sure so I know, because I've been so confused these past couple weeks! 😄

Actually, yeah now that you mention it. There's a bunch of "OutOfRangeException:0" errors logged (probably the same number of errors as when I tried to load the page). Is it safe for me to post the backtrace details of this log here, or do you not need any more info?

Hello IPS team! I just saw this strange notice on my ACP when looking through my Achievements Rules list:

Quote

[[Template core/admin/achievements/rulesListRows is throwing an error. This theme may be out of date. Run the support tool in the AdminCP to restore the default theme.]]

It doesn't relate to any theme template bit that I can manually restore, as the template referred to is in the /admin/ folder (which isn't visible when editing a theme's HTML/CSS - I certainly can't find the "rulesListRows" template when searching for it). I'm not sure how this happened either because I don't recall seeing a template called "rulesListRows", much less editing it.

The direction to "run the support tool in the AdminCP to restore the default theme" is pretty vague as well. I'm not sure where I'm supposed to go or what I'm supposed to do to action this (I assumed it was go to Themes > Edit CSS/HTML > Restore template bit, but as I mentioned above this template doesn't isn't accessible in that part of AdminCP).

Any ideas on how to fix? And this won't do anything to mess up my existing theme, will it? I'm assuming not, seeings as it references an ACP template bit, but I wanted to make sure.

Sorry to revive a dead thread, but I wanted to see if this suggestion was being taken on board? I think having more options for formatting the datetime parameter would be great on the theming level. For example, I might want a datetime on profiles only to read as:

Aug 31, 2022

With short month names. Which I can't do at present with the current boolean options.

Is it possible to add a ' format="m/j/Y" ' parameter to allow for a full suite of date and time options, as Morrigan suggests in the OP?

My community has been asking for a means to toggle/collapse widgets, in the same way you can for forum lists. Is there a way you can do this already, or is it something that IPS needs to add to the system?

I noticed an old plugin on the Marketplace that seemed to accomplish this:

But it doesn't seem to be downloadable anymore, or compatible with the latest version.

20 hours ago, Stuart Silvester said:

I wanted to provide some background on why we've made this change. We were experiencing some reliability issues with the future publishing functionality across the platform in 4.7.7, and we had to revert some recent fixes for bugs and go back to a known state. During that testing, we repeatedly ran into issues with publishing new items with dates in the past, which is why we made the decision to disable the ability to add new items to the past. In older versions, setting a publish date was something specific to Pages, then we expanded it to cover more areas.

If you have any specific use cases for this feature, please let us know. Your input will help us determine the best way to move forward and ensure that our platform meets the needs of all our users. I did see how @Dreadknux uses this functionality to backdate press releases and articles for legacy consoles.

I just wanted to let you all know that I had a good night's sleep and I'm over it 😅

Many thanks to Stuart, Marc and Matt for assisting with all of this, and for the feedback/context. I think the important thing as a customer is just knowing if your feedback is being heard or not, and it was a little bit confusing to think that was happening within this particular thread. I apologise for getting the wrong end of the stick here.

I'm glad to know that use cases are being considered for future updates. I'm more than happy to serve myself up as a guinea pig and road test whatever swanky rewrite you have cooking if it will help to get some added perspective! 🙂 

For now, I'm going to look into this plugin that was shared earlier and hope that all my previous suggestions relating to Pages/CMS are being considered as I think that would really help make IPS shine in future versions.

I understand. Thanks Marc.

The theme select should already be available on mobile view, at the bottom of the page like on desktop by default. But if you want to move it to the header, and are familiar with template editing on the HTML level, you can find the code for displaying the theme select dropdown in the 'footer' template bit. This is the code:

	{{$themes = \IPS\Theme::getThemesWithAccessPermission();}}
	{{if \count( $themes ) > 1 }}
		<li>
			<a href='#elNavTheme_menu' id='elNavTheme' data-ipsMenu data-ipsMenu-above>{lang='skin'} <i class='fa fa-caret-down'></i></a>
			<ul id='elNavTheme_menu' class='ipsMenu ipsMenu_selectable ipsHide'>
			{{foreach $themes as $id => $set }}
				<li class='ipsMenu_item{{if \IPS\Theme::i()->id == $id}} ipsMenu_itemChecked{{endif}}'>
					<form action="{url="app=core&module=system&controller=theme" noprotocol="true" csrf="true" seoTemplate="theme"}" method="post">
					<input type="hidden" name="ref" value="{expression="base64_encode( (string) request.url() )"}">
					<button type='submit' name='id' value='{$id}' class='ipsButton ipsButton_link ipsButton_link_secondary'>{lang="$set->_title"} {{if $set->is_default}}{lang="default"}{{endif}}</button>
					</form>
				</li>
			{{endforeach}}
			</ul>
		</li>
	{{endif}}

You could feasibly copy this code and paste it into the mobileNavBar template bit. You would probably need to work with it a little bit to get it the way you like it - perhaps nest it in the UL list tag for best results - but that should offer the same drop-down functionality as on desktop.

46 minutes ago, Marc Stridgen said:

I believe you may have read my previous response incorrectly. The intention of the feature is for delaying the publication of items. Feesability within the scope, and ability are not one and the same there. 

We do of course appreciate the suggestion there

Why was this intention not fully communicated back in September 2022? I actually feel like this entire bug report/thread has been wholly misunderstood by IPS, which as a long-time and dedicated customer (and one that is looking to move even further into your ecosystem) is sorely disappointing.

I believe I was very clear in what was trying to be accomplished from the start - if there was no intention to fix the issue in the way I outlined (which Matt seemed to offer the impression he was looking into), then IPS Staff should have been up front about this from the first response and I would have dropped the report.

I'm sorry for being flippant in my previous post, but this really has not been a great customer support experience. I'll get over it, but I think given the assurances and lack of detail posted throughout the last few months I could be forgiven for misunderstanding what IPS considers scope, feasibility and ability here.

But apparently it can't be done! 😅

Thanks @Nathan Explosion I'll look into this.

EDIT: I guess I'll say something constructive in all of this - @Matt I suggest this field could be renamed from "Publish Date" to "Future Publish Date" so that users do not get confused as to its actual function. No user is going to use that field for any other purpose (you can't set a past date, and for current date it's redundant), so a name change would make sense and avoid future customers asking about this. 🙂

Appreciate the patient reply Marc. I'm actually quite confused as to how the CMS has been coded in such a way as to make such past-date publish settings unfeasible - it's something that Wordpress can do very easily. Kind of makes me wonder what the CMS app was originally coded for...

I hope if there is a refresh/backend rewrite coming as mentioned elsewhere, that the team takes into consideration how editors/content creators use these systems and accounts for this. And while I can't say I'm thankful that my migration from Wordpress to IPB has been significantly delayed as a result of this (that's what I get for bug reporting I guess, lesson learned!), at least I happened to give Matt an interesting problem to work on 😛

Off to make a plugin to fix this myself I suppose.

Okay... then these changes have done exactly the opposite of what I was reporting! It's not a fix in any way, and not what I was led to be the case when Matt was suggesting he'd fix the issue in the way I outlined. This is super frustrating as I had been waiting for months for something to be done only to be taken by surprise with a random update like this.

If I knew the plan was to completely remove the ability to backdate articles in the way I had been doing in the first post, I'd have been happy to just ask you to ignore this whole bug and just let me use the workarounds I had been using. I'd rather you just revert everything back to the way it was please.

If not, I suppose I will either have to try digging into the database directly to edit post publish dates or get a plugin created to fix this issue for me.

It would be great if a future update allowed for the syncing of Reactions made between a Topic in the forums and a linked CMS/Page Record.

At the moment, when you link a Topic and CMS record together (either by making a CMS record and having a topic created, or by using "Copy to Database" on an existing forum topic), almost everything else is sync'd up. Tags, comments/replies... even the Reactions made towards those comments/replies! But for some reason, Reactions on the Topic's original post and the CMS Record remain completely separate. It's inconsistent.

Changing this would go a long way to help integrate CMS and Topics - a lot of users on my community tend to React to posts more than they do comment, and I want to make sure those Reactions are reflected in all linked content,

I raised this as more of a bug concern around a year ago, but was told it was actually expected behaviour. So I figure I'd make a suggestion about this, it'd be a small but great improvement!

I've just applied the latest optional patch for my community, and it says it addresses this Publish Date issue in some way. What it seems to do is limit the Publish Date field to only be visible when creating a record, and an error appears when an editor attempts to set it to a past date. The field no longer appears when editing an already-published record.

I'm guessing this is the first step to a more complete solution to my issue. Will there be a new field created specifically to allow editors to backdate news records? Or will the existing Publish Date field be modified further in some way?

If a new default/standard date field is being made to account for past-date records, it would be great if this field could be visible and allow input at the record creation level as well as record edit.

16 hours ago, LastPlay said:

As I wrote - it's not a bug!
The programmer told me that this date field is ONLY for future dates (so that the article is published at a certain time/date).

To specify a date in the past:
1 - create the article and save
2 - edit and specify the desired date
*I do exactly that )))
(I think it's not critical to save 1 more time. +/- 5 or 10 seconds of time).

Very strange that you have all the articles changed the date... We should call Sherlock 🤪

Please don’t derail this thread, it’s only confusing and complicating my original post and issues. The objective here is to fix the inconsistencies in the publish date code (which Matt and the IPS team have recognised as a bug) and to track the progress of this. Whatever you were told is related to your own individual issue, so please leave it there. Thanks.

Thanks for the additional context @Matt. I think the ability to backdate content would be integral to any content manager working with content, so even though it's a complex issue I appreciate that it's being looked into. I don't mind waiting for a fix in that case.

Would it be possible to fix the new issue that I found, that I posted in my last reply here? I actually have more information after some additional troubleshooting, if it helps. It seems that the Page Record publish date can not be edited in any way, even post-publish (which was the workaround I was successfully using before). However, the publish date DOES appear with the backdated publish information when looking for the record in Search.

Steps to Reproduce:

• Have a database with settings to publish topic to forum
• Create new record, enter content, set prefix tag, set publish date to a past date (in this case, 1 June 2001 at 13:36)
• Publish, check record. Record displays current date ("Just Now") [see image 1]
• Click prefix to check record in Search results. Record displays past date ("1 June 2001") [see image 2]
• In Search results, associated topic will also be visible. This will display the current date ("Just Now") [see image 3]
• Revisit Page Record, edit record, attempt publish date change to past date again.
• Click save. Usually, this would successfully change the publish date to the past date as desired, but now it does not alter the publish date at all.

Image 1:

Image 2:

Image 3:

-----

So I figure some bug fixing attempt was made to resolve the issue I was having, with the last IPS update... but it strangely seems to have worked in one way and not in others. Any ideas? As I say, I'm happy to just have the situation reverted so I can use my workaround as before (multiple edits post-publish) in the meantime while you guys look further into reworking the CMS for future versions?

Just to update you guys, I upgraded my IPS install to the latest version (February update) and this issue is still apparent. It would be great to get an idea of whether this might be fixed in the March update or sooner @Stuart Silvester @Matt @Gary ? 🙂 

EDIT: Actually I just tried to edit a post and change a publish date to the past and it seems that I can no longer do that after this latest update, which is now a big problem. Is there a way of escalating this?

One of the things I like about Invision Community is the ability to create Pages/CMS records from content published in other areas of the site. In my case, I am exploring leveraging the engaged community on my forums to help populate news stories across my website. So in my situation, I tend to use the CMS 'Copy to Database' feature with Topics often.

However, this causes a little confusion with regards to discoverability and organised search, as content that has been linked/connected in this way are not listed as such in search results or activity feeds. This means that, if a lot of your site content relies on the marriage between CMS/Pages and Topics/other content, it can easily look like content is duplicated several times on the website. This can be (and is, for me) a frustrating browsing experience for users who might want to sweep Tagged content, only to find items that are listed as separate entries but are in fact linked items of the same content.

I would like to suggest an improvement in a future Invision Community version, that attempts to address this. It would be great to have a setting in ACP that ensures, if a topic (or other piece of content on the site) has been used to create a CMS record, the two pieces of content are grouped in search results.

I've made a mockup of how this could be designed. First, here's a snapshot of how it currently looks when I create a new CMS record (in this case, a news article) and have a topic automatically created upon publish. As you can see, there is a Pages content block for the CMS record (complete with thumbnail) at the top, and underneath it a separate Topic content block with exactly the same content.

And here is my mockup for a potential solution. Note that the topic entry is marked as a 'connected topic' as it was created from the CMS record.

You could also build in additional settings to further customise this - for example, I want to make sure that the CMS record/article is always shown first as the 'parent' result in groupings like this, but there could be a toggle to swap this around and ensure that, if any such groupings exist in search results, that it's the Topic that is shown as the top 'parent' result and the CMS record is instead nested underneath it.

It's not the most urgent QOL improvement, to be honest, but I think it would help make search and content discovery on Invision Communities a bit more sensible. 🙂 

Upon further inspection, it seems to be clearing DNS now but it’s giving me ‘Page isn’t Usable on Mobile’ error.

Turns out the Google Search Console / indexing tester doesn’t fully render the page on mobile, only loading 31/57 resources (including a bunch of core CSS files such as responsive.css). Which is weird because loading the URL on a mobile device using a consumer browser (Safari etc) loads all resources totally fine.

I’m guessing this has something to do with my server and needing to do some housekeeping on it to ensure the InvisionCommunity resources are loading quickly/properly… 

Thanks for the insights Jim. Yeah, I think the topic got renamed a couple times. I suppose it will take a while but hopefully all three search entires will be merged into one?

I’ll see what the Google Tools throw up, thanks. I did search for the url on Search Console and for some reason it says “URL is not on Google”. I’ve checked ‘request indexing’ and hopefully that may resolve it…

In your experience, do you think this is just a result of the way my site is organised currently (i.e. my Wordpress is considered the default ‘main site’ so Google crawlers might just be ignoring any ‘news’ URLs on my forum subdomain)? There isn’t anything on Invision Community’s Pages app/SEO settings that would need to be set for Google to crawl database records successfully?

EDIT: Seems like there is a ‘DNS issue’, (the exact error is “Failed: DNS server unresponsive”) which I don’t understand really as the website is live and active and other pages on the Invision Community install are indexable. I’ll investigate further - thanks again for the help.

I'm (slowly, very conservatively) looking to transition an existing Wordpress site install into a migrated Invision Community CMS/Pages setup so that it is integrated nicely with my existing forum. One of the reasons for my conservatism is potential SEO issues - I know how well my Wordpress news stories can reach within Google's search results ranking, but I am not sure whether the same would be true for Invision Community's platform (at least, on the Pages CMS side).

A couple days ago, our team and community made the following pieces of content:

• A LEGO news story, on my existing Wordpress installation,
• A topic on my Invision Community forum, about the same subject (which was renamed several times),
• and a second news story, identical to the Wordpress one, created on Invision Community CMS/Pages app, using 'Copy to Database' and pulling from the above topic.

All of these content pieces have been live and kicking for about three days. I did a quick vanity search to test the ranking/viability of all three content pieces.

As you can see above, it's a little strange.

Of course, the Wordpress story appears at the very top of the search results (which I would expect, as it currently uses the base domain and is the primary location for my website/community's news stories). Nothing weird there.

But the Invision Community Topic appears THREE times in search results, and all three items lead to the exact same topic. I can think of no reason for this happening except, perhaps Invision Community treats a renamed version of the same topic as a separate entry, and that is pushed individually to Google. This can be confusing to see, especially if all three links lead to the same place. Is there scope to fix this in a future revision of Invision Community? If a topic/content is renamed or URL slug changed, it should be considered all one piece of content in terms of SEO, right?

Another issue is that, as you can see, the Invision Community-produced news story linked above does not appear in search results at all. Obviously this is a problem for me if I am seeking to fully migrate my Wordpress over to Invision Community, as it could result in my Google results rankings absolutely tanking. I know the Invision Community news side of things is considered less important than my Wordpress from a search ranking perspective right now... but is it normal for it not to appear at all? The permissions set to my Pages database is all set to public visibility.

Am I doing something wrong? Is there some SEO-specific settings I need to consider? Or is this something that needs some refinement on Invision Community's side for future releases?

Thanks for the updates - interesting revamp of the Gallery! Looking forward to seeing how that evolves. I am currently using a Pages database for a more editorialised media gallery setup (archival of official artworks, etc), and if I could replicate what I'm doing there with this I may just jump in and grab the revamped Gallery app.

I had a question with that in mind; would it be possible (or can there be scope to add, in a future update) to connect or build a link/database relationship between Gallery albums and records in a Pages database? Either by allowing custom fields in gallery albums or some other method?

That's one of the benefits for me to using a Pages-based media gallery right now (I have a DB Relationship custom field in the 'media gallery' database that, when linked to a Pages record in a separate database, will allow those albums and images to appear dynamically on the linked Pages record), but I would rather have the visual benefit of a proper gallery app that I can allow multiple users to contribute to, which can be linked directly to a Pages DB record.

Hello - sorry for the bump, just checking to see if this is an issue that will be resolved in a patch or maybe next month's update? I just upgraded to the December update and latest patch and this issue is still rearing its ugly head. 🙂

Ahh, I see now - so I checked my Forum tab and nothing was selected... but I checked the 'Content' tab and a lot of options there were toggled ON (i.e. "Pin all content"). Deselecting all of those options in the Content tab made all of those same options available under the Forum tab (and the Database tab actually), which is I'm guessing what I need to do in order to efficiently segment the moderation accesses between usergroups?

If that's the case, I'll go ahead and do some admin and sort all of that out. Appreciate the guidance, it's very helpful! 🙂 

Thanks for the help Jim - so in the Moderator's permissions area in the ACP I navigated to the database in question and these are the options that appear:

Since nothing is checked, I'm guessing it means any approval requests that are made will not go to the Moderator group at all? I can see there is a toggle under the general 'Content' area titled, "Can enable/disable moderation on all content?" with the note, "This will allow individual content items to require approval for new comments." That is currently toggled OFF anyway, but is that relevant to what I want to do here at all?