bfarber

Yes. I'd finally figured that out. If you picture someone who's just moved into a furnished house and suddenly dealing with a power outage, stumbling around in the dark and knocking things over and slamming their head into unseen walls, you'll have an accurate read on my attempt to wrangle managing this forum. 

It is recommended to output webp files in a <picture> tag instead of an <img> tag, which supports specifying multiple versions. That's something we'd have to take into account.
Also, ios14 added support apparently: https://css-tricks.com/webp-image-support-coming-to-ios-14/
I found that we have an open internal suggestion discussing this already so I've updated it. Thanks!

What things are you looking for support for specifically? Are you just meaning to display webp images as images, instead of attachments?
Obviously this is something we can look into too, but if you have a list of areas/problems specifically it might be a good starting point.
(For the record, recent releases of GD do support webp, as does ImageMagick, so server-side technology is not a hindrance)

Caching changes in an upcoming release mean that when a page is generated for a guest, that page will continue to be served to all guest visits for a period of time. That means a user could cause the page to be generated, and then 100 bots visit the page and see a cached image. Or a bot could cause a page to be generated and 100 regular guest visitors then view the page.
Guest session tracking is not reliable due to caching and performance optimizations, and all bots are treated as guests, so what you are after simply isn't reliably tracked.

You probably need to also clear the datastore folder via FTP to clear caches.

You probably need to also clear the datastore folder via FTP to clear caches.

I would recommend blocking unwanted traffic at the server level. By the time the request makes it to PHP, a lot of unnecessary overhead has already occurred if your intention is to block the traffic. You can already ban by IP address if you wish, and most legitimate spiders will advertise the IP address ranges used by their bots if you wish to do that, but again...this is better served at the server/firewall level.

AdminCP > System > Settings > Email Settings

 
Make sure the "Log Statistics" setting is off and there won't be any "trackers" in emails. Note that any tracking done with the setting on is anonymized (you can't tell who received what email and so on).

That last error is the result of a custom plugin it looks like. You could try renaming /plugins/hooks.php temporarily to see if this allows you access to the AdminCP.

As above, what specific changes would make it easier for you to accomplish your task? For instance, you can monitor the "Unread Content" activity stream to see all new content as it comes in (the stream will auto-update as well to show you new content as it posts), which might be a tool that you have overlooked based on what you've described?

Database tables using COMPACT row format only allow a certain amount of space per row, and many clients were encountering database errors when tables were being adjusted upgrading to 4.5.4. We recommend using DYNAMIC row format which allows for more efficient use of space and has been the default for several MySQL versions now. It is effectively the only way to resolve the errors that some have encountered.

There's some good discussion in here about the behavior of invoice generation so I've moved the topic to the feedback forum.

I would recommend blocking unwanted traffic at the server level. By the time the request makes it to PHP, a lot of unnecessary overhead has already occurred if your intention is to block the traffic. You can already ban by IP address if you wish, and most legitimate spiders will advertise the IP address ranges used by their bots if you wish to do that, but again...this is better served at the server/firewall level.

There's some good discussion in here about the behavior of invoice generation so I've moved the topic to the feedback forum.

Firstly to be clear, are you asking for this in Blog or in Pages?
I ask because you mention Blog, and Blog already has this. Blog itself:

 
Individual blog entry:

Firstly to be clear, are you asking for this in Blog or in Pages?
I ask because you mention Blog, and Blog already has this. Blog itself:

 
Individual blog entry:

No, the only "default" hooks are for our first party applications, which would not populate the plugin column but rather the application column.
That said, the issue could also be caused by an out of date template. You may need to revert the template in question if it is modified.

I've raised your concern internally for further investigation. Thanks!

I would recommend blocking unwanted traffic at the server level. By the time the request makes it to PHP, a lot of unnecessary overhead has already occurred if your intention is to block the traffic. You can already ban by IP address if you wish, and most legitimate spiders will advertise the IP address ranges used by their bots if you wish to do that, but again...this is better served at the server/firewall level.

It is recommended to output webp files in a <picture> tag instead of an <img> tag, which supports specifying multiple versions. That's something we'd have to take into account.
Also, ios14 added support apparently: https://css-tricks.com/webp-image-support-coming-to-ios-14/
I found that we have an open internal suggestion discussing this already so I've updated it. Thanks!

What things are you looking for support for specifically? Are you just meaning to display webp images as images, instead of attachments?
Obviously this is something we can look into too, but if you have a list of areas/problems specifically it might be a good starting point.
(For the record, recent releases of GD do support webp, as does ImageMagick, so server-side technology is not a hindrance)

I would recommend blocking unwanted traffic at the server level. By the time the request makes it to PHP, a lot of unnecessary overhead has already occurred if your intention is to block the traffic. You can already ban by IP address if you wish, and most legitimate spiders will advertise the IP address ranges used by their bots if you wish to do that, but again...this is better served at the server/firewall level.

For the record since this was bumped, this is a current feature (the original topic is 5 years old). This can be enabled in the AdminCP settings for Calendar.