Forem: Sarah Siqueira

Automatically Deploying Drupal Projects with GitHub Actions (Modules, Themes & Config)

Sarah Siqueira — Wed, 25 Mar 2026 02:15:06 +0000

When working with Drupal, deployment goes beyond simply uploading modules or themes. Unlike other CMS platforms, Drupal relies heavily on configuration management, Composer dependencies, and database updates.

In this guide, I'll show you how to automatically deploy a Drupal project using GitHub Actions, including custom modules, themes, and configuration changes.

Understanding Drupal Deployment

Before jumping into automation, it's important to understand how Drupal handles deployments.

A Drupal application consists of:

Codebase (modules, themes, core)
Dependencies (managed via Composer)
Configuration (stored in /config/sync)
Database updates

This means deployment is not just copying files, it's a controlled process that ensures consistency across environments.

Project Structure

A typical Drupal project looks like this:

/web
  /modules/custom
  /themes/custom
/config/sync
composer.json

Our custom work (modules/themes) lives inside /web, but everything is orchestrated through Composer and configuration management.

GitHub Actions Workflow

Below is a basic GitHub Actions pipeline to deploy a Drupal project:

name: Deploy Drupal

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: 8.1

      - name: Install dependencies
        run: composer install --no-dev --optimize-autoloader

      - name: Deploy files to server
        run: |
          rsync -avz --delete ./ user@your-server:/var/www/drupal-project

      - name: Run Drupal commands
        run: |
          ssh user@your-server "
            cd /var/www/drupal-project &&
            drush cim -y &&
            drush updb -y &&
            drush cr
          "

What Happens During Deployment

Each deployment executes three critical steps:

1. Import Configuration

drush cim -y

Syncs configuration changes (content types, fields, views, etc.)

2. Run Database Updates

drush updb -y

Applies pending schema changes from modules

3. Clear Cache

drush cr

Ensures Drupal reflects the latest changes

Key Differences from WordPress

If you're coming from WordPress, like me when I started in Drupal, the biggest mindset shift is this:

You don’t deploy just a plugin
You deploy the entire application state

This, in my opniion, makes Drupal deployments more predictable, but also more structured.

Deploying Only a Custom Module - Optional

While not recommended for production workflows, we can deploy only a module:

/web/modules/custom/your_module

However, westill need to clear cache:

drush cr

For a more robust approach, managing our module as a Composer package looks a better choice.

Best Practices

Always version your /config/sync directory
Never edit configuration directly in production
Use Composer for dependency management
Automate Drush commands in your pipeline
Treat Drupal as a full application, not just a CMS

Automating Drupal deployments with GitHub Actions provides a reliable and repeatable workflow. By combining Composer, configuration management, and Drush, we can ensure that every environment stays in sync.

While this approach may feel more complex compared to other CMS platforms, it offers significantly more control and scalability, especially in team environments and production systems.

If you're already automating WordPress deployments, adopting this workflow for Drupal is a natural next step toward more advanced DevOps practices.

Setting Up a Drupal Development Environment with DDEV

Sarah Siqueira — Tue, 24 Mar 2026 22:40:36 +0000

DDEV is a powerful tool that simplifies the process of setting up local development environments for PHP applications, including Drupal. In this guide, I'll walk you through the steps to install DDEV and configure a Drupal development environment.

Requirements:

DDEV
Docker

Once you have this, create your Drupal project directory:

mkdir drupal-site

Into your directory run:

composer create-project drupal/recommended-project:^9 .

At the moment I created this project, running composer create-project drupal/recommended-project . automatically would download Drupal 10, which requires PHP version ">= 8.3.0". This would trigger a fatal error:

Fatal error: Composer detected issues in your platform: Your Composer dependencies require a PHP version ">= 8.3.0". You are running 8.1.27. in /var/www/html/vendor/composer/platform_check.php on line 24
because the DDEV container has an older PHP version. That’s why I explicitly asked for Drupal 9 in the command.

Next, configure DDEV:

ddev config

You will be prompted with some options. Select your project name, docroot location, and then the project type. You’ll see options like:

Project Type [backdrop, craftcms, django4, drupal10, drupal6, drupal7, drupal8, drupal9, laravel, magento, magento2, php, python, shopware6, silverstripe, typo3, wordpress]

In this case, I selected drupal9. After that, run:

ddev start

You will see a success message with the URLs to access your Drupal project: Project can be reached at https://drupal-site.ddev.site https://127.0.0.1:52810

Open your chosen browser and finish the Drupal installation.

Simple as that!

DDEV can be used for a wide variety of PHP-based CMSs, such as WordPress. You can follow a similar process; check out this article: Setting up a WordPress development environment with DDEV.

What is your favorite tool for local PHP development? From my experience with a wide variety of setups over the years, DDEV has proven to be an amazing solution for teams. It simplifies versioning, collaboration, and later establishing deployment pipelines, making development smoother and more predictable.

Leave your comment below. I’d love to hear your thoughts!

Image: https://www.valuebound.com/resources/blog/how-use-ddev-streamline-your-drupal-development-process

Publishing a NPM Package Automatically with GitHub Actions

Sarah Siqueira — Sat, 14 Mar 2026 15:09:11 +0000

That's one is mostly for my future reference, but I hope it’s useful to others too. It’s interesting how different this feels compared to when I started this writing journey three years ago. Today, I can easily search my ChatGPT chat history for solutions. Still, I sometimes feel that relying too much on AI makes me lazier and less focused. Writing forces me to focus, something social media endless scrolling and asking AI can take away.

Before this turns into a philosophical discussion on whether AI will take our jobs, I’ll stick to documenting how I publish an NPM package automatically using GitHub Actions.

Even though AI can now generate .yml workflows almost instantly, I still find writing them myself worthwhile because:

It helps me internalize the knowledge
Understanding what you’re doing is essential, relying blindly on generated code doesn’t help long-term.

Step 1 – Have a Package to Publish

You need a valid Node.js package to publish to NPM. If you don’t have one yet:

Create a package.json with npm init (or npm init -y to skip prompts).
Add your source code and tests.
Make sure your package has a unique name on NPM

For this example, I’m using a QR Code generator I built. It uses Reed-Solomon error correction codes and was a fun exercise to practice logic. The package is usable already, though I’m still not quite happy with that, so I am refining some logic.

Step 2 – Set Up Your NPM Account and Token

To publish packages automatically, you need:

An NPM account
An access token with publish permissions.

Store the token as a GitHub secret at the package repository you want to publis so the workflow we gonna build can access it securely.

Step 3 – Publish Your Package Locally

Before automating, make sure you can publish manually:

npm publish

This ensures your package configuration is correct, dependencies are installed, and there are no errors. You likely gonna be prompet to log at NPM by running this for the very first time.

Step 4 – Automate Publishing with GitHub Actions

