Andreas Unkelbach
Logo Andreas-Unkelbach.de

Artikel zum Stichwort Dokuwiki

Alle folgende Artikel sind unter den angegeben Stichwort (TAG) einsortiert. Sollte der gesuchte Artikel nicht dabei sein kann hier auch die Artikelsuche weiter helfen.

Oft sind aber auch die aktuellen Artikel in der jeweiligen Kategorie im Menü interessant.
Espresso Tutorial - die digitale SAP Bibliothek

SAP Fachliteratur ist unter Buchempfehlungen inklusive ausführlicher Rezenssionen und Bestellmöglichkeit zu finden.



Samstag, 14. Januar 2017
16:52 Uhr

Webhosterwechsel und Umstellung von http:// auf https:// (SSL Verschlüsselung) und VG Wort Zählmarken

Wie schon im Jahresrückblick erwähnt stand für mich Ende des Jahres nicht nur ein Wechsel  des Mailanbieters an sondern auch ein Umzug mehrere Seiten zu einen neuen Webhoster an. Mein damaliger Webhoster hatte den Geschäftsbereich Webhosting aufgegeben, so dass ich mir ein neues digitales Zuhause gesucht und mittlerweile auch gefunden habe.

Sollte mein Blog per Feed aboniert worden sein ist auch ein neues Abo erforderlich, da ich meine Seite auf https umstellen werde und so zumindest unter Feedly ein erneutes Abo unter https://www.andreas-unkelbach.de/blog/rss.xml erforderlich ist. Andere RSS-Feedleser scheinen mit einer Umleitung des RSS-Feed wesentlich besser klar zu kommen.

Auswahl Webhoster

Sehr hilfreich war hier die Gegenüberstellung einzelner Webhosting-Pakete im c't magazin auch wenn mittlerweile Strato mit 1&1 zusammengelegt wurde und Hosteurope (wo mein ehemaliger Webhoster Reseller war) nun zu GoDaddy gehört. Mein PLUS Abo des c't magazin zahlt sich aber gerade bei solchen Themen als extrem positiv auf, da ich hier einen Zugriff auf eines der letzten Hefte habe und der Artikel auf http://heise.de/-3318728 eine sehr gute Grundlage bietet um sich für ein Angebot zu entscheiden.

Gelandet bin ich hier mittlerweile bei "ALL-INKL.COM - Neue Medien Münnich" * und bin derzeit auch vom Umzug und den Angebot recht angetan.

Gründe für all-inkl waren, dass ich hier viel Gutes vom Hoster gehört habe und auch vom Angebot her mich die angebotene Technik aber auch die Möglichkeit eines Testaccount sehr angesprochen hat. Für mich war ein wichtiger Punkt, dass sowohl Mailverteiler als auch einige andere Techniken vom Server funktionieren und ich mich hier weniger um die Technik kümmern muss (im Sinne von Serverwartung). Neben PHP und MySQL waren hier also insbesondere auch die Einstellungsmöglichkeiten zur Mail wichtig sowie die Domainverwaltung. Besonders wichtig waren mir hier auch große Postfächer auch wenn ich mittlerweile durch Posteo (wozu ich bei Gelegenheit einmal mehr zu schreibe) eine echte Alternative gefunden habe.

 
Werbung
ALL-INKL.COM - Webhosting Server Hosting Domain Provider


Sofern man sich auch etwas intensiver mit Serverkonfiguration und der Basistechnik rund um Webhosting kümmern macht aber auch Uberspace.de einen spannenden Eindruck.

Datenschutz durch HTTPS / SSL und anonymisierte Logfiles

Im folgenden Artikel möchte ich einige Punkte an sprechen, die an Aufgaben beim Umzug meiner Seiten erforderlich waren und da ich gleichzeitig auch technisch das ein oder andere auf meiner Seite geändert habe auch auf allgemeine Themen im Zusammenhang mit PHP 7 sowie Wechsel von http:// auf https:// (SSL Verschlüsselung) meiner Seite eingehen. Dieses ist ab PrivatPlus ebenfalls kostenlos bei all-inkl möglich.

Warum eine SSL Verschlüsselung auch für "normale" Internetseiten sinnvoll ist dürfte die Verbreitung von WLAN bspw. im Hotel oder auch an anderen Stellen belegen. Gesetzlich wird diese, zumindest  bei Kontaktformularen, auf Basis von § 13 Absatz 7 Telemediengesetz als sicher anerkanntes Verschlüsselungsverfahrens anzubieten gefordert. Im Artikel "Sicher ist sicher: Warum HTTPS für deine Website sinnvoll ist" auf drweb.de werden hier auch einige weitere Gründe mit aufgeführt.

Juristische Aspekte der SSL Verschlüsselung

Die jurisitschen Aspekte sind von Rechtsanwalt Dr. Thomas Schwenke im Artikel "Gastbeitrag: Warum Sie Ihre Website auf https umstellen sollten" auf der Seite der Kanzlei Plutte beschrieben worden. An dieser Stelle mag ich auch sehr gerne auf die von mir gerne gehörten Jura-Podcast (siehe Videoblogs und Podcast ) hinweisen.

Weiter unten bin ich im Abschnitt "Umstellung http:// auf https:// (SSL Verschlüsselung)" auch auf das Thema Warnmeldung wegen mangelnde Zertifikatsprüfung  im Browser eingegangen, was aber eher ein technischer Aspekt im Zusammenhang mit erfolgreichen Wechsel auf SSL bzw. HTTPS eingegangen. Immerhin ist dieses durch HTML relativ leicht zu verhindern :-).
 

Datenschutz und Serverlogfiles

Grundsätzlich bietet diese Verschlüsselung auch einen Gewinn im Bereich Datenschutz, so dass ich dieses mit der Möglichkeit der Anonymisierung oder gar Deaktivierung von Serverlogfiles als einen datenschutzrechtlichen Fortschritt beim neuen Anbieter ansehe. Das Thema Datenschutz ist auch ein Grund, warum ich die nun gewonnene Möglichkeit der Anonymisierung von Serverlogfiles nutze und diese auch in meiner Datenschutzerklärung unter den Punkt Serverlogfiles zusammenfasse.

Die angesprochenen Themen sind dabei allerdings unabhängig vom Anbieter und so hoffe ich, dass dieser Artikel auch für andere interessant sein dürfte.

Umzug der Domain - administrativ

Früher, das ist nun auch schon über zehnJahre her,  war für den Umzug einer Domain tatsächlich ein Brief (oder Fax) erforderlich und es wurde ein unterschriebener KK-Antrag zum Wechsel eines Providers für  eine Domain den neuen Hoster zugesandt und es wurde danach die Domain übertragen. Seit 2008 hat sich hier aber das Verfahren erheblich geändert und es wird vom bisherigen Provider ein AUTH-Code  beantragt und mit diesen wird (ohne Unterschrift) dann die Freigabe und Übertragung der Domain angestoßen.  Dieses funktioniert auch wunderbar bei .DE Domains die bei der Denic registriert sind.

Bei internationalen Domains  (.com, .net, .org, .info, .biz, .name) ist darüber hinaus aber auch eine Bestätigung durch den Domaininhaber erforderlich ist. Hierzu wird eine Mail an den eingetragenen Domaineigentümer  (ADMIN-C Kontakt) gesandt in der ein Bestätigungslink für die Zustimmung oder Ablehung des Transfer gegeben werden kann. Entsprechend wichtig ist es, dass die Mailanschrift bei den WHOIS Daten der Domain aktuell sind (daher bekommt man auch einmal jährlich eine Erinnerung an die hinterlegte Mailanschrift). Sollte die Mail nicht mehr nutzbar sein, kann aber auch immer noch ein Fax genutzt werden.

Sobald der FOA-Service ("Form of Authorisation") abgeschlossen ist wird die Domain nach 14 Tagen übertragen und die Domain dann auf den neuen Server übertragen. Später erfolgt auch noch ein weiteres Bestätigungsverfahren, sollten sich im Rahmen des Umzugs auch Kontaktdaten des ADMIN-C geändert haben. Dieses dann aber über eine Mail zur Domain-Validation, die auch sonst einmal im Jahr zwecks Kontrolle der hinterlegten Daten mich anschrieb.

Umzug der Domain - technisch

Das letzte Mal, dass ich mich intensiver mit der Technik rund ums Blog und dieser Seite auseinander gesetzt habe war im Artikel "In eigener Sache: Updates der Seite (Technik und Design) - Fokus auf Responsives Webdesign und pagespeed" vor fast vier Jahren.

Entsprechend positiv empfand ich, dass ich erst einmal nur das Webhostingpaket ohne Domains bestellen konnte und meine Seiten erst einmal ohne übertragene Domains anlegen konnte.

Allinkl bietet neben einer Vertragsverwaltung (Members Area) in der Domains tatsächlich bestellt werden können und die Vertragsdaten verwaltet werden auch Kundenadministrationssystem  (KAS) unter den eine technische Administration des Accounts vorgenommen werden kann.

Hierdurch ist es möglich  erst einmal alle Daten  zu übertragen und erst zum Schluss Ihre die Domains tatsächlich umziehen zu lassen. Dieses ist besonders dadurch interessant, dass so auch schon IMAP Konten eingerichtet werden können und in der Webmailoberfläche auch von bestehenden Mailkonten sowohl Mails als auch Ordner mit importiert werden können.

Statt einer Domain kann über eine Übergangsdomain  (URL) die eigene Seite aufgerufen werden. Hierbei sind die einzelnen Domains Unterordner des Webspace zugeordnet und die Seite kann über eine Subdomain aufgerufen werden auch wenn die Domain aus irgendwelchen Gründen noch nicht normal erreichbar ist.

Wechsel PHP 5.5  auf PHP 7

Im Rahmen des Serverumzugs habe ich mich auch mit einen Wechsel von PHP 5.5 auf PHP 7 beschäftigen dürfen und doch das ein oder andere Projekt anpassen müssen. Aber zumindest das Blog und auch einige andere Seiten von mir waren dafür schon sehr gut dank schattenbaum.net auf einen Umzug vorbereitet.
 

PHP Code Anpassungen bspw. bei Fehlermeldung von DokuWiki

Gerade wenn auch gleichzeitig ein Wechsel der PHP Version anstand ist dieses sehr praktisch, da erst einmal der Code hier angepasst werden kann und auch beim von mir eingesetzten WikiSystem Dokuwiki konnte ich bei der Fehlermeldung "Declaration of action_plugin_wikicalendar::register(&$controller) should be compatible with DokuWiki_Action_Plugin::register(Doku_Event_Handler $controller) in" feststellen, dass einige Plugins nicht mit der neuesten PHP Version kompatibel sind. Insgesamt verlief besonders der Umzug von Dokuwiki wesentlich einfacher als das 2013 (da allerdings nur von einen auf den anderen Server beim gleichen Webhoster siehe Artikel "Was ist zu beachten beim Serverumzug?".
 

Unterstützung durch PHP für dich :-)

Glücklicherweise habe ich die Autorin von "PHP für dich" geheiratet und so war mit ihrer Hilfe auch der PHP Code und das von ihr entwickelte Blogsystem schnell auf die aktuellste PHP Version angepasst.

Einige wichtige Punkte sind auch auf ihrer Seite unter anderen auch auf erläutert worden aber auch sonst war das ein oder andere Anpassen erforderlich.

Nun aber zum Thema des Zertifikat und Verschlüsselung von Internetseiten.

Umstellung http:// auf https:// (SSL Verschlüsselung)

Der Wechsel des Webhoster ist auch gleichzeitig mit einer Aktivierung der SSL Verschlüsselung für Internetseiten an. Dabei kann hier die Datenübertragung per SSL verschlüsselt werden und so ein Mehr an Sicherheit angeboten werden.

Hier kann im KAS unter Domains beim Eintrag in der Domain unter den Punkt SSL-Schutz ein kostenloses Zertifikat von "Let's Encrypt" beantragt werden (siehe Abbildung).

SSL Zertifikat beantragen

