Dreadknux

I've been experimenting with the Gallery app, considering a purchase in order to enhance my current Core + Pages installation.
Please implement the following QOL improvements, and I'd be very happy to pay for the app:
 
Shared Galleries for Post Editor
Allow the ability to use images uploaded to a Gallery Album (or category of albums), set at the Usergroup level. As it currently stands, only the user that directly uploaded an image to an album can later access the same image when creating a post/CMS Page/similar.
The user who originally uploaded images to an album called "Shared Art" can then go to a CMS Page/Article, click edit, then head to 'Insert Existing Attachment' and see this:
Admin (original uploader of Gallery images) view:

However, another user (let's call them 'TestUser') who is in a Staff/Moderator group, who I might want to be able to also edit CMS Pages and insert the same images, currently cannot do this:
AnotherUser (moderator usergroup user who should also have access) view:

Please add a new permission, something like this:

This way, a user in the group can access images uploaded to that album (or category of albums) as if they uploaded it themselves.
If the "Insert Existing Attachment" location is not a logical place to set such a feature (because you would only expect user-uploaded images to exist in this menu), then please create a new option that does make this logical.
 
Post Editor Dropdown Menu for Galleries
In addition to the above idea, it would be great to enhance the discoverability/filtering of images within the Existing Attachment menu in post editor too. Please see the below concept; a simple dropdown box can help filter and sort images and allow users to quickly fetch the item they need. This will be useful for the above 'Shared Gallery' feature as well as solo Gallery users who just need an extra method of filtering the non-shared images they uploaded on their account.

 
Hooks for CMS/Pages, Custom Fields & Album Tagging
I want to tie certain Galleries into specific records in the CMS/Pages app. There appears to be no simple way to do this - there's no ability to set custom fields for galleries (thus creating a unique ID/hook in order to tie a Gallery to a Record ala Database Relationship/Reciprocal Items method). There doesn't even seem to be a way to set Tags or Prefix Tags to Albums (only on images themselves - unless I am missing something). The opportunities for coders to extend the capabilities of Gallery in the same way they can Pages seems extremely limited, and it would be great to allow closer integration with CMS using various custom field calls and cross-linking relationships with Page Databases.
 
Smaller QOL Improvements
Things like being able to rename uploaded items (it's every admin's nightmare having to see image13362363556.png on their server...), crop an uploaded image via the Image Tools features, and perhaps create custom Record Images for CMS/Pages from images in Gallery (as a cropped copy so as not to modify the original uploaded image) would be lovely as well, if they could be looked into (unless they exist already and I haven't seen them during my demo test with the app).
 
If these were considered, acknowledged and implemented you'd get a sale from me, for sure. 🙂 

There's a lot of confusion here, so I'll do my best to address it all.
Why have you removed CSS editing?
First off, we have NOT removed the ability to edit and add CSS to your themes. When we released Invision Community 4.0 way back in 2012, we added a "custom.css" file and asked everyone to add their custom CSS to this file. This means that when we make changes to the core CSS, you do not have to merge changes, or re-apply edits. Your custom CSS is untouched.

This is exactly what CSS is designed to do. The core CSS may contain something like this.
body { font-size:14px; font-family: Helvetica; margin: 10px color: black; } So, what do you do if you want to change the colour to red? In the past you could edit this core CSS file directly and make it like so:
body { font-size:14px; font-family: Helvetica; margin: 10px color: red; /* Changed color here from black */ } This would work fine BUT if we changed our core CSS to change the font-size to 16 like so:
body { font-size:16px; font-family: Helvetica; margin: 10px color: black; } This will now overwrite your changes, which means you'll need to re-edit it back to:
body { font-size:16px; font-family: Helvetica; margin: 10px color: red; } This does work, but means you are constantly having to compare your changes to ours.
Fortunately, CSS (cascading style sheets) is designed to allow new CSS files to overwrite rules that we set, and that is why we have a custom.css file ready for you to make your upgrade-proof edits.

So, if you wanted to make the body colour red, instead of editing our code and maintaining changes, you simply add this to custom.css
 
body { color: red; } CSS knows to combine OUR rules with YOUR rules. It's exactly what CSS was designed to do. The computed result (how the browser sees it) of this is exactly the same:
body { font-size:14px; /* from our core css */ font-family: Helvetica; /* from our core css */ margin: 10px /* from our core css */ color: red; /* from custom.css */ } This is clearly a much better way of changing the CSS rules. You can keep all your custom code in one place and you no longer have to maintain copy and paste edits to core CSS.
In short, CSS editing STILL VERY MUCH EXISTS!
Why this change?
To be frank, it's 2022 and there's no valid reason at all to be editing core CSS when CSS itself was designed to cascade and make your lives easier.

We should have locked out editing of core CSS a long time ago. As the web moves on, we have to move on too. Serving CSS from a single CDN will improve the page speed of your site as it will come from a cached no-cookie domain.

No modern application out there will allow you to edit core CSS, there just is not the need.
I realise that for a very small number of people this means changing how you work, but this is how you should have been working since 4.0 was released a decade ago.
If you actually use custom.css I promise once you have completed the initial population of this file, your life will be made so much easier!
This is industry standard
If you look at other apps, they allow you to add custom rules that cascade over the core CSS files. Like Squarespace, and Wordpress which states: "You can use the CSS editor to customize the appearance of your WordPress.com site. It works by allowing you to add your own CSS styles to override the default styles of your theme."

Hello! Found something weird, not sure if anyone else is getting it or if I'm doing something wrong. But I have a Pages database with the Publish Date field activated. I'm trying to populate this database with backdated historical articles. The IPB system is letting me do this... eventually. But for the entire system to accept it I have to publish and edit the record several times.
Here are the replicable steps:
Step 1: Create new story as normal via Pages interface.

Step 2: Set Publish Date field to a past date, instead of 'immediately'.

Step 3: Publish. The system for some reason does not accept the past date, and instead acts as if we published this entry just now.

Step 4: Click the Prefix Tag ('Dreamcast', above the headline in the above image), which will take you to the Search section of the site listing entries matching the same tag. The newly-published article will be present, but its publish date will also be 'Just now' instead of in the past.

Step 5: Go back to the article, click 'Story actions > Edit'. Go to 'Publish Date' and re-enter the past date. Save. The article's date will be corrected.

Step 6: Again, click the prefix tag ('Dreamcast') and check once more the Search results for the tag. Even though the Pages entry's date has been fixed after the edit, the date listed on the search meta still acts as if it was recently posted.

Step 7: Go back one more time to the article, click 'Story actions > Edit', change nothing and just hit 'Save'. Go to the article in question, click the prefix tag one final time. Check the Search page results. The date has been fixed.

For some reason, going through the edit process a second time will correct the date on Search.
I imagine this isn't expected behaviour, but wanted to know if there was anything I could do about this or if it is simply a bug that needs fixing? Authors should only need to input the publish date of an entry once, but in order for it to work properly here the entry needs to be published, edited and then edited again. It's a bit much. 😅
Any ideas?

Thanks Matt. A lot of what I'm doing at the moment is still WIP/behind the scenes so it's not critical, just a minor annoyance. 🙂 If it means anything, I should mention as well that I have this database set up to post topics when an entry is created, and similarly when the associated topic is created the date on that is also not adjusted to suit the intended past date (this is true on the forum its supposed to be created in, and the Search results page in which the topic pops up).
I mention that in case fixing the issue with the Pages date setting also doesn't happen to fix the same for the associated topic posting. Usually I think you cannot edit a topic created from a Pages record, but I am at least able to work around this issue by using a third party plugin that allows me to edit the post date of topics...
Appreciate you guys looking into this!

This has now been resolved in the latest release (4.7.2). Please update to this version to resolve the problem. If you are still experiencing the issue after upgrade, please let us know.

I've opened a bug report for you on this. I agree that this isn't what you'd expect to happen.

I've been experimenting with the Gallery app, considering a purchase in order to enhance my current Core + Pages installation.
Please implement the following QOL improvements, and I'd be very happy to pay for the app:
 
Shared Galleries for Post Editor
Allow the ability to use images uploaded to a Gallery Album (or category of albums), set at the Usergroup level. As it currently stands, only the user that directly uploaded an image to an album can later access the same image when creating a post/CMS Page/similar.
The user who originally uploaded images to an album called "Shared Art" can then go to a CMS Page/Article, click edit, then head to 'Insert Existing Attachment' and see this:
Admin (original uploader of Gallery images) view:

However, another user (let's call them 'TestUser') who is in a Staff/Moderator group, who I might want to be able to also edit CMS Pages and insert the same images, currently cannot do this:
AnotherUser (moderator usergroup user who should also have access) view:

Please add a new permission, something like this:

This way, a user in the group can access images uploaded to that album (or category of albums) as if they uploaded it themselves.
If the "Insert Existing Attachment" location is not a logical place to set such a feature (because you would only expect user-uploaded images to exist in this menu), then please create a new option that does make this logical.
 
Post Editor Dropdown Menu for Galleries
In addition to the above idea, it would be great to enhance the discoverability/filtering of images within the Existing Attachment menu in post editor too. Please see the below concept; a simple dropdown box can help filter and sort images and allow users to quickly fetch the item they need. This will be useful for the above 'Shared Gallery' feature as well as solo Gallery users who just need an extra method of filtering the non-shared images they uploaded on their account.

 
Hooks for CMS/Pages, Custom Fields & Album Tagging
I want to tie certain Galleries into specific records in the CMS/Pages app. There appears to be no simple way to do this - there's no ability to set custom fields for galleries (thus creating a unique ID/hook in order to tie a Gallery to a Record ala Database Relationship/Reciprocal Items method). There doesn't even seem to be a way to set Tags or Prefix Tags to Albums (only on images themselves - unless I am missing something). The opportunities for coders to extend the capabilities of Gallery in the same way they can Pages seems extremely limited, and it would be great to allow closer integration with CMS using various custom field calls and cross-linking relationships with Page Databases.
 
Smaller QOL Improvements
Things like being able to rename uploaded items (it's every admin's nightmare having to see image13362363556.png on their server...), crop an uploaded image via the Image Tools features, and perhaps create custom Record Images for CMS/Pages from images in Gallery (as a cropped copy so as not to modify the original uploaded image) would be lovely as well, if they could be looked into (unless they exist already and I haven't seen them during my demo test with the app).
 
If these were considered, acknowledged and implemented you'd get a sale from me, for sure. 🙂 

Hi @Sonya*
Do you have an ETA for the FXPages update, now that IPB 4.7 has been released?

Appreciate the responses - I've thought about it some more, and while the position you're leaning towards does make sense, I'm hoping that you might reconsider and feel that this may be worth the extra dev effort. I've really come to admire the Promote feature of the IPS software, and I feel its purpose was to offer a one-stop solution for community admins to broadcast interesting content across their connected social media platforms. I figured that this could be a really cool USP for the IPS software that could expand to things like Discord, Instagram, Tumblr etc connectivity too. It'd be a shame if this feature stopped at Twitter and reversed course with Facebook. But, I understand if you have other priorities.
I know there are third party solutions like Zapier that can help make things like this work, but what I love about the IPB software is the potential for its all-in-one built in solutions (it's a reason why I purchased Pages, with the intent to adapt it to a blog that I can migrate my Wordpress over to one day). At least, I hope there is a means for community plug-in developers to build something for Marketplace that can fill the gap and add/fix Facebook to the baked-in Promote service.

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?

There's a bug in the Achievements system that needs addressing.
Steps:
- Go to topic and 'Reward' a user with an incorrect badge and incorrect points (i.e. by mistake)
- Head to the '...' menu against the rewarded post and select 'Remove Rewards'.
- A dialog box shows up confirming that this will remove badges and points
- Check user's profile. Badge still remains and points adjustment still apparent in Admin CP.
- Manual deletion via Admin CP > Member Search > Points and Badges is required to fully remove the rewards.
Removing accidentally-awarded achievements...

Confirmation...

Post-removal of rewards - checking user profile (badge is not removed)...

Admin CP view - points are not removed (requires admin to adjust back via 'Edit User's Points' button)...

Admin CP view - badge has not been removed (requires admin to fully remove using the 'delete' button to the right)...

It seems that all the 'Remove Rewards' function does is uncouple the badge and points awarded to the specific post. It needs to completely remove the badge and points from the user as well. My community's moderation team will be responsible for handing out the majority of manual badge/point rewards, and this bug will add unnecessary additional workload and resources to fully remove accidental badge/point rewards.

There's a bug in the Achievements system that needs addressing.
Steps:
- Go to topic and 'Reward' a user with an incorrect badge and incorrect points (i.e. by mistake)
- Head to the '...' menu against the rewarded post and select 'Remove Rewards'.
- A dialog box shows up confirming that this will remove badges and points
- Check user's profile. Badge still remains and points adjustment still apparent in Admin CP.
- Manual deletion via Admin CP > Member Search > Points and Badges is required to fully remove the rewards.
Removing accidentally-awarded achievements...

Confirmation...

Post-removal of rewards - checking user profile (badge is not removed)...

Admin CP view - points are not removed (requires admin to adjust back via 'Edit User's Points' button)...

Admin CP view - badge has not been removed (requires admin to fully remove using the 'delete' button to the right)...

It seems that all the 'Remove Rewards' function does is uncouple the badge and points awarded to the specific post. It needs to completely remove the badge and points from the user as well. My community's moderation team will be responsible for handing out the majority of manual badge/point rewards, and this bug will add unnecessary additional workload and resources to fully remove accidental badge/point rewards.

Hi @Sonya*
Do you have an ETA for the FXPages update, now that IPB 4.7 has been released?

Hi @Sonya*
Do you have an ETA for the FXPages update, now that IPB 4.7 has been released?

Thank you for bringing this issue to our attention! I can confirm this should be further reviewed and I have logged an internal bug report for our development team to investigate and address as necessary, in a future maintenance release.
 

I would to suggest the ability for badges to be able to be granted more then once, by either updating the last given date or simply allowing them to multiply on the user's profile.
 
 

Many people’s idea of what form a ‘community’ takes has changed significantly from the 2000s (and even 2010s). Invision Community started out as a humble forum software, but I think a good future for the platform would be to evolve towards something more familiar to today’s audience.
I think some progress has been made for sure, with Activity Feeds, Clubs and Status Updates bolting-on some level of ‘social media’ component to the platform. But it still feels like a Forum software that’s wearing a nice pair of Twitter-like shoes. It doesn’t yet feel like an all-in-one social media-like community platform that I feel like IPS is wanting it to be.
That’s not to say I want IPS to completely turn IC into Facebook or something. But there are learnings from ease-of-use, timeline feeds, profile pages etc that can be found from various social platforms that should be adopted (for example, an Invision Community member’s profile page doesn’t look all that fresh and interesting next to a Twitter user’s profile, especially when viewing on mobile where a user has to scroll through an entire sidebar of meta info before reaching any user content 😴 ).
Forums can - and should - still be a core component of the platform, but I think the time is right now to focus on the other apps and build a more holistic community solution - in particular, ***PAGES*** 😄. Re-conceptualising these apps and how they connect and work together to suit a more cohesive ‘social community’ platform is where I think IPS has its best shot of forging a great path for the future.

The following error pops up when I attempt to enable the Facebook Social Media Promotion function. Following the link you'll find that these permissions where deprecated, and if you had an old app it would continue to work until August 2022. No new apps however.
Error Invalid Scopes: manage_pages, publish_pages. This message is only shown to developers. Users of your app will ignore these permissions if present. Please read the documentation for valid permissions at: https://developers.facebook.com/docs/facebook-login/permissions

Someone REALLY likes zips

The actual cause is not that the plugin isn't compatible, it's that the zip file as downloaded from CKEditor is really badly structured.
footnotes_1.1.0_0.zip, contains a folder called footnotes_1.1.0, which then contains another folder called CKEditorFootnotes-1.2.0, which then contains another folder called footnotes, which then contains the actual plugin code.
Do the following:
Drag the 'footnotes' folder out of the zip file Then zip the footnotes folder (just dragged out) into a ZIP fil of its own Upload away!!
 
 

Same issue with this one too.
n1ed-editor_2022.2.0.zip contains "plugins" folder, which then contains "N1ED-editor" which then contains the plugin.js file.
It (the zip file) also contains a theme, and instructions on further configuration, and with that...

 

Thank you for bringing this issue to our attention! I can confirm this should be further reviewed and I have logged an internal bug report for our development team to investigate and address as necessary, in a future maintenance release.
 

This is an option we used to have many versions ago. We could create a block and but have it not start pulling content until some variable number of entries/articles back.  This is useful for building a page of articles from multiple categories, but the newest 4 articles (for example) might get featured at the top in one block and then another block below picks up at article 5 in a different block format. It's also useful if you want to have a block pull 3 articles, place an ad, and then the next block pull the next three article, and so on.
It's a feature I use on Wordpress sites all the time to prevent the same article from being shown twice on the same page in different blocks.
Could we have it back please? 
 

These bugs mentioned in the topic you pasted are solved in 4.7.0 which is currently in Beta. You're welcome to test this if you wish.