IMO zu dem Unmark Bookmarkservice

Unmark ist auch eine nette Alternative für Wallabag, besitzt aber leider ein paar Ecken und Kanten

Unmark ist ein Bookmarkservice, welche sich auf dem eigenen Server, oder auch einem shared Webhost installieren lässt. Das Responsivedesign gefällt mir ziemlich gut und auch die Unterkategorien für die Bookmarks, sowie die Anzeige als Timeline machen Ihn zu einem guten Todolistmanager und Bookmarkmanager der Kategorie ReaditLater.

 

Unmark demo
DemoGif von https://Unmark.it

 

Ein Vorteil von Unmark gegenüber von Wallabag ist die fehlerfreie Installation ohne die Notwendigkeit von composer. Was Wallabag in der Version 2 geritten hat, ist mir immer noch nicht klar. Ich habe es bis jetzt nicht geschafft bei einem shared Webhoster die neue Version zu installieren und auch die Dokumentation betreffend der Konfigurationsdatei ( app/config/parameters.yml )von wallabag möchte einfach nur jeden Einsteiger abschrecken, anstelle Ihn zu unterstützen. Hier macht es sich unmark einfach wie ein WordPress, oder jedes andere CMS, und gibt sich mit einer Umgebung aus php, mySQL und Webserver zufrieden. Ein kopieren der Dateien in ein Verzeichnis, kopieren und editieren der sich selbst erklärenden Konfigurationsdatei und per https://FQDN/setup ist unmark installiert.

Aber leider bietet Unmark leider nicht die Anwendungen für Smartphones und Tablets wie wallabag. Auch ist der Import eher rudimentär und bietet keine Übernahme der Daten aus Pocket. Schade eigentlich, ich denke ich hätte gern ein wenig mehr mit der Software gespielt.

Fazit: Wer ein laufendes Wallabag hat, sollte auch bei diesem bleiben.

6 Comments

  1. Compozer hat halt den Vorteil, dass die verwendeten Bibliotheken schön reingezogen werden. Zugegeben, Benutzerfreundlich ist was Anderes – aber dafür eher Admin-Freundlich.

    1. Da gebe ich Dir schon Recht. Nur dem Endanwender ist das schon fast zuviel.
      Frage doch mal einen unbedarften wohin denn Composer die Abhängigkeiten installiert. Du bekommst wundersame Antworten.
      Auch stand ich schon an einigen Servern an welchen Composer genau das Problem ist, da es nicht per Paketmanager einem Update unterzogen wird.
      Es sind halt wieder mehrere Hochzeiten auf welchen getanzt wird.
      Als Administrator könnte ich mir ein Playbook schreiben, aber wenn ich schon selbst bei jedem Webhoster Hand anlegen muss, dann fühle ich mich schon ein wenig genervt. Es gibt Moment in welchen ich auch mal nicht als Bughunter unterwegs sein möchte und mich erfreue nicht Zeit in etwas massiv zu investieren.
      Vor allem wenn man sich auf die Fahne schreibt doch dem Endnutzer die Macht über seine Daten zu geben…

  2. Ich löse es in meinem Hosting derzeit einfach durch verschiedenste Scripts die alle den gleichen Namen haben und je nach WebApp vom git pull bis hin zum composer command managen, da ich sonst einfach nicht mehr fertig werde.

    Composer wurde – so mein Info-Stand – eigentlich für *Entwickler* gemacht um immer die gleiche Umgebung ziehen zu können.

    1. Wie ich sagte, ein Playbook schreiben. Ansible kann da helfen.
      Einiges ist in der Webentwicklung im Unargen und nun den schwarzen Peter immer PHP hinzuschieben ist nicht wirklich die Lösung.
      Hipstersprachen mit aller Gewalt nutzen ist halt falsch. Die richtige Sprache für die stehende Anforderung.
      Aber dies ist doch nicht wirklich gewollt. Wäre nicht Fresh;)

Schreibe einen Kommentar

You have to agree to the comment policy.