Hier kümmert sich dann künftig ALL-INKL um die Verlängerung des Zertifkates.Bei dieser Form des Zertifikates handelt es sich um eine Domain-Validierung (Domain Validation), womit sichergestellt wird, dass die Kommunikation auch tatsächlich über andreas-unkelbach.de verschlüsselt läuft. Daneben gibt es auch noch  Organisation-Validierung (Organisation Validation) wodurch zusäztlich noch Inhaberdaten (personenbezogen) mit angegeben werden.

Zum Hintergrund der Zertifikat von "Let's Encrypt" kann auch der Artikel "https:// für alles! Die Initiative Let’s Encrypt revolutioniert mit kostenlosen SSL-Zertifikaten das Web" des CT-Magazin weiterhelfen.


Dieses bietet sich  für Organisationen an und ist besonders bei Banken oder Onlineshops im Einsatz.

Der Vorteil von SSL verschlüsselten Internetseiten ist, dass die Daten hier geschützt zwischen Browser und Webserver übertragen werden.

Die gesicherte Verbindung ist auch in der Adressleiste durch die URL https://www.andreas-unkelbach.de wie in folgenden Bild zu sehen ersichtlich.

HTTPS mit SSL okay

Hier sind tatsächlich alle Elemente der Seite verschlüsselt übertragen und die Verbindung gilt als sicher.

Problematisch ist es, sofern Teile der Seite noch per http:// eingebunden sind, was sowohl durch externe Skripte oder auch durch Bilder der Fall sein kann, die hier mit ihrer absoluten URL eingebunden werden.

Hier gibt die Adressleiste eines Browser eine entsprechende Warnmeldung aus, wie ebenfalls in der folgenden Abbildung zu sehen ist.

HTTPS SSL mit Warnmeldung

Hier sind gemischte (also verschlüsselte und unverschlüsselte Inhalte) auf einer Seite eingebunden worden. Je nach Browser können diese dann auch blockiert und damit nicht angezeigt werden.

Setzen von protokoll-relativen Pfaden in Blogartikeln per SQL oder Suchen und Ersetzen


Für eigene Bilder oder interne Links bietet sich hier eine relative Verlinkung an. Hier werden einzelne Artikel oder Bilder mit relativen Pfaden bspw. /andreas.php verlinkt statt mit der vollständigen URL https://www.andreas-unkelbach.de/andreas.php .Besonders bei eingebundenen Bildern bietet sich jedoch eine protokoll-relative Verlinkung an. Hierbei werden statt http:// oder https:// nur // zur Verlinkung angegeben.

Diese Vorgehensweise ist auch im SELFHTML Wiki im Abschnitt "Mit protokoll-relativen URIs referenzieren" beschrieben und es war relativ einfach möglich die entsprechenden URL in der Datenbank meines Blogs durch Suchen und Ersetzen anzupassen. Dieses war natürlich durch den Umzug besonders einfach, da ich hier einfach die Exportdatei der Datenbank anpassen konnte und nicht das passende SQL Statement verwenden musste.

Wobei auch per

UPDATE tabelle_blogartikel SET spalte_artikeltext = REPLACE(spalte_artikeltext ,"http://www.andreas-unkelbach.de","//");

eine entsprechende Anpassung möglich gewesen wäre... allerdings ist es mir nie ganz geheuer direkt in der Datenbankverwaltung  (siehe PHP für dich - Tabellen anlegen mit phpMyAdmin) zu arbeiten.
 

Einbindung VG Wort Zählmarken einer SSL verschlüsselten Webseite (https)


Ein weiteres Problem kann noch die Einbindung von VG Wort Zählmarken (siehe Impressum) sein. Hier hat Daniel Weihmann im Blogartikel "VG Wort unter SSL/ HTTPS nutzen" darauf hingweisen, dass die Zählmarken  per http eingebunden werden und es einer speziellen Subdomain benötigt um hier entsprechende sichere Verbindungen aufzubauen und auch die Zählpixel ordentlich einzubinden. Nun stellte sich für mich die Frage, ob auch die einzelnen URL zur jeweiligen Zählmarke aktualisiert werden muss und ob sowohl die HTTP als auch die HTTPS Variante angegeben werden muss.

Auf Rückfrage an die Verwertungsgesellschaft Wort habe ich dazu ebenfalls folgende Antwort erhalten:


Sehr geehrter Herr Unkelbach,
für eine Verwendung in einer SSL verschlüsselten Webseite, muss die Zähldomäne in der Zählmarke in der Tat durch https://ssl-vg03.met.vgwort.de/ ersetzt werden. Der Rest des IMG Tags bleibt identisch zur bisher verwendeten Fassung.

Bitte beachten Sie, dass hier NUR die vg03 Domäne verwendet werden kann, wie angegeben. Nur dort können die Zugriffe auf eine ssl - verschlüsselte Seite korrekt gezählt werden.

Nachlesen können Sie das auch unter https://tom.vgwort.de/Documents/pdfs/dokumentation/metis/DOC_Urhebermeldung.pdf im Kapitel 8.2.4

Und nein, ich kann bei der Korrektur von Meldungen damit umgehen, wenn sich nur das Zertifikat ändert, der Rest der URL aber weiterhin der gleich ist. Einen neuen Webbereich müssen Sie nur melden,wenn sich die URL als ganzes ändert.

Hier hätte auch ein Blick in die Dokumentation ausgereicht in der konkret steht, dass die Angabe einer URL nur dazu dient, die spätere Meldung zu erleichtern.“ die eigentliche Meldung ist von der Angabe der URL unabhängig.

Somit spricht eigentlich nichts mehr gegen eine Verwendung von SSL bzw. der https:// Variante meiner Internetseite auch weil so aus Datenschutzgründen nicht mehr die übertragenen Daten mit ausgelesen werden können.

Dieses ist auch der Grund warum Google (aber auch andere Suchmaschinen) dazu übergehen mehr und mehr Seiten mit der https Variante zu indizieren.

Hierzu sind im Google Webmasterblog die Artikel " Standardmäßig HTTPS-Seiten indexieren " und "  HTTPS als Ranking-Signal " oder auch die Hilfeseite " Website mit HTTPS sichern " lesenswert.

Künftig soll auch der Browser Chrome (ebenfalls von Google) darauf hinweisen, dass eine Seite nicht mit SSL verschlüsselt ist (durch ein rotes X in der Adressleiste).

Bevorzugte Domain / Internetadresse in .htaccess festlegen

Nachdem ich meine Seite nun erfolgreich umgezogen habe biete ich bis zum 16. Januar sowohl eine http:// als auch eine https:// Variante meiner Seite an. Da ich aber ungern doppelt Inhalte ins Netz stelle werde ich dauerhaft meine Seite auf die Variante https://www.andreas-unkelbach.de umleiten. Leider scheint mit dieser Variante feedly etwas Probleme zu haben, daher oben auch der Hinweis dazu.

Hierzu wird eine Weiterleitung per 301 Moved Permanently empfohlen. Da ich selbst immer wieder zur Konfiguration solcher Weiterleitungen in die Hilfe schauen muss, kann ich hier tatsächlich die Seite www.htaccessredirect.de empfehlen in der die meisten Anwendungsfälle vorgestellt sind.

.HTACCESS Redirect und Rewrite Generator

Für umfangreichere Einstellungen isd er Konfigurationsdatei kann auch der online nutzbare "Simple Htaccess Redirects & Rewrite Generator" von Aleyda Solís hilfreich sein.


Sofern keine Weiterleitung eingestellt ist kann zum Beispiel dieser Artikel direkt über vier URL aufgerufen werden:
  1. http://andreas-unkelbach.de/blog/?go=show&id=790
  2. https://andreas-unkelbach.de/blog/?go=show&id=790
  3. http://www.andreas-unkelbach.de/blog/?go=show&id=790
  4. https://www.andreas-unkelbach.de/blog/?go=show&id=790
Auf der Seite seorch.de kann neben anderer SEO Website Check und OnPage SEO Tools auch dieses im Abschnitt "Seite unter mehreren URLs zu erreichen (Duplicate Content)" überprüft werden. Generell kann ich diese Seite als Test immer wieder mit guten Gewissen empfehlen.

Meine Weiterleitung per .HTACCESS sieht im übrigen wie folgt aus:

RewriteEngine On

RewriteCond %{HTTP_HOST} !^www.andreas-unkelbach.de$ [NC]
RewriteRule ^(.*)$ https://www.andreas-unkelbach.de/$1 [L,R=301]

RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Der erste Abschnitt sorgt dafür, dass die Domain immer mit www. aufgerufen wird (bevorzugt www-Domain verwenden) der zweite Abschnitt überprüft ob das HTTPS Protokoll ausgeschaltet ist und leitet sofern dieses der Fall ist auf die https Seite weiter.
 
Für obiges Beispiel erhalten die URL unter 1 bis 3 als HTTP Status Code 301 und die Weiterleitung auf die https Variane und die letzte URL wird per HTTP Status Code 200 als okay ausgeleifert.


Im Ergebnis ist damit die Seite immer in der Form https://www.andreas-unkelbach.de aufgerufen da alle anderen URL durch den 301 Status Code umgeleitet werden, während die gewünschte URL per 200 als okay zählt und die Daten werden immer verschlüsselt übertragen

Website Analytics - Meta tag referrer

Eine interessante Info für andere Seitenbetreibende dürfte noch sein, dass Links von einer mit https:// verlinkende Seite auf eine http:// Seite als direkter Aufruf gezählt werden, da hierdurch der Referrer-Link nicht übertragen wird.

Hier gibt es jedoch einen W3C-Spezifikation eines Meta-Tag durch das weiterhin auch der Referrer Link übergeben wird. Hier regelt "§ 3. Referrer Policies".

Über den, im HEAD Bereich befindlichen Metatag kann die Übertragung des Referrer eingestellt werden. Dabei sind mehrere Möglichkeiten vorhanden:
  • <meta name="referrer" content="origin">
    Hierdurch wird zumindest die Domain als Referrer mit übergeben.
  • <meta name="referrer" content="unsafe-url">
    Hierdurch wird die komplette URL mit übertragen
  • <meta name="referrer" content="no-referrer-when-downgrade">
    Dieses ist die Vorbelegung der Spezifikation. Sofern eine https auf eine http Seite verweist wird kein Referrer übertragen, allerdings erfolgt eine Übertragung von https auf https ebenso wie von http auf https
  • daneben gibt es noch weitere Möglichkeiten auf die ich durch die Spezifikation verweise.
Da ich persönlich es als wichtig empfinde zu sehen, woher Seiten verlinken habe ich bei Einzelseiten und Artikeln die Variante der Übertragung der Seite gewählt und bei Übersichtseiten die sich auch ändern können lediglich die Domain mit übertragen. Aktuelle Browser halten sich wohl auch an diesen Meta-Tag.
 

Fazit

Insgesamt war der ganze Umzug dann tatsächlich erfolgreich, wobei tatsächlich einige Einstellungen noch nachgebessert worden sind (sowohl durch PHP Code als auch was die Einführung von SSL anbelangt). Hier bin ich sehr dankbar, dass meine Frau ruhig und kompetent das entsprechende Coding angepasst hat aber auch der Transfer meiner Seiten recht problemlos funktionierte. Mittlerweile dürfte auch Mailempfang wieder funktionieren und selbst die Twitter-Integration (die tatsächlich etwas arg kompliziert war) hat problemlos funktioniert. Ich würde mich freuen, wenn auch weiterhin mein Blog interessant ist und die Umstellung keine Probleme macht. Bekannt ist mir tatsächlich nur, dass in manchen Feedreadern der RSS Feed erneut abonniert werden muss, daher ist ein Besuch auf dieser Seite sicherlich hilfreich :-)
 

Hinweis: Aktuelle Buchempfehlungen besonders SAP Fachbücher sind unter Buchempfehlungen inklusive ausführlicher Rezenssionen und Bestellmöglichkeit zu finden.
Diesen und weitere Texte von Andreas Unkelbach finden Sie auf http://www.andreas-unkelbach.de


Dienstag, 4. Oktober 2016
20:42 Uhr

