[This is a test article to see if there’s demand. There is no series yet.]
WordPress is NOT a web app framework. But sometimes, it’s good enough.
First of all, let me set the record straight: I do not recommend using WordPress long-term for web app projects. In fact, that’s why I named this guideline (Series? Tutorials? Rants?) “WaryPress” — you should be wary of the limitations and quirks of WordPress as it was not originally designed for building web apps.
However, for some, WordPress can serve as a bridge, a temporary foundation. Go into it with the mindset of “it’s good enough…for now.”
I intend for WaryPress to be a loose guideline for building web apps on WordPress that strives for a balance of:
- – lower learning curve than proper frameworks
- – minimal data structure changes when porting to a proper framework
- – less time/effort needed to achieve small wins
Hopefully the WaryPress guideline can help people who:
- – are beginners and still can’t understand frameworks YET
- – want to make quick prototypes or proof-of-concepts
- – want to make internal web apps for local, small businesses
- – just want to make simple web apps for personal use
There are a few caveats to using WordPress as a web app foundation:
Building the app is easier/faster in the beginning, but over time you will wrestle with it more and more. At that point, consider porting to a framework.
Due to its popularity and the practice of putting all files in the public folder, WordPress is much more susceptible to attacks. We’ll take a look at common security practices later.
AJAX the proper WordPress way is slow — you’d have to resort to hacky workarounds. This will be elaborated on in Part 3.
If you are not a beginner, I urge you to just use popular web app frameworks. Or not. It’s up to you. Who am I to dictate what you should or shouldn’t use?
WordPress? Really?
Again, I do not recommend using WordPress long-term for web app projects. Use it according to the WaryPress guideline as a temporary foundation to get something going and — if you’re a beginner — learn a proper web app framework on the side. Maybe Laravel as it is PHP just like WordPress. Other big ones include Ruby on Rails for Ruby, and Django for Python.
Now, WordPress is great, I use it for my personal website. Despite having millions of installation, the WordPress core team still tries to keep things simple and I really appreciate that. I expect that, for at least another decade, it will continue to be the content management system…and therein lies the problem: it’s already a web application.
To build a web application on WordPress is like using your bedroom as the base of operations for your seed business. In the beginning, storing seeds in your old shoebox is more than enough. You don’t need much space. Then business starts booming. Uh oh.
Maybe after a while it’s overflowing. Fine, whatever, get a second shoe box. Okay, when that second one fills up, do you get a third shoe box? Probably not, it’s starting to feel unmanageable.
Nah, you get something better. Maybe from IKEA. Oh, don’t get me wrong —it’s proven time and time again that WordPress can scale just fine. It can handle being the multiple houses. The concern here is…can you?
Make fun of WordPress all you want, but it has something that most software don’t have: ubiquity. Tens of millions of websites run WordPress — even big, household-name companies are using it. It’s amazing how non-technical people can manage to install WordPress and proceed to help people, enrich other people’s lives, be perverts together across the globe, etc — personally, that’s what software is ultimately for – magnifying results.
It’s safe to say that a small percentage, if not already, will eventually modify WordPress to do something that ready-made plugins or themes can’t or won’t. Most will start small, and most will stop there. However, a percentage of the aforementioned percentage will slowly get better and better and eventually be able to bang out custom web apps…and some even get paid to do so.
Instead of being a dogmatic hemorrhoid jerk-hole and turn my nose up on WordPress web apps, I think it would be better to offer you some ideas on how to make WWA (“Wordpress web apps” — I’m just gonna use this acronym from here on out) without shooting yourself in the foot…hopefully. I’ve made a few WWAs myself, so these are based on my experience.
Before going to the technical stuff, let me elaborate on the why’s of WWA:
Reason 1: Education & Training
I think building WWAs can serve as a training ground for basic app-making skills — it’s not just code, there’s much more to it.
User interface and experience (UI/UX) — arguably the most important part
Architecture
Version control and deployment
Big picture thinking
Curating: what to include, what not to include, what to remove, why’s
Related to above: Ego management
…and more.
You can take months to get somewhat not-embarrassingly-bad at making apps, and progressively get better, little by little, over the time span of years.
Reason 2: Building for Local Businesses
So let’s revisit my analogy mentioned somewhere above:
“To build a web application on WordPress is akin to using a shoe box to store your notebooks.”
Come to think of it, that’s just fine, isn’t it? Sometimes you just need something simple that can hold your stuff. You don’t need a cabinet, you don’t need a storage unit. If your stuff overflows then you can just move them to another place, but for now it’s sufficient enough.
Anyway, my first WWA was something I did for a friend who had a bookstore. She just wanted something done for cheap inside her WordPress site. I took the job because she was kinda scary but also kinda cute. We dated for a while but it didn’t work out and…oh right, you don’t care.
At that time I was running a consultancy building custom internal web apps for businesses. At that time we mostly used Ruby on Rails with some Python for data analytics stuff. We had some experience in WordPress, but a web app was a new beast. I was pleasantly surprised, however. The API is more than powerful enough to do business CRUD apps.
After that, we used WordPress for making crude-but-working prototypes — these are then handed off to our clients — and then build the real web apps in a proper framework based on user feedback. We called this the “1+n months” method, I’ll get back to that later.
That’s what I think WordPress is good enough for: building one-off internal web apps for local businesses and associations. Separate installation per project. Desperate Insta-Commenters LLC gets their own WordPress with stalkee tracking system, and Balding & Binoculars Club gets their own WordPress with stalkee tracking system.
You can make multi-tenant software-as-a-service (SaaS) with WordPress. HelloBar did it, at least in their early days. Be prepared to wrestle with it a lot and risk burnout, though. If you’re planning on making, say, a restaurant management system that restaurant proprietors can pay $49 a month for, I recommend investing in learning a framework or find a programmer.
Reason 3: Prototyping/Proof-of-Concept
I mentioned the “1+n months” method earlier, used in my old software consultancy business (we called ourselves a Business Process & Workflow Consultancy…gotta know how to jargon).
Anyway, basically the first month is for WaryPress. For each project, we used (rough estimation):
Weeks 1–2 to gather requirements and planning. Some back-and-forth.
Week 3 for making a crude-but-working prototype. We could bang out something usable — with mostly custom code — in as little as 3 days using WordPress. Sometimes we just coded live during conference calls.
Weeks 3-4 to start user testing — let them use it with a huge disclaimer saying that this is a temporary tool to find real-world usage patterns.
And then for the next n months (usually 2 for small business and 4–5 for medium/big ones):
- Gather feedback every week — we used these to redesign the UI/UX. In jargon, it’s called “desire engineering.” Over time, our initial guesses got better and better but they always needed some tweaking in the end.
- Analyze real-world usage/data— this allowed us to further optimize their process/workflow (read: cut more costs). I’m guessing this was why we managed to convince our clients to use the crude version early on.
- Progressively build a better version in a proper framework. Side note: We slowly abandoned Rails and went into Laravel simply because it’s faster to port the code from WP since they are both PHP.
- Again, some more back-and-forth. More site visits, tweaking, analyzing, other boring stuff.
That was just a real-world example of how I (we) used WaryPress for my old consultancy business. As you can see, we already planned out most of the stuff. In fact, we could just go straight into building in a framework — WaryPress was just used as a quick way to find UX and structural flaws in our initial plans. Your situation might be different.
Maybe you self-taught yourself WordPress but are not really technical. You can kinda code a bit but are not really good at it. Maybe you just want to quickly test the market and WWA seems like the easiest way to do it.
Or maybe you just want to make something that works to convince a programmer that you’re not just someone who talks about ideas but never actually does the work. Whatever. The point is WWA may be suitable for you if you’re already familiar with WordPress and can’t invest more resources (especially time) in learning a proper framework.
Reason 4: Simple Web Apps for Personal Use
…I’m already bored. I don’t think this one needs more elaboration, so…let’s move on, yeah?
Basic Overviews
I’m going to start with just basic overviews in this article since it’s getting way too long. Please read these first, and continue on via links at the bottom for more in-depth explanations as some of these may seem weird.
By the way, WaryPress is just another way, it’s not the way. Don’t feel forced to use all the suggestions in the guideline, take bits and pieces that are suitable for you, maybe add a little bit of salt, a little bit of pepper.
Series Summaries
Part 1: The Basic Convention
Use a new installation. If there is already an existing WordPress installation (like a blog), share existing users and login sessions.
Use pages and categories, but for URL purposes only (“routing”).
Create custom database tables. Do not store non-Wordpress data in the posts, post meta and user meta.
Make a new theme. The theme is the app. Put Composer in the theme. Commit under version control such as Git.
WP-Admin is inaccessible for everyone except for the Super Admin (you, the developer). The app is shown in the front-end.
Use bcrypt for password encryption.
# use in wp_config
define( ‘CUSTOM_USER_TABLE’, $table_prefix.’my_users’ );
define( ‘CUSTOM_USER_META_TABLE’, $table_prefix.’my_usermeta’ );
Part 2: Planning & Rough Sketches
Since WaryPress is geared towards beginners who want to make something that works with a low learning curve, let’s just do procedural code which I think should be easy to comprehend. Despite what people say, you can build apps with just procedural if you can manage to organize your code nicely.
Your users don’t care. What they care about is can your web app solve their problem? Can your web app make them more money? Can your web app simplify their lives? Will their sex lives improve?
Over time, please look into object-oriented programming. Procedural can turn into rancid spaghetti over time if not managed properly. Maybe start with classes first, and move your procedural functions into those classes.
Anyway, that’s far ahead. You don’t even know if you even like building web apps yet. For now, let’s focus on building something that can be used. Remember I said web app is not just about the code in Part 0? First let’s do a short thinking exercise on viability.
I want to use an example that is closely related to real-life usage for web apps, but still kinda weird enough that it sticks with you. Since WordPress is a content management system, or CMS for short, I thought it would be funny to build a cat management system, or CMS for short. I know, I’m hilarious.
Okay, first…what should it do? Wait. Cat management system? What? That doesn’t even make sense! Cats own you, you’re the one who should be managed! Did that joke land? No? Bummer.
Anyway, cat management system. Who is it for? Let’s see, maybe it’s for cat shelter volunteers. Then again, they are already swamped enough, I doubt they’d even want to use it. Never mind.
Personal cat management system? Why? I don’t even keep track of my cats on paper or even in my brain. Vaccinations and vet stuff are too few and far in between to warrant the help of a custom app — calendars work just fine.
Fine, let’s just do it for cat hotels. They have the money, they’re probably scrambling with data, accountability, etc with their paper systems. They probably want an easier way for tracking tasks, cat guests, memberships, etc. Eureka! There’s our web app idea*!
*I doubt it’s actually viable. It’s just a quick example because I’m already bored. In real life, you should ask around, do some market research first. Build something that solves your own problems, or if someone actually asks for something realistic and is willing to pay. Don’t build solutions for problems that are minuscule or don’t even exist.
However, since this is just an example, let’s go straight to sketching.
Basic UI
Basic data
Part 3: Start With The Interface
Making the WordPress theme that will house the app.
Folder/directory structures.
Bootstrap and jQuery.
Building the HTML templates.
Third-party Javascript libraries.
Maybe you can start with starter themes such as Underscores, I don’t know. I am more comfortable with making a theme from scratch.
Basic app tutorial.
Remember I said MVC-influenced folder structure in Part 0? To oversimplify things, there are supposed to be three folders:
/models/
/views/
/controllers/
However, we can’t really force MVC into a WordPress theme. Even WordPress itself is not MVC. I feel that naming folders as “Models”, “Views”, and “Controllers” would instill false information and cause confusion further down the line. The only thing that can be used is Views, but even that is not technically the V in MVC. Instead, let’s name them:
/database/ influenced by Models — for CRUD operations and table creation
/process/ influenced by Controllers — using /database/ to put data into /ui/
/ui/ influenced by Views — for building blocks of the user interface
Hey, I said MVC-influenced.
Optionally, let’s add another folder called /helpers/. Consider this a more organized functions.php. We’ll revisit that later.
Under /database/
includes.php
/create/
/update/
/read/
/delete/
# put in /ui/ folder
includes.php
/pages/
/components/
# put in /process/ folder
includes.php
/pages/
/helpers/
# use page.php and
# dont use wp-admin
# app views go outside
# hide admin bar
# use bootstrap and jquery at first
Part 4: Regarding The Data…
# you can migrate later easily with just database tables
# dont use meta, instead make specific tables
# use migration
# datatables
# chartjs
# adminer
Part 5: Performance & Security
# Use Laravel Forge and VPS.
# Don’t use caching plugins.
# Try to use a third-party web application firewall. If not, Wordfence should be good enough. Should be.
# Use underscores bcrypt.
# Use Redis if needed (Redis Object Cache plugin)
If this article receives a good amount of traffic, I will continue the series and elaborate more. Consider subscribing!