Acorn – Use Laravel Inside WordPress
roots.io
roots.io
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.
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.
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
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.
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.
- extensibility and flexibility.
- smooth learning curve at the beggining (when developing custom themes from scratch, compared to, for example, a "real" backend framework).
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.
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.
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.
Is not. Is not open source. Is cost more just for having drafts.
Looks nice though.
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.
Made by the roots.io team, who have been doing this since 2011:
Other projects in this space include:
Great projects!
It’s great.
But that’s the point? When WP is picked for political reasons, this is how you can make it nice on the technical side.
This might be the thing. Especially if you can use it for plug-ins.
https://github.com/corcel/corcel
> 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.
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?
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).
Please use another name (end of rant).