Monthly Archives: January 2014

Default Gravatar images and SSL

· 6 Replies

I have a client who runs a number of WordPress/BuddyPress sites over SSL. He noticed in the last few days that default Gravatar images – the images that Gravatar serves when there is no Gravatar associated with the queried email address – were not being served. The browser showed broken images, and when you attempted to load the associated https://secure.gravatar.com URL in a separate tab, you’d see the message “We cannot complete this request, remote data could not be fetched”.

After a bit of futzing around, I found this recent post by Eric Mann describing a similar issue with the Photon CDN feature in the Jetpack plugin. He managed to figure out that Automattic’s CDN service wasn’t fetching items that were served over HTTPS. (The fact that it ever worked was, apparently, a bug; that “bug” was recently fixed.)

It turns out that the same thing is true for Gravatar’s “Default Image” feature (unsurprising, as I assume it uses the same CDN as Photon). Gravatar lets you specify a local file that will be served if no actual Gravatar is found: <img src="https://www.gravatar.com/avatar/00000000000000000000000000000000?d=http%3A%2F%2Fexample.com%2Fimages%2Favatar.jpg" /> But, as of the last few weeks, if the value of the d= param is served over HTTPS only, Gravatar throws an error.

There are a couple strategies for working around the problem.

  • Use Gravatar’s defaults instead – Gravatar hosts a number of default images that you can use, instead of a local image. This is especially pertinent in the case of BuddyPress. BP’s default behavior is to construct Gravatar requests like this: https://www.gravatar.com/avatar/00000000000000000000000000000000?d=http%3A%2F%2Fexample.com%2Fimages%2Fwp-content%2Fplugins%2Fbuddypress%2Fbp-core%2Fimages%2Fmystery-man.jpg. The thing is that this mystery-man.jpg that ships with BuddyPress is the same image as what you get with ?d=mm. So an easy way around the problem of Gravatar reading from your SSL-protected site is to avoid Gravatar from making any requests to your site at all. In BuddyPress, use the following:

    [code language=”php”]
    function bbg_use_gravatar_mm() {
    return ‘mm’;
    }
    add_filter( ‘bp_core_mysteryman_src’, ‘bbg_use_gravatar_mm’ );
    [/code]

  • Allow non-SSL access to your default – As suggested in Eric’s post, you can tell your webserver that some of your content can be served over HTTP rather than HTTPS. For example, on one of the sites I’m working on, we force HTTPS for all requests using an .htaccess rule. I can amend it to allow an exception for the custom Gravatar default:

    [code]
    RewriteCond %{HTTPS} off
    RewriteCond %{REQUEST_URI} !^/wp-content/themes/yourtheme/images/default-gravatar.jpg$
    RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R,L]
    [/code]

    Then, force BuddyPress to tell Gravatar you want the non-SSL version of the fallback:

    [code language=”php”]
    function bbg_custom_default_avatar() {
    return set_url_scheme( get_stylesheet_directory_uri() . ‘/images/default-gravatar.jpg’, ‘http’ );
    }
    add_filter( ‘bp_core_mysteryman_src’, ‘bbg_custom_default_avatar’ );
    [/code]

Even if you’re not using BuddyPress or WordPress, the same strategy applies: if you’re serving your whole site over HTTPS, tell Gravatar to use either one of its own images or one of your non-SSL-available images as its default.

Convert multi-db WordPress mysqldump to single-db

· Leave a reply

