Oxid 6: Wie finde ich heraus, was Oxid für ein Problem mit den Klassen und Namespaces hat?


#1

Hallo,

und zwar Zeigt mir Oxid bei manchen Modulen an, dass es die Klassen nicht findet:

CiOxidUi	
OxidEsales\Eshop\Application\Model\Article => Ci\Oxid\Ui\Models\Article
OxidEsales\Eshop\Application\Component\Widget\ArticleDetails => Ci\Oxid\Ui\Widgets\ArticleDetails
OxidEsales\Eshop\Application\Controller\Admin\ArticleExtend => Ci\Oxid\Ui\Controllers\Admin\ArticleExtend

Die Pfade existieren, die Namespaces sind korrekt, die Angabe in der composer.json ist in Ordnung. Gibt es irgendeinen Cache den ich leeren muss, wenn ich ein Modul anpassen?

Die meisten Module die ich portiere funktionieren, nur bei zweien zeigt Oxid immer wieder, dass die Klasse nicht gefunden werden kann, die Klasse kann aber von mir von Hand aufgerufen werden.

Eine der Klassen (/modules/ci-haeuser/Ui/Models/Article.php) sieht z.B. so aus:

<?php

namespace Ci\Oxid\Ui\Models;

use OxidEsales\Eshop\Core\Model\ListModel;

class Article extends Article_parent
{
}

composer.json

"autoload": {
  "psr-4": {
    "Ci\\Oxid\\Ui\\": "../../../source/modules/ci-haeuser/Ui/"
  }
}

metadata

'extend' => [
    \OxidEsales\Eshop\Application\Controller\Admin\ArticleExtend::class =>
        Ci\Oxid\Ui\Controllers\Admin\ArticleExtend::class,
    \OxidEsales\Eshop\Application\Component\Widget\ArticleDetails::class =>
        Ci\Oxid\Ui\Widgets\ArticleDetails::class,
    \OxidEsales\Eshop\Application\Model\Article::class =>
        Ci\Oxid\Ui\Models\Article::class
],

#2

Wie installierst du das Modul? Was heißt “von Hand aufgerufen”?


#3

Das Modul wird mit composer req installiert. Von Hand heißt <?php new Ci\Oxid\Ui\Controllers\Admin\ArticleExtend(); ?>


#4

Ich glaube der Fehler liegt irgendwo anders. Reduziere das Modul mal auf die eine leere Klasse und probiere das in einer frischen Oxid-Installation.


#5

Also gibt es denn keine Möglichkeit in Oxid zu Debuggen oder irgendwie eine Fehlermeldung zu bekommen? Oxid muss doch einen Grund haben warum es “Probleme mit den Klassen” hat. Die Oxid Installation ist clean, die Klasse ist leer.

Edit: In der Config habe ich debug auf -1 gestellt, das hilft ein wenig.

Dann habe ich den den Composer-Cache Dateien alte Namespaces gefunden, die musste ich entfernen.

LG
Sascha


#6

Danke fürs Feedback.


#7

In der ModuleChainsGenerator in der Zeile (glaube 280 wars) einen BreakPoint setzen. Da sieht man welche Namespaces geladen wurden.

Ansonsten Module Internals hilft auch.
Ist an sich kein Oxid „Problem“ sondern hat was mit Composer zutun :slight_smile:Preformatted text


#8

Danke, ja war ein Composer Problem.

Ich denke ich kann hier auch mehr zur Problem-Lösung beitragen:

  • Stimmt der Quelltext im /source/modules/Kürzel/Modul mit dem in /vendor/Kürzel/Modul überein?
  • Ist in der composer.json eine Version hinterlegt und stimmt diese mit dem Git-Tag überein?
  • Wenn Git-Tags und Packagist / Satis verwendet wird, sollte die Version in composer.json entfernt werden
  • Stimmt der Modul-Quelltext mit dem im Source (Packagist / Path / Git) überein?

Danach die üblichen Probleme:

  • Composer.json prs-4 und target-directory prüfen (Copy&Paste-Fehler ausschließen)
  • Composer.json Paketname prüfen
  • Namespaces prüfen

Ich habe mir ein Satis-Repository aufgesetzt. Durch die Versionsnummer in der composer.json konnte ich ändern was ich wollte, es wurde nie die aktuelle Git-Version, sondern immer nur die Version aus composer.json geladen.

Evt. noch ein weiteres Problem, beim Update werde ich gefragt, ob die Module überschrieben werden sollen. Hier habe ich nicht Y eingetippt sondern meist einfach ENTER oder -n --no-interaction verwendet. --no-interaction funktioniert aber nur korrekt, wenn in der Composer Config discard-changes auf true steht. Sollte aber wirklich nur verwendet werden, wenn man sicher ist, das keine ungesicherten Dateien in den Modulen existieren (z.B. weil man Lokal arbeitet und nicht regelmäßig Committet).

LG
Sioweb