Installation Dummy-Erweiterung

[thesweetg]

Hallo,

ich versuche unter Contao 4.4.28 folgende Dummy-Erweiterung zu installieren:
https://github.com/Sioweb/Contao4DummyBundle

Ich hätte jetzt mal folgendes probiert:

1) Ich habe die Erweiterung runtergeladen und entpackt
2) Den Ordner "Sioweb" in den Ordner "vendor" kopiert
3) "composer update" und "vendor/bin/contao-console cache:clear" ausgeführt

... doch leider scheint das nicht zu funktionieren.
Die Dummy-Erweiterung sollte das Inhaltselement "ContentDummy" bereitstellen.
Dieses Inhaltselement kann ich im Backend nicht finden.

Kann mir jemand sagen was ich falsch mache?

Vielen Dank

[Spooky]

In den vendor Ordner kopierst du nie etwas selbst.

Was genau möchtest du machen? Ein lokales Bundle entwickeln, oder eines, dass du bspw. dann über Github, Packagist, etc. zur Verfügung stellst?

[thesweetg]

Ich möchte ein lokales Bundle entwickeln.

[PaddySD]

In diesem Post sind beide Varianten eigentlich recht gut beschrieben (ich persönlich tendiere immer zur vendor-Variante, man weiss ja nie, und ausserdem kann ich so die Erweiterung auch in einem private repository verwalten).

https://community.contao.org/de/show...l=1#post422990

Einziger Nachteil: der Cloud-resolver im Contao Manager kann keine path-reps lesen, d.h. Dein Server muss den Composer vom Speicher her abkönnen...

[Sioweb]

Ho!

die Installation könnte ich wohl wirklich etwas besser beschreiben

1. Also du lädst das Modul herunter und kopierst das Verzeichnis `bundles` in dein Contao-Root
2. Du passt deine composer.json an wie in der Readme beschrieben
3. Du führst composer install aus

[thesweetg]

Danke für die Tipps.

Leider sagt mir mein Terminal nachdem ich "composer install" ausgeführt habe folgendes:
"Nothing to install or update"


Nochmal zur Sicherheit ob ich eh nichts vergessen habe:


1) Ich hab die Erweiterung runtergeladen und in meine Installation kopiert:
"meine-contaoinstallation/bundles/Sioweb/DummyBundle/"


2) Die composer.json ("meine-contaoinstallation/composer.json") mit dem Code hier ergänzt:

    "repositories": [
        {
            "type": "path",
            "url": "bundles/Sioweb/DummyBundle"
        }
    ] 

3) "composer install" ausgeführt




Müsste doch so funktionieren, oder?

[Spooky]

Leider sagt mir mein Terminal nachdem ich "composer install" ausgeführt habe folgendes:
"Nothing to install or update"

Du musst wenn dann ein composer update machen.

[Sioweb]

Du musst noch sagen was du installieren willst:

Möglichkeit eins: Im Terminal `composer req sioweb/dummy-bundle` eingeben
Möglichkeit zwei: Du schreibst "sioweb/dummy-bundle": "*" in die requirements deiner composer.json und gibst dann `composer install` in das Terminal ein.

[PaddySD]

Ho!

die Installation könnte ich wohl wirklich etwas besser beschreiben

1. Also du lädst das Modul herunter und kopierst das Verzeichnis `bundles` in dein Contao-Root
2. Du passt deine composer.json an wie in der Readme beschrieben
3. Du führst composer install aus

Für das Dummy-bundle ja, aber für

Ich möchte ein lokales Bundle entwickeln.

ist die verlinkte Anleitung doch eher geeignet, oder?

@thesweetg
Du musst natürlich auch Deine Erweiterung unter "require" eintragen (in der composer.json). Und dann "composer install".

Siehe diese Zeile der readme.md
https://github.com/Sioweb/Contao4Dum...poser.json#L21

[Sioweb]

@PaddySD Das DummyBundle ist die fertige Version von deinem Link. Man lädt das Bundle lokal runter, installiert es mit Composer und entwickelt es lokal.

[Spooky]

Mit "lokalem Bundle" meinte ich eher Bundles, die man in src/ ablegt und auto loaded - und nicht über composer installiert.

[PaddySD]

@PaddySD Das DummyBundle ist die fertige Version von deinem Link. Man lädt das Bundle lokal runter, installiert es mit Composer und entwickelt es lokal.

Danke für die Aufklärung, hab ich ja mal wieder mit wenig Ahnung geglänzt...

Aber dann kann ich meine eigene Vorlage ja mal in die Tonne klopfen, und nehm einfach Deine Erweiterung.

[thesweetg]

Ich krieg's leider nicht zum laufen.

Hier meine Contao-composer.json:

{
    "name": "contao/managed-edition",
    "type": "project",
    "description": "Contao Open Source CMS",
    "license": "LGPL-3.0-or-later",
    "authors": [
        {
            "name": "Leo Feyer",
            "homepage": "https://github.com/leofeyer"
        }
    ],
    "require": {
        "php": "^5.6 || ^7.0",
        "contao/calendar-bundle": "^4.4",
        "contao/comments-bundle": "^4.4",
        "contao/faq-bundle": "^4.4",
        "contao/listing-bundle": "^4.4",
        "contao/manager-bundle": "4.4.*",
        "contao/news-bundle": "^4.4",
        "contao/newsletter-bundle": "^4.4",
        "omosde/contao-om-backend": "^1.3",
        "madeyourday/contao-rocksolid-custom-elements": "^2.2",
        "codefog/contao-cookiebar": "^2.1",
        "madeyourday/contao-rocksolid-columns": "^2.0",
        "delahaye/dlh_googlemaps": "^2.4",
        "sioweb/dummy-bundle": "*"

    },
    "conflict": {
        "contao/core-bundle": "<4.4.8"
    },
    "config": {
        "component-dir": "assets"
    },
    "extra": {
        "branch-alias": {
            "dev-4.4": "4.4.x-dev"
        }
    },
    "scripts": {
        "post-install-cmd": [
            "Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
        ],
        "post-update-cmd": [
            "Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
        ]
    },
    "repositories": [
        {
            "type": "path",
            "url": "bundles/Sioweb/DummyBundle"
        }
    ]

}

Und hier mein Dateiverzeichnis:

Bildschirmfoto 2018-11-13 um 08.32.36.png



Wenn ich mit dieser Konfiguration den Befehl "composer install" ausführe, sagt mir Composer folgendes:
"Nothing to install or update"

Wenn ich mit dieser Konfiguration den Befehl "composer update" ausführe, sagt mir Composer folgendes:
" - The requested package sioweb/dummy-bundle could not be found in any version, there may be a typo in the package name."


Bitte nochmal um eure Hilfe.
Vielen Dank im Voraus

[Sioweb]

Oh ich glaube das könnte an meinem Bundle liegen, ich hab in der Composer.json keine Version eingetragen.

Ich hab das hier nachgetragen, kannst du das bei dir bitte auch eintragen und noch mal ausführen? https://github.com/Sioweb/Contao4Dum...mposer.json#L4

Zur Sicherheit noch: /bundles/Sioweb/DummyBundle/composer.json anpassen, nicht die im Root

[thesweetg]

Hab ich gemacht.
Jetzt bekomme ich diese Fehlermeldung nach einem "composer update":
Bildschirmfoto 2018-11-13 um 09.18.53.png

[thesweetg]

Leider krieg ich die Erweiterung trotz eurer Hilfe nicht zum laufen.


Wie sieht eigentlich ein lokales Bundle aus das auf das allernötigste reduziert ist?
Ich denke das mir so ein "Hello-World-Bundle" beim Verständnis helfen würde.

In der 3.5er reichte in der config.php folgende Zeile Code:
"$GLOBALS['BE_MOD']['system']['mymodule'] = array();"
... um im Backend ein (nutzloses) Modul erscheinen zu lassen

Welche Ordner/Dateien brauche ich um das mit einem lokalen Bundle in der 4.4 zu erreichen?

[Spooky]

Hier ein Beispiel mit Controller:

Structure:

contao4/
|- src/
   |- AppBundle/
      |- Controller/
      |---- DefaultController.php
      |- Resources/
      |---- config/
      |     |- routing.yml
      |- AppBundle.php
   |- ContaoManagerPlugin.php

AppBundle.php:

<?php

namespace AppBundle;

use Symfony\Component\HttpKernel\Bundle\Bundle;

class AppBundle extends Bundle
{
}

ContaoManagerPlugin.php:

<?php

use Contao\ManagerPlugin\Routing\RoutingPluginInterface;
use Symfony\Component\Config\Loader\LoaderResolverInterface;
use Symfony\Component\HttpKernel\KernelInterface;

class ContaoManagerPlugin implements RoutingPluginInterface
{
    /**
     * {@inheritdoc}
     */
    public function getRouteCollection(LoaderResolverInterface $resolver, KernelInterface $kernel)
    {
        return $resolver
            ->resolve(__DIR__.'/../src/AppBundle/Resources/config/routing.yml')
            ->load(__DIR__.'/../src/AppBundle/Resources/config/routing.yml')
        ;
    }
}

DefaultController.php:

<?php

namespace AppBundle\Controller;

use Symfony\Component\HttpFoundation\JsonResponse;
use Symfony\Component\Routing\Annotation\Route;

class DefaultController
{
    /**
     * @Route("/ajax")
     *
     * @return JsonResponse
     */
    public function ajaxAction()
    {
        return new JsonResponse(['Hello World!']);
    }
}

routing.yml:

app:
    resource: "@AppBundle/Controller"
    type: annotation

composer.json:

{
    …,
    "autoload": {
        "psr-4": { "": "src/" },
    }
}

composer dump-autoload
vendor/bin/contao-console cache:clear --no-warmup
vendor/bin/contao-console cache:warmup

Siehe auch https://community.contao.org/de/show...AX-im-Frontend

[thesweetg]

Danke für das Beispiel.

Was macht diese Erweiterung?

Ich nehme an mit der "composer.json" ist die im Contao-Root gemeint, oder?

[Spooky]

Was macht diese Erweiterung?

Nichts besonderes. Das Bundle stellt nur eine Route namens "/ajax" zur Verfügung unter welcher ein JsonResponse mit ["Hello World!"] zurück gegeben wird.

Ich nehme an mit der "composer.json" ist die im Contao-Root gemeint, oder?

Genau, ja.

[thesweetg]

Ich hab jetzt die Hello-World-Dummy-Erweiterung adaptiert:
Nun zeigt sie im Backend ein (funktionsloses) Backend-Modul an.

Hier der Link zur veränderten Version:
https://github.com/georgpreissl/basicbundle


Meine Fragen nun dazu:

1) Kann man den Code noch weiter reduzieren?
Ich nehme an die Klassen "DefaultController" und "AppBundle" sind notwendig.

2) Wie sieht der Workflow aus wenn ich nun Änderungen am Code vornehme?
Muss ich jedes mal nach einer Änderung den Cache per Terminal leeren?

3) Um der Erweiterung einen anderen Namen zu geben, muss ich überall den Begriff "AppBundle" ändern, oder?
D.h. in allen Verzeichnisnamen und Files wird "AppBundle" zu zb. "MyBasicBundle".
Müsste das dann wieder funktionieren?


Sorry für meine Anfänger-Fragen
Hab keinen Dunst von der Bundle-Entwicklung.

Vielen Dank im Voraus
lg

[Spooky]

1) Kann man den Code noch weiter reduzieren?
Ich nehme an die Klassen "DefaultController" und "AppBundle" sind notwendig.

Die Klasse AppBundle brauchst du. Das AppBundle wird von Contao automatisch geladen.

2) Wie sieht der Workflow aus wenn ich nun Änderungen am Code vornehme?
Muss ich jedes mal nach einer Änderung den Cache per Terminal leeren?

Nur bei config Änderungen, im wesentlichen.

3) Um der Erweiterung einen anderen Namen zu geben, muss ich überall den Begriff "AppBundle" ändern, oder?
D.h. in allen Verzeichnisnamen und Files wird "AppBundle" zu zb. "MyBasicBundle".
Müsste das dann wieder funktionieren?

Nein, dann musst du das Bundle per Contao Manager Plugin laden lassen.

[thesweetg]

OK, danke schon mal für die Infos.
Leider werden bei mir die Fragen nicht weniger.

Nur bei config Änderungen, im wesentlichen.

Kann ich das "händische" Löschen des Cache im Terminal vermeiden, indem ich die "app_dev.php" in der URL verwende?
Jedes mal bei einer Änderung an der config.php den Cache löschen zu müssen kann's ja auch nicht sein.

Seltsam:
Wenn ich momentan das Backend über "app_dev.php" aufrufe (zb. über "http://mycontaodemo/app_dev.php/contao"), verschwindet mein Backend-Modul in der Auflistung.
Geb ich das "app_dev.php" wieder raus, ist das Modul wieder da.
Wie kann man das erklären?

Nein, dann musst du das Bundle per Contao Manager Plugin laden lassen.

Versteh ich nicht.
Der Name muss "AppBundle" lauten?
Kann ich im Ordner "src" nicht mehrere dieser Bundles (mit verschiedenen Namen) anlegen?



Danke,
lg

[Sioweb]

Ho!

das /src Verzeichnis ist kein Verzeichnis für eine tatsächliche Erweiterung. Im Grunde ist /AppBundle sogar eine "veraltete" Technik. Im /src spricht man auch von "Bundle less". Es sollte nur verwendet werden, um _diese_ eine Contao Installation um Code zu erweitern.

Wenn du eine zweite Erweiterung möchtest, musst du es so machen, wie in dem DummyBundle beschrieben. (Das Bundle funktioniert nun auch in 4.4 - Sry für die Fehler)

Oder du lädst dein Bundle auf Gitlab (Weil privat & kostenlos), oder auf packagist.org (nicht provat, aber kostenlos) je nach dem musst du dich mit einem Installationsprozess ob lokal, gitlab oder packagist vertraut machen. Die Anleitung im DummyBundle hat den Vorteil, dass du das Modul auch irgendwann ganz wo anders speichern kannst, ohne viel umstellen zu müssen.

Cache

Wie hast du die app_dev.php angelegt? Mit dem Konsolen-Befehl?

[Spooky]

Kann ich das "händische" Löschen des Cache im Terminal vermeiden, indem ich die "app_dev.php" in der URL verwende?
Jedes mal bei einer Änderung an der config.php den Cache löschen zu müssen kann's ja auch nicht sein.

Ja, du kannst den Entwicklermodus dafür verwenden.

Versteh ich nicht.
Der Name muss "AppBundle" lauten?
Kann ich im Ordner "src" nicht mehrere dieser Bundles (mit verschiedenen Namen) anlegen?

Nein, er muss nicht AppBundle lauten. AppBundle wird nur vom contao/manager-bundle automatisch geladen, damit ersparst du dir das anlegen eines Contao Manager Plugins. Sobald du aber bspw. eigene Routen brauchst, brauchst du auch ein Contao Manager Plugin.

Du kannst so viele Bundles erstellen wie du willst. Wie Sioweb schon erwähnt hat wären das, wenn du so vorgehst, jedoch Bundles, die üblicherweise nur diese eine Contao Installation betreffen und sonst keine. Natürlich könntest du bei einer neuen Installation die entsprechenden Bundles einfach nochmal hin kopieren - aber sobald du Bundles in mehreren Projekten wieder verwenden möchtest, gehst du den Weg über ein VCS.

[thesweetg]

Danke für die Infos.

Ich hab nun (auch mit Hilfe dieser tollen Anleitung) ein funktionierendes lokales Bundle hinbekommen.

Hab es in einem weiteren GitHub-Repo abgespeichert:
https://github.com/georgpreissl/basic-contao-bundle

Zusätzlich habe ich in der Readme-Datei eine kurze Installations-Anleitung angeführt.
Ergänzungen oder Korrekturen sind jederzeit willkommen.

Bei diesem Bundle tritt auch das ominöse Cache-Problem (weiter oben beschrieben) nicht mehr auf.

In diesem Bundle habe ich nun auch versucht einen Hook zu verwenden.
Das klappt leider noch nicht
Vielleich kann mir da ja jemand helfen.

[Sioweb]

Cool, ist es Absicht dass der Hook auskommentiert ist?

[thesweetg]

@Sioweb:

Ich hatte bei meinem letzten Beitrag dein Posting ganz übersehen.
Danke für deine Erklärungen.
Hab nun die aktuelle Version deiner Dummy-Erweiterung zum Laufen bekommen
Werd sie mir jetzt mal anschauen und versuchen das Ganze zu verstehen.

Wie hast du die app_dev.php angelegt? Mit dem Konsolen-Befehl?

Ich hab die (soweit ich mich erinnern kann) garnicht angelegt.
Muss man das normalerweise?

Cool, ist es Absicht dass der Hook auskommentiert ist?

Ja. Mit dem Hook hat das Bundle nicht mehr funktioniert.
Ich nehme an ich muss hier:

$GLOBALS['TL_HOOKS']['replaceInsertTags'][] = array('DeinName\Test\Hooks\Inserttags', 'myReplaceInsertTags'); 

... einen anderen Klassennamen als Parameter angeben, oder?

Oder etwa die Klasse "MyClass" in der composer.json registrieren?

[thesweetg]

By the way:
Gibts auf https://packagist.org eigentlich eine Möglichkeit die Contao Bundles nach "Aktualität" zu sortieren?
D.h. eine Sortiermöglichkeit wie zb. "zuletzt geändert".

[Sioweb]

Ah ich sehe, vermutlich liegt es daran dass der Hook keine Klasse angibt.

$GLOBALS['TL_HOOKS']['replaceInsertTags'][] = array('DeinName\Test\Hooks\Inserttags\MyClass', 'myReplaceInsertTags'); 

Dann ist der Namespace noch unvollständig, der muss dem Verzeichnis-Pfad entsprechen, damit Composer weis wo die Klasse liegt:

namespace DeinName\Test\Hooks\Inserttags; 

[thesweetg]

Danke für den Tipp, das mit dem Hook hat nun funktioniert.


Ich hab nun auch das Bereitstellen eines Bundles per packagist.org ausprobiert.
Dazu habe ich ein weiteres Test-Bundle erstellt:
https://github.com/georgpreissl/dummyx

Dieses Bundle kann ich wie erwartet per Composer installieren.
D.h. mit dem Befehl:

composer require "georgpreissl/dummyx @dev" 

... landet das Bundle in meiner Contao-Installation und funktioniert.
(Ohne das "@dev" hat's leider nicht funktioniert, weiß jemand woran das liegt?)
So weit so glücklich





Nun hab ich aber auch versucht das Bundle lokal zu installieren:


Schritt 1:
Die packagist-Version mittels:

composer remove georgpreissl/dummyx

... wieder entfernt.


Schritt 2:
Folgende Ordnerstruktur angelegt:
my-contao-root/bundles/GeorgPreissl/DummyX


Schritt 3:
In den Ordner "DummyX" meinen src-Ordner und die composer.json reinkopiert.
Die Inhalte von "DummyX" sowie die composer.json habe ich nicht verändert.


Schritt 4:
Die composer.json im root der Contao-Installation mit folgendem Code ergänzt:

    "repositories": [
        {
            "type": "path",
            "url": "bundles/GeorgPreissl/DummyX"
        }
    ],

Schritt 5:
Die Befehle:

composer update
vendor/bin/contao-console cache:clear

... ausgeführt.


Resultat:
Nichts wird installiert
Was mache ich da falsch?


Danke,
lg

[Sioweb]

Also auf Packagist musst du dem Paket eine Version geben, ich bin mir nicht sicher ob das ohne weiteres geht. Wenn du es von Github/Gitlab automatisch auf Packagist laden lässt, übernimmt Packagist die Git-Tag-Nummer als Version. Auf Github nennt sich dass dann Release.

Du kannst aber in der composer.json deines Paketes noch "version": "1.0.0" angeben. Das dumme daran ist, dass du die Nummer auch immer Anpassen musst, damit Composer die Änderungen von Packagist lädt.

Hast du dein Paket auch in den Requirements hinterlegt? `composer update` kann dein Paket nur finden wenn es in den Requirements steht. Lokal benötigst du wie oben erwähnt die option "version": "1.0.0" in der composer.json deines Paketes.

[thesweetg]

Also auf Packagist musst du dem Paket eine Version geben, ich bin mir nicht sicher ob das ohne weiteres geht. Wenn du es von Github/Gitlab automatisch auf Packagist laden lässt, übernimmt Packagist die Git-Tag-Nummer als Version. Auf Github nennt sich dass dann Release.

OK, danke für die Info.
Hab nun auf Github einen Release mit der Nummer v1.0 erstellt.
Werde die Installation dann nochmal per "composer require "georgpreissl/dummyx" probieren.

Hast du dein Paket auch in den Requirements hinterlegt? `composer update` kann dein Paket nur finden wenn es in den Requirements steht. Lokal benötigst du wie oben erwähnt die option "version": "1.0.0" in der composer.json deines Paketes.

Der require-Eintrag in der composer.json meines Bundles sieht momentan so aus:

	"require": {
		"php": ">=5.6.0",
		"contao/core-bundle": "^4"
	},

... sollte ich den ergänzen?
Tappe da ein wenig im Dunkeln
Etwa so:

	"require": {
		"php": ">=5.6.0",
		"contao/core-bundle": "^4",
		"georgpreissl/dummyx": "^1.0"
	},

[PaddySD]

2) Wie sieht der Workflow aus wenn ich nun Änderungen am Code vornehme?
Muss ich jedes mal nach einer Änderung den Cache per Terminal leeren?

Kann ich das "händische" Löschen des Cache im Terminal vermeiden, indem ich die "app_dev.php" in der URL verwende?
Jedes mal bei einer Änderung an der config.php den Cache löschen zu müssen kann's ja auch nicht sein.

Seltsam:
Wenn ich momentan das Backend über "app_dev.php" aufrufe (zb. über "http://mycontaodemo/app_dev.php/contao"), verschwindet mein Backend-Modul in der Auflistung.
Geb ich das "app_dev.php" wieder raus, ist das Modul wieder da.
Wie kann man das erklären?

Nur bei config Änderungen, im wesentlichen.

Ich kann das leider nicht bestätigen, ich muss eigentlich immer den Cache löschen, nicht nur bei config-Änderungen. Egal, ob ich die app_dev.php aufrufe, oder nicht.

Was auch hier nämlich das Problem ist. Dein Modul ist nach dem löschen des Cache für die prod-Umgebung nämlich dort schon da, in der app_dev werden aber noch die "alten", gecachten Dateien verwendet. Erst wenn man auch den dev cache löscht, dann erscheint auch dort das Modul (..contao-console cache:clear --env=dev).

Ich hab keine Ahnung, woran das liegt, aber mein Workflow sieht das löschen des cache mittlerweilen standardmässig vor... Ist ja auch nicht soviel Aufwand, wenn Du bei Deinem SSH-Client (Putty zB) das ganze einmal eingibst, brauchst Du beim nächsten mal nur die Pfeil-nach-oben-Taste nehmen, dann wird der Befehl exakt wiederholt. Insofern ist cache löschen, egal ob prod oder dev bei mir mittlerweilen eine drei Klick Sache. Terminal auswählen -> Pfeil-nach-oben -> Enter...warten auf den grünen Balken, Browser aktualisieren...

[Spooky]

Nenne mal ein Beispiel wofür genau du den dev Cache löschen musst.

[Sioweb]

Der require-Eintrag in der composer.json meines Bundles sieht momentan so aus:

Genau, aber die Composer.json von Contao braucht den Eintrag. Du brauchst also zwei Dinge in der root composer.json:

- Den Namen des Paketes + Versionsnummer in "require": {}
- Die Angabe WIE das Paket zu finden ist in "repositories": {}
- Die Angabe WO das Paket zu finden ist in "repositories": {}

Version auf Packagist

Wenn du auf Github ein Release angelegt hast, musst du in Packagist noch auf "Update" klicken. Es ist allerdings auch möglich, in Github unter den Settings deines Paketes einen Service zu hinterlegen, der Packagist automatisch aktualisiert.

Wichtig: Wenn du auf Packagist eine Version hinterlegt hast, solltest du "version": "X.X.X" aus der composer.json entfernen. Da composer sonst nicht genau weiß, ob er die Packagist-Version, oder die composer.json-Version beachten soll.

Cache

Den app_dev Cache musst du meist nur einmal leeren. Falls nicht, kannst du in der Konsole auch "rm -Rf var/cache eingeben", sei aber vorsichtig mit dem Befehl, der löscht alles in var/cache ohne dass du es wieder herstellen kannst.

Composer Cache

Wenn dein Modul einmal auf Packagist und einmal Lokal ist, weiß composer nicht so genau, wo und was er suchen soll. In der Datei composer.lock und im Composer Cache steht, wo und wie Composer bereits heruntergeladene Module finden kann. Dazu gibt es in der Konsole den befehl "composer clearcache" - Falls du Composer global installiert hast - Und du musst die composer.lock löschen.