WordPress 2.8 announced and installed

The WordPress version running on this blog is now "2.8-beta1-11380". After the first beta has been announced, i switched the svn installation to trunk again (after having it to branches/2.7) and updated the blog.

There is a problem with gengo though: Right after upgrading i got this warning:

CODE:
  1. Warning: Invalid argument supplied for foreach() in /.../wp-includes/classes.php on line 255

The line in question looks like this:

PHP:
  1. foreach ( $GLOBALS['wp_taxonomies'] as $taxonomy => $t)

I really didn't have the time to get into this, so in order to get the blog going, i used the workaround suggested here and changed the line to:

PHP:
  1. foreach ((array) $GLOBALS['wp_taxonomies'] as $taxonomy => $t)

Convert Gray-Code to decimal/binary and back

Gray-Code is a binary code developed by Frank Gray in 1947. It is used by most absolute incremental encoders and some favor it's use for fringe projection systems that have to encode the pixel data in a series of image patterns (mostly fringes with differing widths). To convert Gray-Code from and to Decimal numbers using c++ i had to look up different approaches with varying difficulty levels. I then compiled the following algorithms, that i will be using for my own fringe projection system (keep tuned).

It's rather easy if you know how to do it. I had to find out the hard way, so here's for the rest of the world:

First the easy part: transforming a integer number dec into a Gray-code _code:

C++:
  1. void _calculateGrayCode () {
  2.     bitset<numeric_limits<int>::digits + 1> bs(dec);
  3.     bitset<numeric_limits<int>::digits + 1> gs(dec);
  4.     bitset<numeric_limits<int>::digits + 1> _code(0);
  5.     bs>>= 1;
  6.     gs ^= bs;
  7.     for (unsigned i=0; i<_code.size(); i++){
  8.         _code[i] = gs[i];
  9.         gs[i]=0;
  10.     }
  11. }

Now to the part of converting Gray-Code to binary and then decimal number: Suppose our Gray-code is inside the bitset _code.

C++:
  1. void _calculateNumber () {
  2.     bitset<numeric_limits<int>::digits + 1> gs(0);
  3.     bitset<numeric_limits<int>::digits + 1> bs(0);
  4.     for (unsigned i=0; i<_code.size(); i++){
  5.         gs[i] = _code[i];
  6.     }
  7.     bs[gs.size()-1] = gs[gs.size()-1];
  8.     for (int i=gs.size()-2; i>=0;i--){
  9.         bs[i]=bs[i+1];
  10.         bs[i]=bs[i]^gs[i];
  11.     }
  12.     _number = static_cast<int>(bs.to_ulong());
  13. }

bs holds the binary representation of the Gray-Code and _number is the decimal respresentation.

References:

Pingbacks and Trackbacks work again in WordPress

For quite some time, i had a problem getting pingbacks and trackbacks working. Receiving them wasn't a problem, but i couldn't send any. It seems, i'm not alone and no where were any answers to be found..

