Verfasste Forenbeiträge

Ansicht von 15 Antworten - 1 bis 15 (von insgesamt 37)
  • mumbomedia

    (@mumbomedia)

    Die Ursache ist nun gefunden und behoben worden.
    Es war global in der php.ini die Einstellung display_errors aktiviert.
    Wurde nun geändert und seitdem werden die Fehler nicht mehr im Frontend angezeigt.
    Daher schließe ich diesen Thread.

    mumbomedia

    (@mumbomedia)

    Vergleich hat leider keine neuen Erkenntnisse zum Unterdrücken.
    Der Fehler wurde schlicht durch Ändern der Zahl hinter continue behoben.

    Bislang sind auch keine Meldungen dieser Art mehr aufgetaucht.
    Werde es weiter beobachten. Sobald sich etwas ergibt, wird es hier umgehend veröffentlicht.

    mumbomedia

    (@mumbomedia)

    @la-geek
    Der Fehler scheint ja nun im Revolution Slider behoben zu sein.

    Dieser war auch nur als Beispiel gedacht, Fehlermeldung dieser Art habe ich auch von anderen Plugins / Themes bekommen.

    Ich versuche dann natürlich, diese zu beheben, was mir meistens auch gelingt.
    Manchmal ist aber nicht sofort ein Update verfügbar. Da wäre es natürlich schön, wennn diese Meldungen nicht angezeigt würden und somit unsere Kunden verunsichern.
    In regelmäßigen Abständen werden alle unsere WP-Installationen aktualisiert, sodass diese aktuell und somit sicher sind. In der Zeit bis diese Updates verfügbar und installiert sind, sollten wie bislang auch Fehler nur geloggt aber nicht sichtbar sein.

    Werde mir mal ansehen, wie es beim Revolution Slider behoben wurde.
    Vielleicht ergeben sich dadurch neue Erkenntnisse.

    mumbomedia

    (@mumbomedia)

    (@la-geek)
    Ne, dieser ist standardmäßig auf 0 eingestellt.
    Das ist es ja was mich wundert. Mit der PHP 5.6 werden keine Fehler angezeigt nur verlangen ja einige Plugins PHP 7.0 oder höher.

    Das hatte ich bereits probiert, hat aber nichts genützt.

    Daher ja auch meine Vermutung, dass es keine richtige Error-Meldung sondern eine Exception ist. Auch ein Bug in PHP selbst halte ich für möglich.

    mumbomedia

    (@mumbomedia)

    @bscu
    Richtig, das Error-Reporting wird zur Laufzeit durch das Setzen von WP_DEBUG an oder ausgeschaltet. Hierfür wird das erwähnte ini_set benötigt, was in unseren Fall möglich ist. In Kombination mit WP_DEBUG_DISPLAY und WP_DEBUG_LOG werden zur Laufzeit noch weitere PHP-Einstellungen gesetzt (ebenfalls per ini_set). Somit werden die Default-Werte überschrieben, sodass es egal ist, ob das error_reporting standardmäig aus oder angeschaltet ist. In unseren Fall ist der Standard an, Anzeige nein, Logging ja. Dies macht bei einem Live-System meiner Meinung nach auch am meisten Sinn.

    Wie gesagt, werden seit PHP 7 vermehrt Exceptions statt Errors geworfen und ich vermute, dass WordPress noch keinen Code zum Abfangen dieser besitzt obwohl der Handler für beide Varianten ab PHP 7 gleich ist, da aber dieser Version sowohl Errors als Exceptions das Throwable-Interface erben. Es muss allerdings nicht nur set_error_handler sondern auch set_exception_handler aufgerufen werden, damit PHP den entsprechenden Handler nutzt.

    Bislang hat die Standardeinstellung von WP_DEBUG dafür gesorgt, dass die Meldungen nicht angezeigt wurden, somit liegt die Vermutung nahe, dass etwas am Code von WordPress geändert wurde, sodass es mit PHP 7 nicht mehr korrekt greift.
    Dies ist meiner Meinung nach ein Problem, dass die Entwickler von WordPress beheben sollten. Daher habe ich es hier veröffentlich in der Hoffnung, dass Sie es bemerken, den Fehler prüfen und beheben.

    • Diese Antwort wurde geändert vor 4 Monate von mumbomedia.
    mumbomedia

    (@mumbomedia)

    @bscu

    „Das ist aber der falsche Weg. Anstatt Warnings zu unterdrücken sollte man besser zusehen, dass der Quellcode fehlerfrei ist.“

    Das ist schon richtig, aber ja wohl Sache des jeweiligen Plugin- / Theme-Autors.
    Auch tauchen diese Warnings bei PHP 7.2 auf.

    Der Zweck von WP_DEBUG ist ja, solche Fehler anzuzeigen bzw. zu loggen.
    Auf Live-Systemen sollen diese aber abgefangen und nicht angezeigt werden.
    Denn die Pfadangaben die in den Meldungen ausgegeben werden sind gefundenes Fressen für Hacker und niemand will, dass seine Seite gehackt und ggf. kompromitiert wird.
    Somit ist diese Antwort wenig hilfreich.

    @pezi

    Zu deiner Frage

    Mit “ oder ‚?

    Es ist beides erlaubt.
    Performance-technisch ist allerdings ‚ zu bevorzugen.
    Der Hintergrund ist, dass bei der Verwendung von “ der PHP-Interpreter prüft ob Sonderzeichen/Steuerzeichen wie der Zeilenumbruch \n gesetzt sind.
    Bei Strings die diese nicht benötigen, sollte man daher besser ‚ verwenden.

    siehe auch https://stackoverflow.com/questions/3446216/what-is-the-difference-between-single-quoted-and-double-quoted-strings-in-php

    • Diese Antwort wurde geändert vor 4 Monate, 1 Woche von mumbomedia.

    @la-geek
    Das habe ich schon so verstanden.

    Es verwundert mich nur, dass es bislang anscheinend niemand gemerkt und gemeldet hat.
    Laut WordPress-Codex ist der Standard für Themes diese in besagten Unterordner zu speichern oder halt im gleichnamigen Unterordner im Theme zu speichern.
    Bei Plugins ist das analog nur dass der Unterordner hier plugins statt themes heisst.

    Die meisten Entwickler (die mir bekannt sind) packen es daher in den Theme / Plugin-Ordner selbst, wobei hier auch nicht immer der Standardname für den Unterordner verwendet wird. Da aber der gesamte Theme-/Plugin-Ordner gelöscht wird, ist dies egal.

    Nur wenn die Sprachdateien sich nicht im selben Verzeichnis wie das Theme / das Plugin befinden, muss explizit per unlink nachgeholfen werden. Daher wird dies wohl so selten gemacht. Es erspart dem Entwickler zusätzliche Programmierarbeit.

    Obwohl generell könnte man es auch so machen, dass in der Routine zum Entfernen der Pfad der Textdomain abgefragt wird und dann dieser Pfad einfach komplett gelöscht wird.
    Dann wäre es egal, wo der liegt. Aber darüber sollen sich die Kollegen des Core-Themes Gedanken machen. Ich habe dort nun ein Ticket erstellt und bin gespannt, was sich da tut.

    @la-geek
    Genau, das Plugin Classic Editor wird bei uns auch genutzt.

    Danke für den Hinweis. Ich erstelle da mal ein Ticket.

    … denn es ist ein normales Verhalten, dass die Sprachdateien nicht gelöscht werden.
    – Nein ist es nicht, denn normalerweise liegen die Sprachdateien in languages-Unterordner des Themes und werden dann mitgelöscht. Technisch gesehen, ist das Löschen, ja keine große Sache, da man ja als Theme-Autor weiß wo die Sprachdateien gespeichert sind.
    Wenn man diese also außerhalb des Theme-Ordners speichert, müssen entsprechende unlink-Befehle in die Deinstallations-Funktion. Ich würde sogar soweit gehen, abzuprüfen ob das Verzeichnis leer ist und falls ja, den Ordner ebenfalls mit unlink zu Löschen.

    • Diese Antwort wurde geändert vor 5 Monate, 2 Wochen von mumbomedia.
    • Diese Antwort wurde geändert vor 5 Monate, 2 Wochen von mumbomedia.

    @robertkraft

    Habe ein ähnliches Problem.
    Wäre toll, wenn Sie mir und allen anderen Hilfesuchenden mitteilen könnten, wie Sie das Problem gelöst haben.

    @Zodiac178

    Danke für die schnelle Rückmeldung.
    Super mit dem Plugin hat es geklappt.

    Dann hab ich wohl mit den Fallback irgendwo Müll gelesen (weiss leider nicht mehr wo).

    Nochmals herzlichen Dank für die schnelle und kompente Hilfe.

    MFG mumbomedia

    Forum: Allgemeine Fragen
    Als Antwort auf: JS Problem WP 4.9?

    Kann ich bestätigen der nervige JS-Fehler ist mit dem Update weg.

    Forum: Allgemeine Fragen
    Als Antwort auf: JS Problem WP 4.9?

    @zodiac1978
    Das ist doch mal ne tolle Aussicht zum Wochenende.

    @pixolin
    Das WordPress Open-Source ist, ist mir bekannt.
    Meine Anerkennung für dieses großartige und leicht zu bedienende CMS möchte ich hiermit zum Ausdruck bringen. Einen großen Dank für das Engagement und die immer schnellen Rückmeldungen. Falls ich jemanden zu Nahe getreten bin, entschuldige ich mich hierfür.

    Forum: Allgemeine Fragen
    Als Antwort auf: JS Problem WP 4.9?

    Schön, dass das Problem bereits bekannt ist.

    Allerdings drängt sich nun die Frage auf, wieso dieser Bug erst nach Veröffentlichung entdeckt wurde. Das CMS ist dadurch doch nicht mehr nutzbar.

    Werde mit dem Updaten erstmal abwarten.

    mumbomedia

    (@mumbomedia)

    Ich war hierbei wohl einem Irrtum aufgesessen, dass der Permalink und das Datum im Filter in Zusammenhang stehen.
    Die Plugins werde ich mir mal anschauen.

    Meine Frage ist damit beantwortet.

    Danke euch allen

    • Diese Antwort wurde geändert vor 3 Jahre von mumbomedia.
Ansicht von 15 Antworten - 1 bis 15 (von insgesamt 37)