4 ms·

So, I recently (as in yesterday evening) converted the following piece of code in index.php of a wordpress plugin: if( $_GET["foo"] == "bar" ) { //add_

So, I recently (as in yesterday evening) converted the following piece of code in index.php of a wordpress plugin: if( $_GET["foo"] == "bar" ) { //add_action( 'wp_loaded', 'do_foo' ); //add_action( 'init', 'do_foo' ); //add_action( 'admin_init', 'do_foo' ); do_foo(); } which allowed easy launching of do_foo() by simply httping http://wordpress.tld/?foor=bar http://wordpress.tld/?foor=bar to add_action('rest_api_init', 'Company\PluginName\setup_foo_route'); and namespace Company\PluginName; function setup_foo_route() { register_rest_route( 'company/v1', 'bar', array( 'methods' => 'GET', 'callback' => 'Company\PluginName\do_foo', ) ); } which can be run by httping http://wordpress.tld/?rest_route=/company/bar http://wordpress.tld/?rest_route=/company/bar Which one of us would like to talk to :) ?

dahart 7y ago
That’s perhaps much too small to be an example of what the parent comment was talking about. This might be a good example of what the article is talking about though. These represent two different fashions, both of which have enjoyed widespread support at different times. The original is explicit and smaller and easier for someone who’s not you to follow & modify. The latter is event/callback driven, and more complicated to follow, but in a large codebase might be a pattern that is easier to build on, maintain, and refactor, as well as harder to screw up when adding new routes.
- johnchristopher 7y ago
  I agree with you. What makes me lean towards my solution is that I can pass the plate to the WordPress documentation if anyone else want to know what the code is doing and we can follow the trail of callbacks and hooks while that request check can be (and in this case, is) sprinkled all over the codebase. What I noticed is that people following the first method ends up hacking core functionalities of WP because "it just works" but in the end that makes the code unstable and harder to maintain because it relies on undocumented stuff and a coding style that is very personal. It can also messes big time with stable things expected from the CMS (mangled taxonomies, hijacked hooks in the core instead of the WP pile that make it hard to debug or to play nice with other plugins/themes).
folkhack 7y ago
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 -_-;

dahart 7y ago

That’s perhaps much too small to be an example of what the parent comment was talking about. This might be a good example of what the article is talking about though. These represent two different fashions, both of which have enjoyed widespread support at different times. The original is explicit and smaller and easier for someone who’s not you to follow & modify. The latter is event/callback driven, and more complicated to follow, but in a large codebase might be a pattern that is easier to build on, maintain, and refactor, as well as harder to screw up when adding new routes.

johnchristopher 7y ago
I agree with you. What makes me lean towards my solution is that I can pass the plate to the WordPress documentation if anyone else want to know what the code is doing and we can follow the trail of callbacks and hooks while that request check can be (and in this case, is) sprinkled all over the codebase. What I noticed is that people following the first method ends up hacking core functionalities of WP because "it just works" but in the end that makes the code unstable and harder to maintain because it relies on undocumented stuff and a coding style that is very personal. It can also messes big time with stable things expected from the CMS (mangled taxonomies, hijacked hooks in the core instead of the WP pile that make it hard to debug or to play nice with other plugins/themes).

folkhack 7y ago

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 -_-;