3 Big Things that Will Happen to WordPress in the Near Future

This opinion piece was contributed by guest author Peter Suhm. Peter is a web developer from the Land of the Danes. He is the creator of WP Pusher and a huge travel addict, bringing his work along with him as he goes.

Yet another WordPress prophecy

Okay, I admit that the title of this post is a bit risky. Honestly, it should probably have been “3 Big Things That I Wholeheartedly Hope Will Happen To WordPress In The Not Too Distant Future”. That being said, I am optimistic by nature, and I actually think these three ideas are realistic scenarios. So in all modesty, and without further ado, here is my take on some of the next big things to happen in the WordPress world in the near future.

WordPress Will Have Dependency Management

There is no question about it. WordPress needs some sort of dependency management mechanism. We have seen all other fragments of the PHP community, and other languages too, adopt the use of dependency managers. Most likely, WordPress will adopt Composer in some form, either out-of-the-box or by configuration.

What is a dependency manager?

A dependency manager is a software tool that can resolve and manage the dependencies (other libraries) that a given library requires. In PHP we have Composer. Each PHP library that supports Composer will have a defined set of dependencies that it depends on. The role of Composer is to fetch all these dependencies and make sure they are all compatible with each other.

… and why does WordPress need one?

WordPress needs one so we do not have to reinvent the wheel every time we want to make a new plugin or theme. Every time we write code for WordPress when we could have used one of the existing PHP packages out there, we are essentially wasting our time. Allowing the use of third-party dependencies allows for much more rapid development and better security. So many security issues in WordPress plugins are the same ones showing up again and again.

What does this mean for you?

In the short run, for plugin developers, WordPress adopting a dependency manager will mean a huge opportunity for making WordPress specific plugins for all the existing PHP libraries out there. When this happens, we will see hundreds, if not thousands, of plugins that will just be WordPress wrappers around existing libraries. Some of these plugins will end up becoming very popular. So be ready if you are an upcoming plugin author!

WordPress developers will probably also have to deal with some sort of frontend dependency manager, since, with the WP REST API, a lot of things will be revolutionized on the frontend side of things. We will touch more on that in the next section.

WordPress Will Be “Just” a Backend

This is not my idea, but I am certain this is the way we are moving. With the WP REST API in core, WordPress will essentially be a backend, complete with user management and so forth, for your API-based web application. Themes are going to be JavaScript based and will communicate with WordPress through the API. Plugins will stay mainly PHP, with a dash of JavaScript, just as the backend itself will.

I believe that a main reason for WordPress’ widespread success is the dashboard. It is extremely user friendly and intuitive. Add to that how simple and easy it is to add 3rd party plugins and themes and you have a winner. Extending core is also really trivial because of all the actions and filters that WordPress has built in. There is no way that the WP REST API is going to change this. It is simply adding an extra layer for frontend developers, and most likely, radically changing how we work with theming.

A few years ago, I worked as a full time Ruby on Rails developer. For one project, we needed some kind of CMS to manage the content of our Rails app. One of the developers (a hardcore Ruby guy) suggested using the WordPress dashboard as a backend and just build a simple API around it. We never ended up doing that, but imagine how easy that would be to implement had the API been around at the time.

What does this mean for you?

If you are a WordPress theme developer, this means that in the future you will probably not be a WordPress developer any more. You will “just” be a theme developer. You better up those JavaScript skills before this happens.

WordPress Will Become More Decoupled

As a result of all this, WordPress will become a lot more decoupled. Obviously, the biggest cut will be between the backend (dashboard and plugins) and the front end (themes). It is also easy to imagine, with an adaptation of Composer, that core itself will become a lot more decoupled. Maybe similar to how the Laravel framework is split up into the Illuminate packages (now we will have to define what “near future” means, though).

As already mentioned, the main component will be the dashboard. Plugins makes sense to keep as a part of the dashboard, but in the future, they might look more like WordPress-specific Composer packages. It makes sense to keep all this in PHP – of course with a bit of JavaScript here and there.

Another thing to consider is that if Composer is adopted in the near future, that would naturally mean an upgrade of the minimum required PHP version. That will probably happen very soon, anyways. We might see some sort of frontend plugins as well, but these will be JavaScript and be managed through a frontend dependency management tool.

What does this mean for you?

This means that if you are a WordPress plugin developer, you can keep writing good old PHP code. No need to jump straight over to NodeJS, yet, but if you are a theme developer, you might want to keep an eye on what those guys are up to.

It also means that WordPress is going to be much more decoupled and customizable. You will be able to pick the parts you need and skip the rest. If you need something different, you will most likely be able to find an existing PHP package that can do the job. Sounds good, right?

These are my 5 cents. I am curious to hear what you think. Where is WordPress headed?

Would you like to write for WP Tavern? We are always accepting guest posts from the community and are looking for new contributors. Get in touch with us and let's discuss your ideas.

Like this:

Related

28 Comments

In case near future is like 5 years or similar – then this title might be ok.
WordPress core team is sluggish in implementing such things – and they have reasons for that, no doubts.
Although (hopefully) REST API will be merged into core this year – that will be a really good boost.

Until Core wants to actually start using Composer as it’s actual package manager (and it would be an amazing thing), the link that Dwain posted is about as good as it will get using Composer and WordPress. Which I use on a daily basis, and it works fine. WP just becomes a dependency itself, instead of the app that uses Composer. But that works too, it makes WP very portable and easy to make clean installs of.

A shame since it’s something that would make including WordPress in a solution a little more straightforward. It’s once of those times where I think too much concern is given to end-user ease-of-use, or to backwards compatibility. I worry that attitude can hold back improvements.

Yeah, that’s a good approach, but it doesn’t solve the main issue. There’s no way to include 3rd party code in a public plugin. I mean, it’s possible, but can result in weird errors if two plugins rely on 2 different versions of the same dependency.

That’s an issue that Composer helps solve. Packages don’t need to specify an exact version, they can use quite a few different ways methods to specify anything within a major release, a minor release, or a point release. As long as the package that is being relied on follows semantic versioning (and most Composer packages do), then you should be reasonably safe in having Composer pick the best package version to install.

This is an issue that Composer helps solve, it doesn’t make it a problem. When installing WordPress plugins as Composer packages as well, multiple plugins can rely on a Composer package and that package only needs to be installed once. It’s a thing of beauty.

I would like to see more security precautions. WordPress has become very vulnerable to attacks and hacks. Most of our sites record over 2000 attacks with Brute Force Attack and Securi installed. Most of these sites don’t even have that many daily visitors. Why is this? Why is WordPress so open to these attacks? Surely it must be possible to have the core more protected without adding half a dozen plugins and modifications….

WordPress is a popular CMS and brute force attempts on login forms is an easy thing to do. This has zero to do with security in WordPress Core. Every login form gets bruteforced regardless of CMS be it Drupal, Joomla, some custom thing etc.

Andreas, I undetstand all of that, but for newbies with easy passwords it can be frustrating when their site is hacked. Development in this direction has been zero in the last ten years, even as you say yourself any idiot can hack a WordPress site.

As part of the install process, WordPress should require you to pick a new Admin username (which can’t be “Admin”) and a login page name (which can’t be wp-login.php — and the other backend pages would be renamed accordingly). Those are the two changes that make the most difference in the various security plugins, and it really should be standard practice enforced by WP itself upon initialization.

I couldn’t agree more that WP needs to start a major refactoring toward decoupling. I fully appreciate the massive number of existing users and code out there that cannot be simply dropped or broken, but WP cannot continue to hide its head in the sand about how brittle its codebase is.

A gradual refactoring while *educating* WP plugin/theme devs on using the new techniques is long overdue

One thing I’m hoping for is a feature-frozen (very) long-term release, to the tune of definitely over five years of support guaranteed, likely longer. No more changes or additions to features after a certain point, but maintained with all security patches (be they fixes or enhancements/hardenings) and bug fixes. For all of us who just want something that gets a simple (or less simple for some, but anyway) job done and keeps working smoothly.

“LTS” (Long Term Service) distros became popular in Linux. They were intended at first for (sniff) business-users, and other special-cases. Regular people of course caught on, and started flocking to LTS releases. The idea & practice is spreading far & wide.

Highly competitive sectors need to innovate and react rapidly. In part, they use a fast/frequent release schedule to do this. It lets them evolve & adapt. At this point, WordPress needs to give the appearance of competing with Drupal, which helps them feel like they are indeed competing/competitive. With the kind of dominance WP now has, any ‘competitor’ still alive has value, as insulation against monopoly-charges.

But WP does have real & good goals they want to achieve, and they may be fully-loaded, just trying to maintain momentum. Adding the burden to maintain (multiple) LTS, or modifying the current product so it makes an LTS version practical, could be more than WP can swing.
===

Note carefully that dependency-resolution (using PHP Composer, in this case) – a main topic here – strongly promotes release-stability and a more-conservative software paradigm, overall. It also isolates the system from its components, which helps with the kinds of things you want.

So going with the Composer-dependency innovation would tend to favor the prospects for an LTS WordPress. It sounds like an enormous step, though.

The Debian Linux distribution became the de facto Linux software repository, package manager, and verification/security gate-keeper. The Ubuntu Software Center eg is a frontend into the Debian Repo.

It is extremely important for the vast majority of Linux developers, that they get their stuff listed in the Repo asap, because the vast majority of stuff not in it, was actively rejected. If you aren’t Repo’d, the default assumption is there’s something bad-wrong.

Today, Linux wares are written with one eye on the Repo requirements. The easier & smoother for the Repo authorities, the sooner your new package becomes socially acceptable. Not everyone & everything not in the Repo is criminal; there are specific contexts & reason why a project will not have been vetted. But the worst is the default assumption, because it is mostly true.

