Dreadknux

=========== (Apologies for the incredibly long read/tons of images; this is a complicated request and I wanted to make everything as clear as I possibly could) =========== Currently, using the "Copy to Database" feature in a forum topic will result in the Pages Record content overwriting the content in the associated topic's first post, unifying the topic's OP with the resulting article. I think this needs to be changed. The Pages Record content needs to be, for a lack of a better word, "orphaned" from the topic content, and displayed as a separate content block within the topic it is associated with. Or at the very least, there needs to be an option in AdminCP that allows us to change the 'Copy to Database' behaviour to act this way. There are many reasons why this should be changed this way, but I'll just give you one very good visual (step by step) example: ^ User creates a topic of interest (called ‘Topic 1’, content here highlighted in yellow for visual purposes) ^ (Another) user creates a second, duplicate, topic about the same subject (called ‘Topic 2’, content here highlighted in red for visual purposes) ^ (A third) user creates a third, duplicate, topic about the same subject (called ‘Topic 3’, content here highlighted in blue for visual purposes) ^ At this point we have three topics existing, all about the same subject. At this point, a moderator would simply merge the topics, right? ^ Before that happens, another mod/admin decides to create a Page Record from one of the Topics (they have chosen to build upon ‘Topic 3’). ^ The mod in question build a new Page Record using the options and settings outlined above. ^ This is the resulting Page Record. Note that the Topic’s original post has not been displayed in the comments section, as that content has now been overwritten by the Page Record content and is now considered a unified content item. ^ Similarly, the topic title has been replaced with the title of the Page Record ^ At this point, a mod sees the duplicate topics and decides to merge. They merge the new Topic 3 with Topic 2. ^ As you can see, clicking through to the merged topic shows the OP from Topic 2 appearing above the Page Record/Topic 3 unified content. This makes sense as Topic 2 was created before Topic 3 was (and Topic 3 was created before the associated Page Record was made) Now at this point, I’d like to say that it is NOT an issue for me for Topic 2’s content to appear above Topic 3’s content when merged this way. The slight issue for me is that the Page Record content (which is now what Topic 3’s content has become) is now sitting lower down the page. If the Topic 3 content was not overwritten with the Page Record content, this would not look so weird. But, this is just a small issue. The real problems come next. ^ Head back to the Topic’s associated Page Record, and you’ll see some issues. The Page Record content is duplicated in the page’s “first comment” because it is really the OP of Topic 3, which was overwritten with the Page Record content. Additionally, the OP of Topic 2 (which was displayed in the Topic view above the Topic 3 OP content, as previously mentioned) is not visible. This is because the IP Suite assumes that the Topic and Page Record are unified, and so Topic Post #1 = Page Record. But as we’ve demonstrated that is no longer the case, and now the Topic’s Post #1 is now Post #2, appearing as the Page Record’s first comment. Now, what we will do next is go to “Actions” > “Edit” on the Page Record, and make an edit or two to the Page Record, then hit Save. We will see what happens to the Page Record’s associated Topic now. ^ The OP content of Topic 2 has been overwritten, again, with the content in the Page Record. This has happened because the first post of the thread is now assumed to be the “mirror” of the Page Record (even though it is no longer the case, since the topic merge) so it has taken over Topic 2 OP. However, this has also left the previous sync’d content from Topic 3’s OP intact, so what you now see are two duplicate posts and the removal of two forum posts to make this happen. ^ Wanted to note at this point that this situation does not seem to impact the comments/replies in the merged topics, thankfully they remain intact. It’s just an issue for whatever the system currently thinks is the Post #1 in the Topic at that given moment. ^ That’s what happens if there is only one topic merge, but let’s see what happens when a third duplicate topic is merged in by another mod/admin? ^ We merge the older Topic 1 with the already-merged Topic 2 and Topic 3. ^ So far, so good on the Forum View. ^ And just like before, because Topic 1 was created before Topics 2 and 3 before them, upon merge the Topic 1 OP content appears at the top of the chain. And the overwritten duped Topic 2 and Topic 3 OP content appears underneath that. ^ Similar to before, viewing the Page Record at this point shows three instances of the Page Record content: once in the Page Record itself, again in the Page’s “first comment” and a third time in the Page’s “second comment”. All while the OP content from the recently-merged Topic 1 is not displayed. A mod needs to make an edit to the Page Record. Click “Actions” > “Edit”, make edits, hit “Save”. What happens? ^ I think you get the idea… ———————— So what should be done? Well, I think that it would be good to re-write the system so that Page Records made via ‘Copy to Database’ do not have the original Topic’s content overwritten or unified. Instead, the Page Record content should be placed in its own field in the database’s Topic table, and displayed outside of the Topic area as its own widget/content above the Topic area. You could use the “Feature First Post” mode to dedicate that spot to echo the Page Record content, while keeping the area underneath as an untouched ‘forum area’. ^ I did a little mockup of what that could look like. As you can see, the Page Record area includes the Page Record content, which lives independently from all of the Topic content (and so doesn’t overwrite any of the Topic content), and underneath the Topic area with the untouched OP content from Topic 1 (after merging with Topics 2 and 3) ^ This is the same mockup page but scrolled down for full visual; just to illustrate that the original Topic would remain intact in its entirety with this setup, with no OP content being unified or overwritten by the Page Record content. The Topic OP that is used as a base for the Page Record connection could be highlighted in the Topic area to indicate the relationship (which might be useful in the case where the Page Record content isn’t actually all that different from the Topic OP content; users might wonder why they are seeing content twice, and so highlighting the relevant Topic OP post would resolve any potential confusion). And then replies appear underneath, just as it would in the standard topic. ———————— I know this is a big request, so I appreciate that this might be more of a long-term thing to implement… Thanks to any IPS Staff reading this far - I know Matt has previously talked about wanting to solve some issues relating to Pages + Topics connectivity, and so I wanted to chip in. I think this might be a good step forward for the feature.

