Tag: trac

How I commit to WordPress

This past week at WordCamp US in Portland, a group of core committers gathered one day after lunch to discuss our individual workflows for committing to core.

As you might expect, everybody works and organizes things a bit differently and so we were encouraged to share our individual workflows.

A few have already shared:

And now here’s mine.

Development environment

As a recently-emerged-from-emeritus-status core committer, my local development environment is, on the whole, vastly different today than it was “back in the day” when I was a lot more active.

So for its latest iteration, I’ve opted for a subversion checkout of the core development package and I’ve leveraged the built-in docker environment that ships with it. Easy peasy.

git and svn and git-svn, oh my!

I know some committers like to use git for development alongside subversion or even git-svn for the actual commits, but I’m comfortable with doing everything in subversion so that’s all I’ve been using lately.

I did a subversion check out and started up the docker development environment inside it.

Applying patches

I was delighted to discover that grunt patch is still available from the old days in the core development package, so that’s what I am still using to apply patches from Trac or GitHub:

grunt patch:123456
grunt patch:https://github.com/WordPress/wordpress-develop/pull/6880

If for some reason I have a local patch file, I’ll simply apply it with:

patch -p0 < whatever.diff

Reviewing changes

To see changed files I prefer to quickly check in the terminal with svn stat -q

To review changes, I’ve had an alias called changes set up for ages that I use quite a lot to generate a local diff and open it. Nothing terribly complicated:

alias changes="svn diff > changes.diff; open changes.diff;

Committing

As I mentioned, I’ve opted to stick with vanilla subversion for this go-round.

While I do sometimes find myself missing git’s “patch mode” as an easy way to review what’s being changed in the moment right before commit, using my changes alias just before commit has about the same utility.

I’ve got TextMate set up as my terminal editor, and thus calling svn commit will launch a TextMate window for me to write the commit message:

Component: Commit message.

Props ...
See/Fixes #123456

That’s about all there is to it.

WordPress 3.3 Could Improve Child Theme Integration

According to a recent WordPress trac ticket, theme authors could soon be rewarded with a little nugget of functionality that would make using child themes much more extensible.

The ticket suggests introducing a function that works similarly to locate_template(), but rather than returning the path of the file (in the parent theme only), it would return a URI to the file, thus allowing a child theme to override the parent’s .js, .css and even image files. The proposed function is called locate_theme_file().

According to the suggested patch posted by johnbillion, this is the current method for loading template files in parent themes only:


wp_enqueue_style( 'dark', get_template_directory_uri() . '/colors/dark.css', array(), null );

If locate_theme_file() is introduced, we could instead see functions like these:


wp_enqueue_style( 'dark', locate_theme_file( 'colors/dark.css' ), array(), null ); 

wp_enqueue_style( 'bar', locate_theme_file( 'bar.css' ) );

<img src="<?php echo locate_theme_file( 'icon.png' ); ?>" />

locate_theme_file() would automatically load any of these files via the child theme, BEFORE the parent. Pretty neat huh?

Up to this point, child themes could only override a parent theme’s template files. If theme authors are rewarded with the ability to enqueue many more types of files at the child theme level with this much ease, I anticipate seeing some really exciting new uses for child themes emerging.