Beiträge von b3317133

    Würde einen der zahlreichen Filter in wp_nav_menu() verwenden, um den Menüpunkt passend einzufügen, z.B. [FONT=courier new]wp_nav_menu_objects[/FONT] dann wird das passende HTML autom. erzeugt, oder [FONT=courier new]wp_nav_menu_items[/FONT] oder [FONT=courier new]wp_nav_menu_{$menu->slug}_items[/FONT] o.ä., wenn man das HTML selbst ergänzen will.

    WordPress stellt von sich aus keinen "Datenschutz-Button" zur Verfügung. Daher erscheint normalerweise auch keiner. Wenn man einen solchen Button haben möchte, muss man den selbst (ggf. über ein Plugin) ergänzen.

    Die Frage hier ist also: Über welches Plugin wird dieser Button eingebunden bzw. sollte eingebunden werden und warum ist er nicht sichtbar bzw. vorhanden.

    Ein Blick in den HTML-Quellcode lässt vermuten, dass Akismet verwendet wird, da CSS für einen akismet_privacy_check vorhanden ist, aber die Checkbox dazu nicht angezeigt wird.

    Welches Plugin wird für die Checkbox benutzt? "Akismet Privacy Policies"? Ein anderes?

    Evtl. wird vom Theme der Filter comment_form_defaults o.ä. nicht korrekt genutzt und daher die Checkbox nicht ausgegeben.

    1. Warum wird jQuery in einer alten Version von extern eingebunden und nicht lokal die aktuelle Version von WordPress? Stelle das externe Einbinden mal ab.

    Falls das nicht hilft, deaktiviere das Plugin "Content Aware Sidebars" und alle sonstigen Plugins die mit Widgets, Sidebars, (vermeintlicher) Script-Optimierung o.ä. zu tun haben.

    2. Die Script-Tags im Frontend werden von irgendeinem Plugin o.ä. modifiziert und sind alle defekt, am Ende steht z.B.: [FONT=courier new]defer'>
    [/FONT]
    Es liegt also offenbar warum ein immer ein Eingriff in das Script-Loading von WordPress vor, das sollte man als erstes abstellen, evtl. lösen sich dann die Widget-Probleme von alleine.[FONT=courier new]
    [/FONT]

    Wie auf der Plugin-Seite von "JP Widget Visibility" beschrieben, wurde die entspr. Funktion aus Jetpack "übernommen". Auf der Seite steht aber auch, dass "JP Widget Visibility" nicht mehr weiterentwickelt wird und nur bis WordPress 4.5.9 getestet wurde.

    Wenn man das Jetpack Plugin verwendet, kann durchaus je nach Funktion eine Ergänzung der Datenschutzerklärung nötig werden.

    Empfehle Jetpack eher nicht, da es auch aufgrund des Umfangs den Server unnötig belastet und oft ohnehin nur kleine Einzelteile daraus verwendet werden, die es als einzelne "schlanke" Plugins auch gäbe.

    Die eigentliche Frage, mit welchem Plugin die Funktion auf dem Screenshot umgesetzt wurde, hat damit aber nichts mehr zu tun.

    Am Rande: Der verlinkte Beitrag mit dem Screenshot ist von 2014, so alte Beiträge sollte man nicht unbedingt als alleinige Quelle für "Finetuning" oder als Anhaltspunkte zur Konfiguration verwenden, da meist vieles/alles hoffnungslos veraltet ist.

    Für Lokal -> Server oder Server -> Lokal oder auch den Umzug zwischen Subdomains oder Domains wird oft das Plugin "Duplicator" verwendet, die Datenbank wird dabei autom. im Rahmen der Installation angepasst. Einfach mal das Video auf de Pluginseite komplett anschauen, ist zwar englisch, aber das grundsätzliche Prinzip sollte dabei in jedem Fall klar werden.

    Kann den Anhang nicht öffnen.

    Welches Widget-Cache Plugin wird verwendet (und warum eigentlich)?

    Was passiert, wenn Du das Text-Widget per Drag & Drop in den passenden Sidebar ziehst?

    Was passiert, wenn Du einen Sidebar und eine Position auswählst?

    Die Meldung "not available" mit 403 HTTP Fehlercode kommt nicht von WordPress sondern von einem Plugin, in dem Fall wahrscheinlich "All In One WP Security & Firewall". Du hast Dich sozusagen ausgesperrt.

    Benenne den Plugin-Ordner wp-content/plugins/all-in-one-wp-security-and-firewall/ per FTP um oder lösche den Ordner. Dann sollte der Login wieder normal möglich sein.

    Am Rande bemerkt: Dieses oft aus welchen Gründen auch immer benutzte "Login" Verstecken bringt gegen entspr. Bots rein gar nichts. Die aktuelle WordPress Version stellt standardmässig (wie auch in Deinem Website) über die REST-API unter /wp-json/wp/v2/users eine Liste der Benutzernamen bereit, "brute force" Login-Versuche laufen dann ebenfalls über diese API und nicht über Login-Formulare.

    Das bedeutet, dass aus irgendwelchen Gründen über ein Plugin oder durch das Theme versucht wird, die jQuery-Bibliothek von einem externen Server einzubinden, anstelle richtigerweise die lokal in WordPress mitgelieferte Version zu benutzen.

    Die Integration der externen Bibliothek wird zudem noch fälschlicherweise über http:// versucht, obwohl der Admin-Bereich via https:// genutzt wird.

    Das führt dazu, dass jQuery nicht korrekt geladen wird und so der zweite Fehler erscheint, der wiederum dazu führt, dass viele/alle sonstigen Scripts auf der Seite nicht funktionieren werden.

    Es gilt also herauszufinden, welches Plugin oder ob ggf. das Theme die Ursache ist, vermutlich ein Plugin, denn die MH Themes machen solchen Unsinn eigentlich nicht.

    Die Einbindung dieser externen jQuery-Bibliothek erfolgt auch im Frontend des Websites, dort allerdings via https://, wodurch zwar die Einbindung klappt, aber ein Problem bzgl. der Datenschutzerklärung verursacht, denn diese Einbindung ist dort nicht erwähnt.