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:
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?
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
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…
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
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):
- Fork a project: Github clickity-click
- Clone it locally:
git clone firstname.lastname@example.org:username/project.git
- Add the upstream project:
git remote add upstream email@example.com:upstream/project.git
- Do not commit to the
master branch; it is to be kept up-to-date with upstream master:
git pull upstream master
- Create branches that solve one feature or issue each, named whatever:
git branch new-branch-name master
- Create a ‘personal master’ named with your username:
git branch username master
- Do not merge master into feature branches, rather rebase these on top of master:
git rebase new-branch-name
- 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.)
To combine the last three commits (and write a new commit message):*
git reset --soft HEAD~3
The second version of Image-Flicker now available. This release fixes a problem with quoting and entities in the description field. If there’s anything I’ve missed, please let me know in a comment to this post. Thanks!