offline-wiki online

[Matthias Apsel]

Hallo alle,

das offline-wiki ist nun endlich auch im Wiki online 😉 https://wiki.selfhtml.org/wiki/SELFHTML:Wiki/offline-Wiki

Nochmals vielen Dank an @dedlfix für die geleistete Arbeit.

Bis demnächst
Matthias

[Matthias Scharwies]

Servus!

Vielen Dank an euch beide!

Herzliche Grüße

Matthias Scharwies

[Felix Riesterer]

Lieber Matthias,

schön wieder von Dir zu lesen!

Liebe Grüße,

Felix Riesterer.

[Matthias Scharwies]

Servus!

Das nächste Projekt wären die fertigen Layouts!

Ich habe die meisten eigentlich schon bereinigt; seit 2013 hat sich einiges geändert:

• viele vendor-prefixes entfernt, da nicht mehr nötig
• kein <li class="active">sondern <a href="/" aria-current="page">
• Noch weniger Hintergrundbilder

Die meisten Templates verwenden noch floats; da müsste man Flexbox und Grid einbauen - und da sind wir beim Problem:

Alleine habe ich keine Lust und vor allem auch nicht genügend Ideen. Wenn sich da jemand (oder sogar ein Team?) fände, mit dem man ein Wochenende mal über teamspeak oder im real life einige solcher Seiten zusammenbauen würde?

Mein Versuch den CSS-Garden nachzubauen:

• Template 01 (Flexbox mit mehreren Layouts, zuletzt beim MiniWeb wieder vorgekramt)
• gewünscht: Webvisitenkarte
• gewünscht: Irgendwas mit grid

Herzliche Grüße

Matthias Scharwies

[Gunnar Bittersmann]

@@Matthias Scharwies

• kein <li class="active">sondern <a href="/" aria-current="page">

href="/"?? Weil wir uns gerade zufällig auf der Homepage befinden?

Menüpunkt der aktuellen Seite entweder mit <a href="#main" aria-current="page"> auf den Hauptinhalt <main id="main"> oder gar nicht verlinken: <a tabindex="0" aria-current="page">.

Bei den Beispielen gibt es aber noch andere Dinge zu berichtigen. Ich hab mir mal zufällig eins rausgepickt: Template 8. Hab versucht, mit der Tastatur zu navigieren: geht nicht, kaputt. Weil das nav-Element im Markup irgendwo steht anstatt ganz oben. Die Reihenfolge im Markup muss aber mit der visuellen Reihenfolge übereinstimmen. (Es sei denn, man will da mit tabindex rumwerkeln. Nein, das will man nicht.)

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Bei den Beispielen gibt es aber noch andere Dinge zu berichtigen. Ich hab mir mal zufällig eins rausgepickt: Template 8. Hab versucht, mit der Tastatur zu navigieren: geht nicht, kaputt. Weil das nav-Element im Markup irgendwo steht anstatt ganz oben.

Und falls man dann doch irgendwann in der Navigation landet, ist diese unbrauchbar, weil wieder mal vergessen wurde, Stile für :focus anzugeben.

Die Reihenfolge im Markup muss aber mit der visuellen Reihenfolge übereinstimmen.

Und ganz oben im Markup bietet sich ein Skip-Link <a href="#main" id="skip-link">zum Hauptinhalt</a> an, der nur sichtbar ist, wenn er den Fokus hat, und mit dem man direkt beim Hauptinhalt landet.

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Und falls man dann doch irgendwann in der Navigation landet, ist diese unbrauchbar, weil wieder mal vergessen wurde, Stile für :focus anzugeben.

Derselbe Kapitalfehler in Template 10.

Bei diesem Template kommt noch hinzu, dass das visuelle Design des Navigationsmenüs an sich nicht taugt. Das Menü sieht nicht aus wie ein Menü, sondern wie eine Fortschrittsanzeige. Ein Element entgegen seiner Funktion wie ein anderes mit einer völlig anderen Funktion aussehen zu lassen, ist ein schwerer Designfehler.

Ich will jetzt nicht alle Templates durchgehen. Vermutlich ist es am besten, sie alle bis zu ihrer erfolgten Überarbeitung offline zu nehmen. Besser keine Beispiele als falsche.

LLAP 🖖

[Matthias Scharwies]

Servus!

[...]

Das lieb ich so an dir!

Noch mal für alle Selfer! Wir haben 2014 diese Vorlagen online gestellt. Die zip-Dateien auf src.selfhtml.org zu stellen hat es leider nicht mehr gereicht.

Im September 2017 habe ich die bei mir privat gehosteten zip-Dateien entfernt und überarbeitet. Sie liegen bei mir auf der Festplatte, da sie niemand auf src.selfhtml.org hochladen wollte. Da es sich dabei aber um die preisgekrönten, sonst aber eher nicht nachahmenswerten Ergebnisse aus dem Designen-lassen.de-Wettbewerb handelt, wäre es zusätzlich wünschenswert/nötig einige neue Templates zu kreieren.

Dass es einen Bedarf gibt, zeigt sich daran, dass wir täglich ca. 2-3 Anfragen kriegen uns die zip-Dateien zuzusenden.

Herzliche Grüße

Matthias Scharwies

[Gunnar Bittersmann]

@@Matthias Scharwies

Das lieb ich so an dir!

😙

Da es sich dabei aber um die preisgekrönten, sonst aber eher nicht nachahmenswerten Ergebnisse aus dem Designen-lassen.de-Wettbewerb handelt

Preisgekrönt, aber nicht nachahmenswert. Finde den Fehler!

Die Krönung sagt nichts über die Laureaten, aber sehr viel über die Jury.

LLAP 🖖

[Matthias Scharwies]

Servus!

Da es sich dabei aber um die preisgekrönten, sonst aber eher nicht nachahmenswerten Ergebnisse aus dem Designen-lassen.de-Wettbewerb handelt

Preisgekrönt, aber nicht nachahmenswert. Finde den Fehler!

Die Krönung sagt nichts über die Laureaten, aber sehr viel über die Jury.

Das war die Firma, die wohl nur an kostenloser Werbung für ihr Vermittlungsportal interessiert war. Template 9 bestand aus 24 (oder 36 - weiß nicht mehr) zerschnittenen Photoshopbildern in einer Tabelle.

Ein Designer hat wohl Matthias Apsel kontaktiert und um Berücksichtigung gebeten, da er die 50€ Preisgeld dringend benötigte.

LLAP 🖖

Herzliche Grüße

Matthias Scharwies

[dedlfix]

Tach!

Die Krönung sagt nichts über die Laureaten, aber sehr viel über die Jury.

Das war die Firma, die wohl nur an kostenloser Werbung für ihr Vermittlungsportal interessiert war.

Gabs da nicht eine öffentliche Abstimmung darüber? Wenn ich mich recht erinnere, gab es die auch nur über das Design an sich, weil man den Code nicht sieht, bevor man sich entschieden hat, ein Design zu nehmen. Sonst wäre die Plattform auch nicht tragbar, weil sonst jeder mit dem Code abzieht und einfach Danke sagt, anstatt für das gewählte Design zu bezahlen.

Zumindest läuft die damals verwendete Plattform auf diese Weise. Man sagt, was man haben möchte, mehrere potentielle Auftragnehmer unterbreiten Vorschläge, die man dls Bilder sieht, man nimmt ein Design, bezahlt es, und bekommt dann alle Dateien dazu.

Und ja, das ist für jemanden, der sich mit HTML/CSS auskennt eine Katze im Sack. Aber das ist vermutlich auch nicht die Zielgruppe der Plattform. Uns ging es damals auch nur um optische Designideen. Dass der Unterbau tiptop sein musst, war nicht gefordert, soweit ich mich erinnere.

dedlfix.

[Matthias Apsel]

Hallo dedlfix,

Dass der Unterbau tiptop sein musst, war nicht gefordert, soweit ich mich erinnere.

tiptop nicht, aber ich hatte in der Ausschreibung zumindest von korrektem HTML geschrieben.

Bis demnächst
Matthias

[Felix Riesterer]

Lieber Gunnar,

Das lieb ich so an dir!

😙

[zensiert]

Preisgekrönt, aber nicht nachahmenswert. Finde den Fehler!

Die Krönung sagt nichts über die Laureaten, aber sehr viel über die Jury.

<I>

Liebe Grüße,

Felix Riesterer.

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Ich will jetzt nicht alle Templates durchgehen.

Die du da findest, sind nicht mehr die aktuellen, imho.

Mit einem zu beginnen, reicht ja schon.

Vermutlich ist es am besten, sie alle bis zu ihrer erfolgten Überarbeitung offline zu nehmen. Besser keine Beispiele als falsche.

Wahrscheinlich sollte ich als Sockenpuppe zu jedem der Templates hier einen Thread aufmachen. Und zack hätte ich ein CodePen nach dem anderen.

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Wahrscheinlich sollte ich als Sockenpuppe zu jedem der Templates hier einen Thread aufmachen. Und zack hätte ich ein CodePen nach dem anderen.

YMMD.

LLAP 🖖

[Gunnar Bittersmann]

@@Matthias Apsel

Wahrscheinlich sollte ich als Sockenpuppe zu jedem der Templates hier einen Thread aufmachen. Und zack hätte ich ein CodePen nach dem anderen.

Eigentlich sollten doch responsive menu, markup corrected, escape key support und basic page layout, header menu CodePens genug sein. Das erste hat das Hamburger-Icon mit drin, das zweite die Markierung der aktuellen Seite. Da müsste man nur aus beidem eins machen und das so stylen, wie’s denn jeweils aussehen soll.

LLAP 🖖

[Felix Riesterer]

Lieber Gunnar,

Da müsste man nur aus beidem eins machen

wer ist "man"...?

Liebe Grüße,

Felix Riesterer.

[Gunnar Bittersmann]

@@Felix Riesterer

Da müsste man nur aus beidem eins machen

wer ist "man"...?

Jedermann (m/w).

LLAP 🖖

[Felix Riesterer]

Lieber Gunnar,

wer ist "man"...?

Jedermann (m/w).

schade - aber nix neues.

Liebe Grüße,

Felix Riesterer.

[marctrix]

Hej Matthias,

Alleine habe ich keine Lust und vor allem auch nicht genügend Ideen. Wenn sich da jemand (oder sogar ein Team?) fände, mit dem man ein Wochenende mal über teamspeak oder im real life einige solcher Seiten zusammenbauen würde?

Wie wäre es mit einer Bugtracker-Software?

Marc

[Matthias Scharwies]

Servus!

Hej Matthias,

Alleine habe ich keine Lust und vor allem auch nicht genügend Ideen. Wenn sich da jemand (oder sogar ein Team?) fände, mit dem man ein Wochenende mal über teamspeak oder im real life einige solcher Seiten zusammenbauen würde?

