
WordPress for app development - gmays
http://torquemag.io/yes-you-really-can-use-wordpress-to-build-apps/
======
minimaxir
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.

~~~
elektronaut
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.

------
heyalexej
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.

------
psaintla
Yes, you can really use steel wool to wipe your ass.

~~~
noir_lord
I'll try that right after I finish using this chainsaw to brush my teeth.

~~~
chillingeffect
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? ;)

------
KhalPanda
"Can", but shouldn't...

------
Isofarro
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.

~~~
lukeholder
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.

~~~
Isofarro
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.

