Beiträge von b3317133

Es kommt darauf an, in welchem Kontext der Schieberegler, auch genannt "Range Slider" o.ä. erscheinen soll.

Zusammen mit dem Plugin "Contact Form 7" gibt es nach kurzer Recherche im wordpress.org Plugin Repository z.B. dieses Plugin oder für "Gravity Forms" dieses Plugin (beides von mir ungetestet), darauf könnte man ggf. aufbauen.

Um es genau so wie im verlinkten Beispiel umzusetzen, ist vermutlich mit allen Plugins noch etwas extra JavaScript-Programmierarbeit erforderlich.

Es kommt immer auf Deine restliche Seite, also das Theme, alle Plugins und auch alle Inhalte an, wie ist was programmiert und eingebunden.

In WordPress gibt es keine zentrale Stelle für Cookies o.ä., das heisst Du musst alles komplett selbst prüfen und ggf. auch diversen Code anpassen, damit so ein "Opt-In" Plugin dann funktionieren kann.

Viele installieren irgendein Cookie-Plugin, das "ihnen empfohlen" wurde, das zeigt dann zwar einen nervigen Banner an, ob man "Zustimmen" oder "Ablehnen" oder nichts anklickt ist aber oft egal, weil das Plugin nicht mit dem restlichen Code zusammenarbeitet und trotz jeglicher Auswahl munter Cookies gesetzt oder externe Dinge eingebunden werden.

Eine gute Alternative ist die Beauftragung einer professionellen Websitebetreuung, die ggf. durch Code-Anpassungen sicherstellt, dass technisch alles sauber zusammenarbeitet, und zwar für jedes einzelne Theme-/Plugin-/Inhalts-Update wieder und immer wieder.

Die beste Alternative ist es, erst gar keine Cookies und externe Einbindungen zu nutzen, das geht bei erstaunlich vielen Seiten einwandfrei. Wenn man einen Onlineshop oder Inhalte nur für Mitglieder o.ä. hat, wird es schwerer.

Dieser Filter wird genutzt wenn die Registrierung über WordPress erfolgt.

Falls - wie ein Besuch der Seite [FONT=Courier New].../registrierung/[/FONT] vermuten lässt - eigener Code verwendet wird, z.B. ähnlich wie hier über Contact Form 7, musst Du den eigenen Code anpassen oder Dich alternativ an die Person wenden, die den Website eingerichtet hat.

PS. Die Seite hat noch so ein paar Probleme, z.B. wird u.a. PHP-Code ausgegeben:

<div class="aa_logout">
            Hallo [xxx]
            </br>         
            Du bis bereits angemeldet.
        </div>


        <a id="wp-submit" href="<?php echo wp_logout_url(); ?>" title="Abmelden">
            Logout
        </a>

.page .page-wrap .content-wrapper {
    padding-top: 0;
}
.page .entry-header {
    margin-bottom: 0;
    /* alternativ: display: none; */
}

Auf Nebenwirkungen auf anderen Seiten testen...

Lt. Google Cache war der alte Link im Menü unter "Start > Einloggen" dieser hier:

https://vfl-bleckede.de/wp-login.php?loggedout=true

Der funktioniert derzeit aber ebensowenig wie der aktuelle im Footer.

Vermutung: Es läuft ein Plugin, das den Login "versteckt", was am Rande bemerkt relativ sinnlos ist, siehe z.b. auch hier.

Mögliche Lösung: Deaktivieren dieses Plugins durch Umbenennen des entspr. Plugin-Ordners in /wp-content/plugins/ und das Auskommentieren oder Entfernen ggf. zugehöriger vorhandener Reste in .htaccess Datei(en).

Zitat von RayyJayy

Seit heute wird meine WP-Website nicht mehr korrekt angezeigt.

Vermutlich wurde die PHP Version des Servers verändert.

Zitat von RayyJayy

Kann man im Seitenquelltext erkennen, warum die Darstellung falsch ist?

Quelltext anzeigen > ans Ende scollen:

...
<img alt="" border="0" src="https://www.paypalobjects.com/de_DE/i/scr/pixel.gif" width="1" height="1" align="top"></form></div></div></aside><br />
<b>Warning</b>:  preg_match(): Compilation failed: invalid range in character class at offset 11 in <b>/var/www/web89/htdocs/wp-content/plugins/wysija-newsletters/helpers/render_engine.php</b> on line <b>526</b><br />
<br />
<b>Warning</b>:  preg_match(): Compilation failed: invalid range in character class at offset 11 in <b>/var/www/web89/htdocs/wp-content/plugins/wysija-newsletters/helpers/render_engine.php</b> on line <b>526</b><br />
<br />
<b>Warning</b>:  preg_match(): Compilation failed: invalid range in character class at offset 11 in <b>/var/www/web89/htdocs/wp-content/plugins/wysija-newsletters/helpers/render_engine.php</b> on line <b>526</b><br />
<br />
<b>Fatal error</b>:  Uncaught Exception: Template 'templates/form/web/widgets/#type.html' not found ! in /var/www/web89/htdocs/wp-content/plugins/wysija-newsletters/helpers/render_engine.php:723
Stack trace:
...
#5 /var/www/web89/htdocs/wp-content/plugins/wysija-newsletters/widgets/wysija_nl.php(285): WYSIJA_view in <b>/var/www/web89/htdocs/wp-content/plugins/wysija-newsletters/helpers/render_engine.php</b> on line <b>723</b><br />
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="de-DE">
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <meta name="viewport" content="width=device-width">
        <meta name='robots' content='noindex,follow' />
    <title>WordPress &rsaquo; Fehler</title>
...

Offenbar funktioniert im Sidebar ein Plugin "wysija-newsletters" nicht (mehr) richtig. Deaktiviere mal das Plugin.

