5 ms·

I absolutely hate Wordpress, but I completely understand why it's popular. The reason why it's bigger than other publishing tools, is because there's almost no

I absolutely hate Wordpress, but I completely understand why it's popular. The reason why it's bigger than other publishing tools, is because there's almost nothing out there that has the deep network of plugins that can do almost anything. Sure, the backend of spaghetti PHP, HTML, MySql and endless backdoors and security issues are a nightmare, but there are really not that many alternatives to what Wordpress can do. And that's why Automattic is doing such a good business by basically hosting Wordpress and cleaning up and whitelisting more and more plugins. It makes perfect sense.

ivanmontillam 5y ago
My business partner and I hit a wall when we tried to automate WordPress. We tried to implement a plugin where Events in WordPress would be triggered, evaluate Conditions and then execute Actions (Send email, Trigger Webhook at Zapier, Update fields over the triggered record, etc.) Turns out, WordPress is not architecturally ready for this much evolution. And that's when we got disenchanted from WordPress and went to hunt on anything else.
- jawngee 5y ago
  This doesn't make any sense or you are explaining it badly. You are basically describing how every WordPress plugin already works via filters and actions (collectively referred to as hooks).
  - camillomiller 5y ago
    Oh it makes a lot of sense! What OP is describing is the experienced programmer approach to Wordpress. Should I check what's already in place for event handling? Absolutely not, I should put my very opinionated layer on top instead of understanding how the system works and go with it. I had major arguments with developers in my team in the past about this, as they would completely miss the point (let's ship) spending time instead reinventing the wheel all the time. They would also be extremely annoyed when I would easily point to the documentation page about how wordpress does exactly what they tried to re-write forcing the system's philosophy.
  - ivanmontillam 5y ago
    WordPress's fault, in this case, is that event propagation for specific actions to be hooked is poorly architected. It's impossible to differentiate "Create a post" event from "Update a post"; they propagate the same event. Every minor change on the post also triggers this event type, along with others. Therefore, leading to scenarios where "On post creation" and "On update, this field of this post" would lead to the same workflow triggered. As an Automator, you don't want to trigger the same workflow for another event that you didn't intend to. Our idea was to use the Conditions to judge if this workflow would run or not, but... We hit another roadblock; another issue was that when an event is triggered and conditions are to be evaluated, WordPress doesn't include in its payload the previous state of the fields, so if you want to do a "diff" (so you can tell which field values change) you then have to store the current state somewhere to be able to do such a "diff" to compare. We then had two roads: - Re-tool the core of WordPress with the functionality (with a lot of PHP hackery) that would enable us to run workflows the right way. - Relying on the existing API and end up with the same feature set that Uncanny Automator plugin currently has. So, instead of reinventing the wheel, we just dropped the idea.
    - jawngee 5y ago
      They don't propagate the same event though. `post_updated` vs `wp_insert_post`. `post_updated` passes the old and new values: https://developer.wordpress.org/reference/hooks/post_updated/ https://developer.wordpress.org/reference/hooks/post_updated... I'm the author of a sizable WordPress plugin (in terms of LoC and integration with WordPress) and nothing you are saying is making any sense to me.
      - ivanmontillam 5y ago
        Yes, these are different hooks with different parameters, but these are triggered by the same function[0]. When the function is called, all of these hooks are triggered. To identify what the user was doing (post creation on the first time? post updated? is the status being updated?), unless you have many conditions (potentially nested ifs), it's a cumbersome job. For example, a user wants a workflow every time the post is sent to the Trash. When a post is sent to the Trash, three things happen: - A hook is triggered because it's sent to the Trash. - The updated status one is also triggered (Published -> Trash). - The Updated post one is also triggered, because yes, this is an update. Yes, these are different hooks, but these do come from the same function. We tested two other plugins similar to ours and found minimal automation capabilities; we speculate this is because of the reasons I just exposed. If you check out the source code for wp_insert_post(), you'll find many do_action(). When clicking the "Add Post" button, the post is created at that moment (so it can reserve the permalink, etc.); by the time you save the post for the first time, in reality, it's being updated, not saved for the first time as one would believe. This is just a single example, but these software design decisions make it not that straightforward to create an automation plugin. By the way, that function calls many others inside, functions that trigger hooks by themselves; therefore, you'll have many workflows trigger attempts many times per second, just by saving the post. EDIT: Clarity. -- [0]: https://developer.wordpress.org/reference/functions/wp_insert_post/ https://developer.wordpress.org/reference/functions/wp_inser...
- sdze 5y ago
  Why would it be WP's fault? Maybe your competence level wasn't on the necessary level to automate WP.
  - ivanmontillam 5y ago
    I invite you to try it. We truly wanted this plugin to happen, we finally found a niche where there wouldn't be a zillion competitors, and we found out that WordPress's software design currently looks like it's been all hacked together. This "hacked-together" situation is not their fault in the sense that they have lacked engineering. I'm sure Automattic has some world-class engineers there. However, their codebase lags by years because of their legacy users. From a business perspective, they are hands-tied because any breaking change will bring hate towards them. Their userbase is too big to make any significant change, and Gutenberg already fragmented their ecosystem badly. They will need to create a new next-generation product from scratch, just like JetBrains does with Fleet instead of IDEA. For a more technical answer, I already gave detail at: https://news.ycombinator.com/item?id=30185809 https://news.ycombinator.com/item?id=30185809
