There’s a lot to love about content management systems, or CMS. Maybe it’s the streamlined web design process: The website builders, themes, and no coding knowledge needed for any of it. Maybe it’s all those nifty plugins that can pull off technical features you’d have no idea where to begin with. But if WordPress just isn’t cutting it, what can you do?
Luckily, there are dozens of quality CMS and website builders out there that can potentially take WordPress’ place, depending on you and your clients’ needs. We’ve collected a few of them below.
Craft’s single best feature is that it’s intuitive – both for you and your clients. WordPress can be difficult to get the hang of and even harder to customize due to its API. But Craft starts with nothing and allows you to add pieces as you need them. Third-party themes and plugins are there too!
The only trouble is the price tag. This is not something you want if you’re working with small projects. But give the free version a spin on your own time and see if it’s something you’d enjoy working with.
Need all the benefits of a CMS without having to deal with one during the design process? Create your website first and foremost, then add Perch to it later. Your clients get the simple interface and you get to design the site yourself.
Webflow was built as a comprehensive tool for freelance web designers. Design a site without ever touching code, build it with a CMS, and deploy to your clients with hosting available right from Webflow. It works great for small design teams, too!
Bolt CMS is defined by its simplicity. The code is simple and not bogged down with features you don’t need – but they’re easily added if you want them. This CMS use Twig to craft templates, so you can code them yourself from scratch. And editing the sites you create is super easy. No more frustrated clients! Plus, the platform is free and open source.
If your biggest woe with WordPress is the difficult installation process, Kirby might be what you’re looking for. It’s lightweight and super easy to set up on a server. No more 5000-step installation guides. There are no databases to contend with and the admin panel is reasonably client-friendly too. Kirby, however, is best for designers who can do some coding in PHP.
Drupal is not easy to learn as a web designer, especially if you’re used to WordPress. However, when you need a CMS that is capable of running websites that WordPress can’t, Drupal is the go-to option. It has a large following, a ton of modules, and way more advanced functionality. If you’re building simple, static websites, another CMS may be the best choice. But if you found WordPress not powerful enough, try Drupal.
While Squarespace offers drastically less flexibility compared to WordPress, it is considerably more client-friendly, as well as less prone to bugs and incompatibilities. The hosted service is not particularly expensive, either. Once you’ve created three websites for clients, Squarespace Circle becomes open to you. The circle can be a great opportunity to get your name out there and collaborate with other designers.
WordPress isn’t the only CMS!
For web designers, there’s always another option. Many feel they can’t pass up WordPress with all its popularity, but these platforms are a great alternative. There’s something for all the theme developers and web designers out there who definitely need a CMS, but no longer want to use WordPress. This list is just the tip of the iceberg!
Single Page Apps (SPA) have grown in popularity due to their ability to deliver dynamic user experiences, like those you would expect from a mobile or desktop application, quickly and easily. While SPAs are great from a user perspective, they can be a bit more challenging for your editors to make content changes and updates.
Simplicity is a funny adjective in web design and development. I'm sure it's a quoted goal for just about every project ever done. Nobody walks into a kickoff meeting like, "Hey team, design something complicated for me. Oh, and make sure the implementation is convoluted as well. Over-engineer that sucker, would ya?"
Of course they want simple. Everybody wants simple. We want simple designs because simple means our customers will understand it and like it. We want simplicity in development. Nobody dreams of going to work to spend all day wrapping their head around a complex system to fix one bug.
Still, there is plenty to talk about when it comes to simplicity. It would be very hard to argue that web development has gotten simpler over the years. As such, the word has lately been on the tongues of many web designers and developers. Let's take a meandering waltz through what other people have to say about simplicity.
Bridget Stewart recalls a frustrating battle against over-engineering in "A Simpler Web: I Concur." After being hired as an expert in UI implementation and given the task of getting a video to play on a click...
I looked under the hood and got lost in all the looping functions and the variables and couldn't figure out what the code was supposed to do. I couldn't find any HTML <video> being referenced. I couldn't see where a link or a button might be generated. I was lost.
I asked him to explain what the functions were doing so I could help figure out what could be the cause, because the browser can play video without much prodding. Instead of successfully getting me to understand what he had built, he argued with me about whether or not it was even possible to do. I tried, at first calmly, to explain to him I had done it many times before in my previous job, so I was absolutely certain it could be done. As he continued to refuse my explanation, things got heated. When I was done yelling at him (not the most professional way to conduct myself, I know), I returned to my work area and fired up a branch of the repo to implement it. 20 minutes later, I had it working.
It sounds like the main problem here is that the dude was a territorial dingus, but also his complicated approach literally stood in the way of getting work done.
Simplicity on the web often times means letting the browser do things for us. How many times have you seen a complex re-engineering of a select menu not be as usable or accessible as a <select>?
Eminently usable designs and architectures result when simplicity is the default. It's why unadorned HTML works. It beautifully solves the problem of presenting documents to the screen that we don't even consider all the careful thought that went into the user agent stylesheets that provide its utterly boring presentation. We can take a lesson from this, especially during a time when more websites are consumed as web apps, and make them more resilient by adhering to semantics and native web technologies.
My guess is the rise of static site generators — and sites that find a way to get as much server-rendered as possible — is a symptom of the industry yearning for that brand of resilience.
... we need to try to do as little as possible when we build the future web.
This isn’t a rationalization for laziness or shirking responsibility—those characteristics are arguably not ones you’d find in successful web devs. Nor it is a suggestion that we build bland, homogeneous sites and apps that sacrifice all nuance or spark to the Greater Good of total compatibility.
Instead it is an appeal for simplicity and elegance: putting commonality first, approaching differentiation carefully, and advocating for consistency in the creation and application of web standards.
Should we find our way to something simpler, something more accessible?
I think we can. By simplifying our sites we achieve greater reach, better performance, and more reliable conveying of the information which is at the core of any website. I think we are seeing this in the uptick of passionate conversations around user experience, but it cannot stop with the UX team. Developers need to take ownership for the complexity they add to the Web.
It's good to remember that the complexity we layer onto building websites is opt-in. We often do it for good reason, but it's possible not to. Garrett Dimon:
You can build a robust, reliable, and fully responsive web application today using only semantic HTML on the front-end. No images. No CSS. No JavaScript. It’s entirely possible. It will work in every modern browser. It will be straightforward to maintain. It may not fit the standard definition of beauty as far as web experiences go, but it will work. In many cases, it will be more usable and accessible than those built with modern front-end frameworks.
That’s not to say that this is the best approach, but it’s a good reminder that the web works by default without all of our additional layers. When we add those additional layers, things break. Or, if we neglect good markup and CSS to begin with, we start out with something that’s already broken and then spend time trying to make it work again.
We assume that complex problems always require complex solutions. We try to solve complexity by inventing tools and technologies to address a problem; but in the process, we create another layer of complexity that, in turn, causes its own set of issues.
Perhaps the worst reason to choose a complex solution is that it's new, and the newness makes it feel like choosing it makes you on top of technology and doing your job well. Old and boring may just what you need to do your job well.
“Boring” should not be conflated with “bad.” There is technology out there that is both boring and bad. You should not use any of that. But there are many choices of technology that are boring and good, or at least good enough. MySQL is boring. Postgres is boring. PHP is boring. Python is boring. Memcached is boring. Squid is boring. Cron is boring.
The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood.
You're going to hear less about old and boring technology. If you're consuming a healthy diet of tech news, you probably won't read many blog posts about old and boring technology. It's too bad really, I, for one, would enjoy that. But I get it, publications need to have fresh writing and writers are less excited about topics that have been well-trod over decades.
As David DeSandro says, "New tech gets chatter". When there is little to say, you just don't say it.
You don't hear about TextMate because TextMate is old. What would I tweet? Still using TextMate. Still good.
While we hear more about new tech, it's old tech that is more well known, including what it's bad at. If newer tech, perhaps more complicated tech, is needed because it solves a known pain point, that's great, but when it doesn't...
You are perfectly okay to stick with what works for you. The more you use something, the clearer its pain points become. Try new technologies when you're ready to address those pain points. Don't feel obligated to change your workflow because of chatter. New tech gets chatter, but that doesn't make it any better.
I have a confession to make — I’m not a rock star programmer. Nor am I a hacker. I don’t know ninjutsu. Nobody has ever called me a wizard.
Still, I take pride in the fact that I’m a good, solid programmer.
Complexity isn't an enemy. Complexity is valuable. If what we work on had no complexity, it would worth far less, as there would be nothing slowing down the competition. Our job is complexity. Or rather, our job is managing the level of complexity so it's valuable while still manageable.
Santi Metz has a great article digging into various aspects of this, part of which is about considering how much complicated code needs to change:
We abhor complication, but if the code never changes, it's not costing us money.
Your CMS might be extremely complicated under the hood, but if you never touch that, who cares. But if your CMS limits what you're able to do, and you spend a lot of time fighting it, that complexity matters a lot.
It's satisfying to read Sandi's analysis that it's possible to predict where code breaks, and those points are defined by complexity. "Outlier classes" (parts of a code base that cause the most problems) can be identified without even seeing the code base:
I'm not familiar with the source code for these apps, but sight unseen I feel confident making a few predictions about the outlying classes. I suspect that they:
The boring designer is trusted and valued because people know they’re in it for the product and the user. The boring designer asks questions and leans on others’ experience and expertise, creating even more trust over time. They rarely assume they know the answer.
The boring designer is capable of being one of the best leaders a team can have.
Little confession here: when I first saw Netlify CMS at a glance, I thought: cool, maybe I'll try that someday when I'm exploring CMSs for a new project. Then as I looked at it with fresh eyes: I can already use this! It's a true CMS in that it adds a content management UI on top of any static site generator that works from flat files! Think of how you might build a site from markdown files with Gatsby, Jekyll, Hugo, Middleman, etc. You can create and edit Markdown files and the site's build process runs and the site is created.
Netlify CMS gives you (or anyone you set it up for) a way to create/edit those Markdown files without having to use a code editor or know about Pull Requests on GitHub or anything. It's a little in-browser app that gives you a UI and does the file manipulation and Git stuff behind the scenes.
It's on GitHub, so it's open to Pull Requests, and each conference is a Markdown file.
That's pretty cool already. The community has contributed 77 Pull Requests already really fleshing out the content of the site, and the design, accessibility, and features as well!
I used 11ty to build the site, which works great with building out those Markdown files into a site, using Nunjucks templates. Very satisfying combo, I found, after a slight mostly configuration-related learning curve.
Enter Netlify CMS.
But as comfortable as you or I might be with a quick code edit and Pull Request, not everybody is. And even I have to agree that going to a URL quick, editing some copy in input fields, and clicking a save button is the easiest possible way to manage content.
That CMS UI is exactly what Netlify CMS gives you. Wanna see the entire commit for adding Netlify CMS?
It's two files! That still kinda blows my mind. It's a little SPA React app that's entirely configurable with one file.
Cutting to the chase here, once it is installed, I now have a totally customized UI for editing the conferences on the site available right on the production site.
Netlify CMS doesn't do anything forceful or weird, like attempt to edit the HTML on the production site directly. It works right into the workflow in the same exact way that you would if you were editing files in a code editor and committing in Git.
Auth & Git
You use Netlify CMS on your production site, which means you need authentication so that just you (and the people you want) have access to it. Netlify Identity makes that a snap. You just flip it on from your Netlify settings and it works.
I activated GitHub Auth so I could make logging in one-click for me.
The Git magic happens through a technology called Git Gateway. You don't have to understand it (I don't really), you just enable it in Netlify as part of Netlify Identity, and it forms the connection between your site and the Git repository.
Now when you create/edit content, actual Markdown files are created and edited (and whatever else is involved, like images!) and the change happens right in the Git repository.
I made this the footer of the site cause heck yeah.
A Detailed Comparison Between WordPress And October CMS
A Detailed Comparison Between WordPress And October CMS
Leonardo Losoviz
Three months ago, WordPress finally released React-powered Gutenberg to power its default content editing experience, triggering many people who are not happy with this change to look for alternatives. Some folks decided to fork and release pre-Gutenberg WordPress, however, for me this doesn’t make much sense since it still carries 15 years worth of technical debt. If I were to find an alternative to WordPress, I would try to avoid being stuck in the past, and aim for a clean cut through some mature platform built on modern foundations.
This article compares WordPress to the arguably similar yet more modern October CMS on a wide arrange of both technical and non-technical topics. The goal of the article is not to convince people to stick to WordPress or to switch to October CMS, but simply to demonstrate what aspects must be taken into account before concluding the move to a different platform. The same comparison could (and should) also be done with other platforms before making a sensible decision.
Why October CMS
I found out about October CMS when it won an award, after which I went into research mode and spent a good deal of time digging deep into this CMS — from the perspective of both a user and a developer. As I gained knowledge on this CMS, I felt confident that I could provide an objective evaluation of its features as contrasted to WordPress. I chose this CMS for the comparison over alternative options such as Grav, Statamic, ButterCMS, Joomla, Drupal, Jekyll, Hugo, and others, for the following reasons:
I know how this CMS works (unlike Grav);
It is free and open source (unlike Statamic and ButterCMS);
At five years, it is “relatively” new (unlike Joomla and Drupal);
It is a dynamic (not static) content generator and based in PHP (unlike Jekyll and Hugo).
I believe that October CMS is a good candidate because it is based on Laravel which is a framework used for building modern applications. After seven years of existence, it has received positive approval from developers (as evidenced by its sizeable community and ecosystem), and marks a distinct contrast over coding in WordPress, i.e. WordPress is mostly procedural programming while Laravel is decidedly object-oriented programming.
What’s The Difference Between The Two?
Below I will compare WordPress and October CMS on different categories and highlight what, I believe, is good and not so good about them. However, I will not pick a winner, since that’s not the objective of the article and, in any case, there is no “best” or even “better” CMS: each CMS has its own set of strengths and weaknesses that will make it more or less suitable for each task, project, company, team, and anything else. Moreover, a project may benefit from using more than one CMS, such as using some CMS to manage and provide data, and another CMS to render the view. To decide which of the dozens of CMSs out there is most suitable for your own needs is entirely up to you.
In addition, this article could never draw definitive conclusions since it is only concerned with a subset of all possibilities. For instance, we can also find online comparisons such as “WordPress vs Drupal vs Joomla”, “WordPress vs Static Site Generators” and even “WordPress vs Medium”. Because none of these articles sees the full picture, then none of these comparisons can ever be conclusive, and should not be treated as such.
Let’s start with the comparison.
Philosophy And Target Group
It is no coincidence that WordPress powers nearly 1 in 3 websites. Ever since its inception, it has strived to be extremely user-friendly and has done so successfully, removing friction for technical and non-technical users alike as well as for people from all backgrounds — irrespective of their education and economic levels. WordPress’ founder Matt Mullenweg expressed that WordPress’ motto of “Democratize Publishing” for the current era meant the following:
“People of all backgrounds, interests, and abilities should be able to access Free-as-in-speech software that empowers them to express themselves on the open web and to own their content.”
WordPress is easy to use for everyone and its inclusivity is evidenced on the development side too: It’s not uncommon to find people without a programming background (such as marketers, designers, bloggers, sales people, and others) tinkering with their WordPress installations, designing their own themes and successfully launching their own websites. WordPress is user-centric, and the needs of the users trump those of the developers. In WordPress, the user is king (or queen).
“October makes one bold but obvious assumption: clients don’t build websites, developers do. The role of a client is to manage the website and convey their business requirements. The web developer, and the industry itself, revolves around mediating these factors.”
In the words of its founders, the CMS’ mission is to “prove that making websites is not rocket science.” Being based on Laravel, October CMS can claim to have strong foundations of reusable, modular code that can produce properly-architected applications, maintainable in the long term and fully customizable without requiring hacks — the type which attracts serious programmers. October CMS can also provide a great user experience, however, it is not as simple or frictionless as that provided by WordPress. Users may need to be explained how to use certain functionality before being able to use it. For instance, embedding a form from some plugin has a lengthy explanation on how to do it, which is more cumbersome than the self-evident, drag-and-drop functionality provided by several form plugins in WordPress.
Installation
WordPress is famous for its 5-minute installation, even though many people point out that (taking into consideration all the plugins that must be installed) a typical installation requires 15 minutes or more. In addition, WordPress also offers the Multisite feature, which allows us to create a network of multiple virtual sites under a single installation. This feature makes it easy for an agency to administer the sites of multiple clients — among other user cases.
Installing October CMS is also very smooth: The Wizard installation itself takes even less than five minutes, and if you install it through the Console installation, it is even faster. You can do the latter by simply navigating to the target directory and then executing curl -s https://octobercms.com/api/installer | php (after which we need to input the database configuration, otherwise it behaves as a flat-file CMS). Once the installation has been completed, we will have a fully functioning website, but still quite bare (if you add the time needed to install and configure the required plugins, you can expect it to take at least 15 minutes).
Installing October CMS with the Wizard is a breeze. (Large preview)
Security
WordPress has been accused of being insecure due to the high amount of vulnerabilities that are constantly found. This forces users to have the software for the CMS and all installed plugins always up to date to avoid security exploits. Among the main issues is WordPress’ support for older versions of PHP which are not supported by the PHP development community anymore (WordPress currently supports PHP 5.2.4, while the latest fully supported PHP version is 5.6). However, this problem should be resolved in April 2019 when WordPress will officially start supporting PHP versions 5.6 and upwards.
Otherwise, WordPress is not necessarily insecure because of itself, but because of its high popularity, which makes it a primal target for hackers. However, this plays both ways: WordPress ubiquity means that its security team must really take their job seriously by constantly looking for exploits and fixing them as soon as possible, otherwise up to a third of the web is at risk. The stakes are just too high.
October CMS, on the other hand, doesn’t have a reputation of being insecure. However, since there are roughly 27,000 live sites that use October as compared with WordPress’ millions, we can’t judge the two of them on the same terms. Nevertheless, the team behind October CMS does take security seriously, as evidenced by the Wizard installation’s prompt to input the CMS backend URL, set as /backend by default but changeable to anything else, as to make it more difficult for hackers to target the site. In contrast, changing WordPress’ login and backend URLs from /wp-login.php and /wp-admin respectively to something else must be done through a plugin. In addition, October CMS can function as a flat-file CMS (i.e. without a database) and avoid database-related vulnerabilities such as SQL injection.
Technology Stack
Both WordPress and October CMS run on the traditional LAMP stack: Linux, Apache, MySQL, and PHP. (However, only PHP is fixed: we can also use Windows, Nginx, MariaDB, and others.) October CMS can also behave as a flat-file CMS, meaning that it can do without a database, however, at the cost of forgoing many functionalities (such as blog posts and users) the only functionality that is guaranteed is pages, which is considered to be the basic unit for the creation and publishing of content and shipped as a core feature.
Concerning the language stack, sites built with both WordPress and October CMS are based on HTML, CSS, and JavaScript (note that PHP is used to generate the HTML). October CMS also makes it easy to use LESS and SASS files.
Programming Paradigm
WordPress follows a functional programming paradigm, based on calculating computations by calling functions devoid of application state. Even though WordPress developers do not need to stick to functional programming (for instance, for coding their themes and plugins), the WordPress core code inherits this paradigm from 15 years of preserving backwards compatibility, which has been one of the pillars to WordPress’ success but which has the unintended consequence of accumulating technical debt.
Programming in WordPress could be characterized as HDD which stands for “Hook-Driven Development”. A hook is a mechanism that allows changing a default behavior or value and allowing other code to execute related functionality. Hooks are triggered through “actions” which allow executing extra functionality, and “filters” that allow modifying values.
Hooks, which are widespread across the WordPress codebase, are one of the concepts that I most like from coding in WordPress. They allow plugins to interact with other plugins (or with a core or theme) in a clean way, providing some basic support of Aspect-Oriented Programming.
Good news is that Laravel (and in consequence October CMS) also supports the concept of hooks, which is called “events”. Events provide a simple observer implementation, enabling code to subscribe and listen for events that occur in the application and react as needed. Events make it possible to split a complex functionality into components, which can be installed independently yet collaborate with each other, thus enabling the creation of modular applications.
Dependence on JavaScript Libraries
The latest version of WordPress incorporates React-powered Gutenberg for its default content creation experience. Hence, WordPress development now relies by and large on JavaScript (predominantly through React), even though it is also possible to use other frameworks or libraries (as evidenced by Elementor Blocks for Gutenberg which is based on Marionette). In addition, WordPress still relies on Backbone.js (for the Media Manager) and jQuery (legacy code), however, we can expect the dependence on these libraries to wither away as Gutenberg is consolidated as the new norm.
October CMS depends on jQuery, which it uses to implement its optional AJAX framework to load data from the server without a browser page refresh.
Pages, Themes and Plugins
Both WordPress and October CMS treat a page as the basic unit for creating and publishing content (in WordPress case, in addition to the post), support changing the site’s look and feel through themes, and allow to install and extend the site’s functionalities through plugins. Even though the concepts are the same in both CMSs, there are a few differences in implementation that produce somewhat different behavior.
In WordPress, pages are defined as content and stored in the database. As a result, page content can be created through the CMS only (e.g. in the dashboard area), and switching from one theme to another doesn’t make an existing page become unavailable. This produces an overall frictionless experience.
In October CMS, on the other hand, pages are static files stored under the theme directory. On the positive side from this architectural decision, page content can be created from an external application, such as text editors like Sublime or Visual Studio Code. On the negative side, when switching from one theme to another, it is required to manually recreate or copy the pages from the current to the new theme, or otherwise, they will disappear.
Significantly, October CMS resolves routing through pages, hence pages are used not just as containers for content but also for functionality. For instance, a plugin for blogging depends on a page for displaying the list of blog posts under a chosen URL, another page to display a single blog post under another chosen URL, and so on. If any of these pages disappear, the associated functionality from the plugin becomes unavailable, and that URL will produce a 404. Hence, in October CMS themes and plugins are not thoroughly decoupled, and switching themes must be done carefully.
October CMS enables the creation of content from external applications. (Large preview)
Core vs Plugin Functionality
WordPress attempts to deliver a minimal core functionality which is enhanced through plugins. WordPress relies on the “80⁄20 rule” to decide if to include some functionality in its core experience or not. If it benefits 80% of the users it goes in, otherwise, it belongs to plugin-land. When adding plugins to a site, they can lead to bloat if too many plugins are installed. Plugins may also not work well with one another, or execute similar code or load similar assets, resulting in suboptimal performance. Hence, whereas launching a WordPress site is relatively easy, a bigger challenge is its general maintenance and being able to preserve an optimal and performant state when adding new features.
The WordPress plugin directory claims to have almost 55,000 plugins. (Large preview)
Likewise, October CMS also attempts to deliver a minimal core functionality, but on steroids: the only guaranteed functionality is the creation and publication of pages, and for everything else we will need to install one plugin or another, which is expressed as:
“Everything you need, and nothing you don't.”
The objective is clear: most simple sites are only composed of pages, with possibly no blog posts, users or login area. So why should the application load resources for these when they are not needed? As a consequence, functionalities for blogging, user management, translation and several others are released through the plugin directory.
Searching for 'Rainlab' in October’s plugins directory displays plugins created by October CMS' team. (Large preview)
October CMS also includes certain features in its core which (even though they are not always needed) can enhance the application significantly. For instance, it provides out-of-the-box support to upload media files to Amazon S3 and accesses them through the Rackspace CDN. It also includes a Media Manager which is mostly used through plugins, e.g. for adding images into a blog post. (Pages can also use the Media Manager to embed media files, however, the CMS also ships with an Assets section to upload media files for these which seems more suitable.)
I believe that October’s opinionatedness can perfectly enable us to produce an application that is as lean as possible — mostly concerning simple sites. However, it can also backfire and encourage bloat, because the line of what is needed and what is not is an arbitrary one, and it’s difficult to be set in advance by the CMS. This difficulty can be appreciated when considering the concept of a “user”: In WordPress, website users and website admins belong to the same user entity (and through roles and privileges we can make a user become an admin). In October CMS, these two are implemented separately, shipping in core the implementation for the website administrator which can log in to the backend area and modify the settings, and through a plugin the implementation of the website user. These two types of users have a different login process and a different database table for storing their data, thus arguably breaching the DRY (Don’t Repeat Yourself) principle.
This problem arises not only concerning the behavior of an entity but also what data fields it must contain. For instance, should the website user data fields be predefined? Is a telephone field required? What about an Instagram URL field, considering that Instagram got kind of cool only recently? But then, when building a professional website shouldn’t we use a LinkedIn URL field instead? These decisions clearly depend on the application and can’t be decided by either CMS or plugin.
The October CMS plugin called User implements users but without any user field, on top of which plugin User Plus adds several arbitrary user fields, which are possibly not enough, so plugin User Plus+ adds yet other user fields. When, where and how do we stop this process?
Another problem is when there is no room to add new capabilities to an entity, which leads to the creation of another, extremely similar entity, just to support those required capabilities. For instance, October CMS ships with pages, and allows to create “static pages” through a plugin. Their nature is the same: both pages and static pages are saved as static files. The only difference between them (as far as I can tell) is that static pages are edited with a visual editor instead of the HTML editor, and can be added to menus. In my opinion, only structural differences, such as having one entity saved as a static file and the other one stored in the database, could justify creating a second entity for a page (there is a pull request to do this), but for simple features, as is the case currently, it constitutes development bloat.
In summary, a well implemented October CMS application can be very lean and efficient (e.g. by removing the database when not needed), but on the contrary it can also become unnecessarily bloated, forcing developers to implement several solutions for similar entities, and which can be very confusing to use (“Should I use a page or a static page?”). Because neither WordPress or October CMS has found a perfect solution for removing bloat, we must design either application architecture with care to avoid down-the-road pain.
Content Creation
Gutenberg makes two important contributions to WordPress: It uses components as the unit for building sites (which offers several advantages over coding blobs of HTML), and it introduces an entity called a “block” which, once Gutenberg Phase 2 is completed (presumably in 2019), will provide a unified way to incorporate content into the site, thus enabling a simpler user experience as opposed to the more chaotic process of adding content through shortcodes, TinyMCE buttons, menus, widgets, and others.
Since WordPress 5.0 Gutenberg is the default content creation experience. (Large preview)
Because Gutenberg blocks can produce and save static HTML as part of the blog post, then installing many Gutenberg blocks doesn’t necessarily translate into bloat on the website on the user side, but can be kept restricted to the admin side. Hence, Gutenberg can arguably be considered a good approach to produce websites in a modular way, with a simple yet powerful user experience for creating content. Possibly the biggest drawback is the (unavoidable, but not easily so) requirement to learn React, whose learning curve is rather steep.
If React components are the basic unit for creating content in WordPress, October CMS is based on the premise that knowing good old HTML is enough for building sites. Indeed, when creating a page, we are simply presented an HTML (Markup) editor:
If the page were solely static HTML, then there would be no need for a CMS. Instead, October CMS pages are written using Twig templates which are compiled to plain optimized PHP code. They can select a layout to include the scaffolding of the page (i.e. repetitive elements, such as the header, footer, and so on), can implement placeholders, which are defined on the layout to allow the page to customize content, and can include partials, which are reusable chunks of code. In addition, pages can include content blocks, which are either text, HTML or Markdown files that can be edited on their own and can attach components which are functionalities implemented through plugins. And finally, for whenever HTML is not enough and we need to produce dynamic code, we can add PHP functions.
The editor is all about HTML. There is no TinyMCE textarea for adding content in a visual manner — at least not through the default experience (this functionality belongs to plugin-land). Hence, having knowledge of HTML could be considered a must for using October CMS. In addition, the several different inputs for creating content (pages, layouts, placeholders, partials, content blocks, components, and PHP functions) may be very effective, however, it is certainly not as simple as through the unified block interface from WordPress. It can even get more complex since other elements can also be added (such as static pages and menus, and snippets), and some of them, such as pages and static pages, seemingly provide the same functionality, making it confusing to decide when to use one or the other.
As a result, I dare say that while pretty much anyone can use a WordPress site from the admin side, October CMS is more developer-friendly than non-technical user-friendly, so programmers may find it a joy to use, but certain other roles (marketers, sales people, and the like) may find it non-intuitive.
Media Manager
Both WordPress and October CMS are shipped with a Media Manager which allows adding media files to the site effortlessly, supporting the addition of multiple files simultaneously through a drag-and-drop interface and displaying the images within the content area. They look and behave similarly; the only notable differences I found are that WordPress’ Media Manager allows to embed image galleries, and October’s Media Manager allows to manually create a folder structure where to place the uploaded files.
October CMS ships with a powerful Media Manager. (Large preview)
Since the introduction of Gutenberg, though, WordPress’ media capabilities have been enhanced greatly, enabling to embed videos, pictures and photo galleries in place as compared to within a TinyMCE textarea (which only provides a non-accurate version of how it will look like in the site), and unlocking powerful, yet easy-to-use features as shown in this video.
Internationalization
WordPress core uses gettext to enable the translation of themes and plugins. Starting from a .pot file containing all strings to translate, we need to create a .po file containing their translation to the corresponding language/locale, and this file is then compiled to a binary .mo file suitable for fast translation extraction. Tools to perform these tasks include GlotPress (online) and Poedit (downloadable application). Conveniently, this mechanism also works for client-side localization for Gutenberg.
Poedit allows to translate strings for themes and plugins for WordPress. (Large preview)
WordPress currently doesn’t ship any solution in core to translate content, and will not do so until Phase 4 of Gutenberg (targeted for year 2020+). Until then, this functionality is provided by plugins which offer different strategies for storing and managing the translated content. For example, while plugins such as Polylang and WPML store each translation on its own row from a custom database table (which is clean since it doesn’t mix content together, but slower since it requires an additional INNER JOIN of two tables when querying the database), plugin qTranslate X stores all translations on the same field from the original database table (faster for querying the data, but content mixed all together can produce wreckage on the site if disabling the plugin). Hence, we can shop around and decide the most suitable strategy for our needs.
October CMS doesn’t ship the multilingual functionality through its core, but as a plugin created by the October CMS team that guarantees a faultless integration into the system. From a functional point of view, this plugin delivers what it promises. From a development point of view, it is not quite ideal how this plugin actually works. In WordPress, a page is simply a post with post type “page” and there is a single translation mechanism for them, but in October CMS, there are entities “page”, “static page” and “blog post” and, even though quite similar, they require three different implementations for their translations! Then, the content from a “page” can include message codes (e.g. codes called nav.content, header.title, and so on), each of which contains its translations for all locales as a serialized JSON object in database table rainlab_translate_messages. The content from a “static page” is created into a new static file per locale, however, all translated URLs for all locales are stored not in their corresponding file but instead on the default language’s file. The content for the “blog post” is stored as a serialized JSON object with one row per locale in database table rainlab_translate_attributes and the translated URL is stored with one row per locale in database table rainlab_translate_indexes. I don’t know if this complexity is due to how the plugin was implemented or whether it is due to October CMS’ architecture. Whichever the case, this is another instance of undesired bloat on the development side.
Plugin Management
Both WordPress and October CMS offer a sophisticated plugin manager which allows to search for plugins, install new plugins, and update currently-installed plugins to their latest version — all from within the backend.
October CMS enables to keep all plugins up-to-date effortlessly. (Large preview)
Dependency Management
October CMS uses Composer as the package manager of choice, enabling plugins to download and install their dependencies when being installed, thus delivering a painless experience.
WordPress, on the opposite side, hasn’t officially adopted Composer (or any PHP dependency manager) because the community can’t agree if WordPress is a site or a site dependency. Hence, if they require Composer for their projects, developers must add it on their own. With the switch to Gutenberg, npm has become the preferred JavaScript dependency manager, with a popular developer toolkit depending on it, and the client-side libraries being steadily released as autonomous packages in the npm registry.
Interaction With The Database
WordPress provides functions to retrieve database data (such as get_posts) and store it (such as wp_insert_post and wp_update_post). When retrieving data, we can pass parameters to filter, limit and order the results, in order to indicate if the result must be passed as an instance of a class or as an array of properties and others. When the function doesn’t fully satisfy our requirements (e.g. when we need to do an INNER JOIN with a custom table) then we can query the database directly through global variable $wpdb. When creating a plugin with a custom post type, the code will most likely be executing custom SQL queries to retrieve and/or save data into custom tables. In summary, WordPress attempts to provide access to the database through generic functions in the first stage, and through low-level access to the database in the second stage.
October CMS employs a different approach: Instead of connecting to the database straight away, the application can use Laravel’s Eloquent ORM to access and manipulate database data through instances of classes called Models, making the interaction with the database also be based on Object-Oriented Programming. It is high-level access; just by following the rules on how to create tables and set-up relationships among entities, a plugin can retrieve and/or save data without writing a line of SQL. For instance, the code below retrieves an object from the database through model Flight, modifies a property, and stores it again:
$flight = Flight::find(1);
$flight->name = 'Darwin to Adelaide';
$flight->save();
Upgrading The Data Model
Another reason for WordPress’ success (in addition to not breaking backward compatibility) has been its database architecture, which was engineered to enable applications to grow over time. This objective is accomplished through “meta” properties, i.e. properties that can be loosely added to a database object at any moment. These properties are not stored in a column from the corresponding entity table (either wp_posts, wp_users, wp_comments or wp_terms), but instead as a row in the corresponding “meta” table (wp_postmeta, wp_usermeta, wp_commentmeta or wp_termmeta) and retrieved doing an INNER JOIN. Hence, even though retrieving these meta values is slower, they provide unlimited flexibility, and the application’s data model rarely needs to be re-architected from scratch in order to implement some new functionality.
WordPress provides unlimited flexibility for upgrading the application’s data model. (Large preview)
October CMS doesn’t use meta properties but instead can store several arbitrary values, which are not directly mapped as columns in the database tables, as a serialized JSON object. Otherwise, when an object needs some new property, we need to add a new column on the corresponding table (which is the reason behind plugins User Plus and User Plus+, mentioned earlier on). To update the application’s database schema, October CMS relies on Laravel’s Migrations, which are sets of instructions to execute against the schema (such as add or drop a column, rename an index, etc) and which are executed when upgrading the software (e.g. when installing a plugin’s new version).
Headless Capabilities
Both WordPress and October CMS can be used as headless, i.e. treating the CMS as a content management system that makes content accessible through APIs, which allows to render the website on the client-side and can power other applications (such as mobile apps). Indeed, WordPress is steadily heading towards headless, since the Gutenberg content editor itself treats WordPress as a headless CMS (and, as a consequence, Gutenberg can also work with any other CMS too, as Drupal Gutenberg demonstrates).
A headless system needs to implement some API to return the data, such as REST and GraphQL. WordPress supports REST through WP REST API (merged in core), exposing endpoints under some predefined route /wp-json/wp/v2/...; October CMS supports REST through plugins RESTful and API Generator, which allow to create custom endpoints and, as a consequence, support versioning as part of the endpoint URL and can offer a better security against bots. Concerning GraphQL, WordPress supports it through WPGraphQL, while October CMS currently has no implementations for it.
Quite importantly, a headless system needs to offer powerful content management capabilities. As mentioned earlier on, WordPress has a very solid database architecture, offering a plethora of data entities (users, posts and custom posts, pages, categories, tags and custom taxonomies, comments) over which the application can be reasonably well modelled, meta properties to extend these data entities (enabling the application to upgrade its data model accordingly and without major changes), and with plugin Advanced Custom Fields filling the gap to construct relationships among the data entities. In addition, plugin VersionPress allows to version control the database content using Git. Hence, WordPress is undoubtedly a good fit for managing content, as demonstrated in severalprojectsinthewild.
On its part, and as mentioned earlier on, October CMS can omit the database and behave as a flat-file system, or it can have a database and behave as a hybrid, storing the content from pages as static files and blog posts (and others) on the database. As a consequence, content is not centralized, and its management involves a different approach. For instance, while we can use Git to version control pages, there is no support to version control the database per se; the solution to this is to populate data into the database through Seeders which, being code, can be put under version control and executed upon deployment. In addition, October CMS doesn’t offer a baked-in database model featuring predefined data entities that can support the needs of most applications. Hence, more likely than not the application will need custom development to implement its data model, which means more work, but also means that it can be more efficient (e.g. accessing a property from a column is faster than from a row in another table through an INNER JOIN, which is the case with WordPress’ meta properties).
CLI Support
Both WordPress and October CMS can be interacted with from the console through a Command Line Interface (CLI): WordPress through WP-CLI and October CMS through Laravel’s Artisan. In addition to Laravel’s commands, October CMS implements several custom commands for updating the system, migrating the database, and others. These tools make it very convenient to access the site from outside a browser, for instance for testing purposes.
Managed Hosting
It is not a problem finding a managed hosting provider for a WordPress site: given WordPress’ market share, there are dozens (if not hundreds) of providers out there vying with each other for the business, constituting a very dynamic market. The only problem is finding the most suitable provider for our specific sites based on all of their offerings, which can vary based on price, quality, type (shared or dedicated services), bandwidth and storage size, customer support, location, frequency of renewal of equipment, and other variables which we can navigate mainly through reviews comparing them (such as this one, this one or this one).
Even though nothing near as many as WordPress, October CMS still enjoys the offering from several hosting providers, which allows for some consideration and selection. Many of them are listed as October Partners, and several others are found DuckDuckGoing, but since I haven’t found any independent review of them or article comparing them, the task of finding out the most suitable one will take some effort.
Marketplace, Ecosystem And Cost
WordPress’ commercial ecosystem is estimated to be USD $10 billion/year, evidencing how many people and companies have managed to make a living by offering WordPress products and services, such as the creation of sites, hosting, theme and plugin development, support, security, and others. Indeed, its size is so big it is even bloated, meaning that it is very common to find different plugins solving the same problem, plugins that underdeliver, underperform or have not been updated for years, and themes which seem to look-alike each other. However, when creating a new site, the size and variety of the ecosystem also means that we will most likely find at least one plugin implementing each of the required functionalities, enabling us to save money by not having to develop the functionality ourselves, and the availability of customizable themes enables to produce a reasonably distinctive-looking site with minimal effort. As a consequence, we can easily create and launch a WordPress site for less than USD $100, making WordPress a sensible option for projects of any budget.
Being relatively new (only five years so far), OctoberCMS certainly doesn’t enjoy anything near WordPress’ marketplace and ecosystem sizes, however, it has been growing steadily so its size is bound to become bigger. Currently, its marketplace boasts 600+ plugins, and only a handful of themes. Concerning plugins, the October CMS team is requesting the community to put their effort into the creation of original plugins, delivering functionality not yet provided by any other plugin.
Hence, even though 600+ plugins doesn’t sound like much, at least these translate into 600+ different functionalities. This way, even though it is not possible to choose among several vendors, at least we can expect to have those basic website features (such as blogging, comments, forum, integration with social media, e-commerce, and others) to be covered. Also, since October’s founders are personally reviewing all submitted plugins and judging them according to quality guidelines, we can expect these plugins to perform as expected. As another plus, October plugins can incorporate elements from Laravel packages (even though not all of them are compatible with October, at least not without some hacks). Concerning themes, the low number of offerings implies we will most likely need to develop our own theme by hiring a developer for the task. In fact, I dare say that the theme in October CMS will most likely be a custom development, since themes and plugins are not thoroughly decoupled (as explained earlier), with the consequence that a market for easily-swappable themes is more difficult to arise. (This is a temporary problem though: once this pull request is resolved, pages will be able to be stored in the database, and swapping themes should not disrupt functionality.)
In my opinion, because of the smaller offerings of themes and plugins, creating a simple site with OctoberCMS will be more expensive than creating a simple WordPress site. For complex sites, however, October’s better architecture (Object-Oriented Programming and Model-View-Controller paradigms) makes the software more maintainable and, as a consequence, potentially cheaper.
Community
Being a part of and having access, WordPress’ community represents one of the most compelling reasons for using WordPress. This is not simply as a matter of size (powering nearly one third of all websites in the world, there are so many stakeholders involved with WordPress, and its community is representatively big) but also as a matter of diversity. The WordPress community involves people from many different professions (developers, marketers, designers, bloggers, sales people, and so on), from all continents and countries, speaking countless languages, from different social, educational and economic backgrounds, with or without disabilities, from corporate, not-for-profit and governmental organizations, and others. Hence, it is quite likely that, for whatever problem we encounter, somebody will be able to help on any of the support forums. And contributing to WordPress is pretty straightforward too: The Make WordPress group congregates stakeholders interested in supporting different projects (accessibility, design, internationalization, and many others) and organizes how and how regularly they communicate — mostly through some dedicated channel on its Slack workspace.
Furthermore, the WordPress community is real and tangible: it doesn’t exist just online, but it gathers offline in WordCamps and meetups all over the world; in 2018, there were a total of 145 WordCamps in 48 countries with over 45,000 tickets sold, and a total of 5,400 meetup events from 687 meetup groups. Hence, it is likely that there is a local chapter nearby which anyone can join to ask for help, learn how to use the platform, keep learning on a regular basis, and teach others as well. In this sense, WordPress is not just a CMS but, more importantly, it’s also people, and considering to leave WordPress should never be done only on its technical merits but on the power of its community, too.
WordCamp Kuala Lumpur 2017 drew more than 200 attendees, coming from several countries. (Large preview)
October CMS’ community is nothing near in size or diversity as WordPress’, even though it has been growing steadily following the increasing popularity of the software. October provides a support forum to ask for help, however, it is not very active. A Slack workspace exists which is pretty active and where, quite importantly, October’s founders participate regularly, helping make sure that all enquiries are properly addressed. This channel is a great source for learning low-level tips and tricks about the software, however, it is geared towards developers mainly: There are no channels concerning accessibility, design, internationalization, and other topics as in the WordPress community, at least not yet. Currently, there are no conferences concerning October CMS, but there is Laracon, the conference for the Laravel community.
Maintainers And Governance
Can we trust that the software will be maintained in the long term, so that if we decide to start a project today, we will not need to migrate to some other platform down the road? How many people are taking care of developing the software? And who is deciding in what direction the software moves towards?
Powering one-third of all sites in the world, WordPress is not short of stakeholders contributing to the software; hence we need not fear that the software will fall into decay. However, WordPress is going through internal deliberations concerning its governance model, with many members of the community expressing that decisions concerning WordPress’s direction are being taken unilaterally by Automattic, the company running WordPress.com. Center stage of this perception was the decision to launch Gutenberg, which many members disagreed with, and which suffered a lack of proper communication by the project leads during its development and release. As a consequence, many community members are questioning the role of “benign dictator”, which has been historically granted to WordPress’ founder and Automattic’s CEO Matt Mullenweg, and researching different governance models to find a more suitable one for the future of WordPress. It is yet to be seen if this quest produces any result, or if the status quo perseveres.
Decisions concerning October CMS’ direction are mainly taken by founders Alexey Bobkov and Samuel Georges and developer and community manager Luke Towers, which keep the project going strong. October CMS doesn’t have the luxury of having a governance problem yet: Its current concern is how to make the project sustainable by generating income for the core software’s maintainers.
Documentation
WordPress documentation in its own site is not extremely comprehensive, but it does the job reasonably well. However, when taking all of the documentation about WordPress into account from all sources, such as general sites (Smashing Magazine, CSS tricks, and many others), specialized sites (WPShout, WPBeginner, and many others), personal blogs, online courses, and so on, there is practically no aspect of dealing with WordPress that hasn’t already been covered.
October CMS doesn’t enjoy anything near the many third-party courses, tutorials or blog posts about it as much as WordPress does, however, the documentation on its site is reasonably comprehensive and certainly enough to start coding. October founders also regularly add new documentation through tutorials. One aspect that I personally enjoyed is the duplication of Laravel’s documentation into October’s documentation for everything of relevance, so the reader must not fill the gaps by him/herself and having to guess what is October’s domain and what is Laravel’s. However, this is not 100% perfect. October’s documentation uses terms originating from Laravel, such as middleware, service containers, facades and contracts, without adequately explaining what these are. Then, reading Laravel’s documentation in advance can be helpful (luckily, Laravel’s documentation is decidedly comprehensive, and Laravel’s screencasts, Laracasts, are another great source of learning, not just concerning Laravel but web development in general).
Conclusion
I set out to discover what features may be enticing for developers looking for alternatives to WordPress by comparing WordPress to a similar CMS, which I defined as being free and open source, based in PHP and producing dynamic content, and enjoying the support from some community. From the CMSs fulfilling these conditions, I chose October CMS for the comparison because of the knowledge I got about it, and because I appreciated its clean and modular coding approach as provided by Laravel, which could offer a fresh and modern perspective for building sites.
This article did not intend to pick a winner, but simply analyze when it makes sense to choose one or the other CMS, highlighting their strengths and weaknesses. There is no “best” CMS: only the most suitable CMS for a specific situation. Furthermore, anyone looking for a CMS to use on a particular project with a specific team and given a certain budget, should do some research and compare all the offerings out there to find out which one is most suitable for the particular context. It’s important not to limit to a few CMSs as I’ve done here in this article, but instead give a chance to all of them.
On a personal note, as a developer, what I found in October CMS is really appealing to me, mostly its ability to build modular applications as provided through Laravel. I would certainly consider this CMS for a new website. However, in the process of writing this article I also “rediscovered” WordPress. Being so popular, WordPress receives more than its fair share of criticisms, mostly concerning its old codebase and, since recently, the introduction of Gutenberg; however, WordPress also has certain excellent features (such as its super-scalable database model) which are seldom praised but should be taken into account too. And most importantly, WordPress should not be considered on its technical aspects alone: in particular, the size of its community and ecosystem places it a level or two above its alternatives. In a nutshell, some projects may benefit from sticking to WordPress, while others may better rely on October CMS or another platform.
As a final note, I would like to remark that exploring how another CMS works is a very rewarding activity on its own, independent of the decision reached concerning whether to use that particular CMS or not. In my case, I had been working for years on WordPress alone, and delving into October CMS was very refreshing since it taught me many things (such as the existence of PHP Standards Recommendations) which I had not been exposed to through WordPress. I may now decide to switch CMSs, or stick to WordPress knowing how to produce better code.
Search engine optimization (SEO) has gotten a lot more complicated over the past few years. Back in the old days (you know, 2016), SEO primarily referred to on-page optimizations. Things like page title, meta descriptions, header tags, image alt tags, and so on, but things have gotten a lot more technical with the latest Google updates. Last year, site speed became one of the signals used to rank pages, but page speed isn't just crucial for SEO; it's also essential to the user experience. Pages with a longer load time tend to have higher bounce rates and lower average time on page. Longer load times have also been shown to adversely affect conversions rates.
In this blog, I'll show you how to do some simple things to ensure your pages are performing well, and we’ll take a look at some code examples of how to programmatically ensure best practices for page performance. I'm using dotCMS for this post and will make some references to the tools available in dotCMS specifically; however, these tips can be applied to most CMSs.
WordPress is popular, and we love it, but it is not the only publishing platform. There are WordPress alternatives that you can use to build your website.
Each of these WordPress competitors are different and have their own pros and cons. You need to understand those differences and limitations when choosing a WordPress alternative.
In this article, we will show you some of the most popular alternatives to WordPress currently available on the market.
Wix is a completely hosted web site builder. It offers a limited free version to use for personal or small business website. Both free and paid plans come with pre-designed templates that users can modify using a drag and drop page builder.
Wix also has eCommerce support with its paid plans which allows site owners to accept online payments using PayPal or Authorize.net. See our article on Wix vs WordPress for a side by side comparison of the two platforms.
Gator is a fully hosted website builder created by HostGator. They are one of the top website hosting companies in the world and know their stuff when it comes to hosting websites.
Gator comes with ready-made website designs that you can customize with a user-friendly drag and drop website builder. Even absolute beginners can quickly familiarize themselves with the app without any learning curve.
Their Starter and Premium plans are suitable for small business websites. You will need their eCommerce plan to add shopping cart and other eCommerce features. Each plan also includes a free domain name and a free SSL certificate.
If you are looking for an eCommerce ready alternative to WordPress, then BigCommerce could be the right platform for you. It is a fully-hosted eCommerce website builder with drag and drop tools and beautiful templates to get you started.
It supports many payment gateways including PayPal, Stripe, Appley Pay, and Pay with Amazon. One notable advantage of using BigCommerce is that they don’t charge you for transactions.
BigCommerce allows you to add unlimited products, view your store performance, and use built-in tools to optimize conversions and boost sales. It also comes with a native WordPress integration, so you can use BigCommerce for your store while WordPress for your main content website.
BigCommerce works with a lot of other third-party apps that you will need to grow your business.
If you want to build an online store, then Shopify is a great alternative to WordPress. It provides easy to use tools to create your own online shop. You can sell your products and accept payments.
Shopify comes with a simple guided setup that helps you quickly get started with your eCommerce store. It has ready-made templates, apps, and lots of integration options.
1&1 IONOS Website Builder is another fully-hosted solution with simple drag and drop tools. You don’t have to worry about managing software, installing updates, or making backups. It comes with a guided setup that helps you choose a website design based on your website’s industry or topic.
All designs come with relevant placeholder content that you can then replace with your own. Each plan gives you hosting, a free domain name, and your own branded email addresses.
Weebly is another completely hosted website builder. It allows you to create your own website using pre-designed templates and their drag-drop page builder.
Weebly has limited eCommerce support, but you can use custom domain names. For a full comparison see our comparison of WordPress vs Weebly.
Medium is a popular publishing platform. It is different than WordPress in many ways. It is not a full content management system. Their focus is on blogging and the community aspect. It aims to connect people with stories and ideas that matter to them.
Medium is designed to provide a clutter-free writing area for publishers and similar reading experience for the readers. It looks beautiful on all devices and screen sizes. Users don’t have to worry about themes or plugins because there are none.
Instead of comments, Medium has in-line notes and responses. You don’t need to worry about the software as Medium is a completely hosted platform. Medium does not allow custom domain names anymore, which means you cannot use your own domain name for your publication.
See our comparison of Medium vs WordPress to see the difference between two platforms.
Several WordPress users who wanted to focus on blogging felt that WordPress was going in a different direction. This gave birth to Ghost, which is a NodeJS based blogging software.
The difference is that Ghost is entirely focused on blogging and keeping the clutter away. It provides a clean writing and browsing experience for bloggers and readers.
Joomla is a popular CMS software and an open source WordPress competitor. It is a strong, multi-purpose, and flexible CMS platform with a large community of users and developers.
Joomla allows you to do many of the things that WordPress can do, and then some more. Like WordPress themes and plugins, Joomla comes with extensions and templates. It is already used by millions of users, small businesses, corporations, government and nonprofits all over the world.
Just like WordPress, Joomla has a community support system, extensive documentation, and it runs on most web hosting platforms.
Wondering how it stacks up against WordPress? See our article on WordPress vs Joomla vs Drupal for a comparison of these three open source CMS platforms.
Drupal is another very popular open source CMS. Just like WordPress and Joomla, Drupal has a strong user base and developer community. It powers nearly 2.1% of all websites on the internet including The White House, The Economist, State of Georgia, and many more.
Drupal has modules and themes just like WordPress plugins and themes. It shares the same software requirements as WordPress and Joomla, so it can run on pretty much any web host that supports WordPress.
Jekyll is a static site generator. It is written in Ruby and requires NodeJS. It is a lot different than WordPress. For starters, it is a static site generator which means it takes your text and generates static HTML pages for your site (no database).
You can use free hosting provided by GitHub Pages with Jekyll. This means that if you are familiar with Markdown, SVN, Git, and command line, then you will be up and running in no-time. In other words, this is made for developers!
Tumblr is a popular free blogging platform. Tumblr combines blogging with social and makes it quite fun. It has a strong user base despite the fact that it was acquired by Yahoo in 2013.
Tumblr allows users to choose from free or premium themes. Users can also use custom domain names for their Tumblr blogs. Apart from your blog, you can also create pages. It is a completely hosted solution, so you don’t have to worry about installing or maintaining any software.
Tumblr has several limitations when compared to WordPress. You cannot easily monetize your content or run an eCommerce store. You also have to follow their content guidelines otherwise your website will be suspended.
We have a step by step tutorial on how to move from Tumblr to WordPress for users looking for a Tumblr alternative with more freedoms.
CMS Made Simple is another open source CMS with similar features as WordPress, Drupal, and Joomla. It is written in PHP and uses MySQL for the database.
It also has themes and modules which allow users to easily extend built-in features. It provides on-screen instructions plus there is free community support and extensive documentation to get you started.
Squarespace is a paid site builder that can be used as a WordPress alternative. It is extremely easy to use and a completely hosted solution.
Just like Wix and Weebly, Squarespace also offers ready-to-use templates that you can customize. There are no plugins or additional modules to install. You can only use the features provided by Squarespace. See our comparison of Squarespace vs WordPress.
Due to its limitations, many Squarespace users eventually move to WordPress. For those users, we have a step by step guide on how to move from Squarespace to WordPress.
Textpattern is another open source content management system. It shares the same server requirements as WordPress. It is a much simpler and straight forward CMS with a limited following.
It comes with a built-in user log for statistics and a native commenting system. It uses Textile to convert plain text into HTML.
Expression Engine is a PHP+MySQL based paid CMS. There is a basic free version with very limited features available for download. Unlike other open source CMS in our list, Expression Engine requires a license fee and most additional features are available as paid addons.
Google Sites is an easy and simple way to build small websites. It is extremely easy to use, free to host, and you can even use your own custom domain for your site.
It cannot be compared with CMS software in our list, but it can be compared with services like Wix, Weebly, and Squarespace.
Statamic is a paid, and flat file CMS software. Unlike other CMS software in our list, Statamic does not store your site’s data in a database. Instead it uses PHP, YAML and Markdown to generate pages.
Last but not least, Blogger is still alive. It is a free blog service by Google. It has most of the features you would need for blogging. A commenting system, built-in social capabilities, easy to use, templates, and the option to use your own domain name.
We hope this article provided you a chance to look at some popular WordPress alternatives. While looking at these alternatives, you may want to take a look at our complete WordPress review and top reasons why you should use WordPress.
If you liked this article, then please subscribe to our YouTube Channel for WordPress video tutorials. You can also find us on Twitter and Facebook.
Hi everyone, we are happy to welcome you back to another roundup of WordPress news featuring the biggest headlines from the past few weeks. In today’s post, you’ll learn about WordPress 5.1, trends in CMS market share statistics, the Google E-A-T algorithm, and a new Amazon release – Alexa Skills Blueprint – that involves blogs. Last but not least, another #wpdrama kept everyone busy for a few days, but it seems to have ceased as quickly as it started.
You’ve taken the first steps towards building your own website after installing WordPress, but you’re wondering what’s next?
(You can refer to the WordPress installation guide here)
Well, WordPress is an incredible content management system (CMS) – the most popular in the world – and it is quite easy to learn. But, after installing WordPress and seeing the blank screen of the new website, moving ahead may seem intimidating.
After all, there are tons of unique ways to bring a WordPress site through its many themes and plugins. Not to mention basic requirements such as general setup adjustments that allow data analysis, contact form creation, and other essential information on the website.
Here’s a checklist at your fingertips covering the first 7 steps you should complete making your site run.
1. Enter the site information (Title, Time Zone, Profile)
Website Title and Slogan In the WordPress control panel (which will be accessible immediately after installation), navigate to Settings> General. Here you can enter the website name and a slogan. Many websites choose to use the slogan space to display a brand motto.
Time zone While you are still in the General section, scroll down to adjust the date and time format you want to display on the website, and the time zone in which it operates.
Profile Profiles are implemented in the WordPress theme, and if you are blogging, your profile can be represented alongside uploaded posts. It’s a good idea to fill this short section earlier in the process.
From the dashboard, navigate to Users> Personal Profile. From here you will be able to enter your user name, contact information, a short biography, and a profile picture.
2. Delete unwanted content (examples of articles and themes)
• Deleting article and page examples If you look at the Dashboard articles section, you will see content as a blog post called “Hello World”. You can remove unwanted posts by navigating to Articles > All Articles and selecting the Garbage option. In the same way, to remove unwanted pages, go to Pages> All Pages and choose the garage option.
• Deleting default themes You will also find default themes included with the WordPress installation by default. While you are already removing excess content, it is possible to delete other unwanted themes to clear your navigation and save space. To delete a theme from the dashboard, navigate to Layout> Themes, then select the delete option in the lower right corner of the unwanted theme. Note: Active themes cannot be deleted. If you want to remove an active theme, you will need to disable it before deleting it as usual.
3. Choose a WordPress theme
Provided by WordPress or third-party developers, the WordPress theme will determine the look of your website. Free or paid themes are available in the WordPress thematic directory.
While you should choose a theme based on taste and budget, it is important to keep in mind that paid themes offer wider customization options, frequent updates, more careful assistance, and easier functionality.
Also, it is important to remember that each theme is coded and works differently, so make sure you look at the support documentation when you modify the theme or check the compatibility of the modules.
4. Install plugins
Plugins are great because they extend the functionality of WordPress sites and are essential for most sites. This is because WordPress is packaged with everything that is needed for the sites itself, so additional site features such as a list of products and services, two-factor authentication, payment processing, and more are possible only by installing plugins.
5. Securing the site
The real trick in keeping your site safe is a good security practice.
Strong passwords, a hidden address of the administrator and making sure your site is up to date is all needed to protect your website.
WordPress security plug-ins are available to further enhance site protection by adding additional features, such as two-factor authentication password protection.
Two-factor authentication requires a second user-specific code that changes during authentication to make strong passwords.
In addition, to demonstrate that your site is safe for users, you will want to install an SSL certificate. SSL certificates protect against external attempts to intercept registered users.
6. Link your site to Google Analytics
Making and developing a website is one thing, but ensuring that it works well and continues to do this is something else.
To monitor website statistics and plan stronger strategies for your site, you’ll want to link it to Google Analytics.
This will allow you to analyze traffic, user behavior, and other useful information to better understand the audience. Virtually all successful companies follow their operational data to influence managerial decisions, which means you can not afford to neglect your own data.
7. Create a backup
With the preliminary steps completed, you are almost ready to launch the website. But, before doing so, it is worth creating a backup reserve. This last task may seem easy to ignore, but it could become the most important.
Imagine that after all your work and effort you have made a popular and profitable site. But then somebody manages to break it and suddenly everything that you have worked is gone and nothing has ever been there.
Having a website backup, it can be restored.
However, remember that WordPress does not come with a backup system, so you will need to manually backup.
You can develop a web app using WordPress in mere days, and for way less money than investing in custom development. WordPress isn’t suitable for every kind of app, but it’s more than a simple CMS for blogs. Once you can transcend the publishing frame of mind, you’ll see how you have some robust infrastructure […]
Joomla! is a free and open-source content management system (CMS) and is one of the most popular website hosting software. According to the official website, Joomla! is built on a model-view-controller web application framework that can be used independently of the CMS, allowing you to build powerful online applications.
One of my personal favorites of Joomla! is the multi-language support with its large library of language packs. You can also translate the website admin backend with language extensions, helping you to easily localize your website.
One of the stand-out headline features of HTML5 for many designers and developers was the addition of a number of new types of form input that could be used. For years, we’d been confined to using single-line text inputs (type="text") and laying on JavaScript and user instructions to try an accurately capture valid data of different types through that one unsophisticated field.
HTML5 brought with it new values of the type attribute that enabled us to be much more specific about the types of data we needed to capture through the field, with the promise being that the browser would then provide the interface and validation required to coerce the user into completing the field accurately.
From URLs to emails, and from search fields to dates, the hope was that instead of needing to write cumbersome JavaScript to try and validate those fields, we could just leave it to the browser to do that hard work for us. What’s more, by adding what it knows about the user’s context (type of device, type of interaction, timezones, and so on) the browser would be able to do a much better job of tailoring the interface to meet the user’s needs that we ever could as page authors.
Having new items in a spec is one thing, but it doesn’t really mean too much unless the browsers our audience are using support those features. These new values of the type attribute had the big advantage of falling back to type="text" if the browser had no support, but this may have also come at the cost of removing the browsers makers’ imperative when it came to implementing those new types in their products.
It’s the start of 2019, and HTML5 has been the current version of HTML now for more than four years. Which of those new types have been implemented, which can we use, and are there any we should be avoiding?
The type="search" input is intended to be used for search fields. Functionally, these are very the same as basic text fields, but having a dedicated type enables the browser to apply different styling. This is particularly useful if the user’s operating system has a set style for search fields, as this enables the browser to style the search fields on web pages to match.
The specification states that the difference between search and text is purely stylistic, so it may be best to avoid this if you intend to restyle the field with CSS anyway. There appears to be no semantic advantage to its use.
Can I Use input-search? Data on support for the input-search feature across the major browsers from caniuse.com.
Recommendation
Use type="search" if you intend to leave the styling of the search field up to the browser.
2. Telephone Number Fields
The type="tel" input is used for entering telephone numbers. These are like the unique usernames used by Whatsapp. If you’re unsure, ask your grandparents.
Internationally, telephone numbers take on lots of different formats, for both technical and localization reasons. Due to this, the tel input doesn’t attempt to validate the format of a phone number. You can make use of the associated validation tools such as the pattern attribute on the tag, or the setCustomValidity() JavaScript method to enforce a format if required.
On desktop browsers, the use of telephone fields seems to have little impact. On devices with virtual keyboards, however, they can be really useful. For example, on iOS, focusing input on a telephone field brings up a numeric keypad ready for keying in a number. In addition, the device’s autocomplete mechanisms kick in and suggest phone numbers that can be autofilled with a single tap.
Can I Use input-email-tel-url? Data on support for the input-email-tel-url feature across the major browsers from caniuse.com.
Recommendation
Use type="tel" for any phone number fields. It’s very useful where implemented, and comes at no cost when it’s not.
3. URL Fields
The type="url" field can be used for capturing URLs. You might use this when asking a user to input their website address for a business directory, for example. The curious thing about the URL field is that it takes only full, absolute URLs. There’s no option to be able to capture just a domain name, or just a path, for example. This does restrict its usefulness in some respects, as I imagine CMS and web app developers would have found lots of uses for a field that accepts and validates relative paths.
While this would be a valid absolute URL:
https://twitter.com/drewm
Both of these would not pass the field’s validation:
It feels like a missed opportunity that different parts of a URL cannot be specified, but that’s what we have. Browser support is across the board pretty great, with virtual keyboard devices offering some customization for URL entry. iOS customizes its keyboard with ., / and an autocomplete button for common TLDs such as .com and for my locale, .co.uk. This is a good example of the browser being able to offer more intelligent choices than we can as web developers.
Can I Use input-email-tel-url? Data on support for the input-email-tel-url feature across the major browsers from caniuse.com.
Recommendation
Use type="url" whenever you need to collect a full, absolute URL. Browser support is great, but remember that it’s no good for individual URL components.
4. Email Fields
Possibly one of the most commonly used of the newer options is type="email" for email addresses. Much like we’ve seen with telephone numbers and URLs, devices with virtual keyboards customize the keys (to include things like @ buttons) and enable autofill from their contacts database.
Desktop browsers make use of this too, with Safari on macOS also enabling autofill for email fields, based on data in the system Contacts app.
Email addresses often seem like they follow a very simple format, but the variations actually make them quite complex. A naive attempt to validate email addresses can result in a perfectly good address being marked as invalid, so it’s great to be able to lean on the browser’s more sophisticated and well-tested validation methods to check the format.
Usefully, the multiple attribute can be added to email fields to collect a list of email addresses. In this case, each email address in the list is individually validated.
<input type="email" multiple>
Can I Use input-email-tel-url? Data on support for the input-email-tel-url feature across the major browsers from caniuse.com.
Recommendation
Use type="email" for email address fields whenever possible.
Safari on iOS shows custom keyboards for telephone, email and number fields, amongst others. (Large preview)
5. Number Fields
The type="number" field is designed for numerical values, and has some very useful attributes along with it in the shape of min, max and step. A valid value for a number field must be a floating point number between any minimum and maximum value specified by the min and max attributes.
If step is set, then a valid value is divisible by the step value.
<input type="number" min="10" max="30" step="5">
Valid input for the above field would be 10, 15, 20, 25 and 30, with any other value being rejected.
Browser support is broad, again with virtual keyboards often defaulting to a numeric input mode for keying in values.
Some desktop browsers (including Chrome, Firefox and Safari, but not Edge) add toggle buttons for nudging the values up and down by the value of step, or if no step is specified, the default step appears to be 1 in each implementation.
Can I Use input-number? Data on support for the input-number feature across the major browsers from caniuse.com.
Recommendation
Use type="number" for any floating point numbers, as it’s widely supported and can help prevent accidental input.
6. Range Fields
Less obvious in use that some of the other types, type="range" can be thought of as being an alternative for type="number" where the user doesn’t care about the exact value.
Range fields take, and will often use, the same min, max and step attributes as number fields, and browsers almost universally display this as a graphical slider. The user doesn’t necessarily get to see the exact value they’re setting.
Range fields might be useful for those sorts of questions on forms like “How likely are you to recommend this to a friend?” with “Likely” at one end and “Unlikely” at the other. The user could slide the slider to wherever they think represents their opinion, and under the hood that gets submitted as a numerical value that you can store and process.
Browser support is good, although the appearance varies between implementations.
Can I Use input-range? Data on support for the input-range feature across the major browsers from caniuse.com.
Recommendation
The uses for type="range" might be a bit niche, but support is good and the slider provides a user-friendly input method where appropriate.
7. Color Fields
The type="color" field is design for capturing RGB colors in hexadecimal notation, such as #aabbcc. The HTML specification calls this a “color well control”, with the intention that the browser should provide a user-friendly color picker of some sort.
Some browsers do provide this, notably Chrome and Firefox both providing access to the system color picker through a small color swatch.
Neither IE nor Safari provide any support here, leaving the user to figure out that they’re supposed to enter a 7-digit hex number all by themselves.
Color fields might find use in theming for personalization and in CMS use, but unless the users are sufficiently technical to deal with hex color codes, it may be better not to rely on the browser providing a nice UI for these.
Can I Use input-color? Data on support for the input-color feature across the major browsers from caniuse.com.
Recommendation
Unless you know your users will be happy to fall back to entering hexadecimal color codes, it’s best not to rely on browsers supporting type="color".
Range, color and date fields as displayed by Edge, Firefox and Chrome. (Large preview)
8. Date Fields
HTML5 introduced a number of different type values for creating inputs for dates and times. These included date, time, datetime-local, month and week.
At first glance, these appear to be heaven-sent, as collecting dates in a form is a difficult experience for both developer and user, and they’re needed pretty frequently.
The promise here is that the new field types enable the browser to provide a standardized, accessible and consistent user interface to capture dates and times from the user with ease. This is really important, as date and time formats vary world-over based on both language and locale, and so a friendly browser interface that translates an easy-to-use date selection into an unambiguous technical date format really does sound like the ideal solution.
As such, valid input for type="date" field is an unambiguous year-month-day value such as 2019-01-16. Developers like these, as they map pretty much to the ISO 8601 date format, which is used in most technical contexts. Unfortunately, few regular human beings use this date format and aren’t likely to reach for it when asked to provide a date in a single empty text field.
And, of course, a single empty text field is what the user is presented with if their browser does not provide a user interface for picking dates. In those cases, it then becomes very difficult for a user to enter a valid date value unless they happen to be familiar with the format required or the input is annotated with clear instructions.
Many browsers do provide a good user interface for picking dates, however. Firefox has a really excellent date picker, and Chrome and Edge also have pretty good interfaces. However, there’s no support in poor old IE and none in Safari, which could be an issue.
Can I Use input-datetime? Data on support for the input-datetime feature across the major browsers from caniuse.com.
Recommendation
While convenient where it works, the failure mode of type="date" and its associated date and time types is very poor. This makes it a risky choice that could leave users struggling to meet validation criteria.
Conclusion
A lot has changed in the browser landscape in the four years since the HTML5 specification became a recommendation. Support for the newer types of input is fairly strong — particularly in mobile devices with virtual keyboards such as tablets and phones. In most cases, these inputs are safe to use and provide some extra utility to the user.
There are a couple of notable exceptions, the worst of which being the date and time fields, which not only lack utility, but also have more patchy browsers support. When support isn’t available, the fallback mode of these fields is poor. In these cases, it might be best to stick to JavaScript-based solutions for progressively enhancing the basic type="text" input fields.
If you’d like to read more, I’d thoroughly recommend the MDN web docs on these field types, and as ever, the W3C specification.
The WordPress platform is used by individuals and organizations across the globe for hosting dynamic web content. You may not even realize it, but a large portion of popular blogs, news sites, and blogs run on WordPress. This popular CMS (content management system provides a framework for working with text, images, and video. How popular […]
Shopify is arguably one of the best e-commerce platforms of our time. WordPress, on the other hand, is the best content management system on the web. Link the formidable e-commerce functionality of Shopify with the powerful CMS features of WordPress via the WP Shopify plugin, and you get all the tools you need to build […]
If you’re looking to launch a small, static, and speedy website, micro-site, or landing page, you may be considering a static-site generator like Gatsby.
This article will walk you through the process of using Gatsby alongside dotCMS, a Java-based open-source headless CMS, to build a static website that uses API calls to pull content that’s created, stored, and managed in dotCMS, and presented by Gatsby.
While the growing adoption of responsive images cannot be ignored, it can be very difficult to employ the functionality under the constraints of a large CMS like WordPress. Although it is entirely possible to write the feature into your theme on your own, doing so is a challenging and time-consuming endeavour.
Thankfully, with the launch of WordPress 4.4, theme developers and maintainers will find it much easier to introduce responsive image functionality into their themes. In this recent launch, the RICG Responsive Images plugin has been merged into WordPress core, which means that responsive image support now comes as a default part of WordPress. Let’s take a look at how the feature works, and how you can use it to get the best support for your WordPress site.
You’ve put a lot of thought, time and effort into creating great content, and you want users to have a great experience with your content. While you might have created the best content in the world, you don’t get to choose how users access it. That’s why it’s important to make sure your content works beautifully on every platform and device, desktop, mobile or something else entirely.
Before you panic, I’m not advocating that you create individual content strategies for each device or network that your content is published to. That would be crazy, and it wouldn’t necessarily work better for your users.
It’s not because you wouldn’t do a good job — it’s because it would be impossible to plan and keep up with special content strategies for every device that exists now (not to mention ones that haven’t been invented yet).
While there’s no magic bullet to make sure your content is publishable and useful on every device, you can change the way you think about, plan for and create content so that it can go anywhere it needs to go.
Developing a mobile content strategy isn’t just about making content look as good on phones and tablets as it does on the desktop. It’s about creating portable, flexible content structures that go wherever your users are, without sacrificing quality. It’s an intimidating task, but not impossible. We’ll start with an example, then cover some of the things you can do to make your content more flexible and accessible.
First, An Example: How NPR Learned To COPE
National Public Radio’s (NPR) core product has long been high-quality audio journalism. But because audiences don’t solely rely on their radio for news, NPR needed a content strategy that would allow it to reach a larger audience by publishing stories to multiple platforms. It needed a way to expand its radio stories with photos, videos, audio and text and get them to readers, no matter what devices they were using. They also needed to be efficient and cost-effective and make it easy for journalists to publish their stories. So, it developed a content strategy that would ensure that its stories would work well on every device without their having to create new publishing platforms for each type of device or having to duplicate every story for each platform.
The key to the strategy was to create “display-agnostic” content structures that allow journalists to COPE — create once, publish everywhere1. In NPR’s new strategy, journalists file their stories once to a CMS. Each story published to the CMS has common elements — titles, categories, tags, captions, etc. — that can be shown or hidden depending on the device and that is distributed via an API. This way, NPR’s designers can change the content’s presentation for each platform without sacrificing quality or requiring the editorial team to publish stories multiple times.
Here’s a small example of how it works. Check out one story about Downton Abbey from NPR’s Monkey See blog. The story was written, edited and then published to NPR’s CMS. But because of NPR’s COPE model and APIs, it displays a little differently on different screen sizes.
Here’s how the story’s excerpt was displayed on NPR’s home page on the desktop:
2 This is how the story appears on NPR’s home page on the desktop. (View large version3)
Looks good, right? Let’s break it down by the elements in the desktop excerpt:
categorization (of the Monkey See section)
headline
excerpt
a few links to related tags (to the right)
image
image caption (hidden behind that blue button)
image credits (also hidden behind the blue button)
Now, here’s how that same story’s excerpt looks on the mobile version of NPR’s home page:
4 This is how the story appears on NPR’s home page on mobile. (View large version5)
You’ll notice it’s pretty much the same, but with a few small differences:
While the category is still there, the related tags aren’t used.
The image credit is visible right below the image, while the caption is still hidden behind the button.
So, the journalist published the story once, and the same content is presented, but some of its elements are left out or rearranged to accommodate for the smaller screen.
In order to create a content strategy that works for you and that goes wherever your users are, you have to stop thinking about devices. Instead, start working to create content that has structure, even as it takes on different forms.
Content Modeling: A Difficult, Time-Consuming And Incredibly Necessary Process
Before you can build an effective content strategy, mobile or otherwise, you have to know exactly what you’re working with. That’s where content models come in — they’re a way to give your content an organizational structure without defining its form, and they’re very important to your strategy’s success.
Trust me, content modeling is something you want — no, need — to do, not because it’s a fun time necessarily, but because doing it early has the potential to save you a ton of time, money and heartache later. Doing content modeling early, before you get into the design and development process, is much better.
Raise your hand if your design team has ever spent weeks or months on a really lovely design for desktop and mobile, only to show it to the client for review and realize that you haven’t accounted for content types that need images or video or some other crucial element. That’s the worst, right? By spending a little time on content modeling, you’re reducing the risk of that happening, while also making your designers and developers’ lives easier. Content modeling isn’t difficult, but it takes some time and effort.
Let’s say you’re working on a website geared to home cooks. Your team is ready to start working on a new mobile content strategy. Before diving into your strategy, though, you need to get your team together for a content modeling session.
A content modeling session is easy to set up. You’ll just need to get a few key stakeholders together around a whiteboard for an hour or two (though, don’t be surprised if it takes longer). There’s no limit to how many people you should invite to the content modelling session, but don’t let it get too big. Include a few of the people who will be creating the content — they’re the ones who will be dealing with the content the most — as well as anyone charged with setting standards, goals and direction for the brand.
Start by looking at the website’s existing content types. What kinds of stories, blog posts or other content types are being created? List each content type and the elements it includes, like photos, captions, body copy, headlines, etc. Don’t forget to include things like newsletters, podcasts, listings and events — the point here isn’t to do this quickly, but to be thorough. For our cooking website, two of the website’s content types might be recipes and ingredients.
Once you’ve got a list of content types, break them down by element. You’ve established that two of the content types are recipes and ingredients. These two content types are related (recipes consist of ingredients, and ingredients can be tied to specific recipes), but each includes its own unique set of elements.
6 This is an example of what the content model for recipes and ingredients might look like. The diagonal lines show the relationships between content elements and content types. (View large version7)
After you’ve listed each existing content type and its elements, think about what content types you’d like to be able to create in future. For example, do you want to go beyond recipes and ingredients and create sets of seasonal dishes? Or is your business model shifting to include notable chefs or contributors, who will need to be featured. Nothing is off limits — think about your business goals, editorial goals and audience’s needs.
Once You’ve Got Models, Start Building Them Out in the CMS
Once you’ve got your content model in place, start setting up a CMS that will help you COPE.
Every CMS is a little different, but in most cases you won’t need to create an entirely custom CMS to support your new content strategy. In most cases, you can bend your existing CMS to your will by creating page types, post types, custom fields and field sets that make it easier to create and display content. You can tie field sets to page and post types, which will make it easier for your content creators to add all of the necessary information.
For example, you might set up a page type in your CMS for each recipe and include these fields:
ingredients list (linking each ingredient to its ingredient page);
cooking time;
categories (like season or course — think appetizers, desserts, etc.);
introductory copy about the recipe;
recipe instructions;
tags;
author (which could possibly include fields for the author’s name, a head shot and a short bio).
Once you know which elements make up each content type and have accounted for them in your CMS, you’ll be able to COPE. You’ll have a flexible content structure that allows you to publish each recipe or ingredient once, even though it might be presented differently on each platform. You can then work with your designers and developers to figure out which elements should appear when.
Understand How Your Content Will Be Used
Ultimately, we don’t get to choose when someone decides to use the content we create or which platform they use it on (but, oh, the world would be a much simpler, if less interesting place, if we did). So, why think about use cases? Because our job is to make our content accessible and useful to all users, no matter when or where it’s being used.
People use every device in every location, in every context. They use mobile handsets in restaurants and on the sofa. They use tablets with a focused determination in meetings and in a lazy Sunday morning haze in bed. They use laptops with fat pipes of employer-provided connectivity and with a thin trickle of data siphoned through expensive hotel Wi-Fi. They use desktop workstations on the beach—okay, they really only use traditional desktop machines at desks. You’ve got me on that one.
Going back to the recipe website, it has a ton of possible use cases. You may have users who:
spend time browsing the website for recipes on their desktops and planning their menu before going to the grocery store;
pick up an interesting ingredient at the store and pull up your website on their phone to learn more about it and to see what recipes it could be used in;
call on Google Glass to find a recipe on their way to the store;
prop their tablets up in the kitchen like a cookbook;
ask an audio interface to read a recipe to them step by step.
What do all of these users have in common? Each one of them deserves to have a great, complete experience with your content.
“But wait!” you might say. “We’ve got a ton of data showing that our users use our website in this particular way on this particular device.” That may be mostly true, but you can’t always be absolutely positive. That’s why the best solution is to make all of your content available and easily accessible across all platforms.
Such accessibility doesn’t mean sacrificing the user experience, though, nor does it mean that the presentation of your content must be identical on phones, desktops and tablets.
Each device has its own considerations for design and user experience that your content can work within. Let’s consider some examples.
You might choose to highlight specific content elements on different platforms, while placing others behind a menu.
Or you could opt for a more visual presentation on large screens, using larger images that might not work as well on smaller screens. (For example, you might hide each section of a recipe behind a tappable button on a phone, so that users can quickly see and access the information they need.)
On desktop displays, you might choose to immediately show more photos of recipes associated with an ingredient to encourage further browsing.
The point is that while your content’s presentation may change, users should be able to access the same amount and quality of content from any platform.
Adapt Your Editorial Process To Your Strategy
Once you’ve done the hard work of modeling your content and thinking about use cases, you should have a pretty good idea of the content you’re working with and where it needs to go.
Before running off and firing up your CMS, you need to consider one more thing: the editorial process. Remember that content strategy is not just about structuring content for the reader, but also about making the process of creating content efficient, thoughtful and sensitive to the content’s mobility.
Your editorial team and its process are crucial to implementing your new content strategy. Your content creators are the ones who will be dealing with the new structure the most, so it’s important to understand their existing processes, any pain points they may have and any changes they’d like to see. Even if you feel pretty good about the editorial process, this is a good time to check in with the content creators to see whether they need anything to make their work easier.
Creating and implementing a flexible content strategy could also mean making some changes to the way your content is published. In a perfect world, it’ll make things easier. When you don’t have to worry about publishing each piece of content to its own platform, you’ll probably be able to streamline the editorial process. Instead of content creators having to create content in more than one place and editors having to edit for each platform, a COPE model allows the editors to edit each piece only once.
During content modeling, you may have added a few new content types or elements to the content’s structure. Don’t forget that these new pieces will need to be brought into your editorial policy. Here are a few things to consider:
Who is responsible for creating each piece of content? The writer, the editor or someone else?
Who publishes the content once it has been edited? Does the editor publish it, or do they inform the writer that it’s ready to go?
Who is responsible for categorizing and tagging content? Will your writers do that or your editors?
How will the content be created? Will the writers create content directly in the CMS, copy and paste from a document, or submit a document to an editor for publication? Given that many CMS’ allow writers to save unpublished drafts, asking your writers to create their stories in the CMS instead of in a document might not be a bad idea. This will reduce the number of steps each story goes through and will make formatting and editing easier.
Additionally, the new content structure could require changes to your editorial standards. You’ll likely have to put new guidelines in place for any new content elements you have added. This is also a good time to review existing editorial guidelines to make sure they still make sense. Think about things like the following:
Who will choose the photos that go with posts? Who will write the captions? Do photos have to have captions?
If you’ve added any new content types (for example, “chefs”), who is responsible for creating those new pieces?
How many categories and tags should be assigned to each piece of content? Does the writer or editor choose them? Also, who determines when it’s time to add a new post category or tag? (Personally, I recommend that editors set them in order to keep things consistent and to make sure you’re not doubling up on tags. This is especially important in content structures such as in the recipe example, which require posts to be in certain categories in order to be found.)
Before implementing your new device-agnostic content strategy, you may need to revisit your guidelines to account for things that might display differently on small screens. Headline lengths may have to be adjusted so that they don’t completely take over small screens. Also, you might have to change the guidelines on image sizes to make sure that a photo attached to a story looks just as good on large monitors as it does on tablets.
Finally, even if you feel pretty good about the editorial process, this is a good time to check in with the editorial team to see whether they need anything or whether you could implement new processes as part of your strategy to make content creation easier.
Final Thoughts
Remember that any new strategy is partly a learning process. And content is messy — it’s human and it’s vital, and ensuring that its creation, distribution and use go smoothly requires a lot of time, effort and coordination. As long as you’re working to make sure that every user has a great experience with your content, you’re fighting the good fight.
Use content models to understand each type of content you’re publishing and the elements it includes. Then, use post types, page types and custom fields to account for each element in your CMS. Study your users to learn how they interact with your content. Try to address their most common needs while making sure the content works well across all platforms. Adapt the process of creating content to your new strategy. Train your content creators to use the new content structures you’ve created, and put editorial guidelines and practices in place to ensure that the strategy will be implemented.
By taking the time to create content structures that can go anywhere, as well as considering use cases and tightening up your editorial strategy, you’ll be confident that the content will work, no matter who’s using it or where.
If you’ve got stories about creating mobile or device-agnostic content strategies that you’d like to share, please leave them in the comments.
Help Your Content Go Anywhere With A Mobile Content Strategy http://www.smashingmagazine.com/2015/03/23/content-mobile-content-strategy/ http://www.smashingmagazine.com/feed/?# Smashing Magazine For Professional Web Designers and Developers
The WordPress platform is used by individuals and organizations across the globe for hosting dynamic web content. You may not even realize it, but a large portion of popular blogs, news sites, and blogs run on WordPress. This popular CMS (content management system provides a framework for working with text, images, and video. How popular […]
Shopify is arguably one of the best e-commerce platforms of our time. WordPress, on the other hand, is the best content management system on the web. Link the formidable e-commerce functionality of Shopify with the powerful CMS features of WordPress via the WP Shopify plugin, and you get all the tools you need to build […]
