[PHP] uploaden foto en weergeven op pagina.

[L01]

Ik wil een webpagina maken waarbij een gebruiker zijn producten kan invoeren. Deze worden opgeslagen in een mysql database.

Dit is geen probleem om te maken maar nu wil ik het volgende: de gebruiker moet een plaatje kunnen uploaden naar de server. Dit plaatje wordt dan ook getoond bij de product informatie.

Het liefst in een vooraf opgegeven groote en dan een link naar een grotere weergave maar ik weet niet of dit mogelijk is.


Hoe moet ik dit aanpakken? Wordt bijvoorbeeld de file in de database gezet of moet dit worden geupload naar een map?

Alvast bedankt, mijn kennis van php is erg klein en ik maak vooral gebruik van macromedia dreamweaver.

[NMe]

Het makkelijkste is het om gewoon te uploaden naar de server en dan de file op het bestandssysteem op te slaan. Wanneer je het in de database zet creëer je alleen maar extra overhead.

Kijk eens naar de $_FILES array in de documentatie, dan kom je wel op de goede functies uit om te doen wat jij wil.

[Verwijderd]

De link naar het bestand zet je dan uiteraard wel in de database (relatieve link). Zie ook:
http://nl.php.net/manual/en/features.file-upload.php

[ixi]

Voor het resizen kun je gebruik maken van:

http://nl.php.net/manual/en/function.imagecopyresampled.php

Let op dat je PHP.INI zo insteld dat je script genoeg geheugen kan gebruiken. Bij grote plaatjes kan de standaard-instelling wel eens te weinig zijn. Hou ook rekening met de verhoudingen van de plaatjes.

Wil je de plaatjes ook opslaan in de database (handig voor backups..) kijk dan eens op:
http://www.phpbuilder.com/columns/florian19991014.php3

[ Voor 20% gewijzigd door ixi op 01-12-2004 01:13 ]

[NMe]

Verwijderd schreef op woensdag 01 december 2004 @ 01:01:
De link naar het bestand zet je dan uiteraard wel in de database (relatieve link). Zie ook:
http://nl.php.net/manual/en/features.file-upload.php

Links hoef je niet eens in de database te zetten, mits je maar één plaatje per record hebt. Je kan dan gewoon de primary key in de filenaam zetten.

[Verwijderd]

Het voordeel van het plaatje in de database is dat je de database makkelijker op een andere server kan zetten zonder dat je met directories moet gaan rommelen.

[NMe]

Verwijderd schreef op woensdag 01 december 2004 @ 01:53:
Het voordeel van het plaatje in de database is dat je de database makkelijker op een andere server kan zetten zonder dat je met directories moet gaan rommelen.

Het grote nadeel is dat je database er log van wordt, en bovendien een stuk trager. Bovendien moet je code schrijven om data uit de database om te zetten naar een plaatje. Het filesystem is bedoeld voor files, een database is bedoeld voor data/gegevens. En daar behoren plaatjes IMHO niet toe.

[Grijze Vos]

-NMe- schreef op woensdag 01 december 2004 @ 02:23:
[...]

Het grote nadeel is dat je database er log van wordt, en bovendien een stuk trager. Bovendien moet je code schrijven om data uit de database om te zetten naar een plaatje. Het filesystem is bedoeld voor files, een database is bedoeld voor data/gegevens. En daar behoren plaatjes IMHO niet toe.

Hij stelt voor om de link naar een file in de DB te zetten, is toch niks mis mee.

--------

ixi> Voor die functies moet zijn webserver wel uitgerust zijn met GDlib, en als ie een webhoster heeft, is de kans groot dat die er niet op staat. Tevens verhoogt een webhoster niet zomaar het geheugengebruik. Dus dat heeft nogal wat haken en ogen.

[Verwijderd]

-NMe- schreef op woensdag 01 december 2004 @ 02:23:
[...]

Het grote nadeel is dat je database er log van wordt, en bovendien een stuk trager. Bovendien moet je code schrijven om data uit de database om te zetten naar een plaatje. Het filesystem is bedoeld voor files, een database is bedoeld voor data/gegevens. En daar behoren plaatjes IMHO niet toe.

Alleen zie je tegenwoordig dat moderne filesystemen steeds meer weg hebben van databases, met als hoogtepunt WinFS, moet je ook code schrijven om data vanaf disk naar een plaatje om te zetten (vrij triviaal, maar dat is het vanuit een database ook) en dat je database er een stuk trager van wordt? Ja als je enkel select * doet. Maar dat is sowieso geen goed idee qua performance. Bij normaal gebruik zijn er eigenlijk totaal geen performance verschillen.

Binary data is een heel normaal verschijnsel in een database en de hier genoemde nadelen zijn eigenlijk al jaren acherhaalt als ze al ooit reeel geweest zijn.

[Skaah]

