Hoster Webgo

[tab]

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.

[mlweb]

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).

[Andreas]

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.

[Andreas]

Neues zu PHP Version per Domain

Ich habe beim Support nochmal nachgefragt:

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 ...

Hier die Antwort (genehmigt vom Verfasser):

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 ...

Lassen wir uns also mal überraschen

[limonen-zebra]

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

[Andreas]

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:

"php_cli": "\/usr\/bin\/php70",

Vielleicht Testweise mal mit ner MariaDB probieren.

[limonen-zebra]

Perfekt!
Vielen Dank - das war es. Jetzt lassen sich die Erweiterungen wieder installieren

[Andreas]

Was war es denn? MariaDB oder "php_cli"?

[limonen-zebra]

"php_cli" musste angepasst werden

[Andreas]

Ah, das ist gut, dass es nicht die DB war.

[Spooky]

Auf dem Server s131 funktionieren momentan keine SSL Verbindungen. zB:

# 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.

# /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

Darüberhinaus ist kein vi verfügbar:

# vi composer.json
-shell: vi: command not found

[Spooky]

Ist nun gefixed

[tab]

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 . 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.

[Spooky]

Das Problem bestand wohl nur bei einem Teil der Server oder diesem speziellen Server. Server 124 und 129 hatten jedenfalls dieses Problem nicht.

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).

[tab]

Was war denn das Problem? Ein Unix ohne vi ist ja fast nicht vorstellbar .