In the recent weeks, we’ve talked a lot about what to avoid when building websites. This week, let’s cover the basics of a professional WordPress website development and how correct workflows can help you incorporate security as early as possible.
Build in a local environment first
When you’re starting with a new project, and you’re the only one building it, there’s mostly no need to upload it to a server until it reaches to a milestone where a client could give a meaningful feedback. It’s always good to keep the production (live site & environment) tidy and do active development locally.
WordPress ecosystem even have some pretty cool local building tools available such as Local, Laragon and the most recent newcomer WordPress.com developer studio. You can always set up your own LAMP stack server locally, but these tools make your life a lot easier if you don’t want to get your hands dirty.
Use a staging server to get feedback
Once you’ve reached a point where you need to present the website to your team or to a client, it’s good to push it to staging. A staging environment is a limited access server, which is an identical clone to the production server.
This is where you do quality assurance, test the new features, collect customer/team feedback and make sure everything works as intended before pushing it live. This is where you can have debugging settings turned on and where you can see how the application behaves in the specific server environment.
The staging environment should not be published online and should only be accessible with a username/password or with IP whitelisting. It should not be publicly accessible to anyone other than your team or to your customer.
No experiments on a live site
Once you’ve built the site locally, tested it in staging and finally pushed it live to the production environment, you should make sure that all debugging settings are turned off and that no experiments are done on the live site.
This is something I see happening all the time. Sites commonly leak environment details because of active debugging features, sites run unused plugins which are leftovers from different experiments which have been left outdated, disabled, and not deleted.
Production has to be clean. You should always test things on the staging server first and only publish changes to the live site when all tests have been successfully completed. Working in such a way will help you get used to better processes and avoid costly mistakes that you wouldn’t want to do on a live site.
Try out the Git based workflow
This is not for everyone, but I’d personally recommend every WordPress developer to get used to the Git workflow and consider making it part of their development practice. It can become very useful if there’s multiple people working on the same project, and it allows multiple people to work on the same project in their own local environments.
There’s an old article from 2014 I still see being shared around titled “No More Cowboy Coding: Improving Your WordPress Workflow” – so I’ll link that here in case you’d like to explore more of it https://wpmudev.com/blog/improve-wordpress-development-workflow-local-server/
Today, there’s also a lot more tools available that have been built to make Git workflow easier for WordPress, such as VersionPress, but there is also an official GIT mirror of WordPress in GitHub and there’s also the official documentation about this here: https://codex.wordpress.org/Installing/Updating_WordPress_with_Subversion#Introduction_to_Using_GIT_with_WordPress
Once you’ve switched to the GIT based workflow, you can significantly simplify the process of local development, testing in staging and pushing to production. It also works well together with the immutable filesystem which can significantly improve the security of your production environment.
Conclusion
When ever you build WordPress websites, plugins or themes – think about the workflow. Make sure to use separate staging and production servers and avoid experimenting on live sites. Take some time and consider moving over to GIT based workflow, it can help you stay organised and allows you to set up stronger security policies for the live sites.
Additional resources: https://maciekpalmowski.dev/blog/deploying-wordpress-with-confidence/
Join the Conversation!
There's a dedicated thread on this post inside of The Admin Bar community. Join in on the conversation, ask questions, and learn more!
Group Thread
Oliver Sild
Oliver Sild is the CEO and Co-founder of Patchstack. He is an entrepreneur and cyber security expert with a strong focus on community building. He has been organising hacking competitions (& local CTF community) in Estonia since 2016, has kickstarted a startup community in his hometown and has nearly 10 years of experience with WordPress security.
