[PHP/Apache] Plaatjes direct vanaf filesystem of via PHP?

dinsdag 1 januari 2008 20:57

Acties:

0 Henk 'm!

Verwijderd

Topicstarter

Naar aanleiding van rob_erwt's post over mooie URL's op tweakblogs.net ben ik gaan nadenken over het behandelen van plaatjes binnen mijn CMS.

Als gebruikers van mijn CMS plaatjes uploaden, krijgt het plaatje op de server dezelfde naam als het geuploade origineel. De meta data wordt in de database opgenomen onder een image_id. Dus:

code:

+-------+------------------+------------+-------
|img_id |name              |mime        | etc...
+-------+------------------+------------+-------
|1      |tweakers-logo.gif | image/jpeg | ......
+-------+------------------+------------+-------

Het CMS maakt geen gebruik van een WISYWYG editor: gebruikers tikken zelf HTML in. Een popupje helpt de gebruiker een plaatje te selecteren. De popup voegt daarna een image tag met goede image source in, in de textarea waarin de gebruiker een artikel (oid) aan het typen is:

code:

1	<img src="images/tweakers-logo.gif">

Maar zoals rob_erwt zegt dat titels van blogposts kunnen veranderen, kunnen ook namen van plaatjes veranderen (althans: die optie wil ik gaan inbouwen). Als iemand een plaatje op de server dan hernoemt, kloppen de verwijzingen niet meer. Dus analoog aan tweakblogs zou een conventie als hieronder ideaal zijn:

code:

1	<img src="images/1/tweakers-logo.gif">

Nu heb ik het (vaste) img_id in de URL, en (voor de leesbaarheid voor de gebruiker) de naam. Dit vereist echter wel een verandering in de manier waarom het CMS plaatjes behandelt. Nu verwijst "images" immers nog naar een fysieke map binnen de webroot en wordt het plaatje uit die map getrokken. In de nieuwe situatie zou de naam uit de image source er niet meer toe doen: "images" gaat (via mod_rewrite) verwijzen naar een PHP pagina op de server, die kijkt welk plaatje hoort bij img_id "1" en duwt dit plaatje naar de client.

De gebruiker kan nu "tweakers-logo.gif" hernoemen naar "tweaklogo.gif" en ondanks dat er een artikel is waar nog een URL in staat die verwijst naar "tweakers-logo.gif", krijgt de client het goede plaatje voorgeschoteld.

Ik heb hier een aantal vragen over:

ondanks dat middels het img_id uit de image tag altijd het goede plaatje geserveerd wordt, zul je op termijn toch artikelen krijgen met hardcoded verwijzingen naar plaatjes die niet meer bestaan (tweakers-logo.gif bestaat immers inmiddels niet meer). Hoe zou ik dit tegen kunnen gaan?
kost het serveren van plaatjes via PHP niet teveel performance? Ik zou plaatjes die veel gebruikt worden (zoals plaatjes voor het sjabloon van de site) apart opslaan, zodat die nog steeds direct vanaf het FS worden geleverd
heb jij nog andere ideeen, bijvoorbeeld uit jouw CMS?

dinsdag 1 januari 2008 21:13

Acties:

0 Henk 'm!

FragFrog

Het eerste probleem is vrij simpel op te lossen: zorg voor een N:1 relatie tussen links en plaatjes in je database. Met andere woorden, twee tabellen gebruiken, eentje met daadwerkelijke plaatjes en hun ID's en eentje met plaatjes-namen en een corresponderend plaatje-ID. Als iemand het plaatje dan hernoemt voeg je aan die laatste tabel een nieuw record toe met de nieuwe naam, op die manier blijven alle links altijd werken.

Wat betrefd performance: dit is altijd een probleem natuurlijk, maar het hangt af van de hoeveelheid plaatjes. Zolang je alle kleine grut voor je template uit je filesystem haalt en enkel een paar plaatjes per pagina door je script laat serveren gaat dat doorgaans prima. Hangt ook een beetje af van hoe je het code natuurlijk

Qua tips: geef users de mogelijkheid een editor als TinyMCE te gebruiken. Niet alleen maakt dat je CMS een stuk toegankelijker voor mensen zonder ervaring met HTML, het voorkomt je ook een berg gezeur met niet afgesloten tags etc.

[ Site ] [ twitch ] [ jijbuis ]

woensdag 2 januari 2008 01:31

Acties:

0 Henk 'm!

DataGhost

iPL dev

