bfarber

Yes, what I'm saying though is we serve the identical code regardless of the user-agent, and Google is indexing the page but then displaying it differently depending on how you access their site. In other words, this is entirely a decision that Google has made, and not something we're explicitly doing. If you look at our json-ld code on this page for instance, there is not even any mention of "topic" or anything like that.

Disclaimer: I do play a crossword puzzle game that is semi-social (like, it shows your Facebook profile image to friends and stuff) on my iPhone when I want to kill time. I prefer puzzle-type games when I'm bored over traditional games (I don't have enough time to really get into a game and can only time block for like 5 minutes or so at a time lol).

I've verified the JSON-LD we are outputting is correct. I suspect Google is just taking limited screen real estate into account when displaying results on mobile, and as it knows the page is a "DiscussionForumPosting" type it is showing "topic" instead of the topic title, which could potentially be quite long. We will look into it a bit, but on the surface I've verified we are outputting the correct markup.

I assume you are referring to the guy on the left - no, it's not me. I've never actually played Candy Crush (I don't have time to play many games as I have 6 kids who keep me pretty busy, and I live at a beach).

Gotcha - I've looked closer and I see where that inconsistent behavior is stemming from and have corrected that as well.

"Number of items" set to 0 was not being respected properly for content item classes (of which status updates are one). This has been resolved for the next release, as I said.

The setting means "do not include the priority element in the sitemap". Random example: https://invisioncommunity.com/sitemap.php?file=22_sitemap_database_categories Thus, what you are describing for each type #2 makes no sense - the sitemap task should still run and generate the sitemaps, just without the priority element being included in the XML file. The issues outlined for Gallery #3 and Pages #3 I've resolved for the next maintenance release (some areas weren't honoring "include 0 items" properly), while profiles was already behaving correctly in this regard.

I've taken a closer look at this and am a little confused. You said a work around for profiles was to set "number to include to 0" in addition to excluding profiles from sitemaps - but that is the only way to exclude profiles from sitemaps. Are you referring to the following when you indicate you've excluded profiles from sitemaps? If so, then that checkbox only results in the priority (for profiles) being excluded from the sitemap, not profiles as a whole. It appears that if you set number of profiles to include to 0, this works correctly. I'm looking in to your other reported issues still, but wanted to get some clarification on this bit too.

I do have a few comments... It's worth pointing out that the majority of our clients do not have 20 years of (undeleted) messenger conversations and conversations with dozens of users and dozens of pages. You use the messenger quite heavily compared to the average client. Some features will not likely be feasible or introduced in messenger - for instance, reactions are kind of a measure of social relevance on a community, and so it doesn't make sense to support them within a walled off area like the messenger. Two users could literally just send each other PMs back and forth and "like" those messages to build up their reputation scores, with no oversight or even a way to see what they did that was being repped. Some behavior is modeled (lightly) against other similar online systems, like Facebook's messenger (where you don't have pagination but rather infinite scrolling, and as I recall they don't even really support any level of filtering or searching. But setting those comments aside, I do see some ideas there that are actionable and will raise them internally for further consideration.

Besides searching for conversations by participant, what other shortcomings are you referring to?

I've logged a bug report to have this looked into. Thanks for raising the concern!

I don't think that's what the page is suggesting. I think it's merely pointing out the developer resources available to you simply by signing in with your Apple ID. Based on the documentation I've seen so far, it appears you will indeed need to be a part of their developer program (i.e. pay $99 per year) in order to use the "Sign in with Apple" feature they are releasing.

The majority of reports we get were along the lines of "I can't click the Quote/Edit/Options links below this post". We'd investigate and find that Grammarly had inserted a large div into the post which was basically sitting on top of those links, making them unclickable. The issue mostly manifested when editing posts which had quotes in them, but this was not a sole factor. In any event, as we have no control over Grammarly's behavior or CKEditor's behavior in this context, the best we could do to prevent issues for our clients was to prevent Grammarly from inspecting the post content. You can still of course use their standalone app to write up posts, and then copy/paste those posts into the editor afterwards.

I'll do it for $19,000. Just saying.

Grammarly and CKEditor do not play well, and we received several bug reports about the same issue(s) related to how Grammarly modifies the DOM within an editor. In short = yes, there was an issue (or a couple of very related issues), and there was no way for us to resolve this outside of disabling Grammarly in the editor. It may return when we reach a point where we can upgrade to CKEditor 5. It is my understanding that the CKEditor devs and the Grammarly devs are working together on maximum compatibility, but won't be backporting that to CKEditor 4.

It can happen at different times. Sometimes Invision Community explicitly cleans up its caches itself, sometimes caches are stored with an expiration timestamp and Redis will automatically purge them, and sometimes Redis simply purges older caches that haven't been used in a while. There are various Redis configuration options to control this sort of thing so I can't give you a blanket answer.

Yes, Redis removes the data no longer in use.

@Alismora that option is present to prevent administrators from editing administrator accounts (i.e. demoting the main site administrator to a regular member). @Sp4x from a moderation perspective on the front end, we generally don't consider "administrators" to be anything special. The moderators can only edit generic profile information, i.e. they cannot demote the administrator to a different group or change their email address. This is not unintended and the harm the moderator can do is essentially limited to adjusting your custom profile fields and changing your birthday, which really isn't a concern (nor a security issue). Similarly, moderators can delete administrator topics or posts if you give them moderator permission to delete topics or posts.

The update banner can only be hidden for a short period of time, not completely dismissed. This is by design I'm afraid.

What you are describing is different from what is being discussed in this topic. I am unaware of any issues sending email notifications that would explain a sudden jump in sending emails upon upgrading, but if you believe there's an issue I would encourage you to submit a ticket in your client area for official support.

We could look into supporting wildcards, but I wouldn't make this automatic. You might want to allow "somesite.blogspot.com" but not "othersite.blogspot.com" for instance.

I have one of these (or rather my daughter does).

I've ensured a bug report was filed

That error typically happens when a rather large animated gif is uploaded, using ImageMagick, and ImageMagick (or the PHP process it was launched from) hits a time or memory limit. It can take a lot of resources to manipulate larger animated gifs in some cases.

Out of curiosity, are you using GD or ImageMagick on your site, as we'd really only be able to do this for ImageMagick.