Beiträge von b3317133

Ohne Code schwer zu sagen...

Nutze einen anderen Browser oder kopiere den Namen nicht aus dem Browser sondern aus einem anderen Dokument / Programm.

Hier funktioniert das Kopieren von Umlautdomains sowohl aus der Adresszeile von Firefox als auch von Chrome einwandfrei.

Der Domainname enthält offenbar mind. einen Umlaut - also z.B. äöü - oder ein anderes Sonderzeichen.

Vereinfacht erklärt: Die obere Zeile ist die "kosmetisch schöne" Darstellung mit Umlaut im Browser (IDN), die untere Zeile ist hingegen der tatsächliche Domainname (ACE), mehr dazu bei Suchmaschinen, bei Strato selbst oder bei Wikipedia.

Geht z.B. so, Idee stammt von hier.

if ( stripos( strrev( $user_email ), 'ur.' ) === 0 ) {
   $errors->...
}

Die Zeile mit [FONT=Courier New]list(..)[/FONT] wird dabei nicht mehr gebraucht. Der Vergleichsstring [FONT=Courier New].ru[/FONT] ist mit Absicht rückwärts...

Deaktiviere mal das/die Plugin(s), die den normalen WordPress Login beeinflussen. Bei Aufruf von /wp-admin/ erscheint derzeit ein seltsames Captcha.

Man könnte eine regelmässige automatische Abfrage via WP-Cron einrichten und darüber dann alle Seiten durchprüfen, get_field( ..) hat dafür auch noch einen post_id Parameter, und dann ggf. eine E-Mail versenden. Damit die E-Mail nicht ständig neu versendet wird, könnte man den Versand in einem Transient oder einem extra ACF-Feld vermerken.

Für Wiederholungsfelder bei ACF verwendet man [FONT=Courier New]have_rows(), the_row(),[/FONT] und [FONT=Courier New]the_sub_field(),[/FONT] Beispiele siehe hier oder hier in der Anleitung von ACF.

Rechte Maustaste auf den gewünschten Bereich > "Element untersuchen" (so heisst der Menüpunkt bei Firefox) > entspr. CSS Selektor ablesen und verwenden.

.single #nav-below {
    display: none;
}

Hier funktionieren die Symbole. Evtl. noch den Browsercache leeren.

Was genau wurde gemacht, damit das Dashboard wieder funktioniert? Genauere Informationen helfen ggf. anderen Lesern, die eines Tages ähnliche Probleme haben.

Wo wurde die Subdomain "gezippt"? Auf dem Server? Oder lokal? Dabei ging ggf. was schief.

Funktioniert das Dashboard, wenn Du die o.g. Datei mit einer frischen Version ersetzt? "Von aussen" kann man das nicht prüfen, man kann nur die Fehlermeldung in der Browser Konsole im Frontend sehen...

Die Beitragsdaten stehen in der Datenbank. Je nachdem wie mit der SQL-Datei umgegangen wurde, kann sie betroffen sein oder auch nicht.

Das Theme erzeugt derzeit einen "illegal character" Scriptfehler in "hueman/assets/front/js/scripts.min.js", dort sind falsch UTF-8 kodierte Zeichen vorhanden. Dürfte durch das "1:1 Hochladen der Sicherung" kommen. Wie genau wurde die Komplettsicherung erstellt bzw. die Sicherung wieder eingespielt?

Ersetze die o.g. Datei durch eine frische Datei aus der gleichen Version des Themes, ein .zip Archiv gibt es z.B. hier.

Hinweis am Rande: Das Problem könnte auch noch weitere Dateien überall auf dem Website betreffen.

Mit der Testversion von Gutenberg gibt es vielerlei Probleme - mit und ohne Yoast SEO. Erstelle am besten ein entspr. Ticket bei Github (wo es derzeit ca. 1180 offene andere Tickets gibt), alternativ im Gutenberg Support Forum.

Gutenberg im aktuellen Zustand hat im produktiven Einsatz nichts verloren.

Wenn die Meta-Beschreibung auch ohne Gutenberg "verschwindet", ist möglicherweise ein anderes Plugin dafür verantwortlich, deaktiviere temporär eins nach dem anderen und prüfe den Zusammenhang. Evlt. vorhandene Ausgaben in der Browser Konsole auf der Editorseite sind bei der Problemsuche hilfreich (diese Ausgaben solltest Du auch in die o.g. Supportanfragen einfügen).

Es wurde offensichtlich noch mehr gelöscht. Welche Dateien und Ordner befinden sich jetzt im Ordner, in dem vorher wp-config.php bzw. wp-config-sample.php waren?

Wenn nur WordPress Systemdateien gelöscht wurden, kann man fehlende Dateien aus einer frischen .zip Datei von WordPress an die richtige Stelle wieder hochladen.

Die fehlende Datei wp-config.php sollte man in Deinem Fall manuell auf Basis der dann wieder vorhandenen wp-config-sample.php neu erstellen (Inhalt von wp-config-sample.php in wp-config.php kopieren, Datenbank Zugangsdaten einfügen) und im Anschluss ein neues Kennwort für den Admin setzen (über den "Passwort vergessen" Link bei der Anmeldung). Warum manuell? Wenn man den automatischen Installationsassistenten von WordPress neu ausführt, kann es sein, dass bestehende Daten in der Datenbank überschrieben werden.

Was hast Du denn gelöscht?

Welche Dateien und Ordner befinden sich jetzt im Ordner [FONT=Courier New]/www/htdocs/w0185e44/natuerliche-abnehmhilfe/ [/FONT]auf dem Server?

Du solltest schon wissen, woher die Screenshots von Webseiten und Dateien kommen, die Du hier postest.

Alle anderen können nur raten.

[plain]Wenn Deine Kunden nach dem Anklicken eines Links (wo/welcher?) auf czotra-32.com geleitet werden und/oder file-upload.net HTML-Seiten herunterladen, könnte z.B. Deine Installation gehackt sein.[/plain]

Vielleicht will jemand anders weiterraten... bin raus.

Aha. [plain]Was haben die Screenshots von czotra-32.com und einer lokal gespeicherten Datei von file-upload.net damit zu tun?[/plain]

Zitat von Fluffi

Keine Ahnung, welche Seite du meinst. Gebe ich meine Shop-Adresse in deinem Link ein,

1. Wie ist die Shop-Adresse?
   
2. Dein Anhang screenshot-2018-09-11-14-13-35.png kommt von [plain]czotra-32.com[/plain]
   
3. Dein Anhang screenshot-2018-09-11-14-13-41.png ist eine lokal gespeicherte Datei von [plain]file-upload.net[/plain]

Die angegebene Seite ist z.B. bei Google als "mit Malware verseucht" gespeichert: [plain]https://transparencyreport.google.com/safe-browsing/…l=czotra-32.com[/plain]

Was hat der Screenshot einer lokalen Datei, die von file-upload.net gespeichert wurde, damit zu tun?

Inwiefern "geht nicht"? Was genau erscheint, wenn Du versuchst, das Plugin zu deaktivieren?

Um Jetpack wieder loszuwerden, lösche den Ordner [FONT=Courier New]wp-content/plugins/jetpack/[/FONT] über einen FTP-Zugang.