HTML5 - oder was nimmt man heute?!

CSS, HTML5 und Javascript sind heutzutage die "Waffen der Wahl" fürs 
freie Coding.

WYSIWIG-Editoren vereinfachen zwar die Entwicklung für den Laien, 
entbinden diesen quasi von beinaher jeglicher Code-Kenntnis, erzeugen 
aber meist auch nur grauenhafte Code-Gespinste, bei denen kaum noch 
jemand durchblickt oder irgendwas ändern/ergänzen kann.

Für eher technisch-sachliche Webseiten ohne allzuviel Design-Overhead 
(was nicht heisst, dass sie schlecht aussehen müssen) empfehle ICH eher 
die Verwendung von CMS-Systemen, wie z.B. Joomla. Der Style wird 
einheitlich über alle Seiten per Template festgelegt. Es gibt zahllose 
Module um Funktionen nachzurüsten, wie z.B. Foren, Formularen, 
Dokumentenverwaltung, Webshops usw. Auch das Einbinden von eigenem Code 
wird per Wrapper "sauber" geregelt.

Das Einbringen von Inhalten wird online über ein sog. "Backend" 
erledigt, ohne dass man zusätzliche Software benötigt. Ich finde dieses 
Prinzip effizient und zeitgemäß. Zusätzlich wird einem meist auch das 
"responsive design" (korrekte Darstellung auf Bildschirmen mit 
unterschiedlicher Geometrie, z.B. Mobilgeräten, abgenommen)

Übrigens: Es gibt tausende von Templates (Stil-Vorlagen), sowohl frei 
als auch kostenpflichtig. Es gibt auch Anleitungen, wie man diese selber 
erstellt, falls man nichts passendes finden sollte ...

MEIN Tip: Sich in Joomla (oder einem anderen CMS) einlesen.

Und jetzt kommt bestimmt gleich ein Schlaumeier und wird einwerfen, dass 
hin und wieder CMS gehackt werden. Ja, das kommt vor, aber alle anderen 
Webserver werden auch gehackt.

In Joomla ist übrigens eine Backup-Funktion vorhanden, mit der man die 
gesamte Präsenz als eine ZIP-Datei herunterladen und wieder herstellen 
kann. Ebenfalls ohne zusätzliche Software.

Frank E. schrieb:
> Und jetzt kommt bestimmt gleich ein Schlaumeier und wird einwerfen, dass
> hin und wieder CMS gehackt werden. Ja, das kommt vor, aber alle anderen
> Webserver werden auch gehackt.

Ja, wobei man bei Joomla noch zwischen dem eigentlichen Kern und den 
Erweiterungen (die prinzipiell jeder anbieten kann) unterscheiden muss. 
Der Kern selbst ist eher selten betroffen, dafür deutlich mehr 
Erweiterungen, insbesondere, wenn man kein regelmäßiges Update 
durchführt

Wenn man das System sauber aufsetzt und nicht jeden Mist 
nachinstalliert, dann ist das schon recht sicher. Wir nutzen Joomla 
jetzt seit 2009 und bisher gab es noch keine Probleme.

Trotzdem ist es natürlich immer gut, vor allem die Dateien auf 
Veränderungen zu überwachen. Wir haben dafür ein kleines Skript 
geschrieben, das mit einem zufälligen Namen hochgeladen und ausgeführt 
wird, MD5-Summen aller Dateien in einer Datei zu uns schickt und diese 
dann direkt vergleicht. Das lässt man alle 2-3 Stunden mit niedriger 
Priorität als cronjob laufen. So gibt es direkt Alarm, wenn etwas nicht 
stimmen sollte (was aber bisher noch nie vorkam :-).
Ähnliches kann man mit den Datenbanktabellen machen, wobei man da 
natürlich manche Tabellen/Spalten ausnehmen bzw. "schlauer" gegenprüfen 
muss, da Joomla/die Erweiterungen dort dynamisch Dinge ändern.

Was man bei Joomla beachten sollte: es benötigt doch eine gewisse Menge 
an Ressourcen. Auf einem Shared Host hatten wir bspw. wenig Freude - die 
Reaktionszeiten waren einfach zu schlecht. Mit (virtuellem) eigenen 
Server läuft es dagegen gut.

Ich finde es kommt ganz auf den Anwendungsfall an.

Wenn man einfach schnell eine gut aussehende Seite braucht, und sich 
nicht so dafür Interessiert was im Hintergrund abgeht, nimmt am besten 
ein CMS.

