Unfortunately any PHP devloper worth their money knows that developing WP sites, even if you follow the WP's standard to the T, is a horrible experience riddled with anti patterns. But, to try to remedy that by duct-taping an entirely different framework on top doesn't, to me at least, make things any better. In fact, it makes it worse - now there's two frameworks to maintain.
Especially if you follow the WP's standard to the T. Wordpress coding "standards" came from one person's idiosyncrasies, going against most other coding standards including (especially) the PSR ones. It's a while since I last looked at contributors' attempts to bring some sanity to it all, but the last I saw was that they kept getting knocked back by the gatekeepers.
look you couldn't pay me any amount of money to work on Wordpress, but not cargo culting PSR like a bunch of others isn't the red flag you make it out to be.
I was dubious when they declared that projects indent method is somehow a barrier to "interoperability".
When they made a logging system based on strings because one existing implementation was written by a guy who apparently doesn't understand syslog levels, I gave up any expectation that they'd produce anything of value.
It's design by committee with the added bullshit of wanting to emulate Java.
PSR has been the single most important advance in the ecosystem. We now have a single, unified code style among all modern projects; a universally supported logging library that virtually all applications use; a universally supported DI container that is implemented by all frameworks; common HTTP request and response types, used or supported by all major frameworks and HTTP clients alike; sadly, two cache standards, albite with a little different targets, but at least most packages support either.
For a concrete example; I can take a PSR request received from the server SAPI, send that to an upstream server via a PSR client retrieved from a PSR container, hand it a PSR cache instance to store the PSR response in, then return that response to the client. This whole chunk of code can be copy-pasted from Laravel to Symfony, and the container will handle injecting the correct local implementation. That doesn’t sound too impressive to a Java developer, but it just wasn’t there in PHP before PSR. Anyone dismissing all that hasn’t really worked on libraries and frameworks before that was a thing.
These packages have made it feasible to create framework-agnostic libraries, easy even, if you’ve got a bit of PHP experience. There’s a reason why the packagist/composer ecosystem is so good, and that’s shared primitives.
If someone just denies all that and bets on their own, badly documented, incompatible solutions just for the sake of it; that absolutely is a red flag, and I’m not going to touch that with a ten foot pole.
> We now have a single, unified code style among all modern projects
Yes I mentioned that, and it's kind of ridiculous how much importance people put on it.
If you can't use another library because they use tabs rather than spaces, that should be a red flag.
> a universally supported logging library
PSRs don't define a logging library. They define a logging interface, and it's based around strings rather than the literal industry standard of SYSLOG levels, because a single implementation that pre-dated the PSR, uses integers but not SYSLOG.
If you think it's a good idea to use a logging library written by someone who doesn't understand syslog, or to use an interface written by people who think it's better to make up shit to accomodate said people who don't understand syslog, be my guest.
But as someone recently said:
> I’m not going to touch that with a ten foot pole
> If you can't use another library because they use tabs rather than spaces, that should be a red flag.
Now that’s just disingenuous. Coding style differences cause issues in collaboration and man-years of bike shedding and have wasted an incredible amount of time in the open source community. Settling on a single standard and be done with it seems very much sensible to me. It’s not about being unable to use a library, but having trouble (or causing it) when contributing.
> PSRs don't define a logging library. They define a logging interface, […]
You’re right of course, although I’m sure you knew exactly what I meant. We’re dealing with a specification that has several implementations, and that doesn’t finish its usefulness at all. I don’t know where your grief around syslog comes from, and I honestly don’t care; Monolog is both flexible and extensible enough to cater to 99% of all use cases or can be adapted to, out of the box. How someone could care that much how the log levels are implemented internally is beyond me; in the meantime, I have built a bunch of applications chugging out logs just fine.
I’ve seen the benefits of PSR firsthand for many years now, but I guess I’m not going to convince you, so I think we can leave it at that.
> Coding style differences cause issues in collaboration and man-years of bike shedding
Solved by each project having its own defined coding style. Every "member" project of PHP-FIG had a defined coding style prior to any PSR telling them how to write code.
There is zero need for this to be enforced across projects.
> I don’t know where your grief around syslog comes from, and I honestly don’t care
You're gesticulating about how important it is to follow "standards", but the moment someone points out how PHP-FIG ignored an established standard that's already used in dozens of languages - including in PHP, it's "I don't care".
You're more concerned with defending your cargo-cult allegiance to a group than understanding criticisms of their work.
Wordpress still didn't have an official style guide or components when I was developing in it which always irked me. Every plugin looked different and most times you would get jQuery conflicts if 2 plugins needed different versions. Also people not using namespaces and just throwing functions within the global namespace was a nightmare to debug. Don't get me wrong, WordPress has always been great at getting something up quick, but if you're going to be creating an app where you need a separate framework, I don't see why you would pickaxe into WordPress itself. Just create a separate app in your favorite framework of choice and use their API to interface with it. Their API is actually really good and easy to work with.
The question I've always had is: why hasn't anyone developed something with all the good things of Wordpress, but none of the bad ones. The good things mainly being:
- extensibility and flexibility.
- smooth learning curve at the beggining (when developing custom themes from scratch, compared to, for example, a "real" backend framework).
I’m sure dozens of excellent replacements have been created, but WP is just so huge.
It doesn’t matter how messy it is, you’re not going to convince the marketing agency with 10 Wordpress devs to learn something else.
It’s probably also relevant that WP is so weird and different from other frameworks. A lot of people who make websites with WP don’t seem to know the first thing about web dev outside of the WP ecosystem. I’m not hating on them, but you can use WP in ways that don’t give you skills to use other tech.
Yeah, you can get a WP site up and running with all the functionality you need to support different types of businesses and business ideas cheap on fiverr. Validate and move on.
Keep in mind that WordPress is over 20 years old at this point - the problem it was built to solve just isn't the same anymore.
Most of the use cases nowadays are covered by even easier products (social media, Medium, Linktree, Wix, Squarespace, Shopify, Webflowly, ...)
So you'd consider WordPress for anything that requires something more advanced like login, storing user data, complex state, fully custom design, ... (or out of habit/experience of course). That seems to be within the possibilities for low-code/no-code tools - they aren't quite there yet in my opinion, but in a couple years they might be.
The extensibility, flexibility, and smooth learning curve for non-techies comes at a significant cost.
WordPress was designed to be extensible and flexible without requiring the user to edit source files or run commands in a shell. After all, both of these tasks are serious hurdles for non-techies just starting a blog. The user gets a cheap hosting account with a domain and WordPress pre-installed, and doesn't want to care about what's happening on the server side.
This precludes the use of composer, npm, or any other command-line tool in vogue, for installing and managing plugins, themes, and associated libraries. Plugin and theme developers, of course, can use a package manager to bring in their own libraries if they want. But this is not centrally managed by WordPress, so you often end up with incompatible versions and duplicate functionality.
This is also the reason why no program whose tutorial starts by running a shell command -- git, brew, composer, you name it -- is ever going to replace WordPress.
I am horrified by this notion. There's no reason to not just build a CMS on Laravel if you actually have PHP developers on hand, even if you have one competent PHP dev on hand you they should be able to build a CMS on Laravel without issue. This whole concept doesn't make sense to me.
Frankstein-ing frameworks like this is asking for trouble. This smells like something that was made by devs because they hated working on WP, not understanding that the reason why WP is picked if often due to political reasons, not technical ones.
I predict two forces will turn these kinds of projects into spaghetti: Actual devs working on resolving issues with code, less technical people fighting to use plugins and other add-ons to add functionality.
> This smells like something that was made by devs because they hated working on WP, not understanding that the reason why WP is picked if often due to political reasons, not technical ones.
Made by the roots.io team, who have been doing this since 2011:
> This smells like something that was made by devs because they hated working on WP, not understanding that the reason why WP is picked if often due to political reasons, not technical ones
But that’s the point? When WP is picked for political reasons, this is how you can make it nice on the technical side.
I work on a website for a non-profit. We have a hybrid wordpress symfony site. We're always being pulled two ways, we like that we switched to wordpress for the more static parts of the site (CMS). We have some minor custom functionality thats being handled by symfony, that should righly be a wordpress plug in....
This might be the thing. Especially if you can use it for plug-ins.
> Corcel is a collection of PHP classes built on top of Eloquent ORM (from Laravel framework), that provides a fluent interface to connect and get data directly from a WordPress database.
You'd just be switching one framework for another really. Either make it framework agnostic or make it use the framework you're already using (wordpress)... anything else is unnecessary overhead
I was trying to get it set up so I could use twig templates inside pages. I couldn't get it to work since both frameworks ( Wordpress & Symfony) want to be in charge. Any secrets you can impart?
Having used acorn (via roots sage) on a project recently I'd say on balance it does improve working with Wordpress. I wouldn't describe it as a nice experience though.
Acorn was - and is - the then famous Acorn Computers. Makers of the BBC computer and eventually the inventor of the ARM processor (first used in the Archimedes range of computers).
