Last week, I attended THATCamp CHNM, and I entered (and somehow managed to win) the Maker Challenge with a WP plugin that pulls related items from the DPLA API and displays them on your posts. I’ve just added the plugin to the wordpress.org repository: http://wordpress.org/plugins/wp-dpla.
Read more about the plugin at my THATCamp post: http://chnm2013.thatcamp.org/06/08/maker-challenge-wordpress-plugin-for-displaying-related-items-from-the-dpla/
I’ve just released version 1.4 of BuddyPress Docs, my collaborative editing plugin for BuddyPress. The big new feature is the one that users have been asking for since the plugin was first released: file attachments. I’m using a nifty trick (involving the autogeneration of .htaccess files) to ensure that Doc privacy levels are extended to their attachments. I think it’s going to be useful to a lot of people.
In the future, I plan to write a tool to migrate content created by the abandoned BP Group Documents to this new system. Stay tuned.
This round of development was generously sponsored by the Center for Applied Research and Environmental Systems at the University of Missouri. They are long-time users of BuddyPress, and they were pleased to support the development of this feature for the community. Special thanks to David Cavins, who set up the connection between me and CARES, and also contributed huge amounts of technical, conceptual, and design help to Docs 1.4. (He also builds beautiful guitars.) Thanks to CARES and to David!
WordPress trick: wp_parse_args() is a helpful function for taking configuration arrays passed to a function and combining them intelligently with the default arguments for the function. I needed a recursive version, for use with multi-dimensional arrays of arbitrary depth, so I wrote the little ditty below. As I note in the docs, there are fundamental ambiguities in the process of rectifying multi-d arrays, and the technique I’ve chosen is specific to my implementation. Use at your own risk.
Mostly for my own records, here are a few recent Boone-related videos and interviews from around the web:
This recent article at Smashing Magazine discussed trends and challenges in deploying WordPress sites. The biggest issue cited by the article and the lengthy comments that follow is the issue of the database: because WordPress stores strings in the database that contain the site domain (including configuration options and asset paths), it’s hard to migrate content and config between dev, staging, and production environments. A bunch of possible solutions were offered up, including interconnectit/Search-Replace-DB, which I use fairly often and really like.
I was surprised, however, that no one talked about my preferred strategy, which is, in a way, the simplest: Dev, staging, and production should all have the same domain names. When you remove the need to change the domain, you make it much easier to deploy specific pieces of content, spin up new instances, etc.
Since all versions of a site have the same domain name – say, booneisthebomb.com – I use my local hosts file (/etc/hosts on *nix systems) to switch between instances. So I may have the following lines in /etc/hosts:
[code]
# Local development
# 127.0.0.1 booneisthebomb.com
# Staging site
# 123.456.789.0 booneisthebomb.com
[/code]
With these two lines commented out, going to booneisthebomb.com in a browser will use DNS for the lookup, which is to say it’ll go to the production site. Uncommenting one of the lines allows me to work on the local or staging site.
The biggest pitfall of this technique is that now there is no obvious way to tell your environments apart (and you definitely don’t want to mistake your production site for a dev site). My solution for this is to drop this file into wp-content/mu-plugins/. Then, in my environment file (which contains env-specific config, such as database connection info), I put a line like this:
[code language=”php”]
define( ‘ENV_TYPE’, ‘staging’ );
[/code]
Now, when I load up the staging site, it shows booneisthebomb.com in the URL bar, and the following box appears at the bottom of every page:
Many WordPress plugins and themes need to write to the filesystem, to cache data, create a debug log, download libraries that for one reason or another aren’t distributed with the main package, etc. And many of these plugins do it wrong, by writing (or attempting to write) to their own plugin/theme directories. This is a bad idea for a couple of reasons:
The good news is that every properly-configured WordPress installation will have at least one location where the webserver can write, and which is highly likely to be ignored by all version control setups: the upload directory wp-content/uploads. The situation is more complicated on Multisite, where each site has its own subdirectory of wp-content/blogs.dir. Happily, there’s an easy way to concatenate an upload path that’ll work across installations:
[code language=”php”]
$uploads = wp_upload_dir();
$my_upload_dir = $uploads[‘basedir’] . ‘/yourplugindir’;
[/code]
WordPress has a very slick filesystem class that’ll help you if you really do need to write to a plugin or theme directory. But 99% of the time, you don’t. Please keep your stuff out of the codebase.
This weekend at BuddyCamp Miami (which ruled btw) I chatted with a number of folks about putting GPL clauses into client contracts. It can be especially challenging when working with universities or other bureaucracies that have hardcore, work-for-hire-ish intellectual property clauses already built into their consultant contract boilerplate. On a number of occasions, my clients and I have worked with the legal departments at universities to develop new language that fits the spirit and law of GPL software. In my opinion, this kind of work is among the most important work I’ve done since I started in this business, even more important than most of the software I’ve written. By having the discussions with legal, and by getting free-software-friendly boilerplate on their books, we take steps toward legitimatizing free software in the university, and making it part of the culture.
Anyway, I was asked privately to share some of this contract language, and I figured it would be more useful to do it in a blog post than in an email. So here are a few examples that have been approved by the legal departments at large universities. (Side note: We should come up with a system for sharing these kinds of strategy docs in a more organized way.)
This clause replaced one university’s extremely restrictive IP boilerplate:
Foundation acknowledges and agrees that enhancements, bug fixes and other custom developments produced under the scope of this agreement will be subject to release under the GNU Public License v2, or another compatible and relevant open-source license.
The following clause is added as a footnote to the existing language about IP:
Section VIII (1-3) shall not apply when work is being performed in the public domain. Consultant agrees to comply with the GNU General Public License version 2, as set out in the Attachment #2, when work is being performed in the public domain.
A few notes about the language in this second example (which their lawyers wrote, not me). First, “Attachment #2” is a copy of the GPLv2. Second, I think there is a little bit of confusion here about “public domain”, because strictly speaking, “public domain” means that no one owns the copyright, while the GPL is dependent on copyright. I think the spirit of the phrase “performed in the public domain” is supposed to be something like “written for public consumption”. But a literal reading of this clause probably means that I must relinquish copyright over the work done under this contract into the public domain. In this specific case, the end goal is for me to extend one of my existing GPL-licensed WordPress plugins; so I will then be integrating this newly-created public-domain code into the plugin, and then distributing the whole thing under the GPL, with a note that the newly added library is in the public domain. This is not ideal, but it’s OK for this case where I’m building a standalone add-on for my own work – good enough not to continue negotiations 🙂
If I can dig up others, I’ll post them here. If you have real-life examples, please share in the comments.
I switched to using Vim full-time about nine months ago, but I haven’t yet cracked the nut that is vimdiff. As a result, I’ve been jumping around between various crummy GUIs for git mergetool. Until a few days ago, when I found the excellent Splice.vim (formerly Threesome.vim). Now I’m back in Vim wonderland.
I’ve found Splice to be pretty great for my (albeit limited) mergetool needs – once you figure out how to use it. Splice has pretty good vimdocs, but they’re more of a reference than a tutorial; and getting the necessary information out of the developer’s screencast walkthrough is a needle-haystack exercise. So here’s a quick guide to getting started.
git mergetool – If you never have to manage merge conflicts, you are a better soul than me. I’ve set up a dopey example in the screenshot below.
-[space] to cycle. ([space] is a space character.)
-n to get to your first conflict.1) or the right-hand change (2), you can do so using -u1 (or 2, as the case may be).-n. When you’re done with the file, -q saves all changes and quits all windows. Hit Enter to resolve conflicts in the next file, or if you’ve reached the end of your conflicts, go ahead and commit your changes.Huge thanks to Steve Losh for developing and sharing such an awesome tool.
This week, Google announced that it’s shutting down Reader. This is the first of Google’s “sunsets” that hits me personally – Reader has been a crucial part of my internet use for the better part of a decade. I happen to think, like Marco Arment, that in the long run the loss of Google Reader will probably be good for innovation in RSS readers and for RSS in general. Google’s hamstrung app has been just good enough for people like me, but non-approachable for non-geeks. A year from now, I’m hoping that there’ll be many more quality players. So, in the long run, I’m reasonably optimistic.
More immediately, though, a couple of causes for concern:
Finding an alternative to Reader. My RSS reading habits are too ingrained for me to abandon them, even for a short time. More than that: following RSS feeds is beyond mere habit, but is check on my intellectual honesty. I follow many blogs whose authors I frequently disagree with, or even dislike. (Contrast this with Twitter, where I’m pretty fickle about whom I follow, and how many tweets/links I pay attention to.) So RSS is, for me, a partial antidote to the echo chamber tendency. That means that I’ve got to find a new app, and migrate over, and I’ve got to do it quickly.
There have been a number of posts over the last couple days listing Reader alternatives. A number of them are cloud/service based, and for practical reasons (such as, um, Google Reader) as well as philosophical reasons (see below), I’m only considering alternative tools that I can run either locally or on my own server. A couple that spring to mind:
Get the hell off of Google. We all know that Google is a company with shareholders and profit goals to meet. Yet we often act like Google is some sort of ambient benevolent force on the web. Since I started Project Reclaim, I’ve been working on extricating myself and my data from the clutches of Google (among other corporate entities). Reader’s demise is a wake-up call that the time for dilly-dallying is over.
For my own part, I still use a few Google services besides Reader:
In some of these cases, there are easy ways to get off of the Google services. In others, it’ll be a challenge to find alternatives that provide the same functionality. In any case, the Reader slaughter is a harsh reminder that Project Reclaim has stagnated too long with respect to Google services.
More than myself, I’m worried about others – those who aren’t as technically inclined as I am, or those who simply don’t care as much as I do. Google’s made it pretty clear (as is their right, I guess) that they’re not an ambient benevolence. Those who rely on Google then, especially for critical services like email, should take this warning very seriously. Please consider carefully what you’re doing when you make yourself wholly dependent on the whim’s of Google’s product managers, and consider options that are either free-as-in-speech, or services that you pay for in a traditional way.
Anthologize, I haven’t forgotten about you! I have some very cool stuff in the works, but for now, a quick update on the progress of the campaign-funded work.
Back in 2011, Patrick Murray-John added some unit tests to Anthologize, covering a number of public methods in the TeiApi class. A number of the major refactoring jobs I’m currently undertaking will require additional test coverage, but they are (unlike TeiApi) dependent on WordPress being initalized. So I’ve migrated Anthologize’s tests to use the WP test suite. I’ve used the scaffold provided by the dope and phatte wp-cli (incidentally, I hope that their scaffold becomes the de facto standard for WP plugin tests).
This change means that, in addition to requiring PHPUnit, you’ll also need to have the WP test suite installed. You can install it manually, but I recommend using wp-cli to get the job done in just a command or two. In brief:
$ wp core init-tests /path/to/wp-tests --dbname=wp_test --dbuser=root --dbpass=asd
$ mysql -u'root' -p'asd' -e 'CREATE DATABASE IF NOT EXISTS wp_test'
To run the tests,
$ cd /path/to/wp/wp-content/plugins/anthologize
$ WP_TESTS_DIR=~/path/to/wp-tests phpunit
You can define WP_TESTS_DIR in your .bashrc file for quicker use in the future.
This post is brought to you by Anthologize campaign supporter Demokratie & Dialog. D&D, a Major Sponsor of Anthologize (woo hoo!), is using WordPress and BuddyPress in amazing ways both to study the way that government policy affects youth and to get youth themselves involved in the development of said policy. I had a chance to get to know the very excellent Andreas Karsten of D&D at BuddyCamp Vancouver last year, and we have big plans to start a BuddyPress jazz band. Many thanks for your support of WP, BP, and Anthologize!