# Suche CMS

## Silicoid

Hi

bin schon seit einiger Zeit auf der Suche nach einem CMS für mich. Leider hab ich bisher nichts gefunden, was das kann, was ich will. Erstmal was hab ich zur Verfügung

 apache (kann keine weiteren Module hinzufügen)

 php ink. mod_php

 perl, ohne mod_perl, weitere Perl Module sind kein Problem. 

 mysql

Was soll es können (der wichtigkeit nach geordnet):

 Es sollen hinten statische Seiten rauskommen. Ich möchte nicht, daß jede Seite bei jedem Aufruf neu generiert wird.

 Über Web bedienbar

 Möglichst einfach. Ich will kein Enterprise Site Management

 Perl (perl kann ich, php eher net)

Für Tips wäre ich sehr dankbar.

Silicoid

----------

## b3cks

Narf...

 :Arrow:  https://forums.gentoo.org/viewtopic-t-517451.html

 :Arrow:  https://forums.gentoo.org/viewtopic-t-462962.html

 :Arrow:  https://forums.gentoo.org/viewtopic-t-363109.html

 :Arrow:  https://forums.gentoo.org/viewtopic-t-266222.html

 :Arrow:  https://forums.gentoo.org/viewtopic-t-304122.html

 :Arrow:  https://forums.gentoo.org/viewtopic-t-228743.html

Um nur mal die deutschsprachigen Threads dazu aufzulisten.

----------

## Silicoid

Hi

 *b3cks wrote:*   

> 
> 
> Um nur mal die deutschsprachigen Threads dazu aufzulisten.

 

ist mir schon klar, daß es dazu einiges gibt. Ich such auch nicht erst seit gestern, sondern schon seit > 1 Jahr und hab nichts gefunden.

Schwierig sind halt die Anforderungen die ich hab. Die meisten scheiden schon aus, weil ich statische Seiten, also html Files gerneriert haben möchte. Warum sollte eine Seite meiner Page, die ich vielleicht nur einmal erstellt habe jedes mal neu generiert werden?

Es gibt zwar sehr viele Scripten, die html Files generieren, aber keine mit einem Webfrontend (zumindest hab ich da nix gefunden). Ich hab keine Shell auf dem Webserver. Wenn ich dann mal eines gefunden habe, dann ist es gleich eines für Enterprise Site Management und braucht extra Konfigs im Apache (mod_perl oder fastcgi). Die kann ich nicht machen. Ich bin nur normaler User.

Hab auch schon auf Seiten wie cmsmatrix.org gesucht. Auch da nicht wirklich was gefunden.

----------

## misterjack

cms != statische html-Seiten, das ist dir schon klar?

----------

## Keepoer

 *misterjack wrote:*   

> cms != statische html-Seiten, das ist dir schon klar?

 

Wollte ich auch gerade meinen  :Smile: 

Ich nutze teilweise CMSMadeSimple (wurde hier auch vor nicht länger als nem Monat empfohlen). Braucht zwar immer noch eine MySQL-Datenbank, ist aber richtig schnell und sehr komfortabel einzurichten.

Sonst gibt es noch diese XHTML+CSS-Systeme, wo du zum Teil deine Daten schon als XML eingeben kannst (glaube ich). Wenn man seine Seiten selten verändert, dann finde ich diese ganz gelungen. XML lässt sich auch relativ gut parsen und html-Seiten ausgeben. Wie schwierig das ist - keine Ahnung  :Wink:  Es gibt dort auch Lösungen mit Perl.

Unter Perl sind wohl auch einige CMSs' geschrieben, aber die gehen eher in die Größenordnung von Typo3.

----------

## oscarwild

 *misterjack wrote:*   

> cms != statische html-Seiten, das ist dir schon klar?

 

Ich vermute, Silicoid möchte die Seiten zum Hosten statisch aus dem CMS generieren, was durchaus sinnvoll ist, wenn man kostenfreien Webspace benutzen möchte, der kein PHP etc. bietet. Manche CMS unterstützen die statische Generierung nativ, bei anderen muss man etwas tricksen.

----------

## Silicoid

Hi

 *misterjack wrote:*   

