XML-RPC is a WordPress API that allows WordPress site-owners functionality, while on-the-go. But how does it affect WordPress sites’ security?

XML-RPC attack_WordPress mobile

What is XML-RPC, and why is it such a big deal?

The ‘XML-RPC’ is an API that enables developers create WordPress ‘apps’ (like clients, plugins and themes), that allow you to make remote HTTP requests to your WordPress site.

This means, as a WordPress site owner, if you used a plugin or client that had WordPress XML-RPC support, you would be able to perform a number of functions without actually logging in to your WordPress site.

Some of the functions you would be able to perform on your site with these plugins or clients would include:

  1. Post-related functions like creation, publication, edition and deletion
  2. Media-related functions that include uploading files, and viewing the media library
  3. User-related functions, such as editing your profile, getting a list of authors for a post, etc.
  4. Comment-related functions such as listing comments, and editing them

There are a number of Weblog Clients and WordPress plugins that allow you to do this. Some of the popular ones include the Jetpack plugin for WordPress.org, clients like rubypress, and WordPress Sharp; and even WordPress’ own app for both Android and iOS. Since all of these functionalities make life easier, WordPress has had XML-RPC enabled by default, since WordPress 3.5. (WordPress’ latest update was WordPress 4.6, so it’s been a while). Obviously these tools would still need you to input your WordPress admin username and password for them to work, so they seem safe.

How does it pose a security risk?

However,  anyone can use the XML-RPC API to make these requests. Using the API, a script can make multiple requests simultaneously to your site. This makes it a convenient choice for attackers who would want to launch a attacks against your site.

One application for this functionality, would be to try with different combinations of usernames and passwords while having substantially lower chances of getting detected. This makes XML-RPC  an ideal approach for Brute Force attacks.

Unlike hacks that focus on vulnerabilities in software, a Brute Force Attack aims at being the simplest kind of method to gain access to a site: it tries usernames and passwords, over and over again, until it gets in. Often deemed ‘inelegant’, they can be very successful when people use passwords like ‘123456’ and usernames like ‘admin.’

Even if you have passwords consisting of a minimum of 10-15 alphanumeric characters and special characters, there is one more threat – DDoS.

DDoS is a type of Denial Of Service (DOS) attack where many infected websites or systems are used to attack a single website and bring it down, by overwhelming the target website with requests. This results in the website’s server denying service, as a result of shutting down (… hence the term).

Actually, in March 2014, a number of WordPress sites experienced an attack involving ‘pingback’. Pingback, is an XML-RPC functionality (especially on WordPress), that allows you to see where links to your WordPress posts are used. This is done by the sites with shared links pinging the source of the link. The source site then replies (or pings them back) with the live link (so that if the post is taken down, it would show you a ‘404 error’, or if it’s been updated, the newer version of the post would be displayed). So when attackers used XML-RPC requests to perform the DDoS attack in 2014, they exploited the pingback functionality, and used thousands of other sites to ping victim sites. Once all the thousand sites starts pinging the victim site simultaneously, the server ran out of resources and the site went down.

Do you have to disable XML-RPC?

Well, it depends. WordPress identified the XML-RPC API abuse, and has made its laws stricter. Plugins like Akismet that help detect spam, have also gotten better at detecting attacks like the one involving pingback. But the bottom line is that there is no way to make your WordPress site 100% attack-proof.

So yes, an easy way to make your site safer, would be to disable the XML-RPC API. For this, one can use  security plugins, such as iThemes Security (formerly Better WP Security), or NinjaFirewall.

However, before making this choice,it is very important to understand that turning this API off can affect the functionality of some plugins and apps that you might be using in conjunction with WordPress. This will disable the WordPress mobile app and severely affect the functionality of plugins like Jetpack, from accessing your site.

This is why it’s always important to have several backups of your WordPress site before you test the change to see if you’re okay with it. If you’d rather keep the functionality on, you can choose from a previous version of your site, and roll back changes to a fully-functional version of your site.

Making an integral change to your site is never easy, but it’s always better when you have all the facts. Which choice have you gone with, on your WordPress site? Let us know in the comments!

At BlogVault, we recently spoke to Rahul Bansal, founder of rtCamp; Asia’s first WordPress.com VIP partner agency. He shares his convictions, struggles, the formation of rtCamp, the growth story that eventually led to this watershed achievement, and his thoughts on ethics & business practices.

India is waking up to the presence of WordPress in the digital landscape now. On the cusp of this realization, rtCamp has emerged to become the very first WordPress.com VIP Partner in Asia. It is a prestigious featured partner program that has till now picked only 12 agencies; including rtCamp, as partners worldwide.

To those in the Indian WordPress community this achievement is definitely a breath of fresh air, considering the unwanted reputation agencies from South Asia carry in global WordPress(WP) market.

As part of the same WP community, and as global leaders in backups & security, we at BlogVault wanted to record this achievement. The premier WordPress agency on the continent has definitely crossed a threshold and its founder joined us recently to trace his journey.

Rahul Bansal answers questions on his convictions, struggles, the formation of rtCamp, and the growth story that eventually led to this watershed achievement.

A Decade Ago: Building up Skills

Rahul’s journey started almost accidentally as he took up blogging during his engineering days, purely to follow a friend he looked up to. The rampant focus on remuneration packages instead of work profiles pushed him away from conventional job interviews during campus placement.

“I didn’t want to join any company; hence I took up M. Tech. It was essentially an escape”, says Bansal. Rahul says that he got more free time during his M. Tech.  He began to enjoy blogging; and the journey took an interesting turn as he discovered Google AdSense.

The revenues from AdSense were sufficient to convince Rahul that he could take up blogging professionally. It was this decision that would eventually take him away from blogging and towards developing on WordPress. But, more on that in a bit.


The Family Front: A Quintessentially Indian Story

Rahul was thinking of becoming a professional blogger in the India of 2006. That too, after his engineering. It is not an easy switch to sell to our parents even now, so it could not have been easy then!

Rahul admits this to be a tough period in his life. However, he found an interesting analogy to help him. “…I used to explain my profession to my folks, especially the older ones, with the analogy of a news agency. [the conversation would go something like this]”

“Do you read a newspaper?”


“How much does a newspaper cost?”

“1 or 2 rupees!”

“Is that enough to run a news agency?”

No! They make money from ads”

“I do the same thing. I run a newspaper online and make my money from ads.”

For the most part, that was that, and Rahul was a professional blogger. He suspects that the point that eventually convinced his parents was that he was no longer taking money from them.

The decision to turn a professional blogger also meant that he had to prepare to do the job well. As part of this project, blogger Rahul turned to WordPress to customize his site  and gain more control over his content and its presentation. This turn, which came out of a necessity, would lead him to be fascinated with WordPress, the CMS’ ease of use, and the many possibilities the platform presented. All of these factors planted the seed of freelancing as a WordPress web developer in his mind; although he wouldn’t give up blogging straight away (after all it was a steady source of income and his blog was growing in popularity).


The Freelance Route to the rtCamp Journey

Perhaps one could read into Rahul’s approach to freelancing, and see the success to come. He says, “I was already making money from the blog. It was because I wanted learn many things on WordPress that I began freelancing.” So, he says that he made a list of things he wanted to learn in WP and went after projects with “realistic challenges”, “realistic deadlines”, and “realistic value” that would help him learn those skills.

The blogging trails paid rich dividends during his freelancing days too. There cannot be a better example for how popular his blog- Devil’s Workshop, was at the time, and for how having rich content can help any business more than the following story. Rahul recollects that he was once awarded a project before the details were finalized. He was surprised and inquired the client. He says, “The client only said that You are running such a successful blog, you must be doing something right!” Rahul says, “On the internet, it is your skills, not your academics that speak for you. That is how the internet works.”

