Ankündigung

Einklappen
Keine Ankündigung bisher.

Foto Selfhosting CMS Projekt (start)

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Foto Selfhosting CMS Projekt (start)

    Hallo an die Coder!

    Der Bereich der Selfhoster von Fotos ist weit Abseits vom Mainstream. Ein paar wenige free CMS für Fotos sind weiterhin auf dem Markt. Einige von denen in einem unveränderten oldschool 1990er Look. Daneben gibt es noch kommerzielle CMSe, die hier außen vor gelassen werden. Plugins und dergleichen ebenso außen vor. Vor einigen Jahren verabschiedete sich Menalto (Gallery 3) wegen eines irreparablen Fehlers. Das letzte brauchbare CMS für Selfhosting von Fotos war zenPhoto. Doch auch dieses hat Fehler und ist im allgemeinen vollkommen überladen (Wollmilchsau). Von meiner Seite aus kann ich zenPhoto nicht mehr empfehlen. Zu großes Risiko in verschiedenerlei Hinsicht. Ich selbst bin deswegen vor einigen Wochen dazu gezwungen worden mich (mitten im Publizieren von Fotos) von zenPhoto zu verabschieden. Mein eigenes Frontend war einigermaßen schnell gecoded. Das Backend dauert etwas länger. Dabei bin ich von Anfang an so an die Sache heran, dass es möglich sein sollte, dass das von mir neu gecodete CMS markttauglich gestaltet wird. Aber von dieser Möglichkeit musste ich mich schon verabschieden, da ich nicht so gut im Coden bin. Deshalb würde ich gerne ein Projekt für ein CMS für Selfhosting von Fotos starten. Ich habe mittlerweile über 10 Jahre Erfahrung mit Selfhosting von Fotos und könnte von daher mein Wissen von Seiten eines Foto-Selfhosters beisteuern. Bei dem Projekt würde ich allerdings nicht selbst coden, sondern als Desinger bezüglich der Struktur und bezüglich einem Default-Frontend/Backend-Theme mitwirken. Das Coden würde ich denen überlassen, die das besser können. Was also gesucht wird sind PHP-Coder.

    Das CMS soll Opensource (Github?) und mit GNU-Lizenz sein.

    Das CMS soll an sich minimalistisch werden. Kein Multi-User. Single-User. Das CMS soll Usern ermöglichen auf sehr einfache Weise Fotos geordnet zu veröffentlichen. Die Web-Struktur (URL) ist gleich der Directory-Tree-Structur. Es wird unterschieden zwischen "Directory" (Verzeichnis) und "File" (Foto-Datei). Es soll einen (endless) "Stream" (per Ajax), sowie "Album-Page" (Directory) und "Single-Foto-Page" (File) geben (pure PHP). Der Upload von Ordnern und Fotos soll nicht per CMS, sondern per SFTP erfolgen. Der Nutzer uploaded Ordner und Fotodateien in ein spezielles Verzeichnis. Das soll ein Filesync mit Lokalen Dateien ermöglichen. Danach wird das Verzeichnis vom Backend aus "gescannt" und neue Ordner und Fotodateien werden in die Datenbank eingetragen. Danach kann der Nutzer die einzelnen Pages mit Title und Descriptions befüllen. Desweiteren sind Tags vorgesehen. Eine simple Suche würde vollkommen genügen. Eine not-human-readable Sitemap würde ebenso genügen, die vom Backend aus generiert werden kann. Als Feature soll es eine OpenLayers openstreetmap auf den Single-Pages und eine Map in einer Single-Page für alle Fotos geben. Das CMS soll so einfach sein, damit es sich jeder unproblematisch auf einem Webhost installieren kann. Hier mal die Struktur der Datenbank, aus der die Struktur des CMS abgelesen werden kann.

    Directorys
    id, parentid, directory, , dirtitle, dirdesc, dirshow, dirthumb, dirsortorder

    Files
    id, dirid, filename, filetitle, filedesc, fileshow, filesortorder, filegpslat, filegpslon

    dirtotag
    id, dirid, tagname

    filetotag
    id, fileid, tagname

    Lat/Lon werden OpenLayers-tauglich als dezimal mit max 6 Nachkomma (cm genau) Lat:"50.837363" Lon:"-12.635353" mit Vorzeichen gespeichert, kein Datenbank-Eintrag für Lat/Lon-Referenz (S/W/N/O).

    SEO URL
    Die URLs des CMS sollen sich nach der Verzeichnisstruktur des Verzeichnisses mit den Fotodateien richten. Dabei soll auf den Single-Foto-Pages die Fileextension abgeschnitten werden. Das hat einige Vorkehrungen im PHP zur Folge, weil Files auf Linux-Servern case-sensitive gespeichert werden können (.jpg, .JPG, .Jpg, ...). Da wäre etwas zu überlegen, oder der Dot wird in der URL in ein Minus umgewandelt. Zu vermeiden gilt es URLs für HTML Pages mit Fileextension like: example.com/summer.jpg oder example.com/summer.jpg.html. Angestrebt wird example.com/summer oder example.com/summer-jpg, example.com/summer-JPG. Mittels den SEO URLs wird unterschieden zwische Directory = "example.com/summer/" und Files = "example.com/summer", also mittels Slash am Ende.

    Für die Files soll es ein "resize" Verzeichnis geben, in das die verkleinerten Fotodateien für das Frontend und Backend gespeichert werden. Im Frontend werden in den Directory-Pages thumbnails und in den File-Pages resize-images angezeigt, sowie mit Klick auf ein resize-image das originale Foto in einer lightbox angezeigt.
    Desweiteren sind notwendig ein Verschieben von Diretorys und Files über das Backend, also SFTP und Datenbank synchron.
    Zudem im Backend die Mögkichkeit vom sortieren der Reihenfolge von Directories und Files für die Ansicht im Frontend/Backend.

    Beim Frontend sollen User eigene Themes verwenden können. Das könnte so gestaltet werden, dass das default-Theme von Updates ausgenommen wird und jeder das default-Theme nach belieben anpassen kann. Dazu werden Usern Variablen angeboten, die den Content (title, description, thumbnails-array, etc.) enthalten, mit denen er eigene Themes erstellen kann. Das Projekt sll hauptsächlich auf den "Core" reduziert werden. Die Sache mit den Themes wird ausgelagert.

    Das ist an sich sicher nicht viel. Dennoch müsste sich jemand zum mitmachen finden!

  • #2
    * Das Ganze ist schon zu eingeschränkt - Wieso nur ein User? Wieso nur sftp?
    * Sind Ordner notwendig, wenn es Tags gibt?
    * Bist Du sicher, dass es in Zeiten von Instagramm und Stock-Photo-Shops eine Zielgruppe für Dein CMS gibt? Da bin ich nämlich skeptisch
    * ...

    Insgesamt sieht das für mich eher danach aus, was _Du_ gerne hättest und nicht, was der Markt sucht.

    könnte von daher mein Wissen von Seiten eines Foto-Selfhosters beisteuern
    Und was soll das sein?

    Bei dem Projekt würde ich allerdings nicht selbst coden, sondern als Desinger bezüglich der Struktur und bezüglich einem Default-Frontend/Backend-Theme mitwirken.
    Das ist nicht gerade viel - Warum sollte da jemand kommen, der dann den Hauptteil der Arbeit tragen muss?

    Das soll kein Bashing sein und ich drücke Dir die Daumen, aber ich befürchte, da findest Du niemanden - Zumindest niemanden, der auch länger dabei bleibt.

    Kommentar


    • #3
      Naja, sagen wir es mal so, ich kenne den "Markt", und der ist sehr lau. Also ein neues CMS für Foto-Selfhosting würde einige begeistern. Man muss sich nur mal vorstellen, dass es immernoch, nach 5 Jahren ohne Support, Leute gibt die Menalto Gallery 3 verwenden und sich in einer Yahoo Community vernetzen. Das ist schon sehr abseits. Ein Wechsel zu zenPhoto wagen sie nicht. Ich hatte ihn gewagt und wurde böse enttäuscht.

      Was sollte es bringen, wenn ich mitcoden würde, wenn ich es eh nur mehr schlecht als recht kann? Ich kann jede Menge anderes relevantes beitragen, eben was so ein CMS können sollte und was nicht. Single-User wäre eines davon. Die meisten, die mir begegnet sind verwenden solche CMSe eh nur als Single-User. Wer solch ein Multi-User CMS verwenden will coded es sich entweder selbst, oder lässt es coden.

      Ich werde mir mein eigenes sowieso coden. Es wird nur nicht für den Markt taugen. Da ich aber weiß, dass andere sowas auch suchen und selbst nicht coden können, habe ich mal den Versuch für ein solches Projekt hier gestartet.

      Was nützt es einem Coder, wenn er keine Erfahrung mit Foto-Selfhosting hat und ein solches CMS ins Blaue hinein coded? Meist artet das so aus, dass das CMS mit irgendwelchen Gimmicks gespickt wird, mit denen ein Foto-Selfhoster wenig anfangen kann.

      SFTP deswegen, weil es übertrieben ist, bei einem File-System-basierten CMS das File-System per Backend im Browser zu regeln. Das wäre so als wenn man den Browser zum Filemanager ummodeliert. Solcherlei Schnickschnack kann man sich sparen, weil Foto-Selfhoster sowieso File-System-basiert arbeiten und da ist SFTP die beste Wahl. Auch bei Foto-Selfhosting gibt es Standards, die das Arbeiten leichter machen. Man muss sie nur vermitteln, dann werden sie von den Leuten auch eingehalten. Das Original ist local. Im Web ist immer nur eine Kopie. Beides in der selben Verzeichnisstruktur.

      PS: Foto-Selfhosting ist an sich eine müde Veranstaltung like Briefmarkensammeln oder Postkartensammeln. Dennoch schaut jeder User im Internet gerne Fotos. Bisher habe ich es geschafft meine Foto-Website suchmaschinenrankingmässig über die Jahre hinweg oben zu halten, konnte also bei allen Veränderungen mithalten, sogar bei Google Images, ohne Rechte am Bild abzugeben. Google Images darf Fotos nur indexieren (base64) in der von mir bestimmten Bildgröße, aber nicht hotlinken. Das soll aber nicht in das CMS von diesem Projekt default eingebaut werden. Das nur mal so erwähnt was ich alles für Erfahrung habe. Einige suchmaschinenkritische Dinge können gerne eingebaut werden.

      Kommentar

      Lädt...
      X