Dreadknux

Unfortunately @Sirmadsen, this is a bug (not IPB's fault, but due to constantly changing API parameters by Facebook themselves) and I've logged it in this topic. It doesn't look like IPB will spend the resources to fix it (understandable), instead leaning on Zapier integration.

Thanks for the follow-up Matt - makes sense, Facebook changes their whole API every five minutes! Zapier isn't really something I'd have the budget for, so hopefully this can also be solved by a marketplace app from a community developer or something.

Just wanted to say, thank you so much for this app. It's lovely, and very thoughtfully made! I have enjoyed reading your documentations and your friendly responses to users on your website as well. Thank you again. Just to add to someone else's comment, my website was too being affected by Enabling the app... it was shifting the sidebar on ALL pages to the left, instead of just the pages I selected in the Settings page. It was very strange. However, updating the app to v2.1.2 has seemingly fixed this problem. The sidebar and theme is now left unaffected, and sidebar stays to the right with exception of the Docs database I have installed. 🙂 I wanted to ask about the left sidebar actually, it seems that when changing the position of the sidebar it automatically puts the sidebar content ahead of the main content when the browser window is shrunk down. Please see an example below. This is Desktop view. As you can see, the left sidebar and contents are where it should be (although is there a way to make it so the Menu block appears above the Announcement and Advertisement? Maybe I just need to modify the template directly to insert the block separately...) This is shrunk to tablet view, and all of the left sidebar content now appears above the main content area (whereas it should appear beneath the main content). It's a lot of scrolling to get to the content. The same happens on mobile view, the mobile-friendly menu also no longer sits at the top of the page but rather halfway down after a lot of scrolling. Is there any chance this can be tweaked so that, even though the sidebar is on the left on these pages, the content is treated as if it is on the right (and therefore appears underneath the main content area when viewing on tablet or mobile)? Thanks again, I appreciate the efforts!

Any chance someone from Invision Community team offer some feedback/thoughts on this? Whether it will be considered, and if so what the roadmap looks like for this? I think it will be an incredibly useful feature that will enhance your Pages app significantly. Appreciate the time in reading this.

Hi guys, starting to get used to Pages app as a potential alternative to move away from my current Wordpress setup (although there are a few issues that I'd like to see resolved first before I take the plunge, I've made topics about those before here I think), and looking for a solution to easily allow for a "Writers" usergroup to share a common imagebank when developing articles and news stories etc. After playing around with the Invision Community Demo, I've found that the Gallery app could be a potentially elegant solution for this, by creating a gallery that is only visible to "Admins" and "Writers" (not Members or Guests). I thought a great feature was the ability to search through Gallery Images when looking to add media to a Pages record, as shown below: However, only the user that uploaded the image can opt to use it in this way - not the rest of the usergroup (or any other group that has access to the gallery). When a different user (who did not originally upload the image) in the "Writer" group tries to add an image the same way, they only see this: It would be great if we could allow for shared galleries, that multiple people in a usergroup can all access no matter who originally uploaded the images.

Thanks for the explanation - bit disappointing. Is there a way this can be fixed in an upcoming update when there is time? It seems quite inconsistent with the supposed goal of sync'ing topics and Pages records, and very confusing for the end user (especially when comments' reactions are synced just fine).

Hi guys, I'm not sure if this is a bug or just something that I've setup incorrectly, but in my Pages database I am noticing that the record's Reactions do not sync up with the associated topic that it is linked to. To give you an example, I took an existing topic on my forum, in which the original post already received around 20 reactions from other users, and Copied to Database so that an identical Pages record was created from it. However, on viewing the Pages record version, the 20 or so accumulated reactions from the topic are not carried over. Image 1 above: Original topic, please note the 20 reactions set against the original post plus the one reaction set against the first reply there. Image 2 above: Pages version of the same record. Please note the lack of any reactions underneath the post (should be on the same line as 'Article actions' and 'Revisions'), and yet the reaction set against the first comment ('You', with the thumbs up reaction) is sync'd. I played around with some of the settings, and toggled on the option for post authors to be able to react to their own posts. When that setting is enabled, I can see the reactions dialog appear in the correct place on the Pages record, but it seems to be tracking its own number of reactions and not sync'ing with the topic's number of existing reactions. Image 3 above: Pages record again, this time with the Members > Member Settings > Reputation & Reactions > "Members can react to their own content?" setting in ACP toggled on. Note how the reactions dialog does appear as expected, but instead of displaying the 20 reactions that have already been accumulated through its sync'd forum topic, it is logging its own individual number of reactions. How can I set this so that any Page record that is sync'd with a topic can share the same number and type of Reactions? It seems very strange that the Database sync feature would sync almost every single other element of a Page and Topic (even Reactions on comments!) but not reactions on the original content itself. Appreciate any help on this, or nudge in the right direction in case I've missed something! 🙂