Hat man spezielle Ansprüche an die Seite, will etwas mehr Kontrolle oder 
traut nicht jedem fremden Code, dann muss man es selbst schreiben. Dabei 
muss man sich folgendes überlegen:

 1) Brauche ich einen einheitlichen Seitenaufbau
 1.1) Ein Templating framework nehmen
 1.1.1) Client oder Serverseitig?
 1.1.2) Selber machen oder vorhandenes nehmen?
 2) Brauche ich Liveupdates
 2.1) Framework nehmen oder
 2.2) websockets nehmen und selbst schreiben
 3) Brauche ich eine JS-Freie version für Konsolensurfer, Dinosaurier 
und Paranoide?
 4) Programmiersprache soll Clientseitig verwendet werden? 
(ECMAScript,TypeScript,...)
 5) Programmiersprache(n) soll(en) Serverseitig verwendet werden?
 6) Welche Webserver will man verwenden?
 7) Welches OS wil man auf dem Server/Woher nimt man diesen?
 8) Soll die Seite auch Offline funktionieren?
 9) Welche Versionsverwaltung (Git, SVN, CVS,...)

www-www schrieb:

> Ob Du nun dynamische Inhalte via PHP, CGI oder RubyOnRails erzeugst
> bleibt Dir überlassen.
> RubyOnRails ist die mächtigste Variante allerdings komplett anderer
> Ansatz.

Ein Framework ist also mächtiger als eine Programiersprache oder als ein 
Protokoll? :)
Von den Drei genannten ist eindeutig PHP das mächtigste, den mit php 
kannst du auch was anderes als ne Dynamische webseite machen.

Da wären wir auch schon bei der Ursprungsfrage.
Wenn dir statische Inhalte reichen guck dir mal die üblichen 
verdächtigen an wenn es um static site Generatoren geht, Jekyll ist da 
einer der beliebteren.

Da hast du zwar kein WYSIWYG, du schreibst aber auch für deine Beiträge 
kein html von Hand.

Du kannst deine Inhalte so versionieren wie du es gewohnt bist und du 
stellst praktisch keine Anforderungen an deinen Webserver, alles was 
sich auch nur im entferntesten Webserver schimpft kann eine statische 
Seite ausliefern.

Das heist auch das du dir keine sorgen um die Sicherheit deiner Software 
(cms) machen musst.
Grüße, Dirk

www-www schrieb:

> RubyOnRails ist ein reines Framework und keine erweiterte OO Sprache die
> speziell für WWW entwickelt ist ?
Ja.
Ruby ist ne Sprache, ROR ist nen Framework.
> PHP ist definitiv nicht mächtiger nur bekannter und mehr im Einsatz.
NA mit PHP (oder Ruby oder Python, oder Node, um nur einige 
vergleichbare Scriptsprachen abzudecken, oder oder oder) schreibt man 
auch andere dinge als ne Webanwendung, ROR ist dafür nicht gemacht, ROR 
ist ein WebApplicationFramework.
Und per Definition sollte eine Programiersprache Mächtiger sein als ein 
Framework für eine Spezielle Anwendung

> JEE wäre auch mächtiger als PHP wenn ORACLE ja nicht ...
Das ist jetzt was, darüber kann man Streiten, genau so wie man darüber 
Streiten kann ob Ruby mächtiger ist als PHP.
Da kommt es dann auf die Genaue definition von Mächtig an, und wohl auch 
ein bisschen auf den eigenen Geschmack.
Wenn du mir jetzt sagst das Ruby mächtiger ist als PHP oder PHP 
mächtiger als Ruby dann ist das zwar auch ne Aussage die Belegt werden 
will, grundsätzlich kann das aber sein.
Wenn ich jetzt aber sage das Express mächtiger ist als Ruby, oder 
Symfony Mächtiger als node, oder ROR mächtiger als PHP, dann ist das 
grober Unfug.

> Aber wie schon mehrfach erwähnt solange der TO nicht weiß was er genau
> erreichen will paßt alles oder nix.
> Man kann auch via XML und passendem Parser dynamische oder statische
> Webseiten erzeugen
XSLT bieter sich hier wunderbar an :)

> oder man schreibt sich einen eigenen Webserver der
> Interaktionen der Webseite auswertet.
> Das läßt sich beliebig weiterführen.

Jo, da gibts dinge die sich für bestimmte Anwendungsfälle durchgesetzt 
haben, so wie Jekyll für Static site Generatoren, ROR für schnell und 
Einfach entwickelte Standard-fälle in Webanwendungen, oder PHP wenn man 
Überall und Günstig hosten möchte.

In den meisten Fällen muss und sollte man von solchen Standardfällen, 
wenn's den auf einen Passt, nicht abweichen.

Wenn du in Chrome Strg-Shift-I drückst öffnen sich die Entwicklertools.
Da kannst du dir HTML, CSS und Javascript ansehen und auch direkt 
verändern. Chrome stellt die Seite dann entsprechend deinen Änderungen 
anders dar, d.h. sozusagen WYSIWIG.