Dokuwiki Seiten als PDF exportieren durch Plugin DW2PDF und technischer Hintergrund zum Erstellen von PDF mit PHP

Wie unter "Erste Erfahrungen mit DokuWiki als Wiki (Installation)" beschrieben nutze ich für eine Dokuwiki Installation derzeit das Template "MonoBook" wodurch die klassische Wikipedia Oberfläche nachempfunden wird. Auf diese Weise ist mein Wiki relativ übersichtlich und kann für mehrere Projekte und unterschiedliche Projektgruppen verwendet werden.

Derzeit sieht die Oberfläche wie folgt aus:

Oberfläche Dokuwiki Installation

Dabei bin ich, zumindest für die Dokumentation von diversen Prozessen und Handbüchern ziemlich der im Artikel "Erste Erfahrungen mit Dokuwiki Konzept + Herangehensweise (Grundlagen)" angedachten Überlegungen treu geblieben. Allerdings habe ich für einzelne Projekte einen eigenen Namensraum verwendet, so dass sowohl Projekte im Ehrenamt aber auch für andere Bereiche sauber durch Namensräume und entsprechende Benutzergruppen getrennt sind.

Als Vorteil hat sich hier das Navigationsverzeichnis und Plugin Indexmenue (siehe "Erste Erfahrungen mit Dokuwiki: Vorteile von Wiki und Internetseite im Indexmenu vereinen") gezeigt, wodurch relativ schnell neue Unterseiten angelegt werden können aber sich auch die Projektteilnehmenden schnell zu recht gefunden haben.

Anhand einzelner Berechtigungsvergaben sind die entsprechenden Unterseiten nur für einzelne Projektteilnehmende frei gegeben und es kann hier relativ entspannt gearbeitet werden.

CKGEdit für WYSIWYG Editor

Besonders durch den im Artikel "Dokuwiki Plugin CKGEdit und Hochladen von PDF, Excel oder andere Medien" ist es auch für Neulinge recht einfach sich ohne Syntax an die Bearbeitung von Artikeln zu wagen und diese auch relativ einfach zu bearbeiten.

Editor CKGEdit für Dokuwiki

Besonders durch die schon in anderen Programmen vertraute Oberfläche ist es hier ein leichtes entsprechende Texte zu bearbeiten.

Export von Wiki-Seiten als PDF Dokument

Neben der Onlineverfügbarkeit der Texte gab es aus einer Projektgruppe aber auch die Anforderung vorhandene Texte nicht nur auszudrucken sondern auch als PDF zur Verfügung zu stellen.

Hierzu nutze ich das DW2PDF Plugin und bin damit von Anfang an sehr glücklich, auch da es mir zu einzelnen Überschriften ein Inhaltsverzeichnis anlegte um in entsprechend erzeugten PDF Dokumente zu navigieren.

Plugin DW2PDF und Dokuwiki Template Monobook

Besonders schick ist, dass im Template Monobook der Export über einen eigenen Reiter als PDF funktioniert. Die Vorgehensweise ist in der Doku zum Plugin beschrieben.

Hierzu habe ich die Datei tabs.php im Dokuwiki Verzeichnis unter
  •  lib     >     tpl     >     monobook     >     user
am Ende um

//PDF plugin: export tab
if (file_exists(DOKU_PLUGIN."dw2pdf/action.php") &&
    !plugin_isdisabled("dw2pdf")){
    $_monobook_tabs["tab-export-pdf"]["text"] = $lang["monobook_tab_exportpdf"];
    $_monobook_tabs["tab-export-pdf"]["href"] = wl(getID(), array("do" => "export_pdf"), false, "&");
}

erweitert. Ferner wurde in der Datei lang.php unter
  •  lib     >     tpl     >     monobook     >     lang     >     de
die Zeile

      $lang["monobook_tab_exportpdf"] = "Export as PDF";

ergänzt. Im Ergebnis ist nun ein weiterer Tab (Export:PDF) vorhanden.

Durch einen Klick auf "Export: PDF" steht das aktuelle Dokument als PDF zur Verfügung.

Schaltfläche Export: PDF


Kritisiert wurde jedoch durch die Projektgruppe dass durch das verwendete Template innerhalb des Plugin weitere Zusatzinformationen, so zum Beispiel URL oder auch QR Code mit eingebunden worden sind.

Daher habe ich in den Einstellungen zum Plugin unter den Punkt


"Plugin»dw2pdf»template- Welches Template soll zur Formatierung der PDFs verwendet werden?" in der Admin Oberfläche unter den Punkt Konfiguarion und hier bei den Einstellungen des Plugin DW2PDF.

Plugin dw2pdf template - Welches Template soll zur Formatierung der PDFs verwendet werden?

ein eigenes Template hinterlegt.

Da mir ja relativ klar war, dass ich keine weiteren Zusatzinfos zum vorhandenen Design der Seite haben wollte habe ich den Ordner default nach unkelbach kopiert.

Template für PDF Export von DW2PDF einstellen

Der Templateordner für PDF Exporte findet sich im Dokuwiki Verzeichnis unter
  • lib      >     plugins      >     dw2pdf     >     tpl
Hier kann der Ordner default nach einen beliebigen anderen Namen kopiert werden. In meinen Beispiel war das unkelbach es kann aber auch blank oder ein vergleichbarer Name sein.

