Diskussion:Kommunikation
Kategorie?
Ergebnisse zu CMS
"Ein Meinungsbild ergab, dass 20 von 22 Teilnehmern dafür sind vorerst auf ein CMS zu verzichten und mit statischen Seiten zu arbeiten, da hier eine schnellere Bearbeitung möglich ist." - das ist afaik so nicht richtig; im Gegenteil wurde am Nachmittag auf der Fortsetzung des Moduls Kommunikation ein CMS für unabdingbar und baldmöglich notwendig erachtet. --Nanuk 22:20, 10. Jan 2007 (UTC)
- Dieses Meinungsbild gab es tatsächlich. Ich war die einzige Enthaltungen. Es ging dabei aber nicht darum ein wenig veränderbares System zu schaffen, sondern vorerst wegen schlechter Erfahrung auf ein CMS für die ersten Seiten zu verzichten und statt dessen von Hand zuzugreifen. Die Zahl dieser statischen Seiten sollte klein sein und intensiv auf Forum, Wiki und CMS (ich wünsche mir auch Blog) verlinken und auf diese Weise Inhalt in tieferen Ebenen schaffen. (Ein standartisierter Zugriff auf HTML/PHP-Dateien per SFTP / SSH ist auch ein CMS). Außerdem war dieser Beschluss meines Erachtens vor dem Hintergrund des Übergangscharakters gefällt worden. --Jan Huwald 09:20, 11. Jan 2007 (UTC)
Liquid Feedback
Liquid Feedback fehlt in der Tabelle der online-Kommunikationskanäle. Warum darf lqfb dort fehlen?? Siehe Diskussionsseite zu "Portale" --Blausand 02:42, 20. Okt. 2011 (CEST)
Wiki vs. Website
"Das Wiki kann nicht als Informationsmedium für Besucher dienen. Es soll keine Konkurrenz zur Website sein."
Hier sehe ich Diskussionsbedarf. http://www.wijvertrouwenstemcomputersniet.nl/ ist auch ein Mediawiki. Die Kampagne hat von Anfang an auf dieses gesetzt und war meines Erachtens nach sehr erfolgreich. Der große Vorteil beim Wiki liegt darin, daß es im Gegensatz zum Typo3 viel einfacher ist, hier Artikel (kollektiv) zu erstellen und diese dann bei ausreichender Reife in die offizielle Seite einzufügen. Gegen womöglich zu befürchtenden Vandalismus der Parteiseite lassen sich Artikel sperren, so dass nur Administratoren diese verändern können. Dadurch ist auch eine entsprechende Verbindlichkeit gegeben. Insbesondere sind sämtliche Änderungen transparent in der Historie nachzuvollziehen. --Jamasi 02:16, 5. Jan 2007 (UTC)
Sicherheit
Dazu würde mich eine aufstellung interessieren wie häufig im Mediawiki, in gängigen CMS und zusätzlich in den Webservern darunter sicherheitslücken entstehen/veröffentliucht werden. ich denke nämlich je mehr scripte etwas von hause aus mitbringt, desto mehr potentielle angriffspunkte hat es.- Amon 23:15, 5. Jan 2007 (UTC)
- Da die Wikipedia, als wohl bekanntestes Projekt, das ein Mediawiki verwendet wohl auch prominentestes Ziel für Angriffe sein dürfte und mir bisher keine massiven Probleme diesbezüglich bekannt sind, schätze ich die Sicherheit des Mediawiki für eine php-Anwendung als recht hoch ein. Wenn man den Server zusätzlich noch etwas härtet (hardend-php), so sollte die Sicherheit bei Weitem über der des phpbb liegen. P.S.: Typo3 hatte doch erst kürzlich wieder eine Lücke. Ich denke, wenn das Teil bei Wikipedia ordentlich funktioniert, dann fahren wir sicher nicht besonders schlecht damit. Zum eigenen Beurteilen der Gefährdungslage:
- Die Lücken werden übrigens zügig behoben, da Wikipedia die Software ja produktiv rund um die Uhr einsetzt. --Jamasi 00:28, 6. Jan 2007 (UTC)
- Dabei handelt es sich größtenteils um Lücken in Mods für phpBB.--Fennias Maxim 15:58, 9. Jan 2007 (UTC)
Varianten des Wikis als CMS
Mindestens zum Erstellen der Seiten ist das Wiki geeignet (wenn auch nicht from Scratch sondern eher nach Vorgabe eines Nutzers oder eben sehr langsam). Auch als CMS ist das Wiki wegen der hohen Verlinkungsdichte und der einfachen Möglichkeit neue Templates zu erstellen praktikabel für den Endanwender. Für Admins fehlt natürlich jede Menge von Features die CMS überlichwerweise haben. Für ein Wiki-CMS gibt es im wesentlichen 2 Betriebsvarianten:
- Wiki-Software direkt nutzen. Gefällt mir nicht so gut.
- Über ein Script Wiki-Artikel (oder einen Teil der Inhalte, zB einen spez. Namespace (~sicher) oder alles was ein bestimmtes Tag hat (~unsicher)) darstellen.
Ich halte die zweite Variante für besser, da wir so mehr Freiheit für Änderungen an der Website haben, ohne all zu komplexen Wiki-Salat zu produzieren und ohne die MediaWiki-Software zu verändern. Insbesondere brauchen wir an einigen Stellen Skripte, und die ins Wiki zu integrieren ist schwerer als das Wiki in die Skripte. -- Jan Huwald 09:31, 11. Jan 2007 (UTC)
- Hi Jan,
- hi allerseits,
- Für Admins fehlt natürlich jede Menge von Features die CMS überlichwerweise haben, welche wären das denn? Ich ich kenn typo3 ziemlich gut, das hatte auch 1000nde Features mit Workflow und Benutzerfreigaben; praktikabel ist davon ist nix. Und Workflow Überwachung haben wir im Mediawiki sicherlich den besten mit den Recents, Beobachtung und History. (mehr dazu)
- so spielereien wie randombild, styleswitscher oder what fehlen im (Media)wiki, ist aber erst die Frage ob wir sowas brauchen, und wenn ja kann man gern reinentwickeln, aber mir hast an noch nix gefehlt.
- Wiki-Software direkt nutzen. Gefällt mir
nichtsuper gut: mehr dazu - Über ein Script Wiki-Artikel (oder einen Teil der Inhalte, zB einen spez. Namespace (~sicher) oder alles was ein bestimmtes Tag hat (~unsicher)) darstellen. Ok, daran hat ich auch schon mal gedacht (für ein Firmenintranet und "statischer" Website). Ist nur die Frage was es bringt den Inhalt zu exportieren, von www zu www? Die Sicherheit wird nicht größer, wenn ich den Wikiartkel sperre. Das Design kann ich (ab Mediawiki ??) für jeden Namensraum einzeln anpassen.
- Wiki-Software direkt nutzen. Gefällt mir
- greetz klml 17:36, 13. Jan 2007 (UTC)
- PS das verlinkt wikibook ist natürlich nicht neutral, da es von mir is, könnt aber auch da reinschreiben ;)
stabile Versionen
In den Wikimediawikis ist schon länger die einführung von einem stabilen Versionsmanagement in Diskussion. Ich denke, dass könnte uns hier viel bringen, weil wir so an Artikeln arbeiten können und sie erst später als gültig und offiziell deklarieren können. Allerdings sehe ich für die stabilen Versionen in mediawiki noch keine Implementierung. -- Chaotika 13:35, 11. Jan 2007 (UTC)