skip to main content.

posts about wordpress.

i have several wordpress installations running on my servers. among them, there is one instance which is not publicly visible. it uses dates which are several decades in the past.
everything was working well when i last worked on that project, which is quite some time ago. but yesterday, when looking at it another time, i noticed something odd. the dates were all replaced with the current date (and time). wtf?
now, some debugging later, i found the culprit. that wordpress installation is in german (the only german one i have), and somewhere inside wordpress, a function called date_i18n is used in that case to translate a timestamp into a date, time, or whatever is requested. unfortunately (for me), this function (in Wordpress/wp-includes/functions.php) contains a “sanity check” for “php 5.1.0-”. in case the unix timestamp is negative, it is set to current time. and obviously, any date before january 1, 1970 will be turned into today.
commenting out these lines (or removing them) fixes the problem.

posted in: www

when i noticed that the spielwiese‘s archives list was pretty long (one line per month, that accumulates over time), i looked for a way to turn this into a tree which is by default folded together to a short list of years. after a short search, i found the wp-dtree plugin, which works nice, but doesn’t really do with the archives what i wanted to do. so i created my own plugin, which uses wp-dtree’s javascript code to create an archives tree as i wanted it. now i polished the plugin a bit, and decided to upload it here, so other interested persons can try it out.
to use it, you must have the wp-dtree-30 plugin installed and activated. otherwise, you won’t see anything. you can download my plugin here. just unzip it into your wordpress’ plugin directory, activate it and add the “lazyone’s archives.” widget to your sidebar and configure it as you wish. as usual, no warranty for anything.
note that you need a new enough version of wordpress. wp-dtree-30 requires wordpress 3.0.1, and my plugin requires wordpress 2.8 (for the new widget interface). so if you have a wordpress installation older than 3.0.1, either upgrade or don’t use the plugins.

as you might have noticed, musikwiese has its categories displayed as a tree. i did this using the wp-dtree plugin. this is pretty nice, and i thought that i might also be able to use it for spielwiese‘s archives list – after all, that list contains like 40 entries. so it would be nice to have a tree with the years as top-level nodes, which can be expanded to get a list of months. unfortunately, wp-dtree doesn’t do this. so i started programming myself, creating a small plugin which outputs the code wp-dtree should create to display such an archive. and, it seems to work fine! i also included a noscript fallback for people with disabled javascript; in that case, the “classical” archives will be displayed.
if you are interested in my plugin, ask me, and i will send it to you or maybe also upload it somewhere here.

when mary asked for more at the end of the music video series, i spent some time thinking about how to continue this. eventually, i got an idea: create another blog, the musikwiese. (isn’t it a perfect name for this?)

the aim of the musikwiese is to present another artist every few days. the beginnings were made with lacuna coil and capricorns, and my todo list features 89 more bands. this will be a rather long term project, and the todo list will probably not only shrink during that time.

this project is also not necessarily a one man project for all its lifetime. if someone is interested in contributing something, please contact me.

anyway, i hope you enjoy the musikwiese! :-)

some people like me have the problem of having several wordpress installations at the same time; people like me and some others i know. i have one wordpress running for this blog, one for my math blog, one for a hidden, password protected project which might or might not ever see the light of the world, and anther one for another music related project showing up soon.
whenever a new wordpress version comes out, a question bugs me: how to update all of these installations without doing it manually for every one? of course, there’s the automatic update, but i don’t really trust it. and i don’t have an ftp server installed, so i’m not sure if it would work at all. so i need another solution.
a first idea was to use symbolic links. have one wordpress installation in a directory outside the web tree, and link these files into all wordpress directories in the web tree, so for updating i only need to change one directory, and i only have to touch the others when the configuration file has to be changed.
unfortunately, this doesn’t work, thanks to php and wordpress. wordpress determines the path to the config file by the path names of the files, and since the files are symbolic links, the paths of the files pointed to are used. but in that directory, no config file is available, and wordpress fails. too bad.
now i got another idea. namely, have a wordpress directory outside the web tree, and put it into subversion. then, in all other wordpress directories, drop in the files using subversion, except the configuration file, uploads, latex caches, etc. so to update an installation, i have to go into its directory and type svn up. that’s it. there’s one thing left to do: namely hide the .svn directories from the web server. i didn’t found the perfect method yet, but adding this to the apache configuration makes them forbidden:

<DirectoryMatch “^/.*/\.svn/”>
  Order deny,allow
  Deny from all

then every access to something in an .svn directory results in an access denied error:

You don’t have permission to access /.svn/ on this server.

some time ago, i wrote a small plugin which logs the most recent user activity (for users having an account) and presents them sorted by their last access to the admins. the plugin only stores timestamps, and refrains from doing so while the user is in the admin area. users not logged in are ignored.
i’ve now polished it up, i.e. made the output a bit more fancy. in case someone else is interested in this as well, i decided to put it online. you can download it here if you are interested. to install it, just extract the zip archive into your wordpress plugin directory.
be warned: i don’t take any responsibility for the use of this plugin. do with it whatever you want. if it breaks your system, that’s your problem. especially if you have many user accounts, make sure you understand what the plugin is doing before trying it out.

i stumbled over a wordpress bug making my xhtml invalid. in fact, i noticed i stumbled about it the second time. i think the first time was when i installed wordpress 3.0, and the second time after upgrading to 3.0.1. the problem is, that shortcodes which appear in single lines should not be enclosed with <p>…</p> according to the manual. but my wordpress installation is doing exactly that what is claimed to be fixed for some time.
i started digging a bit, and quickly noticed that i already fixed it. since it seems to be a persistent problem i want to document it, just in case i have it again. internally, wordpress first runs the function wpautop on the content, which adds <p>…</p>, and then runs shortcode_unautop to remove <p>…</p> around shortcodes standing in a single line. (in previous wordpress versions, both was done in wpautop if i recall correctly.) now the problem is, that my wordpress installation calls these two functions in the wrong order. so shortcode_unautop is called first, finds nothing to remove, and then wpautop is called, which adds the faulty <p>…</p> code.
an easy fix is to change wp-include/default-filters.php by changing all lines add_filter(‘whatever‘, ‘shortcode_unautop’); to add_filter(‘whatever‘, ‘shortcode_unautop’, 11);. after that, everything is fine. i wonder whether this happens on every installation or just on some.
now that i fixed this a second time, i wanted to find out in more detail what’s going on. after some digging, i found out that the cause is a plugin i use: wp_unformatted. it removes wpautop from the filter list and adds it again later, hence moving it after shortcode_unautop if both have the same default priority. well, so the right thing is to fix that plugin.
in case you want to know how to fix that plugin, proceed as follows:

  1. change the line in wp_sponge from return wpautop($pee); to return shortcode_unautop(wpautop($pee));;
  2. add remove_filter(‘the_content’, ‘shortcode_unautop’); after remove_filter(‘the_content’, ‘wpautop’);.
posted in: computer www

while updating some old posts with photos (just designwise, no content changed), i once again experienced a complete lockdown: the server became incredible slow and was floaded with apache processes, and i had to shut down and kill -9 all apache processes several times to be able to continue to do anything except waiting. this isn’t the first time this happend, but this time i had apache’s logging enabled (waiting for something like this) to see what was causing all the accesses. well, out of the 13.000 logfile entries (ranging over a week, i think), around 3.300 were by wordpress – and 99.9% of these happend in the last few hours, while i was updating the old posts. it seems that every time i updated a post, wordpress accesses all links and images in the post, also the local ones, and downloads them. yes, downloads them – also the big versions of panoramas. and if i’m updating posts with often 10–30 photos, some of them large, this clearly explains why the web server was dying. to put it that way, wordpress dosed itself. (the funny thing is that it did not first use a head first, to see what kind of link this is, but starts with a get to first download the whole thing. after downloading all links and images, it uses head on them.)
anyway. i don’t know at the moment what to do against that.
but another annoying thing is that the blog is loading rather slow. i also decided to see what is causing this. well, it turns out that the old main page was doing 298 sql queries. after disabling role scoper, this jumped down to 34, with loading times more or less the same. but then, i disabled the tag cloud. this just saved one query, but reduced the page generation time from around 10 to 2 seconds. wow. enabling role scoper again (i really need that one), i now have a bit less than 50 queries with maybe 4-5 seconds of page creation time.
well, still far from optimal, but already faster.

posted in: daily life thoughts www

i was thinking on using latex in maybe some blog entries, maybe here or maybe somewhere else. so i decided to see what existing plugins there are. after a bit of searching, i stumbled over wp-latex, which is apparently also used by unfortunately, it has a kind of clumsy syntax (“$latex formula$” instead of simply “$formula$”). and it has no support for display style formulae, i.e. something centered in its own line, as opposed to inline formulae which try to fit neatly into the text.

so i tried to fix that. and it worked out, and i can still use a “normal” $ by appending a blackslash in front of it. well, euler's identity is e^{i \pi} + 1 = 0, as simple as that. if you want to see something more complicated:

let K be a number field or an algebraic function field. then, we have the following commutative diagram with exact rows and columns:

\xymatrix{ & 0 \ar[d] & 0 \ar[d] & 0 \ar[d] & \\ 0 \ar[r] & \calO^* / k^* \ar[r] \ar[d] & \Div^0_\infty(K) \ar[r] \ar[d] & T \ar[r] \ar[d] & 0 \\ 0 \ar[r] & K^* / k^* \ar[r] \ar[d] & \Div^0(K) \ar[r] \ar[d] & \Pic^0(K) \ar[r] \ar[d] & 0 \\ 0 \ar[r] & K^* / \calO^* \ar[r] \ar[d] & \Id(\calO) \ar[r] \ar[d] & \Pic(\calO) \ar[r] \ar[d] & 0 \\ & 0 & H \ar@{=}[r] \ar[d] & H \ar[d] & \\ & & 0 & 0 & }

here, T simply denotes the cokernel of the map \calO^* \to \Div^0_\infty(K) which assigns to every unit \varepsilon \in \calO^* its principal divisor (\varepsilon); in particular, T \cong \Div^0_\infty(K) / (\Princ(K) \cap \Div^0_\infty(K)). finally, H denotes the cokernel of the degree map \Div(K) \to \G, where in the number field case, \G = \R, and in the function field case, \G = \Z.

this is written as follows:

 1 let \$K\$ be a number field or an algebraic function field. then,
 2 we have the following commutative diagram with exact rows and 
 3 columns: 
 4 \$\$\xymatrix{ & 0 \ar[d] & 0 \ar[d] & 0 \ar[d] & \\ 0 \ar[r] & 
 5 \calO^*  / k^* \ar[r] \ar[d] & \Div^0_\infty(K) \ar[r] \ar[d] & 
 6 T \ar[r] \ar[d] & 0 \\ 0 \ar[r] & K^* / k^* \ar[r] \ar[d] & 
 7 \Div^0(K) \ar[r] \ar[d] & \Pic^0(K) \ar[r] \ar[d] & 0 \\ 0 \ar[r]
 8 & K^* / \calO^* \ar[r] \ar[d] & \Id(\calO) \ar[r] \ar[d] & 
 9 \Pic(\calO) \ar[r] \ar[d] & 0 \\ & 0 & H \ar@{=}[r] \ar[d] & H 
10 \ar[d] & \\ & & 0 & 0 & }\$\$
11 here, \$T\$ simply denotes the cokernel of the map \$\calO^* \to
12 \Div^0_\infty(K)\$ which assigns to every unit \$\varepsilon \in 
13 \calO^*\$ its principal divisor \$(\varepsilon)\$; in particular, 
14 \$T \cong \Div^0_\infty(K) / (\Princ(K) \cap \Div^0_\infty(K))\$. 
15 finally, \$H\$ denotes the cokernel of the degree map \$\Div(K) \to 
16 \G\$, where in the number field case, \$\G = \R\$, and in the 
17 function field case, \$\G = \Z\$.

note that this example also shows a problem: namely, the vertical alignment of the inline formulae sucks bigtime. let's see how to fix this...

posted in: math www

there was a new version of wordpress out, so i (finally) upgraded. the layout of the admin area completely changed; i already heard about that before. i don’t know if it’s better or worse than the old one, but i stumbled over one thing which is really annoying: in case you write private articles (like me) to ensure that in case the role scoper plugin stops working (or is simply disabled due to upgrades), nobody can see the private stuff (instead of everyone), you will find out that the new version of wordpress automatically publishes articles as soon as the visibility is set to private! this is pretty annoying, as i usually do that as one of the first things before writing (most of) the post itself.
another thing which got worse is the size of the tags field (for the simple tags plugin), which now resides in the right (narrow) column. before, it was prominently seated directly below the area where the post content itself is written (which is rather wide). as i often use a long list of tags, this makes things more confusing than they have to be.

posted in: www