Changing WordPress permalinks from default to postname

Had an issue on a WordPress site after I changed the permalinks to “%postname%” from the default.  Immediately after the change, all my wonderful posts gave 404 when I clicked on them.

So I researched it a bit and found some good recommendations (make sure mod_rewrite is present, check permissions on .htaccess).  Initially it looked like a simple fix – the .htaccess file needed to be populated (I didn’t allow the web server daemon write access to that file or the site’s directory).  So I added the recommended code to that file directly (by the way, that file needs to be in DocumentRoot for your site).  However, that still didn’t fix it.

So I poked around some more and a couple of sites recommended checking AllowOverride and similar settings.  In my /etc/httpd/conf/httpd.conf, AllowOverride was set to None.

My sites are in a separate file in /etc/httpd/conf.d so I opened that file and added the following under the VirtualHost section for that site:

<Directory "/site/home">
AllowOverride Options FileInfo
Options FollowSymLinks
RewriteEngine On
</Directory>

(I obfuscated the path above, so in your file, whether /etc/httpd/conf/httpd.conf or a site-specific file in /etc/httpd/conf.d, Directory will certainly not be “/site/home“).  You can set AllowOverride to All, but do so at your own risk.

Then I bounced httpd and ta-da, it worked.

So, in summary:

-Check to make sure your web server loads mod_rewrite
-Set .htaccess (found in your site’s root, DocumentRoot) to writable so WordPress can modify it, OR modify it yourself by pasting in the code that WordPress shows you
-In your site’s config (either /etc/httpd/conf/httpd.conf or your site-specific file in /etc/httpd/conf.d), add:

<Directory "/site/home">
AllowOverride Options FileInfo
Options FollowSymLinks
RewriteEngine On
</Directory>

-Bounce the web service

 

How I installed WordPress 3.4.2 on CentOS 5.8

Had a real adventure getting a WordPress site going on a CentOS 5.8 LAMP server. It came down to two major areas: packages and permissions.

Packages

I asked the hosting provider to install pretty much just the base package group, knowing we could easily add on from there without having a lot of extra fluff. After a fair amount of troubleshooting (and very patient help from the site developer), I ended up installing the list below. Some of them may be unnecessary in the end, and many were pulled in as dependencies, but we got there.

perl-DBD-MySQL-3.0007-2.el5.x86_64
mysql-server-5.0.95-1.el5_7.1.x86_64
mod_auth_mysql-3.0.0-3.2.el5_3.x86_64
ntp-4.2.2p1-15.el5.centos.1.x86_64
php53-common-5.3.3-13.el5_8.x86_64
php53-cli-5.3.3-13.el5_8.x86_64
php53-pdo-5.3.3-13.el5_8.x86_64
php53-mbstring-5.3.3-13.el5_8.x86_64
php53-mysql-5.3.3-13.el5_8.x86_64
php53-5.3.3-13.el5_8.x86_64
php53-xmlrpc-5.3.3-13.el5_8.x86_64
php53-xml-5.3.3-13.el5_8.x86_64
php53-gd-5.3.3-13.el5_8.x86_64
gd-progs-2.0.33-9.4.el5_4.2.x86_64
libwmf-0.2.8.4-10.2.x86_64
libcroco-0.6.1-2.1.x86_64
lcms-1.18-0.1.beta1.el5_3.2.x86_64
libgsf-1.14.1-6.1.x86_64
librsvg2-2.16.1-1.el5.x86_64
urw-fonts-2.3-6.1.1.noarch
ghostscript-8.70-14.el5_8.1.x86_64
ghostscript-fonts-5.50-13.1.1.noarch
ImageMagick-6.2.8.0-15.el5_8.x86_64
libdrm-2.0.2-1.1.x86_64
libXxf86vm-1.0.1-3.1.x86_64
mesa-libGL-6.5.1-7.10.el5.x86_64
libjpeg-devel-6b-37.x86_64
libXau-devel-1.0.1-3.1.x86_64
bzip2-devel-1.0.3-6.el5_5.x86_64
ghostscript-devel-8.70-14.el5_8.1.x86_64
libtiff-devel-3.8.2-15.el5_8.x86_64
lcms-devel-1.18-0.1.beta1.el5_3.2.x86_64
xorg-x11-proto-devel-7.1-13.el5.x86_64
libXdmcp-devel-1.0.1-2.1.x86_64
libX11-devel-1.0.3-11.el5_7.1.x86_64
libXext-devel-1.0.1-2.1.x86_64
libICE-devel-1.0.1-2.1.x86_64
libSM-devel-1.0.1-3.1.x86_64
libXt-devel-1.0.2-3.2.el5.x86_64
mesa-libGL-devel-6.5.1-7.10.el5.x86_64
ImageMagick-devel-6.2.8.0-15.el5_8.x86_64
imake-1.0.2-3.x86_64
autoconf-2.59-12.noarch
automake-1.9.6-2.3.el5.noarch
php53-devel-5.3.3-13.el5_8.x86_64
php-pear-1.4.9-8.el5.noarch

Also, I had to run ‘pecl install imagick‘.  Newer versions of WordPress require PHP 5.2 and newer.  CentOS provides 5.1 by default, but Red Hat back-ported 5.3 as php53 to accommodate the fact that so many things need it.  One major discovery was that image resizing will break without ‘gd’ support.  This came thru the php53-gd package, as well as the ImageMagic stuff.

Permissions, ownership, etc.

Like many web hosting setups, the apache user needs to be able to read directories, execute files, and in some cases write things.  After lots of trial and error, we settled on these principles:

  • The directory wp-content (and its subdirectories) is owned by the site user, and is in the apache group
  • The site owner is a member of the apache group as an additional group (i.e. usermod -a -G apache user).  You could also just make the apache group the primary group of the site user (usermod -g apache user).
  • All directories under wp-content are setgid (chmod g+s), and are mode 775.
  • All files are mode 664 (644 if you’re a bit paranoid, and for all .php files, but keep an eye out for things that break).