The blogging trail combined with his desire to learn and grow continuously meant that Rahul built a successful client base as a freelancer. His list included clients from around the world. Although, he is quick to point out that this diverse client base wasn’t planned; instead he says “I just went after projects and opportunities [which interested me].”

This approach proved to be financially successful as well. Rahul remembers how almost all of his clients wanted to work with him again after the first projects were completed. This ensured that the workload burgeoned to the point that he couldn’t handle it alone.

Rahul’s growth in his individual professional life coincided with the 2008 global recession. During this period many of his friends could no longer depend on the giants of the IT industry to guarantee them a job. He pitched the work he was doing to them and when some of them showed interest, he trained them. The burden of his workload decreased and the business expanded. This expansion would eventually be titled rtCamp but that was still a few months away.

So far Rahul’s decisions don’t seem obvious to anyone. Turning away from a career after engineering. Convincing his parents about becoming a professional blogger; and taking up freelancing projects as a web developer to learn a CMS that; in 2006-2008 India, was not nearly as popular as it is now.

Another one of such decisions was that, very early on, he decided that he would work solely on WP. This decision too was born out of his conviction, “I believe we should only develop on software we use.” “To date, even out of curiosity, I haven’t installed Joomla or Drupal” explains Rahul. Hence he was a WordPress freelancer much before the marketplace emerged for the title in the country. Following his convictions, as Rahul himself states was a “good decision [looking back].”


rtCamp: The Core Values

The more we spoke the more we realised that Rahul’s freelancing days would come to shape his own values and lay the groundwork for the path rtCamp would take. During his period as a freelancer, Rahul was not only fascinated with acquiring skills but was interested by the open-source platform; and the community that came with it.

In that period he participated in many meetups. The “un-conference” culture of the WordPress community and the open-source movement charmed him. Going along with this, he wanted a work environment where “everyone respects everyone”. The value he derived from camps, and his “hunger for equality”; as Rahul puts it, eventually led to ‘rtCamp’.

rt stands for roundtable, a reference to the famous roundtable of the noble knights in the Arthurian legend. The ‘Camp’ part comes from the desire to replicate the community driven culture around Bar/Word/php camps which Rahul used to attend- an environment where everyone participates, speaks up and takes ownership.  It was an idea he had come to cherish. “I liked the unconference culture and wanted the same in my organization. I believe everybody must speak and express themselves rather than simply taking orders.” says Rahul.

So it is not a hyperbole or an act of taking credit in hindsight when he says, “Looking back you can always connect dots. Our core values have made us the kind of company we are today. One who loves WordPress, open-source, and contributes to the community”

He says we always encourage all ‘rtCampers’ (as the people who work at the agency are called), to participate in the community, whether it is by attending WP meetups, WordCamps or by other means.

On Landing Big Clients:  The Case of Geometric

The points about the “un-conference” culture, and the encouragement for people to take ownership, shine through when you ask Rahul about how rtCamp landed its first big client- Geometric Global.

He began his response to us by crediting rtCamp’s then Head of Marketing, Gajanan Sapate.

Sapate suggested building rtCamp’s presence on LinkedIn as a WordPress Agency. Although Rahul wasn’t keen on the idea Sapate went ahead without his approval, Rahul recollects. “That is what the round table culture is all about,” he says proudly.

Around the time, Geometric Global were on the lookout for a WP agency. They are an MNC and as Rahul pointed out they have offices around the world. The website part of the business however was managed out of Hinjewadi near Pune. They wanted a local vendor to build their site on WP. Decisive on these two points- location of the vendor & the CMS, they went looking for a WP agency on LinkedIn.

This was around 2011-12 and Rahul suspects that Geometric Global’s search for a WP agency on LinkedIn resulted in only rtCamp’s name popping up as there were no other WP agencies at the time. Sapate’s initiative had paid off and only time would reveal how handsomely it had paid off.

For what seemed like a pleasantly fated start, the relationship between Geometric Global and rtCamp was anything but that. rtCamp at the time was a small agency. Despite its size, some members of Geometric Global were keen on working with them. The reason for this was once again; among other points, the Blog- Devil’s Workshop. Rahul remembers that some members of Geometric Global were already familiar with his blog when they approached rtCamp. Apart from this, rtCamp’s plugins on WordPress.org, open-source projects, and participation in and contribution to the WP community were all reasons in their favour.

Even today, Rahul suggests that younger agencies looking to build a reputation with WP must show their love for the CMS by making contributions to the community. This is not simply a pedantic statement. In fact, WordPress.com announced rtCamp as a VIP partner with an article, where rtCamp’s “record of community engagement” was specially mentioned as the reason for extending them VIP partnership.

While the above points were in favour of rtCamp, some other points were not. For starters they were not used to a seemingly long sales cycle of around 6 months. During that phase, Rahul recalls that most, if not all of rtCamps’ sales cycle lasted a maximum period of 2 weeks. This shift proved to be quite frustrating as Rahul mentions. Along with this, rtCamp was also not familiar with many processes that were required by enterprise level clients. They failed many checks like access control (magnetic strip cards) among others.



This meant that, while rtCamp was optimally placed to deliver a project which was based on WordPress for Geometric Global, they were not aware of many requirements and practices of enterprise clients. Both parties, Rahul admits, acknowledged these points. Rahul remembers being upfront in his approach when it came to selling to his first big client, and they eventually landed the project.



Even after this however, the demands of servicing an enterprise client was taking its toll on a small but growing agency. One of the reasons for this was that rtCamp billed Geometric Global like all other of their other clients. This was unsustainable as Rahul himself admits. Geometric Global’s value at the time was greater than the combined value of all their other clients. The demands were also greater to go along with this.

All these struggles meant that Rahul was unconvinced with the idea of taking on enterprise clients. He says that for about two years after signing Geometric Global he did not try to sign any other enterprise clients. During this 2 year period however, their relationship with Geometric Global evolved and stabilized. It wasn’t easy as Rahul recollects, “Even after [we signed them] there was steep learning curve.” Geometric Global’s willingness to work with rtCamp and train them on certain issues sustained the work Rahul recollects. In fact, the suggestion to increase the price too came from Geometric Global Rahul mentions. This maturing relationship eventually convinced Rahul that enterprise level clients were the way forward for rtCamp. It seems that rtCamp hasn’t looked back since.

Mission “WordPress.com VIP Partner”: A New Year’s Resolution

There is a diffident smile on Rahul’s face when he mentions that at an rtCamp New Year’s party he announced that the agency would become a WordPress.com VIP Partner. While he admits that he didn’t have very specific roadmap in mind then, he planned for it every day for the last 18 months.



Part of the plan was to deliver VIP grade code to their clients before they had contact with WordPress.com. Rahul surmises, “Most people change when there is a need to [do so]. We started coding at VIP standards when our clients were not asking for it.”

Such preparation has paid off very well. Rahul says that when they got their first VIP project from WordPress.com, “The code was approved in the very first round!”

However, if you ask Rahul why he aimed to become a VIP partner, then the story takes a more poignant turn. He had noticed how clients abroad would switch off when they knew an agency was from South Asia. Rahul recognised that it would be hard for everyone to go through rtCamp’s work. Having a symbol of quality would bypass some of these issues he though, and becoming the first VIP partner in Asia seemed like the solution.

Unique Growth Story of an Indian Agency: Way forward for Indian WP communities

The challenges were many and in that context the growth of rtCamp is surely a unique story. This is so, not just because of it has done but also because of how the agency has done it. It is one thing to come up with a name or a set of values, and another to thing to stand by and act according those convictions when you know they aren’t going to work in your favor. This is what Rahul has done.

