Selfhtml Download
App
- download
- selfhtml
Hallo, ich wollte die Selfhtml Seite runterladen, finde aber im Netz nur alte Downloads und auf dieser Seite keinen Download-Link.
Kennt jemand einen aktuellen Download auf dieser oder anderen Seite?
Hallo App,
ich wollte die Selfhtml Seite runterladen, finde aber im Netz nur alte Downloads und auf dieser Seite keinen Download-Link.
Kennt jemand einen aktuellen Download auf dieser oder anderen Seite?
Es gibt zur Zeit keinen Download. Das Wiki zum Download bereit zu stellen hat sich als ausgesprochen viel Arbeit herausgestellt, zu der sich bisher keine Zeit gefunden hat.
LG,
CK
Hallo und guten Morgen,
ich wollte die Selfhtml Seite runterladen, finde aber im Netz nur alte Downloads und auf dieser Seite keinen Download-Link.
Kennt jemand einen aktuellen Download auf dieser oder anderen Seite?
Es gibt zur Zeit keinen Download. Das Wiki zum Download bereit zu stellen hat sich als ausgesprochen viel Arbeit herausgestellt, zu der sich bisher keine Zeit gefunden hat.
ein "wget -np" mit anschließendem Verschieben in einen lokalen VirtHost könnte es doch vielleicht tun, oder wo kneift es dann?
Liebe Grüße
TS
Hallo TS,
ein "wget -np" mit anschließendem Verschieben in einen lokalen VirtHost könnte es doch vielleicht tun
Nein. Eine Download-Version sollte nicht mehr auf Online-Ressourcen zugreifen, da reicht ein wget
nicht.
oder wo kneift es dann?
Das Wiki lädt diverse Ressourcen dynamisch nach, abhängig von was-weiss-ich für Bedingungen. Ich hatte mal versucht das über einen Bot nachzuladen, aber die URLs lassen sich nicht wirklich umschreiben. Im wesentlichen läuft es darauf hinaus, dass man das HTML selber generieren muss.
LG,
CK
Hallo Christian, @Matthias Scharwies
Das Wiki lädt diverse Ressourcen dynamisch nach, abhängig von was-weiss-ich für Bedingungen. Ich hatte mal versucht das über einen Bot nachzuladen, aber die URLs lassen sich nicht wirklich umschreiben. Im wesentlichen läuft es darauf hinaus, dass man das HTML selber generieren muss.
Vielleicht ließe sich mit dem URL-Parameter action=render
etwas anstellen:
aus https://wiki.selfhtml.org/wiki/Referenz:HTML/title wird https://wiki.selfhtml.org/wiki/Referenz:HTML/title?action=render, das Ergebnis ist eine HTML-Ausgabe ohne alles drum herum. Fehlt noch:
Problem bleibt da wohl die Suche, aber durch die gute Strukturierung findet man sowieso fast alles auch ohne Suchmaschine.
Habe ich etwas übersehen?
Gruß
Julius
Servus!
Problem bleibt da wohl die Suche, aber durch die gute Strukturierung findet man sowieso fast alles auch ohne Suchmaschine.
Genau. Problem ist das Vernetzen der Seite mit der Suche, ohne die das Wiki ja nur eingschränkt benutzbar wäre.
Auf dieser Wiki-Seite haben wir die diversen Möglichkeiten, die seit 4 Jahren besprochen werden, zusamengefasst:
Habe ich etwas übersehen?
Nein. Auch die Wikipedia hat keine Offline-Versionen mehr.
Es fragen aber immer wieder Schulen (für Prüfungen) und Gefängnisse (für Web-Kurse ohne Zugang zum Netz) nach einer solchen Version.
Gruß
Julius
Herzliche Grüße
Matthias Scharwies
Wenn ihr euch Kiwix angeschaut habt, dann habt ihr doch bestimmt auch das hier entdeckt.
Reicht das nicht? Oder ist die Collection-Extension zu alt und funktioniert nicht mehr?
Rolf
Hallo Rolf b,
Mein technisches Verständnis ist dafür nicht ausreichend. Ich kann nur auf @dedlfix verweisen.
Bis demnächst
Matthias
Hallo und guten Tag @Christian Kruse und @dedlfix,
Es gibt zur Zeit keinen Download. Das Wiki zum Download bereit zu stellen hat sich als ausgesprochen viel Arbeit herausgestellt, zu der sich bisher keine Zeit gefunden hat.
könntet Ihr bitte mal kurz beschreiben, wie das Wiki auf dem Server gespeichert ist (Tree) und welche Tools (Programme, Skript-Sprachen, DBMS, ...) dafür benutzt werden?
Könnte man nicht einen Tarball (zipped) daraus machen und dann lokal einen virtual Host dafür einrichten? Sind die Voraussetzungen dafür so weit weg von normal üblichen XAMMP-Einrichtungen, dass man es auch mit Anleitung nicht zum Laufen brigen würde?
Liebe Grüße
Tom S.
Tach!
könntet Ihr bitte mal kurz beschreiben, wie das Wiki auf dem Server gespeichert ist (Tree) und welche Tools (Programme, Skript-Sprachen, DBMS, ...) dafür benutzt werden?
MediaWiki Standard-Ausführung mit MySQL plus ein paar Extensions. Da wir zwei Instanzen laufen haben, sind die gemeinsamen Verzeichnisse aber nur in den VHost gesymlinkt.
Könnte man nicht einen Tarball (zipped) daraus machen und dann lokal einen virtual Host dafür einrichten?
Kann man sicher, irgendwie. Wird aber deutlich größer als notwendig, weil im DBMS sämtliche Bearbeitungsschritte enthalten sind. Ein einfaches tar ...
reicht da jedoch nicht, um die Datenbank zu extrahieren. Du kennst ja die Probleme mit InnoDB. Und unsere Passwörter sollen auch nicht veröffentlicht werden - ganz zu schweigen von den Nutzerdaten im Wiki. Die Nutzer braucht es aber, sonst gibt es Inkonsistenzen.
dedlfix.
Hallo und guten Tag,
Ein einfaches
tar ...
reicht da jedoch nicht, um die Datenbank zu extrahieren. Du kennst ja die Probleme mit InnoDB.
Ich weiß nicht, ob ich jetzt lachen oder weinen soll!
Angeblich soll doch InnoDB so viel besser sein und es keinen Grund mehr geben, MyISAM zu benutzen höhöhö
Und da Ihr ja DBMS-Profis seid, wird es euch doch nur ein müdes Arschrunzeln kosten, die notwendigen Tabellen zu extrahieren. Werden denn überhaupt Features von InnoDB benutzt, die mit MyISAM nicht abzubilden sind?
Nun bitte mal Butter bei die Fische! Immerhin steht "offline Wiki" ganz offiziell auf der ToDo-Liste und wenn es denn (zumindest für bestimmte Anwenderkreise) so winfach wäre, dann sollten wir das mal durchzuiehen!
Liebe Grüße
TS
Tach!
Und da Ihr ja DBMS-Profis seid, wird es euch doch nur ein müdes Arschrunzeln kosten, die notwendigen Tabellen zu extrahieren.
Man kann einen Dump ziehen, so wie das eben für Backups vorgesehen ist. Aber wie gesagt, kann ich den auch nicht in der Form freigeben wegen der darin enthaltenen persönlichen Daten.
dedlfix.
Hallo Dedlfix,
Und da Ihr ja DBMS-Profis seid, wird es euch doch nur ein müdes Arschrunzeln kosten, die notwendigen Tabellen zu extrahieren.
Man kann einen Dump ziehen, so wie das eben für Backups vorgesehen ist. Aber wie gesagt, kann ich den auch nicht in der Form freigeben wegen der darin enthaltenen persönlichen Daten.
Dann bitte ich um Fakten.
(Oder sind wir bei SelHTML jetzt auch schon im postfaktischen Zeitalter angekommen? :-P )
Dann stelle bitte die Create-Statements der betroffenen Tabellen zur Verfügung und markiere die betroffenen sensiblen Spalten. Die werden wir dann doch im Wege eines Rückschr(i|o)tt-Versuches zu MyISAM einfach droppen, oder?
Ich würde mir das gerne ansehen, ob man eventuell vorhandene Relations nicht einfach als Trigger abbilden kann und mich entsprechend damit beschäftigen.
Liebe Grüße
TS
Tach!
Dann stelle bitte die Create-Statements der betroffenen Tabellen zur Verfügung und markiere die betroffenen sensiblen Spalten. Die werden wir dann doch im Wege eines Rückschr(i|o)tt-Versuches zu MyISAM einfach droppen, oder?
Warum soll denn das rückportiert werden?
Die Tabellenstruktur kannst du in einer Standard-Installation von MediaWiki finden.
dedlfix.
Hallo und guten Tag,
Dann stelle bitte die Create-Statements der betroffenen Tabellen zur Verfügung und markiere die betroffenen sensiblen Spalten. Die werden wir dann doch im Wege eines Rückschr(i|o)tt-Versuches zu MyISAM einfach droppen, oder?
Warum soll denn das rückportiert werden?
Na, weil ich doch die Probleme mit InnoDB kenne und den potentiellen Anwendern diese ersparen möchte ...
Die Tabellenstruktur kannst du in einer Standard-Installation von MediaWiki finden.
Schön! Sowas nennt sich dann "Zusammenarbeit"!
Soll ich jetzt erst Mediawiki installieren, um abschätzen zu können, ob das auch mit MyISAM laufen würde?
Liebe Grüße
TS
Tach!
Warum soll denn das rückportiert werden?
Na, weil ich doch die Probleme mit InnoDB kenne und den potentiellen Anwendern diese ersparen möchte ...
Es geht doch darum, eine Standalone-Installation zu erschaffen. Dabei ist es mir doch egal, ob der Verwender das DBMS noch für andere Zwecke nutzen möchte und dabei eine nicht standardisierte Backup-Prozedur für einzelne Datenbanken verwenden möchte. Die Zahl der Nutzer für dieses Szenario wird wohl gegen 0 tendieren. Das ist kein Grund, da übermäßig vorsorglich zu sein.
Die Tabellenstruktur kannst du in einer Standard-Installation von MediaWiki finden.
Soll ich jetzt erst Mediawiki installieren, um abschätzen zu können, ob das auch mit MyISAM laufen würde?
Ja na klar, wie willst du denn auch sonst das Szenario durchspielen und testen? Aber eine Portierung auf MyISAM kannst du wegen Nichtnotwendigkeit weglassen.
dedlfix.
Hallo
Dann stelle bitte die Create-Statements der betroffenen Tabellen zur Verfügung und markiere die betroffenen sensiblen Spalten. Die werden wir dann doch im Wege eines Rückschr(i|o)tt-Versuches zu MyISAM einfach droppen, oder?
Warum soll denn das rückportiert werden?
Na, weil ich doch die Probleme mit InnoDB kenne und den potentiellen Anwendern diese ersparen möchte ...
Mal abgesehen davon, dass deine Probleme mit InnoDB auf deinem sehr speziellen Anwendungsfall beruhen und mit einer recht großen Wahrscheinlichkeit niemandem sonst auf diesem Planeten unterkommen werden, willst du doch nicht ernsthaft potentiellen Benutzern eine XAMPP-Installation für den Offlinebetrieb des Wikis andienen?
Um Gunnar zu paraphrasieren: Kein Nutzer, jemals!
Tschö, Auge
Hallo und guten Tag,
Mal abgesehen davon, dass deine Probleme mit InnoDB auf deinem sehr speziellen Anwendungsfall beruhen
Könntest Du das bitte näher ausführen? Ich kann Dir da leider nicht folgen, was an der Forderung an einem "TarBall (gz)" ein spezieller Anwendungsall sein soll?
und mit einer recht großen Wahrscheinlichkeit niemandem sonst auf diesem Planeten unterkommen werden,
Was bringt Dich zu dieser waghalsigen Annahme? Ich kenne zumindest mehrere Anfragen von "geschlossenen Anstalten", die sich über eine per Tarball installierbare Updateversion eines einmal einzurichtenden Systems ohne ihre sonstigen Datenbanken zu gefährden, freuen würden.
willst du doch nicht ernsthaft potentiellen Benutzern eine XAMPP-Installation für den Offlinebetrieb des Wikis andienen?
Wieso? Jeder, der das Wissen im Wiki ernsthaft nachvollziehen will, benötigt zuerst einen lokalen Testhost mit den üblichen Servern. Die XAMPP-Installation ist da mMn weit verbreitet und eine strategische Partnerschaft wäre sicherlich nichts Falsches!
Um Gunnar zu paraphrasieren: Kein Nutzer, jemals!
Diese Aussage schätze ich genauso wertvoll ein, wie die von IBM-Chef Thomas Watson zur Anzahl der jemals benötigten Computer.
Wer etwas will, findet Wege. Wer etwas nicht will, findet Gründe.
Ich hatte hier einen Weg aufgezeigt, der es mit wenigen Handgriffen und einer kurzen Beschreibung ermöglichen sollte, das Wiki offline verfügbar zu machen. Außerdem sehe ich darin eine Möglichkeit zu stragtegischen Partnerschaften!
Sollten hier keine positive Mitarbeit spürbar werden (egal, was am Ende rauskommt) empfinde ich die Antworten als Bashing und nicht als intelligent. Das fürht dann zum inneren plonk
Liebe Grüße
TS
Hallo
Mal abgesehen davon, dass deine Probleme mit InnoDB auf deinem sehr speziellen Anwendungsfall beruhen
Könntest Du das bitte näher ausführen? Ich kann Dir da leider nicht folgen, was an der Forderung an einem "TarBall (gz)" ein spezieller Anwendungsall sein soll?
Deine Anforderung, Datenmengen, die offensichtlich für die Übertragung per SQL bzw. einen SQL-Dump zu groß sind, auf voneinander unabhängig betriebenen Installationen einer Software zu verteilen, halte ich durchaus für speziell. Dass du dabei auch noch eine Konfiguration hast, die den damals von dedlfix verlinkten Weg, das mit InnoDB-Tabellen zu tun, ausschließt, noch mehr.
willst du doch nicht ernsthaft potentiellen Benutzern eine XAMPP-Installation für den Offlinebetrieb des Wikis andienen?
Wieso? Jeder, der das Wissen im Wiki ernsthaft nachvollziehen will, benötigt zuerst einen lokalen Testhost mit den üblichen Servern.
Tut er das? Solange wir von den Grundlagen sprechen, die im SelfHTML-Wiki vorwiegend beschrieben werden (HTML, CSS, JS) braucht man den Server auf der lokalen Seite wohl nicht sehr viele Aufgaben. Dass er, wenn vorhanden, hilfreich beim nachvollziehen bestimmter Fälle ist und spätestens für serverseitige Techniken gebraucht wird, steht außer Frage.
Ich hatte hier einen Weg aufgezeigt, der es mit wenigen Handgriffen und einer kurzen Beschreibung ermöglichen sollte, das Wiki offline verfügbar zu machen.
Ganz offensichtlich funktioniert das eben nicht „mit wenigen Handgriffen“. Dein Weg ist also, zumindest bis jetzt, versperrt.
Außerdem sehe ich darin eine Möglichkeit zu stragtegischen Partnerschaften!
Wovon auch immer du sprichst.
Tschö, Auge
Lieber dedlfix,
Und unsere Passwörter sollen auch nicht veröffentlicht werden - ganz zu schweigen von den Nutzerdaten im Wiki.
die könnte man doch leeren? Das Offline-Wiki muss ja keine Bearbeitungsfunktion leisten, da es nur zum Lesen gedacht ist.
Die Nutzer braucht es aber, sonst gibt es Inkonsistenzen.
Kann man hier die Namen der Nutzer unkenntlich machen? Wenn das System einen Primary Key für die Nutzer verwendet, dann sollte intern doch dieser genügen! Und wenn es um alte Versionen von Seiten geht, diese könnten meiner Meinung nach für ein Offline-Wiki entfernt werden (ja, den manuellen Mehraufwand kann ich noch nicht einschätzen - daher der waghalsige Vorschlag).
Welche Daten von Nutzern müssen für das Offline-Wiki erhalten bleiben?
Liebe Grüße,
Felix Riesterer.
Tach!
Und unsere Passwörter sollen auch nicht veröffentlicht werden - ganz zu schweigen von den Nutzerdaten im Wiki.
die könnte man doch leeren? Das Offline-Wiki muss ja keine Bearbeitungsfunktion leisten, da es nur zum Lesen gedacht ist.
Ja, machen kann man vieles, nur eben nicht mit einem einfachen tar
.
Die Nutzer braucht es aber, sonst gibt es Inkonsistenzen.
Kann man hier die Namen der Nutzer unkenntlich machen?
Möglich. Aber die stehen nicht nur in der Nutzerdatenbank, sondern auch an den Stellen, an denen eine Nutzerinformation gespeichert ist. Zum Beispiel an den Revisionen. Das ist deswegen doppelt, weil ja auch IP-Adressen mitarbeiten können, und die haben alle die ID 0. Da steht dann der/die jeweilige Name/IP in einem Textfeld daneben.
Wenn das System einen Primary Key für die Nutzer verwendet, dann sollte intern doch dieser genügen! Und wenn es um alte Versionen von Seiten geht, diese könnten meiner Meinung nach für ein Offline-Wiki entfernt werden (ja, den manuellen Mehraufwand kann ich noch nicht einschätzen - daher der waghalsige Vorschlag).
Dazu muss man die jeweils letzte Revision finden und alle anderen aus der Tabelle der Texte raushauen. Wobei ich nicht weiß, ob immer die gesamte Seite oder nur ein Diff gespeichert wird. Und dann müssen die History-Tabellen und die Log-Tabellen bereinigt werden. Am Ende muss das System so aussehen, als ob es nur einmal ein Erstellen der Seite und keine weiteren Bearbeitungen gegeben hat.
Welche Daten von Nutzern müssen für das Offline-Wiki erhalten bleiben?
Kann ich nicht beantworten, weil ich nicht weiß, was alles nicht mehr geht, wenn es keine Benutzer mehr gibt.
Die Arbeitsweise des Systems ist jedenfalls nicht so einfach, als dass die Create-Statements für das Verstehen reichen. Da muss man sich schon etwas intensiver mit einer Installation beschäftigen.
dedlfix.
Servus!
die könnte man doch leeren? Das Offline-Wiki muss ja keine Bearbeitungsfunktion leisten, da es nur zum Lesen gedacht ist.
Ja, machen kann man vieles,...
Die Nutzer braucht es aber, sonst gibt es Inkonsistenzen.
Kann man hier die Namen der Nutzer unkenntlich machen?
Möglich. ...
Die Arbeitsweise des Systems ist jedenfalls nicht so einfach, als dass die Create-Statements für das Verstehen reichen. Da muss man sich schon etwas intensiver mit einer Installation beschäftigen.
Natürlich gehört das Offline-Wiki zu unseren ToDos, die wir nicht aus dem Auge lassen sollten.
Andererseits gibt es im Backend nur dedlfix, der dort aktiv ist. In der inhaltlichen Bearbeitung gibt es tendentiell auch mehr Baustellen als Mitarbeiter.
Wir sollten Interessierten Wege zeigen, wie sie selbst aktiv werden können. (z.B. eigenes Wiki aufsetzen und unsere Seiten als XML exportieren.
Grundsätzlich sollten wir uns aber, gerade angesichts der überschaubaren Zahl der Mitarbeiter, auf unsere Hauptbaustellen innerhalb des Wikis konzentrieren.
Herzliche Grüße
Matthias Scharwies