Building WordPress assets

Today I was just finally getting around to (maybe) updating my WordPress theme, and couldn’t for the life of me remember what the deal was with the new Node-based build system. So I went looking, only to find this posted on the Core blog today:

In May 2018 we’ve introduced a build step to WordPress core development as preparation to WordPress 5.0. While these changes never ended up in 5.0, the idea was to reorganize the way the JavaScript in WordPress is managed and structured so that it would be easier to include Gutenberg.

Since then, it was no longer possible to run WordPress from the src folder. This gave some issues, especially with developing WordPress core PHP. Today, @atimmer committed a patch which allows developers to build into src again.

So I do still have to build the assets, but it seems that PHP development can once again happen from the normal directory.

Maybe it’s a good thing that I’ve neglected WP development this last year or so?

Features (my cheatsheet)

The Features module is great. I think. Sometimes it seems too good to be true… usually it just is good though.

One can build a site in one’s local Drupal installation, and then piece by piece export its definition to a feature module that can be put under version control and deployed to other sites in one fell swoop. Start with:

drush fe --version-set=7.x-0.1 --destination=sites/all/modules/custom/featurename featurename components

where featurename is the new module’s name and components is the first thing to export (usually a content type). From then, the destination can be left out, and the components definition is also pretty flexible at making it quicker to select which components to export (naming contentions, such as common prefixes, help with this). So, as the site progresses, export new components to the feature:

drush fe --version-increment featurename components

If a component that’s already been exported needs to be changed, just change it and then update the feature with:

drush fu --version-increment featurename

That’s about all there is to the construction phase. Stick the sites/all/modules/custom/featurename directory into a VCS. Then it’s deployment time…


Check the featurename module out to the staging site (in the custom directory still, just for clarity’s sake) and enable the module:

drush en featurename

That only needs to be done the first time; subsequent updates are just cycles of updating the code and reverting the feature (a note on the slightly-confusing terminology of Features: one reverts (fr) the site, or updates (fu) the code).

$ git pull origin master
$ drush fr featurename

Contributing to Github-hosted projects

Some projects provide information about how people should fork and contribute to them. This is my general approach (included here, obviously, for my own edification):

  1. Fork a project: Github clickity-click
  2. Clone it locally:
    git clone git@github.com:username/project.git
  3. Add the upstream project:
    git remote add upstream git@github.com:upstream/project.git
  4. Do not commit to the master branch; it is to be kept up-to-date with upstream master:
    git pull upstream master
  5. Create branches that solve one feature or issue each, named whatever:
    git branch new-branch-name master
  6. Create a ‘personal master’ named with your username:
    git branch username master
  7. Do not merge master into feature branches, rather rebase these on top of master:
    git rebase new-branch-name
  8. Merge all personal feature branches into your personal master branch, so you’ve got a branch that represents all your development.

My main goal is to create discrete branches, based on the upstream master, for features that I want to push back upstream.

(No doubt I’m missing obvious things, and any git-geek will see instantly the gaps in my knowledge.)

Updates:

To combine the last three commits (and write a new commit message):*

git reset --soft HEAD~3
git commit