Kannst Du Plugins installieren? Dann könnte man mit z.B. User Role Editor mal nachschauen, ob/welche Capabilites der aktuellen Admin-Rolle fehlen könnten.
Beiträge von b3317133
-
-
Wann/wo wurde das Update angezeigt? Hast Du ein Plugin wie WordPress Beta Tester o.ä. laufen?
-
Evtl. hast Du keinen vollwertigen Admin Account mit allen "Capabilities"? Erstelle mal zusätzlich einen frischen Admin und versuche es damit.
-
Könnte ggf. auch eine Multisite Installation sein, wo Du nur Zugang zu einem Subsite hast, o.ä.
-
Am besten über die entspr. Dateien im Child-Theme, hauptsächlich [FONT=Courier New]embed-content.php[/FONT], falls die nicht vorhanden sind (wie in 99% aller Themes bzw. Child-Themes), hier wird erklärt, woher sie kommen und wie man sie integriert.
-
-
Sind die Farben, Logos usw. für jede Sprache eingerichtet? Evtl. ein Problem wie hier beschrieben, mehr zu Avada & Polylang ergibt sich ggf. auch aus der Theme Dokumentation.
-
Im [FONT=Courier New]<html >[/FONT] Tag Deiner Seite fehlt die bei WordPress übliche Sprachangabe [FONT=Courier New]lang="XX"[/FONT], evtl. liegt es daran.
In der Demo des verwendeten Themes beim Hersteller ist die Angabe vorhanden.
Wie Du dem Widget direkt die Sprache mitteilen kannst, kann Dir nur der Buchshop sagen.
-
kann mir jemand sagen wie ich das behebe.
Der Buchshop könnte das.
Hier kann das niemand, weil kein Link angegeben ist.
-
Erscheint beim Veröffentlichen im Customizer nach wie vor die o.g. Meldung in der Browser Konsole? Erscheint sie schon beim Aufruf der Seite oder erst nach Klick auf Veröffentlichen?
Was steht im Server Error-Log?
-
Einen "Health Check" gibt es in WordPress standardmässig nicht.
Versuche es mal wie bereits beschrieben mit einer anderen, älteren PHP Version.
-
Würde "http" wählen, zum Rest siehe Erklärungen bei Strato..
-
Bei direktem Setzen der Domain auf den Unterordner sieht man den Unterordner nirgends.
Siehe Anmerkung zu ggf. nötigen Anpassungen bei einer solchen Änderung.
-
Das Laden einiger der Social Media Scripts erfolgt z.B. ab ca. Zeile 743 im HTML-Quelltext des o.g. Links, evtl. also am Ende von [FONT=Courier New]single.php[/FONT] oder der entspr. loop bzw. über einen [FONT=Courier New]the_content[/FONT] Filter o.ä.
Weiterhin werden Daten an Gravatar-Server übertragen (für den Autor Avatar), weiterhin 4x an fonts.googleapis.com für die externe Einbindung der Webfonts, weiterhin an sX.wp.com (offenbar wird die JetPack Image CDN Funktion benutzt), weiterhin an das netdna.bootstrapcdn.com CDN beim Laden des Font Awesome Webfonts, weiterhin an stats.wp.com (offenbar wird die Statistik Funktion von JetPack benutzt), weiterhin an Google Analytics (ohne "anonymizeIp") ca. Zeile 1000, weiterhin an den Google Tagmanager, an Google Adsense, ...
... die Arbeit bzgl. DSGVO fängt also gerade erst an.
-
Würde die .com in dem Fall "extern" auf die "[plain]https://www.xyz.de[/plain]" umleiten.
-
Für interessierte Mitleser, es war seit Dez. letzten Jahres am Anfang von allen functions.php Dateien aller Themes ein entsp. Backdoor Code eingefügt, und weitere Backdoorteile wurden im Ordner /wp-includes/ in Form von wp-feed.php, wp-tmp.php, wp-vcd.php, class.wp.php, wp-cd.php hinterlassen. Eine komplette Aktualisierung der ganzen Installation wäre anzuraten, inkl. aller Plugins. Der (ansonsten jetzt saubere) WordPress Core 4.7.10 ist aber relativ alt, ebenso das (ansonsten jetzt saubere) Theme von dem es auch schon lange kein Update mehr gibt und das aber eine Menge deprecated Functions enthält, was ein Upgrade ggf. etwas komplexer macht... ein schönes Uni-Projekt für eine/n WordPress Kommilitonen/in.
-
Eine klassische Backdoor, offenbar in allen functions.php Dateien in allen Themes... und ggf. in noch weiteren Dateien, das wäre herauszufinden.
-
Der saubere Lösungsweg wäre: Backup von vor einer Woche einspielen, unter "Einstellungen > Allgemein" auf https umstellen (wahlweise direkt in der Datenbank in wp_options) > Neu anmelden > Plugin "Better Search Replace" installieren, damit http://example.com (ohne / am Ende) in allen Tablellen ersetzen durch https://example.com (ohne / am Ende), fertig.
Ggf. noch kleine Nacharbeiten falls Webfonts per http eingebunden waren, die dann gleich nach lokal umziehen, wg. DSGVO...
@maxe: Der Screenshot erwähnt das Datum 2015, ggf. stimmt der Domainname nicht.
-
Poste mal ein paar Zeilen um die Zeile 73 herum, ein $path = $_SERVER['HTTP_HOST'] . $_SERVER[REQUEST_URI]; gibt es eigentlich im ganzen (originalen) Twenty Fourteen Theme nicht. War Twenty Fourteen ursprünglich aktiv?
Eine saubere Version des Twenty Fourteen Verzeichnisses gibt es hier zum Download, aber es könnte sein, dass dann Änderungen im Code (böse, wie gute) nicht mehr da sind, falls kein Child-Theme verwendet wurde.
Einen Ordner von Twenty Fourteen (mit seltsamem Code in functions.php) als Twenty Fifteen oder als Twenty Sixteen ausgeben o.ä. wird zu 100% schiefgehen, das löst die Probleme nicht.
-
Der Website läuft auf einem "CM4all Webserver" lt. HTTP-Header, evtl. ist das für "schöne" WordPress Permalinks nötige aber fehlende Modul siehe @maxe hier in der Tat das Problem.