Tag Archives: htaccess

Default Gravatar images and SSL

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’ );

  • 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:

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

    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’ );

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.

BuddyPress Docs 1.4 and attachment support

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!

Salvaging content from a corrupted WordPress installation

Yesterday a friend emailed me asking for help. Her old WP installation had become corrupt – through a bad plugin or something – and she couldn’t bring it back to life. So she decided to start fresh, with a new WP installation on a new server. She wanted to know if it was possible to salvage her old posts, which (as she could see in PHPMyAdmin) were still in the old database. Here’s a copy of the email I wrote to her, on the off chance that it helps someone else.

Note that this technique should be used as a last resort. Generally, WP installations can be saved with a little bit of know-how and elbow grease. Also note that it assumes that you’re switching domain names in the process. Also note that I wrote this in 10 minutes, off the top of my head – amendments or corrections welcome.


For shorthand:
WPA is your old, corrupted installation
WPB is a brand new, totally empty installation of WP
WPC is your new production installation, on the new domain

The first step is to get your content out of WPA and into WPB. WPB should be a totally new, throwaway installation – a local installation would be ideal, but a fresh one on your webhost would be fine. (This should NOT be the same as WPC!!) Visit your WPA database (using PHPMyAdmin or whatever tool you’ve got), and export the following tables:

In PHPMyAdmin, that usually just means checking the boxes next to those tables, and clicking an Export button somewhere in the interface.

Next, use PHPMyAdmin to view the database of WPB. Drop/delete the four tables corresponding to the ones you exported (wp_posts, wp_postmeta, wp_comments, wp_commentmeta).

Once these four tables are dropped, use PHPMyAdmin to import the versions you exported from WPA into WPB.

At this point, the posts should be safe and sound in WPB. You can verify by visiting WPB in your web browser. The next step is to use the WP export feature of WPB to get the posts out, in a format that WPC will be able to understand. Go to wp-admin on WPB > Tools > Export. Export everything to a local file. Then go to WPC Dashboard > Tools > Import (you may have to install the WP importer plugin) and import. This process should pull your old posts and pages in, without overwriting anything currently in your system.

It’s also a nice idea to set up a redirect from your old domain to your new one. (That will ensure that links to your old blog by other sites will continue to work, as well as any times you may have linked to your own old content.) Two steps:
1) At your domain registrar, make sure that your old WPA domain points to your WPC installation; this usually means putting the WPC domain as the CNAME attribute on the DNS tab.
2) FTP to WPC, and look for a file in the main WP directory called .htaccess (you may have to enable View Hidden Files or something like that). Near the top of the file, put the following lines:

[code]RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} ^myOLDdomain.com$ [NC]
RewriteRule ^.*$ http://myNEWdomain.com%{REQUEST_URI} [R=301,L][/code]

Make sure to replace myOLDdomain and myNEWdomain with the relevant domain names. This will redirect any request to myolddomain.com to the corresponding URL on mynewdomain.com, meaning that all your old permalinks should continue to work.

Moving my photo site to a new URL and server

This post is pretty much just a note to self (I tend to have to relearn how to write Apache rewrites every time I use them), but I thought it might be useful to others as well.

