Sebastian Thomschke

WebSphere Portal 6.1.0.0 does not support installation on a managed node

 Loading ...

Posted on 19 September 2008 No comments

With WebSphere Portal 5.1 a new deployment option was introduced that allowed the installation of WP onto an existing node managed by a deployment manager. AFAIK the main reason for this new option was to simplify the cluster setup procedure.

Both options, installing WP standalone and federating it into a cell afterwards as well as installing it on an already managed node have different pros and cons each. In WP 6.0 the installation onto a managed node was even mandatory to enable WebSphere Process Server integration.

Surprisingly WP6.1.0.0 does not support the installation on a managed node anymore. All nodes of a cluster need to be installed as standalone systems first and then be federated into a WebSphere cell.

For WP 6.0 the installation procedure is described here. The 6.1 info center does not mention this procedure anymore and it no, it was not dropped accidentally.

[Behoben] Leere Seiten mit WordPress 2.6.x

 Loading ...

Posted on 13 September 2008 2 comments

Nach dem Upgrade auf WordPress 2.6 kam es immer wieder vor das im Browser leere Seiten angezeigt wurden. Eine Seitenaktualisierung mittels STRG+F5 behob in den meisten Fällen das Problem. Heute habe ich meinen Blog auf WordPress 2.6.2 aktualisiert und danach war es nicht mehr möglich die Verwaltungsseite für Plug-ins aufzurufen. Egal was ich probierte, die Seite blieb im Browser leer.
Auf der Suche nach einer möglichen Lösung im Internet bin ich auf verschiedene Diskussionen über dieses scheinbar allgemein bekannte Phänomen gestossen. Leider half keine der skizzierten Lösungsansätze in meinem Fall.
Daher habe ich mich einmal mehr in die Untiefen des WordPress Codes gestürzt und die – für meinen Fall – entscheidenden Programmzeilen lokalisieren können. Das Problem wird durch mehrere (object) Casts in der Datei strong>wp-includes/taxonomy.php verursacht, welche Arrays in Objekte transformieren:

$wp_taxonomies['category'] = (object) array('name' => 'category', 'object_type' => 'post', 'hierarchical' => true, 'update_count_callback' => '_update_post_term_count');
$wp_taxonomies['post_tag'] = (object) array('name' => 'post_tag', 'object_type' => 'post', 'hierarchical' => false, 'update_count_callback' => '_update_post_term_count');
$wp_taxonomies['link_category'] = (object) array('name' => 'link_category', 'object_type' => 'link', 'hierarchical' => false);

Da weder Fehlermeldungen im Browser noch in den Log Dateien erscheinen habe ich leider keine Idee wieso diese Casts zum Abbruch der Skriptausführung führen. Die installierte PHP Version entspricht der aktuellen stabilen 5.x Version und sollte daher eigentlich nicht die Ursache des Problems sein.
Um das Problem zu umgehen habe ich eine Methode eingeführt die ebenfalls Arrays in Objekte transformieren kann, welche jedoch nicht auf der PHP Objekt Casting Funktion beruht.

function arr2obj($arr) {
	foreach ($arr as $k => $v) $obj -> {$k} = $v;
	return $obj;
}

$wp_taxonomies['category'] = arr2obj(array('name' => 'category', 'object_type' => 'post', 'hierarchical' => true, 'update_count_callback' => '_update_post_term_count'));
$wp_taxonomies['post_tag'] = arr2obj(array('name' => 'post_tag', 'object_type' => 'post', 'hierarchical' => false, 'update_count_callback' => '_update_post_term_count'));
$wp_taxonomies['link_category'] = arr2obj(array('name' => 'link_category', 'object_type' => 'link', 'hierarchical' => false));

Peter Nalitch – Guitar

 Loading ...

Posted on 12 July 2008 No comments

Vor ein paar Wochen waren zwei russische IT Berater in unserem Büro. Leider wurde mir von einem ein – mir bis dahin verborgen gebliebener Teil – der russichen Kultur näher gebracht: Das Lied “Guitar” von Peter Nalitch. Der Berater meinte, das Lied fräße sich in sein Gehirn. Ich hätte es nicht besser ausdrücken können. Was ist die Steigerungsform von Ohrwurm?

Wer es noch nicht kennt, kann es nun geniessen:

Die originale Version

Read the rest of this entry »

Sun JDK5/6 compilers broken when linking overloaded methods with variable arguments

(5 votes)

 Loading ...

Posted on 16 May 2008 1 comment