> cms != statische html-Seiten, das ist dir schon klar?

 

CMS = Content Management System. Das sagt nicht darüber aus, ob die Seiten jedesmal dynamisch generiert werden oder statische Seiten generiert werden und dann hochgeladen werden.

 *oscarwild wrote:*   

> Ich vermute, Silicoid möchte die Seiten zum Hosten statisch aus dem CMS generieren, was durchaus sinnvoll ist, wenn man kostenfreien Webspace benutzen möchte, der kein PHP etc. bietet. Manche CMS unterstützen die statische Generierung nativ, bei anderen muss man etwas tricksen.

 

Nicht ganz. Mein Problem ist, daß auf dem Webserver teilweise sehr viel los ist. Derzeit habe ich selbstgebaute HTML Seiten. Die flutschen auch wenn der Server unter Last steht. Andere Seiten, die ständig dynamisch generiert werden, sind da deutlich langsamer. Statische Seiten haben auch den Vorteil, daß sich da niemand reinhacken kann, sind also wesentlich sicherer. Wenn ich also ein CMS hätte, daß statische Seiten generiert, brauche nur ich Zugriff und kann das ganze wesentlich sicherer machen.

Und wie ich bereits sagte: Warum sollte jedesmal eine Seite generiert werden. Teilweise ändern die einzelnen Seiten nie. Nur einige werde ich immer wieder editieren. Dann einen Generierungslauf und alles wäre aktuell.

----------

## b3cks

 *Silicoid wrote:*   

>  Statische Seiten haben auch den Vorteil, daß sich da niemand reinhacken kann, sind also wesentlich sicherer. Wenn ich also ein CMS hätte, daß statische Seiten generiert, brauche nur ich Zugriff und kann das ganze wesentlich sicherer machen.

 

Wenn du ein CMS benutzt, welches über eine Web-Frontend administriert wird, hast du auch hier eine Angriffsfläche. Klar ist das Sicherheitsrisiko minimiert, da sich eine potenzielle Gefahr nur auf diese Oberfläche beschränkt und nicht alle Skripte/Seiten.

 *Quote:*   

> Und wie ich bereits sagte: Warum sollte jedesmal eine Seite generiert werden. Teilweise ändern die einzelnen Seiten nie. Nur einige werde ich immer wieder editieren. Dann einen Generierungslauf und alles wäre aktuell.

 

Das Problem ist, dass allein vom logischen Aufbau her, fast alle diese CMSe auf Templates basieren, nicht umsonst Template-Systeme sind, und somit nur dynamisch sein können. Wenn du den Copyright-Tag im Footer änderst, willst du ja schließlich, dass er sich überall ändert und nicht nur auf einer Seite.

Dennoch unterscheidet man zwischen dynamischen und statischen CMSen. Mir ist allerdings kein statisches bekannt. Zudem kann man dann, meiner Meinung nach, auch gleich einen (Web-)Editor nehmen.

----------

## Silicoid

 *b3cks wrote:*   

> 
> 
> Wenn du ein CMS benutzt, welches über eine Web-Frontend administriert wird, hast du auch hier eine Angriffsfläche. Klar ist das Sicherheitsrisiko minimiert, da sich eine potenzielle Gefahr nur auf diese Oberfläche beschränkt und nicht alle Skripte/Seiten.
> 
> 

 

Schon klar. Aber ich kann die Scripten dann zumindest zusätzlich durch htaccess schützen.

 *b3cks wrote:*   

> 
> 
> Das Problem ist, dass allein vom logischen Aufbau her, fast alle diese CMSe auf Templates basieren, nicht umsonst Template-Systeme sind, und somit nur dynamisch sein können. Wenn du den Copyright-Tag im Footer änderst, willst du ja schließlich, dass er sich überall ändert und nicht nur auf einer Seite.
> 
> 

 

Genau dafür braucht man eben eine gute Template Engine. Die Engine von Template Toolkit (perl) erkennt meines Wissens sowas. 

Make sagt man ja z.B. was wovon abhängt. Sobald sich eine der Abhängigkeiten verändert baut make das Target neu.

 *b3cks wrote:*   