Here’s a workflow that automatically generates a GitHub release and publishes to NPM whenever you push a tag.

name: Generate Release and Publish to NPM

on:
  push:
    tags:
      - '*'

jobs:
  build-and-release:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      # Get Tag Name
      - name: Get Tag name
        id: vars
        run: echo "TAG_NAME=${GITHUB_REF_NAME}" >> $GITHUB_ENV

      # Generate GitHub Release
      - name: Create GitHub Release
        uses: softprops/action-gh-release@v2
        with:
          files: ${{ env.ZIP_NAME }}
          body: |
            **QR Code Pack – Version ${{ github.ref_name }}**

            For detailed changes in this version, see the automatically generated notes.
          generate_release_notes: true
          make_latest: "true"
        env:
          GITHUB_TOKEN: ${{ secrets.GH_PAT }}

      # Publish to NPM
      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 20
          registry-url: https://registry.npmjs.org/

      - name: Publish to NPM
        run: npm publish
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

Reference: An Open Source Maintainer's Guide to Publishing npm Package
Image: https://nearform.com/digital-community/publish-npm-packages/

Using GitHub Copilot to Manage Issues (and Save Time)

Sarah Siqueira — Thu, 31 Jul 2025 22:10:32 +0000

Managing issues efficiently is crucial for any project or collaborative development effort. As a maintainer for some or open souce projects, I've always looked for ways to streamline the process of creating, analyzing, and tracking issues. Recently, I've started using GitHub Copilot on my github.com projects to automate and accelerate these tasks, and it’s been surprisingly helpful.

Why Use Copilot for Issue Management?

It’s fast: I can draft and save issues without switching tabs or digging through templates.
It understands the context: Copilot pulls info from the codebase, past issues, etc., so the suggestions aren’t random.
It helps with analysis: You can get a summary or a nicely formatted version of any issue on demand.
Keeps things tidy: Labels, formatting, and author info stay consistent across all issues.

How to Create and Manage Issues Using Copilot (Step-by-Step)

Here’s a practical workflow, based on my recent experience managing issues for a WordPress theme repository:

1. Start a Session with Copilot

You can begin by opening a conversation with Copilot directly on GitHub. Let Copilot know what you need—whether it’s drafting a new issue, analyzing an existing one, or fetching details.

2. Ask for a Draft

Simply tell Copilot your intent, something like:

“Draft an issue for adding Full Site Editing support.”

And Copilot gives me a clean, formatted issue with suggested labels. Sometimes I tweak it a bit, but it’s a solid starting point.

3. Save the Issue

When I’m happy with the draft, I tell Copilot to save it—and it creates the issue with all the usual metadata to your repository like this:

list type="issue"
data:
- url: https://github.com/sarahcssiqueira/base-wp-theme/issues/11
  state: "open"
  draft: false
  title: "Add Full Site Editing (FSE) and Block Theme Support"
  number: 11
  author: sarahcssiqueira
  created_at: "2025-07-26T19:36:28Z"
  closed_at: null
  labels:
    - name: "enhancement"

4. Fetch and Analyze Issues

You can ask Copilot to fetch details for any issue—just provide the issue URL. Copilot returns the data in a clean, YAML format for easy reading, reporting, or further automation.

5. Repeat as Needed

This process can be repeated for any new feature, bug, or enhancement. I go through the same flow. It helps me stay consistent and organized. Copilot keeps track of labels, author, timestamps, and more.

6. Aggregate and Review

Because Copilot outputs issues in a standardized format, you can quickly aggregate, filter, or export issue data for project analysis or reporting.

Example: Workflow Recap

Here’s a summary of what I did using Copilot:

Drafted several issues: For features like FSE support, asset management, performance optimization, and i18n/RTL support.
Saved each issue: Copilot created them on GitHub and provided YAML-formatted data.
Fetched details: I could retrieve or summarize any issue instantly.
Reviewed and analyzed: All issues were ready for tracking and reporting.

Want to See It in Action?

You can check out the actual issues I’ve been working on in this repo: Base WP Theme

Final Thoughts

GitHub Copilot isn’t just for code—it’s a fantastic productivity booster for project management too. If you’re looking to save time, maintain consistency, and analyze your project’s workflow, give Copilot a try for issue management!

Have questions, tips, or your own Copilot workflows? Share below!

Follow me for more insights on open source automation and productivity.

When Physics Meets Code: Did We Find a Bug Fix in the Universe? Is the Universe Debugging Itself?

Sarah Siqueira — Thu, 03 Jul 2025 23:27:36 +0000

This post is very different from the random tutorials I’ve published before (mostly about WordPress). It’s more philosophical and maybe even mind-blowing.

The best programmers I’ve ever met are incredibly curious. They break things and learn how to fix them. Constantly. Same with scientists. The main difference, at least in Brazil, is that developers tend to earn more than scientists on average.

Long story short, I once wanted to be a scientist, a physicist. But I didn’t feel my math skills were strong enough (thanks, Oppenheimer). So I became a developer to pay the bills… and ended up enjoying it.

The actual coding? That’s fun.

Still, part of me never stopped staring at the universe. I often catch myself spotting patterns in everyday life, especially in nature.

It’s like my brain runs on developer mode: I see things as if they were frameworks or packages just waiting to be unpacked.
A seed? Feels like nature’s own NPM package, once installed, it becomes a flower, a tree, or something even more intricate.

I’m constantly trying to “decode” reality through that lens.
And sometimes, it even feels like the whole thing is structured... maybe even designed?

That’s what sparked this random article, written on a cold and boring day.
I was remembering one of the most “whoa” moments I’ve had while on physics college.

Mark this name: James Gates Jr.

Did a Physicist Find Error-Correcting Code in Reality?

Back in college, I read about this guy, the theoretical physicist James Gates Jr. who claimed to have found binary error-correcting codes hidden in the mathematics of string theory.

At the time, I barely knew how to code. But even then, it sounded wild.

I know, it sounds like clickbait. But it’s not.

Strings, Not Particles

I won’t dive deep into string theory here, that would take years and a lot more coffee. But here’s just enough context to follow along:

String theory suggests that the smallest building blocks of reality aren’t particles, but tiny vibrating strings.

Different vibrations = different particles.

It’s a beautiful, deeply mathematical framework that tries to unify gravity, electromagnetism, and nuclear forces. But when researchers dove deeper into supersymmetric string theory, something weird happened...

They found the same kind of codes we developers use to prevent data loss or transmission errors.

Let me be clear: this isn’t pseudoscience or a conspiracy theory. This is high-level math, developed by some of the brightest minds in the world. It deserves, at the very least, our curiosity.

Who Is James Gates Jr.?

Dr. Gates was studying representations of supersymmetry, a principle that (simplified) connects force particles (bosons) and matter particles (fermions).

