Verfasste Forenbeiträge

Ansicht von 15 Antworten - 1 bis 15 (von insgesamt 44)
  • Jetzt verstehe ich was die Doku meint.
    Wenn man mehrere Metaboxen mit Tinymce-Editor hat, muss man noch zusätzliches JS einbinden, damit die Instanz beim Verschieben neu initialisiert wird, da der Editor nach dem Verschieben nicht mehr funktioniert.
    Hierfür kann einer der genannten Hooks genutzt werden.

    Danke für den Hinweis.
    Das Plugin schau ich mir mal an.
    Vielleicht bekomme ich ja so raus, wie man das mit mehreren Metaboxen macht.

    mumbomedia

    (@mumbomedia)

    Nein, das Problem ist nicht gelöst.
    Wenn man nämlich die Standardeinstellungen des Editors (d.h. man lässt den optionalen Parameter $settings weg) nutzt (Quicktags aktiv) werden diese über der Metabox angezeigt.

    Es werden zwar in der Doku einige Hooks genannt, die man nutzen kann um mehrere Tinymce-Instanzen zu haben. Wie man diese allerdings nutzt ist nicht klar.

    Da es wohl vorerst nicht geht, habe ich nun nur eine Metabox in der alle Tinymce-Instanzen über wp_editor eingebunden sind.

    Es wäre allerdings auch nicht verkehrt wenn jeder Eingabebereich eine eigene Metabox wäre, da der Nutzer diese nach seinen Vorlieben anordnen kann und somit mehr Usability gegeben wäre.

    mumbomedia

    (@mumbomedia)

    Es scheint wohl mit wp_editor zu gehen, man muss allerdings explizit die Quicktags mittels des dritten Parameters deaktivieren.

    Beispiel:

    wp_editor(
    	$content,
    	'editor-id',
    	array(
    	'media_buttons'=>false,
    		'textarea_rows'=>5,
    		'tinymce' => array(
    			'toolbar1' => 'bold, italic, strikethrough, | removeformat',sollen 
    			'toolbar2' => '',
    			'toolbar3' => '',
    		),
    	'<strong>quicktags'=>false</strong>
    	)
    );

    In dem Beispiel habe ich die Media-Buttons deaktiviert, da ich diese in dem Kontext nicht benötige. Falls benötigt den Wert auf true ändern.
    Mittels toolbar1 -> toolbar3 können die Zeilen mit dem jeweilgen Tinymce-Buttons konfiguriert werden.
    Das wichtigste ist aber ‚quicktags’=>false womit die Quicktags deaktiviert werden.

    • Diese Antwort wurde geändert vor 3 Wochen von mumbomedia.
    • Diese Antwort wurde geändert vor 3 Wochen von mumbomedia.

    Stimmt.

    Anscheinend funkt dort wohl doch das Theme oder ein Plugin zwischen.
    Muss ich wohl mal debuggen.

    Ich stelle das Ticket daher mal auf gelöst.

    Sag ich ja.
    Ich konnte aber nicht herausfinden, wo dieser ist.
    Hab wie gesagt erstmal nen Workaround in die functions.php des Themes eingefügt, der den falschen Wert berichtigt.

    Dachte nur, sollte ich hier mal ansprechen sodass dieser behoben werden kann.

    @pixolin
    Kann es sein, dass das eine Funktionalität eines Plugins ist?
    -Nein, habe testweise alle Plugins deaktiviert.

    Hatte ich vergessen zu schreiben, man muss erst das Bild auswählen und erhält dann die Ansicht die Sie gepostet haben.

    Wenn Sie nun nochmal auf Bild bearbeiten gehen, bekommen Sie die Möglichkeit angezeigt, den Link im neuen Fenster öffnen zu lassen.

    Gegebenenfalls müssen die „Erweiterte Optionen“ (siehe Screenshot Punkt 1) noch ausgeklappt werden. Dort findet man dann besagte Checkbox „Link in einem neuen Tab öffnen“ (siehe Screenshot Punkt 2)

    Als Quelltext wird etwas wie dieses ausgegeben:
    <a href="https://de.wordpress.org/support/topic/bild-widget-oeffnet-keine-links-im-neuen-fenster/"><img src="http://127.0.0.1/wordpress/wp-content/uploads/2019/09/728x90.png" class="image wp-image-531 attachment-full size-full" alt="" style="max-width: 100%; height: auto;" srcset="http://127.0.0.1/wordpress/wp-content/uploads/2019/09/728x90.png 728w, http://127.0.0.1/wordpress/wp-content/uploads/2019/09/728x90-300x37.png 300w" sizes="(max-width: 728px) 100vw, 728px" width="728" height="90"></a>

    Wie man sehen kann fehlt das target-Attribut sodass dieser Link in selben Tab / Fenster geöffnet wird. Man erwartet aber, dass dieser in einen neuen Tab / Fenster geöffnet wird.

    Übrigens kann man auch Menü-Einträge im neuen Tab / Fenster öffnen lassen.
    Man muss hierfür allerdings erst über „Ansicht anpassen“ die Checkbox „Linkziel“ unter „Erweiterte Menüeigenschaften anzeigen“ aktivieren. Hier funktioniert das Setzen der Option „Link in einem neuen Tab öffnen“ jedoch.

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

    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.

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

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

    @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 Monate, 3 Wochen von 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 6 Monate 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.

Ansicht von 15 Antworten - 1 bis 15 (von insgesamt 44)