WordPress Packagist VS composer-patches

If I have to use WordPress for something, I'll build it as a standard PHP project, requiring WordPress and any themes/plugins as a Composer dependencies from johnpbloch/wordpress and WordPress Packagist (more info here). If I need to do any significant templating, I like to use Timber.

Use it together with https://wpackagist.org/ and you can update all plugins/themes by latest or by version number.

Another option you can look at is Bedrock by Roots - that is sets WP as an app with composer already set up. It allows you to install WP plugins (from official WP repo) via composer (WP Packagist). The structure is set up to allow for git workflow. Also helpful if you want to make use of a bunch of composer packages on your site.

https://wpackagist.org/ in the example you see "repositories", now in that array you can put your plugins github-link and set the other settings. with composer install you install them and with composer update you update them

Side question: I know that the WordPress ecosystem has been moving toward better support for Composer – e.g., with WPackagist. But wouldn't plugins installed/updated via Composer run into the same issue?

if you're using composer with joomla, and the plugin is installed via composer, you can commission someone to make the necessary changes, create a git diff patch that encapsulates the changes, then leverage cweagans/composer-patches to make it work. if/when new changes are necessary, they can build a new patch.

I've had problems with libraries using final having an API that isn't customizable enough in a particular way I need because I'm innovating in some way they could never have considered in the past, so my choice ends up either needing to fork the library or monkey patch it with https://github.com/cweagans/composer-patches so I can get rid of final so I can keep using it. They wouldn't accept a change in API or behaviour because it would break things for other users, etc.

There are cool tools to integrate patches from drupal.org (or your own custom patches) into your composer managed drupal website. For example (not drupal specific but works well with drupal+composer): https://github.com/cweagans/composer-patches

If the PR get's merged, I want `yay` or `pacman` to skip the patch. Ideally it would be declared in a pacman.patches file or similar to what https://github.com/cweagans/composer-patches provides for composer PHP package managment.

This has been an issue for a while, and is outlined here: - https://github.com/cweagans/composer-patches/issues/172#issuecomment-587147692 - https://github.com/cweagans/composer-patches/issues/326

Install a package that allows the composer to work with patches:

And if for some reason you do not want to make a fork, you can also create a composer patch with the help of https://github.com/cweagans/composer-patches

https://github.com/cweagans/composer-patches - this lets you patch packages when they are pulled in by Composer. I have used it in the past to get minor bugfixes into a project ASAP without having to wait for upstream or forking the entire package.