A Few Things to Consider Before Giving Access to Your WordPress Site
Soon or later you will need to hire a developer or designer to do some work on your site and that’s good. This could be a completely new piece of functionality or a task to improve your existing site. This article assumes that you’ve checked the person’s work (github, portfolio etc) & have filtered out the not so qualified or responsive candidates.
Test their actual skills using a test project
The best way to test a person to see if they can get the job done is to give them a small project to work on. That way you will see how they work and communicate. If they pass the first test then you can give them a second project with a shorter deadline to see how they work under pressure. Of course be prepared to pay extra because the person will need to drop everything to make that deadline.
How much access to give
The next thing to consider is how much access to give the person. If they need to work only on your site then there’s no need for them access to domain registration account unless they need it to switch your hosting provider.
Note: if you don’t have the domain registered just yet, register it yourself because there have been cases in which a developer/designer registers it under their own name and can possibly use this to ensure he/she will get paid at the end or to request more money. They can be listed as technical contacts but make sure that you are listed as admin contact because that’s what’s needed when you need to transfer the domain elsewhere.
Of course you should always believe in goodness in people and also take measures to prevent bad things from happening. Sometimes we have to protect the developer/designer from themselves. We are human beings and we all make mistakes. In other cases things just don’t work out so you want to minimize the impact that the wrong person can do.
Last week I had to make changes on a client site. I used FileZilla ftp client and I noticed that the files I edited were truncated (their size was set to 0). Probably the file transfer must have failed (silently). That happened twice and was really annoying. If I had known that I would not have reloaded the already opened file in Notepad++. All the contents were gone! I didn’t have chance to troubleshoot the issue but I am suspecting this is a FileZilla bug or has something to do with server’s firewall or something else.
The good thing was I had everything in version control (git) and was able to restore the files. That’s why it’s dangerous to work directly on the live site. Any development work should never be done on a live site unless the fix is critical and backups are made beforehand. Bad things can happen (to good people) so to prevent this and any other issues from happening I am suggesting to give the least possible access & have a regular (offsite) backups up and running.
Set up a completely new site for the work. If the work needs to be done on an existing site then clone it (using Duplicator or use another WordPress plugin). The main idea here is to have two separate sites whose files and database are cloned version of the live site. That way the changes that are made on that test/staging site won’t crash the live site.
When uploading files they are uploaded in chunks so at a given moment a given php file could be partially transferred and this could would cause a fatal php error or even worse: white screen (of death) which would be super unprofessional to show to your visitors and potential clients.
Removing confidential data
You will need to protect any confidential data from falling into the wrong hands or being leaked on the Internet. If you have an e-commerce store or membership site you have some orders, member info so the developer or designer will be able to see the contact information of those people and can possibly export those and later sell it or spam them. I am not saying that this will happen but you never know. Better safe than sorry.
If the functionality that will be implemented depends on actual data i.e. process all members and upgrade them to Plan 2 then cleaning up user data may be an issue especially if you want to later replace the live site.
Ideally the functionality that will be built should be as a theme or a plugin can easily be installed on the live site and the installation steps repeated there as well. By the way it’s good to ask the developer/designer to document the installation steps in a text file. This is very valuable to have this for your own records and also for the person who will be working on the site next or when doing some troubleshooting later.
There are several options. The person can work directly on a the test/staging site that you’ve set up. This approach can be slow and would require Internet.
For complex tasks you will have to package the *cleaned* test/staging site again (using the same Duplicator plugin or another tool of your choice) and send the package. The benefit of installing the site on a local machine is because of the debugging tools that are installed on a development computer and not having Internet won’t be an issue (with some exceptions such as API integrations & payment tests).
With the debugging tools a developer can stop the site at a given point and inspect all the variables and thus making the troubleshooting of a tricky issue a lot more effective.
If the person will be working on your staging site you will need to create a separate FTP account whose root folder points to the test site’s root folder.
Some people may be tempted to only give access to WordPress admin. That could work but one wrong move and the site may/will become inaccessible anymore.
Editing files from within WordPress (WP Admin > Appearance > Editor or WP Admin > Plugins > Editor) is a very slow process and the developer/designer has to be extremely careful which files he/she edits, especially php files because one missing bracket to an if condition or missing semi-colon can/will crash the site. This is because of a php error will prevent WordPress from loading.
WordPress Admin Access
If the developer/designer has more experience, giving them FTP access this also means that they can access the WordPress admin area. For example our tool SAK4WP (Swiss Army Knife for WordPress) just needs FTP access and allows the first person who uses it to log in as ANY user on a given WordPress site. Of course there are some security measures in place so other people can’t access that tool.
Are we there yet?
You have done all the steps and that’s good. Is the live site secure now? Not yet. Here’s why. Hosting companies run each site under the account that owns them. This is done to make sure that clients cannot access each other’s sites and files. There’s no such separation between your sites and their files. Your account owns them and should have access to them. Therefore, if the developer/designer writes some code or uses an already made (shell) script can potentially get access to the live site’s files because any programming code can bypass the FTP restrictions.
What’s the solution?
To get a higher level of security you will need to get another hosting plan with the same or a different hosting company or use service such as qSandbox.com. That way the test/staging and live sites will be running under different accounts and therefore won’t have access to each other’s files & databases.
You can create a new subdomain subdomain e.g. feature1.YourCompany.com or feature1.YourCompanyStaging.com and point it (via DNS A record) to the new hosting account. You may have to register YourCompanyStaging.com domain but it’s pretty affordable nowadays.
What are your best practices when giving access to developers & designers to your WordPress site?
Slavi Marinov is an entrepreneur/developer who loves creating cool/new products for his clients and for his company Orbisius.
If you need any WordPress related work done (custom plugins, site migrations etc) feel free to contact him by visiting to Orbisius.com