Backend defekt?
- maxem
- Erledigt
-
-
Mehr Info's gem. Forenregeln!
- Wurde vielleicht die PHP-Version vom Hoster verändert?
- Ist Joomla und Extensions/Template/Framework aktuell?
- Steht in der configuration.php eventuell etwas bei 'Live Site'?
- Hast du eine spezielle .htaccess in Nutzung?
- ...........................
-
ja sorry, aber ich habe da vor 2 Tagen noch dran gearbeitet, da ging alles noch völlig normal. Und alles war auch aktuell.
Das Frontend sieht ja total normal aus. Ist nur der BE.
Ich hab keine Ahnung was da passiert sein kann. Hoster DB und PHP hat sich nicht geändert. -
ja sorry, aber ich habe da vor 2 Tagen noch dran gearbeitet,
Was hast du denn gemacht?
-
Schon die Anmelde-Maske zum BE sah so kacke aus.
Wenn es um die gleiche Seite geht wie letzte Woche, dann sieht es normal aus:
-
nein, pinguin47.de/lalita/administrator
-
Also ein Unterordner.
Hast einige Fragen aus #2 nicht beantwortet. Musst du auch nicht.
Stimmen die Pfade in der configuration.php?
-
Was hast du denn gemacht?
nicht wirklich sicher, was als letztes war. Aber ich habe mit dem ICalender geguckt, weil es da wohl css-problme gibt (Buttons verschoben)
https://pinguin47.de/lalita/index.php/kursehabe aber nicht wirklich was gefunden und die seite erst mal ruhn gelseen. Heute hat sich Jemand von ICal gemeldet und ich wollte noch mal in die Seite gucken und "peng"....
Bin mal mit FTP rein und sehe ich einen Ordenr, den ich nicht so kenne. "gsoc19_page_builder-development". Da drin dann optisch eine weitere Installation? Alles sehr komisch. -
von ICal gemeldet und ich wollte noch mal in die Seite gucken und "peng"....
Immer noch keinen Antworten ...........
Ich würde dann das Backup einspielen, oder schauen, was der von ICal (Warum?) gemacht hat (logs).
-
Du solltest in der .htaccess mal diese Zeilen entfernen, als ersten Versuch:
Apache Configuration
Alles anzeigen## GZIP ## 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 gzip. RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-gzip:1] RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-gzip:1] <FilesMatch "(\.js\.gz|\.css\.gz)$"> # Serve correct encoding type. Header append Content-Encoding gzip # Force proxies to cache gzipped & # non-gzipped css/js files separately. Header append Vary Accept-Encoding </FilesMatch> </IfModule>
Ansonsten muss man weiter schauen, welche GZIP-Einstellungen eventuell daran schuld sein könnten, warum CSS und JS-Dateien einen "Content-Encoding"-Fehler auswerfen, wenn der Browser sie aufrufen will.
Eventuell kommt das auch aus einer übergeordneten .htaccess, da du ja in einem Unterordner bist, was leider meist eine blöde Idee ist.
-
das ist der letzte Eintrag im Action-Log:
"
"802","PLG_ACTIONLOG_JOOMLA_EXTENSION_UPDATED","{""action"":""update"",""type"":""PLG_ACTIONLOG_JOOMLA_TYPE_PACKAGE"",""id"":232,""name"":""German (Germany) Language Pack"",""extension_name"":""German (Germany) Language Pack"",""userid"":345,""username"":""lalita"",""accountlink"":""index.php?option=com_users&task=user.edit&id=345""}","2022-09-28
"
Immer noch keinen Antworten ...........
Ich würde dann das Backup einspielen, oder schauen, was der von ICal (Warum?) gemacht hat (logs).
Da hat keiner was gemacht. Der hat sich per E-Mail gemeldet und erwähnte : "There's many issues on your site (script errors and pre-defined default css styling which are not standards...)" Darauf haeb ich mir das Frontend noch mal angesehne, das sieht aus wie immer, dann wollte ich mich einlioggen und das war der Punkt, an dem ich zum ersten Mal gesehn habe, das da was nicht stimmt.
Wie spiele ich denn "nur das BE" ein ? -
Es läuft auf GZIP hinaus. Siehe Post #10.
-
Du solltest in der .htaccess mal diese Zeilen entfernen, als ersten Versuch:
Apache Configuration
Alles anzeigen## GZIP ## 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 gzip. RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-gzip:1] RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-gzip:1] <FilesMatch "(\.js\.gz|\.css\.gz)$"> # Serve correct encoding type. Header append Content-Encoding gzip # Force proxies to cache gzipped & # non-gzipped css/js files separately. Header append Vary Accept-Encoding </FilesMatch> </IfModule>
Ansonsten muss man weiter schauen, welche GZIP-Einstellungen eventuell daran schuld sein könnten, warum CSS und JS-Dateien einen "Content-Encoding"-Fehler auswerfen, wenn der Browser sie aufrufen will.
Eventuell kommt das auch aus einer übergeordneten .htaccess, da du ja in einem Unterordner bist, was leider meist eine blöde Idee ist.
Ja, OK, mache ich gerne, aber es hatte doch alles funktioniert - am 28.9. lt DB....
Was auch immer das gewesen ist: Ich habe den Ordner "gsoc19_page-builder-development" umbenannt (mit FTP) - keine Änderung.
Dann habe ich den Ordner gelöscht.
Im root (also nicht die im "lalita"-Ordner) die .htaccess deaktiviert, und dann war alles wieder wie früher.
Die ".htaccess" wieder aktiviert und es geht wie gewohnt.
Edit: Sieht so aus, als ob sich da doch Probleme durch die ".htaccess" im Root Ordner egeben.
Es gibt doch schon noch komische Darstellungen im BE, wenn die aktiv ist.Wo kann der komische Ordner her gekomen sein? Eine Erweiterung/Plugin, die so was installiert?
Ich habe den Ordner mal gepackt und im Root/dl abgelegt. - wenn sich das Jemand mal ansehen mag. (3 MB)
https://pinguin47.de/dl/gsoc19_page-builder-development.7z -
Der Name deutet auf eine Erweiterung von Joomla, die beim Google summer of code entwickelt werden sollte, aber mangels Programmieren nur noch bedingt weiter entwickelt wird.
Sie hat nichts im Produktivbereich zu suchen. Das muss schon gewollt installiert worden sein. Kommt nicht einfach so dran.
-
Blöde Frage: Wie rufe ich denn nun mein Test-Seite für die Lalita auf, wenn diese kein unterordner mehr von der Pinguin-Seite ist?
In der Strucktur habe ich die ja von der "root" entkoppelt und der Ordner liegt nun auf der selben Ebene.
Edit: Habe mal eine Subdomain angelegt dafür.... -
Am besten ist es in der Regel wenn man es so machen kann wie ich es z.B. dort in #6 und #17 erläutert habe:
Gebastelte Webseite ... mit anderen teilen
Die Webseiten also möglichst in parallelen Dateiordnern anlegen.
In #6 dort also z.B:
Domain so einrichten das sie dann z.B. auf den Dateiordner website1 zeigt.
Subdomain1 so einrichten das sie dann z.B. auf den Dateiordner website2 zeigt.
-
Am besten ist es in der Regel wenn man es so machen kann wie ich es z.B. dort in #6 und #17 erläutert habe:
Gebastelte Webseite ... mit anderen teilen
Die Webseiten also möglichst in paralellen Dateiodnern anlegen.
Habe ich ja jetzt gemacht, und komme aber nur auf den Lalita-Ordner als Webseite, wenn ich diese als Subdomian einrichte. Ein Aufruf über /www.seite1/seite2 klappt dann logicherweise nicht mehr.
Neue Seite: https://lalita.pinguin47.de -
Den Dateiordner lalita und dessen Website könntest du z.B. daher wohl dort unverändert lassen wo er jetzt schon ist.
Eine Subdomain dann dafür noch so einrichten das sie dann auf den Dateiordner lalita zeigt.
Edit: Da war ich jetzt zu langsam.
Ja, bei manchen Webostern benötigt man eine Subdomain und bei manchen Webhostern kommt man auch über einen "Direktlink" an die parallelen Dateiorder und Dateien z.B. ähnlich aufgebaut wie:
http://202348.example.com/lalita/index.php
Hängt halt von Webhoster und "Paket" ab.
Ein Aufruf über /www.seite1/seite2 klappt dann logicherweise nicht mehr.
Das ist übrigens ohnehin die schlechteste Aufrufvariante.
-
Warum auch immer da dieser "Unterordner" erzeugt wurde. Es geht ja nun wieder - deshalb: Erledigt.