Sefrengo installation mit dutzenden Projekten Einstellungen

[MaZderMind]

Hallo
Wir sind eine (sehr) kleine Webagentur (bisher 5 Projekte) und für mich als einzigem Techniker ist die Wartung und Instandhaltung dieser 5 (Dedi-)Projekte ein haufen Arbeit
Ich hab mich gefragt, ob es nicht für unsere (Klein)kunden einfacher wäre, in zukunft nurnoch eine einzige Sefrengo-Installation auf einem Webspace anzulegen und dann pro Kunde nurnoch ein neues Projekt anzulegen, eine neue Domain zu bestellen und alles über ein Backend zu kontrollieren.
Wird Sefrengo mit 10 oder 15 Projekten fertig? Wie sieht es mit der Geschwindigkeit aus (ich kenne das Array-Problem für Seiten & Ordnern)?
Was haltet ihr von dieser Herangehensweise?

Gruß, Peter

[Guest_summerbrother_*]

Ich habe derzeit 6 Projekte mit einem Backend laufen, davon sind zwei Seiten mit ein bischen mehr Traffic und vier dümpeln sich so dahin.

Mit meinem Umstieg von Dedi habe ich mir auh auf die Fahne geschrieben alles in einem zu verwalten. Bis jetzt funktioniert es tadellos. Das Anlegen von neuen Projekten ist immer ein wenig Zirkus, weil ein paar kleine Pfadmacken und ein paar Rechtemacken dann drin sind. Mit der nächsten Version sind die vielleicht weg.

Sehr bequem ist das verwenden des gemeinsamen Modulpools und der gemeinsamen js. So spart man sich viel Arbeit und Fehler bei Updates pder Änderungen.

Für die Zukunft wünsche ich mir noch mehr Unterstützung für Mehr-Projekt-Umgebung. Vileleicht ja sogar ein gemeinsamer Layout-, Css- oder Contentpool.

[amk]

kann man alles machen ... finde ich aber auf der anderen seite wieder ein wenig riskant. wenn was schief geht (hacker, db-crash, db-update etc.), geht's für alle kunden schief ... und die gewissen gefahren sollte man im vergleich zum aufwand mehrerer cms-installationen sehen.

und bzgl. performance usw. - keine ahnung.

[gunwalt]

Wird Sefrengo mit 10 oder 15 Projekten fertig? Wie sieht es mit der Geschwindigkeit aus (ich kenne das Array-Problem für Seiten & Ordnern)?

Theoretisch wird das sicherlich gehen, aber die Menge beinhaltet auch einen ziemlichen Verwaltungsaufwand. Ich persönlich würde bei der Hälfte Schluss machen.

kann man alles machen ... finde ich aber auf der anderen seite wieder ein wenig riskant. wenn was schief geht (hacker, db-crash, db-update etc.), geht's für alle kunden schief ... und die gewissen gefahren sollte man im

Sicherlich richtig, aber wie häufig crasht eine DB? Sicherlich je mehr gleichzeitig drauf zugreifen...

[alexander]

für mich wäre eines der wesentlichen kriterien, dass die inhalte aller kunden in einer db / einer tabellenstruktur liegen.

ein selektives wiederherstellen von projekten ist somit nicht mit vertretbaren aufwand machbar. löscht sich z.b. ein kunden (warum auch immer) seine inhalte, dann kann man nicht einfach die db rücksichern, weil dies alle anderen kunden direkt betreffen würde.

[Guest_summerbrother_*]

Stimmt. Aber wär das nicht ein Ansatz über die Sicherung nachzudenken ?
Immerhin wird in der DB ja alles nach Projekt-ID abgelegt.

Mal als Laie gesagt: Ich stell mir mal irgendwann ein Knöpfchen "Projekt sichern" vor. Da werden dann die html-Daten und DB-Einträge für das Projekt gesichert.
Ist das soweit weg ?

[bjoern]

Die Performance ist bei mehreren Projekten vollkommen OK. Den einzigen Pferdefuss, den wir noch drinne haben, sind die $con_side und $con_tree Arrays. Diese wirken sich aber immer nur auf eine Sprache aus, und zwar die, die gerade angewzeigt wird.

Problematisch sehe ich die Vergabe der Pfade auf unterschiedlichen Domains an. Da mußt Du vermutlich ein wenig basteln, bis das vernünftig funktioniert. Denke aber, das Dich so etwas nicht vor unlösbare Probleme stellt.

Mal als Laie gesagt: Ich stell mir mal irgendwann ein Knöpfchen "Projekt sichern" vor. Da werden dann die html-Daten und DB-Einträge für das Projekt gesichert.
Ist das soweit weg ?

Ja, ist von unserer Seite sehr weit weg. Bevor das kommt, kommt eine Sicherung des gesamten Systems, aber auch das ist derzeit nicht geplant. Mein Schwerpunkt ist nach wie vor die API, schwerpunktmässig das Model, mit Zielsetzung MVC. Das wird mich sicher noch ein gutes Jahr bei Laune halten. Wer eine solche Funktion proggen möchte, kann das natürlich gerne tun. Gegen mehr Manpower ist ja nichts einzuwenden.

[Guest_summerbrother_*]

QUELLTEXT

Problematisch sehe ich die Vergabe der Pfade auf unterschiedlichen Domains an. Da mußt Du vermutlich ein wenig basteln, bis das vernünftig funktioniert.

Das ist mit ein bischen probieren gar nicht so schwer. Ich war überrascht wie tolerant SF mit Subdomain/Domains ist.

QUELLTEXT

Wer eine solche Funktion proggen möchte, kann das natürlich gerne tun. Gegen mehr Manpower ist ja nichts einzuwenden.

ich würd wahrscheinlich nicht mal ansatzweise sowas hinbekommen

[Guest_Jens Wurster_*]

Derzeit verwalte ich mehrere Projekte mit DeDi, die alle auf ein Backend zugreifen. Dabei erhält jeder Kunde noch seine eigene Datenbank und sein eigenes Verzeichnis auf meinem Server. Immo ist bei der ganzen Sache noch einiges an Handarbeit gefragt, wenn man einen neuen Kunde anlegt. Sobald ich allerdings auf Sefrengo umsteige, werde ich das ganze weiter automatisieren.

Grüße Jens

[feniweb]

Einfache Datensicherung finde ich jedoch schon eine relativ wichtige Sache für ein WCMS.

In Dedi gibts ja ein Plugin "MySQLDumper" könnte man das nicht an SF anpassen da hätte man schon einen kleinen Schritt mehr Sicherheit.

Gruss

[alexander]

In Dedi gibts ja ein Plugin "MySQLDumper" könnte man das nicht an SF anpassen da hätte man schon einen kleinen Schritt mehr Sicherheit.

also das tool funktioniert ja standalone genauso - das kannst du sofort einsetzen wenn du willst.

und die datensicherung ist meines erachtens nicht grundsätzlich teil eines webcms, sondern sollte ein bestandteil der systemumgebung sein in welcher es läuft.

Anregungen siehe http://forum.sefrengo.org/index.php?showto...3&hl=backup

[MaZderMind]

Naja der Dumper kann aber auch nur das komplette System auf einen Schlag sichern...

Gruß, Peter