Category Archives:
Wordpress Archives

Matt Mullenweg has announced that from WordPress 4.8, which is expected to be released later this year, WordPress will no longer support Internet Explorer versions older than IE 11. Microsoft only supports IE 11, but WordPress supports IE 8, 9, and 10 because a small proportion of its users remain on older versions. In March 2015, Microsoft announced that the modern Edge browser would replace Internet Explorer on newer versions of its operating systems.

For a project with as many users as WordPress, backward compatibility with older software is both necessary and problematic. Even though only a small proportion of WordPress users manage their websites on older browsers, that proportion may translate to millions of individual users. Corporate policy and government policy or a lack of access to up-to-date hardware and operating systems means people may not be able to use the newest versions of software even if they want to.

But supporting older browsers has a cost for developers and users alike. If features must be compatible with older browsers, developers are obliged to avoid modern tools, libraries, and language capabilities, which limits new features and constrains the experience developers can build.

It’s unsurprising that the ending of support for older versions of IE was met with universal praise in the WordPress developer community. If developers have to support older versions of IE, they can’t take advantage of the newer features available in more modern browsers.

“Depending on how you count it, those browsers combined are either around 3% or under 1% of total users, but either way they’ve fallen below the threshold where it’s helpful for WordPress to continue testing and developing against. (The numbers surprised me, as did how low IE market share overall has gone.)”

This issue came to a head with the planned changes to the WordPress Editor. To build the editing experience Mullenweg and the WordPress developers want, they need to be able to use modern web technologies that aren’t available on older browsers.

Internet Explorer 8 was introduced in 2009, followed by IE 9 in 2011, and IE 10 in 2012. Five years is a long time on the web, and the state of the art in web technology has advanced enormously in that time. Older versions of IE aren’t capable of offering the experience modern web applications aspire to. By dropping support for older versions, WordPress’ developers are free to make use of recent innovations without having to test every change for compatibility with legacy software.

It’s worth emphasizing that WordPress won’t stop working on older versions of IE: functionality that works now should continue to work, but new features will not. And over time, the experience offered by unsupported browsers will stagnate.

Posted in:
Content, WordPress

WP-Base-SEO is a fake WordPress plugin that security researchers have found installed on over 4000 WordPress sites. WP-Base-SEO is a copy of a legitimate WordPress SEO plugin with added malicious code so the attacker can control infected sites.

When a hacker compromises a WordPress site, standard operating procedure is to inject malicious PHP or JavaScript code. The attackers’ code lets them access the site in the future and hijack its resources and traffic. But foreign code is easy to spot if you know what you’re looking for. A security researcher or automated malware scanner will find obviously out-of-place code quickly.

To avoid being discovered, the creators of WP-Base-SEO are using it as a Trojan horse. For the most part, it looks like a legitimate WordPress plugin. The difference lies in a few tweaks that allow the hackers to execute arbitrary code at will.

To see if your WordPress site has been infected with this malware, look in its /wp-content/plugins folder for directories containing “wp-base-seo”.

It appears the plugin is not being installed by WordPress users. Botnets trawl the internet for vulnerable WordPress sites, hack them, and inject malware. In this case the malware is hidden in a WordPress plugin. This technique depends on the availability of insecure sites: those where WordPress, plugins, and themes haven’t been updated to a recent version.

Many of the sites infected with WP-Base-SEO also have older versions of the RevSlider plugin installed. Older versions of RevSlider contain a critical and easily exploited vulnerability. It’s believed that the RevSlider vulnerability was the vector for the Panama Papers leaks. The attackers are exploiting the RevSlider vulnerability, installing their malware plugin, and using it to control WordPress sites.

The best way to secure your WordPress site is to ensure it’s always kept up-to-date. WordPress Core, plugins, and themes should be updated to the most recent version. There’s a wrinkle where RevSlider is concerned because it’s often bundled with themes and only updated when the theme’s developer chooses to do so. If you have any doubt, contact your theme’s developer.

In this case, the malicious plugin is installed by the attackers to hide their presence, but it’s not unusual for criminals to manipulate WordPress users into installing malware-infested plugins. That’s why it’s important to only install plugins from trusted and reputable sources. If you have any doubts about whether a plugin or theme comes from a trustworthy source, do not install it.

Pirated premium plugins are a particular favorite of criminals. They take the code from a genuine premium plugin, add malware to it, and make it available for free. As a general rule, avoid downloading plugins from anywhere other than the official WordPress Repository, well-regarded theme and plugin marketplaces, or a reputable WordPress developer’s website.

Posted in:
Content, WordPress

A huge botnet of home routers has targeted WordPress sites with brute-force attacks over the last few weeks. Brute-force attacks are a risk for WordPress websites with insecure passwords, and they can cause problems even if a site has secure passwords by consuming a significant proportion of its resources.

A botnet is a collection of compromised internet-connected machines under the control of a malicious actor. Botnets are nothing new, but until recently, creating a large botnet was a difficult technical challenge. They were usually made up of hacked Windows PCs. Attackers compromise PCs and install malware, which is used to control the machine. Botnets are used for a wide variety of online crimes, including brute force attacks, distributed denial of service attacks, and spamming.

But in recent years, it’s become more common to see Internet of Things devices used in botnets. In this case, home routers shipped with vulnerable software accessible to the internet. You can see the full technical details in this WordFence post, but, in a nutshell, the routers expose a web server so that ISPs can send instructions to the device. Unfortunately, the web server is easily hacked, allowing criminals to install malicious software.

Tens of thousands of these routers have been used to target WordPress sites with brute-force attacks. Brute force attacks aren’t particularly sophisticated; they simply attempt to login to WordPress sites with guessed username and password combinations. Criminals know which passwords people are most likely to use, which increases their chances of finding the right combination.

Once the attackers figure out a valid username and password combination, they are able to take over the site and install software, deface pages, redirect users to malware sites, send spam, and so on.

If a WordPress site uses strong passwords on all accounts, the chance that a brute-force attack finds the right combination of credentials is minute. Brute-force attacks have an extremely low chance of success against properly secured WordPress sites. However, it’s impossible to guarantee that every user with an account understands how to create and use a decent password, so the best way to combat brute-force attacks is two-factor authentication.

Two-factor authentication combines the traditional username and password with a second factor: usually a one-time code delivered to a mobile device. Without the one-time passwords — which can only be used for a short period of time — the attacker will not be able to authenticate even if they manage to guess the username and password. Two-factor authentication effectively mitigates brute-force attacks.

There are several excellent two-factor authentication plugins for WordPress, including Duo Two-Factor Authentication and Google Authenticator – Two Factor Authentication.

But there remains the problem of resource use. Every time a WordPress site rejects a login attempt, resources are consumed. If a botnet decides to make thousands of login attempts in a short period of time, a substantial proportion of the site’s available resources can be wasted.

To avoid that happening, WordPress users can install a rate limiting plugin like WP Limit Login Attempts, which limits the number of failed login attempts that can be made from an IP address. Rate limiting isn’t a surefire way to beat botnet brute-force attacks, botnets have IPs by the thousand, but it can reduce the resources consumed by malicious login attempts.

Posted in:
Content, WordPress

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