DDD Perth 2019

On Saturday I went to my second DDD Perth conference. This is an annual one-day event that seems to bill itself as being something different from the usual tech conference and to be more accessible to people who might not normally go to these things. Which, I reckon, is pretty great; it feels like a more friendly place (even though I am the sort of person who usually goes to these sorts of things). There is something of a corporate vibe, though, which sort of mars the ‘community’ aspect — although that’s where the low price of the tickets comes from, so I shouldn’t complain!

The welcome to country was done by Nick Abraham, who gave an interesting talk. I liked the lists that he rattled off the names of families he’s part of and places they’re from.

All of the presentations that I went to were interesting, but the two that have stuck with me were about CSS Grid (Amy Kapernick), and WebAuthn (Ben Lowry). I want to experiment with both in my personal projects. Don’t suppose I’ll do so, though. (Too many fun things to explore; not enough time.)

I’m very glad that the Perth developer community is able to support this sort of event these days.

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