The package manager systems in Linux let the user seamlessly install software from the Repo, while riding herd on all the dependencies. It’s a marvel. However, this dependency-management operates on the critical assumption that all the packages have been thoroughly shaken-down, are all compliant & consistent. That’s where all the work really is – whipping all those applications into proper shape, so the click-n-play Frontend can look like a genius.

It so happens that the Linux app-count, and the WordPress app-count (plugins and themes) have converged. You’re looking at roughly 45,000 for both systems. Apps in Linux are bigger, but they are mostly compiled. WP apps are mostly smaller, but many are spaghetti/omg-ware.

Vetting & proofing packages is the main work in keeping the Linux Repo viable. It is one of the largest & most-elite projects in the OSS world. Without this huge grunt-effort, any dependency-manager (including Composer) is just a GIGO-upgrade.

The job in prepping WordPress plugins and themes for dependency is of the same approximate magnitude as doing the same for the entire Linux operating system and all its applications. But then, Linux is a fabulous system, significantly because they make this effort.

Can WordPress address a challenge of this scope & scale?

From Dwain Maralack’s using-composer link, above:

So we’ve got WordPress installed and now we want to add some plugins. Thanks to composer-installers we can install them in the proper location right?

Yes, but we’re limited to plugins that have a composer.json, require composer-installers AND have their package type set correctly. Obviously there aren’t many plugins that actually do this yet. But you can find an example here.

In the Linux Repo, security has become official paranoia. Not only does the software have to be vetted – the vetters have to be vetted. The new system-layer that supports & enables dependency-resolution, also delivers new kinds of power to those entrusted with deploying it. There have been horror-stories. Safeguarding against misuse of the new powers will be another tough-nut, in the WordPress culture.

Composer, I understand why dependency management is important. In the same respect I understand marketing. Developer wise life could be easier. WordPress wise it does not open up lots of new plugins as pretty much every conceivable plugin has already been done. What it results in ultimately is further loss of product control by Automattic. I’d not do it.

XML/RPC API. This is nothing new. Its simply a transport mechanism where WP apparently has been behind the curve. Yes, its important so WP installs can communicate better across services. XML/RPC will have a rather short life in terms of technology. The transport mechanism’s console games have pioneered and will continue to refine are the future as they are binary, compressed, validated and deal with very complex datum in highly structured manners. The big question for PHP is can in handle it? Without multi-threading, no way. Its dead. Apache has no problem with it nor does IIs, Nginx, Linux, MS Server alonf with C#. PHP just does not have the umph without threading ability.

These digital transport (also secure transport) will be rearing their heads in 2-5 years. Which one becomes standard is very much up in the air right now. Since PHP developers keep their eyes on PHP they tend have no idea what is happening in the rest of the data technology universe. Sad but true.

Will WP become a data engine for other applications? Nope. Well… I cant say “nope”. I can say, perhaps some relatively focused things where no money or least money wants be spent. Categories, text data in two formats and limited other capabilities along with procedural code doom it from whats coming in complex web applications. Again, people forget, PC/Mac OS are going as online operating systems. That means computers and devices become smart clients. Can you make Quickbooks online with WordPress? No. Can you make Halo online with WordPress. No.

As a “Framework” engine it cannot suit general purpose complex tasking. Symfony can. Its slower than snail snot. Again, no multiple thread ability within PHP and a general structure of how Object Oriented Code is managed by PHP are BIG hang ups as other languages and frameworks provide faster processings, smaller resource footprints and from word go were created for the tasks suited. This is why managed C# is now 300% faster than PHP. Mono is more capable and faster than any PHP framework going and happily runs under Linux or Mac OS as well.

WP is not ideal for a backend data service platform at least now. It’d take a ton of change to get there and in doing so would probably break its base usage now. Joomla thought similar, J! framework, J! CMS. Done nothing for them and J! framework is really good code, much more advanced actually albeit slower.

So I disagree, all fronts.

Automattic has a tremendous marketshare right now. The best move IMHO is sealing it. Making sure that it stays there and grows. Again IMHO that requires a restructure of its public assets to run more like a business and product (the volunteer scene) and towards not leaving the door wide open for others to exploit several really apparent weaknesses to anyone who’s worked for “the sharks” in business and either get put asunder, bought out, or loosing the development community wordpress enjoys.

There are clearly people who have WordPress Community best interests at heart but with a community of 200,000,000 installs are not the right people in the right places.

Okay, people have been pondering, how does WordPress do it? I have to ask what does WordPress do? Have we forgotten the people who use WP for blogging? Have we forgotten how many people use WP to blog? Is WordPress leaving blogging behind?

One thing I’d like to see is closer cooperation with the W3C people, especially where CSS is concerned. Why. Because there are functions in CSS3 that are not being handled at all in WordPress.(I’ve got a demo blog to set up to illustrate a part of what I’m talking about)

My goal is to see that our readers get something that looks good, and is a pleasure to read.

Seems to me that the very idea that the WP backend will be decoupled from regular theme/templating is the reason for the delay in integrating the API into core. It means a lot to wordpress.com which is where a lot of money is.