bfarber

It's not a bad suggestion (I can't say if there are "plans" for anything right now), I just wanted to clarify how it does work for now in case anyone else was wondering.

There are only a limited and defined number of valid values. What key is this service asking you to add to the manifest file? At present, you would need to create a plugin to use a hook on the method that generates the manifest file to accomplish what you are after (the manifest is not defined in the theme system), but I'm curious what you are wanting to add exactly so we can better understand what you are after.

At present, mentions will only send a notification if directly used as part of a content item or comment, not in associated meta data or areas that are not content items (e.g. if you add a mention in a forum description, the member will not get a notification there either).

I understand, and explicitly said I wasn't getting into the rest of the suggestion right now. I was only responding to this bit, because it is not a highly publicized or obvious feature, but is one that is present already for those who want to use it:

Without getting into the rest of the suggestion yet, I did want to point out related to #2 that we do already support read/write separation.

Yes, however the manifest file is fetched separately (indeed, with Chrome in my tests, it doesn't even use your normal session - it's fetched separately as if a guest fetched the file). That is to say, it is not reloaded on every page load and thus isn't going to inherit your current theme's color regardless. You would actually need to go into your device options and clear your site data for your site in order to force your phone to refetch the file (or wait for whenever it decides to periodically check for updates). The "theme color" option in a manifest file just doesn't work in the manner you're thinking I'm afraid.

That would be a wholly unrelated issue, and I would encourage you to submit a ticket if you can reproduce this. We simply stopped querying to figure out what the topic title's name is in this particular area, which would not impact whether the system believes there are unread items or not.

The intention of the feature is that the posts are not visible anywhere until the user registers. As a new feature, there were a few areas (the sidebar blocks you can add for displaying things like "latest posts" being one notable area) that were overlooked and the posts display there - this is corrected in our next maintenance release. In short, absent a bug (and all known bugs are already fixed and staged for release) they are not intended to display anywhere. Just wanted to add that clarification as there's been some confusion.

Hm, I haven't tested, but have you tried doing something like "More than __9999__ days ago"? Unless your forum is actually that old, it seems like this would cover your use case?

This is a feedback forum - the suggestion has been received and reviewed, but I'm afraid we can't generally respond as to if and when any single suggestion may be included in the software (or not).

The editor toolbar is responsive so shrinking and expanding your window will show different toolbars anyways - so to that end it's not super straightforward. But you could use CSS to do this with :nth-child pseudo selectors. Post in the theme help forum for tips if you're not aware how to do such a thing.

The theme color is used in the manifest file, which is a single file that is theme-independent. Subsequently, you can only set one color for your "theme color" I'm afraid (and it's worth noting this color isn't really used anywhere within the suite, it's something user agents can make use of when supporting PWAs).

As a general rule, you can't have options for things that can be potentially destructive to large communities. Big communities will then just turn the setting on, and we'll have to still support it and make sure it works well.

Once upon a time, many many moons ago, before we had any sort of eCommerce platform offering, we supported very basic subscriptions without purchasing a separate application. When we developed a full-fledged eCommerce solution, naturally this functionality was pulled in under its umbrella for many reasons. This is extremely unlikely to be changed at any time in the near future I'm afraid. If you wish to sell products or subscriptions, you will need to purchase Commerce (or develop your own custom solution/use a solution developed by someone else in the marketplace). We are not likely to pull subscriptions out of Commerce and put this into the core.

There's a lot of discussion here so I'm having trouble following, but my understanding is that this is the crux of the suggestion. If so, I see no point. As you, yourself, point out - it translates identically in English, so why add extra overhead and processing unnecessarily (and frankly, a majority of our clients speak English so that overhead adds up collectively). It sounds like you simply weren't aware that you could separate the behavior by adjusting the string, and to that end the appropriate solution seems to be better education as to how the language system works. Is that a fair understanding, that you basically weren't aware you could adjust the strings as you ultimately did? Perhaps to that end, we could include some more tips on the translation page in the AdminCP how to work with these "pluralized" strings?