ugrás a tartalomhoz

Fancybox + php-s file-listázás + sok kép = browser crash

Creative · 2011. Nov. 20. (V), 15.37
Üdv

Egy olyan problémával kapcsolatban kérnék segítséget, mellyel gondolom, páran már összefutottak. Tehát adva vagyon egy fancybox, meg egy mappa, pár jó minőségű képpel (szám szerint 29).
Egy oldalon függvénnyel behívom rejtett divbe a kért könyvtár tartalmát, s linkre kattintva bejön az adott galéria. Valamiért viszont egyszerűen nem boldogul ennyi képpel, ha ilyen jó minőségűek (s fájlméretűek is). Nincs valami megoldás, függvényoptimalizálási mód, képoptimalizálás generálás közben, vagy bármi, amivel ki lehetne küszöbölni ezt a hibát?

A fancybox behívása s a rejtett div hozzá:
<ul class="ered">
  <li><a href="<?php echo _URL; ?>fancybox/photos/2009/tournament_001.jpg" rel="gallery2009" class="fancy">Képgaléria 1</a></li>
</ul>
<div style="display:none;">
  <?php slideLoad(_DOCROOT . '/' . $forras09, _URL . $forras09); ?>
  <?php slideLoad(_DOCROOT . '/' . $forras10, _URL . $forras10); ?>
</div>
A behívó függvény, ami a galéria tartalmát generálja:
function slideLoad($path, $link) {
  $dir_handle = @opendir($path) or die("Unable");
  while ($file = readdir($dir_handle)) {
    if($file != "." && $file != "..") {
      echo "\t\t\t\t\t\t\t" . '<a rel="gallery2009" href="' . $link . $file . '" class="fancy"><img class="load" src="' . $link . $file . '" alt="" /></a>' . "\n\r";
    }
  }
  closedir($dir_handle);
}
Előre is köszönöm a hozzászólásokat !

C.
‹ PHP - MYSQL - Egyszerű (SESSION alapú) bejelentkező rendszer regisztrációs form karakterek ellenőrzése ›
 ■
1

Mit jelent?

Poetro · 2011. Nov. 20. (V), 15.48
Mit jelent az, hogy jó minőségű, és hogy nem boldogul? Mi a hiba?
2

Fájlméret

Creative · 2011. Nov. 20. (V), 16.18
Azt takarja, hogy legalább 1 megás fájlok, és a böngésző az első 30 kép kezelésétől már összeomlik, akármilyen böngészőben nézem. Ha manuálisan rakom be őket, nincs ez a probléma, de a lényeg pont a dinamikus képlistázáson van.
3

Miniatűrök

Pepita · 2011. Nov. 20. (V), 17.07
Én a képek feltöltésekor készítenék belőlük miniatűröket, értelmetlennek tartom a "hatalmas" képek nagyszámú direkt-kirakását.
Tegyél ki kisebb (mondjuk kb. 600x400 px) képeket, és ráklattyolva egy-egy nagyot (mint régen, csak szebben), vagy slide-show-t, ami szintén 1-esével mutogat.
Nem lehet, hogy a nagy darabszám miatt timelimit-be ér a szkript?
4

A képeket nem töltöm fel

Creative · 2011. Nov. 20. (V), 20.37
A képeket nem töltöm fel dinamikusan, egyszerűen ott csücsülnek egy mappában, vagyis kettőben. Illetve ha megnézed a kódom, nem a kis képre klikk, nagy kép bejön megoldást csinálom, mert linkre kattintva jön csak a galéria, onnantól pedig az egy galériába tartozó képeket lapozással kapja el a fancy. Viszont ha lekicsinyítem a fájl és a dimenzióméreteket is, akkor is a 811 kép betöltésétől megőrül, tehát arra gondoltam, hátha meg lehetne oldani, hogy mondjuk a meglévő függvényt úgy módosítani, hogy az az adott könyvtár tartalmát 6-8 darabszámonként töltené be, egy-egy lekérés között 2-3 mp-et pihenve? Így elvileg nem lenne gond a lefoglalt memóriával a böngészőnek s nem halna meg. Ötlet, tipp, vélemény?

