Beiträge von SniperSister

Die automatische Injection machst du auf JS-Basis, was den Zweck des Plugins ein gutes Stück weit ad absurdum führt: Bots führen in der Regel aus performancegründen kein JS aus, somit wird kein Feld injected und erst recht auch nicht befüllt - dein Honeypot greift also nie.

Bei Joomla ist *immer* nur ein Update der letzten Patch-Version eines Branches (also der 4.4.13) auf die nachfolgende Version (also 5.2.6) möglich. Das ist nicht neu.

Was das Update von 4.4.13 auf 5.2.6 angeht: das war in der Tat ein Dreher im Update-Server, ist jetzt korrigiert.

Falls du den Eintrag im Admin-Menü meinst: der wird nicht über den Serviceprovider generiert, sondern über das XML Manifest.

Ich kann mich nur wiederholen: dir fehlen die Grundlagen, beschäftige dich bitte damit, alles andere hier ist sonst wildes rumraten.

Du hast den Hinweis aus #21 ignoriert; du brauchst EINE Namespace-Angabe.

Sieht grundsätzlich ok aus, prüf nochmal die Angaben zum namespace in der xml Datei (muss zu den Namespaces in den Dateien und dem ServiceProvider passen) und lösch ggf. mal die autoload_psr4.php unter administrator/cache

Dein DisplayController wird nicht gefunden. Prüf dort den Klassennamen und den angegebenen Namespace. Auch hier wird es mutmaßlich ein Problem mit dem Autoloading sein.

Grundsätzlich: es drängt sich der Eindruck auf, dass du ein paar Wissenslücken bei verschiedenen fundamentalen Themen hast. Das betrifft insbesondere Namespaces (https://www.php.net/manual/en/language.namespaces.php), Autoloading (https://manual.joomla.org/docs/general-c…sses-with-psr4/) und Dependency Injection (https://manual.joomla.org/docs/general-c…ency-injection/). Schau unbedingt nochmal intensiv in die vorhandene Dokumentation und verfügbare Beispielerweiterungen um die Grundkonzepte zu verinnerlichen, ansonsten ist es stochern im Nebel und das ist nicht so recht zielführend.

Beispiel Serviceprovider:

<?php
defined('_JEXEC') or die;

use Joomla\CMS\Extension\ComponentInterface;
use Joomla\CMS\Extension\MVCComponent;
use Joomla\CMS\Extension\Service\Provider\ComponentDispatcherFactory;
use Joomla\CMS\Extension\Service\Provider\MVCFactory;
use Joomla\CMS\MVC\Factory\MVCFactoryInterface;
use Joomla\CMS\Dispatcher\ComponentDispatcherFactoryInterface;
use Joomla\DI\Container;
use Joomla\DI\ServiceProviderInterface;

return new class implements ServiceProviderInterface {
    public function register(Container $container): void 
    {
        $container->registerServiceProvider(new MVCFactory('\\PasswordGenerator\\Component\\Passwordgenerator'));
        $container->registerServiceProvider(new ComponentDispatcherFactory('\\PasswordGenerator\\Component\\Passwordgenerator'));
        $container->set(
            ComponentInterface::class,
            function (Container $container) {
                $component = new MVCComponent($container->get(ComponentDispatcherFactoryInterface::class));
                $component->setMVCFactory($container->get(MVCFactoryInterface::class));
                return $component;
            }
        );
    }
};

Die wird (auch schon in dem Ursprungsbeispiel) nicht benötigt, weil die entsprechende Klasse im Code ja nicht verwendet wird

Dein Provider hat in der Struktur doch jetzt aber nichts mit der Beispieldatei zutun? DIe Beispieldatei returned direkt eine Objektinstanz, deine Datei hingegen definiert eine Klasse. Auch der Inhalt der Register Methode ist abweichend. Und der Namespace des Provider Interfaces ist falsch.

Das Problem ist nicht der fehlende Dispatcher (denn die provider.php verweist auf den Default Dispatcher) sondern die unvollständige provider.php, die keine Komponente registriert und die keinen korrekten Namespace angibt. Vergleich siehe hier:

manual-examples/component-exampleform/com_exampleform/administrator/components/com_exampleform/services/provider.php at main · joomla/manual-examples

Examples for manual tutorials. Contribute to joomla/manual-examples development by creating an account on GitHub.

github.com

jumbo125 Joomla hat einen eigenen Plugin-Typ für Captchas, damit kann man das Rendering der Felder sowie die Prüfung abstrakt im Plugin als Methoden bereitstellen und hat damit eine einheitliche Schnittstelle, auf die Erweiterungsentwickler zurückgreifen können. Simples Beispiel: https://github.com/pe7er/hCaptcha…a4/hcaptcha.php

Deine Copy&Paste Variante ist "unüblich" - und im Kontext von Core und Dritterweiterungen auch schlicht unpraktikabel, weil dein Custom Code bei jedem Update überschrieben wird.

Das sieht unnötig komplex aus. Orientier dich an den Namespaces der Core Komponenten. In der XML wird dort jeweils EIN "Basis-Namespace" definiert: https://github.com/joomla/joomla-…wrapper.xml#L13

Bei den Backend Klassen wird an diesen Basis-Namespace ein \Administrator\ angehangen und dann gehts relativ zum src Verzeichnis weiter: https://github.com/joomla/joomla-…mponent.php#L11

Im Frontend ist es das gleiche Prinzip nur mit Site: https://github.com/joomla/joomla-…troller.php#L11

Die Namespace-Deklaration in der XML ist falsch, sie passt nicht zu den verwendenten Namespaces in der PHP Dateien.

Moderationshinweis: Ich habe 3 Posts entfernt, die keinen konkreten Mehrwert zur Fragestellung beigesteuert haben.

Zum konkreten Problem: hast du das Problem mal bei deinem Hoster geschildert? Aus dem Tor Netzwerk kommt überproportional viel Schadtraffic, daher werden IPs von Exit Nodes gerne mal gesperrt.

Debug Modus aktivieren um die Datei zu finden, die den Fehler verursacht, dann Code dieser Datei hier posten. Mutmaßlich wird das use Statement für den BaseController fehlen.

Nein, es gibt derzeit keine Planungen dafür, der Umstieg von J4 auf J5 ist "zu leicht" und der Bedarf daher absehbar klein.

Top, danke

Erlaubt mir die naive Frage: hat jemand von euch den Bug auch gemeldet? In der Echokammer des deutschsprachigen Forums bringt eine slche Meldung ja schließlich nichts.

Zitat von O.D.

Meinen Respekt, richtiges Fachwissen ist halt doch super!

Fachwissen setzt hier beim Lesen des Codes von T4 an, das ist in der Tat etwas für Fortgeschrittene.

Der Teil vorher, also das Eingrenzen auf das Plugin, ist hingegen recht einfach: auf Grundlage der "finalen" Fehlermeldung ist es nicht möglich, das Problem auch nur ansatzweise einzugrenzen, also muss man sich hier zusätzliche Infos besorgen und der Debug Mode ist da immer die erste Anlaufstelle. Alles andere ("check mal XYZ", "kontrollier mal ABC") ist nichts anderes als rumraten und somit wenig zielführend

Der Code-Block sieht für mich aus als hätte jemand bei JoomlArt da vor dem letzten Update dran gearbeitet, halbfertigen Code hinterlassen und dann ist der Kram so veröffentlicht worden. Denn dort ist auskommentierter "richtiger" Code, der genau diese Check (ist das gespeicherte Template ein T4 Template?!) gemacht hätte.