FragFrog schreef op dinsdag 01 januari 2008 @ 21:13:
Het eerste probleem is vrij simpel op te lossen: zorg voor een N:1 relatie tussen links en plaatjes in je database. Met andere woorden, twee tabellen gebruiken, eentje met daadwerkelijke plaatjes en hun ID's en eentje met plaatjes-namen en een corresponderend plaatje-ID. Als iemand het plaatje dan hernoemt voeg je aan die laatste tabel een nieuw record toe met de nieuwe naam, op die manier blijven alle links altijd werken.

Totdat je plaatjea hernoemt naar plaatjeb en plaatjec naar plaatjea

Wat misschien een idee is, is bij het submitten van een pagina de plaatjes eruit filteren en die vervangen door de unieke ID's die in je database staan. Dat parse je elke keer dat de pagina wordt opgevraagd en zo haal je altijd het huidige plaatje op. Als de user de pagina wil editen parse je dat natuurlijk ook weer en de user ziet gewoon de link naar het plaatje zoals die op dat moment heet

woensdag 2 januari 2008 01:45

Acties:

0 Henk 'm!

Johnny

ondergewaardeerde internetguru

Je kan ook een extra tabel maken met daarin de ID's van de artikelen en de afbeeldingen die hij bevat. Wanneer een afbeelding een andere naam krijgt kun je dan een waarschuwing waarin staat in welke artikelen de afbeelding wordt gebruikt. je kunt dan aanbieden om de verwijzingen direct automatisch bij te werken. Op die manier hoef je niet bij iedere afbeelding, of artikel dat wordt opgevraagd te parsen en maak je het proces ook eenvoudige manier inzichtelijk voor de gebruiker.

Aan de inhoud van de bovenstaande tekst kunnen geen rechten worden ontleend, tenzij dit expliciet in dit bericht is verwoord.

woensdag 2 januari 2008 01:49

Acties:

0 Henk 'm!

FragFrog

DataGhost schreef op woensdag 02 januari 2008 @ 01:31:
Totdat je plaatjea hernoemt naar plaatjeb en plaatjec naar plaatjea

Nog nooit gehoord van unieke keys ofzo?

[ Site ] [ twitch ] [ jijbuis ]

woensdag 2 januari 2008 01:54

Acties:

0 Henk 'm!

DataGhost

iPL dev

FragFrog schreef op woensdag 02 januari 2008 @ 01:49:
[...]

Nog nooit gehoord van unieke keys ofzo?

Jawel, maar de bestandsnaam is op zich vrij. Ik vind het een beetje lomp om worst-case belachelijk/overbodig veel bestandsnamen te blokkeren, hoewel dat waarschijnlijk niet veel voorkomt

woensdag 2 januari 2008 02:20

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

Php

In het geval dat je een match op ID kan doen doet de 'nette filename' eigenlijk al niet meer ter zake, da's dan puur een 'versiersel'

Intentionally left blank

woensdag 2 januari 2008 09:26

Acties:

0 Henk 'm!

Cartman!

Waarom maak je niet een map waarin de gebruikers zelf bestanden kunnen uploaden? Dan krijg je gewoon een lijst met plaatjes (evt. thumbs die je maakt tijdens het uploaden). De gebruiker dubbelklikt op het plaatje in de popup (bijv.) en die sluit zich en de correcte url plaats je in het invoerveld terug. Als je zorgt dat ze niet kunnen renamen en verwijderen dan krijg je geen kapotte links en je haalt ze direct uit je filesystem.

woensdag 2 januari 2008 10:56

Acties:

0 Henk 'm!

Verwijderd

Topicstarter

Cartman! schreef op woensdag 02 januari 2008 @ 09:26:
Waarom maak je niet een map waarin de gebruikers zelf bestanden kunnen uploaden? Dan krijg je gewoon een lijst met plaatjes (evt. thumbs die je maakt tijdens het uploaden). De gebruiker dubbelklikt op het plaatje in de popup (bijv.) en die sluit zich en de correcte url plaats je in het invoerveld terug. Als je zorgt dat ze niet kunnen renamen en verwijderen dan krijg je geen kapotte links en je haalt ze direct uit je filesystem.

Dat is dus het hele punt; ik wil gebruikers de optie bieden om plaatjes wel te kunnen hernoemen.

crisp schreef op woensdag 02 januari 2008 @ 02:20:
In het geval dat je een match op ID kan doen doet de 'nette filename' eigenlijk al niet meer ter zake, da's dan puur een 'versiersel'

