Das CalitrixWiki - mein aktuelles Projekt

Wie gross die Datenbank wird hängt vorallem von zwei Faktoren ab: wie lang die Seiten durchschnittlich werden und wie oft sie bearbeitet werden da die Texte und Changelogs den meisten Platz verbrauchen.
Ich hab noch keine grossen Tests gemacht was den Speicherverbrauch angeht. Im Moment ist die Datenbank des Testwikis 99.7 kb gross. Das beinhaltet 20 Seiten a 1000 Zeichen inklusive Volltext-Index und 168 Einträge im Changelog inkl. Diffs.

Wenn da Interesse besteht könnte ich mal einen Speichertest machen.

Das hört sich relativ wenig an. Danke dir.
Dann warte ich mal auf's erste Release und werd's mal antesten. Aber da scheint wirklich gut zu sein.

Das Ganze hat sich jetzt ein bisschen verzögert da mir zwischendurch mein Linux Probleme gemacht hat und ich erst 5 Distributionen testen musste bis ich wieder ein funktionierendes System hatte

Jetzt bin ich aber wieder soweit und möchte gleich mal eine aktuelle Demo vorstellen:
http://demo.calitrix.de/cwiki

Neu ist

• ein überarbeitetes Layout das irgendwann auch mal XHTML 1.0 und CSS2 valid sein soll
• Benutzerverwaltung
  • Lesezeichen
  • Benachrichtigung bei Änderungen
  • Auswahl von Themes und Sprachen
• Namespaces um verschiedene Kategorien von Seiten (Mitglieder, Spezialseiten etc.) zu trennen. Wird ausserdem in einer späteren Version für Unterstützung mehrsprachiger Wikis verwendet.
• Möglichkeit Zugriffsrechte für Seiten festzulegen (lesen, schreiben, wiederherstellen, sperren, entsperren etc.)
• Viele kleine Verbesserungen

Ich arbeite jetzt noch an ein paar kleinen Verbesserungen und Bugfixes und dann gibts heute oder morgen vielleicht (hoffentlich) schon ein Beta-Release.

Sieht gut aus, hört sich gut an, ist gut.

Also ich bin schon sehr gespannt auf das Release. Obwohl ich jetzt schon ahne, dass ich mich erstmal ewiglang einarbeiten werden muss. *g*

Lass dir Zeit & mach's ordentlich.

Und für die Promotion brauchen wir hier noch einige Menschen:
http://demo.calitrix.de/cwiki/cwiki.php?page=Googlehack

Mach doch einen WYSIWYG-Editor dafür

Ich habe nun eine erste Beta zusammengepackt und veröffentlicht. Diese enthält auf Benutzerseite praktisch alle Funktionen die für die erste Version eingeplant sind sowie einen ersten Installer.

Bis zur Final ist damit im Großen und Ganzen nur noch der Administrationsbereich (und natürlich Bugfixes und kleine Verbesserungen) eingeplant.

Die Website des Wikis findet sich nun auf http://www.calitrix.de
Informationen zum Download auf http://www.calitrix.de/Download
Eine Dokumentation habe ich heute auf http://www.calitrix.de/Dokumentation begonnen.

Das bei error_reporting(E_ALL) die Diff-Ansicht in der History eine Notice auswirft ist mir bereits aufgefallen, ist dann in der nächsten Version gefixt.

Bin gerade beim Testen und wollte meine Benutzereinstellungen ändern, was Calitrix leider mit folgender Fehlermeldung ablehnt: Der Zugriff auf diese Funktion ist ihnen nicht erlaubt. Möglicherweise müssen sie sich dafür erst registrieren oder diese Funktion ist einer höheren Benutzergruppe vorenthalten.

In deiner Demoversion konnte ich die Einstellungen aber ohne Probleme ändern...

Komisch, ich bekomme beim ändern:

Hallo,

ich habe mir aus Interesse die Beta 1 eben mal lokal auf meinem Computer (PHP 5, MySQL 4.0; XAMPP Installisation) installiert und musste mit einigen Fehlern jetzt leben.

1. Bei der Installisation habe ich mir die Datenbank erstellen lassen. Keine Sorge, alles geht. Aber warum erhalte ich die Meldung "Versuche die Datenbank auszuwählen ...Fehlgeschlagen" wenn später auf den folgenden Seiten und im Betrieb alles funktioniert?

2. Ich habe auf jeder Seite eine Menge Fehler (mehrfach) folgender Spate:
2048: var: Deprecated. Please use the public/private/protected modifiers
2048: Assigning the return value of new by reference is deprecated
Zudem kommen manchmal header Fehlermeldungen ("2: Cannot modify header information - headers already sent by (output started at C:\webseiten\xampp\htdocs\CaltrixWiki Beta 1\libs\tpl\Smarty.class.php:455)")