He recollects a time when a Project Manager at rtCamp made an error in scoping the document. This led to a verbal commitment to deliver the project on a deadline. When the D-day neared, the error surfaced. Rahul recollects how he not only admitted the error straightaway to the client but resolved to work for the remaining duration of the project for free. “If we made a mistake, then we should pay for it. Why should the client suffer?”, Rahul asserts.


Although the client was very pleased with the results when the project was eventually completed and offered to compensate rtCamp, Rahul says that he refused. He reasoned that they might forget the lessons they learned if they accepted payment.

These actions though exemplary, almost drove Rahul to bankruptcy. The client was one of their biggest at the time and working for them at no cost meant Rahul had to pay a heavy price. If not for a friend who loaned him some money, Rahul would not have been able to even pay the salaries. These decisions are only more admirable because of the accompanying circumstances. Just before the incident came to light Rahul had got married. A new phase of his personal life began with a crisis in his professional one. Although it looks like he took a big gamble; and he did, Rahul simply says, “It was about doing the right thing.”

It is this combination of technical expertise, professionalism and a high level of adherence to their core values and ethical business practices that sets the foundation of rtCamp’s success. It is also a good sign-post for younger WP agencies to begin charting their paths.

The Future

“Becoming a WordPress.com VIP partner is the start of something,” Rahul says. He is not about to rest on his laurels but, “… everything we do must be better now … and we’re working harder to get everything right.” Rahul says he feels more responsible now as there is a sense of representing the Indian WordPress community.

At BlogVault, we wish Rahul and rtCamp all the very best and we look forward to seeing the next big thing from them.



Remote/Local File Inclusions are common attacks on WordPress sites. However, it is Arbitrary Code Execution, that actually does the real damage to your site. Inclusion attacks are generally used in tandem with Code Execution; and learning how they work is key to preventing them.

We’ve been in the WordPress site recovery business for a while now. Over the years, we’ve had a number of our customers come to us with questions about their websites when they noticed something weird, or in the most severe cases, when they lost admin access. We’d try to help out, and most of the time, discover that their site was hacked.

One of the most lethal ways WordPress sites get hacked, in our observation, has been via file inclusion and code execution.

We’ve covered the same attacks and their most well-known approached in a previous piece about the most common attacks on WordPress sites, but with this piece, we hope to help you understand it in a little more detail.

To understand how these attacks work, one of the first things you must be aware of, is they involve PHP code. This is because PHP is a language that servers run on, and it’s also what WordPress is built on. PHP files aren’t just files; they’re executable code. This means that if you have a PHP file and you just access it on your WordPress site, it runs the code it contains.

This is why File Inclusion and Code Execution attacks go hand-in-hand. Once an attacker gets an infected PHP file to your website’s server and runs it, they could use it to do anything with your website.

File Inclusion and Code Execution attacks make your website a puppet in the hands of the attacker
File Inclusion and Code Execution attacks make your WordPress site a puppet in the hands of the attacker

WordPress plugins allow for File Inclusions in order to ‘include’ (or refer to) files on, or outside of the website’s server.

  • Any file that is included from outside your website’s server is said to be ‘remote’. This means even you, as the website admin, access your website remotely… since you’re not accessing it from within the server.
  • Any file that’s included from within your website’s server itself (like the files in your website’s database, or files like wp-config.) is known as a ‘local’ file.

The problem arises when plugins that allow website admins and users to access files (remotely, or locally) exhibit loopholes. These loopholes are exploited by hackers to include malicious files, that can be used to hijack the website’s server. However, simply including a static file (one that doesn’t execute code, e.g. a JPEG file) doesn’t cause damage. This is why most File Inclusion attacks involve PHP files.

Although both Remote and Local File Inclusion attacks have technical differences, both of them are used to perform Arbitrary Code Execution. This is what allows hackers to run their bad code on your server, and take control of it.

So in short, this is how these attack works:

  1. Access: First an attacker would need to get a vulnerable site to ‘include’ a malicious PHP file. This could be done directly (which would need access to your site’s server), or via a WordPress plugin that allows users to ‘include’ files from other locations. Obviously this is a very dangerous situation, especially for any website that allows files to be included without first validating the kind of files accepted.
  2. Execution: Once file is uploaded, the attacker could just access the file to execute it.

Remote File Inclusion

Websites that allow for Remote File Inclusion usually have a way to check where the file came from. Most of the time, they have a whitelist of websites; only files from these URLs are allowed, and others aren’t.

Here is the general process of an Remote File Inclusion attack:

The life-cycle of a Remote File Inclusion attack
The life-cycle of a Remote File Inclusion attack


One of the most famous examples of a Remote File Inclusion exploit combined with Arbitrary Code Execution, was that of a WordPress plugin called TimThumb. TimThumb was used to edit pictures on the fly, without having to open an image editor. Understandably, a lot of websites used it in implementing thumbnail-size images for their users’ avatars. TimThumb’s whitelist consisted of a number of image-hosting websites (like flickr.com and imgur.com). However, the vulnerability in the plugin was that it didn’t verify if the file URLs actually came from those locations: It only checked the words in the URL (or strings) to see if the images looked like they came from a whitelisted site.

Here’s how the TimThumb exploit took place:

A generic example to demonstrate how the TimThumb attack took place
A generic example to demonstrate how the TimThumb attack took place

Once the attacker executed the malicious file on the server, the damage caused depended on what the file was created to do. Since TimThumb was such a widely used plugin, millions of sites were affected.

Local File Inclusion

Local File Inclusion is a little more complex than Remote File Inclusion, because an attacker has to first create an executable, malicious file on the website’s server environment. This is mostly done by exploiting another vulnerability on the website (say one that allows SQL Injection), by which the hacker can access the website’s server. Once the hacker accesses the server, they can do anything, even override controls to make sure that a malicious file can be created on the server, or uploaded to it. The file can then be executed by just accessing it.