Wie wäre es mit einer Bugtracker-Software?

An Software hat es noch nie gemangelt, nur an Mitstreitern!

• github: SELFHTML/Fertige-Layouts latest commit on 18 Oct 2013
• Trello: Neue fertige Layouts machen lassen 24.04.2014
• Benutzer:MScharwies/Konzept für neue Templates (mein Konzept aus dem Jahre 2016; erinnerst du dich ans MiniWeb?)

Wenn sich keine Mitstreiter finden, lassen wir es halt so wie es jetzt ist.

Herzliche Grüße

Matthias Scharwies

[marctrix]

Hej Matthias,

Alleine habe ich keine Lust und vor allem auch nicht genügend Ideen. Wenn sich da jemand (oder sogar ein Team?) fände, mit dem man ein Wochenende mal über teamspeak oder im real life einige solcher Seiten zusammenbauen würde?

Wie wäre es mit einer Bugtracker-Software?

An Software hat es noch nie gemangelt, nur an Mitstreitern!

Yo, dat schtimmt. Ist ja nicht so, als ob ich nicht wollen würde. Ich will es nur gut oder gar nicht machen. Und da hapert es an der Zeit — ist sicher nicht nur mein Problem…

• Benutzer:MScharwies/Konzept für neue Templates (mein Konzept aus dem Jahre 2016; erinnerst du dich ans MiniWeb?)

Ja, ist irgendwie ziemlich schnell im Sande verlaufen… - schade.

Wenn sich keine Mitstreiter finden, lassen wir es halt so wie es jetzt ist.

Nochmal schade, aber verständlich…

Marc

[Camping_RIDER]

Aloha ;)

Alleine habe ich keine Lust und vor allem auch nicht genügend Ideen. Wenn sich da jemand (oder sogar ein Team?) fände, mit dem man ein Wochenende mal über teamspeak oder im real life einige solcher Seiten zusammenbauen würde?

Ich hätte eigentlich total lust dazu, mich mal wieder an was konkret-praktisches zu setzen. Aber ich sehe jetzt schon, wie meine Freundin mir dafür die Finger an die Kehle legt und langsam zudrückt - zurecht übrigens 😂

Nein im Ernst: Ich habe aktuell echt wenig Zeit. Richtig wenig Zeit. Aber ich fänds reizvoll, daraus tatsächlich wie von dir vorgeschlagen ein "Projektwochenende" draus zu machen, für das ich mir die Zeit dann auch gerne nähme, so sie mir denn überhaupt zur Verfügung steht.

Ich würde mich also grundsätzlich gerne anschließen. Vielleicht finden wir einen Ferientermin (bundesländerübergreifend - zumindest im Süden), holen uns den @Felix Riesterer noch ins Boot und profitieren von unseren unterschiedlich verteilten und unterschiedlich aktuellen Kenntnissen?

Grüße,

RIDER

[pl]

Moin,

wozu braucht man dafür denn einen lokalen Webserver? Falls die Antwort auf eine Suchfunktion hinausläuft, die kann man auch mit Javascript realisieren. Zumal es heutzutage moderne Möglichkeiten gibt für eine lokale Datenhaltung auf die mit JS zugegriffen werden kann. Da wären z.B. Appcache und die FileAPI.

Wieviele Einzelseiten sind es denn? MfG

[dedlfix]

Tach!

wozu braucht man dafür denn einen lokalen Webserver?

Warum so und keine statischen Seiten?

Wieviele Einzelseiten sind es denn?

Siehe dazu die Statistik-Seite, zu finden über "Spezialseiten" im Abschnitt "Werkzeuge" der linken Navigation.

dedlfix.

[pl]

Tach!

wozu braucht man dafür denn einen lokalen Webserver?

Warum so und keine statischen Seiten?

Kann ich nicht nachvollziehen. Das ist Stand der Technik die man vor 20 Jahren hatte.

MfG

[Christian Kruse]

Hallo pl,

wozu braucht man dafür denn einen lokalen Webserver?

Warum so und keine statischen Seiten?

Kann ich nicht nachvollziehen. Das ist Stand der Technik die man vor 20 Jahren hatte.

Wenn du meinst es besser zu können: bitte sehr. Du darfst dich gerne versuchen.

LG,
CK

[pl]

Kann ich nicht nachvollziehen. Das ist Stand der Technik die man vor 20 Jahren hatte.

Wenn du meinst es besser zu können: bitte sehr. Du darfst dich gerne versuchen.

Auf die Idee kommt es an, nur ein Beispiel, mit AppCache wäre es auch offline voll funktionsfähig -- ohne Webserver. Und wartungsfreundlich isses auch 😉

[dedlfix]

Tach!

Auf die Idee kommt es an, nur ein Beispiel, mit AppCache wäre es auch offline voll funktionsfähig -- ohne Webserver. Und wartungsfreundlich isses auch 😉

"Für jedes komplexe Problem gibt es eine Lösung, die einfach, verständlich und falsch ist." Das gilt vor allem, wenn man sich nicht oder nur oberflächlich mit den Dingen beschäftigt, über die man sich ein Urteil erlaubt.

AppCache: "This feature has been removed from the Web standards."

Mit AppCache oder dem Nachfolger Service Workers könnte man vielleicht die Suchfunktion nachprogrammieren, aber das löst eine ganze Menge andere Probleme nicht, an denen Offline-Versionen scheitern. Das Problem ist so tiefsitzend, dass es für diese weitverbreitete Software Mediawiki kein Offline-Tool (mehr) gibt (das mit aktuellen Versionen klar käme). Du kannst dich gern daran versuchen, viel Erfolg.

dedlfix.

[pl]

AppCache: "This feature has been removed from the Web standards."

Auch kein Problem. Man kann den ganzen Inhalt samt JavaScript und CSS in eine einzige HTML-Datei einbetten. Wie gesagt, man muss nur die richtigen Ideen haben. Eine solche Inline-Binary hätte bei 500 Einzelseiten eine Größe von ca. 1.5MB (Base64) und ist ausgepackt wie eine Datenbank ansprechbar. Ich habe sowas schon mit Bildern+Titel+Beschreibung gemacht, da belief sich das auf 3MB und da ist noch jede Menge Luft nach oben.

MfG

[Matthias Apsel]

Hallo pl,

Ich sehe deiner funktionierenden Lösung entgegen. Welche Unterstützung benötigst du von uns?

Bis demnächst
Matthias

[pl]

Guck es Dir doch erst einmal an. MfG

[Christian Kruse]

Hallo pl,

Guck es Dir doch erst einmal an. MfG

ja, genau. Guck es dir doch erst einmal an!

LG,
CK

[pl]

Hallo!

Guck es Dir doch erst einmal an. MfG

ja, genau. Guck es dir doch erst einmal an!

Das hier funktioniert offline: Datei speichern unter .. fertig. Kein Webserver erforderlich. MfG

[Christian Kruse]

Hallo pl,

Das hier funktioniert offline: Datei speichern unter .. fertig. Kein Webserver erforderlich. MfG

Deine Perlbase ist aber völlig irrelevant für das hier zugrunde liegende Problem. Du hast überhaupt nicht verstanden, worum es geht und wo das eigentliche Problem liegt. Bevor du also die Fresse aufreisst wie geil du bist, beschäftige dich erstmal mit dem eigentlichen Problem: das Wiki offline verfügbar machen. Danke.

LG,
CK, heute ziemlich genervt

[pl]

hi,

Das hier funktioniert offline: Datei speichern unter .. fertig. Kein Webserver erforderlich. MfG

Deine Perlbase ist aber völlig irrelevant für das hier zugrunde liegende Problem. Du hast überhaupt nicht verstanden, worum es geht und wo das eigentliche Problem liegt. Bevor du also die Fresse aufreisst wie geil du bist, beschäftige dich erstmal mit dem eigentlichen Problem: das Wiki offline verfügbar machen. Danke.

Mit Eurem Wiki kann ich das ganz genauso machen, kein Problem: Meiner Software sind die Inhalte egal.

Und mäßige Dich mit Deiner Ausdrucksweise!

MfG

[Christian Kruse]

Hallo pl,

Mit Eurem Wiki kann ich das ganz genauso machen, kein Problem: Meiner Software sind die Inhalte egal.

Dann los! Erstelle eine Offline-Version des Wikis. Seit 9 Posts wirst du dazu immer wieder aufgefordert. Bisher sehe ich außer substanzlosem Gelaber, das offenbart, dass du nichts verstanden hast - nichts. Schwätzer.

Und mäßige Dich mit Deiner Ausdrucksweise!

Nein. Ich habe die Schnauze voll von deinem arroganten und überheblichen Gehabe, mir platzt gerade der Kragen. Ich will jetzt nicht mehr höflich sein zu dir.

LG,
CK

[pl]

hi,

Ich sehe deiner funktionierenden Lösung entgegen. Welche Unterstützung benötigst du von uns?

Schick mir bitte mal das Schema zum DB-Design. Handskizze genügt, also je Tabelle ein Kasten mit den Feldern und ----> wo die Schlüssel hinzeigen (referentiell).

Ich nehme an, daß sämtliche Inhalte in der Datei wiki.sqlite liegen?

MfG

[dedlfix]

Tach!

Schick mir bitte mal das Schema zum DB-Design. Handskizze genügt, also je Tabelle ein Kasten mit den Feldern und ----> wo die Schlüssel hinzeigen (referentiell).

Haben wir nicht, musst du selbst reverse-engineeren, wenn du das brauchst. Das Schema ist dasselbe wie es Mediawiki anlegt, denn das muss ja damit arbeiten. Vielleicht gibt es auch von Seiten Mediawikis eine Dokumentation.

Ich nehme an, daß sämtliche Inhalte in der Datei wiki.sqlite liegen?

Alles was Mediawiki in seiner Datenbank ablegt, liegt da drin. Also beispielsweise keine Bilder, nur Verweise auf die Bilddateien.

dedlfix.

[pl]

Ich habe mir eine Seite rausgesucht, tabelle page in wiki.sqlite (download)

         {
            'page_content_model' => 'wikitext',
            'page_id' => 4210,
            'page_is_new' => 0,
            'page_is_redirect' => 0,
            'page_lang' => undef,
            'page_latest' => 55877,
            'page_len' => 3614,
            'page_links_updated' => '20170926170509',
            'page_namespace' => 0,
            'page_random' => '0.150785700622',
            'page_restrictions' => '',
            'page_title' => 'JavaScript/DOM/Node/appendChild',
            'page_touched' => '20170926170509'
          }

Diese Seite gibt es im online Wiki. Ich habe nun alle Tabellen durch und kann den Inhalt dieser Seite nicht finden. Bitte mal um Hilfestellung: Welche Tabelle? MfG

