Corcel has worked great for us, even in a production environment.
Our family's e-commerce business previously had a slow and bloated WooCommerce site, largely due to my skill issues. However, we were able to rescue the site by using Corcel, Laravel, Filament, and LunarPHP.
My wife still uses the WordPress admin interface as the main admin tool, while the public-facing website is rendered by Laravel, with data provided seamlessly through Corcel.
Sandly, Automattic / WooComm is responsible for such thing.
For example, the product gallery is such all images - thumbs and main slides - load on page load. If you don't click any thumbs - and had 10 total images - 9 would have loaded for naught.
But there are BE + FE ways to fix that :)
Also, WooComm recently introduced HPOS that moved order meta into its own table. Smart! But there is still order data captured for every order (e.g., customer order IP, etc).that's in the meta table. Why those we're moved to the new table IDK.
On the other hand, most techs are bias. That is, the tool they know is always the best solution, whether that's true to not.
Yeah, perhaps there are times when WP isn't the ideal choice from a pure technology POV, but there's more to it than that. For example, most (solo) devs complete dismiss the "getting hit by a bus" test. Sorry, but no one should accept advice from anyone who dismisses that test.
Oh, interesting. Can you provide more insights? Pitfalls?
I am in a very similar situation. Just it's not my families business. It's a friend e-commerce business that i supported & developed on the site for years. I wanted to move the product creation to a separate php application & sync via api. But those projects always explode.
How much time did you spend on this "migration"?
Is it a monolith? How does everything work together? What if you wanna leave the Wordpress DB schema behind at some point, would it be easy to "just" rewrite your backend models & DB schema?
After taking a quick look at your e-commerce site, you could simplify it further without compromising performance over personalization/technology stack if you have alternative options especially minimal codebase and CDN friendly.
You are right, I should completely move out of Woocommerce and exclusively use Laravel + Filament + LunarPHP or even use hosted Shopify and decouple myself from the tech stack.
At the same time, a day job and raising kids can make major technological transitions a real challenge. So, we are here, still stuck between 2 systems.
I took the WordPress-based / WooCommerce system and split it into 1) the Shopify system for admin stuff and also the whole payment system and 2) the "frontend" i.e. the consumer facing part BEFORE the payment (I used Symfony, similar to Laravel, but more modular and I was more familiar with it). Theoretically you could fetch all the product data via the Shopify API and then sync it automagically. But in the first iteration, we just copied some of the basic product data into a simple Symfony Admin backend and made a simple javascript-based checkout slide-out, and only when they were ready to pay, they would be forwarded to Shopify.
This way we would have full control of the user experience up to the point of purchase, and then Shopify would take over. I thought this was the best way I can deliver a performant website, while also being able to sleep well, because all the money stuff and all the customer data is handled by Shopify.
I was able to increase search engine traffic by 30% this way, reduce page size and increase page speeds and revenue increased significantly.
After 3 years, he decided he wanted to make it more "professional", so he fired me, I got none of the credit ("the search engine traffic must be because of better branding - and the page isn't up to my standards of aesthetics... yes, the designers who were supposed to deliver the designs kept stalling and delivered NOTHING and you had to just create something on the fly before the main selling season, and yes we had huge sales gains on the website and more traffic, but this was not because of the website"... they didn't change any of the marketing or any of their strategies, by the way.) So they hired an agency team with a project manager, designer, developer, marketing person; who then asked me to give them the source code from git so they can upload the code to their FTP server (!).
And they pretty much didn't change anything for a few years, everything looked the same. After like 4-5 years, they adjusted the design a bit, but still looked VERY similar.
Ah, if between the 2, perhaps, Astro web framwork is what I could build a small e-commerce quickly with minimal code in TypeScript, Tailwind and lots of copy and paste UI. Prior to Astro, I was spent months solving the differences codebase on frontend and backend. So anyway, we are in the same timezone.
First request to finished render without any client side caching takes 5 s on my end, so I expect it to take maybe the double on an elderly device with a wobbly connection.
Agreed. I've been doing freelance design/dev for small businesses for 15+ years and at first I would always choose the best current CMS available. Wordpress was always an option, but it was clunky and had a mixed reputation. Well, all those CMSs are gone and I had to migrate several sites. Wordpress offers one of the most important things to these small businesses: (relative) consistency and dependability.
I can very much see the benefit of decoupling the front and back ends for these cases, especially since in most cases nowadays the public facing pages are pre-rendered/cached anyway. Also, I love Laravel.
Just wanting to chime in that ProcessWire [1] has provided this dependency for me over the last 10 years, even in a better way than WordPress can provide, since it is such a small core that rarely needs updating, and that most if not all functionality can be developed through a few lines it's amazing PHP API rather than tons of 3rd party plugins that need constant updating. 10+ year site still running without me touching it. One customer even was able to find a (non-expert) developer to develop it further, since it is all pure PHP anyways.
Looks to me to be a bit more than that in the repo.
Not sure if this is a thing in Laravel yet but usually it's easy to generate ORM classes from an existing database. Symfony has it in their CLI tool, or had back in 2019 when I last used it.
It circumvents the GPL unless you have a very unusual interpretation or have it putting GPL code into your database, with better performance and less complexity that the REST and GraphQL wrappers that are common ways to do headless WordPress.
I can see why people would do this with existing WordPress setups, but would there be any reason to consider it for a new build over a dedicated headless CMS (like Strapi or a bunch for PHP I don't know well enough to name) or headless CMS SAAS (like Prismic)?
We migrated from WordPress to Prismic several years ago, then migrated to Strapi a year ago, and it has been miserable.
We originally used Corcel with our Laravel installation, but somehow still found malware, so we immediately decommissioned the entire WordPress install and switched to Prismic. Prismic worked great and I regret switching to Strapi, but I felt the extensibility would be better (and latency reduced) if we self-hosted our headless CMS.
Managing Strapi is a full-time job, and their support for things like localization and their API are terrible. Don’t believe their marketing hype.
It sucks that you had a tough time with Strapi; I use it for many projects and have not had any issues. Do you have any example, specifically " like localization and their API," where you had issues?
I also know they have open office hours on their Discord channel Mon - Fri 12:30 pm cst where you can get help and ask questions.
Yes. Every content manager and content writer knows and loves Wordpress. It's only developers that hate Wordpress. Corcel lets those content people use the tools they like, and lets developers build secure, performant, maintainable websites.
Can someone explain the sweet spot here? WP has a REST API. It has a GraphQL plugin. Whether you use those via BE or FE requests, the backend is already open to anything.
This is very cool! It always felt like PHP was behind in tooling - git-driven CI was challenging for WordPress (because the framework's plugins edit the project files and it is married to subversion), and serverless PHP was basically impossible until Laravel Vapor came along. Projects like this give me hope and excitement. I wish Corcel was around years ago when I had to write gross SQL string interpolation for various WordPress projects.
Agreed on PHP tooling. I'm surprised more hasn't been borrowed from other frameworks. Working in this space too on serverless wordpress+mariadb[0]. We have a lot of open source tooling on our roadmap to make this as complete as serverless for other languages.
I am not a PHP developer, and our php code is all third party apps.
Do you have any write ups on PHP tooling? My feeling is that php tooling has a hard time handling stateless images, you often need to install plugins to php applications with a GUI with no good way to do it in a build process. Config of php applications is always an mix of php.ini and database config, often making monitoring a case of writing custom http requests and html parsing. I am not that happy with Java but there are many things it get right especially in tooling.
Modern PHP applications use Composer to manage packages as well as to install PHP extensions. Configuring your PHP app is entirely for you to do - whether you keep your configuration in the database is not a problem of PHP, it's your applications and how it was made. These days I'd think the common thing is to just use ENV variables, like all other modern applications do. If you mean however to configure the PHP runtime, well yes, you have to touch php.ini for that, much like you have to have tons of flags to configure the Java runtime, I don't see how it's very different.
For PHP monitoring there are numerous modern solutions out there just a quick google search away.
A direct database connection means almost all of your queries will work without any error handling. Using an API requires you to handle lost connection every time you make a request.
Direct database connections almost always are orders of magnitude faster, especially when joins are involved.
From skimming the docs, this is more about WP database than WP itself. In other words, you could install WP to setup the DB and then kill the WP install if you liked.
1. It looks like it only works with that which would be provided by WP by default. For example, the link below is an extension for working with Woocommerce. Given that WP doesn't even need to exist (you only need the WP DB) then you could use whatever setup is compatible with Laravel. You could also have separate environments with WP and Laravel sharing a remote DB.
2. Both WP and Laravel would work as if the other didn't exist. They only share the DB.
Corcel has worked great for us, even in a production environment.
Our family's e-commerce business previously had a slow and bloated WooCommerce site, largely due to my skill issues. However, we were able to rescue the site by using Corcel, Laravel, Filament, and LunarPHP.
My wife still uses the WordPress admin interface as the main admin tool, while the public-facing website is rendered by Laravel, with data provided seamlessly through Corcel.
in wordpress ecosystem do not blame yourself if you end up with a bloated site :)
Sandly, Automattic / WooComm is responsible for such thing.
For example, the product gallery is such all images - thumbs and main slides - load on page load. If you don't click any thumbs - and had 10 total images - 9 would have loaded for naught.
But there are BE + FE ways to fix that :)
Also, WooComm recently introduced HPOS that moved order meta into its own table. Smart! But there is still order data captured for every order (e.g., customer order IP, etc).that's in the meta table. Why those we're moved to the new table IDK.
The real issue is that customers without knowledge are asking explicitly for wordpress instead letting us techs give the best advice.
Most techs give terrible advice.
On the other hand, most techs are bias. That is, the tool they know is always the best solution, whether that's true to not.
Yeah, perhaps there are times when WP isn't the ideal choice from a pure technology POV, but there's more to it than that. For example, most (solo) devs complete dismiss the "getting hit by a bus" test. Sorry, but no one should accept advice from anyone who dismisses that test.
wordpress is being marketed, deployed and then abandoned without maintenance by seo experts and designers, not techs nor devs.
Oh, interesting. Can you provide more insights? Pitfalls?
I am in a very similar situation. Just it's not my families business. It's a friend e-commerce business that i supported & developed on the site for years. I wanted to move the product creation to a separate php application & sync via api. But those projects always explode.
How much time did you spend on this "migration"?
Is it a monolith? How does everything work together? What if you wanna leave the Wordpress DB schema behind at some point, would it be easy to "just" rewrite your backend models & DB schema?
After taking a quick look at your e-commerce site, you could simplify it further without compromising performance over personalization/technology stack if you have alternative options especially minimal codebase and CDN friendly.
You are right, I should completely move out of Woocommerce and exclusively use Laravel + Filament + LunarPHP or even use hosted Shopify and decouple myself from the tech stack.
At the same time, a day job and raising kids can make major technological transitions a real challenge. So, we are here, still stuck between 2 systems.
I once did that for a client of mine.
I took the WordPress-based / WooCommerce system and split it into 1) the Shopify system for admin stuff and also the whole payment system and 2) the "frontend" i.e. the consumer facing part BEFORE the payment (I used Symfony, similar to Laravel, but more modular and I was more familiar with it). Theoretically you could fetch all the product data via the Shopify API and then sync it automagically. But in the first iteration, we just copied some of the basic product data into a simple Symfony Admin backend and made a simple javascript-based checkout slide-out, and only when they were ready to pay, they would be forwarded to Shopify.
This way we would have full control of the user experience up to the point of purchase, and then Shopify would take over. I thought this was the best way I can deliver a performant website, while also being able to sleep well, because all the money stuff and all the customer data is handled by Shopify.
I was able to increase search engine traffic by 30% this way, reduce page size and increase page speeds and revenue increased significantly.
After 3 years, he decided he wanted to make it more "professional", so he fired me, I got none of the credit ("the search engine traffic must be because of better branding - and the page isn't up to my standards of aesthetics... yes, the designers who were supposed to deliver the designs kept stalling and delivered NOTHING and you had to just create something on the fly before the main selling season, and yes we had huge sales gains on the website and more traffic, but this was not because of the website"... they didn't change any of the marketing or any of their strategies, by the way.) So they hired an agency team with a project manager, designer, developer, marketing person; who then asked me to give them the source code from git so they can upload the code to their FTP server (!).
And they pretty much didn't change anything for a few years, everything looked the same. After like 4-5 years, they adjusted the design a bit, but still looked VERY similar.
Ah, if between the 2, perhaps, Astro web framwork is what I could build a small e-commerce quickly with minimal code in TypeScript, Tailwind and lots of copy and paste UI. Prior to Astro, I was spent months solving the differences codebase on frontend and backend. So anyway, we are in the same timezone.
First request to finished render without any client side caching takes 5 s on my end, so I expect it to take maybe the double on an elderly device with a wobbly connection.
There might be better ways to increase profits.
If I understood correctly, this is basically a collection of Eloquent (Laravel's ORM) models that represent Wordpress database tables.
Nifty tool for PHP projects that need to interface with Wordpress data.
With how large the Wordpress market is, this is probably desired by more teams than one could think of at a quick glance.
Agreed. I've been doing freelance design/dev for small businesses for 15+ years and at first I would always choose the best current CMS available. Wordpress was always an option, but it was clunky and had a mixed reputation. Well, all those CMSs are gone and I had to migrate several sites. Wordpress offers one of the most important things to these small businesses: (relative) consistency and dependability.
I can very much see the benefit of decoupling the front and back ends for these cases, especially since in most cases nowadays the public facing pages are pre-rendered/cached anyway. Also, I love Laravel.
Just wanting to chime in that ProcessWire [1] has provided this dependency for me over the last 10 years, even in a better way than WordPress can provide, since it is such a small core that rarely needs updating, and that most if not all functionality can be developed through a few lines it's amazing PHP API rather than tons of 3rd party plugins that need constant updating. 10+ year site still running without me touching it. One customer even was able to find a (non-expert) developer to develop it further, since it is all pure PHP anyways.
As a former Drupal webdev, ProcessWire is heaven.
https://processwire.com/
> Wordpress offers one of the most important things to these small businesses: (relative) consistency and dependability.
Kudos. Maintainability. It matters. I wish more devs realized that their DIY solutions are a disservice to the client once they leave the project.
WP has it (many) faults. But in general a good new dev can - with some effort - pick up where the ex-dev left off.
Clients should not loose sleep tracking down support for some esoteric megalomaniac-developer solution.
Looks to me to be a bit more than that in the repo.
Not sure if this is a thing in Laravel yet but usually it's easy to generate ORM classes from an existing database. Symfony has it in their CLI tool, or had back in 2019 when I last used it.
It circumvents the GPL unless you have a very unusual interpretation or have it putting GPL code into your database, with better performance and less complexity that the REST and GraphQL wrappers that are common ways to do headless WordPress.
I can see why people would do this with existing WordPress setups, but would there be any reason to consider it for a new build over a dedicated headless CMS (like Strapi or a bunch for PHP I don't know well enough to name) or headless CMS SAAS (like Prismic)?
We migrated from WordPress to Prismic several years ago, then migrated to Strapi a year ago, and it has been miserable.
We originally used Corcel with our Laravel installation, but somehow still found malware, so we immediately decommissioned the entire WordPress install and switched to Prismic. Prismic worked great and I regret switching to Strapi, but I felt the extensibility would be better (and latency reduced) if we self-hosted our headless CMS.
Managing Strapi is a full-time job, and their support for things like localization and their API are terrible. Don’t believe their marketing hype.
It sucks that you had a tough time with Strapi; I use it for many projects and have not had any issues. Do you have any example, specifically " like localization and their API," where you had issues?
I also know they have open office hours on their Discord channel Mon - Fri 12:30 pm cst where you can get help and ask questions.
Yes. Every content manager and content writer knows and loves Wordpress. It's only developers that hate Wordpress. Corcel lets those content people use the tools they like, and lets developers build secure, performant, maintainable websites.
I haven't used Corcel as I haven't needed to reach for Eloquent but https://github.com/roots/acorn and the ecosystem surrounding it is fantastic.
This is a good mid-migration step but I'm not sure the WP database design is of particular merit otherwise.
(This is speaking as someone who just migrated a site TO WordPress because it was still better than the previous system...)
Agreed. Presumably people want to keep years of posts and pages plus the familiar admin interface.
Can someone explain the sweet spot here? WP has a REST API. It has a GraphQL plugin. Whether you use those via BE or FE requests, the backend is already open to anything.
There is also wordpress-interop on the doctrine side: https://github.com/williarin/wordpress-interop
This is very cool! It always felt like PHP was behind in tooling - git-driven CI was challenging for WordPress (because the framework's plugins edit the project files and it is married to subversion), and serverless PHP was basically impossible until Laravel Vapor came along. Projects like this give me hope and excitement. I wish Corcel was around years ago when I had to write gross SQL string interpolation for various WordPress projects.
PHP hasn't been behind in tooling, WordPress has (and still is). Frameworks like Laravel are very much up to par when it comes to tooling.
>serverless PHP was basically impossible until Laravel Vapor came along
I've got production PHP Lambda runtimes that predate Laravel Vapor by 7 years...
Agreed on PHP tooling. I'm surprised more hasn't been borrowed from other frameworks. Working in this space too on serverless wordpress+mariadb[0]. We have a lot of open source tooling on our roadmap to make this as complete as serverless for other languages.
0. https://www.agiler.io
PHP tooling is amazing. WordPress tooling is not, since it uses archaic development practices.
I am not a PHP developer, and our php code is all third party apps.
Do you have any write ups on PHP tooling? My feeling is that php tooling has a hard time handling stateless images, you often need to install plugins to php applications with a GUI with no good way to do it in a build process. Config of php applications is always an mix of php.ini and database config, often making monitoring a case of writing custom http requests and html parsing. I am not that happy with Java but there are many things it get right especially in tooling.
Modern PHP applications use Composer to manage packages as well as to install PHP extensions. Configuring your PHP app is entirely for you to do - whether you keep your configuration in the database is not a problem of PHP, it's your applications and how it was made. These days I'd think the common thing is to just use ENV variables, like all other modern applications do. If you mean however to configure the PHP runtime, well yes, you have to touch php.ini for that, much like you have to have tons of flags to configure the Java runtime, I don't see how it's very different.
For PHP monitoring there are numerous modern solutions out there just a quick google search away.
I think Bref predates Vapor. People were doing PHP with Lambda prior to that, too, with the custom runtimes. https://aws.amazon.com/blogs/apn/aws-lambda-custom-runtime-f...
Interesting.. Is there a Ruby/rails equivalent?
I wrote one years ago, but I suspect the schema has drifted quite far out of sync: https://github.com/robmiller/ruby-wpdb
How's Corcel different to using WP's own API? What are the pros / cons?
A direct database connection means almost all of your queries will work without any error handling. Using an API requires you to handle lost connection every time you make a request.
Direct database connections almost always are orders of magnitude faster, especially when joins are involved.
Curious about the name choice!
Is it derived from "coerce", because it can be pronounced like "core cell"? Or something else? Or just a made-up term? :)
Could imagine people being genuinely grateful for being able to plug another PHP application onto WordPress for the frontend, if this works well.
Great idea!
In Spanish at least, Corcel means Steed. A horse. Like the beautiful one from Shrek 2.
Not to be confused with Porcel, a group of pigs.
Like Vercel but cooler :)
if this works it would completely change how we do things with wordpress.
1. does it work with any wordpress plugin? can i piggy back off laravel + frankenphp to scale what used to be nightmarish with wordpress?
2. does the underlying CMS UI still work for WP? Or is it built separately?
From skimming the docs, this is more about WP database than WP itself. In other words, you could install WP to setup the DB and then kill the WP install if you liked.
1. It looks like it only works with that which would be provided by WP by default. For example, the link below is an extension for working with Woocommerce. Given that WP doesn't even need to exist (you only need the WP DB) then you could use whatever setup is compatible with Laravel. You could also have separate environments with WP and Laravel sharing a remote DB.
2. Both WP and Laravel would work as if the other didn't exist. They only share the DB.
https://github.com/corcel/woocommerce
Would Acorn not also fall under the same utility? It's been around for a while. https://roots.io/acorn/
Ive had success previously using Symfony talking to the WordPress database.
Later, I used React to talk to the WordPress API, exposing the Customiser config as JSON, then getting React to render pages based of this.
Useless. WP has a very good REST API
Have been using this for years to handle the auth in a Laravel application that's tucked inside of a WooCommerce shop, works great.
Anyone know of something similar but for interfacing with a Drupal database?
Better than using Gatsby, which adds complexity both on the node point javascript and WordPress end of things: https://www.gatsbyjs.com/plugins/gatsby-source-wordpress/
Either are better than having to deal directly with WordPress, though.
I've had to do this manually so many times over the years.