To visualize these relationships, he used graphical tools called Adinkras.

And while working with these structures, he discovered something surprising:

We discovered that these equations contain codes, actual, literal error-correcting codes. The same ones used in computers to detect and fix errors in digital data.

Specifically, he found:

Doubly-even self-dual binary linear block codes

Wait… What Are Those?

At the time, I didn’t understand any of this. Now, after almost 10 years in development, I feel more at home with these concepts. Here’s a basic breakdown:

Binary: Made of 0s and 1s
Linear: The XOR of any two valid codewords is another valid codeword
Self-dual: The code equals its own dual (like a mirror image)
Doubly-even: All codewords have a number of 1s divisible by 4

These principles are core to digital integrity, and show up in:

ECC memory
Satellite data transmission
DVDs
RAID storage systems

And now, apparently... the math of the universe.

Is the Universe Debugging Itself?

This finding raises a fascinating question:

Is the universe capable of self-correction?

Dr. Gates isn’t saying we’re living in a simulation... but he’s also not saying we’re not.

Finding built-in error-correction logic within physical equations is eerie.

It’s like discovering a try/catch block in raw spacetime.

“If we’re seeing code in the equations of physics,” Dr. Gates said, “maybe there’s a deeper layer to reality. Maybe reality is structured, or computed.”

Honestly? That idea made my brain itch in the best way.

I Built a JS Demo

Because I’m a curious dev (read: obsessive), I wanted to understand how these codes worked. I ended up spending way more time than I should’ve tinkering with C++ and compiling assembly, seriously, I should’ve been out there living life, for God’s sake.

Eventually, I built a small JS demo to visualize how digital integrity is preserved.

You can check out the full demo and source code in my GitHub repository.

It’s basic, but seeing the patterns come alive gave me chills.

Final Thoughts

This stuff is not trivial. It’s complex. It’s deep. And it’s philosophical.

As someone who studied physics for six semesters, I can say I still don’t have the full math chops to understand it all.

And as a web developer? Well, binary code and self-dual logic aren’t exactly part of my day job.

But if you’re curious like me, here’s what you’d need to dive deeper:

Linear Algebra – for understanding vector spaces and matrices
Introduction to Coding Theory – binary linear codes, self-duality
Basic Quantum Mechanics – wave functions, observables
Intro to Supersymmetry – even at a conceptual level
Mathematics of String Theory – only after building the foundation

It’s not easy, it requires both technical depth and mental flexibility. But the implications?

They’re worth exploring.

Because if the universe is built on code, maybe learning this is our way of reading the source.

We usually debug our code.

But what if the universe is debugging itself?

What if physics is full of hidden logic designed to self-correct?

What if developers and physicists are solving similar problems, just on different scales?

Maybe we’re not just building things inside the system.
Maybe we’re studying the system... from the inside.

Just don’t dive too deep without coming up for air. Stare too long into the abyss, it might stare back.

Remember to breathe. Pay your bills. Enjoy your food. Travel. Laugh with people you love.
Live fully, simulation or not, it’s a beautiful one.

But yeah... this is wild. I need some coffee and to go be blissfully dumb for a while.

References

Setting Up a WordPress Development Environment with DDEV

Sarah Siqueira — Thu, 31 Oct 2024 17:01:39 +0000

**DDEV is a powerful tool that simplifies the process of setting up local development environments for PHP applications, including WordPress. Similar to how I explored setting up Drupal with DDEV in another guide, this article will walk you through the steps to install DDEV and configure a WordPress development environment.

Requirements:

DDEV
Docker

Once you have this, create your WordPress project directory:

mkdir wp-test-site

Into your directory run

ddev config

Then, choose the project name and the project type, which in this case will be WordPress. Run

ddev start

You will see the output with the path to access your WordPress installation: https://wp-test.ddev.site https://127.0.0.1:port

Access through your choose browser and finish WordPress install.

Simple as that! (Or should be).

Seems kind of dumb for looking at it now, but on the first time I came across it a few months ago, while setting the dev environment for a new project I was assigned to, in the agency I worked, I got stuck with the error: 403 forbidden nginx for quite some time.

It took me a few to me realize the thing was: there were no WordPress core files into my root project folder.

The solution?

Download the WordPress files to the root folder, duuh.But, it not practical do it everytime I had to start the project. So, my plan here:

Edit the config.yml on .ddev folder

Within the root project folder, find the ./ddev/config.yml file and add this:

hooks:
  post-start:
    - exec: "curl -O https://wordpress.org/latest.tar.gz"
    - exec: "tar -xzf latest.tar.gz --strip-components=1"
    - exec: "rm latest.tar.gz" on config.yml.

What this does is:

post-start: This hook runs commands after the DDEV project starts.

And the commands:

curl -O https://wordpress.org/latest.tar.gz: Downloads the latest version of WordPress.
tar -xzf latest.tar.gz --strip-components=1: Extracts the contents of the tar file into the current directory, removing the top-level directory from the extracted files.
rm latest.tar.gz: Cleans up by removing the downloaded tar file.

You can also add a conditional check to verify if the WordPress core files are present, otherwise, everytime you run ddev stop and then ddev start again, it will download the WordPress core files all over again, we don't need that.

Command updated with conditional checks:


hooks:
  post-start:
      - exec: '[ ! -f wp-load.php ] && (curl -O https://wordpress.org/latest.tar.gz && tar -xzf latest.tar.gz --strip-components=1 && rm latest.tar.gz) || echo "WordPress core files already present, skipping download."'

This ensures that the hooks only run the installation if WordPress is not already present. By run ddev start on your terminal, if the WordPress core files are present, you will see the message "WordPress core files already present, skipping download." instead.

Finally, start Your DDEV Project

Run:

ddev start

The first time, may take more time, depending on your internet connection, as it will need to install the core files. But the next times, will be easy peasy.

Important Note: Make sure to run ddev start from your project root directory, where the config.yaml file is located.

It's incredibly useful to share projects among teams, we can also add some other features like ddev pull, to pull the DB of a staging website your team is working for example. You can a*dd environment variables and so on*, but this is out of the scope of this article, which was simply to explain how to start a DDEV environment in a few steps.

I had an old docker environment I developed for personal use over time, wrote about it here. It was a such improvement for me back then (moving from ancient XAMPP), but now, it seems so poor compared to DDEV lol.

That's it for now. Start work with DDEV and Happy coding!

Fixing PHP_CodeSniffer Null Trim() Errors in WordPress Coding Standards

Sarah Siqueira — Tue, 15 Oct 2024 18:41:41 +0000

While working on WordPress projects with PHP 8.x, you may encounter the following error:

Fatal error: Uncaught PHP_CodeSniffer\Exceptions\RuntimeException: trim(): Passing null to parameter #1 ($string) of type string is deprecated in /path/...

