Claudia am 09. Februar 2014 —

Hier wird am System gebastelt…

Update 13.2.: Das Problem mit der nicht dunktionierenden Theme-Preview ist erkannt und fürs erste gelöst. Allerdings nicht wirklich befriedigend, doch ist das Thema derart technisch, dass ich es hier nicht ausbreiten will. Zur Lösung und zum Stand der Dinge siehe meinen Bericht im WP-Forum.

Update 10.30 Uhr: Auf CHROME geht die Theme-Vorschau, nicht aber auf FF und MSIE – ich wunder mich!!!

Update 12.Februar, 9.00: nurmehr die Theme-Vorschau funktioniert nicht (inkl. Theme anpassen etc.). Umstellen ist jetzt möglich – weiß der Teufel, woran es gelegen hat! Aber ich brauche auch die Vorschau….

___________________________________________

…deshalb wundert Euch bitte nicht, sollte es gelegentlich Fehler in der Darstellung oder unerreichbare Seiten geben.

Eigentlich wollte ich nur ein Plugin fürs Kommentare editieren erneuern. Da es nicht funktionierte, hab ich erstmal das ganze Blog auf die neueste Version von WordPress geupdatet. Auch alle Plugins sind aktuell – und weil das Kommentar-Plugin immer noch nicht funzte, liegt es wohl am selbst gebauten, aber mittlerweile in die Jahre gekommenen Theme.

Themewechsel und Vorschau funktionieren nicht

Also mal versuchsweise auf ein anderes (twentytwelve) umgeschaltet – und siehe da: das funktioniert auch nicht! Weder per Vorschau, noch per „Aktivierung“ – sehr sehr seltsam! Sowas hatte ich noch nie, auch scheint dieses Verhalten in der Szene unbekannt zu sein, denn im WordPress-Forum sagte bisher keine/r was dazu.

Ich experimentiere also mal weiter auf eigene Faust…

Stand: Sonntag, 11.16 Uhr

Update Sonntag-Nacht: jetzt hab ich das mal getweeted – im WP-Forum antwortet bisher niemand auf diese Frage.

Diesem Blog per E-Mail folgen…

Diskussion

Kommentare abonnieren (RSS)
8 Kommentare zu „Hier wird am System gebastelt…“.

  1. Es ist immer toll, wenn man ein technisches Problem hat und niemand von den Experten antwortet…nur einen Tag später: Kenn ich nicht, weiß ich nicht.

  2. @Gerhard: na, das Problem ist offenbar recht unbekannt, ich hab seitenweise die Google-Suchergebnisse durchsucht, nix!

    Gleichzeitig ist es momentan nicht „lebenswichtig“ – sonst hätte ich längst konkrete Personen persönlich um Rat gefragt: das hat noch immer geklappt.

  3. Ich kenne mich mit wordpress nicht aus, wir hatten aber hier bei meiner website (die serverseitig durch php-scripts aus mysql-tables generiert wird) einmal ein ähnliches Problem (falls deines nach wie vor das Verschwinden des im Formular editierten Textes sein sollte).

    Und zwar lag das an mehreren Fehlern, von denen zwei webserver-spezifisch waren, was erklären würde, daß nur du, i.e. dein webserver, dieses Problem hat, während es bei anderen nicht auftritt:

    Erstens harmonierten die folgenden Einstellungen für das php-system auf dem webserver nicht: ‚memory limit‘ (should be geater or equal than) ‚post max size‘ (should be greater or equal than) ‚upload max filesize‘. Wir haben hier 128M-8M-8M als ausreichend eingestellt, allerdings ist selbstgeschriebener code natürlich nie derart massiv durch den albernen overhead von Multifunktionscode belastet, was bei wordpress vielleicht andere Werte erfordert.

    Zweitens war die php-Einstellung ‚max execution time‘ (in seconds) zu gering, so daß das script-processing auf dem webserver mitten drin ‚verstarb‘, seltsamerweise aber so funktionierte, als wären alle einfachen -Daten noch korrekt verarbeitet worden, während für die -Daten vom client leere Formularfelder übergeben worden. Bei uns klappt es mit 60 seconds prima.

    Vielleicht kannst du ja damit etwas anfangen bei deiner Fehlersuche, ich wünsche dir auf jeden Fall viel Glück!

  4. Ach, jetzt habe ich oben die Tags nicht maskiert. Der vorletzte Absatz sollte lauten:

    Zweitens war die php-Einstellung ‚max execution time‘ (in seconds) zu gering, so daß das script-processing auf dem webserver mitten drin ‚verstarb‘, seltsamerweise aber so funktionierte, als wären alle einfachen <input>-Daten noch korrekt verarbeitet worden, während für die <textarea>Daten vom client leere Formularfelder übergeben worden. Bei uns klappt es mit 60 seconds prima.

  5. Danke Susanne! Mein Provider hat diese Ideen geprüft – daran liegts (leider) nicht.

    Ich hab schon einiges versucht, aber bisher ohne Erfolg. Wobei ich ja auch erst nachts wieder mit gutem Gefühl experimentiere, tagsüber mag ich hier kein Chaos anrichten.. :-)

    Schon seltsam, dass ich bisher nirgends etwas zu diesem Problem fand!

  6. Schade! Mir fällt aber noch ein Punkt ein, nämlich der K(r)ampf mit den Sonderzeichen, falls ein Textfeld mit vom webserver gelieferten Daten vorbelegt ist (also im Falle von sql-tables vor allem die slashes, welche char-Felder umschliessen müssen in einer sql-query.

    Da gibt es diese lustigen Einstellungen ‚magic_quotes‘ und ‚magic_quotes_runtime‘, die einem angeblich alle Arbeit abnehmen, aber es dann irgendwie doch nicht tun…

    Jedenfalls ist es peinlich, wenn dort etwas nicht stimmt und eingegebene Texte, die quotes enthalten, verschwinden, weil diese die erzeugte query durcheinander bringen. Das sollte in einem sauberen System (wie wordpress) nicht vorkommen, aber welches System ist schon ganz sauber?

  7. Hmmm.. da kann ich mir vorstellen, dass sowas mit dem nicht-funktionierenden Editier-Plugin zu tun hatte. Aber doch nicht mit Grundfunktionen wie Theme-Vorschau und Theme-Wechsel… sollte wenigstens nicht.

    Bisher hab ich das kürzliche System-Update auf 3.81 nochmal gecheckt, um womöglich irgendwelche nicht geladenen Dateien als Fehlerquelle auszuschließen. Auch eine neue Rechtevergabe auf dem Themeordner + Unterordner brachte nichts.

    Sodann hab‘ ich die WP-Config von allen im Lauf der Zeit gemachten persönlichen Einstellungen bereinigt – sie ist jetzt genau SO, wie sie mit dem neuen WP geliefert wird, nur ergänzt um die notwendigen DB-Einträge etc.

    Schon komisch… na, heut nacht lösche ich mal temporär das Diary-Theme weg. Mal schauen, was dann passiert…

  8. Viel Erfolg damit!