A few months ago I set up a Twitpic-esque WordPress site for hosting my mobile photos. Since then, the shared hosting space where the sites lives has been filling up, so I don’t have much storage left, and I’ve also gotten a sweet new domain name. So this morning I took a few minutes to move the existing WordPress site (http://boonebgorges.com/photos/, part of a WP network at boonebgorges.com) and to https://boone.gorg.es/photos/, on another server. Here’s how I did it:

  • Use the WP export tool (Dashboard > Tools > Export) to get an XML of the old site data (on boonebgorges.com/photos)
  • Create a new, empty site (boone.gorg.es/photos)
  • Import the content of the old site (Dashboard > Tools > Import > WordPress)
  • Move my custom theme (and its parent theme) to the new server, and activate it for the new site
  • To make sure that old links to boonebgorges.com/photos/* are redirected properly, put the following in .htaccess on the old server:
    # These two lines have to be somewhere near the top of your .htaccess
    RewriteEngine On
    RewriteBase /

    # Redirect old photo URLs
    RewriteCond %{HTTP_HOST} ^boonebgorges.com$ [NC]
    RewriteCond %{REQUEST_URI} photos/*
    RewriteRule ^.*$ https://boone.gorg.es%{REQUEST_URI} [R=301,L]

Because the main purpose of this site is to post from my mobile phone, I also had to change the settings in my WordPress Android app. It doesn’t look like this app allows you to change the URL of an existing site, so I just deleted the one I already had on the phone and added the new one, being sure to enable XML-RPC access first, at Dashboard > Settings > Writing.

Hardening BuddyPress Group Documents

The BuddyPress Group Documents plugin allows groups a handy way for users to share documents with fellow members of a BP group. It’s crucial to the work that is done on the CUNY Academic Commons. But, by default, the plugin stores documents in a subdirectory of your WP uploads folder (usually /wp-content/blogs.dir/ on multisite). That means that documents are available directly, to anyone who has the URL, regardless of the public/private/hidden status of groups. This isn’t a problem from within BuddyPress, since URLs for the documents only appear inside of the protected group interface. But if the URL is shared, then the document becomes publicly available. Worse, if someone posts the URL of a document in a public place, search engine bots will find it, and the contents of the document could end up in Google.

I wrote a few helper functions to change this behavior. The strategy is this: Move the files so that they are not accessible via URL, ie in a directory above the web root. (In my case, it’s a directory called bp-group-documents, just above my web root.) Then, catch requests of a certain type (I’ve chosen to go with a URL parameter get_group_doc=), and check them to see whether the current user has the adequate permission to access the document in question. Finally, make sure that all of the URLs and paths that BPGD uses to upload and display documents are filtered to the updated versions. I’ve provided my code below – use and modify at your pleasure. You should be able to place it in your plugins/bp-custom.php file, and then move your existing docs from their current location (probably something like wp-content/blogs.dir/1/files/group-documents) to the new directory.

I also added a line to my .htaccess file to ensure that requests to the old URLs are redirected to the new, hardened URL. That line is this:
RewriteRule ^wp-content/blogs.dir/1/files/group-documents/(.*) /?get_group_doc=$1 [R,L]
Obviously, you may have to modify it for different file paths.

EDITED Feb 8, 2011 to include the code for creating directories when none exist

[code language=”php”]
define( ‘BP_GROUP_DOCUMENTS_SECURE_PATH’, substr( ABSPATH, 0, strrpos( rtrim( ABSPATH, ‘/’ ), ‘/’ ) ) . ‘/bp-group-documents/’ );

function cac_filter_doc_url( $doc_url, $group_id, $file ) {
$url = bp_get_root_domain() . ‘?get_group_doc=’ . $group_id . ‘/’ . $file;
return $url;
add_filter( ‘bp_group_documents_file_url’, ‘cac_filter_doc_url’, 10, 3 );

function cac_filter_doc_path( $doc_url, $group_id, $file ) {
$document_dir = BP_GROUP_DOCUMENTS_SECURE_PATH . $group_id . ‘/’;

if ( !is_dir( $document_dir ) )
mkdir( $document_dir, 0755, true );

$path = BP_GROUP_DOCUMENTS_SECURE_PATH . $group_id . ‘/’ . $file;
return $path;
add_filter( ‘bp_group_documents_file_path’, ‘cac_filter_doc_path’, 10, 3 );

function cac_catch_group_doc_request() {
$error = false;

if ( empty( $_GET[‘get_group_doc’] ) )

$doc_id = $_GET[‘get_group_doc’];

// Check to see whether the current user has access to the doc in question
$file_deets = explode( ‘/’, $doc_id );
$group_id = $file_deets[0];
$group = new BP_Groups_Group( $group_id );

if ( empty( $group->id ) ) {
$error = array(
‘message’ => ‘That group does not exist.’,
‘redirect’ => bp_get_root_domain()
} else {
if ( $group->status != ‘public’ ) {
// If the group is not public, then the user must be logged in and
// a member of the group to download the document
if ( !is_user_logged_in() || !groups_is_user_member( bp_loggedin_user_id(), $group_id ) ) {
$error = array(
‘message’ => sprintf( ‘You must be a logged-in member of the group %s to access this document. If you are a member of the group, please log into the site and try again.’, $group->name ),
‘redirect’ => bp_get_group_permalink( $group )

// If we have gotten this far without an error, then the download can go through
if ( !$error ) {

$doc_path = BP_GROUP_DOCUMENTS_SECURE_PATH . $doc_id;

if ( file_exists( $doc_path ) ) {
$mime_type = mime_content_type( $doc_path );
$doc_size = filesize( $doc_path );

header(“Cache-Control: public, must-revalidate, post-check=0, pre-check=0”);
header(“Pragma: hack”);

header(“Content-Type: $mime_type; name='” . $file_deets[1] . “‘”);
header(“Content-Length: ” . $doc_size );

header(‘Content-Disposition: attachment; filename=”‘ . $file_deets[1] . ‘”‘);
header(“Content-Transfer-Encoding: binary”);
readfile( $doc_path );

} else {
// File does not exist
$error = array(
‘message’ => ‘The file could not be found.’,
‘redirect’ => bp_get_group_permalink( $group ) . ‘/documents’

// If we have gotten this far, there was an error. Add a message and redirect
bp_core_add_message( $error[‘message’], ‘error’ );
bp_core_redirect( $error[‘redirect’] );
add_filter( ‘wp’, ‘cac_catch_group_doc_request’, 1 );

// http://www.php.net/manual/en/function.mime-content-type.php#87856
if(!function_exists(‘mime_content_type’)) {

function mime_content_type($filename) {

$mime_types = array(

‘txt’ => ‘text/plain’,
‘htm’ => ‘text/html’,
‘html’ => ‘text/html’,
‘php’ => ‘text/html’,
‘css’ => ‘text/css’,
‘js’ => ‘application/javascript’,
‘json’ => ‘application/json’,
‘xml’ => ‘application/xml’,
‘swf’ => ‘application/x-shockwave-flash’,
‘flv’ => ‘video/x-flv’,

// images
‘png’ => ‘image/png’,
‘jpe’ => ‘image/jpeg’,
‘jpeg’ => ‘image/jpeg’,
‘jpg’ => ‘image/jpeg’,
‘gif’ => ‘image/gif’,
‘bmp’ => ‘image/bmp’,
‘ico’ => ‘image/vnd.microsoft.icon’,
‘tiff’ => ‘image/tiff’,
‘tif’ => ‘image/tiff’,
‘svg’ => ‘image/svg+xml’,
‘svgz’ => ‘image/svg+xml’,

// archives
‘zip’ => ‘application/zip’,
‘rar’ => ‘application/x-rar-compressed’,
‘exe’ => ‘application/x-msdownload’,
‘msi’ => ‘application/x-msdownload’,
‘cab’ => ‘application/vnd.ms-cab-compressed’,

// audio/video
‘mp3’ => ‘audio/mpeg’,
‘qt’ => ‘video/quicktime’,
‘mov’ => ‘video/quicktime’,

// adobe
‘pdf’ => ‘application/pdf’,
‘psd’ => ‘image/vnd.adobe.photoshop’,
‘ai’ => ‘application/postscript’,
‘eps’ => ‘application/postscript’,
‘ps’ => ‘application/postscript’,

// ms office
‘doc’ => ‘application/msword’,
‘rtf’ => ‘application/rtf’,
‘xls’ => ‘application/vnd.ms-excel’,
‘ppt’ => ‘application/vnd.ms-powerpoint’,

// open office
‘odt’ => ‘application/vnd.oasis.opendocument.text’,
‘ods’ => ‘application/vnd.oasis.opendocument.spreadsheet’,

$ext = strtolower(array_pop(explode(‘.’,$filename)));
if (array_key_exists($ext, $mime_types)) {
return $mime_types[$ext];
elseif (function_exists(‘finfo_open’)) {
$finfo = finfo_open(FILEINFO_MIME);
$mimetype = finfo_file($finfo, $filename);
return $mimetype;
else {
return ‘application/octet-stream’;