We are currently switching the build system of OVal from custom Ant scripts to Maven 2. During that process we accidentally compiled the project using the Java compiler of the Sun JDK 5 instead of the AspectJ compiler. Surprisingly javac did not complain about the missing aspect class files. Instead it already aborted while compiling an ordinary Java class which only referenced other non-AspectJ related classes. This is the original error message:

[INFO] [compiler:compile]
[INFO] Compiling 180 source files to C:\projects\oval\src\trunk\target\classes
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Compilation failure
C:\projects\oval\src\trunk\src\main\java\net\sf\oval\Validator.java:[373,58]
addMethodParameterChecks(java.lang.reflect.Method,int,java.lang.Object)
has private access in net.sf.oval.internal.ClassChecks 

There exist multiple methods named addMethodParameterChecks in the class ClassChecks with different signatures. The problem is that javac tries to link against the wrong method when compiling the class calling one of the methods.

Read the rest of this entry »

DD Sitemap Generator Plug-in und mehrsprachige Blogs

(2 votes)

 Loading ...

Posted on 1 May 2008 3 comments

Um ein zweisprachiges Blog mit WordPress betreiben zu können, verwende ich das Language Switcher Plug-in. Dieses erlaubt es, durch die Verwendung spezieller Tags in den üblichen Titel und Inhaltsfeldern zu deklarieren, welche Teile in welcher Sprache geschrieben sind (z.B. “[ lang_en]Hello World[ /lang_en][ lang_de]Hallo Welt[ /lang_de]“). Wenn ein solcher Beitrag im Browser angezeigt wird entfernt das Plug-in diese Tags sowie die Inhalte in den nichtausgewählten Sprachen.

Ich verwende das DD Sitemap Generator Plug-in für WordPress zur automatischen Erzeugung einer Sitemap basierend auf den Beiträge und Kategorien meines Blogs. Auf dieser generierten Sitemap werden jedoch bei den Kategorienamen und Beitragstiteln die Übersetzungen in allen Sprachen auf einmal angezeigt inklusive der speziellen Tags.

Um dies zu beheben habe ich mich etwas im Code von WordPress und dem Language Switcher Plug-in umgesehen. Das Language Switcher Plug-in entfernt die Tags und überflüssigen Übersetzungen indem es sich der Filters API bedient – eine Art ereignisbasierter RückrufmMechanismus. Plug-ins können Ihr Interesse in bestimmten Textfilterereignissen signalisieren indem sie die Funktion add_filter(the_event_id, the_name_of_a_function_to_callback) unter Angabe der ID eines Filterereignisses und des Namens der aufzurufenden Funktion im Falle des Auftretens des entsprechenden Ereignis. Neben dem Registrieren für Filterereignisse können Plug-ins auch selbst solche Textfilterereignisse auslösen indem sie Funktion apply_filters(the_event_id, the_text_to_be_filtered) unter Angabe einer ID des Filterereignisses und des zu filternden Textes aufrufen. WordPress führt dann alle für dieses Ereignis registrier Filtermethoden auf dem übergebenen Text aus und die apply_filters Funktion gibt als Ergebnis den “gefilterten” text zurück. Wenn WordPress beispielsweise die Titel von Beiträgen oder Seiten darstellt löst es ein Filterereignis mit der ID “the_title” aus. Dies ermöglicht Plug-ins den Titel zu prozessieren/modifizieren bevor er dargestellt wird. Das Language Switcher Plug-in registriert sich daher selbst für dieses und eine Reihe anderer Filterereignisse um mehrsprachig eingegebene Texte vor der Darstellung um die Sprachtags und die nicht relevanten Übersetzungen zu entfernen.

Leider löst das DD Sitemap Generator Plug-in die entsprechenden Filterereignisse bei der Erstellung der Sitemap nicht aus. Daher ist auch das Language Switcher Plug-in nicht in der Lage die Kategorienamen und Beitragstitel zu bearbeiten.

Um das Problem zu lösen habe ich daher den Quellcode des DD Sitemap Generator Plug-in analysiert und die fehlenden apply_filters Aufrufe an den entsprechenden Stellen hinzugefügt. Wer ebenfalls von diesem Problem betroffen ist kann sich wie folgt behelfen:

1. Die Datei <wordpress_root>/wp-content/plugins/sitemap-generator/sitemap-generator.php (oder <wordpress_root>/wp-content/plugins/dd-sitemap-gen/dd-sitemap-gen.php) in einem Editor öffnen
2. Den folgenden Text lokalisieren
      $tmp_array['title'] = $pages[$k]->post_title;
   und ersetzen durch
      $tmp_array['title'] = apply_filters(‘the_title’, $pages[$k]->post_title);
