Let\u2019s face it: your clients aren\u2019t going to be WordPress pros. That\u2019s why you\u2019re<\/em> getting paid to develop their website in the first place.<\/p>\n Now, let\u2019s say you are an in-house employee building a website for your own company or that you\u2019ve been given a retainer to manage your client\u2019s website post-launch on an as-needed basis. You\u2019d be pretty annoyed if the president, marketing admin, or anyone else at the company came to you and said, \u201cWhoops! I think I broke something.\u201d Imagine how it would feel if you had completed work on a website, closed out the contract, and the same thing happened.<\/p>\n Some clients won\u2019t understand that if the fault is theirs, that they need to compensate you to fix it. So not only are you left having to fix their mistake, but you have to try not to lose money and time while resolving it.<\/p>\n No matter how this plays out for you as a developer, it\u2019s a tough situation to be in. You don\u2019t want to tell your client (or boss) that they made a mistake and you don\u2019t want to lose time on another project in order to fix it.<\/p>\n But what can you do?<\/p>\n The first thing you need to understand is why the most common types of errors occur with a WordPress website. Most website developers would\u00a0classify errors into two categories:<\/p>\n Slips<\/b>: Slips are the type of errors that occur when a WordPress user\u2014usually an expert developer\u2014just forgets to do something or close a loop somewhere. If you think about it, you work on website after website\u2026 At some point, they\u2019re all going to blur one into another and eventually something is going to slip through the cracks because you\u2019re working on autopilot. That\u2019s why it\u2019s important to be diligent about working from a checklist to ensure that all the i\u2019s are dotted and the t\u2019s are crossed with every project.<\/p>\n Mistakes<\/b>: Slips are easy enough to fix since they usually occur somewhere during development. As long as you follow a consistent and thorough process when building a website, it should be easy enough to trace your steps backwards to the error. Mistakes, however, usually stem from WordPress users trying to accomplish a task, but not truly understanding how to execute it. These can be tricky to resolve since the users can explain what<\/em> they were trying to accomplish, but may not have any idea what they did to cause the problem.<\/p>\n Mistakes occur for a number of reasons:<\/p>\n What all this comes back to is the fact that your clients are probably not equipped with the knowledge and training in WordPress or website development to fully manage their websites on their own. This also means that they\u2019re definitely not able to fix any errors they cause either, so the onus will ultimately fall on you.<\/p>\n Reworks suck, especially when you weren\u2019t the source of the problem. However, when WordPress access goes unchecked or clients are given access to parts of the website backend that they don\u2019t know how to properly use, it\u2019s inevitable that something will go wrong.<\/p>\n As a developer, you\u2019re ultimately responsible for what happens to the website. Why?<\/p>\n So are website errors post-launch and post-client handoff the developer\u2019s responsibility? Yes. Definitely. You can\u2019t expect clients (or anyone else granted access to the backend of the website) to understand web design, web development, or even the platform itself. By taking extra steps up front, you can ensure your websites stay (reasonably) safe from user error.<\/p>\n\n Novice WordPress users (i.e. your clients) are going to be clumsy and hasty in making changes. They paid you to build their website because 1) they don\u2019t know WordPress and 2) they don\u2019t have time to do it themselves. That\u2019s why you shouldn\u2019t be surprised if they don\u2019t bother to take the time or care when making changes to their site later on. They know you\u2019re going to be there for them, so why not protect their website (and yourself) now?<\/p>\n Here is a pre-launch checklist you can add to your pre-launch development process. Your clients will be better prepared to manage their own sites and you\u2019ll be able to keep them safer from potential and easily avoidable user error:<\/p>\n Before handing a newly created website over to a client, make sure you have WordPress reference material you can share with them. It\u2019s not your job to teach them how to use WordPress or build a website, but you should have some sort of tutorial or guide that they can quickly reference in case any simple questions come up down the road.<\/p>\n Our suggestion would be to develop a (self-branded) guide of your own that will cover the basics: \u201cHere is where your blog posts reside and here is where your pages are,\u201d \u201cAlways hit Save, but don\u2019t click Publish unless you\u2019re absolutely sure those changes are ready to go live,\u201d etc. You can then use this guide for any and all clients going forward. You should also install the Sidekick plugin<\/a> to ensure your visitors receive real-time WordPress guidance when they need it.<\/p>\n In addition to providing your clients with a WordPress reference guide, you should also plan on walking them through the CMS in real-time. If you don\u2019t work on-site with your client, you can use a free program like Join.Me<\/a> so you can share your screen. Make sure you show them the following:<\/p>\n As a best practice, every web developer should be giving their WordPress website a personalized backend design. By branding the WordPress interface, you\u2019re not only providing clients with a value-add (because, let\u2019s be honest, you don\u2019t have to do this), but you\u2019re also keeping your presence top-of-mind. Can you trust your clients to maintain strict security standards when using their website? No, probably not. So rather than wait around to find out that they\u2019re using a generic \u201cadmin\u201d login and \u201c1234\u201d password, enforce stricter security standards that they have to abide by from the get-go. Two-factor authentication, bcrypt hashing, and strong passwords shouldn\u2019t be optional.<\/p>\n For information on how to set this up ahead of time, check out these ten tips<\/a>\u00a0or our post WordPress Security: The Ultimate 32-Step Checklist<\/a>\u00a0.<\/p>\n Your clients are going to be concerned with the idea of securing their websites, but they\u2019re probably not going to know how to keep it safe or they\u2019re not going to think they need to worry about it right now<\/em>. You know that data can get lost or stolen at any moment and having a site that\u2019s regularly backed up isn\u2019t optional.<\/p>\n If you don\u2019t want to have to deal with rebuilding a website or redoing recent changes because there wasn\u2019t a backup in place, give your clients a system that will automate the process for them. The Snapshot Pro plugin<\/a> can help.<\/p>\n Automation is a wonderful thing for developers. You set up a process to manage itself the way you want it to, and then you just let it run in the background. That way you never have to worry about whether your clients have upgraded to the right version of WordPress or if they\u2019ve kept their themes and plugins secure by making regularly requested updates.<\/p>\n If you’re a WPMU DEV member, you can update your plugins and themes from The Hub<\/a>. Otherwise, the Easy Updates Manager plugin<\/a>\u00a0is worth checking out. If you\u2019re looking for a tool to help automate this process and also give you the ability to control who can and cannot make updates to themes or plugins, definitely get this one.<\/p>\n If your clients plan on making updates to their website in the future and they haven\u2019t sought out the help of you or another developer in making them, the hope then is that the changes are so minor that they don\u2019t require any updates to coding. However, leaving website files\u2014especially the wpconfig.php file which should always be moved above the root\u2014out in the open for a user (or hacker) to accidentally stumble upon and try to make changes to is a recipe for disaster.<\/p>\n WordPress\u2019s codex<\/a> provides some helpful guidelines you can follow when assigning the proper permissions.<\/p>\n When it comes to restricting user access in WordPress, some would argue that it\u2019s as simple as going to the Users tab and updating their role and rights. However, those pre-set rules aren\u2019t always enough.<\/p>\n If you want even more control over user access and capabilities, check out the Members plugin<\/a>.<\/p>\n If you want to control who can use the Visual Editor, give Disable Visual Editor<\/a> a try.<\/p>\n If you want to control the different types of content (posts, pages, categories, media, and more) that can be accessed, Advanced Access Manager<\/a> will do the trick.<\/p>\nWordPress User Errors: Slips vs. Mistakes<\/h4>\n
\n
WordPress User Errors: Why They\u2019re Your Problem<\/h4>\n
\n
Pre-Launch Checklist for Preventing User Error<\/h3>\n
Step 1: Include a WordPress Tutorial<\/h4>\n
![\"Sidekick](\"https:\/\/wpmudev.com\/blog\/wp-content\/uploads\/2016\/07\/Sidekick-plugin-e1469301917470.png\")
<\/div>\nStep 2: Provide Training Post-Launch<\/h4>\n
\n
Step 3: Put Yourself Front and Center<\/h4>\n
\nWith a plugin like Ultimate Branding<\/a>, you can create customized messages and modules in the dashboard, too, which would be a great place to include that tutorial you created for them.<\/p>\nStep 4: Bolster Security<\/h4>\n
Step 5: Automate the Backup<\/h4>\n
Step 6: Automate Updates<\/h4>\n
Step 7: Restrict File Permissions<\/h4>\n
Step 8: Restrict User Access<\/h4>\n
Step 9: Limit the Admin Dashboard<\/h4>\n