DEV Community: dottxado

Manage your WordPress plugin without knowing SVN

dottxado — Mon, 22 Nov 2021 14:42:30 +0000

My Workflow

Despite I started my web developer career using SVN, I changed job in 2 years and moved from SVN to git without returning back. I use daily git, both with a GUI and on the cli, but SVN...well, I have to use it only when I want to release the plugins that I have published on the WordPress repository (...so rarely!).
So, when I finally have will&time to work on my plugins, I also have to remember how to manage the SVN repository, what cli commands use, where I parked the SVN managed code, and usually I have to install it because in the mean time I have played with my OS.

I know, I know...you can say "SVN is easy", "The commands you need to remember are just 2", "You are complaining too much".
No, my answer is: I want a smarter way to manage my SVN repositories.

After the last OS change, I finally decided that came the time to find this smarter way and found a lot of GitHub Actions that I can use to deploy my plugin on the SVN repository starting from the GitHub repository...Fantastic, in this way I don't need to install SVN locally and host the repository to commit new versions to it, but we are missing a step for the final smart solution.

As a background information, you need to know that the WordPress SVN repository is meant to be a release repository, not a versioning repository, so you are warmly invited to remove the old tags and maintain inside the SVN only the current release.

The actions that I found only commit to SVN the new tag, but don't manage the removal of the old tags, leaving this step to be done locally, hosting the repository and committing the deletion of the old tags.

Here I introduce you the final housekeeping step for your SVN repository, my GitHub Action "WordPress SVN tag cleaner".

I can finally manage my plugins without ever knowing what is SVN!

Submission Category:

Maintainer Must-Haves

Yaml File or Link to Code

You can already find an example workflow in the readme of the Action.

dottxado / action-wordpress-svn-tag-cleaner

Take care of your plugin SVN repository cleaning the old tags with this GitHub Action

WordPress SVN tag cleaner

This GitHub Action deletes a specified folder tag from your WordPress SVN plugin repository.

Configuration

Required secrets

SVN_USERNAME
SVN_PASSWORD

Set these secrets in the repository settings.

Required inputs

Tag to remove (tag-to-remove): please require this input in your workflow

Optional environment variables

SLUG: the WordPress repository slug. It defaults to the GitHub repository name

Example workflow

This example demonstrate a simple manual workflow

name: Remove old tags from SVN
on:
  workflow_dispatch:
    inputs:
      tag-to-remove:
        description: 'Tag to remove'
        required: true
jobs:
  remove-tag:
    runs-on: ubuntu-latest
    name: Remove the tag
    steps:
      - uses: dottxado/action-wordpress-svn-tag-cleaner@1.0.0
        with:
          tag-to-remove: ${{ github.event.inputs.tag-to-remove }}
        env:
          SVN_USERNAME: ${{ secrets.SVN_USERNAME }}
          SVN_PASSWORD: ${{ secrets.SVN_PASSWORD }}

View on GitHub

The action is not automatic on git hooks but requires as input the tag to remove.

Additional Resources / Info

I use this workflow on my WooCommerce plugin, check it out here!

dottxado / email-fields-for-woocommerce

WordPress plugin to add or modify the Reply-to and Bcc addresses on WooCommerce emails.

Email Fields For WooCommerce

Add or modify the Reply-to and Bcc addresses on WooCommerce emails.

Description

This plugin can be used to globally modify the Reply-to and/or Bcc addresses used by WooCommerce for all its emails.

Configuration

In the WooCommerce settings, go to the "Emails" tab, and in the bottom of the page you will find two fields for the Reply-to address, and one field for the Bcc address. Only if you configure these addresses, these will overwrite any WooCommerce standard address. You can configure only the Reply-to or only the Bcc, but the Reply-to needs both it's fields to be configured to work.

View on GitHub

How to replicate my WordPress/Symfony local development environment on MacOS

dottxado — Sun, 13 Dec 2020 11:03:38 +0000

As a part of my job, I develop custom WordPress plugins and themes. The other part of my job is to develop applications using Symfony, so for me is crucial to have a development environment that supports both my activities without compromises. I’ve found my perfect balance using these tools:

I will avoid to explain what are these tools, but I have added the links to let you go directly to each website.

The easy part with Homebrew

Using Homebrew I can install pretty everything, except for the Symfony binary. If it can be useful to you, here is my Brewfile (search for “brew bundle”, it is an easy way to let Homebrew know what to install following a list into a file).