[dedlfix]

Tach!

Diese Seite gibt es im online Wiki. Ich habe nun alle Tabellen durch und kann den Inhalt dieser Seite nicht finden. Bitte mal um Hilfestellung: Welche Tabelle?

Die Dokumentation von Mediawiki gibts bei mediawiki.org. Da sind auch die Tabellen und deren Felder beschrieben, zum Beispiel Manual:page table. page_latest zeigt auf die jüngste Revision des Seiteninhalts.

dedlfix.

[pl]

Tach!

Diese Seite gibt es im online Wiki. Ich habe nun alle Tabellen durch und kann den Inhalt dieser Seite nicht finden. Bitte mal um Hilfestellung: Welche Tabelle?

Die Dokumentation von Mediawiki gibts bei mediawiki.org. Da sind auch die Tabellen und deren Felder beschrieben, zum Beispiel Manual:page table. page_latest zeigt auf die jüngste Revision des Seiteninhalts.

Ja, schon aber wo finde ich den Inhalt?

bisher joine ich so

    SELECT 
    
    text.old_text   as content,
    page.page_id    as pageid,
    page.page_title as title
    
    from page 
    join revision on page.page_id = revision.rev_page
    join text on text.old_id = revision.rev_text_id

    --where title = "JavaScript/DOM/Node/appendChild"

und da kann ich die Inhalte finden wie auch vergleichen (anhand Beispiele in where klause). Bin jetzt etwas verunsichert. MfG

[dedlfix]

Tach!

Ja, schon aber wo finde ich den Inhalt?

bisher joine ich so

    SELECT 
    
    text.old_text   as content,
    page.page_id    as pageid,
    page.page_title as title
    
    from page 
    join revision on page.page_id = revision.rev_page
    join text on text.old_id = revision.rev_text_id

    --where title = "JavaScript/DOM/Node/appendChild"

und da kann ich die Inhalte finden wie auch vergleichen (anhand Beispiele in where klause).

Ja, das ist der Seiteninhalt. Aber als Wikitext. Das muss erst noch gerendert werden, inklusive Auflösung von Templates, bevor das auslieferbares HTML ist. Das passiert beim Aufruf, und wird auch gecachet.

dedlfix.

[pl]

und da kann ich die Inhalte finden wie auch vergleichen (anhand Beispiele in where klause).

Ja, das ist der Seiteninhalt. Aber als Wikitext. Das muss erst noch gerendert werden, inklusive Auflösung von Templates, bevor das auslieferbares HTML ist. Das passiert beim Aufruf, und wird auch gecachet.

Ok, danke, da bin ich ja auf dem richtigen Weg 😉

Klar, daß da Platzhalter drin sind, ist ja nicht zu übersehen. MfG

[pl]

Also insgesamt finde ich ca. 8500 Seiten in wiki.sqlite. Für eine Offlineversion jedoch dürften davon ca. 1/4 übrig bleiben, also ca 400 Einzelseiten. Denn nach diesem Kriterium

    where text.old_text not like "#%" 
    and page.page_title not like "%.png" 
    and page.page_title not like "%.gif"
    and page.page_title not like "%.html"

(was ggf. noch qualifiziert werden muss) fällt da Einiges raus. Möglichwerseise bietet ja auch Mediawiki selbst eine Exportfunktion wo gerendertes text/html hinten rauskommt. Das würde die Wartung ungemein erleichtern.

Auf jeden Fall sind 400 Einzelseiten kein Problem für eine Oflineversion dieser Bauart aber auch kein Grund für eine lokalen Webserver bzw. lokale Installation einer Mediawiki-Software.

MfG

[dedlfix]

Tach!

Also insgesamt finde ich ca. 8500 Seiten in wiki.sqlite. Für eine Offlineversion jedoch dürften davon ca. 1/4 übrig bleiben, also ca 400 Einzelseiten.

So kann man nicht rechnen. Es sind zwar nur ca. 2700 Inhaltsseiten, aber das heißt nicht, dass der Rest entbehrlich ist. Eine Menge Seiten sind Weiterleitungen, einerseits aus historischen Gründen, andererseits damit die Suchmaschine Stichwörter finden kann, die auf anders benannten Seiten abgehandelt werden.

Möglichwerseise bietet ja auch Mediawiki selbst eine Exportfunktion wo gerendertes text/html hinten rauskommt. Das würde die Wartung ungemein erleichtern.

Ja, die kann man ansprechen als Extension (hier nicht weiter relevant) oder als Maintenance-Script.

Und es ist ja nicht so, dass mir diese Idee nicht gekommen ist. Die Umsetzung hab ich dann aber abgebrochen. Nackiges gerendertes HTML des Hauptinhaltes sieht nämlich nicht besonders hübsch aus. Da muss neben dem Seitenrahmen noch CSS und gegebenenfalls Javascript hinzu, um Optik und die Funktionalitäten des Wikis bereitzustellen. Und da kam man dann vom Hundersten ins Tausendste, was alles zu beachten gewesen wäre. Der Resource Manager von Mediawiki, der das Zeug bündelt und einbindet ist der Punkt, an dem bereits andere Projekte aufgegeben haben.

Nächster Punkt war, dass aus Seitentiteln wie beispielweise "HTML/Tutorials" oder "Kategorie:HTML" irgendwie ein Dateiname erstellt werden muss, der im Dateisystem erlaubt ist. Und dann müssen die Links auf diese Seiten/Dateien auch noch für das Funktionieren bearbeitet werden.

Letztlich wollte ich dann auch nicht Mediawiki nachprogrammieren und für alle Eventualitäten eine Extrawurst erfinden, und hab mich für eine abgespeckte Version des kompletten Ökosystems Webserver, PHP, Mediawiki und Datenbestand entschieden. Das fand ich einen guten Kompromiss nach Abwägung der möglichen Vorgehensweisen.

dedlfix.

[pl]

hi,

die join using() habe ich wg. Deinem Hinweis geändert, statt

-- bisher
    join revision on page.page_id = revision.rev_page
    join text     on text.old_id  = revision.rev_text_id

-- nun
    join revision on revision.rev_id = page.page_latest
    join text     on     text.old_id = revision.rev_text_id

ist da wohl korrekter, obwohl möglicherweise dasselbe dabei rauskommt. Aber so richtig steige ich noch nicht durchs DB Design, insbesondere was die Kategorien (table category) einschl. deren ref. Integrität betrifft.

In Fakt sind die Inhalte mit dem title like "%.html" komplette Beispiele von <doctype> bis </html>. Mein Ziel ist eine BinärDatei die mit JS lesbar ist. Das Problem ist also nicht

dass aus Seitentiteln wie beispielweise "HTML/Tutorials" oder "Kategorie:HTML" irgendwie ein Dateiname erstellt werden muss

sondern wie ich Kategorie-Seiten und #Weiterleitungsseiten beim Extrahieren des Content rausfiltern kann. Die BinDatei wird eine EAV-Datenstruktur beiinhalten mit den Seitentiteln als Entity. So wie im Wiki gut zusehen ist, liegen ja die Titel der Verlinkung zugrunde und nicht etwa die page_id.

          {
            'cat_files' => 0,
            'cat_id' => 9065,
            'cat_pages' => 10,
            'cat_subcats' => 0,
            'cat_title' => 'Zeichenkodierung'
          },

ist ein Stück aus der category-table. Im Online Wiki nachvollziehbar ist, daß es 10 Seiten zu dieser Kategorie gibt. Also muss die cat_id irgendwie in den anderen Tabellen referenziert sein, fragt sich nur in welcher. Wenn Du ne Idee hierzu hast, lass es mich bitte wissen. Ich vermute eine Verbindung über page_namespace (und ggf. eine weitere Tabelle) aber für Heute reichts 😉

Schöne Grüße!

PS: Geht doch 😉

[dedlfix]

Tach!

[... Revision-Referenz ...] ist da wohl korrekter, obwohl möglicherweise dasselbe dabei rauskommt.

Eine Page kann mehrere Revisions haben, weswegen in der Revision auf die ID der Page verwiesen wird, zu der sie gehört. Aber nur eine Revision ist die aktuelle, weswegen in der Page ein Verweis auf eine Revision existiert. In der Offline-Datenbank ist aber nur die aktuelle Revision enthalten, weswegen aus der 1:n-Beziehung eine 1:1 wurde. Und es ist im Prinzip auch egal, über welchen der beiden Wege du die Beziehung herstellst. Aber wenn es darum geht, den Online-Datenbestand (für eine neue Offline-Version) zu befragen, muss man schon den Weg über die "latest Revision" gehen.

Aber so richtig steige ich noch nicht durchs DB Design, insbesondere was die Kategorien (table category) einschl. deren ref. Integrität betrifft.

Das ist nur eine Liste der Kategorien. Die Beziehungen zu Pages oder übergeordneten Categorien ist in categorylinks zu finden. Dazu muss der cl_type beachtet werden, auf welche Sorte Ziel sich das cl_from bezieht.

In Fakt sind die Inhalte mit dem title like "%.html" komplette Beispiele von <doctype> bis </html>.

Beispiele sind im Namensraum "Beispiel" zu finden. Die Seitennamen dort haben eine typspezifische Endung, damit der Content-Type daraus abgeleitet und entsprechend gesetzt werden kann. Beispiele werden über eine selbstgeschriebene Extension behandelt und gehen nicht den üblichen Mediawiki-Weg.

Mein Ziel ist eine BinärDatei die mit JS lesbar ist.

JSON ist auch mit Javascript lesbar und man kann sich jeden beliebigen JSON- oder Text-Editor nehmen, um es gegebenenfalls zu bearbeiten. Ein proprietäres Binärformat hingegen benötigt ein Spezialwerkzeug und das Wissen um die Spezifikation dieses Formats. Das würde ich wegen schlechter Wartbarkeit ablehnen.

Das Problem ist also nicht

dass aus Seitentiteln wie beispielweise "HTML/Tutorials" oder "Kategorie:HTML" irgendwie ein Dateiname erstellt werden muss

Ach, nicht? Was soll denn da am Ende rauskommen? Eine Art SPA, die sich aus einem Binärdatengrab bedient? Also quasi ein Webserver?

sondern wie ich Kategorie-Seiten und #Weiterleitungsseiten beim Extrahieren des Content rausfiltern kann.

Die Kategorien werden in den beiden erwähnten Tabellen verwaltet. Jede Kategorie hat (genauer: kann haben) außerdem eine Page, die sich im Namensraum für die Kategorien befindet.

dedlfix.

[pl]

hi Danke für Deine Hinwise!

Mein Ziel ist eine BinärDatei die mit JS lesbar ist.

