staging.inyokaproject.org

Aktueller Status: Es gibt keinen (funktionsfähigen) Renderer für ein statisches Wiki.

Das ist auch der Grund warum sowas extrem umständlich händisch gemacht werden muss, was vom Kosten/Nutzen Aufwand her natürlich sehr überschaubar ist. Die Sache zu automatisieren wäre sinnvoll, aber so lange sich hier niemand ran setzt wird das halt auch nicht gemacht. 😉

mfg Stefan Betz

encbladexp schrieb:

Aktueller Status: Es gibt keinen (funktionsfähigen) Renderer für ein statisches Wiki.

Was ist eigentlich mit InyokaEdit, da ist doch ein Renderer drin oder nicht?

InyokaEdit verwendet nicht unseren Markup Parser, sondern was eigenes (AFAIK), dazu kommt das dieser nur für einzelne Artikel gedacht ist und wir ein grafisches Programm nicht als Cronjob nutzen können 😉

mfg Stefan Betz

Hallo zusammen,

encbladexp schrieb:

InyokaEdit verwendet nicht unseren Markup Parser, sondern was eigenes (AFAIK), [...]

Genau, ich habe den Parser von InyokaEdit per Reverse Engineering in C++ nachgebaut. Hinzu kommt noch, dass InyokaEdit zwar alle Wiki-Vorlagen parsen kann, aber die Inyoka-eigene "Template-Sprache" (noch) nicht komplett beherrscht (d.h.: Sobald ein Template geändert wird, muss ich den Quellcode des Editors auch anpassen. Das "richtig" zu Implementieren, steht schon lange auf meiner Liste..).

Um den derzeitigen Stand (soweit ich kenne), nochmal zusammen zu fassen:

1. Inyoka besitzt einen eingebauten Renderer zum statischen Html-Export. Implementiert in Python, aber derzeit defekt.

2. Man könnte InyokaEdit zu einem "Wiki-Reader" umbauen, der auf einen Datenbank-Export des Wikis zugreifen kann.

3. Ein Teammitglied mit viel Freizeit erstellt manuell einen Html Snapshot (sehr zeitaufwändig).

Für Möglichkeit 1.) und 3.) fehlen derzeit die Ressourcen. Bzgl. 1.) findet sich evtl. nach der Codefreigabe jemand, der das übernehmen kann. Möglichkeit 2.) war schon mal angedacht, habe ich aber auf Grund von Punkt 1.) nicht weiter verfolgt, da dies die zunkunftsweisendere Implementierung wäre und mein "Wiki-Reader" nur eine temporäre Zwischenlösung wäre (Programmieraufwand ←> Nutzen).

Mal ein, vollkommen aus /dev/brain bezogener und idealer Lösungvorschlag:

• Erstellen eines Minimaltemplates für das statische Wiki, d.h. alles dynamische raus und die ganze Optionen die Serverzugriff erfordern kicken.

• Erweitern der Article() Klasse in Inyoka um eine z.B. render_static() Methode welche beim aufruf den Artikel mit dem oben genannten Template rendert.

• Logik welche über die Datenbank rauscht und alle Artikel mit render_static() aufruft, und dann die benötigten Static Files (Bilder, CSS, …) zusätzlich in einen Ordner schiebt.

• Cronjob für diese Logik.

Sowas könnten wir auf die Server jagen und dann per Cron oder später als systemd Timer Unit laufen lassen, schon haben wir automatisch einen ordentlichen Export. Die Logik müsste dabei z.B. ACLs beachten und wohl noch eine Hand voll anderer Dinge um sinnvoll zu sein.

Das ist jetzt einfach mal nur ein kurzer Braindump, soll aber zeigen das es mit einem gewissen Aufwand möglich ist. Bedingungen für den Zugriff auf den Quellcode wurden neulich in einem Ikhaya Artikel genannt, in #ubuntuusers-webteam sind wir erreichbar und für Diskussionen über den statischen Wiki Export (neben anderen Themen) erreichbar.

Einen Dump der aktuellen Datenbank, auch in Auszügen, werde ich nicht nach extern verteilen und bekommen auch nur handverlesene Webteam Mitglieder nach Rücksprache mit der Projektleitung.

Bei weiteren Fragen/Ideen bitte einfach melden, ich bin gerne bereit zu helfen oder erforderliche Infos zu organisieren falls nötig. Das Thema mit dem statischen Wiki ist auch für uns wichtig, jedoch haben andere Dinge natürlich eine noch höhere Priorität (Betrieb der Plattform, Anpassungen an neue Django Releases, Vorbereiten der OSS Version, …).

mfg Stefan Betz

Ich habe ehrlicherweise die Diskussion nicht mit jedem Detail verfolgt, aber was spricht dagegen, einen Dump des Wiki mit wget zu erzeugen und dann einzupacken? Oder sind mehr Features gewünscht außer dem statischen Inhalt? (Ich kenne das aktuelle Offline-Wiki nicht.)

Ciao

robert

Die wget Version erzeugt Duplicate Content wenn die gehostet wird, es muss also z.b. Canonical URL gesetzt werden in den Seiten usw...

mfg Stefan Betz

encbladexp schrieb:

es muss also z.b. Canonical URL gesetzt werden in den Seiten usw...

Ich hätte ja nun canonical, also klein, oder kanonische geschrieben. Möchte nicht wissen, wieviele das falsch verstehen. 😉

Ein aktueller Snapshot oder überhaupt eine praktikable Lösung für wesentlich häufigere Snapshots sind sehr wünschenswert.

axt schrieb:

Ein aktueller Snapshot oder überhaupt eine praktikable Lösung für wesentlich häufigere Snapshots sind sehr wünschenswert.

Ich habe hierzu in den internen Foren eine Info gegeben wie sowas z.B. realisiert werden könnte, es muss aber halt auch von jemandem realisiert werden.

mfg Stefan Betz
PS: Edit, war sogar hier!!!

encbladexp schrieb:

Aktueller Status: Es gibt keinen (funktionsfähigen) Renderer für ein statisches Wiki.

Der Renderer, der im Repo ist tut. Es gab nur nach meinem Export vom 10. März 2014 intern Unklarheiten was die Lizenzreferenz angeht, darum ist der Snapshot nie veröffentlicht worden.

/Markus

Oh, den solltest du mir aber dann mal bei Gelegenheit Zeigen 😀

mfg Stefan Betz

So ein Programm, womit man sich das Online-Wiki runterladen kann, wäre schon eine tolle Sache. Am allerbesten mit der Funktion, das synchronisieren zu lassen, damit man selbstständig sich immer das neueste Wiki "holen" kann. Dann bräuchte sich niemand mehr darum kümmern und manuell Snapshots erstellen.

Oder gibt es da irgendeine andere Möglichkeit, die ich noch nicht entdeckt habe?

Ich hab das Wiki-Team über das Script informiert, ggf. schaut es sich ja jemand mal an.

mfg Stefan Betz

Vielleicht eine dumme Frage: Warum wird für ein Offline-Wiki nicht ein Tool wie httrack benutzt?

Die letzten Beiträge übersehen?