Kann es sein, das auf dem Webspace ein Verzeichnis "hochzeitsdj" gibt?
Dann würde der Webserver versuchen, den Inhalt dieses Verzeichnisses zu laden und wenn dort keine Index-Datei vorhanden ist, gibt es wieder einen "403 Forbidden".
Gruß
Ingo
Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenKann es sein, das auf dem Webspace ein Verzeichnis "hochzeitsdj" gibt?
Dann würde der Webserver versuchen, den Inhalt dieses Verzeichnisses zu laden und wenn dort keine Index-Datei vorhanden ist, gibt es wieder einen "403 Forbidden".
Gruß
Ingo
Ja gut, um welche Menüseite geht es denn?
Ich will jetzt nicht alles durchklicken müssen. :-)
Gruß
Ingo
Ich kann die Seite wieder sehen. :-)
Scheint funktioniert zu haben, braucht halt seine Zeit.
Gruß
Ingo
Ja ich hab mir das dort angesehen, sind leider teilweise eher kontraproduktive Tipps, wie man sieht. Dateirechte sind ein sensibles Thema und die richtige Wahl hängt eben von der Serverkonfiguration ab.
Du kannst aber die dort beschriebene Aktion für Dateien wiederholen und anstelle "640" dann "644" (rekursiv) verwenden.
Gruß
Ingo
Ich würde mal sagen, dass auch die CSS-Dateien, Javascripte und Bilder auf "640" stehen.
Auch diese kann der Webserver deshalb nicht lesen. Das müßte alles geändert werden.
Hmmm...
Hast Du die Rechte für die .htaccess-Datei auf "644" gestellt?
Das ist essenziell, denn sonst "sieht" der Webserver die Datei, kann sie aber nicht lesen. Aus Sicherheitsgründen wird dann der Zugriff gesperrt.
Gruß
Ingo
Und noch eine Frage.
Steht bei der PHP Version im KAS "(Modul)" dahinter? Also "7.1 (Modul)"?
Gruß
Ingo
Ok, Nachtrag. Jetzt habe ich die Fehlermeldung oben gründlich gelesen "...Server unable to read htaccess file, denying access to be safe".
Die .htaccess ist auch nicht lesbar, welche Rechte hat die? Sollte auch "644" sein.
Gruß
Ingo
Die Index.php hat 640!
Das ist auch falsch, bitte hier auch "644" verwenden.
Gruß
Ingo
Die config.php Datei habe ich auf 444 gesetzt!
Du meinst die wp-config.php, oder?
Wie sieht denn die index.php-Datei aus, was für Rechte hat die?
Der Fehler "403 Forbidden" wird auch angezeigt, wenn der Webserver keine der Standard-Index-Dateien (index.php, index.html ...) findet oder nicht darauf zugreifen kann.
Gruß
Ingo
Die letzten drei Kontrollkästchen können vom Besucher deaktiviert werden.
Es sollte eher anders herum sein. Diese drei Kontrollkästchen sollten per Voreinstellung deaktiviert sein und der Nutzer muß sie explizit aktivieren.
Genau so nervig finde ich die Unart, den Button [Alle Cookies akzeptieren] schön farbig hervorzuheben und den Button [Einstellungen übernehmen] unauffällig in dezentem Grau zu halten.
Gruß
Ingo
Das leidige Thema Dateizugriffsrechte.
Welche Rechte funktionieren, häng maßgeblich davon ab, in welchem Kontext (Benutzer) der Webserver/PHP läuft.
Bei All-Inkl wurde lange Zeit PHP als Apache-Modul ausgeführt und lief mit den Rechten des Users "www-data" und falls man das nicht umgestelllt hat, ist es auch immer noch so.
Dadurch kann PHP Dateien mit den Rechten "440" nicht lesen, es müssen also unbedingt Leserechte "444" vergeben werden.
Falls Du Deine PHP-Version also noch nicht umgestellt hast, ist der Tip, die wp-config.php auf "440" zu setzen, falsch und führt zu Problemen. In dem Fall solltest Du die Rechte auf "444" setzen.
Hinweise zu den Unterschieden der PHP-Versionen findest Du im KAS.
Gruß
Ingo
Das sieht mir doch alles nach einem Blog bei Wordpress.com mit extern aufgeschalteter Domain aus.
Wobei die Premium-Version dort 8 Euro im Monat kostet, das sind aber keine 399,00 im Jahr. Es gibt dann noch "Business" für 300 Euro im Jahr.
Wie auch immer, hier im Forum geht es um selbstgehostetes Wordpress. Da könne wird Dir bei Deinem Problem nicht weiterhelfen.
Gruß
Ingo
Vor ca. 2 Wochen, habe ich direkt in WordPressOrg Daten geändert, kann aber leider nicht mehr nachvollzeihen welche.
Was genau meinst Du damit? Oder meinst Du bei wordpress.com?
Bei wordpress.org kann meine meines Wissens keine Daten ändern, bei wordpress.com durchaus.
Man benötigt für die Plugins von Wordpress.com Anmeldedaten und man muß diese Plugins entsprechend aktivieren. Wenn man da die Logindarten ändert, könnte es Probleme geben.
Gruß
Ingo
Ahh ok, Lima-City hatte ich jetzt nicht wirklich als Webhoster auf dem Schirm. Finde ich aber schon seltsam, das der Hoster Cookies setzt, für die ich als Betreiber meiner Website gerade stehen muß. Aber bezogen auf die DSGVO ist das lt. Hilfeseite wohl nicht relevant, weil keine personenbezogenen Daten verarbeitet werden.
Gruß
Ingo
Welcher Webhoster (Massenhoster) ist das denn?
Ein Bot-Sperre ist nicht Aufgabe den Hosters. Ich kenne so etwas z.B. nur als Plugin für Wordpress. Das passiert dann aber auf Applikationsebene und nicht durch das Hosting an sich.
Bei den von mir oben genannten Hostern ist das zumidenst nicht der Fall.
Gruß
Ingo
Technisch notwendig sind bei Wordpress nur Cookies zur Benutzeranmeldung, alles was darüber hinaus an Cookies gesetzt wir, kommt von Plugins, dem Theme oder extern eingebundenen Resourcen. Einem Cookie selbst sieht man erstmal nicht an, wofür es benutzt wird. Also wird man das nicht einfach so erkennen können.
Aber letztendlich mußt Du ja wissen, was bei Deinen Seiten für Plugins und externe Ressourcen verwendet werden. Die sollten auch Informationen betreitstellen, wofür ggf. Cookies verwendet werde.
Und warum machst Du hier einen neuen Thread auf, wenn Du doch schon einen mit dem selben Betreff gepostet hast:
https://forum.wpde.org/threads/dsgvo-…rdpress.190720/
Gruß
Ingo
Ich nehme an, das "PHP 7-71LATEST-STANDARD" eher bedeuten soll, das PHP7 in der Version 7.1 läuft.
Wenn Du das im Kundenmenü einfach umstellen kannst, wäre es eine Möglichkeit, 7.3 oder 7.4 kurzzeitig zu aktiviern und zu gucken, ob alles funktioniert. Falls Fehler auftreten, wieder auf 7.1 zurück stellen und auf Ursachensuche gehen.
Gruß
Ingo
PHP 7.71 gibt es nicht, welcher Webhoster ist das denn bitte?
PHP 7.1 ist in der Tat veraltet und wird nicht mehr seitens der Entwickler unterstützt. Eine Umstellung auf eine höhere PHP-Version ist sinnvoll. Allerdings könnte es Probleme mit alten Plugins und Themes geben. Das müßte vorher geprüft werden.
Gruß
Ingo