This error occurs due to a deprecation warning in PHP 8.x, where passing null to the trim() function is no longer permitted. Specifically, this issue arises within a WordPress Coding Standards (WPCS) sniff, part of the PHP_CodeSniffer setup. As of the date of this writing, even with the latest versions of PHP_CodeSniffer and WordPress Coding Standards, this issue persists.

Understanding PHP_CodeSniffer and WPCS

PHP_CodeSniffer is a tool that helps developers maintain coding standards by checking their PHP code for violations of specified rules. WordPress Coding Standards (WPCS) provide a set of guidelines for writing consistent and clean code in WordPress projects. The error mentioned above typically indicates that a code snippet is not adhering to these standards due to changes in PHP's behavior.

Fixing

To fix this, we can manually modify the file causing the issue, locate the line where trim() is called and update the code to ensuring that null values are properly handled when calling trim().

For example, in the file vendor/wp-coding-standards/wpcs/WordPress/Sniffs/NamingConventions/PrefixAllGlobalsSniff.php, locate line 280 and replace the following line:

// this 
$cl_prefixes = trim( PHPCSHelper::get_config_data( 'prefixes' );

// to this 

$cl_prefixes = is_null( PHPCSHelper::get_config_data( 'prefixes' ) ) ? '' : trim( PHPCSHelper::get_config_data( 'prefixes' ) );

However, as in lots of decisions in software development, just because you can do this, doesn't mean you should.

While the previous approach may fix the error, it's important to remember that modifying vendor files is not a sustainable solution. Changes will be lost every time you update your dependencies via Composer.

A better approach, then, is to create a patch file.

Creating a Patch File

Here is a step-by-step guide on how to create and apply a patch for the issue

Create the Patch File

A more robust solution is to create a patch file. This method allows you to apply your changes automatically every time you install or update your dependencies.

A patch file is a text file that contains the differences between two versions of a file—essentially a "before" and "after" snapshot.

In your project directory, create a folder to hold the patch file:

mkdir -p patches

Inside the patches/ folder, create a new patch file called fix-null-trim.patch. You can do this with your text editor:

touch patches/fix-null-trim.patch

Open fix-null-trim.patch in your text editor and add the following content:

  --- a/vendor/wp-coding-standards/wpcs/WordPress/Sniffs/NamingConventions/PrefixAllGlobalsSniff.php
+++ b/vendor/wp-coding-standards/wpcs/WordPress/Sniffs/NamingConventions/PrefixAllGlobalsSniff.php
@@ -280,7 +280,7 @@

        // Original code with `trim()`
        // Update this line:
-       $cl_prefixes = trim( PHPCSHelper::get_config_data( 'prefixes' ) );
+       $cl_prefixes = is_null( PHPCSHelper::get_config_data( 'prefixes' ) ) ? '' : trim( PHPCSHelper::get_config_data( 'prefixes' ) );

--- a/vendor/wp-coding-standards/wpcs/WordPress/Sniffs/WP/I18nSniff.php
+++ b/vendor/wp-coding-standards/wpcs/WordPress/Sniffs/WP/I18nSniff.php
@@ -194,7 +194,7 @@

        // Original code with `trim()`
        // Update this line:
-       $cl_text_domain = trim( PHPCSHelper::get_config_data( 'text_domain' ) );
+       $cl_text_domain = is_null(PHPCSHelper::get_config_data( 'text_domain' )) ? '' : trim( PHPCSHelper::get_config_data( 'text_domain' ) );

--- a/vendor/wp-coding-standards/wpcs/WordPress/Sniffs/Sniff.php
+++ b/vendor/wp-coding-standards/wpcs/WordPress/Sniffs/Sniff.php
@@ -1144,7 +1144,7 @@

        // Original code with `trim()`
        // Update this line:
-       $cl_supported_version = trim( PHPCSHelper::get_config_data( 'minimum_supported_wp_version' ) );
+       $cl_supported_version = is_null(PHPCSHelper::get_config_data( 'minimum_supported_wp_version' )) ? '' : trim( PHPCSHelper::get_config_data( 'minimum_supported_wp_version' ) );

This patch tells Composer to replace the problematic line in PrefixAllGlobalsSniff.php with a safer version that uses the null coalescing operator (??) to avoid passing null to trim().

Modify composer.json to Apply the Patch

Next, you need to instruct Composer to apply this patch automatically whenever you install or update your dependencies.

Open your project's composer.json file. Add the following configuration under the "extra" section. If the "extra" section does not already exist, you will need to create it.

    json

    "extra": {
        "patches": {
            "wp-coding-standards/wpcs": {
                "Fix null trim() issue": "patches/fix-null-trim.patch"
            }
        }
    }

This tells Composer to apply the fix-null-trim.patch file to the wp-coding-standards/wpcs package when it installs or updates dependencies.

Install the Composer Patch Plugin

To apply patches via Composer, you need the composer-patches plugin.Run the following command to install:

composer require cweagans/composer-patches

Apply the Patch

Now, you can apply the patch by running the following command:

composer install

During the installation, Composer will apply the patch from the patches/ folder to the PrefixAllGlobalsSniff.php file.

By creating and applying a patch file, you ensure that your fixes persist across Composer updates, adhering to best practices in software development. Regularly monitor updates to PHP_CodeSniffer and WordPress Coding Standards, as these issues may be resolved in future releases. This proactive approach not only enhances code quality but also improves your development workflow in PHP 8.x environments.

I've shared the patch file in this Gist. Feel free to use it as a reference to implement similar fixes in your projects!

Managing Ruby versions on macOS Apple Silicon with rbenv

Sarah Siqueira — Mon, 02 Sep 2024 14:47:53 +0000

Imagine this common scenario: You need to use a specific Ruby version, so you check which one is currently installed by running:

ruby -v

The output shows:

output ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin23]

Realizing that you need a newer version, you attempt to update Ruby. However, after running the update, you check the version again with ruby -v, only to see the same output as before:

output ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin23]

Why Does This Happen?

This issue occurs because macOS comes with a system version of Ruby pre-installed. This version is managed by the operating system and is located in a system directory, usually /usr/bin. Even if you install a new Ruby version using tools like Homebrew, your terminal may still point to the system’s default Ruby version because it appears earlier in your $PATH.

The $PATH is an environment variable that tells your shell where to look for executable files. If the system Ruby appears first in your $PATH, running ruby -v will return the system version instead of the one you just installed.

To override this, you need to manage Ruby versions using a version manager like rbenv, which can properly set the desired Ruby version as the default.

How to 'fix' this?

To resolve this issue, you can use rbenv, a lightweight tool that allows you to easily install and manage multiple Ruby versions.

What is rbenv?

rbenv is a version management tool for Ruby. It allows you to switch between multiple Ruby versions without needing to mess with your system’s default Ruby installation. With rbenv, you can:

Install multiple versions of Ruby: Easily install and use any Ruby version;
Switch between Ruby versions: Set a global default Ruby version or specify a Ruby version for a specific project.
Simplify your Ruby setup: Avoid issues with conflicting Ruby versions, which is particularly useful if you're working on multiple projects with different Ruby dependencies.

Install rbenv

First, install rbenv using Homebrew:

brew install rbenv

This command also installs ruby-build, a plugin for rbenv that simplifies the process of installing new Ruby versions.

Configure Your Shell

Next, you need to configure your shell to use rbenv by adding the following line to your shell's configuration file:

If you're using Bash, open .bash_profile:

nano .bash_profile

If you're using Zsh (the default on macOS), open .zshrc:

nano .zhrc

At the beginning of the file, add this line:

eval "$(rbenv init -)"

This command sets up your shell to load rbenv automatically, allowing it to manage your Ruby versions seamlessly.

Reload your shell configuration:

For Bash:

source ~/.bash_profile

For Zsh:

source ~/.zshrc

Verify rbenv Installation

To verify that rbenv is installed correctly, run:

type rbenv

This should return a path indicating that rbenv is set up. If it does, you're ready to start managing Ruby versions with rbenv.

Install the Desired Ruby Version

Now, list all available Ruby versions:

rbenv install --list-all

This will display a long list of Ruby versions. Choose the one you need (e.g., 3.3.3) and install it:

rbenv install 3.3.3

This command downloads, compiles, and installs the specified Ruby version on your system.

Set the Ruby Version Globally

To set this newly installed Ruby version as the global default, run:

rbenv global 3.3.3

Verify the Ruby Version

Finally, let's check that the correct Ruby version is now active:

ruby -v

You should see the updated version:

output: ruby 3.3.3p20 (2022-04-12 revision 4491bb740a) [arm64-darwin23]

And that's it! You have successfully updated Ruby on your macOS system using rbenv. Whenever you need to switch to a different Ruby version in the future, simply run rbenv install --list-all to view the available versions and install the one you need.

Additional rbenv Tips

Local Versions: If you need a different Ruby version for a specific project, you can set a local Ruby version by navigating to the project directory and running:

rbenv local 2.7.6

This will create a .ruby-version file in the project directory that tells rbenv to use the specified version of Ruby whenever you're working in that directory.

Rehashing: After installing a new Ruby version or a gem with executables, run:

rbenv rehash

This updates rbenv's shims, making the new commands available in your shell.

Uninstalling Ruby Versions: If you ever need to remove a Ruby version, simply run:

rbenv uninstall 2.6.10

With rbenv, managing multiple Ruby versions becomes simple and straightforward, making it an essential tool for any Ruby developer!

Run PHPUnit locally in your WordPress Plugin with DDEV

Sarah Siqueira — Thu, 27 Jun 2024 17:16:49 +0000

While working with WordPress over the years, I have used multiple solutions for local developments, ranging from old XAMPP setups and transferring files with FTP on FileZilla to Docker custom environments. By the way, here is an example of one of my Dockers you can refer.

Recently, I discovered DDEV. DDEV is an open source tool for launching local web development environments that can be extended, version controlled, and shared across a team easily. With DDEV, we can take advantage of a Docker workflow without Docker experience. Cool right? Of course, it is important to know how docker works under the hood, and beginners should experiment with it. However, later on, why to reinvent the wheel? Give DDEV a chance, and you won't regret it.

Okay, I am digressing; the focus here is PHPUnit for plugins. As with many of my other articles, my goal is to create a reference for myself to use when I need it in the future.

Given my DDEV environment running, I also want to run tests locally in my projects, in this case a WordPress plugin.

Requirements:

DDEV
Docker
PHP 8.3
MySQL
SVN
git
WP-CLI
wget
plugin-folder

The versions for PHP, PHPUnit and PHP Code Coverage I am using, were the compatible ones on the date I am writing this post, June 2024. To check compatibility with PHPUnit and PHP, please refer to official documentation.

First step is to install PHPUnit if it is not installed yet. There are multiple ways to do this, but I choose to do it per project, through Composer with the following command in the plugin root folder:

composer require --dev phpunit/phpunit ^9.5

Also, will need those dependencies:

composer require --dev phpunit/php-code-coverage ^9.2

Remembering proper unit tests for a plugin or theme would not load WordPress. By loading WordPress those will be integration tests.

That said, to generate the plugin test files, run on your plugin root folder:

ddev exec wp scaffold plugin-tests your-plugin-name

While working in a DDEV environment, don't forget to use ddev exec before wp cli commands.

Next, run the install script (which will require wget):

bash bin/install-wp-tests.sh wordpress_test root '' localhost latest

The script above first installs a copy of WordPress in the /tmp directory (by default) as well as the WordPress unit testing tools. Then it creates a database to be used while running tests. More details here.