JSON ist auch mit Javascript lesbar und man kann sich jeden beliebigen JSON- oder Text-Editor nehmen, um es gegebenenfalls zu bearbeiten. Ein proprietäres Binärformat hingegen benötigt ein Spezialwerkzeug und das Wissen um die Spezifikation dieses Formats. Das würde ich wegen schlechter Wartbarkeit ablehnen.

Das Format dieser Binary ist vollkommen egal. In Fragen Wartbarkeit steht das Format überhaupt nicht zur Disposition.

Das Problem ist also nicht

dass aus Seitentiteln wie beispielweise "HTML/Tutorials" oder "Kategorie:HTML" irgendwie ein Dateiname erstellt werden muss

Ach, nicht? Was soll denn da am Ende rauskommen? Eine Art SPA, die sich aus einem Binärdatengrab bedient? Also quasi ein Webserver?

Ja, natürlich eine SPA. Das verlinkte Beispiel einer Solchen ist eine HTML Datei mit einer eingebetteten Binary die derzeit 100 Dokumente beeinhaltet. Bei jedem online-Aufruf wird die SPA neu erstellt, damit hat die Wiki-Redaktion überhaupt nichts zu tun. Und nachdem die SPA erstellt und ausgeliefert wurde, kann sie an einem beliebigen Ort unter einem beliebigen Namen gespeichert werden wo sie dann völlig eigenständig funktioniert -- eben mit der Scriptsprache die ein jeder moderner Browser bei sich hat: JavaScript.

Und selbstverständlich ist da auch die Library eingebettet, die aus der eingebetteten Binary eine griffige Datenstruktur in den Hauptspeicher legt was der SPA den wahlfreien Zugriff auf die Dokumente ermöglicht. So ergibt sich eine einfache Suchfunktion über den zu jedem Dokument gehörigen aussagekräftigen Titel respektive einer aussagekräftigen Beschreibung, beides wird über eine <datalist> bereits beim Eintippen einzelner Buchstaben in das Suchfeld geladen womit schließlich das dazugehörige Dokument in den <body> geholt werden kann sobald der Anwender Enter drückt.

Bei allem Respekt zu Eurer geleisteten Arbeit, leider haben die Dokumente im Mediawiki keinen aussagekräftigen Titel und eine (Kurz)Beschreibung fehlt völlig. Eine Suchfunktion muss also direkt in die Inhalte greifen und zunächst eine Trefferliste erzeugen. Und genau da fällt einem das Problem der fehlenden Beschreibungen ein zweites Mal auf die Füße.

Ansonsten ist es schon ein lohnenswertes Ziel über das man mal nachdenken sollte: Daß man mit einem einzigen Klick eine Offline Version des Mediawiki mit aktuellem Datenbestand auf seinen lokalen PC bekommt und mit demselben Klick jederzeit ein Update machen kann.

sondern wie ich Kategorie-Seiten und #Weiterleitungsseiten beim Extrahieren des Content rausfiltern kann.

Die Kategorien werden in den beiden erwähnten Tabellen verwaltet. Jede Kategorie hat (genauer: kann haben) außerdem eine Page, die sich im Namensraum für die Kategorien befindet.

Ich bleib' dran und studiere Doku. Die Render-Engine zu verstehen ist noch das kleinste Problem 😉

MfG

[pl]

hi,

JSON ist auch mit Javascript lesbar und man kann sich jeden beliebigen JSON- oder Text-Editor nehmen, um es gegebenenfalls zu bearbeiten. Ein proprietäres Binärformat hingegen benötigt ein Spezialwerkzeug und das Wissen um die Spezifikation dieses Formats. Das würde ich wegen schlechter Wartbarkeit ablehnen.

Für die Binary ergeben sich ca 10 MB, egal ob als JSON oder anderweitig serialisiert. Bei dieser Datenmenge ist es besser die Binary über die FileAPI zu laden. Das habe ich gerade eben getestet und das nimmt mein FF absolut stressfrei hin:

• die Datei auspacken und die Inhalte in den Hauptspeicher laden
• Inhalte sind ca 4000 Seitentitel plus wiki"HTML"
• das Laden dieser Titel in eine datalist wo das Suchfeld draufsitzt

Ein OfflineWiki dieser Bauart bräuchte also neben der HTMLDatei noch die Datendatei (Binary) und die Aktualisierung würde sich auf die Bereitstellung der Binary zum Download beschränken. Ein Klick auf den Downloadlink würde so die Binary mit den aktuellen Daten einfach neu erstellen (als Export aus dem Wikimedia).

Das wirkliche Problem ist der Wikidialekt, auch nach intensiver Suche habe ich keine Library auftreiben können womit sich bspw. eine {|wikitable|} ordentlich nach HTML umwandeln lässt.

Kann das nicht die Wikisoftware selbst erledigen!? Lass mich mal wissen was Du liefern kannst 😉

MfG

[dedlfix]

Tach!

Kann das nicht die Wikisoftware selbst erledigen!?

Das war der Hauptgrund, warum ich diese zusammen mit einem Webserver ausliefere. Jede Menge Zeugs, das von Mediawiki erledigt wird, wollte ich nicht nacherfinden. Das wäre nämlich auch keine einmalige Sache, denn Mediawiki wird immer noch aktiv weiterentwickelt.

dedlfix.

[Rolf B]

Hallo dedlfix,

es gibt doch bestimmt einen PHP2JS Transpiler, oder? 😉

Rolf

[pl]

hi Rolf

es gibt doch bestimmt einen PHP2JS Transpiler, oder? 😉

Es gibt sogar txtwiki.js und wiky.js die aber auch nicht das machen was sie versprechen.

GGA

[pl]

Tach!

Kann das nicht die Wikisoftware selbst erledigen!?

Das war der Hauptgrund, warum ich diese zusammen mit einem Webserver ausliefere. Jede Menge Zeugs, das von Mediawiki erledigt wird, wollte ich nicht nacherfinden. Das wäre nämlich auch keine einmalige Sache, denn Mediawiki wird immer noch aktiv weiterentwickelt.

Seit gestern kann ich Deine Entscheidung nachvollziehen: Es gib zwar einige CPAN Module die von der Beschreibung her vielversprechend sind Wikidialekt2HTML zu machen, im konkreten Fall jedoch kläglichst versagen.

Bei einer solchen Art von Eigenbrötlerei wird der Begriff vom Plattformübergreifenden Datenaustausch zu einer hohlen Phrase, was nützen da JSON und XML, wenn damit nur proprietärer Müll transportiert wird.

Ansonsten wäre es von der Datenmenge her kein Problem damit eine SPA als Offline-Variante zu verteilen. Ein solcher Prozess könnte vollständig automatisiert werden und wäre absolut wartungsfrei sowie von der Wikisoftware völlig unabhängig.

Fazit: Mediawiki ist Schrott und das DB Design ist einfach nur grottig. Sich sowas lokal installieren zu wollen ist eine Zumutung.

MfG

[dedlfix]

Tach!

Seit gestern kann ich Deine Entscheidung nachvollziehen:

Willkommen im Club.

Fazit: Mediawiki ist Schrott und das DB Design ist einfach nur grottig. Sich sowas lokal installieren zu wollen ist eine Zumutung.

Mag sein (ich kam jedenfalls gut damit zurecht), aber schlechtes Design im Hintergrund ist kein Kriterium, das den Anwender interessiert.

dedlfix.

[pl]

Tach!

Auuch!!

Seit gestern kann ich Deine Entscheidung nachvollziehen:

Willkommen im Club.

Danke für die Einladung 😉

Hab trotzdem mal weitergemacht und eine SPA erstellt. Einen Auszug aus sqlite als Binary Base64 kodiert in HTML eingebettet. Dateigröße/HTML: ca. 12MB -- funktioniert einwandfrei und das Suchfeld einfach auf die Titel zu setzen würde der Anforderung vollauf genügen. Wenn man statt dem Wikikauderwelsch ordentliches HTML hätte, könnte man HTML mit Bildern und Tabellen ausliefern, die Bilder würde ich einfach als Dateien neben die SPA legen (lokal in einem Verzeichnis). Die Beispiele fänden in der Binary Platz die ich hierzu ganz einfach nach dem namespace strukturieren würde ( 0 => wikidata, 6 => examples).

Text::MediawikiFormat ist ein CPAN Modul was eingebetteten Beispielkode als Solchen erkennt sowie die ===Headlines=== und '''emTags''' einwandfrei formatieren bzw. rendern kann. Wie src- und href- Attribute transformiert werden sollen kann man optional einstellen. Problem sind nur die Tabellen.

MfG Schönes Wochenende!

[pl]

Tach!

Kann das nicht die Wikisoftware selbst erledigen!?

Das war der Hauptgrund, warum ich diese zusammen mit einem Webserver ausliefere. Jede Menge Zeugs, das von Mediawiki erledigt wird, wollte ich nicht nacherfinden. Das wäre nämlich auch keine einmalige Sache, denn Mediawiki wird immer noch aktiv weiterentwickelt.

Eine Möglichkeit wäre, die API (Webservice) zu nutzen:

print 
$json->decode(get "https://wiki.selfhtml.org/api.php?action=parse&page=XML/XSL/XPath&format=json")->{parse}->{text}{'*'};

Und das sieht schonmal ganz gut aus, auch die Tabelle ist gerendert. Ich guckmal inwieweit das noch etwas ansprechbarer und natürlich auch funktional aufgearbeitet werden kann (styles mit reinnehmen, links für offlinemodus anpassen).

~4000 Seiten abzurufen dürfte 1..2 Stunden dauern, welche das sind steht ja in sqlite und euer Server hat ein dickes Fell nehme ich an 😉

MfG

[dedlfix]

Tach!

~4000 Seiten abzurufen dürfte 1..2 Stunden dauern, welche das sind steht ja in sqlite und euer Server hat ein dickes Fell nehme ich an 😉

Setz dir dazu doch lieber eine eigene Installation auf. Die bekommst du ja mit dem Offline-Komplett-Paket. Dann kannst du solche Massenanfragen im lokalen Netzwerk abhandeln. Das schont alle ansonsten Beteiligten.

dedlfix.

[dedlfix]

Tach!

Achja, es wäre auch günstiger, ein Maintenance-Script aufzusetzen, das geht noch direkter als über Webserver und API-Request-Abarbeitung.

dedlfix.

[pl]

Klasse Idee!!!!!!

Der Parser wirds dann wohl sein mit dem ich mich demnächst anfreunde 😉

Schönes Wochenende!

[pl]

Nur die Beispiele aus Namespace 102. Kein Problem also den Sqlite-Auszug als Base64 in die Seite in einem Script-Bereich einzubetten.

Viel Spaß beim Testen. MfG

[Rolf B]

Hallo pl,

ich bin beeindruckt, in wie kurzer Zeit Du an diesen Punkt gekommen bist. Natürlich ist auch Dir klar, dass das nur ein Trittstein auf dem Weg zum Ziel ist.

