John Jameson

I’d…love to know more. Are they saying they have observed performance issues, or that automated code scans detected dynamic queries?

Editoria11y’s queries should only run for logged in users with authoring privileges — there should be no DB activity at all for anonymous traffic, or even for authenticated users without author privileges.

The author-facing queries are so dynamic there is not much that can be cached. So…I can try to rewrite my queries if hosts are complaining about code style, but in practice I do not expect to see performance issues as written, nor improvements by adding a cache layer that mostly returns cache misses.

That said — v1.0.18 did resolve a bug that was causing performance hits on certain multisites. If they had observed issues, that may now be resolved.

Interesting. Well — since the existing code modifies HTML when it draws a tip, it is set by default to recognize editable components and turn itself off if it detects them, to prevent corrupting any data. That is probably what you are experiencing.

The rewrite is to add a live-edit mode that draws all the highlights outside of the editable component instead and only visually positions the tips over it, so I can keep highlighting while you work. Hopefully that will just work out of the box; if it does not and you are still interested, let’s chat then.

Out of the box the front-end checker will work fine when you view or preview a page while logged in.

I have only tested the back-end, as-you-type checker in Gutenberg/Blocks. I am working on a rewrite that will work with any editor that uses a contenteditable container. I hope to have that ready by fall, but I am afraid I do not have an Avada license to test whether that will include Avada.

Just pushed 1.0.13 — no delete buttons or automatic on-delete events yet, but it will now automatically remove the stale result if it encounters a 404, a different page, or a “Turn off Editoria11y if these elements exist” hit when you click through to the page from the dashboard.

Ohhhh interesting. I see why the ignored pages param is working that way…Editoria11y stops bootstrapping itself when it hits that…which means the “done” event never fires…which means it never syncs anything back to the server to remove existing issues. Works fine on a new install, but leaves garbage behind otherwise.

That would be an easy fix…but some people use the same param in cases where they want to hide the checker for certain users, and don’t want to clear results for the URL. I’ll have to sleep on that. I may just compromise by automatically issuing a delete-all request if both the “I got here from the dashboard” and “ignore-all” are present.

I think I’ll work on the delete button first. It’s the easiest next step, and it at least provides a relief valve for frustration while I chase down the harder things.

For contrib…yeah you’re right about that. In the interim I usually give folks a tour of the codebase first if they want to get started. It’s only mildly organized. But there are some…woefully insufficient…notes in the WP repo and the main library.

Yay! This is my favorite project so that makes me happy.

As for issues — I’ll hear them anywhere, but yeah, GitHub is more likely to stay on my radar long-term if it’s not a quick fix. I do have issue queues there for both the checker library and the WordPress integration/dashboard.

I’m working on an update this week, so I’ll get that typo quick. The other two —

• For ignored pages — are you seeing this for both “Hide alert for me” and “Mark as OK for all users,” or just the former? If it’s just on “Hide” — that’s as designed, since all users see the same dashboard. If it’s both we’ve got a new bug…
• Automatically clearing issues from the dashboard when a post is deleted is a need-to-do I’m aware of. I figured out how to do that in Drupal over the summer; I think I’ll be able to use pre_delete_post to do the same here, but it may be a next-summer project if it turns out to be as complicated as it was for Drupal.

At least for now, I’ve added much more extensive inline documentation with more examples in the latest release.

Holler if you want more.

Well that’s exciting to hear!

Hmm…I…honestly don’t know how to add a filter by published status using only the data I’m currently collecting. I can look into it this summer/fall; I may need to collect a bit more meta info so I can connect my tables more tightly with WordPress’s default tables.

For the latter — what format do you think you would find most helpful? More inline verbiage? A screenshot of a full sample configuration? A tip sheet that goes through a couple scenarios? An intro video?

All done!

v1.0.8 changelog:

• Adds option to restrict viewing reports to site admins.
• Adds CSV export for site reports.

…please do holler if those don’t work as you’d hoped.

Heh; same answer. Will do.

I can definitely add a separate permission for that — it’s one of the features in the Drupal integration I wasn’t going to bother porting unless somebody asked for it. You win the prize!

Might be a week or two.