bfarber

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

Yeah, I'm not clear what you are suggesting or indicating is a problem.

The URL structure for some areas has changed, but old URLs will 301 redirect to the new location.

There are no permissions for blog categories (at least at this time). They are for organizational purposes only.

What do you mean "topic pages that have been reviewed"? Topics don't support the reviews functionality, or do you mean rated?

Review data used to be valid for Article object types in structured data, but Google has since changed their mind and no longer allows you to include review data for articles. We are looking into this.

It's been a long time since that was implemented and my memory can only hold so much. As I recall, the reasoning was that most server software (i.e. Apache) can handle dynamically gzipping content, but when you store a static asset on S3 it is served as-is, so we had to do it manually ourselves.

The menu in our guides was custom coded for our site here.

The field has always been labeled "Title" to answer your question.

There isn't anything further to report on the suggestion at this time, no. Presently when the password is cleared out that's it, we have no record of what the previous password value was. We can take your suggestion into consideration for a future release.

4. This is a per-group setting already:

Typically, laws like GDPR give you some grounds to not remove a user's data if you have a certain business relationship and have bookkeeping requirements just FYI. Check with legal experts in your area if you are unsure about the best way to handle that. As for the suggestion itself, it makes sense I suppose and will raise internally.

We already inspect js controllers and strip out any that aren't explicitly allowed. "id" can't be allowed, as it can lead to issues as already noted. It can break javascript on the page, cause other oddities, or even potentially introduce security issues (what if a user pasted an HTML markup that looked like the login form with the id of the login form element on the page, but which sent the credentials to a remote third party? A user could click to login, which would load the nefarious (but normal looking) login form HTML, and submit their credentials to a remote endpoint. In theory at least...I do believe we strip forms out already, but you get the idea. I don't really have any qualms about "name" but as noted, it's kind of deprecated so it seems a bit meh to allow. The reality is, this type of thing is so seldom needed that it is probably best to just leave to a custom plugin. If we start seeing a lot of clients installing custom CKEditor plugins that need this functionality we can revisit.

If you use S3, we do actually pre-compress assets already...

It wouldn't be hard to extend it to code blocks, but it should be noted that clients have requested doing this for quotes quite a bit, but I can't recall seeing any suggestions requesting we add this to code blocks. This is why we strongly encourage clients to post in our feedback area so we can gauge which features our community are most interested in. (We take in input from other sources as well, just to be clear)