Ein paar Fakten, die ich bemerkt habe:

Die Seite braucht bei mir knapp 2s zum Laden, das ist viel. Die meiste Zeit vergeht in deinem handgemachten base64-Konverter - hast Du Dir schonmal window.btoa() angeschaut?

Zwei .js Dateien (txtwiki und wiky) werden mit 410-Gone quittiert.

Das popup "Daten sind geladen" verschwindet nicht von allein (z.B. wenn man was ins Suchfeld eingibt), man muss draufklicken.

Die Suchfunktion mit input und datalist ist für erste Schritte akzeptabel, für das eigentlich Offline-Wiki wirst Du etwas anderes bauen müssen. Die Suche ist zu langsam. Das liegt natürlich daran, dass input die datalist sequenziell mit einer Art "contains" durchsucht. Das Wiki sucht nach Wortpräfixen für die Suchwortliste, präsentiert nur die ersten 10 Treffer und kann, weil es Präfixe sind, einen Wortindex nutzen. Den Wortindex kann man beim Compilieren der Daten aufbauen und mitliefern

Ich bin gespannt, wie es weitergeht. Insbesondere musst Du ja, außer dem Rendering-Klotz, noch das Thema Intrawiki-Links lösen.

Rolf

[pl]

hi Rolf,

Die Seite braucht bei mir knapp 2s zum Laden, das ist viel. Die meiste Zeit vergeht in deinem handgemachten base64-Konverter - hast Du Dir schonmal window.btoa() angeschaut?

Für Binaries ist window.btoa() absolut unbrauchbar. Ansonsten sind doch 2 Sekunden zum Download einer kompletten Offline-Version nicht zu lang oder!?

Zwei .js Dateien (txtwiki und wiky) werden mit 410-Gone quittiert.

Hatte ich vergessen.

Die Suchfunktion mit input und datalist ist für erste Schritte akzeptabel, für das eigentlich Offline-Wiki wirst Du etwas anderes bauen müssen.

Wenn die Dokumente aussagekräftige Titel hätten, wäre diese Art von Suche völlig ausreichend. Und Wenn ich die Suchfunktion auf die Inhalte setze, fällt mir genau dieses Problem bei der Auflistung der Ergebnisseiten ein zweites Mal auf die Füße.

Ich bin gespannt, wie es weitergeht. Insbesondere musst Du ja, außer dem Rendering-Klotz, noch das Thema Intrawiki-Links lösen.

Das ist kein Problem. Die Beispiel:Links der ns0-Inhalte werde ich so umbauen, daß sie für JS auf die Namen der namespace 102 Inhalte verweisen. Und für die img src-Atribute werden einfach die Pfadangaben rausgenommen. Allerdings haben auch Einige der ns 102 Inhalte interne Wikilinks die offline ins Leere zeigen würden.

Die Datenstruktur der Binary (als Base64 eingebettet) sieht im Hauptspeicher so aus:

BIN = {
  examples: { seite: inhalt,.. } // ca 1300 Dokumente, ns 102
  contents: { title: inhalt,.. } // ca 1934 Dokumente, ns 0
};

wobei jede Einzelseite, genau wie im Wiki, über den Seitentitel adressierbar ist. MfG

[Rolf B]

Hallo pl,

Für Binaries ist window.btoa() absolut unbrauchbar.

Einverstanden. Aber welche Binaries wirst Du denn hier verwalten müssen? Es geht um Wikisource - Text. HTML/CSS/JS Beispiele - Text. Eventuell noch Bilder: Die kann man isoliert b64 codieren und einbetten, und dann bei Bedarf decodieren.

Die Binaries, die Du im Moment hast, sind Längenangaben zu E, A und V - die brauchst Du nicht wenn Du dein EAV-Modell als JSON stringifizierst.

Ansonsten sind doch 2 Sekunden zum Download einer kompletten Offline-Version nicht zu lang oder!?

Es ist aber nicht komplett und wird darum nicht bei 2s bleiben. Ich habe mir eine echte Offline-Version deiner Seite gezogen und darin Date.now() Ausgaben gemacht;

startHead to startBody    : 9
startBody to scriptsLoaded: 25
scriptsLoaded to enterInit: 77
enterInit to atLoad       : 62
atLoad to gotText         : 4
gotText to decoded        : 1053
decoded to eavBuilt       : 175
eavBuilt to ready         : 16

startHead ist eine Zeitmarke, die ich in dem Script setze wo Du die SID setzt. startBody ist in einem eigenen Script direkt hinter dem <body> Tag scriptsLoaded in in einem eigenen Script direkt VOR dem Data-Block enterInit ist am Anfang deines Init-Scripts, direkt vor der Definition von loadbody atLoad ist am Anfang des onload-Handlers gotText zwischen den Aufrufen von .text() und .decode() decoded zwischen den Aufrufen von .decode() und .buffer2eav() eavBuild ist nach der Rückkehr von buffer2eav ready ist am Ende des onload-Handlers, vor dem pretext Aufruf.

Die b2a Decodierung benötigt also 3/4 der Laufzeit. Es könnte sich lohnen, für deine EAV über eine nicht-binäre Codierung nachzudenken.

Rolf

[pl]

Hi,

Für Binaries ist window.btoa() absolut unbrauchbar.

Einverstanden. Aber welche Binaries wirst Du denn hier verwalten müssen?

Da gibt es nichts zu verwalten. Die Binary wird zur Laufzeit erstellt, in dem Moment wenn jemand eine aktuelle Version haben möchte: Download der Binary um diese dann lokal über die FileAPI (input type="file") der SPA zuführen zu können.

Base64 is nur eine Alternative, nämlich um die Binary direkt ins HTML einzubetten (davon werde ich jedoch abkommen).

Es geht um Wikisource - Text. HTML/CSS/JS Beispiele - Text. Eventuell noch Bilder: Die kann man isoliert b64 codieren und einbetten, und dann bei Bedarf decodieren.

Nein, Bei den Datenmengen, die Binary hat 25MB und das ist nur text, werden die Bilder nicht auch noch eingebaut sondern native neben die SPA in ein lokales Verzeichnis gelegt. Ich gehe mal davon aus daß es da keine doppelten Dateinamen gibt.

Die Binaries, die Du im Moment hast, sind Längenangaben zu E, A und V - die brauchst Du nicht wenn Du dein EAV-Modell als JSON stringifizierst.

Wenn ich die Binary mit weit über 30MB als JSON in <script type='text/plain'> einbette rendert sich der Browser zu Tode 😉 Base64 hingegen ist neutral, da passiert das nicht.

JSON vergessen wir mal lieber ganz schnell. Ich werde tunlichst bei einer Binary bleiben die explizit als Dowload angefordert werden muss, und welches Format diese Datei haben wird, hängt davon ab was der Browser bei diesen DatenUnmengen verarbeiten kann ohne sich aufzuhängen.

Ansonsten sind doch 2 Sekunden zum Download einer kompletten Offline-Version nicht zu lang oder!?

Es ist aber nicht komplett und wird darum nicht bei 2s bleiben.

Natürlich nicht. Der Anwender muss eine 30-MB-Datei downladen wenn er aktuelle Daten haben will. Serverseitig würde dieser Schritt vollautomatisch und wartungsfrei ablaufen.

Aufwand erfordert das Bereitstellen der Images, aber auch dieses Download als ZIP könnte automatisiert werden. Der Anwender muss die Bilder nur noch in ein lokales Verzeichnis auspacken.

Die SPA selbst hat nur ein paar kBytes und das Download beschränkt sich auf ein Speichern unter.. dieser Datei.

Alles in Allem ist das kein Vergleich zu einer Komplettinstallation der Wikisoftware.

Schönen Sonntag 😉

[pl]

hi Rolf

JSON vergessen wir mal lieber ganz schnell. Ich werde tunlichst bei einer Binary bleiben die explizit als Dowload angefordert werden muss, und welches Format diese Datei haben wird, hängt davon ab was der Browser bei diesen DatenUnmengen verarbeiten kann ohne sich aufzuhängen.

Kaum zu glauben, nun isses doch ein JSON geworden 😉 Hier die erste WikiVersion zum Testen.

Binary (JSON) download und los gehts. Ich guck jetzt mal was ich an originCSS brauche und werde das noch reinschmacken.

Das Nächste sind die Links zu den Beispielen und zum Schluss kommen die Images'src dran.

Und ich denke, dieser Aufwand hat sich bis hierhin schon gelohnt!

Schönen Sonntag 😉

[Rolf B]

Hallo pl,

Kaum zu glauben, nun isses doch ein JSON geworden 😉

Ich lach mich wech 😂 - hast Du bestimmt auch gemacht.

Wie lange hat die b64 to eav Konvertierung bei voller Größe gedauert?

Wiki2HTML Konvertierung hast Du nun selbst geschnitzt oder das Wiki-API genommen?

Und ich denke, dieser Aufwand hat sich bis hierhin schon gelohnt!

Top!

Rolf

[pl]

Hi Rolf,

Kaum zu glauben, nun isses doch ein JSON geworden 😉

Ich lach mich wech 😂 - hast Du bestimmt auch gemacht.

Ja 😉

Wie lange hat die b64 to eav Konvertierung bei voller Größe gedauert?

Der Browser hat sich aufgehängt. Out of Memory. War wohl ein Bit zuviel 😉

Wiki2HTML Konvertierung hast Du nun selbst geschnitzt oder das Wiki-API genommen?

Hab heute morgen in aller Herrgottsfrühe die Webs-API angezapft. Mit sleep 1 nach jedem Request.. als einmalige Sache. War nach'ner Stunde erledigt 😉 (t'schuldigung dedlfix)

Die Beispieldateien hab ich lokal aus sqlite gozogen (page_namespace 102).

ToDo: Style's anpassen. Hast Du mal einen Link zur Legacy-Haupt-CSS-Datei? Ein paar Styles hab ich schon übernommen, sieht gut aus. Per css kann ich auch Dingens verschwinden lassen die offline ohnehin nicht funktionieren würden (z.B. [Bearbeiten] und Iconset).

Bin grad dabei die a-Tags umzuschießen damit die Beispiele funktionieren. Machbar ist alles, braucht nur alles seine Zeit. Eine SuchFunktion auf RegEx-Basis sollte auch zu machen sein -- eine Sache für lange Winterabende 😉

Schönen Sonntag 😉

[Rolf B]

Hallo pl,

a-Tags musst Du nicht umschießen, ein Eventhandler auf #out kann live reagieren.

Die CSS werden offenbar dynamisch geladen:

<link rel="stylesheet" href="/load.php?debug=false&amp;lang=de-formal&amp;modules=ext.smw.style%7Cext.smw.tooltip.styles&amp;only=styles&amp;skin=selfhtml"/>
<link rel="stylesheet" href="/load.php?debug=false&amp;lang=de-formal&amp;modules=mediawiki.legacy.commonPrint%2Cshared%7Cmediawiki.sectionAnchor%7Cmediawiki.skinning.interface%7Cskins.selfhtml&amp;only=styles&amp;skin=selfhtml"/>
<meta name="ResourceLoaderDynamicStyles" content=""/>
<link rel="stylesheet" href="/load.php?debug=false&amp;lang=de-formal&amp;modules=site&amp;only=styles&amp;skin=selfhtml"/>

Was der meta zu bedeuten hat weiß ich nicht.

Rolf

[Rolf B]

Hallo pl,

ich bin überrascht, wie schnell die datalist in der vollen Ausbaustufe durchsucht wird. Trotzdem glaube ich, dass die Suche über eine datalist noch überarbeitet werden muss, wenn ich "A" eingebe, bekomme ich im Online-Wiki das A Element als erstes; das ist eigentlich sinnvoll so.

Dann habe ich ein bisschen an deinem Code gebastelt - jQuery kann man schnell rauswerfen statt es einzubetten. Soo viel machst Du damit nicht, und das sind unnötige Kilobytes in der SPA. Andererseits - das ist eine Einmalaktion, und es könnte auch übersichtlicher sein, HTML, CSS und JS in einzelnen Dateien zu belassen, statt ein einziges HTML zu haben.

Dein HTML kann man auch noch verschönern:

• Inline-Styles
• strong Element (willst Du eine fette Darstellung oder willst Du aussagen, dass die legend besonders wichtig ist?)
• on... Eventhandler
• JavaScript als Modul

aber das sind zum jetztigen Zeitpunkt sicherlich nachrangige Dinge.

Das Wiki CSS sollte man mit #out prefixen, damit die Wiki-Regeln NUR für den Wiki-Text gelten.

Bilder (wie iconset) brauchen wohl ein Postprocessing des HTML.

Links zu catchen ist mir relativ schnell gelungen, für das Abfangen des Back-Buttons muss ich noch mit den History-API spielen. Hast Du's eh schon fertig oder bist Du an meinen Spielereien interessiert?

Rolf

[pl]

hi,

Links zu catchen ist mir relativ schnell gelungen, für das Abfangen des Back-Buttons muss ich noch mit den History-API spielen. Hast Du's eh schon fertig oder bist Du an meinen Spielereien interessiert?

Ne, das ist noch langenicht fertig 😉 Aber wenn Du auch was hast, stells doch einfach life. An der JSON-Datei ändert sich ja vorerst nichts.

Die internen WikiLinks haben allesamt den prefix /wiki/ Daran kann man sie erkennen und per onclickEvent der SPA übergeben so daß zuerst das inputfeld gefüllt und danach das Dokument geladen wird. Etwaige Fragmente müssen dafür abgeschnitten werden.

Externe CSS/JS-Dateien: Serverseitig kein Poblem, ich binde die ganz einfach per Template ein. Ausgeliefert sollte die SPA jedoch als OneFileSPA verbleiben, ich sehe keinen Grund daß sich der Anwender mit externen CSS-Dateien rumschlagen sollte. Offline Betrieb ist das Ziel.

Speichern unter... und gut isses. Funktioniert auch einwandfrei. Bei den img'src's die Pfade raus (JavaScript, todo), die Grafiken nebendran gelegt und schon wirds bunt 😉

Eigentlich überschaubar, was noch zu tun ist 😉

Schönen Sonntag!

[Rolf B]

Hallo pl,

Die internen WikiLinks haben allesamt den prefix /wiki/ Daran kann man sie erkennen und per onclickEvent der SPA übergeben so daß zuerst das inputfeld gefüllt und danach das Dokument geladen wird. Etwaige Fragmente müssen dafür abgeschnitten werden.

So hab ich's gemacht - an Fragmente aber nicht gedacht... Ich bastele mal dran rum...

Externe CSS/JS-Dateien: Serverseitig kein Poblem, ich binde die ganz einfach per Template ein. Ausgeliefert sollte die SPA jedoch als OneFileSPA verbleiben, ich sehe keinen Grund daß sich der Anwender mit externen CSS-Dateien rumschlagen sollte. Offline Betrieb ist das Ziel.

Speichern unter... und gut isses.

Schon. Aber: der Anwender muss für die Images sowieso ein ZIP auspacken. Da kann man dann auch das HTML File und seine Satelliten hinzufügen. Es ist für die Wartung deinerseits (unsererseits) leichter, finde ich.

Eigentlich überschaubar, was noch zu tun ist 😉

Mal gucken, welche Tretminen noch auffallen 😀

Rolf

[pl]

Hi Rolf,

Schon. Aber: der Anwender muss für die Images sowieso ein ZIP auspacken. Da kann man dann auch das HTML File und seine Satelliten hinzufügen. Es ist für die Wartung deinerseits (unsererseits) leichter, finde ich.

Guck mal:

    foreach my $file(qw(x.css y.css asdf.css foo.css bar.css)){
        my $fh = IO::File->new;
        $fh->open("$ENV{DOCUMENT_ROOT}/$file", "r") or die "$!\n";
        read($fh, my $buffer, -s $fh);
        $fh->close;
        $self->{STASH}{style} .= $buffer; # Platzhalter/Template
    }

D.h.: Für die Wartung liegen dedizierte Dateien vor. Da muss der Wartfred nicht an den Code welcher die SPA erstellt. Und der Anwender kriegt mit einem EINZIGEN Speichern unter.. eine aktuelle Version ALLER Styles. Wenn schon SPA dann richtig 😉

MfG

[dedlfix]

Tach!

Guck mal:

[Perl-Code]