Verwijderd schreef op woensdag 01 december 2004 @ 01:53:
Het voordeel van het plaatje in de database is dat je de database makkelijker op een andere server kan zetten zonder dat je met directories moet gaan rommelen.

Ik had een database met enkele (driehonderd) foto's erin. Dat was echt sop. Het duurde heel lang om er gegevens uit te krijgen. Daarna geswitched naar random bestandsnamen + bestandsnaam in de database en niets dan een zegen.

edit:
Het ging hierbij om een MySQL 3.2x database op een dual PIII 500. Bij "SELECT foto_id FROM tabel ORDER BY RAND() LIMIT 1" ging het helemaal sop (duurde 5 à 6 seconden) terwijl de indeces wel goed stonden.

Wat je moet doen:

1. Het geuploade bestand kopieëren naar een map en het een random bestandsnaam geven
2. Een entry in de database maken (alleen de bestandsnaam, het pad zet je ergens in je config.php bestand ofzo)
3. Een thumbnail maken en die aan de gebruiker geven.

Voor het resizen van een 3.1MP foto met GD heb je moet memory_limit minimaal op 32M staan. (16 en 8 waren te weinig).

[ Voor 29% gewijzigd door Skaah op 01-12-2004 11:41 ]

[Verwijderd]

Skaah schreef op woensdag 01 december 2004 @ 11:37:
[...]
Het ging hierbij om een MySQL 3.2x database op een dual PIII 500. Bij "SELECT foto_id FROM tabel ORDER BY RAND() LIMIT 1" ging het helemaal sop (duurde 5 à 6 seconden) terwijl de indeces wel goed stonden.

En geloof je zelf dat dat aan die 300 foto's lag? Wij hebben hier systemen met duizenden foto's in een Oracle database en een select op een geindexeerd ID veld wordt daar echt geen milliseconde trager door.

[Erkens]

Verwijderd schreef op woensdag 01 december 2004 @ 13:42:
[...]


En geloof je zelf dat dat aan die 300 foto's lag? Wij hebben hier systemen met duizenden foto's in een Oracle database en een select op een geindexeerd ID veld wordt daar echt geen milliseconde trager door.

oracle is wel een betere db dan mysql imo

[L01]

ik heb nog eens een beetje zitten kijken en ik begrijp er niets van wat jullie allemaal tikken

Op forum kan je soms wel eens een plaatje bij je bericht toevoegen, dat systeem zoek ik dus.

