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?

From a programmatic standpoint we don't really know if a modified template is "compatible" or not. We simply know it has been changed in the current release, and we can't automatically apply those changes. So, going back to what opentype asked - what would you suggest in terms of wording? I can understand your predicament here and am open to suggestions.

We (temporarily) disabled the ability to set up PayPal if you hadn't already done so when you upgraded to 4.4.x. If you are already using PayPal you will not be impacted by this whatsoever. That said, we have actually reintroduced new PayPal setups in 4.4.1, so even if you hadn't already set up PayPal, you still wouldn't be impacted. 🙂 In short, this is not a concern. https://invisioncommunity.com/release-notes/

At least at one point, Google did not allow the sitemap URL to be submitted more than once. That said, if you've added your sitemap in Webmaster Tools it's irrelevant anyways. Google will crawl it as often as it feels it should, and will prioritize this over the URL being "pinged". In short, I don't really think this makes any difference in the end. The lastMod property in the sitemap files is more heavily relied on to find new content, along with Google's algorithms as to how often your site/sitemap should be crawled based on its size, activity and popularity.

There were some issues with the Elasticsearch server yesterday.

The difference here is basically site-generated content vs user-generated content. With site-generated content (i.e. articles you post, such as you would with Wordpress) you can absolutely consider the representation of the content, ensure you include a relevant image that doesn't violate any copyrights and so on. With user-generated content....this is much more challenging. Most users don't even upload images at all if they don't have a reason to (take this topic as an example 😛 ). So, to that end, when the admin is at the helm (such as the case with the "Promote" tool that I mentioned) we give you more tools to control the experience. When you are working with user-generated content, sometimes you are bound by the limits of what a user is willing and able to do.

We never get fed up 🙂 And if you ever have questions about how the software works, you are always welcome to submit a ticket and one of our technicians will be happy to explain it. Just wanted to put that out there in case you or anyone else was unsure.

Redis doesn't really have separate "databases" as it's not actually a database server. We do segregate caches we store in Redis based on a key unique to the site, and the stats in the AdminCP only reflect the data for that site. Memory available/used is going to be whatever Redis reports directly, but things like "topic views" are only for the site in question.

We wouldn't integrate a new javascript framework without reason (it simply being easy or friendly to work with is not really a reason to add it) - what would you like to see leveraged from vue.js specifically? Why should it be integrated?

I think our first question would inevitably be "how are there RSVP records in the database table for events that don't exist". That situation should not happen, and is probably the first issue we'd look to resolve. Either way, I would encourage you to submit a ticket for support so we can take a look at your site to see if this can be determined.

Thanks, I've logged a bug report to have this checked into.