Win7, XAMPP: Fehler beim Update von Packages

[Spooky]

Ich verwende Composer in einer Contao 3.2.3 Installation. Composer wurde anhand dieser Anleitung installiert: https://community.contao.org/de/show...odels-Composer

Wenn ich nun bei einem Package auf eine höhere (bzw. andere) Version umstellen möchte und danach Update, löscht der Package Manager zwar alle alten Dateien aus dem jeweiligen Verzeichnis in system/modules/..., aber es bleibt danach leer, die neuen Dateien werde nicht mehr hinzugefügt. Die Extension hat zwar immer noch die komplette Ordnerstruktur, es bleibt aber alles leer. Auch mehrmalige Aufrufe von "Update packages" bringen nichts.

Vorgangsweise am Beispiel von Theme+, switch von 4.3.4 auf 5.0.x-dev (zum Test):

1. Ich klicke im Package Manager auf bit3/contao-theme-plus
2. Ich wähle 5.0.x-dev aus
3. Ich klicke auf "Mark package to install"
4. Ich klicke auf "Update packages"
5. Der Package Manager gibt zwar folgendes aus:

   Loading composer repositories with package information Updating dependencies - Removing mobiledetect/mobiledetectlib (2.7.6) - Installing mobiledetect/mobiledetectlib (2.7.7) Downloading - Removing bit3/contao-theme-plus (4.3.4) - Installing bit3/contao-theme-plus (dev-develop 074c62c) Downloading - removed 63 files - installed 64 files - Removing menatwork/semantic_html5 (1.1.9) - Installing menatwork/semantic_html5 (1.1.10) Downloading - removed 24 files - installed 25 files Writing lock file Generating autoload files

   Trotz der Meldung "installed 25 files" wurden jedoch keine Dateien im system/modules/theme-plus Verzeichnis installiert. Die Ordnerstruktur (assets, config, dca, etc.) ist zwar noch vorhanden, alle Ordner sind jedoch leer
6. Weiterer Aufruf von "Update packages" liefert nur

   Loading composer repositories with package information Updating dependencies Generating autoload files

Tril hat mich gefragt, ob ich contao-community-alliance/composer-installer oder contao-community-alliance/composer-plugin (?) benutze, in meinem Fall ist es:

contao-community-alliance/composer-installer ~1.7.1* 1.7.1

Anscheinend ist contao-community-alliance/composer-installer auch schon wieder out of date? Das ist aber das, was man von c-c-a.org bekommt, oder nicht? (Da ich ja nach der oben genannten Anleitung vorgegangen bin.)



Aktuell muss ich immer das komplette Package deinstallieren und wieder installieren, damit der Version Switch funktioniert. Wie könnte ich das beheben? Oder würde contao-community-alliance/composer-plugin dies beheben, wenn ja, wie ersetze ichcontao- community-alliance/composer-installer durch contao-community-alliance/composer-plugin (contao-community-alliance/composer-installer ist ja als Dependency installiert)?

[Spooky]

Ich habe als zusätzlichen Test folgendes gemacht:

• Contao 3.2.4 neu heruntergeladen und lokal am XAMPP entpackt
• Composer für Contao (production use) heruntergeladen und nach TL_ROOT entpackt
• Datenbank eingerichtet
• install.php aufgerufen, alles eingerichtet
• Im Backend die Migration zum Package Manger durchgeführt
• contao-community-alliance/composer-plugin gesucht und die 2.0.x-dev zur Installation markiert
• Update durchgeführt, contao-community-alliance/composer-installer wurde durch contao-community-alliance/composer-plugin ersetzt
• bit3/theme-plus 4.3.4 ausgewählt zur Installation, Update packages
• bit3/theme-plus 5.0.x-dev ausgewählt zur Installation, Update packages
• Package Manager meldet:

  Class ContaoCommunityAlliance\ComposerInstaller\ModuleInstaller is not autoloadable, can not call pre-update-cmd script
  Loading composer repositories with package information 
  Updating dependencies 
  - Removing bit3/contao-theme-plus (4.3.4) 
  - Installing bit3/contao-theme-plus (dev-develop 074c62c) 
  Downloading 
  
  - removed 63 files 
  - installed 64 files 
  Writing lock file Generating autoload files Class ContaoCommunityAlliance\ComposerInstaller\ModuleInstaller is not autoloadable, can not call post-autoload-dump script 
  Class ContaoCommunityAlliance\ComposerInstaller\ModuleInstaller is not autoloadable, can not call post-update-cmd script

  Es sind jedoch keine neuen Dateien installiert worden. Wie zuvor sind alle Dateien gelöscht worden, einzig und allein die system/modules/theme-plus/dca/tl_settings.php blieb über

Getestet unter Windows 7 x64 mit XAMPP 1.8.3 und PHP 5.5.4


Die Meldung

Class ContaoCommunityAlliance\ComposerInstaller\ModuleInstaller is not autoloadable, can not call pre-update-cmd script

passiert bei jedem Update, nachdem der contao-community-alliance/composer-installer durch contao-community-alliance/composer-plugin ersetzt wurde.

[Spooky]

Ok, aktuell removed sich der contao composer sogar selbst, weil es für die dev-master ein Update gibt

Repro:

• Contao 3.2.4 neu heruntergeladen und lokal am XAMPP entpackt
• Composer für Contao (production use) heruntergeladen und nach TL_ROOT entpackt
• Datenbank eingerichtet
• install.php aufgerufen, alles eingerichtet
• Im Backend die Migration zum Package Manger durchgeführt
• Update packages, Meldung "The composer configuration has been updated, please redo the last action."
• Update packages, die Composer Extension wird versucht zu aktualisieren, aber wie zuvor werden nur alle alten Dateien gelöscht und keine neuen Datei installiert. Daher sieht das Backend nach dem zweiten mal "Update packages" so aus:
  
  

Wenn man danach nochmal die Composer Extension aus dem zuvor heruntergeladenem Archiv wieder nach TL_ROOT installiert, das Backend neu aufruft und die Migration nochmal durchführt sieht man auch noch den log output, den man normalerweise nach dem Update sehen würde:

Es steht zwar, wie zuvor, "- installed 79 files", aber es sind nur die alten files removed worden, keine neuen hinzugekommen (die Ordnerstruktur der !composer extension ist nach wie vor vorhanden, so wie in den anderen Fällen).

[Spooky]

Unter Debian 7, PHP 5.4.4 tritt der Fehler nicht auf, scheint wohl ein spezifischeres Problem mit der lokalen Testumgebung zu sein (Windows, XAMPP, Apache und/oder PHP Version bspw.). Im error log des Apache meines XAMPPs scheint aber leider nichts auf, hm :|

[Spooky]

Selber Fehler passiert auch unter WAMP 2.4. Hat jemand ähnliche Probleme unter Windows?

[ciaobello]

Ich verlinken mal das andreasisaak hier nicht alles 3mal schreiben muss:

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


Übrigens darf man auch freiwillig andere Themen angucken mit ähnlichen Problemen ... macht sogar sinn ein einem Forum

[Spooky]

Übrigens darf man auch freiwillig andere Themen angucken mit ähnlichen Problemen ... macht sogar sinn ein einem Forum

Das Problem in solchen Fällen ist ja nicht das "dürfen", sondern die richtigen Search Queries finden . Und in vielen Fällen ist es schwierig andere Threads zu finden, ohne deren Inhalte schon zu kennen (und dann müsste man sie ja schon nicht mehr suchen). Der von dir gepostete Thread käme mir daher auch nie unter - das Problem dort ist ja auch ganz anders, zumindest laut der Beschreibung dort im Thread.

Aber danke... nur leider ist

Auf Windows funktioniert er schlichtweg nicht. Ich würds gar nicht erst probieren.

nicht sehr informativ, einen Grund wird's ja wohl geben.

[ciaobello]

Ja, wegen den Stichworten hast recht ... viele male sind die Themen Haarsträubend Betitelt.

Wegen dem anderen von Andreasisaak fragst ihn am besten mal, entweder in einem gut besuchten Thema von Ihm oder im IRC. Dann kriegst sicher eine Antwort ... aber heute mit Virtualbox ist es doch einfach einen Webserver auf Linux aufzubauen.

Hier ein Beispiel https://puphpet.com/

[andreasisaak]

Aber danke... nur leider istnicht sehr informativ, einen Grund wird's ja wohl geben.

Was gibts dazu zu sagen. Windows ist ne Ausnahme für die derzeit einfach keine Manpower und kein Geld verfügbar ist. Daher versuchen wir Composer erstmal auf Unixsystemen zum laufen zu bekommen.

[Spooky]

Ist schon klar, mir geht es ja nur darum zu erfahren wo das Problem liegt, damit ich da ggf. selbst mithelfen kann. Ohne mehr Info müsste ich halt von 0 weg Debuggen.

[Spooky]

Mit der aktuellsten Version der Composer Extension (von https://c-c-a.org/ueber-composer?fil...o-composer.zip) und Contao 3.2.8 scheint das Problem nicht mehr aufzutreten. Nach updates von Packages scheinen alle neuen Dateien der jeweiligen Extension korrekt installiert worden zu sein.

Einziger Fehler den ich bemerkt habe: bei der Deinstallation der Theme+ Extension blieb der Ordner modules/theme-plus/languages über (ohne Inhalt).

[Spooky]

Leider doch nicht - habe es mal als issue auf Github festgehalten.

[Zero]

So, habe es hinbekommen dass die composer Erweiterung unter Windows läuft:

1. Umgebungsvariable `Path` setzen für `php.exe`
2. Folgende Variablen in der localconfig setzen: (Sollte es wieder erwarten dennoch nicht gehen füge es in die Datei initconfig.php ein)
`$GLOBALS['TL_CONFIG']['composerExecutionMode'] = 'detached';`
`$GLOBALS['TL_CONFIG']['composerPhpPath'] = 'php -d memory_limit=1G -d max_execution_time=900';`
3. composer Erweiterung installieren (Manuell oder übers Extension Repo)
4. In jedem fall den composer cache leeren, sollten schon diverse experimente mit composer gemacht worden sein
5. fröhlich Pakete installieren

Danke an @discordier für den Support und die Erklärungen

[Spooky]

Das behebt leider nicht das Problem, das hier im Thread beschrieben wird, zumindest nicht in meinem Fall. Auch nach diesen Maßnahmen verschwinden die Dateien aller aktualisierten Extensions.

[Zero]

Das behebt leider nicht das Problem, das hier im Thread beschrieben wird, zumindest nicht in meinem Fall. Auch nach diesen Maßnahmen verschwinden die Dateien aller aktualisierten Extensions.

Dann schreib es in die initconfig.php. Xtra meinte das sei ein Fehler, dass bei einem Update die Config nicht richtig eingelesen wird.
Wenn das nichts hilft, musst du dir den aktuellen dev-develop branch holen und es damit versuchen.

[Spooky]

Ok ja, hatte mich schon gewundert, weil eigentlich sollte dann ja ein separater PHP Prozess zu sehen sein (im Prozessmanager), während dem update, oder? Das war nämlich nicht der Fall.

Ich werd's nochmal mit initconfig.php probieren, einmal mit der stable von c-c-a.org und einmal mit der dev.

[Zero]

Ok ja, hatte mich schon gewundert, weil eigentlich sollte dann ja ein separater PHP Prozess zu sehen sein (im Prozessmanager), während dem update, oder? Das war nämlich nicht der Fall.

Ich werd's nochmal mit initconfig.php probieren, einmal mit der stable von c-c-a.org und einmal mit der dev.

Hats eigentlich geklappt?

[Spooky]

Bin noch nicht dazugekommen. Wollte es erstmal bei einer bestehenden Testinstallation probieren, aber ich komm nicht recht dahinter, wie ich die bestehende Composer Extension auf die neueste stable Version aus dem ER oder von c-c-a.org aktualisiere.

[tab]

Also ich habe letztens auch von 0.8.x auf die Version 0.9.2 upgedatet. Dazu habe ich einfach das bestehende Paket angeklickt, dann kommt ja die Liste mit den verfügbaren Versionen. Habe dann einfach die Version 0.9.2 ausgewählt und das Paket für die Installation vormerken geklickt. Danach dann Pakete aktualisieren und ich hatte die neue Version, die alte wurde automatisch deinstalliert.

Mit "Composer aktualisieren", was ich bei meiner alten Version noch ganz oben auswählen konnte, hat es jedenfalls nicht funktioniert, wahrscheinlich weil es ein anderes Paket war - oder warum auch immer.

Jetzt konnte ich vor zwei Minuten einfach mittels "Pakete aktualisieren" auf die noch neuere Version 0.9.3 updaten. Ist allerdings online auf einem Apache-Server und nicht lokal unter Windows. Aber die grundsätzliche Vorgehensweise wird ja wohl dieselbe sein. Jedenfalls hat das Update bei mir einige kürzlich aufgetretene Probleme behoben.

[Spooky]

Also ich habe letztens auch von 0.8.x auf die Version 0.9.2 upgedatet. Dazu habe ich einfach das bestehende Paket angeklickt, dann kommt ja die Liste mit den verfügbaren Versionen. Habe dann einfach die Version 0.9.2 ausgewählt und das Paket für die Installation vormerken geklickt. Danach dann Pakete aktualisieren und ich hatte die neue Version, die alte wurde automatisch deinstalliert.

Mit "Composer aktualisieren", was ich bei meiner alten Version noch ganz oben auswählen konnte, hat es jedenfalls nicht funktioniert, wahrscheinlich weil es ein anderes Paket war - oder warum auch immer.

Jetzt konnte ich vor zwei Minuten einfach mittels "Pakete aktualisieren" auf die noch neuere Version 0.9.3 updaten. Ist allerdings online auf einem Apache-Server und nicht lokal unter Windows. Aber die grundsätzliche Vorgehensweise wird ja wohl dieselbe sein. Jedenfalls hat das Update bei mir einige kürzlich aufgetretene Probleme behoben.

Pakete über den Composer zu aktualisieren geht ja nicht, darum geht es ja hier in diesem Thread .


Mit der bestehenden Installation (wo noch die 0.8.1 oder so benutzt wird) hat auch das mit der initconfig.php nicht funktioniert (hatte auch dann keinen eigenen PHP Prozess gesehen im Taskmanager beim nachfolgenden Aktualisieren der Pakete). Daher würde ich es mal einfach mit der neuesten Version der Composer Extension probieren, aber bin eben noch nicht dazugekommen es bei einer frischen Installation zu testen.

[tab]

Hmm, das heißt man kann lokal unter Windows keine Pakete installieren? Oder nur nicht aktualisieren? Und mit der neuen Composer-Version würde es eventuell funktionieren? Warum nicht die ganze Installation kurz online stellen, dort auf den neuen Composer(Client) aktualisieren und dann wieder aufs lokale System transferieren? Das wäre jedenfalls meine Vorgehensweise, wenn wirklich die berechtigte Hoffnung besteht, dass mit der neuen Version danach alles lokal funktioniert.

[tab]

Sehe gerade, das Problem scheint bei dir eher der Composer-Installer zu sein. Meiner ist auch
contao-community-alliance/composer-installer 1.7.1.0
So wie es aussieht gibt es ja ausserdem nur noch die ganze drei Tage neuere Version dev-master Referenz: d5123c7f vom 29.11.2013.

[Spooky]

Hmm, das heißt man kann lokal unter Windows keine Pakete installieren? Oder nur nicht aktualisieren?

Package update läuft schief, erstmalige Installation von Packages funktioniert. Ob das bei jedem unter Windows so ist kann ich nicht sagen, aber zumindest auf allen meinen Systemen ist das der Fall (ist aber in jedem Fall eben Win7x64 und dieselbe XAMPP Version).

Warum nicht die ganze Installation kurz online stellen, dort auf den neuen Composer(Client) aktualisieren und dann wieder aufs lokale System transferieren? Das wäre jedenfalls meine Vorgehensweise, wenn wirklich die berechtigte Hoffnung besteht, dass mit der neuen Version danach alles lokal funktioniert.

Naja, wenn dann würde ich's lokal in einer Linux VM machen, aber ja, wäre auch meine Vorgehensweise . Aber mir geht's ja auch darum zu testen, was nun genau funktioniert und was nicht. Die von Zero beschriebenen Dinge alleine haben mal nicht geholfen, daher wäre der nächste Versuch es mit der neuesten Version der Composer Extension zu testen. Mit und ohne composerExecutionMode Änderung.

[Spooky]

So, habe nun Zero's Vorschlag mit einer neuen Installation getestet. Folgende Vorgehensweise:

• Contao 3.2.9 neu heruntergeladen und lokal am XAMPP entpackt
• Datenbank eingerichtet
• install.php aufgerufen, alles eingerichtet
• Composer für Contao (production use) heruntergeladen und nach TL_ROOT entpackt
• Im Backend eingelogged und die Migration zum Package Manger durchgeführt
• bit3/contao-theme-plus 4.3.3 im Package Management hinzugefügt (um beim Test später auf bspw. 4.3.5 updaten zu können)
• "Update Packages" damit bit3/contao-theme-plus 4.3.3 installiert wird

Test 1

• Keine Änderung an der initconfig.php oder localconfig.php vorgenommen
• bit3/contao-theme-plus auf 4.3.5 gesetzt
• Update Packages
• Fehler wie gehabt: es fehlen danach alle Dateien in system\modules\theme-plus (die Unterordner bleiben)

Test 2

• Änderung¹ in die localconfig.php hinzugefügt (php.exe ist per command line erreichtbar)
• bit3/contao-theme-plus auf 4.3.5 gesetzt
• Update Packages
• der 'detached' composerExecutionMode scheint zu funktionieren, im Task Manger ist die php.exe sichtbar während dem Update, darüber hinaus sieht man folgendes:
  
• Fehler wie gehabt: es fehlen danach alle Dateien in system\modules\theme-plus (die Unterordner bleiben)

Test 3

• Änderung¹ in die initconfig.php hinzugefügt (php.exe ist per command line erreichtbar)
• bit3/contao-theme-plus auf 4.3.5 gesetzt
• Update Packages
• der 'detached' composerExecutionMode scheint zu funktionieren, im Task Manger ist die php.exe sichtbar während dem Update, und man sieht wieder den oben erwähnten screen
• Fehler wie gehabt: es fehlen danach alle Dateien in system\modules\theme-plus (die Unterordner bleiben)

Leider hat die Änderung also nichts gebracht


¹

$GLOBALS['TL_CONFIG']['composerExecutionMode'] = 'detached';
$GLOBALS['TL_CONFIG']['composerPhpPath'] = 'php -d memory_limit=1G -d max_execution_time=900'; 

[mlweb]

Habe heute das erste Mal "composer" installiert. Eigentlich mit denkbar schlechten Voraussetzungen, wie ich in den Einträgen in diesem Thread entnommen habe
Windows 7 64bit mit XAMPP 1.8.3 PHP5.5.1
XAMPP/Windows ist für virtual Host konfiguriert
contaocheck lief fehlerfrei
Contao 3.2.9 ist jungfräulich ohne Erweiterungen installiert. Die in den vorherigen Beiträgen beschriebenen Einstellungen der localconfig.php bzw. initconfig.php habe ich nicht durchgeführt und auch nicht benötigt.
composer 0.9.5 habe ich über ER2 installiert und danach auch die Migration der einen existierenden Erweiterung (ich nehme an das ist composer selbst) durchgeführt.

bild_1.jpg.

Danach wurde auf "Pakete aktualisieren" geklickt. Auffällig ist, dass im Moment noch keine Abhängigkeiten installiert sind.

bild_2.jpg

Wenn man danach noch einmal auf Pakete aktualisieren klickt - egal ob man eine Erweiterung installiert hat oder nicht - ist die Paketverwaltung verschwunden.

bild_3.jpg

Dieses unbefriedigende Ergebnis ist reproduzierbar und wurde mehrfach mit und ohne Installation weiterer Erweiterungen über die Paketverwaltung getestet.
In diesem Zustand habe ich unter "Einstellungen", " Inaktive Erweiterungen" das Extension Repository wieder aktiviert. Als einzige Erweiterung war composer zu finden.

bild_4.jpg

Diesen einfach noch einmal angeklickt und auf reparieren gegangen. Danach sind Paketverwaltung und ggf. die zuvor über "composer" installierte Erweiterung vorhanden.

bild_5.jpg

bild_6.jpg

Jetzt gibt es eine Abhängigkeit.
Danach Pakete aktualisieren gedrückt bringt die Meldung, dass nichts mehr zu aktualisieren ist, die Paketverwaltung ist nach wie vor vorhanden.

bild_7.jpg

Danach metamodels und einige andere Erweiterungen installiert und alles scheint für mich als Nicht -Entwickler ok.

bild_8.jpg

Vielleicht hilft diese Beschreibung einigen anderen weiter, die Ihre Testumgebung trotz allem unter Windows laufen haben.

Gruß Maren

[Zero]

• Composer für Contao (production use) heruntergeladen und nach TL_ROOT entpackt

Hallo Spooky,
Versuch es mal über das Repo zu installieren. So habe ich es gemacht.
Allerdings habe ich bei einem ereuten Test festgestellt, dass ich es zwingend in die "initconfig.php" schreiben muss.

Contao 3.2.9 ist jungfräulich ohne Erweiterungen installiert. Die in den vorherigen Beiträgen beschriebenen Einstellungen der localconfig.php bzw. initconfig.php habe ich nicht durchgeführt und auch nicht benötigt.

Ohne diese Einstellung? Cool. Bei mir leider nicht. Wieso auch immer... ABer ich habe auch mit Contao 3.3.0 getestet.

[mlweb]

Ohne diese Einstellung? Cool. Bei mir leider nicht. Wieso auch immer... ABer ich habe auch mit Contao 3.3.0 getestet.

Ich habe es gerade auch mit Contao 3.3.0 getestet. Dort funktioniert es genauso. Der entscheidende Schritt ist:

Wenn die Paketverwaltung nach dem Pakete aktualisieren verschwunden ist, einmal unter Einstellungen das Extension Repository wieder aktivieren und Composer reparieren. Danach kann ich nach Herzenlust Erweiterungen installieren und Pakete aktualisieren ohne Probleme.

Vielleicht noch zu erwähnen ist, dass auf meinem Windows-Rechner Github für Windows und Git für Windows (msysgit) installiert sind. Ich weiss nicht ob das eine Rolle spielen kann.

Maren

[Spooky]

Wenn die Paketverwaltung nach dem Pakete aktualisieren verschwunden ist, einmal unter Einstellungen das Extension Repository wieder aktivieren und Composer reparieren. Danach kann ich nach Herzenlust Erweiterungen installieren und Pakete aktualisieren ohne Probleme.

Der Fehler tritt immer dann auf, wenn ein Paket aktualisiert wird - sprich, wenn beim ausführen von "Update Packages" tatsächlich eine neuere Version eines bestehenden Pakets heruntergeladen wird. In dem Fall löscht die Composer Extension die alten Dateien und kopiert aber die neuen Dateien nicht mehr in die entsprechenden Verzeichnisse der Extension in system/modules.

Deshalb ist bei dir auch bspw. die Paketverwaltung verschwunden, weil eben eine neuere Version verfügbar war, diese heruntergeladen wurde, aber in diesem Prozess die alten Dateien gelöscht und keine neuen Dateien kopiert wurden.

Prüfe mal, ob bei dir jetzt tatsächlich bei jedem Package Update der Fehler nicht mehr auftritt. Installiere dir von irgendeinem Paket eine ältere Version und setze es dann auf eine neuere Version, damit ein update durchgeführt wird. Vergleiche den exakten Inhalt der Extension (unter system/modules) davor und danach.


@Zero: die Einstellungen haben bei mir ebenso keine Auswirkungen. Funktionieren tut der Composer auch ohne (Pakete installieren funktioniert, Update von Paketen nicht).

[mlweb]

Hallo Spooky,
irgendwie kann ich den Fehler nicht nachvollziehen.
Ich habe jetzt noch zwei Tests durchgeführt.
System neu aufgesetzt. Mit dem Erweiterungskatalog einige Extension in älterer, zum Teil zu Contao 3.2.9 nicht explizit kompatibler Version installiert. Danach wie gehabt über ER2 Composer installiert, alles upgedatet und die Paketverwaltung war wie erwartet verschwunden. Danach ER2 wieder aktiviert, composer repariert, Pakete aktualisiert (in der Paketverwaltung nicht im ER2) und alles läuft. Dateien und Ordnerstruktur der Module wurden überschrieben und scheinen soweit ok.
Nachträglich eine ältere Version einer Extension manuell in Module geschoben. Dieses Paket ist für die Paketverwaltung erwartungsgemäß gar nicht sichtbar, wird aber bei einer Installation über den Paketmanager korrekt überschrieben.
Warte jetzt mal ab, bis es irgendwo eine "echtes" Update gibt und werde dann Bescheid geben, ob es funktioniert hat.
Eine andere Idee ältere Versionen zu installieren hatte ich jetzt nicht (wie gesagt bin kein Entwickler), denn mit der Paketverwaltung wird auch dann wenn ich eine ältere Version zur Installation auswähle immer die aktuellste installiert oder kann man da noch irgendetwas einstellen?
Bin gern bereit noch weitere Tests durchzuführen.

[Spooky]

Warte jetzt mal ab, bis es irgendwo eine "echtes" Update gibt und werde dann Bescheid geben, ob es funktioniert hat.

Du musst nicht darauf warten, du kannst ja explizit eine gewisse Version verlangen. Angenommen eine Extension hat die Versionen 1.1. und 1.2. verfügbar. Du markierst 1.1. zur Installation und wählst aus, dass nur die exakte Version installiert werden soll. Nach der installation setzt du es auf 1.2. und führst wieder "Update Packages" aus.

Vergleiche aber unbedingt den Status der Extension in system/modules davor und danach (manuell).

Eine andere Idee ältere Versionen zu installieren hatte ich jetzt nicht (wie gesagt bin kein Entwickler), denn mit der Paketverwaltung wird auch dann wenn ich eine ältere Version zur Installation auswähle immer die aktuellste installiert oder kann man da noch irgendetwas einstellen?

Ja, kann man, in dem Drop Down, dass es dort gibt.

irgendwie kann ich den Fehler nicht nachvollziehen.

Tust du eigentlich schon . Du schreibst ja

Danach wie gehabt über ER2 Composer installiert, alles upgedatet und die Paketverwaltung war wie erwartet verschwunden.

Die Paketverwaltung verschwindet, weil sich die Composer Extension quasi "selbst löscht".

Nach dem reparieren der Composer Extension löscht sich die Composer Extension wahrscheinlich deshalb nicht mehr von selbst, weil Composer glaubt, dass bereits die neueste Version installiert ist (weil über das ER2 "manuell" die alten Daten wiederhergestellt wurden - die Info, dass ein update auf die neueste Version gemacht wurde, aber weiter bestehen bleibt).


Meine Vermutung ist, dass auch bei dir weiterhin ein Package Update zu diesem Fehler führen wird. Du solltest dich also nicht darauf verlassen - ansonsten "verlierst" du vielleicht Extensions bzw. nur Teile davon, ohne es zu merken.

[mlweb]

Du musst nicht darauf warten, du kannst ja explizit eine gewisse Version verlangen. Angenommen eine Extension hat die Versionen 1.1. und 1.2. verfügbar. Du markierst 1.1. zur Installation und wählst aus, dass nur die exakte Version installiert werden soll. Nach der installation setzt du es auf 1.2. und führst wieder "Update Packages" aus.

Danke für die Info. Dieses Dropdownfeld habe ich doch glatt nicht ernst genommen.
Hatte jetzt auch den Effekt, dass dann die Ordnerstruktur noch da ist aber keine Dateien mehr.
Habe dann noch ein bisschen gespielt. Downgrade auf eine andere Version. Upgrade auf eine weitere Version, aber nicht auf die aktuellste. Dann nochmal update auf die neuste Version, wieder downgraden usw.
Manchmal wurden neue Dateien eingefügt. Manchmal war nur die Ordnerstruktur da. Werde morgen noch einmal versuchen herauszubekommen unter welchen Umständen es zu funktionieren scheint und wann es Probleme gibt. Auf jeden Fall wurden bei mir immer dann, wenn auch die Dateien eingefügt wurden die zu aktualisierenden Datenbanktabellen in blauer Farbe angezeigt, ansonsten in rot.

Maren

[mlweb]

Auf jeden Fall wurden bei mir immer dann, wenn auch die Dateien eingefügt wurden die zu aktualisierenden Datenbanktabellen in blauer Farbe angezeigt, ansonsten in rot.

Brett vorm Kopf - ist eigentlich logisch, wenn er die Dateien der Extension löscht, werden auch die nicht mehr benötigten Datenbanktabellen gelöscht.

Heute morgen gab es dann auch ein Update des composers und schwups war die Paketverwaltung wieder weg.

Habe dann noch einmal getestet mit den Erweiterungen easy_themes und m17-sticky-backend-footer.
Installiere ich eine ältere Version als exakte Version und führe ein Update z.B. auf eine exakte Version durch werden alle Dateien gelöscht. Verändere ich danach noch einmal von exakter Version auf Bugfix Release werden die Dateien geschrieben. Führe ich danach ein Downgrade auf eine ältere Version aus sind wieder alle Dateien weg.
Dateien geschrieben werden also nur dann, wenn der Ordner bis auf die Struktur leer ist oder gar nicht vorhanden. Damit bestätigt sich das was Spooky schon festgestellt hat. Packages installieren funktioniert, updaten funktioniert nicht (vollkommen unabhängig davon, ob die localconfig oder die initconfig verändert wurde).
Im Moment bin ich mit meinem Latein am Ende. Werde jetzt erst mal bei meinem Hoster eine Testversion einrichten und dort weiter probieren.

[mlweb]

Heute erneut Composer mit Windows7 und XAMPP getestet.
Der Fehler, der beim letzten Test auftrat - Modulordner verschwinden beim Update - ist nicht mehr vorhanden.
Weitere echte Fehler des Composers sind mir beim Test nicht aufgefallen. Hier ein kurzer Testbericht.
Testumgebung

• Betriebssystem: Windows 7 (64Bit)
• XAMPP: 1.8.3
• PHP: 5.5.1
• Contao: 3.4.0 jungfräuliche Installation

Installation Composer

• Installation ohne Fehlermeldung
• Migration dauert zwar ein Weilchen aber auch das ohne Fehlermeldung

Erweiterungen installieren und Upgrade/Downgrade testeneasy_themes

• aktuellste Version 2.0.7.9017 (contao-legacy) installiert
• Upgrade auf 2.0.8 (terminal42)
• sowohl Version 2.0.7 (contao-legacy) als auch Version 2.0.8 (terminal42) werden in der Paketverwaltung aufgeführt
  
  easy_themes_1.png
• Kontrolle Ordnerstruktur - nur ein Modulordner vorhanden
• Paket von contao legacy einfach entfernt
• scheinbar alles ok
• Downgrade auf Version 2.0.7 /terminal 42) und erneutes Upgrade ebenfalls ohne Probleme

rocksolid-slider

• exakte Version 1.3.2.9003 installiert (contao legacy)
• Upgrade auf Version 1.3.3.9003 erfolgreich (contao legacy)
• Upgrade auf Version 1.3.3 (madeyourday) erfolgreich, aber wie schon bei easy_themes bleiben beide Versionen in der Paketverwaltung erhalten
  
  rocksolid_slider_1.png
• nach dem Löschen des Paketes von contao-legacy wird hier allerdings das gesamte Modul entfernt
• Neuinstallation von Version 1.3.2 (madeyourday) und anschließendes Upgrade auf Version 1.3.3 verlaufen problemlos

metamodel/core (dev-contao3)

• Installation einer Erweiterung mit Abhängigkeiten
• Installation mit einem Hinweis
  
  metamodels_1.png
• leider wurde die empfohlene Version (contao-community-alliance/dc-genaral) im Composer nicht gefunden, möglicherweise noch nicht kompatibel mit Contao 3.4

Insgesamt also keine Probleme, sondern eher Schönheitsfehler. Danke an diese Stelle noch mal an die Entwickler.

[Spooky]

Hab' auch gleich mal wieder einen Test gemacht, zuerst folgendes:

• Windows 7 x64
• XAMPP 1.8.3
• PHP 5.5.11
• Contao 3.4.0
• composer-client 0.15.1

Installation und auch Update eines Packages lief ohne Probleme, also der beschriebene Fehler (dass aktualisierte Dateien in system/modules gelöscht statt aktualisiert werden) trat nicht auf.


Dann noch folgendes mit einer bestehenden Contao installation, wo auch nur der composer-client 0.14.0 installiert war:

• Windows 7 x64
• XAMPP 1.8.3
• PHP 5.5.11
• Contao 3.2.16
• composer-client 0.14.0

Auch hier verlief das Package update, mit sehr vielen packages, ohne Probleme. Soweit ich es analysiert habe, wurde nichts (falsches) aus den system/modules Verzeichnissen gelöscht . Funktionierte also scheinbar schon mit dem composer-client 0.14.0

[Zero]

Wie sind denn eure Composer Einstellungen?

[mlweb]

Habe nach der Installation von Composer im Migrationsassistenten "Für den produktiven Einsatz" ausgewählt gelassen und auch später keine Veränderungen vorgenommen.
Hier die Einstellungen:
composer_2.png

[mlweb]

@Spooky
Nach dem ich gesehen habe, dass Du die composer-client 0.15.1 benutzt habe ich gleich mal versucht den Composer zu aktualisieren. Das hat bei mir leider nicht geklappt.

Fehlermeldung:

[08-Dec-2014 21:58:41 Europe/Berlin] PHP Fatal error: Uncaught exception 'Exception' with message 'SSL certificate problem: unable to get local issuer certificate' thrown in C:\xampp\htdocs\_contao_test\system\modules\!composer\src\Downloader.php on line 119
#0 C:\xampp\htdocs\_contao_test\system\modules\!composer\src\Downloader.php(24): ContaoCommunityAlliance\Contao\Composer\Downloader::curlDownload('https://getcomp...', 'C:\xampp\htdocs...')
#1 C:\xampp\htdocs\_contao_test\system\modules\!composer\src\Runtime.php(169): ContaoCommunityAlliance\Contao\Composer\Downloader::download('https://getcomp...', 'C:\xampp\htdocs...')
#2 C:\xampp\htdocs\_contao_test\system\modules\!composer\src\ClientBackend.php(285): ContaoCommunityAlliance\Contao\Composer\Runtime::updateComposer()
#3 C:\xampp\htdocs\_contao_test\system\modules\!composer\src\ClientBackend.php(125): ContaoCommunityAlliance\Contao\Composer\ClientBackend->loadComposer()
#4 C:\xampp\htdocs\_contao_test\system\modules\core\classes\Backend.php(415): ContaoCommunityAlliance\Contao\Composer\ClientBackend->generate()
#5 C:\xampp\htdocs\_contao_test\system\modules\core\controllers\BackendMain.php(135): Contao\Backend->getBackendModule('composer')
#6 C:\xampp\htdocs\_contao_test\contao\main.php(22): Contao\BackendMain->run()
#7 {main}

Wenn ich das richtig verstehe, gibt es Probleme mit einem Zertifikat. Und da schlagen Sie wieder zu meine mangelden Kenntnisse der Serveradministration.
Habe in Google gerade recherchiert, dass man die Zertifikatliste aktualisieren soll.
Muß ich mir mal in Ruhe anschauen.
Tips der Spezialisten auch gern willkommen.

[Spooky]

Da musst du einfach folgendes machen: http://stackoverflow.com/a/16495053/374996

[mlweb]

Danke hat wunderbar geklappt.
Hatte gerade auch schon einiges unter Google gefunden, aber nichts war so eindeutig wie Dein Link. Klasse.

Schönen Abend noch

[Ainschy]

Hier befindet sich eine deutsche Anleitung zum SSL Zertifikat unter Windows XAMPP:

http://christ.media/ssl-certificate-...ificate-howto/