Forum: PC Hard- und Software Welche Homepagesoftware ist für mich zu empfehlen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Joern DK7JB .. (moin)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,
seit vielen Jahren habe ich eine Homepage (www.bartelsos.de) um 
Informationen im Bereich Amateurfunk anderen Nutzern bereitzustellen. 
Ich suche nun nach einer neuen Software, um meine Seite darzustellen.
Von Beginn an habe ich b2evolution verwendet. Nach einem Update habe ich 
aber größere Probleme und so ganz war ich auch mit der Gestaltung nicht 
zufrieden. Vielleicht ist nun Zeit auf eine anderes System umzuziehen.

Was würdet ihr mir empfehlen?

Umfang der Seite:
-75 Posts mit 150 zugehörigen Dateien
-1 Nutzer (mich)
-Einen Webhoster habe ich.

Was benötige ich:
- Ein System für die nächsten vielen Jahre, damit Linkstrukturen 
erhalten bleiben können und ich besser zitiert werden kann. Dieser Punkt 
hat mich in den letzten Jahren auch bewogen bei b2evolution zu bleiben 
(und die Bequemlichkeit)
- Möglichst so gestaltet, dass es keine Probleme mit der dsgvo & Co 
gibt.
- Für die Dateien einen Downloadzähler. Es reicht, wenn dieser Zähler 
nur für mich sichtbar ist.
- Meine Seite soll eher so etwas wie eine Art Wiki oder Handbuch sein, 
mit einer festen Struktur. Es soll kein Blog werden.
- Das Schreiben neuer Beiträge und das Hinzufügen von Dateien für einen 
Download soll einfach sein. Auf eine absolute Freiheit in der Gestaltung 
verzichte ich gerne um mehr "Einfachheit/Bequemlichkeit" zu erhalten.
- Die Seite soll dann so sicher sein, dass es eher unwahrscheinlich ist, 
dass ich für irgendwelche Angriffe interessant bin. Letztlich wäre dies 
aber nur lästig, da es nur eine Hobby-Webseite ist.

Was ich nicht benötige:
- Ich will keine Informationen oder Statistiken über Benutzer speichern. 
Es soll eine im Sinne der dsgvo unproblematische Seite werden.
- Ich will wenig Pflegeaufwand
- Ich will nicht programmieren (html, php,...). Hier habe ich 
rudimentäre Grundkenntnisse.
- Keine Kommentarfunktion
- Emailformular ist nicht notwendig

Eine Info noch. Mein Webhoster bietet für Wordpress eine automatischen 
Updatefunktion mit automatischem Installationsservice an. Ist Wordpress 
vielleicht doch für mich zu empfehlen?

von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
Ich benutze seit vielen Jahren DokuWiki als einfache Homepagesoftware.

von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
Christoph Z. schrieb:
> DokuWiki

Nachtrag zu meinem Set-up (https://brain4free.org):

Ich habe ein paar Plug-ins drin, die du in deinen Anforderungen als
nicht nötig aufgeführt hast:
- Blog
- Kommentare

Das ist bei Dokuwiki nicht von Anfang an dabei. Die Kommentar Funktion
ist bisher auch selten nützlich. Zieht auch manchmal Spam an.

Für dich vielleicht nützliche Plug-ins die ich bei mir habe sind:
- Gallery
- Notes (Info, Warn Boxen)
- RefNotes (Fussnoten etc.)
- Tag, TagEntry, TagCloud
- Indexmenu (nötig für eine klassische Sidebar Navigation)

von Pete K. (pete77)


Bewertung
1 lesenswert
nicht lesenswert
Schon mal bei Wordpress vorbeigeschaut? Wichtig finde ich auch ein 
responsive Design, d.h. dass die Seiten auch vernünftig auf einem 
Smartphone oder Tablet dargestellt werden können.
Für Wordpress gibt es viele Themen und Plugins. Bedienung ist einfach. 
Viele Hoster bringen das als 1-click installer mit.

: Bearbeitet durch User
von Pandur S. (jetztnicht)


Bewertung
1 lesenswert
nicht lesenswert
Bei wordpress sollte man auf all die Plugins verzichten, die bereiten 
update und sicherheitsprobleme. Und nicht bei wordpress.com reinschauen, 
das ist der kommerzielle Teil, sondern bei wordpress.org.

von Nano (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Joern DK7JB .. schrieb:
> -Einen Webhoster habe ich.

Welche Skriptsprachen und Laufzeitumgebungen unterstützt denn der 
Webhoster?
Auch wenn du nicht selber programmieren willst, so ist dennoch eine 
wichtige Information, da die ganzen CMS ja selbst auf eine aufbauen.

Und wenn du da bspw. eine Java oder Pyhton basierte hast, dann nützt dir 
das nicht, wenn der Webhoster nur PHP unterstützt.


Das:

> - Die Seite soll dann so sicher sein, dass es eher unwahrscheinlich ist,
> dass ich für irgendwelche Angriffe interessant bin. Letztlich wäre dies
> aber nur lästig, da es nur eine Hobby-Webseite ist.

und das:

> - Ich will nicht programmieren (html, php,...). Hier habe ich
> rudimentäre Grundkenntnisse.

und das:

> Eine Info noch. Mein Webhoster bietet für Wordpress eine automatischen
> Updatefunktion mit automatischem Installationsservice an. Ist Wordpress
> vielleicht doch für mich zu empfehlen?

lässt eigentlich nur zu, dass du das Angebot des Webhosters wahrnimmst 
und Wordpress verwendest.

Denn nimmst du ein anderes CMS, dann musst du es sicherheitstechnisch 
selber pflegen. Und das willst du ja nicht.

Würdest du etwas selber programmieren, dann könntest du zwar die 
Angriffsfläche minimieren und wärst so vor Überraschungen durch 
Änderungen neuer Versionen sicher, zumal ein Selbstbau bei weitem nicht 
so komplex ist wie ein gewachsenes ausgereiftes CMS, gesetzt den Fall 
natürlich, du machst selber beim überprüfen von Eingaben und bei der 
sonstigen Sicherheit alles richtig, aber programmieren willst du ja 
nicht, bzw. fehlen dir dazu die notwendigen Kenntnisse, also fällt das 
auch weg.

Deswegen bleibt eigentlich nur das Angebot des Webhosters übrig.
Da kümmert er sich um die Updates von Wordpress und Wordpress ist 
leistungsfähig genug, so dass das für eine Hobbyseite mehr als 
ausreichen wird.

Dem Ratschlag auf zusätzliche Plugins zu verzichten, schließe ich mich 
an.
Und wenn deine Webseite dank Wordpress auch von einem Smartphone aus zu 
bedienen ist, dann ist das ein Vorteil den du nutzen solltest.

von Kilo S. (kilo_s)


Bewertung
-1 lesenswert
nicht lesenswert
Wordpress Seiten waren immer mein lieblingsziel wenn mal ein Kunde nach 
einem Penetrationtest fragte.

Über die force-download.php die wp-config.php geholt und weiter ging es.

Wordpress würde ich auch sonst meiden. Viele plugins die unsicher sind.

von Joern DK7JB .. (moin)


Bewertung
0 lesenswert
nicht lesenswert
Ich probiere gerade DokuWiki aus. Vielleicht komme ich schon damit aus. 
Ich muss mir nur noch einen Downloadcounter suchen und die Bedienung von 
DokuWiki verstehen.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Kilo S. schrieb:
> Wordpress Seiten waren immer mein lieblingsziel wenn mal ein Kunde
> nach
> einem Penetrationtest fragte.

Die Frage ist doch, lag es am Kunden (Patch nicht eingespielt oder 
schlecht gepflegte Plugins benutzt) oder haben die Wordpress Entwickler 
zu lange gebraucht um Securityfixes für bekannte Sicherheitslücken zu 
liefern?

Bei einem gut gepflegten System, wie der TS bezüglich seinem Webhoster 
vorgibt, sollte nämlich, wenn, dann doch nur letztere Möglichkeit in 
Frage kommen.
Und in dem Fall ja, nur dann macht es wirklich Sinn etwas anderes zu 
verwenden.

Aber einfach pauschal ne Aussage zu treffen, während vielleicht die 
Kunden das Problem waren, reicht hier nicht. Denn dann wäre jedes andere 
große CMS auch nicht besser.

von Frank E. (Firma: Q3) (qualidat)


Bewertung
-3 lesenswert
nicht lesenswert
Ich empfehle und verwende immer Joomla. Dann gibts da ja noch Wordpress, 
Drupal u.a. CMS. Die Erstinstallation ist ein etwas größerer Aufwand als 
das Hochladen einer simplen HTML-Seite, aber dafür gehts dann später wie 
geschmiert ...

von Kilo S. (kilo_s)


Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> Die Frage ist doch, lag es am Kunden (Patch nicht eingespielt oder
> schlecht gepflegte Plugins benutzt) oder haben die Wordpress Entwickler
> zu lange gebraucht um Securityfixes für bekannte Sicherheitslücken zu
> liefern?

Die force-download.php war einfach generell scheiße gemacht.

Viele Lücken sind auch einfach nicht so schnell zu fixen, zum Teil weil 
sie lange existieren und nur im "untergrund" bekannt werden. (Ob man es 
glaubt oder nicht... aber frag mal in einschlägigen IRC Chats, wenn du 
sie findest ;-) und dort dann auch mal als vertrauenswürdig eingestuft 
wirst!)

Das Problem an wordpress ist das viele plugins schlecht gewartet sind. 
Und das vom Entwickler selbst kaum oder sogar keine Reaktion kommt, auch 
die Themes sind teils anfällig für Angriffe.

https://www.exploit-db.com/exploits/49115

Natürlich gibts das für alle CMS!
Aber Wordpress mit 35%+ Anteil ist besonders stark gefährdet.
Viele Ziele = Hohes Interesse.

Zu 80% waren die Seiten aktuell gehalten. Selten und nur beim absoluten 
Super-DAU war es eine so stark veraltete Version das ich nicht mal 
testen musste sondern gleich sagte das es nichts bringt weil ich in drei 
Minuten den Webspace "Leer" machen kann.

Einer wollte es nicht glauben... am längsten dauerte es die Kopie seiner 
Seite auf meinen Rechner zu laden also das archiv per webshell zu 
machen. Der rest war dann in Sekundenschnelle weg.

Wordpress macht nur Arbeitsaufwand! Täglich nach Lücken schauen, 
plugins/themes rauswerfen die bis zum fix unsicher sind (wenn es nur 
eine Lücke ist) usw...

Für die Anforderung "Sicher und Unattraktiv Für angreifer" taugt das 
nicht.

von DoS (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Joomla.

von dave4 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mir persönlich gefällt https://getgrav.org/ sehr gut.
Das System kommt ohne Datenbank aus, die Seiten lassen sich alternativ 
via Backend oder Texteditor bearbeiten und ein Backup besteht aus einem 
einfachen Archiv von Textdateien.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Kilo S. schrieb:
> Die force-download.php war einfach generell scheiße gemacht.

Ja gut, schlechten Code gibt's natürlich auch noch.

> Das Problem an wordpress ist das viele plugins schlecht gewartet sind.
> Und das vom Entwickler selbst kaum oder sogar keine Reaktion kommt, auch
> die Themes sind teils anfällig für Angriffe.

Ja, das ist aber ein Problem der Plugins, nicht von wordpress an sich 
und
wie du richtig sagst, gibt's die bei anderen CMS ja auch.
Auch da kann man Plugins erstellen und sich dann nicht mehr um deren 
Pflege kümmern. Im Prinzip ist das bei jedem Projekt so, wo Plugins 
möglich sind.


> https://www.exploit-db.com/exploits/49115
>
> Natürlich gibts das für alle CMS!
> Aber Wordpress mit 35%+ Anteil ist besonders stark gefährdet.
> Viele Ziele = Hohes Interesse.

Oder hoher Nutzungsgrad = viele Fehler werden bekannt und dann 
hoffentlich gefixt.

Eine große Anzahl an CVEs ist somit nicht gleich zu setzen mit, dass die 
Software unsicherer wäre, als eine, die nur wenige CVE Einträge hat.
Viele CVE Einträge sind kein Makel, sie sind sogar positiv zu sehen, 
weil der Entwickler die Sicherheitslücken offen benennt, während andere 
sie einfach unter den Tisch kehren und den Fix dann unprotokolliert 
einfach unter den nächsten Patch schieben.

Viel wichtiger ist somit also auch, die Geschwindigkeit mit der bekannte 
Sicherheitslücken gefixt werden und das sie gefixt werden.

> Zu 80% waren die Seiten aktuell gehalten.

Lag es aber an den Drittanbieterplugins oder am Kern der Software?

> Wordpress macht nur Arbeitsaufwand! Täglich nach Lücken schauen,
> plugins/themes rauswerfen die bis zum fix unsicher sind (wenn es nur
> eine Lücke ist) usw...

Die Frage ist halt auch, ob ein anderes CMS gleicher Komplexität, das 
aber nur wenige nutzen, da wirklich besser ist. Nachher fehlt da die 
Entwicklermanpower und notwendige Sicherheitslücken werden nicht zeitnah 
gefixt, sondern die Fixes brauchen viel zu lange.

Prinzipiell sieht's doch so aus. Der Hoster bietet es an. Also ist es 
sein Bier, wenn da was schief läuft.
Nutzt der TS dagegen ein anderes CMS, dann wird es zu seinem Problem, 
inkl. Haftungsfragen. Das sollte man sich gut überlegen ob man sich das 
ans Bein binden möchte.

Zumal ich das Problem, wenn man dann betroffen ist, eher gering 
einstufen würde.
Denn die eigenen Daten hat man noch auf dem Backup und für die 
Folgeschäden  haftet, wenn, dann der Hoster, weil er dafür zuständig 
war, dass er sich um das CMS und dessen Sicherheit kümmert.
Das schlimmste was einem aus dieser Sicht für einen also passieren kann 
ist:
1. Dass die eigene Webseite nicht das anzeigt, was man anzeigen wollte.
2. Dass die eigene Webseite außer Betrieb ist.
3. Der neue nun dargestellte Content einem persönlich schadet.

Wenn die Daten weg sind, hat man sein Backup.
Für alle anderen Probleme, die aus einer unsicheren Webseite resultieren 
können, ist es das Problem des Hosters, wenn er für das CMS zuständig 
ist.

Schlimmer wird's aber, wenn man sein eigenes CMS nutzt. Kümmert man sich 
dann nicht richtig drum und die Homepage wird zum Umleiten auf sagen wir 
mal urheberrechtlich geschütze Filme mißbraucht, dann hat man selbst ein 
Problem. Denn dann kann man nicht sagen, der Hoster war schuld, weil er 
das CMS nicht abgedichtet hat, sondern man hat sich dann nicht selber 
darum gekümmert und wenn man das erst ein paar Wochen später bemerkt, 
ist man aus Fahrlässigkeit dran bzw. könnte einem untergeschoben werden, 
dass man das geduldet hat.
Das kann einem so nicht passieren, wenn der Hoster für die Sicherheit 
des CMS zuständig ist.

von Heiner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Kilo S. schrieb:
> Aber Wordpress mit 35%+ Anteil ist besonders stark gefährdet.
> Viele Ziele = Hohes Interesse.

Das ist zwar aus der Sicherheitsperspektive richtig, aber es ist ganz 
genau diese hohe Verbreitung, die die Sache für den weniger versierten 
Anwender so attraktiv macht: Man bekommt leichter Hilfe als für Exoten 
und die meisten Probleme hat irgendjemand auch schon einmal gehabt und 
darüber geschrieben.

Da es hier nicht um irgendeine hochkritische Infrastruktur oder die 
Erwerbsgrundlage geht, tut ein vorübergehender Ausfall auch wenig weh. 
Man sollte sich des Problems bewusst sein und im Fall der Fälle spielt 
man eben ein Backup ein.

DoS schrieb:
> Joomla.

Joern DK7JB .. schrieb:
> Ich probiere gerade DokuWiki aus.

Auch beides möglich, vielleicht könnte man noch MediaWiki ergänzen. 
Bevor du's ausprobierst, weil es in vielen Übersichten steht: Typo3 ist 
für dich völlig überdimensioniert.

von Kilo S. (kilo_s)


Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> Prinzipiell sieht's doch so aus. Der Hoster bietet es an. Also ist es
> sein Bier, wenn da was schief läuft.

Nö, der bietet nur eine automatische Installation und autoupdate für 
Wordpress Core an. Für Plugins die nachträglich installiert werden gilt 
das aber sehr wahrscheinlich nicht.

Nano schrieb:
> Lag es aber an den Drittanbieterplugins oder am Kern der Software?

Sowohl als auch. Wobei Core deutlich seltener.

Nano schrieb:
> Viele CVE Einträge sind kein Makel, sie sind sogar positiv zu sehen,
> weil der Entwickler die Sicherheitslücken offen benennt, während andere
> sie einfach unter den Tisch kehren und den Fix dann unprotokolliert
> einfach unter den nächsten Patch schieben.

Zum einen werden die NICHT vom Hersteller selbst gefunden und online 
gestellt und zum anderen auch nicht immer bestätigt. Auch wenn sie 
funktionieren!

Manche Lücken wurden auch nicht mit dem nächsten Patch gefixt, oft 
müssten die Nutzer selbst Hand anlegen.

Geh doch mal bitte selbst auf exploit-db.com, nutze die erweiterte Suche 
und such nur mal nach wordpress. Mittlerweile sind es hauptsächlich 
plugins die dort vertreten sind, wordpress core exploits bzw. Lücken 
sind älteren Datums.

Und nun mach das selbe mal für andere CMS.
Joomla/Typo3 käme wohl als nächstes, jedenfalls läuft es auf eines von 
denen hinaus.

Nano schrieb:
> Kümmert man sich dann nicht richtig drum und die Homepage wird zum
> Umleiten auf sagen wir mal urheberrechtlich geschütze Filme mißbraucht

Ach das macht doch schon lange kaum mehr jemand. Wenn laufen dann im 
Hintergrund Miner oder Exploit Tools die direkt auf die User PC's 
zielen. Auch beliebt ist es die mailfunktion von PHP zu nutzen um Spam 
zu versenden.

Oder es werden webproxys geschaltet, webshells um von da aus andere 
Server zu hacken.

Filesharing geht heute leichter und sicherer als links über gehackte 
Seiten zu verteilen.
(Darknet)

Kinox kriegen die ja auch nicht klein. Das wird mittlerweile unter zig 
Domains gehostet usw..

Doku/Media-Wiki und ähnliches sind schon eine gute Wahl.

Trotz der geringeren Nutzerzahlen gut dokumentiert, Hilfe gibts in 
vielen Foren und die Zahl von exploits hält sich in Grenzen.

von db8fs (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hast du mal überlegt, nen Homepagebaukasten als SaaS 
(Software-as-a-service) zu verwenden? Rein von den Anforderungen her, so 
in Richtung "nicht programmieren" bzw. wenig Pflegeaufwand fänd ich das 
fast das Beste. Sieht auch nicht unbedingt schlecht aus bzw. kann man 
recht weit treiben. Aber mit einem vom Hoster gewarteten Wordpress 
kommste wahrscheinlich auch schon recht weit.

Geht so in die Richtung smugmug, jimdo, wix oder webnode. Ist meistens 
recht preisgünstig oder sogar kostenfrei, bis auf die Domain selber.

von Computerwaschel (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Joern DK7JB .. schrieb:
> Ich probiere gerade DokuWiki aus. Vielleicht komme ich schon damit
> aus.
> Ich muss mir nur noch einen Downloadcounter suchen und die Bedienung von
> DokuWiki verstehen.

Hi, ich habe mir es auch herunter geladen. Wie startet man das DokuWiki?
Eine Exe Datei ist nicht dabei. :(

von Andreas M. (amesser)


Bewertung
1 lesenswert
nicht lesenswert
Ich habe auch eine Zeit lang mit Joomla, Drupal oder auch eigenem PHP 
gearbeitet. Inzwischen denke ich aber, das ist für eine Private Homepage 
vollkommen übertrieben.

Aktuell nutze ich eine mittels "Sphinx" statisch erstellte Homepage die 
beim Update einfach per FTP auf den Webserver geschoben wird. Der Inhalt 
kommt aus einfachen Text-Dateien die mit einem beliebigen Editor 
erstellt und bearbeitet werden können. Der Inhalt muss nur entsprechend 
dem reST Format formatiert werden. (Ähnlich Markdown, WikiMarkup ...) 
Sphinx "compiliert" das dann in .html und .js Dateien. (Das Javascript 
wird für die Suche benutzt, bei mir zusätzlich für Bilder-Galerien)

Der Vorteil davon ist, das ich mir das auch ohne Webserver lokal mit 
einem beliebigen Browser ansehen kann bevor ich es hochlade. Außerdem 
gibt es kein einziges auf dem Webserver laufendes dynamisches Skript 
wodurch alle damit verbundenen Einfallstore nicht vorhanden sind. Es 
reicht ein einfachster Webserver und man benötigt keine Datenbank.

Dementsprechend gibt es auch keine Cookies oder sonstige Webseite Daten 
und damit auch kein Pop-Up. Das einzige was man dann wegen der DSGVO 
noch beachten muss ist die korrekte Einstellung der Web-Server Logs 
bezüglich der IP Adressenprotokollierung. (Habe ich bei mir komplett 
ausgeschaltet)

Joern DK7JB .. schrieb:
> - Für die Dateien einen Downloadzähler. Es reicht, wenn dieser Zähler
> nur für mich sichtbar ist.

Die Downloadinformationen kann man auch den Web-Server Protokollen 
entnehmen. Einmal täglich eine Statistik mittels Webalizer reicht mir 
aus. (Um genau zu sein schaue ich sowie nur ein paar mal im Jahr nach)

Sphinx-Doc:
https://www.sphinx-doc.org/en/master/

Ein paar Infos wie man damit eine Webseite machen kann:

http://www.numericalexpert.com/blog/sphinx2website/
https://martin-ueding.de/posts/sphinx-personal-website/

(Eigenwerbung:)
http://bastelmap.de/
(Ja ich müsste mal wieder was dran machen...)

von Joern DK7JB .. (moin)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Computerwaschel,
ich habe mein Test-DokuWiki auf meinem Web-Space installiert und 
probiere die grundlegenen Dinge aus. Ich habe keine Ahnung, wie es lokal 
installiert werden kann.
Siehe hier: www.dokuwiki.bartelsos.de
Wenn du bei Punkt (2) im angehängten Bild den Button betätigst, kannst 
du den Quellcode sehen.

Frage an alle: Wie kann im  angehängten Bild unter Punkt (1) der 
dargestellte Button entfernt werden? Ich möchte, dass die linke Leiste 
dauerhaft dargestellt wird.

von Heiner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Joern DK7JB .. schrieb:
> Wie kann im  angehängten Bild unter Punkt (1) der
> dargestellte Button entfernt werden? Ich möchte, dass die linke Leiste
> dauerhaft dargestellt wird.

Anderes Template verwenden. Das hier sieht mir nach docnavwiki aus. Das 
Standard-Template macht das nicht so. Ob dir dieses Verhalten dann 
besser gefällt, musst du selbst ausprobieren.

Wenn du allgemein nicht möchtest, dass sich die Darstellung der 
Bildschirmgröße anpasst, ... nach kurzer Suche: Das wird schwierig. 
Responsive Design (so heißt das) ist heute quasi Standard, vor allem 
wenn man etwas Neues anfängt. Praktisch alle aktuellen Templates legen 
schon durch die Tags (responsive, mobile, bootstrap, ...) nahe, dass sie 
auch so funktionieren, aber du kannst dein Glück ja versuchen.

von Kilo S. (kilo_s)


Bewertung
-1 lesenswert
nicht lesenswert
Joern DK7JB .. schrieb:
> Ich habe keine Ahnung, wie es lokal installiert werden kann.

XAMPP, du brauchst für die Ausführung von solchen Seiten einen Webserver 
mit PHP und MySQL.

Computerwaschel schrieb:
> Wie startet man das DokuWiki?
> Eine Exe Datei ist nicht dabei. :(

Siehe oben.
Aber mach bitte nicht den Fehler als so blutiger Anfänger (und erst 
recht nicht mit XAMPP) ports ins Internet freizugeben und deinen Rechner 
als Server zu verwenden. Das geht sonst böse in die Hose.

Besorg dir lieber einen Gratis Webspace wenn du das online stellen 
willst und verwende Passwörter die du NIRGENDWO  sonst verwendest.

In der Regel sollte im Archiv eine Datei install.php sein bzw. der erste 
Setupprozess kann auch durch die index.php initialisiert werden.

: Bearbeitet durch User
von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
Heiner schrieb:
> Auch beides möglich, vielleicht könnte man noch MediaWiki ergänzen.
> Bevor du's ausprobierst, weil es in vielen Übersichten steht: Typo3 ist
> für dich völlig überdimensioniert.

MediaWiki ist auch völlig überdimensioniert für die gestellten 
Anforderungen. Muss ich an anderer Stelle pflegen.

von Joern DK7JB .. (moin)


Bewertung
0 lesenswert
nicht lesenswert
Eure Rückmeldungen zeigen mir, dass vielleicht das DokuWiki, welches ich 
momentan ausprobiere, wirklich die richtige Entscheidung für mich ist.

Zum Dokuwiki habe ich noch einige Fragen:
- Wie startet/plant man richtig das Projekt? Gemeint ist, wie man die 
Struktur und das Vorgehen richtig wählt, damit man später nicht so viel 
korrigieren muss. Es sollen rund sechs Hauptkategorien werden, die ich 
nun auch in den entsprechendne Namensräumen abbilden möchte. Auch sollen 
die Kategorien natürlich links im Verzeichnisbaum/Inhaltsverzeichnis 
erscheinen.
Muss ich mit den Links auf die Kategorien immer auf der "start"-Seite 
beginnen oder kann ich die start-Seite frei mit irgendwelchen 
Hinweistexten gestallten? Mir würde es reichen, wenn die Kategorien nur 
über den linken Verzeichnisbaum angewählt werden können und nicht auf 
der start-Seite auftauchen.

Wenn diese Fragen geklärt sind, ist vermutlich der richtig Zeitpunkt um 
das Wiki mit richtigen Inhalten zu füllen ;-)

- Fagen zum Datenschutz und Cockies
Ist es richtig, dass Dokuwiki nur technische Cockies setzt und keine 
Benutzerstatistiken anlegt?

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Kilo S. schrieb:
> Nano schrieb:
>> Prinzipiell sieht's doch so aus. Der Hoster bietet es an. Also ist es
>> sein Bier, wenn da was schief läuft.
>
> Nö, der bietet nur eine automatische Installation und autoupdate für
> Wordpress Core an. Für Plugins die nachträglich installiert werden gilt
> das aber sehr wahrscheinlich nicht.

Die Plugins lässt man natürlich weg und dann ist es so, wie gesagt, der 
Hoster trägt die Verantwortung.


> Nano schrieb:
>> Lag es aber an den Drittanbieterplugins oder am Kern der Software?
>
> Sowohl als auch. Wobei Core deutlich seltener.

Also, alles halb so schlimm.


> Nano schrieb:
>> Viele CVE Einträge sind kein Makel, sie sind sogar positiv zu sehen,
>> weil der Entwickler die Sicherheitslücken offen benennt, während andere
>> sie einfach unter den Tisch kehren und den Fix dann unprotokolliert
>> einfach unter den nächsten Patch schieben.
>
> Zum einen werden die NICHT vom Hersteller selbst gefunden und online
> gestellt und zum anderen auch nicht immer bestätigt. Auch wenn sie
> funktionieren!

Zero Day Sicherheitslücken die, wenn dann nur ein eingeschworener 
kleiner Kreis kennt, kann es bei jeder Software geben.

Und natürlich werden die Lücken auch von anderen gefunden und dann oft 
der Hersteller informiert. Gegenteiliges habe ich nicht behauptet.


> Manche Lücken wurden auch nicht mit dem nächsten Patch gefixt, oft
> müssten die Nutzer selbst Hand anlegen.

Das ist natürlich schlecht.

> Geh doch mal bitte selbst auf exploit-db.com, nutze die erweiterte Suche
> und such nur mal nach wordpress. Mittlerweile sind es hauptsächlich
> plugins die dort vertreten sind, wordpress core exploits bzw. Lücken
> sind älteren Datums.

Ja, es geht hier aber nur um den Kern, nicht um Plugins von Dritten.
Du findest auch über andere CMS auf eploit-db Einträge.

> Und nun mach das selbe mal für andere CMS.
> Joomla/Typo3 käme wohl als nächstes, jedenfalls läuft es auf eines von
> denen hinaus.

Wie ich oben schon sagte, die Anzahl der bekannten und protokollierten 
CVE Einträge sagt überhaupt gar nichts über die Sicherheit einer 
Software aus.
Wenn, dann muss man eher sogar sagen, dass sehr viele CVE Einträge gut 
sind und sehr wenige sind schlecht.

Denn letzteres bedeuten wenige CVE Einträge eins von dem folgenden:

1. Der Hersteller kommuniziert Sicherheitslücken nicht offen.
2. Es gibt zu wenige Nutzer, die nach Sicherheitslücken suchen oder auf 
diese stoßen.

Im ersten Fall bedeutet es, dass der Hersteller alles unter den Teppich 
kehrt. Administratoren können sich daher nicht darauf einstellen. Wenn 
Sicherheitslücken nicht klar kommuniziert werden, dann ist damit noch 
nicht einmal geklärt, ob man den nächsten Patch nun dringend einspielen 
muss und wenn man über eine bestimmte Sicherheitslücke Informationen 
suchen muss, dann gibt es keine CVE Nummer, nach der man suchen könnte. 
Man kann auch nicht herausfinden, ob und ab welcher Version die 
Sicherheitslücke gefixt wurde und welche Versionen davon betroffen sind. 
Deswegen ist das schlecht.

Im zweiten Fall kann man ne Software mit hunderten Sicherheitslücken 
haben ohne es zu wissen. Zu wenige Leute beschäftigen sich mit der 
Software, also ist sie entsprechend schlecht geprüft. Man kann das damit 
vergleichen, wenn man seine eigenen Verschlüsselungsroutinen 
implementiert, als sich auf bewährte Bibliotheken zu verlassen, die von 
vielen benutzt werden.

Also
10000 CVE Eintrge = gut
3 CVE Einträge = schlecht

So kann man das betrachten.
Nur der Laie sieht es umgekehrt.


>
> Nano schrieb:
>> Kümmert man sich dann nicht richtig drum und die Homepage wird zum
>> Umleiten auf sagen wir mal urheberrechtlich geschütze Filme mißbraucht
>
> Ach das macht doch schon lange kaum mehr jemand. Wenn laufen dann im
> Hintergrund Miner oder Exploit Tools die direkt auf die User PC's
> zielen. Auch beliebt ist es die mailfunktion von PHP zu nutzen um Spam
> zu versenden.
> Oder es werden webproxys geschaltet, webshells um von da aus andere
> Server zu hacken.
Ja, die Möglichkeit gibt es natürlich auch.

Aber es bleibt dabei, das betrifft nur die Webseitenbesucher und den 
Hoster, wenn man dessen CMS für das er die Verantwortung trägt, nutzt.
Nutzt man das eigene, dann ist man selber dafür verantwortlich.
Und darauf wollte ich mit meinen Beispiel ja hinaus.

> Filesharing geht heute leichter und sicherer als links über gehackte
> Seiten zu verteilen.
> (Darknet)

Das Tor Netzwerk mag kein Torrent über Tor. Und darüber ist es zu dem 
sehr langsam, das ist heute auch nicht viel besser geworden.

Deswegen werden Links zu Filehostern immer noch bevorzugt und die Links 
muss man irgendwo unterbringen. Dafür können solche gekaperten Webserver 
dienen.

> Trotz der geringeren Nutzerzahlen gut dokumentiert, Hilfe gibts in
> vielen Foren und die Zahl von exploits hält sich in Grenzen.

Eine geringe Nutzerzahl kann bedeuten, dass es da noch hunderte nicht 
bekannter Sicherheitslücken gibt.
Eine Zeroday Lücke dafür zu finden, kann bei dieser Software somit viel 
leichter sein, als bei einer viel benutzten Software wie Wordpress.

von Heiner (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Joern DK7JB .. schrieb:
> Es sollen rund sechs Hauptkategorien werden, die ich
> nun auch in den entsprechendne Namensräumen abbilden möchte.

Nativ, ohne irgendwelche Plugins, hat DokuWiki keine Kategorien. 
Struktur gibt es grundsätzlich über Namensräume. Zusätzlich möchte man 
vielleicht über das Plugin Tags nachdenken.

Joern DK7JB .. schrieb:
> Auch sollen
> die Kategorien natürlich links im Verzeichnisbaum/Inhaltsverzeichnis
> erscheinen.

Wenn sich das nicht täglich ändert und immer automatisch nachgezogen 
werden soll, macht man das von Hand: Du legst eine Seite namens 
"sidebar" an (kann in manchen Templates auch anders heißen), dort 
schreibst du direkt rein. Probier mal verschiedene Überschriften und 
Aufzählungen aus.

Wenn dir solche Funktionen wirklich fehlen: Genau deshalb habe ich oben 
noch das MediaWiki erwähnt. Natürlich ist das erheblich komplexer, aber 
dafür kann es eben mehr. Ob das ein Vorteil oder ein Nachteil ist, musst 
du selbst überlegen.

Joern DK7JB .. schrieb:
> Muss ich mit den Links auf die Kategorien immer auf der "start"-Seite
> beginnen oder kann ich die start-Seite frei mit irgendwelchen
> Hinweistexten gestallten?

Das kannst du machen, wie du möchtest. Seiten müssen auch gar nicht 
verlinkt sein, so wie z.B. die erwähnte "sidebar"-Seite. Am einfachsten 
legt man so etwas über die Suche an: Man sucht nach der Seite (die es 
nicht gibt) und ... lesen kannst du dann selber. :)

Joern DK7JB .. schrieb:
> Ist es richtig, dass Dokuwiki nur technische Cockies setzt und keine
> Benutzerstatistiken anlegt?

Ja, aber Plugins können das ändern. Das hier willst du zum Einstieg 
lesen:

https://www.dokuwiki.org/faq:cookies

von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
Joern DK7JB .. schrieb:
> Zum Dokuwiki habe ich noch einige Fragen:
> - Wie startet/plant man richtig das Projekt? Gemeint ist, wie man die
> Struktur und das Vorgehen richtig wählt, damit man später nicht so viel
> korrigieren muss.
> Es sollen rund sechs Hauptkategorien werden, die ich
> nun auch in den entsprechendne Namensräumen abbilden möchte.

Es ist ein Wiki, das darf auch wachsen :-)

Wenn du mit einer Sidebar arbeitest, bestimmen deine Namensräume dann 
auch gleich deine Navigation.

Seiten lassen sich problemlos von einem Namensräume in den anderen 
verschieben. Ob Links in anderen Artikeln gleich angepasst werden müsste 
ich ausprobieren.

Die Namensräume dienen dann auch dazu, deine Bilder und sonstigen 
Dateien die zu in den Artikeln einfügen möchtest, zu organisieren (Musst 
du bei Upload im Mediamanager dann halt in den gewünschten Namensraum 
tun.).

> Auch sollen
> die Kategorien natürlich links im Verzeichnisbaum/Inhaltsverzeichnis
> erscheinen.

Ja, genau. Meine Sidebar sieht so aus:
1
{{indexmenu>:#1| js#thread2 navbar noscroll msort tsort nsort notoc}}
2
\\
3
\\
4
----
5
6
Tag cloud
7
~~TAGCLOUD:18~~
8
9
----

> Muss ich mit den Links auf die Kategorien immer auf der "start"-Seite
> beginnen oder kann ich die start-Seite frei mit irgendwelchen
> Hinweistexten gestallten? Mir würde es reichen, wenn die Kategorien nur
> über den linken Verzeichnisbaum angewählt werden können und nicht auf
> der start-Seite auftauchen.

Das indexmenu plugin listet einfach alle Seiten im gewählten Namensraum 
auf. Das kannst du in der Sidebar verwenden oder auch auf 
Übersichtsseiten.

Die <namespace>:start Seite ist leicht speziell, da das indexmenu Plugin 
automatisch da hinzeigt für den Titeleintrag des <namespace> (ob das 
start heisst oder anders lässt sich in den Einstellungen des Plugins 
ändern).

Es empfiehlt sich, zu jedem Namespace auch eine "start"-Seite zu 
erstellen. Zum einen um dem Leser zu erzählen, um was es in diesem 
Namespace/Unterkategorie geht.
Zum anderen, weil so die Reihenfolge im indexmenu (entsprechend in der 
Sidebar) bestimmt werden kann.
Für den Namespace "texte" sieht das bei mir so aus:
https://brain4free.org/wiki/doku.php/texte:start
1
{{indexmenu_n>4}}
2
====== Texte ======
3
4
Hier sind ein paar Texte zu finden die ich gesammelt habe und sonst nicht mehr verfügbar sind oder ich selber, aus ganz verschiedenen Gründen, geschrieben habe.

Und steht dann an der 4. Stelle im Menu (es dürfen auch Lücken in der 
Nummerierung sein. Also vielleicht mit 10, 20, 40,... beginnen, dann 
kann man Namespaces dazwischen hinzufügen).

Hier ein Beispiel eines Artikels mit Bildergallerie, Bildern (links und 
rechts ausgerichtete), Links, Wikipedia Link, eingebettetes Video 
(zentriert) und Tags:
https://brain4free.org/wiki/doku.php/elektronik:plattenwaschmaschine

Hier der Dokuwiki Syntax dazu (gekürzt):
1
====== Plattenwaschmaschine ======
2
{{ :elektronik:plattenwaschmaschine:l1120857.jpg?256|}}
3
4
Ich bin ja, neben so anderen Sachen, sehr aktiv in der [[https://sfpd.cultlib.ch|Schweizerischen Stiftung Public Domain]].
5
6
Ich kann da auch auf den sehr guten (und langen) Wikipedia Artikel zur [[wpde>Schallplatte]] verweisen. Alles sehr interessant und vor ein paar Jahren hätte ich nicht gedacht, mal so direkt damit zu arbeiten.
7
8
===== Funktionsprinzip =====
9
Es gibt mehrere verbreitete Prinzipien wie eine Platte von der Reinigungsflüssigkeit befreit werden kann. Wichtig ist, dass keine Rückstände zurückbleiben (leider nicht bei jeder kaufbaren Maschine gegeben). Für mich hat es sich darum schnell auf ein Prinzip reduziert, nähmlich das dass auch von Keith Monks eingesetzt wird, der sogenannte Punktsauger.
10
11
Und weil es so schön ist, habe ich ein kurzes Video gemacht, um zu zeigen wie gut unsere Maschine, dank der starken Vakuumpumpe, eine Platte absaugen kann:
12
{{ :elektronik:plattenwaschmaschine:cleaning-demo.webm |}}
13
14
15
Anstatt noch viel zu schreiben, gibt es hier jetzt einfach Photos und Skizzen vom Bau der Maschine. Mit vielen Details wie, was, wo verbaut wurde.
16
17
{{gallery>:elektronik:plattenwaschmaschine}}
18
19
{{tag>Public Domain Platten Vinyl Waschmaschine Elektronik frei Musik audio openhardware opensource oshw}}
20
21
22
~~DISCUSSION:off~~

von Joern DK7JB .. (moin)


Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank, für eure Beiträge. Sie haben mir sehr geholfen. Ich werde 
bestimmt einiges übenrehmen, nachdem ich es ausprobiert habe.

Nun habe ich nur noch eine einzige Frage.
Wie kann ich unter Dokuwiki Linkpfade so erzeugen, dass sie genauso sind 
wie bei meinem alten Blog.
- Alter Link: 
https://www.bartelsos.de/dk7jb.php/calibration-of-oscillator-phase-noise
- Neuer Link: 
https://www.dokuwiki.bartelsos.de/doku.php?id=calibration-of-oscillator-phase-noise

Aus doku.php muss dk7jb.php werden und das ?id= muss ersetzt werden 
durch einen Schrägstrich.

: Bearbeitet durch User
von Martin (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Bei apache2 mit rewrite?

von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
Joern DK7JB .. schrieb:
> Aus doku.php muss dk7jb.php werden und das ?id= muss ersetzt werden
> durch einen Schrägstrich.

So wie Martin auch, hätte ich dir für diesen Zweck auch Apache 
mod-rewrite rules empfohlen.

von Joern DK7JB .. (moin)


Bewertung
0 lesenswert
nicht lesenswert
Wie viele rewrite rules sind erlaubt, ohne dass z.B. der Google-Bot 
abbricht oder die Seite zu langsam wird.

Da die Pfade sich doch stark unterscheiden, denke ich darüber nach die 
am häufigsten aufgerufenen Seiten direkt umzuleiten (40 Seiten und ca 
100 Dateien). Der Dokuwiki-Pfad würde dann einfach so bleiben, wie er 
nach der Installation voreingestellt war. Das würde vermutlich wiederum 
ein Update vereinfachen.

alt: https://www.bartelsos.de/dk7jb.php/tracking-generator-hp8594q
neu: 
https://www.dokuwiki.bartelsos.de/doku.php?id=oszillator:selbstbau:tracking-generator-hp8594q
(später natürlich ohne das "dokuwiki")

.htaccess-Eintrag: RedirectMatch 301 
www.bartelsos.de/dk7jb.php/tracking-generator-hp8594q(.*) 
www.dokuwiki.bartelsos.de/doku.php?id=oszillator:selbstbau:tracking-gene 
rator-hp8594q/$1
Ist ein solcher .htaccess Eintrag richtig?

Ist das Vorgehen sinnvoll? Muss man dann alle möglichen Links umleiten - 
ohne Ausnahme (vermutlich so um die 300)? Oder reicht es nur die 
Wichtigsten Links umzuleiten und den Rest auf die neue Homepage (neue 
Startseite) zu leiten?
Also alles mit www.bartelsos.de/dk7jb.php und irgendetwas folgendes 
(wenn es nicht schon umgeleitet worden ist) auf 
www.dokuwiki.bartelsos.de
Also z.B. https://www.bartelsos.de/dk7jb.php/hf-bastelplatine auf 
www.dokuwiki.bartelsos.de
Einfach nur um dem Besucher und dem Google-Bot zu helfen.
Wie würde ein solcher .htaccess Eintrag aussehen?

von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
Joern DK7JB .. schrieb:
> Wie viele rewrite rules sind erlaubt, ohne dass z.B. der Google-Bot
> abbricht oder die Seite zu langsam wird.

Wenn du dem Google-Bot 301 (Permanently moved) redirects zurücklieferst, 
wird er einfach weitermachen und brav seine Datenbank updaten. Das ist 
ja das Ziel vom 301 und der Bot möchte eine aktuelle Datenbank haben.

Ich habe keine Erfahrung mit Apache Performance.

Joern DK7JB .. schrieb:
> Ist das Vorgehen sinnvoll? Muss man dann alle möglichen Links umleiten -
> ohne Ausnahme (vermutlich so um die 300)? Oder reicht es nur die
> Wichtigsten Links umzuleiten und den Rest auf die neue Homepage (neue
> Startseite) zu leiten?

Müssen tust du gar nichts. Ist halt nett, wenn die alten Links noch 
gehen und die Suchmaschinen ihre alten Einträge ersetzen anstatt neue 
anzulegen.

Mir ist gerade eine Idee gekommen, wie du mit ganz wenigen Rewrite rules 
auskommen könntest. Startseite, Impressum etc. mit 301 weiterleiten so 
wie du vorgeschlagen hast aber alle anderen Seiten nicht einzeln 
weiterleiten (eben weil es viel zu viele Rules geben würde) sondern 
weiterleiten auf eine Seite mit passenden Dokuwiki Suchergebnissen.

z. B. bei mir ist die Such-URL: 
http://brain4free.org/wiki/doku.php/start?do=search&sf=1&q=%2A<suchbegriff>%2A

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.