Sorry Ehren I missed this - unfortunately this was all happening on my localhost. But it doesn't seem to be happening anymore so I guess it was either a random browser bork or something that a recent beta upgrade fixed (but probably the former if you couldn't replicate). Thanks for reaching out anyway!

Just made a few Events in a Club Calendar, and noticed that when this event is displayed in other areas of the suite, and doesn't have its own Cover Photo, the fallback thumbnail used is that of the Club's Icon and not of the Club's Cover Photo: As you can see, the result is an incredibly low-quality image appearing on Calendar views and widgets. The purple circle in the image above is the Club Icon that is being pulled for Calendar Events related to the club across the suite. The Cover Photo is much more high quality and visually engaging, and it would make sense for a future update to tweak it so Cover Photos are used in future. This issue only occurs when the Club Event doesn't have its own Cover Photo assigned, by the way. If I set a unique Cover Photo for the event itself, that image is used instead of the Club Photo. But it would be good to alter the fallback image option to have something more high quality.

I just noticed that polls can always be voted on when the topic itself has been published, regardless of its lock status. I understand wanting to keep polls open if a topic has run for a week and mods/admins decide to lock discussion on the topic, but it seems like an oversight to allow votes on a poll that an admin doesn't want to start yet (which is the assumed condition when the "Unlock Time" feature is used in the Topic creation form)? To elaborate more about my specific use case, I'm setting up a number of poll topics ahead of an event I'm planning to run for my community (a very vote-heavy one, as you might have assumed already). Each poll needs to be run on a specific date/time, and so I thought I'd be efficient and make the topic and use the "unlock date/time" feature to prevent any interaction taking place on those topics before we plan on running the associated poll. If I create a topic, add a poll and set the Unlock Time to a future date (say, tomorrow morning at 9am), then hit publish/save, the topic is visible (as desired) and no comments/replies can be posted (as desired) until that set time, but the poll alongside it is very much open for votes to be counted. There are two solutions I can see that could fix this: Lock Polls in topics that use the "Unlock Time" feature in Moderator Options, to prevent votes from being cast until that time Add a new option under the "Poll" tab of a Topic creation form next to "Automatically close poll on specific date?", which works in a similar way but for opening the poll ("Automatically open poll on specific date?") In the meantime, my only option on V4 (I haven't tested this issue in V5 but I assume it's the same) is to create the poll topic and hide it, then remember to manually unhide it when I want to start the polling, which isn't ideal. Any chance this can be looked at, as a QOL update? :)

Oh I see what the problem is - that option only appears if you click the blue "Add Page" button in AdminCP, not if you click the "+" button within a Page Folder. I'll log this as a bug in the tracker, thanks Matt.

