Beiträge von Ammaletu

    Um es noch mal umzuformulieren: Wenn Du Code gefunden hast in WP, der so nicht valides HTML oder CSS ist, dann sollte das auf jeden Fall behoben werden, keine Frage. Wenn es dagegen darum geht, dass z.B. das Theme etwas nutzt, was der FF 2 nur noch nicht versteht, dann wäre die Frage, ob es sich lohnt, das zu beheben/umgehen. Werden dann die Twenty-Ten-Entwickler entscheiden müssen. Melden kann man es so oder so. Ich nehme halt an, dass mit FF 2 nicht exzessiv getestet wurde.

    Also für 1.: Spricht etwas gegen ein simples Text-Widget? Oder brauchst Du irgendwo anders auch noch ein Archiv der Kurzmitteilungen? Apropos Kurzmitteilung, eine andere Variante wäre natürlich ein Twitter-Konto und da dann die letzten x Meldungen in der Sidebar anzeigen.

    2. bis 4 muss ich passen, sorry.

    5.: Meinst Du das Plugin "Excerpt Reloaded" oder so ähnlich? Müsste ich mir näher anschauen, aber wirkt das nicht überall, wo Du the_excerpt() statt the_content() im Theme stehen hast?

    Da werden wohl JS-Dateien fehlen. Hast Du das automatische Upgrade genutzt? Du könntest mit einem Tool wie dem Firefox-AddOn "LiveHttpHeaders" mal schauen, ob Dateien nicht gefunden werden. Oder Du lädst per FTP einfach den wp-admin-Ordner mal auf Verdacht neu hoch.

    Im Theme fehlt übrigens auch eine JS-Datei: contentslider.js wird nicht gefunden (404).

    Das WP direkt in der Datenbank ändern wird nur gehen, wenn Du es auch korrekt verschlüsselst. Geht also eher nicht. Wieso klappt denn die PW-Vergessen-Funktion nicht bzw. wie äußert sich das? Wenn es an der Mail-Adresse liegt -- die kannst Du ja direkt in der DB ändern.

    P.S.: Login sperren -- das ist keine Standard-WP-Funktion, oder? Der Count dafür muss eigentlich ja auch in der DB stehen. Kannst Du den da nicht wieder runtersetzen auf 0? Steht eventuell in der usermeta-Tabelle, denke ich. Oder falls das über ein Plugin geht, probier mal, das Plugin zu deaktivieren. Eventuell ist die Sperrung auch nur temporär, alles andere würde ja nicht viel Sinn machen.

    Hm, ich nehme an, dass trac.wordpress.org dafür die richtige Anlaufstelle ist. Das Theme ist ja ein Teil des offiziellen WP-Packages. Ich bin aber nicht sicher, ob das hohe Priorität hat, da FF-Nutzer ja eigentlich doch mehrheitlich schnell updaten. Kommt drauf an, was die Ursache für die Probleme ist, schätze ich mal. Aber melde es ruhig, wenn sich noch nichts entsprechendes im Trac findet.

    Um Deine Frage noch zu beantworten: Den wp-admin-Ordner von z.B. WP 2.9 in ein WP 3.0 einspielen wird mit ziemlicher Sicherheit nicht gut gehen. Das kannst Du nur mit exakt der gleichen Version machen, aber dann würde es auch nur Sinn machen, wenn Du vermutest, dass Dateien kaputt sind oder fehlen.

    Plugin-Inkompatibilität: Da hat ein Plugin ein neueres MooTools integriert, oder? Kann euch dann in Zukunft aber immer wieder passieren. Gut wäre es natürlich, wenn der Theme-Autor das mal auf die aktuelle Version aktualisieren könnte und dann auch wp_enqueue_script nutzen würde.

    Bist Du sicher, dass Du das willst? Da kann dann ja sonst was verlinkt werden, und irgendwie machst Du Dir diese Links ja schon zu eigen, wenn Du sie auf Deiner Webseite setzt, Disclaimer hin oder her. Wenn Du die nicht mal oberflächlich prüfst vor dem Setzen, macht man es Abmahnern dann nicht relativ leicht?! Nur so ein Gedanke... ;)

    Ein Tool dafür kenne ich im Moment auch nicht, aber wenn dann würde das vielleicht von Seiten wie Google oder Technorati kommen. Ist mir aber keins bekannt.

    Die Slideshow nutzt scheinbar die JavaScript-Library MooTools. Dabei tritt ein JavaScript-Fehler auf (sollte Dir Dein Browser anzeigen). ... Und wenn man mal etwas in den Quelltext schaut wird auch klar wieso: Die Slideshow nutzt MooTools 1.11. Es ist aber vorher auch noch mal MooTools 1.2 eingebunden, wenn ich das nicht ganz falsch sehe. Und wenn Du Pech hast beißt sich das obendrin auch noch mit jQuery, das weiß ich nicht genau.

    Generell sollte jede JS-Library nur einmal eingebunden sein, dafür gibt es in WP-Theme die enque_script-Methode. So oder so müsste sich da jemand mal das Theme näher anschauen, das haut so nicht hin.

    Ist aber nicht eine Browser-Sache, oder? Hast Du es mal mit einem anderen Browser probiert? Ansonsten müsstest Du das theoretisch umgehen können, indem Du die URl verfrmdest, zumindest fürs Kontaktformular des Providers. Pack [REMOVE] oder so in die Mitte.

    Du könntest mal in eine php-info-Ausgabe schauen, ob auf Deinem Server etwas wie Suhosin läuft, das nach verdächtigen Aktionen Ausschau hält. Vielleicht ähnelt diese URL ja zufällig einem Hackversuch und wird deshalb blockiert. Wäre jetzt so auf Anhieb meine erste Idee. ;)

    Tja, prinzipiell ist das nicht falsch gedacht. wp-config.php wiederherstellen, den wp-content-Ordner und die .htaccess (alternativ im Backend die Permalinks neu speichern, so sie denn verwendet werden). Die Datenbank sollte dabei ja unverändert bleiben, was natürlich auch heißt, dass ggf. Deine Probleme nach wie vor in der Datenbank stecken (z.B. kaputte Optionen in der Optionstabelle).

    Was genau heißt denn "es tut sich gar nichts"? Kommt eine Fehlermeldung? Nur eine weiße Seite? Geht das Backend, wenn Du es direkt aufrufst (/wp-admin an die URl hängen, ggf. mit passendem Verzeichnis)? Hast Du beim Neuhochladen die gleiche WP-Version hochgeladen, die vorher installiert war? Falls das gleichzeitig ein Update werden sollte, musst Du die upgrade.php aufrufen (und vorher Datenbank-Backup ziehen!).

    Ich glaube nicht, dass Du mit dem Ansatz glücklich wirst. Du umgehst damit ja effektiv WordPress' eigenes Permalink- und Themesystem, indem Du eine Themedatei über die .htaccess direkt aufrufst. Das kannst Du natürlich machen, aber dann wurde WordPress selber gar nicht geladen und Du wirst auf der Seite nicht viel sehen.

    Sinnvoller wäre es, WPs Permalinkstruktur entsprechend anzupassen und das dann über die normalen Themedateien umzusetzen, je nachdem was ein Stadtteil ist (page.php für Seiten z.B.).

    Hm, also die Methode ist schon mal insofern nicht richtig, als is_page nur prüft, ob es sich um eine Page handelt. Wenn Du die IDs also korrekt ermittelt hast, müsste das Widget immer zu sehen sein. ;)

    Besser:

    [LEFT]

    PHP
    <?php 
    function is_subpageFrom($parentID) {
      global $post;
      return ($post->ID == $parentID || $post->post_parent == $parentID);
    }
    ?>

    [/LEFT]