Nun müssen nur noch die einzelnen Dateien bearbeitet werden.
  1.  footer_even.html 
    Hier wird die Fußzeile für alle Seiten festgelegt
  2. footer_odd.html
    Ebenfalls allerdings für ungerade Seiten
  3. citation.html
    Zitatbox (hier ist die URL zum Wiki-Artikel hinterlegt und ggf. ein QR Code
  4. header_even.html
    Kopfzeile
  5. header_odd.html
    Kopfzeile für ungerade Seiten
Da es mir wichtig war eben keine weiteren Infos zu hinterlegen, habe ich die weitergehenden Formatierungsanweisungen direkt gelöscht und quasi eine leere Seite hinterlegt.

Grundsätzlich hätte hier aber neben HTML Code auch Platzhalter wie: @WIKIURL@ oder @DATE@ für das Erstellungsdatum des PDF hinterlegt werden. Besonders elegant für citation.html sind natürlich auch @QRCODE@ für einen QR Code zur Seite oder auch @PAGEURL@ für die direkte URL zum Artikel.

Innerhalb des Templatev Verzeichnis liegt auch die Datei readme.txt in der weitere Möglichkeiten zur Gestaltung hinterlegt sind.

So kann auch ein Cover verwirklicht werden ebenso wie eine letzte Seite. Gerade wenn Seiten eines Wiki auch als Vorlage zum Weitergeben gedacht sind, eignet sich dieses Plugin besonders gut um hier mittels PDF auch fertige Dokumente auszutauschen.
 

Technischer Hintergrund PDF mit PHP erstellen

Auch wenn PHP selbst schon PDF erstellen kann (siehe zum Beispiel das Anwendungsbeispiel auf php.net durch die PDFlib)  verwendet dieses Plugin jedoch die Befehlsklasse / PHP Library mpdf (siehe Homepage oder Github).

Hierdurch kann das Plugin auch Lesezeichen in PDF erstellen und auch erweiterte PDF Funktionen nutzen.

Thomas Weise hat auf drweb.de im Artikel "PDF-Dokumente mit PHP erzeugen" zu diesen Anwendungsfall ebenfalls eine umfangreiche Dokumentation erstellt. Allerdings wird hier die Klasse FPDF verwendet.

Anwendungsgebiete Dokuwiki

Durch die PDF Export Funktion eignet sich Dokuwiki noch mehr wie schon im Artikel "Erste Erfahrungen mit Dokuwiki Konzept + Herangehensweise (Grundlagen)" oder auch im Abschnitt "Grundsätzliche Ansätze zur Einführung eines Wissensmanagementsystems oder Austauschplattform" des Artikels "Social Media Systeme wie Wiki, Onlineforen oder Komptenzprofile mit PHP umsetzen" beschrieben sowohl zur gemeinsamen Arbeit an Dokumenten als auch für eine zentrale Anlaufstelle für umfangreiche Dokumentationen.

Hinweis: Aktuelle Buchempfehlungen besonders SAP Fachbücher sind unter Buchempfehlungen inklusive ausführlicher Rezenssionen und Bestellmöglichkeit zu finden.
Diesen und weitere Texte von Andreas Unkelbach finden Sie auf http://www.andreas-unkelbach.de


Dienstag, 29. März 2016
21:28 Uhr

Dokuwiki Plugin CKGEdit und Hochladen von PDF, Excel oder andere Medien

Vor einiger Zeit hatte ich mich schon einmal das Thema Dokuwiki (ein rein auf PHP basierendes Wiki System ohne Datenbank) beschäftigt. Hierbei werden die einzelnen Medien und Seiten als Dateien gespeichert (Inhalte und Metadaten als Textdateien) so dass hier keine SQL-Datenbank wie MySQL erforderlich ist. Dieses hat einige Vorteile gerade in Hinblick auf Datensicherung, Wartung oder auch Umzug eines bestehenden Wiki. Dabei kann es durch verschiedene Erweiterungen ("Plugins") erweitert werden um das Wiki auf die eigenen Bedürfnisse anzupassen.

Im Rahmen einer Anwendungsdokumentation ("Erste Schritte mit Wiki von der Anmeldung zur Seitenerstellung") habe ich mich auch mit der Möglichkeit auseinander gesetzt wie nicht nur Inhalte aus Winword in den Editor kopiert werden können sondern auch Dokumente (Texte, Tabellen, PDF, ...) in das Wikisystem eingebunden beziehungsweise hochgeladen werden können.
 

Dateien im Dokuwiki Editor (DW Editor) hinzufügen

Innerhalb des Dokuwiki Editor (DW Editor) können Medien (unabhängig ob Bilder oder Dateien über die Schaltfläche "Bilder und andere Dateien hinzufügen" (siehe Abbildung) hochgeladen werden.

Doku Wiki Editor Bilder und andere Dateien hinzufügen

Danach erscheint ein Fenster zur Dateiauswahl über das sowohl Bilder als auch andere Dateien hochgeladen und eingebunden werden können.

DokuWiki Editor - Dateiauswahl

Das entsprechende Medium (Bild oder Datei) wird dann entsprechend hochgeladen.

Plugin CKGEdit - WYSIWYG Editor für Dokuwiki


Ich nutze für ein Wiki allerdings das "CKGEdit Plugin"  was mir einen WYSIWYG Editor ermöglicht. CKGEdit beruht auf den auf JavaScript beruhender freier webbasierter WYSIWYG Editor CKEditor (siehe Beschreibung "CKEditor auf Wikipedia" ) der für Dokuwiki angepasst wurde und auch für andere Projekte genutzt werden kann. Insgesamt erleichtert dieses Plugin in meinen Augen gerade für Einsteiger die Handhabung eines Wiki wie auch das von mir genutzte Dokuwiki. Dieses Plugin überzeugt schon allein dadurch, dass es Formatierungen (z.B. aus Winworddokumente aus der Zwischenablage (Kopieren (STRG+C) und Einfügen (STRG+V) oder per rechter Maustaste) ebenso wie Bilder direkt in den Editor einfügen kann. Gerade bei Screenshots ist dieses sehr praktisch, da hier Bilder auch direkt hochgeladen und in die Wikiseite eingebunden werden. Aber dieses nur am rande.
 

Dateien im Plugin CKGEdit hochladen

Beim Versuch hier über die Schaltfläche "Bild" eine Datei hochzuladen (siehe Abbildung)

CKEdit Bild einfügen

erscheint dann jedoch ein Auswahlmenü (hinter der Schaltfläche "Durchsuchen") über das tatsächlich nur Bilder hochgeladen werden können.

CKEdit Bildeigenschaften

Daher hatte ich lange Zeit überlegt ergänzend zum Plugin auch den ursprünglichen DW Editor zur Verfügung zu stellen.

Jedoch ist es auch mit diesen Plugin möglich normale Dateien hochzuladen, sofern diese als Mediafiles als Dateityp entweder unter conf/mime.conf oder conf/mime.local.conf  zugelassen sind.  Die meisten Officedokumente sind hier ebenso wie PDF schon zugelassen. Besondere Formate (als Beispiel sind hier die von mir gerne verwendete Dateiendung *.sq01 für SAP Query) sind hier in der lokalen media.local.conf zu hinterlegen.

Hierzu ist jedoch statt über Bild einfügen die Schaltfläche "Link einfügen/editeren" zu verwenden (siehe Abbildung).

CKEdit Link einfügen
Anstatt nun einen Link auf eine bestehende Seite einzufügen kann im Menü die Option "internal media" gewählt werden (siehe Abbildung).

CKEdit Link einfügen internal media

Hier kann nun über die Schaltfläche "Durchsuchen" tatsächlich auch jede andere Datei (sofern diese vom Dateityp zugelassen ist) eingefügt und hochgeladen werden.

CK Edit andere Dateien uploaden

Insgesamt ist die Trennung von Medien und Bildern hier tatsächlich logisch, jedoch muss man auch erst einmal darauf kommen diese an unterschiedlichen Stellen zu suchen. Wenn man das System aber einmal verstanden ist, besteht eigentlich kaum noch eine Notwendigkeit die Möglichkeit des Wechsel zum normalen DW Editor zu erlauben (dieses lässt sich in der Konfiguration über den Punkt dw_edit_display deaktivieren.

Hier kann festgelegt werden, welche Benutzer Zugang zur Schaltfläche "DW Edit" und damit Wechsel zum Original Editor von Dokuwiki haben.

Als Optionen stehen hier folgende Möglichkeiten zur Verfügung:
  • "all" für alle Benutzer
  • "admin" für Administratoren
  • "none" für Niemand.
Defaulteinstellung ist dabei "all".

Hintergrund: Dokuwiki für Wissensmanagement oder als interne Austauschsplattform

Die Vorzüge dieses Wiki-System hatte ich ja auch schon im Artikel "Erste Erfahrungen mit Dokuwiki Konzept + Herangehensweise (Grundlagen)" kurz dargestellt.

Ein weiterer Vorteil ist sicherlich auch die einfachen Installation und der Verzicht auf eine Datenbank (siehe hierzu auch "Erste Erfahrungen mit DokuWiki als Wiki (Installation)").

Insgesamt machen entsprechende Plugins und Erweiterungen hier ein Wiki tatsächlich zu einen sehr sinnvollen Arbeitsinstrument und ich sehe es gerade für Projektarbeit als ein sehr gut geeignetes Tool, das zwar einiges an Einarbeitungszeit bedarf (wobei die Überzeugungsarbeit für andere Projektbeteiligte noch höher ist) aber dann tatsächlich für Wissensmanagement oder als interne Austauschsplattform wie im Artikel "Praktische Nutzung von social media Diensten für meinen Arbeitsalltag" beschrieben sich sicherlich bewähren kann.

Ich bin gespannt, wie es sich für eine kleine Arbeitsgruppe bewähren wird und hoffe, dass dieses dann im kommenden Jahr vielleicht auch für andere Bereiche genutzt werden kann.

Weitere Erfahrungen
Weitere Erfahrungen im Umgang mit Dokuwiki sind unter den Tag Dokuwiki zu finden.

Hinweis: Aktuelle Buchempfehlungen besonders SAP Fachbücher sind unter Buchempfehlungen inklusive ausführlicher Rezenssionen und Bestellmöglichkeit zu finden.
Diesen und weitere Texte von Andreas Unkelbach finden Sie auf http://www.andreas-unkelbach.de


Donnerstag, 26. November 2015
21:15 Uhr

Social Media Systeme wie Wiki, Onlineforen oder Komptenzprofile mit PHP umsetzen

Im Artikel "Praktische Nutzung von social media Diensten für meinen Arbeitsalltag" hatte ich ja schon einige von mir genutzten Tools im Rahmen des social web vorgestellt. Gerade die Themen Onlineforen, Profile oder Wissensmanagement sind aber gleichzeitig auch Themen, die oftmals in einer kleinen Benutzergruppe behandelt werden sollen und eben nicht öffentlich zugänglich gemacht werden sollen. Entsprechende Gründe können hier Datensicherheit aber auch Datenschutz sein oder einfach, dass man unbeschwert ohne das gesamte Internet als Zuschauende eine Frage stellen kann.

Grundsätzlich empfinde ich den Austausch über social media auch im Arbeitsumfeld eine gute Idee. So können Fragen schnell in Onlineforen gestellt werden und sind auch für andere Personen leichter gemeinsam mit der Antwort zu finden, ohne dass eine ganze Sammlung von E-Mails durchsucht werden müssen.

Ebenso verhält es sich bei der Dokumentation von verschiedenen Sachverhalten in Form eines Wiki oder auch von Profilen mit den einzelnen Kompetenzen von Teilnehmenden einer Gruppe.

Allerdings sind alle technischen Tools im ersten Moment einmal nur Werkzeuge und müssen danach organisatorisch mit Leben gefüllt werden. Auf einige der damit verbunden Aspekte möchte ich in unteren Artikel eingehen.

Sollten Sie die interne Kommunikation mit Microsoft Sharepoint nutzen wollen, so sind auf der Seite "Interne Kommunikation mit SharePoint Communities, Wikis & Blogs"  der S&L Netzwerktechnik GmbH ein Überblick über die Möglichkeiten mit Sharepoint Server dargestellt. Im Verlauf des folgenden Artikels möchte ich jedoch Webtools basierend auf PHP und Opensource vorstellen. Dennoch gelten die allgemeinen Angaben natürlich auch für andere Produkte.


Innerhalb der  folgenden Abschnitte möchte ich sowohl die technischen Aspekte der Einführung von Software beschreiben als auch kurz auf den organisatorischen Hintergrund des social web im Unternehmen eingehen. Nachdem hier technisch die Tools vorgestellt werden und diese auch sicherlich verlockend erscheinen stellt sich nun aber noch die Frage, wie ein solches Tool in der Praxis genutzt wird und welche Vorraussetzungen vor der Einführung solcher Tools erfüllt sein sollten. Hier habe ich versucht im folgenden Abschnitt eine Antwort zu geben. Hierbei möchte ich diesen Artikel allerdings nicht als Kritik an der Einführung solcher Systeme verstanden wissen, sondern einige Punkte erwähnen, die bei der guten Idee mit bedacht werden sollten.


 

Wikisysteme


Wie schon im oberen Artikel erwähnt hatte ich schon im Artikel "Erste Erfahrungen mit Dokuwiki Konzept + Herangehensweise (Grundlagen)"  erste Überlegungen zum Einsatz eines Wiki aufgeschrieben.

Exkurs: Wikis im schulischen oder wissenschaftlichen Umfeld
Zur wissenschaftlichen Nutzung eines Wiki als Wissensmanagementsystem gibt es an der Humboldt-Universität zu Berlin  eine Abhandlung zum Thema "Internen Wissensmanagement in kleineren Bibliotheken", welche wesentlich tiefer in dieses Thema einsteigt. Aber auch im schulischen Umfeld wird  "Ein Unterrichtswiki mit DokuWiki realisieren" ein solches System gerne genutzt. Die Landesakademie für Fortbildung und Personalentwicklung an Schulen  in BW hat dabei die Vorteile und Nachteile der Software auf der Seite "Vor- und Nachteile eines DokuWikis" ausführlicher dargestellt.


Da ich nicht zusätzlich zum Wiki System eine weitere Datenbank anlegen wollte hatte ich mich für Dokuwiki entschieden, das rein auf PHP basiert. Hier werden die einzelnen Einträge als Dateien angelegt und auch sonst bietet das Wiki eine gut pflegbare Oberfläche und ermöglicht sehr schnell sowohl einen Umzug als auch eine sinnvolle Datensicherung oder auch manuelle Bearbeitung der Dateien.

Von daher war die im Artikel "Erste Erfahrungen mit DokuWiki als Wiki (Installation)" beschriebene Installation wirklich sehr einfach und dank Upgrade-Plugin kann ich ohne weiteren Aufwand auch sowohl Plugins als auch das Wiki selbst ständig auf den aktuellen Stand halten. Hierzu ist allerdings für die neueste Version der Software PHP ab Version 5.3.3 erforderlich.

Dafür bietet Dokuwiki dann tatsächlich den Vorteil, dass es schnell installiert ist und auch wirklich nur als Datei einzelne Daten ablegt.

Durch die Nutzung von Templates (siehe auch Artikel "Erste Erfahrungen mit Dokuwiki: Vorteile von Wiki und Internetseite im Indexmenu vereinen") kann das Wiki auf die eigenen Bedürfnisse angepasst werden. Besonders zu loben ist nebenbei das Onlineforum zur Software forum.dokuwiki.org wo sowohl Entwickler als auch Anwender gerne weiter helfen.

Onlineforen

Sowohl für eine Vereinsseite als auch auf meiner damaligen im BWL Studium hatte ich die Software phpBB genutzt. Dieses weit verbreitete Forum basiert ebenfalls auf PHP und MySQL.

Aus Nostalgiegründen habe ich sogar noch einen kleinen Screenshot von dieser Seite:
BWL Studium an der FH Gießen
Mittlerweile gibt es jedoch auch Onlineforen die ausschliesslich mit PHP auskommen.
EIne interessante Option ist dabei "phpFK – PHP Forum ohne Datenbank". Dabei handelt es sich umein kostenloses PHP Forum Script, ohne MySQL, programmiert in PHP. Es kann auf der Seite www.frank-karau.de heruntergeladen werden.

Persönlich habe ich das Forum selbst noch nicht im Einsatz kenne jedoch ein sehr gut besuchtes Forum, dass auf diese Technik aufsetzt und in meinen Augen ebenfalls sehr stabil läuft.

Grundlagen Onlineforen PHPbb

Eine schöne Einführung in die Organisation eines Onlineforums (in diesen Fall mit PHPbb) ist im ctMagazin im Artikel "Diskussionsgrundlage Eigene Webforen mit phpBB einrichten und verwalten". Gerade die Themen abseits der Technik sind hier sicher gerade am Anfang lesenswert. Für den deutschsprachigen Bereich ist sicherlich auch die Seite phpbb.de eine gute Anlaufstelle.



Soziale Netzwerke

Natürlich denkt man da an erster Stelle an Profile bei Facebook, XING oder vergleichbare Netzwerke. Interessanterweise gibt es hier aber mittlerweile ebenfalls OpenSource Lösungen die es ermöglichen selbst Profile anzulegen und eine eigene Community zu bilden.

Hier kann dann aber tatsächlich nicht auf eine Datenbank verzichtet werden, so dass der Einsatz von MySQL angsagt ist. Dennoch dürfte ein Blick auf "HumHub eine kostenlose Social Network Software" das intensivere Beschäftigen wert sein. Das Projekt kann auf der Seite humhub.org betrachtet werden.

Blog

Zu Blogsystemen brauche ich wohl kaum etwas zu sagen. Sofern man keine eigenentwickelte Software einsetzt wird allgemein wohl Wordpress empfohlen. Dieses System ist unheimlich verbreitet und hat dadurch natürlich Vorteile in Bezug auf Anlaufstellen für Support oder Hosting auf der anderen Seite aber auch den Nachteil, dass bei bekannten Sicherheitsprobleme hier ein schnelles Patchen und regelmäßige Wartung erforderlich ist.


 

Fazit

Trotz aller vorhanden Technik bedarf es auch des kooperativen Miteinanders, ansonsten ist unabhängig von der eingesetzten Software am Ende eine oder nur sehr wenige Personen am Schreiben von Artikeln und es weiter kein Wunder, wenn ein ambitioniertes Projekt dann mangels Input eingestellt wird. Von daher wäre vor der Einführung eines Tools zur Dokumentation von vorhandenen Tools die größere Frage, ob eine solche Austauschsplattform für jeden Arbeitsbereich sinnvoll ist.
 

Grundsätzliche Ansätze zur Einführung eines Wissensmanagementsystems oder Austauschplattform

Vor der Einführung eines Tools sollte jedoch geklärt werden, welche Ziele mit der Software verfolgt werden sollen. Auch hier trifft das Sprichtwort zu, dass wenn man einen Hammer in der Hand hält sämtliche Probleme wie Nägel aussehen.

Letzten Endes ist die Einführung eines Wissensmanagementsystems egal ob nun Wiki oder Onlineforum auch immer ein Kulturwechsel in der Austauschsform und bedarf gleichzeitig eine Abstimmung und sowohl Menschen die Fragen in einen Forum stellen oder Struktur in eine Seite / Wiki bringen als auch wieder Menschen die auf Fragen Antworten schreiben oder Artikel einarbeiten und diese entsprechend erweitern.

Hier sollte eine entsprechende Vorarbeit geleistet werden (bspw. bestimmte Themengebiete schon einmal in groben Zügen abgearbeitet werden, so dass hier nicht alle interessierten Personen vor einer leeren Seite stehen und nicht wissen, was sie schreiben sollen. Daneben sollte die Struktur aber auch nicht zu beengt sein oder zu kleinteilig, so dass hier die freie Gedankenentfaltung eines Wiki eventuell beeinträchtigt wird.

Gerade wenn Sachverhalte (bspw. Kostenstellenstrukturen oder Nummernkreise bei Stammdaten) unterschiedliche bei den einzelnen Teilnehmenden dargestellt werden, sollte abgestimmt werden, wie ein allgemeiner Teil dann in für die jeweiligen Bereiche individuelle Abschnitte aufgeteilt werden kann.

Denkbar wäre zum Beispiel eine Seite zur Anlage eines Projektes in Form eines Innenauftrag mit Bezügen auf Kostenstelle und Profitcenter. Diese Seite kann sehr allgemein gehalten werden und auf Unterseiten innerhalb des Wiki je Teilnehmende verweisen in der dann die Besonderheiten bzgl. Nummernlogik, Stammdatenhierarchie oder zu informierenden Personen festgehalten werden kann.

Dieses sind allerdings keine Themen die einfach so angefangen werden können sondern tatsächlich einen beträchtlichen Einsatz an Ressourcen in die grundsätzliche Planung einer Struktur und eines gemeinsamen Vorgehens bedürfen.

Ebenso verhält es sich auch bei der Einführung eines Onlineforums.

Hier sind nicht nur Kreise der Teilnehmende zu bestimmen (so wäre die Frage, ob nur die Controllingabteilung, Finanzbuchhaltung oder auch Planung einen Zugang erhalten) sondern auch die einzelnen Unterforen sollten entsprechend geordnet und ggf. auch moderiert werden.

Sinnvoll kann hier eine Aufteilung in die Rubriken:
  • Technik
    • Finanzwesen
    • Controlling
    • Beschaffung
    • Personalwesen
  • Fachlich
    • KLR (Kosten Leistungsrechnung
    • Berichtswesen
      • extern
      • intern
    • Feste Themenbereiche
      • Finanzstatistik
      • Personalstatistik
Schon anhand der Strukturierung von Unterforen kann abgesehen werden, wie unterschiedlich hier die Themen behandelt werden. Im SAP Umfeld kann ich als positive Beispiele die beiden Onlineforen  Forum zum Thema SAP ERP Financials (FI CO) (fico-forum.de) und das Forum der SAP Community -Forum für SAP (dv-treff-community.de) nennen.

Für ein unternehmensinternes Forum würde aber ebenfalls die Frage gestellt werden, wie kleinteilig dieses abgebildet werden soll und wer sich für die Moderation oder auch um regelmäßige Antworten zu den einzelnen Themen kümmert.

Der Vorteil eines Forum ist allerdings, dass die vorhandenen Antworten später in ein anderes System (Wiki, Handbuch etc.) übertragen werden können und sich hier die Basis eines Wissenspool bilden kann. Vorraussetzung dafür ist aber auch dass die Teilnehmenden entsprechend Zeit haben und nicht andere Baustellen dringlicher sind und hier dann das Thema nicht durch andere Themen überlagert wird.

Sicherlich ich bin zu meiner Anfangszeit (1997) mit Foren wie spotlight und verschiedene andere Foren (oder auch Echos im Fidonet siehe "Das FIDO-Netzwerk (FidoNet) - ein Netzwerk zwischen Mailboxen (BBS)" quasi groß geworden, aber heutzutage ist es sicherlich schwieriger hier Personen, gerade im beruflichen Umfeld, für eine solche Technik zu begeistern und vor allen anderen zur dauerhaften Mitwirkung (okay seien wir ehrlich es ist Mitarbeit) zu überreden.

Dennoch steckt in diesen Tools ein Potential und die Möglichkeit Wissen nicht nur zu dokumentieren sondern durch das gemeinsame Schreiben auch tatsächlich miteinander auszutauschen.
Hier sollte aber sehr viel Zeit in die Grundlagen und weniger in die Technik gesteckt werden.

Bei den ausgewählten Softwarelösungen habe ich mich bewusst um solche bemüht die mit PHP umzusetzen sind. PHP ist mittlerweile bei den meisten Webhostingangeboten dabei und dürfte daher eine wesentlich geringere Hürde darstellen als die Installation von Clientsoftware auf den Rechnern der Teilnehmenden, so dass hier direkt von den einzelnen Personen die Software genutzt werden kann.

Zum Thema PHP möchte ich auf folgende Literarturempfehlung hinweisen:

"PHP für dich" von Claudia Unkelbach
ISBN: 383915409X

Nebenbei, sollten Sie Interesse an PHP und MySQL haben, kann ich auch die Buchrezension zu "PHP für dich" empfehlen.
 

Hinweis: Aktuelle Buchempfehlungen besonders SAP Fachbücher sind unter Buchempfehlungen inklusive ausführlicher Rezenssionen und Bestellmöglichkeit zu finden.
Diesen und weitere Texte von Andreas Unkelbach finden Sie auf http://www.andreas-unkelbach.de


Samstag, 18. Mai 2013
20:38 Uhr

Was ist zu beachten beim Serverumzug?

Ausgangslage
Im Rahmen eines anstehenden Serverumzuges bei meinen Webhoster hatte ich mich nun doch wieder einmal etwas intensiver mit diversen Einstellungen beschäftigten können und konnte einige für mich neue Hilfsmittel und Hinweise finden. Damit der Umzug reibungslos funktioniert habe ich die für mich wichtigsten Punkte hier festgehalten und denke, dass diese auch auf andere Anbieter zutreffen kann.

Ich bin mir sicher, dass hier noch der ein oder andere Punkt hinzu kommen kann .


1. Register globals
Gerade beim Wechsel der PHP Version kann es einige Änderungen geben.

Unter anderen wird ab PHP Version 5 auch "register_globals" nicht mehr standardmäßig aktiviert. Sofern die Webhostingkonfiguration keine Aktivierung anbietet, besteht die Möglichkeit dieses auch bspw. per .httaccess über die Anweisung "php_flag register_globals 1" wieder zu aktivieren. Weitere Möglichkeiten sind bei mrphp.com im Artikel How to Enable Register Globals in PHP 5 beschrieben. Sofern die per Formular übergebenen Variablen allerdings per $_POST und $_GET ausgelesen werden sollte register_globals auch nicht zwingend aktiviert werden, sofern nicht bestimmte Skripte dieses erfordern. Dieses kann aber unter Umständen ein Sicherheitsrisiko sein. Eine Anleitung zur sicheren Übergabe von Variablen ist unter PHP für dich - Variablen mit und ohne Formulare übergeben ausführlich beschrieben.

2. Dateizugriffsrechte
Da Dokuwiki die einzelnen Dateien direkt in Ordnern speichert und hierfür keine Datenbank verwendet benötigt Dokuwiki (bzw. PHP) entsprechende Schreibzugriffsrechte am Server. Sofern diese nach erfolgreichen Umzug nicht mehr vorhanden sind, sollten hier die chmod Einstellungen der einzelnen Ordner und Seiten überprüft werden.

Sofern hier die Zugriffsberechtigung auf "0755" hat nur der Besitzer Schreibberechtigung auf die einzelnen Seiten des Servers. Hier ist es dann erforderlich, dass der PHP-Prozess unter dem gleichen Usernamen ausgeführt wird, wie der Besitzer der Dateien. Alternativ könnte der PHP Prozess in der gleichen Gruppe wie der Besitzer angelegt sein, dann würde auch die Berechtigung "0770" hilfreich sein. Die denkbar ungünstigste Alternative (aus Sicherheitsgründen) ist es wohl Zugriff per "777" zu gewähren, da hier dann jeder mit Zugriff auf den Webserver (bspw. auch andere Benutzer) die Berechtigung hätten Dateien zu erstellen oder auch zu löschen.

Unter Zugriffsrechte auf Dateien setzen ist auf dokuwiki.org ein PHP Skript "getUIDGID.php" dargestellt mit dem festgestellt werden kann unter welchen Benutzernamen der PHP Prozess läuft. Alternativ kann dieses auch über phpinfo(); im Abschnitt User/Group unter Configuration ausgelesen werden.

Sofern PHP als apache Modul ausgeführt wird, kann es helfen, dies auf Fast-CGI umzustellen, da scheinbar hierdurch PHP unter den eigentlichen Benutzer läuft.

Sofern PHP nicht als Apache-Modul (mod_php) sonmdern als FSTCGI läuft besteht der Vorteil, dass PHP mit den entsprechenden Rechten des User anstat des Webservers laufen. Hier durch bestehen dann auch keine Probleme bzgl. der Rechtevergabe (bzw. des Schreibzugriffes). Alternativ müsste per chmod auch dem Webserver (bzw. user unter dem PHP ausgeführt wird, Schreibberechtigung auf die jeweiligen Wikiverzeichnisse gestattet werden.

Sofern in der Serverkonfiguration die Umstellung nicht möglich ist, besteht die Möglichkeit ggf. ebenfalls per .httaccess möglich zu aktivieren.

AddHandler fcgid-script .php
Options +ExecCGI
FcgidWrapper /var/www/cgi-bin/php-fcgi .php

Hierbei liegt das cgi-bin Verzeichnis unter /var/www/cgi-bin. Meistens sollte hier das Stammverzeichnis des Webspace eingetragen werden.Die Einstellung gilt dann für alle Dateien mit der Endung .php. Siehe hierzu den Blogbeitrag Configure .htaccess. to use FastCGI for PHP auf mikeyboldt.com.

Ansonsten funktioniert ein Umzug von Dokuwiki tatsächlich wie unter Wie zieht man DokuWiki am besten um? auf dokuwiki.org beschrieben relativ unproblematisch. (Zusammenfassung: einfach Ordner von einen auf den anderen Server kopieren .).

Sofern es noch Fehlermeldungen bezüglich Schreibzugriff auf den Cache gibt hilft das Plugin Cache and Revisions Eraser wodurch der Cache der einzelnen Seiten gelöscht wird und bei erneuten Aufruf der Seiten wieder aufgebaut wird.

3. absolute und relative Pfade
Wie unter Erste Erfahrungen mit Dokuwiki Plugins (Oberfläche) beschrieben ist es, sofern keine symbolischen Links vom Webserver unterstützt werden erforderlich den absoluten Pfad zur Dokuwikiinstallation in der Datei
config.php
im Ordner
lib/plugins/fckg/fckeditor/editor/filemanager/connectors/php
anzugeben. Dieses ermöglicht dann auch ein Hochladen von Bildern, Dokumenten und auch Erstellen von Seiten mit FCKGlite (und vermutlich auch mit dem Nachfolger CKGedit) im vorgesehenen Datenverzeichnis.

Der absolute Serverpfad ist über die PHP Anweisung echo $_SERVER['DOCUMENT_ROOT']; zu ermitteln.

4. MySQL
Eine weitere Umstellung kann bei der Verwendung von MySQL sein, dass sich hier Datenbanknamen und auch Zugangsdaten geändert haben. Entsprechend sind hier PHP Skripte ebenfalls anzupassen, sofern hier ein Zugriff auf MySQL erfolgt. Zur Datenbankverbindung finden sich Informationen auch auf PHP für dich - Mit PHP mit der mySQL-Datenbank verbinden nebst einen Hinweis auf MySQLi.

5. Mailaccounts
Oft ändern sich auch die Zugangsdaten oder Serveradressen von Mailaccounts (Benutzername oder IMAP Server), da ich K-9 Mail unter Android einsetze sind, sofern das Mailprogramm nicht komplett neu eingerichtet werden soll, sowohl Mailausgangsserver- als auch Maileingangsserverzugangsdaten anzupassen. Diese sind innerhalb K-9 Mail an unterschiedliche Stellen zu finden.

Unter Menü->Mehr->Einstellungen
kann unter Kontoeinstellung über "Nachrichten abrufen"ziemlich weit unten die "Einstellungen Posteingang" bearbeitet werden. Hier können Benutzernamen, Server, Passwort und Sicherheitsauthentifizierung (SSL, etc.) eingestellt werden. Unter "Nachrichten verfassen" finden sich die "Einstellungen für Postausgangsserver". Hier sind die entsprechenden Serverdaten zu ergänzen. Eine zweite Alternative wäre die Einstellungen von K-9 Mail zu exportieren und die entsprechende XML Datei zu bearbeiten. Hier finden sich die Einstellungen innerhalb des Tags account. Die exportierte Datei trägt die Bezeichnung settings.k9s und kann in der Kontenübersicht über "Einstellungen Importieren & Exportieren" exportiert werden. Die Einstellungen nebst Konten finden sich dann unter /sdcard/com.fsck.k9/settings.k9s


Mit ein wenig Planung, sollte auch der hier geplante Umzug zu relativ kurzen Aussetzern der Seite führen. Wobei ich dennoch für den ein oder anderen Hinweis dankbar bin.


b) Dokuwiki
Nach einer Neuaufsetzung von Dokuwiki ist einer der ersten Schritte langdelete Plugin welches nicht genutzte Sprachdateien entfernt. Dieses betrifft sowohl die Grundinstallation des Wiki (Core) als auch die installierten Plugins.

Sofern ein Wiki komplett neu aufgesetzt werden soll (oder wie unter Upgrade auf dokuwiki Release 2013-03-06 beschrieben per Upgrade Plugin auf eine neue Version gewechselt werden soll, sind jede Menge aktuelle Sprachversionen automatisch mit heruntergeladen und ggf. gar nicht für alle relevant. Unter download.dokuwiki.org bietet nun Dokuwiki auch selbst an eine Grundinstallation mit der Möglichkeit die für einen selbst genutzte Sprachversion auszuwählen. Darüber hinaus werden auch häufig genutzte Plugins automatisch mit angeboten. Hier kann auch ein entsprechend angepasstes Update von dokuwiki heruntergeladen werden.

c) Providerwechsel
Als interessante Information am Rande. Das damals[TM] übliche Verfahren per KK Antrag eine Domain von einen Provider zum anderen zu wechseln ist bei den meisten Domains (bspw. .de, .net, .com, und andere) auf das Auth-Code Verfahren umgestellt worden. Zur Verfahrensweise hat beispielsweise die Denic unter Providerwechsel mit AuthInfo in 2008 veröffentlicht. Hier wird vom bisherigen Hoster ein Authcode an den Seiteninhaber weiter gegeben und dieser Code kann dann beim Wechsel der Domain zu einen anderen Hoster angegeben werden. Alternativ besteht natürlich auch die Möglichkeit die Domains unabhängig vom Webspace zu halten und hier die entsprechenden IPs selbst zu pflegen.

Hinweis: Aktuelle Buchempfehlungen besonders SAP Fachbücher sind unter Buchempfehlungen inklusive ausführlicher Rezenssionen und Bestellmöglichkeit zu finden.
Diesen und weitere Texte von Andreas Unkelbach finden Sie auf http://www.andreas-unkelbach.de


Sonntag, 17. März 2013
20:27 Uhr

Ghostery Addon und Dokuwiki

Das Browseraddon Ghostery weist beim Besuch von Seiten auf versteckte Hinweise (bspw. Trackingcookies) hin die möglicherweise private Daten am Seitenbetreiber übermitteln und diese auf Wunsch blockieren. Das Programm ist als Erweiterung für die Webbrowser Firefox, Safari, Chrome, Opera und Internet Explorer verfügbar sowie als eigenständige Webbrowser-App für das iOS.

Leider hat dieses Addon unter den Einstellungen bspw. durch Aufruf der URL

chrome://ghostery/content/options.html

unter Advanced die Option Nach Umleitung von bekannten Trackern suchen und diese verhindern (preventRedirect) standardmäßig aktiviert. Diese unterbindet leider auch eine Weiterleitung über die PHP Funktion
header welche in Dokuwiki in der index.php eingesetzt wird.

Eine einfache Lösung könnte entweder sein, diese Option beim Addon zu unterbinden oder die Besucher auf diesen Umstand hinzuweisen. Entsprechend kann es sinnvoll sein hier die Datei index.php um einen entsprechenden Hinweis zu ergänzen.

Bspw. könnte die Datei index.php wie folgt ergänzt werden:

?>
<html><head><title>ghostery und dokuwiki</title><h1>Dokuwiki & Ghostery</h1>
<p>Sofern Sie das Browser-Addon Ghostery einsetzen kann es sein, dass Sie nach der Anmeldung oder beim Aufrufen des Wiki eine leere Seite angezeigt bekommen bzw. auf diese Seite gelandet sind.</p>
<p>Um dennoch auf das Wiki zuzugreifen können Sie direkt <a href=doku.php>doku.php</a> um das Wiki aufzurufen.</p>
<p>Ursache hierfür ist, dass Ghostery diverse Weiterleitungen über Leistungsoptionen unter den Punkt "Nach Umleitung von bekannten Trackern suchen und diese verhindern" in den Einstellungen unterbindet.<br/>
Sie finden diese Option unter den Einstellunegen nach Aufruf der URL chrome:ghostery/content/options.html im Reiter Advanced. Sie könenn nun entweder diese Option deaktivieren oder das Wiki direkt über <a href=doku.php >doku.php</a> aufrufen.</p>
</body></html>

Hinweis: Aktuelle Buchempfehlungen besonders SAP Fachbücher sind unter Buchempfehlungen inklusive ausführlicher Rezenssionen und Bestellmöglichkeit zu finden.
Diesen und weitere Texte von Andreas Unkelbach finden Sie auf http://www.andreas-unkelbach.de


Donnerstag, 7. März 2013
20:59 Uhr

Upgrade auf dokuwiki Release 2013-03-06

Dokuwiki hat den neuen Release Candidate "Weatherwax" veröffentlicht und hier einige Änderungen an JQuery vorgenommen. Hierbei sind nicht mehr aktuelle JavaScript Elemente aus der Datei lib//exe//js.php entfernt. Siehe hierzu auch der Hinweis unter 99421189 auf github.com.

Insgesamt hatte ich hier tatsächlich die Befürchtung, dass ein Addon wie bspw. indexmenue nicht mehr funktionieren würde. Hier wurde aber eine angepasste Version veröffentlicht, die nun nicht mehr die veralteten Syntaxe verwendet sondern auch mit der aktuellen JQuery Version funktioniert. Für Plugin Entwickler wurde unter jqueryfaq die häufigst verwendeten veralteten Funktionen erläutert und auch gleich eine
Alternative angeboten.

Insgesamt ist dieses schon sehr gut dokumentiert, so dass ich mich dann auch für das Update auf Release 2013-03-06 "Weatherwax RC1" entschieden habe.

Nachdem alle Plugins auf etwaige aktuellere Versionen überprüft (und ggf. mit einen Update versehen) worden sind machte ich mich an eine Datensicherung des dokuwiki Verzeichnis und überlegte mir schon einmal, wie ein Update wohl verlustfrei vonstatten gehen könnte.

Eigentlich hatte ich erwartet, dass hier einfach alle Dateien ersetzt werden müssen und ich nicht mehr genutzte Dateien manuell löschen müßte.

Allerdings bietet Dokuwiki auch für ein Upgrade ein geniales Plugin. Über das Plugin Upgrade werden die Schreibrechte kontrolliert, die notwendigen Systemdateien selbstständig herunter geladen und die einzelnen Dateien ersetzt. Insgesamt war das Upgrade innerhalb kürzester Zeit durchgeführt, so dass nun auch die aktuellste Version von Dokuwiki am Laufen ist. Das Schöne an den RC Kandidaten von dokuwiki ist, dass diese auch tatsächlich für den Produktivbetrieb gedacht sind und hier ohne Probleme funktionieren.

Weitere Erfahrungen
Weitere Erfahrungen im Umgang mit Dokuwiki sind unter den Tag dokuwiki zu finden.

Hinweis: Aktuelle Buchempfehlungen besonders SAP Fachbücher sind unter Buchempfehlungen inklusive ausführlicher Rezenssionen und Bestellmöglichkeit zu finden.
Diesen und weitere Texte von Andreas Unkelbach finden Sie auf http://www.andreas-unkelbach.de


Freitag, 4. Januar 2013
18:45 Uhr

Erste Erfahrungen mit Dokuwiki: Vorteile von Wiki und Internetseite im Indexmenu vereinen

Ausgangslage
Innerhalb des Template monobook (aber auch in andere Templates) besteht die Möglichkeit eine Navigationsleiste im Wiki auf der linken Seite einzubauen. Hier bietet es sich an, bspw. über das Plugin indexmenue ein entsprechendes Indexmenü auf Basis der Berechtigungen der User auszugeben. Auf diese Weise werden nur die Seiten oder Namensräume ausgegeben, für die auch tatsächlich eine Leseberechtigung vorhanden ist.

Dieses hat sicherlich Vorteile verwandelt allerdings das Wiki eher in eine Form einer Internetseite, da alle Unterseiten und Ordner (Namensräume) mit ausgegeben werden.

Problem
Das Wiki soll innerhalb der einzelnen Namensräume die Vorzüge einer Internetseite (freier Zugang, leichte Bedienung und Bearbeitung) mit den Vorteilen eines Wiki zum freien Informationsaustausch vereinen. Die Namensräume sind hierbei als Themenfelder gedacht innerhalb deren sich die Teilnehmenden dann frei austauschen können und auch entsprechende Unterseiten innerhalb des Namensraumes anlegen können.

Auf diese Weise sollte bspw. im Bereich des Finanzwesen auch Begriffe wie Budget oder vergleichbares eingehend erläutert werden, ohne dass hierbei in der Navigation direkt diese einzelnen Unterseiten mit ausgegeben werden.

Lösungsansatz
Eine mögliche (ideale) Lösung wäre es nun, wenn in der Navigation nur die Namensräume als Navigationspunkte angezeigt werden und nur auf einer spezielen Seite das vollständige Inhaltsverzeichnis ausgegeben wird.

Lösung
Diese Lösung kann in drei Schritten erfolgen:

1.) Festlegung der Indexseite (Gesamtindex)
Innerhalb der "Indexmenu Plugin-Konfiguration" kann über die Funktion "plugin»indexmenu»page_index" festgelegt werden, welche Seite im Wiki den eigentlichen Dokuwiki Index ersetzen soll. Diese Seite bspw. wiki:inhaltsverzeichnis wird zukünftig das komplette Inhaltsverzeichnis des Wiki enthalten.

2.) Festlegung der Navigationsleiste im Template
Innerhalb der Templatekonfiguration von monobokk können zwei Punkte eingestellt werden:
a) tpl»monobook»monobook_navigation
Hierdurch wird im Template die Navigationsleiste aktiviert.
b) tpl»monobook»monobook_navigation_location
Hierdurch kann eine Wiki-Seite als Navigationsleiste definiert werden. Diese Seite kann bspw. wiki:navigation lauten.

3.) Inhalt der beiden Seiten festlegen

Als Inhalt kann folgender Wikicode auf die einzelnen Seiten zur Einbindung des Indexmenü eingetragen werden.
a) Die Navigationsleiste
{{indexmenu> ..|js navbar nocookie id#random nopg}}
Durch die Option nopg wird hier durch indexmenu nur die Namensräume als Navigation angezeigt. So kann durch einen Klick auf einen Ordner die Startseite des Namensraums aufgerufen werden und von dort aus innerhalb des Wiki und des Themengebietes durch die Seiten geklickt werden, oder auch bestimmte Begriffe durch Anlage eines Links (bspw. über [[Budget]] erläutert werden, ohne dass die Seite Budget nun ebenfalls in der Navigationsleiste erscheint.
Ergebnis:


b) das Inhaltsverzeichnis
In der Seite wiki:inhaltsverzeichns (oder wiki:index) kann nun durch folgenden Code das komplette Inhaltsverzeichnis ausgegeben werden.
{{indexmenu> ..|js navbar nocookie id#random }}
Hier wird nun das gesamte Inhaltverzeichnis inklusive aller Unterseiten aufgerufen werden.
Diese Seite kann innerhalb des Wiki über
doku.php?id=start&do=index aufgerufen werden. Dieser Link ist auch in der entsprechenden Werkzeugleiste verfügbar.
Ergebnis:



Weitere Erfahrungen
Weitere Erfahrungen im Umgang mit Dokuwiki sind unter den Tag dokuwiki zu finden.

Hinweis: Aktuelle Buchempfehlungen besonders SAP Fachbücher sind unter Buchempfehlungen inklusive ausführlicher Rezenssionen und Bestellmöglichkeit zu finden.
Diesen und weitere Texte von Andreas Unkelbach finden Sie auf http://www.andreas-unkelbach.de


Samstag, 8. Dezember 2012
17:47 Uhr

Erste Erfahrungen mit Dokuwiki noch mehr Anpassungen :-)

Während der Nutzung von Dokuwiki hat sich dann doch ergeben, dass manche Addons hinzugekommen sind.

hiddenswitch
Der Nachteil des unter Erste Erfahrungen mit Dokuwiki Plugins (Syntax + Admin) vorgestellten Plugins hidden ist, dass in der Druckversion natürlich auch alle Elemente ausgeblendet sind. Hier hilft das Plugin hiddenswitch sinnvoll. Wichtig ist hierbei jedoch, dass das Plugin hidden ebenso wie dieses Plugin wie folgt angepasst werden muss (siehe auch discussion auf hiddenSwitch Plugin.


fckglite und Tabellen
FCKglite ist insbesondere beim Einfügen von Tabellen unheimlich hilfreich als WYSIWYG Editor. Wobei sich hier auch Complex Tables Upgrade (Version 07) unheimlich sinnvoll.

sortable
Wo wir gerade bei Tabellen sind. Das Plugin sortablejs ermöglicht es Tabellenspalten zu sortieren. Gerade bei Kontaktdaten und andere sortierbare Elemente ist dieses sehr hilfreich.
Über <sortable> vor und </sortable> nach der Tabelle ist es möglich die Tabellen entsprechend zu sortieren.

Confmanager
Sollen im Wiki auch mit Abkürzungen, Interwikilinks und andere Einstellungen gearbeitet werden muss in der Regel eine configdatei angepasst und hochgeladen werden. Das Addon confmanager bietet die Möglichkeit diese direkt im Adminmenue zu editieren, was sowohl bei erlaubten Dateitypen als auch interwikilinks unheimlich praktisch ist.


Kleiner Bug in fckglite Editor
Dieses Plugin hat sich für mich als sehr praktisch erwiesen, da fckglite leider bei Interwikilinks, sofern hier mehrere Variablen in der Interwiki-URL übergeben werden, diese Variable mehrfach überschreibt.

Beispiel:
Um einen Blogartikel von mir aufzurfen würde /index.php?go=show&id={URL}
aufgerufen werden. Entsprechend ist auch im DokuWiki Editor dieser Interwikilink definiert. Wird nun im FCKGlite Editor der Text erneut gespeichert werden alle Variablen nach ? auch wieder als {URL} angefügt.

Ein kleiner Workaround ist, dass hier der Interwikilink analog zu wp defineirt wird und dann als Verweis alle Variablen übergeben werden.

Beispiel:
[blog>?go=show&id=374]
Dieses funktioniert dafür unproblematisch.

Hintergrund ist, dass FCKGLITE Interwikilinks direkt auflöst und die volle URL hinterlegt.

Weitere Erfahrungen
Weitere Erfahrungen im Umgang mit Dokuwiki sind unter den Tag dokuwiki zu finden.

Hinweis: Aktuelle Buchempfehlungen besonders SAP Fachbücher sind unter Buchempfehlungen inklusive ausführlicher Rezenssionen und Bestellmöglichkeit zu finden.
Diesen und weitere Texte von Andreas Unkelbach finden Sie auf http://www.andreas-unkelbach.de


Samstag, 1. Dezember 2012
14:14 Uhr

Erste Erfahrungen mit Dokuwiki Konzept + Herangehensweise (Grundlagen)

Grundüberlegung eines Wiki sind sicherlich mehrere Punkte. Persönlich bin ich hier selbst noch ein wenig in der Testphase habe aber folgende Grundüberlegungen für mich als sinnvoll erachtet.

1.) Warum ein Wiki?
Ausgangslage ist für mich eine Sammlung von Informationen die über ein Sammlung von unterschiedlichen Dokumenten hinaus geht. Im Laufe der Zeit haben sich eine Unzahl von Dokumenten angelgt die vielleicht auch in ein DMS gut aufgehoben sein könnten aber doch so umfangreich sind, dass sie nur schwer durchsuchbar geschweige denn geordnet sind.
Daher hatte ich mir vor einiger Zeit Scribble Papers im Einsatz (siehe Blogbeiträge oder die Beschreibung unter Tools).
Hier können einige Texte in Ordnern festgehalten werden und es ist eine relativ einfache Struktur möglich. Der Nachteil einer solchen Software ist jedoch, dass diese a) nur von einer Person genutzt werden kann (alternativ wäre eine Speicherung auf ein Netzlaufwerk) und b) eine Extrasoftware benötigt. Ein Wikisystem hat hierbei den Vorteil, dass es zum einen von mehreren Personen genutzt werden kann und zum anderen direkt im Netz lauffähig ist.

2.) Grundüberlegungen zur Struktur
Gerade bei geschlossenen Wikis sollte sich besonders Gedanken um die Struktur gemacht werden. Hier sind zum einen die Frage der Berechtigung auf einzelne Namensräume notwendig als auch (gerade bei mehreren Schreibenden) eine grundsätzliche Überlegung zum darzustellenden Inhalt.

Für mich hat sich folgende Struktur von Namensräumen als hilfreich ergeben:
  • About(Allgemeine Infos zum Wiki)
  • Handbuch (Wie funktioniert das Wiki)
  • FachlichesHier sollen alle inhaltliche Fragen zum Thema des Wiki besprochen und beschrieben werden. Diese sind in zwei Bereiche aufgeteilt:
    • Individueller Bereich (Hier können Informationen zu verschiedenen Bereichen hinterlegt werden, diese sind dann auch identisch zu den Benutzergruppen)
    • Verbindender Bereich (Ein Bereich der für alle Gruppen von Interesse ist, sei es durch rechtliche Vorgaben oder gemeinsam bearbeiteten Themen).
  • Technischik / Anwendung (Ein Bereich in der bestimmte Software dokumentiert wird, welche zwar von allen genutzt wird, jedoch mit den Schwerpunkt auf Technik und Anwendung. Hier können z.B. Berichtstool vorgestellt werden oder gemeinsam an einer technischen Dokumentation gerabeitet werden).


3. Erste Schritte
Gerade das unter 2. erwähnte Handbuch hat für mich den Vorteil, dass hier sicher selbst mit der Technik eines Wiki vertraut gemacht werden kann und durch eine Dokumentation der Struktur des Wiki aber auch Erläuterung, wei Artikel erfast werden, zeigen sich oftmals schon im Vorfeld Verbesserungspotentiale und Ideen, wie sich das Wiki fortentwickeln kann. Danach kann es hilfreich sein schon einmal die ersten Seiten zu verschiedene Themen anzufangen, so dass diese dann erweitert werden können. Hier ist sicherlich am Anfang auch die größte Gefahr, dass am Ende nur eine Person Artikel schreibt oder das die Richtung des Wiki sehr stark von einer Person geprägt wird.
Ideal ist es, wenn anhand eines Thema schon Seiten aufgebaut werden können die später ohnehin in eine gemeinsame Dokumenntation oder Schulungsunterlagen münden werden.

4. Motivation & Fortbestand
Als besondere Gefahr ist sicherlich, dass bei aller Technikverliebtheit irgendwann der Inhalt liegen bleibt. Daher sollte sich schon vorab darum Gedanken gemacht werden, welchen Vorteil andere von diesen Wiki haben und warum diese ggf. ihre Zeit dafür gebrauchen sollten an bestehenden Texten mit zu schreiben. Hilfreich kann hier ein gemeinsames Thema sein, welches alle Beteiligten beschäftigt und fasziniert. :-)