3. Trotz der Auswahl von "Angemeldet bleiben?" bin ich wenn ich auf eine weitere Seite gehe nachdem ich erfolgreich eingeloggt war, abgemeldet.

Ich habe die Fehler nicht mit PHP 4 getestet, sondern wie o.g. nur mit PHP 5.0.0!

Ich schätze da liegt ein Problem mit Cookies vor so dass du dich zwar anmelden kannst aber bei jeder Folgeseite für registrierte Benutzer die "Zugriff verweigert"-Meldung bekommst.

Testest du auf einem localhost? Und welche Serverkonfiguration hast du? (PHP, Apache)
Werden Cookies akzeptiert?

Das kommt wenn du noch keine Datenbank erstellt hast und ausgewählt hast das das Script beim Fehlen der Datenbank eine Neue erstellen soll. Das Auswählen schlägt dann fehl, aber wenn die Datenbank danach erstellt werden kann ist trotzdem alles in Ordnung.

Das liegt daran das PHP5 mit error_reporting auf E_STRICT betrieben wird. In PHP5 ist das Schlüsselwort 'var' bei der Definition von Klassenvariablen veraltet da Schlüsselwörter wie 'public' oder 'protected' verwendet werden sollen. Wenn ich die aber verwende funktioniert das Script nicht mehr mit PHP4 da es dort nur 'var' gibt.
Einzige Lösung ist PHP5 mit der Fehlereinstellung E_ALL zu betreiben, dann fallen Meldungen zum Klassendesign weg.

Die 'headers already sent' Meldungen sollten dann auch wegfallen da vor der eigentlichen Ausgabe keine Fehlermeldungen mehr erscheinen.

Muss wieder ein Problem mit den Cookies sein, ich schau mir das nochmal an.

Hallo,

meine Punkte, zu 1:
In Ordnung.

zu 2:
Mir brauchst du das nicht zu erklären, ich programmiere selber unter PHP 5. Aber um von anderen User solche Probleme abzufangen, nutze doch folgendes Codeschnipsel:
zu 3:
Sonstige Skripts lokal funktionieren bei mir auch mit Cookies.

Laut PHP-Manual gibt es E_STRICT erst ab PHP5 und echo E_STRICT; ergibt auch nur

Warum also ein Workaround für PHP5 wenn diese Fehlerkonstante sowieso nicht benutzt werden kann solange das Script noch abwärtskompatibel sein muss?

Hallo,

du verstehst das Codeschnipsel wohl falsch. Ist die PHP Version unter PHP 5.0.0 (also auch PHP 4), wird nur E_ALL genutzt, E_STRICT zusätzlich erst ab PHP 5.0.0.

Es sei hierbei allerdings zu beachten, dass es E_STRICT schon in der Testphase von PHP 5 gab.

Aber da man E_STRICT nicht verwenden kann, solange ein in Klassen organisiertes Script in PHP5 ohne Notizen laufen soll, wird es hinfällig E_STRICT für PHP5 zu aktivieren.

Oder steh ich jetzt komplett auf dem Schlauch?

Eher umgekehrt. Da hast du wiederum recht, weil, wie du sagst, fehlt in der Classe das public, private und protected. Ja, aber welche Lösung gibt es dann? Sind wir wieder am Anfang.

Ich hab da ne Anmerkung zu.. PHP 5.0.1 wird bald erscheinen.. Dann greift dein Snippet nicht mehr, oder?

Mir fällt da auf Anhieb auch keine brauchbare Lösung ein - ausser PHP5 auf E_ALL zu stellen anstatt E_STRICT.

Hallo exe,

sieht interessant aus. Was ich ein bisschen Schade finde ist, dass du dich an der grässlichen Wiki-Syntax orientiert hast ('''''fett und kursiv''''' usw.), ich suche ja schon länger nach einem Wiki welches bspw. Textile zur Textformatierung benutzt.
Wie würdest du den Aufwand einschätzen Textile (oder allgemein eine alternative Textformatierung) in dein Wiki einzubauen?

Zu dem PHP5-Problem: Ich hab im BlackBoard Klassen drin, die unter PHP5 geklont werden müssen. Da PHP4 aber das clone keyword nicht kennt und seit der PHP5 final die _clone() Methode nicht mehr aufrufbar ist, hab ich den PHP5-Code mit dem clone drin in ein eval() reingesteckt. Sieht zwar dumm aus, macht aber nix und funzt unter PHP4+5. jm2c

Ehrlich gesagt war mein erster Versuch ein Wiki zu programmieren eines mit gewöhnlichen BB-Codes. Mir hat dann aber doch die Wiki-Syntax besser gefallen.

Wie hoch der Aufwand ist eine andere Formatierung einzubauen kann ich so nicht sagen. Prinzipiell dürfte es aber nicht allzu schwer sein den bisherigen Parser gegen einen anderen auszutauschen.

Wenn du eine eigene Syntax einbauen willst (beispielsweise BB-Codes) hängt das davon ab wie gut du dich mit regulären Ausdrücken auskennst um die Suchmuster im Parser zu ändern. Der Eine schreibt die Muster innerhalb eines Arbeitstages um, der Andere fummelt da eine Woche dran herum.

Ich habe schon eingeplant alternative Formatierungen zu unterstützen, da die Wiki-Syntax doch Geschmackssache ist. Aber das wird frühestens in Version 1.1 der Fall sein.

Wenn da entsprechendes Interesse besteht kann ich inoffiziell vielleicht auch davor einen Parser mit geänderter Syntax (BB-Codes, XML o.ä.) anbieten - wenn ich mal ein bisschen Zeit nebenher finde.

Ich bin mir nicht so sicher ob sich das auch mit dem var Problem so machen lässt und ich bin auch kein Freund solcher Workarounds, zumal dies ja nicht die Funktionalität des Wikis einschränkt sondern nur Hinweise auf nicht 100%ige PHP5-Programmierung sind. Aber mal sehen, vielleicht findet sich noch eine elegante Lösung.

Falls du Textile noch nicht kennst: http://www.textism.com/tools/textile/
Es ist eine PHP-Klasse, aber es gibt mittlerweile Implementation in Python, Perl, Ruby, usw.

Dean Allen hat es geschrieben und benutzt es in seinem Weblog/CMS-System Textpattern. Es gibt aber auch Plugins für MovableType, MoinMoin, bloxsom, punBB, pMachine, Wordpress, drupal, serendipity...

Ich habe aber bisher nur 2 Wikis gefunden mit denen man Textile nutzen konnte, eins ist MoinMoin (Python) und das andere war glaube ich ein in Ruby-geschriebenes, das ich aber nicht mehr wiederfinden konnte.

Es gibt definitiv eine Nachfrage nach in PHP implementierten Wikis die Textile benutzen. Es würden sich sicherlich einige Leute freuen, wenn du dich dazu entschliessen solltest, Textile einzubauen. Wär Klasse wenn du dir das bei Gelegenheit anschauen würdest...

Die Klasse ist hier im Download enthalten:
http://www.textpattern.com/deanload/ (GPL)

Hallo exe,
ersteinmal ein ganz dickes Lob an dich - das Wiki ist wirklich toll.
Was mir aber aufgefallen ist, dass die Suche anscheinend nicht funktioniert.
Ich gebe PHP ein, aber das Wiki meint, es gäbe keinen passenden Eintrag, obwohl es einen gibt.
Außerdem verstehe ich nicht so ganz wieso hinter manchen Wötern mit einem Edit-Formular verlinkte '?'s stehen? Was hat das für einen Zweck?
In der Druckansicht sollten hinter Links auch die Zieladressen selbiger angezeigt werden.


codethief

Danke, ich schau mir das mal an.

Das Wiki benutzt die MySQL Volltext-Indexe für die Suche und MySQL beschränkt die Suchwortlänge standardmäßig auf mindestens 4 Zeichen.

Der reguläre Ausdruck der nach WikiWords sucht ist ziemlich tolerant so das nicht nur reine WikiWords gefunden werden. Beispielsweise wird MySQL auch als WikiWord erkannt da nach dem beginnenden Grossbuchstaben auch noch weitere stehen dürfen, womit solch ein Begriff sich schon als "WikiWord" qualifiziert hat. Mehr darüber unter http://www.calitrix.de/WikiWord

Der Aufwand muss sich wohl in Grenzen halten. Ich hab mal einen modifizierten Parser erstellt der nur noch den wikispezifischen Kram (WikiWords, InterWiki, Plugins, Redirects, Variablen) übernimmt und für den Rest auf die Textile-Klasse zurückgreift.

Das Ganze ist nur ein experimenteller Hack, aber wer möchte kann das ja mal ausprobieren.

http://www.calitrix.de/download/textilewiki.zip runterladen und libs/class_parser.php im CalitrixWiki-Verzeichnis durch die class_parser.php aus dem Zip-Archiv ersetzen.

Der Nachteil daran ist nur das auf der Ergebnisseite der Suche Formatierungscodes nicht mehr aus den Ergebnissen entfernt werden da ich gerade nicht das Bedürfnis habe einen Parser zu schreiben der die Textile-Codes aus einem Text entfernt