Alternativ gibt es natürlich die Möglichkeit, einen normalen Texteditor 
wie Sublime zu benutzen und per Javascript ein dauerhaftes Autoupdate im 
Browser laufen zu lassen, so dass man nach dem Speichern nicht noch F5 
drücken muss.

D. I. schrieb:
> Wenns um das geht was man mit der Sprache machen kann sind PHP und Ruby
> wohl gleich mächtig, da beide turing-vollständig sind. ;)
> Aber das eine ist ein Krampf im Arsch und das andere ein Genuss in der
> täglichen Anwendung ;)
> Wieviel Dynamik soll deine Webseite denn haben? Dann kann man
> weitersehen.

Da frag ich mich doch ob du eher das mit der halbgaren OO meinst oder 
das mit der gem / rbenv Hölle?! :)

Frank E. schrieb:
> CSS, HTML5 und Javascript sind heutzutage die "Waffen der Wahl" fürs
> freie Coding.
>
> WYSIWIG-Editoren vereinfachen zwar die Entwicklung für den Laien,
> entbinden diesen quasi von beinaher jeglicher Code-Kenntnis, erzeugen
> aber meist auch nur grauenhafte Code-Gespinste, bei denen kaum noch
> jemand durchblickt oder irgendwas ändern/ergänzen kann.

Das kann ich nur unterschreiben. Vor allem im Zusammenhang mit modernem 
Java- bzw. ECMAScript sind WYSIWIG-Editoren äußerst problematisch, und 
die Qualität des erzeugten Code ist bei allen mir bekannten Werkzeugen 
dieser Art einfach nur unterirdisch schlecht.

> Für eher technisch-sachliche Webseiten ohne allzuviel Design-Overhead
> (was nicht heisst, dass sie schlecht aussehen müssen) empfehle ICH eher
> die Verwendung von CMS-Systemen, wie z.B. Joomla. Der Style wird
> einheitlich über alle Seiten per Template festgelegt. Es gibt zahllose
> Module um Funktionen nachzurüsten, wie z.B. Foren, Formularen,
> Dokumentenverwaltung, Webshops usw. Auch das Einbinden von eigenem Code
> wird per Wrapper "sauber" geregelt.

Mit Verlaub: auf die vom OP als eher einfach beschriebene Aufgabe mit 
einem Monster wie Joomla draufzuhauen, erscheint mir dann doch ein wenig 
überdimensioniert. Für so kleine Sachen bieten sich eher Microframeworks 
wie Bottle.py oder (mittlerweile mein Favorit für Kleinkram) Flask an:

1

from flask import Flask, render_template

2

app = Flask(__name__)

3

4

@app.route('/')

5

def index():

6

    return render_template('index.html')

7

8

if __name__ == '__main__':

9

    app.secret_key = "Geheimer Random-Key"

10

    app.run(host='0.0.0.0', port=8080)

Dazu im Unterverzeichnis "templates/" eine Datei "index.html" mit dem 
gewünschten HTML-Template, und die Sache ist geritzt. Acht Zeilen Python 
für einen Webserver mit einer Template-Engine und einer Startseite!

Am Rande sei hier noch auf passende Javascript-Frameworks wie jQuery und 
CSS-Werkzeuge sie SASS hingewiesen, welche die Entwicklung und die 
Pflege moderner, dynamischer Webanwendungen sehr vereinfachen und 
beschleunigen.

> Und jetzt kommt bestimmt gleich ein Schlaumeier und wird einwerfen, dass
> hin und wieder CMS gehackt werden. Ja, das kommt vor, aber alle anderen
> Webserver werden auch gehackt.

Verzeihung, aber es ist regelmäßig nicht der Webserver -- sogar 
Microsofts IIS ist mittlerweile deutlich besser geworden -- sondern die 
auf demselben laufende Software, die gecrackt wird. Dies betrifft 
besonders häufig sehr beliebte Softwaresysteme, die in PHP geschrieben 
sind -- vermutlich führt die besonders niedrige Einstiegshürde dazu, daß 
PHP viele Anfänger und andere unterdurchschnittliche Programmierer 
anzieht, und das äußert sich dann auch in der Codequalität und dem 
Sicherheitsniveau der von diesen Leuten implementierten Software. 
Deswegen haben Wordpress, XT-Commerce und seine Ableger, und leider auch 
CMS-Systeme wie Typo3, Joomla und Magento eine ziemlich abschreckende 
Sicherheitshistorie.

Daß auch andere gecrackt werden, macht die Sache allerdings nicht besser 
und entschuldigt gar nichts. Tatsache ist, daß man insbesondere größere 
CMS- und Weblog-Software sehr regelmäßig aktualisieren und dafür einen 
ziemlichen Aufwand betreiben muß, wenn man derartige Software wenigstens 
halbwegs sicher betreiben möchte. Insbesondere Mainstream-Systeme 
stellen dabei hohe Anforderungen, denn einerseits sind Monokulturen nun 
einmal besonders anfällig für Schädlinge, und andererseits sind zuviele 
Jäger bekanntlich des Hasen Tod.

Dirk D. schrieb:
> Das ist jetzt was, darüber kann man Streiten, genau so wie man darüber
> Streiten kann ob Ruby mächtiger ist als PHP.

Nein, darüber kann man nicht streiten. Unter den verbreiteten 
Skriptsprachen ist PHP die mit Abstand schlechteste und am wenigsten 
mächtige; PHP ist im Prinzip nur eine Templateengine für Webseiten, 
ähnlich wie Embperl. Ja, man kann mittlerweile sogar GUI-Anwendungen mit 
PHP entwickeln, aber das macht keiner, weil PHP dafür einfach nicht 
gemacht ist und es deswegen weh tut, sowas in PHP zu entwickeln. Das tun 
nur Leute, die nichts anderes können (siehe dazu auch: 
Hammer-Nagel-Problem).

Perl, Python und Ruby sind hingegen vollständige Programmiersprachen und 
schon vom Design her nicht nur für Webanwendungen, sondern als 
Allrounder angelegt -- und werden auch in der Systemautomation, der 
Datenanalyse und -verarbeitung, GUI- und CLI-Programmierung und dem 
Scripting von anderen Anwendungen wie PostgreSQL, KDE oder Libreoffice 
benutzt. PHP hat dort überall nicht den Hauch einer Chance.

Auch sonst stinkt PHP ziemlich ab: das Sprachdesign ist mit "beschissen" 
noch wohlwollend beschrieben, die Stringverarbeitung ausgerechnet von C 
abgeguckt, das Templateing von Embperl und die Objektorientierung von 
Java. Damit vereint PHP die schlechtesten Eigenschaften von C, Perl und 
Java, und ist dabei obendrein meist auch noch langsamer als die anderen 
Skriptsprachen und verbraucht mehr Ressourcen.

Der einzige Vorteil, den PHP hat -- und wie ich im vorherigen Beitrag ja 
schon beschrieben habe, ist das eigentlich eher ein Nachteil -- ist die 
Tatsache, daß PHP von Anfängern besonders einfach benutzt werden kann, 
ohne sich mit der Webserverkonfiguration, Dateirechten und ähnlichen 
fortgeschrittenen Kenntnissen belasten zu müssen. Und genau so sieht die 
in PHP geschriebene Software dann eben häufig auch aus.

Sheeva P. schrieb:
> Dirk D. schrieb:
>> Das ist jetzt was, darüber kann man Streiten, genau so wie man darüber
>> Streiten kann ob Ruby mächtiger ist als PHP.
>
> Nein, darüber kann man nicht streiten.
Was machst du den grade? :)


Warum glaubst du das ich hier PHP verteidigen will?
ich hab lediglich gesagt das PHP Mächtiger ist als Rails, das willst du 
nicht bestreiten, oder?

Aber wenn wir da schon mal

> Unter den verbreiteten
> Skriptsprachen ist PHP die mit Abstand schlechteste und am wenigsten
> mächtige;

Wie machst du die Mächtigkeit aus?
Was ist für dich eine vollständige Programmiersprache, erkläre :)

Sheeva P. schrieb:
> Tatsache ist, daß man insbesondere größere
> CMS- und Weblog-Software sehr regelmäßig aktualisieren und dafür einen
> ziemlichen Aufwand betreiben muß,

Regelmäßig aktualisieren - ja.
Ziemlicher Aufwand - zumindest bei Joomla: nein

Man wird bei Joomla automatisch über neue Versionen informiert und das 
Update gestaltet sich nicht viel anders als ein Ubuntu-Update. Man kann 
das problemlos im Backend durchführen. Ebenso lassen sich viele 
Erweiterungen (halb-)automatisch aktualisieren.

Man muss es aber auch tun :-)

Wichtig ist es mMn, nicht jeden Mist zu installieren.
Es gibt unter Joomla wirklich auch hingerotzte Komponenten.

> wenn man derartige Software wenigstens
> halbwegs sicher betreiben möchte. Insbesondere Mainstream-Systeme
> stellen dabei hohe Anforderungen, denn einerseits sind Monokulturen nun
> einmal besonders anfällig für Schädlinge, und andererseits sind zuviele
> Jäger bekanntlich des Hasen Tod.

