@SirEctor: Wenn keine Rolle angegeben ist, deutet es darauf hin, dass entweder ein Account mit [FONT=Courier New]wp_create_user(..)[/FONT] angelegt wurde, aber noch [FONT=Courier New]..->set_role()[/FONT] fehlt, oder dass jemand den Account z.B. über eine SQL-Injection unvollständig direkt in die Datenbank geschrieben hat.
Beiträge von b3317133
-
-
Sieht nach klassischem Hack aus. Ob das durch die neuen Plugins kam, kann man "von aussen" kaum sagen. Wurden die Plugins aus dem offiziellen Repository installiert oder aus irgendeiner anderen Quelle?
Als erstes mal ein Komplettbackup erstellen, alle Dateien im Webspace und die Datenbanken, für spätere Analysezwecke.
Hier eine Kurzbeschreibung wie es dann weitergeht.
Zum Thema "hoffentlich 'nur' ein Troll", sobald Dritte solche Accounts anlegen können, ist praktisch die komplette Installation als kompromitiert zu betrachten.
-
-
Mir ist jedoch aufgefallen, dass beim WordPress Login meine E-Mail Adresse nicht vorgeschlagen wird.
Dann stelle in Firefox ein, dass der Browser Login-Informationen speichern soll. Das hat mit WordPress nichts zu tun.
Außerdem bekomme ich ständig E-Mail von Wordfence, dass sich jemand (Ich) mit Admin Rechten eingeloggt hat.
Das liegt einfach daran, dass bei Dir in Wordfence bei "Alert me when someone with administrator access signs in" ein Haken gesetzt ist.
-
Wird denn "test" ausgegeben, wenn das Seiten-Template benutzt wird? Stimmt der Dateiname der Templatedatei exakt mit dem Parameter überein? Liegt die Datei ggf. in einem Unterverzeichnis, dann muss das Verzeichnis mit in den Parameter, siehe auch Beispiele im Codex. Evtl. hilfreich wäre ein Link zu einer Seite mit so einem Template oder die Angabe, was genau im body-Tag auf einer Template-Seite als class="xxx" ausgegeben wird?
-
Da gibt es viele Möglichkeiten je nach weiterem Context, würde wahrscheinlich sowas nehmen:
-
Schau Dir mal is_page_template() im Codex an.
-
Das über Plesk zu machen, halte ich für sehr ambitioniert. Viel Erfolg.
Alleine schon dieser eine Punkt ist bzgl. Plesk ein "no-go" bzw. nicht nachvollziehbar für mich, ob das wirklich so der Fall ist:
Außerdem macht es mir immernoch Kopfschmerzen, dass ich Wordpress erst im laufenden Betrieb deinstallieren muss, bevor ich die Domain umschalten kann.
Die von mir beschriebene Variante zielt darauf ab, dass man jederzeit einen Rollback zum Original machen kann, wenn beim nächtlichen aktuellen Klon, Integration der Änderungen und Launch was nicht klappt wie gedacht, ganz einfach weil das Original unangetastet bleibt.
Lediglich das Mapping der (Sub)Domains auf den jeweiligen Ordner wird dann via Plesk gemacht, keinerlei Eingriffe in die Daten.
-
Was ist wenn man im Impressum darauf hinweist, dass Google Fonts verwendet werden? Das selbe wäre ja noch mit Google Maps?
Das muss man in der Datenschutzerklärung aufführen, es gibt viele, viele Seiten dazu in Suchmaschinen, am besten aber für den Einzelfall einen passenden Anwalt befragen.
-
.. im Bezug auf Jquery wo "immer" externe Links/Dienste/Scripts etc. geladen werden.
Das stimmt so nicht.
WordPress lädt jQuery vom gleichen Server. Nur wenn man irgendwelche Optimierungs- oder CDN-Plugins verwendet, oder obskure Code-Schnipsel aus alten Tutorials verwendet, die jQuery extern laden, oder ein Plugin/Theme selbst externe Scripts verlinkt, mag das anders sein.
-
Schau mal hier in der WP-Optimize Beschreibung im Bereich FAQ: Unterstützt WP-Optimize InnoDB-Tabellen?
-
Ein automatisiertes, einfaches "Zusammenbringen" der beschriebenen Inhalte ist mit WordPress sehr schwierig, und out-of-the-box gibt es dazu keine Lösung.
Würde es wohl so lösen, Kurzversion ohne Details:
Wie beschrieben einen Klon auf Subdomain installieren, dort entwickeln, alles gut dokumentieren. Am Stichtag nachts weiteren Klon des Live Websites mit den dann aktuellen Daten auf eine zweite Subdomain kopieren, die entwickelten Änderungen anhand der eigenen Dokumenation dort in einem Rutsch einpflegen, testen, und diesen Klon dann auf die Hauptdomain schalten.
Dazu genau nachlesen, wie ein WordPress Wechsel zwischen Subdomains gemacht wird, z.B. wie man Better Search Replace u.ä. nutzt, dazu gibt es viele Threads hier im Forum.
Würde für sowas generell manuelle WordPress Installationen verwenden, keine Plesk-Funktionen, das verkompliziert die Sache noch mehr.
-
Ist es möglich, ob man auf einer aktuell laufenden Website ein weiteres Theme installiert, und zeitgleich im Hintergrund dieses so anpasst, mit Beitragen, Slide , Formular usw. , dass ich dies nur noch sichtbar machen muss.
Nein.
Man benötigt dafür eine zweite WordPress Installation, z.B. eine Kopie des aktuellen Websites auf einer Subdomain, die man nach Abschluss der Anpassungen dann unter der Hauptdomain live schaltet.
-
Was macht dieses Plugin denn? Geht aus der Beschreibung leider so gar nicht hervor.
Nach kurzem Blick in den Code fügt es wohl irgendwo eine Checkbox ein und verlinkt ansonsten auf die Herstellerseite des Plugins, getestet nur bis WordPress 4.7.10, sieht gesamt nach Werbung aus.
-
Verwende den o.g. Ansatz i.v.m. einem passenden posts_where Filter. Dafür sollte man sich etwas mit WordPress und PHP auskennen bzw. die Dokumenation genau lesen, eine einfache Copy & Paste Lösung ist da anhand der bisher bekannten Eckdaten eher nicht sinnvoll möglich.
-
Schau mal ins Netzwerk-Tab, evtl. sieht man da, wo der 400 herkommt.
Das ein Fehler auf dem einen Gerät erscheint und auf dem anderen nicht, könnte mit Media-Queries ö.ä. zu tun haben..
-
Auf dem Screenshot ist in der letzten Zeile ein Error 400 zu erkennen, dem würde ich mal auf den Grund gehen.
Laufen irgendwelche Cache- oder Minify-Plugins?
-
Ein interessanter Effekt, normalerweise überstimmen solche "define" die Datenbank-Einträge. Danke für das Feedback.
Und für Mitleser, das eigentliche Problem hier lag offenbar nicht direkt an der genannten Umstellung auf https sondern an einer unvollständigen Umstellung der Test-/Entwicklungsdomain auf die echte Domain. Gesamt ein schönes Beispiel, wie man Fehler erkennt und dann mögliche Ursachen eine nach der anderen der Reihe nach ausschliesst.
-
Ich habe jetzt erstmal in die header.php eine Zeile eingefügt .,,. Aber das kanns ja eigentlich nicht sein..
Das ist es auch nicht, das ist eher kontraproduktiv, bzw. direkter gesagt, es scheint zu funktionieren, ist aber einfach falsch und wird früher oder später andere Probleme verursachen.
Finde besser raus, wo der ..swh.strato-hosting.eu Link herkommt.
Deaktiviere z.B. temporär alle Plugins, und schau Dir dann den Quelltext der Seite mal an (ca. Zeile 16), ob da nach wie vor falsch verlinkt wird. Startseite jeweils neu laden, Tastenkombi. "Strg-U" oder "rechte Maustaste -> Seitenquelltext anzeigen".
Falls ja, liegt es am Theme bzw. Child-Theme und die Suche geht dort weiter, vermutlich in der functions.php o.ä.
Falls der Link weg ist, liegt es an einem Plugin, dann weiter durch schrittweises einzelnes Aktivieren eingrenzen, welches Plugin verantwortlich ist.
-
jQuery wird nicht geladen, der Link zeigt aus welchen Gründen auch immer auf [plain]https://59[XXXX]11.swh.strato-hosting.eu/wp-includes/...[/plain]
Das fehlgeschlagene Laden und die darauf folgenden Fehler sieht man in der Browser Console ganz gut.