I think i found the problem: the function spawn_cron (/wp-includes/cron.php, 153) opens a socket to then wp-cron.php file after adding a new scheduled item. For that reason it runs the function wp_remote_post which also accepts a timeout parameter. That parameter is set to 0.01 by default. I guess these are seconds (which means these are 10 milliseconds!) and for some webservers this value is simply too small. Change that to something bigger (i'm using 0.1 or 1) and pingbacks and trackbacks should work again..

Now what about the old trackbacks and pingbacks that didn't get sent? Actually you'll simply need to write a new post and all the old unsent pings should be scheduled for sending. If you don't want to do that, you could install the plugin Wp-Crontrol where you can specify a hook to be scheduled to a specific time. Schedule the hook "do_pings" to be triggered any time soon (parameter should be empty = "[]") and it should take care of the old pingsbacks.

Finally wordpress 2.7 final

The final version of wordpress 2.7 "Coltrane" has been released. I've kept this blog up to date and switched from trunk to 2.7-branch now for fear that the stability held up until now won't be kept up. I've also updated my main blog. The only thing that is bugging me is the notice at the top of the blog telling me to upgrade to please WordPress 2.7, even though the blog is long updated.. A last-minute bug?

It's really funny at the dashboard, where it literally says "You have version 2.7. Would you like to upgrade to version 2.7?"

upgrade27

upgrade27

Anyway, the team of Automattic has again done a great job with this version. I'm totally happy with it. Thanks guys.

Lighty Development is not (!) dead

I thought it was. The forum was long abandoned. Just now i was looking for a problem i'm having with high-load combined with enabled xcache and found out they've changed from trac to redmine (have to try!). Here is the new development site.

On this happy note, i now think i could be changing soon to lighttpd 1.5.0svn. Let's see. Maybe even try an svn-version of xcache?? Any thoughts about such a transition? I know there are quite some sites already running 1.5.0, but as long as i didn't see progress on the site of lighttpd i was too afraid, that i wouldn't get any support if i changed to the unstable version.

Gengo und WordPress 2.7

Ich hatte Probleme damit, Gengo und WordPress 2.7 gemeinsam zum Laufen zu bringen und die Option zum Anhängen von Sprachkürzeln in Gengo zu aktivieren (Gengo should append language codes to permalinks automatically.), da Gengo in eine Endlos-Weiterleitungsschleife ging. Ich dachte schon, das wäre eine grundsätzliche unverträglichkeit zwischen den beiden und schaltete deswegen diese Option aus, was dazu führte, dass sämtliche Links nicht mehr funktionierten. Joshreisner schlägt dagegen im Forum auf wordpress.org vor, die Permalink-Strukturen neu zu speichern.

Und tatsächlich geht man auf Einstellungen>Permalinks und speichert einfach die bereits gespeicherte Permalink-Struktur neu, dann geht das Problem der Endlosschleifen weg! Es hat wahrscheinlich damit zu tun, dass Gengo beim Speichern der Permalinks selbst eine Aktion durchführt.

Gengo and WordPress 2.7

I had an issue with gengo getting into an endless redirect loop once i activate the option "Gengo should append language codes to permalinks automatically.". I thought this was an issue of gengo-compatibility and deactivated the option making many links unusable. Now i just found this thread over at wordpress.org where joshreisner suggests simply saving the permalink structure again:

i just upgraded to 2.6.1 using the automatic updater and it caused a redirect loop on my site. whenever i would visit it it would be like "the address /en/en/en/en/en/en/en etc was in a repeat loop that would never be resolved"

i pulled my hair out for a minute but then figured it out. just go to the permalinks settings page (in wp, not gengo) and hit save. no change, just save. that fixed the problem!

Thanks. This works. It seems gengo uses some action that is being pulled once the permalink structure is saved..

WordPress 2.7 beta soon

Quick note: Version 2.7 of WordPress is coming soon. Ryan has announced the feature freeze. This blog has been running the trunk-version that has been leading to 2.7 for quite a while now. Part of it is to be on top of things, but also to be able to test wp-stattraq with 2.7. And: it still works!

Oh! And the interface doesn't look like this yet:

but like this:

wordpress27

Using nanocms to create a simple site with news

For a client of mine i've been looking for a way to host his very simple and small site. The site (which can be found here in its old outfit) consists of some rather static pages, two formulas, which have to be sent by email and a news section that is split into two categories (events and tours). Both news categories land in a collective archive after a specific date.

Until now, the site has been using a selfmade content management system, which reads custom files in some directories. Every time i wanted to change the content of an event article, add a new one or move it to the archive i had to manually change the files. You have to have in mind, that the customer asked for a rather minimalistic server hosting solution and i didn't see it as necessary for him to have a database in the hosting package. The problem is that most content management systems are in need of a database of some sort (mostly mysql). Yes i am aware of plugins for cmss that can do the job. But mostly the systems are too complicated to setup for this simple site..

In come nanocms. Nanocms is being developed by Kalyan Chakravarthy who runs his own blog over at kalyanchakravarthy.net (last update about nanocms). From the description of the project:

Nano CMS is the tinyest CMS you can find around...:)
The user interface and the functionality are very very simple and easy to use.
NanoCMS is filebased, so no database blah,. Easy to install

