Was klappt nicht? Lediglich das [FONT=Courier New]top:[/FONT] ist ggf. etwas zu wenig für die verwendete Schriftgrösse und das [FONT=Courier New]margin-top:[/FONT] sollte wg. der Verwendung von [FONT=Courier New]margin:[/FONT] im [FONT=Courier New]style[/FONT] Attribut mit einem [FONT=Courier New]!important[/FONT] versehen werden.
Beiträge von b3317133
-
-
Da [FONT=Courier New]'jquery'[/FONT] als dependency Parameter angegeben ist, sollte es a) vorher geladen weden und b) funktionieren. Link zur Seite?
-
Definitive Aussagen kann man nur durch einen Audit aller Dateien nach jedem Update (und vor jeder Installation) jedes Plugins und/oder Themes machen - also zuerst die entspr. .zip Datei direkt runterladen, entpacken, den gesamten Code manuell prüfen.
-
Werden die Daten dauerhaft von api.wordpress.org gespeichert ..
Keine Ahnung, was dort gespeichert wird, entspr. Angaben lt. DSGVO / GDPR haben wir bisher nirgends gefunden. Da musst Du also die Betreiber des Servers ausfindig machen und dort direkt fragen.
.. wenn man die E-Mail zum Beispiel nicht überall hinsenden möchte. Unterbinden könnte man das ja nicht, ..
Standardmässig wird die hinterlegte E-Mail in WordPress nicht versendet. Falls sowas in ein Plugin einprogrammiert wäre, könnte man es unterbinden, indem man das entspr. Plugin nicht installiert.
Könnte man das auch mit dem Log HTTP Requests Plugin überprüfen?
Wenn was "an der HTTP API von WordPress vorbei" aufgerufen / gesendet wird, nein.
Ergänzend: Ein weiteres Plugin für das Monitoring der HTTP API wäre z.B. Snitch.
-
Man nimmt irgendeine vorhandene (Sub-)Domain und eine neue Datenbank, lädt die Dateien in den Domain-Ordner hoch, spielt die Datenbank-Datei z.B. via phpMyAdmin / Import in die neue Datenbank ein, passt die Datenbank Zugangsdaten in [FONT=Courier New]wp-config.php[/FONT] an, trägt zudem in [FONT=Courier New]wp-config.php[/FONT] z.B. direkt unter der Zeile mit WP_DEBUG die Zeile
[FONT=Courier New]
define( 'RELOCATE', true );[/FONT]ein, und dann öffnet man im Browser direkt [plain]irgendeinevorhandenedomain.de/wp-login.php[/plain] und meldet sich an.
-
Evtl. ist auf Deiner Diskstation kein Mailserver für den Versand eingerichtet.
Du könntest in dem Fall den Mailversand von WordPress mit Hilfe eines der SMTP Plugins über einen ggf. vorhandenen anderen externen SMTP Server konfigurieren o.ä.
Weiterhin scheint ein Captcha-Plugin o.ä. zu laufen, das bei Registrierung eine Rechenaufgabe abfragt. Solche und alle sonstigen Sicherheitsplugins sollte man temporär deaktivieren, wenn es um das Debugging von Mailversand usw. geht.
Ergänzung: Ein kurzer Test mit einer [plain]10minutemail.com[/plain] E-Mail inkl. Rechenaufgabe soeben ergab, dass die Registrierungsmail zur Vergabe eines Passworts korrekt verschickt wird und die Registrierung also wie gewünscht klappt. Den Benutzer "o8733646" kannst Du wieder löschen...
Problem scheint also gelöst.
Evtl. lag/liegt es auch an Deiner GMX-Email als Absender, manche Mailserver akzeptieren keine E-Mail ausserhalb der aktuellen Website Domain o.ä., oder E-Mail mit entspr. "unstimmigen" Headern landet beim Empfänger durch entspr. Scripts autom. im Spam, das hat aber nicht direkt mit WordPress zu tun.
-
Bei der Installation eines Plugins wird die aktuelle WordPress Version, der Link zur WordPress Startseite und der komplette Serverpfad /var/www/... an api.wordpress.org übertragen.
Bei der regelmässigen Überprüfung auf Updates für Plugins wird die WordPress Version, die PHP-Version, die MySQL-Version, die Sprache, ob Mutlisite, die Bloganzahl, die Benutzeranzahl, der Link zu Startseite und Blogseite, der komplette Serverpfad, von allen Plugins die Namen, Autornamen, Beschreibung usw. an api.wordpress.org übertragen.
Beim Download eines Plugins noch dazu der Pfad zum Temp-Verzeichnis auf dem Server (warum auch immer).
Die o.g. Zugriffe erfolgen über die offizielle HTTP API von WordPress und man kann sie sich z.B. mit Plugins wie Log HTTP Requests ansehen.
Wenn was "an der HTTP API vorbei" aufgerufen wird, also z.B. per PHP curl oder file_get_contents o.ä., dann ist das von WordPress aus schwer/nicht zu tracken.
An den jeweiligen Plugin-Anbieter geht standardmässig keine Info ausser das ist im Plugin einprogrammiert, z.B. beim Aktivieren oder für Pro-Version Prüfungen usw.
Definitive Aussagen kann man aber nur durch einen Audit aller Dateien nach jedem Update jedes Plugins und/oder Themes machen.
-
Am Rande bemerkt, die Funktion [FONT=Courier New]wp_new_user_notification( .. )[/FONT] ist "pluggable", d.h. man kann sie über ein Plugin oder Theme komplett überlagern.
Ergänzung: Sehe gerade im Code, seit WordPress 4.9 gibt es alternativ auch einen Filter [FONT=Courier New]wp_new_user_notification_email[/FONT] mit einem Daten-Array als Parameter, wodurch Anpassungen auch einfacher möglich sind.
-
Was war denn die Lösung? Evtl. haben andere Mitleser eines Tages das gleiche Problem.
-
-
Hast Du schon in der Anleitung des Themes geschaut?
Und was sagt der Theme-Support?
Es handelt sich offenbar um ein Kauftheme, daher kann man als Aussenstehende(r) nicht einfach so in den PHP-Code schauen.
-
Bevor ich es teste, was genau bewirkt das?
Das bewirkt einen 301 Redirect, den Du ja nicht willst, warum auch immer.
Ein simpler "Hack" wäre sowas in der Art, ohne Gewähr für ggf. daraus resultierende andere Probleme...
-
Alternativ das Plugin "Classic Editor" nutzen, siehe z.B. hier.
-
Browser Cache zwischenzeitlich mal geleert? Linkt zu Seite?
-
Würde mal folgendes versuchen, um das weiter einzugrenzen:
In der Datei [FONT=Courier New]wp-content/themes/graphene/inc/loop.php[/FONT] bei ca. Zeile 1145 in der Funktion [FONT=Courier New]graphene_header_image()[/FONT] eine Zeile [FONT=Courier New]if ( ! $header_img ) return;[/FONT] einfügen:
Vorher:
Codeif ( ! $graphene_settings['slider_as_header'] ) { $header_img = graphene_get_header_image( $post_id ); } else { $header_img = get_header_image(); if ( ! $header_img ) return; $alt = get_bloginfo( 'name' ); }
Nachher:Codeif ( ! $graphene_settings['slider_as_header'] ) { $header_img = graphene_get_header_image( $post_id ); if ( ! $header_img ) return; } else { $header_img = get_header_image(); if ( ! $header_img ) return; $alt = get_bloginfo( 'name' ); }
Erscheint dann noch die <img test="1" ... Zeile im HTML Code? -
-
Apache 2.4.37 vom 18.10.2018 wäre aktuell, auf dem Server läuft Apache 2.4.25 vom 16.12.2016
Autom. Directory Listing kann auch von Nachteil sein, bei manchen Installationen landen auch mal Dinge in /wp-content/uploads/ die man nicht gelistet haben will usw.
-
Könnte an der über 2 Jahre alten Apache Version liegen, vielleicht hat sich ja jemand eingeschlichen... Und das autom. Directory Listing könnte man noch abschalten, siehe z.B. [plain]deinedomain.de/wp-includes/[/plain] usw.
-
- Auf dem Server läuft kein PHP, alle PHP-Dateien werden derzeit direkt als Text ausgegeben.
- In der derzeit auch als Text ausgegebenen Datei wp-config.php fehlt am Anfang das Kommentar Startzeichen /**
Also erstmal PHP aktivieren, dann klären wie die index.php so fehlerhaft werden konnte, und klären wohin das Kommentar Startzeichen der wp-config.php verschwunden ist.Alles sehr seltsam... o_O
- Auf dem Server läuft kein PHP, alle PHP-Dateien werden derzeit direkt als Text ausgegeben.
-
Link zur Seite?
Und die eigentliche Frage: Wie konnte die index.php so fehlerhaft werden? Ggf. sollte man alle Systemdateien aus einem frischen Installationsarchiv der gleichen Version wie derzeit installiert überschreiben.