sdze 5y ago
> Sure, the backend of spaghetti PHP, HTML, MySql and endless backdoors and security issues are a nightmare, but there are really not that many alternatives to what Wordpress can do. What "backend spaghetti" ? What endless backdoors and security issues? https://www.opencve.io/cve?vendor=wordpress&cvss=critical&search= https://www.opencve.io/cve?vendor=wordpress&cvss=critical&se...
iqanq 5y ago
The security issues are a feature. Wordpress never ends making money for those who get paid to install and maintain it.

ivanmontillam 5y ago

My business partner and I hit a wall when we tried to automate WordPress. We tried to implement a plugin where Events in WordPress would be triggered, evaluate Conditions and then execute Actions (Send email, Trigger Webhook at Zapier, Update fields over the triggered record, etc.) Turns out, WordPress is not architecturally ready for this much evolution. And that's when we got disenchanted from WordPress and went to hunt on anything else.

jawngee 5y ago
This doesn't make any sense or you are explaining it badly. You are basically describing how every WordPress plugin already works via filters and actions (collectively referred to as hooks).
- camillomiller 5y ago
  Oh it makes a lot of sense! What OP is describing is the experienced programmer approach to Wordpress. Should I check what's already in place for event handling? Absolutely not, I should put my very opinionated layer on top instead of understanding how the system works and go with it. I had major arguments with developers in my team in the past about this, as they would completely miss the point (let's ship) spending time instead reinventing the wheel all the time. They would also be extremely annoyed when I would easily point to the documentation page about how wordpress does exactly what they tried to re-write forcing the system's philosophy.
- ivanmontillam 5y ago
  WordPress's fault, in this case, is that event propagation for specific actions to be hooked is poorly architected. It's impossible to differentiate "Create a post" event from "Update a post"; they propagate the same event. Every minor change on the post also triggers this event type, along with others. Therefore, leading to scenarios where "On post creation" and "On update, this field of this post" would lead to the same workflow triggered. As an Automator, you don't want to trigger the same workflow for another event that you didn't intend to. Our idea was to use the Conditions to judge if this workflow would run or not, but... We hit another roadblock; another issue was that when an event is triggered and conditions are to be evaluated, WordPress doesn't include in its payload the previous state of the fields, so if you want to do a "diff" (so you can tell which field values change) you then have to store the current state somewhere to be able to do such a "diff" to compare. We then had two roads: - Re-tool the core of WordPress with the functionality (with a lot of PHP hackery) that would enable us to run workflows the right way. - Relying on the existing API and end up with the same feature set that Uncanny Automator plugin currently has. So, instead of reinventing the wheel, we just dropped the idea.
  - jawngee 5y ago
    They don't propagate the same event though. `post_updated` vs `wp_insert_post`. `post_updated` passes the old and new values: https://developer.wordpress.org/reference/hooks/post_updated/ https://developer.wordpress.org/reference/hooks/post_updated... I'm the author of a sizable WordPress plugin (in terms of LoC and integration with WordPress) and nothing you are saying is making any sense to me.
    - ivanmontillam 5y ago
      Yes, these are different hooks with different parameters, but these are triggered by the same function[0]. When the function is called, all of these hooks are triggered. To identify what the user was doing (post creation on the first time? post updated? is the status being updated?), unless you have many conditions (potentially nested ifs), it's a cumbersome job. For example, a user wants a workflow every time the post is sent to the Trash. When a post is sent to the Trash, three things happen: - A hook is triggered because it's sent to the Trash. - The updated status one is also triggered (Published -> Trash). - The Updated post one is also triggered, because yes, this is an update. Yes, these are different hooks, but these do come from the same function. We tested two other plugins similar to ours and found minimal automation capabilities; we speculate this is because of the reasons I just exposed. If you check out the source code for wp_insert_post(), you'll find many do_action(). When clicking the "Add Post" button, the post is created at that moment (so it can reserve the permalink, etc.); by the time you save the post for the first time, in reality, it's being updated, not saved for the first time as one would believe. This is just a single example, but these software design decisions make it not that straightforward to create an automation plugin. By the way, that function calls many others inside, functions that trigger hooks by themselves; therefore, you'll have many workflows trigger attempts many times per second, just by saving the post. EDIT: Clarity. -- [0]: https://developer.wordpress.org/reference/functions/wp_insert_post/ https://developer.wordpress.org/reference/functions/wp_inser...
sdze 5y ago
Why would it be WP's fault? Maybe your competence level wasn't on the necessary level to automate WP.
- ivanmontillam 5y ago
  I invite you to try it. We truly wanted this plugin to happen, we finally found a niche where there wouldn't be a zillion competitors, and we found out that WordPress's software design currently looks like it's been all hacked together. This "hacked-together" situation is not their fault in the sense that they have lacked engineering. I'm sure Automattic has some world-class engineers there. However, their codebase lags by years because of their legacy users. From a business perspective, they are hands-tied because any breaking change will bring hate towards them. Their userbase is too big to make any significant change, and Gutenberg already fragmented their ecosystem badly. They will need to create a new next-generation product from scratch, just like JetBrains does with Fleet instead of IDEA. For a more technical answer, I already gave detail at: https://news.ycombinator.com/item?id=30185809 https://news.ycombinator.com/item?id=30185809

sdze 5y ago

> Sure, the backend of spaghetti PHP, HTML, MySql and endless backdoors and security issues are a nightmare, but there are really not that many alternatives to what Wordpress can do. What "backend spaghetti" ? What endless backdoors and security issues? https://www.opencve.io/cve?vendor=wordpress&cvss=critical&search= https://www.opencve.io/cve?vendor=wordpress&cvss=critical&se...

iqanq 5y ago

The security issues are a feature. Wordpress never ends making money for those who get paid to install and maintain it.