C.
5

Próbáltad?

Pepita · 2011. Nov. 20. (V), 21.35
Viszont ha lekicsinyítem a fájl és a dimenzióméreteket is, akkor is a 811 kép betöltésétől megőrül

Ezt próbáltad is?
Egyébiránt:
- én ezt a "fancy"-t nem ismerem;
- soha meg sem próbáltam 811 képet egy oldalra betölteni, pláne nem ekkorákat - és nagyon nem is javaslom. (Gondolj az egyre terjedő mobileszközökre, amiknek egyes helyeken a sávszélessége alig éri el a 30 kbit/s-t);
- tényleg nem értem, miért ekkora (fájl)méretűek a képek a neten, ha ennek esetleg "letöltheti a Júzer" oka van, akkor is nézegessen kisebbeket, amelyiket meg le akarja tölteni nagyban, azt add neki;
- a kódodból és az iménti adatból (811 db kép, eddig 29-re gondoltunk!) számomra ezek derülnek ki:
1. A while ciklus és benne az if feltétel több, mint 811 x hajtódik végre. Nem tudom, mennyi a szerveren a szkriptek beállított maxi futásideje, de elképzelhetőnek tartom (a rengeteg egyesével hívott echo miatt is), hogy nem fér bele és a szerver letiltja. Bocs, de nem jut eszembe a php-változó neve, ami állítja.
2. A böngésző dolga a maga memóriáját intézni az oprendszerrel, sztem vár az magától, ha kevés. De(!) 811 x min 1 MB az testvérek közt is van 1 giga, kérdem én: van-e a böngésződnek ekkora cache-területe? Ha van, nincs tele?
3. Nekem ennyi jutott hirtelen fejembe, biztos van más is, de leírhatnád: mi a bánatnak kell ennyi és ilyen marhanagy kép egyetlen oldalra? Érdekelne.
3+1. Oldd meg a dolgot másképp, hogy ilyen nagy képből max 1-et kelljen egy oldalon letölteni. Le se töltődik 6-8 db (MB) 2-3 s alatt, vagy akik nézni fogják az oldalt, azok Gbit/s-os nagyságrendű kapcsival rendelkeznek? Számolj ilyenkor utána, átlag Júzer névleges (!) 1 Mbit/s - al 1 sec alatt ugye 128 kB tartalmat tölt le... És ez csak névleges. Én nem emlékszem, hogy csináltam-e olyan oldalt (letöltéstől eltekintve), amelyik css-el, kép(ek)pel, mindennel együtt meghaladta volna az 512 kB-ot.

Remélem, segítettem.
6

Bocs, de nem jut eszembe a

kuka · 2011. Nov. 21. (H), 09.25
Bocs, de nem jut eszembe a php-változó neve, ami állítja.
A max_execution_time php.ini állításra illetve a set_time_limit() függvényre gondolhatsz.

Ami a 811 képet illeti, nekem egy hónapra is sok volna. Akármilyen jók, 10-20 után már kezdem unni.
12

A memória limit sem tárgytalan ekkora kódnál

BoA · 2011. Nov. 22. (K), 19.13
Ekkora kódnál a szerveren beállított php memória is megtelhet szerintem.
Ez ugyan alapjáraton 128 mega, de 811 kép-hez mire mindent végigcsinál...

php.ini => memory_limit = 128M; Maximum amount of memory a script may consume (8MB)

Azonban lényegét tekintve a dolognak én is másképpen csinálnám és mindenképpen használnék php kép átméretezést kis képek létrehozásához!
Ha másképpen nem is, egy külön futtatható php fájlra gondoltam, ami végigmegy a könyvtáron, és előállítja a képek miniatűrjét (értelem szerűen akinek van kicsinyített mása, azt kihagyja).
7

engem is érdekelne a megoldás

razielanarki · 2011. Nov. 21. (H), 14.13
nekem sokkal kevesebbtől is meghal a fancy: ha monjuk 10 db képet linkelek neki egy galériába
<a href="nagykep.png" rel="galerianeve"><img src="kiskep.png"/></a>
-módon,

az 1.8as dualcore-omon, chromeban és ffban is csúnyán szaggatni/lagolni kezdenek az animációk... :(

(a nagyképek pl max. 1275×1650px-es álló a4-es pdf-preview-k lennének)

ha csak 5-öt linkelek neki, még érszevehető a lag, de már nem zavaró.
8

Látom nem egyedüli a példa

Creative · 2011. Nov. 21. (H), 14.56
Akkor ezek szerint lehet, hogy maga a fancybox is jelentősen lassítja az oldalműködést -mondjuk firebug szerint 162ms, a hozzá tartozó css pedig 58ms- , ha ebbe belekombinálom a használni kívánt képeket... ajjaj. No de a képek mennyiségét csökkentettem, a minőségük s fájlméretük is csökkent, viszont ugyanaz. Sokkal tovább jut, de ugyanúgy kifagy még mindig.
Pepita, nagyon szépen köszönöm a válaszod, felnyitotta a szeme igen. Nos 29 az egyik galéria, 781 a másik galéria tartalma. Összeadtam őket, mert eszembe jutott közben, hogy a két függvény közvetlenül egy más alatt fut le s így nem a 29 kép töltődik, hanem a 810... xD Továbbá agyaltam, hogy meglehet oldani, hogy a nagyobbik tömböt N elemenként kissebb tömbökre bontom fel, s úgy iratom ki csak tartalmukat a kezelővel. Itt jönnek rögtön a felmerülő dolgok:
- de meglehet azt oldani, hogy egymás után írja ki a kis tömbök tartalmát oda, ahova kell? - valahogy biztos meg... maximum a kis tömböket bejárom foreach -el a nagy tömbön belül, ehhez maximum módosítom a függvényem
- meg lehet oldani, hogy egy-egy N-tagú tömb lekezelése után várjon kicsit, hogy ne fagyassza ki rögtön a böngészőt? - meglehet, ott a sleep(time_to_be_sleeping_beauty)
- meg lehet oldani, hogy a moratórium közben ne halljon le a többi folyamat? - ebben már nem vagyok biztos...
- page-load eseménynél csak az első kis tömb lekérése fusson le, linkre klikkelve a másodiké is, s onnantól menjen időzítve a többi, pl 20mp -ként? - erre se tudom sajnos a választ
Viszont ha valaki értelmes elgondolásnak látja, ahogy én is járatom az agyam ,az szóljon hozzá :)

C.
9

betöltődéskor semmi gond,

Raziel Anarki · 2011. Nov. 21. (H), 22.31
betöltődéskor semmi gond, csak amikor az egyik <a>-ra klikkelve előjön a doboz, lesz nagyon lassú a dolog.

az a sejtésem h hasonló gondunk van, mert lehet nálad h egyszerűen megeszi a memóriát valamiért, nálam meg csak belassul. mindenesetre fura.
10

Más, újabb verzió?

Poetro · 2011. Nov. 21. (H), 22.36
Nem tudom, a Fancybox milyen verzióját használjátok, érdemes lehet azt frissíteni, és amennyiben ez nem segít, akkor egy másik lightbox utánzatot kereni.
11

Saját

Pepita · 2011. Nov. 22. (K), 16.22
Lehet, hogy az én gondolkodásmódom hibás, de ha már ilyen spec. eset van, hogy egyszerre enyyi sok kép megnézésére kötelezzük Júzert, akkor én inkább egy saját, egyedi "mutogatót" írnék.
13

Lehet, hogy valami elkerülte

prom3theus · 2011. Nov. 23. (Sze), 12.35
Lehet, hogy valami elkerülte a figyelmemet, de felmerült bennem a kérdés: nem lenne célszerűbb nem az összes képet megjeleníteni egy aloldalon? Úgy értem: én talán lapozhatóvá tenném egy oldal szintű pager bevezetésével a galériákat és mondjuk csak 20 képet jelenítenék meg egy adott oldalon.