5. Abgrenzung Wiki & Blog
Auch innerhalb eines Blogsystems kann von mehreren Personen an Artikel gearbeitet werden. Diese haben jedoch den Nachteil, dass sie nur schwer unterinander verknüpft sind und Teilaspekte nicht, so erforderlich, näher ausgeschmückt werden können.

Theoretisch ist ein Wiki (in meinen Verständnis) eine aktiveres Instrument als ein Blog, welches zu einen besseren Austausch und tiefere Bearbeitung eines Thema führen kann.

Weitere Erfahrungen
Weitere Erfahrungen im Umgang mit Dokuwiki sind unter den Tag Dokuwiki zu finden. Wobei ich künftig dieses Thema eher in der Kategorie "Internet" einsortieren werde.

Hinweis: Aktuelle Buchempfehlungen besonders SAP Fachbücher sind unter Buchempfehlungen inklusive ausführlicher Rezenssionen und Bestellmöglichkeit zu finden.
Diesen und weitere Texte von Andreas Unkelbach finden Sie auf http://www.andreas-unkelbach.de


Samstag, 1. Dezember 2012
13:37 Uhr

Erste Erfahrungen mit Dokuwiki Plugins (Syntax + Admin)

Neben der Oberfläche ist es auch möglich den Wikisyntax um einige weitere Funktionen zu erweitern.

