weUniversalClassLoaderPlugin

Want to use an Sf2 component or any other namespaced PHP code in your sf1 project? Use this plugin to make it work automatically.
weUniversalClassLoaderPlugin

weGlobalConfigPlugin

A custom config handler to bypass the crowded app.yml with some nice bonus. Not mandatory but useful!
weGlobalConfigPlugin

weErrorHandlerPlugin

Tired of finding out where that damn “Notice in file xy.php on line 1234″ comes from? Make it an exception and view the stack trace!
Sick of crappy php libraries (oh yes, php_ldap, this one goes to you) that use warnings and notices instead of exceptions? This is the past, baby, welcome to the 21st century!
weErrorHandlerPlugin

What’s the status, actually?

All the code comes as-it-is, this means:

• No (unit) tests
• Not all the functions are documented well

This shouldn’t keep you from trying it, since the usage READMEs are helpful and the code is mostly self-explaining. If you have any questions, don’t bother to ask them (probably by opening github tickets).

If you want to help (e.g. by writing tests, documentation, better code), feel free to fork and pull-request. It’s all about the code nowadays!

Have fun!

I’ve nominated symfony in 3 categories:

• Best Tool or Utility for Developers
• Best Project
• Best Commercial Open Source Project

Click the picture to nominate symfony too! Of course don’t forget to read and follow the nomination rules to allow for a fair voting process!

Have fun!

If you want to save your Wiki content and settings you just have to allow the browser to re-save the local HTML file – using that it will just overwrite itself and remember its changes when you re-open the file in the future.

TiddlyWiki is intended to be used as a single user Wiki mostly, ranging from a powerful notebook or journal to a tool to document all your work. Since it creates backup copies of its previous state upon saving, you don’t have to fear losing all your work at once in the future.

I think it is really great fun to use and marks a new step in browser based software. After playing around for a while I quickly understood how to use it and what benefits one might gain from such a tool.

Try it out for yourself and have fun!

Even if you don’t have any particular question, just browsing it for fun or broadening your mind is great and leads to some nice insights.

For this reason I combined my upgrade to wordpress 2.6 with the installation of the Register-Plus plugin to add a captcha to the registration. Unfortunately the simple captcha does not seem to work, it always tells me that my captcha code is wrong (I also tried adding session_start() to wp_login.php as suggested by the plugin, but it didn’t help), so I switched to the reCAPTCHA service. reCAPTCHA works and should be good against bots, so let’s hope for the best!

If you are still reading this, you are really doing backups of your personal data. But do you have regular backups of your web host data (e.g. blog, forum, online shop) including files AND databases? Perhaps you are using stuff like phpMyAdmin to backup your databases from time to time.
And if you DO have backups of your web host (and I’m sure that there are not many people out there doing this, especially for their private hosts), do you have an archive of previous versions? Yes? You’re great, welcome on board, skip this blog posting (or don’t if you want to learn how I do it).

Everyone else who wants to know how to perform fully automated incremental backups of your web host including files and mysql databases and an archive of previous backups and do all this on Windows (of course I know that the Linux guys have advantages in that area) go and read on…

What you need for backing up your web host

To perform the automated backup described here you need the following things:

• A web host that is reachable over FTP
• phpMyBackupPro
• GNU Wget for Windows (included in my package)
• 7-zip
• David’s Web Host Backup Script v1.0

Setup phpMyBackupPro

Download the latest version (currently 2.1) and any language file if you prefer non-English interfaces. The installation is quite easy: just follow the instructions in the INSTALL.txt file. The moving/renaming of the configuration file is security through obscurity: it should be fine without this, but making assurance double sure is no bad way of thinking in terms of security. I have secured my export directory through a .htaccess file, so no one can access anything in there from the web. The .htaccess file is included in my backup package.

After successfully entering your configuration data in phpMyBackupPro you are ready to proceed. Go to the “configuration” and choose “Extended configuration” and set up the values for automatic deletion of files (I have marked the fields with big red dots):

These values depend basically on your personal preferences and on the size of your databases and available web host space. I’m using 14 days, so there are always 14 days of previous database backups directly on the web server. I think 5 or 7 would be enough, but as long as there is enough space… however. Let’s go on!

Create a schedule job file

phpMyBackupPro has a nifty little feature to create semi-automated backups. Go to “schedule backup” and set the following options:

• Backup period: 1 day
• Directory: choose any directory on your server where you might want to put the caller script, I usually just put it into the phpMyBackupPro directory
• Databases: Select all databases you want to include in the backup
• Comments: I always enter “daily backup” here
• Make sure all the checkboxes below the comments area are checked. For the compression i prefer gzip since zip does not always work. If your web server does not support compression select none.

After clicking “Show script” you should get something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<?php
// This code was created by phpMyBackupPro v.2.1 
// http://www.phpMyBackupPro.net
$_POST['db']=array("database_1", );
$_POST['comments']="daily backup";
$_POST['tables']="on";
$_POST['data']="on";
$_POST['drop']="on";
$_POST['zip']="gzip";
$period=(3600*24)*1;
$security_key="eae9fe894401239614a469f87e7ec638";
// This is the relative path to the phpMyBackupPro v.2.1 directory
@chdir("../phpMybackupPro/");
@include("backup.php");
?>

Because the backup always takes a few seconds the full 24 hours setting for the period would work only every 2nd day in average. Therefore I change it to 22 hours (this also makes sure no DST change overrules a backup):

10

$period=3600*22;

Now take the content and put it into a file called something like “auto_backup.php” and upload it onto your server – to the directory you specified before. Now it’s time for the first test: type the address to the auto_backup.php into your browser and hit enter:

http://www.yourhost.com/your-path/auto_backup.php

You will see nothing but a blank page in the browser. To check if the backup worked, go back to your phpMyBackupPro installation and select “import”. There you should see something like database_1.1206988550.sql.gz. If the list is empty, check your script for an invalid relative path in the @chdir or try to perform a manual backup in phpMyBackupPro. To perform several test backups in a row you must change the period value in the auto_backup.php to something much smaller like 30 seconds or so. Don’t forget to set it back to 22 hours afterwards!

How to get the files from your web host to your PC

This is where I had so search quite a long time myself (there are lots of automated FTP mirror tools, most of them costing too much money and not providing what I need here) until I found a solution that is so unbelievably easy that I don’t know why I didn’t get it earlier. The point is not only in loading everything from your server but also 2 other things:

• Getting only those files that are new or have changed
• Getting rid of stuff that also does not exist on the server anymore (full one-way synchronization)

There are tools like rsync out there, but they are too Unix-oriented for my taste and often require shell access that can’t be provided. What I needed had to work with any regular FTP server.

I found out that Wget, the command-line HTTP download tool from the Unix world, is also available for Windows and can download complete FTP structures too. There are of course thousands of people that have known this for years, but I did not since I’m using mostly Windows. Knowledge still equals power.

So what I do is mirroring the FTP server locally using Wget. Of course those readers who know that Wget only does mirroring, not synchronizing, will ask what the hell is he braying about, that’s not what we need!. Well, it was not what I needed either. But it was the main part to be followed by some work of myself.

How to get rid of files that don’t exist anymore

The whole topic of synchronization is about getting the things that have changed (this we have already achieved) and then getting rid of the stuff that’s not on the other side anymore (e.g. old database backups that have been removed or folders that have been renamed). Wget comes in handy in this situation: when downloading from a server, it can provide a file called .listing that names all files that have been downloaded. So the conclusion is: everything that is NOT in this .listing file is outdated and ready to be trashed.

To parse these .listing files and remove outdated files and folders I’m using an Eclipse-based file organization workspace that is strictly object oriented and needs 450 Megabytes of space on your hard drive. Ha, got you there, just joking! It’s a dirty little VBScript, and I’m sure there are lots of ways to improve it, but it works fine for me and that’s basically why I want to share it with people out there who need something that might be working fine for them.

How to get an archive of previous versions

After moving the old files away my script calls 7-zip to create a compressed self-extracting archive. By using the self-extractor feature you don’t have to worry if you don’t have 7-zip any more one day – the files will be available as long as something can execute win32 binaries. There is a new archive created for every day (using the current date when you are executing the script), so you can spot your old data easily.

Summary

So this is what my backup does in the same order:

• Start the database backup online using Wget
• Grab everything that has changed (including the latest database image) using Wget
• Move everything away that is not on the web server anymore using my VBScript
• Create a compressed archive bearing the current date in its name using my VBScript and 7-zip

Use the Windows Task Manager to kick this off every day at the same time and that’s it!

Yeah, alright, I just want to download this thing and go on!

In the end this is all you need besides 7-zip and phpMyBackupPro (which you don’t need in case you don’t have a database to backup):

David’s Web Host Backup Script v1.0