Der hier gesuchte Filter sollte wohl eher [FONT=Courier New]wp_new_user_notification_email[/FONT] heissen, nicht [FONT=Courier New]wp_new_user_notification_email[COLOR=#ff0000]_admin[/COLOR][/FONT]...

Am Rande bemerkt, dieser Semikolon kann nicht die (Haupt)ursache gewesen sein, gängige Browser benötigen kein Semikolon nach dem letzten Element in einer Klasse, Beispiel hier.

Evtl. wird noch ein Optimierungsplugin o.ä. genutzt, das damit nicht klarkommt, oder es gab noch eine weitere Ursache. Ohne Link zur Seite kann man sowas nicht sinnvoll beantworten.

Falls das der besagte Website ist, nutzt dieser Schutz wenig, da die REST-API und xmlrpc aktiv sind und man dadurch den Benutzernamen sehen und Passwörter raten kann, so wie nahezu alle Bots das machen. Im Gegenteil, der aktuelle Schutz kann sogar kontraproduktiv sein, da er auch /wp-admin/admin-ajax.php Aufrufe blockiert.

Erstelle für eine spätere Analyse durch die Person, die den Website eingerichtet hat, ein Backup der .htaccess.

Dann entferne alles aus der .htaccess im Hauptverzeichnis des Websites ausser Basic WP wie hier beschrieben (falls WordPress Multisite genutzt wird, entspr. die Hinweise weiter unten auf der Seite beachten).

Was bedeutet "weisse Seite mit Powered by Wordpress"? Link? Screenshot?

Laufen irgendwelche "Login verstecken" Plugins o.ä.? Falls ja, siehe z.b. auch hier.

Ergänzend: Falls eine .htaccess im /wp-admin/ Ordner angelegt wurde und hier das Problem liegt, erstelle ein Backup und entferne diese Datei.

Du kannst im PHP Error-Log des Servers nachlesen, was den "Fehler 500" verursacht hat. Das Log findest Du im Regelfall im Loginbereich des Hostinganbieters, ggf. den Hostingsupport fragen wo genau.

Tipp am Rande: Wenn man mit irgendwelchen Daten einen Account registriert, sollte a) der Account nicht direkt sofort aktiv sein und b) ggf. auch die E-Mail validiert werden... :rolleyes:

Ergänzung: Die Mitgliedseite mit fehlenden Daten nach Login erscheint im Netzwerktab ohne Status Code mit Hinweis [FONT=Courier New](raced)[/FONT], erst nach Reload / F5 wird sie dann vom Server neu mit den Daten geladen. Offenbar also ein Cache-Problem, evtl. kann man in Ultimate Member da was ab-/umstellen o.ä.

Versuche es mal mit dem Plugin Classic Editor.

Zitat von Lars Schmidt

Gehts auch vielleicht irgendwie einfacher ? o_O

Ja, wenn Du jemanden damit beauftragst, der sowas täglich macht.

Alternativ jeden einzelnen Punkt der o.g. Liste recherchieren, ausprobieren, dazu nachlesen und selbst dazulernen.

Wie genau sieht der Hosting-Anbieter einen Virus o.ä. bei Dir?

PS. Plugins, wie in Deinem Fall Wordfence und Cerber, die sich in den Funktionen überschneiden, gleichzeitig zu nutzen, macht wenig Sinn und bringt eher Probleme mit sich.

Kannst Du das Video als .mp4 in WordPress auf Deinen Server laden? Dann hättest Du schonmal keine DSGVO-Probleme...

Das wichtigste sind starke Passwörter. Mehr zu diesen "Bots" hier.

WordPress Core, Theme, Plugin Dateien kann man per FTP herunterladen und lokal mit sauberen frischen Archiven abgleichen, dafür gibt es sog. "diff" Programme, z.B. für Windows ExamDiff Pro, WinMerge o.ä.

Zugangsdaten prüft man nicht auf Viren, man ändert sie beim Hosting-Anbieter und die Datenbank-Zugangsdaten zusätzlich noch in der Datei wp-config.php

Das allgemeine Vorgehen mit allen notwendigen Schritten bei einem Hack ist z.B. hier beschrieben.

Einen allgemeinen Scan "von aussen" kann man z.B. via sitecheck.sucuri.net oder virustotal.com o.ä. machen, aber wenn da nichts angezeigt wird, heisst das noch lange nicht, dass alles auch sauber ist.

Wie genau siehst Du einen Virus o.ä. bei Dir?

Die einzige Stelle, wo die Datenbank geändert werden muss, in in wp-config.php

Entferne die Einträge von WordFence aus der .htaccess oder falls vorhanden php.ini o.ä., daher dürfte der Fatal Error kommen.

Die Domain passt man 2x in der Datenbank an, mehr dazu unter "WordPress Umzug" in der Forumsuche oder Suchmaschinen. Danach passt man alle Links in der Datenbank über ein Plugin wie "Better Search Replace" an, auch hierzu mehr in der Forumsuche oder Suchmaschinen.

Generell hätte man statt allem was gemacht wurde, eher ein Duplikator Paket der Hauptdomain erstellen und auf der Subdomain installieren sollen/können. Alternativ mit einem ähnlichen Clone-Plugin. Damit würde alles automatisch angepasst bzw. abgefragt.

Wenn Design > Widgets gemeint ist, das steckt u.a. mit in der Capability [FONT=Courier New]edit_theme_options[/FONT].

Zitat von ProduktiverPanda

Ich hoffe es gibt jemanden, der mir diese spezielle Frage beantworten kann..

Vermutlich wäre das ein Anwalt, der sich mit Preisauszeichnungen auskennt...