Hierzu nutze ich folgende Plugins:

Erweiterung des Syntax

hidden
Über das Plugin hidden können. Hierdurch können über die Anweisung hidden Textbestandteile über CSS ausgeblendet werden, so dass diese in einr Seite erst nach Klick eingeblendet werden.

numbersheadings
Über das Plugin numberedheadings werden als Überschriften formatierte Bestandteile sofern vorangestellt ein - erscheint passend durchnummeriert auf diese Weise muss man sich nicht mehr merken, auf welcher Ebene eines Inhaltsverzeichnises man zur Zeit innerhalb einer Seite ist. Das Plugin setzt automatisch 1.1.2. etc. Hierbei sollte innerhalb der Einstellungen des Plugins das Startlevel auf 1 gesetzt werden, wenn die erste Ebene auch als Überschrift 1 formatiert werden soll.

wrap
Das Plugin wrap ist eine ganze Sammlung von nützlichen Formatierungen. Hier können Texte in containern gesetzt werden und als Infoboxes oder diverse andere Formatierungen gesetzt werden. Über examples kann sich ein Eindruck über vorhandene Möglichkeiten gemacht werden.

socialshareprivacy
Vergleichbar zum Blog kann auch in Dokuwiki das Projekt "2 Klick für mehr Datenschutz" der ct genutzt werden. Hierbei kann über das Plugin socialshareprivacy über {{socialshareprivacy}} die Weiterempfehlung eingestellt werden.
Besonders schön gelöst ist, dass die einzelnen Infofelder in der Konfiguration des Plugins manuell gesetzt werden können, so dass hier keine Probleme mit etwaigen Zeilenumbrüche entstehen.

Hierzu können geschützte Leerzeichen verwendet werden. Die Einstellungen der Texte sind hierbei wie folgt angepasst:
global_txt_help MouseOver-Text des i-Icons

facebook_txt_info MouseOver-Text des Facebook Empfehlen-Buttons

twitter_txt_info MouseOver-Text des Twitter-Buttons

gplus_txt_info MouseOver-Text des GooglePlus Empfehlen-Buttons


Hilfreiches für die Administration des Wiki

langdelete
Die meisten Plugins sind für mehrere Sprachen ausgelegt. Das Plugin langdelete löscht alle nicht notwendigen sprachdefinitionen durch Eingabe des ISO-Codes der Sprachen, welche ausser Englisch behalten werden soll. Auf diese Weise werden im Pluginordner einige eigentlich nicht erforderliche sprachdateien gelöscht. Dieses ist besonders dann sinnvoll, wenn das Wiki einsprachig betrieben werden soll.

cacherevisionseraser
Das Plugin Cache and Revisions Eraser ermöglicht das Löschen des Cache der Wikiseiten als auch alte Versionen von einzelnen Seiten.
Innerhalb des Cache sind die Wikisyntaxeingaben schon umgewandelt, so dass die Seite direkt (ohne erneutes generieren) ausgeliefert wird.

