Update-Probleme und JCS funktioniert nicht nach Übertragung auf den Server

  • Hallo,


    ich habe ein ähnliches Problem, wie in diesem Thread beschrieben

    Extensions Update geht nicht

    Mir fiel jetzt auf, dass die Sprachdateien nicht aktualisiert werden können und auch der Joomla Checksumscanner JCS von Rubik Kubik, im Gegensatz zur lokalen Stamminstallation (php 5.6.33), nicht mehr richtig funktioniert.

    Beim Import der Datenbank gab es wohl wegen einem Datenbankeintrag der alten Datenbank ein Problem. Ich dachte die Reparatur der Datenbank hätte das behoben. Dann gab es doppelte Einträge der Sprachdateien. Nach dem Aufräumen der Quellliste tauchen die Spracherweiterungen aber nur noch einmal auf, werden also normal dargestellt, nur lassen sie sich immer noch nicht instalieren.



    Die Fehlermeldung lautet:



    Außerdem gibt es eine Warnung:


    Zitat

    Warning

    There are some warnings detected.


    The PHP temporary folder is not set.

    The PHP temporary folder is the folder that PHP uses to store an uploaded file before Joomla can access this file. Whilst the folder not being set isn't always a problem, if you are having issues with manifest files not being detected or uploaded files not being detected, setting this in your php.ini file might fix the issue.


    System Temp Dir ist aber /tmp. Keine Ahnung also, ob das damit zu tun hat.


    Kubik Rubiks Joomla Cecksum Scanner JCS arbeitet auch nur in der lokalen Installation. Auf dem Remote-Server kommt eine Fehlermeldung:


    Joomla Checksum Scanner (JCS, kubik rubik)

    Code
    COM_JOOMLACHECKSUMSCANNER_SCAN_ERROR="Error! Scan process could not be executed properly."

    https://github.com/Kubik-Rubik…joomlachecksumscanner.php


    Alle Infos: https://bpaste.net/show/6746788bf407


    Sollte ich den Datenbank-Import nochmal wiederholen und dabei vorher die Einträge i der sql-Datei mit Suchen-und-Ersetzen an die neue Datenbank anpassen um den SuperUser-Fehler beim Import zu umgehen, oder hat das mit irgendwelchen Proxy- oder sonstigen Server-Einstellungen zu tun?

    Ich kann gerne noch weitere Infos nachliefern.

  • Womit bist du denn umgezogen? MIt Akeeba oder mit dem JEB von Kubik Rubik?

    Falls mit Akeeba: deinstalliere Akeeba und nimm den JEB. Akeeba meldet leider ab und an Fehler.


    Es gibt dann auch noch die Möglichkeit, dass du per FTP die aktuelle Joomla-Version (3.6.6 3.8.6), bis auf das installationsverzeichnis, über die vorhandenen Dateien kopierst und danach nochmal die Datenbank im Backend reparierst. Reparieren auch, wenn die Meldung auftaucht, das alles in Ordnung sei. Kaputtmachen kannst nichts.


    Achte auch darauf, dass der tmp-Ordner nicht nur angelegt ist, sondern auch in der Configuration per Webserver-Pfad angegeben ist.


    Danach schauen wir dann weiter...



    Axel

  • 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?

  • die aktuelle Joomla-Version (3.6.6),

    Das muss natürlich 3.8.6 heißen!


    Deinstalliere mal in der localversion Akeeba komplett und nutze es einfach nicht mehr ;)

    Besser ist Easy Joomla Backup (EJB) von Kubik Rubik.


    Zu deiner Vermutung kann ich dir leider nichts sagen.


    Was passiert denn, wenn du einfahc mal ein "jungfräuliches" Joomla direkt installierst? Gibt es da auch Probleme oder läuft das sauber durch?



    Axel

  • 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"

  • Ich habe nun mal die remote .htaccess lokal „installiert“. Nun bekomme ich dort ein 404. Vielleicht liegt es also wirklich an der .htaccess . Ich werde dem mal weiter nachgehen. Vielleicht probiere ich auch mal zu Testzwecken eine Joomla!-Standardinstallation Remote, dazu muss ich aber eine andere Datenbank löschen. Jetzt gehe ich erst mal raus.

  • Nein, das lag am redirect auf https:// , die Seite wird hier vom xampp lokal wohl nicht über :443 ausgeliefert. Da müsste ich nochmal schauen, was da in der Apache-Konfíguration des xampp falsch eingestellt ist.
    Übrigens meinte ich die Anweisungen deGobbis, in Kommentar #20, hatte ihn mit kitepascal verwechselt.

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

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

    Komplett:

    Code
    SQL-Befehl: Dokumentation
    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` ;
    MySQL meldet: Dokumentation
    #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.


  • Code
    SHOW GRANTS FOR 'dbo673384265'@'%'

    Code
    Grants for dbo673384265@%
    GRANT USAGE ON *.* TO 'dbo673384265'@'%' IDENTIFIED BY PASSWORD <secret>
    GRANT ALL PRIVILEGES ON `db673384265`.* TO 'dbo673384265'@'%'

    Die zweite Zeile bedeutet doch, dass alle Rechte vorhanden sind, oder?

  • Nimm Akeeba Backup, das habe ich mehrere Jahre meist problemlos im Einsatz. Was auch immer du da für einen Dump importieren willst, erfordert Userrechte für die DB, die nicht vorhanden sind. Wenn das Wiederherstellen mit AB auch nicht geht, wende dich an den Hoster. Wenn du Pech hast (und da bin ich mir ziemlich sicher, habe, glaube ich, schon mal sowas migriert), läuft JoomFish eh nicht mit J3, geschweige denn mit PHP7.

  • 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
    Der Index „'idx_old_url'“ ist nicht in Tabelle „'rtci1_redirect_links'“ enthalten. (Von Datei: „3.5.0-2016-03-01.sql“.)
    Der Index „'idx_alias'“ ist nicht in Tabelle „'rtci1_content'“ enthalten. (Von Datei: „3.8.2-2017-10-14.sql“.)
    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“.)
    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).

  • Code
    CREATE ALGORITHM=UNDEFINED DEFINER=`dbo673384265`@`localhost` SQL SECURITY DEFINER VIEW

    Mit dem Teil des Statements kann der User deiner DB bei 1und1 nix anfangen. Hast du denn in der 2.5 mal aufs DB reparieren-Knöpfchen gedrückt? Einmal zuviel schadet nichts. Versuch einfach, die Kiste mit AB wiederherzustellen, und wenn dir das keine Fehler wirft, sollte das DB-Reparieren auch in 3.x keine Probleme machen. Kann natürlich anders kommen, dann evtl von selbst Hand anlegen, die Updates sind in /administrator/components/com_admin/sql/updates/mysql. Präfix anpassen.

  • 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

  • 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

  • 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
    -- Zeile 36285
    --
    -- Struktur des Views `rtci1_jf_languages`
    --
    DROP TABLE IF EXISTS `rtci1_jf_languages`;
    -- joomfish-Reste
    -- 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` ;
    -- 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.