How do I customise a Category Listing template in Pages so that sub-category records (as well as category records) are visible, preferably in a masonry-style layout with pagination (similar to the 'Category 2 Column First Featured' template that's seemingly designed only for top-level category indexes)? For example, I have the following Pages database/category structure: domain.com/articles domain.com/articles/features domain.com/articles/news (three records exist) domain.com/articles/news/games (five records exist) domain.com/articles/news/comics (two records exist) domain.com/articles/news/movies (three records exist) For the /articles/ top-level category, I can simply use the built-in 'Category 2 Column First Featured' template to get the desired design I like. This template includes all posts within the entire /articles/ database, including those from sub-categories like 'features' and 'news' and all the sub-categories within those too. This is great. No complaints here. But when I visit domain.com/articles/news, I am both unable to easily use the 'Category 2 Column First Featured' masonry template design, nor am I able to see sub-category records on the page. Underneath the subcategory table in the default view, I only see three records (the three that were created specifically within that /news/ category). What I want to do is set things so that records from /articles/news, /articles/news/games, /articles/news/comics and /articles/news/movies all appear on the /articles/news/ category listing. How do I make that happen? I must admit I'm quite proficient in CSS/template design, but the technical/coding side of Invision is a little beyond me 😄 I feel like this would require some level of unique php coding to call sub-cat records or something, but maybe there's a solution already out there that I'm not aware of? Appreciate any help!

Appreciate the response, thank you Marc! 🙂

No problem, just wasn't sure if it was being looked at or not. I appreciate it, thank you!

Any feedback/thoughts on this (or my other topic here), IPS Team? Intended, unintended behaviour? Urgent, not urgent? Fix, not gonna fix?

I have found a bug that occurs when trying to merge duplicate forum topics with a topic created from an existing article/record from the Pages CMS. Setup 'Articles' Database has been created in Pages CMS Under 'Forums' tab in Database settings, 'Post Topic' and 'Use Forum For Comments' is checked, and a destination forum specified Steps to Duplicate 1. Create a record in the 'Articles' database, then post a comment on the resulting article page. This should create an associated topic (for the article content) and post (for the comment content) in the destination forum, as outlined in the Database settings 2. Create two forum topics in the same destination forum set in the Articles Database settings. Select the two duplicate topics, plus the topic created via Pages CMS (titled 'Test Merge Article 2' in the below screenshot). 3. Select the 'Merge' option using the mod options at the bottom of the screen. The only options available to you are to make either of the two forum topics the dominant topic. There is no option to make the topic created by Pages CMS ('Test Merge Article 2') the dominant thread. 4. Select one of the two topics as the dominant thread (I chose 'Test Merge Forum Topic 1'), and select 'Merge' (I also opted to 'leave a link to the new location', but I do not think this makes a difference to this bug) 5. This is the result: not only is the resulting forum topic forced to keep an incorrect and unintended title and URL (in this case, I am forced to accept 'Test Merge Forum Topic 1' as the dominant thread and not 'Test Merge Article 2' as desired, meaning that I will have to rename the merged topic and change other details), but the merged topic is seemingly de-coupled from the Pages record and the comments removed from view when visiting the record on the Pages side of the site. I am sure this is a bug (or a design oversight) as I cannot imagine this is intended behaviour. I should be able to merge forum topics into a Pages CMS-created topic and have that be the dominant thread, with all merged posts within that topic being associated with the Pages record. Can this be investigated and fixed please?

So I'm trying to take advantage of the social media promotion / Our Picks feature on my forum, and while Twitter integration is working as intended there is some sort of fatal error preventing me from connecting my community to my Facebook Page. When going through the AdminCP, I'm told to head to Facebook and sign in to grant the following permissions: 'manage_pages' 'publish_pages' However when I click the links to head off-site and onto Facebook, the following error is thrown at me every single time. I have done some digging and it turns out that both "manage_pages" and "publish_pages" are actually deprecated Facebook Page parameters since mid-2020, which I am assuming is leading to the errors here. https://developers.facebook.com/docs/permissions/reference/manage_pages/ Classic case of Facebook changing its code every five minutes... but it does mean that IPB's software urgently needs to be updated in order for this feature to work correctly now. Can we please get this addressed in the next bugfix update?

I see. So it works essentially the same way as 'Theme Resources' but for Pages. Perhaps that could be renamed then as the term 'media library' implies something more akin to Wordpress' own integrated media library (that works as @Maxxius mentions). Page Resources, perhaps? Thanks for the explanation @opentype, that makes a lot of sense now. I feel like my suggestion, then, is even more useful: This is something IPB lacks and is a severe drawback compared to other solutions such as Wordpress, which has an integrated media library where users can upload an image/audio/video to a sandboxed depository, to be re-used/searchable by other editors for multiple pages/articles.

Some smaller (but useful!) suggestions I've made in the past: Allow Multiple Categories to be assigned to a Page record Options to change URL slug format on a database level (by [YYYY]/[MM]/[record_slug] for example) Remove the "-r" at the end of a record's URL by default (this one is really annoying) Allow Page Categories to be set in Menu Manager Ability to pull records from multiple databases in Widgets/Blocks/Loops But in particular, I'd like to throw in a more inspired idea. I'd like InvisionCommunity to really focus in on the relationship between Pages and the Core community. @Jordan Invision I enjoyed reading about how you were able to migrate your news/blog into the core InvisionCommunity software to great benefit, so I figure you might appreciate this suggestion as well. I think it would really help integrate the two apps together and encourage community activity/contributions. 🙂 The concept is to improve the 'Copy to Database' feature. Let's say that I run a movie news website/community. Oftentimes, the community will post (and react to) a piece of movie news (a new trailer or celebrity interview) as a Topic in the Forums, before the admin's staff writers get a chance to write a story about it. To avoid duplication of content, Copy to Database can be a powerful tool - admins can import a user's existing topic to a 'news' record in Pages. But there's a problem; by doing this in the current InvisionCommunity system, you either destroy the original community user's content (if your site editor writes new content when Copying to Database) or you create a duplicate topic in a different forum to where the original Topic lives, creating redundant content (which will return duplicate results in searches). This can be alleviated in three major improvements to the system: ------------------------------ Step 1: New AdminCP Settings to 'Keep Original Topic Content' & 'Add Post Meta' When Copying to Database The above image is a mock-up of two new options that could be implemented into the AdminCP. The first makes sure that any content in the original topic/post is not modified in any way when an admin Copies the content to Database - even if the admin decides to write entire new content for the news story. Why would someone want to rewrite a topic's content when importing to Database, but keep the topic itself the same? An admin may wish to simply unify Page comments and Topic replies, and keep the tone of both separate It gives the freedom to reword the information in the original topic to reflect the site's "house style" of writing, while keeping the topic's original informal tone It helps to acknowledge the community source of any resulting story (and avoid annoying the community by "censoring/deleting" their posts)... ...which can open the community up to special rewards for helping contribute to the site blog, via custom Achievements or Badges Step 2: Add Post Meta Related to Step 1, there could be additional post meta produced when an admin Copies a Topic to Database (which can be toggled on or off). A mock up of what that might look like is above. The post meta could be situated relative to the exact time an admin takes the Copy to Database action, or it could sit at the top of a Topic much like the Recommended Posts might do. Having this feature will make the community feel like they are contributing to the overall site/blog and that their content is getting noticed. Step 3: 'Post Topic' AdminCP Options Override in Page Creation Form If an admin creates a new article in Pages, they will often want to have that story re-posted as a Topic in a designated forum. That's where the AdminCP "Post Topic" settings come in real handy. But if that same admin wanted to create an article using Copy to Database, they may not wish to have an additional Topic created. They might think that the existing Topic - and all the comments/replies that may exist in it - is enough. Unfortunately, in InvisionCommunity's current setup, if you set your database category's "Post Topic" settings, it's everything or nothing. You can't tell InvisionCommunity to NOT post a topic on the odd occasion, if you do not want it to. That's where this Topic Override option comes in. Set at the per-post level, this gives admins the freedom to choose on an article-by-article basis if they want an associated topic to be created when the article is published. ------------------------------ I appreciate the open ears and eagerness to hear feedback! 😄 🙏

Thanks Rikki - great to see that there's interest in these ideas! I know that some of them might require a bit of heavy work/rework (I'm thinking the categories idea I mentioned in particular might involve some reworking of how Pages works with taxonomies/saved records in database). But I know that there's loads of ways Pages can be integrated into the Core community app - for me, fine-tuning the relationship between Pages-As-A-Blog and Forum/Topics would really elevate the Pages app into something special. 🙂 Happy to be patient and wait for when some of this can come to fruition - looking forward to the next generation of Pages!