> 
> 
> Dennoch unterscheidet man zwischen dynamischen und statischen CMSen. Mir ist allerdings kein statisches bekannt. Zudem kann man dann, meiner Meinung nach, auch gleich einen (Web-)Editor nehmen.

 

Da ist schon noch ein Unterschied. Bei einem CMS hab ich ggf. Module für Galerien oder Menüs. Ich möchte natürlich auch mit Templates arbeiten,  sonst darf ich jede Seite editieren, wenn ich was grundsätzliches ändere.

Wenn ich nichts bessers finde, werd ich wahrscheinlich sowas wie Template Toolkit nehmen und mit einem Webeditor die Template Files editieren. Danach Template Toolkit über ein kleines CGI starten. Ich hätte das zwar lieber aus einer Hand, aber wenn ich nichts besseres finde wirds das wohl werden.

----------

## Robelix

Will mich hier jetzt nicht weiter über Sinn und Zweck eines derartigen Systems aufhalten, sondern eines anbieten mit dem das prinzipiell geht:

Für Typo3 gibt es die extension fl_staticfilecache http://typo3.org/extensions/repository/?tx_terfe_pi1%5Bview%5D=search&no_cache=1&tx_terfe_pi1%5Bsword%5D=fl_staticfilecache

die genau sowas macht.

Entwickelt wurde das Ding allerdings primär aus Performance-Gründen für High Traffic Sites.

Ob jetzt wirklich Typo3 die Lösung für dich ist waage ich etwas zu bezweifeln - die Einarbeitungszeit dafür würde ich mit Minimum 2 Wochen angeben - allerdings kann ich mir gut vorstellen, daß es für kleinere/einfachere CMS ähnliches gibt.

----------

## l3u

Einfach mit irgendwas lokal bauen und dann mit httrack spiegeln? Dann hat man statische HTML-Dateien, die man hochladen kann.

----------

## Silicoid

Hi

 *Robelix wrote:*   

> 
> 
> Für Typo3 gibt es die extension fl_staticfilecache http://typo3.org/extensions/repository/?tx_terfe_pi1%5Bview%5D=search&no_cache=1&tx_terfe_pi1%5Bsword%5D=fl_staticfilecache
> 
> die genau sowas macht.
> ...

 

neee, Typo ist da auch nicht das Richtige. Meines Wissens generiert Typo auch keine statischen Seiten, sondern legt einen Cache an. Das heißt jeder Setienaufruf geht durch Typo. Schaut halt nur zuerst nach, ob die Seite bereits im Cache ist. Wenn nicht wird sie generiert.

Von daher auch nicht ganz was ich suche ...

 *Libby wrote:*   

> 
> 
> Einfach mit irgendwas lokal bauen und dann mit httrack spiegeln? Dann hat man statische HTML-Dateien, die man hochladen kann.
> 
> 

 

Lokal bauen hat eben den nachteil, das ich die Seite nicht von überall verändern kann. Möchte ich z.B. können um Codebeispiele Online zu stellen und sie mir zu merken.

----------

## mr_elch

 *Silicoid wrote:*   

> 
> 
> Nicht ganz. Mein Problem ist, daß auf dem Webserver teilweise sehr viel los ist. Derzeit habe ich selbstgebaute HTML Seiten. Die flutschen auch wenn der Server unter Last steht. Andere Seiten, die ständig dynamisch generiert werden, sind da deutlich langsamer.

 

Was ist mit mod_cache bzw. Squid als Reverse-Proxy? Die sind doch genau für solche Zwecke gedacht!

Noch ein paar Links:

http://www.tecchannel.de/server/linux/402259/index5.html

http://www.tecchannel.de/server/linux/402455/

http://aktuell.de.selfhtml.org/artikel/server/apachetuning/

----------

## Robelix

 *Silicoid wrote:*   

> Hi
> 
> neee, Typo ist da auch nicht das Richtige. Meines Wissens generiert Typo auch keine statischen Seiten, sondern legt einen Cache an. Das heißt jeder Setienaufruf geht durch Typo. Schaut halt nur zuerst nach, ob die Seite bereits im Cache ist. Wenn nicht wird sie generiert.
> 
> 

 

