Dreadknux

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.

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.

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?

OK that makes sense - I guess by default then, the 'Curators' would get approval notifications for the Pages app but not the Forums app as they don't have the access to moderate any of the forums... I am guessing there would be a similar way to set this up for Moderators so that the reverse is true (i.e. is there maybe a toggle on ACP > Members > Staff > Moderators that I could uncheck for the Moderator usergroup relating to Page Databases? Or maybe something to do with the Database's permissions area)? I just want to make sure the Mods on my forum aren't getting spammed with approval requests for something they don't care about! 🙂 Appreciate the guidance on this!

Thanks Marc. I just checked the individual notification settings area as advised - it doesn't seem like there's a way to allow for approval requests by database? It just has an overall "moderator approval" section which seems to apply to everything. The ideal things here would be for me to allow my Moderators usergroup to continue getting notifications for Forum-based approval requests (i.e. I have a 'newbie' usergroup for new registrations that require their first posts in the forum to be approved by a moderator), and allow for 'Curators' usergroup to only get notifications for Pages Database-based approval requests. Otherwise, my moderators will get requests for Pages approvals and Curators will get requests for Forums approvals, right? Or is there an option on AdminCP that would make sure Moderators and Curators don't get approval requests for areas they are not in authority over?

Hello! I am about to launch a Pages Database that will work as a kind of crowd-sourced information resource (like a wiki, almost), and I have a few questions about moderation/approvals for this specific space that I wanted to ask in case I was missing anything: Is there a way to 'ban' offending users solely from the Pages Database instance, preventing them from editing/contributing to the Pages Database - while still allowing them regular access to other apps? My main app is Forums, and I don't want to have to completely ban users from the Forums if I want to simply restrict them from editing the Pages. Would I need to set up a new usergroup for this and just move users I don't want to edit Pages into that new usergroup? I have a usergroup called 'Curator' that will act as a semi-moderator for the Pages Database only. They will have no other moderation privileges and won't have the same access or status as a moderator. Is there a way to allow users in that specific group to receive and manage notifications for edit/create approvals for Pages Database? I imagine the way it works at the moment is that all Moderators and Admins will get such approval notifications, but I'd like this 'Curator' usergroup specifically to handle these entirely. I know there is an ACP section for Members > Staff > Moderators where I can specify exactly what each usergroup can be allowed to moderate, but there doesn't seem to be a toggle for managing approvals per database?

Hello! Sorry if this is in the wrong forum, but I had a question about IPB's built-in tabbing tools and was hoping someone could steer me in the right direction. So I have a Pages database set up, organised as a sort of archive for certain video game releases. I have included a tabbed section in order to segment off parts of each record; I want to add a slug to the end of the record's url when they click to a specific tab, which I've managed to do by following the IPB documentation on ips.ui.tabbar. But it seems that the slug doesn't actually do anything besides cosmetic effect - when they click to a tab, then refresh the page with the url slug appended, they see a 404 error instead of the tab they were just on. Here's an example of my code: <div class="ipsTabs ipsTabs_contained ipsTabs_withIcons ipsTabs_large ipsClearfix ipsResponsive_pull" id="elTabBar" data-ipstabbar data-ipstabbar-contentarea="#elTabContent" data-ipstabbar-updateurl="true"> <a href="#elTabBar" data-action="expandTabs"><i class="fa fa-caret-down"></i></a> <ul role="tablist"> <li> <a href="page" role="tab" id="1" class="ipsType_center ipsTabs_item ipsTabs_activeItem" aria-selected="true"> <i class="fa fa-file-text-o" style="font-size: 16px;"></i> Page </a> </li> <li> <a href="articles" role="tab" id="2" class="ipsType_center ipsTabs_item"> <i class="fa fa-newspaper-o" style="font-size: 16px;"></i> Articles </a> </li> <li> <a href="media" role="tab" id="3" class="ipsType_center ipsTabs_item"> <i class="fa fa-picture-o" style="font-size: 16px;"></i> Media </a> </li> <li> <a href="reviews" role="tab" id="4" class="ipsType_center ipsTabs_item"> <i class="fa fa-star-half-o" style="font-size: 16px;"></i> Reviews </a> </li> </ul> </div> <article id="elTabContent" class="ipsTabs_panels ipsTabs_contained ipsContained ipsBox ipsResponsive_pull"> <div id="ipsTabs_elTabBar_1_panel" class='ipsTabs_panel' style="padding:0;"> PAGE CONTENT </div> <div id="ipsTabs_elTabBar_2_panel" class='ipsTabs_panel' style="padding: 0 !important;"> ARTICLES CONTENT </div> <div id="ipsTabs_elTabBar_3_panel" class='ipsTabs_panel'> MEDIA CONTENT </div> <div id="ipsTabs_elTabBar_4_panel" class='ipsTabs_panel'> REVIEWS CONTENT </div> </article> Using the code above, a user will visit and land on the 'Page' part of the page, then may click the 'Articles' tab to view that segment of the page. The browser URL will have domain.com/database/record/articles appended to it. The user then refreshes their browser, and they are greeted with a "Sorry, that page does not exist" error message. I know logically why this is happening - there is no actual "articles" page for my IPB site to direct the user to - but is there an extra "ips" function I'm missing somewhere in my HTML that would direct the user straight to this tab upon reload? I imagine this is a functionality of the tabbed system otherwise it wouldn't be mentioned in documentation, so I'm assuming I'm just doing something wrong. Any help would be appreciated! 🙂

Good point! I was wondering if I was missing something. I'll trial it and see if it can be useful for this purpose. Thank you!

I’ve seen on other forum platforms, the ability for mods/admins to flag important posts in a topic with ‘threadmarks’, which can be collated and presented as a drop-down menu situated next to a topic’s pagination. Allowing users to quickly jump to areas of a topic where a significant update or subject change has occurred. I can’t find any such feature or third-party plugin to replicate this on InvisionCommunity, and I think it would be a great simple function that’d improve the browsing experience for users who return to a long fast-moving topic after a period of time.