Wieder aktuell: Module abschalten ohne Backend

Hallo zusammen!
Meine Entwicklungsumgebung steht seit heute Nachmittag,
Ich hatte lediglich ein paar Häkchen in den Einstellungen eines Moduls gesetzt und dann war Feierabend.
Es wird nur noch eine weiße Seite angezeigt.
Dank Exception- und PHP-Log habe ich eine recht genaue Vermutung, welche Module betroffen sind und habe die Entwickler um Hilfe gebeten.

Den ganzen Abend habe ich jetzt damit zugebracht, herauszufinden, wie man alle Module im Shop deaktiviert.
Lesestoff gibt es dazu ja genug.
Aber der Kram ist teils aus 2011/2012, also vermutlich nicht mehr ganz zutreffend oder funktioniert aus anderen Gründen nicht.

Einen interessanten Vorschlag habe ich in einem Beitrag gefunden. Die Möglichkeit, alle Module per Eintrag in die config.inc.php abschalten zu können wurde diskutiert und für gut befunden. Leider ist das Thema danach nicht mehr aufgetaucht.

Den Vorschlag unter “http://www.ackis-oxid.de/2013/module-kann-nicht-aktiviert-werden-in-oxid-eshop-beheben-modulkonfiguration-zurcksetzen/” habe ich mich nicht getraut, da auch schon aus 2013. Außerdem hätte ich damit vermutlich jede Chance der Modulentwickler zunichte gemacht, den Fehler zu finden.

Der beste Vorschlag schien mir noch dieser hier, obwohl auch schon älter.
http://oxidforge.org/de/moduleintraege-via-frontend-bearbeiten-reparieren-deaktivieren.html
Aber wenn ich das Skript aus der Box raus kopiere, dann habe ich einen Haufen Shrott-Zeichen dabei.
Bsp.: “<?php” und dergleichen mehr.
Ich habe denn trotzdem versucht, ein optisch ok aussehendes Skript daraus zu bauen. Aber irgendwas hat wohl auch daran nicht gestimmt. Jedenfalls konnte ich das Skript nicht zum Laufen bringen.
Vielleicht lag das ja auch daran, dass ich, ebenso wie viele andere Shopbetreiber auch, den Admin-User gelöscht habe, wegen dem Security-Bug neulich. In der Anleitung steht nicht, ob das mit einem “normalen” Admin auch klappt.

Langer Rede kurzer Sinn:
Ist das Thema eigentlich jemals abschließend und zufriedenstellend gelöst worden?

Wenn der Shop wegen eines Moduls steht, sollte es doch eine einfache und nicht-destruktive Möglichkeit geben, per Datenbank oder config.inc.php alle Module auf deaktiviert zu setzen und dann das Backend ohne Module neu zu starten.

Vielleicht bin ich ja auch nur betriebsblind und habe die passende Anleitung nicht gefunden?

Es wäre ganz Klasse, wenn mir mal jemand erklären könnte, wie der “offiziell empfohlene” Weg in solchen Fällen denn nun funktioniert.

Vielen Dank im Voraus!

Beste Grüße.
Bianca

Ich benutze dazu das emergnecy pack http://www.foxido.de/tools-2.

@Paperless:
wenn Du weist, welches Modul den Fehler erzeugt, einfach das entsprechende Modulverzeichnis auf dem Server löschen

@adamweber: sieht interessant aus. Leider kein Preis dabei.
Was genau tut das Modul? Werden da nur die Module deaktiviert oder löscht es einfach per SQL die ganzen Moduleinträge?
Ich suche ja eigentlich nach einer nicht-destruktiven Lösung - falls es die gibt… :confused:

@patchwork.de:
Interessante Idee. Da hatte ich auch für einen Moment drüber nachgedacht.
Aber was bewirkt sie?
Wenn ich den Modulordner lösche, stehen die Config-Einträge der Module noch immer in der db. Ob es dadurch viel besser wird? Immerhin mal einen Versuch Wert, wenn es anders gar nicht mehr weiter geht.

Ich dachte, dass vielleicht nach dem Statement von Marco Steinhaeuser, vom 17.09.2013, 12:13, schon was in die Entwicklung eingeflossen wäre und ich es nur nicht gefunden habe.
http://forum.oxid-esales.com/showthread.php?t=12795&highlight=config.inc.php+modul+deaktivieren&page=2

Beste Grüße.
Bianca

das ist gratis, löscht einfach alle einträhe und bietet die möglichkeit, das passwort zurückzusetzen. hat mir schon ein paar mal zeit gespart, denn ich muss die befehle sonst immer suchen.

Alle Einträge zu löschen ist aber schon recht destruktiv. Es gab auf github “Oxid module internals” oder sowas ähnliches, ich muss mal danach suchen

Im Modul aus dem OXID Kochbuch zum Cache löschen, gibt es auch eine “Entwickler version”


/**
     * Remove all module entries from the oxConfig table
     * Will only work if the developer mode is enabled.
     */
    protected function removeAllModuleEntriesFromDb()
    {
        if (false != oxRegistry::getConfig()->getRequestParameter('devmode')) {
            oxDb::getDb()->execute('DELETE FROM `oxconfig` WHERE `OXVARNAME` LIKE \'%aMod%\';');
            oxDb::getDb()->execute('DELETE FROM `oxconfig` WHERE `OXVARNAME` LIKE \'%aDisabledModules%\';');
        }
    }

Die Datenbankbefehle kann man ja auch ohne Php ausführen.

Dann sind erst mal alle Module deaktiviert und man kommt wieder ins Backend.

[QUOTE=vanilla thunder;182714]Es gab auf github “Oxid module internals” [/QUOTE]

Meinst Du das hier?
https://github.com/acirtautas/oxid-module-internals/blob/master/metadata.php

leider nein, habe mich geirrt, was den Namen angeht.
Es gab irgendwo eine PHP Datei, die man in den Hauptverzeichnis hochladen kann und komplett am Shop vorbei alle Moduleinträge in der Datenbank abrufen und ändern. Genau für solche Fälle, wenn ein Modul bockt und das Backend nicht mehr startet, man aber das problem lösen will, ohne gleich alle Module komplett zu löschen oder zu deaktivieren.

Dann meinst Du vermutlich dieses:
http://oxidforge.org/de/moduleintraege-via-frontend-bearbeiten-reparieren-deaktivieren.html

Ist aus 2011. Noch gültig???

Ich habe versucht, das zum Laufen zu bekommen. Aber wenn ich den Code aus dem Browserfenster in meinen Editor ([I]EDIT Plus 3[/I] - der kann sonst perfekt PHP und smarty ) kopiere, komt da immer Schrott mit.
Habe versucht, die Codierung im Browser umzustellen - wurde nur schlimmer.
In anderem Editor (Edit ++) gleiches Bild.

Das sieht dann praktisch so aus:


<?php

Und weiter unten:


    'delimiter'   => PHP_EOL,
    'separator'   => '=>',
    'str_pad'     => 30,
    'session_key' => 'hz_modules',//basename(__FILE__)
    'redirect'    => false,
    'lang'        => ( $lang = oxLang::getInstance()->getLanguageAbbr() ) ? $lang : 'de',
    'history'     => null,
    'text'        => array(
        'headline' => array(
            'de' => 'Moduleinträge bearbeiten.',
            'en' => 'Edit Module-Entries'

die “&gt” sollen vermutlich TABS sein?
Na jedenfalls habe ich versucht, das Skript von Hand so aufzuräumen, dass was Lauffähiges daraus wird. Habe es aber nicht zum Laufen bekommen.

Bei Zeilen, wie


    $shopConfig->saveShopConfVar( 'aarr', 'aModules', $aModules, $sShopId, $sModule = '' );
    $_aTmp = array();
    foreach( $aModules as $class => $module ) {
        $_aTmp[] = str_pad($class,$scriptConfig->str_pad,' ') . str_pad( $scriptConfig->separator, ( strlen( $scriptConfig->separator ) + 2 ) , ' ', STR_PAD_BOTH ) . $module;

Blicke ich dann leider nicht mehr durch, was dazu gehört und was nicht. :confused:

Beste Grüße.
Bianca

das sieht tatsächlich stark danach aus.
ich habe mal auf die Schnelle den Code aktualisiert, versuch das mal:

kopiere aber vorsichtshalber das, was in dem Feld erscheint, in einen Texteditor (als Backup quasi)


<?php
/**
 * $Id$
 *
 * Datenbankeintrag der Module bearbeiten.
 * Falls das Backend mal wieder zerschossen ist :-)
 *
 * # Für die Benutzung muss man im Frontend als Admin-Benutzer (oxdefaultadmin)
 *   angemeldet sein.
 * # Datei ins Root-Verzeichnis
 * # http://meinedomäne.tld/diesedatei.php aufrufen.
 *
 * Zum übernehmen eines Verlauf-Eintrages wird .textContent verwendet. Ist in
 * dem Fall egal, da kein HTML drin steht und Firefox innerText nicht kennt.
 * innerText wäre besser, da keine HTML mitgenommen wird.
 * http://www.google.de/search?q=innerText+undefined
 *
 * Kann gut sein, das ältere Browser textContent auch nicht richtig umsetzen.
 * Muß man dann halt ne Funktion basteln.
 * <code>
 *     var hasInnerText = (Element.innerText !== undefined) ? true : false;
 *     if(!hasInnerText){
 *         Element.textContent = 'bla';
 *     } else{
 *         Element.innerText = 'bla';
 *     }
 * </code>
 *
 * @TODO
 *     # Ausbauen um alle Konfigurationsschalter zu bearbeiten.
 *     # Verlauf in Datei speichern
 *
 * @version 0.1.0 | 20110427
 * @author Stefan Mayer | [email protected]
 */

ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);

//define('OX_BASE_PATH',dirname(__FILE__).DIRECTORY_SEPARATOR);

//require_once dirname(__FILE__).DIRECTORY_SEPARATOR . 'core/oxfunctions.php';

require_once dirname(__FILE__) . "/bootstrap.php";

$config = oxRegistry::getConfig();
header('content-type:text/html; charset=utf-8');

/**
 * Module speichern
 */
if( isset( $_POST['speichern'] ) )
{
    $_string  = trim( $_POST['module'] );
    $_lines   = explode( PHP_EOL, $_string );
    $aModules = array();
    $sModules = '';
    foreach( $_lines as $_line ) {
        if( strpos($_line, '=>' ) === false ) {
            continue;
        }
        $_m = explode('=>', $_line);
        if( !isset( $_m[0] ) || !isset( $_m[1] ) ) {
            continue;
        }
        $class    = trim( $_m[0] );
        $module   = trim( $_m[1] );
        if( !empty( $class ) && !empty($module) ) {
            $aModules[$class] = $module;
        }
    }
    //var_dump($aModules);
    $config->saveShopConfVar( 'aarr', 'aModules', $aModules );
    header('location:http://' . $_SERVER['HTTP_HOST'] . $_SERVER['PHP_SELF'] );
}

?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" dir="ltr" lang="de" xml:lang="en">
<head>
    <title>OXID eSales - Module bearbeiten</title>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <meta http-equiv="Content-Language" content="de" />
    <meta http-equiv="Content-Script-Type" content="text/javascript" />
    <meta http-equiv="Content-Style-Type" content="text/css" />
    <meta name="language" content="de" />
    <meta name="author" content="Stefan Mayer[[email protected]]" />
    <style type="text/css">
        body{ font-family: Arial, Helvetica, sans-serif; font-size: .8em }
        textarea, #save{ width:100%; }

        textarea,dd{ white-space: pre; font-family: 'courier new'; font-size: 12px; }
        dd{ padding: 10px 0; margin-bottom:10px; border-bottom: 1px dotted #333}
        dt a{ color: inherit; padding: 2px 5px; border-radius:4px; }
        dt a.setzen:hover{ background-color: green; color: #fff; }
        dt a.loeschen:hover{ background-color: red; color: #fff; }
    </style>
</head>
<body id="start">
<h1>Module bearbeiten</h1>
<form method="post">
    <fieldset><legend>Aktuelle Moduleinträge:</legend>
        <textarea id="hotze-module" name="module" rows="20" cols="150">
<?php foreach($config->getConfigParam( 'aModules' ) as $class => $modules ) {
    echo "$class => $modules".PHP_EOL;
} ?>
        </textarea>
        <br />
        <input id="save" type="submit" name="speichern" value="Module speichern" />
    </fieldset>
</form>

<h2>Hinweise:</h2>
<ul>
    <li>Man kann Einträge auch auskommentieren in dem man die Klasse "unkenntlich" macht. z.B.: "//oxorder => ... "</li>
    <li>Achtung: Windowssystem akzeptieren "Datei.php = datei.php", Unix nicht. Schreibweise beachten.</li>
</ul>
</body>
</html>

Danke für Deine Hilfe!
Jetzt geht was!

Nach den Warnungen kommt eine Liste von Moduleinträgen.

Ich bin mir jetzt nur nicht sicher, was passieren würde, wenn ich auf SPEICHERN gehe, mit diesen Warnungen im Fenster.

<b>Warning</b>:  Cannot modify header information - headers already sent by (output started at /<Pfad aus Sicherheitsgründen gelöscht/ModReset.php:106) in <b>Pfad aus Sicherheitsgründen gelöscht/core/oxutilsserver.php</b> on line <b>79</b><br />
<br />
<b>Warning</b>:  Cannot modify header information - headers already sent by (output started at /Pfad aus Sicherheitsgründen gelöscht/ModReset.php:106) in <b>/Pfad aus Sicherheitsgründen gelöscht/core/oxutilsserver.php</b> on line <b>79</b><br />

Wenn ich das richtig verstehe, könnte ich hier jetzt also Zeilen löschen oder auskommentieren (//) und dann mittels Speichern diese Module quasi deaktivieren?

Ich habe anscheinend noch nicht verstanden, wie ein Modul in der dB eingetragen ist und wie der Aufruf funktioniert… :confused:

Aber für den Anfang kann ich damit jetzt mal testen und irgendwann kapiere es sicher auch ich. :smiley:

Beste Grüße.
Bianca

Der Muster ist so
klasse von Oxid, die mit Modulen erweitert wird => modul1/Erweiterung & modul2/Erweiterung

Wenn du weißt, dass Modul 2 nicht funktioniert, kannst du all seine Einträge entfernen und dann speichern.
Ob Auskommentieren was bringt, weiß ich nicht. Du kannst aber genau so gut einfach eine Zeile wegnehmen. Und tmp leeren nicht vergessen!

[QUOTE=adamweber;182713]das ist gratis, löscht einfach alle einträhe und bietet die möglichkeit, das passwort zurückzusetzen. hat mir schon ein paar mal zeit gespart, denn ich muss die befehle sonst immer suchen.[/QUOTE]

Schau mal genau hin. Nicht nur alle, sondern auch einzelne Module sind möglich. Dieser Teil ist aber nicht viel anders, als die genannte Lösung.

[QUOTE=Paperless;182700]Den Vorschlag unter “http://www.ackis-oxid.de/2013/module-kann-nicht-aktiviert-werden-in-oxid-eshop-beheben-modulkonfiguration-zurcksetzen/” habe ich mich nicht getraut, da auch schon aus 2013. Außerdem hätte ich damit vermutlich jede Chance der Modulentwickler zunichte gemacht, den Fehler zu finden.[/QUOTE]
Hallo,

die Methode gilt hat weiterhin Gültigkeit, es würde also auch in aktuellen Shopversionen genau so funktionieren.
Die Felder beinhalten Moduleinstellungen und die Angaben aus der Metadata-Datei. Alle diese Angaben können neu gesetzt werden. Ein Datenverlust wäre also nicht so schlimm, sofern man seine Einstellungen kennt und diese wieder hinterlegen kann.

[QUOTE=Paperless;182722]Ist aus 2011. Noch gültig???
Ich habe versucht, das zum Laufen zu bekommen.[/QUOTE]
Hallo zusammen,

ich habe mal das Script auf der OXIDforge aufgeräumt. Es sollte nun also lauffähig sein. Ob es auch funktioniert, müsste man mal testen. Auf der OXIDforge gibt es übrigens einen Feedback-Button, über den man uns auch fehlerhafte Seiten melden kann :wink:

Gruß
Jürgen

[QUOTE=foxido.de;182737]Schau mal genau hin. Nicht nur alle, sondern auch einzelne Module sind möglich. Dieser Teil ist aber nicht viel anders, als die genannte Lösung.[/QUOTE]

Tschuldigung habe ich übersehen. Habe immer nur die eine Datei mit den Befhelen aufgerufen.

Ich habe die Beschreibung angepasst, damit das nicht mehr passiert

Hallo, das Script in dem Fenster hinter dem Link läuft bei mir überhaupt nicht (noch 4.7.). Da sind scheinbar auch Kopierfehler drin.
Gruß
Der Predator

[QUOTE=juergen.busch;182757]Hallo zusammen,

ich habe mal das Script auf der OXIDforge aufgeräumt. Es sollte nun also lauffähig sein. Ob es auch funktioniert, müsste man mal testen. Auf der OXIDforge gibt es übrigens einen Feedback-Button, über den man uns auch fehlerhafte Seiten melden kann :wink:

Gruß
Jürgen[/QUOTE]

Hallo Predator,

da sollte kein Kopierfehler drin sein. Im Errorlog bekomme ich beim Ausführen des Scripts folgenden Fehler: PHP Fatal error: Call to undefined method oxConfig::getInstance() in /var/www/html/ce_4101/check.php on line 23.

Da muss vermutlich etwas am Script repariert werden. Input willkommen!

Gruß
Jürgen