WBCE CMS Forum

chriz

Member

[gelöst] GlobalStrings Manager läuft nicht wie erwartet / Meldungen im Errorlog

Ich habe zum ersten Mal das Modul GlobalStrings Manager ausprobiert.
Leider läuft es nicht wie erwartet. Oder ich habe es nicht verstanden....

Es lassen sich keine GlobalStrings anlegen. Die Auswahlliste StringArt ist immer leer.

Und auf der Optionen-Seite lassen sich die verschiedenen Einstellungen zwar umstellen, sie werden aber nicht gespeichert bzw. springen beim Speichern wieder auf die Defaults zurück.

GSM produziert viele Meldungen (Notice + Warning) im Errorlog:

2024-07-19 06:28:13 	User Notice 	/framework/class.database.php: L:333
from /modules/global_strings/functions/global_strings.functions.php L:151 	database->query "STATEMENT: SELECT `name`, `value` FROM `hhk_mod_global_strings_cfg`"
2024-07-19 06:28:13 	Warning 	/framework/class.database.php: L:737
from /modules/global_strings/functions/global_strings.functions.php L:152 	mysql->fetchRow "mysqli_fetch_array() expects parameter 1 to be mysqli_result, bool given"
2024-07-19 06:28:13 	User Notice 	/framework/class.database.php: L:333
from /modules/global_strings/functions/global_strings.functions.php L:151 	database->query "STATEMENT: SELECT `name`, `value` FROM `hhk_mod_global_strings_cfg`"
2024-07-19 06:28:13 	Warning 	/framework/class.database.php: L:737
from /modules/global_strings/functions/global_strings.functions.php L:152 	mysql->fetchRow "mysqli_fetch_array() expects parameter 1 to be mysqli_result, bool given"
2024-07-19 06:28:13 	Notice 	/modules/global_strings/tool.php: L:58
from /admin/admintools/tool.php L:100 	"Undefined property: stdClass::$string_types" 

Meine Umgebung:

WBCE

• WBCE Version: 1.6.2

• Tag: 1.6.2

• PHP Version: 7.4.33

Datenbank

• Server version    5.5.5-10.5.23-MariaDB-0+deb11u1

• Host info    Localhost via UNIX socket

• Protocol version    10

• Client info    mysqlnd 7.4.33

• Client encoding    utf8

Webserver

• Apache/2.4.61 (Debian)

Last edited by florian (19.07.2024 13:57:07)

florian

Administrator

Re: [gelöst] GlobalStrings Manager läuft nicht wie erwartet / Meldungen im Errorlog

Da ist bei der Installation irgendwas schiefgegangen. Die Tabellen scheinen nicht angelegt worden zu sein, und dann funktioniert das Modul natürlich nicht. Kannst du im Errorlog schauen, ob auch etwas während der Modulinstallation geloggt wurde?

---

Sorgen sind wie Nudeln: man macht sich meist zu viele.

chriz

Member

Re: [gelöst] GlobalStrings Manager läuft nicht wie erwartet / Meldungen im Errorlog

Ich habe den GSM nun de- und nochmal neu installiert.

Die Installation endet mit der Meldung "Droplet string installed successfully" auf einer ansonsten leeren Seite, springt aber nicht wieder zum Admin-Tool zurück.

Im ErrorLog steht nichts. In den Apache Logs und System-Logs auch nicht.

Bei der Deinstallation sieht man zwar kurz (zu kurz zum Kopieren) eine Meldung, dass drei Tabellen erfolgreich gedropped wurden,
Edit: aber in phpmyadmin finde ich (vorher) keine Tabellen des Moduls. Also sind sie wohl tatsächlich nicht angelegt worden...

Last edited by chriz (19.07.2024 09:28:57)

chriz

Member

Re: [gelöst] GlobalStrings Manager läuft nicht wie erwartet / Meldungen im Errorlog

Ich habe in GSM's install.php noch ein echo eingefügt:

// get functions file
require __DIR__.'/functions.php';
// check if we should install any DB TABLE's or if this is an upgrade
if(db_table_exists(STRINGS_CFG_TBL) == true) {
    echo "DB exists ". STRINGS_CFG_TBL;
    exit;
}

Und das meldet dann "DB exists ..._mod_unzip_cfg".

Also funkt das Modul unzip irgendwie dazwischen, so dass STRINGS_CFG_TBL nicht korrekt/wie erwartet gefüllt ist.

florian

Administrator

Re: [gelöst] GlobalStrings Manager läuft nicht wie erwartet / Meldungen im Errorlog

Ominös. Es gibt kein Modul unzip.

---

Sorgen sind wie Nudeln: man macht sich meist zu viele.

chriz

Member

Re: [gelöst] GlobalStrings Manager läuft nicht wie erwartet / Meldungen im Errorlog

Ein in GSM's functions.php eingefügtes echo

$sDirname = basename(dirname(__FILE__));
echo "functions.php sDirname " . $sDirname . "  " . __FILE__;

zeigt auch ein sDirname "unzip" an bzw.  "wbce/temp/unzip/functions.php"

Last edited by chriz (19.07.2024 10:50:07)

chriz

Member

Re: [gelöst] GlobalStrings Manager läuft nicht wie erwartet / Meldungen im Errorlog

Es liegt vermutlich an einer Unverträglichkeit mit https://forum.wbce.org/viewtopic.php?pid=43764#p43764

Dort hatte ich ja die Modulinstallation so angepasst, dass es nicht mehr zu den PHP-Cache Problemen kommt. Dazu wird im temp/unzip Verzeichnis gearbeitet.

Und das passt nicht mit dem $sDirname = basename(dirname(__FILE__)); von GSM zusammen.

Ich bleibe dran, brauche jetzt aber mal 'ne Pause...

chriz

Member

Re: [gelöst] GlobalStrings Manager läuft nicht wie erwartet / Meldungen im Errorlog

Ursache gefunden. War zum Glück ein lokales Problem.

Ich hatte noch weiter im admin/modules/install.php minimal(!)  "optimiert".
So dass dann das jeweilige Modul-install.php statt im Modul- im temp-Directory ausgeführt wurde, mit obigen Folgen...

Sorry für die Aufregung.

PS: Falls es jemanden interessiert:

Ich hatte das:

// Run the modules install // upgrade script if there is one
if (file_exists($module_dir . '/' . $action . '.php')) {
    require($module_dir . '/' . $action . '.php');
}

// Load upgraded module info into DB.
// But no longer from $module_dir. Instead from original unzipped dir,
// due to possible opcache issues otherwise! Especially when upgrading the module!
// Print success message
if ($action == "install") {
    load_module($temp_unzip, false);
    $admin->print_success($MESSAGE['GENERIC_INSTALLED']);
} elseif ($action == "upgrade") {
    upgrade_module($temp_unzip, false);
    $admin->print_success($MESSAGE['GENERIC_UPGRADED']);
}

zu Folgendem reduziert/"optimiert", weil ja der Aufruf der modulspezifischen install/upgrade.php auch in load_module() bzw. upgrade_module() identisch wie oben existiert und einfach mit Parameter "true" aktiviert werden kann:

// Load upgraded module info into DB.
// And run the modules install // upgrade script if there is one.
// But no longer from $module_dir. Instead from original unzipped dir,
// due to possible opcache issues otherwise! Especially when upgrading the module!
// Print success message
if ($action == "install") {
    load_module($temp_unzip, true);
    $admin->print_success($MESSAGE['GENERIC_INSTALLED']);
} elseif ($action == "upgrade") {
    upgrade_module($temp_unzip, true);
    $admin->print_success($MESSAGE['GENERIC_UPGRADED']);
}

Die unterschiedlichen Verzeichnisse lassen diesen Ansatz aber scheitern.

Last edited by chriz (19.07.2024 13:33:02)