Please read the included README.txt file carefully. It is quite long, but you will save the time for reading hundredfold as soon as the backup works and you don’t have to do anything any more.
Unpack everything to some folder. The folder where wget.exe and clean.vbs reside is also the root folder of all backup stuff. Read the README.txt again, edit example_backup.cmd according to your needs and configuration and lean back!

License

I have released my part of this package under the GNU GPLv3. Wget uses the same license, and I’ve included everything that was inside the original wget package. Feel free to use, modify or spread my work as long as you include the original copyright notice and license.

Please be careful when editing the batch file or modifying the script. I cannot take any responsiblity for your lost data if you do something wrong. If you are unsure please ask me.
This little script has been working fine for me for over 18 months and I’m currently backing up 5 different web hosts every day without any problems, and of course without having to do anything manually. Every few weeks I check if everything is fine and delete some old archives, but that’s it!

If you have any questions, comments or improvements you want to share with others, feel free to comment here or send me an email using david (at) vworld.at.

Copying the files and database worked just as well as expected. I had the CMS up and running on the external host after 10 or 15 minutes of uploading, checking and adapting the configuration. The performance was ok, too. I added some further content and was satisfied with the results so far.

Extending Joomla!

The frustration followed when I tried to install additional plugins. My web host uses the inglorious Safe Mode and it cannot be deactivated (and I cannot switch the web host so easily either, so I’m kind of stuck with it), so there is no way around it. I would also accept the fact that Joomla! just does not work with the Safe Mode – but the documentation does not say so! In fact there are some hacks and plugins that allow installing Joomla! in Safe Mode, but they do not seem to work for everyone, and they are apt to be pure pain.

What bugs me even more than the fact this is not working is that it handles the failures extremly badly in my opinion. Let me give you an example of a simple plugin installation that goes wrong:

• I started by uploading a package file through the weg interface – this just didn’t work at all, probably because it could not be decompressed or whatever. Ok.
• I tried to manually upload a package to the web host and install it from there. This resultet in some error messages telling me that this or that folder had no write permissions.
• Creating the folder and providing write permissions would not work either – then the installer complained that the folder already existed
• You truly have to give write access to nearly all folders of your Joomla! installation to allow the installation of extensions! Now it could create the folder and copy the files, but failed to copy another plugin package because it was already there!
• Deleting this other package became very interesting too, since deleting files created by the web server does not work through FTP in safe mode. The solution was a quick deltree-like PHP script.
• After some further failed tries I decided to give up the automatic installer take a look at the installation script.

The installation script is quite simple: some uncompressing and copying of archives with folders inside and a few lines to be added to the database.

Doing it manually

As someone who has been used to installing phpBB MODs just the manual way for years I have absolutely no aversion to copy a few files and add a few lines to the database (this could even be done easily through a provided little script). But Joomla! just does not allow to do this – at least not officially. They seem to be so proud of their error prone Extension Installer, that it does not come to their mind to allow anything else.

An extension installer that is not failsafe (e.g. providing fallback mechanisms if something goes wrong) is bad. Some unexperienced user could ruin their whole installation just by trying to install an extension the way it is suggested!

This makes Joomla! maintenance just a little better than DotNetNuke maintenance, but they are close. I don’t know what I had done if my Joomla! installation had gone down the drain too. Perhaps I would have tried typo3.

After this experience the way to upgrade or extend your Joomla! installation on a Safe Mode web host is clear:

• Copy your Joomla! installation to a local XAMPP or whatever environment with less restrictions
• Install everything you need
• Move it back to the other server
• Don’t forget to do backups!

Fortunately (at least they got this right at Joomla!) the database and path configuration is stored in a single text file, so you can move everything else and it will keep working.

Software that does this better

By the way this was my first bad experience with Safe Mode during the last 4 or 5 years. Just recently I installed phpBB 3.0 on another web host like this (it was even an upgrade from 2.x) and it just worked. IT JUST WORKED. The phpBB guys make sure that their software works on nearly any web server configuration and this is what makes their product so successful. Joomla! looks great and has lots of useful features, but in that respect the maintainers still have a lot to learn. Learn about why some web applications are more usable than others.

For PHP stuff testing purposes I usually consult my local XAMPP installation. This is an easy to use Apache/PHP/MySQL package that is preconfigured and runs out-of-the-box – at least as long as you don’t need full pear support with commandline installer and everything, but that is another story to be written.

Joomla! is based on the Mambo CMS and was forked during some quarrel over the development roadmap and commercialization issues a few years ago. There are 2 versions available: 1.0.x and 1.5.x. While the 1.0.x path bears more resemblance to the original Mambo code, the 1.5.x series was designed with modularity in mind and is easier to extend and maintain. I decided to take the latest version, even though the first release of 1.5.0 is only several weeks past.

