Beiträge von Iarsin

    Ich hatte die alte Zeile drin gelassen und falsch auskommentiert (für php, statt html, da ja mehrfach <php ?> in der Datei vorkommt). Nach dem entfernen der alten Zeile (die ich auskommentieren wollte) ging's dann. ka, ob das hier auch der Fall war, oder das Problem anders gelagert ist. Hatte den patch also manuell in den code eingearbeitet.

    Ja, aber das wäre auch eine Möglichkeit. Eine Antwort beschließt die Möglichkeit und alle Änderungen bleiben als Versionen nachvollziehbar. Allerdings ist mir auch aufgefallen, dass der Versionsvergleich nicht ganz funktioniert. Einmal hatte ich nur zwei Kommata gesetzt und der ganze Vergleichstext war rot hinterlegt, man musste den Unterschied also selbst herausfinden.

    Also ich brauche mindestens 10 Minuten oder gar eine Viertelstunde, so langsam wie ich offenbar bin, und bei der Fehleranfälligkeit im Tippen.

    Ich kenne aus einigen Foren, dass eine Antwort einen Deckel drauf setzt. Das macht ja auch Sinn, so kann man eine Diskussion nicht verfälschen. Man muss es dann in der Diskussion zurücknehmen. Solange keine Antwort erfolgt kann ich dem zuvorkommen und meinen Unsinn zurücknehmen sobald er mir auffällt.

    Danke für die Zusammenfassung einiger Posts zu einem.

    Ich muss manchmal in die Quellansicht, weil ein Textblock den ich markiere, und dann als Quote oder Code auszeichnen will, nicht sauber als Block erfasst wird. Eigentlich sollte das auch schon anderen aufgefallen sein, mir jedenfalls passiert das häufig. Ich korrigiere das dann in der Quellcode-Ansicht.

    Naja, da sieht man mal wie die Zeit vergeht. Ich denke das sind dann bei mir gefühlte 30 Sekunden bis eine Minute. Tut mir leid, dass der Thread so zu einem Dickicht verkommen ist. Besser fände ich, wenn die Zeit höher angelegt wäre, aber dass man, sobald jemand anderes antwortet nicht mehr bearbeiten kann, um den Beitrag nicht nachträglich zu verfälschen, falls es Streitpunkte gibt.

    Außerdem habe ich des öfteren Probleme mit Quotes oder Codeblöcken.

    So, das wars. Herzlichen Dank noch mal an j!-n für den entscheidenden Hinweis, dass es sich um joomfish handelte!

    Das hatte ich zwar komplett entfernt, aber offenbar war dabei während der Upgrade-Prozedur vor etwa zwei Monaten einiges schief gelaufen. Der Datenbankeintrag dazu verhinderte jetzt jedenfalls den erneuten export/import, also die erfolgreiche Migration auf den remote/live(nennt man das unter Joomla! so?)- Server.

    In der zu importierenden SQL-Datei der lokalen Installation kommentierte ich Zeile 36293 mit -- aus, und schon klappte der Import probemlos.

    Code
    1. -- Zeile 36285
    2. --
    3. -- Struktur des Views `rtci1_jf_languages`
    4. --
    5. DROP TABLE IF EXISTS `rtci1_jf_languages`;
    6. -- joomfish-Reste
    7. -- CREATE ALGORITHM=UNDEFINED DEFINER=`dbo673384265`@`db673384265.db.1and1.com` SQL SECURITY DEFINER VIEW `rtci1_jf_languages` AS select `l`.`lang_id` AS `lang_id`,`l`.`lang_code` AS `lang_code`,`l`.`title` AS `title`,`l`.`title_native` AS `title_native`,`l`.`sef` AS `sef`,`l`.`description` AS `description`,`l`.`published` AS `published`,`l`.`image` AS `image`,`lext`.`image_ext` AS `image_ext`,`lext`.`fallback_code` AS `fallback_code`,`lext`.`params` AS `params`,`lext`.`ordering` AS `ordering` from (`rtci1_languages` `l` left join `rtci1_jf_languages_ext` `lext` on((`l`.`lang_id` = `lext`.`lang_id`))) order by `lext`.`ordering` ;
    8. -- Zeile 36293

    Joomla! Checksum-Scanner funktioniert wieder, die Datenbank war direkt aktuell, aber ich habe sie dennoch nochmals repariert. Alles scheint nun normal, auch die neuen redirects (Umleitungen) bekommen die nächst höhere ID 21700 statt wie zuvor die falsche ID 0, die auf die korrupte Datenbank verwies.


    Kerndateien habe ich erneut inststalliert, dabei wurde das Akeeba Backup getriggert , das aber meckerte.


    Zitat

    Start a new backup

    The automatic backup can not be started because your output directory is not writable. Please follow the instructions below to fix this issue.


    In order to fix this issue, please go to the Configuration Page and set the Output Directory to [DEFAULT_OUTPUT] (all caps, including the brackets). If this still doesn't work, please take a look at our troubleshooting instructions


    Das lagt daran, dass als output-directory der lokalen Installation "C:\xampp\htdocs\htdocs/administrator/components/com_akeeba/backup" angegeben ist.
    Kann man hier auch einen anderen externen Host angeben? Das wäre ja sinnvoll? Ich habe nun das Server-Verzeichnis /administrator/components/com_akeeba/backup angegeben. Das erscheint mir suboptional, aus Sicherheitsgründen wegen Datenverlust und auch fremder Begehrlichkeiten durch Angriffe.

    Nun habe ich noch Probleme mit dieser PHP-Warnung (Erweiterungen > Verwalten > Warnungen), oder ist das gar kein Problem?

    Zitat

    Das Verzeichnis für temporäre Dateien in PHP ist nicht gesetzt

    Dieses Verzeichnis wird zum temporären Speichern von hochgeladenen Dateien benutzt, bevor Joomla! auf die Datei zugreifen kann. Obwohl das temporäre Verzeichnis nicht gesetzt wurde, sollte es in der Regel keine Probleme geben. Wenn es Probleme gibt, dass XML-Dateien (Manifest-Dateien) nicht erkannt oder hochgeladene Dateien nicht gefunden werden, sollte der Wert von „upload_tmp_dir“ in der „php.ini“-Datei angepasst werden.

    Außerdem wüsste ich gern noch wie ich inkompatible Erweiterungen erkenne, und was es mit den oft niedrigen Versionen und den alten Datumsangaben der Erweiterungen auf sich hat.

    Wie kann ich erkennen, welche Erweiterung nicht kompatibel ist, und sich querlegt. Übrigens kann ich joomfish nicht finden, daher werde ich mal versuchen die ganze Zeile aus der sql-Datei zu löschen und nochmals zu importieren. Merkwürdig auch, dass das lokal mit xampp 5.6.33 und 10.1.30-MariaDB funktioniert.

    Lokal

    Zitat

    Datenbank-Server

    • Server: 127.0.0.1 via TCP/IP
    • Server-Typ: MariaDB
    • Server-Version: 10.1.30-MariaDB - mariadb.org binary distribution
    • Protokoll-Version: 10
    • Benutzer: root@localhost
    • Server-Zeichensatz: UTF-8 Unicode (utf8)

    Webserver

    • Apache/2.4.29 (Win32) OpenSSL/1.0.2n PHP/5.6.33
    • Datenbank-Client Version: libmysql - mysqlnd 5.0.11-dev - 20120503 - $Id: 76b08b24596e12d4553bd41fc93cccd5bac2fe7a $
    • PHP-Erweiterung: mysqli, curl, mbstring
    • PHP-Version: 5.5.33

    phpMyAdmin

    • Versionsinformationen: 4.7.4, aktuelle stabile Version: 4.7.9


    Server (remote, live)

    Systeminformationen

    Einstellung
    PHP erstellt für Linux info 3.0 #1337 SMP Tue Jan 01 00:00:00 CEST 2000 all GNU/Linux
    Datenbanktyp mysql
    Datenbankversion 5.5.59-0+deb7u1-log
    Datenbankzeichensatz latin1_german2_ci
    Datenbankverbindungszeichensatz utf8mb4_general_ci
    PHP-Version 7.1.15
    Webserver Apache
    PHP-Interface für den Webserver cgi-fcgi
    Joomla!-Version Joomla! 3.8.6 Stable [ Amani ] 13-March-2018 14:00 GMT
    Joomla!-Plattform-Version Joomla Platform 13.1.0 Stable [ Curiosity ] 24-Apr-2013 00:00 GMT
    Browsererkennung Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0



    Module, ID >10000
    FireShot Capture 006 - Erweiterungen_ V_ - http___www.my-joomla-site.local_administrator_index.php.pdf

    Danke, ich schaue mir das Morgen weiter an. Das Frontend funktioniert nach wie vor. Anfang Februar hatte ich jedenfalls nach jedem Upgrade-Schritt alle Komponenten jeweils aktualisiert, die Datenbank repariert und Akeeba-Backups erstellt. Gute Nacht!

    Der Link in #9 ist falsch, den hatte ich verwechselt mit dem zur php tmp Warnung. (leider lässt sich der Beitrag nun nicht mehr bearbeiten). https://stackoverflow.com/ques…-super-privileges-for-thi

    Hallo j!-n, vielen Dank für Deine Unterstützung! Danke für den Hinweis, dann sind das Reste von Joomfish, das ich vor dem upgrade von 2.5.18 über 3.5.1 auf 3.8.4 .. 3.8.6 nicht vollständig entfernt habe. Keine Ahnung, weshalb das lokal so läuft. Ich versuche es mal das lokal zu säubern und dann nochmal zu ex-/importieren. Wenn das nicht geht versuche ich mal Akeeba für die Migration auf den remote Server. Das hatte vorher auch schon geklappt.

    Mich wunderten schon die 4 Datenbankfehler. rtci1_jf_languages_ext hatte ich nicht mit joomfish assoziiert.


    Code
    1. Der Index „'idx_old_url'“ ist nicht in Tabelle „'rtci1_redirect_links'“ enthalten. (Von Datei: „3.5.0-2016-03-01.sql“.)
    2. Der Index „'idx_alias'“ ist nicht in Tabelle „'rtci1_content'“ enthalten. (Von Datei: „3.8.2-2017-10-14.sql“.)
    3. Der Index „'idx_client_id_parent_id_alias_language'“ ist nicht in Tabelle „'rtci1_menu'“ enthalten. (Von Datei: „2.5.0-2011-12-24.sql“.)
    4. Der Index „'idx_access'“ ist nicht in Tabelle „'rtci1_languages'“ enthalten. (Von Datei: „2.5.4-2012-03-19.sql“.)

    Die beiden letzten Zeilen (menu, languages) haben aber trotzdem nichts mit joomfish zu tun, sind aber von 2.5.x, oder bedeuten die Versionshinweise nur, mit welcher Version das in Joomla! eingeführt wurde?

    (Sorry, leider konnte ich das nicht mehr in den letzten Post eintragen).

    Laut https://stackoverflow.com/ques…temp-files-go-experiments hätte DEFINER=`dbo673384265`@`localhost` eigentlich gegen den Fehler #1227 helfen müssen.

    Im 1&1 Controlcenter wird dbo673384265 auch als Datenbankbenutzer angegeben. In der configuration.php auch.

    Oder spielt dieser Kommentar, Zeile 21-22, in der sql Datei die importiert werden soll auch eine Rolle?


    Code
    1. --
    2. -- Datenbank: `db517208114`
    3. --

    Ich habe nun die Datenbank nochmal importiert. Das schlug aber trotz Ersetzung des Datenbanknamens wieder fehl.

    Code
    1. #1227 - Access denied; you need (at least one of) the SUPER privilege(s) for this operation

    Komplett:

    Code
    1. SQL-Befehl: Dokumentation
    2. CREATE ALGORITHM=UNDEFINED DEFINER=`dbo673384265`@`localhost` SQL SECURITY DEFINER VIEW `rtci1_jf_languages` AS select `l`.`lang_id` AS `lang_id`,`l`.`lang_code` AS `lang_code`,`l`.`title` AS `title`,`l`.`title_native` AS `title_native`,`l`.`sef` AS `sef`,`l`.`description` AS `description`,`l`.`published` AS `published`,`l`.`image` AS `image`,`lext`.`image_ext` AS `image_ext`,`lext`.`fallback_code` AS `fallback_code`,`lext`.`params` AS `params`,`lext`.`ordering` AS `ordering` from (`rtci1_languages` `l` left join `rtci1_jf_languages_ext` `lext` on((`l`.`lang_id` = `lext`.`lang_id`))) order by `lext`.`ordering` ;
    3. MySQL meldet: Dokumentation
    4. #1227 - Access denied; you need (at least one of) the SUPER privilege(s) for this operation



    Zitat

    Warnung

    Achtung: Die Datenbank ist nicht auf dem neuesten Stand!


    Andere Informationen

    4 Datenbankprobleme gefunden!

    Nach der Datenbankreparatur wieder:

    Zitat

    Version des Datenbankschemas (in #__schemas): 3.8.6-2018-02-14

    Aktualisierungsversion (in #__extensions): 3.8.6

    Datenbanktreiber: mysqli

    146 Datenbankänderungen wurden überprüft.

    186 Datenbankänderungen hatten keinen Einfluss auf die Struktur der Datenbanktabellen und wurden deshalb übersprungen.

    Ich habe Akeeba für den Transfer ja gar nicht verwendet, nur zur Sicherheit Backups erstellt.

    Ich habe nun lokal nochmal getestet: Dort gibt es keine redirect links mit ID 0 und die Sprachdateien ließen sich problemlos upgraden.

    JCS funktioniert dort auch.

    .htaccess ist unterschiedlich


    Lokal

    $ egrep -v '^[[:space:]]*#|^ *$' "C:\xampp\htdocs\htdocs\.htaccess"


    Remote

    $ egrep -v '^[[:space:]]*#|^ *$' "C:\Users\Iarsin\AppData\Local\Temp\fz3temp-2\.htaccess"

    Hallo Axel,

    vielen Dank für Deine Antwort.

    Ich habe alle Dateien per FTP hochgeladen und per phpmyadmin die Datenbank exportiert, remote eine neue angelegt und per phpmyadmin wieder importiert. In der configuration.php habe ich log und tmp entsprechend der Serverangaben und die mysqli Zugänge, wie db, dbo und Passwörter angepasst.

    Die Datenbank unter Erweiterungen > Verwalten > Datenbank habe ich mehrmals repariert, auch kitepascals Prozedur auf Seite 1 unten im verlinkten 3seitigen Thread durchgeführt (core Dateien ersetzt, db-Reparatur etc.).

    Mit akeeba hatte ich vorher und nachher noch Backups gemacht. configuration.php hat 444, Dateien 604 und Verzeichnisse 705. Das Frontend funktioniert. Das Backend ja auch so weit, bis auf die genannten Einschränkungen, die mir bisher auffielen.

    Was ist mit meiner Vermutung, Vorkommnisse des alten Datenbanknamen in der zu importierenden sql-Datei per search-and-replace mit dem neuen Namen auszutauschen und dann nochmals den import (nach löschen der vermutlich korrupten db auf dem remote server) zu versuchen?

    Ich sehe gerade, seit dem Import angelegte redirect links haben die ID 0. Das ist doch auch ein Hinweis auf eine beschädigte Datenbank, oder?