nicht angemeldet Kirsten Evers
Kirsten Evers
Kirsten Evers
Kirsten Evers
Auge
hallo Forum,
vermutlich bekomme ich demnächst mal wieder einen "Kunden", dem ich einiges basteln darf. Es handelt sich dabei um eine bundesweit vertretene mittelgroße Organisation, die einen root-Server aufgesetzt haben möchte, Betriebssystem soll unbedingt Debian sein, und ich müßte mindestens einen mail-Server einrichten und ein CMS basteln.
Hm. So einen Auftrag nimmt man, falls er denn zustande kommt, ganz gerne an. Die bezahlen zwar keine Höchstsummen, aber wenn sie eine Bezahlung zusagen, dann zahlen sie auch - was man leider nicht immer bei allen "Kunden" voraussetzen kann.
Etwas Grübeleien bereitet mir das vermutlich zu erstellende CMS. Bei allen Ansätzen, an denen ich mich bisher versucht habe, war ich gezwungen, für die Formatierung von Schrift (fett, kursiv, unterstrichen, eingerückt usw.) Javascript bzw. sogar JScript einzusetzen. Das "Gerüst" kann wahlweise Perl oder PHP sein, ob ich das auch mit C/C++ hinkriege, weiß ich (noch) nicht. Aber mich stört, daß ich bisher für Schriftformatierungen nur Lösungen mit Javascript kenne. Wie kann man das besser machen? Beziehungsweise - um es etwas allgemeiner zu formulieren - wie geht man an das Konzept für ein CMS heran, bei dem es im wesentlichen darauf ankommt, daß Leute Grafiken und Text einbinden und bei Bedarf auch ein paar Textblöcke unerschiedlich formatieren dürfen? Bestehende Seiten sollen sie nicht unbedingt mehr ändern dürfen, aber neue erstellen.
Grüße aus Berlin
Christoph S.
Hallo Christoph,
Etwas Grübeleien bereitet mir das vermutlich zu erstellende CMS. Bei allen Ansätzen, an denen ich mich bisher versucht habe, war ich gezwungen, für die Formatierung von Schrift (fett, kursiv, unterstrichen, eingerückt usw.) Javascript bzw. sogar JScript
vermutlich meinst du dann ECMAScript, wobei mir schleierhaft ist, wie du auf die Idee kommst, damit Text zu formatieren.
HTML, XHTML bieten dir doch dazu genügend Tags (<em>, zum Beispiel)
einzusetzen. Das "Gerüst" kann wahlweise Perl oder PHP sein, ob ich das auch mit C/C++ hinkriege, weiß ich (noch) nicht. Aber mich stört,
Naja, ein webbaseirtes (darum geht es doch, oder?) CMS auf C/C++-Basis wäre sicherlich mal ein ganz nettes Projekt. Viel Spaß damit!
daß ich bisher für Schriftformatierungen nur Lösungen mit Javascript kenne.
Aber HTML sagt dir schon was, oder?
Wie kann man das besser machen? Beziehungsweise - um es etwas allgemeiner zu formulieren - wie geht man an das Konzept für ein CMS heran, bei dem es im wesentlichen darauf ankommt, daß Leute Grafiken und Text einbinden und bei Bedarf auch ein paar Textblöcke unerschiedlich formatieren dürfen? Bestehende Seiten sollen sie nicht unbedingt mehr ändern dürfen, aber neue erstellen.
Grob gesagt:
du baust ein Template, das so aussieht:
<html>
<body>
<h1>mein tolles template</h1>
<div id="content">$content</div>
</body>
</html>
Nun gehst du hin und ersetzt die Variable Content durch das, was der Benutzer des CMS dort eingetragen haben will.
Das muss natürlich HTML-konform sein.
Abspeichern kannst du die Texte dann direkt als HTML-Bruchstücke. Der User kann Sie bearbeiten zum Beispiel mit FCKEdit
HTH,
Sebastian
hi,
Aber HTML sagt dir schon was, oder?
Wenn ich lange genug überlege ... ja, natürlich, das hat irgendwas mit dem Titel dieses Forums zu tun ;-)
du baust ein Template
Mit Templates zu arbeiten wäre prinzipiell möglich, ja.
Der User kann Sie bearbeiten zum Beispiel mit FCKEdit
Genau das soll der "User" eben nicht nötig haben, sonst könnte ich mir die Zappelei sparen.
Ein CMS ist _ungefähr_ sowas wie ein online-WYSIWYG-Editor. Es gibt ein paar sehr einfach gestrickte, und es gibt Monster wie Typo3. Es gibt kommerzielle für sehr viel Geld, und es gibt ein paar freie. Alle haben mehr oder weniger "Eigenheiten". Bei meinem möglichen Kunden gehts darum, eben "eigene Eigenheiten" zu entwickeln.
Zu einem solchen "Editor" gehört es, daß der "user" sich irgendwie eine Vorschau anzeigen lassen kann, bzw. im besten Fall eine Textstelle mit der Maus markiert, dann auf einen button klickt - und schwupps, schon sieht er die gewünschte Textformatierung, genauso, wie man es von Word her kennt. Das heißt, daß in diesem Zustand seine Arbeit noch nirgends gespeichert ist, sondern in seinem Cache bzw. in seinem Auslagerungsspeicher herumschwirrt. Das bedeutet aber auch, daß noch keinerlei "Template" befüllt werden konnte - und an dieser Stelle sehen die Konzepte, die ich kenne, Javascript bzw. JScript vor. Ach, übrigens: die Bezeichnung "Javascript" hat sich historisch etabliert, seit Netscape das Konzept dafür erfand. JScript unterscheidet sich in einigen Punkten davon. Von ECMA-Script spricht kaum jemand, auch wenn es die Bezeichnung für die standardisierte Form wäre.
Natürlich kann ich mir anschauen, wie es CK angestellt hat, daß hier im Forum bei Aufruf der Vorschau bestimmte Script-Bausteine, die man eventuell posten möchte, farblich abgesetzt erscheinen. Das Forum läuft über einen ganzen Berg an Templates, aber es ist halt ein C-Forum, und als "richtungweisendes Beispiel" in meinem Fall nur beschränkt nutzbar.
Grüße aus Berlin
Christoph S.
öhm ...
und an dieser Stelle sehen die Konzepte, die ich kenne, Javascript bzw. JScript vor.
In PHP-basierten Boards gibt es den PHPBB-Code. Ich benutze ihn (teilweise), sofern ich mich an solchen Foren beteilige. Allerdings habe ich ihn noch nie in irgendein Projekt implementiert. Da gibts aber doch jemand hier im Forum, der einen Verweis auf diesen Code in seiner Signatur führt ...
;-)
Grüße aus Berlin
Christoph S.
Moin!
Zu einem solchen "Editor" gehört es, daß der "user" sich irgendwie eine Vorschau anzeigen lassen kann, bzw. im besten Fall eine Textstelle mit der Maus markiert, dann auf einen button klickt - und schwupps, schon sieht er die gewünschte Textformatierung, genauso, wie man es von Word her kennt.
Das ist WYSIWYG. Die Abkürzung bedeutet: What you see is what you get.
Das heißt, daß in diesem Zustand seine Arbeit noch nirgends gespeichert ist, sondern in seinem Cache bzw. in seinem Auslagerungsspeicher herumschwirrt.
Nein, das heißt das nicht zwingend. In den meisten CMS _ist_ das so, aber die meisten CMS nutzen ja auch kein AJAX.
Das bedeutet aber auch, daß noch keinerlei "Template" befüllt werden konnte - und an dieser Stelle sehen die Konzepte, die ich kenne, Javascript bzw. JScript vor.
Richtig, denn Javascript ist das einzige, was man benutzen kann, wenn man komplexe User-Interaktion im Browser erlauben möchte.
Natürlich kann ich mir anschauen, wie es CK angestellt hat, daß hier im Forum bei Aufruf der Vorschau bestimmte Script-Bausteine, die man eventuell posten möchte, farblich abgesetzt erscheinen.
Das bringt dir nichts!
Die Textarea hier im Forum ist genau das: Ein reines "Plain Text" Eingabefeld. Dort eingegebener Text wird im Grundsatz ohne weiteres Formatieren 1:1 durchgereicht zur Ausgabe.
Eingebaut ist dann noch eine Abart von BB-Code, durch welchen klickbare Links, Einbindung von Bildern und zuletzt auch Syntax-Highlighting von Quellcode möglich werden.
Dieser Mechanismus ist aber so kompliziert, dass man ihn keinem normalen Benutzer zumuten möchte. Das Zielpublikum hingegen sollte grundsätzlich Verständnis für die Textauszeichnung haben, deshalb ist diese Quellcode-Eingabe dann kein großes Problem (obwohl: Doch! Links kriegt hier ja schon kaum einer richtig hin, du meckerst das doch bei jedem an).
Die farbliche Hervorhebung von Zitaten geschieht einzig auf Basis der Anwesenheit des userspezifisch eingestellten Zitatzeichens am Zeilenbeginn, ebenso wie die Auszeichnung der Signatur.
Alles sind Mechanismen, die man in einem benutzerfreundlichen Texteditor für ein CMS nicht haben kann. Dort gibt es nur zwei Möglichkeiten:
1. Entweder der Benutzer kriegt einen WYSIWYG-Editor durch Javascript und kann damit ähnlich wie in Word arbeiten. Es wäre deine Aufgabe, den Editor so zu konfigurieren, dass dieser nur HTML ausspuckt, welches dir gefällt und welches zum Stylesheet der Site paßt (damit das CI eingehalten wird). Damit hat der Benutzer dann komfortable Möglichkeiten, Fettschrift, Bilder, Links, Tabellen etc. zu realisieren.
2. Oder der Benutzer kriegt nur eine Textarea oder ein Text-INPUT zur Eingabe seines reinen Textes, darf aber keinerlei Formatierungen integrieren. Dann bedeutet das, dass du ausreichend viele Templates oder Templatefragmente produzieren mußt, die alle Formatierungen schon mitbringen, und in die nur noch der Text passend hineingeschrieben wird. Mit Templatefragmenten sind so Dinge wie "Überschrift groß", "Überschrift klein", "Textabsatz" oder "Tabelle mit 4 Spalten" gemeint. Diese Templatefragmente kann der Benutzer dann vielleicht noch passend übereinander anordnen und sortieren. Nur eventuell kann dem Benutzer die Integration von HTML oder BB-Code in den eingegebenen Text gestattet werden.
Fakt ist: Keine der Methoden 1 oder 2 führt zu optimalem HTML-Text, wie du ihn dir vorstellst.
Die schwierigste Aufgabe wird es also sein, dass du deinen Perfektionismus besiegst und dir auch suboptimale Ergebnisse erlaubst. Der Kunde wird, auch mit Schulung und Ratschlägen, deine guten Vorsätze sowieso versauen. Und sei es nur, indem er als Textinhalt nur einen einzigen <p>-Block einbaut, innerhalb dessen er Absätze durch <br><br> erzeugt. Oder indem er alt-Attribute grundsätzlich nicht belegt.
- Sven Rautenberg
hallo Sven,
Das heißt, daß in diesem Zustand seine Arbeit noch nirgends gespeichert ist, sondern in seinem Cache bzw. in seinem Auslagerungsspeicher herumschwirrt.
Nein, das heißt das nicht zwingend. In den meisten CMS _ist_ das so, aber die meisten CMS nutzen ja auch kein AJAX.
Was würde AJAX denn an diesem Zustand ändern? Es kann auch nicht _gleichzeitig_ eine benutzer-erzeugte Aktion im Browser und auf dem Server in Gang setzen, soviel ich bisher davon weiß.
Das bedeutet aber auch, daß noch keinerlei "Template" befüllt werden konnte - und an dieser Stelle sehen die Konzepte, die ich kenne, Javascript bzw. JScript vor.
Richtig, denn Javascript ist das einzige, was man benutzen kann, wenn man komplexe User-Interaktion im Browser erlauben möchte.
Genau das, nämlich die "komplexe User-Interaktion", ist der Kern meiner Nachfrage. Dann wird es vermutlich doch nicht ohne Javascript gehen können. Es sei denn, ich baue noch irgendeine kleine Applikation auf PHP-CLI-Basis, die sich aber jeder, der schreibend drauf zugreifen will, erst downloaden müßte. Das ist bei einigen zehntausend zu erwartenden "usern" aber ein enormes Risiko.
Natürlich kann ich mir anschauen, wie es CK angestellt hat, daß hier im Forum bei Aufruf der Vorschau bestimmte Script-Bausteine, die man eventuell posten möchte, farblich abgesetzt erscheinen.
Das bringt dir nichts!
Na doch, es bringt was: das große Staunen *g*
Ich habe allerdings auch nur die letzte seinerzeit von CK noch freigestellte Fassung der Forums-Sourcen. Die wird nicht mehr absolut aktuell sein, aber man kann mit viel Mühe das "Bauprinzip" nachvollziehen.
Die Textarea hier im Forum ist genau das: Ein reines "Plain Text" Eingabefeld. Dort eingegebener Text wird im Grundsatz ohne weiteres Formatieren 1:1 durchgereicht zur Ausgabe.
Eingebaut ist dann noch eine Abart von BB-Code, durch welchen klickbare Links, Einbindung von Bildern und zuletzt auch Syntax-Highlighting von Quellcode möglich werden.
Dieser Mechanismus ist aber so kompliziert, dass man ihn keinem normalen Benutzer zumuten möchte.
Der muß es aber nur benutzen können und braucht davon, wie es vielleicht funktioniert, überhaupt nix zu wissen.
Alles sind Mechanismen, die man in einem benutzerfreundlichen Texteditor für ein CMS nicht haben kann. Dort gibt es nur zwei Möglichkeiten:
[...]
Fakt ist: Keine der Methoden 1 oder 2 führt zu optimalem HTML-Text, wie du ihn dir vorstellst.
Die schwierigste Aufgabe wird es also sein, dass du deinen Perfektionismus besiegst
Naja, nicht unbedingt meinen. Sondern ich muß die Erwartungshaltung des möglichen Auftraggebers (das ist in dem Fall ein stellvertretender Vorsitzender) korrigieren. Das ist weit schwieriger, da der zwar sehr viel von Ästhetik, aber so gut wie nichts von den Webtechnologien versteht.
Grüße aus Berlin
Christoph S.
Hallo
Das heißt, daß in diesem Zustand seine Arbeit noch nirgends gespeichert ist, sondern in seinem Cache bzw. in seinem Auslagerungsspeicher herumschwirrt.
Nein, das heißt das nicht zwingend. In den meisten CMS _ist_ das so, aber die meisten CMS nutzen ja auch kein AJAX.Was würde AJAX denn an diesem Zustand ändern? Es kann auch nicht _gleichzeitig_ eine benutzer-erzeugte Aktion im Browser und auf dem Server in Gang setzen, soviel ich bisher davon weiß.
Wenn die Vorschau des zu erwartenden Ergebnis per JavaScript im Browser geladen wird, wird der momentane Stand auch per Ajax an den Server gesandt. Damit fällt dein Satz von "noch nirgends gespeichert[en]" Zustand (sozusagen) "weg".
Tschö, Auge
hallo,
Wenn die Vorschau des zu erwartenden Ergebnis per JavaScript im Browser geladen wird, wird der momentane Stand auch per Ajax an den Server gesandt. Damit fällt dein Satz von "noch nirgends gespeichert[en]" Zustand (sozusagen) "weg".
Hm. Ich habe mir grade mal einen winzigen "Summy" gebastelt - also einfach bloß eine Textarea und ein klein bißchen Javascript. Es scheint so, als ob du recht hättest.
Allerdings ging meine Frage im OP ja dahin, ob derlei "WYSIWYG-Effekte" nicht auch gänzlich ohne Javascript möglich sind. Es scheint bedauerlicherweise entweder wirklich nicht möglich oder zumindest nicht bekannt. Und wenn es hier im Forum keiner weiß - naja, dann ist es halt nicht möglich, da, was hier nicht bekannt ist, schlichweg nicht existieren kann ;-)
Grüße aus Berlin
Christoph S.
Hallo
Allerdings ging meine Frage im OP ja dahin, ob derlei "WYSIWYG-Effekte" nicht auch gänzlich ohne Javascript möglich sind. Es scheint bedauerlicherweise entweder wirklich nicht möglich oder zumindest nicht bekannt.
Solange das im Browser laufen soll, kannst du nur dessen Möglichkeiten nutzen. Wobei mir auf die Schnelle nur JavaScript bzw. JScript, Java und Flash einfallen.
Und wenn es hier im Forum keiner weiß - naja, dann ist es halt nicht möglich, da, was hier nicht bekannt ist, schlichweg nicht existieren kann ;-)
Holla, welch Anspruch. :-)
Tschö, Auge
Moin!
Das heißt, daß in diesem Zustand seine Arbeit noch nirgends gespeichert ist, sondern in seinem Cache bzw. in seinem Auslagerungsspeicher herumschwirrt.
Nein, das heißt das nicht zwingend. In den meisten CMS _ist_ das so, aber die meisten CMS nutzen ja auch kein AJAX.Was würde AJAX denn an diesem Zustand ändern?
Mit AJAX kannst du im Hintergrund, wahlweise bei jedem Tastendruck, oder in einer Tipppause (hab ich da gerade wirklich 3 p getippt?), den bisherigen Content zum Server schicken und damit vor der unabsichtlichen Vernichtung retten - und vor dem Session-Timeout (war wirklich ein blödes Ding, das mich in Contenido ziemlich geärgert hat: Fixes Timeout nach 60,0 Minuten dank selbstgestrickter Session-Engine. Blöd, wenn man als User dann mehr als eine Stunde per WYSIWYG am aufwendigen Layout der Seite, z.B. mit Tabelle darin, bastelt).
Es kann auch nicht _gleichzeitig_ eine benutzer-erzeugte Aktion im Browser und auf dem Server in Gang setzen, soviel ich bisher davon weiß.
Das Konzept der Gleichzeitigkeit existiert ja sowieso nicht. Nichts passiert wirklich exakt gleichzeitig, es gibt immer miniminiminifeinste Abweichungen, die irgendwann in der Zeitunschärfe nicht mehr genau beobachtbar sind ... aber das sind philosophisch-wissenschaftliche Nebensächlichkeiten, für das Web gilt: Mit AJAX geht ziemlich viel, und es wirkt tatsächlich so, als geschehe es "gleichzeitig".
Nur den armen Browser mit zuvielen Scripten überlasten - das sollte man vermeiden.
Genau das, nämlich die "komplexe User-Interaktion", ist der Kern meiner Nachfrage. Dann wird es vermutlich doch nicht ohne Javascript gehen können. Es sei denn, ich baue noch irgendeine kleine Applikation auf PHP-CLI-Basis, die sich aber jeder, der schreibend drauf zugreifen will, erst downloaden müßte. Das ist bei einigen zehntausend zu erwartenden "usern" aber ein enormes Risiko.
Wozu die Applikation? Was soll die tun? Javascript ist doch nur für die Redakteure relevant. Gibts zehntausend Redakteure beim Kunden?
Wenn es nur zehntausend Personen in der Kundenorganisation gibt, solltest du alles unternehmen, die nicht alle komplett zu Redakteuren werden zu lassen. Dann kannst du das Erscheinungsbild der Website nämlich innerhalb von einer Stunde knicken. Außerdem kann die Schulung niemand finanzieren.
Wenn es aber tatsächlich so viele Redakteure gibt, dann benötigst du zwingend ein ausgewachsenes Redaktionssystem mit ausgeklügelter Rechteverwaltung. Alles andere (Editor etc.) ist dann erstmal komplett zweitrangig, denn bei zehntausend Redakteuren kommt mit Sicherheit von den Chefs die Anforderung, dass ein x-beliebiger Redakteur nicht die komplette Site bearbeiten oder löschen darf, sondern nur seinen Bereich.
Mein Erfahrungswert hingegen: Egal ob es zwei, zehn oder tausend Redakteure geben _könnte_: Keine der Personen, die schon den normalen Tätigkeitsalltag für die Organisation haben, hat noch Zeit, sich nebenbei mit dem Webauftritt zu befassen - erst recht nicht mit der Einarbeitung in das System, nur um alle zwei Monate mal irgendwas online zu stellen oder zu ändern.
Hingegen ist jede Person in der Lage, dem zuständigen Webmaster oder hauptamtlichen Webredakteur oder -team eine Mail mit Neuigkeiten oder Änderungen zu schicken. Und das wird dann von zentraler Stelle aus eingearbeitet. Hat den Vorteil: Der Webredakteur macht nichts anderes, kennt sich folgerichtig recht bald mit dem CMS aus, wendet insbesondere die gleichen Mechanismen für die gleichen Informationselemente an, so dass auch ein hoher Wiedererkennungs- und Ähnlichkeitswert gegeben ist.
Eingebaut ist dann noch eine Abart von BB-Code, durch welchen klickbare Links, Einbindung von Bildern und zuletzt auch Syntax-Highlighting von Quellcode möglich werden.
Dieser Mechanismus ist aber so kompliziert, dass man ihn keinem normalen Benutzer zumuten möchte.Der muß es aber nur benutzen können und braucht davon, wie es vielleicht funktioniert, überhaupt nix zu wissen.
Richtig, aber er muß sich merken oder andauern in der Hilfe nachlesen, wie denn das nochmal ging mit den Links.
Erfahrungswert: Teilzeit-Redakteure, die in großem zeitlichem Abstand mit dem CMS arbeiten (müssen), vergessen die einfachsten Dinge wieder.
Und wenn dann die Funktion noch so extrem harsche Anforderungen an die syntaktische Korrektheit der Linksetzung hat, verzweifelt der Redakteur sofort und läßt es lieber.
Guck dich doch einfach nur mal in einigen Boards mit BB-Code um: Da formatiert auch nur eine Minderheit ihre Texte, der Rest kommt mit schlichtem Tippen auch ganz gut über die Runden.
Die schwierigste Aufgabe wird es also sein, dass du deinen Perfektionismus besiegst
Naja, nicht unbedingt meinen. Sondern ich muß die Erwartungshaltung des möglichen Auftraggebers (das ist in dem Fall ein stellvertretender Vorsitzender) korrigieren. Das ist weit schwieriger, da der zwar sehr viel von Ästhetik, aber so gut wie nichts von den Webtechnologien versteht.
Doch, du mußt _deinen_ Perfektionismus besiegen. Du neigst dazu, einfache Dinge unnötig zu komplizieren, thematischen Abschweifungen zu erliegen, suchst nach dem großen Wurf, dich dabei an unerreichbaren Vorbildern orientierend, der dir vorraussagbar nicht gelingen wird.
Ich glaube, mir dieses Urteil anhand deiner Postings hier im Forum erlauben zu können. Immerhin habe ich es dir zu verdanken, dass eine gewisse Frau I. E. aus Berlin mir unabsichtlich immer noch Mails schickt, die an ganz andere Personen gehen sollten, nur weil dein damaliger Versuch, ihr die Webseite zu verbessern, von ihr als "Aktion von SELFHTML" mißverstanden wurde, und sie sich dann bei uns per Mail beschwert hatte, dass sie vor einer Ruine stand und nichts mehr machen konnte. Damals hat sie meine SELFHTML-Mailadresse der Antwortmail bei sich gespeichert - und ihr Mailprogramm anscheinend nicht unter Kontrolle.
Alleine dieser Erfahrung macht mir für deinen potentiellen Auftraggeber Angst. Und genau deswegen der eindeutige Rat: Beschäftige dich mit Dingen, die du einigermaßen gut kannst. Ein CMS selbst aus dem Hut zaubern gehört definitiv nicht dazu, aber ein existierendes CMS testen, vorschlagen, installieren und den Server anpassen. Die restliche Arbeit ist dann noch genug Herausforderung.
- Sven Rautenberg
hallo Sven,
Immerhin habe ich es dir zu verdanken, dass eine gewisse Frau I. E. aus Berlin mir unabsichtlich immer noch Mails schickt, die an ganz andere Personen gehen sollten, nur weil dein damaliger Versuch, ihr die Webseite zu verbessern, von ihr als "Aktion von SELFHTML" mißverstanden wurde
Ups. Das ist mehr als bedauerlich. Aber darüber hättest du mich selbst längt in Kenntnis setzen können. Das ist kein ganz einfacher Mensch, wie ich seit Jahrzehnten weiß. Ab und an gelingt es mir, ihr etwas zu raten, was sie eventuell befolgt. Nur: wenn ich darüber nicht informiert bin, kann ich auch nichts unternehmen.
Um es sehr kurz auszusagen: sie hat sich im Lauf der Jahre ihre eigene "Legende" erbaut und hält die für wahr. Und opponiert heftig, wenn jemand (in diesem Fall ich) irgendwo irgendetwas aussagt, was zwar tatsächlich wahr ist, aber ihrer heutigen "Legende" nicht mehr entspricht. Sowas kommt bei sehr phantasiebegabten Menschen gelegentlich vor.
Im übrigen neige ich tatsächlich zu einem gewissen "Perfektionismus", was mir in der Regel bisher aber eher weitergeholfen hat.
Grüße aus Berlin
Christoph S.
Tach.
Entweder der Benutzer kriegt einen WYSIWYG-Editor durch Javascript und kann damit ähnlich wie in Word arbeiten.
Oder der Benutzer kriegt nur eine Textarea oder ein Text-INPUT zur Eingabe seines reinen Textes, darf aber keinerlei Formatierungen integrieren.
3. Du benutzt ein Zwischending wie z. B. Textile oder Markdown. Ich weiß, daß es in der Vergangenheit bereits Diskussionen darüber gab, ob die Syntax dieser Systeme wirklich eine Vereinfachung gegenüber BBCode und Konsorten darstellt. Die Meinungen darüber gehen auseinander. Ich möchte sie der Vollständigkeit halber erwähnen, damit Christoph sich ggf. selber ein Urteil darüber bilden kann.
Hallo,
Das "Gerüst" kann wahlweise Perl oder PHP sein, ob ich das auch mit C/C++ hinkriege, weiß ich (noch) nicht.
C im Weboberfläche? Fein, welche EXE müssen die Benutzer dann herunterladen?
»»Aber mich stört, daß ich bisher für Schriftformatierungen nur Lösungen mit Javascript kenne. Wie kann man das besser machen?
Schreibe ein Java-Aplet.
Grüße
Thomas
PS: na gut im Ernst: nimm ein fertigs CMS, installiere es bei dir, teste es aus, erweitere es dort wo notwendig, erstelle vernünftige Templates und dann installiere es am Server.
Alles andere wird weder die Erwartungen erfüllen, weil du schlicht das nicht im Alleingang ausprogrammieren kannst, noch wird deine Zeit dazu reichen etwas was auch nur annährend passen würde auszuprogrammieren.
Hallo,
Alles andere wird weder die Erwartungen erfüllen, weil du schlicht das nicht im Alleingang ausprogrammieren kannst, noch wird deine Zeit dazu reichen etwas was auch nur annährend passen würde auszuprogrammieren.
Kann ich voll unterschreiben. Bei meinem mini CMS Jlog hat es ja schon Jahre gedauert bis es so weit war wie es heute ist, und was da noch so alles fehlt an funktionen ...
Jeena
hallo Thomas,
welche EXE müssen die Benutzer dann herunterladen?
Keine. Ich würde mich allerdings zu CK in Konkurrenz stellen müssen, und da ist ein einigermaßen erfolgversprechendes Ergebnis ziemlich unwahrscheinlich.
Schreibe ein Java-Aplet.
Hey, so verkehrt ist das gar nicht. Allerdings kein Applet, sondern ein Servlet, und ich müßte dann Tomcat auch noch administrieren. An der Idee werde ich noch ein wenig herumdenken. So völlig falsch ist sie gar nicht, es sei denn, -lina hält sie für Blödsinn ;-)
nimm ein fertigs CMS, installiere es bei dir, teste es aus, erweitere es dort wo notwendig, erstelle vernünftige Templates und dann installiere es am Server.
Das wäre eine wahrscheinlich weithin "übliche" Praxis.
Alles andere wird weder die Erwartungen erfüllen, weil du schlicht das nicht im Alleingang ausprogrammieren kannst, noch wird deine Zeit dazu reichen etwas was auch nur annährend passen würde auszuprogrammieren.
Naja, daerzeit ist alles noch Vermutung und Konzeptsuche. Ein Wiki werde ich jedenfalls bestimmt nicht anbieten können ;-)
Grüße aus Berlin
Christoph S.
Hallo Thomas,
Alles andere wird weder die Erwartungen erfüllen, weil du schlicht das nicht im Alleingang ausprogrammieren kannst, noch wird deine Zeit dazu reichen etwas was auch nur annährend passen würde auszuprogrammieren.
Dem kann ich nur voll und ganz zustimmen - es gibt bestimmte Dinge, die brauchen a) Zeit und b) viel Manpower. Ein richtiges CMS gehört auch in diese Kategorie. Christoph, es gibt hunderte CMS, die man frei verwenden kann - such Dir von denen das aus, das Dir am besten gefällt, passe das evtl. noch in Details an und schlag Dir die Idee, sowas selber basteln zu wollen, lieber gleich mal aus dem Kopf.
Viele Grüße,
Christian
Das "Gerüst" kann wahlweise Perl oder PHP sein, ob ich das auch mit C/C++ hinkriege, weiß ich (noch) nicht.
C im Weboberfläche? Fein, welche EXE müssen die Benutzer dann herunterladen?
Das ist sogar relativ üblich unter alten C-Proammierern. Die lassen statt Scripten wirklich C-Programme laufen, die die Ausgabe besorgen. Das wäre höchst performant vgl. bspw. mit PHP, so heisst es. LOL
»»Aber mich stört, daß ich bisher für Schriftformatierungen nur Lösungen mit Javascript kenne. Wie kann man das besser machen?
Schreibe ein Java-Aplet.
Schriftformatierungen würden uns eher auf CSS schliessen lassen, aber vermutlich ist was anderes gemeint.
PS: na gut im Ernst: nimm ein fertigs CMS,
Alles andere wäre Selbstmord. Welche CMSe sind denn gerade in? (vorausgesetzt: MySQL, Unicode-Unterstützung, und alles was ein CMS so können sollte...)
Hi Christoph
Wieso mußt du das CMS denn selber basteln? Gehts auch mit diesem:
http://ez.no/download/ez_publish
Uwe
Portland, Oregon
Hallo Christoph,
Ich habe mein kleines CMS an die Auszeichnungen der Wikipedia angepasst - weil einfach und millionenfach erprobt. Zusätzlich habe ich einige wenige eigene Auszeichnungen hinzugefügt.
'''strong''', ''em'', ==h2==, ===h3===, [Bild:url|größe|klasse|alt-text]
#geordnete
#liste
*ungeordnete
*liste
{{hinweis wichtig:hier der text (p-element der klasse "hinweis wichtig")}}
Viel mehr brauche ich nicht bzw. lässt sich das CMS bei Bedarf sehr leicht erweitern.
lg
Martin Dunst
Hallo!
Beziehungsweise - um es etwas allgemeiner zu formulieren - wie geht man an das Konzept für ein CMS heran, bei dem es im wesentlichen darauf ankommt, daß Leute Grafiken und Text einbinden und bei Bedarf auch ein paar Textblöcke unerschiedlich formatieren dürfen? Bestehende Seiten sollen sie nicht unbedingt mehr ändern dürfen, aber neue erstellen.
Du solltest als aller ersten Deinen Kunden in einem Gespräch kennenlernen. Das bedeutet, wie ist das technische KnowHow Deines Kunden, bzw. der Mitarbeiter die nachher mit dem CMS arbeiten müssen.
Typo3 zum Beispiel richtet sin an technisch versierte Redakteure. Ich würde nie einem Kunden Typo3 aufsetzen, der alle zwei Wochen einen Text einfügt. Mit Jamola, Mambo und Co. ist das genau das selbe.
Pass auf, verrenne Dich nicht in PHPBB-Codes etc. Der Kunde muß wenn Du Dein Auftrag abgeliefert hast, mit dem CMS arbeiten können. Eventuell hat er gar keine Zeit bzw. Lust, spezielle Dinge zu lernen. Ich geben den Kunden WYSIWYG-Editoren an die Hand, dass kennen die von Word. Einfache HTML-Tags kann man den Kunden in 5 Minuten beibringen. So individuell muß der Kunde seine Seiten auch nicht gestalten können. Das Layout und die Struktur der Seiten ist ja sicherlich vorgegeben.
Gerade wenn das Buget klein ist, solltest Du nicht anfangen, etwas selbst zu stricken. Viele Kunden mögen es auch, wenn Du eine fertige Lösung nimmst, weil somit eine gewisse Planungssicherheit besteht.
André Laugks
Tach Christoph,
... wie geht man an das Konzept für ein CMS heran, bei dem es im wesentlichen darauf ankommt, daß Leute Grafiken und Text einbinden und bei Bedarf auch ein paar Textblöcke unerschiedlich formatieren dürfen? Bestehende Seiten sollen sie nicht unbedingt mehr ändern dürfen, aber neue erstellen.
Probiere einfach mal Systeme wie CMS made simple oder PHPWCMS aus. Ersteres arbeitet mit Smarty-Templates, deren Nutzung Du ja mal erwähnt hast.
Man liest sich,
svg4you
habe d'ehre Christoph
vermutlich bekomme ich demnächst mal wieder einen "Kunden", dem ich einiges basteln darf. Es handelt sich dabei um eine bundesweit vertretene mittelgroße Organisation,
Etwas Grübeleien bereitet mir das vermutlich zu erstellende CMS.
Auch wenn ich mit meiner Meinung gegen alle anderen Aussagen stehe: nimm Typo3. Warum?
1.) Berechtigungen können sehr fein justiert werden.
2.) Mehrsprachigkeit einfach zu handeln
3.) Durch saubere HTML-Vorlagen und der Verwendung der *richtigen" Static-Templates auch valider Code
4.) Sehr großer Pool von leicht integrierbaren Extensions
5.) Sehr ausgereiftes System mit großer Verbreitung und sehr guter Community
6.) Der WYSIWYG-Eitor kann exakt auf die CI der Firma eingestellt werden und damit Wildwuchs bei der Formatierung vermieden werden.
7.) Ist die Bedienung nicht so komplex, wie immer gerne behauptet wird.
Zu Deinen Einwänden bzgl. Javascript: Ein CMS läuft in einem geschlossenen Benutzerkreis und eine vernünftige Lösung wirst Du ohne JS nie hinkriegen.
Noch ein Tip: Verabschiede Dich von Deiner C-Idee einer Eigenentwicklung! So gut dieses Forum trotz der mangelhaften Auszeichnungsfähigkeit auch ist, die dafür nötigen technischen Voraussetzungen sind einfach zu hoch. Root-Server hin, Rootserver her. Ein strategisch denkender Entscheidungsträger wird von Dir mit Sicherheit eine nachhaltige Support- und Pflegegarantie einfordern. Diese sind bei einer Eigenentwicklung einfach nicht gegeben (der berühmte Baum). Wenn Du trotz allem nicht davon abgehen willst, auf meiner Seite findest Du als Denkanstoss unter INTERNET Screenshots aus meiner Contentverwaltung
man liest sich
Wilhelm
Auch wenn ich mit meiner Meinung gegen alle anderen Aussagen stehe: nimm Typo3.
Meine Empfehlung: nimm "den kleinen Bruder" von Typo3, Redaxo. Alles, was du (Wilhelm) zurecht forderst, kann Redaxo ebenfalls umsetzen und ist dabei längst nicht so komplex.
Viele Grüße!
_ds
Tach.
Meine Empfehlung: nimm "den kleinen Bruder" von Typo3, Redaxo.
Von Redaxo rate ich persönlich ab. Auf den ersten Blick sind ganz brauchbare Ideen dabei, aber ich halte das Fundament dieses Systems für Schrott. Ich hatte vor einer Weile das Vergnügen, ein damit laufendes Projekt um einige grundlegende Funktionen zu erweitern. Beim Studium des Redaxo-Codes, der DB-Struktur usw. habe ich regelmäßig Herzinfarkte bekommen.
Hi.
Von Redaxo rate ich persönlich ab. Auf den ersten Blick sind ganz brauchbare Ideen dabei, aber ich halte das Fundament dieses Systems für Schrott.
Den Unterbau von Redaxo kann ich als Grafiker nicht beurteilen. Was ich sehe und an Funktionen einsetzen kann, hat mich aber überzeugt. Seit Neuestem habe ich auch Textpattern im Einsatz. Bei beiden begeistert mich Textile.
vg Bud
hallo Wilhelm,
Auch wenn ich mit meiner Meinung gegen alle anderen Aussagen stehe
Och, sowas kommt schonmal vor ;-)
nimm Typo3
Nö. Ist bereits in den bisherigen Kontakten ausgeschlossen worden. Allerdings ist deine Argumentation nachvollziehbar.
Grüße aus Berlin
Christoph S.
habe d'ehre Christoph
nimm Typo3
Nö. Ist bereits in den bisherigen Kontakten ausgeschlossen worden.
Hmhh, die Gründe hierfür würden mich interessieren.
man liest sich
Wilhelm
hallo Wilhelm,
nimm Typo3
Nö. Ist bereits in den bisherigen Kontakten ausgeschlossen worden.
Hmhh, die Gründe hierfür würden mich interessieren.
Im wesentlichen waren das finanzielle Gründe. Und der Hinweis, daß Typo3 schon wieder "zuviele" Features enthalte. Aber das letzte Wort ist ja eh noch nicht gesprochen.
Grüße aus Berlin
Christoph S.
ich müßte mindestens einen mail-Server einrichten und ein CMS basteln.
Wie hier im Thread schon erwähnt wurde: warum die enorme Zeit investieren, um ein CMS selbst zu bauen? Ich fände das nur dann sinnvoll, wenn das spätere CMS ein besonderes (wirtschaftliches/kulturelles/persönliches) Ziel hat oder sich von anderen, bereits existierenden, CMS unterscheidet.
Wir hatten z.B. ebenfalls mal angedacht, ein CMS zu entwickeln, weil uns nahezu alle verfügbaren CMS nicht zusagten. Entweder waren sie nicht flexibel genug (viele kleine CMS), produzierten unsauberes HTML (wie z.B. das eklige Joomla), waren zu komplex (z.B. Drupal), für den Benutzer nicht verständlich, nicht logisch aufgebaut, uns sagte die technische Basis nicht zu (Perl, Java), der Support/die Weiterentwicklung schien wackelig oder aber - und das war der wichtigste Grund von allen - das CMS setzte entweder auf einen WYSIWYG-Editor oder HTML/Metasprache zur Auszeichnung. Beides letztgenannte ist für uns indiskutabel: ein WYSIWYG-Editor führt zu keinen sauberen Ergebnissen, HTML oder eine Metasprache muss vom Benutzer erlernt werden und taugt deshalb nicht für technisch wenig erfahrene Benutzer (Kunden).
Uns war also enorm wichtig, dass ein Artikel innerhalb des CMS nicht in einem Guss (also in einer Textarea), sondern aus einzelnen Blöcken aufgebaut wird, die individuell auf den Inhalt zugeschnitten werden können. Sowas macht zum Beispiel Typo3, oder aber das wunderprächtige Redaxo, das zu unserem Darling wurde und inzwischen für nahezu alle Projekte eingesetzt wird. Es ist brachial flexibel und dabei wunderschön einfach zu benutzen (für den Kunden). Bisher hat sich keine Anforderung ergeben, die Redaxo nicht hätte erfüllen können (allerdings mit etwas Anpassung/Erweiterung unsererseits).
Empfehlung an dich also: Redaxo anschauen und danach die Pläne, ein eigenes CMS zu entwickeln, über Bord schmeißen ;)
Viele Grüße!
_ds
hallo Dirk,
ich müßte mindestens einen mail-Server einrichten und ein CMS basteln.
Ich fände das nur dann sinnvoll, wenn das spätere CMS ein besonderes (wirtschaftliches/kulturelles/persönliches) Ziel hat oder sich von anderen, bereits existierenden, CMS unterscheidet.
Dann mal etwas genauer: bisher gibt es nur zwei elektronische Anfragen und zwei Telefongespräche. Der erste wirkliche "Termin" kommt in der ersten Februarwoche. Erst dann werde ich selber genauer wissen, was der potentielle Kunde denn unter "CMS" versteht oder verstanden haben will. Sie haben bereits jemanden als "Webmaster" seit einiger Zeit eingestellt, der Kumpel fällt ihnen mit bis zu tausend Euro _zusätzlichen_ Fahrgeldforderungen pro Monat aber etwas lästig und sie wollen ihn gerne loswerden. Er hat ihnen allerdings bereits ein CMS geschrieben, dafür aber die Rechte einbehalten, so daß sie es nicht mehr nutzen dürfen, falls sie ihn hinauskomplimentieren.
Ich weiß nun bisher nicht, was der Gute da gebastelt oder auch nur umgestrickt hat. Ich bin nicht einmal sicher, ob mein bisheriger Gesprächspartner überhaupt ansatzweise versteht, was er gerne haben möchte. Derzeit habe ich nur die telefonische "Vorbestellung" für ein CMS. Und keine näheren Details - die gibts, wie gesagt, erst in der ersten Februarwoche.
Außerdem scheint es hie und da auch in den Threadbeiträgen etwas begriffliche Verwirrung zu geben, zu der ich wohl selber auch etwas beigetragen habe. Ein CMS ist halt nicht zwingend dasselbe wie ein online-WYSIWYG-Editor, kann so ein Teil aber enthalten. Wenn es um "Inhaltspflege" der auf einem Server liegenden Dateien und Daten geht, braucht man etwas mehr als bloß schreibenden Zugriff auf mögliche Webseiten. Wenn es darum geht, daß "Nutzer" (das betrifft einen personell eingrenzbaren Bereich von Leuten, die ihre eigenen Inhalte pflegen möchten) schreibenden Zugriff auf ihre eigenen Seiten bekommen, ist es ein bißchen weniger, weil ein solches "CMS" keine Verwaltungsaufgaben erfüllen können muß. Dazu kommt dann natürlich die gesamte "Welt", die sich die auf dem Server liegenden Sachen natürlich im Browser anschauen können soll, aber überhaupt nichts davon zu erfahren hat, daß es Zugänge für Schreibzugriffe gibt.
Wir hatten z.B. ebenfalls mal angedacht, ein CMS zu entwickeln, weil uns nahezu alle verfügbaren CMS nicht zusagten.
Das verstehe ich gut.
Empfehlung an dich also: Redaxo anschauen
Mache ich grade. Sieht tatsächlich überzeugend aus.
die Pläne, ein eigenes CMS zu entwickeln, über Bord schmeißen ;)
Das muß man ja nicht unbedingt. Kann ja im "geheim"-Ordner auf der eigenen Platte verschwinden und als Lieblingskind ein Weilchen gehätschelt werden ;-)
Ich habe diesen Thread aber auch deswegen angestoßen, weil ich vermutete, daß sich mit vergleichbaren Anforderungen oder Plänen auch andere Forumsteilnehmer beschäftigen oder zu beschäftigen haben. Und ich finde, die bisherige Diskussion zeigt, daß das nicht ganz falsch vermutet war.
Grüße aus Berlin
Christoph S.
habe d'ehre Christoph
Wenn es um "Inhaltspflege" der auf einem Server liegenden Dateien und Daten geht, braucht man etwas mehr als bloß schreibenden Zugriff auf mögliche Webseiten.
Was zum Beispiel noch? Klar, eine serverseitige Möglichkeit der Verarbeitung mit einer Sprache Deiner Wahl, aber sonst?
Dazu kommt dann natürlich die gesamte "Welt", die sich die auf dem Server liegenden Sachen natürlich im Browser anschauen können soll, aber überhaupt nichts davon zu erfahren hat, daß es Zugänge für Schreibzugriffe gibt.
Sorry Christoph, was willst Du uns jetzt damit wieder sagen?
Ich will ja nicht wieder das - noch gar nicht solang zurückliegende - Quark-Zitat bringen. Aber egal, ich klinke mich jetzt hier aus, da ich Deinen Verkomplizierungen nicht folgen kann. Das klingt mir irgendwie alles zu verquast.
man liest sich
Wilhelm
Moin, Schuer,
Wir hatten z.B. ebenfalls mal angedacht, ein CMS zu entwickeln, weil uns nahezu alle verfügbaren CMS nicht zusagten. Entweder waren sie nicht flexibel genug (viele kleine CMS), produzierten unsauberes HTML (wie z.B. das eklige Joomla)[...]
zu Joomla möchte ich jetzt auch mal was sagen. Ich beschäftige mich seit ein paar Monaten damit und pflege darüber die Elternratsseite der Gesamtschule, auf die mein Sohn geht, mit (GSH24). Inzwischen habe ich es mir lokal und auf meinem Webspace zum Testen installiert und habe vor, damit diese wunderschöne Seite hier zu relaunchen. Joomla bot sich für mich an, denn die anderen CMSse, die ich kenne und mit denen ich Erfahrung habe, sind kommerziell und teuer. Und andere kenne ich bis jetzt noch nicht, nur vom Hörensagen (z.B. Typo3).
Erstmal zur Installation: der Offene Hamburger Schulserver hat bestimmte PHP-Settings gesetzt, die es mir unmöglich machen, über das Backend Module und Komponenten zu installieren. Eine von Joomla angemeckerte Sicherheitslücke kann ich nicht schliessen. Ich kann auch mit einer php.ini die Serverstandards nich umgehen, auch nicht mit htacssess. Also muss ich die Hostmaster freundlich bitten, mir das Verzeichnis anders zu setzen als global, und ob sie das tun...
Bei 1&1 läuft es nach dem php.ini-Trixen fehlerlos. Es ist schonmal blöd, wenn ein CMS auf der einen Plattform prima läuft, auf der anderen nur nach Klimmzügen und auf der dritten gar nicht. Die Hostmaster vom OHS haben mit Sicherheit Recht wenn sie sagen, dass Joomla "nicht ganz ausgreift" ist ;-)
Zum Handling: Derzeit kämpfe ich mit der Erstellung von Templates. Am besten geht das, wenn man sein Layout in XHTML umsetzt und danach eine php-Datei daraus generiert. Naja, ist halt Fummelkram. Was mich aber am meisten stört, ist die Unübersichtlichkeit im Backend. Als Administrator will man ausserdem ab und an mal ein bißchen HTML codieren, aber wenn der Editor eingeschaltet ist, wird der Code teilweise einfach ignoriert (Formulare können so z.B. nicht erstellt werden, warum auch, dazu gibt es ein Modul, das man sich aber auch erstmal installieren muss, und ob es anschliessend läuft, ist auch noch die Frage).
Lange Rede kurzer Sinn: Inzwischen bin ich auch nicht mehr so ganz überzeugt von Joomla. Als "eklig" würde ich es aber nun auch nicht bezeichnen, immerhin gibt es genug Leute, die es erfolgreich einsetzen. Und für eine Homepage der o.g. Sorte sollte es allemal ausreichen. Schliesslich ist das Engagement, das dort einfließt, ausschließlich ehrenamtlich.
Uns war also enorm wichtig, dass ein Artikel innerhalb des CMS nicht in einem Guss (also in einer Textarea), sondern aus einzelnen Blöcken aufgebaut wird, die individuell auf den Inhalt zugeschnitten werden können. Sowas macht zum Beispiel Typo3, oder aber das wunderprächtige Redaxo,
Deinen Darling werde ich mir jetzt mal ansehen, und Typo3 hatte ich auch schon im Auge. Aber wer schenkt mir die Zeit, mich damit intensiv zu beschäftigen? ;-)
Viele Grüße,
Kirsten
Hallo Kirsten,
Es ist schonmal blöd, wenn ein CMS auf der einen Plattform prima läuft, auf der anderen nur nach Klimmzügen und auf der dritten gar nicht. Die Hostmaster vom OHS haben mit Sicherheit Recht wenn sie sagen, dass Joomla "nicht ganz ausgreift" ist ;-)
Kann sein das Joomla nicht ganz ausgereift ist. Aber die Sicherheitsprobleme die Joomla auf manchen Systemen feststellt, sind Einstellungen wei register_globals etc. Solche PHP-Sicherheitslücken Joomla in die Schuhe zu schieben ist doch ziemlich unfair.
Grüße
Jasmin
Hallo Jasmin,
Kann sein das Joomla nicht ganz ausgereift ist. Aber die Sicherheitsprobleme die Joomla auf manchen Systemen feststellt, sind Einstellungen wei register_globals etc. Solche PHP-Sicherheitslücken Joomla in die Schuhe zu schieben ist doch ziemlich unfair.
register_globals kann nur dann eine Sicherheitslücke sein, wenn das Programm schlampig geschrieben ist.
Schöne Grüße,
Johannes
Hallo Johannes,
register_globals kann nur dann eine Sicherheitslücke sein, wenn das Programm schlampig geschrieben ist.
Sicher. Ich bezweifle auch nicht das es bessere CMS als Joomla gibt, vor allem wegen des unansehlichem HTML. Das Joomla auf Sicherheitslücken hinweist ist doch aber in keinem Falle als Kritikpunkt gegen das CMS aufzufassen. Man kann den Hinweis ja ignorieren so viel ich weiß. Wenn sich Kirsten also ärgert, dass sie gewisse Einstellungen zu treffen hat, dann würde ich mich eher über die PHP-Entwickler ärgern, die solch eine Funktion aus dumpfer Benutzerfreundlichkeit auf Kosten der Sicherheit eingebaut haben.
Grüße
Jasmin
Hallo Jasmin,
Kann sein das Joomla nicht ganz ausgereift ist. Aber die Sicherheitsprobleme die Joomla auf manchen Systemen feststellt, sind Einstellungen wei register_globals etc. Solche PHP-Sicherheitslücken Joomla in die Schuhe zu schieben ist doch ziemlich unfair.
ich habe weder irgend jemandem was "in die Schuhe geschoben" noch habe ich mich in irgend einer Weise "unfair" geäussert. Ich habe die Lage beschrieben wie sie sich aus meiner Sicht und nach meinen Erfahrungen darstellt.
Ich verstehe zuwenig von PHP um beurteilen zu können, wo welche Sicherheitslücken sich auftun und ob die Serverkonfiguration oder die Joomlaprogrammierung diese verursachen.
Soviel habe ich gelernt: register_globals und safe_mode müssen off gesetzt sein (Vorgabe der Sicherheitsempfehlungen von Joomla). Bei dem einen Provider ist das so, bei dem anderen nicht. Man kann etwas tun, um diese Einstellungen zu umgehen, indem man sie in der php.ini bzw. .htaccess setzt. Aber das klappt eben nicht immer. Und man muss sich schon recht gut (aus meiner Sicht jedenfalls, die Junkies hier mögen das milde belächeln) in PHP und Serverkonfiguration zurechtfinden, um fruchtbare Settings setzen zu können. Und das tue ich eben nicht wirklich. Bzw. kann ich auch gar nicht, weil ich abhängig bin von den Providern, ich bin eben nicht meine eigene Herrin diesbezüglich (ausser auf meinem localhost). Muss ich das sein? Ich finde nicht. Natürlich wird man nicht dümmer, wenn man gezwungen ist, sich in das eine oder andere fachliche Thema einzuarbeiten, aber ich habe allmählich den Verdacht, dass sich Joomla als ein kleines aber feines Fass ohne Boden entpuppt.
Viele Grüße,
Kirsten
hallo Kirsten,
Soviel habe ich gelernt: register_globals und safe_mode müssen off gesetzt sein (Vorgabe der Sicherheitsempfehlungen von Joomla). Bei dem einen Provider ist das so, bei dem anderen nicht. Man kann etwas tun, um diese Einstellungen zu umgehen, indem man sie in der php.ini bzw. .htaccess setzt.
Der Ansatz ist prinzipiell korrekt. Nur hast du normalerweise auf php.ini keinen Zugriff.
Aber das klappt eben nicht immer.
Hast du ein Beispiel, wo es nicht klappt?
die Junkies hier mögen das milde belächeln
Vermutlich bin ich kein "Junkie", allerdings hast du eine interessante Sache angesprochen. Das Problem mit "register_globals" hat nämlich sehr häufig auch damit zu tun, welche PHP-Version der Provider zur Verfügung stellt.
ich habe allmählich den Verdacht, dass sich Joomla als ein kleines aber feines Fass ohne Boden entpuppt.
Womit du nicht ganz allein stehst.
Grüße aus Berlin
Christoph S.
Hallo Christoph,
Der Ansatz ist prinzipiell korrekt. Nur hast du normalerweise auf php.ini keinen Zugriff.
Habe ich auch nicht. Ich darf vielleicht eine eigene erstellen und hochladen. In einem Fall ging das und wurde mir sogar von den Hostmastern so vorgeschlagen, das war bei 1&1. Es klappte.
Aber das klappt eben nicht immer.
Hast du ein Beispiel, wo es nicht klappt?
Jo, hier: die zu relaunchende Wesite. Die liegt auf dem Offenen Hamburger Schulserver. Die phpinfo() kannst du hier sehen (nicht verrückt machen lassen von den Farben, ich habe dem Trieb eines Spielkalbs nachgegeben;-))
Vermutlich bin ich kein "Junkie", allerdings hast du eine interessante Sache angesprochen. Das Problem mit "register_globals" hat nämlich sehr häufig auch damit zu tun, welche PHP-Version der Provider zur Verfügung stellt.
4.4.4.
Allerdings habe ich auf php.net gelesen, dass diese Settings ab PHP 6.0 (also php_global usw.) hinfällig werden :-)
ich habe allmählich den Verdacht, dass sich Joomla als ein kleines aber feines Fass ohne Boden entpuppt.
Womit du nicht ganz allein stehst.
Gottseidank :-)
Viele Grüße aus Hamburg,
Kirsten
ps: Kann ich nicht super anklickbare Links setzen? :-)=)
hallo Kirsten,
Der Ansatz ist prinzipiell korrekt. Nur hast du normalerweise auf php.ini keinen Zugriff.
Habe ich auch nicht. Ich darf vielleicht eine eigene erstellen und hochladen. In einem Fall ging das und wurde mir sogar von den Hostmastern so vorgeschlagen, das war bei 1&1. Es klappte.
Da wärs ja aus pädagogischen Gründen für eventuelle "stille Mitleser" (und fürs Archiv und dessen Suchfunktion) wichtig, genauer auszusagen, wie. Ich hab ja erst gestern in einem anderen Thread darauf aufmerksam gemacht, daß "PHPINIDir" in .htaccess erlaubt ist (allerdings ist mir da ein winziger Tipfehler unterlaufen).
Das Problem mit "register_globals" hat nämlich sehr häufig auch damit zu tun, welche PHP-Version der Provider zur Verfügung stellt.
4.4.4.
Na bitte, da hast du es doch. Das gesamte "Verständnisproblem" mit register_globals hat eigentlich erst mit PHP5 begonnen.
Allerdings habe ich auf php.net gelesen, dass diese Settings ab PHP 6.0 (also php_global usw.) hinfällig werden :-)
Jaein. "register_globals" kann unter bestimmten Bedingungen immer noch eine sinnvolle Einstellung sein - das heißt, den Wert dafür auf "on" zu stellen, macht in Intranetanwendungen nach wie vor gelegentlich Sinn. Man sollte nur genau prüfen, wann das Sinn macht. Im WWW ist es eine Entscheidung des Providers, die von dessen Einschätzung der möglichen Gefährdungsmomente abhängig ist. Ich habe mich, wie vermutlich im Forumsarchiv nachzulesen ist, längere Zeit mit dieser Einsicht auch ziemlich schwer getan.
Im übrigen hindert dich nichts daran, PHP6 in einer tagesaktuellen Entwicklerversion zu testen. Ich finds gut ...
ich habe allmählich den Verdacht, dass sich Joomla als ein kleines aber feines Fass ohne Boden entpuppt.
Womit du nicht ganz allein stehst.
Gottseidank :-)
Och ... ich mag zwar selbstberufener Alterspräsident des Forums sein, aber der liebe Gott liest vermutlich hier nicht immer mit *g*
Grüße aus Berlin
Christoph S.
Moin, Chrisoph,
Da wärs ja aus pädagogischen Gründen für eventuelle "stille Mitleser" (und fürs Archiv und dessen Suchfunktion) wichtig, genauer auszusagen, wie. Ich hab ja erst gestern in einem anderen Thread darauf aufmerksam gemacht, daß "PHPINIDir" in .htaccess erlaubt ist (allerdings ist mir da ein winziger Tipfehler unterlaufen).
Also, für alle 1&1-Kunden, die php Einstellungen bei 1&1 setzen wollen, das geht so:
"die Anpassung von PHP-Einstellungen können Sie selbst vornehmen. Legen
Sie hierzu eine Datei php.ini in dem Verzeichnis an, in dem sich das
PHP-Skript befindet, für das die geänderten Einstellungen gelten sollen..
Bitte beachten Sie, dass die Einstellungen nicht automatisch auch für
Unterverzeichnisse gelten, bitte legen Sie daher ggf. entsprechende
Kopien der php.ini an.
Die php.ini besteht aus beliebig vielen Einträgen der Form "variable =
wert" in jeweils einer Zeile. Eine einfache php.ini könnte bespielsweise
so aussehen:
register_globals = off
upload_max_filesize = 50M
allow_url_fopen = off
Durch das Anlegen einer eigenen php.ini werden einige
Standardeinstellungen unseres Servers ignoriert. Wenn Sie sichergehen
möchten, dass sich Ihre PHP-Konfiguration nur in dem Punkt
unterscheidet, den Sie ändern möchten, fügen Sie Ihrer php.ini bitte
folgende Einträge hinzu:
memory_limit = 40M
upload_max_filesize = 20M
max_execution_time = 50000
browscap = /usr/local/lib/browscap.ini
register_globals = on
error_reporting = (E_ALL & ~E_NOTICE & ~E_WARNING)
url_rewriter.tags =
"a=href,area=href,frame=src,form=fakeentry,fieldset="
Die aktuell gültigen Einstellungen können Sie überprüfen, indem Sie in
Ihr PHP-Skript den Befehl "phpinfo();" einfügen. Eine selbst angelegte
php.ini ist automatisch für PHP3, PHP4 und PHP5 gültig."
4.4.4.
Na bitte, da hast du es doch. Das gesamte "Verständnisproblem" mit register_globals hat eigentlich erst mit PHP5 begonnen.
Nagut, aber wie zwinge ich den Provider nun, PHP 6.0 zu installieren? Vorgehaltene Knarre?
Im übrigen hindert dich nichts daran, PHP6 in einer tagesaktuellen Entwicklerversion zu testen. Ich finds gut ...
Ich will es doch gar nicht testen, das soll doch der Provider tun, ich will doch nur, dass meine Anwendungen laufen, Mist aber auch...
Och ... ich mag zwar selbstberufener Alterspräsident des Forums sein, aber der liebe Gott liest vermutlich hier nicht immer mit *g*
Hast Du eine Ahnung :-)
Viele Grüße,
Kirsten
hallo Kirsten,
aber wie zwinge ich den Provider nun, PHP 6.0 zu installieren? Vorgehaltene Knarre?
Das ist immerhin ein Verhandlungsansatz. Ihr solltet euch irgendwo in der Mitte treffen, so daß dein Provider dir PHP 5.2 einrichtet und du ihm danach erklären kannst, daß deine Knarre eh nur mit Gummibärchen geladen war.
Im übrigen: dein Zitat aus irgendwelchen 1&1-Quellen liest sich zwar gut, aber dann weiß man nur, wie "die bei 1&1" das handhaben. Immerhin erfährt man, "daß es geht", aber nicht, "wie die das gemacht haben". Grob umrissen und vermutlich nicht für alle Provider gültig sieht es so aus, daß man in der httpd.conf mit einer Variablen festlegen kann, daß eine in einem beliebigen Verzeichnis liegende php.ini die zentralen Vorgaben der auf dem Server vorhandenen php.ini überschreiben darf. Dafür git es die Direktive "PHPINIDir", die übrigens konsequenterweise in der Apache-Dokumentation nicht aufgeführt ist (hihi, wenn ich will, kann ich offenbar auch ganz schnucklige Links formatieren).
Grüße aus Berlin
Christoph S.
Hallo Christoph,
aber wie zwinge ich den Provider nun, PHP 6.0 zu installieren? Vorgehaltene Knarre?
Das ist immerhin ein Verhandlungsansatz. Ihr solltet euch irgendwo in der Mitte treffen, so daß dein Provider dir PHP 5.2 einrichtet und du ihm danach erklären kannst, daß deine Knarre eh nur mit Gummibärchen geladen war.
PHP 6 ist sowieso noch nicht für den Produktiveinsatz vorgesehen. Wenn Kirstens Provider 5.2.0 installiert hat, hat er damit schon die aktuellste stabile Version.
Dafür git es die Direktive "PHPINIDir", die übrigens konsequenterweise in der Apache-Dokumentation nicht aufgeführt ist (hihi, wenn ich will, kann ich offenbar auch ganz schnucklige Links formatieren).
Was soll die auch in der Apache-Dokumentation verloren haben? Siehe http://www.php.net/configuration.
Schöne Grüße,
Johannes
Moin,
Das ist immerhin ein Verhandlungsansatz. Ihr solltet euch irgendwo in der Mitte treffen, so daß dein Provider dir PHP 5.2 einrichtet und du ihm danach erklären kannst, daß deine Knarre eh nur mit Gummibärchen geladen war.
Ganz falsch, Mon Chéri :-)
PHP 6 ist sowieso noch nicht für den Produktiveinsatz vorgesehen. Wenn Kirstens Provider 5.2.0 installiert hat, hat er damit schon die aktuellste stabile Version.
Aber du hast gesehen, welche installiert ist? 4.4.4? Und ob ich darauf Einfluss habe, wird sich erst nach der Schachtel Mon Chéri zeigen :-)
Dafür git es die Direktive "PHPINIDir", die übrigens konsequenterweise in der Apache-Dokumentation nicht aufgeführt ist (hihi, wenn ich will, kann ich offenbar auch ganz schnucklige Links formatieren).
Wieso, es geht doch gar nicht darum, ob du es kannst, sondern darum, ob andere es können und ob sie deinem gnädigen Urteil standhalten was das Linksetzen angeht, jedenfalls habe ich da sowas gelesen...? ;-)
Was soll die auch in der Apache-Dokumentation verloren haben? Siehe http://www.php.net/configuration.
Ich kann doch als ganz stinknormaler Webspacemieter die Konfigurationsdateien nicht beeinflussen...
Aber wir sind alle in der glücklichen Lage, Linkformatierungen im Selfraum selbst beeinfussen zu können :-)
Viele Grüße,
KIrsten
Hallo Kirsten,
redest du mit Christoph oder mit mir? ;-)
Schöne Grüße,
Johannes
Hallo Christoph,
Na bitte, da hast du es doch. Das gesamte "Verständnisproblem" mit register_globals hat eigentlich erst mit PHP5 begonnen.
Nein, PHP 5 hat in dem Punkt nichts geändert.
»Perhaps the most controversial change in PHP is when the default value for the PHP directive register_globals went from ON to OFF in PHP 4.2.0« (Quelle).
Allerdings habe ich auf php.net gelesen, dass diese Settings ab PHP 6.0 (also php_global usw.) hinfällig werden :-)
Jaein.
Doch, die Einstellung wird unter PHP 6 nicht mehr zur Verfügung stehen: http://www.php.net/~derick/meeting-notes.html#register-globals und http://cvs.php.net/viewvc.cgi/php-src/NEWS?revision=HEAD.
"register_globals" kann unter bestimmten Bedingungen immer noch eine sinnvolle Einstellung sein - das heißt, den Wert dafür auf "on" zu stellen, macht in Intranetanwendungen nach wie vor gelegentlich Sinn.
Ja, wen man PHP3-Scripte laufen lassen möchte z.B. Ansonsten ist es lediglich schlampiger Programmierstil, wenn diese Funktion von einem Script benötigt wird.
Schöne Grüße,
Johannes
Hallo
Das Problem mit "register_globals" hat nämlich sehr häufig auch damit zu tun, welche PHP-Version der Provider zur Verfügung stellt.
4.4.4.
»»
Na bitte, da hast du es doch. Das gesamte "Verständnisproblem" mit register_globals hat eigentlich erst mit PHP5 begonnen.
Begonnen hat es schon mit Version 4.2. Seit dem wird PHP standardmäßig mit register_globals:off ausgeliefert und von einigen wenigen Hostern auch so betrieben[1]. Dies führte damals auch in diesem Forum zu irritierten Nachfragen wegen nicht mehr funktionierender Skripte (das PHP-Pendant zur 2-Frames-mit-einem-Klick-ändern-Frage).
[1] ... auch wenn die meisten Hoster wieder auf "on" umschalteten, um den Nachfragen genervter Kunden zu entgehen.
Tschö, Auge
--
Die Musik drückt aus, was nicht gesagt werden kann und worüber es unmöglich ist zu schweigen.
(Victor Hugo)
Lange Rede kurzer Sinn: Inzwischen bin ich auch nicht mehr so ganz überzeugt von Joomla. Als "eklig" würde ich es aber nun auch nicht bezeichnen, immerhin gibt es genug Leute, die es erfolgreich einsetzen.
"Eklig" war übertrieben. Ich mag Joomla einfach nicht besonders, es wird an zu vielen Stellen gepfuscht (Module) und liefert nicht die Qualität, die ich von einer Website (im Frontend und im Backend) erwarte.
Das ist natürlich eine Dienstleistersicht. Für private Websites oder jede Art von Tue-ein-gutes-Werk ist Joomla vollkommen in Ordnung. Und wenn es allein darum geht, mit vorhandenen Mitteln Inhalte ins Netz zu bringen, dann wäre mir sogar eine Frontpage-, myspace oder Beepworld-Seite recht. Der heimische Gesangsverein und die KITA stehen also besser mit geringen Mitteln im Netz als gar nicht im Netz.
Viele Grüße!
_ds
