December 17, 2007
December 11, 2007
The Mysterious Hang article has been updated.
Prompted by an e-mail from a reader, I added a paragraph on how to solve the problem.
I was working with some integration project where menus of the shell and a plugin are merged a-la MDI.
Both menus are
ToolStrips. We used
ToolStripManager.Merge() to merge them. It turns out that
MergeIndex field of a source menu item is used as absolute position where this item will be inserted in the target menu.
MergeIndexes of the target menu items are ignored.
E.g. if your source is (merge indexes in brackets)
and your target is
File View Help
then merged menu will be
File View PluginMenu Help.
If you later change the shell menu (target) to
File Edit View Window Help
then the merged menu will be
File Edit PluginMenu View Window Help
There is no way to specify something like “this plugin menu goes just before help” or “this plugin menu goes right after View”. Infragistics uses weights instead of absolute indexes. This creates much more sane and maintainable approach.
December 10, 2007
Trying it from work. The website is somewhat slow today. I wonder what may have caused it…
December 9, 2007
Just installed WordPress.
The installation was not as easy as they try to tell you, but this was mostly mySQL’s fault. Still, it was not that bad. Below are the gore details.
I grabbed the latest mySQL (version 5), but their Windows installer failed to finish the job properly. It installed almost everything, but failed to set the root password, for unknown reason. Generally, the installer (or, rather, instance configurator) seems to be very brittle. E.g., if mySQL service already exists, it still tries to create it and fails (duh). I tried to reconfigure mySQL several times, uninstalled it, reinstalled it, but still could not make it work.
The error log was telling me some horror stories about corrupted databases, missing tables, incomplete shutdowns and whatnot. Finally, I had to manually reset root password and only then I was able to log in. Uf-f…
The next WordPress requirement was to create a mySQL database and a user that has access to it. Creating a database was easy, but the user gave me some headaches. For starters, the syntax in the manual did not work for whatever reason. The error message was something like “your SQL is busted; read the manual for your version of mySQL”. Not very helpful.
Then I installed PHP. For someone who knows absolutely nothing about PHP (Windows developer, he-he) the installation went pretty well. I’ve got a little bad feeling when I saw a mile long list of extensions. They also warned to install only the extensions I actually need. I thought WordPress site would list what extensions are required, but it didn’t. So, I chose not to install any extensions, mentally preparing myself for a long battle with an zoo of various interdependent modules, of which WordPress will be telling me one at a time.
With the PHP install completed, the next step was to run WordPress install script. Of course, it did not work. Instead the browser happily showed me the raw PHP code. It turned out that the PHP installer did not restart Apache, so new configs did not kick in. I restarted Apache manually and the PHP execution engine started ticking.
But it did not help me much. As I feared, WordPress installer told me that it cannot continue, because it cannot find the mySQL extension for PHP. I had to run the PHP installer again. Of course, it forgot everything I told it before, and asked me again about what kind of server I have, where is its config, etc. It also promptly commented out settings put into the apache config by the previous run of the PHP installer and added brand new ones. Anyhow, mySQL module was now installed.
However, WordPress installer still could not see it. After about an hour of googling and staring at “cannot load php_mysql.dll” error messages in the Apache log, I found out that this is because libmySQL.dll is not on the path. mySQL installer did not put mySQL bin directory on the path as I asked it to. The recommendation on the Internet was to copy libmySQL.dll to the windows system folder, but I did not like it. Instead, I manually added mySQL bin directory to the system path. Still no joy.
Of course, Apache runs as its own user, and its environment was not updated. Restarting Apache service did not help. I could probably fiddle with the windows stations and what not, but I decided just to reboot the computer. After all, it is not a real server, it is just my toy
Once I rebooted the computer, WordPress stopped complaining about missing mySQL module, but it still could not connect to the database. I tried to connect manually by running mySQL client, and it failed. After a small 10-15 minute fight with mySQL command line, I was finally able to connect as wordpress user and see the database. The wordpress PHP script, however, was still stuck.
I double-checked the config and found that I put ‘username@localhost’ in WordPress config, and it probably expected just ‘username’, since the host is specified elsewhere. I fixed that, and after that the install was nice and easy
One more wrinkle though: when I tried to login, it asked me for user name and password, and then displayed a “forbidden” page: “you don’t have access to the blog directory”. The reason being: WordPress assumes Apache will treat index.php as a default document: when you access http://myhost/foo/ it will serve you http://my/host/foo/index.php. PHP installer, however, did not care to add this option (or maybe I missed it). Once I fixed that my blog was really running.
So, overall install time for WordPress: 4-5 hours. Not bad for a free open source geekware, but horrendously bad for a consumer product. A “normal” not-so-savvy user would probably be thrown off on the mySQL stage. From the other hand, for not-so-savvy users they have managed hosting