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!
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!
Kommentar