Going to the customizer is the real issue. It seems something is off because many settings are blank (this could be just a difference between free and pro version in case it has a pro version) but seems fishy.
I am not getting JS errors or errors of any sorts after amending the code in functions.php like explained above.
Is that what are you referring to when you explain something is happening with Customizer?
@timkaye what are your thoughts on the matter? where can we look to find what is going on? (aside from the fact the theme is coded with separation of concerns in mind and this could make it easy to spot what file is responsible for the wrong behavior IMHO since functions.php only lists all the required files with proper commenting to indicate their use)
Guess there is INDEED need for a compatiblity plugin, CONTRARY to whatever others say.
Query Monitor breaking is a big deal, as there is almost no other good alternative for development.
Forking all and everything is not the best option, because keeping everything up-to-date AND backporting would eventually turn into a massive and insane struggle.
How would this plug work?
Isnât the only real test to try the theme or plugin and see if it works properly?
I had some thought that a plugin to add back anything that was removed would have some usefulness, but where do you draw the line on that?
Maybe the route of a modified âthumbs upâ or voting thing would work, where users could indicate they have the add-on working - not sure how to implement that though, since compatibility might change over time.
To some extent it would seem that providing case basis community support may actually be the best method to handle things, and maybe the notice could say something more along those lines?
Iâve already built one for myself. It just adds backported functions, partial functions, but mostly dummy function wrappers, ie. that just exist so a check for function_exists like the one in Query Monitor does not fail. Same goes for classes.
Obviously this only works for functions and classes that either dont exist in CP, other plugins (eg. WooCommerce) or are treated as drop-ins (see eg. WP Engineer: WordPress Dropins).
For a more systematic, orderly, âcorrectâ approach to this - its basically the same, a plugin published eg. on Github, and then use the respective issue tracking system to register eg. a plugin that does fail with a Fatal Error or only partially work.
One could extend this with must-use plugins, and potentially also drop-ins, albeit the latter ones might clash with others, eg. caching or database-centric ones (including Query Monitor).
I am certainly not saying this is a bad idea in general terms.
I do think it may be something that people need to do themselves just as you have though, mainly because I think it would probably also be a project that could take up a lot of time and effort to cover every add-on or situation.
A community effort using github is a valid approach perhaps, but in some ways isnât the longer term goal is to move away from patching CP to be WP?
Sure, thats the eventual goal. But a separate plugin would be a good intermediate step towards this - else weâre indeed stuck to âjust patching CPâ, or doing nothing at all, which doesnt improve making the platform attractive for potential âswitchersâ.
As mentioned before, this is also not viable for more deeper-going things, eg. if WP decided to introduce breaking changes to essential parts of the system, but for now, this base-level approach should do.
It is almost a catch 22.
Making it easy to switch is important, but you could also end up married to that plugin âforeverâ (if provided as a CP entity).
@fwolf forking and backporting and such is a struggle. Also trying countless themes that seemingly can have the features one does need only to find that at a deeper inspection/test they break the site.
In some cases there is a simple solution for themes, just amend what is not working. Some other times even doing this the theme itself is off.
I have discovered it is easier to take a âretiredâ theme from the BGB (Before Gutenberg Era) that does work even if it is not compatible with latest PHP standards and latest coding standards and correct its files, then go the long road of changing its name entirely and considering it a NEW theme and not a simple fork, But this takes time, effort and knowledge not everybody is willing/able to put in.
I do not agree on a compatibility plugin, because it just means you put in CP what was purposefully taken out (blocks/FSE and all that jazz) just for the sake of plugins and themes from WP working for us.
I am more inclined to ask developers to develop for CP or just taking old versions of plugins and themes and making them into their own CP plugins and themes without having to rely on a compatibility fix that might not work for everyone since itâs not one size fits all.
A polyfill was added to restore Query Monitor functionality.
But not always adding âdumbâ functions work, and sometime that would break other thing.
I think that if someone is interested can build a plugin with React and all the stuff that was removed from CP. But if I will need such things⌠for sure I will use WP.