After the WordPress update from 3.1.3 to 3.1.4 unexpectedly broke one of the plugins I use (My Link Order – why this was removed as a native feature in WordPress is beyond me…), I decided it was time to actually test updates locally before I pushed them to my site. That would also allow me to locally test theme changes and new plugins rather than just doing it live and attempting to quickly revert all breakages I made. It is still not the worlds best testing set-up as it does not use the same web server, PHP or MySQL version as my host, but I am fairly happy assuming the basics of WordPress will be compatibly with what my host provides and so only really need to test functionality that should not be affected by such differences.
Note I decided to go with Nginx as the web server as it seemed an easy way to go. I also did not use the WordPress package provided in the Arch Linux repos as it kind of defeats the whole purpose of testing the upgrade, requires slightly more set-up in nginx.conf and I think files in /srv/http should not be managed by the package manager (but that is another rant…).
So here is a super-quick ten-step guide to getting a local WordPress install up and running.
- pacman -S nginx php-fpm mysql
- Adjust /etc/nginx/conf/nginx.conf to enable PHP as described here
- Enable the mysql.so and mysqli.so extensions in /etc/php/php.ini
- sudo rc.d start mysqld php-fpm nginx
- If this is your first MySQL install, run sudo mysql_secure_installation
- Give yourself permission to write to /srv/http/nginx
- Download and extract the WordPress tarball into /srv/http/nginx
- Create the MySQL database and user as described here
- Adjust the wp-config.php file as needed (see here)
- Point your browser at http://127.0.0.1/wp-admin/install.php
And it is done! I have not attempted to set-up the auto-update features in WordPress as that involves either setting up and FTP or SSH server and I have no need to do either on my laptop.
As a bonus, I can now draft blog posts while offline and preview them with all their formatting. So you can all look forward to more rambling posts here from me…
If you would indulge me, why do you not like having files in /srv/http managed by the package manager? It seems sane to me that if you install wordpress via pacman, you’d want a -Syu to update wordpress as well. (Granted, only when the package is available.)
The only thing I can think of is that the configuration files might be messed up, if so, then perhaps pacman’s config file handling should be changed in some way? Any ways, I digress.
I do not object to having those files managed by the pacman manager, but I think should be the user supplying the package rather than the distribution. It would probably be fine to use a distributions WordPress package given all the customization is done in subfolders of the install. But that assumes the packager does nothing strange while making the package and I am not sure that is an assumption that should ever be made…
i use apache due.to smaller user base and lit of processing