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. 👍

It would be great, to help with consistency, if Forum Topics that had 'Feature First Post' enabled were designed in the same way as other nodes across the suite. Namely, Page record designs. To illustrate, here's a comparison of the same content posted across both Forum and Pages (using 'Copy to Database'). I used web inspector to remove the cover photo from the Page record to make the comparison a bit more obvious: ^ Page Record ^ Forum Topic There's additional padding in the main content area on the Page record, which I think would look good if mirrored on the Forum post. Also, the 'byline' / author strap on the Page record looks pretty good with the background colour and borderline; would be nice if this was matched on the Forum (I know there are other buttons/meta that's specific to Forums that need to be considered, but maybe some of that information - rank badge, online indicator etc - could actually go the other way and be displayed on the Page record too). I know I could just do this with Custom CSS (and I actually did with one of the beta instances I had until that borked and had to recreate my V5 theme from scratch...), but I figure I'd put it here as a suggestion for an out-of-the-box improvement. Played on my mind as I remember some chatter about aligning Blog articles to get closer to the Pages design in recent updates, so thought it was worth mentioning a similar unification for the Forums app too.

You know, I thought OP was just a... "confused" individual that had buyer's remorse after agreeing to very obvious and very big-letter V5 terms that they no doubt would have needed to read several times before confirming... but to find out they haven't even moved to V5 and are still on V4? That's crazy. So "you forced my bill [to increase]" was a total lie, then. 😂 I know it's a necessary evil for a company like IPS, but personally TrustPilot is perhaps one of the least trustworthy sites out there, ironically enough. I'm going to write a review too! In today's world, I honestly think it's a better policy to publicly call this kind of stuff out (but only on rare/especially egregious cases like this where you feel it could damage your rep... otherwise you'd have a forum swamped with complaints and that doesn't look good either), as these days the internet tends to be judge, jury and executioner without prejudice as soon as they see someone being disingenuous like this. It's a shame that supposedly grown adults can't even be courteous online these days.

I'll drop the "almost" if I can get a slice 🍕

I broadly agree, but I'm going to be the annoying one and say that I'd likely have a need to multiple colour schemes at the very least (there are a lot of colourful characters - and lots of fans of each of those characters - in the kind of community I manage!). Also you guys have made V5 almost too good, because now I'm thinking I should offer different themes just to offer an option of sidebar/no sidebar! It's ironically made the Theme select situation a bit difficult for me, because I don't want to make 10 different colour themes * 2 for every structural/design choice (blue theme for classic design + blue theme for sidebar design for example). I'm trying to think creatively about it, and am looking at maybe using Custom CSS variables and template hooks to add a second dropdown next to the Theme select to specifically change the colour palette of the current design theme... but I'm currently not clever enough to connect the dots fully on that. Maybe in a couple months when I swot up! I personally don't get the confusion (light/dark and theme serve two separate functions now), but I appreciate that some might find it strange.

I'm not sure what you mean. It does make sense to have light/dark options alongside a theme selector because different themes may have different colour schemes (and therefore different dark colour themes). Different themes may also have different design settings (things like page layouts, enabling sidebar menu etc) which you might want to offer your users. You no longer need to create an entire new theme in V5 in order to accomplish light/dark modes, it's all handled in a single theme's Theme Editor options. I believe you can choose to remove the light/dark/system options too and force just one or the other for the user, via the Theme Editor... Nothing about that seems counter-intuitive to me. In fact, it seems a bit redundant now to have multiple themes in V5 just to serve a light/dark purpose (like you had to do in V4). Just build one theme and set the light/dark options in the Theme Editor.

If you're talking about the 'Theme' dropdown, I believe that menu disappears completely if you offer only one Theme to users. To do that, you'll need to go to AdminCP > Customisation > Themes and from there click 'Edit' on every theme that you don't want to make available, and under 'Available for' make sure you uncheck all boxes (or click 'None') and hit 'Save'. Once you only have one Theme that users can select, that dropdown will disappear.

You're very welcome @SC36DC ! More than happy to help, glad you were able to get it working the way you like it too!

So it still occurs on an unaltered theme, but I think I figured it out. Those options DO work when applied against an 'area' layout (i.e. multiple widgets stacked together, in either a 'brick', 'grid', 'center' layout etc), but they don't in the instance I showed above... because I'm trying to apply it to a widget ('Tagged Content') and not an area. Whenever I click on any other widget (Image, Media, Club etc) those two options ('block pad' and 'inline pad') do not appear at all. So I think this is a case of, these two options are appearing when a 'Tagged Content' widget block is selected, when they shouldn't be. So, still a bug, but just a slightly different one. :)