The post Moving WordPress’ /wp-content/uploads out of your DocumentRoot appeared first on Justin Silver.
]]>Why might you want to move your /wp-content/uploads folder out of your DocumentRoot? In my case, I use DropBox to sync files between my desktop and my laptop for doing development – no matter where I was working last, my changes, including Subversion status from the hidden .svn directories, are ready to go on the other computer (assuming I have Internet access of course, but even then DropBox will copy over the local network if it’s available, which means it’s pretty quick at home). For some of my site’s, like this one, there are gigabytes and gigabytes of images in my uploads directory, but they don’t really do that much for me in terms of development, but I still need them.
The solution for me was to move the uploads folder outside of the Apache DocumentRoot, were it can still be accessed, but doesn’t count against my DropBox usage (and doesn’t suck up bandwidth syncing thumbnail generation and the like.)
My first order of business was to break uploads out into a different SVN path – otherwise it will just update the folder every time you run an “svn up“. On the production server, you would want to do the following:
# WordPress Files # https://svn.example.com/mysite/web/trunk svn co https://svn.example.com/mysite/web/trunk /var/www/mysite/html # WordPress Uploads # https://svn.example.com/mysite/uploads/trunk svn co https://svn.example.com/mysite/uploads/trunk /var/www/mysite/html/wp-content/uploads # add "uploads" to your svn:ignore in the wp-content folder svn propedit svn:ignore /var/www/mysite/html/wp-content/ svn up /var/www/mysite/html/wp-content/ svn commit -m "saving svn:ignore for uploads" /var/www/mysite/html/wp-content/
And then on your Workstation, the following:
# WordPress Files # https://svn.example.com/mysite/web/trunk svn co https://svn.example.com/mysite/web/trunk ~/Dropbox/MySites/mysite # WordPress Uploads # https://svn.example.com/mysite/uploads/trunk svn co https://svn.example.com/mysite/uploads/trunk ~/Documents/MySites/mysite
I also added the following rules to /etc/subversion/config on my server and ~/.subversion/config on my workstation to prevent thumbnails from being added – there are lots of ways these can be regenerated if necessary.
[miscellany] global-ignores = *-[0-9]*x[0-9]*.jpg -[0-9]*x[0-9]*.gif -[0-9]*x[0-9]*.png -[0-9]*x[0-9]*.bmp -[0-9]*x[0-9]*.jpeg
Now in your Apache configuration for your workstation, you need to set an AliasMatch for the uploads directory so that Apache can serve up these files. I use MAMP running as my user, so I don’t have to worry about permissions, but you should keep this in mind depending on your configuration.
<VirtualHost *:80>
DocumentRoot "/Users/justinsilver/Dropbox/MySites/mysite"
ServerName local.mysite.com
# Reference the uploads folder in your Documents
AliasMatch ^/wp-content/uploads/(.*) /Users/justinsilver/Documents/MySites/mysite/wp-content/uploads/$1
<Directory /Users/justinsilver/Dropbox/MySites/mysite>
AllowOverride All
</Directory>
</VirtualHost>
With all of this done, you’re good to go as far as serving files, but WordPress will still be confused when it tries to write to the directory, since it uses an absolute path. To fix this, we can use a static defined in wp-config.php (which should be different than production anyway, considering you probably had to set overrides for WP_HOME and WP_SITEURL plus the local database configuration) and use that to selectively change the path to the uploads directory. Thus, add the absolute path to your wp-config.php like so, on the workstation:
define('WP_DEV_UPLOADS', '/Users/justinsilver/Documents/MySites/mysite/wp-content/uploads');
With this set, add the following to your theme’s functions.php, or your functions plugin (more on this at a different time) to hook to the “upload_dir” and change the uploads directory that WordPress uses.
if (defined('WP_DEV_UPLOADS')){
if (is_dir(WP_DEV_UPLOADS)){
// use directory outside of Dropbox for uploads so they dont go to Dropbox (uses Alias in VirtualHost)
function wp_dev_upload_dir($upload_dir){
$upload_dir['path'] = str_replace( $upload_dir['basedir'], WP_DEV_UPLOADS, $upload_dir['path'] );
$upload_dir['basedir'] = WP_DEV_UPLOADS;
return $upload_dir;
}
add_filter('upload_dir', 'wp_dev_upload_dir');
} else {
error_log('WP_DEV_UPLOADS is defined but does not exist: ' . WP_DEV_UPLOADS);
}
}
The post Moving WordPress’ /wp-content/uploads out of your DocumentRoot appeared first on Justin Silver.
]]>The post Memcached with MAMP 2.0.5 and Brew appeared first on Justin Silver.
]]>Requires that you have brew installed which is pretty easy, info here, but run:
/usr/bin/ruby -e "$(/usr/bin/curl -fsSL \ https://raw.github.com/mxcl/homebrew/master/Library/Contributions/install_homebrew.rb)"
We ultimately want to install memcached-php, and since libmemcached and memcached are both dependencies for it we can get them all at once. First we need to access the proper repository with “brew tap josegonzalez/php”
Io:/ $ brew tap josegonzalez/php Cloning into /usr/local/Library/Taps/josegonzalez-php... remote: Counting objects: 757, done. remote: Compressing objects: 100% (386/386), done. remote: Total 757 (delta 308), reused 703 (delta 267) Receiving objects: 100% (757/757), 105.33 KiB, done. Resolving deltas: 100% (308/308), done. Tapped 26 formula
Now we can access the memcached-php with “brew install memcached-php”
Io:/ $ brew install memcached-php ==> Installing memcached-php dependency: memcached ==> Downloading http://memcached.googlecode.com/files/memcached-1.4.13.tar.gz ==> ./configure --prefix=/usr/local/Cellar/memcached/1.4.13 ==> make install ==> Caveats You can enable memcached to automatically load on login with: mkdir -p ~/Library/LaunchAgents cp /usr/local/Cellar/memcached/1.4.13/homebrew.mxcl.memcached.plist ~/Library/LaunchAgents/ launchctl load -w ~/Library/LaunchAgents/homebrew.mxcl.memcached.plist If this is an upgrade and you already have the homebrew.mxcl.memcached.plist loaded: launchctl unload -w ~/Library/LaunchAgents/homebrew.mxcl.memcached.plist cp /usr/local/Cellar/memcached/1.4.13/homebrew.mxcl.memcached.plist ~/Library/LaunchAgents/ launchctl load -w ~/Library/LaunchAgents/homebrew.mxcl.memcached.plist Or start it manually: /usr/local/bin/memcached Add "-d" to start it as a daemon. ==> Summary /usr/local/Cellar/memcached/1.4.13: 9 files, 168K, built in 5 seconds ==> Installing memcached-php dependency: libmemcached ==> Downloading http://launchpad.net/libmemcached/1.0/1.0.4/+download/libmemcached-1.0.4.tar.gz ==> ./configure --prefix=/usr/local/Cellar/libmemcached/1.0.4 ==> make install /usr/local/Cellar/libmemcached/1.0.4: 224 files, 3.1M, built in 33 seconds ==> Installing memcached-php ==> Downloading http://pecl.php.net/get/memcached-2.0.1.tgz ######################################################################## 100.0% ==> phpize ==> ./configure --prefix=/usr/local/Cellar/memcached-php/2.0.1 --with-libmemcached-dir=/usr/local/Cellar/libmemcached/1.0.4 ==> make ==> Caveats To finish installing memcached-php: * Add the following line to /usr/local/etc/php.ini: extension="/usr/local/Cellar/memcached-php/2.0.1/memcached.so" * Restart your webserver. * Write a PHP page that calls "phpinfo();" * Load it in a browser and look for the info on the memcached module. * If you see it, you have been successful! ==> Summary /usr/local/Cellar/memcached-php/2.0.1: 4 files, 100K, built in 6 seconds
The rest of the process is actually spelled out in the brew output. You can memcached manually as a daemon by running the following.
memcached -d
Alternatively you can start memcached up every time you log in by running these commands.
mkdir -p ~/Library/LaunchAgents cp /usr/local/Cellar/memcached/1.4.13/homebrew.mxcl.memcached.plist ~/Library/LaunchAgents/ launchctl load -w ~/Library/LaunchAgents/homebrew.mxcl.memcached.plist
Next we need to install the extension in MAMP, so copy the following into the section labeled “; Extensions” in your php.ini file. Mine is located at /Applications/MAMP/bin/php/php5.3.6/conf/php.ini.
extension="/usr/local/Cellar/memcached-php/2.0.1/memcached.so
Restart the Apache service via the MAMP console and you should be good to go. You can check by making a file called phpinfo.php in your root that contains ““. Loading http://localhost:PORT/phpinfo.php will have a section titled “memcached” if the module loaded successfully.
PS – don’t forget to actually start the memcached server via “memcached -d” or you won’t actually be using it even if the module is enabled :/
The post Memcached with MAMP 2.0.5 and Brew appeared first on Justin Silver.
]]>