Ja, das ist leider so: je bekannter, desto häufiger sind die 
Angriffsversuche. Da kann man ja auch etwas vorsorgen. Durch unsere 
Code/Datenbank-Überwachung wäre mir zumindest ein aktiver Einbruch rasch 
bekannt.

Aber es ist eben auch so, dass man für bekannte CMS auch die 
interessantesten Erweiterungen bekommt :-/

WYSIWYG-Editoren kann, muss man aber unter Joomla nicht verwenden. Ich 
persönlich habe lieber einen normalen Editor, in den ich die Tags per 
Hand eintrage.

Ob der OP wirklich ein CMS braucht?
Vermutlich reicht ihm wirklich eine statische Seite.

Selbst für uns hier ist Joomla eigentlich oversized (ich bin der einzige 
Autor ;-) - aber es gibt einige Komponenten, auf die ich nicht 
verzichten möchte.

Und: wenn man sich einmal in etwas eingearbeitet hat, dann wechselt man 
ungern. In Joomla bin ich jetzt seit Jahren halbwegs fit und kann meine 
Erweiterungen problemlos selbst schreiben. Einbrüche hatten wir noch 
nicht (was aber auch nichts heißen muss).

Chris D. schrieb:
> Einbrüche hatten wir noch nicht (was aber auch nichts heißen muss).

Doch: Du hast zumindest keine der “üblichen“ Lücken drin und die Seite 
nicht interessant genug, um ordentlich zu suchen ;-)

Jan H. schrieb:
> Chris D. schrieb:
>> Einbrüche hatten wir noch nicht (was aber auch nichts heißen muss).
>
> Doch: Du hast zumindest keine der “üblichen“ Lücken drin und die Seite
> nicht interessant genug, um ordentlich zu suchen ;-)

Das stimmt natürlich - Laufkundschaft haben wir eher nicht und 
politische Statements gibt es dort auch nicht <:-)

Mit ein paar wirklich einfachen Dingen kann man seine Seiten aber schon 
recht sicher gestalten. Bei uns ist der Administrator-Bereich bspw. 
durch eine entsprechende .htaccess passwortgeschützt. Man muss sich dann 
natürlich zweimal hintereinander einloggen, was lästig ist. Dafür ist 
der gesamte Admin-PHP-Bereich aber auch von außen nicht direkt 
angreifbar.

Dirk D. schrieb:
> Sheeva P. schrieb:
>> Dirk D. schrieb:
>>> Das ist jetzt was, darüber kann man Streiten, genau so wie man darüber
>>> Streiten kann ob Ruby mächtiger ist als PHP.
>>
>> Nein, darüber kann man nicht streiten.
> Was machst du den grade? :)

Feststellen, daß man darüber nicht streiten kann.

> Warum glaubst du das ich hier PHP verteidigen will?

Weil Du es tust.

> ich hab lediglich gesagt das PHP Mächtiger ist als Rails, das willst du
> nicht bestreiten, oder?

Doch. PHP kann ja nichtmal Multithreading oder Multiprocessing, EOD.

Sheeva P. schrieb:
> Dirk D. schrieb:
>> ich hab lediglich gesagt das PHP Mächtiger ist als Rails, das willst du
>> nicht bestreiten, oder?
>
> Doch. PHP kann ja nichtmal Multithreading oder Multiprocessing, EOD.

Du vergleichst als ein Framework mit einer Sprache und bist der Meinung 
das Framework (für einen Speziellen Einsatzzweck) ist Mächtiger, nein, 
mit wir will ich auch garnicht weiter diskutieren plonk

Sheeva P. schrieb:
> Doch. PHP kann ja nichtmal Multithreading oder Multiprocessing, EOD.

Schonmal gegoogelt vor dem Schreiben?

https://secure.php.net/thread
https://secure.php.net/manual/de/function.pcntl-fork.php

Daniel A. schrieb:
> Sheeva P. schrieb:
>> Doch. PHP kann ja nichtmal Multithreading oder Multiprocessing, EOD.
>
> Schonmal gegoogelt vor dem Schreiben?
>
> https://secure.php.net/thread
> https://secure.php.net/manual/de/function.pcntl-fork.php

Nein, das war in PHP3 so, seid dem kann das ja nur schlimmer geworden 
sein :)

Chris D. schrieb:
> Sheeva P. schrieb:
>> Tatsache ist, daß man insbesondere größere
>> CMS- und Weblog-Software sehr regelmäßig aktualisieren und dafür einen
>> ziemlichen Aufwand betreiben muß,
>
> Regelmäßig aktualisieren - ja.
> Ziemlicher Aufwand - zumindest bei Joomla: nein
>
> Man wird bei Joomla automatisch über neue Versionen informiert und das
> Update gestaltet sich nicht viel anders als ein Ubuntu-Update. Man kann
> das problemlos im Backend durchführen. Ebenso lassen sich viele
> Erweiterungen (halb-)automatisch aktualisieren.

