Fehler beim Template-Installation (bzw. Upgrade): Kein Update der DB

chriz · 17.05.2024 06:30:31

Hallo zusammen!

Ich habe hier einen "interessanten" Effekt/Fehler bei der Installation eines Templates (Caminar).
Vermutlich liegt es nicht am Template selbst, sondern am Core. Deshalb habe ich dieses Unterforum hier gewählt.

Die Erstinstallation klappt vollkommen problemlos.

Wenn allerdings später ein Upgrade des Templates installiert wird, wird es zwar installiert (und lässt sich auch korrekt nutzen), aber der Eintrag in der Datenbank (Tabelle ..._addons) wird nicht aktualisiert. Und so ist die Anzeige im Backend falsch. So scheint es zumindest...

Genauer: Es passiert Folgendes:

* Die Versionsnummer der neu zu installierenden Template-Version wird gegen die Version des Templates auf der Platte geprüft
* Wenn sie größer (also neuer) ist:
* Die Daten aus der info.php der alten(!) Version auf der Platte werden ausgelesen und in die DB geschrieben
* Die neue Template-Version wird korrekt aus der ZIP-Datei in das templates-Verzeichnis ausgepackt

Und so ist die Inkonsistenz da.

Das lässt sich einfach testen, indem vor dem Template-Upgrade in der info.php des Templates auf der Platte manuell ein Datenfeld markiert wird. Ich hatte in "$template_description" einen Kommentar geschrieben. Der landet dann zusammen mit der kompletten alten info.php in der Datenbank/im Backend.

In der zuständigen

wbce/admin/templates/install.php

sieht das von der Reihenfolge her korrekt aus:

[== PHP ==]

// Unzip template to the template dir
$list = $archive->extract(
    PCLZIP_OPT_PATH,
    $template_dir,
    PCLZIP_CB_PRE_EXTRACT,
    'pclzip_extraction_filter',
    PCLZIP_OPT_REPLACE_NEWER
);

// Delete the temp zip file
if (file_exists($temp_file)) {
    unlink($temp_file);
}

// Chmod all the uploaded files
$dir = dir($template_dir);
while (false !== $entry = $dir->read()) {
    // Skip pointers
    if (substr($entry, 0, 1) != '.' and $entry != '.svn' and !is_dir($template_dir . '/' . $entry)) {
        // Chmod file
        change_mode($template_dir . '/' . $entry);
    }
}

// Load template info into DB
load_template($template_dir);

"Irgendwie" kommt da die Reihenfolge durcheinander, das "load_template()" scheint vor dem Auspacken abzulaufen!?!?!
Ich bin noch nicht schlau draus geworden...

Vielleicht kann zumindest jemand von euch den Effekt reproduzieren. Dann weiß ich zumindest, dass es nicht an meinen Systemen liegt.
(WBCE 1.6.2)

bernd · 17.05.2024 08:45:04

Die "gute" Nachricht:
ich kann es reproduzieren und es ist definitv unabhängig vom Template (habe es mit "justthefacts" ausprobiert).
Die "schlechte " Nachricht:
keine Ahnung was da schief läuft ...

chriz · 17.05.2024 20:46:17

Nach vielem Rumprobieren (mangels echter PHP-Ahnung) habe ich das Problem zumindest ein wenig eingekreist.

In wbce/admin/templates/install.php, die deutschen Kommentare sind von mir zur ergänzenden Erklärung:

Das initiale require() aus dem $temp_dir klappt korrekt (die neue info.php),
ebenso wie folgender require() etwas später die alte, noch aktuelle info.php einliest:

[== PHP ==]
// Check if this module is already installed
// and compare versions if so
$new_template_version = $template_version;
if (is_dir(WB_PATH . '/templates/' . $template_directory)) {
    if (file_exists(WB_PATH . '/templates/' . $template_directory . '/info.php')) {

        // dieses require() klappt und liest korrekt die alten Daten ein
        require(WB_PATH . '/templates/' . $template_directory . '/info.php');

        // Version to be installed is older than currently installed version
        if (versionCompare($template_version, $new_template_version, '>=')) {
            if (file_exists($temp_file)) {
                unlink($temp_file);
            } // Remove temp file
            $admin->print_error($MESSAGE['GENERIC_ALREADY_INSTALLED']);
        }
    }
    $success_message = $MESSAGE['GENERIC_UPGRADED'];
} else {
    $success_message = $MESSAGE['GENERIC_INSTALLED'];
}

Aber dieser require() scheint so etwas wie einen "read-only-Effekt" yikes zu haben. Die folgenden requires() kommen nicht zur Geltung:

[== PHP ==]
// Unzip template to the template dir
$list = $archive->extract(
    PCLZIP_OPT_PATH,
    $template_dir,
    PCLZIP_CB_PRE_EXTRACT,
    'pclzip_extraction_filter',
    PCLZIP_OPT_REPLACE_NEWER
);

// das Test-copy() zeigt, dass nach dem unzip nun tatsächlich die neue Version im Template-Verzeichnis liegt
// $f = $template_dir . '/info.php';
// if (!copy($f, $f.'x')) {
//    echo "failed to copy $file...\n";
// }

// ABER die folgenden requires() wirken irgendwie nicht, beide Test-Zeilen nicht!?!?!?! 
require($template_dir . '/info.php');
require(WB_PATH . '/templates/' . $template_directory . '/info.php');

// Die alten Werte z.B. in $template_version bleiben erhalten
$admin->print_success("UNZIPPED-1  " . $template_version . "    " . $template_dir);

Im etwas weiter unten folgenden

[== PHP ==]
    load_template($template_dir);

werden (geplant) die Daten aus info.php wie eben in den Test-requires() eingelesen aber ebenso nur die alten Werte erkannt/erhalten!

Und so steht in der Datenbank jeweils der Datensatz der eben überschriebenen alten Template-Version. Und nicht der neue.

Kapieren tue ich nicht, was da schief läuft. Irgendein Cache-Mechanismus?
Wenn mir noch etwas einfällt, teste ich weiter...

Last edited by chriz (17.05.2024 20:54:45)

chriz · 17.05.2024 21:26:00

Nein, das ist doch kein "Read-Only-Effekt". Sondern wohl wirklich ein Puffer/Cache, der da irgendwie dazwischen kommt.

[== PHP ==]
// Unzip template to the template dir                                                                                 
$list = $archive->extract(                                                                                            
    PCLZIP_OPT_PATH,
    $template_dir,
    PCLZIP_CB_PRE_EXTRACT,
    'pclzip_extraction_filter',                                                                                       
    PCLZIP_OPT_REPLACE_NEWER                                                                                          
);                                                                                                                    

// das copy() zeigt, dass nun tatsächlich die neue Version auf Platte liegt
// lässt sich in einer Shell o.Ä. überprüfen
$f = $template_dir . '/info.php';                                                                                     
if (!copy($f, $f.'-copy')) {                                                                                              
    echo "failed to copy $file...\n";
}

// Das Einlesen der Kopie zeigt korrekt die neuen Daten
require(WB_PATH . '/templates/' . $template_directory . '/info.php-copy');
$admin->print_success("UNZIPPED + Kopie  " . $template_version);

// Aber beim Einlesen des Originals kommen die Werte aus den alten Dateien, die gar nicht mehr existieren, zum Vorschein
require(WB_PATH . '/templates/' . $template_directory . '/info.php');
$admin->print_success("UNZIPPED-Original  " . $template_version);

Faszinierend roll

chriz · 18.05.2024 08:29:15

Ich habe nun eine sehr ähnliche Fehlerbeschreibung gefunden:

https://stackoverflow.com/questions/488 … in-php-5-6

... und werde damit weiter forschen.

Treffer! smile

Eine kleine Änderung in der php.ini lässt alles wieder funktionieren!

; How often (in seconds) to check file timestamps for changes to the shared
; memory storage allocation. ("1" means validate once per second, but only
; once per request. "0" means always validate)
;opcache.revalidate_freq=2
; MODIFIED:
opcache.revalidate_freq=0

Das ist natürlich keine wirkliche Lösung, aber ein Workaround. Und nun scheint die Ursache klar zu sein.