Auch ein Punkt, der wesentlich zum Wartungsaufwand beiträgt. Perl ist eine Sprache, die ich nicht kann und auch nicht nur wegen dieses einen Falles lernen möchte. Damit habe ich keine Erfahrung und habe auch keine Projekte, an denen ich Erfahrung sammeln kann, geschweige denn, dass ich irgenwelche Vorteile darin sehen, Projekte in Perl statt etwas anderem und mir bereits bekanntem aufzusetzen. Eine Lösung in Perl ist damit so gut wie nicht wartbar.

    foreach my $file(qw(x.css y.css asdf.css foo.css bar.css)){

Wenn es denn so einfach wäre, ein paar Dateien auszulesen. Mediawiki hat neben statischen Dateien auch Wiki-Seiten in einem speziellen Namensraum, in dem solche Ressourcen stecken. Einige Ressourcen werden erst zur Laufzeit nachgeladen. Und deswegen gibt es einen Mechanismus, der dafür sorgt, dass bei Abhängigkeiten die richtige Reihenfolge des Ladens und Ausführens von Javascript eingehalten wird.

dedlfix.

[pl]

Tach!

Guck mal:

[Perl-Code]

Auch ein Punkt, der wesentlich zum Wartungsaufwand beiträgt.

Ich verstehe nicht warum Du dich daran aufhängst. In welcher Scriptsprache die SPA erstellt wird, ist doch vollkommen Wurscht. Das Ergebnis ist HTML, ein bischen CSS und ein bischen JS und das kann sich mittlerweile sehen lassen weil:

Es funktioniert als OneFileAPI nach einen speichern unterr.. einwandfrei, auch die Beispiels.

So stelle ich mir eine OfflineVersion vor und die internen Links kriege ich auch noch hin.

MfG

[dedlfix]

Tach!

Auch ein Punkt, der wesentlich zum Wartungsaufwand beiträgt.

Ich verstehe nicht warum Du dich daran aufhängst. In welcher Scriptsprache die SPA erstellt wird, ist doch vollkommen Wurscht.

Ja, solange man nie wieder was dran ändern muss. MediaWiki ist aber in seiner Entwicklung noch nicht abgeschlossen. Ebensowenig glaube ich, dass du einen vollkommen fehlerfreien Exporter hinbekommen wirst. Irgendeinen Punkt übersieht man immer. Und in solchen Fällen heißt es, Anpassungen vorzunehmen, weswegen die Möglichkeit zum Ändern ein wesentlicher Punkt ist.

dedlfix.

[pl]

Tach!

Auch ein Punkt, der wesentlich zum Wartungsaufwand beiträgt.

Ich verstehe nicht warum Du dich daran aufhängst. In welcher Scriptsprache die SPA erstellt wird, ist doch vollkommen Wurscht.

Ja, solange man nie wieder was dran ändern muss. MediaWiki ist aber in seiner Entwicklung noch nicht abgeschlossen. Ebensowenig glaube ich, dass du einen vollkommen fehlerfreien Exporter hinbekommen wirst. Irgendeinen Punkt übersieht man immer. Und in solchen Fällen heißt es, Anpassungen vorzunehmen, weswegen die Möglichkeit zum Ändern ein wesentlicher Punkt ist.

Ja natürlich. Das größte Problem in Sachen Wartungsfreundlchkeit ist das Wiki selbst. Aber das habe ich ja schon vor ein paar Tagen festgestellt. Eine Dokumentenhierarchie in den Titlen abzubilden mag ja noch angehen. Die Interne Verlinkung geht jedoch in dem Moment schief, wenn eine Weiterleitung ins SPiel kommt, z.B. von JavaScript/Ajax => /JavaScript/Ajax/XMLHttpRequest => JavaScript/XMLHttpRequest das ist beim Datenexport nicht konsistent.

Man könnte ja die class="mw-redirect" befragen, aber um rauszukriegen wo der Link tatsächlich hinführt, müsste man eine entsprechende Übersetzungstabelle haben.

Der Einstieg über HTTP ist jedoch ein Beispiel wo die Verlinkung ganz gut klappt. Ich werd' mal die history mitschneiden.. 'MfG

[pl]

hi,

Man könnte ja die class="mw-redirect" befragen, aber um rauszukriegen wo der Link tatsächlich hinführt, müsste man eine entsprechende Übersetzungstabelle haben.

Hat man:

$VAR1 = [
          {
            'body' => '#WEITERLEITUNG [[CSS/Kaskade#.21important]]',
            'name' => '!important'
          },
          {
            'body' => '#WEITERLEITUNG [[Webserver/htaccess]]',
            'name' => '.htaccess'
          }
        ];

Ich hatte das bisher nur rausgenommen, kein Problem das wieder reinzunehmen. Danach gibts auch keine kaputten links mehr. MfG

[Rolf B]

Hallo pl,

Weiterleitungsseiten sollte man eigentlich automatisiert erkennen und verarbeiten können, ohne eine zu pflegende Übersetzungstabelle. Problem ist aktuell, dass die Weiterleitungsseiten nicht in deiner .bin existieren (Beispiel XMLHttpRequest). Wenn die drin wären, könnte man den redirect automatisiert verarbeiten.

Rolf

[pl]

Hi Rolf

Weiterleitungsseiten sollte man eigentlich automatisiert erkennen und verarbeiten können, ohne eine zu pflegende Übersetzungstabelle. Problem ist aktuell, dass die Weiterleitungsseiten nicht in deiner .bin existieren (Beispiel XMLHttpRequest). Wenn die drin wären, könnte man den redirect automatisiert verarbeiten.

Ich mach jetzt Pause. Danach sind die Weiterleitungen drin, Achtung: Neue Binary zum Download

Bis dann 😉

[pl]

Hi Rolf

Weiterleitungsseiten sollte man eigentlich automatisiert erkennen und verarbeiten können, ohne eine zu pflegende Übersetzungstabelle. Problem ist aktuell, dass die Weiterleitungsseiten nicht in deiner .bin existieren (Beispiel XMLHttpRequest). Wenn die drin wären, könnte man den redirect automatisiert verarbeiten.

Ich mach jetzt Pause. Danach sind die Weiterleitungen drin, Achtung: Neue Binary zum Download

Done. Guck mal 😉

Download der neuen Binary nicht vergessen!

[Christian Kruse]

Hallo pl,

ich finde es gut, dass du dich an der Aufgabe versuchst. Leider glaube ich, dass du nicht so richtig siehst, wo denn eigentlich das Problem ist.

Das Problem war nicht, eine Suche zu bauen, die auch offline funktioniert. Das Problem ist, dass man die Wahl hat zwischen zwei Lösungsansätzen: entweder man scraped das HTML ab und erstellt so eine Offline-Version oder man erstellt eine Offline-Version aus den Roh-Daten.

Die erste Variante hat das Problem, dass das MediaWiki Styles dynamisch lädt, aus diversen Dateien und zusätzlich eine Art Loader-Framework im JS hat, mit dem es Daten (weiteres JS und CSS) lädt. Man müsste also das JS umschreiben, mit dem das getan wird, und herausfinden, welche Ressourcen wo benötigt werden.

Die zweite Variante hat das Problem, dass man ein neues Layout, einen Wiki-Parser und ein Script erstellen müsste, mit dem man die ganzen HTML-Dokumente erzeugt. Weiterhin bleiben noch ein paar Details zu klären.

Deine Lösung krankt auch an diesem Problem: du hast scheinbar die Meta-Daten komplett entfernt und lieferst die Styles und das JS vom Wiki gar nicht mit. Links auf andere Seiten des Wikis führen zu 404. Bilder werden nur teilweise geladen. Jetzt fängt die eigentliche Arbeit erst an…

LG,
CK

[pl]

Moin,

ich finde es gut, dass du dich an der Aufgabe versuchst. Leider glaube ich, dass du nicht so richtig siehst, wo denn eigentlich das Problem ist.

Das Problem war nicht, eine Suche zu bauen, die auch offline funktioniert. Das Problem ist, dass man die Wahl hat zwischen zwei Lösungsansätzen: entweder man scraped das HTML ab und erstellt so eine Offline-Version oder man erstellt eine Offline-Version aus den Roh-Daten.

Letzereres. Die Bereitstellung der Downloaddaten beschränkt sich auf eine DB-Abfrage mit dessen Ergebnis eine JSONDatei erstellt wird. Ein hierzu administrativer Aufwand ist praktisch gleich NULL.

du hast scheinbar die Meta-Daten komplett entfernt und lieferst die Styles und das JS vom Wiki gar nicht mit.

Die wichtigsten Styles habe ich schon eingebaut. Auch die Beispiele werden vollständig funktionieren resp. SELFHTML-Beispiel-Grundlayout.css -- die Daten liegen alle vor.

Links auf andere Seiten des Wikis führen zu 404. Bilder werden nur teilweise geladen. Jetzt fängt die eigentliche Arbeit erst an…

Was da noch zu tun ist, schrieb ich bereits. Leider haben nicht alle Links einen className like beispiel_url aber alle wikiinternen Links haben zumindest denselben Prefix. Also ist das Alles machbar und die Klicks auf Beispiel ansehen funktioniern ja bereits.

MfG

[Christian Kruse]

Hallo pl,

Also ist das Alles machbar […]

Das hat keiner bestritten. Wir sprachen davon, dass es ein unverhältnismässig hoher Aufwand ist.

LG,
CK

[dedlfix]

Tach!

Letzereres. Die Bereitstellung der Downloaddaten beschränkt sich auf eine DB-Abfrage mit dessen Ergebnis eine JSONDatei erstellt wird. Ein hierzu administrativer Aufwand ist praktisch gleich NULL.

Das war die kleinste Herausforderung an der Geschichte. Der Aufwand beginnt dann, alle Mechanismen herauszufinden, die man braucht, um eine bedienbare Offline-Version erstellen zu können. Und wenn eine neue Version Änderungen mitbringt, diese zu erkennen und einzubauen, oder vielleicht von vorn zu beginnen, den Seitenrahmen zu erstellen und alle benötigten Ressourcen zusammenzutragen. Das ist der eigentliche Aufwand und der hat einen deutlichen Abstand zu Null.

dedlfix.

[pl]

Und Schwubs gehen die internen Wiki Links

[Matthias Apsel]

Hallo pl,

Bis demnächst
Matthias

[pl]

hi

Und was willst Du mir damit sagen!?

Ein paar (viele) interne Links sind übrigens defekt, guckt mal nach ajax und xmlhttprequest.

MfG

[Matthias Scharwies]

Servus!

Ein paar (viele) interne Links sind übrigens defekt, guckt mal nach ajax und xmlhttprequest.

Diese Links gehen auf (noch) nicht existierende Seiten, für die es jedoch Weiterleitungen (#redirect [[Seitenname]]) gibt.

MfG

Herzliche Grüße

Matthias Scharwies

[dedlfix]

Tach!

Ein paar (viele) interne Links sind übrigens defekt, guckt mal nach ajax und xmlhttprequest.

Konkretes Beispiel bitte. Einige Links sind absichtlich (noch) defekt, weil sie auf Seiten verweisen, die noch nicht existieren. So ist die Arbeitsweise in einem Wiki. Abgesehen von Fehlern verlinkt man schon mal Stichwörter, zu denen die Zielseite noch nicht existiert, so dass man diese Links schon hat und nicht erst bis zum Seitenerstellen warten muss, um dann überall rumzuschauen, wo man Links einfügen könnte. Gewünschte Seiten.

dedlfix.

[Matthias Apsel]

Hallo pl,

Und was willst Du mir damit sagen!?

Nix. Deshalb mit Humor getagt.

Bis demnächst
Matthias

[JürgenB]

Hallo Rolf,

kannst du mir bitte mal erklären, wie ich dein Offline-Wiki nutzen kann?

Ich gehe auf die verlinkte Seite, lade die Binary runter und wähle Sie aus. Wenn ich jetzt in das Suchfeld „html“ eingebe, kommt die Meldung „Das Dokument wurde nicht gefunden!“.

Gruß
Jürgen

[pl]

Hallo Rolf,

kannst du mir bitte mal erklären, wie ich dein Offline-Wiki nutzen kann?

Ich gehe auf die verlinkte Seite, lade die Binary runter und wähle Sie aus. Wenn ich jetzt in das Suchfeld „html“ eingebe, kommt die Meldung „Das Dokument wurde nicht gefunden!“.

Nach der Eingabe warten was die datalist als Auswahl zeigt, HTML ist auf jeden Fall dabei. Und das ist case-sensitive genauso wie im Life-Wiki.

[JürgenB]

Hallo Rolf,

planst du auch noch eine Startseite?

Gruß
Jürgen

[pl]

Hi Jürgen

planst du auch noch eine Startseite?

Das nicht aber mit den richtigen Styles sieht Mein Wiki doch schon richtig geil aus 😉

MfG

PS: Als Nächstes werde ich die redirekts auflösen. Und history.push..

[JürgenB]

Hallo Rolf,

Hi Jürgen

planst du auch noch eine Startseite?

Das nicht aber mit den richtigen Styles sieht Mein Wiki doch schon richtig geil aus 😉

kann ich nicht beurteilen, weil ich nicht weiß, wonach ich suchen soll.

Gruß
Jürgen

[pl]

Hi Jürgen

planst du auch noch eine Startseite?

Das nicht aber mit den richtigen Styles sieht Mein Wiki doch schon richtig geil aus 😉

kann ich nicht beurteilen, weil ich nicht weiß, wonach ich suchen soll.

Da habe ich was für Dich: gib JavaScript ins Suchfeld ein, drücke Enter und dann klicke Dich mal durch. Du bekommst den SelfWiki im gewohnten Aussehen, Vor- /Zurücknavigation funktioniert und wenn Du auf den LifeWiki gehen willst, klick auf die Überschrift unter dem Suchfeld (gibt neues Fenster).

MfG

[Rolf B]

Hallo dedlfix,

die Überlegung ist doch auch, welchen Aufwand ein Offline-Nutzer hat. Eine Lösung aus 2 Dateien - eine Driver-SPA aus optimalerweise einer Datei, ggf. ein Images-ZIP, dazu eine Datendatei, das ist schon fast DAU geeignet. Eine nginx Installation dagegen nicht.

Rolf

[dedlfix]

Tach!

die Überlegung ist doch auch, welchen Aufwand ein Offline-Nutzer hat. Eine Lösung aus 2 Dateien - eine Driver-SPA aus optimalerweise einer Datei, ggf. ein Images-ZIP, dazu eine Datendatei, das ist schon fast DAU geeignet. Eine nginx Installation dagegen nicht.

Deswegen habe ich ein Script geschrieben, das die benötigten Dateien an Ort und Stelle legt. Das ist also ohne weitere Kentnisse mit sehr wenigen Handgriffen erledigt. Du darfst das gern mal probieren und Feedback geben.

dedlfix.

[pl]

Tach!

die Überlegung ist doch auch, welchen Aufwand ein Offline-Nutzer hat. Eine Lösung aus 2 Dateien - eine Driver-SPA aus optimalerweise einer Datei, ggf. ein Images-ZIP, dazu eine Datendatei, das ist schon fast DAU geeignet. Eine nginx Installation dagegen nicht.

Deswegen habe ich ein Script geschrieben, das die benötigten Dateien an Ort und Stelle legt. Das ist also ohne weitere Kentnisse mit sehr wenigen Handgriffen erledigt. Du darfst das gern mal probieren und Feedback geben.

Mein Feedback kriegst Du immer wieder gerne: Für'n Offline Wiki einen lokalen Webserver installieren zu müssen ist ein absolutes No Go. Von der Datenmenge ganz abgesehen.

Schöne Grüße.

[Matthias Apsel]

Hallo pl,

Mein Feedback kriegst Du immer wieder gerne: Für'n Offline Wiki einen lokalen Webserver installieren zu müssen ist ein absolutes No Go. Von der Datenmenge ganz abgesehen.

Du wiederholst dich.

Bring dein Projekt zu ende, schreib ne Anleitung, was auf Geber- und was auf Nehmerseite zu tun ist, und dann können wir es meinetwegen gern verwenden, wenn ich eine Unbedenklichkeitserklärung bekomme.

Bis demnächst
Matthias

[pl]

Moin,

ich werde hier einen Bericht ablegen. Fakt ist, eine SPA dieser Größenordnung ist machbar und mit der Nutzung lokaler Speichermöglichkeiten die moderne Browser bieten kann man sogar die Daten im Browser selbst persistent machen so daß ein Laden der Datei nur noch für Updates notwendig ist.

MfG

[Rolf B]

Hallo dedlfix,

hätte ich gerne mal. Aber https://selfhtml.org/offlinewiki/selfhtml-wiki-komplett.zip ist tot?

Ich habe mir also ein Alt-PHP geholt, musste mich wieder dran erinnern dass man in der PHP.INI das extension_dir setzen muss, weil sonst die Extensions nicht gefunden werden 😂, hab mir im ohnehin vorhandenen (bzw als Windows-Feature aktivierbaren) IIS eine FastCGI Application dafür eingerichtet, das MediaWiki und das Daten-ZIP ausgepackt und es hat funktioniert.

Und dann fiel mir auf, dass dein Daten-ZIP recht alt ist, mein Testbeispiel für Redirektionen war die JavaScript/JSON seite, die auf XMLHttpRequest verlinkt - aber das ist nur online so, im Offline-Wiki nicht. Das hat einen Stand von vor ca. eineinhalb Jahren. Wenn PL den Live-Stand basierend auf der Datenbasis des Offline-Wiki gerendert hat, dann passt seine .bin Datei wohl nicht.

Was mich auch etwas stört, ist, dass das Mediawiki-Paket ungefiltert ist; da sind Unit-Tests drin, Sprachen für die ganze Welt und diverse Extensions die nur für die editierbare Version wichtig sind. Man kann den Download um ein Drittel abstrippen, wenn man das entfernt, aber ok. Aufwand halt...

Ansonsten lief das recht geschmeidig, ist aber ohne Script keinesfalls DAU geeignet.

Rolf

[dedlfix]

Tach!

hätte ich gerne mal. Aber https://selfhtml.org/offlinewiki/selfhtml-wiki-komplett.zip ist tot?

Das war noch die falsche URL. Zwei Absätze weiter oben stand schon die richtige. Jetzt auch unten.

Und dann fiel mir auf, dass dein Daten-ZIP recht alt ist, mein Testbeispiel für Redirektionen war die JavaScript/JSON seite, die auf XMLHttpRequest verlinkt - aber das ist nur online so, im Offline-Wiki nicht. Das hat einen Stand von vor ca. eineinhalb Jahren.

Der Datenbestand ist vom 20. Januar dieses Jahres. Bei mir leitet JavaScript/JSON zu JSON weiter, offline wie online.

Was mich auch etwas stört, ist, dass das Mediawiki-Paket ungefiltert ist; da sind Unit-Tests drin, Sprachen für die ganze Welt und diverse Extensions die nur für die editierbare Version wichtig sind. Man kann den Download um ein Drittel abstrippen, wenn man das entfernt, aber ok. Aufwand halt...

Ja, dazu müsste ich genau wissen, was weg kann und was nicht. Verzeichnisse beim Kopieren zu exkludieren ist ja nicht das Thema.

Ein Drittel halte ich aber für zu hoch gegriffen. Das wären 70 MB, aber der Mediawiki-Anteil ist nur 50 MB. Da bleiben am Ende minus 20MB für den Code übrig und da wüsste ich nicht, wie man den da reinbekommen soll …

dedlfix.

[Rolf B]

Hallo dedlfix,

bei mir reduziert sich der MediaWiki-Footprint von 180 Megabyte auf 83,8 Megabyte (Mega=Million). Über 50 Mega in languages (habe nur die de und en Sprachen behalten), 8 Meg in extensions (SemanticMediaWiki hat i18m und tests, SemanticResultFormats hat i18n, WikiEditor), 6 Meg tests, der LM Ordner in vendor/wikimedia/textcat, es läppert sich.

Es gibt noch ein paar Ordner mehr, aber ich habe nur die Brocken angeschaut. Ich hatte allerdings nicht gezippt, und habe es jetzt mal als Solid RAR komprimiert: 103 Megabyte (WinZIP hab ich nur im Büro, nicht zu Hause) für MediaWiki und SQLite-DBs von SelfHTML.

Der Grund, warum meine Daten veraltet waren, liegt in der Installationsbeschreibung. Es gibt die Ordner offline-wiki und offlinewiki, in der Beschreibung ist offlinewiki verlinkt und das ist offenbar veraltet.

Das neue Datenpaket ist verbesserungsfähig: das install.cmd trennt nicht zwischen Daten- und Mediawiki-Installation. Ich brauche keine PHP.INI oder NGINX.CONF, wenn ich Daten updaten will. Das kann mir im Gegenteil auf die Füße fallen, falls ich meine php.ini angepasst hatte.

Bei den Bildern scheint mir images/thumb merkwürdig, vielleicht voller Leichen: Die Thumbnails haben mehr als das doppelte Volumen der Bilder und enthalten viel mehr Dateien?! WTF? 80 Megabytes Thumbnails für 31 Megabyte Bilder...

Rolf

[dedlfix]

Tach!

(WinZIP hab ich nur im Büro, nicht zu Hause)

Nimm doch 7zip.

Der Grund, warum meine Daten veraltet waren, liegt in der Installationsbeschreibung. Es gibt die Ordner offline-wiki und offlinewiki, in der Beschreibung ist offlinewiki verlinkt und das ist offenbar veraltet.

Die restlichen Links sind nun auch aktualisiert, wenn ich keine übersehen habe.

Bei den Bildern scheint mir images/thumb merkwürdig, vielleicht voller Leichen: Die Thumbnails haben mehr als das doppelte Volumen der Bilder und enthalten viel mehr Dateien?! WTF? 80 Megabytes Thumbnails für 31 Megabyte Bilder...

MediaWiki. Das hat die Orignale und zusätzlich gegebenenfalls mehrere kleine Versionen. Wenn in einer Seite angegeben wurde, wie groß das Bild sein soll, wird eine dazu passende Datei generiert. Sonst müsste das immer erst bei Bedarf erfolgen oder die große Datei übertragen im Browser runterskaliert werden.

dedlfix.

[pl]

Die Beispiele sind nun anklickbar und funktionieren.

So hab ichs gemacht, mit BlobURLS:

CSS = URL.createObjectURL( new Blob([RAM.examples['SELFHTML-Beispiel-Grundlayout.css']]) );

var str = new String(RAM.examples[name]);
str = str.replace("./Beispiel:SELFHTML-Beispiel-Grundlayout.css", CSS);
var xURL = URL.createObjectURL( new Blob([str]) );
                        
window.open(xURL, 'Example',"width=640,height=640,left=100,top=100");

Und weiter gehts 😉

[Rolf B]

Hallo pl,

vergiss nicht, dass createObjectURL auch einen zugehörigen revoke Aufruf braucht. Gerade bei einer SPA extrem wichtig. Sonst hast Du ein Memory Leak.

Rolf

[dedlfix]

Tach!

Warum so und keine statischen Seiten?

Kann ich nicht nachvollziehen. Das ist Stand der Technik die man vor 20 Jahren hatte.

Worauf genau bezieht sich das "Das"? - Vor 20 Jahren jedenfalls hatten wir statisches HTML ohne CSS und Javascript - zumindest waren diese beiden noch nicht sehr bedeutend. Damit wäre es kein größeres Problem gewesen, ein paar Offline-Seiten zu erzeugen. Mediawiki ist aber nicht mehr auf dem Stand von vor 20 Jahren. Die Art und Weise, wie es heutzutage funktioniert, macht es sehr schwierig mit der Vorgehensweise von vor 20 Jahren eine Lösung zu erstellen. Mit zukünftigen Versionen wird der Aufwand sicher auch nicht geringer werden, für alle Eventualitäten, die das Mediawiki so bereithält, eine statische Lösung zu erstellen und zu pflegen. Aufwand und Nutzen einer Vor-20-Jahren-Lösung stehen in keinem tragbaren Verhältnis.

dedlfix.

[pl]

Du verstehst nicht,

Aufwand und Nutzen einer Vor-20-Jahren-Lösung stehen in keinem tragbaren Verhältnis.

Euer Wiki mit lokalem Webserver ist Stand einer Vor-20-Jahren-Lösung. MfG

[dedlfix]

Tach!

Du verstehst nicht,

Liegt auch daran, dass da in deiner Aussage eine Menge Interpretationsspielraum war, weswegen ich da ja auch rückgefragt habe, was du genau meinst.

Aufwand und Nutzen einer Vor-20-Jahren-Lösung stehen in keinem tragbaren Verhältnis.

Euer Wiki mit lokalem Webserver ist Stand einer Vor-20-Jahren-Lösung.

Das tolle an dieser "Vor-20-Jahren-Lösung" ist, dass sie die Anforderungen sehr gut abdeckt, was andere Lösungen nicht mit vergleichbarem Aufwand konnten.

dedlfix.

[JürgenB]

Hallo Rolf,

wie würdest du denn eine Offline-Doku auf Basis des Selfwikis realisieren.

Gruß
Jürgen

[Mitleser]

Du verstehst nicht,

Aufwand und Nutzen einer Vor-20-Jahren-Lösung stehen in keinem tragbaren Verhältnis. Euer Wiki mit lokalem Webserver ist Stand einer Vor-20-Jahren-Lösung. MfG

Mir gefällt die Substanz Deiner Ausführungen sehr. Insbesondere die Wiederholung hat diese nochmals untermauert.

[Bernd]

Hallo,

ich habe eine Frage, lohnt sich der Aufwand überhaupt offline etwas anbieten zu wollen? Ich meine ist man heute nicht ständig am PC, auf dem Handy oder Tablett online? So viel Traffic verursacht ein Aufruf im Wiki bestimmt nicht?

[dedlfix]

Tach!

ich habe eine Frage, lohnt sich der Aufwand überhaupt offline etwas anbieten zu wollen?

Zumindest gibt es Anfragen von Nutzern, die ...

Ich meine ist man heute nicht ständig am PC, auf dem Handy oder Tablett online?

... gerade das eben nicht können. Die sitzen (einige davon im doppelten Wortsinne) an Plätzen ohne Internetzugang und können nicht mal eben schnell ins Netz.

dedlfix.