Beiträge von JoomlaWunder

Alternativ:
Such dir aus den log-Files die Zugriffe heraus, die besonders häufig sind und forsche ein wenig nach, ob diese seriös/unseriös/sinnvoll/überflüssig sind.
Sperre dann deren user-agent in der .htaccess. Mach aber für die robots.txt eine Ausnahme. Denn viele große Suchmaschinen (besonders aus dem asiatischen Raum) beachten die robots.txt, so dass du diese nur dort eintragen müsst.

Auf gar keinen Fall solltest du in der DB selber rumbasteln!

Wenn es nicht all zu viele Beiträge sind, dann wie bereits beschrieben vorgehen:
- Joomla 3.6.5 frisch installieren
- Menüpunkte und Beiträge anlegen
- Inhalte der Beiträge mittels Copy&Paste von der alten in die neue Version übernehmen

Xampp wäre eine Lösung, wenn man keinen Zugriff mehr auf das alte Joomla hat. Eventuell lässt sich das alte Joomla-Verzeichnis bei deinem Hoster doch noch auf eine alte PHP-Version zurückstellen. Frag einfach mal nach!
Oder du hörst dich um, wer dich da unterstützen kann. Bei einigen Hostern laufen diese Versionen noch. Und der ein oder andere wäre vielleicht behilflich.

Den Konfigurations-Assistenten hast du ja sicherlich mal durchlaufen lassen?
Vielleicht hat sich am Server etwas geändert. Lass ihn nochmal durchlaufen und versuche das Backup erneut!

Ergänzend: https://www.joomla.org/announc…-joomla-3-6-1-update.html

Wenn ich das jetzt richtig verstehe, hast du das Update auf 3.6.1 gemacht und kannst dich nun nicht mehr ins Backend einloggen, oder? Oder bist du nun auf 3.6.5?
Läuft das Frontend?
Wie hast du dann die DB repariert, ohne Zugriff aufs Backend?

Bin mir nicht sicher, aber war es nicht so, dass das Problem manchmal (warum auch immer) auftaucht, wenn das automatische Backup vor einem Update angestoßen wird, so wie von dir beschrieben.
Ich würde das entsprechende Plugin mal deaktivieren und das Backup direkt in der Komponente starten! Geht es dann?

Zitat von Bitbutcher

Unter dem Menüpunkt "Optionen ausschließen" wollte ich die genannten JavaScripte ausschließen. Hier kann ich aber leider nur....

Ich kann mich erinnern, dass ich mit dem Eintragen der "richtigen" Ausnahmen auch mal so meine Probleme hatte und mir es dann doch noch gelungen ist. Ist allerdings schon einige Versionen her. Vielleicht findest du noch eine Möglichkeit.

Verwendest du irgendein Framework oder ähnliches, was bereits automatisch eine Optimierung vornimmt? Vielleicht gibt es da noch eine gegenseitige Beeinflussung.

Einen Schutz, wie du ihn dir bzgl. Mediadateien vorstellst, scheint es nicht zu geben. Ich habe mich auch sehr lange mit der Materie beschäftigt und bin bisher zu keiner zufriedenstellenden Lösung gelangt.
Die einzige Methode, die ich noch nicht probiert habe, ist die Realisierung von Symlinks. Hierbei werden die Mediadateien außerhalb des zugreifbaren Bereiches gespeichert, so dass die direkte URL-Eingabe zu diesen nicht möglich ist. Die Verknüpfung erfolgt dann über die Symlinks.
Wie gesagt, ich habe diese Methode bisher nicht getestet. Falls du damit weiterkommst, würde ich mich über ein Feedback deinerseits freuen.

Du hast wohl das Modul bearbeitet. Dann gibt es noch: /components/com_users/views/login/tmpl oder so ähnlich.....

Ich vermute, dass die entsprechende Datei hier irgendwo liegt

Kannst du vielleicht in der Komponente diesbezüglich eine Einstellung vornehmen, so dass dies möglich ist?
Eventuell hilft auch ein Blick in die Datenbank, ob das Modul so etwas überhaupt vorsieht! Wenn es irgendwo nur einen einzigen Tabellen-Eintrag gibt, auf welchen alle Module zugreifen, anstatt mehrerer Tabellen-Einträge, dann ist das halt so.
Leider kenne ich das "Teil" selber nicht.

