[DISC] Hoe images verwerken binnen CMS?

De afgelopen maanden heb ik voor mijn eigen site een CMS'je geschreven dat ik binnenkort wellicht ook ga proberen te verkopen aan kleine ondernemingen.

Momenteel werkt het systeem als volgt: een gebruiker met voldoende rechten kan op een admin pagina plaatjes uploaden. Er wordt automatisch een thumbnail gemaakt en in de database wordt bijgehouden welke gebruiker dit plaatje wanneer heeft geupload. Dit alles werkt fantastisch, maar - zo blijkt nu ik er zelf mee moet werken - erg omslachtig.

Laatst had ik een aantal plaatjes gemaakt in Photoshop. Ik wilde ze snel online hebben, en heb ze direct naar de image map ge-ftp'd. Lekker makkelijk, maar op deze manier is de meta data niet opgeslagen in de database en is er geen thumbnail gemaakt.

Als ik het systeem wil verkopen, is het een nadeel dat als iemand ftp'd de zaak zo snel corrupt gemaakt is. Aan de andere kant - welke gemiddelde MKB-er zal ftp prefereren boven een upload pagina zoals ze die van bv. GMail etc. kennen?

Ik zit nu aan drie opties te denken:

• het systeem laten zoals het nu is en de discipline hebben om via de admin plaatjes te uploaden. Voordeel: het is al klaar. Nadeel: zie boven;
• het hele database / thumbnail gedoe eruit gooien en alleen ftp en een eenvoudige upload via de site aanbieden. Voordeel: makkelijk te realiseren. Nadeel: om snel te kunnen browsen door de plaatjes zijn thumbnails wel makkelijk en die ontbreken dan;
• een script schrijven dat regelmatig de inhoud van de image mappen vergelijkt met de thumbnails en database info en deze gelijk trekt. Voordeel: bullet proof. Nadeel: lastige oplossing. Het CMS geeft de mogelijkheid binnen de image map, (fysiek) submappen aan te maken. Je moet dus een recursieve (= resource intensieve) functie gaan bouwen om alles te controleren. Ik zou het mezelf makkelijker kunnen maken door de functie om plaatjes in submappen onder te verdelen, eruit te gooien.

Ik zou graag jullie mening / ervaringen horen op dit gebied. Hoe werkt jouw site / CMS? Welke voor- en nadelen zie jij in bovenstaande drie oplossingen? Waar zou je behoefte aan hebben en hoe schat jij gemiddelde gebruikers van een op het MKB gericht CMS in? Alle reakties zijn welkom!

Upsal schreef op donderdag 23 februari 2006 @ 20:50:
Je zou ook je plaatjes on-the-fly kunnen thumbnailen, als bijvoorbeeld de foto gallery wordt geladen, er een dynamisch tijdelijk plaatje zichtbaar wordt gemaakt (in php wordt het dan zoiets als [img]"thumbnail.php?img=../fotos/1.jpg"[/img]).

Je krijgt bovendien op dat moment wel een behoorlijke serverload...on the fly 20, 30 of meer thumbs in elkaar draaien...

TangLeFuzZ schreef op donderdag 23 februari 2006 @ 20:52:
Nog een optie is misschien om te zoeken naar een soort filemonitor, die continue op je server draait en in de gaten houdt of er een map is gewijzigd, en op basis van wijziging een script kan uitvoeren.
Zoiets zal vast wel bestaan (als het al niet standaard in je besturingssysteem zit... maar daar weet ik verder weinig vanaf ).

