The first rule of WordPress: you do not hack the core.

RT @ryancduff: DO NOT HACK WORDPRESS CORE. I don't care if your life depends on it.. DO NOT HACK WORDPRESS CORE.— andrea_r (@andrea_r) June 11, 2012

When building a WordPress site, it’s strongly advised that you don’t change the core code and there are good reasons for that. The most obvious being once you edit the core code, you will no longer be able to update to the latest version of WordPress without your changes being overwritten, which severely limits maintainability. Given the open source nature of WordPress many of the updates involve security patches to fix vulnerabilities so being able to update should be a priority. Editing the core code could inadvertently create vulnerabilities as well. Luckily, there’s a way to add functionality without editing the core code.

WordPress offers flexibility in its ability to be extended by themes and plugins. The massive community-sourced collection of both means there’s a lot of options. One example is the Advanced Custom Fields plugin that provides an interface for adding new form fields of different types to the post form. Many other companies have integrated their services into WordPress in the form of a plugin such as Constant Contact, Freshbooks, Google Analytics, which make using those services much easier than manual integration. Plugins like these have brought WordPress a long way from its humble beginnings as simply a blogging platform but they do come with some considerations. While WordPress itself is created and maintained by professional developers at Automatic, as an open source platform there is no quality assurance for the code from third party vendors; this brings security and efficiency concerns. Also over time, plugins could become incompatible as the WordPress core continues to be updated so long-term maintenance is a consideration.

In many cases existing plugins and themes won’t cover the exact scenario you’re faced with and you’ll have to write your own. One question that comes up frequently is where to put your custom code: in the theme or the plugin. Tom McFarlin, a contributor to Smashing Magazine and a WordPress developer, created a great flowchart that shows how to answer that question simply.

Generally, if the feature alters the design or layout then it should be added to the theme; while if it’s adding functionality it should be made into a plugin, which is pretty straight forward. While writing your own themes and plugins removes the dependency on third party developers for updates, it puts the responsibility on you to maintain them and ensure compatibility with the latest iteration of WordPress.

Is WordPress the right CMS for you?

When starting any new project, lots of consideration goes into the build process and what tools can facilitate that process. One of the first decisions to make is what CMS, if any, to use and the answer inevitably is to use the best tool for the job. WordPress is a monolithic CMS that covers everything from front-end templating, routing, taxonomy, administrator dashboard, and database architecture to subtler things like cron job management. This is a great advantage when starting a project from scratch or rapidly prototyping an idea where you want to get into the customization right way without being bogged down with setting up your own CRUD interfaces, publishing workflow, templating system, etc. The dashboard lends itself to a typical content creation workflow with different roles for writing, editing, and approving content. The drawbacks of this reveal themselves when you try to change features that are integrated into the core of the CMS. Many times the only option is to hide something with CSS or to use JavaScript to override something in the DOM, and this tends to feel like more of a hack than a customization. As you try to push the boundaries beyond the original design, you will find yourself spending more time working around those limitations than implementing features. In this case WordPress wouldn’t be the best option.

Where is WordPress headed?

Many developers are adopting a relatively new trend of separating the front-end from the back-end known as decoupling. Decoupled WordPress essentially leaves the back-end and dashboard intact while ditching the standard front-end structures in favor of RESTful APIs that grant the option to use a different front-end framework such as Angular or ReactJS. This can be used to push the same data to several consumers at once such as native apps and multiple websites simultaneous, and it also lends more flexibility to the front-end design. While developers at WordPress seem to remain focused on the blogging and publishing aspects of the CMS, the community has been pushing more in the direction of a web framework, which has tangentially been touched on throughout this article.

Is WordPress a framework already?

Some would say yes while others claim it’s not quite there yet. Either way, the future for WordPress is bright and it will be exciting to see what direction it takes.