Ik heb het idee dat veel mensen over dat punt heenlezen. Omdat in de image source het id van het plaatje al staat, doet de naam er inderdaad in principe niet toe. De kwestie is alleen dat het slordig is als er nog verwijzingen staan naar plaatjes die niet meer bestaan, ook al wordt het plaatje via de image_id gewoon weergegeven...

Johnny schreef op woensdag 02 januari 2008 @ 01:45:
Je kan ook een extra tabel maken met daarin de ID's van de artikelen en de afbeeldingen die hij bevat. Wanneer een afbeelding een andere naam krijgt kun je dan een waarschuwing waarin staat in welke artikelen de afbeelding wordt gebruikt. je kunt dan aanbieden om de verwijzingen direct automatisch bij te werken. Op die manier hoef je niet bij iedere afbeelding, of artikel dat wordt opgevraagd te parsen en maak je het proces ook eenvoudige manier inzichtelijk voor de gebruiker.

DataGhost schreef op woensdag 02 januari 2008 @ 01:31:
Wat misschien een idee is, is bij het submitten van een pagina de plaatjes eruit filteren en die vervangen door de unieke ID's die in je database staan. Dat parse je elke keer dat de pagina wordt opgevraagd en zo haal je altijd het huidige plaatje op. Als de user de pagina wil editen parse je dat natuurlijk ook weer en de user ziet gewoon de link naar het plaatje zoals die op dat moment heet

Ik heb er dus ook aan gedacht om de input te scannen / filteren op image links en deze zonodig aan te passen. Het probleem hierbij was alleen dat een gebruiker plaatjes op verschillende manieren kan oproepen: hardcoded via een image tag, via een javascriptje dat een url samenstelt, of in een stylesheet. De eerste is te filteren, maar omdat de syntax die de gebruiker in z'n javascripts of css files gebruikt, onbekend is, kan ik die niet filteren en kan er dus nog steeds een probleem ontstaan als de plaatjes hernoemd worden.

Een oplossing hiervoor zou kunnen zijn om een technische manual te schrijven waarin staat dat de naam in de URL slechts eyecandy is en je een plaatje ook kunt aanroepen met een src met daarin alleen het id (img src="images/1" dus). Graag jullie meningen / oplossingen

woensdag 2 januari 2008 11:28

Acties:

0 Henk 'm!

FragFrog

DataGhost schreef op woensdag 02 januari 2008 @ 01:54:
Jawel, maar de bestandsnaam is op zich vrij. Ik vind het een beetje lomp om worst-case belachelijk/overbodig veel bestandsnamen te blokkeren, hoewel dat waarschijnlijk niet veel voorkomt

Dat bedoel ik juist, je geeft gewoon (optioneel) ook een uniek ID mee. Dan krijg je bijvoorbeeld '/images/13/blaat.jpg' of '/images/blaat_13.jpg'. In het eerste geval match je op ID zodat '/images/13/meuk.jpg' ook werkt, in het tweede geval match je op naam (en voeg je een nieuw record toe met de naam blaat.jpg) zodat je '/images/blaat_14.jpg' krijgt. vBulletin bijvoorbeeld gebruikt de tweede methode om topics te vinden terwijl React de eerste methode lijkt te gebruiken - da's vooral een kwestie van smaak

[ Site ] [ twitch ] [ jijbuis ]

woensdag 2 januari 2008 17:18

Acties:

0 Henk 'm!

rogierslag

Gebruik dat aanhangsel gewoon als SEO.

Tweakers.net maakt hier ook gewoon gebruik van. Zie bijvoorbeeld nieuws: 'Nunchuck'-controller voor mobieltjes in de maak. Zelf gebruik ik deze manier ook. Zie bijvoorbeeld http://www.abenslag.nl/page/specialisaties/5/incassos.html (die om onbekende redenen momenteel traag als stront is trouwens). Het achtervoegsel incassos.html dient enkel voor een grotere relevantie in de zoekmachineresultaten (dit vind ik spamming, want een statische website had ook dergelijke achtervoegsels gehad. Met mod_rewrite drop je gewoon dat achtervoegsel.

Met betrekking tot de huidige plaatjes, kan je 's nachts gewoon even je database locken en een find en replace uitvoeren waardoor alle verwijzingen in het vormaat images/plaatje.jpg worden omgevormd naar images/id_van_het_plaatje/plaatje.jpg. Daarna unlock je alles weer. Grote kans dat die 2 minuten wat zo'n actie maximaal duurt niemand iets heeft gemerkt. Het hernoemen van de bestandsnaam kan nu dus nog steeds, aangezien het plaatje duidelijk via het ID wordt opgehaald

Onderwerpen