Passwort neu setzen ohne Löschen von .env hat funktioniert und jetzt klappt auch die Verbindung. Wer weiss wo ich mich da vertippt habe oder welchen Grund das Ganze auch immer hatte.
Druckbare Version
Passwort neu setzen ohne Löschen von .env hat funktioniert und jetzt klappt auch die Verbindung. Wer weiss wo ich mich da vertippt habe oder welchen Grund das Ganze auch immer hatte.
Hm, heute habe ich auf Server 124 schon wieder Probleme mit der app_dev.php. Obwohl eine .env Datei vorhanden ist, wird mir vom Apache kein HTTP Auth Response geliefert (sehe also immer nur "You are not allowed to access this file. Check app_dev.php for more information.").
// nvm, war ein Fehler in einer PHP Datei von mir... Leerzeichen vor dem <?php -_-
Musste zwar das Passwort neu setzen, da ich es vermutlich vergessen hatte, aber danach ging es problemlos bei mir auf Server 124.
Das Update von 4.4.1 auf 4.4.2 mit dem Contao-Manager lief jetzt auch komplett ohne Fehlermeldungen durch. Fast noch einfacher als EasyUpdate3 ;)
Bei mir auch. Was mir aufgefallen ist:
Beim ersten Aufruf von example.org/contao-manager.phar.php war dort in der Konsole nichts zu sehen. Habe die Seite dann nochmal neu geladen, dann kam dort die Ausgabe (plus einige Fehlermeldungen die Servereinstellungen betreffend).
Nach Fertigstellung stand dort bei Contao immer noch Version 4.4.1. Erst nach Neuladen der Seite sah ich dort 4.4.2.
Was noch fehlt wäre eine visuelle Anzeige der letzten Updates. easy_themes ist z.B. mit geupt worden und funktioniert jetzt auch perfekt.
Muss man die contao-manager.phar.php (contao-manager.phar) eigentlich auch mal erneuern, oder macht sie das selber?
Der Server stand auf PHP-5.6 (weils meine Spielwiese ist und momentan noch nicht per Domain geht).
Bei mir hat der Manager (=contao-manager.phar.php) gleich beim Aufruf ein Update von Beta8 auf Beta10 gemacht. Das mit dem Neuladen der Seite war bei mir auch so. Hatte mich gewundert, dass im Backend 4.4.2 steht und im Manager immer noch 4.4.1. Seite neu laden hilft, sollte aber besser automatisch gehen.
Der Manager updatet sich selbst zumindestens wenn Du mit einer Beta-Version begonnen hast (ich glaube 1xpro Stunde). Nur die ersten Alpha-Versionen hatten das nicht gemacht.
Im Moment sollte Dein Manager Beta 10 zeigen (ist heute kurz nach dem Mittag veröffentlicht worden).
Ah, danke, gut zu wissen, dass er sich updatet, das ist ja praktisch. Stand wahrscheinlich auch in der Konsole (grüner Text), aber ich habe da nicht alles gelesen. Steht jetzt auf 1.0.0-beta10.
Ich habe beim Support nochmal nachgefragt:
Hier die Antwort (genehmigt vom Verfasser):Zitat:
Hallo liebes webgo Team,
ich muss nochmal nachfragen, wann wir die Möglichkeit bekommen, die PHP-Versionen per Domain einzustellen. Es pressiert etwas und andere Entwickler warten auch darauf. Vor allem, weil wir ja zur Zeit zwischen PHP 5.6 und 7.x hängen. Letztes Jahr hieß es, dass es Anfang dieses Jahres kommen sollte.
Liebe Grüße ...
Lassen wir uns also mal überraschen :)Zitat:
Sehr geehrter Herr ...,
vielen Dank für Ihre E-Mail.
Einen Termin für das neue System und die damit verbundene Neuerung im Bezug auf die PHP Versionen, können wir aktuell leider noch nicht nennen. Die Entwicklung läuft jedoch auf Hochtouren.
Um eine optimale Benutzerfreundlichkeit und hohe Zuverlässigkeit des neuen Systems zu gewährleisten, investieren wir viel Kraft und Zeit in die Entwicklung, wobei wir weitere Kundenwünsche aufgenommen haben, die zu einer Verlängerung der Entwicklungszeit führten.
Aus diesem Grund dauert die Entwicklung noch an. Wir haben sehr gute Ideen entwickelt und sind überzeugt, dass Sie (und alle anderen webgo Kunden) von dem neuen Kundenportal begeistert sein werden. Es wird dann ein komplett neues Layout geben und auch viele neue und interessante Funktionen und Erweiterungen.
Sollte es für Sie unerlässlich sein die PHP Versionen individuell anpassen zu können, empfehlen wir Ihnen einen vServer zu buchen. In Froxlor können Sie die gewünschte PHP Version pro Kunde einstellen.
Falls noch Fragen auftreten sollten, können Sie sich jederzeit wieder an uns wenden. Wir schauen uns das dann gerne für Sie an.
Ich wünsche Ihnen noch einen schönen Tag.
Für Fragen und Anregungen stehen wir Ihnen gerne zur Verfügung.
Antworten Sie bitte einfach auf diese E-Mail, ohne den Betreff zu ändern.
Mit freundlichen Grüßen ...
Ich habe zwei kleine kleine Projekte, die ich mit Contao 4 umsetzen wollte, da sie beide keinen großen Schnickschack benötigen und sich daher quasi gut für den Umstieg eignen würden.
Beide haben das gleiche Paket (goPaket Silver) - beide Installationen habe ich nacheinander durchgeführt.
Seite 1
Die Installation und auch die (spätere) Installation von Erweiterungen liefen mit dem Contao Manager problemlos.
Ich hatte beim Einfügen von Bildern immer mal wieder die Fehlermeldung "Bad Gateway 502 nginx" im Frontend - einmal sogar im Backend, sobald ich einen bestimmten Artikel bearbeiten wollte - zum Glück ging es nach ein paar Aktualisierungen des Browsers wieder von alleine.
Die Frage hier: wie bekomme ich das ganze stabiler und woran liegt es?
Contao 4.4.2 - PHP7.1 - MySQL DB
Seite 2
Installation lief genauso - heute will ich nun die Erweiterungen installieren ... allerdings komme ich hier nicht weiter.
Bei jeder Erweiterung kommt folgende Fehlermeldung:
Process terminated with exit code 255
Reason: Unknown error
Contao 4.4.2 - MySQL DB - PHP-Versionen habe ich von 5.6, 7.0 und 7.1 durchgetestet (ob das nun klug war, weiß ich nicht - aber es war das erste Rädchen, an dem ich versuchen konnte zu drehen) ;)
Meine 3.5-LTS Projekte laufen bei Webgo super - von daher weiß ich nicht, ob ich was verkehrt gemacht habe, die 4er-Version einfach noch ein wenig Schluckauf hat oder ich ein anderes Paket wählen müsste :)
Schau mal in die contao-manager/manager.json. Wenn du die PHP-Version umstellst, dann muss da bestimmt auch immer der entsprechende Wert drin stehen. Beispiel:
Vielleicht Testweise mal mit ner MariaDB probieren.Code:"php_cli": "\/usr\/bin\/php70",
Perfekt!
Vielen Dank - das war es. Jetzt lassen sich die Erweiterungen wieder installieren :)
Was war es denn? MariaDB oder "php_cli"?
"php_cli" musste angepasst werden ;)
Ah, das ist gut, dass es nicht die DB war.
Auf dem Server s131 funktionieren momentan keine SSL Verbindungen. zB:Code:# wget https://getcomposer.org/download/1.5.2/composer.phar
converted 'https://getcomposer.org/download/1.5.2/composer.phar' (ANSI_X3.4-1968) -> 'https://getcomposer.org/download/1.5.2/composer.phar' (UTF-8)
--2017-09-13 19:16:17-- https://getcomposer.org/download/1.5.2/composer.phar
Resolving getcomposer.org (getcomposer.org)... 87.98.253.108, 2001:41d0:a:7b19::2
Connecting to getcomposer.org (getcomposer.org)|87.98.253.108|:443... connected.
ERROR: The certificate of 'getcomposer.org' is not trusted.
ERROR: The certificate of 'getcomposer.org' hasn't got a known issuer.
Darüberhinaus ist kein vi verfügbar:Code:# /usr/bin/php71 composer.phar update --prefer-dist --no-dev --optimize-autoloader
Loading composer repositories with package information
[Composer\Downloader\TransportException]
The "https://packagist.org/packages.json" file could not be downloaded: SSL operation failed with code 1. OpenSS
L Error messages:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Failed to enable crypto
failed to open stream: operation failed
Code:# vi composer.json
-shell: vi: command not found
Ist nun gefixed :)
Das Problem bestand wohl nur bei einem Teil der Server oder diesem speziellen Server. Server 124 und 129 hatten jedenfalls dieses Problem nicht. Allmählich entdecke ich immer wieder Dinge, die bei 1&1 geklemmt haben und jetzt plötzlich richtig funktionieren. Zum Beispiel der E-Mail Versand per SMTP. Bei 1&1 musste man einen speziellen SMTP-Server benutzen, also einen anderen als mit dem Mail-Client. Dieser hat SSL nicht unterstützt und war ar***langsam :rolleyes:. Die Weiterleitungsseite kam erst nach einer gefühlten halben Minute, unglaublich. Deswegen hatte ich SMTP deaktiviert, was wegen Spamfiltern gelegentlich auch nicht ganz unproblematisch sein kann. Jetzt, nach dem Umzug des Kunden, klappt das Senden per SMTP und SSL problemlos, die Weiterleitungsseite kommt praktisch sofort.
ja schon klar, das war mir bewusst ;). Wir haben auch noch einige anderer Server bei webgo wo das Problem nicht besteht (oder bereits behoben wurde).Zitat:
Zitat von tab
Was war denn das Problem? Ein Unix ohne vi ist ja fast nicht vorstellbar :D.
Naja, der Pfad zur vi executable muss für den jeweiligen Benutzer in der Umgebung eingetragen sein. Das war wohl nicht der Fall.
Zur Zeit ist das Zertifikat für *.goserver.host abgelaufen ...
Eigentlich peinlich. Aber jetzt scheint’s erneuert worden zu sein …
Ja, jedenfalls ist mein Email-Client jetzt wieder zufrieden :):D
Auf Server s131 noch nicht.Zitat:
Zitat von amateur
In der E-Mail, die ich schon vor 11 Uhr auf meine Anfrage erhalten habe, steht u.a.:
Wenn also das Problem auf deinem Server noch besteht, würde ich empfehlen das zu melden bei webgo. Denn dann ist dein Server bei der manuellen Verlängerungsaktion möglicherweise "übersehen" worden. Bei mir und meinen Kunden ging es jedenfalls bereits wieder, schon bevor die E-Mail bei mir eintraf. Und ich habe die Kundenserver bei meiner Anfrage nicht explizit erwähnt, so dass sie eigentlich nur "meinen" Server kennen konnten.Zitat:
Leider ist es beim automatischen Verlängern der SSL-Zertifikate für vereinzelte Server zu einem Fehler gekommen. Die Technik konnte dies bereits nachhaltig lösen und die Zertifikate manuell verlängern. Der E-Mail Verkehr ist wieder wie gewohnt möglich und auch der Webspace Admin ist in Kürze wieder erreichbar. Sollte Ihr E-Mail Client noch Fehlermeldungen ausgeben, hilft ein Neustart des Programms bzw. Handys um das Problem zu lösen.
Sorry - ich noch einmal :(
Ich hoffe, ich bin in diesem Thread richtig - so ganz weiß ich nicht genau, auf welcher Baustelle ich mich nun befinde.
Das zuvor beschriebene Projekt geht gerade weiter. Ich benötige jetzt die Erweiterung "contao-calendar-ical-bundle".
Die Contao-Version ist inzwischen bei 4.4.5 - PHP läuft mit 7.0
Bei der Installation mit dem Manager bekomme ich als Fehlermeldung:
#11 /home/www/domainname.de/contao-4-x/web/contao-manager.phar.php(55): require('phar:///home/ww...')
#12 {main}
--------------------------------------------------------
Process terminated with exit code 1
Reason: General error
Wie mache ich an dieser Stelle weiter?
Hier gab es ein ähnliches Problem - https://community.contao.org/de/show...with+exit+code - aber so wie ich den Verlauf verstanden habe, war es letztendlich hosterbezoges Problem ... ??
Du hast die eigentliche Fehlermeldung nicht gepostet.
Sorry - Vielleicht war Fehlermeldung der falsche Begriff. :(
Bei der Installation durch den Manager bricht diese irgendwann ab mit der Meldung:
Konsolentask beendet!
Der Hintergrundprozess wurde abgebrochen oder unerwartet beendet. Bitte prüfen Sie das Konsolenprotokoll.
Und am Ende in der Konsole steht eben folgende Meldung:
Process terminated with exit code 1
Reason: General error
Oder ist mit Konsolenprotokoll etwas anderes gemeint?
Du hast von der Fehlermeldung nurgepostet. Da fehlt noch #0 bis #10 des Stack trace und die eigentliche Fehlermeldung (vor #0) ;).Code:#11 /home/www/domainname.de/contao-4-x/web/contao-manager.phar.php(55): require('phar:///home/ww...')
#12 {main}
--------------------------------------------------------
Das Problem liegt an den Sicherheitszertifikaten, die bei Webgo automatisiert sind, aber manchmal einfach nicht eingespielt werden. Gerade auf einem neuen Account gibt es deswegen Probleme und ein Support-Mitarbeiter muss manuell nochmal nachhelfen.
Bin seit kurzen bei Webgo und froh, das es keinerlei Probleme mit Contao 4 gibt und auch alle Features funktionieren.
Oh - vielen Dank für die Geduld.
Ich habe jetzt noch einmal versucht zu installieren, damit ich die komplette Konsolenausgabe einmal rauskopieren konnte - und diese habe ich mir jetzt nochmal angeschaut (das hätte ich auch gleich machen können - aber man lernt ja mit seinen Aufgaben ... )
Ich vermute mal folgende Aussage ist die entscheidende (bevor ich jetzt alles reinkopiere):
[RuntimeException]
Contao Manager Plugin "Craffft\ContaoCalendarICalBundle\ContaoManager\Pl ugin" was not found.
// d.h. das Plugin ist nicht verfügbar und daher läuft die Installation ins Leere?
Scheinbar habe ich mit meiner Aktion noch mehr zerschossen *seufz*
... auf der Manager-Seite ist derzeit folgende Meldung:
ERROR 500 Unknown installation status
Some files were found on your server but no known Contao version could be detected.
You must either manually repair your application or remove the following files and folders to install Contao:
- .gitignore
- README.md
- app
- assets
- composer.json
- composer.lock
- files
- system
- templates
- var
- vendor
Ich habe eben schon im Forum geschaut - da liefen bei den Betroffenen aber trotzdem noch die Live-Seiten. Diese ist bei mir komplett weiß - ebenso kann ich mich nicht ins Backend einloggen.
Ich hoffe echt, das sind gerade persönliche Startschwierigkeiten mit Contao 4 ... :(
Hallo allerseits,
also ich habe gerade ein paar Projekte auf Contao 4.4.8 aktualisiert und es gab keine Probleme, weder mit dem Manager, noch mit den von mir eingesetzten Extensions.
Insofern bin ich sehr zufrieden mit webgo. SSD-Festplatten, SSH, Git, Anpassbarkeit der php.ini, was will man mehr von einem Shared Hosting Paket?
Viele Grüße
Jay
Oops, das Beste habe ich glatt vergessen, den Support.
Keine endlosen Warteschleifen, keine "Ich frage mal in der Technik nach"-Hotline-Dummies, sondern echte Techniker mit Ahnung von der Materie.
Kannst Du mal sagen, was Du bei Webgo für Contao 4 in die parameters.yml eingegeben hast. Mir ist es bis jetzt nicht gelungen SMTP-Versand einzurichten.Zitat:
Zitat von tab
Cache hatte ich natürlich über die Konsole bzw. den Manager nach jeder Änderung gelöscht.
Ich habe das zwar noch nicht probiert, aber mir ist letztens aufgefallen, dass ich bei easybill den Benutzernamen anstatt web42p1 auf web42 einstellen musste.
Ansonsten habe ich im Thunderbird
- Port 465
- SSL/TLS
- Authentifizierung: Passwort normal
In der Hilfe sieht man bei Authentifizierung soll man "Automatisch erkennen" einstellen, das hat mein Thunderbird aber nicht.
Mit normalen Versand hab ich kein Problem. Trage ich allerdings die Daten entsprechend in die parameters.yml ein wird das Kontaktformular nicht versendet. Versand über php Mail funktioniert.
Das muss ich erst mal testen, der Kunde hat bisher nur Contao 3 Websites. Da geht es problemlos mitZitat:
Zitat von mlweb
Also einfach die gleichen Daten die ich auch in Thunderbird oder Windows Live-Mail oder MS Outlook eingebe.Code:SMTP-Hostname: sxxx.goserver.host
SMTP-Benutzername: webyyyp2
SMTP-Passwort: <Das Passwort eben>
SMTP-Verschlüsselung: SSL
SMTP-Portnummer: 465
Hmm, ich hoffe, mein Kunde hat einfach ein wenig Pech. Erst steigt die Downloadzeit in den Crawling-Statistiken durchschnittlich von ca 220ms auf ca 430ms. Und vorhin als ich mir gerade mal eben die SMTP-Einstellungen im Backend ansehen wollte, war das Zertifikat abgelaufen, obwohl automatische Verlängerung angehakt war. Als Laufzeit war im Webspace-Admin der 13.12.2017, also heute, angezeigt. Es besand aber offenbar kein gültiges Zertifikat mehr. Keine Ahnung, ob da ein Mißverständnis zwischen Let's Encrypt und WebGo bzgl. der tatsächlichen Gültigkeitsdauer besteht und das Zertifikat in Wirklichkeit eventuell nur bis zum 12.12.2017 lief und von Webgo heute noch automaisch verlängert worden wäre. Jetzt habe ich es jedenfalls manuell gemacht und alles läuft wieder.
Da werde ich wohl morgen mal den Support auf die beiden Probleme ansprechen müssen, wobei das mit der Downloadzeit auch andere Ursachen haben könnte. Zum Beispiel das Contao-Update auf 3.5.31, der Zeitpunkt des Anstiegs korreliert auffallend gut mit dem Termin des Updates. Hat da sonst noch jemand etwas Ähnliches bemerkt?
Mit mailer_encryption ssl hat es bei mir jetzt auch geklappt. Danke @tab. Ich hatte es wegen dieser Info https://www.e-recht24.de/news/abmahn...abmahnung.html über tls versucht. Bisher habe ich mich für die Kontaktformulare bei den kleinen Seiten meist mit php-Mail zufrieden gegeben.
Gestern Abend hat WebGo bei allen Servern unserer Kunden, die ein Shared Hosting Paket von WebGo benutzen, ohne Vorwarnung die Imagick Extension entfernt :mad:. Das hatte zur Folge, dass alle Contao 4 Installationen plötzlich nicht mehr funktioniert haben - da beim Aufbauen des Symfony Cache registriert wird, welche Bildbearbeitungsbibliothek benutzt wird.
So, bei mir seh ich das auch gerade
"Ein Fehler ist aufgetreten"
Bist du an dem Problem dran?
EDIT: Der Support hat einen System-Check durchgeführt (das kann man auch im Webspace-Admin machen), nun läuft es wieder.
Ja ich habe bei einem Paket seit einiger Zeit auch meine Probleme. Nach einer Serverwartung wegen Performanceproblemen um den 20.01 rum gingen keine Updates mehr. Weder ssh noch Contao-Manager. Auch wenn das im Grund nicht ganz so problematisch ist, man kann es ja manuell auf der eigenen Entwicklungsumgebung machen. Trotzdem hatte ich ausgiebig Kontakt mit dem Support. Gestern nach dem noch einmal etwas umgestellt wurde - was genau erfährt man ja nie - dann auf der Konsole folgende wenig erbauliche Meldung auf der Konsole
Dürfte doch wohl ein Zertifikate Problem sein. Damit ist natürlich auch der manuelle Weg verbaut wenn ich das richtig sehe.Code:The "https://packagist.org/packages.json" file could not be downloaded: SSL operation failed with code 1. OpenSSL Error messages:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed Failed to enable crypto failed to open stream: operation failed https://packagist.org could not be fully loaded, package information was loaded from the local cache and may be out of date
Imagemagick ist bei dem betroffenen Server nicht das Problem aber bei allen anderen Installationen.
Wird es mal wieder Zeit umzuziehen? Die Probleme häufen sich. Leider. :mad:
Ja, die Probleme mit SSL Verbindungen über die Konsole treten immer wieder mal auf den Servern von WebGo auf. Das musst du dem Support sagen, die müssen das fixen. Du kannst ihnen das auch mit einem normalen wget deutlich machen.
Oops, das ist ein absolutes NoGo! Nicht, dass ich das Imagick für alle Kunden unbedingt brauchen würde, die ich eigentlich nach und nach im Zuge des Updates auf Contao 4 nötigenfalls zu Webgo umziehen wollte. Aber einfach so ohne Vorwarnung entfernen, das geht nun wirklich nicht. Ich will mal hoffen, dass das ein einmaliger "Unfall" ist und bald behoben wird.Zitat:
Zitat von Spooky
Habe ich auch schon. Aber es fängt an zu nerven.
Ich habe jetzt bei den Installationen von mir erst mal kurzerhand den Cache neu aufgebaut. Damit laufen die Seiten auch erst mal wieder.Zitat:
Zitat von tl_richard_user
Auf solche Überraschungen kann ich aber auch gern verzichten. :D
Dank @Spooky hat es bei mir anscheinend noch kein Kunde bemerkt.
Ist nach dem Systemcheck Imagick Extension eigentlich wieder da?
Ja, ich bin im Kontakt mit dem Support. Sie prüfen gerade ein globales Roll-Out, damit man nicht selbst überall den System Check anstoßen muss.Zitat:
Zitat von tl_richard_user
Dadurch wird jetzt allerdings nur die GD verwendet. Wenn du wieder die Imagick haben willst, müsstest du den Cache neu aufbauen, sobald Imagick beim Web Prozess und auf der Konsole verfügbar ist. Beim Web Prozess überprüfst du das mit phpinfo();, auf der Konsole zB so:Zitat:
Zitat von mlweb
Da sollte dann "imagick" auftauchen bspw.Code:php71 -m | grep -i magick
Im Web Prozess ja, zumindest bei den Accounts die ich zur Hand habe. Auf der Konsole nicht, das musst der Support fixen. Bzw. das eigentlich Problem war, dass sie zwei verschiedene PHP CLIs hatten: /usr/bin/php71 (das hatte ich immer verwendet) und /usr/bin/php7.1. Letzteres ist die neueste PHP CLI, wo auch Imagick aktiv ist, bei ersterem nicht (mehr) seit gestern. Auf den von mir getesteten Servern sollte /usr/bin/php71 nun auch ein Symlink auf /usr/bin/php7.1 sein.Zitat:
Zitat von mlweb
Schon klar. Ich wollte nur schleunigst die Websiteiten wieder laufen haben, bevor ich Kundenbeschwerden habe.Zitat:
Zitat von Spooky
Ist ja interessant.Zitat:
Zitat von Spooky
Hmm, Chaos pur. So einfach benutzen will ich die /usr/bin/php7.1 erst mal nicht, beim direkten Aufruf kommt da die Warning mit der readline.so. Selbst richten ist also wohl nicht so einfach.
Ja, das hab ich denen eh auch schon gesagt, dass sie das fixen sollen.
Na dann lasse ich sie mal arbeiten, damit die garantierte Zufriedenheit wieder steigt ;).
Habe mal geschaut für 70 ist imagick auch verfügbar. :D
Zum Glück ist bei mir - außer meinem eigenen Webspace - nur mein Versuchskan... ähhh Pilotkunde betroffen. :D
Eigentlich wollte ich dort nächste Woche ein neues Projekt starten.
Also besser diesen Kunden wo anders hosten?
Musst Du letzten Endes selbst entscheiden. Vor Problemen bist Du nirgends sicher Nicky Hoff und ich haben zur Zeit z.B. auch bei Netcup ein etwas merkwürdiges Problem.
Den Hoster wo immer alles funktioniert gibt es m.E. nicht.
Ich habe da durchaus Hoffnungen.
Andererseits sehe ich zu, dass ich nie alle Kunden beim gleichen Hoster habe. Das ist gerade bei den Shared Hostingpaketen etwas aufwendig weil die unterschiedlichen Oberflächen schlichtweg gewöhnungsbedürftig sind, aber damit hat man immer einen Vergleich und ggf. eine schnelle Ausweichmöglichkeit.
Also bisher wurden bei Webgo seit ich da Kunde bin Probleme eigentlich immer zügig gelöst. Ich bin da also erst mal zuversichtlich. Allerdings sollten sich die Probleme nicht unbedingt häufen.
Es wird demnächst eine Stellungnahme dazu geben, wurde mir gesagt. Evt. auch hier im Thread.
Ich hatte das Problem heute morgen auch. Leider hab ich es erst bemerkt, als eine Kundin bei mir angerufen hat :-(
Ich bin gerade erst zu Webgo gewechselt. Ich hoffe doch sehr, dass dies ein einmaliger Ausrutscher war.
Leider hat es mich auch getroffen. In einem neuen Paket konnte erst kein Contao 4 über den Manager installiert werden, Support hat geholfen und irgendwas korrigiert.
Datenbanken importieren geht nur mit Fehlermeldungen und jetzt kann ich mich nicht mehr in das Installtool einloggen.
Könnt Ihr Euch noch in das Installtool einloggen?
Leider lässt mich der Support seit gestern hängen, keine Information auf meine E-Mail! Zum Glück ist das zur Zeit noch die Testinstallation ...
Besonders bedenklich finde ich es, dass WebGo als Contao Premium Partner beim Hosting gelistet ist und es zur Zeit einfach nicht rund läuft.
Welche Probleme hast du aktuell genau? Poste das vielleicht in einen eigenen Thread.
Damit hatte ich bisher noch keine Probleme.Zitat:
Zitat von andre.5tz
Danke, wenn der Support bei WebGo am Arbeiten ist, dann warte ich erst mal bis morgen früh. Wenn es bis dahin nicht klappt, mache ich für die Fehlermeldung mal einen Post auf.Zitat:
Welche Probleme hast du aktuell genau? Poste das vielleicht in einen eigenen Thread.
Liebe Contao Community,
leider kam es bei unseren regelmäßigen PHP-Updates zu einem Fehler. Durch einen Syntax-Fehler innerhalb unserer Routine, wurde die alte Version nicht ersetzt sondern eine neue weitere Version aktiv geschaltet.
Da seit diesem Rollout die PHP-Module an einer zentralen Stelle verwaltet und geladen werden sollen, müssen zusätzlich die globalen für den Kunden nicht änderbaren - php.ini Einträge abgeändert werden.
Da bereits im ersten Schritt die alte Version nicht ersetzt wurde, aber zeitgleich die globalen php.ini verändert wurden (z.B. LoadModule Parameter wurden entfernt) kam es zu dem Phänomen der fehlenden Module (z.B. Imagick).
Ein System-Check behebt in 99% der Fälle dieses Problem, da er automatisch erkennt welche die neuere Version ist und ersetzt die PHP-Version.
Wir haben nun diesen Prozess in einem globalen Rollout auf allen Servern deployed. So gibt es u.a. auch keinen Fehler mehr innerhalb einer SSH-Konsole.
Aktuell wird nur ein PHP-Warning angezeigt. Dieser ist gegenwärtig zu Vernachlässigen. Dieser Fehler wird heute Nacht ebenfalls behoben.
Für etwaige entstandene Unanehmlichkeiten bitten wir vielmals um Entschuldigung.
Bei mir besteht das Problem immer noch.
Wie ist die Situation bei den anderen betroffenen?
Ich hab aus Zeitgründen bisher nur eins meiner Pakete getestet. Da war Imagick da. Alle anderen kommen demnächst dran. Sind nicht so besonders bildlastig, da ist die Hauptsache alles wird angezeigt egal ob gdlib oder imagemagick.
Bei meinem eigenen Paket und dem Kundenpaket ist imagick jetzt in der Konsole wieder vorhanden.
Das Problem wurde eigentlich auf allen angepassten Systemen durch einen Systemcheck aller Benutzer behoben.Zitat:
Zitat von WG2000
Sollte das Problem bei dir weiterhin auftreten kann du mir gerne weitere Infos per PM zukommen lassen, ich schaue mir das dann einmal genauer an.
Sites fuktionieren wieder.
Danke adSilva