Ha usability-re is törekszel, talán valahogyan meg lehetne oldani, hogy az adott oldalhoz tartozó utolsó képen ha a felhasználó "tovább"-ot nyom, akkor a galéria oldala lapozódjon és betöltés után a következő kép jelenjen meg.

Így sztem nem omlana össze se a kliens oldal, és egész biztosan a szerver se futna ki az erőforrásaiból/egyéb korlátaiból.
14

A lapozás nem lehetőség,

Creative · 2011. Nov. 24. (Cs), 15.33
A lapozás nem lehetőség, azért csináltam direkt úgy, hogy rejtett divben legyen a galéria, vagyis legyenek a galériák és ... már leírtam fentebb :) ügyeskedtem PS -ben action-írással s elértem, hogy egy-egy kép mérete mindenféle minőségromlás nélkül nem éri el a 100kb -et sem! Ez jó, mert ettől gyorsul az oldal, csökken az összeomlás veszélye, de még kiválogatott képekkel is 190 képről beszélünk! Ugye a lapozás, ahogy már írtam is, nem opció, kezem kötve vala :)
Támadt az ötlet tehát, hogy a galériákat nyitó linkek .click eseményére kezdjen csak el izzani a rendszer. Tehát, .click eseményre ajax kéréssel átadok egy értéket egy feldolgozó php fájlnak, majd ott definiálva, mit kell csinálnia a függvénynek, lefuttatom azt. Ezt utána a küldő oldalon megkapja, már mint tömb (ha szerencsénk van), s ezt az előre rejtett divbe populálja, így már user nyugodtan tud a képgalériában lapozni. Szerintetek? Még most írom csak hozzá a kódot, remélem ez beválik és így megkímélhetem a böngészőket a fagyástól ^^

C.
15

Haladunk ^^ Működik az

Creative · 2011. Nov. 25. (P), 12.25
Haladunk ^^ Működik az ötletem, tehát nem az oldaltöltéskor lassít most már be mindent. Viszont tudom ez már más téma lenne igazából, de inkább ide írom, mivel ehhez kapcsolódik közvetlenül. Ha én .click eseménykor behívok egy js-t, mely feldolgozó php-nak ad át egy azonosító értéket s azzal próbálom a kívánt képeket tartalmazó mappár elkapni, akkor visszatudom vele adatni a tartalmat (értem itt a képfájlokat). De -igen, most jön a DE- ha én így próbálok egy opendir -t futtatni, mindig unable to read -el elszáll (die ágba ezt írtam neki). Az érintett részem jelenleg így mutat:
		if($evjarat == 2009) {
			$forras = 'fancybox/photos/' . $evjarat;
			$return['error']	= false;
			$return['msg']		= '';
			$return['gallery']	= @opendir('../' . $forras) or die("Unable to read : " . '../' . $forras);
		} else {
			$return['error']	= true;
			$return['msg']		= 'A kapott évjárat nem a vártnak megfelelő értékkel rendelkezik!';
			$return['gallery']	= '';
		}
Az évjárat változómat kapja meg jquery data -ként, s ezt rendesen kezeli is. Viszont válaszként ennyit kapok:
{"error":false,"msg":"","gallery":null}
Ez történik akkor is, ha előredefiniált változóként adom meg, illetve ha ott helyben kérem is le. Mit nézhettem így be szerintetek? :(
Struktúra mappákon belül, csak amiket itt használok:

/
includes/
  feldolgozo.php
scripts/
  behivott_script.js
templates/
  fo_tartalmi_oldal_ahol_a_link_talalhato.php
fancybox/
  photos/
    2009/
      ezeket_a_kepeket_kene_innet_kiolvasnia.jpg
C.
16

vedd ki a kukacot az opendir

szabo.b.gabor · 2011. Nov. 25. (P), 14.45
vedd ki a kukacot az opendir elől és lehet, hogy okosabb leszel. mindenestre szerintem te ott scandir-t akartál írni. bár nem biztos...

másik javaslat.

mi lenne ha már az alap oldalletöltéskor tartalmazná a html kód a képek forrásának elérését (akár egy javascript változóba berakod json segítségével), és amikor nyomatod a galériát, akkor innen veszed ki, hogy milyen kép jelenjen meg és hozol létre egy img tag-et, vagy átállítod egy meglévő kép src-át az új képre. ha májer vagy preloadolhatsz is rejtett képben.
17

Igazad volt, a @ a hiba, amit

Creative · 2011. Nov. 27. (V), 16.20
Igazad volt, a @ a hiba, amit én elég sokszor használok amiatt, hogy ne adjon ki ismeretlen változós hibát... Lehet nem a legjobb megoldás, de 95% -ban működik :)
Tehát... a hiba a fancy-töltéssel megoldódott. S most megosztanám veletek,több okból is:
- az információ s vele a tudás mindenkié
- ha másnak is hasonló gondja lenne, ne őrölje az idegeit szintén napokon át
Lássuk tehát:
A fancyt minden esetben valahogy be kell hívnunk, tehát jobb esetben a forráskód végén található egy ehhez hasonló rész, természetesen az oldal igényeihez személyre szabva:
$(document).ready(function() {
	$(".fancybox-thumb").fancybox({
		prevEffect	: 'none',
		nextEffect	: 'none',
		helpers	: {
			title	: {
				type: 'outside'
			},
			overlay	: {
				opacity : 0.8,
				css : {
					'background-color' : '#000'
				}
			},
			thumbs	: {
				width	: 50,
				height	: 50
			}
		}
	});
});
Na ezt szépen jelen esetemben el kell tüntetni, hiszen:
- a galériát egy szöveges linkre kattintva hívom be, s csak egyetlen képet hívok be, a jquery adja utána vissza az egész galériát, miután legenerálja hozzá a kódokat
- maga a behívó kép nem tagja a galériának, ezért nem tudja a fancy erre már alkalmazni magát
Megoldás?
- jquery success ágában tudatom csak a scriptel, hogy itt most a fancynek dolga van.
			success : function(data){
				e.preventDefault();
				var blokk = data.gallery;
				$(blokk).appendTo(".result");
				$("a.fancy").fancybox({
					'padding'			: 0,
					'transitionIn'		: 'elastic',
					'transitionOut'		: 'elastic',
					'titlePosition' 	: 'over',
					'overlayColor'		: '#000',
					'overlayOpacity'	: 0.5,
				});
				$('.result a:first-child').click();
			},
Mint látható, a first-child pesudoval tudatom vele, hogy az a kép lesz, amitől a fancynek galériába kell rendeznie az itemeket. S mivel a php feldolgozó fájlban az első elemet kihagyatom vele, így az első kép statikusan ott marad, fancy viszont már lekezeli, ám a dinamikus galériaelemek közé nem kerül be sose, így nincs az a hiba, hogy visszalapozáskor a galériában az első kép duplikálva lenne ^^
Tehát nincs oldaltöltéskor lassulás, kifagyás.
Nincs galériatöltéskor kifagyás.
Több különböző galéria generálódik dinamikusan, de csak sikeres jquery-futáskor.

Köszönöm a segítségeket, végre sikerült ezt megoldanunk ^^

C.
18

Örülök, hogy sikerült,

Pepita · 2011. Nov. 29. (K), 13.13
de:
, amit én elég sokszor használok amiatt, hogy ne adjon ki ismeretlen változós hibát... Lehet nem a legjobb megoldás, de 95% -ban működik

helyett ajánlanám az isset() függvény használatát.
19

error_reporting

razielanarki · 2011. Nov. 29. (K), 13.42
vagy egy 
error_reporting (error_reporting () & ~E_NOTICE);
hívással kikapcsolni a notice jellegű hibákat.

de az isset() használata egy rövid ?: operátorban sokkal jobb gyakorlat.
20

Extra opció

Creative · 2011. Nov. 29. (K), 17.03
Eszembe jutott közben még egy megoldás, amivel még lejjebb lehet venni a sávszélesség-foglalást és a gyorsítás is elérhető.
Base64 Encoding még generálási időben. Kipróbáltam, működik, de nem alkalmazom a végleges "termékben". Viszont a jövőre való tekintettel biztosan használni fogom még.

C.