IT Berater – Java, J2EE, WebSphere Portal, Lotus Domino
RSS icon Home icon
  • WebSphere Portal 6.1.0.0 does not support installation on a managed node

    1 Star2 Stars3 Stars4 Stars5 Stars
    Loading...
    Posted on 19 September 2008 Sebastian Thomschke*/?> 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

    1 Star2 Stars3 Stars4 Stars5 Stars
    Loading...
    Posted on 13 September 2008 Sebastian Thomschke*/?> 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 in meinem Fall keine der skizzierten Lösungsansätze.
    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));