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.

CREATE ALGORITHM=UNDEFINED DEFINER=`dbo517208114`@`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` ;

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

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

Die Fehlermeldung lautet:

Warning
Update: :Extension: Could not open
Warnung
Update: :Extension: „“ kann nicht geöffnet werden!
https://forum.joomla.de/thread/2239-extensions-update-geht-nicht/

Error
Invalid extension update
Fehler
Ungültiges Erweiterungsupdate

Notice
Before updating ensure that the update is compatible with your Joomla! installation.


Search
Name     Location     Type     Installed     Available     Folder     Install Type     URL Details

Dutch
Site     Package     3.8.4.1     3.8.6.1     N/A     Update     https://update.joomla.org/language/details3/nl-NL_details.xml

French
Site     Package     3.8.5.1     3.8.6.1     N/A     Update     https://update.joomla.org/language/details3/fr-FR_details.xml

German DE
Site     Package     3.8.5.1     3.8.6.1     N/A     Update     https://update.joomla.org/language/details3/de-DE_details.xml

Italian
Site     Package     3.8.5.1     3.8.6.1     N/A     Update     https://update.joomla.org/language/details3/it-IT_details.xml

RSForm! Pro 2.0.8
Administrator     Component     2.0.3     2.0.8     N/A     Update     https://www.rsjoomla.com/updates/com_rsform/Component/com_rsform.xml
https://www.rsjoomla.com/support/documentation/rsform-pro/changelog/rsform-pro-changelog.html

Spanish
Site     Package     3.8.5.1     3.8.6.1     N/A     Update     https://update.joomla.org/language/details3/es-ES_details.xml

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.

Core
PHP Version     7.1.15
Directive    Local Value    Master Value
sys_temp_dir    no value    no value

<?
// http://php.net/manual/de/function.sys-get-temp-dir.php
echo sys_get_temp_dir() . PHP_EOL;

gives: /tmp

[...]/htdocs/tmp: 705

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)

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.

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?

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"

<IfModule autoindex>
IndexIgnore *
</IfModule>
Options +FollowSymlinks
Options -Indexes
RewriteEngine On
RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule .* index.php [F]
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteCond %{REQUEST_URI} !^/index\.php
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* index.php [L]

Remote

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

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule .* index.php [F]
RewriteCond %{HTTP_USER_AGENT} .*{.* [NC]
RewriteRule .* - [F,L]
RewriteCond %{HTTP_USER_AGENT} O:[0-9]+: [NC]
RewriteRule .* - [F]
RewriteCond %{THE_REQUEST} !^POST
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php\ HTTP/
RewriteCond %{SERVER_PORT}>s ^(443>(s)|[0-9]+>s)$
RewriteRule ^index\.php$ http%2://www%.{HTTP_HOST}/$1 [R=301,L]
RewriteCond %{SERVER_PORT} !^443$
RewriteRule (.*) https://%{HTTP_HOST}/$1 [R=301,L]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]
RewriteCond %{HTTP:X-FORWARDED-FOR} ^66\.249\.(6[4-9]|[78][0-9]|9[0-5])\.
RewriteCond %{HTTP_USER_AGENT} Googlebot
RewriteCond %{REQUEST_URI} (/index\.php/de/|/)[a-z0-9+%\/]{6,21}[_/+]{0,1}[0-9a-z+%\=]{4,9}[-/+]{0,1}[0-9a-z+%.]{0,14}[/]{0,1}$
RewriteRule ^ - [R=410,G]
RewriteBase /
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteCond %{REQUEST_URI} !^/index\.php
RewriteCond %{REQUEST_URI} /component/|(/[^.]*|\.(php|html?|feed|pdf|vcf|raw))$ [NC]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* index.php [L]

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.

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

Komplett:

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.

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?

--
-- Datenbank: `db517208114`
--

SHOW GRANTS FOR 'dbo673384265'@'%'

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?

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.

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

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

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.

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

Die .htaccess hatte nichts damit zu tun, aber ich habe sie inzwischen um ein paar Zeilen aus der 3.8.6 htaccess erweitert, die die Verzeichnisauflistung („Directory Listing“) unterbinden.