▲ 31 points
back
16 comments
This could use a discussion of advantages vs. disadvantages of using WordPress to build apps.
Advantages:
* Can use WordPress plugins for rapid development.
* Can use a WordPress theme for a quick beautiful design.
Disadvantages:
* Large amount of internal overhead (which caching plugins won't solve)
* Plugin conflicts must be handled manually
* Need to maintain proper versioning when adding/removing/updating plugins.
* Your website is a beacon for hacker attempts because it's running Wordpress.
It's good to work with WordPress in a pinch, but if you can build an app using traditional tools, it's better in the long run.
Advantages:
* You only need to learn to use one hammer for everything.
Disadvantages:
* Eventually you'll realize the things you've beat into shape tend to fall apart.
First things first. It's a great post. But just because you can doesn't mean you should.
The growing pains and the transition to a "real" solution later on will be a huge pain in the.... It's literally a duct tape hack more than an actual app. The database models and security of apps built on top of WordPress are horrible most of the time.
I agree that WordPress is enabling for a lot of people who bootstrap this kind of things and are not tech savvy or don't have the funds to build an application. I also know that it's scary to tackle these things when you don't know where to start. A false assumption people fall for a lot of times is that it'll be cheaper that way. It won't. If you consider starting with WordPress you should keep in mind to change the framework as quickly as possible. A good time to change it is when the idea is validated. But in reality people keep patching and patching until it collapses.
Yes, you can really use steel wool to wipe your ass.
I'll try that right after I finish using this chainsaw to brush my teeth.
This is an interesting discussion for old-school types like me who used to think, "Why would you run apps in a browser, native code on the machine is so much better, less overhead, better designed for it."
We had to take the hit, realize and admit that, "Well, browsers are nearly everywhere, it's what people are used to."
Now, I see the "browser app" people saying, "Why would you run apps in Wordpress, the browser is so much better, less overhead, better designed for it."
What's next, people using "Yo" as an app platform? ;)
"Can", but shouldn't...
To be a viable web app development model Wordpress really needs to follow down the ExpressionEngine -> CodeIgniter route. Slowly evolving into a set of modular components that work together. (Or how bulky symfony evolved into lightweight symfony2 + components)
Wordpress is still very much stuck in the old-school PHP world: download one big codebase, add some Wordpress specific packages (themes and plugins). That's a far away from where modern PHP is: smaller components brought together with composer and packagist. Which leads to more nimble frameworks for putting together web apps, picking and choosing the right set of components. Don't like Doctrine, use Propel, or RedBean, or Eloquent.
It's okay if your app fits into Wordpress' constraints of the world.
My concerns over the current state of Wordpress as a web-app framework:
* Plugins are special snowflakes, and so raises a gnarly set of conflicts and issues.
* Themes that do a lot more than theming - like WPGeo, which is an entire location-based functionality. It's like there's a packaging construct that involves themes + set of plugins that's missing. So themes become a dumping ground for any code.
* Dependence on global variables (like $wpdb)
* The datastore being SQL is leaked through the codebase.
* The visual layer drives the processing - so themes take control.
* Plugins are wordpress plugins, not well-built PHP packages.
* The extension mechanism (pseudo-event-binding through global functions) makes any code "Wordpress code", it's a lock-in.
* The custom data storage is a joke and inconsistent. serialised php being stored in mysql field, or serialised JSON. Wordpress is missing a mechanism to encourage structured data. I care about the quality of my data, my app needs to care too.
* Unit tests. Wordpress' architecture makes decent unit test coverage difficult.
* The quality of third-party plugin development isn't great. Understandable considering the typical Wordpress audience. If the plugin works, great. If there's a conflict, that can open up a pile of hurt.
* Essentially it's a code-coupling problem. It's difficult to disentangle. So you're mostly writing Wordpress specific code, not componentised PHP modules.
I like the admin interface, I wish that was a separate component that could be forked, and used as the basis for a web app.
I can't see how Wordpress can deal with these issues in a backwards compatible way. Yes, they can create a modular and componentised core that can be packaged up for use outside of Wordpress, but at some point there's going to have to be a shedload of Adaptors to translate that clean crafted and organised code into a bunch of global variables and global functions that themes and plugins rely on.
I can see good bits of Wordpress (like the admin ui) being forked off into separate projects and worked on in isolation to the point they catch up with modern PHP development. But these won't be backwards compatible with Wordpress without a grungy wordpress layer over the top.
Perhaps the damning thing is the lack of a consistent and appropriate data model, backed with a properly structured database. Sure, I can define my own relational database, do by hand what a content management system should already be doing for me - at that point where's the benefit? What if I want to be using a noSQL store instead?
It's hard to justify starting with Wordpress, when there are so many much better frameworks available for PHP that are more suited to packages and componentised code.
First step, up-to-date autoloader and namespaces.
By own admission, I'm a bit of a WP fan boy, but this was a stellar example of putting forth a constructive criticism about WP (in this case, for App usage). Almost all WP sentiments here tend to have obnoxious/negative/histrionic/elitist/brash/shortsighted qualities, so it's refreshing to see a balanced perspective padded with actual reasoning.
I agree with everything in this comment.
I've written plugins which used a PSR-0 autoloader, and namespaces, and considered templates to separate code from data, and realized very quickly that scaling that in Wordpress means treating every plugin as, essentially, its own completely autonomous and globally-running web framework (and also they didn't actually run on the particular site I wrote them for because they weren't running an up to date version of PHP.) It's difficult to write good code for Wordpress when for all your know your plugin is one of a hundred in someone else's install.
This is one of the most level-headed and accurate criticisms of WordPress I've ever seen, thank you for that.
I'm a mostly-WordPress developer (for now) learning NodeJS and seeing how all of these things combine to make the ecosystem less-than-optimal for "real" app-building. Some are more damning than others but it's hard to see how WP could start where it is now, a competent and popular CMS, and get to where it supposedly wants to be, an app platform, without breaking much of what's built on it already.
Your comment "It's okay if your app fits into Word[P]ress' constraints of the world" rings totally true. In fact, it's worth it to give the platform a try for an app-y project so you have something to compare it to, especially if that's where you're starting. Because my experience is so WP-heavy, the projects that I've wanted to build are colored by that. Now that I'm exploring a new stack, many of these assumptions seem ridiculous.
Thanks again for taking the time to put this all together.
ExpressionEngine? All all the cool kids are moving over to Craft CMS. The ExpressionEngine template parser is a mess of a find and replace engine while Craft uses Twig etc.
Not ExpressionEngine per se, but CodeIgniter that came from it.
Thanks for the Craft CMS pointer. I did not spot that when looking for something more modern that supported custom content types last year. I played briefly with Bolt CMS, but it didn't quite feel right to me.
Craft CMS - closed source?
agreed. rather than repeat myself, there was a sizable discussion regarding wordpress code quality several weeks back some may be interested in reading [1]