Category Archives: Apache

Site Landing Page fronting WordPress

Posted on by

A client wanted a site-wide landing page with some basic images and a few navigation buttons to front-end their WordPress site and other places like their Etsy shop and Social media links.  Out of the box WordPress allows you to define a home page (see under the admin options for Settings->Reading) but that isn’t exactly what they wanted as that is still within WordPress and so has the header, menus and footer and all the other stuff related to a WordPress site unless the theme allows for all of these to be turned off.

When you connect to the URL without any path or a resource file name e.g. www.openmutual.org rather than for example www.openmutual.org/blog/example.txt then (using Apache) the file that will be presented if a file is not specified in a URL is decided by the mod_dir  DirectoryIndex directive (or in IIS the <defaultDocument> elements).

WordPress by default has an index.php file in its root and usually this is what is normally used. If your hoster has setup their DirectoryIndex similar to the above then the index.html file will override the index.php If so then you are good to go. If not then you will have to get your hoster (or it may be you) to get index.html being dished out in preference to index.php. The two options open to my client are to,

a) move the WordPress out of the site root e.g. move the files to /blogging or similar subdirectory and then add a static web page e.g. index.html
b) or add an index.html with static code in it that will be run first before index.php

The option a) is obvious but I wanted to avoid that for the moment so I picked b) to see if that would work. Please read the “quirks” at the bottom and test this on your own test beds before playing with a client site !

Step 1) On WordPress create a new page with any name and slug (we’ll called it My Home and have a slug of my-home )
Step 2) Copy the contents of the existing Home page to this new page (use control-C and control-V or similar)
Step 3) There is usually no need to change anything in Settings->Reading for the front page displays but you cannot set it to a Static page that is navigable in the menu. The reason being is that whatever you set as the WordPress Static front page is given a slug of /. If it is already set to posts of Home then you can leave it as that.
Step 4) Edit your Theme menu in Appearance -> Menus and remove the existing “Home” or whatever has a slug of your site root (/) and replace it with your new copied home page (in my example “My Home”)
Step 5) You can add the original Home page back but give it a different name e.g. “Site Root” as it will jump you back to the non-Wordpress file.
Step 6) Test that your tweaked WordPress site still works OK. You won’t notice many problems yet.
Step 7) Create an index.html file and have at least the one link to your new “My Home” WordPress slug e.g. <a href=”./my-home”>My Blog Site</a>
Step 8) Upload and check the new file gets priority. If not then check the Apache mod_dir  DirectoryIndex directive is set correctly e.g.

<Directory /> 
DirectoryIndex index.html index.php 
</Directory>

That is all is needed. Now when web visitors hit your web site they will get the index.html and they can then navigate from there. When they click any WordPress link slug from that landing page then they then go to your WordPress site and will stay there unless you have given them a menu option to escape back up to the index.html.

Quirks:

  • You MUST set Permalink Settings to something other than the default of …site/?
  • When you are in Media Manager then when you try and view an attachment then it will go to the attachment page and not the media file link.
  • When you insert an image into a post or page then do not use the attachment post ID but the media file link.
  • This may not work on other web servers – I have only done this on Apache

wp-super-cache stale cache due to Apache permissions

Posted on by

This may happen to you in that web pages for anonymous users (i.e. not logged on) stay stale even when you use “Delete Cache” in WordPress dashboard and clear the data from your browser. The page contents stay stale and menus (if they were changed) stay on the old layout.

If this happens to you and you are pulling your hair out in testing and unable to get the pages to display on the new content then ssh into your server and check the permissions (ownership) of the /wp-content/cache is actually owned by the web server and has not been changed..

After a Plesk/Parallels upgrade (automatic I think) the user that Apache ran in changed and this meant that files that were previously created by Apache using the old user account were now not able to be deleted by the new Apache account user (www-data). This is probably never going to be seen on shared hosting but could be seen on virtual or dedicated servers.

The WordPress site would have kept dishing out the old file not matter what I did because the old cache files couldn’t be deleted.

