This extended category features quality articles about developing clean, smart and fast websites with WordPress. The articles are intermediate level, with an emphasis on practical, hands-on discussions related to WordPress. Curated by Daniel Pataki. Subscribe to the RSS-Feed.
A few months ago, I ran an experiment to see how much faster I could make one of my websites in less than two hours of work. After installing a handful of WordPress plugins and fixing a few simple errors, I had improved the website’s loading speed from 1.61 seconds to 583 milliseconds. That’s a 70.39% improvement, without having made any visual changes to the website.
According to a 2009 Akamai study, 47% of visitors expect a page to load in under 2 seconds, and 57% of visitors will abandon a page that takes more than 3 seconds to load. Since this study, no shortage of case studies have confirmed that loading time affects sales.
“Danger: malware ahead!” and “This website may harm your computer” are the two sentences that I hate most and that I don’t want any of my clients to see when they open their website. If you have seen any of them on your own website, then I’ll bet you still remember your panic attack and how you struggled to get your website up and running ASAP.
Many great articles show how to prevent a website from being hacked. Unfortunately, unless you take it offline, your website is not and will never be completely unhackable. Don’t get me wrong, you still need to take preventive measures and regularly improve your website’s security; however, responding accordingly if your website does get hacked is equally important. In this article, we’ll provide a simple seven-step disaster-recovery plan for WordPress, which you can follow in case of an emergency. We’ll illustrate it with a real hack and specific commands that you can use when analyzing and cleaning the website.
When people talk about WordPress security, file permissions and ownership are usually the last thing on their minds. Installing security plugins is a good practice and a must for every WordPress website. However, if your file-system permissions aren’t set up correctly, most of your security measures could be easily bypassed by intruders.
Permissions and ownership are quite important in WordPress installations. Setting these up properly on your Web server should be the first thing you do after installing WordPress. Having the wrong set of permissions could cause fatal errors that stop your website dead. Wrong permissions can also compromise your website and make it prone to attacks.
The latest version of WordPress named "Smith" was released yesterday which brings us another round of core changes. This time, the team worked mainly on the back-end editing and admin functions, such as a big TinyMCE (visual editor) update, gallery previews, media playlists, an improved widget UI and live theme previews (only to mention a few). Here's what you need to know about the major changes in WordPress 3.9.
While the old widget interface set the standard for drag and drop UI when it was introduced, it was time for an overhaul. The developer team took the Widget Customizer plugin and essentially built it into the core.
If you've searched recently for tips on optimizing WordPress’ performance, then you have definitely come across various techniques that people recommend.
These include all sorts of caching mechanisms, such as reverse proxies, object caching and cache plugins, CSS minification, using sprites for images, and so on. All of them are viable and effective ways to speed up a WordPress website’s performance. However, be careful when implementing any of these techniques, and always test their effect on your particular website.
WordPress has come a long way since its genesis in 2003. Once reserved for humble blogs, it now powers websites for some of the world’s largest companies and is even being promoted as a platform to power the next generation of Web apps.
As a result of this increasing popularity, over the last couple of years my team and I have been regularly tasked with building ever more complex WordPress websites and apps. As the sizes of these projects increased and our team grew, however, we noticed that keeping the various dependencies of a given project in sync across our development team was becoming increasingly difficult.
2013 was a busy year for me for conferences and travel. It was also the year I attended my first (and second) WordCamp. The first was WordCamp UK in July, where I met Mike Little, one of the two co-founders of WordPress.
Three months later, I was honored to meet the other co-founder, Matt Mullenweg, twice in three weeks: at WordCamp Europe in Leiden, and at The Summit. I was lucky enough to have both Matt and Mike participate in interviews for this post about WordPress, including its history, community and future.