Got another one: the AJAX “API”. That is, having to use admin-ajax.php to communicate.
Most of the time, you dont really know what you’re doing, hope this callback stuff just works, and your requests are at least somewhat XSS-protected … and things get even better, as soon as firewall plugins like WP Cerper or Bad Behaviour chime in - and block IPs based on “suspicious activities”, just because a script is using admin-ajax like its supposed to!
And if you want to use something more efficient, or much more customized, like just simple JSON or AH(A) request and response “actions”, things get so tremendously complicated one usually has to resolve this by building your own implementation of the whole scheme. Which in the end makes the site or plugin you’ve build even more prone to potential security threads, because you’ve now added another layer of complexity, or an additional entry point, just because the whole WP Ajax thingy is so … garbled up and developer-hostile.
I’ve heard this before and don’t understand why a theme needs to have classes, which are great for storing state, but themes don’t need state. Themes are perfect for the thing that PHP is designed for: interjecting dynamic things into static HTML. I think using classes where they are not needed makes the code overly complicated, and themes are just so simple that they don’t need them.
The parent-child theme thing is a great invention and it’s only a hassle when the parent is written needlessly complicated.
I didn’t like it at first, but since themes in the WP repo were required to use it for options, I have come to understand it better. It needs more documentation. I wrote a Trac ticket for streamlining the JS and making it more reusable, but it has been ignored.
I must disagree on this one. Namespaces add more cognitive load to the programmer, and it is quite confusing. I much prefer to leave it out of core. Let plugins use it if they want.
I don’t see this in the codebase at all. It’s not a requirement of the software to be extensible, so whatever extensibility it has is a bonus. The admin UI works pretty well.
This is the same answer as above: it’s not a requirement, nor was the software designed for use standalone, so it does pretty well despite that.
It works well and loads all of core stuff needed. I think it’s a good system, as opposed to having to reinvent the DB access and user authentication and capability checks and the hook system to collaborate with other plugins…
You’re misunderstanding the underlying concept of object oriented programming. OOP (ie, classes) allow you to containerize data along with the functions that apply to and operate on it. This isn’t anything to do with preserving state, so, perhaps you’re basing that argument on something you saw which was poorly implemented to start with.To preserve state, you’d use a session or a cookie, or an option or a transient…not a class. Learn about it.
Also, the current theme system is utterly terrible in its implementation and shouldn’t be looked at as a model for anything other than how not to do it. But, I get it… it’s what we’ve got for now.
Yes, I’m fully aware, and the main thing there is data. The theme doesn’t have data. It’s a straight flow-through, and there shouldn’t be classes to do that. I’ve seen many themes written that way and they are more difficult to follow, more code, more difficult to extend. It’s just the wrong model for a theme. But that’s on the theme author, and not the core codebase. The parent/child part of the code works well when you keep the theme simple, as it should be.
You need to be more specific than “utterly terrible”. I don’t see this in the template system, although it might be better to have a core fallback for front end output (which doesn’t exist now). The code for reading theme headers and populating a class with that data works well.
This is because WordPress taught and perpetuated the techniques from early-PHP when it was a templating language, which it isn’t anymore. I’m not saying they did it wrong for the time in which it was originally created … I’m just saying that it’s dated and could be better implemented with a proper template engine, or at least a modern approach to the code.
We’ll just have to disagree on this. PHP has evolved new features, but it is still a filter language, perfectly suited for what a theme does with no special features needed.
You still haven’t stated what is the “terrible” part of the core codebase, but keep harping on themes, which are not part of core.
I’ve stated it elsewhere and you commented on it there. There’s no need to go into it again. At any rate, I think this exchange has run its course. I’ve got work to do.
