Új hozzászólás Aktív témák
-
#5964
Sk8erPeter
nagyúr
Speeedfire
#5963
Sk8erPeter
nagyúr
válasz
Speeedfire
#5963
üzenetére
Az aposztrófot nem escape-elted!
echo '
<a href="'.$file.'" class="w" onmouseover="o(13, \''.$file.'\');" onmouseout="f(13);">
<img src="'.$file.'" alt="'.$file.'"></a>
';Így okés.
Sk8erPeter
-
#6000
Sk8erPeter
nagyúr
Speeedfire
#5991
Sk8erPeter
nagyúr
válasz
Speeedfire
#5991
üzenetére
"Valami olyasmi lenne a cél mint a ph-s képfeltöltő, csak nem ajaxos."
Az sem AJAX-os, hanem iframe-es.Amúgy AJAX-szal nem is lehet fájlt feltölteni, csak ilyen iframe-es trükközéssel, az AJAX-os képfeltöltők nagy része is így (vagy Flash közreműködésével) működik.
[ Szerkesztve ]
Sk8erPeter
-
#6004
Sk8erPeter
nagyúr
Tele von Zsinór
#6002
Sk8erPeter
nagyúr
-
#6011
Sk8erPeter
nagyúr
Tele von Zsinór
#6009
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#6009
üzenetére
"Amúgy én úgy szoktam csinálni, hogy minden projektnek létrehozok egy-egy apache VirtualHost-ot, projektneve.local néven, megfelelő DocumentRoottal, és ezt felveszem a /etc/hosts-ba is. Innentől külön domainen futnak, elkerülve például az ilyen problémákat."
A számból vetted ki a szót
Pont ezt akartam javasolni, még csak a múlt hónapban csináltam meg, azóta már csak így használnám, ezerszer kényelmesebb, mint a korábbi megoldás, amikor a localhostnak megfelelő könyvtárba pakoltam mindent, azonbelül is külön könyvtárakat kellett létrehozni a projekteknek, annál többet bepötyögni a böngésző címsorába, stb., szóval több szempontból is nagyon macerás.
Így meg teljesen egyedi neveket tudok létrehozni, és oda állítom be az elérési útjukat, ahová csak akarom.
Kezdetben próbálkoztam azzal is, hogy különböző portszámokhoz rendeltem a localhoston belül az egyes projekteket, aztán gyorsan rájöttem, hogy az megint macera (pl. nem túl beszédes a neve annak, hogy http://localhost:1234).Sk8erPeter
-
#6013
Sk8erPeter
nagyúr
Speeedfire
#6012
Sk8erPeter
nagyúr
válasz
Speeedfire
#6012
üzenetére
Pont úgy viselkedik, ahogy elvárható lenne, mert nem tetted ciklusba a mysql_fetch_assoc függvényt.
Így lenne helyes:$query = 'SELECT fid, COUNT(fid) AS mennyi FROM `linkek_tartalom`
GROUP BY fid HAVING COUNT(fid) >= 10';
$result = mysql_query($query);
if(mysql_num_rows($result)) { //ha van egyáltalán megjeleníthető eredmény
while( $row = mysql_fetch_assoc($result) ) {
$felhasznalo_tomb[] = $row; //tömbbe gyűjtöd az adatokat - de akár egyből ki is írathatod a megfelelő mezőt
}
// ... (pl. felhasználhatod a tömböt, újabb ciklussal kiíratod [erre a kellően gyors foreach javasolt])
}
else {
echo 'Nincs bejegyzés...';
}[ Szerkesztve ]
Sk8erPeter
-
#6043
Sk8erPeter
nagyúr
Inv1sus
#6041
-
#6103
Sk8erPeter
nagyúr
Dave-11
#6070
Sk8erPeter
nagyúr
válasz
Dave-11
#6070
üzenetére
"Csináld így:
echo "<h3>"."Szöveg"."</h3>";"Minek fűzögeted össze ennyiszer? Lehet így is:
echo '<h3>Szöveg</h3>';"szerintem egyes idézőjelek ' ' helyett használj kettősöket " " ha szöveget akarsz kiírni."
Rossz tanács.
A sima aposztróffal való kiíratás gyorsabb lehet, mivel nem kell megvizsgálnia a "fordítónak", hogy van-e behelyettesítendő változó.
Nem mindegy, hogy írod:<?php
$var = 'akármi';
echo 'Itt a változó: $var'; //Kimenet: Itt a változó: $var
echo 'Itt a változó: '.$var; //Kimenet: Itt a változó: akármi
echo "Itt a változó: $var"; //Kimenet: Itt a változó: akármi
?>Itt van egy kis teszt a Weblaborban, a teszteredmények vagy relevánsak vagy nem, a lényeget leírja: ["Karaktersorozatok sebessége" PHP-ben].
Sk8erPeter
-
#6109
Sk8erPeter
nagyúr
Tele von Zsinór
#6107
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#6107
üzenetére
És erre mi a bizonyíték? Mert amúgy logikusnak tűnik, hogy legyen különbség, mivel gondolom meg kell vizsgálni, tartalmaz-e egyáltalán változónevet.
Amúgy meg már csak a HTML-elemek miatt is érdemes szerintem sima aposztrófot használni, csak egy példával élve nem mindegy, hogy néz ki a következő:
<?php
//aposztróffal:
echo '<img src="/images/misc/valid-xhtml10-blue.png" alt="Valid XHTML 1.0 Strict" height="31" width="88" />';
//idézőjellel:
echo "<img src=\"/images/misc/valid-xhtml10-blue.png\" alt=\"Valid XHTML 1.0 Strict\" height=\"31\" width=\"88\" />";
?>utóbbi elég ocsmány.
Sk8erPeter
-
#6112
Sk8erPeter
nagyúr
Speeedfire
#6111
Sk8erPeter
nagyúr
válasz
Speeedfire
#6111
üzenetére
Azt nem tudom, mekkora lehet a konkrét különbség, ha egyáltalán az általad említett példánál mérhető, de szerintem minél kevesebb kiíratást kell a PHP-ra bízni, és minél több a statikus tartalom, annál gyorsabb lehet. Tehát itt a 2. eset egy ennél azért hosszabb tartalomnál szerintem mérhetően gyorsabb lehet.
Nem szórakoztam még ezeknek a méregetésével, majd egyszer, ha nagyon ráérek... (akkor elmegyek inni
)Sk8erPeter
-
#6120
Sk8erPeter
nagyúr
Frigo
#6114
Sk8erPeter
nagyúr
Thanks, pl. ez is elgondolkodtató:
$a = 'aaaaaaa';
echo 'aaaaaaa'.$a.'aaaaaaa'.$a; // 606 µs
$a = 'aaaaaaa';
echo 'aaaaaaa',$a,'aaaaaaa',$a; // 589 µsTehát vesszővel ennyivel gyorsabb. Mondjuk előbbiről korábban is láttam már írást, de ezen azért meglepődtem:
echo 'aaaaaaa'.'aaaaaaa'.'aaaaaaa'.'aaaaaaa'; // 218 µs
echo 'aaaaaaa','aaaaaaa','aaaaaaa','aaaaaaa'; // 562 µsItt a vesszővel kiíratás meg ennyivel lassabb, mint a konkatenálás, ezt egyelőre nem is értem...
Szerk.:
még egy:
hogy mi van? A foreach ennyivel lassabb, mint a for ciklus (216 µs vs. 64 µs)?!
Korábban pont azt olvastam, hogy a foreach gyorsabb működési elven alapszik, de majd megkeresem az erről szóló írást.[ Szerkesztve ]
Sk8erPeter
-
#6121
Sk8erPeter
nagyúr
Sk8erPeter
#6120
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#6120
üzenetére
Ja jó, most látom, hogy itt épp az a lényeg, hogy pl. egy tömb minden elemének megváltoztatása esetén milyen rossz eredmények tudnak kijönni a foreach ciklusra a forral szemben, lásd Conclusion:
"Conclusion:
Proof in this example shows how functionally murderous the foreach() loop can be."DE ez a modify loop-ra vonatkozott.
Van viszont read loop, ahol gyorsabb a for ciklus."Conclusion:
In all cases I've found that the foreach loop is substantially faster than both the while() and for() loop procedures. One thing to note is that when using an entire loop from the start it's extremely good to use the reset() function in all examples."Érdekes eredmények jönnek ki egyébként minden frissítésnél, pl. több frissítés után már az idézőjel vs. aposztróf kérdés is megfordult.
"Is a there a difference in using double (") and single (') quotes for strings. Call 1'000x
[...]
Conclusion:
In today's versions of PHP it looks like this argument has been satisfied on both sides of the line. Lets all join together in harmony in this one!"[ Szerkesztve ]
Sk8erPeter
-
#6123
Sk8erPeter
nagyúr
Sk8erPeter
#6121
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#6121
üzenetére
Na, már megint rosszat írtam:
"Van viszont read loop, ahol gyorsabb a for ciklus."
helyesen:
"Van viszont read loop, ahol gyorsabb a foreach ciklus."
Sk8erPeter
-
#6133
Sk8erPeter
nagyúr
Inv1sus
#6132
Sk8erPeter
nagyúr
válasz
Inv1sus
#6132
üzenetére
Egyrészt lehet, hogy az újabb XAMPP verzióban (php.ini-ben) a default beállítás az volt, hogy notice jellegű hibákat is dobjon, ha pl. vizsgálgatsz olyan változót, ami nincs is definiálva, és előtte nem végeztél isset() ellenőrzést (tipikusan pl. a $_GET változók lehetnek ilyenek; megjegyzem, ezt a hibajelzést érdemes is bekapcsolni tesztelés idejéig, mert a fejlesztő hibája, ha ezek a hibák megjelennek), másrészt újabb PHP-verzió is lehet, aminél egyes deprecated függvényeket/globális változókat/stb. megszüntettek biztonsági vagy egyéb szempontok miatt. Egyéb ok is lehet, de ezek a valószínűek, ha egyébként sikeres volt a telepítés.
[ Szerkesztve ]
Sk8erPeter
-
#6135
Sk8erPeter
nagyúr
Inv1sus
#6134
Sk8erPeter
nagyúr
válasz
Inv1sus
#6134
üzenetére
Azt nem tudom, mennyivel rontja a teljesítményt, ha egyáltalán észlelhetően rontja, mindenesetre semmiképp sem jó gyakorlat kihagyni a változók meglétének ellenőrzését, ha olyanról van szó, ami esetleg hiányozhat, mint pl. a $_GET értékek.
Ezeket is érdemes lehet inkább átadni egy másik változónak, aminek pl. van egy alapértelmezett értéke, de ha pl. a $_GET be van állítva, és "valid" (a saját feltételeid szerint), akkor az annak megfelelően módosul.
Pl. ha van egy $_GET['page'] változó, amire számítasz, akkor azt ellenőrzöd, pl. így (leegyszerűsített példa):<?php
// ......
try{
$page = 'home';
if( isset( $_GET['page'] ) ){
if( is_valid_page( $_GET['page'] ) ){ //feltételezzük, h megvan az is_valid_page() függvény.
$page = $_GET['page'];
}
else{
throw new Exception('Hibás címet adott meg!');
}
}
// .......
} catch (Exception $e){
// kivétel kezelése... pl.:
echo $e->getMessage();
}
?>Sk8erPeter
-
#6139
Sk8erPeter
nagyúr
j0k3r!
#6138
Sk8erPeter
nagyúr
Van "tmp" nevű könyvtárad a rootban? Ha nincs, akkor atw-n sikertelen a fájlfeltöltés PHP-vel.
http://atw.hu/gyik#gyik5
"Miért nem működik a file feltöltés PHP-vel?A munkamenet fájlokat a PHP minden esetben a gyökérkönyvtárad alatti 'tmp' könyvtárban tárolja, ezért nincs más dolgod, mint létrehozni azt."
Sk8erPeter
-
#6303
Sk8erPeter
nagyúr
zka67
#6302
Sk8erPeter
nagyúr
Szerintem elég gányolós megoldás kiíratni a hozzászólást egy fórum esetén <pre> tagekkel ellátva, és ennek a stílusát megváltoztatni CSS-sel utólag, hogy ne az alapértelmezett betűtípussal jelenjen meg. Tök másra való a <pre>, nem véletlenül más a betűtípusa sem, és nem véletlenül nem ezt szokták használni ilyen esetben - a JS-alapú szövegszerkesztők (lásd TinyMCE) is általában <br /> sortörésre alakítják a szöveget Shift+Enternél, vagy új bekezdést (<p>) hoznak létre sima Enternél. Nyilván jelen esetben az elsődleges cél a(z) (X)HTML-ben való megjelenítés, akkor ennek megfelelően is tároljuk el, és ne utólag gányoljunk a szöveggel. Szerintem.
Sk8erPeter
-
#6316
Sk8erPeter
nagyúr
Tele von Zsinór
#6315
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#6315
üzenetére
"cserébe ne feledd figyelmeztetni az ilyenre a felhasználót egy jól elhelyezett noscript taggal."
Pont ezt alkalmazom az egyik egyelőre csak tesztoldalamon, de időközben az jutott eszembe, hogy akkor esetleg ezt is indexeli a Google, az meg furcsán mutathat a találatoknál, hogy szerepel rajta egy figyelmeztetés arról, hogy be kéne kapcsolni a JavaScriptet, vagy olyan böngészőt használni, ami támogatja azt.
Mi a véleményetek erről?Sk8erPeter
-
#6317
Sk8erPeter
nagyúr
LW
#6311
Sk8erPeter
nagyúr
Előző kommentekhez hozzáfűzve:
ha már JS-függő site, és cikkírások, akkor érdemes megfontolni azt a megoldást is, amit a Gmail és pl. akár a stackoverflow is alkalmaz: levél/hozzászólás/... írása esetén időszakos mentéseket készít az addigi piszkozatról, így nem vész el az irományod. Gmailnél mondjuk meg is marad véglegesen. Felhasználóhöz kötve tehát érdemes lehet piszkozatot is készíteni bizonyos cikkekről, így később is folytatható, valamint nem vész el - legalábbis nem teljesen, ha közben lejár a munkamenet. Természetesen a legjobb megoldás az, amit mostanában Neptunnál is alkalmaznak végre, hogy a munkamenet lejárta előtt figyelmeztet annak lehetséges megújítására - ha 1 percen belül nem kattintasz arra a gombra, ami ezt elintézi neked, akkor kiléptet; na, a kiléptetés előtt lehetne közvetlenül piszkozatként elmenteni a cikket.
Manapság az AJAX-os megoldások szerintem elkerülhetetlenek, nagyságrendekkel felhasználóbarátabbá és akár programozói szempontból is kényelmesebbé tehetik az oldalakat (a programozói szopásoktól most eltekintve).Sk8erPeter
-
#6319
Sk8erPeter
nagyúr
Tele von Zsinór
#6318
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#6318
üzenetére
Ja, az ötleted jó a noscript áthelyezésére, pl. milyen jó lenne erre JavaScript használata.
Igen, én is úgy csinálom, hogy megírom először teljesen JS nélkül működőképesre az oldalt, és csak azután módosítgatom az oldalt úgy, hogy AJAX-szal is működjön. Természetesen pluszmunka, de szerintem a használhatóság miatt megéri. Pl. amikor egy form-ot küldök el, akkor engem felhasználói szemmel nagyon szokott zavarni a teljes oldal-újratöltődés. Minek, amikor csak pár adatot küldök át (ha épp nem fájlfeltöltésről beszélünk, ott felőlem lehet újratöltődés, bár a Flash-es vagy iframe-es megoldás itt is sokkal szebb) - az adatok fogadásáig meg megjelenítek egy forgolódó kis ikont, hogy a felhasználó azért tudjon róla, hogy valami tényleg történik a háttérben.
Tipikus példa lehet akár a stack overflow. Tele van JavaScriptes, AJAX-os megoldásokkal, és épp ezért kényelmes a használata. Ezért mondom azt, hogy manapság az igazán modern honlapok esetén elkerülhetetlen, vagyis inkább szükséges az AJAX használata - pusztán a felhasználói élmények növelése érdekében.Sk8erPeter
-
#6330
Sk8erPeter
nagyúr
Speeedfire
#6327
Sk8erPeter
nagyúr
válasz
Speeedfire
#6327
üzenetére
Ha sok HTML-kód kerül az outputra, nem is árt, ha az aposztrófos megoldást választod.
(Jó fárasztó és csúnya escape-elni a sok idézőjelet az attribútumoknál.)(#6329) Siriusb: állítólag az aposztrófos megoldás a kiértékelés szükségességének hiánya miatt (de jól hangzott) gyorsabb lehet, mások szerint urban legend.
Személy szerint jobban szeretem inkább összefűzögetni, és aposztrófot használni, részben a fenti okok miatt (pl. esetleges sebességkülönbség plusz HTML-kód kiíratása), részben meg amiatt, hogy így szerintem sokkal jobban elkülöníthető a kód, ha böngészgetem a kódot - még ha a fejlesztőkörnyezet ki is emeli az idézőjelben elhelyezett kiértékelendő változót, akkor is sokkal inkább egybefolyik a többi kóddal. Ráadásul tömbindexelésnél vagy egyéb esetben is szintaktikai hiba lehet belőle, az összefűzögetésnél könnyebb elkerülni (számomra).Többiektől kérdezném, ha már erről van szó:
echo-zásnál mennyire használjátok azt a változatot, hogy vesszővel elválasztva íratjátok ki a különböző változókat, sztringeket, és nem konkatenálva?
Eszerint itt is lehet sebességbeli különbség, mégpedig a vesszővel elválasztott módszer javára.
Lehet, hogy értelmesebb, mint az állítólag lassúnak számító sztring-összefűzögetés, és érdemes lenne esetleg erre a módszerre átszokni.[ Szerkesztve ]
Sk8erPeter
-
#6333
Sk8erPeter
nagyúr
rt06
#6332
Sk8erPeter
nagyúr
Ja, most a szintaktikai hibát pont nem a kapcsos zárójeles megoldásra értettem.
Persze, nem feltétlenül pont a kiíratás milyenségén kell lefaragni, de ahol lehet sebességet növelni, ott sosem árt, főleg, ha a kényelmi szempontokat nem rontja (jelentősen).
Pl. lehet, hogy csúnya, de a kódomban sokszor keverem a statikus HTML-megjelenítési formákat a PHP-vel, pusztán sebességbeli megfontolásokból (bár lehet, hogy nem dob sokat, nem mértem), hirtelen példaként (alternatív szintaktikával):
<?php
// .....
foreach($valami as $key => $value) :
?>
<div>blabla sokszor: <?php echo $value;?>
................
</div>
<?php
endforeach;
?>Persze ezt csak akkor, ha nagyon muszáj (pl. nagyon sok kiírandó HTML-kód van), mert különben gány lesz a kód.
Nyilván mindent egybevéve kell a sebességen javítani, ahol lehet, de olykor apróságok is számíthatnak sok kicsi sokra megy alapon.Az, hogy a kiíratást valaki kapcsos zárójellel vagy egyéb módon csinálja, tényleg csak ízlés kérdése.
Sk8erPeter
-
#6356
Sk8erPeter
nagyúr
Speeedfire
#6341
Sk8erPeter
nagyúr
válasz
Speeedfire
#6341
üzenetére
Szerintem speciel az "1985. 08. 27." pont nem egy érvényes dátum, amit megeszik az strtotime függvény.
"1985 08 27" - ez sztem megint nem érvényes dátumformátum, így jogosan dobja a kivételt.
Mellesleg így elsőre nekem úgy tűnik, hogy a könyv az OOP-s részt kezdőknek feleslegesen elbonyolítja, mert így csak nézel, hogy mi a bré van...
Én annak idején C++-ból értettem meg elég jól az OOP-t, elsőre ilyen magic függvényekkel "varázsolni" fura lett volna, tuti nem vágtam volna elsőre, mi a pálya. Így utólag belátom, hogy ezek könnyíthetik a melót, de elsőre érdemes sztem a hagyományos módszerekkel tisztában lenni, hogy értsd, de ez mondjuk csak egyéni vélemény. Ezért fura a könyv felépítése.Sk8erPeter
-
#6357
Sk8erPeter
nagyúr
jeges
#6342
Sk8erPeter
nagyúr
"szerintem próbáld külön a köszöntésig egy ciklusba (megjegyzem, logikailag nekem egyébként is az tűnik egy teljes ciklusnak)"
Hol van itt ciklus?
try {
$obj->szuletesidatum = '1985. 08. 27.';
}
catch (Exception $e) {
echo 'Caught exception: ', $e->getMessage(), "\n";
} if (!isset($e)) {$obj->koszontes();}???
a köszöntésnek épp a dátum után kéne lennie...
if (!isset($e)) {$obj->koszontes();}
Ennek meg a végén bocsi, de totál semmi értelme.
Így pont a try-catch szép logikus blokkját bontod meg.
Amennyiben kivételt dobunk, akkor úgysincs köszöntés, tehát egy tök felesleges feltételvizsgálatot tettél a végére.Meg még ezt írtad:
try {
$obj->szuletesidatum = 'piros';
$obj->koszontes();
}
catch (Exception $e) {
echo 'Caught exception: ', $e->getMessage(), "\n";
} if (!isset($e)) {$obj->koszontes();}
Főleg úgy nincs értelme, hogy amennyiben nem lenne kivétel attól, hogy beállítod "piros"-ra a változót, kétszer futna le a köszöntés.Sk8erPeter
-
#6359
Sk8erPeter
nagyúr
Tele von Zsinór
#6358
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#6358
üzenetére
Ja tényleg, az meg a másik. Tehát magyarul ha lenne is kivételdobálás, akkor is le akarna futni az $obj->koszontes(); függvény, mert teljesülne, hogy nem létezik az $e változó.
Sk8erPeter
-
#6367
Sk8erPeter
nagyúr
jeges
#6362
Sk8erPeter
nagyúr
Ciklussal kapcsolatban: programozási kérdésekben az ilyen jellegű alapfogalmak elég ritkán sokértelműek, jelen esetben is egyértelmű a jelentése, és programozásnál meg főleg nem mindegy, hogy egy adott szót a tényleges jelentése alapján használsz, vagy csak saját definíciót találtál-e ki rá, képzeld el, mi lenne pl. csapatmunkánál, ha mindenki más és más értelemben használná a fogalmakat.
A Wikipédiás meghatározás a ciklusra:
Ciklus (programozás)
"A ciklus, vagy iteráció a számítógép-programozás és az algoritmusok egyik alapvető eszköze, amely az ismétlődő (azonos vagy hasonló) tevékenységek megvalósítására szolgál. A ciklus beépítését a programba ciklusszervezésnek is nevezik. A ciklust az egyes programozási nyelvek különböző kulcsszavakkal valósítják meg, de a működési módjukat tekintve három alaptípusba sorolhatók aszerint, hogy hányszor futnak le: ezek az elöltesztelő, a hátultesztelő és a számlálós ciklus."Ne vedd kötekedésnek, nem azért mondtam, hanem csak hogy tisztázzuk.
"különösebb galibát egyébként az első esetben nem okoz"
Hát ha nincs kivétel, akkor valóban nem probléma, de ellenkező esetben elég para."az, hogy a try/catch-ben vizsgált jelenség utáni lépést a szerkezetbe vagy utána teszed, környezetfüggő."
Hát nekem most a try-catch blokkokkal kapcsolatban nem jut eszembe olyan környezet, ahol a logikának teljesen ellentmondó megoldást kéne alkalmazni.
De mondj ilyet, ha van rá ötleted.
A try-catch esetén még az osztály példányosítását is a legtöbb esetben belepakolják a blokkba, mivel még a konstruktornál is történhet kivétel, ha valamiért nem sikerül a példányt létrehozni, ennek a kivételét is kezelni kell.
Az említett példában a köszöntéssel kapcsolatos függvény pont szervesen hozzátartozik a korábbiakhoz, tehát nagyon nem logikus, ha épp a try-catch blokk után teszed annak a függvénynek a meghívását, aminek a lefutása épp attól függ, hogy volt-e kivétel vagy sem.
"a példa szempontjából majdnem mindegy."
Többek közt a fent említett indokok miatt nagyon nem.
Sk8erPeter
-
#6387
Sk8erPeter
nagyúr
shaggy
#6385
Sk8erPeter
nagyúr
akkor ne a rövidet használd, tehát ne a <? nyitótagformát, hanem a <?php változatot.
Rendesen le is van zárva a kód ?> jellel?
Milyen címen próbálod elérni? Fizikailag hol van a fájl?
NE használd a PHP4-et, inkább visszafelé ne haladj az időben, maradj csak a PHP5-nél.
Egyébként ahogy a többiek is mondták, lehet, hogy inkább le kéne szedned az eddigi feltelepített Apache-ot és PHP-t, aztán felrakni sokkal egyszerűbben egyszerre, jól bekonfigolva az összes csomagot, mégpedig a WAMP vagy AppServ segítségével.
Ezek pár kattintással felmennek, viszont faszán telepít mindent, és nem kell vele szívni. Tégy vele egy próbát.Sk8erPeter
-
#6395
Sk8erPeter
nagyúr
Speeedfire
#6394
Sk8erPeter
nagyúr
válasz
Speeedfire
#6394
üzenetére
"van-e az adott néven ilyen függvény, ha van akkor meghívja ha nincs akkor elkészíti"
Nem készít el semmilyen függvényt.
Függvényt legfeljebb meghív. [call_user_func()]"Nem lenne célszerűbb már a __get() résznél megvizsgálni a dolgokat? dátum, név stb? Mert így feleslegesen dolgozik utána még a __set() is."
Másra való a kettő! A getter függvényekkel lekérdezel bizonyos attribútumokat, változóértékeket, a setter függvényekkel pedig beállítod azok értékét.Ha be akarnám állítani vagy épp le akarnám kérdezni a "pityipalko" változó értékét, akkor arra nyilván kivételt dobna, mert nincs ilyen (ha beállítottad volna a konstruktorban, akkor lenne ilyen! példa:
$this->_tulajdonsagok['pityipalko'] = null;).
De a $_tulajdonsagok tömbben létezik 'nev' és 'szuletesidatum' index is, így azokhoz tartozik egy érték, azok beállíthatók, lekérdezhetők.Amikor ezt írod:
$obj->szuletesidatum = '1985-08-27';
Akkor tulajdonképpen a "mágikus" __set függvény hívódik meg, a __set $tulajdonsagnev paramétere megkapja a 'szuletesidatum' sztringet, az $ertek pedig az '1985-08-27' értéket.Ezután az array_key_exists() függvénnyel megvizsgáljuk, hogy a $_tulajdonsagok tömbben beállítottunk-e egyáltalán 'szuletesidatum' index-szel bármit (ami a konstruktorban egyébként null értéket kapott [lásd $this->_tulajdonsagok['szuletesidatum'] = null;], de ezzel már létrejött ezen az indexen egy érték), ha nem, kivétel, ha igen, megyünk tovább.
Ezután megvizsgálja, létezik-e az osztály adott példányában ($this) $tulajdonsagnev . 'Beallitas' nevű függvény - tehát esetünkben szuletesidatumBeallitas nevű függvény (mivel konkatenálja a $tulajdonsagnev változó értékét a 'Beallitas' sztringgel, majd megvizsgálja, van-e ilyen metódus ( method_exists() függvény).
Ha létezik ilyen metódus, akkor meghívja azt, különben pedig csak simán beállítja a $tulajdonsagnev nevű indexen található értéket a $_tulajdonsagok tömbből.Remélem valamennyire érthetően mondtam el.
[ Szerkesztve ]
Sk8erPeter
-
#6397
Sk8erPeter
nagyúr
Sk8erPeter
#6395
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#6395
üzenetére
Korrigálnám magam annyiból, hogy tulajdonképpen valamilyen szinten mégiscsak "létrehoz" dinamikusan függvényeket a PHP, a lényeg:
http://php.net/manual/en/language.oop5.overloading.php
"Overloading in PHP provides means to dynamically "create" properties and methods. These dynamic entities are processed via magic methods one can establish in a class for various action types.The overloading methods are invoked when interacting with properties or methods that have not been declared or are not visible in the current scope. The rest of this section will use the terms "inaccessible properties" and "inaccessible methods" to refer to this combination of declaration and visibility.
All overloading methods must be defined as public."
Mellesleg most látom, hogy tulajdonképpen Tele von Zsinór már korábban leírta tömörebben a lényeget.
Na sebaj, elmondtam másféleképpen.---
(#6396) j0k3r!: pont a fentebb linkelt oldalon mutatják be a __call használatát!
Sk8erPeter
-
#6482
Sk8erPeter
nagyúr
abteam2008
#6481
Sk8erPeter
nagyúr
válasz
abteam2008
#6481
üzenetére
Tehát azt várod, hogy az adatbázisod és a konkrét kódod ismerete nélkül lekódolja neked bárki is, amit szeretnél? Nem fog menni. Tartok tőle, hogy senki sem fogja ilyen munkára szánni a szabadidejét amúgy sem, de így konkrétumok nélkül meg aztán garantált, hogy senki nem fog foglalkozni a dologgal.
Olvasgass ezzel kapcsolatos tutorialokat - pl. adatbázisból való kiolvasás módjai, majd az adatbázisbeli elemek lekérdezése PHP-n keresztül, stb., kódolj, juss el valameddig, aztán ha elakadtál, mutass kódot, akkor segítünk kijavítani. Vagy ha már munkát ajánlasz, akkor azt tálald úgy.------
(#6480) Scobbyka:
hát ennyi alapján úgy tűnik, mintha az új szerverre nem lett volna megfelelően telepítve az eAccelerator.
Egyébként konkrét használat során van tényleges haszna ennek az eAcceleratornek? Én egyáltalán nem ismerem, nem hallottam még a hatékonyságáról.[ Szerkesztve ]
Sk8erPeter
-
#6488
Sk8erPeter
nagyúr
Speeedfire
#6487
Sk8erPeter
nagyúr
válasz
Speeedfire
#6487
üzenetére
És mire hivatkozva akarnak lebeszélni róla? Én mint teljesen pártatlan kérdezem, még nem próbáltam.
================================
(#6483) abteam2008 : legközelebb használd a "Programkód" gombot a bemásolt kódod kijelölése után, mert így nagyon nehéz áttekinteni, én legalábbis ha ilyen kódot látok, többnyire meg sem próbálom megérteni, mert annyira zavaró, hogy mindenféle formázás, indentálás nélkül van csak bemásolva. Szerintem ezzel itt a legtöbben így vannak.
Sk8erPeter
-
#6491
Sk8erPeter
nagyúr
Sk8erPeter
nagyúr
Hali!
Apache mod_rewrite-ot használok egy .htaccess fájlon keresztül, és egy viszonylag komplex RewriteRule-t használok - sok a vagy feltétel, plusz az, hogy ha az egyik feltétel megvan, akkor mi szerepelhet még a következő alakban; ha a reguláris kifejezésnek megfelelt a felhasználó által beírt cím, akkor átadom query stringként (tehát viszonylag kötötten) az index.php mögé a megfelelő kifejezéseket (pl. ........ index.php?page=$1&lang=$4&dog_id=$7 [QSA]), egyébként pedig dobok egy 404-et. Utóbbit is úgy, hogy beletettem egy
ErrorDocument 404 /index.php?page=404
sort.
Jó esetben viszont ezt:
.../eng/home
átalakítja ilyen formára:
.../index.php?lang=eng&page=homeKérdéseim:
1.) Ez a fenti ilyenformán jól működik, mégis felmerült bennem, hogy tulajdonképpen melyik a gyorsabb, az, ha Apache-csal vagy PHP-vel dolgozom fel a címet?
Tudtommal egy ilyen szintű reguláris kifejezés már eléggé lassíthat, ezért gondolkoztam rajta, hogy talán lehetne gyorsítani rajta. De az is lehet, hogy sebesség szempontjából még így is ez a leggyorsabb megoldás, nem tudom, mert nem mértem.
Nektek mi a tapasztalatotok, hogyan használjátok, mit javasoltok?2.) Tulajdonképpen ez a szerkezet így eléggé megköti a fejlesztő kezét, mert az értékek átadásának sorrendje határozza meg, melyik változóhoz lesznek rendelve a címek.
Mégis tudtommal legtöbb helyen a "felhasználóbarát URL-ek" miatt ezt a módszert alkalmazzák.
Ti hogy látjátok a kérdést? Másképp használjátok, vagy muszáj elfogadni, hogy ez egy viszonylag kötött szerkezet, jól kell kitalálni az elején, és nem érdemes változtatni rajta később? Mi van pl., ha a júzer már úgy könyvjelzőzte az oldalunkat, hogy http://blabla.hu/eng/home, mégis mi kitaláljuk közben, hogy valójában jobban tetszik az a sorrend, hogy http://blabla.hu/home/eng, tök mindegy milyen okból.3.) Több RewriteRule-t hogyan adtok hozzá úgy, hogy helyesen működjön?
Pl. ha nem illik az egyik reguláris kifejezésre a cím, ugorjon a következő feltételre, és vizsgálja meg, arra illik-e.
Egyébként így széjjelszedve a feltételeket gyorsabb lehet a dolog?Előre is köszönöm a konstruktív javaslatokat!
Sk8erPeter
-
#6506
Sk8erPeter
nagyúr
Speeedfire
#6496
Sk8erPeter
nagyúr
válasz
Speeedfire
#6496
üzenetére
Miért nem használod fel a $_GET['phpoldal'] változót?
Úgy értem, akkor minek adod át ennek a query stringnek a címet?http://localhost/!!!szapar.hu/
Ehelyett meg létrehozhatnál egy bejegyzést a hosts fájlban, meg apache-beállításokban egy VirtualHost-ot, és lehetne a címe http://szapar.local Így azé' szebb, meg nem kell annyit pötyögni a cím beírásához. $valogatas = "select * from szapar_alias where eng = '".$uri."' ";
Itt azért az $uri változót nem ártana escape-elni, az SQL Injection elkerülése érdekében!$i= 0;
foreach ($valogat as $ertek) {
if ($i != 0) {
parse_str($ertek);
}
$i++;
}
Ezt nem is értem, minek csinálod, ha utána egyáltalán sehol nem használod fel az $ertek változót?
Vagy felhasználod, csak valami include-olt fájlban? Vagy csak benne maradt?if (!mysql_query($valogatas,$con)) {
die('Hiba: ' . mysql_error());
}
Itt a die() helyett érdemesebb lenne inkább valami felhasználóbarátabb hibaüzenetet, hogy nem elérhető az adatbázis, látogasson vissza később. Ráadásul a felhasználónak semmi köze a konkrét hibaüzenethez. Nem célszerű kiírni! Főleg, hogy nem is túl szép.
Az ilyen jellegű hibákat amúgy nagyon faszán le lehet kezelni kivételkezeléssel, ha valami kritikus jellegű hibád van, azonnal dobsz egy kivételt, hogy ne is futkorásszon tovább a kód, nem is kell bonyolult és ronda if-else blokkokat csinálni, egyszerűen valahol elkapod a kivételt, megfelelő módon kezeled, és kész.Saját kivételtípusokat is definiálhatsz, ha származtatsz az Exception osztályból, azt is érdemes, hogy el tudd dobálni, és tudd, hogy egész pontosan milyen kivételt kell kezelned, így akár végtelen mennyiségű kivételt is elkaphatsz.
Példa:class Kiskutya extends Exception {
//nem is feltétlenül kell, hogy bármi más legyen benne
}
/// ... valahol a kódban
try{
// ...
$hiba = true;
if($hiba){
throw new Kiskutya('elég nagy gáz van, kiskutyákat dobálok! :D');
}
///...
$legyen_meg_kivetel = true;
if($legyen_meg_kivetel){
throw new Exception('ha az előbb nem dobáltam volna kivételt, akkor még idáig is eljutna, de ezt a kivételt is elkapnám a catch-ben! Bruhahahahh.');
}
} catch (Kiskutya $e) {
echo 'Kiskutya kivétel elkapva! Konkrét hibaüzenet: '.$e->getMessage();
} catch (Exception $e) { // fontos a sorrend! Az ősosztály (Exception) később legyen, mint a származtatott!
echo 'Általános jellegű hiba: '. $e->getMessage();
}if (!empty($valogat['url']) and isset($valogat['url']))
Ennek a feltételvizsgálatnak így nem sok értelme van, itt elég lenne a !empty() részt vizsgálni, nyilván ha nem üres a változó (nem is NULL, nem is üres string, stb.), akkor be van állítva, tehát a második feltétel már felesleges. Sőt, itt előbb célszerű lenne inkább megvizsgálni, hogy van-e kapott eredményhalmaz, vagy sem, ha már úgyis lekérdezed a kapott sorok számát a mysql_num_rows() függvénnyel.Na, a többi részéhez most nem volt türelmem.
(#6494) Speeedfire:
"Amelyik táblában az url-ek vannak cachelve van."
Hogyan bírod rá így külön az adatbázist, hogy cache-elje? Tudtommal default cache-eli, indexeléssel lehet esetleg segíteni a lekérdezés gyorsaságát.Sk8erPeter
-
#6507
Sk8erPeter
nagyúr
cucka
#6504
Sk8erPeter
nagyúr
Jé, ezt az fpassthru() függvényt még soha nem használtam, ez miben más, mint a többi, kép kiíratására használható módszer?
(Pl. akár a readfile() - meg most hirtelen az imagepng() jut eszembe, de az mondjuk nyilván azért nem jó, mert képtípusfüggő az eredménye (pl. beadok neki egy jpg-t, akkor false-t ad vissza, az nem túl jó.)[ Szerkesztve ]
Sk8erPeter
-
#6508
Sk8erPeter
nagyúr
cucka
#6501
Sk8erPeter
nagyúr
Köszi a választ.
Igen, épp a bottleneck-eket szeretném megragadni, és felmerült bennem, hogy esetleg az Apache-csal ilyen módon való regexpes szarakodás esetleg lassíthatja az oldalbetöltést, mert tárhelyen szándékosan elhelyeztem egy időméregetőt, először az elején hívom meg a fv.-t, majd a kiíratások legvégén megint, és az eredményét kiírom, és van, hogy többet várok, mint a kiírt eredmény (a script maga jó), ami mondjuk következhet abból is, hogy valamiért lassan reagál a szerver a kérésre, vagy f#ngom sincs.Amúgy itt az időméregető:
<?php//Oldal generálási idejének számolásához ( http://weblabor.hu/cikkek/idezojelek )
function getmicrotime() {
list($usec, $sec) = explode(" ", microtime());
return ((float) $usec + (float) $sec);
}
$time_start = getmicrotime();
/// blablabla, vizsgálgatás, kiíratás, stb.
// oldal legvégén:
$time_end = round( getmicrotime() - $time_start , 5 ) ;
echo '<small>|| Oldalgenerálás: '.$time_end.' s ||</small>';
///... HTML-kód befejezése (pl. </body></html>)"A RewriteRule-ok alapból így működnek. Fentről lefele halad a .htaccess fileban egészen addig, amíg talál egy megfelelő sort, ami alapján átírja az url-t"
Sejtettem, csak még sajnos a gyakorlatban nem volt időm megtapasztalni, hogy is van ez, addig azért kérdeztem, hátha van valakinek erről már tapasztalata korábbról, mert egyelőre azt sem tudom, hogy olyan feltétel esetén, ami stimmel, megáll-e egyáltalán a vizsgálat. (Szerk.: valszeg erre való az [L] flag használata. Itt egész jó lista van a flagekről: [link]. Meg egy igen alapos leírás a mod_rewrite-ról, aminek mondjuk tisztában vagyok az alapjaival, csak ezt a többes feltételt nem próbálgattam.)
Mindjárt megpróbálok utánanézni.[ Szerkesztve ]
Sk8erPeter
-
#6510
Sk8erPeter
nagyúr
Tele von Zsinór
#6509
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#6509
üzenetére
Valóban, ez teljesen igaz! És bocsi, nem voltam túl pontos és egyértelmű, azt akartam mondani, hogy sokszor JÓVAL többet várok, tehát mintha a szerver túl sokat szarakodna az általad említett dolgokkal, aminek része az Apache-szerver felőli dolgok elintézése, így pl. a .htaccess fájl vizsgálata is, és ezért merült fel bennem, hogy esetleg a reguláris kifejezés vizsgálgatásával is elszöszmötöl egy darabig.
De rájöttem, hogy ez hülyeség, mert annyira azért nem komplikált a reguláris kifejezésem, hogy pont ez lenne a probléma. Igazából ingyenes tárhelyről van szó, előfordulnak olykor problémák, amikor lassú a szerver, valószínűleg ez lehet ritkán a baj. Amúgy meg van, hogy rohadt gyorsan lefut az egész. Úgyhogy bocsi, tárgytalan!
Nem tudom, miért pont erre feküdtem rá...
Amúgy milyen jó lenne, ha már a .htaccess fájlból is el lehetne indítani egy időmérést.
---
Holnap megpróbálom a többszörös kondícióvizsgálgatást .htaccess-ben mod_rewrite-hoz, ma már nem volt időm rá.[ Szerkesztve ]
Sk8erPeter
-
#6513
Sk8erPeter
nagyúr
Brown ügynök
#6511
Sk8erPeter
nagyúr
válasz
Brown ügynök
#6511
üzenetére
.htaccess fájlba mehet:
<IfModule mod_rewrite.c>
# Először is kapcsoljuk be a RewriteEngine-t
RewriteEngine on
# Kiindulási hely
RewriteBase /
# NEM fájl és NEM könyvtár
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
# illeszkedik a "/komment/show" és "/komment/show/" query stringre is (a perjel a különbség)
RewriteRule ^(/komment/show(/)?)$ /komment/index.php [L,QSA]
# előbbinél a QSA flag egyelőre felesleges, de hátha később szeretnél átadni query stringeket, amiket később feldolgozol PHP-ben
# az NC flag egyébként arra lenne jó, hogy case-insensitive módon fogadja el a címet, tehát mindegy, hogy /KoMmENt/ShOW vagy épp a helyes /komment/show címet írod be, ezt döntsd el, hogyan szeretnéd
</IfModule>Viszont ez a rész tök felesleges, ha már Apache-ból intézed el a dolgokat:
$uri = $_SERVER['REQUEST_URI'];
if ($uri == '/komment/') {
index();
}
elseif ($uri == '/komment/index.php') {
funkcio() );
}
...Tulajdonképpen itt nem vágom igazán, mit szeretnél, ha már mod_rewrite-ot használsz.
[ Szerkesztve ]
Sk8erPeter
-
#6514
Sk8erPeter
nagyúr
Sk8erPeter
#6510
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#6510
üzenetére
"Amúgy milyen jó lenne, ha már a .htaccess fájlból is el lehetne indítani egy időmérést."
Igazából nem is tűnik olyan nagyon hülye gondolatnak (hogy saját magamnak reagáljak).Találtam egy ilyen cikket: [Measuring Apache request processing time]
Ez alapján plusz az Apache vonatkozó hivatalos oldala alapján (mod_headers):
ha ezt a két Header direktívát beteszem a .htaccess fájlba:# %t: The time the request was received in Universal Coordinated Time since the epoch (Jan. 1, 1970) measured in microseconds. The value is preceded by t=.
# %D: The time from when the request was received to the time the headers are sent on the wire. This is a measure of the duration of the request. The value is preceded by D=.
Header set Ekkor_kapta_a_kerest_ms_1970_jan_1-hez_kepest: %t
Header set Keres_feldolgozasi_ideje_us: %D
akkor hozzáadja a HTTP-fejlécekhez ezeket is (szándékosan adtam most ilyen jó hosszú, de beszédes neveket).
Ebben az esetben a következő fejléceket látom a Firebug Net fülén:
Ekkor_kapta_a_kerest_ms_1... t=1301593430575379
Keres_feldolgozasi_ideje_... D=539031Tehát eszerint 539031 us = 0.539031 s ideig tartott az Apache-nak, hogy kiszolgálja a kérést.
A t=1301593430575379 azt jelenti, hogy ennyi mikroszekundum telt el 1970. jan. 1-je óta.Ezek a fejlécek feldolgozhatók PHP-ból is (most itt a tömbben a fent megadott, jó hosszú nevű index-szel érhető el a kívánt érték, mindenki nevezze át ízlése szerint):
<?php
$headers_array = get_headers('http://'.$_SERVER['SERVER_NAME'], 1);
// headerek kiíratása:
echo 'HEADERS:------------<hr />';
echo '<pre>';
print_r($headers_array);
echo '</pre>';
$request_rec_time = $headers_array['Ekkor_kapta_a_kerest_ms_1970_jan_1-hez_kepest'];
// levágjuk a "t=" részt
$request_rec_time = str_replace( 't=', '', $request_rec_time );
// mikroszekundumban kapjuk meg, azt átalakítjuk másodperccé (s) (1 s = 1 000 000 ms)
$request_rec_time /= 1000000;
// átalakítva olvasható dátummá:
echo date('Y.m.d H:i:s', $request_rec_time).'<br />';
?>Igazából az utóbbi, a kérés ideje nem túl pontos, mivel integer értéket kapunk, így megegyezik a $request_rec_time változóval formázott fenti date() kimenete a sima date('Y.m.d H:i:s') kimenetével, aminek a második paramétere az alapértelmezett time() kimenet.
Létezik azonban a $_SERVER['REQUEST_TIME'] változó is, amit szintén felhasználhatunk, ez szerintem kicsit pontosabb, mert talán nem csak a .htaccess fájlhoz érve kezdi számolni az időt...
Így azt is átalakíthatjuk olvasható formátumra:echo date("Y.m.d. H:i:s", $_SERVER['REQUEST_TIME']).'<br />';
De sajnos ez is csak másodperces eltéréseket fog mutatni, nálam legalábbis az "u" (mikroszekundumot jelző) formátum karakter hozzácsapása ( date("Y.m.d. H:i:s.u") ) csakis csupa nullát eredményezett.
Ha valaki tud még jobb, még pontosabb módszereket, ne tartsa magában.
Kösz!Sk8erPeter
-
#6516
Sk8erPeter
nagyúr
Brown ügynök
#6515
Sk8erPeter
nagyúr
válasz
Brown ügynök
#6515
üzenetére
Nem ártana tudni, hogy ezt az "Object not found" hibaüzenetet egész konkrétan melyik kódsorra írja, valamint hogy egyáltalán kipróbáltad-e a javasolt módszert a .htaccess fájl módosításával.
Sk8erPeter
-
#6529
Sk8erPeter
nagyúr
Alukard
#6525
Sk8erPeter
nagyúr
válasz
Alukard
#6525
üzenetére
Csak kíváncsiságból kérdezem:
MINEK használod az ob_start();, ob_end_flush(); függvényeket? Van rá valami különleges okod? Ha nincs, csak szólok, hogy annak felesleges használata sajnos gányolás.
Az esetek igen nagy többségében tényleg nincs rá szükség.
Nyilván ki lehetne találni valami különleges okot a használatára, de az általad mutatott kód, és az "átlagos" webfejlesztés egyáltalán nem teszi indokolttá az igénybe vételét (habár szerintem még az advanced alkalmazásfejlesztés nagy részében is elkerülhető). Főleg, ha az MVC-szemlélet konkrét alkalmazására gondolunk.Sk8erPeter
-
#6531
Sk8erPeter
nagyúr
Alukard
#6530
Sk8erPeter
nagyúr
válasz
Alukard
#6530
üzenetére
sebaj, majd utólag remélhetőleg észreveszed ezeket, és rájössz, milyen viccesek a régi kódjaid...
legalábbis én akárhány régi kódomat látom, mindben azonnal látom a hibát, meg hogy most már mit csinálnék másként.
na, de a dolgon nem változtat, hogy a kódodban tök felesleges az ob_start()...
mondjuk ez is kemény így rögtön egymás után:
$username = stripslashes($username);
$password = stripslashes($password);
$username = mysql_real_escape_string($username);
$password = mysql_real_escape_string($password);
tényleg ez egész gány[ Szerkesztve ]
Sk8erPeter
-
#6533
Sk8erPeter
nagyúr
Alukard
#6532
Sk8erPeter
nagyúr
válasz
Alukard
#6532
üzenetére
Ehelyett a szerintem csúnya megoldás helyett jobb kikapcsolni a magic_quotes_gpc beállítást php.ini-ben (PHP 5.3.0-tól deprecated beállítás):
magic_quotes_gpc Off
esetleg .htaccess fájlból:
php_flag magic_quotes_gpc Off
vagy pedig egy korábban mutatott módszerrel elintézni (fordfairlane írta, én most csak beraktam egy függvénybe):function check_magic_quotes() {
if (get_magic_quotes_gpc()) {
function stripslashes_gpc(&$value) {
$value = stripslashes($value);
}
array_walk_recursive($_GET, 'stripslashes_gpc');
array_walk_recursive($_POST, 'stripslashes_gpc');
array_walk_recursive($_COOKIE, 'stripslashes_gpc');
array_walk_recursive($_REQUEST, 'stripslashes_gpc');
}
}a kódod elején (a függvénydefiníció után) lehetőleg hívd meg a függvényt így:
check_magic_quotes();Egyébként félreértés ne essék, a Te megoldásod (vagyis hát a másolt) is működik, nincs azzal olyan nagy baj, csak szerintem nem túl szép megoldás.
Közben találtam egy egész értelmes magyarázatot: [link]
itt a végén épp a Te kódodban látott részt mondja gyors alternatív megoldásnak, de alapvetően ő is azt javasolja, hogy a fentiek legyenek kikapcsolva. Kábé ugyanazt írta le, mint én (franc, egyszerűbb lett volna egyből linkelni), mondjuk a fenti függvényt nem írta bele, az még igen hasznos lehet.[ Szerkesztve ]
Sk8erPeter
-
#6543
Sk8erPeter
nagyúr
Speeedfire
#6540
Sk8erPeter
nagyúr
válasz
Speeedfire
#6540
üzenetére
"Kellene még egy másik tábla, ahol el lenne tárolva ez mind"
Ezt hogy érted?
Engem is érdekel a gyorsítás, de ezt most nem értem, mire gondolsz.Szerk.: jé, közben pont írtál nekem, mindjárt elolvasom.
[ Szerkesztve ]
Sk8erPeter
-
#6544
Sk8erPeter
nagyúr
Speeedfire
#6542
Sk8erPeter
nagyúr
válasz
Speeedfire
#6542
üzenetére
Én a VirtualHostot így csináltam a httpd.conf fájlban:
NameVirtualHost 127.0.0.1
ServerName localhost
## Próbálgatásokhoz
<VirtualHost 127.0.0.1>
ServerName proba.local
DocumentRoot "d:/Honlap/www/proba"
<Directory "d:/Honlap/www/proba">
Options All
AllowOverride All
Order allow,deny
Allow from all
</Directory>
</VirtualHost>itt ebben a példában a http://proba.local címen elérem a "d:/Honlap/www/proba" elérési úton található könyvtárat, amennyiben beteszek egy ilyen megjegyzést a hosts fájlba (Windows alatt: C:\Windows\System32\drivers\etc\hosts):
#Próbákhoz
127.0.0.1 proba.localÍrd át a neked megfelelő elérési utakra és nevekre, ha gondolod, szerintem érdemes.
"Hogy érted azt, hogy nem célszerű kiírni?"
A felhasználóknak semmi köze az adatbázissal kapcsolatos pontos hibaüzenetekhez, azt inkább csak a fejlesztőnek kell tudnia.
Úgy lenne érdemes, hogy még a kiíratások előtt vizsgálgatod, hogy elérhető-e az adatbázis, meg annak megfelelő lekért sorai, és amennyiben valami gond lenne, akkor egy ennek megfelelő hibaoldalra irányítod át a júzert, vagy átirányítás helyett simán csak a fő tartalomrészbe kiíratsz egy felhasználóbarát hibaüzenetet, mint pl. "Sajnos para van az adatbázissal, gyere vissza később, csá". A hibaüzeneteket meg naplózod és/vagy elküldöd magadnak e-mailben, hogy tudj róla, de a felhasználó lehetőleg ne lássa, mi is történik a háttérben (pl. melyik tábla nem elérhető, miért, stb.). Ez is egyfajta biztonsági rés lehet, de ami lényegesebb szempont, hogy nem túl szép, ha a felhasználó az arcába kap egy warningot, fatal errort vagy hasonlót. Sk8erPeter
Pont ezt akartam javasolni, még csak a múlt hónapban csináltam meg, azóta már csak így használnám, ezerszer kényelmesebb, mint a korábbi megoldás, amikor a localhostnak megfelelő könyvtárba pakoltam mindent, azonbelül is külön könyvtárakat kellett létrehozni a projekteknek, annál többet bepötyögni a böngésző címsorába, stb., szóval több szempontból is nagyon macerás.
)
Nem tudom, miért pont erre feküdtem rá... 
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen