Calendar: Make hierarchical taxonomies non-editable to solve performance and usability problems

[jerclarke]

Following on from #505, this issue is to document the performance problem I discovered while investigating why the calendar post_li_html object cache was needed in the first place.

[Note I make a lot of mistakes in this original ticket, see my reply below. The system does work, but badly and hierarchical taxonomies are the main problem that should be removed from 'editable' status.]

You can follow along with my research in this reply, but the upshot is that there's a whole useless system in the calendar based around the editable flag on the fields from ->get_post_information_fields(), which doesn't seem to offer any functionality at this point, but has the effect of inserting enormous amounts of HTML processing time and page bloat.

Here's how it works in the latest plugin version:

• ->get_post_information_fields() is used to generate the list of fields that will be output in the Calendar's "inner information" for each post. i.e. the stuff that shows when you click the post to show details.
• ->get_post_information_fields() can insert a ['editable'] = true flag on a field. Currently it only does this for taxonomies.
• ->get_inner_information(), which generates the post details HTML, checks this editable field and if it's true, loads a whole alternate version of the field, where it can be clicked to reveal a hidden form to edit the field.
• ->get_inner_information() calls ->get_editable_html() to fetch the form specific to that field.
• ->get_editable_html() has various $types inside it with custom form fields for each type, like text/location/date/user, but ONLY taxonomy and taxonomy hierarchical are actually used by the plugin itself.
• calendar.js has a bunch of code to listen to these editable fields and send AJAX to update based on edits.
• calendar.css has a few styles related to editable fields.

The only built-in "editable field" in Edit Flow is taxonomies and they don't work at all.

The thing about this is that the "editable taxonomy" fields just don't work. You end up with a wp_dropdown_categories pulldown menu to represent categories which both doesn't save anything, and would be disastrous if it did, because of course you are likely to have multiple categories already on the post.

Here's what you see when you click the "editable" list of categories on a post in the Calendar:

Then aside from these taxonomy items, nothing else in core Edit Flow is actually editable! I don't know if at some point in the past there were core fields that were editable, but the fact that none of them currently are tells me that this system is probably not working properly!

What about other plugins adding "Editable fields" that do work?

Now in theory there may be installations where someone has used the filters in ->get_post_information_fields() to add editable fields that use the $type classes from ->get_editable_html() to create editable fields that actually work, but I have my doubts!

I might try setting one up just to see, but honestly I think the maintenance burden of trying to keep all these theoretical field types working correctly is more than this plugin can bear, especially considering that the single field that was part of core EF is completely broken.

Anyone relying on an editable field from this filter will probably be better off using the "Edit" button to reliably update the post in the default editor.

Suggested course of action: Remove "Editable fields"

We should completely remove this concept of "editable fields" from the plugin. This will have an immediate performance benefit that sites with a lot of categories no longer load pointless wp_dropdown_categories() for every single post, and in one fell swoop will eliminate a ton of "bugs" around the other specific $types from ->get_editable_html() which no one has been testing.

Here's what I see as the steps to accomplish the complete removal:

• Remove ->get_editable_html()
• Clean up ->get_post_information_fields() to remove all reference to editable
• Clean up ->get_inner_information() to remove all reference to editable
• Clean up calendar.js and remove all reference to editable
• Clean up calendar.css and remove all reference to editable

Alternate "Just fix the horrific bug" solution: Make taxonomies not editable.

The bare minimum change we need here is to remove taxonomy and taxonomy hierarchical from ->get_editable_html(), since they don't work, and remove the editable=true flag from taxonomies in ->get_post_information_fields().

This would stop the bleeding in terms of performance slowdown, while still enabling theoretical third-party use of other field types that may or may not work if implemented correctly.

I'll attempt to create PRs for both solutions.

[jerclarke]

Ok after some more testing I should have done before, I see that it actual does mostly work, at least with tags (non-hierarchical taxonomy).

Previously I didn't realize that the Save button appears when you are editing an "editable" field in the box (It's visible in the screenshot above, I'll blame the UI for being pretty strange).

So really, I guess it's fine to leave the non-hierarchical taxonomy as editable, maybe someone uses it, and it doesn't add a lot of HTML to the page because it only includes the tags that are actually applied to the post.

That said, the taxonomy hierarchical $type still needs to go, IMO. It may work in theory, but it only lets you save a single category, which means if you have multiple categories on the post and use this select to choose a new one, it will remove all the others without warning you! It also causes the aforementioned performance problems on sites with lots of categories, because it lists them all out on every single post.

I'll submit a PR that only removes taxonomy hierarchical from the list of default editable fields.

[jerclarke]

I'd say this one is all cleared up by the merged PRs as well 🎉