Category Archives:
Wordpress Archives

WordPress’ editing interface is great for writing – and it’s only going to get better – but collaboration is a weak point. It is possible to collaborate on a WordPress article, but only if writers and editors take it in turns. Several contributors can’t work on the same document at the same time, which is one of the reasons so many WordPress publishers turn to third-party editors like Google Docs.

Google Docs offers excellent collaboration support. Any number of participants can edit a document and – most of the time – Docs will do the right thing with the changes. It’s easy to see who has made each edit, suggest edits without committing them to the active document, and add comments.

But for WordPress users there’s a major stumbling block: getting content out of Google Docs and into WordPress isn’t straightforward. The obvious solution is to copy-and-paste, but that plays havoc with formatting and links. When I’ve used this method for longer documents, it’s taken a lot of work to knock the article into shape for publishing.

In a move that recognizes the value of collaboration and that WordPress’ native collaboration features aren’t quite there yet, Matt Mullenweg has announced the release of a Google Docs add-on that can send documents to WordPress sites as a draft. The big win here is that all the formatting – images, text styles, links – are maintained.

As with many of the innovations coming out of Automattic, the Google Docs add-on only works if you have a JetPack-enabled WordPress site.

The add-on isn’t perfect: image layout can go awry, and any edits that happen in the Google Doc after it’s been pushed to WordPress aren’t synchronized. As a consequence, it’s not possible to edit any existing WordPress drafts in Google Docs – it’s a one-way process. I expect some of these limitations will be overcome in the future, and the features that are available are welcome.

As someone who writes a lot of content that ends up in WordPress via Google Docs, this tool will save me a lot of time. Apart from single-writer blogs, almost every publishing workflow involves collaboration with other writers, editors, and clients. Google Docs is the perfect app for that sort of collaboration.

When I write an article, it starts life as a Markdown file which is converted to HTML and uploaded to Google Docs, where editors or clients can review it, add notes, and make edits. That process is smooth – but once the article is ready for publication, someone has to take the Google Doc, paste it into WordPress and then spend a lot of time redoing formatting, images, and links that were already part of the Google Doc. For a busy site owner, that’s a frustrating waste of time.

The new WordPress Google Docs add-on has the potential to improve that process, providing a friction-free workflow that can take documents from drafting to publication-ready without an onerous duplication of effort.

Posted in:
Content, WordPress

WordPress security plugins help improve the security of WordPress sites, but they’re no substitute for an understanding of basic security precautions. Any web application is vulnerable if its developers and users don’t follow security best practices. WordPress is no different, and because WordPress is used by millions of non-technical users, it’s reasonable to assume that many of them won’t understand the complexities of web application security.

WordPress security plugins exist — in part — to help non-technical users limit the risk, without asking them to become security experts. But no WordPress plugin can make a site invulnerable to hackers, and it’s important that WordPress site owners understand at least the basics of web application security to keep themselves safe. It’s perfectly possible for WordPress to be secure. In fact, it’s relatively easy to create a secure WordPress site, but you need to know a few commonsense rules.

Bringing easy web publishing to everyone is a core goal of the WordPress project, and it’s been remarkably successful. Anyone with an idea can publish content on a site over which they have complete control. But, however easy it is to create a WordPress site — and modern WordPress hosting companies make it very easy indeed — the user still has some responsibility to educate themselves about security. The vast majority of hacked WordPress sites are the result of user error: the user chooses a bad password for their admin account or they fail to update a plugin with a known vulnerability.

However well-designed and feature-rich a security plugin is, it won’t protect users against many of the mistakes that hackers exploit. WordPress security plugins like WordFence and iThemes Security make it much easier to secure a WordPress site, and I’d strongly advise any non-technical WordPress user to install a security plugin, but WordPress users should understand that installing a security plugin isn’t the end of their security responsibility.

This isn’t a WordPress problem: it’s web application problem. Web applications like WordPress, Joomla!, Drupal, and Magento are immensely complex pieces of software. No one has figured out how to make software that’s both feature-rich and completely without bugs. Software bugs, and hence software vulnerabilities, come with the territory — and, unfortunately, so do hackers and criminals.

Installing a security plugin won’t protect you against these vulnerabilities. WordPress and WordPress plugin developers try hard not to introduce bugs, and when bugs are found, they’re squashed very quickly. To be protected, you have to update and understand why you have to update.

Many classes of vulnerability aren’t caused by software bugs, but by simple user errors. Nothing the developers can do will stop you using “miaow” as your admin password, although the WordPress interface will tell you it’s a bad idea. Security plugins won’t help you out there either, although they can limit your exposure to brute force attacks that take advantage of bad passwords. You need to know that using a simple password isn’t a good idea.

Web application security is a partnership between developers, hosting providers, and users. Users have to do their part, and installing a security plugin a great first step, but it won’t get you all the way to a secure site on its own.

Posted in:
Content, WordPress

The release of WordPress 3.7 introduced a feature that was met with mixed reactions: automatic background updates. In all versions after 3.7, WordPress completes minor updates without asking for permission.

Left to their own devices, site owners often neglect to perform updates. Updates – particularly the minor updates that can be applied automatically – include security patches that fix known vulnerabilities. If the updates aren’t applied to a WordPress site, it remains vulnerable. If the vulnerability wasn’t widely known in the criminal community, it will be after a patch is released, increasing the risk to sites that fail to update. The sooner sites are patched, the better. But many in the WordPress developer and professional communities weren’t impressed with automatic updates.

Updates sometimes break WordPress sites. This happens rarely, but whenever part of a complex system changes, so do its interactions with other parts of that system. An update may stop a plugin from working or cause a regression – a bug introduced when another bug is fixed or feature added.

It’s not impossible that a minor security update could stop a WordPress site working, but ask yourself how often you’ve seen that happen when applying a minor update to a production site. And then ask yourself how many hacked WordPress sites you’ve come across. Compare the two numbers and I think it’s fair to say that it’s a risk worth taking.

Some argue that automatic updates introduce a security risk. If the servers hosting the updates are compromised, criminals could inject malware into the update files and infect hundreds of thousands of sites. It would be nice if WordPress introduced code signing to further reduce the risk, but in reality the likelihood of this chain of events occurring is vanishingly small. And it’s certainly smaller than the risk of leaving sites unpatched.

Finally, some people simply want complete control over what’s installed on their site. Automatic updates don’t sit well with them. That’s fine: control over your own site and content is what WordPress is all about. But that has to be balanced against the potential risk if security problems aren’t dealt with. If you’re a responsible WordPress site owner, you’ll apply the patch eventually. If you plan to pore over the code before you patch, then you’re probably not the target market for automatic updates. If your objection is simply to the concept of automatic updates, that’s your choice, but you shouldn’t make that choice for less technical users for whom you build and manage sites.

Earlier this year, a vulnerability in the newly introduced WordPress REST API lead to the defacement of a large number of WordPress sites. The patch to fix the vulnerability was released immediately after the problem was discovered and pushed out as an automatic update. Sites with automatic updates turned on – the default state – are no longer vulnerable. And yet, we’re still seeing many thousands of sites fall victim to the attack. The obvious conclusion is that some people think turning automatic updates off is a good idea.

There’s nothing wrong with turning off the automatic updates in principle, but if you provide a client with a site that has automatic updates turned off, you have a responsibility to make sure security updates are applied in good time. If you’ve turned off automatic updates on your own site, it’s up to you to manually update at the earliest possible opportunity.

Otherwise, the smart thing is to leave automatic updates turned on and let them do their job.

Posted in:
Content, WordPress

I’ve been a WordPress user for years and I’ve written many thousands of words in the WordPress editor. I’ve seen the editor develop from a barely usable and — at times — frustrating writing experience into a functional tool. Gradual iteration over more than a decade has created a polished interface for writing and creating blog posts.

But sometimes an iterative approach isn’t enough. Sometimes a complete re-imagining is called for. The core functionality of the editor, including shortcodes and embeds, was developed for a different time, and has become increasingly clunky compared to the best editing experiences available on the web.

While many of us have grown to know and love WordPress’ TinyMCE-based editor, it can be off-putting to new users used to writing and editing in word processors like Word or text editors like iA Writer.

An early prototype of a new vision for WordPress editing was recently released, and it promises to revolutionise the WordPress editing experience. Gutenberg is a block-based editor that leverages the best in modern web technology to provide an editing interface that will hopefully satisfy TinyMCE nostalgics and new WordPress users alike.

It should be noted that Gutenberg is a very early prototype. It demonstrates where the developers are hoping to go, but there’s a long road to travel before they get there. Most of the promised functionality isn’t yet working, and it’ll be some time before we see Gutenberg in WordPress Core.

A Gutenberg page is made up of blocks, and each block contains a particular type of content. Each paragraph or heading is a block, and so are images, lists, and galleries. As Gutenberg matures, new blocks will be added to extend the editor’s functionality. Each block offers tools appropriate to its contents in a pop-up menu: paragraph blocks provide text styling options and image blocks provide positioning and sizing options. Blocks can be moved around relative to each other to create custom page layouts quickly and intuitively.

Blocks are intended to take the place of shortcodes and other less-than-intuitive techniques for adding content to pages and posts.

Joen Asmussen, Design Wrangler at Automattic, expresses Gutenberg’s design goals in a recent blog post:

“At the core of the 2017 editor focus is the is idea of introducing blocks (or sections) which help “make easy what today might take shortcodes, custom HTML, or ‘mystery meat’ embed discovery”. How do we do that?”

Gutenberg is a product of the new focus-based development process announced by Matt Mullenweg at last year’s State of the Word address. Rather than focusing on fixed releases, during 2017, WordPress development will be focused around specific projects. The editor is one of those projects. A release-based schedule with fixed release dates is great for iterative improvement, but it’s not ideal for making deeper changes to software. Without the pressure of a release date and the ability to focus all their energy on single project, developers can make more revolutionary changes.

Posted in:
Content, WordPress

The popular comment platform will charge bloggers a monthly fee to remove advertising from comment threads.

