“Optimizing your database is a necessary part of WordPress housekeeping. Things can start to pile up in there… post revisions, old spam comments, etc., and your blog can start to get sluggish. We’ve gathered a number of solid tips for getting your database into shape without having to be an expert”.

Need to look at the WP-Optimize plugin mentionned.

I have been trying to think of anything I might have done to mess this installation up and the only thing I can think of is that, perhaps coincidentally, various troubles date back to when I disabled and deleted the BuddyPress plugin and themes and upgraded WPMU to 2.9.1. The whole site has been flaky but the http://terrywassall.org/blogs/  has been the least reliable bit of it. I think I may completely remove the MUWP install in the blogs folder and start from scratch with a new install of 2.9.2. I’ll see how it goes. As I say, all seems to be OK for the moment.

Postscript: Just got a message from 34SP re: the problem. It seems there are a number of security modules on the server and one of these picked up on a script trying to change the allowed memory. Apparently this is something  a lot of bogus scripts do. When this happens, to protect the server, it blocks user access. Although this may seem a little harsh, as 34sp admit, the security module is just doing its job. I don’t think we can argue with that. It would be nice, however, if there was a process where the  site owner/admin was contacted about the problem rather than waiting for them to notice themselves. I sometimes don’t visit this site for up to 2 weeks and I have no idea how long it has been down for. I assume the offending script (is that the same as a php file?) could be identified as well. If is is a rogue script this would be useful information I would have thought!

What’s the difference between running PHP as a cgi or as a module …

Should PHP run as a CGI script or as an Apache module?

Upload Failed! Error was: Unable to create directory /var/www/vhosts/terrywassall.org/httpdocs/blogs/wp-content/blogs.dir/1/files/avatars/3. Is its parent directory writable by the server?

I tried creating the directory path manually on the server and gave everything in the path 777 permissions and I did manage to upload a new avatar for the user but when tried to do it for admin I got a message saying the file could not be uploaded. I have reset all the default avatars and deleted the folders I created manually so back to square one for the moment. I had to make a copy of the blogs.dir folder as I couldn’t open it or change permissions – it belongs to apache it seems.  I renamed the original and have now reinstated that so it is exactly like the original installation again.

In addition, probably the same problem, on trying to upload a pdf file (a permitted file type for uploading) it looked as if it was uploading with a percentage cout down but then failed with the message:

Unable to create directory /var/www/vhosts/terrywassall.org/httpdocs/blogs/wp-content/blogs.dir/1/files. Is its parent directory writable by the server?

$CONFIG->disable_registration = true;

The settings file was created by the install script and I couldn’t edit it. I managed to get in by copying it and renaming the uneditable version settings-original.php just in case. The added line has disabled public user registration from the home page and anywhere else it used to appear. I find admin can still create new users and a notification email is sent to the new users email address with the username and password.

I found this by Googling “elgg disabling user registration”. This came up with http://groups.google.com/group/elgg-development/browse_thread/thread/ec973efbb4b021de which also makes mention of a ‘walled garden’ plugin that might be worth a look. But further research suggest that this plugin disables admin’s ability to manually create new users.

Other possible tweaks for the config.php file are (none of which I have tried):

// The following should be set to false if you don’t want the
// general public to be able to register accounts with your
// Elgg site. 

     $CFG->publicreg = false; 
   
 // The following should be set to false if you don’t want users
// to be able to invite new users into the system. 

     $CFG->publicinvite = false; 
 
// Set this to 1 to enable a walled garden – i.e., if you’re not logged in,
// all you can see is the login page. 

$CFG->walledgarden = 0;

Does this last one need a plugin?

All these found with many others in:
http://cepadev.if.usp.br/trac/stoa/browser/trunk/elgg/config-dist.php

So all is well. I have registered a new user and the blogs work OK. Lots to learn about plugins and widgets and alternative layouts but looks very promising so far and will probably be worth the effort.

It’s as if the generated pages aren’t picking up any css or something. I still can’t find any references to this problem on the Web. I had no trouble installing WordPress, Moodle and phpBB. I had some initial problems installing WPMU but found and fix I needed with my first Google search a reference past onto me via Twitter supplied the rest. I will try posting a message to the Elgg forum.

Update: Posted the following message to the Getting Started group at Elgg.
————————————-
Hope this is the right place for this. I have just installed 1.6.1 following the installation instructions in the documentation area. All went as described until I got to the login page and into the site. No formatting or structure to the pages – http://terrywassall.org/elgg/. You’ll see what I mean if you look. Any ideas on what it is I need to do or have left undone? I have spent most of today searching for info on this and come up with nothing so far.

Whoops (update): after checking earlier messages in this discussion I tried changing to another view, choosing failsafe. Now I can’t log in or anything! I’ll look in the installation and db to see if I can change back to default view there. Any ideas gratefully received.

Further update: Sorry this is becoming a bit of a saga (appropriately enough). I found a line in the db where the view is specified, in the elggconfig table: view  = s:8:”failsafe”;

I changed this back to view  = s:8:”default”; and I can log in again. But still no formatting or layout, as if no css or anything else is being applied. I don’t like messing about in the database as I’m not sure what I’m doing.