Mehrfaches Nutzen von require() auf dieselbe Datei innerhalb eines Requests schlägt fehl (bzw. liest die alten Daten ein), wenn die Datei im OS verändert wurde, wie es hier im Template/Modul-Install durch das $archive->extract() geschieht.

Last edited by chriz (18.05.2024 09:47:43)

Slugger, mk70

chriz · 18.05.2024 09:08:14

Und hier eine mögliche Lösung:

Direkt nach dem Unzippen ins Template-Verzeichnis die info.php im Cache invalidieren:

[== PHP ==]
// Unzip template to the template dir
$list = $archive->extract(
    PCLZIP_OPT_PATH,
    $template_dir, 
    PCLZIP_CB_PRE_EXTRACT,
    'pclzip_extraction_filter',
    PCLZIP_OPT_REPLACE_NEWER
);

// Make especially the require('info.php') in load_template() below
// aware of the new contents of info.php!
opcache_invalidate($template_dir . '/info.php');

Dann kann auch die Workaround-Einstellung in der php.ini aus Beitrag #5 wieder weg.

Ich vermute, dass das nicht nur das install.php für die Templates betrifft!
Weitere Kandidaten sind:
* admin/modules/install.php
* admin/languages/install.php

Last edited by chriz (19.05.2024 06:41:47)

mk70, florian

florian · 20.05.2024 18:40:09

Danke für den Hinweis und den Lösungsansatz, ich schaue mir das die Tage genauer an.

bernd · 20.05.2024 18:45:31

Ich vermute, dass das nicht nur das install.php für die Templates betrifft!
Weitere Kandidaten sind:
* admin/modules/install.php
* admin/languages/install.php

Bei languages wohl eher nicht, dort gibt es ja keine info.php und die entsprechende Sprach .php wird direkt "verwuschtelt".

Last edited by bernd (20.05.2024 18:46:09)

chriz · 20.05.2024 19:02:04

bernd wrote:

Ich vermute, dass das nicht nur das install.php für die Templates betrifft!
Weitere Kandidaten sind:
* admin/modules/install.php
* admin/languages/install.php
Bei languages wohl eher nicht, dort gibt es ja keine info.php und die entsprechende Sprach .php wird direkt "verwuschtelt".

Ach ja, direkt verwurschtelt, stimmt. Aber beinahe: wink :

[== PHP ==]
        // require($sFilePath);  it's to large
        // read contents of the template language file into string
        // ...

Allerdings ist in dem languages/install.php auch eine Abfolge drin, die vielleicht überprüft werden sollte:
Und zwar das rename() und kurz dahinter require():

[== PHP ==]
rename($temp_file, $language_file);

// Chmod the file
change_mode($language_file, 'file');

// Load language info into DB
load_language($language_file);

// Restore to correct language
require(WB_PATH . '/languages/' . LANGUAGE . '.php');

Nachtrag: Das gilt (noch) für WBCE 1.6.2. In jüngeren Commits wurde admin/languages/install.php von Florian stark überarbeitet.
Das habe ich gerade erst gesehen...

Last edited by chriz (24.05.2024 15:32:12)

florian · 22.05.2024 06:55:15

Vielen Dank für den Hinweis und die weitere Erforschung. Auf so was soll man erstmal kommen...
So weit ich sehe, tritt das Problem nicht grundsätzlich auf, sondern nur auf Webspaces, bei denen opcache aktiviert ist.
Leider gibt es Hoster, die aus Sicherheitsgründen opcache_invalidate deaktivieren (ergoogeltes Beispiel), es bedarf also noch Prüfungen, ob es a) die Funktion gibt und b) diese ausgeführt werden kann (Funktion isClearable ganz unten), da braucht es also doch wieder noch etwas mehr Code drumherum.

Last edited by florian (22.05.2024 06:56:28)

chriz · 22.05.2024 07:37:47

Wenn es so viele Konfigurations-Unwägbarkeiten bzgl. opcache gibt, macht es vermutlich mehr Sinn, das Problem zu umschiffen, als zu versuchen, alle Sonderfälle abzudecken.

Ich denke da z.B. an ein etwas anderes Vorgehen beim Entpacken und in die DB Einlesen.
So dass ein möglicherweise aktivierter Cache gar kein Problem darstellt.

Schaue ich mir nachher mal etwas an.

chriz · 22.05.2024 09:10:59

Hier nun ein Lösungsweg, ohne opcache speziell zu behandeln.

Die Daten für den Eintrag in der DB werden nun aus dem initialen unzip-Verzeichnis gelesen, nicht mehr aus der eventuell durch opcache fragwürdigen Abfrage des template-Verzeichnisses.

Bei der Gelegenheit habe ich auch noch das Aufräumen im Fehlerfall an einer Stelle komplettiert.

Das neue install.php ist angehängt, der diff zum Original ist dies:

root@pi6:/var/www/html/wbce-hhk/admin/templates# diff install-orig.php install.php

144a145,149
>     // Remove the temp unzip directory and the temp zip file
>     rm_full_dir($temp_unzip);
>     if (file_exists($temp_file)) {
>         unlink($temp_file);
>     }
156,158d160
< // Delete the temp unzip directory
< rm_full_dir($temp_unzip);
< 
205,209d206
< // Delete the temp zip file
< if (file_exists($temp_file)) {
<     unlink($temp_file);
< }
< 
220,221c217,225
< // Load template info into DB
< load_template($template_dir);
---
> // Load template info into DB, but no longer from $template_dir.
> // Instead from original unzipped dir, due to possible opcache issues otherwise!
> load_template($temp_unzip);
> 
> // Remove the temp unzip directory and the temp zip file
> rm_full_dir($temp_unzip);
> if (file_exists($temp_file)) {
>     unlink($temp_file);
> }

Last edited by chriz (22.05.2024 09:14:53)

chriz · 22.05.2024 09:16:48

chriz wrote:

Das neue install.php ist angehängt,

Irgendwie klappt das mit dem Anhängen nicht. Keine Fehlermeldung, aber auch kein Anhang dran...

Nächster Versuch...

Last edited by chriz (22.05.2024 09:19:53)

chriz · 22.05.2024 09:18:20

Dann halt so:

[== PHP ==]
<?php
/**
 * WebsiteBaker Community Edition (WBCE)
 * Way Better Content Editing.
 * Visit http://wbce.org to learn more and to join the community.
 *
 * @copyright Ryan Djurovich (2004-2009)
 * @copyright WebsiteBaker Org. e.V. (2009-2015)
 * @copyright WBCE Project (2015-)
 * @license GNU GPL2 (or any later version)
 */

/**
 * pclzip_extraction_filter
 * PclZip filter to extract only files inside Add-on root path
 */
function pclzip_extraction_filter($p_event, &$p_header)
{
    global $addon_root_path;
    // don't apply filter for regular zipped WBCE Add-on archives w/o subfolders
    if ($addon_root_path == '/.') {
        return 1;
    }

    // exclude all files not stored inside the $addon_root_path (subfolders)
    if (strpos($p_header['filename'], $addon_root_path) == false) {
        return 0;
    }

    // remove $addon_root_path from absolute path of the file to extract
    $p_header['filename'] = str_replace($addon_root_path, '', $p_header['filename']);
    return 1;
}

/**
 * find_addon_root_path
 * Returns WBCE Add-on root path inside a given zip archive
 * Supports nested archives (e.g. incl. Add-on folder or GitHub archives)
 * @return string
 */
function find_addon_root_path($zip)
{
    // get list of files contained in the zip object
    if (($zip_files = $zip->listContent()) == 0) {
        return '';
    }

    // find first folder containing an info.php file
    foreach ($zip_files as $zip_file => $info) {
        if (basename($info['filename']) == 'info.php') {
            return '/' . dirname($info['filename']);
        }
    }
    return '';
}

// do not display notices and warnings during installation
error_reporting(E_ALL ^ E_NOTICE ^ E_WARNING);

// Include required files
require '../../config.php';
require_once WB_PATH . '/framework/addon.precheck.inc.php';
require_once WB_PATH . '/framework/functions.php';
require_once WB_PATH . '/include/pclzip/pclzip.lib.php';

