[ALG] Plaatjes in CMS: hernoemen of originele naam houden?

[Verwijderd]

Ik ben bezig met het plannen van de image-module voor mijn CMS. Met de image-module bedoel ik een onderdeel binnen mij CMS dat:

• de gebruiker in staat stelt om plaatjes te uploaden of te fetchen van een bepaalde URL
• de gebruiker tools biedt om deze plaatjes bij te snijden
• de plaatjes in mappen in kan delen

Nu zit ik met een grote vraag: als de gebruiker een plaatje uploadt, kan ik de naam van dit plaatje uitlezen en het plaatje op de server een gelijke naam geven. Als er al een plaatje met die naam bestaat, geef ik de toevoeging _0, _1 (dus: bestaand_plaatje_0.jpg). Ik kan er echter ook voor kiezen om bv. een md5-string aan te maken en het plaatje te hernoemen (dus: mijn_upload.jpg >> e365692167c426183780c1a956e37954.jpg)

Het grootste voordeel van de naam overnemen is de herkenbaarheid van het plaatje (steve_jobs_osx.jpg zegt meer dan e365692167c426183780c1a956e37954.jpg). Grootste voordeel van md5 is dat het plaatje meteen een unieke naam krijgt, en je geen excessieve namen krijgt als steve_jobs_PRESS_OSX_macworld_2005-140x100px.dbimg.gif.

Ik twijfel ook of ik de gebruiker een mogelijkheid wil geven om het plaatje te hernoemen. Nadeel hierbij is dat als het plaatje hernoemd wordt NADAT het in artikelen is opgenomen, je dode img-verwijzingen krijgt in die artikelen.

Het is wel ontzettend irritant om bv. een template of stylesheet te bouwen als alle plaatjes een md5 string als naam hebben:

Cascading Stylesheet:

.poll {
  background: url(images/e365692167c426183780c1a956e37954.gif) no-repeat;
}

Wat de beste methode is, hangt mede af van het soort editor dat je in je site implementeert. Stel dat elk plaatje op de server ligt opgeslagen als {md5-string}.jpg. Middels een database kun je unieke namen aan die plaatjes hangen. Vervolgens zou je een UBB editor kunnen bouwen waarbij je zoiets doet als:

code:

[b]Ik voeg hier een foto van mijzelf in[/b]
[img]zecco pasfoto[/img]

Als dit artikel opgeroepen wordt, match ik de unieke naam "zecco pasfoto" met het plaatje e365692167c426183780c1a956e37954.jpg en output de volgende HTML:

HTML:

<strong>Ik voeg hier een foto van mijzelf in</strong>
<img src="e365692167c426183780c1a956e37954.jpg">

Maar dat kan dan weer niet als je een WYSIWYG editor wilt implementeren (of: het wordt in ieder geval ontzettend lastig).

Kortom: een hoop issues die door mijn hoofd razen. Ik hoor graag hoe jullie met plaatjes omgaan binnen een CMS

[Spockz]

Je zou met een ID voor elk plaatje kunnen werken. Een md5 sum is namelijk ook niet altijd uniek. Dit ID kun je als middel gebruiken om het plaatje op te zoeken (in een db of iets) en daar de de echte naam aan te koppelen.

[Verwijderd]

Simpel zat. Het boeit mij niet hoe een plaatje heet. Mensen kunnen bestaande plaatjes niet hernoemen. Wij hebben dus wel een naam die is gebaseerd op de bestandsnaam, maar dan enigszins "gesanitized". Geen vreemde tekens, alles in lowercase, etcetera.

Als mensen een bestaande afbeeiding willen vervangen (dat kan wel) wordt de optie gegeven om de bestandsnaam te behouden. Mensen mogen zelf bedenken dat artikelen waarin die afbeeldingen voorkwamen niet meer zullen kloppen. Dat is een kwestie van instrueren, niet van een heel log controlesysteem maken.

En je gaat toch niet template/layout-afbeeldingen verwarren met content-afbeeldingen? Voor het eerste ga je natuurlijk geen namen laten genereren.

[Verwijderd]

Verwijderd schreef op maandag 20 augustus 2007 @ 19:29:
Simpel zat. Het boeit mij niet hoe een plaatje heet. Mensen kunnen bestaande plaatjes niet hernoemen. Wij hebben dus wel een naam die is gebaseerd op de bestandsnaam, maar dan enigszins "gesanitized". Geen vreemde tekens, alles in lowercase, etcetera.

En de reden daarvoor is dus de leesbaarheid? Staat het plaatje op de FS of in een DB? Roepen gebruikers een plaatje aan via een UBB-tag (oid) of kan het ook via een reguliere image-tag (<img src="mijn-sanitized-plaatje.gif">)?