Bei Begriffen wie "halbautomatische Aktualisierung" rollen sich bei 
erfahrenen Sysops die Fußnägel auf! ;-)

> Man muss es aber auch tun :-)

...und können! ;-)

> Wichtig ist es mMn, nicht jeden Mist zu installieren.
> Es gibt unter Joomla wirklich auch hingerotzte Komponenten.

Das ist der Punkt, der die Sache so aufwändig und problematisch macht. 
Auf der einen Seite preist Du Joomla wegen seiner Erweiterungen an, auf 
die Du nicht verzichten willst. Auf der anderen Seite mußt Du jedoch 
eingestehen, daß viele Joomla-Erweiterungen schlecht programmiert 
sind...

Für jemanden, der sich mit Joomla nicht so gut auskennt wie Du, stellt 
das ein unlösbares Problem dar. Denn derjenige weiß ja im Gegensatz zu 
Dir gar nicht, welche Erweiterungen brauchbar sind und welche nicht. Das 
heißt, er muß die gewünschten Erweiterungen entweder gegen die letzten n 
Joomla-Versionen und -Patchstände testen und hat dann immer noch keine 
Garantie, daß das nächste Update ihm nicht die Seite zerschießt. Oder, 
er muß ein aufwändiges Staging betreiben, mit dem er jedes einzelne 
Update vor der Installation überprüft, und eine 
Fehlerbehandlungsstrategie entwickeln, wenn ein Update mal nicht 
funktioniert. Oder er wählt den ganz sicheren Weg und verzichtet muß 
gänzlich auf Erweiterungen, aber das führt einen Kernaspekt der 
genannten Vorzüge von Joomla ad absurdum.

>> wenn man derartige Software wenigstens
>> halbwegs sicher betreiben möchte. Insbesondere Mainstream-Systeme
>> stellen dabei hohe Anforderungen, denn einerseits sind Monokulturen nun
>> einmal besonders anfällig für Schädlinge, und andererseits sind zuviele
>> Jäger bekanntlich des Hasen Tod.
>
> Ja, das ist leider so: je bekannter, desto häufiger sind die
> Angriffsversuche. Da kann man ja auch etwas vorsorgen. Durch unsere
> Code/Datenbank-Überwachung wäre mir zumindest ein aktiver Einbruch rasch
> bekannt.

Für sowas gibt es übrigens fertige Systeme für die hostbasierte 
Intrusion Detection, etwa AIDE, OSSEC und den Klassiker Snort.

> Ob der OP wirklich ein CMS braucht?
> Vermutlich reicht ihm wirklich eine statische Seite.

Das können wir nur vermuten oder nicht -- entscheiden kann das nur der 
OP. Da er aber selbst schreibt, daß er nur etwas einfaches sucht, 
dürften der Aufwand für die Einarbeitung und die Pflege eines 
vollständigen CMS wohl eher nicht gerechtfertigt sein.

> Selbst für uns hier ist Joomla eigentlich oversized (ich bin der einzige
> Autor ;-)

Dann bist Du ein Single Point Of Failure: wenn Du für längere Zeit krank 
bist, haben Du, Deine Kunden und Deine Joomla-Installationen ein 
Problem.

> Und: wenn man sich einmal in etwas eingearbeitet hat, dann wechselt man
> ungern. In Joomla bin ich jetzt seit Jahren halbwegs fit und kann meine
> Erweiterungen problemlos selbst schreiben. Einbrüche hatten wir noch
> nicht (was aber auch nichts heißen muss).

Das ist genauso verständlich, wie die Tatsache daß jeder seine Werkzeuge 
für die besten hält. Schließlich hat er ja bereits erheblichen Aufwand 
in deren Einarbeitung, Pflege und Erweiterung investiert. Diesen eigenen 
BIAS -- dem ich genauso unterliege wie Du und alle anderen -- muß man 
immer im Hinterkopf haben. Weil ich das weiß, habe ich ganz bewußt davon 
abgesehen, große Systeme wie Zope oder Django mit ihrem inhärenten 
Einarbeitungs- und Wartungsaufwand zu empfehlen und das stattdessen 
Flask empfohlen. Ich gehe sogar so weit, zu behaupten, daß es ein 
deutlich kleinerer, vielseitigerer und deswegen lohnenderer Aufwand ist, 
sich Python und Flask anzueignen, als ein nur in der Webnische nutzbares 
CMS- oder Weblog-System in PHP.

Daniel A. schrieb:
> Sheeva P. schrieb:
>> Doch. PHP kann ja nichtmal Multithreading oder Multiprocessing, EOD.
>
> Schonmal gegoogelt vor dem Schreiben?

Natürlich.

> https://secure.php.net/thread
> https://secure.php.net/manual/de/function.pcntl-fork.php

Das sind lediglich nachträgliche Erweiterungen für die Sprache -- und 
demzufolge sind diverse Teile der Sprachmittel dann auch nicht 
threadsafe. Ernstzunehmende Programmiersprachen haben das bereits in 
ihrem Sprachkern integriert, und brauchen dazu keine obskuren 
Erweiterungen, die bei einem Update neu zu kompilieren und mit anderen 
Subsystemen inkompatibel sind.

Gib Dir keine Mühe -- ich diskutiere solche Themen schon seit vielen 
Jahren mit bekannten PHP-Koryphäen wie Björn Schotte und Volker Göbbels, 
und habe mit denen jeden, aber auch wirklich jeden einzelnen Aspekt bis 
zum Erbrechen und weit darüber hinaus ausdiskutiert.

Ich kenne PHP, seine Anwendung und seine Interna sehr gut, ich habe 
(gegen Schmerzensgeld) jahrelang damit entwickelt. Genau das ist der 
Grund, warum ich diese Sprache und ihre Fänbois nicht mehr ernstnehmen 
kann. Ich sag' nur: Namensräume. Und bevor Du über das nächste Stöckchen 
hüpfst: ja, die gibts es mittlerweile auch, nachdem die Coreentwickler 
jahrelang darüber gestritten und verschiedene inoffizielle Patches dafür 
herausgebracht haben -- und die Lösung, die es letztlich in den 
offiziellen Sprachkern geschafft hat, ist dermaßen häßlich, daß dagegen 
sogar Perl plötzlich elegant und aufgeräumt aussieht.

Daher schlage ich vor, daß wir uns die millionste leidige Diskussion 
über PHP einfach mal sparen und dem TO helfen, eine für sein Vorhaben 
passende, vernünftige Lösung zu finden.

Ich weiß nicht, wie es euch damit geht, aber ich versuche auf solche 
Threads garnicht zu antworten (manchmal kann ich es mir trotzdem nicht 
verkneifen). Solche Prinzipien-Diskussionen erkennt man schon an Titeln 
a la "Windows besser als Linux ?", "PC besser als Mac ?", "Was ist der 
beste Einstieg für ... ?".

In der Folge schlagen sich die tatsächlichen und selbsternannten 
Experten die Argumente auf einer Bewusstseinsebene um die Ohren, die dem 
TO, sollte er kein Troll sein, ohnehin nichts bringen. Wenn er doch ein 
Troll ist, hat er sein Ziel erreicht.

Sheeva P. schrieb:
> Bei Begriffen wie "halbautomatische Aktualisierung" rollen sich bei
> erfahrenen Sysops die Fußnägel auf! ;-)

Daher auch die Klammer - man kann, muss aber nicht automatisch 
aktualisieren :-)

>> Man muss es aber auch tun :-)
> ...und können! ;-)

Klar :-) Aber das sind hier nur zwei Klicks. Ist also nicht so 
dramatisch.

Bisher gab es bei uns mit Updates auch noch keine Probleme. Getestet 
wird allerdings vorher trotzdem.

>> Wichtig ist es mMn, nicht jeden Mist zu installieren.
>> Es gibt unter Joomla wirklich auch hingerotzte Komponenten.
>
> Das ist der Punkt, der die Sache so aufwändig und problematisch macht.
> Auf der einen Seite preist Du Joomla wegen seiner Erweiterungen an, auf
> die Du nicht verzichten willst. Auf der anderen Seite mußt Du jedoch
> eingestehen, daß viele Joomla-Erweiterungen schlecht programmiert
> sind...

Ich sehe da keinen Widerspruch.

Schlecht programmierte Module/Bibliotheken/Erweiterungen hast Du in 
jeder Sprache, in jedem CMS usw.

Man sollte sich die Erweiterungen eben genau ansehen, schauen, wer 
dahintersteckt, wie gute auf Bugs reagiert wird usw.
Dann kann man da schon recht gut die Spreu vom Weizen trennen.

> Für jemanden, der sich mit Joomla nicht so gut auskennt wie Du, stellt
> das ein unlösbares Problem dar. Denn derjenige weiß ja im Gegensatz zu
> Dir gar nicht, welche Erweiterungen brauchbar sind und welche nicht.

Naja, das wusste ich damals als Neuling auch nicht - aber offenbar kann 
man das durchaus herausfinden.

