Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellen
Am Rande: Bzgl. Fragen zur Einrichtung sind die Einstellungen des jeweiligen Plugins gemeint, das die Zugriffe regeln soll.
Testbild-768x768.jpg[FONT=Arial] > noch offen[/FONT]
Siehe Antwort #4.
Dann beschreibe für spätere Mitleser mit ähnlichen Problemen doch noch kurz, was genau die Lösung bei Dir war.
Der Hauptaufwand bei vielen Problemen hier im Forum ist das Beschäftigen mit den jeweiligen Theme Einstellungen und/oder Plugin Einstellungen und/oder WordPress Funktionen.
Du hast jetzt doch schon einige Anhaltspunkte bekommen, probiere sie einfach aus. Alternativ frage den Theme Support, wie Du die genannte autom. erstellte Datei ohne das tubular Script regenerieren bzw. den Debug Modus aktivieren kannst.
Ist es ggf. dieses Problem hier? Siehe dazu auch Plugin Dokumentation.
Falls nein, hast Du es mal ohne alle sonstigen Plugins bzw. mit einem Standard Twenty XXX Theme versucht?
Ansonsten wäre es hilfreich, Dein Theme & Version zu kennen, ebenso die WordPress Version usw., siehe auch Forenregeln, Punkt II
Entfernen kann man Bildgrössen mit [FONT=Courier New]remove_image_size()[/FONT], auf Basis eines Beispiels aus den User Contributed Notes dort:
function wpdocs_remove_plugin_image_sizes() {
remove_image_size( '1536x1536' );
remove_image_size( '2048x2048' );
}
add_action('init', 'wpdocs_remove_plugin_image_sizes');
Zu empfehlen ist das nicht, da die Bildgrössen im Core und auch im Theme für die Beitragsbilder usw. durchaus ihren Sinn haben.
Es sieht lt. Quellcode so aus, als wäre in die Inhaltsbereich solcher Beiträge etwas bzw. zu viel hineinkopiert worden, inkl. html/head/body Tags, die dort nichts verloren haben.
Daher könnten diese internal-linking-related-contents Elemente evtl. bereits aus der Quelle der Kopie stammen.
Oder es ist/war ggf. das Plugin Internal Linking of Related Contents installiert und hat diese Dinge dort eingefügt.
Zwei Hinweise:
Testbild-768x768.jpg
Dürfte die seit WordPress 4.4 im Core befindliche interne Grösse [FONT=Courier New]medium_large[/FONT] sein, siehe [FONT=Courier New]wp-admin/includes/schema.php[/FONT]
Testbild-1536x1536.jpg
Testbild-2048x2048.jpg
Dürften die seit WordPress 5.3 im Core befindlichen Grössen für 2x/retina sein, siehe [FONT=Courier New]wp-includes/media.php[/FONT]
Die Beschreibung sagte das Gegenteil:
In der DB stand http. Ich habe daraus https gemacht, ...
Browsercache leeren brachte keinen Erfolg.
Inwiefern? Wird trotzdem auf https weitergeleitet?
Das ist die .htaccess, die ich aus der funktionierenden Seite kopiert habe.
Die enthält andere Pfade, das dürfte kaum passen.
Nach jeder Änderung muss der Browsercache komplett geleerte werden. Evtl. leerst Du nur die letzte Stunde o.ä. Weiterhin versuche es auch mit einem anderen Browser.
Die Seite bindet weiterhin diese generierte Datei [FONT=Courier New]__scripts.js[/FONT] ein. Man könnte in den Theme Einstellungen suchen, wo man diesen lt. Code vorhandenen Debug Modus aktivieren kann und/oder wie man die Datei [FONT=Courier New]__scripts.js[/FONT] neu generiert, dann ggf. ohne den "tubular" Teil.
In der DB stand http. Ich habe daraus https gemacht, was aber keinen Erfolg brachte.
Kein Wunder, denn dort sollte [FONT=Courier New]http[/FONT] stehen und nicht [FONT=Courier New]https[/FONT] - in den Feldern [FONT=Courier New]home[/FONT] und [FONT=Courier New]siteurl[/FONT]
Wenn ich im Browser eingebe localhost/wordpress/wp-admin macht er daraus ein https://localhost/...
Entferne nach der o.g. Anpassung in der Datenbank noch ggf. vorhandene Einträge für eine Weiterleitung zu https in der Datei [FONT=Courier New].htaccess[/FONT] und leere Deinen Browser Cache.
dem Hinweise ''Sie haben dieser Webseite zusätzliche Berechtigungen erteilt'.
Das ist eine Einstellung in Deinem Browser.
Bzgl. des neuen Problems auch der Hinweis:
...Tests auf Nebenwirkungen vorausgesetzt...
Schau Dir z.B. die Parameter in [FONT=Courier New]$query[/FONT] an, die bei den jeweiligen Aufrufen in [FONT=Courier New]ajax_query_attachments_args[/FONT] ankommen, evtl. kannst Du da eine Unterscheidung feststellen. Alternativ kann man in PHP evtl. über [FONT=Courier New]debug_backtrace()[/FONT] die Herkunft des Aufrufs feststellen und so entscheiden, wann man die Bilder rausnimmt und wann nicht. Oder man begibt sich in die JavaScript Welt der Seite und versucht, alleine darüber in die Parameter für den gewünschten Button einzugreifen oder schickt einen eigenen Parameter mit, der dann von einem PHP Filter Code erkannt werden kann. Entdecke die Möglichkeiten, viel Erfolg beim Basteln.
Das Plugin Postie bietet viele Möglichkeiten, z.B. auch die Zuordnung zu einer Kategorie. Weiter dann in der Antwort #4 oben.
Alternativ kann man im Plugin Postie auch den Veröffentlichungs-Status voreinstellen, Lesen der Dokumentation hilft auch hier.
Ersetze in der Datenbanktabelle beim Feld [FONT=Courier New]home[/FONT] das [FONT=Courier New]https[/FONT] durch [FONT=Courier New]http[/FONT]
Gibt es somit doch die Möglichkeit das ganze zu unterdrücken?
Lt. Code wird das tubular Script nur dann eingebunden, wenn im Theme a) ein Header Video verwendet wird und dazu b) das Video von YouTube stammt.
Leider sind wieder Cache-, Optimierungs- und sonstige Plugins, die in die Ausgabe eingreifen, z.B. auch Borlabs aktiv, so dass man das nicht weiter sinnvoll analysieren kann.
Ergänzung: Die einzelnen Scripts im Code ab [FONT=Courier New]Skip link focus[/FONT] werden generell nur dann je nach Einstellung eingebunden, wenn offenbar ein Debug Modus des Themes aktiv ist. Ansonsten immer das zusammengefasste [FONT=Courier New]themes/niobe/js/__scripts.js[/FONT] das bei Dir den entspr. YouTube Code enthält, wie/wo auch immer das generiert wird.
Ersetze in Einstellungen > Allgemein > Website-Adresse (URL) das [FONT=Courier New]https[/FONT] durch [FONT=Courier New]http[/FONT]
Beim genannten Link ist ein [FONT=Courier New]!important[/FONT] nicht nötig.
... möchte ich verhindern, dass der User über den "Dateien hinzufügen"-Dialog Bilder einbinden kann. Er soll aber weiterhin PDFs, DOCs etc. auswählen und verlinken können.
Hier ein möglicher Ansatz anhand von Codebeispielen in der wordpress.org Dokumentation, Tests auf Nebenwirkungen vorausgesetzt...
function b3317133_ajax_query_attachments_args( $query = array() ) {
$unsupported_mimes = array( 'image/jpeg', 'image/gif', 'image/png', 'image/bmp', 'image/tiff', 'image/x-icon' );
$all_mimes = get_allowed_mime_types();
$accepted_mimes = array_diff( $all_mimes, $unsupported_mimes );
$query['post_mime_type'] = $accepted_mimes;
return $query;
}
add_filter( 'ajax_query_attachments_args', 'b3317133_ajax_query_attachments_args' );table {
background-color: #ffffff;
}.. All in One SEO im Einsatz - Deaktiviere ich diesen, kann ich ohne Probleme arbeiten;
Beschäftige Dich etwas mit den Einstellungen des Plugins, dann findest Du ggf. die Funktion, die dafür verantwortlich ist und kannst sie abschalten. Kenne das Plugin selbst nicht, lt. der Beschreibung dürfte das diese TruSEO Analyse sein.
Mit der Wahl des Browers oder Caching hat das Problem wohl eher nichts zu tun.
