Class "JPlugin" not found - Deaktivierung von "Behaviour - Backward Compatibility" - Plugin aktivieren ohne Zugriff auf Datenbank!

Zitat von WM-Loose

... ohne Zugriff auf die Datenbank wieder zu aktivieren?

Das Backend funktioniert ja nicht mehr.

Zitat von WM-Loose

Wäre es nicht sinnvoll, dass man für Joomla 5 und Joomla 6 eine einfache Möglichkeit schafft, das Plugin ohne Zugriff auf die Datenbank wieder zu aktivieren?

Übersieht man nur eine Erweiterung oder ein Plugin und deaktiviert das Plugin Behaviour - Backward Compatibility kann man ohne Zugriff auf die Datenbank das Plugin nicht mehr aktivieren. Das ist einfach unglücklich, da viele User nicht so geübt sind im Umgang mit Datenbanken.

Ist es irgenwie machbar?

Gab/gibt dazu schon mal einen Issue: https://github.com/joomla/joomla-cms/issues/46392

Ein PR wurde probiert, aber geschlossen: https://github.com/joomla/joomla-cms/pull/46393

Liebe Grüße
Christine

Zitat von WM-Loose

...ich wünschte mir deshalb, dass es eine Chance über einen Link geben könnte...

Habe jetzt mal in Anlehnung an die readmedia.php von SniperSister eine kleine php-Datei geschrieben welche per aufruf das Backward Compatibility" - Plugin aktiviert.

Die Datei enthält den nachfolgenden Code im Spoiler:

<?php

/**
 * @copyright  Copyright (C) 2026 Sieger66
 * @package    S66Compat
 * @version    1.0.0
 * @license    GNU GPLv3 <http://www.gnu.org/licenses/gpl.html>
 * Datei speichern in  /administrator/templates/atum/compat.php
 */


declare(strict_types=1);

use Joomla\CMS\Application\SiteApplication;
use Joomla\CMS\Application\AdministratorApplication;
use Joomla\CMS\Factory;
use Joomla\CMS\Session\Session;
use Joomla\CMS\Uri\Uri;
use Joomla\CMS\Response\JsonResponse;
use Joomla\Session\Session as SessionAlias;
use Joomla\Session\SessionInterface;

/* Initialize Joomla framework */
const _JEXEC = 1;

// Load system defines
// aus /administrator/templates/atum/compat.php
// drei Dateordnerebenen hoch um JPATH_BASE zu erreichen
// per dirname(__DIR__ , 3)

if (!defined('JPATH_BASE')) {
define('JPATH_BASE', dirname(__DIR__ , 3));
}

require_once JPATH_BASE . '/includes/defines.php';
require_once JPATH_BASE . '/includes/framework.php';

$container = Factory::getContainer();

$container->alias('session.web', 'session.web.site')
          ->alias('session', 'session.web.site')
          ->alias('JSession', 'session.web.site')
          ->alias(Session::class, 'session.web.site')
          ->alias(SessionAlias::class, 'session.web.site')
          ->alias(SessionInterface::class, 'session.web.site');

 $app = $container->get(AdministratorApplication::class);
// $app = $container->get(SiteApplication::class);

// Load the extension Namespaces
JLoader::register('JNamespacePsr4Map', JPATH_LIBRARIES . '/namespacemap.php');
$extensionPsr4Loader = new JNamespacePsr4Map();
$extensionPsr4Loader->load();

// Set the application as global app
Factory::$application = $app;

// Actual permission check starts here
if (!Factory::$application->getSession()->get('user')->id) {
    header('HTTP/1.0 403 access denied');
echo '<h1>Zuerst anmelden um das Kompatibilit&auml;ts-Plugin compat wieder zu aktivieren!</h1>';
    exit('Access denied');
}

$db = Factory::getDbo();

$query = $db->getQuery(true);

$query->update('#__extensions');

$query->set($db->qn('enabled') . ' = 1');

$query->where($db->qn('folder') . ' = ' . $db->q('behaviour'));

$query->where($db->qn('type') . ' = ' . $db->q('plugin'));

$query->where($db->qn('element') . ' = ' . $db->q('compat'));

$query->where($db->qn('client_id') . ' = 0' );

$db->setQuery($query);
$db->execute();


echo '<h1>Das Kompatibilit&auml;ts-Plugin compat ist nun wieder aktiviert</h1>';

und habe ich als Dateianhang als txt-Datei beigefügt.

Die Datei muß entsprechend umbenannt und gespeichert und aufgerufen werden z.B. in

/administrator/templates/atum/compat.php

Wie auch im obigen Beispieldateipfad ersichtlich funktioniert sie unverändert nur dann wenn sie genau 3 Dateiordnerebenen über dem Joomla-root Dateiordner abgelgt wird.

Übrigens muß man im Joomla-Backend angemeldet sein sonst wird durch den Aufruf der Datei das Plugin nicht aktiviert. Es sei denn man ändert den Code vom Script entsprechend ab.

Diese zusätzliche Sicherheitsvorkehrung wäre zwar nicht unbedingt erforderlich wenn man das Backend ohnehin per .htaccess geschützt hat. Habe ich aber im Script gelassen für alle Fälle.

Der Dateiname vor dem .php kann übrigens auch beliebig geändert werden z.B. in

/administrator/templates/atum/mycompatsecret0815.php

Das selbe Script könnte man übrigens auch sehr leicht für das compat6-Plugin umschreiben und verwenden...

Ich "klinke" mich einmal mit einem "Erfahrungsbericht" ein von einer meiner Seiten:

Plugin compat deaktiviert > Fehlermeldung ("Class ...") > Backup eingespielt > Errorreporting auf Max und neuer Versuch
wieder die bekannte Meldung, aber keine weitere Fehlermeldung > Rückkehr zum Dashboard und dort konnte ich das Update auf 6.1.0 starten.
Das Update war erfolgreich, Front- und Backend funktionieren fehlerfrei.

Dann habe ich das Plugin compat6 deaktiviert mit dem Ergebnis Fehlermeldung ("Class ...")

Dank dem Script von Sieger66 war das Plugin schnell wieder aktiviert.

Wie komme ich jetzt auf die Spur des "Übeltäters"?
Bei anderen Seiten hat der Wechsel auf J6 mit Deaktivierung des Plugins ohne Fehlermeldung geklappt.

Zitat von chr-hl

Wie komme ich jetzt auf die Spur des "Übeltäters"?

Debug an und Fehleranzeigen auf Maximum, den Call Stack sollte dann anzeigen welche Erweiterung das Problem verursacht

Zitat von drmenzelit

Debug an ...

Das Problem sitzt immer vor dem Bildschirm.
Wie konnte ich das übersehen, dass ich den Debug-Modus nicht eingeschaltet hatte,

Kaum macht man es richtig, schon funktioniert es.

"Übeltäter" gefunden und beseitigt (ein "uraltes" Plugin, was gar nicht mehr benötigt wird).

Hallo zusammen,

vielen Dank erstmal für eure Hilfe. Ich habe dasselbe Problem, aber ich checke es irgendwie nicht.

Danke an Sieger66 für das PHP-Script. Ich habe den Code genommen und als "compat.php" in /administrator/templates/atum/ gespeichert und hochgeladen. Auf dem Server ist die Datei verfügbar.

Wenn ich die Website dann jedoch über das Backend aufrufen möchte, passiert nichts und es erscheint noch immer die Fehlermeldung.

Versuche ich die Datei über URL aufzurufen, erhalte ich eine Fehlermeldung: "Zuerst anmelden um das Kompatibilitäts-Plugin compat wieder zu aktivieren!" und "Access denied"- Was habe ich doofkopp denn nun wieder falsch gemacht?

Sorry, bin wohl schon zu alt 🤪🫶

Nachtrag: ich sehe gerade, dass ich mich gar nicht im Backend anmelden kann. Die Fehlermeldung "0 Class..." erscheint schon beim Versuch, sich einzuloggen.... Und nu?

Bleibt mir wohl nur die Möglichkeit, das Backend einzuspielen, aber was kommt dann? Alles nochmal von vorne?

Nö,

man kann auch in der Datenbank direkt ändern

Christian

Hast du den Debug Modus eingeschaltet und Fehlerberichten auf Maximum gestellt? Das kann man per (S)FTP in der configuration.php machen. Sonst findest du nicht raus, welche Erweiterung Ärger macht.

Hallo chr-hl,

vielen Dank.

Ich hatte es in einem anderen Post schon geschildert, dass ich es leider nicht ändern kann.

Missverständnis bei Abwärtskompatibilität in 5.4 für Update auf 6.0

Oder gibt es noch eine andere Möglichkeit?

Hast Du wirklich keine Möglichkeit mit phpmyadmin an die DB zu kommen?

Doch, natürlich. Aber ich finde diesen Eintrag "plg_behaviour_compat" nicht.

Oder meinst du etwas anderes?

Hallo drmenzelit

ich komme leider gar nicht mehr ins Backend....