Backend defekt?

Moin,

was kann das sein, das nach ein paar Tagen der "Nichtbenutzung" das Backend so kacke aussieht?

Schon die Anmelde-Maske zum BE sah so kacke aus. Das Frontend funktioniert wie gewohnt. anch dem letzten Besuch habe ich nicht bewust was geändert.

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.

nein, pinguin47.de/lalita/administrator

Zitat von Elwood

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/kurse

habe 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.

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

"

Zitat von Elwood

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 ?

Zitat von Re:Later

Du solltest in der .htaccess mal diese Zeilen entfernen, als ersten Versuch:

Apache Configuration

## 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>

Alles anzeigen

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

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....

Zitat von Sieger66

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

Warum auch immer da dieser "Unterordner" erzeugt wurde. Es geht ja nun wieder - deshalb: Erledigt.