Kannst du im JCH nicht einstellen, wo hin die generierten Dateien gesetzt werden? Da würde ich mal dran "rumspielen"! Eventuell mal nach unten setzen.
In vielen Fällen wird aber die Funktionalität der Seite gestört, so dass es dann schlichtweg unmöglich ist, die Änderung vorzunehmen.
Man kann, so glaube ich, auch Dateien angeben, die nicht mit in die JCH-Datei geschrieben werden. Insofern kannst du da noch einiges testen.
Ich würde dem aber nicht zu viel Beachtung schenken. Habe selber auf etlichen Seiten das Problem und konnte bisher nichts nachteiliges feststellen.

Gibt es denn nicht weitere Möglichkeiten, deine Webseite zu optimieren, z.B. GZIP, kleinere oder weniger Bilder... usw.

Zur Frage, wie du eine Datei wie index.php öffnen kannst:

Nutze einen Editor wie z.B. PSPAD !

Du scheinst irgendeinen grundlegenden Fehler beim Sichern oder Herunterladen zu machen. Ist allerdings schwierig, diesen herauszufinden, weil man dir ja nicht direkt über den Rücken schauen kann.

Den Konfigurations-Assistenten lässt man durchlaufen, damit sich AkeebaBackup an den Server anpassen kann. Erst danach macht man das Backup.
Hast du bereits ein Backup, dann ist es zu spät.
Aber nach dem Entpacken weißt du sicherlich mehr, ob das Archiv in Ordnung ist.

Ansonsten:
Welchen Übertragungsmodus verwendet dein FTP-Programm?
Kann es sein, dass sich das Archiv nicht im gleichen Ordner befindet wie kickstart.php? Kannst du das Archiv auswählen und der Fehler erscheint erst danach?

Du verwendest das .jpa und hast vor der Sicherung auch mal den Konfigurations-Assistenten durchlaufen lassen?
Gab es während der Erstellung irgendwelche Warnhinweise?
Anschließend das Archiv mittels FTP heruntergeladen und nicht über den Download-Button (sorgt manchmal für Probleme)?
Bei deinem Hoster hatte ich mit AkeebaBackup und kicktstart.php noch nie Probleme.

Du kannst lokal Xampp "installieren" und es dort testen. Wenn man es aber nicht wirklich benötigt, würde ich drauf verzichten und alles auf dem Server testen.
Und du hast wirklich das aktuelle kickstart.php?

Wenn du möchtest kann ich das Archiv für dich ja mal testen?

Zitat von Girgei

....seit einiger Zeit bekomme ich beim Restor stets obige Fehlermeldung von Kickstart.

Und auch kickstart.php wird hin- und wieder aktualisiert. Hast du das aktuelle?

Den Webspace zu löschen und sich auf das noch nicht getestete Backup zu verlassen, war wohl ein Fehler.
Wenn das Backend bereits korrekt lief (Isis ist angebracht), dann würde ich zunächst versuchen, über den Hoster den entsprechenden Stand wiederherzustellen.

Wie hast du denn das Backup erstellt? Manuell oder mittels AkeebaBackup?
Hast du beim Sichern eventuell etwas vergessen oder DB-Tabellen/Dateien ausgeschlossen?

Ich würde zunächst aber einmal auf "DB reparieren" klicken und alle Caches leeren!
Vielleicht wäre auch PHP 5.6 oder sogar 7.0 angebracht.

Bekommst du sonst irgendeine Fehlermeldung? Mit den Modulen war doch auch diese Problematik. Habe ich aber bereits vergessen, worin diese bestand.

Achso.

Hast du mal die Caches geleert? Oder gib mal einen Link zur Seite, ob die Fehlermeldung generell erscheint!

Und du kannst es unter Erweiterungen->Verwalten->Verwalten wirklich nicht deinstallieren?
Benötigst du den Counter wirklich? Sonst verzichte drauf!
Irgendwo sind möglicherweise auch noch Reste zu finden.

Wenn ich "Mai 2017" anklicke, wird mir alles genauso angezeigt wie z.B. bei "April 2017". (im aktuellen IE). Wo soll da ein Unterschied sein?
Leere eventuell mal die Caches!

Wenn eine Datei abgespeichert werden soll, dann hat das ganz andere Gründe und würde auch die anderen Punkte betreffen.

Ergänzend:
Du kannst in der Akeeba-Konfiguration unter "Art der Sicherung" einstellen, was gesichert werden soll. Standardmäßig: Joomla und DB
Dann lassen sich Verzeichnisse und einzelne DB-Tabellen auch ausschließen. Das ist standardmäßig aber alles optimal eingestellt.