It seems WordPress owning the plugin distribution channel took an advantage of some plugin authors and replaced "Advanced Custom Fields" with own implementation ("fork"). Incident raises many questions and causes many issue, and the worst are people ruined days when such in-place, silent replaces are causing downtimes or partial malfunction.
Eli Lap
Posts
-
Grok Summary of the WordPress vs WP Engine situation -
A Vision of the Future: What if the WordPress Plugin architecture were based on inheritance?To be honest presented code looks ugly.
I personally prefer composition over inheritance.
Mixing functionality, styling, elements all together… I’m not sure what are the improvements comparing to existing systems.I’d prefer having interface based contracts and possibility to provide implementations.
Having a plugin bootstrap would allow plugin author to bootstrap and build any possible hierarchy within the module.
In-line requires… well, even composer 1 had PSR0/PSR4 autoloaders 4 years ago.Keeping the list of installed modules is IMO better than endless inheritance extensions.
Dependency Injection is a proven way to avoid globals.All of that does not sound like Wordpress anymore. But sounds like a battle-proved receipt for a well-functioning software.
-
Welcome to the forum!That’s fine to explicitly express the feelings, that’s just my choice to avoid the specific feelings and not spread it around, mostly highlighting I’m not a fan of WP. But we should carefully listen to them if we want to change something.
I always considered WP popularity was coming from possibility to build solutions fast. Not of the highest quality, possibly raising problems in the future, but pretty straightforward.
-
Encouraging the adoption of a standard API model.I think I’ve spotted similar concept: https://strapi.io/
I think it is a great tool and while personally I love Go it won’t reach the popularity of JS or PHP. And adoption is a key here.
API-first approach is great and reflects the modern approach. However, this requires more careful decisions and actually may lead to building 2 products: API platform and client platform, to make sure bootstrap and customization is fast.
Obviously there must be a default implementation to make it possible fast-forward setup.I think CSS is relatively easy with CSS-framework.
OpenAPI might provide a convenient way to generate client-agnostic network layer.The components are tricky: I’m not a huge fan of React but this seems to be the most popular option. From another perspective there are framework-agnostic solutions like Astro.build, that actually misses a reliable API data source.
These solutions, however increases total complexity of the entire solution, but might provide more flexible solutions. Also high performance might be easier to achieve while splitting the client/data source roles.
-
Welcome to the forum!I don't like to express hate, I think the world is big enough to choose and use what I love. Leaving the philosophy behind I must confess WP was not the platform of my choice.
Yet I believe we deserve to have an alternative. To have a good platform that is go-to solution for fulfilling our needs. Blogging, sharing, selling. The shape and flavour changes, but a solid base should be flexible and well known for fast and accurate delivery.