For many years I've been using a customised badge/award plugin to assign badges to my community's users (for things like participating in community events), and with the new Achievements feature I'm considering migrating my old awards over to the built-in system. I have a few small suggestions that would really help out admins that want to lean more on custom badges rather than the Rules-based badge approach. 1. Custom Descriptions It would help a lot if admins were allowed to write unique descriptions for manually-made badges. At the moment there is no such feature and it kind of looks strange when you see manual badges alongside rule-based badges (which do include a description). For example: Notice how the top badge doesn't include a description? This could be added via the AdminCP > Achievements > Badges page by adding an extra option in the Edit Badge dialog. I'd like to be able to tell users exactly how they earned a particular badge, and it's a little awkward to have to do that in the Badge Name. Something like the below... 2. Multi-User Awarding As far as I can see, the only way to manually award a user a badge is by searching for their username in AdminCP > Members, clicking 'Manage' within the Badges dialog, and then click 'Add Badge'. It's quite monotonous, if you have many users that you want to award a single badge to manually. There should be an option to award members directly from the 'Badges' section of the ACP. A dropdown can replace the current 'delete' option, or an 'award' option can be positioned next to it. I made a crude mockup of what I mean, below. A dialog box could appear upon clicking 'Award to Member' which can allow you to type the usernames of multiple users. 3. Backdating / Custom Award Dates Another really useful enhancement would be the ability to set custom dates when awarding badges manually. Using the example above, you could include an optional date field within the award member dialog (either on the Badges ACP page or when managing badges on a User profile via ACP). As a lot of the badges I've previously awarded users date back as far back as 2014, it would be great to be able to add a 'legacy' badge to a user's profile and identify exactly when they received it, instead of relying on the moment it was specifically added to the user's account.

