Nach Update auf J4 - alle Links zu 404

  • Joomla Version
    The currently installed Joomla! version is "‎4.4.8"
    PHP Version
    PHP 8.1.x
    Hoster
    bplaced
    Link (URL) zur Seite mit dem Problem
    https://zaktn.bplaced.net/

    Schönen Mittag,

    ich habe mich gestern (mit Cov19) mal wieder zum PC gesetzt um unsere "alte BüroHP", laufend auf 3.10.12 endlich upzudaten...hatte diese im Frühjahr mal schon auf externen Testserver auf 4.0.8 doch seit März keine Daten mehr eingespielt. (Sicherung von März jedoch noch vorhanden...) J2XML würde für Beiträge wohl nutzen, jedoch sämtliche Links zu pdfs (phocadownload) müssten neu erstellet und in den Beiträgen adaptiert werden..

    Also zog ich gestern von laufender 3.10.12 ein Backup, auf Testserver gespielt, auf 4.0.8 migriert und gestartet - VOILA --> eine Anzahl von 1.131 Links führen zu einer 404 Seite :-(((

    Wo fange ich nun zum Suchen des Problems an?

  • In vielen URLs ist 2x dieses /index.php/ vorhanden.
    Schau beispielsweise mal die .htaccess durch! Wurde diese entsprechend angepasst?

    Des Weiteren: Nutzt du eine aktuelle .htaccess, in der unten dieser GZIP-Block drinnen steht? Dann diesen mal als Kommentar setzen! Da wird momentan css und js nicht geladen.

    Schau auch in die configuration.php! Da musst du den Inhalt bei $live_site und $cookie_domain entfernen!
    Dann bist du schon mal einen großen Schritt weiter. Anschschließend muss man weiterschauen. ;)

  • Hallo ihr 2,

    danke erstmals für eure Antworten - bin aus dem Bett gekrochen um nachzusehen, was schon für Antwoten vorliegen...

    Btw: die Spiegelung er Onlineseite läuft lokal via xampp fehlerfrei und ohne 404 Fehlerseiten...

    • Inhalte bei $live_site und $cookie_domain sind leer
    • Die .htaccess Datei im Ordner .protection beinhaltet nur "#A1 Directory Delete Protection deny from all"
    • Die htaccess.txt im Stammverzeichnis hat GZIUP Bock "ausgeklammert" (Block ist eher zum Schluss)

    Komischerweise scheint im Linkchecker wirklich oftmals index.php/index.php/.... auf, beim Drüberfahren im Menü auf der Livesite ist dies jedoch nur einmal vorhanden - ebenso betrifft das anscheinend alle Links in der Menüleiste, zu den Beiträgen zB in "Unsere ZA - Infos" kommt man ohne Probleme...

  • Die htaccess.txt ist eine reine Textdatei und wird nicht vom Server abgearbeitet. Sie dient lediglich als Vorlage, wenn man sie benötigt. Das ist beispielsweise dann der Fall, wenn man in der Joomla-SEF-Konfiguration entsprechende "Ja" setzt. Siehe die Info an entsprechender Stelle im Backend zu mod_rewrite! Dann muss man sie umbenennen in .htaccess (ohne Datei-Endung und mit einem Punkt davor). Kannst sie aber auch neu erstellen und den Inhalt hineinkopieren. Anschließend noch mit eigenen Zeilen ergänzen, falls nötig.

    Interessant wäre der Inhalt einer .htaccess im Joomla-Root-Verzeichnis sowie der Inhalt einer .htaccess im übergeordneten Verzeichnis. Sowie du das beschreibst, existieren dort keine .htaccess-Dateien. Falls du in der Joomla-SEF-Konfiguration auch das zweite "Ja" gesetzt hast, würde diese benötigt werden. Dann setze sie ins Joomla-Root-Verzeichnis.

    Auf der anderen Seite deute ich viele Fehlermeldungen auf deiner Webseite so, dass eine .htaccess im Joomla-Root-Verzeichnis existiert?!?
    Dadurch, dass der GZIP-Block nicht als Kommentar gesetzt wurde, kommen diese Konflikte. Deshalb wird auf den erreichbaren Unterseiten kein Design angezeigt.
    Also: Existiert dort nun diese .htaccess im Joomla-Root?

    Also zog ich gestern von laufender 3.10.12 ein Backup, auf Testserver gespielt, auf 4.0.8 migriert und gestartet - VOILA --> eine Anzahl von 1.131 Links führen zu einer 404 Seite :-(((

    Hast du vor der Aktualisierung alle Drittanbieter-Erweiterungen auf einen aktuellen J3-Stand gebracht?
    Warum hast du nicht gleich auf das aktuelle Joomla 4 aktualisiert, sondern nur auf 4.0.8?
    Ist dein Yootheme aktuell und zu J4 kompatibel?
    Schau mal die Einstellungen durch, die das Routing betreffen, insbesondere was Yootheme angeht! Kenne mich damit nicht so aus.
    Und leere auch unbedingt mal alle Caches! (Yootheme hat da scheinbar einen eigenen).

  • Hi,

    bezüglich Phoca Download siehe:

    Jan
    31. März 2024 um 00:26

    Ich hatte das gleiche Problem und habe es per Joomla! Redirect Komponente gelöst.

    Freundliche Grüße,

    Benno

  • Hi, sch...Cov2... (sorry)

    Lege euch Bilder dazu...

    Habe vor Aktualisierung alle J3 Extensions geupdated, ja - dann erst auf J4, dann erst Spiegelung von lokal auf Server...

    Elwood Hast du denn die .htaccess bei der Spiegelung umbenannt/deaktiviert --> nein, alles von lokal genauso auf Server überspielt (lokal = offline funktioniert alles fehlerlos, online nicht....)

    Bplaced pro - habs mir mal für 1 Monate freigeschaltet :)

    Benno ok, das übersteigt einsteilen mein Wissen ... :)

    Leg mich wieder nieder... bleibt gesund und danke für eure Ratschläge...

    GLG aus Kärnten

  • Schönen Nachmittag...

    Vielleicht könnt ihr diesen Thread hier lesen, auch wenn anscheinend alle Links auf forum.joomla.de nur auf einen Beitrag verlinken...

    Möchte das Thema nochmal aufgreifen...

    Habe mir am gleichen Server wie in #1 genannt die J3 samt Komponenten auf J4 und dann auf J5 lokal geupdated, alles funktioniert lokal ohne Probleme.

    Dann via kickstart.php am Server zurückgespielt - Startseite der HP läuft, alle Links im Menü führen zu 404 --> Klick auf "Startseite" der 404 Seite --> es kommt eine Auflistung aller Menüpunkte ohne CSS Aufbau --> klick auf einen Link --> die webadresse wird immer "erweitert" , zB:

    https://zaktn.bplaced.net/ --> Über uns - DA Bezirke --> https://zaktn.bplaced.net/index.php/uebe…n-bezirken.html mit 404, Klick auf Startseite ergibt https://zaktn.bplaced.net/index.php/ueber-uns/index.php (ohne CSS)--> Kick auf anderen Link, zB "Zentralauschuss" --> https://zaktn.bplaced.net/index.php/uebe…lausschuss.html ... usw.

    Was ist hier nicht in Ordnung???

    GLG und Danke aus Kärnten

  • .....alle Links im Menü führen zu 404

    Das passiert dann, wenn du beispielsweise im Backend das "Mod-Rewrite" in der Joomla-Konfiguration aktiviert hast und es keine .htaccess gibt.

    ...es kommt eine Auflistung aller Menüpunkte ohne CSS Aufbau

    css- und js-Dateien werden nicht geladen, da MIME-Typ-Konflikt und deswegen Blockierung. Typischerweise liegt es an dem GZIP-Block am Ende der .htaccess. Da müssten wahrscheinlich 2 Zeilen als Kommentar gesetzt werden.

    Also:
    Was hast du bei SEO-Konfiguration aktiviert?
    Gibt es eine .htaccess?
    Wie ist der Inhalt der .htaccess?
    Beachte auch, dass die .htaccess lokal ein wenig anders ausschaut bzw. ausschauen kann als auf dem Webserver. Muss halt immer angepasst werden!

    Wichtig auch:
    Beachte, dass in der configuration.php bei $live_site keine Eingrag vorhanden sein darf. Ich glaube, das musst du korrigieren!
    Selbiges bei $cookie_domain!
    Und je nach Hoster darf in der .htaccess vor RewriteBase / keine # stehen!

  • Hallo...

    danke für eure Antworten, folgend SEO Einstellungen im Joomla BE:


    die .htaccess

    ##
    # @package Joomla
    # @copyright (C) 2005 Open Source Matters, Inc. <https://www.joomla.org>
    # @license GNU General Public License version 2 or later; see LICENSE.txt
    ##

    ##
    # READ THIS COMPLETELY IF YOU CHOOSE TO USE THIS FILE!
    #
    # The line 'Options +FollowSymLinks' may cause problems with some server configurations.
    # It is required for the use of Apache mod_rewrite, but it may have already been set by
    # your server administrator in a way that disallows changing it in this .htaccess file.
    # If using it causes your site to produce an error, comment it out (add # to the
    # beginning of the line), reload your site in your browser and test your sef urls. If
    # they work, then it has been set by your server administrator and you do not need to
    # set it here.
    ##

    ## MISSING CSS OR JAVASCRIPT ERRORS
    #
    # If your site looks strange after enabling this file, then your server is probably already
    # gzipping css and js files and you should comment out the GZIP section of this file.
    ##

    ## OPENLITESPEED
    #
    # If you are using an OpenLiteSpeed web server then any changes made to this file will
    # not take effect until you have restarted the web server.
    ##

    ## Can be commented out if causes errors, see notes above.
    Options +FollowSymlinks
    Options -Indexes

    ## No directory listings
    <IfModule mod_autoindex.c>
    IndexIgnore *
    </IfModule>

    ## Suppress mime type detection in browsers for unknown types
    <IfModule mod_headers.c>
    Header always set X-Content-Type-Options "nosniff"
    </IfModule>

    ## Protect against certain cross-origin requests. More information can be found here:
    ## https://developer.mozilla.org/en-US/docs/Web…e_Policy_(CORP)
    ## https://web.dev/why-coop-coep/
    #<IfModule mod_headers.c>
    # Header always set Cross-Origin-Resource-Policy "same-origin"
    # Header always set Cross-Origin-Embedder-Policy "require-corp"
    #</IfModule>

    ## Disable inline JavaScript when directly opening SVG files or embedding them with the object-tag
    <FilesMatch "\.svg$">
    <IfModule mod_headers.c>
    Header always set Content-Security-Policy "script-src 'none'"
    </IfModule>
    </FilesMatch>

    ## These directives are only enabled if the Apache mod_rewrite module is enabled
    <IfModule mod_rewrite.c>
    RewriteEngine On

    ## Begin - Rewrite rules to block out some common exploits.
    # If you experience problems on your site then comment out the operations listed
    # below by adding a # to the beginning of the line.
    # This attempts to block the most common type of exploit `attempts` on Joomla!
    #
    # Block any script trying to base64_encode data within the URL.
    RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]
    # Block any script that includes a <script> tag in URL.
    RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
    # Block any script trying to set a PHP GLOBALS variable via URL.
    RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
    # Block any script trying to modify a _REQUEST variable via URL.
    RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
    # Return 403 Forbidden header and show the content of the root home page
    RewriteRule .* index.php [F]
    #
    ## End - Rewrite rules to block out some common exploits.

    ## Begin - Custom redirects
    #
    # If you need to redirect some pages, or set a canonical non-www to
    # www redirect (or vice versa), place that code here. Ensure those
    # redirects use the correct RewriteRule syntax and the [R=301,L] flags.
    #
    ## End - Custom redirects

    ##
    # Uncomment the following line if your webserver's URL
    # is not directly related to physical file paths.
    # Update Your Joomla! Directory (just / for root).
    ##

    RewriteBase /

    ## Begin - Joomla! core SEF Section.
    #
    # PHP FastCGI fix for HTTP Authorization, required for the API application
    RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
    # -- SEF URLs for the API application
    # If the requested path starts with /api, the file is not /api/index.php
    # and the request has not already been internally rewritten to the
    # api/index.php script
    RewriteCond %{REQUEST_URI} ^/api/
    RewriteCond %{REQUEST_URI} !^/api/index\.php
    # and the requested path and file doesn't directly match a physical file
    RewriteCond %{REQUEST_FILENAME} !-f
    # and the requested path and file doesn't directly match a physical folder
    RewriteCond %{REQUEST_FILENAME} !-d
    # internally rewrite the request to the /api/index.php script
    RewriteRule .* api/index.php [L]
    # -- SEF URLs for the public frontend application
    # If the requested path and file is not /index.php and the request
    # has not already been internally rewritten to the index.php script
    RewriteCond %{REQUEST_URI} !^/index\.php
    # and the requested path and file doesn't directly match a physical file
    RewriteCond %{REQUEST_FILENAME} !-f
    # and the requested path and file doesn't directly match a physical folder
    RewriteCond %{REQUEST_FILENAME} !-d
    # internally rewrite the request to the index.php script
    RewriteRule .* index.php [L]
    #
    ## End - Joomla! core SEF Section.
    </IfModule>

    ## These directives are only enabled if the Apache mod_rewrite module is disabled
    <IfModule !mod_rewrite.c>
    <IfModule mod_alias.c>
    # When Apache mod_rewrite is not available, we instruct a temporary redirect
    # of the start page to the front controller explicitly so that the website
    # and the generated links can still be used.
    RedirectMatch 302 ^/$ /index.php/
    # RedirectTemp cannot be used instead
    </IfModule>
    </IfModule>

    ## GZIP & BROTLI
    ## These directives are only enabled if the Apache mod_headers module is enabled.
    ## This section will check if a .gz file exists and if so will stream it
    ## directly or fallback to gzip any asset on the fly
    ## If your site starts to look strange after enabling this file, and you see
    ## ERR_CONTENT_DECODING_FAILED in your browser console network tab,
    ## then your server is already gzipping css and js files and you don't need this
    ## block enabled in your .htaccess
    <IfModule mod_headers.c>
    # Serve gzip compressed CSS files if they exist
    # and the client accepts gzip.
    RewriteCond "%{HTTP:Accept-encoding}" "gzip"
    RewriteCond "%{REQUEST_FILENAME}\.gz" -s
    RewriteRule "^(.*)\.css" "$1\.css\.gz" [QSA]

    # Serve gzip compressed JS files if they exist
    # and the client accepts gzip.
    RewriteCond "%{HTTP:Accept-encoding}" "gzip"
    RewriteCond "%{REQUEST_FILENAME}\.gz" -s
    RewriteRule "^(.*)\.js" "$1\.js\.gz" [QSA]

    # Serve correct content types, and prevent mod_deflate double compression.
    RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-gzip:1,E=no-brotli:1]
    RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-gzip:1,E=no-brotli:1]

    <FilesMatch "(\.js\.gz|\.css\.gz)$">
    # Serve correct encoding type.
    Header set Content-Encoding gzip

    # Force proxies to cache gzipped &
    # non-gzipped css/js files separately.
    Header append Vary Accept-Encoding
    </FilesMatch>
    </IfModule>


    Jetzt Büro schließen... GLG

  • Schönen guten Abend :)

    Ihr seid ein Wahnsinn!!!!! dance:love:<3:*

    Danke danke danke - das mit "kein # vor RewriteBase /" und auch das EINschalten von "URL rewrite" war vermutlich der Grund!!!

    Seite läuft nun mal auf J5 am Testserver, muss nun alle Unterseiten, Links, Bilder,... überprüfen...aber ich bin guter Hoffnung!!!!

    Sollte noch was sein, melde ich mich....

    Wo kann ich was spenden? ;)

    GLG aus Kärnten