Hiho, also ich stehe gerade vor einem, nunja, kleinem Problem. Ich würde gerne eine Webseite erstellen, nichts wildes, aber es sollte dennoch einen gewissen Modernen "Touch" haben. Gaaanz früher hatte ich das mit normalen HTML, PHP und für Tastenevents wie MouseOver Javascript gemacht. Aber wie macht man das am besten heute? Ich bin da schon so dermaßen raus mit den Jahren. Gibt es gute und kostenfreie WYSIWYG Editoren?! :D
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.
:
Bearbeitet durch User
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.
Wenn keine dynamischen Inhalte nötig sind, gibt's auch noch die Möglichkeit, das CMS lokal oder gar in einer VM zu betreiben und daraus statische HTML-Seiten zu exportieren, die man dann auf der Server lädt. Für Typo3 gibt's 'ne Extension, die das automatisch macht, wenn man die Seite ändert; dürfte bei anderen CMS ähnlich sein. Such-Stichwort 'static site export'. Bis dann dann: Jochen
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,...)
:
Bearbeitet durch User
Wenn man alte IE oder Netscape noch unterstützen will kann man auch alles noch in HTML3 oder niedriger coden. HTML5 ist aktueller Standard und daher zu bevorzugen. Ob Du nun dynamische Inhalte via PHP, CGI oder RubyOnRails erzeugst bleibt Dir überlassen. RubyOnRails ist die mächtigste Variante allerdings komplett anderer Ansatz. Da HTML5 nun offiziell als
1 | <!DOCTYPE HTML>
|
definiert ist sollte man das nehmen außer man braucht Dinge die HTML5 nicht abbilden kann. Wenn's ein BLOG, FORUM oder DynamischeWebseite werden soll gibt es wie schon erwähnt Freeware CMS, Forensoftware und Blogsoftware. Einfach mal ansehen und das was man am einfachsten findet und schnell bedienen kann nehmen. Sicherheitsprobleme sind natürlich immer im Auge zu halten.
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
Dirk D. schrieb: > 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. > RubyOnRails ist ein reines Framework und keine erweiterte OO Sprache die speziell für WWW entwickelt ist ? PHP ist definitiv nicht mächtiger nur bekannter und mehr im Einsatz. JEE wäre auch mächtiger als PHP wenn ORACLE ja nicht ... 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 oder man schreibt sich einen eigenen Webserver der Interaktionen der Webseite auswertet. Das läßt sich beliebig weiterführen.
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.
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.
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?! :)
Dirk D. schrieb: > Da frag ich mich doch ob du eher das mit der halbgaren OO meinst oder > das mit der gem / rbenv Hölle?! :) Mh, ich verwende RVM ;)
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: > Damit vereint PHP die schlechtesten Eigenschaften http://news.php.net/php.internals/70691: > Back when PHP had less than 100 functions and the > function hashing mechanism was strlen(). In order to get a nice hash > distribution of function names across the various function name lengths > names were picked specifically to make them fit into a specific length > bucket.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.