On a number of client sites, I use HyperDB or SharDB to spread a WordPress Multisite installation across multiple databases on a single server. However, in my local dev environments, it’s annoying to have thousands of databases. So I use the following technique to create a copy of the remote site that operates in a single database locally.

  1. Use mysqldump to get a backup file. The following command ensures that you don’t pull in information_schema or any other unrelated databases; you can add other DBs to ignore to the NOT IN list:
    [code language=”bash”]
    $ mysql -u [username] -p -B -N -e “SELECT SCHEMA_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME NOT IN (‘mysql’,’tmp’,’innodb’,’information_schema’,’performance_schema’)” | xargs mysqldump -u [username] -p –add-drop-table –skip-lock-tables –quick –extended-insert –result-file=[path/to/your/dumpfile.sql] –databases
    [/code]
  2. Use sed to remove all the ‘CREATE DATABASE’ and ‘USE’ lines in the dumpfile. This prevents the multiple databases from being created when importing locally.
    [code language=”bash”]
    $ sed -i ” -e’/^CREATE DATABASE /d’ /path/to/dumpfile.sql
    $ sed -i ” -e’/^USE /d’ /path/to/dumpfile.sql
    [/code]
  3. Get the dumpfile to your local machine, and import:
    [code language=”bash”]
    $ mysql -u [username] -p -e “create database foo”
    $ mysql -u [username] -p foo < ~/path/to/local/dumpfile.sql [/code] (or whatever technique you use for mysql imports) (don't know why my code formatter is converting < to &lt; but you get the idea).

The pleasure of being a lone wolf

· 9 Replies

The WordPress consulting world has, of late, been all about consolidation and upsizing. Firms get larger by hiring independents and acquiring smaller businesses. Every week I read countless tweets and blog posts about the joys of working for a larger team: the camaraderie, the efficiencies of scale, the pleasure of getting a regular paycheck. And as a longtime solo freelancer, I’m very sensitive to the shortcomings of being a lone wolf.

At the same time, I try not to forget the beauty of going it alone. First and foremost is the flexibility. Aside from my personal expenses, I have no payroll and practically no overhead. I’m able to turn down work that seems unpleasant or doesn’t jibe with my philosophical predilections, even when the work would pay very well. If I have a good few months and feel like not taking on any more projects for a while, I can do so. I can spend as much time as I’d like working pro bono on free software. On the flip side, when someone approaches with a project that sounds fun but might not pay well, I can take it, guilt-free.

Flying solo also means that I’m constantly being integrated in and out of new teams and projects. I’m constantly exposed to new workflows, new tools, new technologies, new ideas. Sometimes the rootlessness feels lonely, but it can also be exhilarating.

It’s not so bad being a loner.

Getting started with WordPress plugin development

· 8 Replies

I got an email with the following question, and figured I may as well answer publicly. The question comes from someone who’s an experienced programmer, but has never worked with WordPress before.

[…] I wondered if you had some helpful advice on learning the basics of WP plugin development. I’m mostly hoping there are frameworks/libraries that the community is currently using.

I don’t know of a widely-used library of general WP plugin development tools. Partly this is because WP itself partially qualifies as a “library”, insofar as it provides ready-to-use functions for saving data to the database, URL routing, template loading, user management, etc. And partly it’s because the architecture of WP is so wide open that it’d be difficult to build a more generalized library that covered even a majority of the possible modifications you might make to stock WordPress.

That said, here are a few useful tools that I know of:

  • The official WP documentation on writing a plugin is good for learning about plugin manifests as well as a top-level overview of the aspects of plugin development.
  • The official Plugin API page is also a good starting point. It explains WP’s hook system, which is the foundation for plugin development.
  • Pippin Williamson has written a series called Plugin Development 101 that features a set of video tutorials on common plugin development techniques. Costs a couple bucks, but Pippin is a smart dude and I’m sure the videos are a really good way to get started.
  • There are a couple of tools that can be used to generate boilerplate and basic file setup for plugins. The ones I know of are https://github.com/tommcfarlin/WordPress-Plugin-Boilerplate and the wp scaffold plugin command in WP-CLI.
  • The book Professional WordPress Plugin Development is very solid, and a good investment for those who like to learn this kinda stuff through books.

My #1 piece of advice to people getting started with WP plugin development is to find a plugin that does something sorta like what they are trying to do and to reverse engineer it. For me, this is far faster and more practical than any hello-world tutorial or sequential set of lessons. YMMV.

If anyone has other suggestions, please feel free to add them in the comments.

WP-CLI tools for BuddyPress

· 1 Reply

I think we can all agree that WP-CLI is the cat’s pajamas. Starting today, I’ll be maintaining a small (but growing) library of BuddyPress commands for WP-CLI: wp-cli-buddypress. Available commands are currently quite meager (and quite biased toward my needs as a developer rather than a site admin), but I’ll be building more, and would be delighted to receive pull requests.

Sony service does not screw it up

· Leave a reply

While I was out of town over Christmas, the keyboard on my Sony Vaio Pro laptop stopped working. I was annoyed.

When I got back to New York, I called for warranty support. I was told to drop the laptop off at the Sony store, where two different technicians shook their heads in befuddlement at the fact that I’d removed Windows from the machine. They warned me that the service tech would probably have to do a factory reset, because it’s necessary to boot to Windows to complete the service checklist. I was very annoyed.

I got the laptop back today. To my delight, my data had not been touched. The Sony tech managed to work around the unsupported OS, booting from an unsupported bootloader that requires non-standard BIOS settings, with Dvorak as the default keyboard layout. To that tech, wherever he or she is: thanks, and well done. (I’ll overlook the crappy Intel stickers you reapplied.)

Commit messages, tickets, and inline docs

· Leave a reply

As a Trained Academic™, I try to think about software documentation in terms of audience and purpose. Who is going to read technical docs? What will they be trying to learn by reading them? I use these questions as a lens for writing different kinds of documentation.

I like to think of commit messages as the canonical technical narrative of the project. These messages matter most for two groups of people: those following the ongoing development of the project, and those intrepid future souls who are combing through logs to track the lineage of given bit of code. The needs of the two groups are similar, which suggests certain content and formatting for commit messages. Both groups are scanning sizable streams of changesets, and thus need a quick way to disregard those that are irrelevant to them. That’s where the one-line summary is helpful, for git log and GUIs like this. Beyond the summary, they usually need a bit more context, a bird’s-eye summary of the problem the changeset is intended to fix. They need pointers to full discussions (ie, linked tickets). And because in projects like WordPress the changelog is also an attribution log, they need reference to the person responsible for the fix (“props”). It’s these kinds of needs I’m thinking about when I structure commit messages like this. (Side note: I’m a big fan of this post arguing for a similar commit message format.)

Tickets are bug notices or feature requests as they appear in the project’s issue tracker. The primary audience here is the developers, designers, and users who are currently involved in the ongoing development of the software. It’s a workspace, and it’s messy. Tickets may contain extended discussions, with numerous digressions and dead-end patches. It’s for this reason that issue tickets are not a replacement for good commit messages. Commit messages contain justification for changesets, while trackers contain the process that led to that justification.

Inline docs, primarily in the form of function/method/class docblocks, are intended first and foremost for developers who are currently trying to figure out how the software works. As a rule, these people don’t care about the history of the project, or the reasoning that led to a given piece of code. The documentation should answer questions like: where is this function used in the codebase? if I put x into the function, what will I get out of it? etc. While it’s often good to have pointers to the project history in certain cases – such as a link to a ticket that explains why an unintuitive bit of code works in the way it does – it probably does more harm than good to litter inline documentation with details about the project’s intellectual history. That’s what blame tools are for.

It goes without saying that there are gray areas. Commit messages, tickets, and inline docs all have the same “text” as their subject: the codebase. And the intended audiences for the three kinds of documentation are frequently overlapping. Still, I think it’s helpful to keep the distinctions in mind. When you write documentation, you’re writing the story of the project as it’ll be understand by future coder-historians. You want to make sure that the story makes sense.

A less finicky BuddyPress search

· Leave a reply

BuddyPress search, out of the box, is not very good. Say you’re looking for a group called “History of Wars in America”. The search term Wars in America will return the group, but America Wars will not. (Technical reason: search terms get lumped as a single string into a MySQL LIKE clause.)

I have some ideas about how to improve this behavior in BuddyPress itself, including stealing some of the goodies that recently went into WordPress. But for now, here’s a simple drop-in filter that fixes the word-wise problem.

(if the formatting is messed up, view the original at https://gist.github.com/boonebgorges/8301715)

Something very similar would work for members searches, though the query variables passed along to the filters probably have a slightly different syntax. (I made these changes for City Tech OpenLab, whose members queries are custom anyway.)

Again, this filter is not perfect – it doesn’t try to do any caching, it doesn’t look for literal strings in quotes, etc – but you might find it useful until some real fixes are in place in BP.

Affirmations for the free software developer

A friend recently came to me to express some frustration. He’s the leader of a relatively new free software project, and was having his first run-in with a user who was making extensive, arguably unreasonable support demands, in a tone that was increasingly hostile. If you’ve ever contributed to a public project, you have probably had similar experiences.

I responded to him with the following words of “wisdom”. Nothing terribly original here, but I have to remind myself of these points on a regular basis.

  • For every one user who engages with you in an unpleasant way, there are 10 users who provide feedback and request support in a friendly and reasonable manner, and 100 people who are using the software happily and asking for nothing.
  • People only bother to complain about something if they care about it.
  • Obviously, you want to be fair and kind to people who come to you for help. But your capacity to give a shit is like currency: it exists in finite quantities. It’s better to spend it on something that’ll provide positive good in the world, than to dump it into a bottomless pit.

Brooklyn is for runners

· 6 Replies

I lived in Brooklyn when I started running in my mid-twenties. I didn’t know it at the time, but I was spoiled.

I never really enjoyed running for its own sake. I did it because my then-girlfriend (now-wife) was a serious runner, and because I wanted to continue to eat and drink as I pleased without risking my girlish figure. I managed to tolerate running thanks only to my Brooklyn backdrop. Over the course of about five years, I ran some 5,000 miles on Brooklyn’s streets. It was my way of learning the grid. From Williamsburg, I got to know Greenpoint, Bushwick, Fort Greene, Bedford-Stuyvesant, Crown Heights; from Park Slope, it was Windsor Terrace and Kensington and Sunset Park and Bay Ridge; from Carroll Gardens, it was Red Hook and DUMBO and the waterfront. I have a decent mental map of maybe a third of Brooklyn’s seventy square miles, thanks to these here legs.

So I came to think of myself as an “urban runner”. Pounding the pavement was my way of getting to know my surroundings, and soaking up the city was my way of coping with running.

Then I moved to Queens, and everything changed. I’m not talking about Whitestone or Hollis or Rockaway or some other deep-Queens neighborhood. I lived in Ridgewood, about five blocks from the border with Brooklyn. But it was a totally different world. The car-to-pedestrian ratio was out of whack, which resulted in a totally different relationship between drivers and non-drivers. Instead of grumbling deference, I came to expect outright hostility from cars. I can’t count the number of times a driver sped up – or ran a stop sign – to beat me through an intersection. I even got hit once (albeit slowly), even after having made eye contact with the driver.

To make matters worse, Queens (or at least my portion of it) was boring. The semi-suburban neighborhoods bleed together in my mind: Glendale, Elmhurst, Woodside, Maspeth, Middle Village, Forest Park, Woodhaven. I know Queens is a (ethnically, linguistically, culinarily…) diverse place, but I could take or leave the bafflingly numbered streets/avenues/lanes/courts and single-family houses.

I moved to Manhattan a few months ago, where I hoped to recapture my love of urban running. It hasn’t gone well. Too many cars, too many people, too many stoplights, too much street construction. Dodging walkers on the sidewalk isn’t fun for me, and it isn’t fun for the people being dodged. Central Park is very nice, but I’m bored with it already.

In retrospect, Brooklyn is the perfect balance for the urban runner. It’s dense enough to be interesting. Neighboring neighborhoods contrast sharply with each other. Cars – at least in the northern and eastern parts of the borough – are few enough (and deferent enough) to make it safe to share the streets. I miss it.

If you are a runner living in Brooklyn, fight the urge to stick to the well-trodden paths. I too love Prospect Park, and the Belt Parkway Promenade, and Brooklyn Bridge Park. But you should be out on the streets, because there’s no better place to run.