Category Archives:
Content Archives

Getting a theme into the WordPress Theme Repository can give a big boost to a WordPress developer’s credibility, especially if it proves popular with WordPress users. It’s also a great way to promote a premium theme — many theme developers publish “light” versions of their theme for free to promote a premium version with more features.

But to get a theme into the WordPress Theme Repository, developers have to follow some strict guidelines. Some of the guidelines are commonsense coding best practices, but others are specific to the WordPress project and are made clear in the Theme Review Requirements document and the documentation for the Theme Check Plugin.

But some developers either aren’t aware of the rules or choose not to follow them. In a recent blog article, Carolina Nymark discussed the reasons some themes are rejected. Many rejections could have been avoided with a better understanding of the guidelines, so I’d like to have a look at five common mistakes WordPress theme developers should avoid if they want a smooth voyage into the WordPress Theme Repository.

Missing Escape Or Using The Wrong Function

Forgetting to escape user input is a common problem, and one that can have disastrous results for security. Cross-site scripting attacks are the number one security risk on the web, and failure to properly escape input causes cross-site scripting vulnerabilities.

The WordPress Theme Handbook gives clear guidance about which functions should be used and which shouldn’t, so it’s well worth spending a few hours familiarizing yourself with it before embarking on theme development.

Text That Isn’t Translation Ready

WordPress is used by hundreds of millions of people in almost every country in the world. That’s a huge number of languages that have to be supported. WordPress provides plenty of tools and guidance for internationalization, so there’s really no good reason a theme shouldn’t be translation ready.

Scripts Or Styles Not Enqueued

WordPress provides functions for adding JavaScript and CSS files to themes. It’s better to use these functions than to load the files using other mechanisms.

The typical WordPress site has a theme and many plugins, all of which might load JavaScript and CSS files. The enqueue functions make sure that everything works well together and that there are no compatibility problems.

PHP Notices, Errors, Or Warnings

This one isn’t too complex: if your PHP code throws errors or warnings, you’re unlikely to be approved to join the WordPress Theme Repository.

Duplicate Theme

Some developers submit themes that are already in the repository. As I said at the top of this post, getting a theme in the repository is good for a WordPress developer’s career, so there’s an incentive to pass off another developer’s work as your own. But copied themes will be found and rejected immediately.

All of this is straightforward stuff for experienced WordPress developers, but if you’re new to theme development, taking a close look at some of the theme development resources we’ve linked to here would be a fruitful use of your time.

Posted in:
Content, WordPress

Google has long been wise to ways of comment spammers, but that doesn’t stop many comment threads degenerating into spammy lists of “work from home” comments and link spam. Akismet and similar spam filters catch most of it, but judging by the sites I see every day, these filters let plenty of spam through.

Although many publishers have removed comments from their sites, largely because they don’t want to deal with spammers and other “problem commenters,” hundreds of thousands of bloggers allow their users to contribute to the conversation.

If you think having comments on your blog is valuable, you have to deal with the spam. I’ve found that one of the best ways to reduce spam is to close comment threads after a while. This works because the majority of comments are posted immediately after an article is published. Publishers only have to moderate comments for a short time, and spammers have less of a window to get their comments into the thread.

For a moderately popular post, there’s a clear pattern to comment posting. The peak is almost immediate: usually in the first one or two days after the post is published. If the article continues to attract attention, the plateau may continue for a few days, but it’ll eventually decline, and after a couple of weeks, comments are sporadic. The most valuable interactions usually happen right after publication.

Closing comments after a couple of week will reduce the total number of comments and limit conversations — some potentially great comments won’t be published — but publishers should balance the risk of restricting comments with the benefits.

A moderately active blog that’s more than a couple of years old may have hundreds or thousands of posts; some have tens of thousands of posts. Monitoring every one of those posts for spam comments is a full-time job, sometimes it’s several full-time jobs. Those resources are better invested elsewhere. Allowing comments for a limited period drastically reduces the number of posts that publishers must actively moderate.

In fact, what tends to happen is that older posts aren’t actively monitored. Comment spammers love this type of blog. They can slip spam onto the site in the confidence that no one will see it. For some types of spam — link spam in particular — spammers don’t care whether anyone sees it. What matters is the link from a popular site. This sort of spamming isn’t hugely effective — smart bloggers no-follow links in comments anyway, but that doesn’t stop spammers and their bots.

Closing comments on older posts does little to limit the contribution that readers can make to site’s community, while massively reducing the amount of spam that site owners have to deal with.

Many comment systems recognize the benefits of closing comments after a predetermined period. Disqus has a setting that allows publishers to choose a number of days before the thread is closed. WordPress’s built-in comments have a similar option; you can find the option under “Setting -> Discussion” in the WordPress admin dashboard.

Posted in:
Content, WordPress

As any blogger or publisher will tell you, managing publishing workflows takes a dedication to organization. There are any number of general productivity tools an editor might use, but if you’re managing a site that publishes multiple authors, a dedicated tool is the best option. A workflow management tool that’s integrated with your content management system is even better.

We’ve covered WordPress editorial calendars like CoSchedule and Editorial Calendar before, but I’ve avoided talking about Edit Flow. It’s an excellent tool, but since it was bought by Automattic, releases have been few and far between. Bug reports went unresolved, and the plugin wasn’t updated regularly.

This month, it seems that Automattic have started to pay attention to Edit Flow again. It received a new bug-fix release to address outstanding problems, and, after an intervention by popular WordPress news site WP Tavern, a project member apologized for poor communication and maintenance.

“Folks, we’re sorry that it looks as though we’ve abandoned Edit Flow. We certainly haven’t, and we should have at least updated the tested tag for the plugin as you rightly point out. We’ve done that today, as well as make sure Github and WordPress.org are in sync.”

Edit Flow implements a number of features that make it easier for editors to manage complex publishing workflows.

First and foremost, Edit Flow integrates an editorial calendar into the WordPress admin dashboard. The calendar allows editors to see upcoming articles at a glance, including their current status. Statuses are customizable, so each publisher can choose to implement statuses relevant to their particular workflow.

One of the most useful features of Edit Flow is editorial comments. Many publishers use Google Docs and similar collaboration tools while articles are actively edited, but it’s more convenient to bring the whole process into WordPress. Editorial comments facilitate communication between editors and writers and help streamline the process of shaping articles for publication.

In addition to a calendar view, Edit Flow also implements a Story Budget view: a list of upcoming stories that can be grouped and filtered according to author, date, category, and other criteria. If you make use of Edit Flow’s custom editorial metadata feature, that information can be integrated into the Story Budget.

Finally, Edit Flow includes a useful notification feature integrated with the plugin’s user groups. Custom notifications can be sent to users and groups both manually and when articles change status.

Edit Flow isn’t the slickest editorial workflow manager I’ve seen, but it’s a solid tool that allows publishers to bring the whole content creation and editorial process into WordPress.

Hopefully, Edit Flow will be more conscientiously updated in the future, and if that proves to be the case, it’s well worth trying if you’re struggling to manage your site’s publishing workflows.

Posted in:
Content, WordPress

If you’re a regular user of the WordPress editor interface, you might want to make your thoughts known by completing the Editor Experience Survey.

The survey, part of the WordPress project’s attempt to understand how WordPress bloggers and professionals use the tools WordPress provides shouldn’t take more than a few minutes to complete and will provide valuable information WordPress’ developers can use to focus their efforts as work continues to improve the editing experience.

The WordPress team doesn’t collect data from self-hosted WordPress sites, so it’s hard for them to know what users really want. Millions of people use WordPress every day, but without input, developers are working in the dark. Most WordPress users spend the majority of their time with WordPress using the editor. That’s not the case for WordPress developers and professionals, so it’s difficult for them to assess the pain points and needs of professional writers and bloggers.