tap "exolnet/deprecated"
tap "garethlawson/php"
brew "node"
brew "composer"
brew "dnsmasq", restart_service: true
brew "git"
brew "imagemagick"
brew "mailhog", restart_service: true
brew "mysql@5.7", restart_service: true, link: true
brew "nginx", restart_service: true
brew "php", link: false
brew "php-code-sniffer"
brew "php@7.2", restart_service: true, link: true
brew "php@7.3"
brew "pkg-config"
brew "postgresql"
brew "wp-cli"
brew "exolnet/deprecated/php@7.0"
brew "exolnet/deprecated/php@7.1"

So let’s start and install PHP, Composer and Laravel Valet following the guide on the Valet website

When it’s time to install the database you can continue to follow the guide or, for example, you can install in the same manner PostgreSql.

If you know that you are going to develop on WordPress multisites, you need to add to Valet a custom driver to manage the multisite: I’m currently using this and it has never failed, just follow the one-line instruction on top for installation

Continuing with the things you can install with Homebrew, proceed installing Mailhog, PHP Code Sniffer and WP CLI.
This is also the moment when I install the Symfony binary.

You can test Valet, WP CLI and the database, but not the others. Now it’s time to finish some configurations.

Finishing the configuration of PHP Code Sniffer

PHP Code Sniffer needs to have the sniffs configured. It come with a basic set of sniffs, but you can add the WordPress ones following the documentation here (I prefer the standalone version)
Depending on your IDE setup, you would have to setup all from the command line, or you can have your IDE to manage the sniffs. In my case, with PHPStorm I need only to setup the PHP Code Sniffer path and the rules to follow at the beginning of the project.

Tweaking Valet

After 2 years I’ve collected 2 setups to apply to the servers: more timeout for MySQL and more timeout for Valet.

For MySQL, add these rows in the file /usr/local/etc/my.cnf (and tweak them to your use cases)

interactive_timeout = 1000
wait_timeout = 1000
max_allowed_packet=160M

For Valet follow this guide

Manage a lot of PHP versions

I develop on a lot of different applications, and I need all the PHP minor versions of the 7. I have found how to install them via Homebrew (look at my Brewfile), and I need that the PHP version used by the web server is the same used by the command line. To achieve that, I have my precious .zshrc file to setup the global PATH:

export VALET_PHP_70="/usr/local/Cellar/php@7.0/7.0.33/bin/"
export VALET_PHP_71="/usr/local/Cellar/php@7.1/7.1.33/bin/"
export VALET_PHP_72="/usr/local/Cellar/php@7.2/7.2.32/bin/"
export VALET_PHP_73="/usr/local/Cellar/php@7.3/7.3.23/bin/"
export VALET_PHP_74="/usr/local/Cellar/php/7.4.11/bin/"
export BREW_MYSQL="/usr/local/opt/mysql@5.7/bin"
export COMPOSER_PATH="$HOME/.composer/vendor/bin"
export SYMFONY="$HOME/.symfony/bin"
export PATH="$VALET_PHP_72:$BREW_MYSQL:$COMPOSER_PATH:$SYMFONY:$PATH"

Every time I change the version with Valet, I also link into the operating system’s path the right PHP version. As you can see, when I picked both the Brewfile and the .zshrc file I was working with PHP 7.2, and there is also the Symfony binary path.

Install XDebug

I have always looked at the installation of XDebug like a pain, but frankly with this environment it is not. Just remember that if you (like me) need more PHP versions ready to work, you will have to repeat these steps for each version you linked in the $PATH into the .zshrc

First, instal XDebug with pecl:

pecl install xdebug

Then into the folder /usr/local/etc/php/[YOUR PHP VERSION]/conf.d put a new ini file, let’s call it xdebug.ini with the configurations to run it, for example mine is:

xdebug.remote_enable=1
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000
xdebug.remote_autostart=1
# I don't use anymore this last line, but I keep it in case of need
xdebug.idekey="PHPSTORM"

…and that’s it. On PHPStorm I just check the XDebug port and hit the debug icon of the telephone.

Configure Mailhog

Knowing that you are already here (/usr/local/etc/php/[YOUR PHP VERSION]/conf.d) put another new .ini file, call it mailhog.ini and add into it this line without changing anything (except the Mailhog version if needed):

sendmail_path = /usr/local/Cellar/mailhog/1.0.0/bin/MailHog sendmail test@test

Install Image Magick

If you need it, you have already installed something with Homebrew (see the Brewfile, there is pkg-config and imagemagick). If you don’t need it you can remove them from the installation with Homebrew, but if you need it you have to continue the installation with:

pecl install imagick

As you have done for XDebug, this command needs also to be run for each PHP version you want to use.

Conclusion

If you have read this article untill here…well, thank you! Let me know: what are you using for your local development environment? And what do you think I can change to improve mine?