The tide has turned against comments among some major publishers, but they’re still regarded by many as an essential part of the blogging experience. Although they can be a pain to moderate and they’re a magnet for spammers and trolls, most bloggers believe the community-building benefits of comments are worth the investment. Disqus, a cloud-based comment platform, is by far the most popular alternative to WordPress’ native comment system. Disqus is easy to use, fast, and has features that aren’t available from alternative comment systems.

When big publishers do choose to keep comments on their site, Disqus is usually where they turn. Disqus has always been free to use, but, starting later this year, Disqus will charge its users if they want to offer an ad-free experience.

We know that ads may not be a good fit for all publishers and all sites. For these publishers, we will provide a simple option to remove ads altogether. For an inexpensive monthly fee publishers will be able to completely remove ads and take advantage of all of Disqus’ basic features and functionality. We will release finalized pricing for this offering soon.

Bloggers will be able to use Disqus for “free”, but unless they pay the fee and opt-out of advertising, Disqus intends to monetize their comments.

It’s easy to see why Disqus wants to add advertising. The infrastructure necessary to support comments on hundreds of thousands of sites isn’t cheap. But understanding why Disqus is making the change isn’t likely to make publishers any happier about it. Publishers like to be in control of the content on their sites, and they also want a slice of the pie for any advertising displayed with their content. Disqus also faces the resistance that any company encounters when it takes once-free services and charges from them.

A few things to note here: if you’re running a blog that isn’t monetized, it appears you won’t be charged to opt out. But if your blog does run advertising, you’ll have to pay around $10 per month for ad-free comments. At the moment, it’s claimed that the adverts will mostly be for Disqus itself, but there’s no guarantee that will be the case forever.

If you’re unsettled by this change in Disqus’ policy there are plenty of alternatives, although none of them offer the full range of features that Disqus includes.

The most obvious alternative is native WordPress comments. WordPress comes with a built-in commenting system. It’s by no means as advanced as Disqus or the other alternative we’re about to discuss, but for smaller blogs, it’s perfectly adequate.

A more advanced alternative is the comment system included in the Jetpack plugin collection. It offers features that aren’t part of WordPress’ native comments, like social media sign-in. The ability to sign-in using social media networks is a big improvement over the native comments interface, which requires users to jump through hoops before they can comment.

Epoch is also a promising alternative to Disqus. Epoch is a JavaScript-based real time commenting plugin that uses WordPress’ native comment handling but provides a more advanced interface. Epoch combines the benefits of real-time updating with the ability to keep your comment data stored on your WordPress site, rather than on a third-party platform, which means you can use tools like Akismet for spam filtering.

If you’re fine with Disqus inserting its advertising into your site or paying to have them removed, there’s no real reason to migrate to another comment system, but it’s good to know there are alternatives if things change in the future.

Posted in:
Content, WordPress

A typical WordPress theme consists of the same basic components put together in novel ways. Almost every WordPress site has a logo, navigation components, blog posts, blog indexes, and so on. Many theme developers create their own spins on each of these components or adapt existing front-end frameworks to work with WordPress.

Rebuilding or repurposing is often not the best approach though. Building common components in-house duplicates effort that could better be spent building truly original custom functionality and providing added value to clients.

The WordPress Component Library, created by WordPress development agency 10up, is a collection of front-end components designed to be used in WordPress themes. Each component in the library provides commonly needed functionality that developers and designers can integrate into their own projects.

The Library is divided into UI, Content, and Navigation components. A standout member of the Navigation collection is an elegant lightweight responsive navigation menu implemented almost entirely in CSS (SCSS) and a small JavaScript component. After experiencing any number of glitchy “responsive” menu bars, I’m happy to see the release of an off-the-shelf component that just works.

Each component in the library includes minimal styling, so developers can build unique themes to suit specific projects. A key benefit of using a components library of this sort is that future maintenance is made substantially easier: developers can get up to speed on a site’s code base more quickly if it’s built from well-understood parts.

One of the outstanding features of the WordPress Component Library is that it’s built from the ground up to conform to the Web Content Accessibility Guidelines 2.0. Each component is designed to provide an accessible experience to users and work well with keyboard navigation and assistive devices.

Everyone wants to provide accessible websites, but complying with accessibility best practices can be time consuming. Many developers don’t have a well-developed understanding of accessibility issues. And when under time or budgetary constraints, accessibility issues fall by the wayside.

The WordPress Component Library gives theme developers a quick and easy way to build accessible WordPress-based websites using of-the-shelf components.

Much of the buzz around WordPress is focused on the new REST APIs, which give developers the ability to build WordPress themes and front-end integrations in any number of languages, but particularly in JavaScript. Any increase to the flexibility of WordPress is welcome. There are millions of developers who know JavaScript and don’t know — or want to learn — PHP. The REST APIs will invigorate an ecosystem that has become somewhat stuck in its ways.

But it shouldn’t be forgotten that WordPress is — at heart — a PHP application and WordPress professionals all over the world are intimately familiar with PHP and WordPress. Tools like the WordPress Component Library may not generate headlines, but they do provide useful tools that have the potential to improve the workflows of WordPress developers and help them build better sites.

Posted in:
Content, WordPress