The new WP2.0 has been out for more than two weeks now and seeing there haven’t been any urgent patches/bug fixes/etc I assumed it is mature enough to be upgraded. Other than that, it seems like a perfect Sunday procrastination task
I basically followed the official WP upgrade instructions, but as my WP has been somewhat customized, I had to do some extra steps. Here’s what I did:
1. Backup the database, disable the plugins (SK2 and Markdown).
2. Move the old WP directory to “blog-old“.
3. Install a new “blog“ directory, fix permissions, copy the configuration files.
4. Upgrade the blog using “upgrade.php“ script.
5. Check that everything almost works
That was easy. Now the difficult part.
First, my theme has been somewhat customized (including [Diego's "linky"](http://www.zzamboni.org/brt/2005/02/19/20/) patch). However, even if WP2.0 still uses WP1.5 theme, some things have been changed (don’t know exactly what and why). To port my changes, I used the following procedure:
1. Create a diff against “vanilla” WP1.5.2.
2. Apply the patch on the new WP2.0.
3. Fix those little changes that didn’t merge.
Second, I once fixed a bug in WP1.5.2 concerning categories counts on the main page. Basically the problem is that the counts reflect only the “posted” posts and the private posts are not counted. However, when you are logged in and click on a given category you get to see all the posts, also including the private ones. Similarly, (sub)categories containing only private items do not show. The patch for WP1.5.2 was basically a one-liner, but it doesn’t work in WP2.0
Looking at the relevant file, it turned out that the new version uses precached counts stored in the database, instead of computing them dynamically. Hence, the patch doesn’t and cannot work. There also doesn’t seem to be an easy way of fixing it, so it has to stay the way it is.
Third, I had to upgrade SpamKarma2.0 to SpamKarma2.1 (I still doesn’t want to use Akismet, which is shipped by default in WP2.0).
Fourth, I upgraded Markdown plugin, to a new verison and disabled the new WYSIWYG editor (seems to conflict with Markdown).
Finally, I made a small fix to “linky” code, as it also conflicts with Markdown plugin. As the linky doce uses “wptexturize“ to get the content of the entry Markdown is not converted correctly. I changed “wp_texturixe“ to “apply_filters(‘the_content’,…)“ as the latter calls the plugin conversion function. However, in this case I had to remove extra “p“ tags, or more precisely, remove all “p“ tags alltogether. Finally the code looks like this:
Posted in Personal, Tips&Tricks | 2 Comments »
Wednesday, January 11th, 2006
While writing my paper I found out a nice page table layouting package – [``tabulary``](http://www.ctan.org/tex-archive/help/Catalogue/entries/tabulary.html)). If has the following advantages over “tabularx“:
1. The results are “intuitive”, i.e. the table columns can be scaled proportionally to their original width (it takes some manual tricks to make “X“ with different widths). This is similar to HTML rendering in the browser.
2. Yet you can specify maximum and minimum width for layouting to avioid overly imbalanced tables.
2. You can use various aligning (“C“, “L“, “R“ does exactly what you think it does).
3. Obviously, similarly to “tabularx“ you can mix the variable-width columns with fixed width ones.
The only problem was that “tabulary“ (v.0.8) didn’t work well for me in all cases. I looked a bit into the code and I think I found the bug (I’m not a TeX expert, so I’m not sure, but it works for me now). The fix is the following one-line patch file:
— tabulary.dtx 2006-01-11 15:45:03.000000000 +0100
+++ tabulary.dtx.orig 2006-01-11 15:44:29.000000000 +0100
@@ -599,7 +599,7 @@
\let\TY@checkmin\relax
\ifdim\TY@tablewidth>\z@
\Gscale@div\TY@ratio\TY@linewidth\TY@tablewidth
– \ifdim\TY@tablewidth <\TY@linewidth
+ \ifdim\TY@tablewidth <\linewidth
\def\TY@ratio{1}%
\fi
\else
Posted in Progs/Tools/Libs, Tips&Tricks | No Comments »
Thursday, January 5th, 2006
It’s stupid, but it took me a good hour to figure this out, so maybe I’m not the only one…
I’ve recently had a problem with command-line arguments in my Java program. The problem was that command line arguments containing spaces were parsed incorrectly, i.e. chopped into individual arguments. My initial suspect was [gnu.Getopt](http://http://www.urbanophile.com/arenn/hacking/getopt/Package-gnu.getopt.html) package I use for parsing arguments, but as it turned out I was wrong.
The real culprit was a shell wrapper script I used to wrap my java code. The code was the following:
java
$@
See the problem? I didn’t. You need quotes around “”$@”“ in which case the parameter gets expanded to: “”$1″ “$2″ “$3″…“ With no quotes the shell expands it to “$1 $2 $3“, hence all parameters containing spaces get chopped (also globbing takes place in this case).
BTW: There’s also “”$*”“ which is used to combine all parameters into a single one, i.e, “”$*”“ expands to “”$1c$2c$3c…“, where “c“ is “$IFS“ (or space). Here it’s also important to have it enclosed in quotes.
Posted in Personal, Shell, Tips&Tricks | 6 Comments »