In principe wil ik mijn CMS (php / mysql) zo onafhankelijk mogelijk houden. Het moet geschikt zijn om op windows en niet-windows OS'en te draaien. Een cronjob bv. is dus geen optie. In het kader van portabiliteit zijn de opties om met een bepaalde interval een taak uit te voeren, beperkt. Momenteel voer ik onderhoudstaken om de 30 minuten uit. De taken (gedefinieerd in PHP functies) worden getriggerd door een pageklik. In de database ligt de timestamp van de volgende taakronde opgeslagen. Op elke pageview controleer ik de huidige tijd met die timestamp; zijn we voorbij de timestamp, dan trigger ik de functie php_cronjob(), die op zijn beurt weer alle aparte taken triggert. het idee is eigenlijk om elke automatische taak op dat systeem aan te sluiten, dus ook deze...

[ Voor 61% gewijzigd door Reveller op 23-02-2006 20:59 ]

neevedr schreef op donderdag 23 februari 2006 @ 21:11:
Het grote voordeel IMHO is dat het uploaden van meerdere afbeeldingen met FTP zo gemakkelijk gaat. Als je het eenvoudig uploaden van meerdere bestanden kan verwerken in je CMS ben je er volgens mij ook. Op welke manieren dit het handigst gedaan kan worden zou ik wel graag willen weten.

Voor het uploaden heb ik GMail (attachments bij email) na-geaapt: op de upload pagina staat 1 file input, maar je kan er extra toevoegen.Nadeel is wel dat je elk plaatje apart via zijn eigen file input moet aanwijzen op je lokale schijf. Wat dat betreft zou de zip oplossing van henronijboer een oplossing zijn.

JHS schreef op donderdag 23 februari 2006 @ 21:09:
Ik zou als basis optie 1 nemen. De functionaliteit van het uploaden via de browser door mkb'ers weegt ruim op tegen de corruptie risico's.

En dan in de handleiding erbij vermelden dat ftp-en de zaak corrupt maakt maar dat dat voor eigen risico is? Is dat gebruikelijk?

Een betere variant is afhankelijk van hoe je CMS met plaatjes omgaat. Moeten mensen ze includen in artikelen bijvoorbeeld, of bekijk je ze (vooral) vanuit een map(achtige) weergave?

Ik heb voor fysieke mappen gekozen, omdat ik dan (via een WYSIWYG of meer hardcore editor ) directe paden kan aangeven voor bv. plaatjes, zoals [img]"images/producten/appels.jpg">.[/img], waarbij je zowel een php script als een database nodig hebt om een plaatje te laden. Is dat wat je bedoelde?

[ Voor 3% gewijzigd door Reveller op 23-02-2006 21:33 ]

Eigenlijk is de eerste reden waarom ik voor vaste mappen gekozen heb, gebruiksvriendelijkheid. In eerste instantie schreef ik het CMS voor mijzelf, en ik typ liever een image source naar images/producten/appels.jpg dan naar images.php?id=354. Op de eerste manier kan ik nog eens iets uit mijn hoofd doen en ik verraad ook de achterliggende scriptaal niet (CMS werkt ook met vriendelijke URL's, dus icm fysieke mappen voor plaatjes ziet de bezoeker nog in de URL nog in de source de extensie .php staan ). Maar nu loop ik wel wat tegen de lamp hiermee...de keuze is nu dus (met dank aan iedereen die tot nu toe reageerde):

• FTP afraden en het systeem zo laten
• een script bouwen dat recursief door de mappen loopt en de database / thumbnail dir up-to-date houdt (en evt. om de load te beperken de submappen eruit gooien)

JHS schreef op donderdag 23 februari 2006 @ 21:54:
Hm, ik bedenk me net dat je op zich best images/producten/appels.jpg kan gebruiken, en dat m.b.v. je database gegevens weer kan "resolven" naar het image. Net zoals met je navigatie (i.i.g. zoals die uit vorige topics bleek) .

Heb ik ook aan gedacht en is in principe niet moeilijk. Maar ook dat levert wel extra load op, en de vraag is waarvoor: eigenlijk alleen om het schrijven van een script dat de integriteit in de gaten houdt wanneer iemand ftp'd, te vergemakkelijken. Of mis ik nu iets?