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.
Druckbare Version
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.
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.
Sites fuktionieren wieder.
Danke adSilva
Ich hatte das Problem auch nur kurz. Hatte kurz Kontakt mit dem Support und wurde sofort gefixt.
Aber kann es sein, das die Performance stark eingebrochen ist?
Ich kann den Manager quasi ohne Memory Fehler nicht mehr nutzen... das ging bis vor kurzen einwandfrei mit meinem Paket (Platin).
Kommt quasi egal bei welcher Erweiterung. Der Manager-Check sagt alles i.O.Code:Error: "Out of memory (allocated 1046487040) (tried to allocate 4096 bytes)" in phar:///home/www/***/web/contao-manager.phar.php/vendor/composer/composer/src/Composer/DependencyResolver/Solver.php on 220
mmap() failed: [12] Cannot allocate memory
mmap() failed: [12] Cannot allocate memory
mmap() failed: [12] Cannot allocate memory
Process terminated with exit code 255
Reason: Unknown error
Hat da jemand ähnliche Erfahrungen?
Ja die Erfahrung, dass bei einem Platin Paket plötzlich keine Updates mehr funktionieren habe ich auch gemacht. Dabei ist es egal ob Manager oder Konsole. Ich bin da schon seit einiger Zeit in Kontakt mit Webgo bisher aber leider noch ohne Ergebnis.
Das wäre schade, passt allerdings irgendwie auch mit meiner Beobachtung zusammen, dass bereits seit längerer Zeit Googles durchschnittliche Ladezeiten für Seiten deutlich höher sind als ursprünglich. Circa 200ms mehr pro Seite. Hatte das ursprünglich auf die durchgeführte Umstellung auf https mit Let's Encrypt geschoben, weil das in etwa zeitgleich passiert war.
Dies spiegelt sich leider nicht mit unseren Beobachtungen im Bezug auf die Ladezeit. Stichprobenartig konnten wir eine Verbesserung der Ladezeiten von bis zu 150% beobachten, in keinem Test gab es höhere Ladezeiten als vor dem Update. Wir haben ca. 200 Webseiten auf verschiedenen Servern getestet.
Ebenfalls ist apc/apcu hinzu gekommen, welches aktiviert ist und direkt verwendet werden kann.
Im Bezug auf das Memory Problem sind derzeit noch interne Tests nötig um definitiv sagen zu können woher das Problem kommt.
Ich kann das Problem auch nicht eindeutig zuordnen. Sonst hätte ich schon länger mal nachgefragt. Es hat mit der jetzigen Änderung auch sicher nichts zu tun, denn die Änderung der Ladezeiten ist jetzt schon fast 3 Monate her. Es war eben auffällig, dass plötzlich statt Ladezeiten von meist unter 200ms in der Crawling-Statistik praktisch von einem Tag zum anderen 350-450ms angezeigt wurde und auch die dort angezeigte durchschnittliche Ladezeit entsprechend höher wurde. In etwa zu der Zeit habe ich aber ein Contao-Update gemacht und auch auf https umgestellt. Vielleicht liegt es ja daran - oder Google misst jetzt einfach irgendwie anders. Nachdem Google Pagespeed immer noch jenseits der 95 liegt, kann es eigentlich auch nicht so furchtbar schlimm sein. Deshalb habe ich da bisher nichts unternommen. Werde jetzt aber doch nochmals genauer in die Installationen reinschauen, ob ich dabei vielleicht irgendwas verbogen habe.
Ich habe für meine Kunden mehrfach Platinpakete im Einsatz. Das Problem tritt bei mir nur bei einem einzigen Paket auf. Insofern bin ich da noch relativ gelassen und arbeite im Moment mit lokalem Update und Übertragung der composer.lock. Der Aufwand dafür hält sich ja Gott sei Dank in Grenzen.
Kannst du mal kurz skizzieren, wie der Weg konkret aussieht oder gibts dafür irgendwo eine Anleitung oder was wissenswertes...? Lokal entwickle ich nämlich garnicht.
Das wäre vielleicht für brennende Upgrades eine Variante.
Danke!
PS: Die Konsole hat bei meinem Paket wohl scheinbar nur 5.6.30 als PHP Version. Kann das ein möglicher Grund sein?
lokal arbeite ich mit XAMPP unter Windows 10. Da unter Windows der Manager noch nicht funktioniert läuft dort alles über die Konsole. Wie man bei wenig RAM dann alles auf den Server bekommt hat @Spooky einige Male erklärt u.a. in diesem Post
Ist mir bei den Platin-Paketen noch nicht untergekommen. Ich hatte immer auch 7.0 und 7.1 auf der Konsole und im Paket zur Verfügung.
Fakt ist dass der Speicherbedarf bei 5.6 höher ist.
Hallo liebes Webgo-Team,
ich habe mir heute ein CMS Power zugelegt.
Gehe ich auf die Konsole steigen mir schon wieder leicht die Nackenhaare zu Berge. Egal ob ich PHP 7.1 oder 7.2 benutze, es kommt die Warnmeldung
Ich dachte das sollte auf allen Paketen der Vergangenheit angehören.Code:PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/20160303/readline.so' - /usr/lib/php/20160303/readline.so: undefined symbol: rl_on_new_line in Unknown on line 0
Auch ein Zertifikats-Problem besteht dort scheinbar.
Eure Composer Version ist inzwischen so alt, dass ich damit nicht mehr arbeiten möchte, weil ich nicht weiß ob einige Probleme daher kommen. Eine aktuelle krieg ich aber nicht zu fassen.
Versuche ich es dann doch mit eurer composer-Version 1.4.2 habe ich natürlich erwartungsgemäß das Zertifikatsproblem:Code:wget https://getcomposer.org/download/1.6.3/composer.phar
--2018-02-13 14:09:03-- https://getcomposer.org/download/1.6.3/composer.phar
Resolving getcomposer.org (getcomposer.org)... 54.36.53.46, 2001:41d0:302:1100::8:104f
Connecting to getcomposer.org (getcomposer.org)|54.36.53.46|:443... connected.
ERROR: The certificate of 'getcomposer.org' is not trusted.
ERROR: The certificate of 'getcomposer.org' hasn't got a known issuer.
Ich bin etwas angesäuert.Code:PHP Warning: PHP Startup: Unable to load dynamic library 'readline.so' (tried: /usr/lib/php/20170718/readline.so (/usr/lib/php/20170718/readline.so: undefined symbol: rl_on_new_line), /usr/lib/php/20170718/readline.so.so (/usr/lib/php/20170718/readline.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
[Composer\Downloader\TransportException]
The "https://packagist.org/packages.json" file could not be downloaded: SSL
operation failed with code 1. OpenSSL Error messages:
error:1416F086:SSL routines:tls_process_server_certificate:certificate veri
fy failed
Failed to enable crypto
failed to open stream: operation failed
create-project [-s|--stability STABILITY] [--prefer-source] [--prefer-dist] [--repository REPOSITORY] [--repository-url REPOSITORY-URL] [--dev] [--no-dev] [--no-custom-installers] [--no-scripts] [--no-progress] [--no-secure-http] [--keep-vcs] [--no-install] [--ignore-platform-reqs] [--] [<package>] [<directory>] [<version>]
Wie gesagt ich bin kein Entwickler und auch kein Serveradministrator. Normalerweise mag ich mich mit diesem Bereich nicht rumschlagen und mir fehlt dazu auch das nötige Wissen, sonst würde ich einen eigenen Server administrieren. Ihr zwingt mich allerdings derzeit gerade dazu mich viel intensiver mit der Problematik zu befassen, als das eigentlich bei einem Shared Hosting Paket erforderlich sein sollte
Gerade nach dem letzten Wirbel hier im Forum habe ich anderes erwartet.
Huhu, das Zertifikatsproblem auf der Konsole hat bei mir der Support nach dem letzten Update bei zwei Paketen behoben. Bei PHP 7.2 habe ich ebenfalls das readline.so Problem, bin wieder zurück auf 7.1, da funktioniert es mittlerweile, ebenfalls aber erst nach Ticketerstellung, wieder. Momentan bin ich da auch etwas enttäuscht, bin von 1&1 sowie von Domainfactory teilweise zu Webgo umgezogen wegen den dortigen Unzulänglichkeiten wie Composer, Laufzeitproblemen etc. Jetzt habe ich wieder Baustellen, nur anderer Art. Unglaublich....
Gesendet von iPad mit Tapatalk
Hatte die Info auch an den Support gegeben weil ich ohnehin noch in Kontakt bin wegen eines Paketes mit anderen Problemen.
Man hat mir versichert, dass man das auf allen Systemen prüfen wird und auch den global installierten Composer updaten wird.
Für mein Paket wurde es definitiv gerade behoben. Der Composer ist upgedatet. Das Zertifikatsproblem wurde auch behoben.
Damit bin ich erst einmal zufrieden. Danke an Webgo.
Ich denke es ist gerade eine schwere Zeit. Von PHP5 auf PHP 7 und dann die neuen Anforderungen wegen des Composers. Webgo ist auf jedenfall der einzige Provider den ich kenne, welcher sich hier im Forum meldet und sich wirklich der Probleme annimmt. Ich habe gerade gestern noch versucht Contao 4 auf einem großen Hetzner L19 Paket zu installieren und dort ist Schluss, sobald man versucht eine Erweiterung zu installieren. Bei anderen Kunden kann ich kein kostenloses Let'sEncrypt aufsetzen.
Ich bin jetzt bestimmt schon 12 Jahre bei Webgo und bisher gab es dort keine Probleme. Also auch mal ein Dank an den Support von Webgo und natürlich bin ich selber auch daran interessiert, dass dort demnächst alles wieder reibungslos läuft.
Auch einen Dank an alle, welche ihre Probleme beim Support melden, denn ich profitiere schließlich auch davon ;)
Wollte nur auch kurz vermelden, das gestern wohl ein Fehler in der Hardware entdeckt und die Nacht entsprechendes Equipment getauscht wurde. Das ganze wurde gestern zeitig angekündigt. Seither hab ich zumindest wieder die gewohnte Performance, auch ohne jede Probleme mit dem Manager/Composer.
Prima! :D
Einer meiner Server ist am Sonntag dran.
Ja, meiner von Sonntag auf Montag, da bin ich ja mal gespannt ...
Checkt danach bitte euere MariaDBs im Webspace-Admin. Die wurden bei mir dort schon nicht angezeigt und somit liefen die natürlich auch nicht in meinen Installationen. Es wurde sofort gefixt und sie sollten es jetzt im Griff haben, schaut aber bitte trotzdem dort nach.
Ich werde in jedem Fall vorher noch ein Backup fahren und runterladen. Man hat schon Pferde ko**en sehen... ;)
Hallo,
ich finde bei WebGo kein Platin-Webhostingpaket, nur Starter, Profi, Business und Power.
Ist das Platinpaket ein älteres Paket und kann nicht mehr gebucht werden?
Wer hat Erfahrungen zum aktuellen Business-Paket und Contao 4.4.x?
Kann ich beim Business-Paket je Subdomain eine andere PHP-Version wählen oder nur eine PHP-Persion für das gesamte Paket?
Danke für die Infos.
Schmidty