Error: The PHPUnit Polyfills library is a requirement for running the WP test suite.
If you are trying to run plugin/theme integration tests, make sure the PHPUnit Polyfills library (https://github.com/Yoast/PHPUnit-Polyfills) is available and either load the autoload file of this library in your own test bootstrap before calling the WP Core test bootstrap file; or set the absolute path to the PHPUnit Polyfills library in a "WP_TESTS_PHPUNIT_POLYFILLS_PATH" constant to allow the WP Core bootstrap to load the Polyfills.
If you are trying to run the WP Core tests, make sure to set the "WP_RUN_CORE_TESTS" constant to 1 and run composer update -W before running the tests.
Once the dependencies are installed, you can run the tests using the Composer-installed version of PHPUnit or using a PHPUnit phar file, but the dependencies do need to be installed whichever way the tests are run.

To fix the error above, install:

composer require --dev yoast/phpunit-polyfills *

Edit the ./tests/bootstrap.php file created with the previous scaffold step, in order to require this file:

require dirname( dirname( __FILE__ ) ) . '/vendor/yoast/phpunit-polyfills/phpunitpolyfills-autoload.php';

Start to write your tests!

Run tests by using ./vendor/bin/phpunit filename or register a Composer script, as I did:

"scripts": { "test": "vendor/bin/phpunit" },

Now, I can simply run composer test filename and that's it!

My WordPress learning journey, so far...

Sarah Siqueira — Mon, 06 May 2024 23:11:30 +0000

I started to work with WordPress back in 2015, while in physics college, just to get some money. At first, as a freelancer, I was just a plugin/theme installer by saying so, with no clue about how things worked under the hood.

Over time, I needed to understand how WordPress plugins and themes were hosted, which led me to learn about host companies and set DNS domains, and tasks using CPanel. Later on, I had to work with VPS, hosted by companies like Digital Ocean and AWS. Also, that's how I learned to work with Apache, NGINX, and Linux servers back in 2016.

WordPress under the hood

Ok, after working on tasks setting up all DNS domains, installing WordPress, connecting with the database, choosing a theme, and installing plugins for clients' projects, I came to the question: How do those themes and plugins interact with those bunch of WordPress core files downloaded from WordPress.org? To understand that, one of the things I had to learn was PHP, which started in 2016. With PHP knowledge I was able to actually understand WordPress - even wrote an article about that: WordPress under the Hood.

WordPress themes

Despite the amazing themes available for download on WordPress.org, I needed to make websites look beautiful to the client's eyes, and sometimes the projects needed further customizations. That led me to research, learn, and work with WordPress themes. Initially, I learned how to create WordPress child themes, and later on, finally learned to create my own themes - something I am still learning to be honest.

Here are two open-source themes I worked on, you can see here and here.
In the process of creating a WordPress theme, I needed to handle the frontend part, which led me to dive, among other things, into CSS and JavaScript about 6 years ago, in 2017.

CSS

CSS can be very tricky if we underestimate it. If you work alone on a project and everything is still fresh in your head, it's easy to maintain, but after some time, if you don't structure things well, it becomes a nightmare to maintain.

When you jump into a project with distributed teams, you must find ways to organize things. After that conclusion, one of the things I started to learn was SCSS, which proved to be great for my needs and my chosen option nowadays. However, compiling all the files took SCSS a lot much time. To increase productivity and get rid of this manual task, I learned Gulp.
Somehow I read that Weppack was more complete but had a bigger learning curve, well, I am not afraid to research, so I learned Webpack, my way to go nowadays.

Here is a Webpack sample I developed to work in a WordPress theme.

JavaScript

JavaScript was also required to create mobile menus and carousels for example. The same problem with CSS arose in JavaScript: compiling and minifying those files used to take so long, here is where Webpack shows up again and is very handy.
Again, my webpack configuration file is here.
Of course, JavaScript is not used only for that, there are a million possible uses, and that's why something I keep learning and searching (and will do forever).

E-commerce

In 2018, after this journey as a freelancer, I started an e-commerce of pet supplies. The project was and still is based on WordPress and Woo (former WooCommerce). During this time, I faced lots of challenges being the most experienced IT person in the room at some points.
On the e-commerce, aspect, Woo has several amazing plugins to enhance an e-commerce project, but paying for them was not an option back then. At that point, among other tasks, I started to learn how to build plugins.

WordPress plugins

Due to our tiny budget, I had to create our own plugins, like this to customize order status or this other one to create custom post types.

MySQL

What tells about databases? Last year, I worked in server migration, from AWS to Digital Ocean LAMP server, migrating all tables of a WordPress/Woo project, handling errors with data formats, and primary keys, cleaning data that was not needed anymore, optimizing, changing the collation for InnoDB.
I like to use PhpMyAdmin as a tool to handle those MySQL-related tasks.

Coding Standards

There are multiple ways to solve the same problem, also we can organize files differently, but in the open-source world, using standards makes it easier to share your work with others.
Today, I use Composer to manage PHP_CodeSniffer rules like WordPress Coding Standards. I wrote an article about how to set up it correctly.

As a project grows, everyone involved must speak the same language, it will make things way easier and will help with productivity.

React and Next

Yes, I had to learn React to work with WordPress, but that's a subject for another post, I think.

DevOps

In the WordPress context, deployment is basically synchronizing plugins and theme files to the respective paths.

I used the old approach, syncing files through FTP - which is not a very productive approach let's be honest - so I started to use automation like GitHub actions for CI/CD.

In this repository, I share some workflow samples to deploy WordPress projects.

My next steps

Right now, in my learning journey, I am focusing on exploring advanced WordPress aspects like Gutenberg Blocks and Block Themes. Also trying to improve my writing test skills with PHPUnit.

Through the years, I got the ability to see the bigger picture. And if got stuck on some problem I don't know exactly how to solve, I am not afraid to jump in and acquire the needed missing skill. That's my learning approach, sometimes I get lost banging my head against the wall, but when I finally get why something is happening, that's my friends is the funny part of this work.

And you? What about your learning journey? Any suggestions about something I need to learn/explore?

Syncing a Spreadsheet with Google Calendar using Google Scripts to be (or at least try) more productive

Sarah Siqueira — Sat, 04 Nov 2023 17:53:35 +0000

Remote working requires discipline, that's a fact. And I must admit I have this problem of lack of focus, I am curious and easily get bored, I am always tempted to start a new project because of some random article I read. That's something I have been fighting against since I was 17 years old in my first job in an accountant's office. For a long time, I was told that was my weakness.

Later, at some point I became a developer and realized this curiosity and eagerness to learn something new could also be my biggest strength, as long I could be able to not get lost in my random ideas.

I tried to find tools to help me be more productive and there are lots of books about that, tutorials, coaches' lectures, etc. I tried several approaches through the years but guess what? Furthermore, I didn't was able to use any fancy tool with consistency, no matter how awesome were the tools.

After trying dozens, and hundreds of productivity tools I realized the one that would work for me was that I would be able to follow with consistency, and turns out the obvious answer was right in front of my eyes: Excel.

Microsoft Excel doesn't require a presentation, and I know it can seem boring for developers, but it is a tool I always liked and learned to use in my account work times. Well, I do not know how to do those insane things the guys from the financial market do, but I can do one thing or another. It also was a tool I used with some consistency for making notes and even for controlling my finances.

Why does not apply to control my dev working routine? And what about if I could share it with my team? That would be perfect.
Okay, new awesome project idea. How could I do that?

As a Google products fan, I moved to Google Spreadsheets and started to register my work planning and any new project idea in a Spreadsheet, similar to this one here. I was also using Google Calendar to schedule meetings, etc., so why not synchronize everything?

After some googling, I discovered some product add-ons available, but none of them seemed right for my needs. Then, a few more googling to discover how those product add-ons for Google Workspace were made.

I discovered Google Apps Scripts, and now we finally reach the main point of this post: to share how we can synchronize a Google Spreadsheet with a Google Calendar using Google App Scripts.

Requirements

Google Account
Some JavaScript Knowledge
Google Spreadsheets and Google Calendar familiarity

Because we are going to handle data formats, we need to be careful with the spreadsheet to avoid errors. That's a sample of my current spreadsheet already correctly formatted to work with the following script.

Step 1 - Log in your Google Account

After login to your Google Account, at your spreadsheet menu, go to the tab Extensions > Apps Script

Click on it, and now you are in the Google Apps Script editor:

The Google Apps Script Editor is a web-based integrated development environment (IDE) provided by Google for creating, editing, and deploying custom scripts and automation solutions for various Google Workspace (formerly G Suite) applications. It allows users to write code in JavaScript to extend the functionality of Google Apps, automate tasks, and build custom applications within the Google ecosystem.

Give a name to your project, I called mine Sheet & Calendar Synchronizer:

Step 2 - Write the code

In the web-based IDE, paste the following codes, and make sure to make the proper replacements.

To create or update events

function createorUpdateEvents() {

  /*
  * Open the Calendar
  */
  const calendarId = 'YOUR CALENDAR ID';
  const sheet = SpreadsheetApp.getActiveSheet();

  /*
  * Import events data from the spreadsheet
  */
  const events = sheet.getRange("A2:G1000").getValues();

  /*
  * Event details for creating an event
  */

  let event; // Declare event variable outside the loop

  for ( i = 0; i < events.length; i++ ) {
    const shift = events[i];
    const eventID = shift[0];
    const eventsubject = shift[1];
    const startTime = shift[2];
    const endTime = shift[3];
    const description = shift[4];
    const color = shift[5];


     // Check if all variables are defined
      if (
        eventID !== undefined && 
        eventsubject !== undefined && 
        description !== undefined && 
        color !== undefined && 
        startTime instanceof Date && 
        endTime instanceof Date
        ) {
        const event = {
            id: eventID,
            summary: eventsubject,
            description: description,
            'start': {
                'dateTime': startTime.toISOString(),
                'timeZone': 'America/Sao_Paulo'
            },
            'end': {
                'dateTime': endTime.toISOString(),
                'timeZone': 'America/Sao_Paulo'
            },
            colorId: color
        };

        /** 
        * Insert or update event
        **/
       try {
        let createOrUpdate;
        if (event.id) {
          createOrUpdate = Calendar.Events.update(event, calendarId, eventID);
        } else {
          createOrUpdate = Calendar.Events.insert(event, calendarId);
        }
      } catch (e) {
        if (e.message && e.message.indexOf("Not Found") !== -1) {
          createOrUpdate = Calendar.Events.insert(event, calendarId);
        } else {
          console.error("Error:", e);
        }
      }
    }
  }
}

Replace 'YOUR CALENDAR ID' with your Google Calendar ID.

To get events from Calendar to Sheet

function exportCalendarEventsToSheet() {

  const calendarId = 'YOUR CALENDAR ID';
  const startDate = new Date('2023-01-01');
  const endDate = new Date('2023-12-31');
  const calendar = CalendarApp.getCalendarById(calendarId);
  const sheet = SpreadsheetApp.getActiveSheet();
  const events = calendar.getEvents(startDate, endDate);
  const data = [];


  if (events.length > 0) {
    for (let i = 0; i < events.length; i++) {
      const event = events[i];
      const eventID = event.getId().split('@')[0];
      const eventTitle = event.getTitle();
      const startTime = event.getStartTime();
      const endTime = event.getEndTime();
      const description = event.getDescription();
      const color = event.getColor();

      data.push([eventID, eventTitle, startTime, endTime, description, color]);
    }

    const numRows = data.length;
    const numCols = data[0].length;
    sheet.getRange(2, 1, numRows, numCols).setValues(data);
  } else {
    console.log('No events exist for the specified range');
  }
}

Step 3 - Add services

In the left panel, add the services Google Calendar API and Google Sheets API

Step 4 - Run the code

You need to run the scripts, you can do that by clicking on run in the web-based IDE every time you need.

However, that is not practical for daily basis use. So we will need a few more codes to create a menu that will allow us to run the code directly through the Google spreadsheets menu.

Step 5 - The Menu Code

In the editor, place the following code:

function onOpen() {
  var ui = SpreadsheetApp.getUi();
  ui.createMenu('Sync Data with Calendar')
    .addItem('Calendar to Sheet', 'exportCalendarEventsToSheet')
    .addItem('Sheet to Calendar', 'createorUpdateEvents')
    .addSeparator()
    .addSubMenu(
      ui.createMenu('About')
        .addItem('Documentation', 'showDocumentation')
    )
    .addToUi();
}

function showDocumentation() {
  var htmlOutput = HtmlService.createHtmlOutput('<p>For more info, visit <a href="https://github.com/sarahcssiqueira/google-sheets-calendar-synchronizer" target="_blank">this link</a>.');
  var ui = SpreadsheetApp.getUi();
  ui.showModalDialog(htmlOutput, 'Documentation');
}

function closeDialog() {
  google.script.host.close();
}

This will create a menu like the one in the image, and you will be able to execute the scripts directly from the spreadsheet menu.

Step 6 - Give permissions

The first time you try to use the project by clicking on the menu button, you may be asked to give permission. Allow.

Usage

Create the spreadsheet where you intend to save your events and actually list your events, following this format.

Once you hit the Sheet to Calendar button, it will create or updates all events listed in the spreadsheet in the Google Calendar you choose.

You can also drag and drop your events on Calendar, and by hitting the Calendar to Sheet button, these changes will be reflected in the spreadsheet.

About the event's colors

There are eleven colors available we can use, those colors should be listed in the color column or selected in the Calendar. More info here.

This code was written for personal use, so certainly there are room for improvement. Feel free to improve giving your suggestions in the comments below or even through PR in GitHub. If it was useful for you, please consider leaving a star in the repository.

References

Automatically deploying WordPress plugins and/or themes with GitHub actions

Sarah Siqueira — Tue, 24 Oct 2023 21:29:47 +0000

There are a lot of ways in which a WordPress GitHub integration can be helpful in WordPress development and project collaboration. One of them is in deploy routines with automatic deployments, instead of the cowboy coding approach, using FTP, manually grabbing our themes and/or plugin files, and uploading them manually using software like FileZilla, we can deploy directly from GitHub to our live WordPress site.

That's why I wrote this post and, as always, to record what I did for when I forget it in a few months from now.

We will review how to set up a WordPress GitHub integration to manage the deployment of our WordPress themes and WordPress plugins, which can save us a lot of time and is especially important if we are using custom themes and plugins.

We will not cover:

The WordPress Core: Well, we should never edit core WordPress files, so it doesn't make sense to include the core files in our repository.
The database: Trying to version control the WordPress database opens up a can of worms and we will not open that now.
WordPress development of plugins and themes: I am assuming you have this done, ready to deploy.

Let's get started with the sample workflows we will gonna use to synchronize our WordPress themes and plugins!

Deploying a WordPress Theme

The following .yml code is used to synchronize the theme files you coded, with the /wp-content/themes folder in your server. For a LAMP server hosted in a company like Digital Ocean, that's a sample workflow:

name: Deploy Theme

on:
  push:
    branches: [master]

env:
  SSH_USER: ${{ secrets.SSH_USER }}
  SSH_HOST: ${{ secrets.SSH_HOST }}

jobs:
  deploy:
    name: Deploy WordPress Theme on Digital Ocean
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Set SSH Connection
        run: |
          mkdir -p ~/.ssh/
          echo "$SSH_KEY" > ~/.ssh/deploy.key
          chmod 600 ~/.ssh/deploy.key
          cat >>~/.ssh/config <<END
          Host digitalocean
            HostName $SSH_HOST
            User $SSH_USER
            IdentityFile ~/.ssh/deploy.key
            StrictHostKeyChecking no
          END
        env:
          SSH_KEY: ${{ secrets.DEPLOY_KEY }}

      - name: Sync theme files
        run: "rsync --delete -avO
          --exclude /deploy_key \
          --exclude /.git/ \
          --exclude /.github/ \
          ./ ${{ env.SSH_USER }}@${{ env.SSH_HOST }}:${{ env.DEST }}"
        env:
          SSH_HOST: digitalocean
          # That's the most commom path in a WordPress instalation on a LAMP stack,
          # but you can change the destination according to your needs.
          DEST: "/var/www/your-domain/wp-content/themes/theme-folder"

Workflow name

In the first line we have the workflow name name: Deploy Theme.

Workflow triggers

Later, we have the trigger definition, in this case, whenever I push a commit to the master branch on the repository with my WordPress theme, the workflow will be triggered. You can custom that, for more details, you can refer to GitHub documentation.

on:
  push:
    branches: [master]

Secrets

I create variables for the custom secrets. More info here.

env:
  SSH_USER: ${{ secrets.SSH_USER }}
  SSH_HOST: ${{ secrets.SSH_HOST }}

Jobs

The jobs section in a GitHub Actions workflow file defines one or more jobs to be executed when a workflow is triggered.

jobs:
  deploy:
    name: Deploy WordPress Theme on Digital Ocean
    runs-on: ubuntu-latest

In the case above:

deploy is the name of the job, which can be customized to describe the job's purpose.
name is an optional field we use to making it more understandable when viewing the workflow.
runs-on specifies the type of virtual environment or runner on which the job will be executed. In this case, it uses the ubuntu-latest runner, indicating that the job runs on the latest available version of the Ubuntu operating system.

Steps

The steps section in a GitHub Actions workflow file defines a series of individual tasks that are executed as part of a job.

steps:
      - name: Checkout
        uses: actions/checkout@v2

In the case above:

steps: contains a list of actions to be executed in the specified order.
name: is an optional field we use to making it more understandable when viewing the workflow.
uses: Specifies the action to be performed. In this example, the actions/checkout@v2 action is used to check out the source code repository.

Setting SSH Conection

This is the section of your workflow responsible to sets up an SSH connection for secure access to our remote host.

name: Set SSH Connection
        run: |
          mkdir -p ~/.ssh/
          echo "$SSH_KEY" > ~/.ssh/deploy.key
          chmod 600 ~/.ssh/deploy.key
          cat >>~/.ssh/config <<END
          Host digitalocean
            HostName $SSH_HOST
            User $SSH_USER
            IdentityFile ~/.ssh/deploy.key
            StrictHostKeyChecking no
          END
        env:
          SSH_KEY: ${{ secrets.DEPLOY_KEY }}

- name: as in the previous parts, it's a optional field making it more understandable for us, ins this case we will see: Set SSH Connection.

run defines the steps or shell commands to execute. In this case:
- Creates the ~/.ssh/ directory if it doesn't already exist.
- Writes the SSH key, stored in the SSH_KEY environment variable, to ~/.ssh/deploy.key.
- Sets the permissions of ~/.ssh/deploy.key to ensure it's only accessible by the user.
- Appends SSH configuration to ~/.ssh/config, including the hostname, username, and path to the SSH key.
- Additionally, it disables strict host key checking for the "digitalocean" host.
env section specifies environment variables used in the workflow, in this case, it defines the SSH_KEY variable and retrieves its value from a GitHub secret (DEPLOY_KEY).

Syncing the theme files:

This syncing section is responsible for syncing theme files to the remote server using the rsync command. In some hosts, may be necessaire to install manually rsync.

  - name: Sync theme files
        run: "rsync --delete -avO
          --exclude /deploy_key \
          --exclude /.git/ \
          --exclude /.github/ \
          ./ ${{ env.SSH_USER }}@${{ env.SSH_HOST }}:${{ env.DEST }}"

The rsync command performs the following tasks:

--delete: Ensures that files deleted locally are also deleted on the remote server.
-avO: Sets rsync options for archive mode, verbose output, and optimization.
--exclude: Specifies which files or directories to exclude from the synchronization. In this example, it excludes the /deploy_key, /.git/, and /.github/ folders, but you can customize according to your project.
./: Specifies the source directory to sync from, which is the current directory of the workflow.
${{ env.SSH_USER }}@${{ env.SSH_HOST }}:${{ env.DEST }}:Specifies the destination for the synchronization. It uses environment variables for the SSH username, host, and destination path.

The var definition

In this section there are some other environment variables that are used within the workflow.

 env:
          SSH_HOST: digitalocean
          # That's the most commom path in a WordPress instalation on a LAMP stack,
          # but you can change the destination according to your needs.
          DEST: "/var/www/your-domain/wp-content/themes/theme-folder"

Deploying a WordPress Plugin

To deploy a plugin, you can follow the same idea above, just changing the deploy path to /var/www/your-domain/wp-content/plugins/plugin-folder

The sample workflow below:


name: Deploy Plugin

on:
  push:
    branches: [master]

env:
  SSH_USER: ${{ secrets.SSH_USER }}
  SSH_HOST: ${{ secrets.SSH_HOST }}

jobs:
  deploy:
    name: Deploy WordPress Plugin on Digital Ocean
    runs-on: ubuntu-20.04

    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Set SSH Connection
        run: |
          mkdir -p ~/.ssh/
          echo "$SSH_KEY" > ~/.ssh/deploy.key
          chmod 600 ~/.ssh/deploy.key
          cat >>~/.ssh/config <<END
          Host digitalocean
            HostName $SSH_HOST
            User $SSH_USER
            IdentityFile ~/.ssh/deploy.key
            StrictHostKeyChecking no
          END
        env:
          SSH_KEY: ${{ secrets.DEPLOY_KEY }}

      - name: Sync plugin files
        run: "rsync --delete -avO
          --exclude /deploy_key \
          --exclude /.git/ \
          --exclude /.github/ \
          ./ ${{ env.SSH_USER }}@${{ env.SSH_HOST }}:${{ env.DEST }}"
        env:
          SSH_HOST: digitalocean
          # That's the most commom path in a WordPress instalation on a LAMP stack,
          # but you can change the destination according to your needs.
          DEST: "/var/www/your-domain/wp-content/plugins/plugin-folder"

That's my repository with some sample workflows customized for different servers. Be free to contribute through pull requests adding more workflows or even suggest improvements to the current ones. If that was useful for you, please consider leaving a star in the repository.

References and special thanks to: