Security Weekly

How to Make the WordPress Development Process Safer

Cleanshot 2023 11 30 At 14.14.30

Published:

Cleanshot 2023 11 30 At 14.14.30

Oliver Sild

Patchstack

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.

Week 22

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
Cleanshot 2023 11 30 At 14.14.30

Oliver Sild

Patchstack

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.

Brought to you by:
Logo

Patchstack auto-mitigates security vulnerabilities found on WordPress core, plugins and themes. Patchstack is the leading vulnerability intelligence provider in the entire WordPress ecosystem and has the largest collection of vulnerability specific vPatch rules that provide precision protection without any performance hit nor false positives. Patchstack is the go-to security provider for many of the leading agencies such as 10up, Valet, SiteCare and others.

Never Miss an Issue!

Subscribe and have Security Weekly delivered to your inbox every week!

Come Join Us!

Join the #1 WordPress Community and dive into conversations covering every aspect of running an agency!

Kyle Van Deusen

Community Manager

More from Security Weekly

Week 25

Getting Started with Access Management (Password Managers)

One of the most basic security related question I’m constantly being asked is “What password manager …

Week 24

How to Deal with Incoming Security Reports

Sometimes developers and security researchers find bugs accidentally or when intentionally testing software security. If they …

Week 23

Are Your WordPress Sites Really Isolated From Each Other?

We’ve touched the topic of site isolation in February on an episode covering server level security. …