Ich hab in den kompletten Auftritt damals allerdings auch zwei Monate 
regelmäßiger Arbeit investiert.

Mit Schnellschüssen und wild zusammengeklickten Erweiterungen wird man 
da sicher nicht glücklich.

> heißt, er muß die gewünschten Erweiterungen entweder gegen die letzten n
> Joomla-Versionen und -Patchstände testen und hat dann immer noch keine
> Garantie, daß das nächste Update ihm nicht die Seite zerschießt.
> er muß ein aufwändiges Staging betreiben, mit dem er jedes einzelne
> Update vor der Installation überprüft, und eine
> Fehlerbehandlungsstrategie entwickeln, wenn ein Update mal nicht
> funktioniert.

Das muss er aber in jedem Fall - ganz unabhängig von Joomla. Wer so 
tollkühn ist und ein Update ohne Test über die aktive Serverseite laufen 
lässt, dem ist nicht mehr zu helfen, ganz unabhängig von der Art des 
CMS.

> Oder er wählt den ganz sicheren Weg und verzichtet muß
> gänzlich auf Erweiterungen, aber das führt einen Kernaspekt der
> genannten Vorzüge von Joomla ad absurdum.

Das Kernsystem alleine kann man schon nutzen - es ist immer eine Frage 
der Forderungen, die die Seite erfüllen muss.

Nun: einarbeiten muss man sich natürlich, aber es gibt auch Foren, in 
denen man auch als Anfänger gute Hilfe erhält.

>>> wenn man derartige Software wenigstens
>>> halbwegs sicher betreiben möchte. Insbesondere Mainstream-Systeme
>>> stellen dabei hohe Anforderungen, denn einerseits sind Monokulturen nun
>>> einmal besonders anfällig für Schädlinge, und andererseits sind zuviele
>>> Jäger bekanntlich des Hasen Tod.
>>
>> Ja, das ist leider so: je bekannter, desto häufiger sind die
>> Angriffsversuche. Da kann man ja auch etwas vorsorgen. Durch unsere
>> Code/Datenbank-Überwachung wäre mir zumindest ein aktiver Einbruch rasch
>> bekannt.
>
> Für sowas gibt es übrigens fertige Systeme für die hostbasierte
> Intrusion Detection, etwa AIDE, OSSEC und den Klassiker Snort.

Klar, aber unsere Lösung ist sehr einfach und ich kann sie genau auf 
unsere Seite anpassen und vor allem benötige ich dafür keine weitere 
Software auf unserem Server (wir haben hier einen gemanagten Server) - 
die dann wieder Bugs/Lücken enthalten kann.

>> Ob der OP wirklich ein CMS braucht?
>> Vermutlich reicht ihm wirklich eine statische Seite.
>
> Das können wir nur vermuten oder nicht -- entscheiden kann das nur der
> OP. Da er aber selbst schreibt, daß er nur etwas einfaches sucht,
> dürften der Aufwand für die Einarbeitung und die Pflege eines
> vollständigen CMS wohl eher nicht gerechtfertigt sein.

Ja, sehe ich mittlerweile auch so.

>> Selbst für uns hier ist Joomla eigentlich oversized (ich bin der einzige
>> Autor ;-)
>
> Dann bist Du ein Single Point Of Failure: wenn Du für längere Zeit krank
> bist, haben Du, Deine Kunden und Deine Joomla-Installationen ein
> Problem.

Ich glaube, das mißverstehst Du: ich habe nur eine einzige Installation 
- die auf meinem Webserver. Ich biete keine Dienste rund um Joomla an.

Wenn ich längere Zeit krank bin, dann hat mein Unternehmen aber ganz 
andere  Probleme als die Website, da ich nur noch einen Mitarbeiter habe 
der sich mit den Updates/der Wartung allerdings auskennt :-)
(natürlich bin ich für den Fall finanziell abgesichert, aber meine 
Ideen/Entwicklungen und meine Arbeit fehlen trotzdem.)

> Ich gehe sogar so weit, zu behaupten, daß es ein
> deutlich kleinerer, vielseitigerer und deswegen lohnenderer Aufwand ist,
> sich Python und Flask anzueignen, als ein nur in der Webnische nutzbares
> CMS- oder Weblog-System in PHP.

Klar - allerdings half mir das damals nicht viel: meine gewünschten 
Komponenten gab es da nur für Joomla bzw. so, dass sie leicht in Joomla 
integriert werden konnten.

Das war ja damals der Grund, warum Joomla bei uns den Zuschlag erhalten 
hat - es ging ausschließlich um die entsprechende Erweiterungen.

Dass das ein CMS ist, war mir damals auch egal: es erfüllte einfach 
meine Ansprüche.