Great job as always, guys! Quick question, I saw this in the release notes: #3561: Restore HTML pages functionality for PagesBut I'm not seeing that reflected in my localhost test environment (updated to the Beta 5.0.4). Don't know if this note is referring to some other functionality that has been restored and I'm misunderstanding? ^ What I'm seeing in V5 versus... ^ The HTML functionality that exists in V4.

Yes, that has been my experience with V3 and V4 too. That's my point: that this will likely change with V5. And it's not just a prioritization matter; I imagine it no longer makes business sense for IPS to dedicate resources in splintered development across six separate apps that may or may not be interacting with each other. Matt and the IPS team have already said many times that Self Hosted is becoming less valuable to them in terms of revenue and more of a burden, so being offered the entire suite in a single package was really the only way you were ever going to see V5 in a non-cloud offering. Of course, it's up to you if you wish to use another solution instead, but that is the offering that IPS has now. The rest of your post doesn't seem relevant to what I said, so I won't comment.

I remember that IPS already addressed this question (I can't recall where, sorry) a few years ago. The reasoning for this, IIRC, was that offering a 'bare bones' suite with Core+Forum only and allowing for additional apps to be 'bolted on' (as used to be the case before, and what you're asking for) is simply not viable anymore - neither in terms of development, nor in offering a quality product. The apps that didn't sell would be less developed in terms of feature-set, and connectivity/interoperability between those apps would suffer as a result because IPS would only consider spending dev time on improving/upgrading the apps that people actually bought. We have all actually seen this to be true - I have seen many complaints in the past about how updates on V4 favoured Forums and Pages, with little care or attention paid to Gallery, Blogs or Commerce. This way, with V5, development time can be focused on all apps working together (and the dev team would not have to spend so much time considering use cases where a client might have the Blogs app but not Gallery, or the Commerce app but not Pages, and the many variations of this).

Thanks for the assistance @Jim M and for the added context Terabyte. Maybe another thing to look into, if possible, is to also use the tweet's media tag as the blog entry's cover photo, too. But that's more of a suggestion than a bug I suppose. But figured I'd mention it, while we were talking about this.

I am doing some tests on my live site (V4) with Blogs and the RSS Import feature. I'd like to use RSS feeds of Twitter channels to automatically post any tweets into my Blogs app. But I'm having some trouble with it. I'm using a service called rss.app to generate an RSS feed for select Twitter channels, and I'm using those xml files as a basis for the RSS Import. But images and video that are attached to tweets don't display on the Blog entries that are generated on Invision Community. It is also not automatically adding new Blog entries on Invision Community when the feed updates. Steps: > Create a new Blog (private, not public, for testing purposes) > Manage Blog > Atom/RSS Import options > Check 'Enable RSS Import', set URL to "https://rss.app/feeds/8X3mB2dbhydz7V8r.xml" (the Twitter RSS generated from rss.app) > Hit Save; initial blog entries are generated > Click through to an entry that should have an image attached to the original tweet; doesn't display. I've talked to support on rss.app about this and they say the image meta is fine on their end (rss.app also has an on-platform feed reader which does display a tweet's associated images), and they suggest it is some issue on the Invision Community side. Videos, according to rss.app, won't display anyway because of how Twitter's structures its website data, but images should be working fine. Any ideas what might be causing the issue (both the lack of auto-posting Blog entries and the lack of image output)?

To be fair, has anyone from IPS actually said those specific words ("It's for the best / get used to it"), or is that just projection on your part because they wouldn't do what you asked (happy to be proven wrong, genuinely curious)? Because in my experience, I've always had any rejections of my ideas come with a polite explanation of why they can't/won't do something I've asked. It does suck, obviously, but ultimately the suite as-is remains a great product, if anything is considered 'out of scope' for the core development team to work on, there are always third-party coders and solutions to get you what you need.

Noticed that the way Club Content is currently displayed across other apps in the suite is a little off. Links to Club Gallery/Forums in those apps, for example, include the Club Name in the title alongside the name of the gallery/forum itself, which looks pretty poor (especially when scanning pages looking for something to draw the eye to - just looks like a mess of text). ^ That's what the Club Forum and Club Gallery items look like on the Forum and Gallery apps. 🤮 I suggest we break out the Club Name from the Title and include it as meta underneath the Gallery/Forum name, with an icon to represent that it is from a Club. The Club Name should also link to the Club itself, in case users are interested in browsing that Club (and possibly even joining). ^ That looks a lot cleaner, and I think users will appreciate it too. 👍