Ok.Zitat:
Zitat von webhebamme
Du könntest jetzt noch PHP 7.1 und 7.2 versuchen; vermute aber das das auch nicht hilft…
Ggf. dem Hoster den Link auf den Manager schicken, Zugangsdaten und dann gibt es hoffentlich Hilfe…
Druckbare Version
Ok.Zitat:
Zitat von webhebamme
Du könntest jetzt noch PHP 7.1 und 7.2 versuchen; vermute aber das das auch nicht hilft…
Ggf. dem Hoster den Link auf den Manager schicken, Zugangsdaten und dann gibt es hoffentlich Hilfe…
Ich bin mein eigener Hoster, weiß also nicht ob sich das lohnt weil ich nicht untervermiete;)
Wenn ihr das wollt aber gerne.
Meine Serverjungs die ich angeschrieben habe verweisen auf die Contaocommunity da die mir mit Sofwarespezifischen Anforderungen nicht weiterhelfen können.
Alles andere machen die aber wenn ich selbst mal nicht weiterkomme.
Nachtrag: Wir haben geschaut was ich an PHP updaten kann. Da ich allerdings erstellte Websiten von 2014 in Contao auf dem Server laufen habe ist bei PHP7.0 bei mir erstmal Schluss. Meine Kunden ziehen bei Updates nicht so mit... Wie ich das in naher Zukunft regeln möchte schau ich mir gerade an.
Falls du ein Argument brauchst :D
Könnte man so interpretieren, man muss eine PHP Version einsetzen zu der es noch mindestens Security Updates gibt. Das wäre bei der 7.0 nur bis zum 3.12.2018.Zitat:
In der DSGVO wird der "Stand der Technik" grundsätzlich bei allen Maßnahmen gefordert, die der Sicherheit der Verarbeitung dienen sollen (Artikel 32 DSGVO).
https://secure.php.net/supported-versions.php
Hallo BugBuster,
ja ich weiß das ich so oder so was tun muss. Letzte Woche wollte ich noch alles in die Tonne treten aber bevor das mache wollte ich mir erstmal anschauen ob ich nicht evt. doch gewuppt bekommen könnte.
Egal den Manager würde ich mir trotzdem gerne mit dem Contao 4 ansehen. Je nachdem wie es mir von der Hand geht wird dann entschieden.
Habt ihr noch ne Idee dazu? Muss ich evt. noch was in der PHP Ini ändern?
Aus einem Ticket:
Zitat:
Wenn der PHP Binärpfad nicht akzeptiert wird, bedeutet dies, dass der PHP-Prozess, auf dem der Contao-Manager läuft, die Binärdatei nicht ausführen kann oder keine erwartete Ausgabe erhält. Stellen Sie sicher, dass die Datei ausführbar und für den Webserver-Benutzer zugänglich ist. Sie können die Ausgabe auch mit debuggen:
Code:/opt/php-7.0/bin/php /path/to/contao-manager.phar.php test
Hmmmm,
die Dateien im angegeben Pfad besitzen die Berechtigungen 755, die darüberliegenden Ordner auch. Oder bin ich nun auf dem Holzweg... grübel, grübel, grübel
Oh Mann ich habe mich schon ganz lange nicht mehr damit auseinandergesetzt....
Konsolenausgabe: Could not open input file: /path/to/contao-manager.phar.php
Schwitz....
So Euch war das schon vorher klar... wie erzähl ich dem jetzt das er doch darf?
Also grundsätzlich ist mir mal aufgefallen, dass dein angegebenes PHP eine cgi-Version ist, also eigentlich nicht für die Konsole gedacht.
Du hast aber schon das "/path/to/contao-manager.phar.php" mit Deinem eigenen Pfad ersetzt?
Gesendet von meinem LG-H815 mit Tapatalk
Nabend,
CGI hab so im Kopf das dies als Schnittstelle dient, weiß also nicht was du mit der konsole meinst.
Ich arbeite nicht gerne mit der Konsole aber wenn es sich nicht vermeiden lässt...
Ja er sagt mir das immer das gleiche. Ich denke ja das es vielleicht doch noch an der PHP ini liegt, aber ich habe echt kein Plan davon. Ich poste mal den Teil
Muss ich hier vielleicht noch was rausnehmen?PHP-Code:open_basedir = "{OPEN_BASEDIR}"
disable_functions = exec,passthru,system,proc_get_status,proc_nice,proc_terminate
Hallo Zusammen.
Nachdem ich gestern Abend mit dem Manager Contao 4.4.18 'updates' durchlaufen liess sind das 'Backend' und das 'Frontend' nicht mehr ansprechbar. Im 'Backend' kann ich einloggen, aber sobald etwas ausgewählt wird springt das System zum Login. Das update lief normal durch. Hat das wiederum mit einem Symfony Fehler zu tun. Niemand kann mehr einloggen.
Was kann ich da tun? Vielen Dank für eine Antwort.
Ja, ist leider wieder ein Symfony Fehler (mehr oder weniger). Siehe https://github.com/contao/core-bundle/issues/1534
Das Problem im Frontend ist aber evt. ein anderes
Spooky vielen Dank.
Die Frage bleibt was soll ich machen? Vielleicht bemühe ich morgen unseren Hoster damit er die ganzen 'files' auf gestern 18:00 Uhr zurückstellt.
Gruss Rolf
Hoffentlich kennt jemand morgen eine Antwort wie der composer.json file geändert werden kann. Nachdem dieses Problem seit 7 Tagen bekannt ist sollte dies möglich sein.
Gruss Rolf
Hilft das nicht was im Ticket steht?
https://github.com/contao/core-bundl...ment-394336748
Hello BugBuster
Meinst Du die Line:
Weiter unten steht dann; man soll die nicht ausschalten.Zitat:
For now a quick "fix" is adding to your composer.json:
"conflict": {
…
"symfony/symfony": "3.4.11|3.3.17"
},
And remove the line
"roave/security-advisories": "dev-master",
From require.
Be sure to revert these changes once Contao got an update.
Edit: If you don't have the line "roave/security-advisories": "dev-master", don't re-add it.
Mit dieser Linie werden x Warnungen ausgespuckt.
Gruss Rolf
Ebenfalls lässt sich der Wartungsmodus nicht mehr aktivieren. Ein Chaos :mad:.
Gruss Rolf
Hallo Spooky, hallo BugBuster
Nochmals vielen Dank.
Nachdem ich die Linie:
gelöscht habe lief der Composer durch und die Webseiten sind wieder erreichbar.Zitat:
"roave/security-advisories": "dev-master",
Ab sofort lasse ich meine Finger für längere Zeit von den 'updates'.
Gehe jetzt schlafen :)
Gruss Rolf
Es ging um den conflict Eintrag. Den solltest du machen.
Spooky ohne den conflict Eintrag wäre der 'update' (downgrade) nicht durchgelaufen. Es ging um um das Streichen von:
Mit dieser Linie funktioniert der 'update' das heisst das 'downloading' nicht.Zitat:
"roave/security-advisories": "dev-master",
Das Hauptproblem ist aber, dass Ihr diesen Fehler schon vor 8 Tagen entdeckt habt und keine Warnung im Forum publiziertet. Unzählige Web Seiten wurden dadurch lahmgelegt. Es zeigt aber auch das Contao mit der Version 4 seine Stabilität verliert. Wir haben ein Sprichwort:
Lieber der Spatz in der Hand, als die Taube auf dem Dach.
Gruss Rolf
Das hat mit deinem ursprünglichen Fehler aber nichts zu tun.Zitat:
Zitat von rwaelty1944
Mir ist dieser Fehler bisher nicht untergekommen. Eine Warnung im Forum macht vielleicht Sinn, ja.Zitat:
Zitat von rwaelty1944
Der Fehler ist erst nach dem 'update' mit dem Manager und danach mit dem Composer aufgetreten. Obwohl alles ohne Fehler durchlief.
Code:Titel: Nach Contao Manager Update Frontend und Backend nicht mehr ansprechbar
Der Fehler tritt nur auf, wenn man eine Contao Version niedriger als 4.4.18 im Einsatz hat, soweit ich das sehe. Man sollte also als conflict zumindest "contao/core-bundle": "<4.4.18" eintragen, damit auf jeden Fall auf Contao 4.4.18 aktualisiert wird.
Ja, aber du sprichst hier von verschiedenen Fehlern ;).Zitat:
Zitat von rwaelty1944
Bei uns läuft Contao 4.4.18
Frontend: Ein 'login' in den geschützten 'frontend' Bereich war nicht mehr möglich. System sprang sofort wieder auf den ungeschützten Bereich. Dort funktionierte alles im 'frontend' (aeropens.ch).
Backend: Login im 'backend' war möglich, aber nach einer Auswahl sprang das System sofort zurück auf die 'login' Seite. Beim nächsten 'login' war die vorherige Auswahl selektiert. Direktwahl (zB. aktivieren des Wartungsmodus) funktionierte nicht mehr.
Was mich in dem Zusammenhang Symfony Unverträglichkeiten mal interessieren würde: Ist Contao momentan für Symfony auch so ein exotischer Anwendungsfall wie das reine Update der json- und lock-Dateien ohne Download der Bundles für Composer? Und falls ja, liegt das daran, dass Contao eben noch nicht in allen Bereichen komplett auf Symfony umgestellt ist? Wird sich das also irgendwann mal legen? Damit meine ich, dass mittlerweile gefühlt jedes zweite Symfony-Update irgendwas in Contao schrottet und verhindert werden muss. Ansonsten würde ich vorschlagen, die Symfony-Version bei jeder Contao-Version defaultmäßig festzupinnen. So wie es ja im Prinzip früher(tm) mit Third-Party Modulen auch - notgedrungen - gemacht worden ist.
Das Problem mit symfony/finder war kein Contao spezifisches Problem.Zitat:
Zitat von tab
Die diversen Probleme mit symfony/security betreffen nur Contao 4.0.x bis 4.4.x, da die Implementation der alten Contao Benutzerauthentifizierung innerhalb von Symfony, sagen wir mal, schwierig war. Diverse Änderungen innerhalb von symfony/security führen in letzter Zeit manchmal zu Probleme, weil Contao diese Komponente teilweise unerwartet benutzt und teilweise werden durch diese Benutzung Fehler bzw. Problematiken in der Komponente aufgezeigt.
Ab Contao 4.5 besteht dieses Problem nicht mehr, weil das System komplett neu geschrieben wurde und sich auf das Symfony Framework stützt.
Also teilweise doch wie vermutet. Da muss ich mir wohl nochmal Gedanken über meine Update-Strategie machen. Aber so wie der Release-Plan aussieht, ist 4.4.x leider relativ alternativlos. Die Ochsentour 4.5->4.6->4.7->4.8->4.9 mag ich mir bestenfalls mit einigen wenigen Installationen antun. Und bei 3.5 zu bleiben bis zum bitteren Ende und zu hoffen, dass danach in 3.5 bis zum Release 4.9 nichts sicherheitskritisches gefunden wird, ist bestenfalls ziemlich riskant. Da wäre ich dann bei einer Sicherheitslücke in 3.5 gezwungen, die ganzen Installationen sehr kurzfristig doch noch auf auf 4.4 oder eventuell 4.8 zu heben, je nachdem wann es passiert. Das wäre dann wohl nicht realistisch leistbar.Zitat:
Zitat von Spooky
Ich habe festgestellt das mit Aufkommen der 4er Releases seltsamerweise die meisten Kunden mit 2.9 Installationen sich mittlerweile zumindest für ein 3.5er Update bereit erklären ( die sich zuvor aus Kosten Gründen bisher geweigert hatten ) nicht zuletzt auch aufgrund der aktuellen PHP Versionen. In diesem Zusammenhang versuche ich - sofern im Provider Umfeld möglich - dann auch gleich ein 4.4er LTS durchzusetzen. Also zunächst von 2.9.x ->3.5.x und dann auf die LTS. Zumeist ist dies ohne Probleme möglich da ich größtenteils auf Erweiterungen verzichtet o. zumindest nur die gängigen/gut gepflegten Erweiterungen herangezogen hatte. In der Hoffnung das später ein Update von 4.4.x auf 4.5.x ähnlich unproblematisch sein wird.Zitat:
Zitat von tab
Und bezüglich
Bitte nicht als Kritik verstehen - wenn ich beispielsweise Toflars Beitrag aus https://github.com/contao/core-bundle/issues/1492 lese:Zitat:
Nicht alle verfolgen die diversen Github Threads oder spezifische Lösungen die hier im Forum gegeben werden
welcher hierzu führt:Zitat:
After 5h of debugging together with @aschempp, I think we found the source of the problem in Symfony. Here we go: symfony/symfony#27309
https://github.com/symfony/symfony/pull/27309 ist die Leistung schon beeindruckend (auch wenn ich kein Wort verstehe :-) )
Nachdem ich es nun endlich geschafft habe hier die Ausgabe der Console:Zitat:
Zitat von BugBuster
Könnt ihr mir nun bitte weiterhelfen?Code:{"version":"7.0.7","version_id":70007,"sapi":"cli"}root@1a-8767:~#
Diese Ausgabe kannst Du jetzt hier im Ticket posten: https://github.com/contao/contao-manager/issues/266
Hallo xchs,
hatte ich gestern abend noch gemacht. Heute ist das Ticket geschlossen worden.
Ich hoffe ich durfte dies hier zitieren. Ich versuche mich an alle Regeln zu halten aber langsam weiß ich nicht wo ihr was haben möchtet/braucht. Mir hat das bisher noch nicht weitergeholfen.Zitat:
Bitte wiedereröffnen falls es sich um einen Bug handelt. Support ansonsten wie von @xchs bereits erwähnt im Forum.
Ich bitte um weitere Anweisungen. Dankeschön
Klar darfst Du das hier ebenfalls zitieren! Kein Problem.
Hast Du schon die aktuelle Version 1.0.0 des Contao Managers probiert?
Meine installierte Version ist Contao Manager 1.0.0-beta19
Heute ist die stabile Version 1.0.0 veröffentlicht worden. Du solltest also ein Update auf diese Version durchführen.
Ich habe die neue Version installiert habe aber das gleiche Problem.
Es geht um die Domain webhebamme.de oder? Derzeit scheint der DocumentRoot nicht korrekt gesetzt zu sein und auch das Directory Listing sollte deaktiviert werden.
Habe es unter http://contao4.4.webhebamme.de.
Werde das Directory Listing ausschalten.
Anhang 20940
Hi,
teste meine erste Installtion (4.5) mit dem Cloud-Resolver (V 1.3.1) ... wie lange dauern die Auflösungen? bei mir läuft die Sache schon seit über 12 Minuten...?
... hmmm Button "Abbrechen" ist disabled..?Zitat:
Resolving dependencies using Composer Cloud
Job ID 5b1a3782a3b453.93530347 is running for 1435 seconds
... uff: Neuladen des Managers bringt mich immer wieder auf die Cloud-Resolver-Anzeige - wie kann ich die Sache abschießen :( ?
Das läuft vermutlich gar nicht mehr wirklich. Ich habe bei den selben Symptomen, nachdem ich ohne Erfolg sogar den Apache gekillt hatte :rolleyes:, einfach im Verzeichnis Contao-Manager die ganzen Task/TensideTask json-Dateien gelöscht, bs auf die background-process.get.json und background-process.set.json, dabei muss ich wohl den/die Übeltäter erwischt haben und der Contao-Manager verhielt sich dann wieder normal. Natürlich kann man auch das ganze contao-manager Verzeichnis löschen, dann muss man halt wieder den Zugang neu einrichten und die Einstellungen nötigenfalls neu machen.
uff... Danke schonmal!
nach ca. 25 min hat sich der Task allein beendet - in der anschließenden Übersicht des CM war "Composer-Umgebung" nicht mehr grün sondern gelb mit Button "installieren" und "Contao-Installation" zeigte einen Spinner...
/contao-manger komplett gelöscht und neu ausgeführt
Aus Leo's Keynote zum CM inkl. dem "Composer Cloud Resolver":Zitat:
Zitat von zonky
https://leofeyer.github.io/konferenz-2018/#84
bzw.
https://leofeyer.github.io/konferenz-2018/#85 (weitere Angaben mit [SPACE])
Da bel. skalierbar wird da evtl. noch aufgeforstet - sicher auch abhängig von den Finanzierungsmöglichkeiten für diesen Service ...
Ich habe gestern zwei Sites auf CM 1.0.0. upgedatet. Das Paketaktualisiern hat aber nur auf dem Server funktioniert (Webgo Business Paket), nicht über die Cloud. Lag das daran, dass gestern zu viel Traffic, zu viele Updates und zu wenig 'Worker' zur Verfügung standen?
Danke, Michael
wenn zu viele Worker, sollte eine Meldung kommen - ggf. man ich an Position 200 von 500 ;-)
aber das Abbrechen sollte auf alle Fälle funktionieren!
wenn die Kapazitäten noch nicht ausreichen, ist es sicher Kontraproduktiv den Cloud-Resolver als Default zu aktivieren
Das wird sicher wieder heiß diskutiert werden.Zitat:
Zitat von zonky
Default ON - gedacht sicher damit es in jedem Fall funktioniert :-)
Bei Hostern die keine Probleme bereiten sollte man den Service deaktivieren - auch um da fairerweise Ressourcen zu sparen ...
Super finde ich auf jeden Fall die neue Lösung um explizit NUR einzelne Pakete zu aktualisieren ...
Nachtrag: Ich hatte es gestern direkt auf einem 1&1 Kundenaccount zum Test angestoßen - lief super durch. Und das ist schon eine beachtlicher Schritt meiner Meinung nach ...
Warten wir mal ab. Eine "persönliche" Job-Übersicht wäre evtl. aus UI Sicht sicher sinnvoll anstatt den jeweiligen Job nach einer best. Zeit einfach autom. zu beenden (o. zumindest manuell abbrechen zu können). Da bin ich aber technisch raus ( Derartige Infos benötigen/binden ja auch sicher wieder Ressourcen ).Zitat:
Zitat von zonky
@webhebamme Hast Du in der Contao Manager Serverkonfiguration den korrekten Pfad zur PHP-CLI Binary eingetragen?
Um welchen Hoster handelt es sich eigentlich? So wie ich es verstanden habe kommst Du ja via SSH auf die Console. Und egal wo Du Dich dann befindest (cd~ o. pwd) sollte man ja mit:Zitat:
Zitat von xchs
eine gültige PHP Info erhalten. Wenn nicht stimmt der CLI Pfad einfach nicht - dann bitte beim Hoster nachfragen ...Code:/opt/php-7.0/bin/php -v
Habe eben eine Version 4.4.18 auf 4.5.8 upgedated.
Hoster 1&1 Paket 1&1 Basic.
Ist problemlos durchgelaufen.
ggf. per Default aus und wenn memory limit erreicht (sollte sich aus der Meldung gaben lassen) Fall-Back-Versuch per Cloud-ResolverZitat:
Zitat von Franko
Legt Tickets an unter contao-manager mit euren Wünschen!
Meine Frage:
Sind mit dem CM 1.0.0. auch die letzten Symfony Probleme für Contao 4.4.18 gelöst?
Nein, das Eine hat mit dem Anderen nichts zu tun.
Vielen Dank xchs für die Antwort.
Zweiter Versuch: nach Install von Contao über die Console nun ein Update: das ging...
Und wie hier zu lesen ist - Weitere Infos direkt von toflar:
https://medium.com/@yanick.witschi/c...r-e64254f5728e
Guten Morgen,
ich wollte gerade meine Contao-Installation auf Version 4.4.29 aktualisieren. Aber im Contao-Manager habe ich nur die Version 4.4.28.
Ein klick auf Paket aktualisieren bringt keine Änderung. Habe ich da was übersehen?
Markiere alle Contao Pakete (inkl. "Contao Open Source CMS") für ein Update und führe dann eine Paket Aktualisierung durch.
ok, jetzt ist durchgelaufen.
Vielen Dank.
(Beitrag in dieses Unterforum verschoben)
Kämpfe seit mehreren Stunden mit einer nicht mehr funktionierenden Contao 4.4.23 Installation, die ich nach einem Contao-Manager Update, auf die aktuelle Version (4.4.29) updaten wollte.
Das Update der Pakete brach mit einer Fehlermeldung ab. Ein Reparaturversuch über die neue Wiederherstellungskonsole schlug ebenfalls fehl.
Versuche ich im abgesicherten Modus die Pakete einzeln upzudaten, erhalte ich immer folgenden Fehler:
Die gesuchte Version (contao-components/tablesorter-2.0.5.7) gibt es laut packagist.org jedoch gar nicht.Code:In DownloadManager.php line 156:
Package contao-components/tablesorter-2.0.5.7 seems not been installed properly
install [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--no-custom-installers] [--no-autoloader] [--no-scripts] [--no-progress] [--no-suggest] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--ignore-platform-reqs] [--] [<packages>]...
# Process terminated with exit code 1
# Result: General error
---
### The background task has stopped unexpectedly. ###
Den gleichen Fehler erhalte ich, wenn ich die Composer Abhängigkeiten neu installieren will.
Beim Leeren und Neuerstellen des Anwendungs-Cache kommt folgende Fehlermeldung:
Stehe z.Zt. völlig auf dem Schlauch.Code:In BundleConfig.php line 151:
The Symfony bundle "Sensio\Bundle\FrameworkExtraBundle\SensioFrameworkExtraBundle" does not exist.
Ein Update auf die Contao-Manager Version 1.1.1 brachte auch nichts.
Hast Du Zugriff auf eine Konsole / SSH-Zugang? Dann dort ins contao-root (Ordner in dem sich der Ordner web/ befindet) und einprobieren. Poste bitte die Ausgabe.Code:composer update --dry-run --no-dev
Ausserdem poste bitte mal Deine composer.json, ebenfalls aus dem contao-root.
Glaube das Problem gefunden zu haben.
In der composer.json gab es einen scheinbar fehlerhaften php-Eintrag:
"require": {
"php": "^5.6.0",
nach der Änderung in:
"require": {
"php": "^5.6|^7.0",
lief der Reparatur-Assistent durch und hat alle Pakete neu runtergeladen.
Danach war die Seite wieder erreichbar.
Jetzt muss ich noch die sonstigen Pakete updaten. Hoffe das geht problemlos.
Trotzdem danke für die Ratschläge.
Zitat:
Zitat von BugBuster
Inzwischen sind ja ein paar Tage vergangen und mittlerweile gibt's die Composer-Cloud. Jedenfalls habe ich jetzt keine Probleme mehr beim Updaten von Contao samt Erweiterungen mit dem Contao-Manager in einem DomainFactory ManagedHostingProfesional-Paket (PHP 7.1).
(Was ist leider nicht oder nicht auf Anhieb finden konnte, waren Infos über die Angaben in den Versionsfeldern des CM und in welcher Reihenfolge der Core, die Bundles und Erweiterungen aktualisiert werden sollten/müssen bzw. dass alles fürs Update markiert werden muss.)
Am besten einfach ganz oben über den Button "Pakete aktualisieren" alle Pakete gleichzeitig aktualisieren lassen.
Moin
Mal eine Frage wie ist es aktuell mit dem CM unter Windows gibt es Neuigkeiten da zu?
Grus sascha
@Sascha1378
es gibt einen Editierbutton zum Überarbeiten Deines Textes... bitte denSatzText 1x selbst laut vorlesen... ;-)
@Sascha1378 Nein, nichts Neues. Der Contao Manager funktioniert nach wie vor.
jezt auch unter WINDOWS ? den Laut Webseite geht der noch nicht unter Win...Zitat:
Zitat von xchs
Grus sascha
Der Contao Manager funktioniert schon eine ganze Weile unter Windows. Laut welcher Website sollte denn das nicht der Fall sein?