Ich würde erst einmal bei dem Umleitungsplugin die Option „URLs sammeln“ deaktivieren. Mit der wird für jeden 404 ein neuer Eintrag in der Tabelle angelegt.
Gruß,
kdh
Beiträge von kdh
-
-
Läuft bei mit 644, allerdings nicht unter Joomla.
Gruß, kdh
-
Scheint aber nicht aktuell zu sein, weiter unten auf der Seite steht:
ZitatAdditional Info
- Version: 18.14.02
- Compatibility: J3, J4
-
Bei all-inkl gab es vor ein paar Tagen eine Server-Umstellung, bei der ich auch betroffen war. Es wurden u. a. auch ältere php-Versionen entfernt und die Maria-DB Version aktualisiert.
Ich hatte bisher noch keine Probleme nach der Umstellung.
Gruß,
kdh
-
Leider kann nicht jeder, aus welchen Gründen auch immer, hier 24h online sein, wie andere Supporter,
die Selbständig oder Rentner sind.
Es soll auch Selbständige und Rentner geben, die nicht 24h online sein können.
Gruß kdh.
-
Das habe ich gemacht nachdem HostEurope von GoDaddy aufgekauft wurde.
Gruß, kdh
-
Das Joomla-Verzeichnis ist doch schon joomla5. Also müsste der Link pdf/SATZUNG1997.pdf (ohne joomla5/) lauten.
Gruß,
kdh
-
Bei mir ist flexicontact seit 10 Jahren im Einsatz. Hatte noch nie Probleme.
flexicontact ist auch J5-fähig ohne Kompatibilitätsplugin. Ich hatte deswegen vor einiger Zeit Kontakt mit dem Entwickler, finde aber gerade die Mail-Adresse nicht.
Gruß,
kdh
-
Die erste Zeile deiner htaccess.txt enthält ungültige Zeichen.
Die Schlüsselwörter AuthName, AuthUserFile, Require müssen jeweils am Anfang einer neuen Zeile stehen, also
Apache ConfigurationAuthType Basic AuthName "Passwortgeschützter Bereich" AuthUserFile /homepage/joomla5/.htpasswd Require valid-userDas Problem kann evtl. durch falsches Hochladen entstanden sein (binär hochgeladen?)
htpasswd.txt scheint ok.
Gruß,
kdh
-
kdh Mache es doch aber nur wenn es im Verzeichnis liegt wo es auch hingehört
???
Ich selbst bin ja nicht betroffen, aber wie oft habe ich hier im Forum gelesen, dass das Verzeichnis nicht leer war und deshalb der Restore nicht funktioniert hat. Kann doch so schwierig sein, die Prüfung einzubauen.
Gruß,
kdh
-
Das war m.E. nicht richtig.
Die jpa-Datei und die Kickstart.php gehören in ein leeres Verzeichnis.
Dazu ist die Datenbank zu leeren (phpmyadmin).
Christian
Warum prüft kickstart das eigentlich nicht?
Gruß,
kdh
-
Danke übrigens für diesen Hinweis. Das hat wirklich Klarheit gebracht. Und den Hinweis zu deny from 2a03:2880 habe ich dann auch im Kontext von Require angewendet, was prompt zu einem 500er-Fehler führte, aber die Gewissheit brachte, das IONOS Apache 2.4 einsetzt. Habe dann 2a03:2880::/16 vewendet, was offensichtlich funktioniert.
2a03:2880::/16 ist nicht richtig, dies wären alle IPV6-Adressen die mit 2a03 anfangen. Richtig ist 2a03:2880::/32 für alle Adressen beginnend mit 2a03:2880. Allerdings hat Facebook Ireland (heißt jetzt Meta Platforms Ireland Limited) 2a03:2880::/29 d. h. 2a03:2880:: bis 2a03:2887:ffff:ffff:ffff:ffff:ffff:ffff
Für die Umrechnung von CIDR in IP Ranges gibt es im Internet natürlich auch Tools, z. B. https://www.ipaddressguide.com
Gruß, kdh
-
Was mir auf den ersten Blick auf die htaccess aufgefallen ist:
# Amazon
deny from 3.224.220.0
deny from 23.22.35.0
deny from 52.47.201.0
deny from 52.70.240.0
deny from 65.2.171.0
deny from 185.191.171.0Hiermit sperrst du nur die einzelne IP-Adressen z. B. 3.224.220.0 aus, nicht aber z. B. 3.224.220.1 - 3.224.220.255.
Die Adresse 3.224.220.0 ist Teil des großen Amazon-Bereichs 3.128.0.0 - 3.255.255.255. Den ganzen Bereich kann man sperren indem man angibt:
deny from 3.128.0.0/9
deny from 2a03:2880:: funktioniert auch nicht, damit würde nur die ipv6-Adresse 2a03:2880:0:0:0:0:0:0 gesperrt. deny from 2a03:2880 würde alle Adressen, die so beginnen, sperren.
Eine gute Beschreibung habe ich hier gefunden: https://htaccessbook.com/block-ip-address/
Gruß, kdh
-
Mach doch einfach das "^" weg, dann funktioniert es immer, auch wenn der Name des Bots nicht am Anfang steht, z. B. bei dem Bot "OAI-SearchBot", der kommt bei mir z. Zt. häufig mit folgendem HTTP_USER_AGENT:
Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; OAI-SearchBot/1.0; +https://openai.com/searchbot
Gruß, kdh
-
RewriteCond %{HTTP_USER_AGENT} ^BadBot1 [NC,OR]
......
RewriteCond %{HTTP_USER_AGENT} ^BadBot-letzter [NC]
RewriteCond %{REQUEST_FILENAME} !^.*robots\.txt$
RewriteRule ^.* - [F]Die RewriteCond mit HTTP_USER_AGENT funktioneren vermutlich wegen dem ^-Zeichen nicht. Das bedeutet nämlich, dass der "BadBot" am Anfang des HTTP_USER_AGENT stehen muss. Das ist meistens nicht der Fall. Also das ^ rausnehmen oder wie bei dem RewriteCond mit der robots.txt darunter ".*" einfügen.
Gruß kdh
-
RewriteCond %{HTTP_HOST} ^meine.seite.de [NC]
RewriteRule ^(.*)$ https://www.meine-seite.de/$1 [L,R=301,NC]
Das funktioniert natürlich. Aber es funktioniert auch bei RewriteCond mit Backslashes vor dem Punkten, also
RewriteCond %{HTTP_HOST} ^meine\.seite\.de [NC]
RewriteRule ^(.*)$ https://www.meine-seite.de/$1 [L,R=301,NC]Bei dem zweiten Wert von RewriteCond und dem ersten Wert von RewriteRule handelt es sich um einen regulären Ausdruck (regular expression). Das bedeutet der Punkt "irgendein Wert an dieser Stelle", also auch ein Punkt. Das "^" bedeutet übrigens "Anfang der Variable", "$" Ende der Variable.
Der erste Wert von RewriteCond und der zweite Wert von RewriteRule ist kein regulärer Ausdruck. Deshalb darf bei RewriteRule zweiter Wert kein Backslash stehen.
Gruß,
kdh
-
Nimm mal die Backslash aus der ersten Zeile bei der Domain.
Die Backslashes sind schon ok. Der RewriteCond ist ein regulärer Ausdruck. Ohne Backslash bedeutet der Punkt "irgendein Zeichen". Das würde in diesem Fall natürlich auch funktionieren.
Gruß,
kdh
Ich habe die Zeilen
RewriteCond %{HTTP_HOST} !^www\.ihre-domain\.de$ [NC]
RewriteRule ^(.*)$ https://www.ihre-domain.de/$1 [R=301,L]
in die .htaccess eingesetzt also so, wie oben eigentlich gedacht..Könnte es sein dass du in der .htaccess vor den eingefügten Zeilen eine andere RewriteRule mit [R=301,L] hast, die ausgeführt wird? Dann würden die danach eingefügten Zeilen nicht mehr ausgeführt werden.
Gruß,
kdh
-
Der Parameter wird von Joomla wahrscheinlich garnicht abgefragt. Deshalb läuft es so als ob der Parameter nicht angegeben wurde.
Es gab mal so einen Link von extern auf meine Seite. Den hat Google gefunden und seitdem wird dieser regelmäßig von Google abgefragt. Da das Ergebnis immer HTTP 200 ist, kommt Google immer wieder damit.
Gruß
kdh
-
Das Problem hatte ich auch.
Bei mir war unter Joomla-Update: Optionen als Update-Server "Joomla! Next" eingestellt. Nachdem ich auf "Standard" geändert habe wurde das Update auf 5.1.1 angeboten.
Gruß,
kdh
-
Der Fehler wurde mit Joomla 5.1.1 behoben.
Gruß,
kdh
