Ist ein bekanntes Problem der aktuellen Version des scripts. iOS Geräte wollen nicht die gesamte Datei herunterladen, sondern nur ein paar erste Frames. Das Script unterstützt aber nur gesamtdownloads und das mögen die Browser nicht.
Lösung: script anpassen. Dafür fehlt mir aber bislang die Zeit.
Qfe was genau ist denn das Problem dass du lösen willst? Ein neuer Beitrag mit den wesentlichen Infos in leichter Sprache anzulegen ist doch trivial? Wozu brauchts da ein Plugin?
Bedeutet dass nun, dass ich einen Link und eine Empfehlung hätte angeben können aber nicht der Entwickler?
Richtig. Wir wollen vermeiden, dass das Forum zu einer Self-Promotion Plattform wird, bei der es nicht mehr um die beste Lösung für ein Problem geht, sondern der persönliche Vorteil im Vordergrund steht.
Die interessante Frage ist eigentlich, woher der Aufruf mit einem null als Wert kommt, der vorschlagene Fix kümmert sich ja "nur" um die Symptome, nicht um das Grundproblem.
Was den Mechanismus angeht ist es positiv 
Verbesserungspotenzial gibts sicherlich bei der Codequalität und der Anbindung ans Joomla-Framework, aber das ist ne Frage der Übung
Ah I see, das heißt du erwartest die Existenz der Felder, sie müssen aber leer sein. Na dann feuer frei.
In der ajax.php ist recht gut nachvollziehbar, was passiert:
https://github.com/joomla/joomla-cms/blob/5.2-dev/components/com_ajax/ajax.php
Beachte dabei insbesondere den Part, bei dem im Modulnamen bei _ oder - gesplitted wird - warum auch immer das der Fall ist. Das könnte, mit Blick auf deinen Modulnamen, hier unerwartete Ergebnisse produzieren. Zudem muss der ServiceProvider des Moduls das HelperFactoryAwareInterface implementieren:
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:
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.