The installation completed without any troubles and after 3 hours of studying the backend I had a fairly good knowledge of how Joomla! works. Of course there is much to learn yet, but so far this was fine. The next step was to continue where DotNetNuke had failed: change the template of my page. My template of choice was Siteground J15-22 (Demo). It has a variable (adjustable) width, is fully XHTML compliant and looks quite nice. The template installation was as easy as it could be: save to template folder, activate in admin panel, done.

There was one thing though that annoyed me: when using sub items inside the sidebar menu, they appeared only if the parent item was selected – this is the default behaviour and ok for me. But when I activated the option to always show sub menu items, they were visible but no longer recognizable as sub menu items because they look the same as the parent items. WTF?

After seeing through the code I found out that both Joomla! and the template share their parts in this issue. The menu is made of an unordered list, and all the items bear a different CSS class parameter like this: <li class=”item53″> or <li class=”item54 parent”>. The currently selected item looks like this: <li class=”item24″ id=”current”>. Come on, this is bad! There are even space characters in the class names!

Shouldn’t the class and id tags be the other way round? What is the use of having lots of menu items with completely different css classes? Was the developer who did this on some psycho-pushing substance – like, erm, caffeine – or just thinking “nobody will ever have to define CSS classes for their menu items, so this is fine” or just simply ignorant? My point in this is the following: you can’t have grouped menu items with this design. You can’t assign 1 or 2 menu items a specific style (oh, you can… but if the item ids ever change, the style will be gone or even be assigned to the wrong item!). It just feels bad, and this is why I had to undo this in the mod_mainmenu PHP code.

I also fixed the style sheet so that sub menu items are always indented. Personally I would have preferred to use something like a .subitem{} CSS class – at least this would have saved a lot of CSS code. But defining the style through the structure alone is perhaps the even better model, so I kept with that.

OK. So far the style was ok, the menu was working as I would expect it, and I filled in some of the content from the DotNetNuke installation that had been fixed by my colleague in the meantime – he had a full backup from before me meddling around with it.

The next chapter in this small series will be about the transfer to a LAMP web host and how the real trouble with Joomla! began.

The installation seemed fairly easy, and he had a web site including some test content set up in a short time. Personally I think of the basic design as “quite ugly”, but this shouldn’t be a problem for an experienced web developer, should it? Besides the optical ugliness there was a second reason for me to decline the existing layout: its lack of working without javascript turned on (oh how I hate those javascript-only menus!). Besides being a usability failure we should have overcome 5 years ago, this also makes a web site less indexable by any search engine, so this is a knock-yourself-out-kit for any serious business web site.

I took a look at the default templates and was somewhat lost. OK. Lots of HTML and other (unrecognizable) files. Then I took a look at the documentation (pdf only?) and was a little less lost, but this was plainly a pain. Fortunately I found a nice and slick and clean replacement template at xhtmlskins.com, which I downloaded after registering on their web site (guys, this was the last time I did this, I was just too desperate to search any further). This template (or skin as it is called throughout DNN) is a zip package with some files inside (this one much easier to understand than the template on the web server). I uploaded the skin package using the skin upload mechanism built into DNN, and this is problably where I should have RTFM first. There are 2 options when uploading a skin, and it looks like I chose the wrong one. The upload worked and the DNN engine obviously unpacked the zip file, parsed the HTML data and created lots of new files, so everything looked fine.

Everything fine? Wrong, pal! After the (seemingly) successful upload of the skin I activated it as my default skin. You never guess what happened: the page broke completely. At first, some content panes switched their layout to something totally different, including lots of partly unrecognizable error messages. When I navigated the page, i got very long waiting times, followed by an IIS error. Going back there was no chance to undo what I just had done. I messed up and killed the complete DotNetNuke installation by activating the wrong skin. Since there is no separate admin front end there is no chance to remove this any other way than by accessing the server directly (which wasn’t possible at that moment). Knock-yourself-out at its best.

I don’t know if I will ever install DNN again in my life. This happening even convinced my otherwise Microsoft-friendly colleague to go for something different – which will be the next part of this story.

One more thing before any fanboy fraction starts to complain: I know that I possibly made a mistake. But any software that is THAT mature (version 4.8) and THAT widespread should do better than screw up by installing a skin. This is what software quality is about, and DNN did this incredibly wrong. Period.