Installation Contao 4.4 / Contao Manager

Mag sein das es mit 5.5 geht und mit 7 nicht.
Aber unter gleichen Bedingungen lässt sich die Installation via Composer nunmal unter PHP7 problemlos durchführen. Da sind also die Voraussetzungen für Composer, Symfony und Contao erfüllt wobei bereits Composer nicht als Leichtgewicht gehandelt wird. Jetzt verweigert ausgerechnet der Contao-Manager in dieser Umgebung seinen Dienst?!?
Sollte der Contao-Manager nicht einmal sowas wie der „Fels in der Brandung“ werden, mit dem man eine Contao Installation im Fall der Fälle sogar wieder reparieren kann werden?
Dann jedenfalls dürfen dessen Systemvoraussetzungen nicht höher oder penibler sein als die von Contao (und Symfony sowie Comoser) selbst.
Aber bitte fair bleiben. Es steht immer noch ein „beta“ in der Version. Nur gerade in einer beta sollte man natürlich nicht auf ein Logging verzichten. Ich persönlich bin davon überzeugt, dass es am Ende gut wird – wie immer.
Daumen hoch für die Leistung der Entwickler des gesamten Contao-Teams!

Hier meine E-Mail an DomainFactory
************************************************** ************
Meiner Ansicht nach liegt es daran, dass bei DomainFactory und PHP7 das Zertifikat für https://api.ipify.org (ausgestellt von COMODO RSA Domain Validation Secure Server CA) nicht angenommen wird.

Zum Nachvollziehen können Sie folgendes probieren:

Variante 1 - Konsole:
wget -O- https://api.ipify.org
--> Führt zur Fehlermeldung: ERROR: cannot verify api.ipify.org's certificate...

Varinate 2 - php-Script:
<?php
$a = file_get_contents('https://api.ipify.org/');
echo $a;
?>
--> funktioniert mit PHP 5.5 (lädt die Seite mit der IP-Adresse des Servers)
--> funktioniert nicht mit PHP 7.0
Fehlermeldung: file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed in ...

Können Sie bitte das Zertifikat installieren? In meinem Browsern (Chrome, Firefox und Edge wird das Zertifikat als vertrauenswürdig und sicher dargestellt.)
************************************************** ************

Zitat:

---

Zitat von the_scrat

Und "Da fehlt ein Zertifikat oder ähnliches unter PHP 7" ist ungefähr so aussagekräftig wie "Unerwarteter API Status" ;-)

---

Ich bezog mich natürlich auf die SSL Fehlermeldung wodurch ein API Fehler angezeigt wurde. Der API Fehler kommt, wenn der Server nicht so antwortet (json) wie erwartet.
Ob man das abfangen kann weiß ich nicht, da kann ja alles mögliche zurück kommen statt der richtigen Antwort. Neben SSL Meldungen kamen da auch schon open_basedir Meldungen.

Zitat:

---

Zitat von Tim G

Du meintest sicher eine Installation in einem Unterverzeichnis des Server-Roots geht nicht. Also: contao4.meineWebseite.de/web/... wäre unzulässig. Das ist unabhängig ob es sich um eine TLD oder Subdomain dieser Handelt. Server-Root muss auf /web/ pointen, ist gemeint.

---

Genau :)

Zitat:

---

Zitat von t.mayer

Code:

---

Resolving api.ipify.org... 54.243.147.114, 54.235.148.27, 50.19.238.1, ...
Connecting to api.ipify.org|54.243.147.114|:443... connected.
ERROR: cannot verify api.ipify.org's certificate, issued by '/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA':
  Unable to locally verify the issuer's authority.
To connect to api.ipify.org insecurely, use `--no-check-certificate'.

---

---

Damit kannst du dich ja bereits an den Hoster wenden. Das Zertifikat von api.ipify.org ist korrekt (lässt sich auch mit Online Zertifikats Testern überprüfen). Der Fehler liegt daher beim Hoster. Du kannst DomainFactory ja zB folgendes schreiben:

Zitat:

---

Auf dem Servers des verwendeten Pakets ist keine Verbindung über SSL zu api.ipfy.org möglich. Wenn man zB

wget -O- https://api.ipfy.org

versucht auszuführen, bekommt man nur die Meldung

Resolving api.ipify.org... 54.243.147.114, 54.235.148.27, 50.19.238.1, ...
Connecting to api.ipify.org|54.243.147.114|:443... connected.
ERROR: cannot verify api.ipify.org's certificate, issued by '/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA':
Unable to locally verify the issuer's authority.
To connect to api.ipify.org insecurely, use `--no-check-certificate'.

Das Zertifikat von api.ipify.org ist aber korrekt. Dies lässt sich auch mit diversen Online Zertifikats Tests bestätigen, zB:

https://www.ssllabs.com/ssltest/anal...ify.org&latest
https://www.sslshopper.com/ssl-check...=api.ipify.org
https://www.digicert.com/help/

Auch unter PHP mit bspw.

var_dump(file_get_contents('https://api.ipify.org'));

kann keine Verbindung aufgebaut werden.

---

Du könntest auch noch weitere Tests mit cURL machen, aber ich denke das sollte DomainFactory erstmal reichen.

// edit: ah, zu spät gesehen dass du das bereits gemacht hast

Zitat:

---

Zitat von the_scrat

Das darf in diesem Fall (Contao Manager) aber kein Grund sein um nicht zu funktionieren.

---

Das Aufbauen einer Verbindung zu einem Server ist eine Grundvoraussetzung. Wenn das Hosting bspw. auch keine Verbindung zu contao.org aufbauen kann, dann kannst du mit dem Contao Manager auch nicht Contao 4 installieren lassen. Oder wenn du Contao 3 verwendest kannst du die Erweiterungsverwaltung nicht verwenden etc.

Hi,
ich habe auf einer meiner Webseiten Contao 4.4 manuell bei All-Inkl.com installiert. Das hat auch wunderbar funktioniert. Ich habe aber mal ein paar Fragen dazu.

Verstehe ich das richtig, das wenn man die 4.4 installiert, dort nur noch der Core zu finden ist und alles was es an Erweiterungen und etc. gibt, dann über den Manager läuft?
Leider kann ich den Manager nicht installieren. Jedes mal, wenn ich den Manager aufrufe kommt ein Fehler:

Code:

---

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
 - cgi-bin
 - composer.json
 - composer.lock
 - files
 - logs
 - system
 - templates
 - usage
 - var
 - vendor

---

Ich kann leider nicht nachvollziehen, warum der Fehler auftaucht. Die Caontao Version läuft einwandfrei und die CM-Datei liegt im web-Ordner.

MfG
Sebeljaner

Zitat:

---

Zitat von Sebeljaner

Hi,
ich habe auf einer meiner Webseiten Contao 4.4 manuell bei All-Inkl.com installiert. Das hat auch wunderbar funktioniert. Ich habe aber mal ein paar Fragen dazu.

Verstehe ich das richtig, das wenn man die 4.4 installiert, dort nur noch der Core zu finden ist und alles was es an Erweiterungen und etc. gibt, dann über den Manager läuft?
Leider kann ich den Manager nicht installieren. Jedes mal, wenn ich den Manager aufrufe kommt ein Fehler:

Code:

---

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
 - cgi-bin
 - composer.json
 - composer.lock
 - files
 - logs
 - system
 - templates
 - usage
 - var
 - vendor

---

Ich kann leider nicht nachvollziehen, warum der Fehler auftaucht. Die Caontao Version läuft einwandfrei und die CM-Datei liegt im web-Ordner.

MfG
Sebeljaner

---

Hi,

schau nochmal genau hin, der Manager sagt Dir ja, was er bemängelt bzw. wieso ein Fehler auftaucht:

Zitat:

---

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:

---

VG

Welches Contao 4 hast du dort installiert, die Standard Edition oder die Managed Edition?

Hi,
ich habe schon gesehen, was der Manager von mir verlangt, allerdings macht das für mich kein Sinn. Die Installation funktioniert ja und wenn ich jetzt die Ordner löschen soll, ist das irgendwie komisch, denn darunter sind ja auch Ordner der Core-Installation und auch Serverseiteseitige Ordner die ich nicht löschen kann.
Die Fehlermeldung ist einfach zu umfangreich und daher schließe ich daraus das wohl ein größeres Problem vorliegt. Auf dem Server läuft z.B. PHP 7 und da ich manuell den Composer nicht installiert habe, kann es vielleicht auch daran liegen.

An Composer liegt es nicht, da der Contao Manager diesen selbst mitbringt.
Woran er sich aber bei dir auf alle Fälle stört ist "cgi-bin". Vielleicht könnte man das noch filtern, ich frag mal nach.

Sinn ist, wenn im Installationsverzeichnis schon was liegt, was nicht von Contao ist, dann geht der Manager davon aus, das es dort was überschreiben könnte und das so nicht gewollt sein kann.

In der beta2 wird cgi-bin ignoriert. Welche Contao Manager Version hast du installiert?

Da Andreas bei der Konferenz gesagt hat, dass der Manager über ein Selfupdate (Intervall dafür war glaub ich bei 10min??) verfügt, sollte die Version des Managers nahezu jederzeit aktuell sein.

Aber nicht, wenn beim Aufruf gleich der Fehler kommt denke ich mal.

Naja, der CM kann ja eigentlich noch nicht installiert sein, da ich ja nicht soweit komme. Vorher kommt die Fehlermeldung. Die jetzige Version ist 1.0.0-beta1.

Die Ordner cgi-bin und usage sind bei All-Inkl.com Standardordner die ich nicht löschen kann. Es wäre also gut, wenn solche Ordner die nicht zu Contao gehören, zukünftig ignoriert werden können.

Zitat:

---

Zitat von BugBuster

Aber nicht, wenn beim Aufruf gleich der Fehler kommt denke ich mal.

---

Da hast Du natürlich verdammt recht :D.

Zitat:

---

Zitat von Sebeljaner

Die Ordner cgi-bin und usage sind bei All-Inkl.com Standardordner die ich nicht löschen kann. Es wäre also gut, wenn solche Ordner die nicht zu Contao gehören, zukünftig ignoriert werden können.

---

Das ist doch gar nicht nötig. Du solltest den Ordner web nicht ins root Deines Hostings legen sondern in einen extra Ordner, dann gibt es auch keine Probleme diesbezüglich.

Zitat:

---

Zitat von BugBuster

In der beta2 wird cgi-bin ignoriert. Welche Contao Manager Version hast du installiert?

---

Schön wäre es, wenn usage dann auch ignoriert werden würde. cgi-bin und usage werden von All-Inkl immer standardmäßig angelegt.

Zitat:

---

Zitat von mlweb

Das ist doch gar nicht nötig. Du solltest den Ordner web nicht ins root Deines Hostings legen sondern in einen extra Ordner, dann gibt es auch keine Probleme diesbezüglich.

---

Hi Maren,

das ist m.M.n. etwas missverständlich in den Anleitungen dargestellt. Hier wird immer nur vom Ordner /web gesprochen, aber nicht davon, dass der Ordner /web irgendwo unterhalb eines anderen Ordners abgelegt werden sollte. Ich hatte bei meinem ersten Versuch gestern genau das selbe Problem. Beim zweiten Versuch habe ich dann /web unter /contao angelegt und damit dann keine Probleme gehabt.

Zitat:

---

Zitat von jscholtysik

das ist m.M.n. etwas missverständlich in den Anleitungen dargestellt.

---

Für die Installation von Contao 4 ist das ja auch eigentlich unerheblich, daher taucht es auch in keiner Anleitung auf. Wenn du mit vhosts arbeitest ist es aber ohnehin üblich die folgende Verzeichnisstruktur zu haben:

/path/to/webspace/domain1/…
/path/to/webspace/domain2/…
/path/to/webspace/domain3/…

Je nach Hoster könnte es aber sein, dass trotzdem irgendwelche automatisch erzeugten Ordner in den DocumentRoots erzeugt werden.

Zitat:

---

Zitat von jscholtysik

Schön wäre es, wenn usage dann auch ignoriert werden würde. cgi-bin und usage werden von All-Inkl immer standardmäßig angelegt.

---

Siehe dazu auch https://github.com/contao/contao-man...ment-309371548

Zitat:

---

Zitat von Sebeljaner

Hi,
ich habe schon gesehen, was der Manager von mir verlangt, allerdings macht das für mich kein Sinn. Die Installation funktioniert ja und wenn ich jetzt die Ordner löschen soll, ist das irgendwie komisch, denn darunter sind ja auch Ordner der Core-Installation und auch Serverseiteseitige Ordner die ich nicht löschen kann.
Die Fehlermeldung ist einfach zu umfangreich und daher schließe ich daraus das wohl ein größeres Problem vorliegt. Auf dem Server läuft z.B. PHP 7 und da ich manuell den Composer nicht installiert habe, kann es vielleicht auch daran liegen.

---

Den Fehler mit dem CGI-Ordner kannst du auch elegant umgehen, in dem du mehrere Unterverzeichnisse bei All-Inkl einrichtest und dann Contao darin installiert. Bei mir hat es geklappt, nachdem ich einen Ordner

Code:

---

http/web/........<contao-installation>

---

eingerichtet habe.

@BugBuster
Die Fehlermeldung taucht bei All-Inkl mit allen Dateien und Ordnern auf, wenn der Webspace nicht vorher zu 100% geleert wurde bevor man mit der Installation von Contao 4.* beginnt.

Zitat:

---

Zitat von Spooky

Für die Installation von Contao 4 ist das ja auch eigentlich unerheblich, daher taucht es auch in keiner Anleitung auf. Wenn du mit vhosts arbeitest ist es aber ohnehin üblich die folgende Verzeichnisstruktur zu haben:

/path/to/webspace/domain1/…
/path/to/webspace/domain2/…
/path/to/webspace/domain3/…

Je nach Hoster könnte es aber sein, dass trotzdem irgendwelche automatisch erzeugten Ordner in den DocumentRoots erzeugt werden.




Siehe dazu auch https://github.com/contao/contao-man...ment-309371548

---

Danke Spooky fürs Kommentieren auf Github!


Sollte man dann nicht in der Anleitung unterscheiden, ob es sich um ein Shared Hosting Paket oder um Managed/dedizierte Server mit der eventuellen Möglichkeit für vhosts handelt? Ich selbst hatte bisher noch nie die Notwendigkeit, überhaupt mit vhosts arbeiten zu müssen. Ich arbeite immer mit Subdomains.

Zitat:

---

Zitat von jscholtysik

Sollte man dann nicht in der Anleitung unterscheiden, ob es sich um ein Shared Hosting Paket oder um Managed/dedizierte Server mit der eventuellen Möglichkeit für vhosts handelt?

---

In welcher Anleitung meinst du jetzt? Außerdem ist das ja irrelevant, oder was genau meinst du da jetzt?

Zitat:

---

Zitat von jscholtysik

Ich selbst hatte bisher noch nie die Notwendigkeit, überhaupt mit vhosts arbeiten zu müssen. Ich arbeite immer mit Subdomains.

---

Das ist (mehr oder weniger) dasselbe ;). Für jede (Sub)Domain existiert auch ein Eintrag in einem vhost.

Gerade eben Contao 4.4 via Contao Manager auf einem PLESK-System installiert, war wohl erfolgreich, bin im Backend drin. :D

Hatte vorher aber auch die Meldung "ERROR 500 Unerwarteter API-Status", da war aber noch PHP 5.6 eingestellt. Mit PHP 7.1 geht es. (Plesk hat Probleme mit dem Composer und dem Live-Update bei Verwendung von PHP 5.6).

Zitat:

---

Zitat von jscholtysik

Schön wäre es, wenn usage dann auch ignoriert werden würde.

---

Das sind die Ordner die bei All-Inkl angelegt werden. 1&1 hat im root in einem meiner Kunden-Pakete die Ordner .subversion und log liegen. Bei strato sind es die Ordner cgi-data und cgi-bin.
Ich denke die vernünftige Struktur im Hostingpaket ist völlig unabhängig von Contao. Dafür trägt derjenige die Verantwortung der das Paket einrichtet.
Aber ich gebe Dir recht ein kleiner Hinweis darauf, dass der Ordner direkt oberhalb von web leer sein muss, könnte vielleicht manche Nachfrage ersparen.
Abfangen kann man das m.E. so einfach nicht. Es ist halt bei jedem Hoster etwas anders. Webgo z.B. legt mir bei anlegen einer Domain grundsätzlich einen eigenen Ordner an in dem sich eine index.html befindet. Wenn ich die nicht lösche, meckert der Manager auch.

Zitat:

---

Zitat von Spooky

In welcher Anleitung meinst du jetzt? Außerdem ist das ja irrelevant, oder was genau meinst du da jetzt?

Das ist (mehr oder weniger) dasselbe ;). Für jede (Sub)Domain existiert auch ein Eintrag in einem vhost.

---

Zur Anleitung:

Hier zum Beispiel:

https://docs.contao.org/books/manage...n-manager.html

Finde ich persönlich etwas missverständlich und bedeutet für mich:

- Erstelle einen Unterordner /web (egal wo) und kopiere dann da den Contao Manager rein.
- Ich habe also eine Subdomain bei All-Inkl: contao4.domain.de
- Dann erstelle ich einen Unterordner /web
- Leite dann den DocumentRoot in dieses Unterverzeichnis, was aber durch die All-Inkl-Verzeichnisse cgi-bin und usage die anschließende Installation verhindert
- Erstelle ich aber einen Unterordner /contao und darin dann /web, funktioniert die Installation ohne Fehlermeldungen


Zu den vhosts:

Mit denen ich dann aber nicht in Berührung komme... ;-)

Zitat:

---

Zitat von jscholtysik

Mit denen ich dann aber nicht in Berührung komme... ;-)

---

Doch, wenn du den DocumentRoot einer Domain festlegst, "berührst" du die VirtualHost Konfiguration.


Die Anleitung anzupassen hat eigentlich keinen Sinn. In der nächsten Version der Managers sollte die Installation in solchen Fällen ja funktionieren.

Zitat:

---

Zitat von AgentK

Die Fehlermeldung taucht bei All-Inkl mit allen Dateien und Ordnern auf, wenn der Webspace nicht vorher zu 100% geleert wurde bevor man mit der Installation von Contao 4.* beginnt.

---

Ich habe da nichts löschen müssen. Ich habe Contao 4.4 mit dem Contao Manger auf der Konferenz in ca. 10 Minuten fehlerfrei installiert.
Am längsten hat gedauert, den Pfad zum PHP 7.1 herauszufinden (/usr/bin/php71).
- Subdomain anlegen, PHP-Version setzen
- SSL-Zertifikat einrichten
- neue Datenbank anlegen
- Contao-Manager downloaden
- Contao Manager hochladen und .php anfügen
- aufrufen und die Installation ausführen lassen
-----
In Summe ca. 10 Minuten bei schlechter WLAN-Verbindung

All-Inkl Premium-Paket
PHP 7.1

Zitat:

---

Zitat von do_while

Ich habe da nichts löschen müssen.

---

In welchen Ordner genau hast du den Manager installiert?

Nachtrag zur Installation auf All-inkl:

So, ES HAT GEKLAPPT!!!!

php5.5 -> gescheitert
php5.6 -> gescheitert
php7.0 -> gescheitert
php7.1 -> damit hat es geklappt. Daten per Manager. Ich konnte das Installations-Tool betreten und roh installieren.

PHP-Binary: /usr/bin/php71

(Der Contao check hat bei allen Versionen grünes Licht gegeben)

Anbei die KAS Ansicht meiner Subdomain. Paket ist: All-inkl PrivatPlus

Anhang 19475

Genau die gleiche Konfiguration habe ich jetzt auch bei All-Inkl. Installation z.B. unter /htdocs/contao4/web, nicht unter /htdocs/web, weil das ja mit den automatisch angelegten Ordnern bei All-Inkl nicht funktioniert.

Zitat:

---

Zitat von Spooky

In welchen Ordner genau hast du den Manager installiert?

---

Na in den Ordner web, sonst kann man ihn ja nicht über die Subdomain aufrufen.

Code:

---

https://sub.domain.tld/contao-manager.phar.php

---

Zitat:

---

Zitat von jscholtysik

Genau die gleiche Konfiguration habe ich jetzt auch bei All-Inkl. Installation z.B. unter /htdocs/contao4/web, nicht unter /htdocs/web, weil das ja mit den automatisch angelegten Ordnern bei All-Inkl nicht funktioniert.

---

Du musst hier bedenken, dass Contao in einem Verzeichnis höher liegt: Wenn Du nur ein /web anlegst, landet die Contao-Installation in der Root des Webspaces und Du kannst nicht mehrere unabhängige Installationen verwalten. Eine tiefere Verzeichnisstruktur tut ja auch nicht weh, macht den Webspace aber übersichtlicher.

Hi Hagen,


deswegen lege ich ja eine Subdomain an, weil ich nicht mehrere unabhängige Installationen in dieser Subdomain benötige (schön alles trennen), sondern in diesem Fall nur eine Contao 4 Installation.

Zitat:

---

Na in den Ordner web, sonst kann man ihn ja nicht über die Subdomain aufrufen.
Code:
https://sub.domain.tld/contao-manager.phar.php

---

Das ist schon klar, aber wie sieht hier der DocumentRoot bei All-Inkl bei Dir aus?

Zitat:

---

Zitat von do_while

Na in den Ordner web, sonst kann man ihn ja nicht über die Subdomain aufrufen.

Code:

---

https://sub.domain.tld/contao-manager.phar.php

---

---

Ich meinte den absoluten Ordner, nicht den relativen Ordner zur Domain.

Die Installation von Paketen über den "contao-manager.phar.php" dauert um einiges länger als bei Contao 3.5.
Der Installationsprozess für die "Rocksolid Custom Elements" zb. hat bei mir ca 1 Min gedauert.
... und zusätzlich muss man dann auch noch ins Contao-Installtool :rolleyes:

Zitat:

---

Zitat von Spooky

Ich meinte den absoluten Ordner, nicht den relativen Ordner zur Domain.

---

Code:

---

/www/htdocs/w0123456/webseiten/_tests/contao4.4/web/

---

Zitat:

---

Zitat von do_while

Code:

---

/www/htdocs/w0123456/webseiten/_tests/contao4.4/web/

---

---

Deswegen passiert bei dir auch nicht dieser Fehler, weil du Contao nicht direkt im Root des Webspace installiert hast.

Zitat:

---

Zitat von thesweetg

Die Installation von Paketen über den "contao-manager.phar.php" dauert um einiges länger als bei Contao 3.5.

---

Im Gegensatz zur Erweiterungsverwaltung werden im Manager zuvor auch alle Abhängigkeiten auf Kompatibilität getestet.

Zitat:

---

Zitat von thesweetg

... und zusätzlich muss man dann auch noch ins Contao-Installtool https://community.contao.org/de/imag...s/rolleyes.png

---

Das soll in Zukunft alles in den Manager integriert werden. Ist aber im Moment noch nicht so weit.

Hmmm, ich rätsle gerade...

Der Manager funktioniert in einer 4.4 bei netcup tadellos. Bei den beiden anderen nicht, da erhalte ich beim Aufruf der .phar.php. Alles waren ursprünglich 3.5er, die ich auf die 4.3 angehoben und gestern auf die 4.4. geupdated hatte (über die Konsole).

Code:

---

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
- composer.phar
- files
- system
- templates
- var
- vendor

---

Der Domain-Root ist bei allen 3: /httpdocs/contao4/web -> darin liegt auch die contao-manager.phar.php.

Ist da schon jemand dahinter gestiegen? Aus den bisherigen Posts wurde ich jetzt nicht wirklich schlau...

Ist das auch eine Managed Edition?

Ja, sry, vergessen zu erwähnen

Gibt es die Datei /vendor/bin/contao-console ?

Ja, in allen 3 Installationen. Ist ein Symlink woandershin.

Interessant ist aber, dass bei der Installation, bei der der CM funktioniert, doctrine-dbal, parse, pscss und update-psl ebenfalls Symlinks sind. In den anderen beiden, wo es nicht funktioniert, sind es keine.

Zitat:

---

Zitat von mlweb

Das ist doch gar nicht nötig. Du solltest den Ordner web nicht ins root Deines Hostings legen sondern in einen extra Ordner, dann gibt es auch keine Probleme diesbezüglich.

---

Ok, ich finde das zwar ein wenig umständlich, aber ich werde es probieren. Vielleicht sollte man das im Manual, dann explizit erwähnen, das auf jedenfall ein eigener Contao Unterordner erstellt werden muss, in dem die gesamte Installation hochgeladen wird. Dann ist das eindeutig und selbst, wenn es nicht alle Hoster betreffen wird, geht man damit auf Nummer sicher. :)

MfG
Sebeljaner

Zitat:

---

Zitat von k-webdesign

Ja, in allen 3 Installationen. Ist ein Symlink woandershin.

Interessant ist aber, dass bei der Installation, bei der der CM funktioniert, doctrine-dbal, parse, pscss und update-psl ebenfalls Symlinks sind. In den anderen beiden, wo es nicht funktioniert, sind es keine.

---

Funktioniert die contao-console? Also kannst du zB

Code:

---

php vendor/bin/contao-console cache:clear

---

ausführen?

Zitat:

---

Zitat von Spooky

Funktioniert die contao-console? Also kannst du zB

Code:

---

php vendor/bin/contao-console cache:clear

---

ausführen?

---

Ja, das geht bei allen dreien durch. Doch auch nach Leeren des Symfony-Caches ändert sich nix :(

Du könntest mal probieren den gesamten /vendor Ordner zu löschen und danach wieder ein

Code:

---

composer install

---

ausführen. Auf eigene Gefahr ;)

Gemacht - mit Backup natürlich ;)

Jetzt sind überall die Symlinks da, der 500er leider auch nach wie vor. Hab zuerst den Symfony Cache geleert, dann vendor gelöscht und composer install ausgeführt. Meeeh :(

Dann würde ich das mal mit allen Informationen als Ticket posten.

Thema Symlinks nach der Installation:

Für die Ordner "files", "templates", die jetzt eine Ebene über dem Server-Root "web" liegen müsste eigentlich ein Symlink angelegt werden in "web". Hab ich etwas übersehen?
Ohne Symlinks enden Dateiabfragen natürlich in einem 404. Das {{image}} Inserttag scheitert damit auch.

Zitat:

---

Zitat von BugBuster

Also, wenn das mit PHP 5.5 geht aber mit 7.0 nicht, dann ist das doch der beste Beweis, dass die Ursache beim Hoster liegt.
Da fehlt ein Zertifikat oder ähnliches unter PHP 7.
Das sollten die von DF aber auch kapieren.

---

Dass der Hoster die Wurzel allen Übels ist, kann ich nur bestätigen. ;-)
Habe gestern zig Stunden damit verbracht, ein lauffähiges Contao 4.4 an den Start zu bekommen.
Musste leider feststellen, dass der Contao Manager nicht nutzbar ist (1&1 Unlimited Pro Paket).
Man kommt nur weiter, indem man direkt in der Konsole arbeitet. Aber auch nur begrenzt (composer/update führt auch zu diversen Abbrüchen).
Der Manager bricht sämtliche Konsolen-Tasks ab mit einer Fehlermeldung.
Es steht zum einen nur PHP 5.6 zur Verfügung und zum anderen einfach zu wenig RAM - was sich auch nicht durch das hochsetzen des memory limits per php.ini lösen lässt.
Mit voreingestelltem PHP7 kommt man gar nicht zum Zug (max. /usr/bin/php5.5-cli möglich).

Für alle, die es interessiert - bei 1&1 gibt es zumindest eine Kurzanleitung für den Composer:
https://community.1und1.de/php-compo...nd1-verwenden/

Ansonsten bleibt einem nur übrig, einen Server zu mieten, den man beliebig konfigurieren kann.
Dann klappt es vielleicht auch mit dem Contao Manager ;-)

Ich habe im Rahmen des Alphatest vom Contao Manager ein 1&1 Dual Basic von 2012 getestet, leider nur mit 60MB. Mit PHP 5.6 war keine Installation des Cores möglich. Mit PHP 7.1 aber schon.
Der Manager hat leider nicht den richtigen Pfad zu PHP erkannt. Mit manuell eingetragenem Pfad /usr/bin/php7.1-cli konnte ich den Core installieren, aber es war nicht möglich Erweiterungen zu installieren oder ein Coreupdate durchzuführen (memory_limit völlig logisch bei den 60MB). Da es sich um ein Kundenpaket handelt, kann ich auch nicht mal einfach Updaten. Dein Paket sollte aber je nach Alter 128 MB bzw. bei neueren Paketen 512 MB zu Verfügung haben. Da würde ich erwarten, dass erstens auch PHP 7.1 zur Verfügung steht und Du mindestens soweit kommen solltest wie ich (also Installation Core).

Zitat:

---

Zitat von siebenvier

Ansonsten bleibt einem nur übrig, einen Server zu mieten, den man beliebig konfigurieren kann.
Dann klappt es vielleicht auch mit dem Contao Manager ;-)

---

Oder auf einen anderen Hoster zu setzen. Das Preis-Leistungsverhältnis bei anderen Hostern m.E. deutlich besser.

Zitat:

---

Zitat von Tim G

Der Manager lief soweit bei mir gut durch. Den sehe ich mal als optional.
Danach der Aufruf zum Install-Tool > Lizenz akzeptieren > Klick > und tschüss... Danach die Hinweisseite "Unvollständige Installation"

"Wie kann ich das Problem lösen?
Bitte öffnen Sie das Contao-Installtool (/contao/install) in Ihrem Browser."
- Öhh.. ja, genau da bin ich. Ich möchte ja installieren. :). Url ist: http://contao4:8888/contao/install.php (Root ist /web Verzeichnis)
---
Prüfsystem: Mac OSX Sierra, Mamp 4, php 7.0.16, Chrome, DB name: contao4

---

Das hatte ich beim ersten Versuch auch (lokal unter Mac OSX Sierra / MAMP PRO 4 / PHP 5.6.30) mit Safari.
Mit Firefox hat es sofort geklappt!

Der Aufruf wäre auch http://contao4:8888/contao/install , ohne php am Ende. Die install.php sollte es mittlerweile auch nicht mehr geben.

Zitat:

---

Zitat von Tim G

Thema Symlinks nach der Installation:

Für die Ordner "files", "templates", die jetzt eine Ebene über dem Server-Root "web" liegen müsste eigentlich ein Symlink angelegt werden in "web". Hab ich etwas übersehen?
Ohne Symlinks enden Dateiabfragen natürlich in einem 404. Das {{image}} Inserttag scheitert damit auch.

---

Dateien die direkt im /files Ordner liegen können in Contao 4 nicht öffentlich verfügbar gemacht werden. Du kannst nur einzelne Ordner innerhalb von /files öffentlich verfügbar machen.

Zitat:

---

Zitat von t.mayer

Hier meine E-Mail an DomainFactory
************************************************** ************
Meiner Ansicht nach liegt es daran, dass bei DomainFactory und PHP7 das Zertifikat für https://api.ipify.org (ausgestellt von COMODO RSA Domain Validation Secure Server CA) nicht angenommen wird.

Zum Nachvollziehen können Sie folgendes probieren:

Variante 1 - Konsole:
wget -O- https://api.ipify.org
--> Führt zur Fehlermeldung: ERROR: cannot verify api.ipify.org's certificate...

Varinate 2 - php-Script:
<?php
$a = file_get_contents('https://api.ipify.org/');
echo $a;
?>
--> funktioniert mit PHP 5.5 (lädt die Seite mit der IP-Adresse des Servers)
--> funktioniert nicht mit PHP 7.0
Fehlermeldung: file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed in ...

Können Sie bitte das Zertifikat installieren? In meinem Browsern (Chrome, Firefox und Edge wird das Zertifikat als vertrauenswürdig und sicher dargestellt.)
************************************************** ************

---

Hast du schon eine Antwort/Lösung von DF?

Zwischendurch mal etwas Positives:

Lokal: MAMP Pro 4.1.1 auf MacOs Sierra und php 7.1.4 funktioniert bei mir problemlos mit Safari, Firefox, Chrome und Opera.
Remote auf All-Inkl: Läuft ebenfalls mit allen o.g. Browsern und auch mit Edge und Ie11.

Hatte nach Erscheinen der 4.4.0 und CM beta1 sowohl die lokale als auch die All-Inkl Installation (jeweils 4.3.11 ME) per Kommandozeile mit "php composer.phar update" auf 4.4.0 upgedated, nachdem ich zuvor in den jeweiligen composer.json die Releases auf "^4.4" bzw. "4.4.*" geändert hatte.

Die Updates liefen ohne Fehler durch und der Contao-Manager ließ sich sowohl lokal als auch auf dem Webhost ohne Fehler aufrufen. Paketaktualisierungen (z.B. visitors-bundle), Aufruf des Install-Tolls etc. funktionieren ohne Probleme. Hatte nur bei der Übertragung in das web Verzeichnis einer zweiten Installation ein Problem, da der CM nicht im binary-mode per ftp übertragen wurde. Aber das war eigene Dusseligkeit und ist längst behoben. Auch das Auto-Update des CM nach Aufruf funzt ... nun beta3.

Fazit: Ich bin rund'rum zufrieden ...

Nicht nur, aber für DF wurde der Zugriff auf api.ipify.org durch ein anders Ziel ersetzt. Also allgemein, nicht nur für DF :-)
Damit solltet ihr nun mehr Glück haben.

Auch speziell für 1&1 Kunden wurde was angepasst in Richtung PHP Pfad.

Mit der beta3 hat jetzt die C4.4 Installation geklappt. Der Manager zeigt im Anschluß auch Erweiterungen an. Diese können aber scheinbar nicht installiert werden. Bisher habe ich dies bezüglich 2 Test gemacht und bekomme folgende Ausgabe:

Code:

---

Task ade582880bcc5521b4b0d9371997e6e2 started.
Using version ^2.0 for madeyourday/contao-rocksolid-columns
/kunden/XxXxX/c4test/composer.json has been updated
Loading composer repositories with package information
Updating dependencies


mmap() failed: [12] Cannot allocate memory

mmap() failed: [12] Cannot allocate memory

mmap() failed: [12] Cannot allocate memory


Process terminated with exit code 139
Reason: Segmentation violation [signal 11]

---

*) dF, PHP7.0.13

Zitat:

---

Zitat von BugBuster

Auch speziell für 1&1 Kunden wurde was angepasst in Richtung PHP Pfad.

---

Hm, was heißt denn das?
Ich dachte bei 1und1 geht gar nichts mit Composer / Contao-Manager weil nur max. cli 5.5 angeboten wird?????

Danke
Frank

PHP 5.5 ist prinzipiell ausreichend für Composer Operationen - es muss nur in der composer.json die richtige PHP Version in der Platform Konfiguration hinterlegt sein.

Zitat:

---

Zitat von Spooky

PHP 5.5 ist prinzipiell ausreichend für Composer Operationen - es muss nur in der composer.json die richtige PHP Version in der Platform Konfiguration hinterlegt sein.

---

Sorry, aber hier schreibst Du:

Zitat:

---

Aber auch das wird dich nicht glücklich machen, da Contao 4.4 mindestens PHP 5.6 benötigt. Über composer wirst du Contao 4.4 also wahrscheinlich nicht installieren können.

---

???
Frank

Teste den CM beta3 Morgen nochmal auf einem 1und1 Paket ...

Zitat:

---

Zitat von Franko

Sorry, aber hier schreibst Du:


???
Frank

Teste den CM beta3 Morgen nochmal auf einem 1und1 Paket ...

---

Ja, installieren über composer create-project wird nicht mit der PHP 5.5 CLI gehen (wahrscheinlich). Wie der Contao Manager die Contao Managed Edition installiert weiß ich nicht.

Zitat:

---

Zitat von Franko

Teste den CM beta3 Morgen nochmal auf einem 1und1 Paket ...

---

Stelle dann mal im Kundenmenü für die Test-Domain PHP 7.1 ein und trage beim php-Pfad manuell /usr/bin/php7.1-cli. So hat im Rahmen des Alphatest bei mir zumindestens die Installation des Cores geklappt. Erweiterungen und Update dann nicht mehr weil das Dual Basic von 2012 welches ich zur Verfügung habe nur 60 MB hat.

Ich betreibe Conato nur hobbymässig und habe in letzten Tagen auch mit der 4.4 und dem Manager geübt. Aus meiner Sicht hat alles auf Anhieb funktioniert. Grad eben habe ich eine Erweiterung installiert, wo dann im Manager "inkompatibel" angezeigt wird (Bild). Das mit der unmittelbar vorher geholten und hochgeladenen contao-manager.phar. Nun erstaunt mich das etwas, weil ich den Forumtenor so verstanden habe, dass der Manager alle Abhängikeiten prüft. Die Folge davon habe ich so interpretiert, dass nur Kompatibles installiert werden kann. Ist meine Annahme falsch?

Anhang 19478

Zitat:

---

Zitat von Spooky

Ja, installieren über composer create-project wird nicht mit der PHP 5.5 CLI gehen (wahrscheinlich). Wie der Contao Manager die Contao Managed Edition installiert weiß ich nicht.

---

Hm, ich dachte der CM macht im Grunde nichts anderes als der php composer selbst.

@mlweb:

Zitat:

---

Stelle dann mal im Kundenmenü für die Test-Domain PHP 7.1 ein und trage beim php-Pfad manuell /usr/bin/php7.1-cli. So hat im Rahmen des Alphatest bei mir zumindestens die Installation des Cores geklappt. Erweiterungen und Update dann nicht mehr weil das Dual Basic von 2012 welches ich zur Verfügung habe nur 60 MB hat.

---

Sorry, aber mit nem 1und1 (Tarif 1und1 Unlimited) ssh Zugriff und (ls -l /usr/bin/php/*) erhalte ich:

Code:

---

lrwxrwxrwx  7 root root      21 Feb 28 12:32 /usr/bin/php -> ../lib/cgi-bin/php                                                              4.4
/usr/bin/php-config4.4
/usr/bin/php-config5.2
/usr/bin/php-config5.4
/usr/bin/php-config5.5
/usr/bin/php-config6 -> php-config5.4
/usr/bin/php4 -> php4.4
/usr/bin/php4.4 -> ../lib/cgi-bin/php4.4
/usr/bin/php4.4-cli
/usr/bin/php5 -> php5.2
/usr/bin/php5.2 -> ../lib/cgi-bin/php5.2
/usr/bin/php5.2-cli
/usr/bin/php5.4 -> ../lib/cgi-bin/php5.4
/usr/bin/php5.4-cli
/usr/bin/php5.5 -> ../lib/cgi-bin/php5.5
/usr/bin/php5.5-cli
/usr/bin/php6 -> ../lib/cgi-bin/php5.4
/usr/bin/phpize4.4
/usr/bin/phpize5.2
/usr/bin/phpize5.4
/usr/bin/phpize5.5
/usr/bin/phpize6 -> phpize5.4

---

Also max. /usr/bin/php5.5-cli - nix mit 5.6/7.x

Gruß
Franko

Nachtrag: beta3 bei dF mit PHP7.0.13

Der Manager installiert nun selbstständig eine neue Contao4.4 und eine anschließende Paket Installation von "bugbuster/contao-xing-bundle" hat auch funktioniert. Viele passende Pakete stehen ja noch nicht zur Auswahl.
Das ganze läuft noch sehr träge und sehr langsam... aber es läuft.

Same here mit UNLIMITED PLUS. @mlweb: welchen Tarif hast Du?

Zitat:

---

Zitat von Franko

Sorry, aber mit nem 1und1 (Tarif 1und1 Unlimited) ssh Zugriff und (ls -l /usr/bin/php/*) erhalte ich:

...

Also max. /usr/bin/php5.5-cli - nix mit 5.6/7.x

---

Genau das wundert mich ja. Dieses poplige alte Paket, hat soweit ich sehen kann kein ssh Zugriff, ist mit Sicherheit viel "schwächer" auf der Brust und auch deutlich älter (wenn ich mal den Infos von 1&1 glaube) als Dein Unlimited und dort kann ich die 7.1-cli verwenden. So bescheuert kann doch nicht mal 1&1 sein :D.