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!
For some reason I have been geeting server error 500 messages occassionally for this url – http://terrywassall.org - althoug a connection is made a little later or on refreshing the browser. Strangely I don’t seem to be getting the same problem with http://terrywassall.org/blogs/ or http://terrywassall.org/wiki/. On reporting this to 34SP they reported back to me (very quickly) “… the few connection issues seen in your error_log with phpfastcgi both relate to when apache on the server was restarted, this can happen when users add/delete things like subdomains/webusers etc . It looks like on this occasion it was the restarts that caused the errors to occur, php fastcgi however allows for idling and can sometimes become detached from the apache process…” with the offer of switching my account to pure phpcgi to see if this helps with the errors I am getting. Needless to say I had no idea of what fastcgi is let alone pure phpcgi. I was assured there would be no side affects to switching to pure phpcgi other than perhaps a ‘tiny’ decrease in performance. So the switch has been made and so far no more server error messages. I usually try to get my head round these technical issues as I do find it useful to have at least some idea of what the techies are saying. I’ve looked at http://en.wikipedia.org/wiki/FastCGI to get some background. A WP fourm post on server errors that has several mentions of fastcgi and problems is at http://wordpress.org/support/topic/259015.
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.
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.
