Beiträge von b3317133

Schau Dir mal Relevanssi an, oder zum Anschauen die "free" Version.

Setze [FONT=courier new]WP_SITEURL[/FONT] und [FONT=courier new]WP_HOME[/FONT] per FTP via wp-config.php

Zitat von Draggy

Also z.B. ein Formularfeld, wo man Text eingeben kann, welcher dann nur auf der Beitragsseite angezeigt wird, danach kommt dann automatisch der Link zum Beitrag selbst ("weiterlesen"). Im Beitrag selbst kommt dann der Text des ersten Formularfeldes gefolgt von dem Text, welcher in einem zweiten Formularfeld eingegeben wird und ...

Man kann im normalen Formularfeld von WordPress über den Button "Weiterlesen-Tag einfügen" (drei Linien übereinander, die mittlere gestrichelt) die Trennung des Textes in zwei Teile und damit auch das automatische Einfügen von "Weiterlesen.." für Besucher des Websites manuell bestimmen. Evtl. hilft das auch ohne sonstige Anpassungen schon etwas weiter.

Zitat von Ka1ry

und könntest du mir sagen was ich da genau ändern muss damis das plugin nicht drauf greift ?

Zitat von Ka1ry

Oder kann ich diese funktion einfach auskommentieren (also diese random zahlen) ?

Weder eine Änderung noch eine Auskommentierung wird dazu führen, dass WordPress einen Benutzernamen ein zweites Mal anlegt bzw. anlegen kann. Jeder Benutzername kann nur einmal vorkommen.

Das macht das Plugin. Es benutzt dabei vorher eine Funktion von WordPress, um herauszufinden, ob ein Benutzer bereits existiert.

Ein kurzer Blick in eine zufällig hier vorhandene ältere Version des Codes zeigt, dass unter bestimmten Umständen bei jeweils via username_exists() ermitteltem existierendem Benutzernamen dieser z.B. über [FONT=courier new]$username = $username.time();[/FONT] ergänzt oder z.B. in der Funktion [FONT=courier new]unique_user()[/FONT] über [FONT=courier new]$username = $username . $r1 . $r2;[/FONT] zwei Zufallszahlen an den Benutzernamen gehängt werden.

Es gibt noch weitere diesbzgl. Tickets, würde eine Kontaktaufnahme mit dem Autor empfehlen. Den Support für ein Kaufplugin kann man in der Regel auch verlängern...

Der Permalink in WordPress wird in "Einstellungen" -> "Permalinks" eingestellt, dort wurde das Datum offenbar entfernt. Vermutlich war früher mal "Tag und Name" eingestellt.

Gibt es den User "Test" evtl. schon? Lt. diesem Ticket könnte es auch an einem anderen, gleichzeitig genutzen Plugin liegen...

Die URL-Struktur in WordPress wurde offenbar nachträglich verändert, z.B. enthielt zum Zeitpunkt des Teilens des Beitrags "Novemberrosen und Kiwanos probieren" der Link das Datum "2017/11/15/", inzwischen aber nicht mehr. Facebook und andere soziale Medien behalten den beim Teilen mitgeteilten Link bei.

Auch hier könnte (abgesehen davon, dass die Zeiten der meta Keywords nach Meinung vieler eindeutig vorbei sind) das Lesen der Dokumentation von Yoast SEO helfen.

Der Fehler tritt lt. Fehlermeldung interessanterweise nicht in der Datei page.php des Themes von WordPress auf, sondern (siehe auch Hinweis von Edi) im Bereich des gambio Shops:[FONT=courier new] /www/htdocs/w[...]/html/insiderasia/gambio/blog/page.php [/FONT]was auf eine unerwünschte Wechselwirkung hinweist.

Bei der Datei page.php des Themes als Grund müsste als Quelle wohl eher [FONT=courier new]/www/htdocs/w[...]/html/insiderasia/gambio/blog/wp-content/themes/68ccb4ff-a99b-4d42-aae2-bcdd6c8e2f89/page.php[/FONT] erscheinen.

Im zitierten Code ist das [FONT=courier new]target="_blank"[/FONT] bereits drin.

Ansonsten würde man das über den im Code aufgeführten Filter [FONT=courier new]responsive_social_skin[/FONT] in der Datei [FONT=courier new]functions.php[/FONT] des Child Theme ergänzen können, z.B. so ähnlich (ungetestet):

function b3317133_responsive_social_skin( $html ) {
    $html = str_replace(
        'a href="',
        'a target="_blank" href="',
        $html
    );
    return $html;
}
add_filter( 'responsive_social_skin', 'b3317133_responsive_social_skin' );

