bfarber

DiscussionForumPosting documentation on schema.org (look at the json+ld tab): https://schema.org/DiscussionForumPosting Introduction to structured data from Google: https://developers.google.com/search/docs/guides/intro-structured-data Can you explain why you believe the URL needs to be changed?

Please submit a ticket if you are experiencing issues.

The downloads manager stores the files in the database (even before they're saved) and then will delete any files not saved after 1 day via the task named tempFileCleanup. As I said, if this isn't working on your site, please submit a ticket and a support agent will be happy to take a look. :)

If we implement this change, then yes we would need to review our uses of the original image and potentially adapt some areas.

I think this is a workable solution to the concerns raised, personally. Even if you didn't use Amazon, you could plug up another cheap HDD on the server and push the "original" images there (as a cold-storage type setup). (FWIW, we don't save originals of attachments - only the "maximum size to save" and a thumbnail, based on your ACP settings. Thus this concern is mostly isolated to Gallery which necessitates a more balanced approach when it comes to image quality and retention)

While the RSS specification does support an <author> element, it must be the author's email address which is not data that should be publicly exposed in the case of an RSS feed of user-generated content. https://validator.w3.org/feed/docs/rss2.html The only way to do this would be to define a custom namespace for the author name which no RSS reader would really know to look for, so it would be relatively pointless except in very specialized cases (where a custom plugin would make more sense).

Keep in mind we cater to many different audiences, and not all of them are technically inclined. 😉 The idea was raised and discussed, so don't take my responses as "no this isn't happening". I'm simply trying to explain why things work the way they do presently.

Have you ever heard of a "copy of a copy"? If you take an original image and manipulate it to downsize it, storing that copy at ~80% quality, it'll be ok to view. But then if you take that image and downsize it, and store the new copy at 80% quality, you start seriously losing image quality fast.

I think the term you're looking for is a "threaded" view. I'm afraid this is a fairly antiquated concept and while we supported it many, many versions ago, it is not a capability in the current release of Invision Community.

Yes, they should be. You shouldn't need to manually look for and remove orphaned attachments. You may wish to submit a ticket so we can investigate.

You could store Gallery images on S3 - the originals are rarely ever requested so bandwidth would be minimal and general storage costs with S3 aren't much, plus you'd benefit by having the regularly accessed images served by a CDN. Unfortunately, deleting the originals entirely isn't really feasible. For instance, Gallery 4.3 used new sizes for most images which meant the images had to be rebuilt, which isn't really possible without the original.

Can you clarify what specifically about the layout you are after?

You can find third party developers in our Providers directory https://invisioncommunity.com/third-party/providers/

Frankly, this is how every calendar app works. The event color is a function of the calendar the event is (currently) stored in.

1) Clubs can contain one or more features, so for instance a club could have 5 forums in them (and 2 galleries and 1 blog, etc.). 2) The plugin I linked you to is developed by a third party so I can't really say much for or about it, but it appears to provide the functionality you are after.