- Samsung Galaxy A56 - megbízható középszerűség
- Milyen okostelefont vegyek?
- Kicsomagolták a Vivo X Fold 5-öt (videó és fotók)
- Szerkesztett és makrofotók mobillal
- iPhone topik
- Honor 200 Pro - mobilportré
- Huawei Mate X6 - keleti oldal, nyugati oldal
- Android alkalmazások - szoftver kibeszélő topik
- VoLTE/VoWiFi
- Samsung Galaxy A54 - türelemjáték
Új hozzászólás Aktív témák
-
fordfairlane
veterán
Ha nem akarsz annyi mappát létrehozni a fájlrendszerben, mint amennyi usernek akarsz külön urlt, akkor az url értelmezését a webszervertől át kell tenni az alkalmazásodba. A http requesteket át kell irányítani egy fájlba, majd ezen fájlban kell feldolgoznod a kapott url fragmentet, a saját értelmezésednek megfelelően.
-
cucka
addikt
Nem. Egy ilyen url routing szabály úgy néz ki, hogy mondjuk a
/users/{username}
útvonalat átírja úgy, hogy
/users.php?username={username}
Ez persze pszeudokódban van, a routing-ot sokféleképpen lehet intézni. Egy jól megoldott rendszeren jellemzően a php alkalmazás dönti el, hogy egy URI-hoz milyen kontrollert kell meghívni. A webszerver dolga ilyenkor csak annyi, hogy eldönti, ki tudja-e saját maga szolgálni az erőforrást (mondjuk statikus képeknél) vagy sem. Utóbbi esetben a php alkalmazás megoldja saját maga. Ez azért jó így, mert a programod viselkedése a programban lesz leírva, nem pedig egy külső program konfigurációs file-jában.Egyébként olvasgatom az utóbbi hozzászólásokat, ti tényleg ezt a PDO-t használjátok? Olyan ocsmány az egész, szívem szerint bottal sem piszkálnám.
-
Sk8erPeter
nagyúr
Hogy érted azt, hogy "aloldalt"? Ez egy alias, tehát nem fizikailag különálló könyvtár, vagy hasonló... egyszerűen egy leképezés.
Mondjuk van a
http://example.com/users/kisjozsi
ez egy alias erre:
http://example.com/user/231Utóbbira meg van egy .htaccess-szabály, vagy akár másik megoldással ez is egy alias pl. erre:
http://example.com/index.php?user_id=231
Ez csak egy példa a végtelen lehetőség közül.Igen, 10000 felhasználónál ugyanennyi alias lesz. (De nem "aloldal".)
Szerk.: most jövök rá, hogy szerintem félreérted az "alias" szót ebben az esetben. Ennek totál semmi köze a webszerver aliashoz (pl. Apache-ban van Alias kulcsszó). Ez egy URL alias, ami az alkalmazásodhoz kötődik.
Ilyet alkalmaznak a CMS-ek is (pl. Drupal), meg frameworköknél is lehet használni.Szerk. 2.: na várj, akkor most userhez tartozó könyvtárakról beszélünk? Mert akkor meg én is félreértettelek. Attól még, mert a userhez tartoznak könyvtárak, ahova mondjuk gyűjtögeti a fájljait (pl. a profiljához tartozó kép, vagy hasonló, ha nincs ömlesztve), attól még nem kell "aloldal", miért kellene? Egyszerűen a hozzá tartozó könyvtárba pakolod a hozzá tartozó fájlokat, és onnan húzod elő, ha szükséged van rá, azt' kész.
De ahogy már sztanozs is említette, léteznek alternatív megoldások, pl. a fájlokat gyűjtheted dátum szerint rendezve is, ez már kb. tök mindegy, csak tartsd nyilván, hol van. -
Sk8erPeter
nagyúr
"Neked nem mindig könnyen emészthető a stílusod viszont a kritikák egyértelműek és építőek."
Akkor ezt bóknak veszem, kösz!">>sztanozs korábban linkelt neked egy stackoverflow-s topicot, annak az alkalmazásával mi a helyzet? Nem látom a kódodban.<<
Ha erre gondoltál akkor nem értem hogy hogy nem látod mert benne van :
$db->setAttribute( PDO::ATTR_EMULATE_PREPARES, false );"Én erre gondoltam.
-
j0k3r!
őstag
nincs elottem most eles kornyezet, ezert nem tudom tesztelni, de elvileg a $queryString property kell neked: [link]
ugye tobb oldalrol is meg lehet kozeliteni ezt a problemat, egyreszt megnezheted mit kuldtel el a db server fele, erre jo a most leirt megoldas, masreszt megnezheted db server oldalrol, hogy oda mi jut el server oldalrol (ertsd: ahol a php scripted fut), erre meg a kulonbozo sql profilerek valok (sot meg sokkal tobbre is kepesek altalaban).
-
j0k3r!
őstag
"Az összes Objectet visszakapom, rendesen megvan minden attribute , csak épp mindegyik értéke null . Ha a limitet és offsetet kiveszem a kódból és csak egy useren keresem az összes képet akkor működik minden jól."
ebben az esetben valami sql profilerrel ranezhetnel, hogy milyen query jut el az adatbazisserverhez. (faek megoldaskent valahova (view, logfile, akarmi) kiirathatnad az osszerakott queryt, mielott lefuttatod)
-
sztanozs
veterán
$object_array = array();
while ($row = $query->fetch($result_set)) {
$object_array[] = self::instantiate($row);
}
return $object_array;Ez nem az alábbinak kellene legyen?
$object_array = array();
while ($row = $result_set->fetch(PDO::FETCH_OBJ)) {
$object_array[] = $row;
}
return $object_array; -
Lacces
őstag
"Ahány ember, annyi féle" - pont ez a legrosszabb benne
Mikor 5 éves kódba kell beleírnod, semmi Joinolás nincs a query-kben stb. Én menekülök...
Biztos hogy van eredmény a query lefutása után? phpmyadmin (vagy mysql-ben) a query lefutása után van ott visszaadott sor?
csinálj egy die($query) - vagy $sql, amiben van a "SELECT * FROM..." és azt kell megnézni mysql-ben is.
-
Lacces
őstag
Csak nekem fura, új az az query-zés
, én év elején tanultam a php-t és azt láttam neten és új könyvekben is inkább az-az megoldás, amit én írtam. Nem kötekedésből írtam, elnézést ha az volt. Szal nekem csak ezért volt fura, még sosem láttam
. Elnézést kérek ha félreérthető voltam
t|-|om! Nálad a pont, bemutattam egy olyan példát, amit nem szabad elkövetni... a rossz szokás hatalma itt a melóhelyen, átveszem a rossz kódolást, mindig más rendszerébe kell belenyúlni. Tudom nem kifogás, de jó hogy szóltál, mert rám ragad
-
burgatshow
veterán
Ha a :változókat lecseréled kérdőjelre, utána meg a tömbben csak a megfelelő sorrendben felsorolod az értékeket akkor sem jó?
Pl.:
$sql = 'SELECT * FROM photographs WHERE users_id = ? LIMIT ? OFFSET ?';
$query = $db->prepare($sql);
$result_set = $query->execute(array($page, $per_page, $pagination));Mod: vagy ötvözve Lacces megoldásával.
-
Lacces
őstag
Esetleg ez? Nekem nem tetszik az utolsó sorod
A bindparamot javaslom a típusok miatt is. Szerintem jó az ha felvan tüntetve a típus
$id= 150;
$per_page= '120';
$pagination = '10';
$sth = $dbh->prepare('SELECT *
FROM photographs
WHERE users_id =:id LIMIT :per_page OFFSET :pagination);
$sth->bindParam(':id', $id, PDO::PARAM_INT);
$sth->bindParam(':per_page', $per_page, PDO::PARAM_INT);
$sth->bindParam(':pagination', $pagination, PDO::PARAM_INT);
$sth->execute();PDO::PARAM_INT --- Integer típus. Ha meg stringről van szó, akkor meg PDO::PARAM_STR
-
sztanozs
veterán
Reasons to strongly type parameters in PDO? - első válasz...
-
Tele von Zsinór
őstag
Igen, ez így egy elég erős randomot ad, de a crypt felesleges, attól nem lesz nehezebben kitalálható. Kérsz az openssl-től 32 random byte-ot, és ez már elég jó.
Két dologra figyelj oda: egyrészt az openssl nem mindenhol van bekapcsolva, másrészt ha a második paraméterben átadott változóban false-t kapsz vissza, akkor kriptográfiailag nem erős algoritmussal lett generálva a véletlen érték - bár ezzel nem igazán tudsz mit kezdeni, jó tudni. A php.net szerint ez elég ritka.
-
Tele von Zsinór
őstag
Igen, ennyi a lényeg. Usernevet nem kell tárolni, a token pontosan azonosít egy felhasználót. És igen, ha megszerzi a tokened, azzal be tud lépni, ez egy komoly biztonsági kockázata ennek a funkciónak. Javítani lehet a helyzeten, ha egy tokent adott ip-re (vagy ip tartományra) korlátozol.
sztanozs: egyszerű, könnyen érthető példát akartam. Az mt_rand nem erős kripto értelemben. Arra inkább az openssl_random_pseudo_bytes kell neked, de még ez sem az igazi - valójában php-ben kriptográfiailag biztos véletlen érték generálása nem éppen triviális feladat. Érdemes megnézni a CryptLib Random részét, ez számos forrást ismer, és ezeket kombinálva kellemes nagyságú entrópiát tud létrehozni.
-
Tele von Zsinór
őstag
Amikor a felhasználó normálisan bejelentkezik, és így is akar maradni, generálsz neki egy remember me tokent - ez legyen nehezen kitalálható és egyedi (például md5("salt" . time()). Ezt kirakod cookieba és tárolod adatbázisban.
Amikor a user aktív session nélkül érkezik, de van ilyen tokenje, megpróbálod adatbázisbeli felhasználóhoz passzolni - ha sikerül, sessiont feltöltöd a bejelentkezéshez szükséges adatokkal, egyéb esetben törlöd a tokent, hogy időt és sávszélt spórolj.
Jelszócsere esetén a felhasználó token mezőjét nullra állítod.
-
TonTomika
aktív tag
Nem kell egy bonyolult dologra gondolni.
Egy egyszerű űrlap, amit kitöltenek, majd elküldi emailben, de bele kell iktatni egy egyedi rendelési számot.
Lehetnek benne betűk is, csak ezt így most egyszerűbbnek láttam, hogy az időpontból csinálok egy számsort. Sajnos a php tudásom nem olyan nagy, nem kellett még random értékekkel dolgoznom, de hátha találok rá valami tutorialt.
-
Sk8erPeter
nagyúr
Szerintem a 6 számjegy kicsit kevés.
(#10520) Soak : "A VirtualHost-hoz nem nyúltam abszolut."
Most hogy van beállítva?
pl. localhost/phpmyadmin, vagy hogyan használod?
Azt még mindig nem írtad, próbáltad-e már másik verzióval.
Ha nem, tedd meg.
Esetleg rakd fel a php.ini-det is valahova, vagy a my.cnf-et, esetleg az Apache megfelelő konfigfájljait. -
DeltaPower
addikt
-
DeltaPower
addikt
Alapbeállításban egy fájlos, kivéve ha a konfigban az innodb_files_per_table hozzá lett adva telepítés után.
Az előző kérdésem az összes adatbázisra együtt vonatkozott, ami a helyi mysql-ben van. Nálam összesen több mint 5 giga adatbázis van, és még ha nem is valamelyik nagyot, hanem egy pár táblás, majdnem üres kisebb adatbázist használok, az is eléggé lassú tud lenni. Persze ebben benne van a lassú és töredezett vinyó is.
Az egy fájlos tárolás azért lényeges, mert ilyenkor az összes innodb adatbázis egyetlen fájlban tárolódik, ami szerintem teljesítmény szempontjából nem a legjobb megoldás egy bizonyos méret felett. (sajna egy fájlosról több fájlosra áttérni elég nehézkes egy létező adatbázis esetén).Csináltam most egy gyors tesztet, teljesen egyszerű php file, csak simán felkapcsolódok egy tök üres adatbázisra. A szerveren most 21 adatbázis van, össz tárhelyfoglalás 5,98 GB.
A mysql 250-es satás, 7200-as WD vinyón, 220 gigás partíció, 500 mega szabad hely. Az InnoDB ibdata1 fájlja 220(!) fragmentben. (8G ram, x2 250, a rendszer ssd-n van, nem ezen)Ezek az idők jöttek ki:
0.0013120174407959s // saját DB layer include
0.99860501289368s // kapcsolódás saját DB layeren keresztül
0.00019001960754395s // kapcsolat lezárás DB layeren keresztül
1.0029170513153s // kapcsolódás mysql_connect()-el
7.9870223999023E-5s // kapcsolat lezárás1 másodperc körüli idő egy sima kapcsolódásra, üres adatbázishoz.
-
Sk8erPeter
nagyúr
Lehet, hogy korábban már volt szó róla, de már nem tudom követni, szóval milyen szerver?
Milyen szerverbeállításaid vannak?
Ha Apache, akkor az adott VirtualHost beállítása hogyan néz ki?
Újabb verzióval próbáltad már?
Nem tudom, miket kérdezzek még.(#10499) randras : hát jó.
-
DeltaPower
addikt
Ha jól értem ezt, az IF első része arra vonatkozik, ha egy adott feladótól érkező üzeneteket akarsz listázni, a második része pedig a feladók listája.
Három foreach tényleg fölösleges, még ha max 2 fut is le, főleg hogy minddel végigmész az összes üzeneten.
Én ilyesmi megoldást ajánlok:
function list_messages()
{
if( $_GET['i'])
{
$messages = self::find_messages_by_sender_id($_GET['i']);
}
else
{
$messages = self::find_messages_by_users_id($_SESSION['user_id']);
$sender_list=getSenderListWithCount($_SESSION['user_id']);
}
foreach ($messages as $message) { ... }
}
function getSenderListWithCount($cimzett_id)
{
// SELECT COUNT(message_id), ... WHERE cimzett_id={$cimzett_id} GROUP BY sender_id
} -
Sk8erPeter
nagyúr
"Az előző hsz.-edben az volt a problémád"
Ácsi, kicsit rosszul közelíted meg a kérdést. Nekem aztán nem probléma, ha gányolsz, de tanácsot kértél.$_GET: Akkor totál félreértetted, amit mondtam. Annyit javasoltam, hogy a $_GET, $_POST és hasonló tömbökhöz közvetlenül már ne nyúlj az objektumodban, hanem add át paraméterként a tartalmukat a metódusnak, állítsd be a konstruktorban, vagy fogalmam sincs, hogyan oldd meg, de a metóduson belül ne közvetlenül használd már ezeket a tömböket, mert szerintem nem szép. Komolyabb rendszerekben sem nagyon szoktam látni, hogy közvetlenül nyúlkálnak hozzá az osztályon belül. De ahogy érzed.
A foreach egy egyszerű bejáró algoritmus, semmi extra mutatvány nincs a dologban. De ha háromszor használsz foreach-et, akkor háromszor járod be. Ez felesleges.
Ez most a kosaras példánál maradva olyan, mintha lenne egy kosarad, ami tele van kék, fekete, piros golyókkal, és neked az lenne a feladatod, hogy ezeket külön kosarakba gyűjtsd színek szerint; te pedig úgy oldanád meg, hogy először átnéznéd a kosarat, és kiszednéd a pirosakat a saját kosarába, majd ha ezzel végeztél, akkor megint átnéznéd a kosarat, csak a kék golyókra koncentrálva, aztán harmadik alkalommal is átnéznéd, akkor már csak a fekete golyókat keresgélve, miközben ezt megoldhattad volna úgy is, hogy az épp kezed ügyébe kerülő golyót a megfelelő kosárba pakolod, szín szerint.$senders tömböd:
itt már részletesen leírtam, mi a probléma vele. Nem igazán vágom, mit nem értesz belőle, de megpróbálom még egyszer elmagyarázni, kiemelve a lényegi részt:$senders = array();
if(array_key_exists($message->sender_username,$senders))Elmagyarázva szavakkal, a kosaras példával:
$kosár = tök üres
ha a $kosárban van piros színű golyó, akkor csináld ezt:
Vágod? -
Sk8erPeter
nagyúr
"Te hogy oldanád meg?"
Egyetlen ciklussal.
De őszintén szólva már a kérdést sem értem. Egymás alatt, azonos metódusban szerepel háromszor ez:
foreach($messages as $message)
Akkor ebből nyilvánvaló, hogy pontosan ugyanazt csinálják, tehát nem értem, miért nem pakolod egyszerűen egybe azt, amit számomra érthetetlen okból különválasztottál, és vizsgálgatod a feltételeket a cikluson belül.Leegyszerűsítem olyan példára, aminél egyszerűbbet már nem tudnék mondani az adott helyzetre:
foreach($messages as $message){
echo 'ELSŐ blablabla';
}
if($tokmindegy){
foreach($messages as $message){
echo 'MÁSODIK blablabla';
}
}
if($ezismindegy){
foreach($messages as $message){
echo 'HARMADIK blablabla';
}
}ehelyett miért ne lehetne így:
foreach($messages as $message){
echo 'ELSŐ blablabla';
if($tokmindegy){
echo 'MÁSODIK blablabla';
}
if($ezismindegy){
echo 'HARMADIK blablabla';
}
}Capisce?
"Az lett volna az értelme, hogy elösször biztosan le kell futnia, mivel az első vizsgálatnál még nem volt üzenet és fogalmam sincs ki a feladója az első üzenetnek. Ezért az elsőt beleírja és ha tőle jött még 3 akkor azokat már ignorálja és csak a következő legfrissebbet rakja ki, másik usertől."
Miért találna bármit is egy üres tömbben?
Most gondolj már bele, ez olyan, mintha lenne egy tök üres kosárkád, és elkezdenél keresgélni benne izomból egy piros színű labdát, amikor tudod jól, hogy az a kosár tök üres. -
Sk8erPeter
nagyúr
"A 3 foreach azért van, mert legrosszabb esetben 2 fut le, de nem tudtam jobban megoldani, hogy ki tudjam jelezni egy usertől hány üzenet van."
Akkor sem értem a logikát, hogy miért kell különbontani, és három különálló, de teljes mértékben egyező ciklusban megoldani, amit meg szeretnél, ezzel háromszorosára növelve a ciklus futási idejét..."Azért egyenlő egy üres tömbbel, mert különben hibaüzenetet dobál, hogy nincs definiálva..."
Még mindig nem érthető, mit is akarsz üres tömbbel... array_key_exists-szel vizsgálgatsz egy nyilvánvalóan nem létező kulcsot, mivel üres a tömb? Mi értelme? -
Sk8erPeter
nagyúr
Használd ezt a formázót, ha nem sikerül másként...:
http://beta.phpformatter.com/Szétb@szhatja azért is a formázást, mert public functionnel kezded kapásból, és nem adsz nevet az osztálynak. Nyilván most csak kivágtad a megfelelő részt, de akkor ne az ideone.com-ra rakd, hanem a pastebinre, ha előbbire, akkor legalább adj egy nevet az osztálynak, és tedd oda kommentbe a három pontot, ami jelöli, hogy ott amúgy van más is. (Hogy ne legyen itt ezen az oldalon syntax error.)
if(isset($_GET['i']))
Már eleve rossz kezdés szerintem. Itt már szerintem nem kellene $_GET, $_POST és hasonlókhoz nyúlni, hanem a megfelelő helyen be kellene ezeket állítani, legalábbis ez ebben a formában csúnya osztályon belül.
Ezenkívül mi az az "i"? Miért szopatod magad ilyen kulcsokkal? Miért nem használsz beszédesebb neveket, teljes szavakat?
Én kimegyek a fazonomból az ilyenektől, elég utálatos feladat, amikor más kódját kell kotorásznod, és ilyeneket látsz, egyből letépnéd a fejét annak, aki írta ezt a kódot, és még egy nyomorék kommentet sem rakott oda. Ha már agilis szoftverfejlesztés, akkor már a kód legyen beszédes.$messages = self::find_messages_by_sender_id($_GET['i']);
Miért static függvényhívás? Miért kevered a szezont a fazonnal? Egyáltalán minek ide static függvény?
Erről már korábban is volt szó, cucka is említette neked.foreach($messages as $message)
Összesen háromszor??Mi a francnak mész végig rajta külön-külön?!
Ugye tudod, hogy ez így háromszor annyi időbe is kerül (és egyébként totál értelmetlen)?if(strlen($message->body) > 140){$dots = "...";} else {$dots = "";}
Ez is több helyen szerepel, az már eleve gáz, de amúgy is: mi értelme van? Ennyiből kb. semmi.
Ha le kell vágni a törzsből valamennyit, mert adott karaktermennyiséget túllép, akkor azt egy tök különálló truncate() metódusban végezd el, ne ugyanebben a függvényben. A default karakterlimit pedig a függvény egyik paramétere lehet, default értékkel. Vagy tárold pl. osztályváltozóként a limitet, de inkább előbbi.Aztán egyszer a $message_username változót használod, egyszer a $message->sender_username-et. Abszolút semmi értelme. Egyébként sincs értelme itt átadni másik változónak.
$senders = array();
foreach($messages as $message){
if(array_key_exists($message->sender_username,$senders)){
$senders[$message->sender_username]++;
}
else{
$senders[$message->sender_username] = 1;
}
}Ennek magyarázd már el légyszi, mi értelme, mert szerintem kb. semmi.
Miért kotorászol a $senders-ben, amikor egy üres tömbbel tetted előtte egyenlővé?Tovább nem volt kedvem keresgélni a hibákat, ezek csak első blikkre tűntek fel, némi fájdalmat okozva.
Bocs, de ez így iszonyatosan gány. A kritikákon ne sértődj meg, mert Te kérted.
-
Sk8erPeter
nagyúr
foreach($previous as $previous){
foreach($current as $current){
foreach($next as $next){
A lényeget cucka már leírta, de nekem a fentiektől nyílt ki legjobban az agyam.Nem is tudom, ez működik-e így egyáltalán, bár valószínűnek tartom, hogy inkább nem, és felmerül, hogy felül is írja a változót...
De ezek szerint a foreach használatának logikája sem jött át, vagy nem vágom, ilyet miért toltál be a kódodba.Példa jó használatra:
foreach($ezatömböd as $ezazaktuáliskulcs => $ezazaktuálisérték){
}
vagy csak
foreach($ezatömböd as $ezazaktuálisérték){
}
De ne legyen már ugyanaz a neve a tömbnek és az aktuális értéknek...(#10461) Soak : annyira rondán van indentálva a kódod, hogy őszintén szólva nem sok kedvem van a végignézésére.
Mit használsz PHP-fejlesztésre? Csomó IDE-ben van automatikus formázás, pl. NetBeans-ben Alt+Shift+F.
DW: [link].=========
(#10458) cucka :
"Az empty() nyelvi elemet (figyelem, ez nem függvény) érdemes elkerülni"
Szerintem nem kell kerülni, tudni kell, hol indokolt a használata.
Akár debuggolásra is jól jöhet.
És/vagy ha az ember számíthat NULL, 0 vagy false értékekre is valamilyen oknál fogva.
Persze mielőtt mondanád, azzal egyetértek, hogy jobb szigorú szabályokhoz kötni, adott függvények/metódusok mivel térhetnek vissza, de előfordulhat olyan eset, hogy nem vagy biztos benne, milyen jellegű típus várható az empty()-nek megfelelőek közül, és nincs kedved típusonként ellenőrizni.
Persze a konkrét esetben valóban nem indokolt, de általános értelemben szerintem nem feltétlenül igaz, hogy kerülni kell. -
cucka
addikt
Elnézést, ha belepofázok, de jól láthatóan nem értetted meg az OOP lényegét:
- Az osztályod statikus függvényeket tartalmaz, ami azt jelenti, hogy nem csináltál mást, mint egy névteret globális függvényeknek.
- A függvényeid globális változókat változtatnak, ahelyett, hogy rendes (matematikai) függvényként működnének: a függvény kap n darab bemeneti paramétert, ami alaján kiszámolja az eredményt. Ennyit csinál, nem többet. Nem módosítja a paramétereit. Nem nyúl ki a globális névtérbe. Sőt, igyekezni kell mellékhatás-mentesre csinálni (nyilván sokszor elkerülhetetlen).A fentiek miatt elkerülheted a rengeteg global deklarációt.
Továbbá itt van ez a kódrészlet:
$previous = self::find_previous($id, $users_id);
...
foreach($previous as $previous){
global $previous_pic_id;
$previous_pic_id = $previous->id;
}
- Ciklusban deklarálod a globál változót, biztos ami biztos?
- A foreach-ben érdemes kerülni a névütközést.
- A ciklusod annyit csinál, hogy végigmegy a previous tömbön, majd az utolsó elemnek eltárolja az id-ját egy globális változóba. Minek ehhez végigmenni a previous tömbön?
- Ha a previous tömb utolsó elemére van csak szükséged, miért nem azt adja vissza a függvényed?
- Mi van, ha az első képen állsz és nincs previous? Nem kezeled le az esetet, kiírsz egy üres stringet bele a html-be.
- Ugyanez a foreach megismétlődik a $current változónál, ami viszont nyilvánvalóan nem egy tömb, mert egy aktuális elem van. Ott mi szükség rá? (Vagy mégis tömb? A kódból nem derül ki, és ez nagy baj)Még:
- A $_GET['p'] értékét háromszor escape-eled ki, amíg bekerül az adatbázisba. Ha valóban van az értékben egy olyan karakter, amit ki kell escape-elni, akkor a kódod nem fog működni.
- Az empty() nyelvi elemet (figyelem, ez nem függvény) érdemes elkerülni, jól meg tudod sz*patni magad vele.
- Mivel a php-ban nem látod, hogy melyik változó milyen típusú, érdemes beszédesebb neveket adni - például ami tömb, az többes szám, vagy a függvény paramétereknél $id helyett $pic_id - így nem kell nyomozni, ha fél év múlva tovább akarod fejleszteni a kódodat, akkor el is fogod tudni olvasni -
Sk8erPeter
nagyúr
"JS jobb klikk védelmet"
Na ezt inkább ne. Legalábbis ne globálisan (úgy értem, max. csak akkor legyen érvényes, ha ténylegesen a képre kattintasz jobb gombbal). Vagy akkor már valahogy flash-sel jelenítsd meg a képet, az is nehezíti a dolgot (ehhez képest a jobbklikkes tiltás tényleg nem sokat ér). De ez a jobbklikk-tiltás engem legalábbis megőrjít, utálom, hogy egy oldal még a böngészőmnél is okosabb akar lenni, a felhasználók nagy része számára szintén rendkívül frusztráló lehet. Meg a JS-t akkor kapcsolod ki, amikor akarod."Ez lenne a cél végsősoron amit mondasz, csak egy léptethető, értelmes galériában. Olyan linkel ami nem évül el (kivéve nyilván ha törölve lett a fotó)."
Én is erről írtam korábban, hogy a photo_id-s $_GET-paraméter sem évül el... Hacsak nem törölték a képet, ekkor pedig megjeleníted a komplett galériát, és kész. De őszintén szólva még mindig nem világos számomra, ez miért is nem jó neked. Ha oldalakat akarsz megjeleníteni a képekből dátumra szűrve, az megint más. Ettől még én azt mondanám, inkább többféle megjelenítési módra is kellene gondolni: ahol összegyűjtve, galériaszerűen, albumba rendezve akarod megjeleníteni a képet, ahol dátum szerint rendezel (és nem feltétlenül albumba rendezve, hanem mindent megjelenítesz, ami adott időperiódusban készült), ahol user szerint rendezel, aztán tagek szerint, stb., és van egy, ahol csak egy képet jelenítesz meg nagyban, meg thumbnaileket (kisképeket) a nagyobb kép alatt, amire kattintva tovább tudsz menni a többi képre, meg van előző-következő nyíl.Ha az a gond, hogy több query kellene a lekérdezéshez, meg lehet oldani egy query-vel is, biztos van egyszerűbb is, de most hirtelen ez jutott eszembe, egész gyorsan lefut:
SELECT *, 'previous' FROM `photographs`
WHERE fid < 34
LIMIT 2
UNION
(SELECT *, 'current' FROM `photographs`
WHERE fid = 34)
UNION
(SELECT *, 'next' FROM `photographs`
WHERE fid > 34
LIMIT 2)Így összesen 5 kép jelenik meg, a "középső" az aktuális kép. (Persze nem "középső" lesz a 'current', ha az adott id előtt vagy után nincsenek képek.)
Most ezt csak példaként írtam, ahogy hirtelen eszembe jutott, nem feltétlenül ez az optimális megoldás.Egyébként lehet, hogy érdemes lenne keresni egy open source galériamodult PHP-hoz, és azt felhasználni, ahol már a legtöbb ilyen problémát kezelték.
-
Sk8erPeter
nagyúr
Nem értem, a direkt link miért generálna felesleges forgalmat, ezt még nem fejtetted ki. A hotlinkelés generálhat felesleges forgalmat, ezt esetleg lehet szűrni .htaccess-szel.
Meg lehet írni úgy is a query-t, hogy az előző és utána lévő pár képet is behozza.
Viszont a wis által javasolt dátum szerinti rendezés tényleg jó ötlet, egy áthidaló megoldás a problémádra. A query-nél egyszerűen dátum szerint rendezve kéred le a képeket, az adott dátumnál kisebb vagy épp nagyobb sorrendbe rendezve; így az sem gond, ha közben törölték a képet, mert akkor egyszerűen nem fog szerepelni a találatok között, és kész.
A (#10437)-ben írt kérdésed viszont megint nem világos, hogy miért ne lehetne ugyanezt a címsorból linkelni. Egy újabb $_GET paraméterként a dátumot is megadhatod, aminél előbb vagy később feltöltött képeket szeretnél megjeleníteni.(#10437) szerk. utáni rész:
Itt a "direkt link" alatt nem azt értettem korábban, hogy megnyitod a képet külön fülön mondjuk (bár jogos, tulajdonképpen általában erre vonatkozik), hanem arra, hogy közvetlenül a kép id-ja szerint tudod belinkelni, és ezt a felhasználó is el tudja menteni kedvencek közé, elküldheti, stb... Míg ha ilyen nincs, akkor konkrét képre nem tud hivatkozni, csak dátumokra, az meg gáz. Engem legalábbis idegesítene.
Egyébként ha meg szerzői jogokra hivatkozva nem akarod, hogy megjeleníthető legyen külön, akkor már eleve buktad a dolgot, ami az internetre felkerül, az már csak úgy védhető le, ha föléraksz egy vízjelet, vagy legalább nehezíted a dolgát a júzernek. Viszont az nem megoldás, hogy ne tudjon közvetlenül hivatkozni egy képre, ha az mondjuk tetszett neki, és később is meg akarja nézni, az oldalad keretével együtt; mert ahogy most szeretnéd, úgy első ránézésre nem fogja tudni csak azt a képet megnézni.Remélem azért már kezdünk kevésbé elbeszélni egymás mellett.
-
wis
tag
Megnéztem a kepfeltoltes.hu-t, de nem tudom mire gondolsz.
Gondolom a képek linkelése valahogy így néz ki:
http://valami.hu/kep.php?id=65&galeria=4Na most annyi, hogy hozzáadsz egy újabb feltételt:
http://valami.hu/kep.php?id=65&galeria=4&datum=20120712Ezt belerakod egy nem írható szövegmezőbe, vagy akárhova ahonnan az user egyszerűen kimásolhatja.
-
Sk8erPeter
nagyúr
"Na most, ha valaki nézi ezt a nagy képet akkor szeretném ha tudná linkelni is, nem direkt linkként - fehér háttéren a kép-, hanem a konkrét oldalt amin van, mindenestől."
Hát ez azért necces, mert ha bekerülnek újabb képek az adatbázisba, vagy törölsz párat a régiek közül, akkor teljesen megváltozik a sorrend, tehát mondjuk ami addig az 1. oldalon volt, pl. 20 újabb kép után a 2. oldalra tolódik.
Az még esetleg kerülő megoldás lehet, hogy $_GET paraméterként megadod a photo_id-t és még egy egyéb paramétert is, ami jelzi, hogy galériaszerűen akarod megjeleníteni, tehát legyen előtte és utána is kép, vagy csak utána, stb... ekkor adatbázisból ennek megfelelően kérdezed le az eredményeket, hogy mindenképp köztük legyen a megadott photo_id-val jelölt kép is.
Az előző-következő nyilak kezelése meg nem olyan nehéz, de ahogy elnéztem, ez nálad kezelve is van valahogy a $pagination->has_previous_page() és $pagination->has_next_page() metódusokkal.
De egyébként ha az adott képet nagyban meg lehet nézni, tehát az van a "középpontban" akkor most hirtelen nem világos számomra, miért nem jó az, hogy a photo_id szerint direkt linkeled be, és akkor attól még felajánlhatod az előző-következő képeket, és lekezeled azt az esetet is, ha azóta a képet törölték: ha ez a helyzet, akkor pl. megjeleníted a teljes galériát (esetleg jelezheted azt is, hogy azóta az adott képet törölték), vagy hasonló. -
Sk8erPeter
nagyúr
Hát meg kellene különböztetni a kép id-ját és a page-et: a page-dzsel csak megadod, hogy az adatbázisból lekért, korlátozott mennyiségből hanyadik oldalt szeretnéd megjeleníteni.
De elvileg hasonlót csinál a kódod is, tehát csak limitálja a lekért mennyiséget, és megad egy bizonyos offsetet is, ahányadik rekordtól meg akarod mutatni az eredményhalmazt.
Szóval itt még egyáltalán nem jön képbe a képnek a konkrét id-ja...Vegyük azt, hogy pl. van 200 képed. Egy oldalon 20 képet jelenítesz meg, tehát az 1. oldal lekérése így néz ki:
SELECT * FROM photographs LIMIT 0, 20
aztán a 2. oldal megmutatása:
SELECT * FROM photographs LIMIT 20, 20
a 3. oldalé:
SELECT * FROM photographs LIMIT 40, 20
a 4. oldalé:
SELECT * FROM photographs LIMIT 60, 20
és így tovább...(Utóbbi egyébként ekvivalens ezzel:
SELECT * FROM photographs LIMIT 20 OFFSET 60
)A képekhez tartozó linkekbe meg belegenerálhatod a photo_id-t...
Remélem szép lassan közelebb kerülünk a megoldáshoz. Kérdezz, ha valami még nem érthető. -
Sk8erPeter
nagyúr
Pedig "elég magától értetődő mi történik", épp Te írtad.
"csak hogyan linkelen egy olyan id-t amit elvileg adott környezetben nem látok, mivel minden esetben csak 1 képet kapok"
Mi az, hogy "adott környezetben nem látod"?
Normális esetben egy képhez egyetlen id tartozik, tehát egyértelműen azonosítja.
Az offsetnek pedig a címben is megadhatod a kezdetét és végét, vagy ahogy most is csinálod, egyszerűen megadod a page számát, és akkor nyilván nem kell id a címbe.Szerk.: egyébként most látom, hogy itt az id-vel user id-t azonosítasz... nem tudom, milyen rendszert használsz, miért így van megoldva, és ennek mi értelme. Meg van egy ilyen:
if(!isset($_GET['id']) AND !isset($_GET['user']))
{
$id = $_SESSION['user_id'];
}A $_SESSION['user_id'] biztos, hogy be lesz ezelőtt állítva?
Egyébként minél többet nézem, annál kevésbé világos a megvalósítás miértje.
-
Sk8erPeter
nagyúr
A linkbe tedd bele a fotónak mondjuk az id-ját, és aszerint szűrj.
Pl. /photos.php?id=123123Így már lesz $_GET['id']-d.
De felhasználótól érkező adatot soha ne hagyj ellenőrizetlenül!
Mielőtt adatbázis-query-t futtatnál, escape-eld - de inkább jobbat javaslok, használj prepared statementeket!
Ezt muszáj belinkelnem: [link].Szerk.:
echo " <a href=\"photos.php?page={$i}\">{$i}</a> ";
HELYETT pedig lehetne
echo ' <a href="photos.php?page='.$i.'">'.$i.'</a> '; -
trisztan94
őstag
-
cucka
addikt
Félreértettél, nem azért írtam ilyen sokat, hogy leszóljalak, hanem hogy meg is magyarázzam, hogy az általam írt megoldás miért jobb, mit a tied.
Általában akkor szoktam ide írni, amikor úgy érzem, a válaszomból a másik fél tanulhat is valamit. Ha csak simán meg kell oldani/le kell kódolni egy feladatot, azt úgy hívom, hogy munkahely. -
cucka
addikt
Egy ilyen sql-el érdemes elindulni:
select events.* from events where users_id in (select friend_id from relations where users_id={$user_id}) order by dateofcreation ascAz in()-ben található lekérdezés kiszedi a $user_id-hez tartozó barátok azonosítóját (ide php-ban be kell helyettesíteni a $user_id változót. A külső lekérdezés meg egyszerűen listázza az events táblát, leszűrve a megfelelő felhasználói azonosítók szerint. Ha a barát adataira is szükség van, akkor bejoin-olod a users táblát is és kész.
A te php-s megoldásod annyi soron megy végig, amennyi a userek és a relációk számának szorzata, tehát az algoritmusod négyzetes.
Ebben az sql-es megoldásban a belső lekérdezés csak egyszer fut le és az index miatt logn időben végez, a külső lekérdezés pedig végigfut az összes soron, de egy index létrehozásával ezt szintén meg tudja oldani logn időben.
Gondolatkísérlet: tegyük fel, hogy nő az oldalad látogatottsága. Tegyük fel, hogy az eredetihez képest tízszer annyi felhasználó van, ami mondjuk húszszor annyi relációt jelent. Ez esetben:
- az én lekérdezésem nagyjából ugyanannyi idő alatt végez a kereséssel, mint előtte
- a te php-s megoldásod 200-szor () annyi műveletet fog végezni, mint előtte
-
cucka
addikt
Már írták a tárolt eljárást, de szerintem a függvényed által szállított végeredményt egy normálisan összerakott sql lekérdezés is vissza tudná adni. Egy join (főleg, ha még index is van hozzá) összehasonlíthatatlanul gyorsabb és jobb megoldás, mint ha ugyanezt php-ban bohóckodod össze.
-
Peter Kiss
őstag
Most 2 query-t intézel az adatbázis felé, az egyik egy nagy halom felesleges rekordot is visszaad, míg a másik (find_all_friends) jó eséllyel felesleges oszlopokat is lekérdez.
A megoldást egy tárolt eljárás jelentené, ami paraméterben megkapja a $_SESSION['user_id']-t, majd visszaadja csak azt, amit kell. A logikát már leírtad, SQL-ben sem lesz nehéz megfogalmazni, mit is szeretnél. Ha ezt így összehozod, akkor egyetlen felesleges műveletet sem fogsz végezni.
-
zzolika
aktív tag
Ennyit még tudok, hogy a php kódot a szerver hajtja végre, és csak az eredményt adja vissza a kliensnek.
Egy egyszerû kérdést tettem fel, hogy hogyan lehet meghívni egy gomb megnyomására egy PHP függvényt. Bocs hogy nem tudom magamtól, ezért kérdeztem. A topic címe nem az hogy PHP csak profiknak... -
Sk8erPeter
nagyúr
Nem kell túlbonyolítani, de ha már tanítasz, ne hülyeségeket verj a diákod fejébe...
Ezt írtad:
"Ezzel eléred azt, hogy ugymond a te gépeden egy könyvtár ki lesz nevezve servernek"
ez nem igaz, és félre is vezeti, ezért ezt is írhattad volna:
"A WAMP telepítése után lesz egy c:\wamp\www könyvtárad, amibe pakolhatod a http://localhost címen elérhető weboldalad tartalmát, és már tesztelheted is."
Nincs túlbonyolítva. -
Sk8erPeter
nagyúr
Bocs, de muszáj megint pontosítanom, nem kötekedésből, csak hogy ne vezessen félre senkit. Ne vedd rossz néven, én sem szoktam, ha korrigálnak, sőt, ha jó a korrekció, annak örülök is.
"Magyarul, ha te a böngésző elött ülsz és megnézed a forráskódot akkor csak html lesz
benne."
Nem feltétlenül HTML, ha más content type-ra vonatkozó headert küldött ki a szerver, és nem HTML-tartalmat rakott össze."Ezzel eléred azt, hogy ugymond a te gépeden egy könyvtár ki lesz nevezve servernek"
Könyvtár nem lehet kinevezve szervernek.
A WAMP mozaikszóban benne van az Apache is, na az a szerver (webszerver). Az Apache-hoz tartozó különböző hostokhoz pedig különböző gyökérkönyvtárak tartozhatnak, mindez csupán beállítás kérdése. Az alapértelmezett, localhosthoz tartozó gyökérkönyvtárat is könnyen át lehet állítani az Apache megfelelő konfigurációs fájljában. De ugyanezt a gyökérkönyvtárat tetszőleges számú másik (virtual)hosthoz beállíthatod. -
Sk8erPeter
nagyúr
"az action="" azt jelenti, hogy a form hol keresi a függvényt"
Nem, az azt jelenti, hogy megadod, HOVA, melyik feldolgozó fájlba küldöd el a form adatait. Nem keres semmilyen függvényt, és ennek önmagában még a PHP-hoz sincs köze. A megadott metódusoknak a HTTP-protokollhoz van köze, meg a böngészők működési mechanizmusához. Az action attribútumban megadott feldolgozó fájl akár nyugodtan lehetne ASP.NET fájl is."valamint fontos a name is mert a $_POST onnan tudja, hogy most ő van porondon."
A $_POST nem tud semmit. Az csak egy tömb, a kapott adatokkal. A name attribútum valóban kell, mert szerveroldalon csak így kapod meg a bevitt adatokat. -
Soak
veterán
Az éjjel megálmodtam. Elválik majd, hogy mennyira bírja a szerver.
public static function show_all_relevant_event(){
$friends = Relation::find_all_friends($_SESSION['user_id']);
$events = self::find_all();
foreach($events as $event){
$author_id = $event->users_id;
foreach($friends as $friend){
$friend_id = $friend->friend_id;
if($friend_id == $author_id){
$filename = $event->photograph_filename;
$username = $event->users_username;
$datetime = strtotime($event->dateofcreation);
$mysqldate = date("F j, G:i ", $datetime);
echo "itt van a kontent";
}
}
}
}A find_all functio már alaprból csökkenő sorrendbe adja az eventeket.
-
zzolika
aktív tag
Az oldalon van egy input form, sok mezõvel, és van két gomb, amit szeretnék ha megnyomásra két különbözõ PHP eljárást indítana el, de maradna ugyanebben a ablakban.
A gombnyomásra aktualizálja a form néhány mezõjét.
Ezért raktam a PHP eljárást ugyanabban az oldalba, hogy ne nyíljon meg új ablakban.
<form name="form_vegar" method="post" action="">
Tehát az action üres, ugyanitt kéne keresnie a meghívott függvényt is.
Ha üres az action, akkor mit indít el?
<input name="Submit" type="submit" value="Szamol" onClick="szamol()">
Mert így nem megy ha PHP függvény a szamol(), csak ha Javascript.szerk: Kezdem érteni. Tehát a gombra csak egy külsõ fileban megadott xxxx.php-t tudok elindítani, (mivel a php függvény igazából nem is létezik a kliens oldal számára, amíg a szerver ki nem számolta és el nem küldte, csak az eredményt kapja meg a kliens böngészõ) amit a szerver számol ki.
Tehát ezt a fügve'nyt mindenképpen külön file-ba kell tennem, hogy el tudjam indítani. Meg lehet oldani azt, hogy ugyanebben az ablakban maradjak, csak frissüljön a tartalma? -
Soak
veterán
Ezzel a kóddal oldottam meg a foreach között :
$id = $photo->id;
mysql_query("UPDATE photographs SET views = views+1 WHERE id=".$id." ");Mondjuk ez egyelőre minden frissítésnél növel egyet, szóval vissza lehet vele élni, mármint e-péniszt növelésre, de ezt majd később oldom meg
-
Cathfaern
nagyúr
Mi számít kép megnézésének? Ha már a thumbnailt látja, vagy ha konkrétan rákattint egy képre?
Bár a lényegen sokat nem változtat: felteszem magát a képet php-ból iratod ki. Elég ha a kiiratásra írsz egy functiont, ami a kiírás mellett incrementálja az adott képhez tartozó számlálót is. Legalábbis szerintem nem nagyon van értelme ennél jobban túlbonyolítani -
Sk8erPeter
nagyúr
Gondolom ezekre a függvényekre gondolsz: imagepng és társai, mutat is példát, hogyan tudsz PHP segítségével képeket kiíratni a böngészőbe:
<?php
$im = imagecreatefrompng("test.png");
header('Content-Type: image/png');
imagepng($im);
imagedestroy($im);Esetleg megoldás lehet, hogy mindenféle kép megjelenítését átirányítod .htaccess-szel egy PHP-fájlba, amiben elvégzed a nézettség naplózását, megnézed, milyen kiterjesztésű a kép, és aszerint használod a headert, majd használsz imagepng-t, imagejpeg-et vagy a többit.
-
Sk8erPeter
nagyúr
Te tettél fel kérdést felhasználó által megadott fájlnevekről, és én erre reagáltam... Arra mondtam, hogy whitelisteket érdemes alkalmazni.
Egyébként szerintem értelmesebb egy beszédes képnév, mint egy névben lévő id, ami totál semmitmondó, ha ránéz az ember. Azt nem tudom, SEO-szempontból mennyit nyom a latba, de elvileg ennek is lehet szerepe, hogy maga a fájlnév is legyen beszédes. Ettől még olyan id-t generálsz bele PLUSZBAN, amilyet akarsz.
A képeket normális esetben így is-úgy is id szerint tárolod az adatbázisban, amihez - mint említettem - tárolod az egyéb adatait is, ezek közül a fájlnév is csak egy a sok közül, vagyis nem a kép egyértelmű azonosítására szolgál, az "csak" egy fizikai elérhetőség, de jó esetben úgy tárolod, hogy tök mindegy, mikor, mire változtatod a fájlnevet, attól még beazonosítható marad a kép.=======
(#10228) ArchElf : OK.
Én egyébként olykor ciklusoknál is az $i és $j és $k és egyebek helyett beszédesebb indexneveket használok, de persze csak akkor, ha ennek a kódban van az olvashatóságot javító szerepe (sokszor van).
A lokális változónevek tekintetében én egyelőre a kódjaimban az underscore-t használom túlsúlyban, mostanában vettem fel a camelCase-zel kódolás szokását PHP-nél is. -
Sk8erPeter
nagyúr
Itt már leírtam a fájlnevekre vonatkozó dolgot, arra semmit nem reagáltál. (whitelist)
A leírás mezőt meg általában a képtől/bármi egyéb fájltól külön szokták kezelni, nem is minden képformátum támogatja a leírás "beleégetését" (vagy nem tudom, erre gondoltál-e), adatbázisban a file-hoz tartozó id-val rendeled össze a kiegészítő mezőket (maga a fájlnév, leírás, szerző, stb.).
A leírásban lévő karaktereket meg a szokásos módon szűröd (pl. legegyszerűbb példaként htmlentities()-t is használva, stb.), adatbázisban tárolod, és nem fájlban. -
Tele von Zsinór
őstag
Felettem kolléga már írt egyet, de hozzáteszem a magamét: sok formátumban (kiragadott példa: jpeg) van megjegyzés mező, ahová azt írsz, amit akarsz. Akár php kódot is. És akkor képzeld el, ha ezt .php kiterjesztéssel mented a feltöltött fileok (általában nyilvánosan elérhető) mappájába.
Én valami autogenerált értéket szoktam névként használni (például a hozzá kapcsolódó tábla primary key-ét).
-
fordfairlane
veterán
Ha a user bármilyen nevet adhat a feltöltendő filenak akkor az lehet potenciális biztonsági rés?
Lehet, mivel a filekezelő függvények nem szimpla fájlnévként értelmezik a fájlnév paramétert, így pl. komplett elérési utat is lehet megadni. A fájlnévben vezérlőkarakterek is lehetnek, amik szegmentálják a nevet. Ilyen pl. a \ vagy unixon a /.
-
j0k3r!
őstag
ezen meg egy kicsit javitani kellene szerintem. a $logged_in valtozonak az osztalyon belul lenne a helye, raadasul a zarojelezes se stimmel, valamint nem kavarnam ossze a session kezelest es a user autentikaciot egy osztalyon belul.
en egy egyszerubb session kezelo osztalyt ilyen funkciokkal tudnek elkepzelni: start, set, get, unset, destroy (utobbi ketto mehetne egy helyre - pl.: egy default ertekkel rendelkezo parameterrel)
az autentikaciot tartalmazo osztaly meg a "session wrapper" osztaly segitsegevel manipulalna a $_SESSION tombot
mod: ja meg ugye erdemes lenne a camelCase nevkonvenciot kovetni
-
Sk8erPeter
nagyúr
Szerintem senki nem fog tudni itt konkrét határokat húzni neked, a legjobb válasz erre megint az "attól függ".
Attól is függ, hogy elbírsz-e az 50000+ felhasználóddal, hogy milyen szerverek vannak a háttérben, mennyire erőforrás-kímélő a kód, stb.
Ettől függetlenül nyilván nem véletlen, hogy nagyobb projektekhez már azért a PHP-t legfeljebb vegyítve használják (lásd Facebook), a Stack Exchange családhoz tartozó oldalak (Stack Overflow, Super User, stb.) már ASP.NET-ben készülnek, stb.A Symfony meg azért jó, amiért jó általában egy keretrendszer, hogy egységesebbé teszi, szigorúbb szabályok közé szorítja, de egyben elősegíti és gyorsítja a kódolást.
"a php mellett nagy érv, hogy könnyű és gyors eredményt produkál, olcsón"
Ez igaz.
Ezzel együtt ez sajnos sokszor a minőség rovására is megy. (Lásd nagyszámú olcsó, csakis PHP-n nevelkedett, szűkebb látókörű, és/vagy fejlődni nem akaró munkaerő.) -
fordfairlane
veterán
A 'miért'-re a válasz annyi, hogy a különböző PHP installációkon különböző a hibaüzenetek megjelenítéseinek a beállítása. Mostanában egyre sűrűbb az, hogy a PHP minden hibaüzenetet kiír, még a notice-okat is, illetve production installnál nem kiírja, hanem logolja.
Ez sokszor azt eredményezi, hogy a régebbi, "legacy" kódsorok, amik eddig jól működtek, most mindenféle noticeokat produkálnak.
-
fordfairlane
veterán
Beraksz egy isset-et a feltételvizsgálat elé, oszt jónapot.
if(isset($_GET['clear']) and $_GET['clear'] == 'true')
Ha sok bejövőparamétered van, akkor érdemes másfajta megoldást választani ahelyett, hogy isset-tel szemeteled tele az összes feltételvizsgálatot, de egyetlen paraméter esetében elég ennyi.
Új hozzászólás Aktív témák
Hirdetés
- iKing.Hu - Apple iPhone 13 Pro Max - Graphite - Használt, újszerű
- BESZÁMÍTÁS! Gigabyte B650M R7 7700 32GB DDR5 1TB SSD RTX 5070 12GB BE QUIET! Pure Base 500DX 650W
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 16/32/64GB RAM RTX 4060Ti 8GB GAMER PC termékbeszámítással
- Lenovo LEGION Pro 5 / Pro 7, Lenovo Yoga Pro gépek (RTX 4060 / 4070 / 4080 / 4090)
- ÚJ HP EliteBook 840 G8 - 14"FHD IPS - i5-1145G7 - 32GB - 512GB SSD - Win10 - 6 hónap Garancia
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged