Dual Basic von 2012.Zitat:
Zitat von fiedsch
Druckbare Version
Dual Basic von 2012.Zitat:
Zitat von fiedsch
Das Paket kenne ich von einem Kunden. Da gibt es definitiv keinen SSH-Zugang und in der Regel ist zu normalen Zeiten vom RAM her bei 32 MB Ende Gelände. Insofern ist es zwar erstaunlich, dass ausgerechnet da eine PHP 7 CLI vorhanden ist, aber das wird letztlich nicht viel helfen. Ich kann mir nicht vorstellen, dass man dort mit C4 Erweiterungen anders als manuell wird installieren können. Aber ich schau mal nach, ob das 7.1 CLI dort auf dem Kundenserver auch verfügbar ist.
Habe das Verzeichnis /usr/bin/ mal eben ausgelesen, 7.1 gibts da nicht, aber dafür immerhin php5.6-cli. Immer noch besser als bei den großen und neueren Paketen :rolleyes:.
Zitat:
Zitat von Bas
https://hostingwerk.de/ ;)
Dass das dann nicht möglich ist habe ich ja weiter oben auch geschrieben. Hatte nur aus meiner Erfahrung mit diesem schwachen Paket gedacht es müsste bei den etwas besseren und neueren Paketen vielleicht doch klappen mit Contao 4. Ich bin gerade etwas fassunglos, dass da dann die PHP 7 cli nicht vorhanden ist :eek:. Das kann doch nicht wirklich war sein :mad:. Was denkt sich 1&1 eigentlich bei dieser Strategie?Zitat:
Zitat von tab
Na gut ich muss es ja nicht verstehen. An der Kundin kann ich dann mal weiter baggern wegen eines Hosting-Wechsels. Brauche ich mir wenigstens keine Gedanken zu machen, ob sie wunschgemäß vielleicht doch bei 1&1 bleiben kann. Das macht die Argumentation deutlich einfacher :D.
Juhuu, mit der Beta3 klappt die Installation bei der DF (PHP 5.6) nun auch bei mir. :D
Allerdings kann ich noch keine Erweiterungen installieren, da erhalte ich immer folgende Meldung:
Weiß jemand, was das bedeutet? :eek:Zitat:
Process terminated with exit code 255
Reason: Unknown error
Edit: Problem tritt auch mit PHP 7.0 auf ...
Doch! Ich hätte auch noch "1&1 Homepage Perfect von 2008" zu bieten. Auch mit mit ssh aber bzgl. der PHp-Versionen das gleiche Elend.Zitat:
Zitat von mlweb
Bei Aufruf der "contao-manager.phar.php" erhalte ich die Meldung: "No input file specified."
Dem "error.log" ist folgendes zu entnehmen:
Server: nginxCode:2017/06/21 07:21:45 [error] 32078#32078: *12 FastCGI sent in stderr: "Unable to open primary script: /var/www/domain.tld/web//web/app.php (No such file or directory)" while reading response header from upstream, client: XX.XXX.XXX.XX, server: domain.tld, request: "GET /contao-manager.phar.php/ HTTP/1.1", upstream: "fastcgi://unix:/var/lib/php5-fpm/web28.sock:", host: "domain.tld"
Document Root (Standard): /var/www/domain.tld/web/
Hat jemand einen Ratschlag dazu?
Diese Ordner Angabe sieht falsch aus:
Wie lautet der tatsächliche, absolute Pfad zur app.php?Code:/var/www/domain.tld/web//web/app.php
Bei einem zweiten Testsystem habe ich die Installation via CLI/ Composer in einem Unterverzeichnis "contao" eingerichtet. Der absolute Pfad zur "app.php" wäre demnach:
Oder muss der Ordner "contao" zwingend als "web" benannt werden?Code:/var/www/clients/client1/web27/web/contao/web
Du hast das mit dem web Ordner falsch verstanden. Du musst den DocumentRoot in den web Ordner der Contao Installation setzen, nicht die Contao Installation in einen Ordner namens web geben und dann dorthin den DocumentRoot setzen.
Verrätst du mir, welches Hostingpaket du hast? Ich hab ein Managed Hosting Pro und kann zwar Contao, aber noch keine Erweiterungen installieren. :(Zitat:
Zitat von codework
Hast du noch irgendwelche besonderen Einstellungen (php.ini ...) gemacht?
01: Der Versuch einer Contao 4 Managed Installation via Composer im Standard Document Root "/var/www/domain.tld/web", erzeugte den Fehler "Invalid Argument Exception / Project directory is not empty". Klar, denn dort liegen u.a. die Server Statistiken etc.
Hier stellt sich mir die Frage, warum muss das Verzeichnis leer sein?
02: Zwangsweise habe ich die Installation dann in den Unterordner "contao" ausgeführt und den Document Root auf "/var/www/domain.tld/web/contao" geändert. Als Ergebnis läuft Contao wie gewünscht.
03: Ändere ich den Document Root nun aber in "/var/www/domain.tld/web/contao/web", funktioniert weder der Aufruf der "contao-manager.phar.php" noch Contao selbst.
04: Unabhängig von einer vorhandenen Contao Composer Installation, führt der Aufruf der "contao-manager.phar.php" immer zu vergleichbaren Ergebnissen.Code:2017/06/21 10:57:27 [error] 30145#30145: *23 FastCGI sent in stderr: "Unable to open primary script: /var/www/domain.tld/web/contao/web/web/app.php (No such file or directory)" while reading response header from upstream, client: XX.XXX.XXX.XX, server: domain.tld, request: "GET /contao-manager.phar.php/ HTTP/1.1", upstream: "fastcgi://unix:/var/lib/php5-fpm/web27.sock:", host: "domain.tld"
2017/06/21 10:55:08 [error] 30145#30145: *11 FastCGI sent in stderr: "Unable to open primary script: /var/www/domain.tld/web/contao/web/web/app.php (No such file or directory)" while reading response header from upstream, client: XX.XXX.XXX.XX, server: domain.tld, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/lib/php5-fpm/web27.sock:", host: "domain.tld"
Demzufolge mutmaße ich, dass die Probleme entweder mit den Zeilen ~58-80 in der "contao-manager.phar.php" und/ oder der nginx Konfiguration in Verbindung stehen. Der betreffende Auszug in der nginx Konfiguration lautet:
Code:location /{FOLDER} {
client_max_body_size 100M;
root {DOCROOT}/{FOLDER}web;
index app.php;
try_files $uri $uri/ /{FOLDER}app.php$is_args$args;
location ~ ^/(app|app_dev|config|install)\.php(/|$) {
include /etc/nginx/fastcgi_params;
{FASTCGIPASS}
fastcgi_split_path_info ^(.+\.php)(/.*)$;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_intercept_errors on;
fastcgi_temp_file_write_size 10m;
fastcgi_busy_buffers_size 512k;
fastcgi_buffer_size 512k;
fastcgi_buffers 16 512k;
fastcgi_read_timeout 1200;
fastcgi_param HTTP_AUTHORIZATION $http_authorization;
<tmpl_if name='php' op='==' value='hhvm'>error_page 500 501 502 503 = @phpfallback{FOLDERMD5};</tmpl_if>
}
}
<tmpl_if name='php' op='==' value='hhvm'>
location @phpfallback{FOLDERMD5} {
client_max_body_size 100M;
root {DOCROOT}/{FOLDER}web;
include /etc/nginx/fastcgi_params;
{PHPFALLBACKFASTCGIPASS}
fastcgi_split_path_info ^(.+\.php)(/.*)$;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_intercept_errors on;
fastcgi_temp_file_write_size 10m;
fastcgi_busy_buffers_size 512k;
fastcgi_buffer_size 512k;
fastcgi_buffers 16 512k;
fastcgi_read_timeout 1200;
fastcgi_param HTTP_AUTHORIZATION $http_authorization;
}
</tmpl_if>
ResellerHosting BasicZitat:
Zitat von bibib
PHP 7.0.13 / Standard / "Sichere Einstellungen": AUS!
PHP.ini Änderungen gegenüber Server-Standard:
allow_url_fopen TRUE
display_errors FALSE
extension_dir /usr/local/lib/php_modules/7-70STABLE
session.save_path /kunden/XxXxXxX/var/session
extension = "intl.so" //bei PHP7 eigentlich überflüssig, habe es aber drin gelassen
Also keine besonderen Einstellungen.
Für den Manager festgelegtes Binary:
/usr/local/bin/php7-70STABLE-CLI
@mandrake: du musst den Ordner /var/www/domain.tld/contao/web erstellen, den DocumentRoot auf dieses Verzeichnis setzen, die contao-manager.phar.php auch in dieses Verzeichnis kopieren und dann den Contao Manager mit https://domain.tld/contao-manager.phar.php aufrufen.
@Fritz: Der fett markierte Teil des Document Roots "/var/www/domain.tld/web/contao/web" ist serverseitig festgeschrieben und kann nicht geändert, sondern nur ergänzt werden.
Spielt keine Rolle, dann halt dieser Ordner ;)
Du hast meinen obigen Punkt 03 gelesen?!
Ja - und meine Anleitung soll dein Problem beheben. Lösche alles, erstelle den Ordner /contao/web, etc.
Liegt die contao-manager.phar.php dann auch im Pfad meine-festvorgegebenen-ordner/contao/web? Das sieht mir bei Deiner obigen Beschreibung nicht so aus. Außerdem, wenn Du vorher schon irgendetwas im Ordner contao versucht hast, solltest Du alles löschen bevor Du neu im Ordner web anfängst.
Es sieht außerdem so aus, als ob der Ordner web doppelt vorhanden ist:
Code:"Unable to open primary script: /var/www/domain.tld/web/contao/web/web/app.php
Gleiches Problem wie im Post #145 auch bei Webhosthone. Contao-Installation mit dem Manager läuft sauber durch. Jegliche zusätzlichen Erweiterungen jedoch nicht.
Danke für die Info. Zumindest gibt es schon mal einen Output im Konsolenfenster ;-)Zitat:
Zitat von BugBuster
Doch auch damit ist ein Arbeiten auf 1&1 Hosting-Paketen noch nicht möglich.
Hier mal meine Fehlermeldung für den Versuch, den Contao-Cache zu bereinigen via Contao-Manager:
Task a9b7c3c495d1081d7b7056d1afe79cc7 started.
// Clearing the cache for the prod environment with debug
// false
[OK] Cache for the "prod" environment (debug=false) was successfully cleared.
// Warming up the cache for the prod environment with debug
// false
--------------------------------------------------------
Exception occured: The process "/usr/lib/cgi-bin/php5.6 '-q' '/homepages/x/xxxxxxxx/htdocs/contao-4/vendor/bin/contao-console' 'cache:warmup' '--env=prod'" exceeded the timeout of 60 seconds.
#0 phar:///homepages/x/xxxxxxxx/htdocs/contao-4/web/contao-manager.phar.php/vendor/symfony/process/Process.php(421): Symfony\Component\Process\Process->checkTimeout()
#1 phar:///homepages/x/xxxxxxxx/htdocs/contao-4/web/contao-manager.phar.php/vendor/symfony/process/Process.php(216): Symfony\Component\Process\Process->wait()
#2 phar:///homepages/x/xxxxxxxx/htdocs/contao-4/web/contao-manager.phar.php/vendor/tenside/core/src/Task/AbstractCliSpawningTask.php(53): Symfony\Component\Process\Process->run(Object(Closure))
#3 phar:///homepages/x/xxxxxxxx/htdocs/contao-4/web/contao-manager.phar.php/api/Tenside/Task/RebuildCacheTask.php(86): Tenside\Core\Task\AbstractCliSpawningTask->runProcess(Object(Symfony\Component\Process\Proce ss))
#4 phar:///homepages/x/xxxxxxxx/htdocs/contao-4/web/contao-manager.phar.php/api/Tenside/Task/RebuildCacheTask.php(52): Contao\ManagerApi\Tenside\Task\RebuildCacheTask->runSymfonyCommand('cache:warmup')
#5 phar:///homepages/x/xxxxxxxx/htdocs/contao-4/web/contao-manager.phar.php/vendor/tenside/core/src/Task/Task.php(173): Contao\ManagerApi\Tenside\Task\RebuildCacheTask->doPerform()
#6 phar:///homepages/x/xxxxxxxx/htdocs/contao-4/web/contao-manager.phar.php/vendor/tenside/core/src/Task/Runner.php(89): Tenside\Core\Task\Task->perform('/homepages/13/d...')
#7 phar:///homepages/x/xxxxxxxx/htdocs/contao-4/web/contao-manager.phar.php/vendor/tenside/core-bundle/src/Command/RunTaskCommand.php(83): Tenside\Core\Task\Runner->run('/homepages/13/d...')
#8 phar:///homepages/x/xxxxxxxx/htdocs/contao-4/web/contao-manager.phar.php/vendor/symfony/console/Command/Command.php(264): Tenside\CoreBundle\Command\RunTaskCommand->execute(Object(Symfony\Component\Console\Input\Ar gvInput), Object(Symfony\Component\Console\Output\ConsoleOut put))
#9 phar:///homepages/x/xxxxxxxx/htdocs/contao-4/web/contao-manager.phar.php/vendor/tenside/core-bundle/src/Command/RunTaskCommand.php(61): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvIn put), Object(Symfony\Component\Console\Output\ConsoleOut put))
#10 phar:///homepages/x/xxxxxxxx/htdocs/contao-4/web/contao-manager.phar.php/vendor/symfony/console/Application.php(887): Tenside\CoreBundle\Command\RunTaskCommand->run(Object(Symfony\Component\Console\Input\ArgvIn put), Object(Symfony\Component\Console\Output\ConsoleOut put))
#11 phar:///homepages/x/xxxxxxxx/htdocs/contao-4/web/contao-manager.phar.php/vendor/symfony/console/Application.php(223): Symfony\Component\Console\Application->doRunCommand(Object(Tenside\CoreBundle\Command\Ru nTaskCommand), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOut put))
#12 phar:///homepages/x/xxxxxxxx/htdocs/contao-4/web/contao-manager.phar.php/api/ApiApplication.php(71): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\Argv Input), Object(Symfony\Component\Console\Output\ConsoleOut put))
#13 phar:///homepages/x/xxxxxxxx/htdocs/contao-4/web/contao-manager.phar.php/vendor/symfony/console/Application.php(130): Contao\ManagerApi\ApiApplication->doRun(Object(Symfony\Component\Console\Input\Argv Input), Object(Symfony\Component\Console\Output\ConsoleOut put))
#14 phar:///homepages/x/xxxxxxxx/htdocs/contao-4/web/contao-manager.phar.php/api/console(74): Symfony\Component\Console\Application->run(Object(Symfony\Component\Console\Input\ArgvIn put), Object(Symfony\Component\Console\Output\ConsoleOut put))
#15 /homepages/x/xxxxxxxx/htdocs/contao-4/web/contao-manager.phar.php(55): require('phar:///homepag...')
#16 {main}
--------------------------------------------------------
Process terminated with exit code 1
Reason: General error
Ähnliches Ergebnis beim Versuch, die Pakete zu aktualisieren (s. Anhang).
Anhang 19481
Diese Meldungen kommen was ich hier sehe immer dann, wenn eine cgi Version von PHP verwendet wird statt einer cli Version.
Ob das wirklich damit zusammenhängt kann ich nicht sagen, ist aber auffällig.
eine /usr/bin/php5.6 oder /usr/bin/php5.6-cli gibt es bei dir nicht zufällig?
Wenn ich die providers.yml richtig verstehe prüft er auf Vorhandensein der cli Varinate zuerst und hängt noch ein memory Limit Parameter drann.
https://github.com/contao/contao-man...rs.yml#L48-L50
ist das ein ISPConfig Backend? Ich hatte in meiner ISPConfig den DocumentRoot via Apache Directives geändert -> sieht auf den ersten Blick verwirrend aus:Zitat:
Zitat von mandrake
- fett ist festgeschrieben - dann per FTP einen Unterordner in einem Webspace "web" erstellt und danach die direktive in der Optionen Registerkarte gesetzt.Code:DocumentRoot /var/www/clients/client1/web1/web/web
Nja, wird wohl bei dem Hoster so sein, dass da von Haus aus die document root im Ordner web oder irgendwo darunter liegt. So außergewöhnlich fände ich das jetzt nicht. Insofern macht es ja durchaus Sinn, den Unterordner contao/web als document root festzulegen.
Das maximale ist php5.5-cli:Zitat:
Zitat von BugBuster
Anhang 19483
Aber zumindest habe ich es nun geschafft, den Cache per Kommandozeile zu löschen:
php5.5-cli /homepages/x/xxxxxxxxx/htdocs/contao-4/vendor/bin/contao-console cache:clear --no-warmup -e prod
Ein Update per Kommandozeile ist jedenfalls nicht möglich, da der liebe alte RAM bei 1&1 nicht mitspielt:
Anhang 19484
Möglichweise liegt es ja auch an der Einstellung zum memory_limit: /usr/bin/php{major}.{minor}-cli: ['-d', 'memory_limit=-1']
Na ja, dann muss ich wohl doch mein 1&1 ProfiSeller Konto löschen ;-)
Ist hier zu finden https://community.contao.org/de/show...Fehlermeldung)
@mlweb: Ja, die Datei lag im Ordner ".../contao/web", auf welchen auch der Document Root eingestellt war.
@Fritz: Ich habe nun - nur um wirklich sicher zu gehen - nochmals Document Root auf Standard gesetzt und bestehende Inhalte komplett gelöscht.
Dann wieder neu das Verzeichnis ".../contao/web" und den Document Root darauf eingerichtet, dann die Datei "contao-manager.phar.php" dort abgelegt und entsprechend über "http://domain.tld/contao-manager.phar.php" aufgerufen.
Das Ergebnis ist immer noch der gleiche Fehler: " ... Unable to open primary script: /var/www/domain.tld/web/contao/web/web/app.php (No such file or directory) ..."
@Seefahrer: Das hast Du korrekt erkannt, denn genau da liegt das Problem für das ich eine Lösung suche. ;)
Edit: Nur um das klar zu stellen: Der Ordner "web" ist natürlich nicht wirklich doppelt vorhanden. Deshalb auch mein Hinweis auf die entsprechenden Zeilen in der "contao-manager.phar.php" und meiner nginx Konfiguration als mögliche Ursache.
@kretschi: Warum machst Du diesen Eintrag in ISPConfig nicht einfach unter "Website" im Register "Domain > Erweiterte Einstellungen > Abweichender Document Root"? Fahre übrigens nginx, wobei mir diverse Anpassungsversuche an meiner o.g. Standard Konfiguration leider auch noch keinen Erfolg gebracht haben. Trotzdem danke für den Hinweis.
Hm, was zB macht diese Zeile hier:Zitat:
Zitat von mandrake
?Code:try_files $uri $uri/ /{FOLDER}app.php$is_args$args;
Nur interesssehalber, da ich auf einem Server ebenfalls ISPConfig nutze, da aber unter "Website => Domain" nirgends "Erweiterte Einstellungen" sehe. Welche ISPConfig Version nutzt Du?Zitat:
Zitat von mandrake
VG
Hallo,
ich habe nach einigen Schwierigkeiten Contao 4.4 über den Contao Manager installiert und kann diesen nun auch aufrufen.
Zum Schluss erschien die Meldung, dass ich nun in das Install Tool wechseln solle, was ich auch wollte. Leider erhalte ich dabei immer wieder nur die Meldung, dass die Seite nicht existiert.
Der Root Pfad der Subdomain ist der Web Ordner, wie gefordert. Die Berechtigungen passen auch und leider wird im zugehörigen Log nichts angezeigt (es existiert nicht unter /var/log).
Wisst ihr wo der Fehler liegt oder habt ein paar Tipps, was ich prüfen sollte?
LG Stefan
Existiert im /web Ordner eine .htaccess? Verwendest du nginx statt Apache?Zitat:
Zitat von stefanabg
Eine .htaccess gibt es leider nicht, ich benutze Apache
Dann muss bei der Installation etwas schief gelaufen sein. Nach der erfolgreichen Installation von Contao sollte sich im Ordner /web eine .htaccess Datei befinden (und auch im Root der Contao Installation).Zitat:
Zitat von stefanabg
@w3scout: Ich nutze Version 3.1.0.0. So weit ich mich erinnere (ohne Gewähr), sind die "Erweiterten Einstellungen" aber schon seit min. 1-2 Jahren verfügbar. Vielleicht eine Sache der Konfiguration?
BTW: Steht Dir im Bereich "Website" der Reiter "Optionen" zur Verfügung? Wenn nein, nutzt Du vielleicht ein Shared Hosting Angebot, bei dem bestimmte Bereiche gesperrt sind?!
Ok, ich habe nun noch einmal den Contao Manager in einem anderen Browser geladen und es funktionierte. die .htaccess Datei wurde nun auch angelegt...mit Firefox klappte es nicht.
Kann mir vielleicht gerade mal jemand sagen, seit wann bzw. für welchen Zeitraum die Alpha Version vom Manager zur Verfügung stand? Stand diese nur dem Core Team bzw. einigen wenigen "Eingeweihten" oder z.B. auch Contao Premium Partnern oder anderen Nutzerkreisen zum testen zur Verfügung?
Die Alpha Tester wurden vom Team persönlich eingeladen. Wir haben einige Wochen getestet, zumindest war ich solange dabei.
Warum fragst du?
Nur so aus Interesse. Hatte im Hinterkopf, dass die Alpha closed war, war mir aber auch nicht mehr ganz sicher.
So sieht's bei mir auch aus - Ich bin auf der Registerkarte Optionen - allerdings keine erweiterten Optionen - mit denen man direkt den DocumentRoot verstellen könnte. Vielleicht ist das bei ISPConfig mit ngix der Fall.Zitat:
Zitat von w3scout
Für mich - ich setze da auch paar andere Einstellungen in den Directiven - passt das schon - so habe ich alles im Blick was die Website angeht.
Meine ISPCconfig ist die 3.1.3
Hallo zusammen!
Ich habe die contao-manager.phar.php im Verzeichnis http://domain.de/web/ abgelegt. Beim Aufruf erscheint jedoch ein "Not found" error und in der Browserleiste steht plötzlich http://domain.de/contao-manager.phar.php/. Was läuft hier schief?
Der Contao-Check sagt "Sie können Contao 4.x installieren". Hoster ist All-Inkl.
Und die Domain zeigt in das web/ Verzeichnis? Der Aufruf muss über domain.de/contao-manager.phar.php erfolgen können.
Hi Markus,Zitat:
Zitat von mapfei
leg Dir ein Verzeichnis "contao" und darunter dann ein Verzeichnis "web" an und kopiere dann die contao-manager.phar.php in dieses "web"-Unterverzeichnis. Der DocumentRoot im KAS muss dann auf /contao/web/ zeigen.
Dann die contao-manager.phar.php wie schon von Glen geschrieben folgendermaßen aufrufen:
Zitat:
Und die Domain zeigt in das web/ Verzeichnis? Der Aufruf muss über domain.de/contao-manager.phar.php erfolgen können.
Prima, funktioniert! Ich danke euch!
Das zum Abschluss der Installation folgende Meldung erscheint ist "normal"?
Anhang 19496
Provider 1und1 / Tarif 1und1 Unlimited / Domain auf PHP7.1 CGI
- Download .zip Archiv und Installation: Geht
- Contao-Manager und Installation: Geht mit der beta3 ???
Mit der vorherigen CM Version ist er mir schon beim Task Aufruf abgesprungen.
Mit der Beta3 lief alles sauber durch (Das ganze ging sogar sehr flott).
Und ehrlich ich verstehe nicht warum: Der CM setzt den binary auf /usr/bin/php7.1-cli
Diesen gibt es nicht (wie schon hier mehrmals erwähnt bei 1und1 max. /usr/bin/php5.5-cli).
Beim Versuch eine 4er Erweiterung zum Test über den CM zu installieren (madeyourday/contao-rocksolid-slider) kam dann aber sofort:
??Zitat:
Using version ^2.0 for madeyourday/contao-rocksolid-slider
/homepages/3/xyz/htdocs/contao4/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 255
Reason: Unknown error
Frank
Das manager-bundle wird bei der Installation über den Manager nicht mehr installiert oder wie verstehe ich das?
Ja, ist nur zur Info und keine FehlermeldungZitat:
Zitat von mapfei
Deutet auf zuwenig RAM hinZitat:
Zitat von Franko
Wegen 1und1 s.o.
Test SSH Zugriff und dann:
Folgendes geht:Code:[Prompt]/usr/bin/php7.1-cli contao-manager.phar.php -v
[Prompt]-bash: /usr/bin/php7.1-cli: No such file or directory
Code:[Prompt]/usr/bin/php5.5-cli contao-manager.phar.php -v
Code:[Prompt]/usr/bin/php5.5-cli contao-manager.phar.php integrity-check
(Pfad überarbeitet - muß ja 5.5 ein - sorry)Code:[Prompt]/usr/bin/php5.5-cli contao-manager.phar.php self-update
Ist jetzt die beta4
Frank
Doch, das ist ja grad der Unterschied zur Standard Edition.Zitat:
Zitat von mapfei
Kannst du mitZitat:
This bundle adds manager functionality to Contao core. It provides a Symfony skeleton that allows full application management using the Contao Manager GUI.
auf Kommandozeile auch gut sehen, hier mal ein Ausschnitt:Code:composer info
Code:contao/calendar-bundle 4.4.0 Adds calendar functionality to Contao 4
contao/comments-bundle 4.4.0 Adds comments functionality to Contao 4
contao/core-bundle 4.4.0 Contao 4 core bundle
contao/faq-bundle 4.4.0 Adds FAQ functionality to Contao 4
contao/installation-bundle 4.4.0 Required to install and update Contao 4
contao/listing-bundle 4.4.0 Allows to list arbitrary data in the Contao 4 front end
contao/manager-bundle 4.4.0 Contao 4 manager bundle
contao/news-bundle 4.4.0 Adds news functionality to Contao 4
contao/newsletter-bundle 4.4.0 Adds newsletter functionality to Contao 4
In meiner Installation gibts kein manager-bundle: Anhang 19497Zitat:
Zitat von BugBuster
Hängt das evtl. mit der Fehlermeldung in Beitrag #185 zusammen?
Das manager-bundle Paket wird dort absichtlich nicht gelistet. Du musst dir die composer.json selbst ansehen oder es so machen wie BugBuster beschrieben hat.Zitat:
Zitat von mapfei
Nein, ich glaube das kannst du einfach ignorieren.Zitat:
Zitat von mapfei
Jo, Pakete die per Abhängigkeit geladen wurden werden im Manager nicht aufgelistet.
Gilt auch für externer Erweiterungen. wer zum Beispiel von mir "bugbuster/contao-visitors-bundle" installiert sieht auch nicht, das "bugbuster/contao-botdetection-bundle" mit installiert ist und schon gar nicht was das alles noch mitzieht.
Naja, das manager-bundle ist keine Abhängigkeit, das steht ja direkt im require der composer.json.
Alles klar. Danke für die Info!Zitat:
Zitat von Spooky
Leider noch nicht - echt komisch. Geht sonst relativ schnell.Zitat:
Zitat von contaouser1
Ich meld mich, sobald ich was bekomme.
Habe die beta4 mal bei Domainfactory unter PHP7 getestet:
- PHP CLI wird automatisch richtig erkannt
- Contao Installation läuft ohne Fehlermeldungen durch
- Finished without error.
- Install-Tool wird korrekt aufgerufen
- Pakete können anschließend (relativ) problemlos installiert werden
Kleiner Spaß am Rande, ein Vergleichstest:
Code:Test1: Manager
contao-manager.phar.php in /web legen
Script mittels vorbereiteter SubDomain aufrufen
Installation inkl. Install-Tool und Admin anlegen durchlaufen lassen
Dauer bis zum funktionierenden Backend: knapp 7 Minuten.
Egal welche Variante... das ist richtig schnell! Respekt!Code:Test2: Composer direkt
Via SSH einloggen
zum Zielverzeichnis navigieren (/cms/domain)
Contao via Composer installieren lassen
Installtool in vorbereiteter Subdomain aufrufen DB, Admin anlegen
Dauer bis zum funktionierenden Backend: knapp 3 Minuten.
Vielen Dank!Zitat:
Zitat von BugBuster
Installation / Aktualisierung und Cache leeren klappt nun mit dem Contao-Manager beta4 bei DF!
Ich habe dies getestet bei den Tarifen ManagedHosting Medium und Ultimate.
Für alle DF-User zur Info - so habs ich gemacht:
- Subdomain auf Unterverzeichnis web setzen
- PHP-7-70-STABLE
- PHP-ini-Editor
-- Haken bei allow_url_fopen
-- Im PHP-ini-Editor folgendes ergänzt:
[Extension]
extension_dir = "/usr/local/lib/php_modules/7-70STABLE"
extension = "intl.so"
Antwort von DomainFactory:Zitat:
Zitat von t.mayer
****************************
Wir haben die Root-Zertifikate des Servers soeben um jenes "Comodo RSA Certification Authority (SHA-2)" erweitert sodass die Verbindung zu api.ipify.org nun ohne Fehler hergestellt werden kann.
****************************
Nochmals zu 1und1 (alter Tarif Unlimited)
Mit dem CM beta3/4 lief die Installation bei mir durch... Wobei ich noch immer nicht weiß warum????
Habe jetzt versucht über den CM beta5 Erweiterungen zu installieren - brechen immer ab.
Habe dann versucht dies manuell über den Composer zu installieren:
Gibt mir 256M an - sollte aber bei diesem Tarif max. 512M sein - siehe hier.Zitat:
/usr/bin/php5.5-cli -i | grep memory_limit
Test Erweiterung terminal42/notification_center:
versucht mitCode:/usr/bin/php5.5-cli composer.phar require terminal42/notification_center
Fatal error: Out of memory (allocated 606339072) (tried to allocate 32 bytes) in phar:///homepages/3/XXX/htdocs/contao4/composer.phar/src/Composer/DependencyResolver/Rule2Literals.php on line 53
brachte es auch nicht.Code:/usr/bin/php5.5-cli -d memory_limit=-1 composer.phar require terminal42/notification_center
Fatal error: Out of memory (allocated 606863360) (tried to allocate 64 bytes) in phar:///homepages/3/XXX/htdocs/contao4/composer.phar/src/Composer/DependencyResolver/Rule2Literals.php on line 53
Test Erweiterung bugbuster/contao-be_user_online-bundle:
Code:/usr/bin/php5.5-cli -d memory_limit=-1 composer.phar require bugbuster/contao-be_user_online-bundle
[InvalidArgumentException]
Could not find package bugbuster/contao-be_user_online-bundle at any version matching your PHP version 5.5.38.0
hat auch nichts gebracht.Code:/usr/bin/php5.5-cli -d memory_limit=-1 composer.phar --ignore-platform-reqs require bugbuster/contao-be_user_online-bundle
Ich würde gerne wissen ob dies ausschließlich ein memory_limit Problem ist oder auch noch mit der php5.5 CLI zusammenhängen kann.
Die neuen 1und1 Tarife "Unlimited Plus/Pro" sollen in dieser Hinsicht deutlich mehr Leistungen bieten. Siehe hier.
Würde das helfen???
Zitat Andreas (CM) auf meine Frage wieso nur 5.5-cli:
D.h. theoretisch sollte der Manager mehr schaffen als du auf der Konsole.Zitat:
auf der SSH-Konsole gibt es maximum 5.5 CLI
aber der Manager läuft scheinbar unter einem anderen Chailroot, da stehen auch neuere CLIs zur verfügung
Guckst Du: https://github.com/contao/contao-man...rs.yml#L42-L50
Hm, ?!?,Zitat:
aber der Manager läuft scheinbar unter einem anderen Chailroot, da stehen auch neuere CLIs zur verfügung
Ich hab mich gewundert das der CM auf 1und1 den binary-pfad autom. auf /usr/bin/php7.1-cli setze, obwohl dieser über die Shell nicht verfügbar ist.
Daher auch die Verwunderung, das die Installation dennoch funktioniert.
Wenn der CM dann das bei der Installation so hinkriegt, müßten dann doch auch die Erweiterungen installiert werden können???
Frank
Da gibt es dann bei Überprüfen der Abhängigkeiten wieder Probleme mit dem RAM. Zumindestens war das in meinem DualBasic-Paket so.
Dazu kam noch die Aussage:
Zitat:
Memory ist bei 1&1 aber gar nicht das Problem, mit dem Flag gemäss providers.yml hatte ich keine limiten mehr, aber der Prozess wurde nach gewisser Zeit abgeschossen
Nachtrag (Sorry),
zum Verständnis: Der CM hat mehr Möglichkeiten als über den direkten shell/composer Aufruf (hinsichtlich der php CLI Version).
Bedeutet doch dann, das auf 1und1 NUR noch ein Problem mit den memory_limit besteht und evtl. bei den neuen Tarifen auch Erweiterungen installiert werden sollten:
Siehe auch Beitrag hier ...
Ups, Du warst schneller.Zitat:
Zitat von BugBuster
Also dann würde dies auch nicht nutzen: Infos,
wenn es nicht am memory liegt ...
Da gibts mehr memory und mehr gleichzeitige Prozesse - weiß aber nicht wie hoch die MAX_EXECUTION_TIME dann ist, was demnach hier relevant wäre.
Frank
Andreas hat derzeit Probleme, das der Prozess einfach abgeschossen wird bevor er fertig ist, was wohl nichts mit der PHP Laufzeit zu tun hat.
Wenn das so ist und die neuen Pakete eine höhere Laufzeit der Prozesse erlaubt, dann könnte das funktionieren.
Das sind mir aber alles zu viele Wenn und Könnte.
Zitat
Zitat:
...nicht von PHP (Execution Time) sondern vom Prozessmanager (SIGKILL) beendet.
Genau das kriege ich ja nicht raus - da steht ja nur was von mehr gleichzeitigen Prozessen aber nicht wieviel Zeit je Prozess zugestanden wird ...Zitat:
Zitat von BugBuster