Stimmt, Cache in der DB ist das normale Verhalten von Typo3. Die von mir erwähnte extension modifiziert das aber so, daß "echte" Files geschrieben werden.

Und nochmal: Ich will dir nicht unbedingt Typo3 aufdrängen, ich nehme sogar an, daß es für deine Anwendung heilloser Overkill ist. Ich wollte nur darauf hinweisen, daß es CMS gibt die diese Möglichkeit bieten, auch wenn sie nicht Standard ist. Du dich also bei den CMS nach entsprechenden Plugins/Extension/Components/WieauchimmerdasZeugdortheisst umsehen solltest.

----------

## return13

```
*  www-apps/nanoblogger

      Latest version available: 3.2.3

      Latest version installed: 3.2.3

      Size of downloaded files: 160 kB

      Homepage:    http://nanoblogger.sourceforge.net/

      Description: Small and simple weblog engine written in Bash for the command-line

      License:     GPL-2

```

erzeugt statische seiten - das ganze jedoch recht dynamisch aus der bash...

----------

## Silicoid

Hi

 *mr_elch wrote:*   

> Was ist mit mod_cache bzw. Squid als Reverse-Proxy? Die sind doch genau für solche Zwecke gedacht!

 

Es geht mir nicht unbedingt darum die Seite schneller auszuliefern, indem ich irgendwas um ein CMS System rumbaue. Ich bin auch von Beruf Sysadmin und mir widerstrebt es einfach, wenn ich weiß, daß ein System etwas immer wieder tut, obwohl das nicht nötig ist. Wie ich schonmal geschrieben habe finde ich es einfach nur Verschwendung eine Seite jedes mal neu zu generieren, die sich nur sehr selten oder vielleicht nie ändert. Klar gibt es andere Seiten, die dynamisch sein müssen. Gästebücher und Webforen um nur zwei zu nennen. Wenn ich aber eine Bildergalerie habe, so wird sich diese nur dann ändern, wenn ich Bilder hinzufüge oder enferne  oder wenn ich das Layout der Seite ändere. Warum sollte diese Seite bei jedem Besuch neu gebaut werden. Das reicht, wenn sie bei der Änderung neu gebaut wird.

@Robelix: Richtig, Typo ist da Overkill. 

@return13: Danke!!! Werd ich mir mal anschauen. Mal schauen was das so kann.

----------

## firefly

 *Silicoid wrote:*   

> Hi
> 
>  *mr_elch wrote:*   Was ist mit mod_cache bzw. Squid als Reverse-Proxy? Die sind doch genau für solche Zwecke gedacht! 
> 
> Es geht mir nicht unbedingt darum die Seite schneller auszuliefern, indem ich irgendwas um ein CMS System rumbaue. Ich bin auch von Beruf Sysadmin und mir widerstrebt es einfach, wenn ich weiß, daß ein System etwas immer wieder tut, obwohl das nicht nötig ist. Wie ich schonmal geschrieben habe finde ich es einfach nur Verschwendung eine Seite jedes mal neu zu generieren, die sich nur sehr selten oder vielleicht nie ändert. Klar gibt es andere Seiten, die dynamisch sein müssen. Gästebücher und Webforen um nur zwei zu nennen. Wenn ich aber eine Bildergalerie habe, so wird sich diese nur dann ändern, wenn ich Bilder hinzufüge oder enferne  oder wenn ich das Layout der Seite ändere. Warum sollte diese Seite bei jedem Besuch neu gebaut werden. Das reicht, wenn sie bei der Änderung neu gebaut wird.
> ...

 

Also "moderne" CMS-Systeme generieren nicht ständig die Seite neu, auser es wurden ihnen gesagt es zu tun, sondern verwenden ein cache-system um den Seitenzugriff zu beschleunigen. Was dann quasi statischen Seiten entspricht.

----------

## Silicoid

 *firefly wrote:*   

> 
> 
> Also "moderne" CMS-Systeme generieren nicht ständig die Seite neu, auser es wurden ihnen gesagt es zu tun, sondern verwenden ein cache-system um den Seitenzugriff zu beschleunigen. Was dann quasi statischen Seiten entspricht.

 

Das ist schon richtig, allerdings geht mir das eben noch nciht weit genug. Jede Anfrage muß erstmal durch das CMS. Das CMS muß dann entscheiden, ob es die Seite schon gecachet hat oder generieren muß. Aber auch das kostet Rechenleistung. Zwar 

 weniger, aber doch mehr, als wenn der Webserver die Seite einfach nur aus dem Filesystem nimmt und ausliefert. 

Es geht mir eben auch ein wenig um Sicherheit. An statischen Seiten kann man nichts hacken. Selbst wenn ein CMS nur gecachte Seiten ausliefert, ist es doch das CMS, mit dem gesprochen wird. Es ist also von jedem Ansprechbar und somit kann man es hacken.

----------

## think4urs11

 *Silicoid wrote:*   

> Das ist schon richtig, allerdings geht mir das eben noch nciht weit genug. Jede Anfrage muß erstmal durch das CMS. Das CMS muß dann entscheiden, ob es die Seite schon gecachet hat oder generieren muß. Aber auch das kostet Rechenleistung. Zwar weniger, aber doch mehr, als wenn der Webserver die Seite einfach nur aus dem Filesystem nimmt und ausliefert. 

 

Dafür hast du dann ja deinen reverse Proxy davor; der schaut in seinem Cache nach und liefert aus - zusätzlich hast du mit einem RP erhöhte Sicherheit gegenüber direktem Zugriff auf den Webserver (außer letzterer liefert ausschließlich statischen Content versteht sich).

Aber ich verstehe dich schon vom Grundgedanken dahinter. Es ist teils Geschmackssache und teils eine philosophische Frage welche Lösung man bevorzugt. Man muß ja auch bedenken das die meisten CMS mit DB-Backend deutlich mehr Möglichkeiten haben als ggf. verfügbare die mit statischen flatfiles arbeiten... Was ist nun wichtiger, bessere Gestaltungsmöglichkeiten oder Performance? Frag 5 Admins und du erhältst 6 Antworten dazu.

----------

## l3u

Hast du auf deinen Seiten wirklich so viel Zugriffe pro Sekunde, daß du dir ernsthafte Gedanken darüber machen mußt, daß das Generieren der Seiten zu viel Rechenleistung in Anspruch nehmen könnte?

----------

## Silicoid

 *Libby wrote:*   

> Hast du auf deinen Seiten wirklich so viel Zugriffe pro Sekunde, daß du dir ernsthafte Gedanken darüber machen mußt, daß das Generieren der Seiten zu viel Rechenleistung in Anspruch nehmen könnte?

 

Ich alleine nicht. Aber auf dem Server laufen über 1000 Domains. Die haben teilweise schon recht viel zu tun. Vor einem Jahr war der Server mal extrem dicht. Bei den dynamisch generierten Seiten ging nix mehr. Bei meiner statischen hat es geflutscht. Von daher möchte ich ihn so wenig wie möglich belasten. Performance ist ja nicht der einzige Grund. Sicherheit eben auch.

----------

## b3cks

Sorry, aber schon mal über einen Serverwechsel nachgedacht? Ich mein >1000 Domains auf einem Server ist ja schon pervers, aber dann auch noch diverse Einschränkungen und zudem größere Latenzen/Ausfälle hinnehmen?

Oder geht das aus irgendwelchen Gründen nicht?

----------

## Silicoid

 *b3cks wrote:*   

> Sorry, aber schon mal über einen Serverwechsel nachgedacht? Ich mein >1000 Domains auf einem Server ist ja schon pervers, aber dann auch noch diverse Einschränkungen und zudem größere Latenzen/Ausfälle hinnehmen?
> 
> 

 

Ich könnte schon, aber ich sehe keinen Grund. Der Space ist sehr günstig. Selbst wenn ich woanders hin ziehe, werde ich den Space auf diesem Server weiter haben, da er teil eines Paketes bei einer Non Profit Organisation ist.

Ausserdem könnte der Server noch bedeutend mehr, wenn alle statische Seiten hätten und nur zum ändern von Seiten eine Webapplikation verwenden würden  :Smile: 

----------