Through this CMS you can create pages without actually touching any code.
You can manage website pages very easily and the links in the sidebar are generated automatically...

Indeed nanocms is really small and well written for that. The main functionality consists of creating pages, which are then stored in distinct files in a specific folder. The only way to sort the pages on the site is to include them in different categories (each page can be a member in different categories) and then using those categories for displaying menus. There is no way of specifying a hierarchy for the pages. The sort order of the pages inside each category though can be changed independently.

Now, this functionality doesn't provide exactly what i needed, since i wanted some "pages" (/posts) to be shown on the same webpage - like a blog. Also, i needed submenus to allow the navigation the client was asking for.

So, this is what i did..

To extend the functionality of nanocms i created "customfunctions.php" with the following two functions:

PHP:
  1. <?php
  2.  
  3. function show_contents($cat){
  4.     global $cap;
  5.     $itemlist = get_links_array($cat);
  6.     foreach( $itemlist as $slug=>$title ){
  7.         show_content($slug);
  8.         echo '<hr />';
  9.     }
  10. }
  11.  
  12. function show_content($slug){
  13.     $contentFile = pageDataDir( $slug );
  14.     if( file_exists( $contentFile ) ) {
  15.         runTweak( 'slug_load_before' );
  16.         require_once( $contentFile );
  17.         runTweak( 'slug_load_after' );
  18.     }
  19.     else {
  20.         header("HTTP/1.0 404 Not Found");
  21.         echo "404 : File Requested was Not Found";
  22.     }
  23. }
  24. ?>

The function "show_contents" is a near-copy of the native function "show_links" which shows all the links to the pages inside a category. "show_content" is a near-copy of "show_content_slug" with the only difference, that "show_content_slug" doesn't accept any argument and gets the page slug from the global variable $cap.

With those two functions i'm now able to show a page inside another page (which i use to display the "Kontakt"-page under the welcome message) and i'm able to show the content of a category.

So, the content of "Aktuelles" becomes the following small script:

PHP:
  1. <h2>Aktuelles</h2>
  2.  
  3. <?php show_contents('aktuelles'); ?>

And here is a link to the site, as i proposed it to the client: www.campuscultur.de/nano/

Gengo and woopra plugin

I just found out, that there is a problem with running the woopra wordpress plugin together with gengo. Gengo is the multilingual plugin running in the background of this blog. Woopra is an external statistics program that has a nice wordpress plugin (which by the way is looking for some translation work itself).

Anyway, when i activate the woopra-plugin it says

Fatal error: Call to a member function wp_rewrite_rules() on a non-object in /var/www/oan/htdocs/wp-includes/classes.php on line 145

First, i thought it's a compatibility thing with wordpress 2.7 (right now: "2.7-almost-beta), but it seems to work when i deactivate gengo. I found this quote on the gengo-blog which i am quoting since the site has some database problems:

If that happens, the plugin you just activated has been written incorrectly. It is trying to set its language too early, before Gengo has loaded. The solution is an easy one - the call to load_plugin_textdomain() in the plugin must be moved so that it is run on the ‘init’ hook. Do your plugin author a favour - drop them an email letting them know the problem and see if they’ll fix it - many authors don’t know that this is even a problem! Make sure you’re polite when you do, though. From personal experience, I can tell you it’s not pleasant to receive an angry email from a stranger, demanding that you fix something that you’ve released for free.

Hope, someone from over at woopra can change the code accordingly. Meanwhile i'm relying on the stattraq-plugin..