Als mensen een bestaande afbeeiding willen vervangen (dat kan wel) wordt de optie gegeven om de bestandsnaam te behouden. Mensen mogen zelf bedenken dat artikelen waarin die afbeeldingen voorkwamen niet meer zullen kloppen. Dat is een kwestie van instrueren, niet van een heel log controlesysteem maken.

Ik zat eraan te denken dat ik user-generated content (pagina's, artikelen, etc.) zou scannen op plaatjes en dan een tabel zou maken content_id -- used_images, zodat ik een error kan geven als gebruikers een plaatje willen gebruiken dat in een bestand aangeroepen wordt. Hier zitten wel haken en ogen aan: je moet ook stylesheets, js-files etc. scannen. Maar in de laatste kan een plaatje ook dynamisch aangeroepen worden. Dat zorgt ook weer voor problemen. Allemaal op te lossen, maar dat is ws. wat jij met "log" bedoelt

En je gaat toch niet template/layout-afbeeldingen verwarren met content-afbeeldingen?

Dat was ik wel van plan eigenlijk, maar ik begrijp uit je reaktie dat dat niet echt best-practice is Heb jij een aparte upload-procedure / sectie voor template / content-afbeeldingen? En ik begrijp dat template-afbeeldingen niet gesanitezed worden?

[Verwijderd]

Je kunt ook iedere afbeelding in z'n eigen mapje stoppen waarbij de naam van het mapje uniek is (bijvoorbeeld relatief aan het artikel waarin het gebruikt wordt).

Wel zou ik persoonlijk altijd de extensie overschrijven adhv het type zoals geidentificeerd.

[ Voor 22% gewijzigd door Verwijderd op 20-08-2007 19:47 ]

[Verwijderd]

Verwijderd schreef op maandag 20 augustus 2007 @ 19:44:

En de reden daarvoor is dus de leesbaarheid? Staat het plaatje op de FS of in een DB? Roepen gebruikers een plaatje aan via een UBB-tag (oid) of kan het ook via een reguliere image-tag (<img src="mijn-sanitized-plaatje.gif">)?

De reden is dat ik geen gedoe wil krijgen met meerdere bestanden die op een Linux-bestandssysteem wel verschillen qua bestandsnaam, maar onder Windows maakt dat nog steeds niets uit. Ik wil geen collisions, en dus gaat alles naar lowercase. Dat tikt bovendien lekkerder in de console.

Ik zat eraan te denken dat ik user-generated content (pagina's, artikelen, etc.) zou scannen op plaatjes en dan een tabel zou maken content_id -- used_images, zodat ik een error kan geven als gebruikers een plaatje willen gebruiken dat in een bestand aangeroepen wordt. Hier zitten wel haken en ogen aan: je moet ook stylesheets, js-files etc. scannen. Maar in de laatste kan een plaatje ook dynamisch aangeroepen worden. Dat zorgt ook weer voor problemen. Allemaal op te lossen, maar dat is ws. wat jij met "log" bedoelt

Precies. Dat moet je helemaal niet willen. Als een gebruiker een plaatje verwijdert dat nog ergens gebruikt wordt, dan is het plaatje dus "kapot". Het is niet anders. Dat is een stukje eigen verantwoordelijkheid. En dat moet je niet wegnemen, je moet gebruikers van het CMS opleiden (of beter: opvoeden). Dat vind ik tenminste. En onze klanten accepteren dat ook. Het is namelijk helemaal niet moeilijk te begrijpen.

Dat was ik wel van plan eigenlijk, maar ik begrijp uit je reaktie dat dat niet echt best-practice is Heb jij een aparte upload-procedure / sectie voor template / content-afbeeldingen? En ik begrijp dat template-afbeeldingen niet gesanitezed worden?

Een CMS moet van template bestanden afblijven. Het is een content-managementsysteem. Je moet onderscheid maken tussen wat inhoud is, en wat niet. Een gewoon CMS hoort van stylesheets, templateafbeeldingen en scripts af te blijven. Eventueel mag er dynamisch iets toegevoegd worden, maar van de originele statische templatebestanden moet worden afgebleven. Maar dat is slechts mijn mening.

[Verwijderd]

Verwijderd schreef op maandag 20 augustus 2007 @ 19:55:
[...] De reden is dat ik geen gedoe wil krijgen met meerdere bestanden die op een Linux-bestandssysteem wel verschillen qua bestandsnaam, maar onder Windows maakt dat nog steeds niets uit. Ik wil geen collisions, en dus gaat alles naar lowercase. Dat tikt bovendien lekkerder in de console.

En waarom kies je er dan nog steeds voor om (hetzij sanitized), leesbare bestandsnamen te houden ipv numerieke (vb. md5 of rand())?

[...] Een CMS moet van template bestanden afblijven. Het is een content-managementsysteem. Je moet onderscheid maken tussen wat inhoud is, en wat niet. Een gewoon CMS hoort van stylesheets, templateafbeeldingen en scripts af te blijven. Eventueel mag er dynamisch iets toegevoegd worden, maar van de originele statische templatebestanden moet worden afgebleven. Maar dat is slechts mijn mening.

Misschien is CMS dan geen goede beschrijving voor wat ik maak. Gebruikers kunnen content managen via hun browser, maar ook templates en css bestanden aanpassen (mits zij hiervoor de goede rechten hebben). Het is (yet another ) systeem waarmee een website in zijn geheel via een browser te onderhouden is. Ik maak geen industrieel CMS (waar jij misschien mee bezig bent ) maar een CMS voor MKB

Maar begrijp ik het goed dat binnen jullie CMS plaatjes die bij content horen geupload kunnen worden via een browserinterface, maar dat template plaatjes buiten het systeem om behandeld worden (bijvoorbeeld via FTP)?

[Verwijderd]

Verwijderd schreef op maandag 20 augustus 2007 @ 21:34:

En waarom kies je er dan nog steeds voor om (hetzij sanitized), leesbare bestandsnamen te houden ipv numerieke (vb. md5 of rand())?

Omdat je alleen maar een unieke naam hoeft te hebben. Geen onherkenbare. Maak het dan ook niet onherkenbaar.

Misschien is CMS dan geen goede beschrijving voor wat ik maak. Gebruikers kunnen content managen via hun browser, maar ook templates en css bestanden aanpassen (mits zij hiervoor de goede rechten hebben). Het is (yet another ) systeem waarmee een website in zijn geheel via een browser te onderhouden is. Ik maak geen industrieel CMS (waar jij misschien mee bezig bent ) maar een CMS voor MKB

Wil het MKB een hele website onderhouden dan? Doe eens een marktonderzoek, zou ik zeggen.

Maar begrijp ik het goed dat binnen jullie CMS plaatjes die bij content horen geupload kunnen worden via een browserinterface, maar dat template plaatjes buiten het systeem om behandeld worden (bijvoorbeeld via FTP)?

Zo ongeveer.

[Verwijderd]

Verwijderd schreef op maandag 20 augustus 2007 @ 22:08:
[...]
Omdat je alleen maar een unieke naam hoeft te hebben. Geen onherkenbare. Maak het dan ook niet onherkenbaar.

Dat vind ik een goed argument Heb hier alleen nog een vraag over: geef je de gebruiker een mogelijkheid om bij het uploaden een andere (unieke) naam aan het plaatje toe te kennen? Ik heb bv. eens een plaatje geupload dat steve_jobs_PRESS_OSX_macworld_2005-140x100px.dbimg.gif heette. Wat zou dan de sanitized versie hiervan zijn?

Als ik het goed begrijp kunnen gebruikers plaatjes dus na upload niet hernoemen, maar wel onder een al bestaande titel een vervangend plaatje hangen. Wat doe je dan als iemand een plaatje wil uploaden onder een naam die al bestaat op de server? Geef je dat aan of hernoem je het plaatje automatisch (net zoals Windows (1), (2) etc. achter de bestandsnaam zet)?

[xtra]

Verwijderd schreef op maandag 20 augustus 2007 @ 21:34:
[...]
Misschien is CMS dan geen goede beschrijving voor wat ik maak. Gebruikers kunnen content managen via hun browser, maar ook templates en css bestanden aanpassen (mits zij hiervoor de goede rechten hebben). Het is (yet another ) systeem waarmee een website in zijn geheel via een browser te onderhouden is. Ik maak geen industrieel CMS (waar jij misschien mee bezig bent ) maar een CMS voor MKB

Een CMS met beheerfuncties kan een grote meerwaarde zijn voor het MKB, of het nu gaat om het aanpassen van templates of het aanmaken van gebruikersaccounts. Aangezien je hiervoor niet echt het wiel opnieuw hoeft uit te vinden lijkt me een marktonderzoek meer kosten dan het oplevert.

Bij "Content Management" wil je het beheren van inhoud zo eenvoudig en foutloos mogelijk maken. Een functie die waarschuwt als je een afbeelding wilt verwijderen die in gebruik is sluit volledig aan bij dat doel. Dan kunnen de gebruikers zich bezighouden met de inhoud en hoeven niet van een klant te horen dat de site vol kruisjes staat.

Zelf kies ik altijd voor om waar mogelijk het resultaat (de html etc.) zo leesbaar mogelijk te houden. Dus waar mogelijk zinvolle bestandsnamen. (Waar je best spaties en andere vreemde tekens uit kunt halen om andere problemen te voorkomen.) Dit sluit beter aan bij de gedachten van de gebruiker en maakt het (zeker bij md5) makkelijker eens een probleem op te zoeken.
Bij dubbele bestandsnamen kun je nog de keuze geven om te overschrijven of de naam te wijzigen.