3 ms·

Sorry for the critique on methodology but I'd start to consider a different system for routing vs hooking into the WordPress REST API. If I'm doing anything th

Sorry for the critique on methodology but I'd start to consider a different system for routing vs hooking into the WordPress REST API. If I'm doing anything that actually requires sane PHP primitives (like the routing in your above example, and also notably DB) I steer clear from WordPress entirely. WordPress is a good CMS and makes for a great blogging platform but I have done my best to decouple any-and-all custom application development to it's own API. WordPress and it's core simply don't offer good tools, and it's a VERY highly targeted platform in regards to security. I would suggest Symfony or Laravel for PHP frameworks that do APIs very well; or even AltoRouter + vanilla PHP for super light-weight stuff where you want minimal dependencies. Personally I think Laravel is the easiest, and a joy to learn. Otherwise - kudos on ripping it out and replacing it with cleaner code!

johnchristopher 7y ago
Thanks. I am not sure I understand the suggestion. Do you mean I could build the API with Laravel/Lumen/Symphony and bolt it on top of WP-Core or WordPress options or even directly the posts table (for example) ? (In this particular case the WordPress CMS is non-negotiable but I have no problems considering bypassing its REST API to interact with it if it brings significant advantages). I admit I am a bit nervous in regard to opening WP with REST endpoints considering its reputation.
- rubyn00bie 7y ago
  Yes, that's more or less what I assume they mean. Likely[1], the intent is almost to treat Wordpress as one component (dependency) of your application. Remove all business logic that's held directly in its tables and code, and instead add layer from Symphony/Laravel/Framework-Goes-Here which "syncs/pushes/writes" to Wordpress. Wordpress becomes just a "piece" of your application instead of your application. Wordpress is just the CMS for your business logic (application), not the application itself :) It'll reduce the surface area of attacks because you fucks with wordpress internals less. It'll make upgrades easier because you fucks with wordpress internals less, and it'll generally make life easier down the road because you need to fucks with wordpress internals less. Just my two cents :) [1] Because what they outlined is like spot on with what I'd be doing... I think nervous laugh -_-;
  - folkhack 7y ago
    > Likely[1], the intent is almost to treat Wordpress as one component (dependency) of your application. Remove all business logic that's held directly in its tables and code, and instead add layer from Symphony/Laravel/Framework-Goes-Here which "syncs/pushes/writes" to Wordpress. Nailed it. 100% WordPress gets pushed WAY too far and treating it more as a component/dep of your application is a perfect way of describing how I go about my work (stealing that explanation). When I start see people jacking into the REST API and the like I feel like that's "too far". However, in OP's defense, I have done exactly what he's showing myself and 100% understand the need with the right constraints! I often push my clients to decouple anything that can be described as "application-specific" or "business logic" ASAP for MANY reasons - security, better dev tooling, scaling, not relying on an EAV DB design under the hood, etc. Usually it's a <5 table CRUD application that can be described in 10-20 API routes... Even if you need an authentication system thrown in there Laravel eats that for breakfast. Way easier to scale, I have better control over the DB schema, I get "nice-to-haves" if I want them (ORM, input validation, DB migrations/seeds), I can trust it, etc etc. Also - when you use something like Laravel/Symfony you can totally tie into WordPress primitives, or even just point at the same DB as WP (you kinda touch on this). Some people may really look down on that - I see it just as any other integration. When done thoughtfully and WITH DOCUMENTATION it is 100% fine to "join the worlds" like that IMO. Ultimately, you get a LOT more flexibility when you pull in a tool and decouple a bit from WordPress which is why I'm getting all preachy. I feel responsible PHP devs should program very carefully, and/or use opinionated tools that are thoroughly vetted and well designed (like Symfony and Laravel). WordPress, it's core, it's team, and it's plugins are the antitheses of that last sentence! But for many it's a necessary evil as it still is the most popular/developed-for "host-your-own CMS" solution. Thanks for backing me up - that comment could have really backfired with the HN audience. Cheers!
    - johnchristopher 7y ago
      Thanks, I'll be looking into all that.
- folkhack 7y ago
  Yep! I've supported a lot of high profile WordPress installations for about 15 years now, all with varying degrees of customization/applications tied-in. For me it's less reputation and just personal experience of knowing what will be less painful in the long-run to support, scale, and extend. A lot of people will frown on my advice to pull in the primitives from WP and/or directly tie-in to the existing database. People have an "all-or-nothing" approach to WP/application development and will push you to do things 100% in one tool or another... sometimes this is a great decision, many times it is not. The truth is, WordPress is a great CMS with backwards compatibility that is astounding... but to maintain that backwards compatibility it has to hold itself back. When I have to work on WordPress sites (way less often by choice) I find the APIs and ergonomics to be horrid and regressive, as-if I was still stuck programming for PHP 5.x. The downside of what I'm pushing: you have one more codebase to manage/deploy/update/document/etc. For me, that's no big deal. I have an established GitLab pipeline for smooth deployments of WordPress and Laravel codebases alike. Effectively I've designed my engineering projects/teams around "spinning off a microservice when needed"; but I also work on very large-scale applications. One more thing that keeps this manageable is hella-good documentation _IN THE REPOS_ that link to sibling codebases + describes every significant integration. (WP + Laravel via HTTP API and DB tie-in) Same goes with the API docs - even if internal, and even if for 1-2 routes: Ensure every potential HTTP request/method/URI is documented and kept up-to-date. I rely on Postman for this so I also get actual tooling along with my docs! Keep fighting the good fight =)

johnchristopher 7y ago

Thanks. I am not sure I understand the suggestion. Do you mean I could build the API with Laravel/Lumen/Symphony and bolt it on top of WP-Core or WordPress options or even directly the posts table (for example) ? (In this particular case the WordPress CMS is non-negotiable but I have no problems considering bypassing its REST API to interact with it if it brings significant advantages). I admit I am a bit nervous in regard to opening WP with REST endpoints considering its reputation.

rubyn00bie 7y ago
Yes, that's more or less what I assume they mean. Likely[1], the intent is almost to treat Wordpress as one component (dependency) of your application. Remove all business logic that's held directly in its tables and code, and instead add layer from Symphony/Laravel/Framework-Goes-Here which "syncs/pushes/writes" to Wordpress. Wordpress becomes just a "piece" of your application instead of your application. Wordpress is just the CMS for your business logic (application), not the application itself :) It'll reduce the surface area of attacks because you fucks with wordpress internals less. It'll make upgrades easier because you fucks with wordpress internals less, and it'll generally make life easier down the road because you need to fucks with wordpress internals less. Just my two cents :) [1] Because what they outlined is like spot on with what I'd be doing... I think nervous laugh -_-;
- folkhack 7y ago
  > Likely[1], the intent is almost to treat Wordpress as one component (dependency) of your application. Remove all business logic that's held directly in its tables and code, and instead add layer from Symphony/Laravel/Framework-Goes-Here which "syncs/pushes/writes" to Wordpress. Nailed it. 100% WordPress gets pushed WAY too far and treating it more as a component/dep of your application is a perfect way of describing how I go about my work (stealing that explanation). When I start see people jacking into the REST API and the like I feel like that's "too far". However, in OP's defense, I have done exactly what he's showing myself and 100% understand the need with the right constraints! I often push my clients to decouple anything that can be described as "application-specific" or "business logic" ASAP for MANY reasons - security, better dev tooling, scaling, not relying on an EAV DB design under the hood, etc. Usually it's a <5 table CRUD application that can be described in 10-20 API routes... Even if you need an authentication system thrown in there Laravel eats that for breakfast. Way easier to scale, I have better control over the DB schema, I get "nice-to-haves" if I want them (ORM, input validation, DB migrations/seeds), I can trust it, etc etc. Also - when you use something like Laravel/Symfony you can totally tie into WordPress primitives, or even just point at the same DB as WP (you kinda touch on this). Some people may really look down on that - I see it just as any other integration. When done thoughtfully and WITH DOCUMENTATION it is 100% fine to "join the worlds" like that IMO. Ultimately, you get a LOT more flexibility when you pull in a tool and decouple a bit from WordPress which is why I'm getting all preachy. I feel responsible PHP devs should program very carefully, and/or use opinionated tools that are thoroughly vetted and well designed (like Symfony and Laravel). WordPress, it's core, it's team, and it's plugins are the antitheses of that last sentence! But for many it's a necessary evil as it still is the most popular/developed-for "host-your-own CMS" solution. Thanks for backing me up - that comment could have really backfired with the HN audience. Cheers!
  - johnchristopher 7y ago
    Thanks, I'll be looking into all that.
folkhack 7y ago
Yep! I've supported a lot of high profile WordPress installations for about 15 years now, all with varying degrees of customization/applications tied-in. For me it's less reputation and just personal experience of knowing what will be less painful in the long-run to support, scale, and extend. A lot of people will frown on my advice to pull in the primitives from WP and/or directly tie-in to the existing database. People have an "all-or-nothing" approach to WP/application development and will push you to do things 100% in one tool or another... sometimes this is a great decision, many times it is not. The truth is, WordPress is a great CMS with backwards compatibility that is astounding... but to maintain that backwards compatibility it has to hold itself back. When I have to work on WordPress sites (way less often by choice) I find the APIs and ergonomics to be horrid and regressive, as-if I was still stuck programming for PHP 5.x. The downside of what I'm pushing: you have one more codebase to manage/deploy/update/document/etc. For me, that's no big deal. I have an established GitLab pipeline for smooth deployments of WordPress and Laravel codebases alike. Effectively I've designed my engineering projects/teams around "spinning off a microservice when needed"; but I also work on very large-scale applications. One more thing that keeps this manageable is hella-good documentation _IN THE REPOS_ that link to sibling codebases + describes every significant integration. (WP + Laravel via HTTP API and DB tie-in) Same goes with the API docs - even if internal, and even if for 1-2 routes: Ensure every potential HTTP request/method/URI is documented and kept up-to-date. I rely on Postman for this so I also get actual tooling along with my docs! Keep fighting the good fight =)