OK. Starting again. This time I’ll be a little less arrogant and do some research! I have deleted the blogs.terrywassall.org subdomain and the database and will install WPMu from scratch in a sub-directory, terrywassall.org/blogs/. I’ll update this post with anything and everything that occurs. Any problems will be reported and, assuming I can solve them, where I got the information for the fix. I don’t know how useful this will be for others but it will be a full account of how it went for a comparative beginner so it might be.
Day 1 (5/11/09 23.05): Created a sub-directory terrywassall.org/blogs/. Uploaded all the WPMu files and folders into it. That’s it for now. Before I do anything else tomorrow I will be looking at Installing in a subfolder on Andrea’s very useful WPMU Tutorials web site which I discovered today thanks to her response to my plaintive wailing on Twitter.
Day 2 (6/11/09 8.00): As warned in Installing in a subfolder, when going to terrywassall.org/blogs a message came up saying there is no wp-config file and a button inviting me to create one. This must be resisted! Don’t do it. Following the instructions I opened the wp-blog-header.php file and commented out lines 9 and 14 (not 24 as stated in Installing in a subfolder) to look as follows:
// if ( !file_exists( dirname(__FILE__) . ‘/wp-config.php’) && !file_exists( dirname( dirname (__FILE__) ) . ‘/wp- config.php’)) {
if (strpos($_SERVER['PHP_SELF'], ‘wp-admin’) !== false) $path = ”;
else $path = ‘wp-admin/’;
include( “index-install.php” ); // install WPMU!
die();
// }
On refreshing terrywassall.org/blogs/ a page appeared with an instruction to change the file permissions for a couple of folders to 777 - httpdocs/blogs and httpdocs/blogs/wp-content/. Once I had done this and refreshed again the installation form appeared. Now it was just a matter of filling the form in with the details of the database and database user I had created, choosing a name for the blog and supplying an email address. All the other fields I left as defaults but I noticed the server address was identified as terrywassall.org. I was tempted to add /blogs/to the end but didn’t. Surely the script knows best. On completing the form the installation was reported as having been successful and the admin password was displayed. This was also sent to the email address I had entered in the installation form. I clicked on the Log in button and found myself in the dashboard. So far so good.
However, on visiting the site the installation screen displayed again. I returned to the wp-blog-header.phpfile and uncommented lines 9 and 14 (as above) and on refreshing the browser the home page of the new installation opened. (There was a clue to this in Andrea’s post referenced above). Finally I returned httpdocs/blogs and httpdocs/blogs/wp-content/ to their previous file permissions.
Next task: try to create a new blog.
I attempted to install the multi-user version of WordPress in this domain today. You can see it at http://blogs.terrywassall.org. As you can see, rather than install in a directory, for instance terrywassall.org/blogs, I created a subdomain for the installation. All seemed to go well until I activated the option allowing visitors to register their own blog to see how and if this worked. It didn’t. I tried to register a blog with the user name ‘test’. This should have created a blog at test.blog.terrywassall.org. The email was delivered confiming the creation of the blog with a link to activate the blog. However, on doing so I get a ‘not found’ error message.
Two possibilites occur. One is that it looks as if WPMU is trying to create a subdomain in a subdomain. I didn’t realise this is how it would work and I chose the ‘subdomain’ option when installing as I thought this referred to the installation’s location, i.e. in a subdomain. It now seems this option tells WPMU to create a new subdomain for each blog. Perhaps this will only work if I install WPMU in the root – httpdocs in this case. This is probably the problem. The other information I have found is that if I want to use the subdomain option for blogs I need to add a wildcard record to my DNS records (whatever that means). I found this information in chapter 12, page 258, of WordPress for Dummies which I can heartly recommend. I need to add a hostname record pointing at my web server using a DNS configuration tool. I don’t think I have access to one of these. Looks like I will have to email my ISP for help.
The alternative would be to do the installation in a directory or to dedicate a domain to it by installing in root rather than in a subdomain or a subdirectory.
Useful post on Customize MediaWiki into Your Ultimate Collaborative Web Site by Lifehacker. Just stuck this post here until I get time to read it and apply any tips to the Mediawiki installed here. The post mentions a rather nice Mediawiki installation used as a collaboratively written guide book The Complete Guide to Google Wave.
Mediawiki make it quite clear that it is not the best product if you want to create and manage private pages for specified users. However, it is possible to set up group based access to pages using the Mediawiki group access extension. This link takes you to the instructions on how to install the extension and how to use it to make pages private to groups of users. You can also download the extension files.The following text is added to the localSettings.php file:
require_once(“extensions/accesscontrolSettings.php”);
include(“extensions/accesscontrol.php”);
It may be necessary to edit the contents of the accesscontrolSettings.php as instructed. One thing that needs doing here is to uncomment the english version lines and comment or delete the german version lines. Another edit I made was to make a No_Access page display within the wiki. To do this I had to create the No_Access page and edit the following line:
$wgAccessControlNoAccessPage = “/index.php/No_Access”;
This took the reader to the WP installation 404 page and therefore outside of the wiki.
$wgAccessControlNoAccessPage = “../index.php/No_Access”;
This takes the reader to a no access page I created within the wiki.
In another installation I did a year or so ago sometimes an access controlled page would appear to be public still. I found the following fix, to disable caching, on the talk page to the above extension page:
Mediawiki group access extension: Talk page
$wgMainCacheType = CACHE_NONE;
$wgMessageCacheType = CACHE_NONE;
$wgParserCacheType = CACHE_NONE;
$wgCachePages = false;
A warning indicates that this is necessary for the access controls to work properly.
I have now managed to change the default Mediawiki logo. I added the $wglogo line to the localConfig.php file as before but put in the full path to the file:
$wgLogo = “http://terrywassall.org/wiki/logo.png“;
This now works fine. The image size has to be 135 x 135 and I created it with a transparent background using Fireworks
Since I have not been able to get any advice on what might be a better OS wiki to host here I have installed Mediawiki using the 34SP Mediawiki installation utility. The necessary database and db user have to be set up first but after that all the required information,domain, ftp, e.g., is entered into the installation form including a password for the Mediawiki admin account that will be created and the process takes place automatically. The resulting installation is fully public and open to user account creation on demand and anonymous editing but this is soon secured by adding the appropriate lines to the localSettings .php file. This following disables anonymous editing and account creation.
$wgGroupPermissions['*' ]['read'] = true;
$wgGroupPermissions['*' ]['edit'] = false;
$wgGroupPermissions['*' ]['createaccount'] = false;
The first line allows public reading of pages but changing this to false would mean that only logged on users can read. I have left pages publicly readable and will protect pages as required using the control access feature.
I also tried to change the default logo by uploading a new logo image and adding the
$wgLogo = ‘/path/to/your/logo.png’;
to the localSettings .php file but I couldn’t get this to work. The new log failed to display. This may be something to do with paths and permissions and I will have another go later. Another approach will be to overwrite the skins/common images/wiki.png with my own logo file but this will need redoing every time I upgrade and is not recommended.
The installation of WordPress was as easy as usual. Little has been changed so far. Have spent some time looking at themes I might use. At the moment I am using the Notes Blog theme. This looks like it might be a good one to learn from as it is explicitly designed for child themes to be developed from it and the theme web site promises some tutorials.
The appropriate code has been added to a .htaccess file so that item urls and permalinks have meaningful names. I am hoping to install some other web 2.0 applications here as well, possibly Elgg and a wiki but the next task will be to chose a more attractive theme, hopefully one that is sutable for me to edit and learn how WP themes work. I will also investigate what plugins might be useful. I am conscious of the fact that the normal WP code and MUWP may be merged in future so will not do too much until we see how that pans out.
I have run a number of WordPress installations on a server my nephew, Daniel, hosts but for the first time I am hosting this installation myself. On the recommendation of Matt Dukes I opted for a hosting company called 34SP and their new ‘Professional Hosting’ package. I buy my domain names from LCN and found no difficulty in pointing this one, terrywassall.org, to the 34SP name servers. Once I had signed up to 34SP and changed the name server details for the domain with LCN I got access to the admin panel within the hour. I was relieved to find it was the Plesk application I am used to that is provided by Daniel’s hosting service. Consequently creating the WordPress database and database user and installing WordPress was a breeze, as usual. So far all has been straightforward and the package of LCN plus 34SP looks like a good one.