Recently, this vulnerability was observed on the Easy Forms for MailChimp WordPress plugin (v The plugin allowed unlimited forms to be added to WordPress sites, of many different formats. However, the its vulnerability allowed an attacker to upload a PHP file using these forms. Once this was done, the file would get stored locally on the website. The attacker could then execute the arbitrary code.

Arbitrary Code Execution

A hacker’s aim in both File Inclusion attacks, is to execute arbitrary code on the website’s server.

Arbitrary Code Execution though, doesn’t have to only start with File Inclusion including files… in fact a lot of attacks (like Injection attacks) could be used in conjunction with running code arbitrarily.

One way that Arbitrary Code Execution was exhibited, was via WordPress plugins that cache dynamic content, like WP Super Cache. Plugins like these help reduce WordPress sites’ load times for visitors. One of the ways this is achieved, is by using special tags to tell the difference between static content (content on the site that doesn’t change), from dynamic content (that is executed server-side, and is interactive).

Here is how the attack worked:

How Arbitrary Code Execution took place in conjunction with SQL injection via a vulnerability on WP Super Cache
How Arbitrary Code Execution took place in conjunction with SQL injection via a vulnerability on WP Super Cache

While this is only one way hackers were able to execute code arbitrarily on the website’s server, there are a variety of ways to achieve the same result. The reason hacks have become more complex, is because hackers keep modifying how they way they exploit vulnerabilities.

There are a few ways to secure your site though. One way is to modify your WordPress site’s .htaccess files to prevent uploaded PHP files from being executed, and to update your themes and plugins. Another way is and to employ good security measures, like a WordPress firewall, or an intelligent antivirus.

Themeco Hosting users can now enjoy the premium WordPress backup service from BlogVault. This partnership allows all users of Themeco Hosting to utilize BlogVault’s expertise, at no extra charge.

As advocates for best practices in WordPress backups and security, we are certainly proud of this partnership with Themeco Hosting which makes professional backups a part of the hosting service.

BlogVault WordPress backup at no extra cost for Themeco Hosting users
Themeco Hosting users can now get WordPress backup by BlogVault at no extra cost


A Quick Intro to BlogVault

To all the new users, welcome!

Our service, stores up to 30 days of backups guaranteed. You can find all the versions listed in order with date, time and changes. So, when the time comes to restore or migrate your site, you can choose the desired version with ease.

Users will be happy to know that apart from backups following WordPress best practices, BlogVault’s service comprises one-click restores and one-click migrations along with a host of other comprehensive features that are intuitive to use.


A Comprehensive Dashboard

The dashboard is designed to be pain-free and is a single-point access to all options related to backups, restores, and security settings; so that you can focus on creating and managing content in a dynamic & creative environment.

You can login to your BlogVault dashboard anytime to find all your files and tables, & find out which ones are excluded from backups. In the same list, you can also add any excluded site to backups or download any on or all of the files/tables.

To do this simply click on the files/tables and at the end of the list click ‘Add to backup’. On the other hand you can select the files/tables with same method and at the end of the list click on ‘Download’. You have complete access to and control over all your files and tables.

With that we welcome Themeco Hosting users to BlogVault and look forward to a fruitful partnership.


About BlogVault, & Themeco

BlogVault is a Bengaluru based, five-year old tech company developing premium backup & security solutions.

Themeco Hosting is brought to you by the same people behind the creative WordPress theme- X, and the versatile page builder Cornerstone.

One of the most powerful ways to make your website more search engine friendly, is to use a site map. But what are site maps, and how do you create one for your site?

What is a site map, and why is it important?

Search engines like Google, Bing, and Yahoo crawl through the contents of a WordPress site in order to index all the data present on the site. They use different mechanisms to identify different pages/URLs on the website. One of the most powerful ways for crawlers to index your WordPress site is through site maps (or sitemaps).

Having an XML site map on your WordPress site makes it easier for search engines to crawl it.
Having an XML site map on your WordPress site makes it easier for search engines to crawl it.

A site map is a document that contains a list of URLs of all the pages in your website. When you use site maps on your website, as the website owner, you’re telling search engines what content is present on your site and where to find it. This makes the job of search engines easier and ensures that they don’t miss any pages on your site, even by mistake.

Why XML site maps are important

Site maps are of different types, of which the XML site map is the one that search engines look for while crawling your site.

sitemap.xml files are polar opposites to robots.txt files. While robots.txt files are URL exclusion protocols that inform web crawlers and bots not to crawl the pages in the file, sitemap.xml files are URL inclusion protocols. An XML site map should be stored in your root WordPress directory so that search engines can locate and access it with ease.

Types of XML  site maps

There are many types of XML site maps you can create to provide search engines and users with more information about your website. Some of them are discussed below.

  • Image site maps: As the name suggests, image site maps are site maps that include a list of all the images on your website.
  • News site maps: These site maps contain a list of all the News published on your site.
  • Video site maps: Video site maps contain an index of all the videos posted on your website.
  • Mobile site maps: These site maps list only those URLs that serve mobile web content.

The format of a URL XML site map

A site map, in addition to web page URLs, contains some additional information such as the date on which a page was last modified; how frequently a page is likely to be changed, modified or updated; and how important a page is with respect to other pages on the same website. A typical URL entry in a sitemap.xml file looks like this:


Here, the <loc> attribute states the web page URL. The <lastmod> attribute states the date on which the page was last modified. The date should be mentioned in W3C Datetime format, as shown in the above example. The <changefreq> attribute states how often the page may change. The options that can be mentioned here are always, hourly, daily, weekly, monthly, yearly, or never. Lastly, the <priority> attribute states how important the page is when compared to other pages on your website. Valid options for this range from 0.0 to 1.0, the default value being 0.5.

Creating an XML site map for your WordPress Site

If you have a WordPress site with lots of web pages to index, it might seem like a daunting task to create a site map for your site. But it isn’t, so don’t you worry. You can automatically generate a site map for your WordPress site using a site map generator like XML-Sitemaps. Once a site map is generated, you can then upload it to your WordPress root directory. Else, you could also use WordPress site map plugins like WordPress SEO by Yoast and Google XML site maps to generate a site map for your website. These plugins will also notify all major search engines about new content on your site, every time you create a post.

Once you’ve generated an XML site map for your site, you can submit the sitemap.xml file directly to search engines like Google and Bing via the Google Webmaster tools and Bing Webmaster tools respectively. Alternatively, you can use the following directive to specify the path to your site map anywhere in your robots.txt file:

Sitemap: http://www.yourwebsitename.com/sitemap.xml

This is sure to have a positive impact on your search engine rankings. So what are you waiting for? Get started with your website site map already!

Making WordPress Backup to Dropbox seems like an attractive option due to ease of use & low cost.  However, is it the best practice & will restores be as easy as backups?

WordPress backup to Dropbox
Plugins generally store a copy of the API keys to your Dropbox account on your site. In such cases, if your WordPress site is hacked, then your backups maybe compromised too.

There are generally two ways you can make a WordPress backup to Dropbox. The first way requires two processes to be completed. You can manually download WordPress files using a FTP client and then download your WordPress database using phpMyAdmin. Then you can upload it all to Dropbox. WordPress.org recommends having at least three copies of a given backup and Dropbox can serve as the destination of one of those three copies.

The other way is seemingly easier. Backup your WordPress database and files with a backup plugin. Backup & Restore Dropbox, Dropbox Backup by Supsystic, and WordPress Backup to Dropbox are all plugins which backup to Dropbox.

Other plugins like Backup Guard, and UpdraftPlus WordPress Backup Plugin provide Dropbox as one of the optional destinations for backing up. IN the case of the the former the option is available only in the PRO version, where as in the case of the later it is an add on.

The process is simple You will need to input your Dropbox login credentials, confirm them and you are done. Some plugins will regularly backup your WordPress site to Dropbox according to the schedule you have set. Tracking this may be another matter altogether.

Apart from the simple process, cost is another factor which  makes Dropbox a seemingly attractive option for backups. Some plugins which allow you to backup your WordPress site to Dropbox are free. Dropbox itself is free up to 2 GB so you may feel there are no extra costs with this option.

WordPress Backup to Dropbox: Think again!

In order to backup up your WordPress site to Dropbox, plugins will need to store a copy of  your Dropbox account’s API key on the site itself. This means that you are keeping a spare key to your backups on your site. What is the point of leaving a copy of your bank vault’s key in your living room? You might as well have left your valuables in the living room too, right?

Backing up to Dropbox is indeed simple enough. Our WordPress backup plugin offers users the option to upload backup to Dropbox too. Users who know a particular version to be without any problems can download the backup to their Dropbox account. This is not a default option when you use the BlogVault plugin and regular backups are not made to your Dropbox account. We do this because we follow best practices for WordPress backups. Know more about why backups to Dropbox is not safe.

However, if you’re relying on Dropbox only to provide the safety net for your WordPress site then you are in trouble, at least according to our experience.

Dropbox Backups & Restores

Apart from all of these points, there is another issue to making WordPress backup to Dropbox only- restores. Afterall the entire point of making backups is to empower us when we need to restore our business or blog.

Most WordPress backup plugins zip your files; meaning they download your site in .zip or .gz files. You cannot view .zip or .gz files in Dropbox anyway and you have to download the files to sort them out. In this case Dropbox becomes a temporary storage solution rather than a comprehensive backup solution.

Seemingly simple matters like clutter. Regularly backing up to Dropbox clutters your account. You may not be able to find the files you desire quickly, when you need them. When you have to restore your site, you don’t want to sift through thousands, if not millions, of files.

Tip: When backing up to Dropbox

Ensure that you label the downloaded backups in an organised manner so that you know can categorise different backups. This will be helpful when you have to restore your site.

You need to safeguard your data in a more robust manner to ensure that in your hour of need you know not only know that you have access to backups but also that they are functional. Especially, if you’re running a small business or a popular blog then you might want to look at a more holistic solution for backup and continue making WordPress backup to Dropbox only as an additional step.

Intro about WordPress Firewalls

“Why do hackers hack websites?”, is one of the more philosophical questions of anyone with a website. Whatever the size of your WordPress site, protecting it from the common attacks against websites is definitely a concern.

Figuring out the best security option, (especially making the decision between a WordPress firewall and an antivirus) for your website requires a lot of research and technical know-how. But if you’ve decided on getting a WordPress firewall, NinjaFirewall is one of the options that you will have to consider.

This is why decided to test NinjaFirewall (v 3.2.4) for you, and to do it from a WordPress newbie’s point of view. We’ve pitted it against against the common exploits on WordPress sites to see if it stands our tests of fire.
A Web Application Firewall (or a WAF) provides customizable inspection and runs as an appliance, plugin, or a cloud-based service.


NinjaFirewall's logo
NinjaFirewall is a host-based WAF, that runs for WordPress.

Host-based firewalls on WordPress help protect against threats originating within the host (which, in this case, is your website). This means that they help reduce the risks of vulnerabilities in your website being exploited.

About NinjaFirewall

NinjaFirewall allows you to install and configure it just like a WordPress plugin, but it’s a ‘stand-alone’ plugin that intercepts all requests made to WordPress. The fact that it’s ‘stand-alone’ means it has its own settings, options, policies and rules that you can configure. If you’ve googled NinjaFirewall, you’d have seen phrases saying that the firewall ‘sits in front of WordPress’. This simply means that NinjaFirewall intercepts requests with the aim of alerting you of, and stopping any suspicious activity/requests before they affect your site.

There are also a few hiccups that you might face during installation, that the NinjaFirewall team has documentation for, which is great, if you aren’t a beginner with WordPress, and know the basics enough to understand code.

What NinjaFirewall Claims to Do for You

NinjaFirewall claims to intercept and determine which traffic to allow to your site. Upon installation, the firewall backs up your php.ini and .htaccess files and then modifies them to intercept every request made to your site. It then filters requests and traffic using extensive rules (and a whitelist), to separate good requests from malicious ones. The bad requests are dropped while normal requests are forwarded to your WordPress site. Its aim as a firewall, is to prevent your site from getting hacked, by avoiding bad requests from the get-go.

NinjaFirewall has a lot of features, that help towards this end, and many varied security functionalities to your site.


NinjaFirewall has a lot of features, that help towards this end, and many varied security functionalities to your site.  Each feature of NinjaFirewall has different options and settings, and we hope to explain the most important ones below:

NinjaFirewall has a great-looking set of features
NinjaFirewall has a great-looking set of features


  1. Firewall Options

    This is where you enable or disable NinjaFirewall. You can also customize the error messages to be displayed on your site when the firewall detects a bad request.
    Firewall Options
    If you’ve got NinjaFirewall installed on another site and have configured it according to your needs, you can import it to a fresh installation in the Firewall Options section. The only requirement is that both sites should have the same versions of NinjaFirewall.
    Importing another configuration of NinjaFirewall will override any firewall-related rule, option or configuration that exists on the site you’re importing to.

  2. Firewall Policies
    Most of the options that control how NinjaFirewall works, are in the “Firewall Policies” section.
    None of these options are customizable though: the majority of them are Yes/No options, or have checkboxes. The first few options let you decide whether you only want traffic with an SSL certificate or you’re okay with traffic that comes from other sources. Since a lot of hacks originate from file uploads, the firewall also allows you to choose whether you want to allow them or not. These first few options are easy enough to configure:
    Firewall Policies for traffic and uploads
    But as you scroll down the list, they get more and more complex. Some options even caution the user to not click on them if the user doesn’t understand what they entail. NinjaFirewall has documentation to explain all of these options, but some of them might still need some technical knowledge. This is why we’re going to try and break it all down for you.The HTTP variable is what requests information from a web page.
    Scanning it for dangerous values is a great move, especially since hacks depend on GET, POST and REQUEST variables.
    Sanitizing these variables makes sure that the website interprets strings as such, and not as commands.
    Scanning and sanitizing the HTTP variables can keep you from a number of attacks
    These options keep out suspicious bots from crawling your site:
    NinjaFirewall tries its best to keep suspicious bots from your site.
    The HTTP response headers help in protecting your site from other hacks that originate from the browser’s end.
    These settings help NinjaFirewall help protect you from attacks that originate from your browser.
    There are also a few options that are unique to WordPress:
    These options help protect against SQL dumping, and a number of shell scripts.
    These help protect your site from SQL dumping ( i.e. creating a snapshot of and storing all of your website’s database files); as well as a number of shell scripts.When a hacker tries to attack your site, they make a number of attempts, and depend on error messages to determine whether their attack worked or not. NinjaFirewall has the following options to not let your site display revealing error messages:
    These options prevent hackers from using PHP wrappers to pass GET and POST requests. They also hide error messages.
    And then there are other ‘various’ options that you can enable:
    And then there are other 'various' options
    NinjaFirewall also has options that control the requests made to and the access to WordPress core files and directories:
    Options that control how the WordPress directories are handled
    This section is also where you can modify the firewall’s whitelist:
    There are also options to control your WordPress site's whitelist
  3. File Check
    This feature helps create a ‘snapshot’ of files changed by comparing original files (or existing ones) against modifications. Once you create a snapshot (that you can later download or delete), it allows you to scan your site for file changes. You can not activate this scan before you create a snapshot.
    The File Check feature
  4. Anti-Malware
    The NinjaFirewall also has an Anti-Malware feature, that allows you to scan for hacks. According to NinjaFirewall’s documentation, this feature doesn’t alert you of spammy links, (like those that might redirect your visitors to porn sites).However, it does alert you based on signatures of malware, that could damage your site. This isn’t a great way to go about scanning sites though, especially since hacks are complex.This is probably why this is the one feature on NinjaFirewall that allows you to add custom rules or signatures, for malware or suspicious activity.

    NinjaFirewall has an interesting feature called Anti-Malware, that allows you to add custom malware signatures.
    NinjaFirewall has an interesting feature called Anti-Malware, that allows you to add custom malware signatures.

    NinjaFirewall has handy documentation for how to go about this. You will need to understand what to create signatures for, in order to make use of this feature.
    The Anti-Malware feature poses a couple of issue though. More on them here.

  5. Event Notifications
    The firewall logs any suspicious activity in the Firewall Log section, but you can set how often it alerts you, and what to alert you of:
    You can see exactly what triggers alerts
    This way, if the Firewall blocks any attacks, you can see what happened, from the Firewall log. It’s always good to examine why/how it blocked the attack.
    and how often they come in.
  6. Login Protection
    Brute Force Attacks are a different thing altogether- NinjaFirewall has a separate option to help protect against these attacks: Login Protection.The option asks for HTTP authentication credentials, without which you can’t enable this option. You can also set the message displayed when the firewall blocks such attacks.
  7. Firewall Log
    It is what it sounds like: a log of everything NinjaFirewall found unusual, according to the rules you set in Firewall options. So if you’ve asked to be notified about any plugins updated, deleted or created, this log will contain all the details.
    NinjaFirewall's Firewall Log
  8. Live Log
    This feature monitors HTTP and HTTPS traffic on your site, so it aims at protecting against any traffic related attacks (like Brute Force, DDoS, or weird IPs trying to access your site.)
  9. Rules Editor
    NinjaFirewall has a set of ‘rules’ according to which it operates.
    NinjaFirewall has a list of in-built security rules.
    These rules are mostly signs, or signatures of attacks that it tries to prevent. According to NinjaFirewall’s documentation, the rules are downloaded from the WordPress.org repository, and the plugin doesn’t contact NinTech’s servers during the update process.
    The list that NinjaFirewall follows
    You can’t add your own rules, but you can modify them in the Firewall Policies section, if they’re greyed out in the drop-down.
  10. Updates
    This feature allows your installation of NinjaFirewall to be up to date. Setting the firewall up to check for security rules is a tradeoff between choosing your custom configuration, and keeping your site secure.
    Of course, you could ask to be notified about the changes and then go back to fix the changes so they suit your requirement though.
    This option checks for NFW updates


What we tested it against

We ran a series of tests to evaluate first-hand, the efficiency of NinjaFirewall, against some of the common attacks WordPress sites face. For this, we created a test-site (which would be the stand-in for your website): vulnerabilities we tested the firewall against were:

1. SQL Injection

The Firestorm real-estate plugin (actually v 2.03), is one that contained a vulnerability that allowed for SQL Injection. This plugin allows you to add real estate listings to your WordPress site.

Testing NinjaFirewall against SQL Injection

To exploit this vulnerability, we tried accessing entering SQL code into the Firestorm plugin to get data from wp_users. (For those of us who don’t know what wp_user actually does, it allows you to get data from, and modify both the roles and capabilities of WordPress users other than the admin.)

Here is the SQL code we used: UNION SELECT 1, user_pass, 3, 4, 5, 6, 7, 8 from wp_users.

Because this version of the plugin in vulnerable, it will execute the code to try and select the user credentials from users 3, 4, 5, 6 and 7.

We used this in our browser’s address bar.

(Note: This is why for this attack and the couple others following, we’re going to ask you to look closely at the address bar.)

Running the test in the address bar

Once we entered the same code into the address bar of the browser, this is what showed up on the test site (look at the address bar carefully, please):

NinjaFirewall doesn't take entering SQL code into the address bar very lightly.
NinjaFirewall doesn’t take entering SQL code into the address bar very lightly.


But how did things work out behind the scenes of the attack?

Firewall Log for SQL Injection

This is what NinjaFirewall’s Firewall Log had to show us:
How NinjaFirewall logged the SQL Injection attack


Looks like the firewall had this exploit already in its list in the Rules Editor section, and hence it detected the exploit and prevented it from occurring too.

2. Arbitrary File Upload and Local File Inclusion (LFI)

There were a couple of vulnerable plugins that came to mind when we thought of Local File Inclusion. One was Slider Revolution (v 3.05), and the other was Gravity Forms (< v 1.8.19).

We chose Slider Revolution though, because it allowed to make both exploits, and because more than 100,000 sites were attacked in 2014 through this plugin.

Testing NinjaFirewall against Local File Inclusion

The Slider Revolution plugin was used to perform Local File Inclusion on vulnerable websites in the following manner:

Say the vulnerable site was called ‘victim.com’.

The vulnerability allowed attackers to request the RevSlider plugin on the vulnerable site to show the images in the slider. Once it did that, the attackers would also try to figure out the structure of the WordPress directory. They would then get it to include files on the website’s local server (like the wp_config files) to the files it revealed. So the final URL entered on the site would be something like:


We used a very similar approach to try and get the plugin to include the wp_config files of the website, and to reveal them.

Here is how NinjaFirewall reacted:

Running the test

NinjaFirewall on Local File Inclusion: You shall not pass!
NinjaFirewall didn’t let us perform a Local File Inclusion.


Since the action got blocked, we just checked out the Firewall Log.

Firewall Log for Local File Inclusion

What NinjaFirewall's Firewall Log registered the LFI attack as
This is what NinjaFirewall had to say about the attempt to include a file locally to the test-site.

Testing NinjaFirewall against Arbitrary File Upload

Again, trying to get to two attacks with the same plugin, we tried uploading random (or arbitrary) files to the test site. If the attempt is successful, the damage to the site would depend on the kind of file uploaded, and what it was intended to do.

Take a look at the address bar to see what we’ve tried to do.

Now don’t get confused… We named the files to be uploaded as “revslider” so that it would be accepted more easily by the plugin.

Running the test

NinjaFirewall successfully blocks Arbitrary File Uploads.
We used Google Chrome’s extension to test the Arbitrary File Upload exploit. The exploit was unsuccessful

Again, we only checked out the Firewall Log, since this attack was unsuccessful.

Firewall Log for Arbitrary File Upload

Here is what the Firewall Log said:

The Firewall Log for Arbitrary File Uploads
The Firewall Log for Arbitrary File Uploads

3. Brute Force Attacks

As mentioned earlier, to protect against Brute Force attacks, NinjaFirewall has a separate option called Login Protection.

Testing NinjaFirewall against Bruteforce attacks

Just to test its effectiveness, a colleague of mine, Vijay, tried launching a Brute Force attack against the website using Hydra, a tool that helps test websites and crack admin credentials.

Running the test

We launched a Brute Force attack against the site when we’d set the “Enable Brute Force Attack Protection” to “No”. This is what Hydra got us:
Hydra was able to get the admin credentials from the site

As you can see, the attack was successful, and Vijay was able to get the site admin’s login credentials.

Then, we went ahead and enabled the Login Protection feature:
Setting Login Protection to 'Yes, if under attack'
Vijay then launched the attack again. This is what Hydra’s log said:
Hydra was unsuccessful

Firewall Log
A quick look at how the attack was reported in NinjaFirewall’s Firewall Log (this shows how the attack was let through, and then stopped):
the Firewall Log for Brute Force Attacks

4. Remote File Inclusion (RFI), Arbitrary Code Execution, and Backdoors (a custom hack)

We used TimThumb because it was a plugin that was widely used, and exhibited a vulnerability that allowed for millions of WordPress sites to get hacked. This test was therefore meant to check the basics of the firewall.

Testing NinjaFirewall against Remote File Inclusion and Arbitrary Code Execution

For this, we used the (currently defunct) Pict.Mobi widget, that used TimThumb (v 1.28) on the test site. Obviously since the RFI exploit would need a hackfile to be included from a remote location, we also created another site that would host the bad file.
We took the approach a hacker would: we first confirmed that the (test) site used TimThumb, and that it used a vulnerable version.

"Does this site have TimThumb?"- An optimistic hacker
Most hackers looks for vulnerable plugins on your site.


Then selected a very small file (in this case, it was a 16X16 .png icon), and modified it to contain PHP code.

Modifying a small image to contain malicious PHP code
Modifying a small image to contain malicious PHP code


Next we used the TimThumb vulnerability to include the file remotely to the test site. Note that the file was PHP, which means that any time it was accessed, it would run.

Including the malicious file remotely to our website
Including the malicious file remotely to our website (notice the address bar!)


Sure, it was an image file, so it could easily bypass the site’s usual sensors, but the PHP code could still be accessed, and executed.

Testing NinjaFirewall against Backdoors

We wanted to kill three birds with one stone, so we made sure to create an encrypted shell for the PHP code on the image before we uploaded it.

Running the test

We then extracted the code from the hackfile shell, just like a hacker would:

Extracting code from the hackfile's shell
Extracting code from the hackfile’s shell

And then ran it.

Executing the code. A three-in-one attack.The website gave us what we wanted.
Executing the code. A three-in-one attack. The website gave us what we wanted.

NinjaFirewall didn’t stop the attack.

We think it was because NinjaFirewall has a list of rules for what attacks should look like, in a section called Rules Editor.

A look at NinjaFirewall's Rules Editor
A look at NinjaFirewall’s Rules Editor

Click on the drop-down, and you see the list of rules that NinjaFirewalls follows:

The Rules Editor has an extensive list
The Rules Editor has an extensive list

These rules are internal to NinjaFirewall, so you can’t see what exactly each rule entails.

The attack we performed though, didn’t exactly go by the rules of how the attacks worked.
The results of the tests are as follows:

Firewall Log

The log didn’t pick up on the hack. In fact, it only listed the backdoor we’d tested it for.

The Firewall Log only registered the backdoor.
The Firewall Log only registered the backdoor.

File Check

The firewall didn’t detect changes in files. We were still able to list the files in the WordPress directory.

The firewall didn’t detect changes in files. We were still able to list the files in the NinjaFirewall's File Check resultsdirectory.
What NinjaFirewall’s File Check showed up


We didn’t expect this feature to remove the malware, because it’s only a scanner.

Unfortunately, it didn’t find the infected files. We were under attack, and this is what the anti-malware feature said:

What the Anti-Malware feature said
What the Anti-Malware feature said

Live Log

No blips on this feature either.

The results on Live Log
The results on Live Log

Unresolved issues with NinjaFirewall

Since this is a review of the entirety of NinjaFirewall, we didn’t only test it against vulnerabilities. We also checked for issues other than those of protection. Most of these issues are documented on NinjaFirewall’s forum on WordPress, or on its online documentation.

● Anti-Malware scans time out

The Anti-Malware feature on NinjaFirewall allows you to scan files in a particular directory for your site for malware (by default this is/var/www/html/wordpress/).

The thing is, by default, this feature scans your site for malware in files that have been created or changed in the last 7 days. You can change the time period (or Timestamp) or even make it zero, in which case it scans your whole site.

The options that Anti-Malware shows you
The options that Anti-Malware shows you

However, when if your website is on a shared host, there is one major problem you could face: the Anti-Malware scan timing out.
The feature stops scanning your site after a certain time period that is set by your web host. This means that if you have too many files on your site, the scan will get cut short. Your site could never get fully scanned, unless you try some workarounds, (like this one suggested by the NinjaFirewall team). This is probably why NinjaFirewall’s Anti-Malware feature also has the two options of “Ignore file extensions” and “Ignore files/folders”:

Working around NinjaFirewall's time-out issue
Working around NinjaFirewall’s time-out issue

While there isn’t anything NinjaFirewall can do to change the timing out of the scan, it is a huge drawback for users who want to scan their sites.

● The Anti-Malware feature uses only signatures to detect malware

This is a widely-used method to identify malware and viruses, but it doesn’t catch everything. This is why most security scanners use it in combination with other approaches. Hacks utilize vulnerabilities on your site, but how bad code is run on your site depends completely on how hackers want to carry out the attack. So the ‘signature’ of malware could always be altered in small ways so as to escape detection. This is why, as we explained earlier, our exploit of the vulnerabilities in the Pict.Mobi plugin allowed for RFI, Arbitrary Code Execution and Backdoors on our test site.

● The firewall modifies .htaccess files

NinjaFirewall backs up the PHP INI and .htaccess files that it has to modify, but modifying the .htaccess file in itself can wreak a lot of havoc on your site. The .htaccess file controls a lot on your WordPress site. One of its more obvious functions is access control (i.e. which users are allowed to your website), but it also dictates how files with certain extensions run on your site. This is why any minor slip-up with this file could cause your server to majorly malfunction. Just to be on the safer side, we recommend that you perform a backup of your entire site rather than just the .htaccess file. That way even if something breaks, you can always roll back to a working version of your site.

● Modifying the .htaccess files and php.ini files slows down your site

.htaccess allows you access to the configuration of directories on your website even if you don’t have your hosting server’s (eg: Apache) main configuration file.

This means, when your site is configured to direct traffic based on the modification made to .htaccess, Apache has to look for, and load all the .htaccess files on any request made to your site. As a result, your WordPress site’s load time increases.

It’s a good way to direct traffic when your main server configuration file isn’t accessible, but otherwise it isn’t a great thing.

● The firewall interrupts backup operations regularly

NinjaFirewall triggers false alarms when WordPress backup plugins are run, sometimes doesn’t allow backup plugins to backup the site. The firewall also has to be disabled before migrating your site to a new IP address.

● Can’t manually install NinjaFirewall

As mentioned earlier, NinjaFirewall might log you out of your WordPress site and deny you access if you use an FTP client to make changes to it, or even uninstall it. Anything that you need to do with respect with this plugin has to be done from your WordPress dashboard.


The NinjaFirewall seems like a powerful tool against known attacks that occur according to their signatures. But the thing is that most hackers know these signatures, and know that most security measures protect against these signatures. So they modify the signatures to perform more successful, and at times, most devastating attacks.

Alerting of attacks after they’ve taken place isn’t something a lot of website owners can afford, especially with the damage hacks can wreck. However, having a hack-cleaner might help you scan for, and remove malware that causes the damage. In any case, it’s always important to have a dependable backup service for your WordPress site.
Did you like this review of NinjaFirewall? Would you like to see other firewalls tested too? Let us know in the comments!

Why do you need it?

Can your business continue to function if you were to lose your data? If your answer is a clear no, then having a disaster recovery plan is a must for you. At some point down the road, your data is going to be in danger. It could be a machine error. It could be a simple human error. It could be a tornado the size of Nebraska. But sooner or later, you’re going to be in a situation where you’re at risk of losing some or all of your data. Some of the common consequences of a disaster –

  • Loss of business/customers
  • Loss of credibility/goodwill
  • Cash flow problems
  • Loss of operational data
  • Financial loss

90% of businesses that lose data from a disaster are forced to shut down within 2 years of the disaster. 50% of businesses experiencing a computer outage will be forced to shut within 5 years. (Source: London Chamber of Commerce). So, having a disaster recovery plan is the best insurance for your business and entire data. But what are the possible reasons behind this ‘disaster’? And how do you deal with them?

It's wise to have a recovery plan for your website
It’s wise to have a recovery plan for your WordPress site

What Can Go Wrong?

Hardware Failure

While we’ve made huge strides in terms of technology, it’s still not perfect. There are bound to be issues now and then. Hard disks, which are the most popular form of storage media, fail more often than you think. The statistical figure indicated is by no means trivial. Other forms of hardware failure can have a similar impact on your business.

Web-hosting Failure

As every site is hosted using one of the providers, a failure on their end undoubtedly spells disaster. Any sort of networking problem can bring down your site. However, this doesn’t pose a big threat to your data. But that’s not the end of it. These hosting providers are a common target of hackers. Once the server is compromised, the hackers have access to all the data that resides on it. The hackers can thus attack 1000s of site by hacking a single provider. Sometimes, hosting providers even suspend your account without prior notice.

Natural Calamities

Natural calamities, though rare, can pose a huge threat to your data. Hurricane Sandy, which hit New York City in 2012, had companies fighting hard to keep their data centers up. It was one of the busiest days for many of them.

WordPress Issues

WordPress, though WP core is known to be stable, has its own share of problems that crop up from time to time. The most common issue that users face is that of version incompatibility. Though WordPress versions are meant to be backward compatible, quite often, a WordPress update ends up breaking a plugin or theme due to incompatibility. Underlying API changes in a new version could also result in breaking parts of your site.

Plugin/ Theme Issues

WordPress is an open platform, inviting a lot of people to develop plugins and themes. Since each plugin and theme is written independently, not all of them follow the same set of coding guidelines and standards. This makes installing new themes and plugins on your site a risky proposition. A new addition may be incompatible with the underlying WordPress version. Some of the changes made by plugins and themes are –

  • Bad database changes
  • Addition of new tables
  • Modification of standard WordPress tables
  • Changing WordPress configuration files
  • Introducing incompatible code
  • Corruption of .htaccess files

This can result in breaking parts of your site or worse, lead to a crash. Upgrading plugins and themes can also lead to similar issues.

Hacks and Vulnerabilities

WordPress core, by itself, is known to be safe and stable. However, plugins and themes added by developers hailing from diverse backgrounds have become game changers when it comes to WordPress security. Plugins and themes together make up the biggest source of  vulnerabilities found in recent times. Popular plugins like MailPoet, W3Total Cache and Super Cache have been exploited to attack thousands of sites. Similarly, themes are also vulnerable to attacks. The TimThumb library included in many themes was exploited to compromise tons of sites.

Hackers are always looking for new ways to launch attacks on WordPress sites. While most hackers look to make quick profits, some do it merely for fun. They can install malware that’s extremely hard to detect and get rid of. They can also wipe out all of your site’s data.

Human Errors

To err is human. But these errors can prove to be very costly. You can delete a single post or the entire database. Ben Congleton of Olark describes in an interview, a case where a human error nearly took down his business.

The reason behind the disaster can vary, but they will all impact you in the same way. They can all potentially take down your site, and thus your business. So what is the best possible plan to recover from a disaster?

Putting Together a Disaster Recovery Plan

Backup, Backup, Backup: the Cornerstone of a Disaster Recovery Plan

Not enough emphasis can be laid on the importance of backups. Taking regular backups of your data is critical for any business. That way if anything untoward happens, you can recover your site in a matter of few minutes. There are multiple options available from which you can choose. However, it is best to opt for a managed offsite backup service like BlogVault that can handle any situation with ease.

Plan for Extended Downtime

Your plan should cover what you will do if the downtime from the disaster is expected to last more than a few days. For instance, there may be a major outage with your hosting provider. You’ll need to identify possible alternatives to host your site.

Emergency Contact

A natural disaster or emergency could cut off all your regular avenues of communication, so adding a communications element to your plan is important as well. Notifying your customers about the downtime is extremely important. However, when you lose data, your customer information is lost too. Hence it is critical that you have a separate emergency contact list, such as all customer email IDs, stored separately in an easily accessible place.

Test the Plan

Do a test run of your disaster recovery plan to make sure that it works when needed. Also ensure that your plan is known to multiple people at your company so that they can spring into action immediately when disaster strikes.

Disasters do happen, and your company’s data is one of its most important assets. When disaster strikes, you need to be sure that you can get your data back quickly, so there is minimal impact to your business. So work on that disaster recovery plan today, in case you already haven’t. Better safe than sorry, right?

The correct answer to this question, for any WordPress agency, is that, it depends. Running an agency which delivers quality products and services can be daunting.  While many are looking for the answers to be able to balance both, very few agencies actually can manage both successfully.

A good example in the Indian WordPress community is rtCamp. Asia’s first WordPress.com VIP partner agency has two popular products: EasyEngine and rtMedia. It is interesting to note that, both these products were born out of requirements the company had at those respective times. The statement by Rahul Bansal, “You should only develop on platform which you use,” rings true here it seems.

rtMedia was born when Bansal, suggested that his college use BuddyPress to build their own social network. His professors pointed out that a popular social network at the time- like Orkut, had images and videos and without that students might be bored. BuddyPress didn’t have the option to add media at the time and rtMedia was born to solve that problem. While the plugin was released 2 months after rtCamp was formalized, the product was being worked on before the birth of rtCamp itself, Bansal recollects.

In the case of EasyEngine, Bansal used NGNIX to reduce the budget for hosting his blog network which at that time used to get half a million page views. He found the solution to be efficient. However, being the only one in the company at the time to offer this solution, he refrained from making it their USP.

Over time, requests from Bansal’s friends in the blogging community resulted in moving their sites, over NGNIX, one by one. To avoid repeating the same task EasyEngine was created.

The success of both these products, coupled with the recent success of rtCamp as a WordPress.com VIP partner agency may paint a rosy picture of a company balancing both service and products. However, Bansal, would be the first to dispel you of such a notion.

There cannot be greater proof of the difficulty in delivering quality on both fronts; products and services, than when Bansal says that if he could travel in time, then he would kill either products or services on day one of rtCamp.

His reasoning is simple: unless a company has a manager dedicated to ideation, and development of the product, life can get very tough. As Bansal states that being the only person to head both products and services means that person may end up becoming a bottleneck in their own company; as all the approvals have to go through one person.

It may not be a satisfying answer but smaller or younger companies will do well to take note of the experiences of Asia’s premier WordPress company. Running a WordPress agency can be stressful at most times. Learning from each other’s experiences extends the feeling of community which is so inherent to WordPress, while helping us make smart choices too.

Let us get the common question about Asia’s first WordPress.com VIP agency out of the way. What does rtCamp stand for?

RT, as the founder Rahul Bansal himself explained to us, stands for ‘Round Table’ after King Arthur’s famed table in the Arthurian Legend. Camp, refers to the whole circuit of bar/blog/php camps in which, Bansal, as a successful WordPress freelancer, actively participated.

Two factors influenced the name and the culture at rtCamp. One factor Bansal says was his “hunger for equality”- the desire that everyone must have a say and contribute by taking initiative instead of just taking orders. The other factor was the unencumbered, open-source loving, community-driven culture around WordPress; which was represented by bar camps and so on, which he had come to appreciate.

These values he says got reflected in their work culture and while he adds that such core values cannot be altered according to the balance sheet, he can also trace the foundation of rtCamp’s growth to these values.

At rtCamp, their core values, have resulted in them building an agency where they love open-source, contribute back to the WordPress community, share the spotlight, and celebrate the contributions as well as exits of their team members.

A reflection of this is Bansal’s description of how, the now VIP partner WordPress agency, landed their first big client; when they were much smaller and younger.

Bansal is quick to attribute credit to the then Marketing Head, Gajanan Sapate; who is no longer with rtCamp and has started his own social media agency, SocialChamps. Sapate had approached Bansal with the idea of creating a company profile on LinkedIn- a popular professional social networking platform. Bansal, admittedly, was not too keen on the idea. Sapate made the choice to create the company profile on LinkedIn without his approval Bansal recollects, appreciatively.

When the ‘big client’- Geometric, went searching on LinkedIn, rtCamp had an advantage, as they were probably the only company to be listed as a WordPress agency in India at the time; around 2012.

This is only one example of how Bansal, and rtCamp set up a platform for many to take initiative and grow. Many of them have left the agency to carry on to big projects while continuing to make contributions to the WordPress community.

If you need an example of the extent to which rtCamp’s contributions to WP core has had an impact, you only need to look at the citation they received when becoming WordPress.com VIP partners. It was consistent contributions to WordPress Core which was mentioned as the main reason for being chosen as Asia’s first WordPress.com VIP partner agency.

Another aspect of the agency that Rahul takes pride in, is the  involvement of rtCampers in the WordPress community itself- participation in WordCamps and publishing of tutorials. He says that the company encourages team members to make such contributions.

The culture of sharing the spotlight and getting better at one’s job, while contributing back to the community in combination have produced a team which today boasts of only enterprise clients or funded clients. While rtCamp was not born as an enterprise level WordPress agency, the core values as described by Bansal certainly seem to reflect in the work and now in the client base the agency has developed over the years.