As WordPress developer Morten Rand-Hendriksen pointed out a couple of months ago, there’s a considerable gap of knowledge and expectations between the average WordPress user and WordPress developers. The developers want to make the WordPress editor a world-class writing and publishing interface — it’s one of Matt Mullenweg’s focus areas for 2017. We’ve already seen some indication of where the editor is heading, but any extra information can only improve the final experience.

The survey includes questions about how WordPress users interact with the editor and which features they find useful, including whether they use the markup editor, which formatting features are useful, and whether the no-distraction interface is regularly used.

Of particular importance are questions concerning the accessibility of the WordPress editor. If you find that the WordPress editor doesn’t provide a positive experience when used with a screen reader or other assistive devices such as braille embossers, voice recognition programs, or screen enlargers, the WordPress team would love to hear from you.

It’s worth noting that the survey itself isn’t particularly friendly to those with accessibility issues, so Amanda Rush from the WordPress Accessibility team has written a blog post with some guidance for people with accessibility issues who want to complete the survey.

The team also wants to know about any plugins you install to change the functionality of the WordPress editor. Discovering how users modify the editor could give developers information they need to decide which feature to add (or to remove).

If you’re a regular user of the WordPress editor, I’d encourage you to take the time to add your two cents. In the absence of telemetry data showing real-world use, surveys of this type are hugely helpful to developers and designers. The results of the survey are likely to shape the future editing experience, so it’s well worth making your thoughts known.

Posted in:
Content, WordPress

Google has announced the retirement of its popular WordPress AdSense plugin, which was embraced by bloggers and publishers as a simple way to monetize content on WordPress sites. Existing ads aren’t affected, but within a couple of months, users will no longer be able to change the layout of their ads or visit the front-end of the plugin.

Advertising is the most common monetization strategy for WordPress sites, and Google’s AdSense the most popular advertising network. For non-technical site owners, the AdSense plugin offered a quick and easy way to include relevant advertising on their pages. Designed to be usable without requiring any coding expertise, ads were managed through a simple click and drag interface.

But the plugin hasn’t been updated for Google’s newest advertising products, and is being retired because it no longer offers the best experience to publishers or their visitors.

Google advises WordPress users to deactivate and uninstall the plugin, which will receive no further updates. At the time of writing, publishers have a couple of months to investigate alternatives — some of which we’ll discuss below. If you want to avoid disruption to your site’s revenue, make sure you have an alternative ready before removing the AdSense plugin.

According to the timetable published by Google, from the beginning of this month (March 2017), WordPress users will no longer be able to sign-up for AdSense using the plugin. From the beginning of April, the management of ad units and ad settings will be disabled, and from May, the plugin will no longer be supported.

It’s likely thousands of WordPress users will be impacted by the retirement of the plugin. We suggest that publishers and bloggers who rely on this plugin seek an alternative advertising solution as soon as possible. Google no longer supports alternative third-party AdSense WordPress plugins either, so simply switching to another plugin that offers similar functionality is not a viable long-term solution.

WordPress AdSense Plugin Alternatives

Although Google is retiring the plugin, it isn’t turning its back on WordPress users. The search giant’s official recommendation is that WordPress users embed advertising in WordPress text widgets. While this isn’t as intuitive as the plugin, it’s a usable solution that is well-documented in Google’s help pages.

Google’s QuickStart advertising is the least complicated way to replace some of the WordPress plugin’s functionality. With Quickstart, publishers simply add a JavaScript snippet to their pages and AdSense takes care of the rest.

Google also suggests page-level ads as an alternative, a new advertising format designed to be particularly friendly for mobile users. Page-level ads include anchor ads, small pop-up banners at the bottom of the screen, and vignette ads, fullscreen advertising that appears between the pages of your site.

For WordPress users looking for a low-friction way to include advertising on their site, QuickStart and page-level ads are worth investigating.

Posted in:
Content, WordPress

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