Zitat von irmen

es ist aber schon richtig, dass ich das childtheme einsetze, damit die änderungen beim Update nicht überschrieben werden, oder?

Ja.

Zitat von irmen

Das heißt sämtliche Änderungen mache ich im Childtheme, oder?

Ja.

Zitat von irmen

Das heißt, das locate_template() bzw. get_template_part() wird irgendwo im CHildtheme gesetzt, oder?

Nein, das müsste im Parent Theme (Haupttheme) verwendet werden.

Zitat von irmen

Kann ich nicht in der functions im Childtheme mit remove_die_doppelt_aufgerufene_datei arbeiten?

Nein. Manche Parent Themes umfassen überschreibbare einzelne Funktionen mit einer [FONT=courier new]function_exists()[/FONT] Abfrage, aber da Du einen "weissen Bildschirm" bekommst, ist das offenbar bei den gewünschten Funktionen nicht der Fall.

Würde vorschlagen, in diesem Fall den Autor des Parent Theme zu kontaktieren und nachzufragen, wie/ob/welche Möglichkeiten es gibt, die gewünschten Funktionen anzupassen. Manchmal gibt es auch sog. Filter, über die man Ausgaben anpassen könnte usw., das kommt aber auf den Einzelfall des Themes an.

Zitat von maxsei

Hier die Meldung aus dem Log für WordPress.

... "found in file "/www/htdocs/wVERTRAGSNR/DOMAINs.de/wp-includes/images/smilies/imhnvcxx.php"

Eine Datei [FONT=courier new]/wp-includes/images/smilies/imhnvcxx.php[/FONT] gibt es in WordPress nicht, diese dort hinterlassene PHP-Datei ist mit Sicherheit als schädlich einzustufen und ein klares Anzeigen für eine auch weitergehend gehackte Installation. Um das festzustellen, braucht man keinen Scanner...

Das als "false positive" o.ä. zu bezeichnen, kommt daher nicht in Betracht.

Ob der eigentliche Hack über ein z.B. altes WordPress, ein Theme oder ein Plugin kam, oder aber über ein ganz anderes PHP-Script oder über ein geklautes/zu einfaches FTP-Kennwort o.ä., kann man anhand dieses Logs nicht feststellen.

Die Herkunft/Ursache des Hacks ist wohl das, was all-inkl gern geklärt hätte. Denn mit einem älteren einfach nur neu eingespielten Backup wird sich der Hack garantiert wiederholen...

Evtl. noch ergänzend, der eigentlich im WordPress Sinn richtige Ansatz für ein Parent Theme (Haupttheme), eine Überlagerung durch Child Themes zuzulassen, wäre die Verwendung von locate_template() bzw. get_template_part()

Diese "verschiedenen Methoden" waren leider alle grundfalsch, daher führte das auch zu nichts.

Würde für eine Fehlersuche eins nach dem anderen alle Plugins aber v.a. erstmal diese "Sicherheits"-Plugins abschalten, gerade wenn es noch dazu mehrere gleichzeitig sind.

Wo genau kann man denn die nicht funktionierende 404 Seite mal ansehen?

Um Dateien mit Hilfe eines Child Themes überschreiben zu können, muss das Parent Theme entspr. darauf vorbereitet sein.

Der o.g. zitierte Code des Parent Themes (Hauptheme) ist nicht darauf vorbereitet.

Im Haupttheme müsste [FONT=courier new]get_stylesheet_directory()[/FONT] anstelle von [FONT=courier new]get_template_directory()[/FONT] verwendet werden, dann würde WordPress die entspr. Datei im Childtheme falls vorhanden automatisch finden und ohne extra [FONT=courier new]require(..)[/FONT] im Child Theme nutzen (sofern das Parent Theme nicht noch anderen Unsinn macht, der aus dem Codeteil aber nicht ersichtlich ist).

Die "weisse Seite" kommt daher, dass Funktionen durch den aktuell falschen Ansatz doppelt definiert werden und diese Doppeldefinitionen einen PHP-Fehler verursachen. Das könnte man im entspr. error.log sehen.

Man könnte z.B. via [FONT=courier new]wp_footer()[/FONT] o.ä. ein JavaScript ergänzen, das z.B. je nach "hash" oder GET-Parameter in der URL den in WordPress genutzten HTML5-Player entspr. ansteuert, die API gibt es z.B. hier.

Ggf. ist "Yoast" -> "Dashboard" -> "Funktionen" -> "Erweiterte Einstellungen" abgeschaltet.

Mehr dazu in der Dokumentation von Yoast SEO.