Princess Celestia

My ACP says ~17 hours ago but my site's Invision license is attached to a different account so the download would have come through that one. If you want, I can message you the other account's name so you can cross-verify it against your download log.

As the person who wanted this, thank you very much for adding it! ❤️ I had my bug report all written up and ready to submit when I saw your new post come in saying you already fixed it, haha. Thanks for being so on the ball with this (free!) app!

I found it and I love it!! 😄 Thank you so much! I found a minor bug with the new setting but will go post it in your support thread where it belongs.

When trying to view a certain forum on my community in "expanded view", the result is an empty white page with an HTTP 500 response code. It generates errors like this one in my webserver's log which indicate that Invision Community is running out of memory: FastCGI sent in stderr: "PHP message: PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /[redacted]/system/Db/Select.php on line 503" while reading response header from upstream, client: [redacted], server: [redacted], request: "GET [redacted] HTTP/1.0", upstream: [redacted], host: "[redacted], referrer: [redacted] My server's PHP memory limit is set to 128 MB, the value recommended by the requirements checker. I already ruled out third-party mods because I can reproduce it with all non-IPS applications and plugins disabled. The issue still occurs after raising the memory limit to 256 MB but goes away after raising it to 512 MB, which seems excessive. For now, I set the limit back down to 128 MB. I left the problematic forum section's URL in my ACP's "admin notes" widget for IPS support to take a look.

Asking for a "full name" is redundant in our case because the only name we need is a user's display name - and we already automatically get that through Pages knowing who created a given record. 🙂 That's a clever workaround! It feels very wrong to maintain a field with meaningless garbage data like that but it'll probably tide us over. Will have to see how <title> tags and such play out with this approach. Thanks for the idea!

I went to change the storage method for my site's "Theme Resources" today but the procedure appears to have gotten stuck. Here's what I did: Configured a new storage method. Changed "Theme Resources" to the new method, set the "Move files automatically" option to yes, then saved the changes. Saw two background tasks appear on the ACP dashboard: one for moving theme resources, one for deleting them at the source. Used the "manually run background tasks" option in the ACP to make this finish quickly. At the end of this, I now see: The ACP shows no active background tasks. Most of my site's CSS and JS files are still loading from the old storage method's domain. None of these files were moved to the new storage method (but some image files were). The "Theme Resources" storage method setting is now stuck and unchangeable with the message shown in this screenshot: There's no indication that any further moving-of-files is happening or will happen (files stopped being added to the new storage method). It's been stuck in this state for over 20 minutes now. Did I hit a bug?

Pages databases currently require a field to be designated as the "title" field. We're looking to use Pages as a custom form tool to accept staff applications and in that context, making the submitter come up with a title for their submission is really weird and none of the other fields are appropriate for use as a title either. So any officially supported solution that lets us avoid exposing a "title" field to the submitter would be fantastic for enabling use cases like this. Adding support for any one of the following would do the trick: Automatically generate the contents of the title field based on other information like the submission date and submitter's display name (ideally configurable but even a nonconfigurable automatic title would work). Designate the record's author as the title "field". Designate the record's creation date as the title "field". Allow a Pages database to exist with no concept of a "title" field at all (I understand this may be unrealistic from a technical design standpoint but hey, one can dream 🙂 ). I'm sure we can hack our way around this by creating a hidden form field in a custom record creation template but considering this seems like an obvious use case for Pages, it might make sense to support it in the core product (titles also aren't obviously relevant to the "testimonials" use case that Pages is currently advertised for either). This will help position Pages as a well-integrated alternative for your customers to tools like Typeform, Microsoft Forms, Google Forms, Wufoo, and the like. There are at least two past topics here from other customers trying to achieve something similar:

From time to time, I find what looks like corrupted tag entries in this app's ACP area that don't correctly link back to the content item they're on. Example - in this screenshot, everything that's redacted appears correctly but three entries don't link back to their respective content item: The "Remove duplicate tags" and "Clear broken/empty tags" tools don't fix these so I suspect my site is hitting a weird edge case. Do you recognize the issue and have a fix for it? Unrelated, this app is pretty awesome already but I'd like to request a few features that I find myself wishing for: Tag implications: a tag may imply one or more other tags. When a tag with implications is added, all the tags it implies are automatically added as well. Automatically apply aliases retroactively: after creating an alias, it would be super nice if it was automatically applied to all existing instances of the newly aliased tag(s). Merging aliased tags manually is a bit tedious and error-prone right now. Improve support for "going back" to search results to make mass-updating tags easier. Two specific changes here would fix what feels like UX bugs right now: Eliminate the CSRF error that shows after searching for tags in the ACP, viewing a specific tag, then using the browser's back button. Expected result: return to the search results the admin was just looking at. When the admin reaches a "tag view" from a tag search, make the "Go back to tag listings" button when viewing a tag go back to the same search results they were just looking at (instead of "resetting" the search). An option to make a saved action remove specific tags, complementing the option to make a saved action add tags.

This looks like a great mod but it's not useful to me because it only adds pay-what-you-want to Downloads files (and my site doesn't even use the Downloads app). I'm hoping to add pay-what-you-want options to the subscriptions that Commerce itself sells.

It would be super useful for Commerce to support pay-what-you-want pricing. I mainly have subscriptions in mind but it would be nice for one-off purchases, too - think of it as letting customers leave a tip. My community always tried to have this by offering multiple subscription tiers which, for the most part, only differ in price. But offering a single subscription with a pay-what-you-want option would be a much better UX than offering a large list of very similar-looking options. Bandcamp (for selling one-time purchases), Patreon (subscriptions), SubscribeStar (also subscriptions), and other services did a lot to popularize pay-what-you-want in recent years so I recommend checking out their UI flows for inspiration. Here are some ideas for how it could work in Commerce: Anywhere Commerce allows one to set a price, there is an option to enable pay-what-you-want pricing. When pay-what-you-want is enabled, the "normal" price becomes a "suggested" price and a lower minimum can optionally be set. When managing a pay-what-you-want subscription, a user can modify their "pledge" at any time. An admin can choose whether this bills them for the difference immediately or takes effect in the next billing cycle, similar to the existing subscription upgrade/downgrade settings. When a user "pledges" an amount for a subscription that would bring them to a higher-priced tier, it'll automatically upgrade them to said tier upon payment and communicate this unless: the higher tier limits how many people can have it and said limit is reached, or the user deliberately chooses to stay on the lower tier anyway. Other ideas are welcome, too. 🙂

Darn, that's a shame. Still, thank you! I look forward to having your new setting in the Box of Tricks app.

@Matt: The deprecation tracker currently says: If converting plugins to applications now in preparation for v5 is a waste of time as you say, you may wish to clarify the guidance on the deprecation tracker, which makes it sound worth going out of one's way to do ASAP. 🙂

I know they'll be getting removed but v4 will still be supported until at least 2025 or 2026, which should mean bugfixes to existing functionality can still be expected until v4 support actually ends. And at this time, IPS still prominently promote it as a feature of their suite, which suggests they still intend to stand behind it at this time. Status updates are an integral part of my community and I don't see us moving to v5 without them. I intend to license or build an add-on that restores them once v5 is out so I have an interest in the feature working well until then.

Bumping this in the hope of bringing attention to this issue with 4.7.10 coming up. The most annoying way in which it manifests on my community is as in the quoted post: Our members and staff alike have been complaining about this for years and it hurts their perception of IPS and of our website. It's one more thing we have to explain to new users all the time, too ("yes, your status comment went through even though it looks frozen"), which hurts first impressions and creates unneeded anxiety about losing the comment they just spent the time writing. Several approaches to fixing this have already been identified in this thread's OP. If you knock this out with your next release, it'll help all members of your customers' sites who use status updates.

This is fantastic! Thanks for making it. It works! The one thing that would make this plugin even better is if it enabled an admin to blanket-allow all extensions in the Media Manager, similar to what's possible with attachments in the core software. We trust our admins with this power. 🙂