I agree - I've been exploring use of Pages as a means to potentially migrate a long-running Wordpress into InvisionCommunity (I've used Invision for my forums for the last 15 years or so), but as much as I adore the concept of having a unified theme/account integration for forums and site content, Pages isn't quite there yet for me and needs some attention. Hopefully now that 4.6 is out the door, Pages can be the next app to get InvisionCommunity's full focus. I certainly think that being able to splinter longform articles via pagination is a useful idea, as is the ability to dynamically modify a page's layout using different block formats. I've been thinking about it, and I'd love to see the following improvements implemented into the Pages app in some way too: 1. Multiple Category Selection It would be great if it was possible to assign a record in a database to more than one category. My Wordpress blog allows me to set a news post as either a ‘Games’ story, a ‘Movies’ story or both if the news concerns both mediums. 2. Change URL Slugs per Database At the moment, the definition is [domain.com]/[database_name]/[category_name]/[record_slug], and this is true for any and all databases you can create in Pages. Would be good to get some options on this - being able to use [YEAR]/[MONTH]/[record_slug] instead would keep things in uniform with a blog style. 3. Remove "-r" suffix on URL per Database I can understand the reason for the 'revision' suffix in a record URL if you're using it for a "wiki" like database of some sort. Doesn't really lend itself well for blog-style page URLs, or other potentially interesting uses of the Pages app. Should be a setting on the database-level in AdminCP to automatically remove the "-r" in a Page record slug by default, instead of asking writers to manually remove it after creating each post. 4. Pages Media Library I still don't really understand the use case for the internal Pages Media Library in AdminCP (Pages > Page Management > Media). What is it for, exactly? I thought it was going to be a 'media gallery' that could be used by Page authors across the entire database (similar to Wordpress' Media Gallery). But its use is extremely limited. It doesn't appear when creating a new article/record. The only way to use an image uploaded to this Media Library is to remember the media tag for each image and include it (and even then it only works in Page templates). It's quite useless, especially when the Theme Resources section exists. This should be re-imagined as a dedicated Page Database media library, accessible to usergroups with the ability to post records - with editable filenames and support for images, video, files etc. It should be accessible via the WYSIWYG post editor and the media contained here sandboxed from all other media uploaded by users (Gallery entries, Attachments, etc). You could set either a 'global' media library for everything related to Pages, or a separate media library for each Page Database. 5. Allow Categories to be set in Menu Manager I can set specific Pages as a Primary/Secondary navigation menu item in Menu Manager, but not the categories associated with a particular database. At the moment I have to set them as External Links, which doesn't allow for a consistent design when using CSS to style 'active' secondary nav links. 6. Ability to pull from multiple databases in Widgets/Loops This might already be possible re: the Loop and it's something I'm not aware of, but I have two databases ('News' and 'Articles') that I want to be able to combine if I wanted to. For example, on a Homepage I might want to build a block that contains latest News specifically, and a second block that pulls all the latest posts from both News and Articles. I feel like that shouldn't be too difficult to do... 7. Do Not Post Duplicate Topics when using Copy to Database Function 8. Do Not Modify Original Topic Content when using Copy to Database Function 9. Add Post Topic Meta when using Copy to Database Function I explain these last three in more detail in a topic I created a month or so ago, but basically the 'Copy to Database' function doesn't lend itself well to non-wiki style Page-Forum integration. The idea currently is that, if an author decides to write a news story (for example), a Page record and an associated Forum topic is created together, with Page comments and Topic replies merged. However, if an author decides to write a news story based on a topic that exists already, using 'Copy to Database' will result in a Page record, a new duplicate Forum topic AND the existing Forum topic. There needs to be a way to override the Post Topic feature, while keeping the Comments-Replies integration. When using 'Copy to Database', the existing Forum topic content is also changed to reflect the new Page record. For instance, an author re-writes the text from the Forum topic when developing the Page record, to make it read better as a news story. The original topic should not be modified if this happens; I'm not entirely sure why this is considered normal behaviour in Pages anyway. The Topic Meta idea just adds a little nice site-forum integration to the Copy to Database feature, and isn't really necessary... but I think it would help make a forum community feel more connected to the news/article side of the website, if they were made aware that their topic contributions were also having an impact on the associated news story. ---------- Sorry for going on and on - there's a LOT to Pages that I like but I think if your ideas and the above ideas are followed through on, I would feel a lot more comfortable taking my Pages install out of a test environment and look to fully building it into a revamped version of my community. 🙂 Thanks for making the topic, great ideas!

Really enjoying the release of 4.6, now that it's released I wanted to re-suggest this as an important feature to consider for a next version of the Pages app. I think it would really help integrate the Core app and Pages app further, in a way that other solutions (i.e. XenForo + Wordpress bridge - which I'm looking into as an alternative) will be unable to. I'd really love to have a one-stop shop for my users to view and comment on news and forums using a consistent design and account system, and the above suggestions would go far to making Pages the perfect app for this.

