Beiträge von ClaudiaBerlin

    Hallo Leute,

    weil das Thema immer wieder auftaucht, aber nicht immer gelöst werden kann, hier mein getesteter Befund:

    Die Live-Vorschau verträgt sich nicht mit der Zlib-Kompression (=für kürzere Ladezeit), die - falls vorhanden - in der .htaccess steht!

    Wer also in der Live-Vorschau nur die linke Spalte mit den Einstellungen sieht, rechts aber keine Vorschau, sollte mal schauen, ob in der .htaccess (im Wurzelverzeichnis des Blogs) Zeilen stehen wie diese:

    php_flag zlib.output_compression on
    php_value zlib.output_compression_level 5

    Einfach löschen und nach den Arbeiten am Theme wieder reinkopieren.

    Hallo Leute,

    seit vorgestern setze ich Statify in meinem Blog auf claudia-klinger.de ein. Dieses Blog liegt in einem Verzeichnis /digidiary/ unterhalb Root.

    1)

    Nun läuft es einen Tag und wirft als "beliebte Seiten" im Dashboard ziemlich falsche Pfade aus, nämlich mit einer unsinnigen Doppelung:
    /digidiary/digidiary/
    /digidiary/digidiary/2008/04/04/allergischer-schnupfen/
    /digidiary/digidiary/2015/08/17/flucht-zum-beispiel-syrien/
    /digidiary/digidiary/2009/07/16/1-euro-jobs-demuetigende-sinnlose-beschaeftigungen/


    und so weiter.

    Woran mag das liegen? Muss ich was tun? Schadet es denn irgendwie? (ist ja nach außen nicht sichtbar)

    Wäre für einen Hinweis dankbar!


    2)

    Des weiteren wundern mich die angezeigten Seitenaufrufe.

    Für den 18.August zählt Statify stolze 1509 Seitenaufrufe, wogegen der zum Vergleich noch mitlaufende StatCounter 275 Pageviews anzeigt (NICHT unique visitors, mir ist klar, dass das ein Unterschied ist)

    Wie kann das sein? WAS zählt Statify denn da? Etwa gar nicht die Seitenaufrufe, sondern alle HTTP-Requests - also jedes Bild etc. einzeln? Das kann doch eigentlich nicht sein...

    Kann dazu jemand was sagen?

    Das ist es eben grade nicht! Ich würde gerne eine einzige Seite im übergeordneten Verzeichnis mitverwalten - ohne dass sich ansonsten etwas ändert. Das Blog ist nämlich bald 16 Jahre alt und ich möchte nicht alle Links zu alten Seiten verlieren - Umleitungen sind bei der Menge eher nicht drin.

    Wenn es keine Standardlösung gibt, würde mich auch die Info interessieren, ob man das theoretisch als Plugin programmieren kann.

    Hallo alle,

    zwar nutze ich seit Jahren Wordpress, doch taucht das Problem, das mich grade umtreibt, in meinen Installationen mangels "Moderation" nicht auf. Wohl aber bemerke ich es auf vielen Blogs und würde es gerne ändern, jedenfalls bei neuen Blogs, die ich gestalte.

    Es geht um das verbreitete Phänomen, dass WP-Blogs keinerlei Rückmeldung geben, wenn man einen Kommentar abgeschickt hat. Kommentare zu moderieren ist heute viel verbreiteter als früher, deshalb fällt dieses Verhalten auch immer häufiger unangenehm auf. Man schickt den Kommentar ab - und nichts passiert, die Seite, die in der Folge angezeigt wird, ist diesselbe, auf der man kommentierte. Ganz ohne jeden Hinweis, dass der Kommentar angekommen und in die Moderation geschickt wurde.

    Ich finde das schade, denn es lässt Kommentierende im Unklaren darüber, ob ihr Kommentar im Nirvana versackt ist oder nicht.

    Deshalb meine Fragen:

    Wie ist das zu ändern?
    An welchen "Schrauben" vom WP muss man drehen?
    Ist es eine Frage der Einstellungen oder des Theme-Designs?

    Freue mich über jeden Hinweis!

    Das Jetpack-Plugin ist ja so eine Art eierlegende Wollmilchsau mit jeder Menge Funktionen - also wird es da keine einfache Antwort geben.

    Ich wäre schon allein deshalb skeptisch, weil auf der Plugin-Seite

    https://wordpress.org/plugins/jetpack/

    235 Leute nur einen Stern vergeben und von schweren, aber sehr unterschiedlichen Problemen beim Einsatz berichten. Wenn du dir diese 235 Postings mal durchforstest, findest du vielleicht Anhaltspunkte...

    So, nach langem Suchen bin ich auf die Lösung gestoßen, warum es dieses Problem gibt: Es handelt sich um eine Art Inkompatibilität zwischen Wordpress, Firefox (u.a. Browser außer Chrome) und der serverseitigen Kompression per ZLIB. Letztere verhindert offenbar das korrekte Handling von AJAX-Code.

    Folgende Threads fand ich dazu:

    http://wordpress.org/support/topic/…king?replies=37

    https://core.trac.wordpress.org/ticket/22430

    Ich versuchte die Lösung mit dem selbst gebastelten Plugin, die in Thread 1 empfohlen wird - leider ohne Effekt.

    Zum Glück hatte mich das Stichwort ZLIB erinnert, dass es ja noch die .htaccess gibt - und tatsächlich, da fand ich die früher einmal eingesetzten Zeilen zur Verbesserung der Ladezeit:

    php_flag zlib.output_compression on
    php_value zlib.output_compression_level 5

    Hab die Zeilen entfernt - und prompt funktioniert alles wieder, die Vorschau und auch das Anpassen.

    Dennoch: keine GUTE und zukunftsfähige Lösung! Denn die Nicht-Nutzung der Kompression bedeutet längere Ladezeiten - und das nur, damit die Theme-Preview funktioniert? Die brauche ich ja nicht so oft, also könnte ich die .htaccess ja im Grunde so lassen... ABER: das Problem hat wohl auch Auswirkungen auf andere AJAX-Anwendungen, z.B. Kommentar-Plugins.

    So ist jedenfalls mein Stand der Dinge - da sich hier niemand zur Sache geäußert hat, werde ich das Thema eher dort weiter verfolgen:

    http://wordpress.org/support/topic/…=3#post-5228849

    Nach Update auf WP 3.81 funktionierte weder die Theme-Vorschau (alles Themes!) noch war es möglich, das Theme umzustellen (das alte "klebte" quasi fest).

    Ich hab nochmal alle WP-Dateien überschrieben, um auszuschließen, dass es an einer fehlerhaften/fehlenden Datei lag. Zunächst brachte das keine Veränderungen, doch zu meinem Erstaunen funktioniert seit heute früh der Theme-Wechsel immerhin wieder.

    Nicht aber die Vorschau, die ich ja brauche, um komplexere Themes anzupassen (auch "anpassen" zeigt die Vorschau nicht),


    • Ich hab versucht, alle Plugins zu deaktivieren - keine Veränderung,
    • Alle Themes haben Namen ohne Leerzeichen und Bindestriche.

    Der DIREKTE Aufruf der Vorschau in der URL

    http://www.claudia-klinger.de/digidiary/?pre…et=twentytwelve

    funktioniert! (Wenn ich eingeloggt bin, klar!)

    Was könnte ich noch tun?

    Gibt es evtl. eine Möglichkeit, WP dazu zu bringen, Fehlermeldungen auszugeben, so dass man erkennen könnte, woran es liegt?

    So, nochmal runter geladen - hier war die richtige cache.php dabei!

    Und siehe da: ES GEHT!!!!

    Was DAS wohl für ein Wurm war, der hier drin steckte? Mal kurzzeitig ein fehlerhaftes Paket im Download gewesen...? Tja, vermutlich werde ichs nie wissen. Hat mich leider einiges Gewürge, Gesuche und Zeit gekostet...

    Danke allen für Tipps und Anteilnahme!

    So, mein Provider sagt, er habe JEGLICHE SPEICHERBEGRENZUNG testweise rausgenommen - keine Veränderung!

    Die Fehlermeldung sollte doch eigentlich SAGEN, was los ist

    Zitat

    Call to undefined function wp_cache_get() in /srv/www/cklinger/modersohnmag/htdocs/wp-includes/functions.php on line 1131 Fatal error: Call to undefined function wp_cache_close() in /srv/www/cklinger/modersohnmag/htdocs/wp-includes/load.php on line 581

    - ich bin nun kein PHPler, aber wenn ich das so mit gesundem Menschenverstand zu verstehen suche, dann werden hier offenbar in den angegebenen Dateien (functions.php und load.php) zwei Funktionen aufgerufen, die nirgends definiert sind. Nämlich

    wp_cache_get()
    wp_cache_close()

    Bis hierhin richtig? Beide aufrufenden Dateien sind auch tatsächlich da

    In der functions.php im Zeile 1131 steht

    Zitat

    if ( wp_cache_get( 'is_blog_installed' ) )
    return true;

    und in der load.php steht in Zeile 581

    Zitat

    wp_cache_close();

    Soweit so richtig. WO sind aber diese Funktionen, die da nicht gefunden werden? Bzw. wo sollten sie sein?

    Eine Suche ergibt folgende Dateien:

    http://de.wpseek.com/wp_cache_get/
    http://de.wpseek.com/wp_cache_close/

    beide geben als "Ort" der Definition die Datei cache.php an.

    Und wirklich, in der cache.php befinden sich diese Definitionen auch nicht. Im Gegenteil kommt mir diese Datei etwas ungewöhnlich für eine WP-Core-Datei vor. Da steht zu Beginn nach dem öffnenden <PHP:


    Zitat

    /**
    * SimplePie
    * A PHP-Based RSS and Atom Feed Framework.
    * Takes the hard work out of managing a complete RSS/Atom solution.
    * Copyright (c) 2004-2012, Ryan Parman, Geoffrey Sneddon, Ryan McCue, and contributors
    * All rights reserved.

    und weiter unten:


    Klicke ich mich jedoch von den beiden oben genannten Fund-Seiten zum jeweiligen Code der dort verlinkten cache.php weiter, so handelt es sich offensichtlich um ganz anderen Code! Die auf GitHub stehende Variante ist vor 3 Monaten letztmalig geändert und beginnt mit


    Aha, anscheindend ist da eine falsche Datei ins Paket (deutsche Version, heute herunter geladen) gekommen. Hab also mal die cache.php aus der vorherigen WP-Version hochgeladen, die in etwa so aussieht wie das auf GitHub. Und siehe da: die Fehlermeldung über nicht gefundene Cache-Funktionen erscheint nicht mehr.

    DAS BLOG ABER AUCH NICHT!!! Auch der Aufruf der Upgrade-Datei ergibt nach wie vor nur eine weiße Seite...

    Tja, was kann es noch sein?

    (Und: war mein Vorgehen richtig? Wie kommt es, dass so eine seltsam ANDERE Datei plötzlich im Core ist?)

    cache.php ist vorhanden. Ich hab das Update händisch gemacht und sogar doppelt hochgeladen, weil ich auch dachte, evtl. fehlt was.

    Ansonten hab ich an meinen Hoster gemailt wg. des Memorys... danke erstmal für Eure Tipps.

    Es wird gefühlt immer häufiger, dass das Update nicht so ohne weiteres klappt...

    Liebe Leute,

    zum Glück ist es nicht mein wichtigstes Blog, dass ich zuerst auf 3.8 geupdatet habe. Nach Hochladen der Dateien erscheint beim Aufruf des upgrade-Links nur eine weiße Seite - Back- und Frontend sind nicht zugänglich.

    http://www.modersohn-magazin.de/

    Natürlich hab ich zuerst die gängigen Fehlerbehandlungen durchgeführt:

    -> neuen Plugin-Ordner erstellt (leer), den alten umbenannt (-temp dran)
    -> aktuelles Theme ebenfalls so umbenannt, damit WP auf ein Standardtheme zugreift

    Kein Erfolg!

    Also hab ich in der config.php mal debug auf "true" gesetzt - nun erscheint eine Fehlermeldung, wenn man das Blog aufruft:

    Zitat

    Fatal error: Call to undefined function wp_cache_get() in /srv/www/cklinger/modersohnmag/htdocs/wp-includes/functions.php on line 1131 Fatal error: Call to undefined function wp_cache_close() in /srv/www/cklinger/modersohnmag/htdocs/wp-includes/load.php on line 581

    Was tun?

    Die htaccess sieht so aus:


    Die hatte zuerst noch Zeilen zum Komprimieren drin, die ich wegen einer auf "zlib" bezogenen Fehlermeldung raus geworfen habe:

    Zitat

    php_flag zlib.output_compression on
    php_value zlib.output_compression_level 5

    <FilesMatch "\\.(js|css|html|htm|php|xml)$">
    SetOutputFilter DEFLATE
    </FilesMatch>

    Das war mal so ne Aktion auf gut Glück, besonders gut kenn ich mich damit nicht aus. Nun funktioniert es aber auch mit der abgespeckten .htaccess nicht,

    Bin für jeden Tipp dankbar, was ich noch machen könnte...