// Setup admin object, skip header for FTAN validation and check section permissions
$admin = new admin('Addons', 'templates_install', false, true);
if (!$admin->checkFTAN()) {
    $admin->print_header();
    $admin->print_error($MESSAGE['GENERIC_SECURITY_ACCESS']);
}
// Output admin backend header (this creates a new FTAN)
$admin->print_header();

// Check if user uploaded a file
if (!(isset($_FILES['userfile']) && isset($_FILES['userfile']['name']))) {
    $admin->print_error($MESSAGE['GENERIC_SECURITY_ACCESS']);
}

// Check write permissions for templates folder
if (!is_writable(WB_PATH . '/templates/')) {
    $admin->print_error($MESSAGE['GENERIC_BAD_PERMISSIONS']);
}

// Create unique file within WBCE /temp folder
$temp_dir = WB_PATH . '/temp/';
$temp_file = tempnam($temp_dir, 'wb_');
$temp_unzip = WB_PATH . '/temp/unzip/';

// Move uploaded file to WBCE /temp folder and deal with possible upload errors
if (!$_FILES['userfile']['error']) {
    // Try uploading file to WBCE /temp folder
    if (!move_uploaded_file($_FILES['userfile']['tmp_name'], $temp_file)) {
        $admin->print_error($MESSAGE['GENERIC_BAD_PERMISSIONS']);
    }
} else {
    // work out error message
    $error_code = $_FILES['userfile']['error'];
    switch ($error_code) {
        case UPLOAD_ERR_INI_SIZE:
            $key = 'UPLOAD_ERR_INI_SIZE';
            break;
        case UPLOAD_ERR_FORM_SIZE:
            $key = 'UPLOAD_ERR_FORM_SIZE';
            break;
        case UPLOAD_ERR_PARTIAL:
            $key = 'UPLOAD_ERR_PARTIAL';
            break;
        case UPLOAD_ERR_NO_FILE:
            $key = 'UPLOAD_ERR_NO_FILE';
            break;
        case UPLOAD_ERR_NO_TMP_DIR:
            $key = 'UPLOAD_ERR_NO_TMP_DIR';
            break;
        case UPLOAD_ERR_CANT_WRITE:
            $key = 'UPLOAD_ERR_CANT_WRITE';
            break;
        case UPLOAD_ERR_EXTENSION:
            $key = 'UPLOAD_ERR_EXTENSION';
            break;
        default:
            $key = 'UNKNOW_UPLOAD_ERROR';
    }
    $admin->print_error($MESSAGE[$key] . '<br />' . $MESSAGE['GENERIC_CANNOT_UPLOAD']);
}

// remove temporary unzip folder if exists to avoid unzip process fails
rm_full_dir($temp_unzip);

// create PclZip object to extract Addon zip archives
$archive = new PclZip($temp_file);

// extract Add-on files into WBCE temp folder
$addon_root_path = find_addon_root_path($archive);
$list = $archive->extract(
    PCLZIP_OPT_PATH,
    $temp_unzip,
    PCLZIP_CB_PRE_EXTRACT,
    'pclzip_extraction_filter',
    PCLZIP_OPT_REPLACE_NEWER
);

// Check if uploaded file is a valid Add-On zip file
if (!($list && file_exists($temp_unzip . 'info.php'))) {
    // Remove the temp unzip directory and the temp zip file
    rm_full_dir($temp_unzip);
    if (file_exists($temp_file)) {
        unlink($temp_file);
    }
    $admin->print_error($MESSAGE['GENERIC_INVALID_ADDON_FILE']);
}

// Include the templates info file
unset($template_directory);
unset($theme_directory);
require($temp_unzip . 'info.php');

// Perform Add-on requirement checks before proceeding
preCheckAddon($temp_file);

// Check if the file is valid
if (!isset($template_directory)) {
    if (file_exists($temp_file)) {
        unlink($temp_file);
    } // Remove temp file
    $admin->print_error($MESSAGE['GENERIC_INVALID']);
}

// Check if this module is already installed
// and compare versions if so
$new_template_version = $template_version;
if (is_dir(WB_PATH . '/templates/' . $template_directory)) {
    if (file_exists(WB_PATH . '/templates/' . $template_directory . '/info.php')) {
        require(WB_PATH . '/templates/' . $template_directory . '/info.php');
        // Version to be installed is older than currently installed version
        if (versionCompare($template_version, $new_template_version, '>=')) {
            if (file_exists($temp_file)) {
                unlink($temp_file);
            } // Remove temp file
            $admin->print_error($MESSAGE['GENERIC_ALREADY_INSTALLED']);
        }
    }
    $success_message = $MESSAGE['GENERIC_UPGRADED'];
} else {
    $success_message = $MESSAGE['GENERIC_INSTALLED'];
}

// Set template dir
$template_dir = WB_PATH . '/templates/' . $template_directory;

// Make sure the template dir exists, and chmod if needed
if (!file_exists($template_dir)) {
    make_dir($template_dir);
} else {
    change_mode($template_dir, 'dir');
}

// Unzip template to the template dir
$list = $archive->extract(
    PCLZIP_OPT_PATH,
    $template_dir,
    PCLZIP_CB_PRE_EXTRACT,
    'pclzip_extraction_filter',
    PCLZIP_OPT_REPLACE_NEWER
);

// Chmod all the uploaded files
$dir = dir($template_dir);
while (false !== $entry = $dir->read()) {
    // Skip pointers
    if (substr($entry, 0, 1) != '.' and $entry != '.svn' and !is_dir($template_dir . '/' . $entry)) {
        // Chmod file
        change_mode($template_dir . '/' . $entry);
    }
}

// Load template info into DB, but no longer from $template_dir.
// Instead from original unzipped dir, due to possible opcache issues otherwise!
load_template($temp_unzip);

// Remove the temp unzip directory and the temp zip file
rm_full_dir($temp_unzip);
if (file_exists($temp_file)) {
    unlink($temp_file);
}

// Print success message
$admin->print_success($success_message);

// Print admin footer
$admin->print_footer();

PS: Und nun auch als Pull-Request: https://github.com/WBCE/WBCE_CMS/pull/558 wink

Last edited by chriz (24.05.2024 06:40:11)

mk70

chriz · 24.05.2024 10:05:25

Zur Zeit schaue ich mir das admin/modules/install.php an.
Es ist nahezu identisch programmiert wie das admin/templates/install.php. Aber der störende Caching-Effekt tritt dort nicht auf!?!??!?! yikes
Ich versteh's noch nicht...

Nachtrag 1:

Doch, in admin/modules/install.php passiert es auch.
Es ist nur nicht so deutlich, weil ausgerechnet die $module_version hier anders behandelt wird:
Schon vor dem Unzip/Caching wird $new_module_version explizit gespeichert und dann später in upgrade_module() per global übergeben und in der DB eingetragen.
Die anderen Felder aus info.php bleiben aber auf den alten/gecache-ten Werten. Also doppelt inkonsistent...

Nachtrag 2:

Ich habe nun auch admin/modules/install.php vergleichbar angepasst.
Damit das klappt, mussten auch framework/functions.php und admin/modules/manual_install.php angepasst werden.

Alles zusammen ist in obigem Pull-Request https://github.com/WBCE/WBCE_CMS/pull/558

Das funktioniert nun (zumindest bei mir).

Allerdings ist der Lösungsweg nicht sehr intuitiv, da nun hier ein $temp_unzip Pfad an framework/functions.php übergeben und dort als $sModulePath weiterverarbeitet wird...

Last edited by chriz (24.05.2024 18:29:41)

florian

florian · 24.05.2024 18:49:55

Danke, klappt reibungslos. Hab's gemerged.

florian · 10.10.2024 06:13:02

Ich habe jetzt erst beim Testen gemerkt, dass es da doch einen etwas unschönen Nebeneffekt gibt.
Siehe https://github.com/WBCE/WBCE_CMS/issues/560
Das passiert bislang (ich habe noch nicht alle Module durrchgetestet) nur beim Installieren / Updaten des Moduls News With Images, aber irgendwie fühlt sich seit der Änderung der Installer/Updater dazu berufen, die einzelnen Moduldateien zusätzlich als Droplets zu interpretieren und dort erscheinen zu lassen.

Last edited by florian (10.10.2024 06:14:05)

chriz · 14.10.2024 19:42:01

Ich habe die Ursache gefunden.

Das admin/modules/install.php scheint in bestimmten Fällen - die ich noch untersuchen werde - das Verzeichnis temp/unzip nicht zu löschen.

Ungücklicherweise nutzt News-with-Images-main/install.php dasselbe Verzeichnis, allerdings ohne sicherzustellen, dass es leer ist
(deutschsprachige Kommentare und die zwei Workaround-Zeilen sind hier von mir ergänzt):

[== PHP ==]
    // install the droplet(s)
    if(!defined('CAT_PATH')) {
        try {
            // workaround for problem with global $module_directory overwritten
            // by functions.inc.php here
            $orig_module_dir = $module_directory;
             include WB_PATH.'/modules/droplets/functions.inc.php';
            make_dir(WB_PATH.'/temp/unzip');

            # Problem: 
            # Wenn dieses temp/unzip-Verzeichnis zufällig schon existiert und dann noch php-Dateien enthält
            # werden diese im weiteren Verlauf als Droplets eingelesen.
            # Als Sicherheitsmaßnahme könnten folgende zwei zusätzlichen Zeilen dienen:
            rm_full_dir(WB_PATH.'/temp/unzip');
            make_dir(WB_PATH.'/temp/unzip');

            wbce_unpack_and_import(WB_PATH.'/modules/news_img/droplets/droplet_fetchNewsItems.zip', WB_PATH . '/temp/unzip/');
            rm_full_dir(WB_PATH.'/temp/unzip');
            $module_directory = $orig_module_dir;
        } catch ( \Exception $e ) {}
    } else {
        CAT_Helper_Droplet::installDroplet(WB_PATH.'/modules/news_img/droplets/droplet_fetchNewsItems.zip');
    }

florian

florian · 15.10.2024 06:54:26

Okay, danke schon mal, das löst das Droplet-Problem.
Ich bin ungern Überbringer schlechter Nachrichten, aber jetzt muss ich leider berichten, dass

bei einem Update die Versionsnummer (ersichtlich unter Erweiterungen > Module > Details zum Modul) nicht erhöht wird
bei einer Neuinstallation (nach vorherigem Deinstallieren des Moduls) dieses nicht in der Art-Auswahl für neue seiten/Abschnitte erscheint

Das ist zwar behebbar durch das Ausführen von Erweiterungen > erweitert > Module neu laden, aber genau das sollte ja eigentlich vermieden werden... mysteriös.

chriz · 15.10.2024 07:58:30

Ich habe nun die eigentliche Ursache in admin/modules/install.php gefunden.

Durch meinen Lösungsvorschlag im PR #558 wurde das Verzeichnis $temp_unzip sowohl in dem install.php, als auch im Modul-eigenen install.php verwendet und zwar leider überschneidend.
Das hat zu

