Just lately yet again I found that this blog fails to load reliably. When it does it won’t always let me log in and on refeshing fails to load again. In addition the other installations here don’t load reliably - http://terrywassall.org/elgg and http://terrywassall.org/wiki/. Worst of all is http://terrywassall.org/blogs/ which either won’t load at all or, if it does, has no formatting as if it can’t find the css or theme files. Once again 34SP.com came to my rescue. Apparently one of my scripts has been trying to increase its memory allowance. This has been allowed and all seems to be OK again.
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!
In preparation for updating the WPMU installation to the latest version 2.9.1 I have deactivated and deleted the BuddyPress plugin and themes. This also required the manual dropping of all the BP fields in the database. I started to deleted BB fileds too by mistake so removed all these as well. I think a bulletin board app was part of the BP plugin so hopefully these database forms are also no longer needed!
I may wait for the WP version 3 which will apparently be a merging of WP and MUWP.
Update: 16/01/2010 In fact I did the automatic update on the MUWP installation and it worked perfectly.
In reply to a message about the avatar/file upload problem I put on the BuddyPress forum it was suggested I contact my ISP about the problem. This I did immediately and got an email within the hour. I had to run a script on-line (by filling out a form) to ”install php as a cgi module” and then go to the 34SP (my web hosting service) to “activate the ticket”to give me permissions to the requisite folders and files. In addition I had to paste 3 lines of code into the .htaccess file in the document root folder. A short while later I received an email saying all had been done and, on testing, avatars and files upload fine! I’ll reinstall Elgg and see if this has fixed the similar problem I had with it.
Having come to a full stop on the Elgg installation until I can track down information on my avatar and file upload problem, I thought I would continue exploring WPMU. As we now have a successful BuddyPress installation at work now I have decided to copy what our tech team and users are doing there and add BuddyPress to http://terrywassall.org/blogs and take advantage of expertise and information they are gaining. The installation went fine and nothing reeally to report. I basically followed the instructions at http://wpmu.org/beginners-guide-to-buddypress/. I also activated the bbPress installation for forums. Every thing went well until I tried to upload a new avatar, for the admin account and for a user. In both cases I got the message:
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?