The fix is easy (assuming your Apache installation is going to remain stable) and that is to ssh shell into your account and delete using the file owner (or root) the contents of the /wp-content/cache directory (which will have a “meta” and  supercache” subdirectories.

You may also be able to use your FTP client to do the same but probably the cache directory won’t actually be visible at all.

Once you have deleted all of that old stuff then go back into the wp-super-cache plugin settings and remove and then re-enable the cache settings.

Non-logged on browsers will now correctly display the site and the supercache/www.example.com/… files correctly build up with the ownership being the Apache web server.

To test this I use Firefox and Opera: Firefox is logged in and Opera is used to display the web site as an anonymous user. Opera has a nice feature in Opera -> Settings -> Delete private data that you can quickly clear the browser cache of everything.

Using error_log() with print_r() to gracefully debug PHP

Posted on by

When debugging php code (especially Open Source code you have not written yourself) then to get a feeling of what is passed around when it doesn’t work I find that the print_r() function is very useful.

Trouble is that if you just throw in print_r() into the code where you think it is faulty then you can upset json, AJAX or your web page layouts as the print_r() splatters stuff to your displayed web page or in some cases the PHP file is not going to a browser (e.g. the PayPal IPN notify).

The trick is to throw it at the error log as follows e.g. if I was tracing what $number was being set to then I would use….

error_log(print_r($number,true));

note that you MUST set that print_r() option to “true” so that it returns a string. This string is then sent to the error_log() function which formats it with referrer details and puts it into the Apache error log.

Where does it end up ? Well on my test system on a non-vHost it is /var/log/apache2/error.log and on a vHosted server it is :/var/www/vhosts/<domain name>/statistics/logs/error_log so on your own system it will be a similar Apache error log file. Just tail that file to see what the messages are which will be something like this (in this example the $number was “2008” so the output for that error log message was,

[Sun Jan 01 13:21:12 2012] [error] [client 192.168.2.2] 2008, referer: http://19
2.168.2.250/bluebox/index.php/numbermanager/index

To synchronize the log messages with your testing then just look at the logging time.

WordPress media uploads first day of use

Posted on by

On a new server you may find that you cannot upload images and it fails with an error,

Unable to create directory /var/www/path/to/your/httpdocs/wp-content/uploads/2011/06. Is its parent directory writable by the server?

This is because of permissions in that the apache web server can’t write to the wp-content/uploads folder.

The wp-content/uploads folder is defined by default in WordPress under the Settings -> Media and doesn’t need to change but you have to get the web server to be able to write to this location on the first day of use.

If you are using Filezilla or similar FTP Client you must set the file permissions of  /wp-content to 777 then go into your post again and add the image. This should work now and if you look at the wp-content directory you will see a new uploads directory with the file permissions of 777 and owner and group will be the apache web server. Set the /wp-content back to 755.

You don’t need to do anything else. It will keep working from now on.

Obviously the issue of setting 777 on a directory when we’re usually told to not do this raises alarm bells so is this an issue ? On shared hosting it could be an issue. A malicious user on another account could get Apache to upload content to this directory and then hotlink to this content in SPAM emails or bogus web sites but if this is a server or virtual server that you control all the shared accounts then there is no real problem.

A good shared hosting company should have setup the Apache mod_suexec and suPHP module for the virtual host that you are using on the shared account system and you won’t have access to that.

 

Don’t forget that .htaccess

Posted on by

When you install your wordpress site on a new machine then don’t forget to add or change the .htaccess file to allow the permlinks to work properly without getting 404 page errors. What you need to add is right at the very bottom of the WP Admin Settings-> Permlinks administration page. Copy and paste that into the .htaccess file that is (or should be) at the document root of your web site.

If it is not there then you need to create this file. If you are using Windows and try and create a file called .htaccess on your local PC to upload to your web server then you will get an error “You must type a file name”.

Just call it htaccess.txt or similar and then edit that with the WP permlinks related changes and then upload that in FTP. Then rename the file on the server to .htaccess

As the server will be Unix-like then it won’t care about such a filename and now your permlinks will work and you won’t get 404 errors for your posts.