I’m a mac user and, as familiar as I am with docker, I have always used local development software for the sake of convenience. In recent months, however, I have switched from MAMP to LocalWp, this software makes it very easy to create a ready and reliable development environment and has a very convenient feature for cloning projects.
Working for small agencies and individual clients, I often find myself using the same plugins, starting theme and configurations. Using LocalWp I have the ability to create a starter site with everything I need ready and configured and with one click clone it so I can start with a new project. Local also has other very useful features such as wp-cli, backups and image optimisations that save me a lot of time.
In a future post I will explain in detail the plugins I use, configurations, and other details about creating my monolithic showcase and e-commerce sites, but now let’s assume that we have finished making the site and moved it into production with a simple duplicator, so we can move on to other information I want to share with you in this article.
In most of my projects, barring specific features that I plan to reuse in multiple projects, I write all the code related to site-specific features, styles, and custom elements ( I call them elements since I use a premium theme that uses WPBakery ) within a child theme.
Let us now look at how I organize this child theme and how I maintain synchronisation between local and production
On this repository I uploaded my starter theme, which is a child theme using salient as the parent theme. Within this project you will be able to find the standard elements of a child theme, such as the files: style.css and functions.php , but I have decided to add parcel for .scss management, which I find very convenient, and a github action for direct publishing to each push via FTP.
Let’s see the two configurations in detail.
Parcel
I decided to adopt Parcel because it is a zero-configuration build tool. In my case, as you see from the project, I only had to add a dependency “parcel-namer-custom” to not have variable output file names but a fixed one that allows me to enqueue from functions.php.
GitHub Action
At the following path .github/workflows/main.yml you’ll find a very interesting job for the publication in production of the theme at each push, with the addition of the .gitignore that will allow github to ignore much of the code that is only needed in the development environment. These two files together will allow us to publish only the necessary .php and .css files. Obviously a better approach would be to allow the committing of all code and to exclude in this job in the exclude statement the publishing of the development files, or start it only on commit on main and use a branch development.
As I wrote above, a second scenario is that of plugins where I write code that needs to be published not only on one website but that is relevant to many more projects. I will share my solution for having a private repository and automatic WordPress updates with you in a future article.
If the information in this article was helpful to you, I recommend moving on to the next article in this series: https://blog.riccardodicurti.it/my-thoughts-on-css
Published: 7/19/2023