More problems with this site (and postscript)

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!

Server error problems (fast and pure cgi)

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.

Mediawiki post-spam clean up

I found that every page and discussion page in my Society and Environment Development  wiki had been written to anonymously with spam links. Also most of my content had been deleted. Fortunately there are only about 6 pages but it still took me an hour to work out what to do and get rid of the mess. Basically, for each page (article and discussion) I had to revert to the last version before the spam was added, delete the page and then restore the page selecting only the revisions I wanted to keep.

Sadly I have also had to change the permissions so that only logged in users can edit.

MUWP+BuddyPress update

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.

Trying out Digress.it

Digress.it is a development of a WordPress theme called CommentPress, now no longer being developed. The original author of CommentPress, Eddie Tejeda is behind its new incarnation and Digress.it. The original idea of CommentPress, and now Digress.it is to be able to turn “a document into a conversation” The main difference seems to be that Digress.it is a WP plugin plus theme. This allows a great deal more flexibility and customisation. So far I have only used the plugin with the default Digress.it theme and I have no idea if it will work with others yet.

The process is as straightforward as installing any other plugin – unzip the contents of the download zip file and copy the lot to the plugins folder. Then go into plugins in the Dashboard and activate it. My problem was that the resulting Digress.it blog had no formatting and just displayed in unstructured and unformatted plain text. Joss Winn told me about the Digress.it Google Groupwhere I posted a message about my problem. Eddie responded soon after with the explanation of the problem and how to fix it. When the plugin folders and files are installed (in the wp-content/pluginfolder) the structure had a folder called ‘theme’. On activating the plugin another folder is created in the wp-content/theme folder named digressit. I’m not sure how this works but there is a symbolic link between wp-content/plugin/digressit/theme/ and wp-content/theme/digressit. However, a particular Apache setting has to be in place for this to work – FollowSymLinks. This is not set on the host I am using. Eddie suggested a temporary fix -  to copy the wp-content/plugin/digressit/theme/ folder into wp-content/theme/ and rename it digressit. (I renamed the original wp-content/theme/digressit/folder first in case I needed to reinstate it). And this worked absolutely fine. As Eddie pointed out, this has consequences for upgrading but he intends to sort the FollowSymLinks issue out for the next release. It seems to have this Apache setting is not necessarily the default with some hosting services so organising the plugin-theme coupling so it doesn’t need it would no doubt save others having the same problem.

PS Broke the fix by deactivating the plugin and then reactivating. Had to reinstall whic I did by deleting the plugin and the theme and installing from the plugin page. It looks different from the last installation in that it has the sdiebar on the home (contents) page and a set of buttons along the top as a mani menu. These are labelled:

Table of Contents, Comments, Commenters, General Comments

The first is the home page but the others go to the home page of http://terrywassall.net rather than somewhere in http://terrywassall.net/documents/

PPS Found in the header.php file a section:

<div id=”top_bar”>
   <ul id=”front_menu”>

In addition to the code for the Contents page button there is code for the 3 others. For example the first one is:

<li><a <?php echo ($_GET['comment-browser'] == ‘posts’) ? ‘ ‘ : ”;  ?> title=”Comments By Section” href=”/?comment-browser=posts”><span ><img src=”<?php bloginfo(‘url’); ?>/wp-content/plugins/digressit/theme/images/famfamfam/text_padding_top.png”> Comments</span></a></li>

for the Comments by Section button in the top menu. I edited this as follows:

<li><a <?php echo ($_GET['comment-browser'] == ‘posts’) ? ‘ ‘ : ”;  ?> title=”Comments By Section” href=”./?comment-browser=posts”><span ><img src=”<?php bloginfo(‘url’); ?>/wp-content/plugins/digressit/theme/images/famfamfam/text_padding_top.png”> Comments</span></a></li>

This has corrected the paths and fixed the buttons and they no longer go to the home page of http://terrywassall.net. I assume this is a problem because the installation is not in the root of a WP installation. It is in a subfolder called /documents.

PPPS (Jan 2nd 2010) Deleted the digress.it installation from http://terrywassall.net/documents/ and will do a new installation at terrywassall.org/documents/.

Elgg problems solved by installing php as cgi

On installing php as cgi and reinstalling Elgg the avatar and file upload problems have been soved. I thought it might be useful to understand a bit more about php as cgi. Apparently php normally runs as an apache module. Anyway, clues to what it is all about can be found at:

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?

WPMU + BuddyPress install upload problems resolved

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.

WPMU + BuddyPress install (avatar and file upload problem)

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?

Elgg – a step too far for a non-techie?

I think I will have to leave trying to get my Elgg installation going for the moment. It is taking too much time and help seems difficult to find. The latest problems are no tbeing able to uplaod new profile icons/avatars. They are reported as successfully uploaded but do not appear either as the new picture or in the preview and cropping area. This may be related to a file upload problem. Files appear to upload OK but when they are opened or downloaded they are empty. A txt file I uploaded was 0 bytes and a PowerPoint file had no slides in it.  I’m sure all this is fixable. Certainly plenty of Elgg sites work fine. But the forums suggest a lot of people have a lot of problems!

Elgg tweak- disabling user registration

For a private Elgg set up put the following somewhere in the engine/settings.php file:

$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

Copyright © terrywassall.org
work in progress

Built on Notes Blog Core
Powered by WordPress