Weitere Erfahrungen
Weitere Erfahrungen im Umgang mit Dokuwiki sind unter den Tag dokuwiki zu finden.

Hinweis: Aktuelle Buchempfehlungen besonders SAP Fachbücher sind unter Buchempfehlungen inklusive ausführlicher Rezenssionen und Bestellmöglichkeit zu finden.
Diesen und weitere Texte von Andreas Unkelbach finden Sie auf http://www.andreas-unkelbach.de


Samstag, 1. Dezember 2012
12:36 Uhr

Erste Erfahrungen mit Dokuwiki Plugins (Oberfläche)

Plugins
Da die Nutzung des Wiki so einfach wie möglich sein soll (auch um die Motivation in der Hauptsache fürs Schreiben aufzubringen) kann Dokuwiki um einige Plugins erweitert werden.

Im Folgenden möchte ich die von mir eingesetzten Plugins vorstellen verbunden mit ein paar Anmerkungen, die mir das Einrichten und Verwenden einfacher gemacht haben.

Folgende Plugins möchte ich hier näher beschreiben:

Oberflächenanpassung
1. fckglite - WYSIWYG Editor
2. addnewpage - einfaches hinzufügen von Seiten
3. editx - Verschieben von Seiten
4. indexmenu - dynamisches Inhaltsverzeichnis



1. fckglite
Das Plugin fckglite ersetzt den Standardeditor durch eine WYSIWYG Oberfläche, die gerade das Einfügen von Tabellen aber auch Bilder oder Dateien um einiges erleichtert.

Update:
Im Artikel "Dokuwiki Plugin CKGEdit und Hochladen von PDF, Excel oder andere Medien" bin ich auch etwas tiefer auf den Nachfolger CKGEDIT eingegangen. Es ist auch aus Sicherheitsgründen empfehlenswert das aktuelle Plugin CKGEDIT zu installieren.
Sofern man jedoch fckglite nicht auf einen eigenen Server einsetzt auf den symbolische Links möglich sind gibt es Probleme beim Datei hochladen. Ursache ist ein symbolischer Link im Ordner /lib/plugins/fckg/fckeditor/userfiles auf die eigentlichen Mediadateien des Wiki.

Sofern dieses nicht funktioniert kommt es beim Versuch Dateien hochzuladen zu folgender Fehlermeldung:

Error creating folder "wikpfad/lib/plugins/fckg/fckeditor/userfiles/image/" (File exists)

Wird das Wiki auf einen eigenen Server mit Shellzugriff (egal ob Windows oder Unix) eingesetzt können symbolische Links wie unter fckglite troubleshooting beschrieben gesetzt werden.

Sofern die Konfiguration über diese Links nicht funktioniert gibt es zwei Möglichkeiten.

a) Löschen der Dateien file, flash, image, media im userfiles Ordner.
Dieses hat den Nachteil, dass alle Bilder und Medien innerhalb des Pluginordners hochgeladen werden. Somit wären aber nicht mehr Inhalt und Technik voneinander getrennt.
b) Konfiguration der absoluten und relativen Pfade
Hierzu muss die Datei
config.php
im Ordner
lib/plugins/fckg/fckeditor/editor/filemanager/connectors/php

bearbeitet werden.

Dabei muss die Variable:

$Config['UserFilesAbsolutePath']
(etwa Zeile 110)
auf das absoluten Serververzeichnis für die Mediafiles des Wiki gesetzt werden
Beispiel:
$Config['UserFilesAbsolutePath'] = '/var/www/htdocs/dokuwiki/data/media/';

$Config['UserFilesPath']
(etwa Zeile 120)
auf den realtiven Pfad
Beispiel:
$Config['UserFilesPath'] = '/dokuwiki/data/media/';

Um den absoluten Pfad des Servers zu erhalten ist eine phpinfo Anweisung hilfreich, da diese auch den absoluten Pfad der Installation ausgibt (neben anderen Informationen).

Nähere Info hierzu sind auf schattenbaum.net/php/anfang.php zu erfahren.

Alternativ kann dieser auch über die PHP Anweisung echo $_SERVER['DOCUMENT_ROOT']; ermittelt werden.

Wichtig
Um diese Variante zu verwenden, sollten die Optionen

nix_style
und
no_symlinks

in der Konfiguratiion aktiviert werden.


Da die Verwaltung von Mediadateien nur über fckglite erfolgen soll, ist es sinnvoll über die Einstellung "disableactions" den Mediamanager unter den Feld andere Aktionen mit media zu deaktivieren. Nähere Informationen zum deaktiveren von Funktionen sind auf dokuwiki beschrieben.


2. Addnewpage
Zur Ergänzung des Wikisyntax zum Anlegen von neuen Seiten nutze ich das Plugin addnewpage. Dieses blende ich als seitenübergreifenden Hinweis innerhalb des monobook Template ein (siehe Einstellungen monobook_sitenotice innerhalb der "Monobook Template-Konfiguration".

Durch {{NEWPAGE}} können Redakteure direkt Seiten in passenden Verzeichnisen (Namensräumen) angelegt werden.
Dieses ist ganz praktisch, wenn diese nicht direkt verlinkt werden sollen.
Innerhalb der Konfiguration können bestimmte Namensräume ausgenommen werden, so dass diese nicht in der Auswahlliste erscheinen.


3. Editx
Durch das Plugin editx besteht die Möglichkeit Seiten zu verschieben (inklusive einer Weiterleitung von der bisherigen Seite). Dieses erleichtert besonders das Verschieben von Seiten von einen Namensraum in einen anderen.


4. Indexmenu
Das Plugin Indexmenu ermöglicht es ein dynamisches Indexmenu (mit aufklappbaren Ordnern etc. anzulegen. Über die Einstellungen "skip_index" sollten dabei Namensbereiche ausgenommen werden, die dann nicht im Index erscheinen.

Dieses ist bspw. der Fall für Diskussionsseiten deren Namensraum im Template monobook unter "monobook_discuss" festgelegt sind.
Ferner ist es sinnvoll das Standardindexverzeichnis (?do=index) durch eine Seite mit eingebundenen Indexmenu zu ersetzen. Dieses ist innerhalb der indexmenu Konfiguration unter page_index möglich. Auf dieser Seite kann dann bspw. wie vorgeschlagen über: "{{indexmenu>..|js navbar nocookie id#random}}" ein entsprechendes Indexmenu eingeblendet werden.

Hierbei berücksichtigt indexmenu die Berechtigungen (ACL) so dass keine Seite aufgenommen wird, für die die Berechtigungen fehlt. Problematisch ist, dass der erste Ordner eines Namensraums ausgegeben wird für den keine Berechtigungen vorhanden ist. Dieses kann jedoch innerhalb dokuwiki unter der Option "sneaky_index" deaktiviert werden.


Weitere Erfahrungen
Weitere Erfahrungen im Umgang mit Dokuwiki sind unter den Tag dokuwiki zu finden.

Hinweis: Aktuelle Buchempfehlungen besonders SAP Fachbücher sind unter Buchempfehlungen inklusive ausführlicher Rezenssionen und Bestellmöglichkeit zu finden.
Diesen und weitere Texte von Andreas Unkelbach finden Sie auf http://www.andreas-unkelbach.de


Samstag, 1. Dezember 2012
11:49 Uhr

Erste Erfahrungen mit DokuWiki als Wiki (Installation)

Ausgangslage:

Seit einiger Zeit überlege ich zur Dokumentation und für eine Zusammenarbeit ein Wikisystem aufzusetzen. Nach einiger Recherche (u.a. auf Wikimatrix) habe ich mich für Dokuwiki entschieden, welches als Dokumentationssoftware für Projekte einen sehr stabilen Eindruck machte und auch in der Einführung unproblematisch ist. Im Gegensatz zu anderen Wikisystemen erfolgt hier die Seitenspeicherung direkt in Textdateien und nicht in einer Datenbank, was auch für Datensicherungen einen gewissen Vorteil hat.

Wesentliche Punkte die für eine Nutzung von Dokuwiki sprachen waren für mich:
  • einfache Installation
  • basierend auf PHP
  • Rechtemanagement basierend auf User & Gruppen
  • Erweiterbarkeit durch Plugins & Templates

Installation
Die Installation und auch Dokumentation ist sehr ausführlich und gut auf dokuwiki.org beschrieben. In diesen Artikel möchte ich nur die Erweiterungen und Einstellungen festhalten, die für mich nützlich waren. Nachdem die Dateien auf den Server hochgeladen worden kann in einen kurzen Installationsdialog kann auch direkt mit der Einrichtung des Wiki begonnen werden.

Im ersten Schritt werden Name des Wiki, Superuserkonto (Admin) und Art des Wiki (offen für alle, lesen für alle schreiben für registrierte, geschlossen) gewählt. Gerade für geschlossene Arbeitsgruppen bietet sich letztere Option an. Später kann über Berechtigungen für jeden Bereich des Wiki basierend auf User oder Gruppenzuordnung einzelne Rechte vergeben werden.

Wenn das Wiki installiert ist kann es natürlich auch erweitert werden.

Template
Als Template nutze ich Monobook welches Mediawiki (bzw. Wikipedia bis 2010) erinnert. Es bietet für mich die Vorteile, dass hier sowohl Seiten für Benutzer (userpages) angeboten werden, als auch die Möglichkeit einer Diskussionsseite für die einzelnen Seiten des Wiki. Ferner können Bestandteile wie Navigationsfenster über eigene Seiten innerhalb des Wiki gestaltet werden.

Templates werden im Ordner /lib/TPL des Wiki gespeichert und können in der Administation innerhalb der Konfiguration beim Punkt template (Designvorlage) ausgewählt werden.

Im Unterordner User kann das Template individuell angepasst werden, so dass bspw. die CSS Definition zur Ausrichtung der Navigationsbox angepasst werden kann (siehe Hacks for /user/screen.css).

Weitere Erfahrungen
Weitere Erfahrungen im Umgang mit Dokuwiki sind unter den Tag dokuwiki zu finden.

Hinweis: Aktuelle Buchempfehlungen besonders SAP Fachbücher sind unter Buchempfehlungen inklusive ausführlicher Rezenssionen und Bestellmöglichkeit zu finden.
Diesen und weitere Texte von Andreas Unkelbach finden Sie auf http://www.andreas-unkelbach.de


Hinauf




Werbung


© 2004 - 2017 Andreas Unkelbach
Andreas Unkelbach

Stichwortverzeichnis
(Tagcloud)


Aktuelle Infos (Abo)

Facebook Twitter Google+

»Schnelleinstieg ins SAP Controlling (CO)« und »Berichtswesen im SAP ® ERP Controlling«
Privates

Kaffeekasse 📖 Wunschliste