möglichen Fehlern in Zweiterem (hier die Droplets, https://github.com/WBCE/WBCE_CMS/issues/560)
und zu einem sicheren Fehler in Ersterem (kein Eintrag in der DB), falls $temp_unzip durch das Modul-eigene install.php gelöscht wird

geführt.

Hier die Korrektur, die ich in den PR 558 gepushed haben wollte:
[gelöscht, siehe nächsten Beitrag]

Unabhängig davon macht es aber IMHO Sinn, an allen Stellen, wo ein Temp-Dir verwendet wird, dieses vor Gebrauch lokal zu bereinigen und sich nicht auf ein leeres Verzeichnis zu verlassen. Oder noch besser: Ein jeweils individuelles lokales Temp-Dir zu verwenden.

PS: Deinen Beitrag #19 habe ich erst gerade gesehen. Ich hoffe, mit meiner Korrektur aus #20 ist das nun auch behoben...

Last edited by chriz (15.10.2024 08:48:36)

chriz · 15.10.2024 08:05:50

chriz wrote:

Hier die Korrektur, die ich in den PR 558 gepushed habe:

Nein, habe ich wohl nicht. Mit Git/Github habe ich so meine Schwierigkeiten... sad

Vermutlich muß ich einen neuen PR erstellen. Ich forsche noch...

angel

Hier ist der neue Pull-Request: https://github.com/WBCE/WBCE_CMS/pull/562

Last edited by chriz (15.10.2024 08:21:15)

florian

florian · 15.10.2024 11:19:53

Danke für die schnelle Reaktion.
Die Probleme treten jetzt nicht mehr auf.
Ich habe den PR gemerged.

chriz · 15.10.2024 11:42:24

Ich habe admin/templates/install.php noch nachgezogen, so dass auch dort bei den Fehlerausgängen das temp_unzip gelöscht wird.

https://github.com/WBCE/WBCE_CMS/pull/563

Ist allerdings noch ungetestet (Ich habe gerade keine Idee, wie ich Fehler provozieren soll. devil )

florian · 15.10.2024 13:10:00

Danke, hab's gemerged

WBCE CMS Forum

#1 17.05.2024 06:30:31

Fehler beim Template-Installation (bzw. Upgrade): Kein Update der DB

#2 17.05.2024 08:45:04

Re: Fehler beim Template-Installation (bzw. Upgrade): Kein Update der DB

#3 17.05.2024 20:46:17

Re: Fehler beim Template-Installation (bzw. Upgrade): Kein Update der DB

#4 17.05.2024 21:26:00

Re: Fehler beim Template-Installation (bzw. Upgrade): Kein Update der DB

#5 18.05.2024 08:29:15

Re: Fehler beim Template-Installation (bzw. Upgrade): Kein Update der DB

#6 18.05.2024 09:08:14

Re: Fehler beim Template-Installation (bzw. Upgrade): Kein Update der DB

#7 20.05.2024 18:40:09

Re: Fehler beim Template-Installation (bzw. Upgrade): Kein Update der DB

#8 20.05.2024 18:45:31

Re: Fehler beim Template-Installation (bzw. Upgrade): Kein Update der DB

#9 20.05.2024 19:02:04

Re: Fehler beim Template-Installation (bzw. Upgrade): Kein Update der DB

#10 22.05.2024 06:55:15

Re: Fehler beim Template-Installation (bzw. Upgrade): Kein Update der DB

#11 22.05.2024 07:37:47

Re: Fehler beim Template-Installation (bzw. Upgrade): Kein Update der DB

#12 22.05.2024 09:10:59

Re: Fehler beim Template-Installation (bzw. Upgrade): Kein Update der DB

#13 22.05.2024 09:16:48

Re: Fehler beim Template-Installation (bzw. Upgrade): Kein Update der DB

#14 22.05.2024 09:18:20

Re: Fehler beim Template-Installation (bzw. Upgrade): Kein Update der DB

#15 24.05.2024 10:05:25

Re: Fehler beim Template-Installation (bzw. Upgrade): Kein Update der DB

#16 24.05.2024 18:49:55

Re: Fehler beim Template-Installation (bzw. Upgrade): Kein Update der DB

#17 10.10.2024 06:13:02

Re: Fehler beim Template-Installation (bzw. Upgrade): Kein Update der DB

#18 14.10.2024 19:42:01

Re: Fehler beim Template-Installation (bzw. Upgrade): Kein Update der DB

#19 15.10.2024 06:54:26

Re: Fehler beim Template-Installation (bzw. Upgrade): Kein Update der DB

#20 15.10.2024 07:58:30

Re: Fehler beim Template-Installation (bzw. Upgrade): Kein Update der DB

#21 15.10.2024 08:05:50

Re: Fehler beim Template-Installation (bzw. Upgrade): Kein Update der DB

#22 15.10.2024 11:19:53

Re: Fehler beim Template-Installation (bzw. Upgrade): Kein Update der DB

#23 15.10.2024 11:42:24

Re: Fehler beim Template-Installation (bzw. Upgrade): Kein Update der DB

#24 15.10.2024 13:10:00

Re: Fehler beim Template-Installation (bzw. Upgrade): Kein Update der DB

Board footer