Verfasste Forenbeiträge

Ansicht von 15 Antworten - 16 bis 30 (von insgesamt 48)
  • Thread-Starter 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 5 Jahren von mumbomedia.
    Thread-Starter 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.

    mumbomedia

    (@mumbomedia)

    @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 5 Jahren von mumbomedia.
    Thread-Starter mumbomedia

    (@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.

    Thread-Starter mumbomedia

    (@mumbomedia)

    @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 Jahren, 1 Monat von mumbomedia.
    • Diese Antwort wurde geändert vor 5 Jahren, 1 Monat 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.

    Thread-Starter mumbomedia

    (@mumbomedia)

    @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.

    Thread-Starter 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 7 Jahren, 8 Monaten von mumbomedia.
    Thread-Starter mumbomedia

    (@mumbomedia)

    Und wenn es als Demo-Content des Theme mitgeiefert wird?
    Oder es kann auch sein, dass das Bild über die Import-Funktion angelegt wurde.
    Wenn ich recht informiert bin, so wird hierbei der Permalink übernommen und nur bis wp-content mit den Daten des Servers überschrieben.

    Thread-Starter mumbomedia

    (@mumbomedia)

    Danke Bego,

    dass war mir schon klar.
    Hm, es scheint mir als wenn die EXIF-Daten allerdings für den Permalink genutzt werden.
    Die betreffende Datei wurde am 28. Sep 2015 @ 17:20 hochgeladen.
    Der Permalink lautet aber http://domain/verzeichnis/wp-content/uploads/2012/07/01_Ähre_klein.jpg.
    Bevor hier einer aufschreit, wegen der Umlaute. Dagegen hab ich bereits das Dropin von Herrn Bueltje eingebaut. Das war quasi der Grund warum es mir überhaupt aufgefallen ist.

    Stellt sich also die Frage, warum der Permalink nicht http://domain/verzeichnis/wp-content/uploads/2015/09/01_Ähre_klein.jpg heisst.
    Evtl. werden bei der Permalink-Erstellung ja die EXIF-Daten berücksichtigt.

    Thread-Starter mumbomedia

    (@mumbomedia)

    Genau, nur im Adminbereich.
    Widget hab ich noch garnicht ausprobiert.

    Mich wuerde interessieren, wie man die Sortierung ausschaltet.
    Oder meinst du etwa die Einstellung „Organisiere Uploads in monats- und jahresbasierten Ordnern“ unter Einstellungen > Medien ?

    Diese hab ich nämlich an, da diese bei einem Magazin mit monatlichen Ausgaben Sinn macht.

    Thread-Starter mumbomedia

    (@mumbomedia)

    Hy fk59,

    freut mich dass ich dir helfen konnte.
    Noch ein Tipp, schau doch mal nach, ob bei dir evtl. Scripte sind, die preg-Funktionen nutzen. Bei mir war es ein altes FCKeditor-Skript das gehackt wurde. Dort wurde eine Schwachstelle ausgenutzt. stand etwas in der Art
    preg_replace(Muster\e,““,$_POST[‚xyz‘]) drin.
    Näheres findest du z.B. in diesem Youtube-Video https://youtu.be/iuqv-2DC1g8 (französisch) oder http://blog.benny-baumann.de/?p=332.
    Im Prinzip nutzt der Angreifer darüber die Möglichkeit aus, mittels preg_replace ein eval auszuführen, dass er i.d.R. base64-kodiert in der Post-Variablen übergibt.
    Betroffen sind quasi alle Hoster, da diese i.d.R. eval erlauben um z.B. Backups durch den Kunden durchführen zu lassen, wenn dieser an der Webseite etwas ändern will.
    Ab PHP 5.5 ist der Modifier veraltet und wir zum Glück mit Version 7.0.0 komplett entfernt.
    Evtl. kann man diesen Modifier auch verbieten. Kannst du deinen Hoster ja mal darauf ansprechen.

Ansicht von 15 Antworten - 16 bis 30 (von insgesamt 48)