Ik zit nu al 2 weken te zoeken maar ik kan niets vinden dat echt werk, iets iets waarmee je een file kan uploaden (http://www.php4you.nl/artikelen/tonen.php?id=54) maar hoe kan je dat bestand dan koppelen aan een product in de database?

[Pollus]

tja... verdiep je eens in SQL zou ik zeggen.

Je INSERT gewoon de naam van het plaatje in de database.

even heel simpel:
INSERT INTO plaatjes_db (plaatje_name)
VALUES (
'plaatje_name')";

[plakbandrol]

Pollus schreef op maandag 13 december 2004 @ 16:39:
tja... verdiep je eens in SQL zou ik zeggen.

Je INSERT gewoon de naam van het plaatje in de database.

even heel simpel:
INSERT INTO plaatjes_db (plaatje_name)
VALUES (
'plaatje_name')";

of nog makkelijker, je slaat het plaatje op als de ID van de betreffende SQL entry

dus product met ID 344 heeft als plaatje 344.jpg

(ik neem aan dat er dus 1 plaatje per product is)

[Bosmonster]

Erkens schreef op woensdag 01 december 2004 @ 13:44:
[...]

oracle is wel een betere db dan mysql imo

Dan nog.. de data voor een foto, of wat voor bestand dan ook, staat gewoon in een BLOB veld. Dat is niet anders dan anders bij het ophalen van een record aan de hand van een key.

Dus als zijn database traag is kan dat imho onmogelijk te maken hebben met wat bestanden die er in opgeslagen zijn.

[ Voor 15% gewijzigd door Bosmonster op 13-12-2004 17:06 ]

[Verwijderd]

Hier een beetje ruwe code van een upload script van mijzelf dat de file gewoon 001.JPG noemt

PHP:

<? 

// De variabelen 

$path = "/var/www"; 
$file_size_max = 5000 * 1024; 
$possible_size = round($file_size_max / 1024); 
$possible_extensions = array ('jpg', 'jpeg');  
$count_possible_extensions = count($possible_extensions);  

if (!$case) 
{    
$case = 1;    
}    
switch ($case) 
{ 
    
case 1: 
?> 
<form action="<? echo $_SERVER['PHP_SELF']; ?>" method="post" enctype="multipart/form-data"> 
<table border="0" cellspacing="0" cellpadding="4"> 
<tr> 
<td> 
<b>Plaatje:</b> <? echo "$imagenr" ?>
<br> 
<br> 
<b>Maximaal:</b> <? echo "$possible_size"; ?> kb 
<br> 
<b>Extensies:</b> 

<? 
for ($i = 0; $i < $count_possible_extensions; $i++ ) 
{  
echo $possible_extensions[$i] . "&nbsp;&nbsp;";  
}  

?>   
<br> 
<br> 
<input type="file" name="plaatje" size="40"> 
<br> 
<br> 
<input type="hidden" name="case" value="2"> 
<input type="submit" value="Upload"> 
</td> 
</tr> 
</table> 
</form> 
<? 
break; 

case 2: 

if(!$_FILES[plaatje]) 
{ 
echo"Je hebt geen plaatje geselecteerd"; 
} 
if($_FILES[plaatje]) 
{ 
$file_size = round($_FILES[plaatje][size] / 1024); 
$file_type = $_FILES[plaatje][type]; 
$file = basename($_FILES[plaatje][name]); 
$ext = explode(".", $file); 
$file_extension = $ext[1]; 
$file_name = $ext[0]; 

if($file_size > $possible_size) 
{ 
echo "<b>Fout:</b> Uw plaatje is groter dan <b>$possible_size</b> kb"; 
} 
if (!in_array(strtolower($file_extension),$possible_extensions)) 
{  
echo "<b>Fout:</b> Uw plaatje is niet van het type: "; 

for ($i = 0; $i < $count_possible_extensions; $i++ ) 
{  
echo "<b>$possible_extensions[$i]<b>&nbsp;&nbsp;";  
}  

} 
else 
{ 

// De naam van de file veranderen in bv. artikel_pic0 

$file_name = "001";    
$n = 0;  
$temp_name = $file_name;  



if(move_uploaded_file($plaatje, $path . $file_name . "." . JPG)) 
{ 
echo"De foto <b>$file</b> van <b>$file_size</b> kb, met de extensie <b>$file_extension</b> is geupload naar <b>$path</b> als <b>$file_name</b>"; 
} 
else 
{ 
echo"Het uploaden van <b>$file</b> is niet gelukt"; 
} 
} 
} 
break; 
} 
?> 

[ Voor 19% gewijzigd door Verwijderd op 27-12-2004 17:10 ]

[Erkens]

Bosmonster schreef op maandag 13 december 2004 @ 17:05:
[...]


Dan nog.. de data voor een foto, of wat voor bestand dan ook, staat gewoon in een BLOB veld. Dat is niet anders dan anders bij het ophalen van een record aan de hand van een key.

True

Dus als zijn database traag is kan dat imho onmogelijk te maken hebben met wat bestanden die er in opgeslagen zijn.

maar wellicht wel aan de grote van de records, ik weet niet precies hoe mysql grote BLOB's opslaat, en ook heb ik het nog steeds niet getest, ik doe dan ook geen uitspraken hierover anders dan dat oracle een "betere" db is dan het populaire mysql en dat betere moet je dan vooral lezen als "mogelijkheden" maar waar ik eigenlijk op doelde was het feit dat een oracle db werd vergeleken met mysql.

[ Voor 8% gewijzigd door Erkens op 13-12-2004 19:52 ]

[PanMan]

Ik zal het zelf ook niet zo snel doen in de praktijk, maar foto's in een db stoppen heeft wel bepaalde voorbeelden. Vooral qua synchroon houden tussen data in db en op disk (als je alles in je db zet, kan je met 1 query alle info van een item wissen). Dat is toch iets lastiger als je data in db en op disk hebt staan. Niet onoverkomenlijk, maar wel iets meer moeite. Vooral als er dingen misgaan (wissen lukt niet, door permissies, b.v.). Ook heeft het voordelen met backuppen van data (alles staat in db, dus alleen die moet je backuppen).
[/advokaat v/d duivel modus ]

[NMe]

Grijze Vos schreef op woensdag 01 december 2004 @ 07:29:
Hij stelt voor om de link naar een file in de DB te zetten, is toch niks mis mee.

Nee hoor, maar het lijkt me een beetje overbodig. Je kan gewoon de primary key als bestandsnaam nemen. Maar dat hangt dus van de eis af. [/late reactie]

Verwijderd schreef op maandag 13 december 2004 @ 18:50:
Hier een beetje ruwe code van een upload script van mijzelf dat de file gewoon 001.JPG noemt

offtopic:
Ik zou als ik jou was mezelf aanleren om je code in te springen. De structuur van je code is praktisch onleesbaar.

[Bergen]

-NMe- schreef op dinsdag 14 december 2004 @ 02:22:
[...]

offtopic:
Ik zou als ik jou was mezelf aanleren om je code in te springen. De structuur van je code is praktisch onleesbaar.

offtopic:
...en zet de code tussen [ php] en [ /php] ipv [ code] en [ /code] zodat je mooie kleurtjes krijgt. Maw: edit je post ff