Beiträge von codestyling

    Allerdings braucht WP 2.5 in der wp-config.php einen Eintrag, den deine alte Datei mit Sicherheit nicht hat:

    PHP
    // Ändere den SECRET_KEY in einen eindeutigen Ausdruck. Du brauchst dich später
    // nicht mehr daran erinnern, also mache ihn am besten möglichst lang und kompliziert.
    // Auf der Seite https://www.grc.com/passwords.htm kannst du dir einen Ausdruck generieren lassen.
    define('SECRET_KEY', 'bla bla bla .......'); // Trage hier einen eindeutigen Ausdruck ein.

    Bitte vergleiche die wp-config-sample.php mit deiner alten wp-config.php und ergänze das, was in deiner alten fehlt.

    WP 2.3.3. hatte den languages Ordner unter /wp-includes/ aber in WP 2.5 gehört der in /wp-content/.

    Falls du eine WP 2.5 DE installiert hast, könnte es sein, das du jetzt 2 hast, einen dort wo ihn 2.3.3. hatte und einen dort, wo ihn 2.5 sucht.

    Möglicherweise nimmt WP die alte und hat dann nicht für alles einen Text.

    Also, laut Überprüfung ist deine Weiterleitung falsch weil temporär:
    Status=Moved Temporarily - 302
    Ich würde das aus dem Confixx wieder rausnehmen und statt dessen die .htaccess im Grundverzeichnis ändern (dort wo deine wp-config.php liegt).
    Mach bitte vorher eine Sicherheitskopie und dann bearbeite sie, bis sie so aussieht:

    Das muß aber dein Problem noch nicht lösen (kann es aber), sondern hilft erstmal den Suchmachinen.

    Ergänzung:

    Hast du im Admin Menü unter Einstellungen -> Allgemein auch folgendes mit geändert ?
    WordPress-Adresse (URL):

    Code
    http://www.markus1803.de

    Blog-Adresse (URL):

    Code
    http://www.markus1803.de

    NextGen Gallery Plugin benutzt jQuery (/nextgen-gallery/admin/js/jquery.js) in der Version

    Code
    /*
     * jQuery 1.2.2 - New Wave Javascript
     *
     * Copyright (c) 2007 John Resig (jquery.com)
     * Dual licensed under the MIT (MIT-LICENSE.txt)
     * and GPL (GPL-LICENSE.txt) licenses.
     *
     * $Date: 2008-01-14 17:56:07 -0500 (Mon, 14 Jan 2008) $
     * $Rev: 4454 $
     */

    ebenso wie die Admin Oberfläche (wp-includes/js/jquery/jquery.js) aber diese mit Version

    Code
    /*
     * jQuery 1.2.3 - New Wave Javascript
     *
     * Copyright (c) 2008 John Resig (jquery.com)
     * Dual licensed under the MIT (MIT-LICENSE.txt)
     * and GPL (GPL-LICENSE.txt) licenses.
     *
     * $Date: 2008-02-06 00:21:25 -0500 (Wed, 06 Feb 2008) $
     * $Rev: 4663 $
     */

    Wenn also beide geladen werden in der Admin GUI von WP, ist das nicht "gesund". Da WP die neuere braucht, kann es sein, das die ältere von nextgen die neuere "überschreibt" und somit geht zwar nextgen aber TinyMCE nicht mehr.
    Frag bitte beim Autor nach, ob er das auch in einer zu WP passenden jQuery.js Version bereitstellen kann.


    OS: Linux (Linux server114 2.6.13-15.18-default #1 Tue Oct 2 17:36:20 UTC 2007 i686)


    Da ist der beste Ansprechpartner wohl RapidShare selbst.
    Wenn man aber bedenkt, das die englische Version kein *.mo File braucht, weil ja alles schon im PHP code drin steht, wird auch gettext nicht benutzt.
    Erst wenn man ein Language File braucht, muß auch gettext benutzt werden.
    Und für das gettext Modul gibt es einige Bugbeschreibungen, die sagen, das es zu Segmentation Faults kommen kann und somit zu Crash.

    Das müsste eine weiße Seite bringen, also Hoster fragen.

    Selbst wenn ich den nachträglich ändere, kann ich mich einloggen.
    Aber Achtung, es gibt 2 Stellen im WP, wo man den Key eingeben muß, obwohl nur eine bekannt ist:

    1. wp-config.php (dürfte bekannt sein)
    2. wp-settings.php (ist nirgends dokumentiert)

    in wp-settings.php findet man:

    PHP
    /**
     * Should be exactly the same as the default value of SECRET_KEY in wp-config-sample.php
     * @since 2.5
     */
    $wp_default_secret_key = 'bla bla...';

    Der sollte ebenfalls angepasst werden. Risiken und Nebenwirkungen, wenn man's nicht macht, hab ich noch nicht testen können.

    Mod.: Bitte die Code-Auszeichnungen des Forums benutzen! Danke!

    Das sieht ganz danach aus, als ob dein wp-admin Ordner nicht korrekt ist.
    In einer Original WP 2.5 (DE) kommt documentation_link() nur 1 mal vor und wird nirgends ein 2. Mal definiert. Auch aufgerufen wird's nirgends.

    Kannst du bitte folgendes mit einem Original WP DE 2.5 nochmal machen:
    - den wp-admin Ordner löschen
    - den wp-includes Ordner löschen
    - im Hauptordner bis auf .htaccess und wp-config.php alles löschen
    - wp-content nicht anfassen :-D

    Danach den wp-admin wieder vom Original hochladen.
    Dann den wp-includes wieder hochladen.
    Dann im Hauptordner alle Dateien hochladen, die da hin gehören.

    und dann /wp-admin/updgrade.php aufrufen.

    Hi,
    ich bin gerade dabei, selbst ein WP 2.5 Maintenance Plugin zu schreiben, denn alles, was ich finden konnte, macht nicht das, was ich will.
    Also das sind die Sachen, die ich mir vorstelle, Wünsche erbeten:
    - Konfiguration per Oberfläche
    - nutzerspezifische Erlaubnis vergeben
    - ggf. per IP durchlassen
    - ggf. per UserAgent durchlassen (kann ja meinem Browser einen Maintenance UserAgent geben :-D )
    - korrekter HTTP redirect mit Statuscode, damit auch Google und Co. bescheid weiß.
    - temporäre .htaccess Umleitungsmöglichkeiten für Mirror Systeme.

    So im Groben wars das, wenn's fertig ist, kündige ich das an und stell es bereit.

    Dann wäre ich für die "harte" Tour und würde Fehlermeldungen ausgeben lassen. In die /wp-admin/upgrade.php mal die roten Zeilen einfügen:

    PHP
    <?php
    [COLOR=Red][B]error_reporting(E_ALL);
    ini_set("display_errors",1);[/B][/COLOR]
    define('WP_INSTALLING', true);
    if (!file_exists('../wp-config.php'))
        die("Die Datei <code>wp-config.php</code> scheint nicht zu existieren. Sie wird aber ben&ouml;tigt, bevor wir anfangen k&ouml;nnen. Brauchst Du weitere Hilfe? Bei <a href='http://wordpress-deutschland.org/'>WordPress Deutschland</a> findest du eine <a href='http://wordpress-deutschland.org/installation'>deutschsprachige Anleitung</a>. Eine <a href='http://codex.wordpress.org/Editing_wp-config.php'>englischsprachige Anleitung</a> findest Du bei <a href='http://wordpress.org/'>WordPress.org</a>. Du kannst die Datei <code>wp-config.php</code> auch <a href='setup-config.php'>online erstellen</a>, das funktioniert jedoch nicht mit allen Servern. Die sicherste Methode ist es, die Datei manuell zu erstellen.</p><p><a href='setup-config.php' class='button'>Konfigurationsdatei erstellen</a>");

    ... dann müssten zumindest Fehlermeldungen, die sonst unterdrückt werden, sichtbar werden. Mal sehen, was WP damit sagt.
    Ach so, und die von Putzlowitsch vorgeschlagene zusätzliche install.php vorher wieder wegwerfen.

    Ich hab mal meine WP 2.3.3 Datenbank mit der WP 2.5 Datenbank verglichen und da gibt's Unterschiede in der wp_options Tabelle:

    Option: "widget_categories"

    WP2.3.3:

    Code
    a:2:{s:6:"number";i:1;i:1;a:4:{s:5:"count";b:0;s:12:"hierarchical";b:0;s:8:"dropdown";b:0;s:5:"title";s:0:"";}}

    WP2.5:

    Code
    a:2:{s:6:"number";i:1;i:1;b:0;}

    Da beides identische Installationen sind nur eine eben auf 2.3.3 und die andere auf 2.5, denke ich schon, das da was geändert wurde.

    Es scheint eine Fülle von Problemen mit dem suPHP Module zu geben, je nachdem, welches Apache Forum man liest.
    Das ist schwer zu sagen, woran der sich jetzt "verschluckt".
    Zumindest bekommt man die wp-config.php jetzt als weiße Seite nach deiner Rechteanpassung.

    Was mir noch einfällt:

    WP 2.3.3. hatte den languages Ordner unter /wp-includes/ aber in WP 2.5 gehört der in /wp-content/.

    Falls du eine WP 2.5 DE installiert hast, könnte es sein, das du jetzt 2 hast, einen dort wo ihn 2.3.3. hatte und einen dort, wo ihn 2.5 sucht. Kann sein, das sich suPHP daran verschluckt, denn die Admin GUI braucht nun mal Beschriftungen.

    damit ich die, die ich oben ausgeschlossen habe anderorts wieder anzeigen kann


    ...also nicht in der Sidebar ?

    Was macht das für einen Sinn, es erst rauszunehmen und dann wieder reinnehmen zu wollen mit einen 2. Widget, in dem ich dann hunderte ID's sperren muß, um die paar ausgeschlossenen nur allein zu haben ?

    Alle Einträge des Seiten Widget haben korrekte Auszeichnungen wie class="page_item page-item-2" also die Seite mit ID = 2.
    Das kann ich mit CSS alles so machen, wie ich möchte und mit JavaScript könnte ich sogar die UL in mehrere Aufteilen lassen. Wer js aus hat, bekäme dann die Liste wie CSS es macht am Stück ansonsten sieht man das js Ergebnis.

    Inhalt und Presentation sollte man trennen ...

    Also wenn ich im Browser folgendes aufrufe, muß ich eine weiße Seite bekommen:

    Code
    http://www.dumpblog.de/wp-config.php

    Statt dessen bekomme ich folgendes:

    Code
    [B]Internal Server Error[/B]
    
    
       File "/web/1/000/031/542/93916/htdocs/blog/wp-config.php" is writeable by group
         suPHP 0.6.2

    Da stimmt was mit deiner wp-config.php nicht. Die Dateirechte sind "komisch" gesetzt und dein Provider macht was nicht, was er sollte. Komisch ist nur, das der Blog selbst, der die gleiche PHP verwendet, funktioniert.

    Stell mal die Rechte der Datei auf 644. Heißt:

    Besitzer: lesen (ja) / schreiben (ja) / ausführen (nein)
    Gruppe: lesen(ja) / schreiben (nein) / ausführen (nein)
    öffentlich: lesen(ja) / schreiben (nein) / ausführen (nein)

    Das sollte Standard sein und funktionieren.

    Da beides von Javascript Bibliotheken abhängig ist, kann es zu Komplikationen kommen, wenn beide nicht mit der gleichen Bibliotheksversion arbeiten.

    Beispiel:
    bei Prototype.js sind die Versionen ab 1.6 aufwärts nicht mehr 100 % kompatibel zu den niedrigeren Versionen.
    Sollte also einer der beiden (LightBox/TinyMCE) Prototype 1.5.x benutzen der andere aber 1.6.x verwenden wollen, dann wird einer, wenn nicht beide ausfallen.


    Kannst du bitte prüfen, ob die beiden eine "gemeinsame" Datei einer Bibliothek benutzen aber in jeweils einer anderen Version ?