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.
I think, classicpress can update the way how to create projects with Wordpress including composer.json out of the box. Most of developers use it to manage dependencies.
WordPress hook system is good, but I miss the dependency injection and other software patterns.
For example, RestAPI is super slow because needs to load everything until the endpoint is reached; sometimes this behavior is unnecessary.
I hope to see this project improving the code pattern.
Some users have expressed concerns about ClassicPress’s legacy code, smaller ecosystem, and smaller community. However, many find it reliable and efficient. Ultimately, the best way to determine if ClassicPress is right for you is to try it out.
I’m pleased to say the current version of ClassicPress (v2.2) has significantly less “legacy” (i.e. out of date) code than the current version of WordPress. And v2.3 will have even less.
Our development team may be small, but we seem to be doing something right!
@Mehvish99 ClassicPress can be a good fit for some, and some others like you might prefer something else. ClassicPress is just an option among many CMS that offer site building capabilities to people.
Knowing the options at your disposal is always good, you never know when they could come in handy. That does not mean you are forced to adopt them.
It is very true that ClassicPress made significant progress in reducing the codebase size by cleaning up core code, modernized it and converted many JS libraries to Vanilla JS for better maintainability and improved performance. It is also true that some cool features were added and that some of the things people wanted to be removed have been deprecated (or are in the process of being deprecated). I understand if this is not what you look for. CP is not the only option you can chose from after all.
One thing that I would like to highlight is that even if you do not like the CMS, you should be kind and recognize the value of the (volunteer) work that our core team does. They put in many hours to make it what it is now. It is ok to manifest dislike, it’s not ok to berate and belittle people’s efforts like I feel you are doing here with a grumpy “I do not like it”.
People here are happy the platform is growing and show that by being enthusiast about it and its new features. Or at least they say something along the lines of: it is not the right platform for me, but you did a good job. This shows that at least they do not disrespect the community and it’s ok not to use CP if it’s not the right solution for you.
I am sorry if the above comes out as sharp as a knife, I am not good when trying to convey things involving “emotion” - what I want to say is: be kind to the people who make CP. even if you end up not liking the software and not using it. Thanks.