3. Den folgenden Text lokalisieren
      $tmp_array['title'] = $cat_data[$c]['cat_name'];
   und ersetzen durch
      $tmp_array['title'] = apply_filters(‘the_category’, $cat_data[$c]['cat_name']);
4. Den folgenden Text lokalisieren
      $tmp_array['title'] = $posts[$k]->post_title;
   und ersetzen durch
      $tmp_array['title'] = apply_filters(‘the_title’, $posts[$k]->post_title);
5. Die Änderungen speichern. Das sollte es gewesen sein.

Mit diesem Verfahren kann man auch andere Plug-ins für ein gutes Zusammenspiel mit dem Language Switcher Plug-in korrigieren.

[Behoben] WordPress 2.5 One-Click Plug-in Upgrades – Could not create directory

(5 votes)

 Loading ...

Posted on 25 April 2008 37 comments

Vor einigen Tagen habe ich meine WordPress Installation auf das neue 2.5 Release aktualisiert. Aufgrund meiner Trägheit im Hinblick auf administrative Tätigkeiten wollte ich natürlich auch die neue on-click plug-in upgrade Funktion nutzen um ein paar Plug-ins zu aktualisieren. Allerdings scheiterten alle meine Versuche die Funktion zu nutzen mit der ziemlich nutzlosen Fehlermeldung “Could not create directory”. Daher begab ich mich auf die übliche Netzsuche und bin relativ schnell auf einige Beiträge gestossen, welche die Ursache in unzureichenden Berechtigungen auf bestimmte Verzeichnisse ausmachten. Das manuelle Anlegen des Verzeichnisses /wp-content/upgrade und das “chmodden” auf 777 dieses selben sowie der Plug-in Verzeichnisse würden das Problem lösen. Leider nicht bei mir. Daher blieb mir nichts weiter übrig als die Ärmel hochzukrempeln und WordPress zu debuggen…

Lange Rede, kurzer Sinn, ich bin schließlich auf den PHP Bug Report #42739 mkdir doesn’t like a trailing slash when safe_mode is enabled gestossen und es zeigte sich, daß dies genau das Problem war, welches sich mir auf meinem Hosting Account entgegenstellte. Die PHP Option safe_mode ist dort aktiviert und WordPress versucht vergeblich mit Schrägstrich endende Verzeichnissepfade anzulegen (z.B. /htdocs/wp-content/upgrade/the-plugin/).

Nachdem mir der Grund also bekannt war, konnte ich einen Workaround entwickeln und endlich den on-click plug-in updater nutzen. Für alle die das gleiche Problem haben, hier meine Lösung:

1. Die Datei <wp_root>/wp_admin/includes/class-wp-filesystem-direct.php lokalisieren und in einem Editor öffnen
2. Nach “function mkdir” in der Datei suchen
3. Die nachfolgenden Codezeilen in die Methode einfügen. 

   function mkdir($path,$chmod=false,$chown=false,$chgrp=false){
   	if( ! $chmod)
   		$chmod = $this->permission;
   
   	// workaround for http://bugs.php.net/bug.php?id=42739 starts here
   	if(ini_get('safe_mode') && substr($path, -1) == '/')
   	{
   		$path = substr($path, 0, -1);
   	}
   	// workaround for http://bugs.php.net/bug.php?id=42739 ends here
   
   	if( !@mkdir($path,$chmod) )
   		return false;
   	if( $chown )
   		$this->chown($path,$chown);
   	if( $chgrp )
   		$this->chgrp($path,$chgrp);
   	return true;
   }

4. Mit der Ein-Klick-Aktualisierung beginnen!

Nachtrag:

1. Die Änderung funktioniert auch mit WordPress 2.5.1
2. Falls diese Änderung nicht zum gewünschten Erfolg führen, kann der Fehler noch eine zweite Ursache haben. Daher sollten die Berechtigungen des Verzeichnis /wp-content/upgrade/ und dessen Unterverzeichnisse überprüft und gegebenenfalls per chmod auf 777 gesetzt werden. Falls das upgrade Verzeichnis gar nicht existieren sollte, reicht es vielleicht schon dieses einfach manuell anzulegen.

Nachtrag 2:

1. Falls sich das Problem weiter besteht sollte geprüft werden ob das Plug-in AskApache Password Protect installiert ist.
2. Wenn ja, kann es helfen dieses vor dem Aktualisieren anderer Plug-ins zu deaktivieren.