Interested to know if anyone from the Invision team would consider adding options like these for a Pages update.

Hi guys Long time InvisionCommunity user, almost-first-time poster. 🙂 I've been using this software to power my community forums for about 15+ years now and I'm looking to take the next step by building an integrated site for my users. I recently purchased the Pages app to experiment with it - the idea is that, one day, I might migrate a long-running Wordpress blog into Pages. With that in mind, I had a few ideas that would greatly help with improving workflow and ensure more consistent connectivity between Forums and Pages. I hope you'll consider them! To keep things concise, my ideas here are focused on the 'Copy to Database' feature of Pages (I do have other ideas but this is the biggest area of concern for me - I'll post the other suggestions in a separate thread). My Setup In AdminCP > Pages > Databases > Articles > Forums, 'Post Topic' and 'Use Forum For Comments' are enabled. Post Topic is enabled because not every article we write will be sourced from a forum topic or Copied to Database, and we want to make sure that all news stories we write have an associated topic posted (i.e. if a topic does not exist already, we want to create a topic, but if a topic does exist we want to Copy to Database and use that particular topic as the news story's associated topic) Use Forum for Comments is enabled because we want to always marry the comments in news stories with the replies in the associated topic. We never want this feature to be disabled. My Scenario A regular user in my community discovers some interesting news that they may have read elsewhere, and posts a topic on a particular forum. A member of my community's "News Team" usergroup sees this topic, notices that our Articles database has yet to cover this news topic. The News Team member chooses to 'Copy to Database' the original topic. The original topic is written in a way that works fine for a community environment, but it needs editing in order to read well as a news article. So the News Team member modifies the original topic content to suit the tone of voice we want to present within our news stories. The Issues When the News Team member posts the news story, a duplicate topic is made (in the forum selected in AdminCP). This has the result of confusing the community as there are now two separate topics in which to submit replies/comments to. When rebuilding synchronised topic content, the original topic's content is modified to match that of the news story which was created from it. This is not desired behaviour; if copied to database, the expectation is that the original topic remains the same, with any edits made for the news story living solely on the page record/database. There's no topic meta to illustrate to users on the forum that a news story was created from it. The Solutions: 1. 'Post Topic' Override (per Record basis) A simple checkbox could be added to a record creation page, if the 'Post Topic' setting is enabled for that database in AdminCP. What this will do is ensure that a topic is not created when the record is created. This will be useful for users who want to use an existing topic as the basis for a record's comments/replies without splintering it into a duplicate topic elsewhere. However, some users might find posting a duplicate topic useful (for instance, they might want to dedicate a specific forum for record entries), which is why having this as an ad-hoc option is the best solution here. 2. AdminCP-level Option to Keep Topic/Record Content Separate Provide a toggle which allows the content in the Original Topic to remain unaffected/does not sync with the copy written in the Page content. I would have thought that this would be standard behaviour, so it's surprising that it's not. I doubt many community members would appreciate their topics being edited without their consent, so this option would fix that issue. This could be a new setting added to AdminCP, which applies to all records made in a database (as illustrated above). 3. Add Topic Meta to Copied Topics Upon using 'Copy to Database', have a setting/toggle (default setting: On) that automatically inserts a new Topic Meta box in the original/source topic, detailing that a user has used the thread as a basis for a new 'record/story/article'. Clicking the Meta box could dynamically expand it, revealing an excerpt of the new story/record/article (Title, Author, Date, Excerpt, Link to Full Article). Some ideas as to how that would look like below. Idea 1: Idea 2: This could also be a setting in the Database options page in AdminCP. A feature like this would be a more elegant solution when copying topics to databases, instead of simply syncing the topic content and record content to be identical. It can also allow users who create interesting topics to see that their posts have been considered worthy of interest from the moderation/news team. You could even tie Achievements/Points/Rewards to this - users who create topics that a moderating team deems interesting for a story, could be awarded points for 'sourcing' the content. --------------------------------------------------- Hopefully these suggestions are worth considering and implementing in a future update. I know the next update of the Core app is at the forefront of the development team's minds right now, but I think these would be great QOL updates for the Pages app that can make it even more unified with the Forums/Core. Thanks for reading!

Now I understand that changes have to be made to the core codebase whenever a new version of IPB is written. But in the last couple of updates (3.0.3 and now 3.0.4) I have had skins that I have developed during the 3.0.1 era break completely on me, because of deprecated skin code and a complete disregard of the skin's CSS on browsers (possibly as a result of deprecated skin code). Now, as I have worked very hard on my unique themes and they are vastly different from the IPB default skin, simply implementing the Skin Differences published is easier said than done, nor should I expect to constantly update my skins in this manner. I was led to believe that when 3.0.0 was released, that custom skins could be created without fear of them breaking in future releases. This has turned out to be a false belief. Skins made the second a brand new version is released should be supported 100% until the very end of that version's life cycle. If nothing else, I would expect the money I paid for this software (and services) to reflect this, considering I have no time in my life now to micro-manage my skins whenever an incremental update comes out. IPS, figure out where you want to be with your skin design and stick to it, please! Stop changing your mind every twenty seconds and invalidating my custom skins. I would like some confirmation that this issue will not occur again in future updates, otherwise I might as well just not make skins for my forums again (what would be the point?). Regards, Svend Joscelyne.