Standalone mode may be the only mode?! [german]

[tristanlins]

Mal in Deutsch, weil dass die Diskussion glaube ich etwas erleichtert.

@discordier hat Vorgeschlagen, den Standalone Modus (siehe #218, vergleichbar mit dem Install Tool oder Live Update Tool) als einzigsten Modus anzubieten. D.h. es gäbe keinen in das Backend integrierten Client mehr.

Klickt man auf die Paketverwaltung würde man (über ein One-Time-Token) direkt an der Paketverwaltung angemeldet.
Wird die Paketverwaltung direkt aufgerufen muss man sich entweder mit seinen BE User Daten (nur Administratoren) oder dem Install Passwort anmelden.
Der Wechsel zurück zum Contao Backend erfolgt dann über einen Link im Client.

Ich bin unschlüssig was den Vorschlag angeht.
Auf der einen Seite würde uns das durchaus einiges mehr Freiheiten für den Client geben. Außerdem könnten wir die Nutzer direkt darauf erziehen, dass es einen Modus gibt, in dem der Client auch ohne Contao Backend läuft (was wichtig ist, wenn ein Update schief gelaufen ist und das Backend nicht mehr erreichbar ist).
Auf der anderen Seite bin ich mir nicht sicher, ob das von der Usability so gut wäre. Viele Nutzer wären sicher verunsichert darüber, wenn plötzlich das gewohnte Backend weg ist.

Ich möchte den Vorschlag deshalb einfach mal zur Diskussion stellen.

/cc @discordier @MacKP @frontendschlampe @tim-bec @leofeyer @aschempp

[aschempp]

wie ich mit @tristanlins schon mal kurz diskutiert habe, hat für mich Composer für Contao 4 Priorität. In diesem System wäre das relativ einfach umzusetzen. Eine eigene Route und einen eigenen Controller, und vielleicht noch ein eigenes ENV. Natürlich wäre es noch immer möglich dass Symfony gar nicht mehr läuft, aber diesen Fall gab es jetzt ja auch im ER und dann muss man halt per FTP ran... eine komplett unabhängige Applikation halte ich für overengineering (hint: http://blog.ircmaxell.com/2014/10/an-open-letter-to-php-fig.html)

/cc @Toflar

[tim-bec]

Das gewohnte Backend darf nicht verloren gehen. Aber ich sehe nicht das Problem den Client technisch als Standalone zu entkoppeln und das Backend Template zu "clonen".

[tristanlins]

Natürlich wäre es noch immer möglich dass Symfony gar nicht mehr läuft, aber diesen Fall gab es jetzt ja auch im ER und dann muss man halt per FTP ran...

Genau das wollen wir verhindern, weil es vor allem durch Timeouts (max_execution_time limit) auf Shared Hostern nicht selten passiert, dass ein Composer Update nicht vollständig ist und dir damit Contao killt. Da hilft dir FTP nichts, da musst du per Konsole ran. Und komme mir bitte nicht wieder mit "das haben wir doch jetzt auch nicht", nur weil wir es jetzt nicht haben heißt es nicht, dass es nicht sinnvoll ist, wir haben uns da schon was bei gedacht, aus rein praktischer Erfahrung die wir mit dem Client bisher gemacht haben ;-)

eine komplett unabhängige Applikation halte ich für overengineering (hint: http://blog.ircmaxell.com/2014/10/an-open-letter-to-php-fig.html)

Sry, aber dem kann ich mich zu 100% nicht anschließen. Ich glaub dafür bin ich zu sehr Java Entwickler. Imo könnten die PSR's ruhig noch etwas weiter gehen. PSR-3 ist bspw. unbrauchbar für "richtiges" Logging. Ich nutze nicht ohne Grund in einigen Fällen lieber Monolog direkt, anstelle des LoggerInterface.

Aber ich sehe nicht das Problem den Client technisch als Standalone zu entkoppeln und das Backend Template zu "clonen".

Den Client optisch so aussehen zu lassen wie das Backend ist kein Problem, solange man nicht ein eigenes Backend Theme verwendet... :-\

[tim-bec]

Composer für Contao 4 Priorität. In diesem System wäre das relativ einfach umzusetzen.

@aschempp - die Umsetzbarkeit sehe ich nicht als Problem, sondern eher wie man die Nutzer bei der Stange hält. Ein abgekappelster Modus fühlt sich immer komisch und unsicher an (hint: externe Checkout / Bezahlprozesse in Shops). Wir müssen vermeiden, das die normalen Nutzer Composer nicht auch noch wegen solch einer Umstellung ablehnen.

solange man nicht ein eigenes Backend Theme verwendet... :-\

Guter Punkt. Aber jemand der ein anderes Backend-Theme installiert würde ich so viel Transferleistung zutrauen darin kein Problem zu sehen.

[WorkerBeeEu]

Für diesen externen Modus spricht ganz klar die Zugriffssicherheit nach Problemen mit Erweiterungen bzw. gecrashten Contao. Magento hat ja die Plugin-Verwaltung und die Update-Mechanismen allesamt in einem gesonderten Bereich.

Andere CMS-Systeme wie Joomla und WordPress [ja, WP als CMS, reden wir nicht drüber ;-) ] haben hingegen das alles vollständig integriert und für Redakteure massiv vereinfacht - so kann unterm Strich jeder das System aktuell halten und das sehe ich als Stärke. Nicht jeder, der eine Webseite betreibt, hat auch den technischen Hintergrund.

Wird Contao durch composer zum Kandidaten, der nur noch auf entsprechenden Servern läuft, wird das irgendwann wirklich Frust bereiten.

Ich denke es wäre durchaus wichtiger sich in die Entwicklung von composer einzubringen um diesen monströsen RAM-Verbrauch in den Griff zu bekommen. Die Auflösung von Abhängigkeiten scheint ja der Knackpunkt der langen Laufzeit und des Speicherverbrauchs zu sein, der dazu führt, dass man composer nicht ohne Bedenken ins Backend integrieren kann.

[aschempp]

Du wärmst hier sehr alte Themen auf ;-)

Ich denke es wäre durchaus wichtiger sich in die Entwicklung von composer einzubringen um diesen monströsen RAM-Verbrauch in den Griff zu bekommen.

Composer hat in den letzten Monaten diesbezüglich sehr viel getan. Aber natürlich wäre es wunderbar wenn du dich in die Entwicklung von Composer einbringst und das RAM-Problem löst 😉

[WorkerBeeEu]

@aschempp Jepp, das tu ich ;-) Das Problem bleibt ja nach wie vor bestehen. Zwar ändert sich das mit dem Contao Manager, aber bis dahin haben wir ja noch ca. 2 Jahre. Das RAM-Problem hat aber bisher noch keiner annähernd in den Griff bekommen, was spätestens bei der 4.4 LTS wieder thematisiert werden darf, wenn dann alle damit arbeiten. Schauen wir mal =)