Tag: farm

Testing Hosted Blog Solutions [en]

I’ve set up a few test blogs on various hosted blogging farms. Nasty feedback for some of them.

[fr] J'ai ouvert des blogs-tests à  divers endroits qui offrent blogs et hébergement. Voici une liste de mes blogs-tests avec quelques commentaires.

I’ve started setting up test blogs here and there to try out hosted blogging solutions, as I’m eager to encourage people to start blogging, but I’m aware that getting server space, a domain, and installing WordPress isn’t something the casual user will do.

So, very brief review here, more details on the blogs themselves (which tend to be lists of complaints and problems I ran into while functioning in my lazy-lambda-user mode).

ViaBloga

My test blog is Chez Steph. ViaBloga is a cousin of Joueb.com, minus the community emphasis, which appears repulsive to some. (Think LiveJournal.)

I’ve run into a few bugs and usability problems there, which have always been quickly responded to and addressed by the staff. I should add that I’ve known Delphine and Stéphane for quite some time now, and that the latter personally asked me if I was interested in testing ViaBloga when they were starting with it.

ViaBloga has got wiki-like features I haven’t really managed to get into. One thing that really has me enthusiastic (and I discovered that today) is the list management system. Just add the url, it fetches the title of the link, the rss feed, and creates a thumbnail. Here is an example of what it can look like — look at Delphine’s blogroll, too. I’d love to see something like this rolled into a plugin for WordPress — it makes me feel like adding all sorts of links to my blog.

Skyblog

I’ve decided to go public with my skyblog, and I hope you appreciate my courage. Skyblog is clearly aimed at a very young public (teens), and even the language in the admin interface reflects that. Many of my pupils have skyblogs on which they post photos of their friends and make brief comments in sms-talk.

I find the blogs themselves ugly, and the admin interface is kludgy, though it seems it works, because my pupils always complain that WordPress is so hard to use and that skyblog is so much better and easier. One thing to be said, skyblog makes it really easy to upload photographs, so many of these skyblogs ressemble a vaguely commented photo album.

I hardly posted anything to my test blog, and upon checking it out again today I was amazed at the amount of (a) visits (nearly 1000) it had had, and (b) nasty aggressive comments complete strangers had left me. I’ve added a photo of my cat, I wonder what the reaction to that will be.

Blogsome

Blogsome is clearly my favourite. Here is my Blogsome test blog, complete with a Pink Lilies theme. It took me less than 30 seconds to open my weblog (a username, an e-mail address, and a title for the weblog — done.)

It’s WordPress, so I’m in known territory, and I’ve been busy posting bugs and comments in the forums. Blogsome is still young, and my biggest gripe for the moment is the caching problems — for example, changes to the template or links are not immediately reflected on the blog (though “publishing” a post helps).

If you’re looking for a free hosted blogging solution right now, Blogsome is the one I would recommend, along with Blogger, of course. I used Blogger for years, before Blogspot existed. I left mainly because it lacked certain features I wanted (like categories) — and I’d say that still now, it’s a little bit poor on the feature side. But it’s a good, reliable service which has been around long enough to be trusted without too many second thoughts.

MSN Spaces

I just opened a test blog at MSN Spaces. My first two posts complain quite a bit (my biggest gripe for the moment being that it doesn’t convert line breaks into paragraphs — a showstopper, if you ask me). My positive experience was changing the template — that worked fine.

So, if you’re interested, keep an eye on those blogs. I’m always happy to try things out and complain about all the problems I run into.

Edit 06.12.04: Got another test blog at NRJ blogs — though in my opinion you can barely call it a blog. I had to log out to figure out what my blog address was, and it seems totally impossible to make outgoing links. Keep an eye on the individual test blogs for comments on the different systems.

Edit 2: OK, got one at CanalBlog too. The admin interface completely takes over the browser, but it seems really usable (I didn’t run into any problems!) and the default layout is clean enough. Just an ad banner on top. That’s enough for tonight, folks!

Edit 3, 07.12.04: Add a 20six.fr test blog to the list. Follow-up post coming.

Edit 4: HautEtFort, and I think I’m done with creating test blogs. Gah.

Edit 5, 08.12.04: Hopefully the last bunch, but you never know. I seem to be suffering from some obsessive-compulsive blog opening disorder. LiveJournal, BlogSpot, Joueb and U-blog. Have I forgotten someone? I count 12 test blogs. Now let me go and update all my blogrolls.

Edit 6: A fresh new French service, open since yesterday: Mon-Blog.org, based on DotClear.

Similar Posts:

Blogsome: a WordPress Weblog Farm [en]

A hosted WordPress weblog provider just opened. I’m testing.

[fr] Blogsome est une solution hébergée fournissant à  qui le désire un weblog WordPress en deux clics (moins d'une minute).

Check out Blogsome. It looks exciting. I’ve set up a test blog: enter a username, an e-mail address, your blog title, and there you are. 1 minute.

I’m very curious to see how this will scale, especially given my experiences with my school blogs. I’m also curious to see if they will release the code used.

If you’re trying it, please let me know what you think!

[via Ollie]

Similar Posts:

Scripts for a WordPress Weblog Farm [en]

A first step to WordPress-farming: a shell script and a PHP script which allow you to easily install a whole lot of WordPress weblogs in only a few minutes (I installed over 30 in less than 5 minutes). Scripts require adapting to your environment, of course.

Update 03.11.06: Batiste made me realise I should point the many people landing here in the search of multi-user WordPress to WordPress MU. All that I describe in this post is very pretty, but nowadays completely obsolete.

Here is the best solution I’ve managed to come up with in half a day to finally install over 30 WordPress weblogs in under 5 minutes (once the preparation work was done).

A shell script copies the image of a WordPress install to multiple directories and installs them. A PHP script then changes a certain number of options and settings in each weblog. It can be used later to run as a “patch” on all installed weblog if a setting needs modifying globally.

Here are the details of what I did.

I first downloaded and unzipped WordPress into a directory.

wget http://wordpress.org/latest.tar.gz
tar -xzvf latest.tar.gz
mv wordpress wp-farm-image

I cleaned up the install (removing wp-comments-popup.php and the import*.php files, for example), added a language directory (as I’m wp-farming in French) and modified index.php to my liking; in particular, I edited the import statement for the stylesheet so that it looked like this:

@import url( http://edublogs.net/styles/toni/style.css );

The styles directory is a directory in which I place a bunch of WordPress styles. I don’t need the style switcher capability, but I do need to styles. Later, users will be able to change styles simply by editing that line in their index.php (or I can do it for them).

Another very important thing I did was rename wp-config-sample.php to config-sample and fill in the database and language information. I replaced wp_ by xxx_ so that I had $table_prefix = 'xxx_';.

To make it easier to install plugins for everyone, correct the language files, and edit whatever may be in wp-images, I moved these three directories out of the image install and replaced them with symbolic links, taking inspiration from Shelley’s method for installing multiple WordPress weblogs.

mv image/wp-content common
mv image/wp-images common
mv image/wp-includes/languages common
ln -s common/wp-content image/wp-content
ln -s common/wp-images image/wp-images
ln -s common/languages image/wp-includes/languages

I also added an .htaccess file (after some painful tweaking on a test install).

Once my image was ready, I compiled a list of all the users I had to open weblogs for (one username per line) in a file named names.txt, which I placed in the root directory all the weblog subfolders were going to go in.

I then ran this shell script (many thanks to all those of you who helped me with it — you saved my life):

for x in `cat names.txt`
do
cp -rv /home/edublogs/wp-farm/image/ $x
cat $x/wp-config.php | sed "s/xxx/${x}/" > config.tmp
mv config.tmp $x/wp-config.php
wget http://st-prex.edublogs.net/$x/wp-admin/install.php?step=1
wget http://st-prex.edublogs.net/$x/wp-admin/install.php?step=2
wget http://st-prex.edublogs.net/$x/wp-admin/install.php?step=3
done

This assumes that my WordPress install image was located in /home/edublogs/wp-farm/image/ and that the weblog addresses were of the form http://st-prex.edublogs.net/username/.

This script copies the image to a directory named after the user, edits wp-config to set the table prefix to the username, and then successively wgets the install URLs to save me from loading them all in my browser.

After this step, I had a bunch of installed but badly configured weblogs (amongst other things, as I short-circuited the form before the third install step, they all think their siteurl is example.com).

Entered the PHP patch which tweaks settings directly in the database. I spent some time with a test install and PHPMyAdmin to figure out which fields I wanted to change and which values I wanted to give them, but overall it wasn’t too complicated to do. You’ll certainly need to heavily edit this file before using it if you try and duplicate what I did, but the basic structure and queries should remain the same.

I edited the user list at the top of the file, loaded it in my browser, and within less than a few seconds all my weblogs were correctly configured. I’ll use modified versions of this script later on when I need to change settings for all the weblogs in one go (for example, if I want to quickly install a plugin for everyone).

In summary:

  1. compile list of users
  2. prepare image install
  3. run shell script
  4. run PHP script

If you try to do this, I suggest you start by putting only two users in your user list, and checking thoroughly that everything installs and works correctly before doing it for 30 users. I had to tweak the PHP script quite a bit until I had all my settings correctly configured.

Hope this can be useful to some!

Update 29.09.2005: WARNING! Hacking WordPress installs to build a farm like this one is neat, but it gets much less neat when your weblog farm is spammed with animal porn comments. You then realise (oh, horror!) that none of the anti-spam plugins work on your beautiful construction, so you weed them out by hand as you can, armed with many a MySQL query. And then the journalist steps in — because, frankly, “sex with dogs” on a school website is just too good to be true. And then you can spend half a day writing an angry reaction to the shitty badly-researched article.

My apologies for the bad language. Think of how you’re going to deal with spam beforehand when you’re setting up a school blog project.

Similar Posts:

Requirements for a WordPress Installer Script [en]

To install 30+ WordPress blogs on a server, it would be nice to have an automatic installation script. Here is a list of what this script should do for me.

[fr] Pour installer plus de trente weblogs WordPress sur mon serveur, il serait utile d'avoir un script d'installation en PHP. Quelqu'un a offert d'en écrire un pour moi. Ce billet récapitule ce que devrait faire un tel script, de mon point de vue (installation et configuration de WordPress en fonction d'un nom d'utilisateur).

As you may know, I’m shortly going to install 30+ WordPress blogs on my server. Noderat on #wordpress kindly offered to have a go at writing a PHP script to automate WP installs. I sent him this list of what the ideal script should be able to do for me, but on second thoughts, I’m posting it here so that everybody may see it. Of course, if you know of an existing script which already does this, let me know!

  • take $username + $password as input
  • install wordpress in a subdir named “$username”, using table prefix “$username_” and with an extra user (on top of admin) named “$username” (password=”$password”), user level 3
  • mysql user should be “$username” too (password “$password” also), with grants only on the tables belonging to this weblog
  • set permalink scheme to
    /archives/%year%/%monthnum%/%day%/%postname%/ for monthlies and /categories for categories
  • generate .htaccess in directory, based on this template, with “blog” replaced by “$username” everywhere
  • in wp-config: define (‘WPLANG’, ‘fr’) and edit appropriate lines
  • wp-includes/languages and wp-content/plugins should be symlinked to directories I can specify in the script
  • blog admin password should be reset to something I can specify in the script

I should be able to edit the script config file to provide mysql root user + pass, wordpress database name.

It would also be interesting if the script was built in such a way that it could be further modified/developed to allow installation of blogs on separate subdomains rather than subfolders. From the point of view of the filesystem the blogs live in, this wouldn’t change much — but some extra WordPress options would need editing (e.g. blog address), as well as the Apache and Bind config files necessary to set up the subdomain. This is not mandatory, but could be useful at some point (if we’re thinking in the line of WordPress-farming).

Similar Posts:

Musings on a Multiblog WordPress [en]

Thinking about a solution to make WordPress MultiBlog. Comments, criticism and other ideas welcome — please join the fun. In particular, I bump into a hairy PHP include problem.

[fr] Je réfléchis à comment on pourrait donner à WordPress la capacité de gérer plusieurs blogs avec une installation. Je me heurte à un problème concernant les includes PHP. Feedback et autres idées bienvenues!

**Update June 2007: Try [WordPress Multi-User](http://mu.wordpress.org/) now.**

I’ve used Shelley’s instructions using soft links. I tried Rubén’s proof-of-concept, but got stuck somewhere in the middle.

So I started thinking: how can we go about making WordPress MultiBlog-capable? Here is a rough transcript of my thoughts (I’ve removed some of the dead ends and hesitations) in the hope that they might contribute to the general resolution of the problem. I have to point out my position here: somebody with a dedicated server who’s thinking of setting up a “WordPress weblog-farm” (for my pupils, mainly). So I’m aware that I’m not the “standard user” and that my solution is going to be impractical to many. But hey, let’s see where it leads, all the same. Actually, I think I probably reconstructed most of Rubén’s strategy here — but I’m not sure to what extent what I suggest differs from what he has done.

From a system point of view, we want to have a unique installation of WordPress, and duplication of only the files which are different from one blog to another (index.php, wp-config.php, wp-comments.php, wp-layout.css, to name a few obvious ones). The whole point being that when the isntall needs to be upgraded, it only has to be upgraded in one place. When a plugin is downloaded and installed, it only has to be done once for all weblogs — though it can of course be activated individually for each weblog.

From the point of view of the weblogs themselves, they need to appear to be in different domains/subdomains/folders/whatever. What I’m most interested in is different subdomains, so I’ll stick to that in my thinking. (Then somebody can come and tell me that my “solution” doesn’t work for subfolders, and here’s one that works for subfolders and subdomains, and we’ll all be happy, thankyouverymuch.) So, when I’m working with blog1.example.com all the addresses need to refer to that subdomain (blog1.example.com/wp-admin/, etc); ditto for blog2.example.com, blog3.example.com, blogn.example.com (I used to like maths in High School a lot).

As Rubén puts it, the problem with symbolic links (“soft links”) is called “soft link hell”: think of a great number of rubber bands stretched all over your server. Ugh. So let’s try to go in his direction, for a while. First, map all the subdomains to the same folder on the server. Let’s say blog1.example.com, blog2.example.com (etc.) all point to /home/bunny/www/wordpress/. Neat, huh? Not so. They will all use the same wp-config.php file, and hence all be the same weblog.

This is where Rubén’s idea comes in: include a file at the top of wp-config.php which:

  1. identifies which blog we are working with (in my case, by parsing $HTTP_HOST, for example — there might be a more elegant solution)
  2. “replaces” the files in the master installation directory by the files in a special “blog” directory, if they exist

The second point is the tricky one, of course. We’d probably have a subfolder per blog in wordpress/blogs: wordpress/blogs/blog1, wordpress/blogs/blog2, etc. The included file would match the subdomain string with the equivalent folder, check if the page it’s trying to retrieve exists in the folder, and if it does, include that one and stop processing the initial script after that. Another (maybe more elegant) option would be to do some Apache magic (I’m dreaming, no idea if it’s possible) to systematically check if a file is available in the subdirectory matching the subdomain before using the one in the master directory. Anybody know if this is feasible?

The problem I see is with includes. We have (at least) three types of include calls:

  • include (ABSPATH . 'wp-comments.php');
  • require ('./wp-blog-header.php');
  • require_once(dirname(__FILE__).'/' . '/wp-config.php');

As far as I see it, they’ll all break if the calling include is in /home/bunny/www/wordpress/blogs/blog1 and the file to be called is in /home/bunny/www/wordpress. What is wrong with relative includes? Oh, they would break too. Dammit.

We would need some intelligence to determine if the file to be included or called exists in the subdirectory or not, and magically adapt the include call to point to the “right” file. I suspect this could be done, but would require modifying all (at least, a lot of) the include/requires in WordPress.

Maybe another path to explore would be to create a table in the database to keep track of existing blogs, and of the files that need to be “overridden” for each blog. But again, I suspect that would mean recoding all the includes in WordPress.

Another problem would be .htaccess. Apache would be retrieving the same .htaccess for all subdomains, and that happens before PHP comes into play, if I’m not mistaken.

Any bright ideas to get us out of this fix? Alternate solutions? Comments? Things I missed or got wrong? The comments and trackbacks are yours. Thanks for your attention.

Similar Posts: