- Steam Deck
- Melyik tápegységet vegyem?
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- TCL LCD és LED TV-k
- Fejhallgató erősítő és DAC topik
- NTFS, exFAT, FAT32 – Melyiket válaszd és miért?
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- Milyen belső merevlemezt vegyek?
- Acer notebook topic
- Milyen videókártyát?
Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
válasz
TomyLeeBoy #15612 üzenetére
Még mindig nem értem, miért lenne "kézenfekvő".
Amúgy nem kötekedésből írom, hanem hogy nehogy valaki fejében rossz infók maradjanak meg véletlenül.
-
Sk8erPeter
nagyúr
válasz
TomyLeeBoy #15610 üzenetére
"A get-et igazából csak azért használtam, mert frissítés nélkül mentődik ez a tartalom, szóval ajaxos és így kézenfekvő volt."
A kettő között még csak minimális összefüggés sincs, AJAX-szal is tudsz mind POST-, mind GET-metódusok segítségével kommunikálni. Attól még, mert AJAX-szal küldöd el az adatokat, esetedben ugyanúgy a POST-metódus használata a kézenfekvő, és nem a GET, mivel nem egy keresőt vagy ahhoz hasonlót készítesz. -
Sk8erPeter
nagyúr
válasz
TomyLeeBoy #15608 üzenetére
A sortöréseket GET-metódussal is lehet továbbítani természetesen (ez platformfüggő, pl. Windows esetén CRLF (vagyis carriage return-line feed): %0D%0A a query stringben), de ilyen formok esetében, ahol pl. már textarea van, tehát valószínűleg nagyobb tartalmakat fogsz továbbítani, nem indokolt a GET-metódus, sőt, ha túl hosszú a tartalom, az URL/query string hosszának limitáltsága miatt problémákat is okozhat, tehát használj POST-metódust. De pl. egy kereső esetén GET-metódus indokolt, így az URL kimásolható, elküldhető, könyvjelzőzhető.
Tehát esetedben érdemes lenne inkább POST-metódust használni (nem mintha ez okozná a problémádat, ez inkább csak javaslat).
A problémádra rátérve: azt írtad, "Ha a textarea-ban van sortörés, mentés és megjelenítés után már nincsen", hogyan mented el? Nem szeded ki a sortöréseket véletlenül? Megnézted már az elmentett tartalmat mondjuk tök egyszerűen phpMyAdminnal vagy valami másik adatbázis-kotorászóban? Debuggoltad már a tartalmat elküldés után?
-
Sk8erPeter
nagyúr
Ne duplikáld már légy szíves a hsz.-eidet mindenhova... Elég lesz egyszer is.
(#15589) daninet :
Akkor valamit félreérthettél, mert Google Docs-szerű megoldást senki sem javasolt. -
Sk8erPeter
nagyúr
válasz
daninet #15587 üzenetére
"Simán mint excelben csinálsz egy táblázatot és irkálsz be függvényeket"
Miért kellene függvényeket beírni akárhova is? Nem lenne túl felhasználóbarát, ha ilyenről lenne szó."Ha pedig nincs akkor Google Doc-ból táblázatot beszúró bővítmény tuti van. "
Hát ez elég egyszerű, de nagyon béna megoldás. Főleg, hogy ez nem túl nagy rugalmasságot jelent az adatok különböző szempontok szerinti megjelenítésében.
Mindenesetre a Weblapkészítés topicban folytatódott a kapcsolódó eszmecsere, ott is megkérdezte. -
Sk8erPeter
nagyúr
válasz
Phvhun #15584 üzenetére
XPath-t használj:
http://www.php.net/manual/en/domxpath.query.php(inspectorban egyébként ugyanúgy jobb klikk, csak Copy CSS helyett Copy XPath)
-
Sk8erPeter
nagyúr
válasz
DNReNTi #15555 üzenetére
Egyetértek, teljesen értelmetlen szarakodni a mail() függvénnyel. Ezt akartam én is beírni, csak aztán visszafogtam magamat, mert ilyenkor jön egy ilyen válasz.
Vagy a PHPMaileren kívül még ott a Swift Mailer. -
Sk8erPeter
nagyúr
válasz
TomyLeeBoy #15546 üzenetére
php.ini:
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
válasz
fordfairlane #15519 üzenetére
Ez mondjuk jogos...
-
Sk8erPeter
nagyúr
válasz
Speeedfire #15507 üzenetére
Sztem arra gondolt, hogy tök más lesz az API (erről infókat nem tudok), és így nem triviális a migrálás. Egyébként az ilyen radikális váltás sokszor gyümölcsöző tud lenni, egy tök más példát kiragadva például a Drupallal az a bajom, hogy rohadtul ragaszkodnak a nagyobb szintű API-kompatibilitáshoz, a könnyebb migrációhoz a különböző major verziók között, hogy nevezzék ugyanúgy, hogy lehessen ugyanúgy meghívni, hogy legyen ugyanúgy procedurális kód, blablabla, és mivel még mindig a PHP4 körül kialakult konvenciók vannak erősen belecuppanva a "rendszerbe", ezért a kód is kicsit kutyulmány-feeling. Mondjuk még mindig ezerszer jobb, mint egy Joomla.
-
Sk8erPeter
nagyúr
válasz
DeltaPower #15493 üzenetére
"Ez mintha egy captcha generátor lenne, azokban szokták ezeket a betűket kihagyni a vizuális hasonlóságuk miatt..."
Jogos, hogy emiatt lehet, ez már valahogy fél 3-kor eszembe se jutott.Amúgy a pwdgen() névből ítélve inkább jelszógeneráló lehet. De lehet, hogy csak a név félrevezető, és neked van igazad, és a CAPTCHA-ban megadandó szöveget is jelszónak hívják náluk.
"A $QUERY_STRING-re nem csoda hogy sikít az interpreter, se paraméterként se global-al behúzva nincs ott a függvényben
"
Az egész függvény tele van undormány megoldásokkal, úgyhogy ez csak egy része a sok parának... -
Sk8erPeter
nagyúr
Azt a qrva, de jó ronda. Hogy sikerült ezt így összehozni? Attól kifejezetten rossz minőségű lesz a kód, ha be van hányva egy sorba egy csomó minden - lásd azt a csodálatos while+regexp-tesztelés+változónak értékadás+sprintf+rand sort... Az ilyen hányadék kódhoz már szinte művészi tehetség kell.
Ha ezt meg így kaptad, hát az szívás, de itt az ideje, hogy átalakítsd valami áttekinthető formátumúra.$i=($QUERY_STRING)?($QUERY_STRING):"10";
helyette
$i=( isset($QUERY_STRING) ? $QUERY_STRING : 10 );
vagy
$i=( !empty($QUERY_STRING) ? $QUERY_STRING : 10);Amúgy minek ide a $QUERY_STRING változóhoz a nagybetű? És ez valami globális változós undormány? Miért nem kapta meg ezt paraméterként a függvény, és lett egy default értéke a paraméternek, ami jelen esetben 10 (amennyiben nem lenne az megadva a fvhíváskor; ja, és nem mindegy, hogy nem "10" stringként, hanem 10 intként)?
A $pwd változót meg deklaráld előre még az első while-ciklus előtt:
$pwd = '';A regexp betűiből szándékosan maradt ki az i és l (mint ló), I (mint Ilona) és O betű, meg a 0-s és 1-es szám, mert valaki azt gondolta, ettől biztonságosabb lesz a dolog?
-
Sk8erPeter
nagyúr
válasz
csabyka666 #15470 üzenetére
Milyen jó lett volna, ha megfogadod a tanácsunkat, és PDO-t használsz exception-kezeléssel.
(#15473) csabyka666 :
Könyörgöm, fejezd már be ezt a mentalitást! Bocs, de minek jössz ide kérdezgetni, ha tákolni akarsz, és ragaszkodsz a saját elképzeléseidhez? Azért nem érdemes használni a mail()-t, mert egyszerűen túl sok a problémalehetőség, formázási problémák vannak vele, olyan gondjaid fognak előfordulni, amit épp a javasolt SwiftMailerben vagy a PHPMailerben már régesrégen megoldottak. Korrekt kimenetet kaphatnál, és fordíthatnád az idődet HASZNOS tevékenységekre, HASZNOS önfejlesztésre, ahelyett, hogy ilyen baromságokkal szopatnád magadat.
Megint én vagyok a beszólogatós köcsög, de vállalom, valakinek meg kell mondania időben, hogy hülyeséget csinálsz.(#15476) Soak :
Notórius önszopató, mondhatjuk neki mi a magunkét, egyszerűen szarik rá, "jó lesz az"-alapon. Mindjárt jön a hosszú kifejtése annak, hogy "de hát én így meg úgy, ti meg úgy meg amúgy", szóval fűrészelhetjük majd vele a fingot keményen megint, ahelyett, hogy valami érdemi dologról lenne szó végre ebben a topicban. -
Sk8erPeter
nagyúr
válasz
csabyka666 #15456 üzenetére
A cookie beállításához miért használsz mysql_real_escape_string()-et?
-
Sk8erPeter
nagyúr
válasz
csabyka666 #15453 üzenetére
Pont azért lenne érdemes időben átállnod a manapság is jól használható eszközökre, mert minél tovább húzod a dolgot, annál nehezebb lesz később átírni a projektet. Csak rá kell érezned, és nem lesz akkora katasztrófa átírni a mostani, kerülendő mysql_*-es megoldást.
Természetesen próbálgasd előbb localhoston, egy tök másik projekten, hogy hogy is működik a dolog, és meg fogod szokni. -
Sk8erPeter
nagyúr
válasz
csabyka666 #15449 üzenetére
Még mindig (addig fogod kapni ezt a választ, amíg nem váltasz a mysql_ kezdetű függvényekről): használj PDO-t prepared statementekkel, és akkor elkerülöd az ilyen szerencsétlenkedéseket.
-
Sk8erPeter
nagyúr
válasz
csabyka666 #15440 üzenetére
"Itt kaptam egy tanácsot a PH-n, hogy írjam oda minden adatbázis-kapcsolódás után, hogy:
mysql_query("SET NAMES SET 'utf8'");
mysql_query("SET CHARACTER SET 'utf8'");
"
Ilyen tanácsot sztem nem adtunk.
A mysql_* kezdetű függvényeket már nem használjuk, deprecated ahogy ezerszer ki lett tárgyalva a topicban.
Ilyesmi inkább elképzelhető:$db = new PDO(
"mysql:host=localhost;dbname=test",
"root",
"root",
array(
PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES UTF8;',
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
)
); -
Sk8erPeter
nagyúr
válasz
DNReNTi #15427 üzenetére
"Nem kezel. Az adatbázis kapcsolat létrehozása előtt ki aztán pedig bekapcsolja az error_reporting-ot, hogy hiba esetén egy szépen megformázott hiba oldalra tudja dobni a felhasználót (header()). Ha nem kapcsolnám ki, akkor maga a php dobna hibát, ami után nem menne a header, ezért van benne. Ez ebből hiányzik, mivel: 1: nincs hibaoldal, 2: teszt."
Te ezt írtad:error_reporting(0);
$DB_Connect = new mysqli(self::$DB_Host, self::$DB_User, self::$DB_Pass, self::$DB_Name);
if ($DB_Connect->connect_error) {
echo 'Database connection failed. Code : ' . $DB_Connect->connect_errno;
}
$DB_Connect->set_charset(self::$DB_Char);
error_reporting(1);Tehát fogod, és 0-ra, majd 1-esre állítod az error_reportingot.
Egyrészt eleve milyen alapon nyúlkál az osztályod az error_reporting értékéhez, minek? Az ilyesmit felejtsd el gyorsan.A kód ne csináljon többet az elvártnál.
Másrészt sztem te az error_reporting()-ot a display_errors értékével kevered.
Harmadrészt miért állítod be az error_reporting szintjét pont az E_ERROR-ra? Az error_reporting(1); ugyanis ekvivalens azzal, ha azt írod, hogy error_reporting(E_ERROR); Mi van, ha korábban az error_reporting értéke szándékosan E_ALL-ra volt állítva, ami 32767? (Itt láthatod az értékeket.)"»»"Ha csak kiírsz egy üzenetet a képernyőre, attól az alkalmazásod még fut tovább"
Az előzőben benne a válasz. Élesben egy hibaoldalra dob."
Hát ez eleve rossz megközelítés. Most akkor itt echo-zol, de aztán majd élesben átírod normális hibakezelésre? Ez így nem lesz jó. Az ilyenből tuti, hogy az lesz, hogy tesztelésnél nem jelentkezik semmilyen hiba, tök jól működnek a dolgaid, aztán majd élesben jöhet a gebasz, és akkor szépen kiírtad a képernyőre a hibaüzenetet, ahelyett, hogy eleve normálisan kezelted volna a hibákat, már amikor megírtad a kódot.
Jótanácsként mondom, ne szopasd magad azzal, hogy "hát ezt majd átírom", mert úgyis elfelejted, vagy pedig később csak macerás lesz megcsinálni.
Szóval az echo-zás helyett dobj szépen egy exceptiont, hiszen komoly hiba, ha nem tudtál csatlakozni az adatbázishoz.A többit asszem mallee már leírta, például hogy tök értelmetlenek az if-else-be rakott exception-dobásaid.
Pont azért jó, hogy tudsz dobálni exceptionöket, mert elkerülheted az ilyen ocsmány if-else szerkezeteket. -
Sk8erPeter
nagyúr
válasz
fordfairlane #15402 üzenetére
Ebben igazad van, de tulajdonképpen ez ilyen Singleton+Factory minta egyvelege.
(#15403) DNReNTi :
"Mért lenne gáz?Adatbázis kapcsolat kezelésére szvsz nem igen van jobb megoldás."
Egyrészt szerintem az ironikus hangvételből kiderült, hogy nem feltétlenül tükrözi a véleményemet a dolog, még ha bőven van is igazsága az azt ellenzőknek, tehát nincs szükség a szemforgatásra (arra amúgy sincs, ha szakmai vitát akarunk nyitni), másrészt meg javaslom, keress rá a topicban (pl. Athlon64+ kolléga itt kardoskodik ellene: [link]), illetve Stack Overflow-n és más forrásokban is, hogy mik is az érvek a Singleton-minta ellen; az "Adatbázis kapcsolat kezelésére szvsz nem igen van jobb megoldás" mondatra meg az a válasz, hogy van, akik meg tudják oldani nélküle, tehát lehet jobb megoldás. Most is előkapható a sablon-érv, hogy "nincs legjobb megoldás". -
Sk8erPeter
nagyúr
válasz
fordfairlane #15398 üzenetére
Vigyázz, mert mindjárt megkapod, hogy a Singleton qrva gáz.
"Majdnem olyan, mint egy Singleton"
Hogy érted azt, hogy majdnem olyan? Jelen formájában ez konkrétan Singleton-minta. -
Sk8erPeter
nagyúr
válasz
csabyka666 #15386 üzenetére
Ja, hogy így! Valóban, az jogos.
(#15387) DNReNTi :
Azért olyan jellegű kérdéseket nem láttam tőled, mint amilyeneket ez a blog kifiguráz.Egyébként meg meglehetősen érdekes felfogás, hogy akkor van _létjogosultsága_ ezeknek a SZAKMAI (!!!4444NÉGYNÉGYNÉGY) topicoknak, ha tele van olyan kérdésekkel, amikről messzire bűzlik, hogy a kérdező még csak meg sem próbált energiát beleölni, utánanézni, tanulni. Mindenki kérdezhet hülyeségeket, ha még csak most kezdte, de azért nem mindegy, hogy az jön le, hogy az illető alapból félhülye, vagy simán lusta, és szarik bele, vagy látszik, hogy valamit erőlködött, de nem jött össze, meg is osztja, mire jutott, és a továbbhaladásban kéri a segítséget. Nyilván az utóbbi a jó/jobb eset.
Érted te ezt. -
Sk8erPeter
nagyúr
válasz
Speeedfire #15373 üzenetére
Őőő, vazze, ne nézz már full kreténnek.
Szóval de, átjött, csak szerintem ez a topic is tele van hasonló vagy durvább hsz.-ekkel, így sajnos már cseppet sem meglepődve olvastam a kifigurázás céljából kiemelt írásokat.
Vannak benne elvétve viccesek, de mondom, ha ebből a topicból szemezgetnénk, akkor is találnánk ütősebbeket.Például "A minap azon agyaltam, hogy miképp lehetne egy js fájlba php kódot illeszteni." sztem annyira nem számít viccesnek, mint amilyennek szánta a blog készítője, mert ezek szerint az író nem ért hozzá, hogy lehet ilyet, a szerver egysoros átkonfigurálásával.
(#15372) csabyka666
Szívesen! De amúgy az általad linkelt oldalon is működik a reguláris kifejezés tesztelése: http://www.rubular.com/r/AJLZHA9Msj
-
Sk8erPeter
nagyúr
válasz
Speeedfire #15368 üzenetére
Ez most micsoda? Hogy lehet ekkora fejlécbe berakni olyan kódot, ami notice-t dob?
-
Sk8erPeter
nagyúr
válasz
csabyka666 #15366 üzenetére
$testString = 'valami blabla';
if(preg_match('/.*? .*?/i', $testString) {
echo 'A stringben van egymás után 2 vagy több szóköz.';
}Tesztelheted:
http://www.functions-online.com/preg_match.html -
Sk8erPeter
nagyúr
válasz
kemkriszt98 #15360 üzenetére
"az eredeti PHP kód eredménye egy ilyen alakú String: username+++password... majd ezt a +++-nál elvágtam.... itt csúszhatott be valami mert amióta picit átírtam az egész kódot és rájöttem hogy a felhasználónévre nincs is szükségem"
Ugye most csak viccelsz, hogy felhasználói jelszavakat kapsz eredményül egy ilyen lekérés során?Bumbum, te...
(#15358) trisztan94 :
(#15359) DNReNTi :
http://stackoverflow.com/questions/2223882/whats-different-between-utf-8-and-utf-8-without-bom -
Sk8erPeter
nagyúr
válasz
kemkriszt98 #15355 üzenetére
"Na, megnéztem a kódolás.... UTF8..."
Pont erről beszéltem itt, hogy NEM MINDEGY, hogy UTF-8 vagy UTF-8 without BOM, még alá is húztam...
Az UTF-8 without BOM karakterkódolást használd. -
Sk8erPeter
nagyúr
válasz
kemkriszt98 #15353 üzenetére
Én sem csináltam még, de lehet róla találni forrást bőven:
http://stackoverflow.com/questions/15732853/how-to-connect-android-app-to-mysql-database
http://stackoverflow.com/questions/19217835/can-an-android-app-connect-directly-to-an-online-mysql-database
stb. -
Sk8erPeter
nagyúr
válasz
DNReNTi #15351 üzenetére
Nincs 3 másodperc, lásd Quick JavaScript Switcher ([link])
Ahogy elnézem, most csak annyi a feladat, hogy az adott URL-en PHP-vel jelenít meg MySQL-adatbázisból egy nagyon egyszerű adatot, és lényegében ennyit kell tudnia annak az oldalnak. Szóval itt nagy biztonsági rések nincsenek, főleg, hogy már PDO-t használ prepared statementekkel, így már az SQL Injection veszélye is elhárult, ettől függetlenül ronda, ha nem kezeli le azt az egyetlen hibalehetőséget, ami két sor lenne.
Az is kérdéses, miért nem inkább az Android-alkalmazásból kapcsolódik közvetlenül a MySQL-adatbázishoz (beállítás kérdése, engedélyezünk-e távoli kapcsolódást), ami ezek szerint localhoston van; inkább a közvetlen hidat teremteném meg a kettő között, nem pedig egy "harmadik szereplőt" vezetnék be, de végül is így is lehet. -
Sk8erPeter
nagyúr
válasz
kemkriszt98 #15349 üzenetére
Sosem lehet magyarázat a hibakezelés, főleg két sor lespórolására, hogy "nem érdemes vele bajlódni".
-
Sk8erPeter
nagyúr
válasz
kemkriszt98 #15347 üzenetére
Na, gyorsan átálltál PDO-ra, ügyes.
Kivételesen nem iróniából mondom, ritka az, amikor javasoljuk egy újonnan érkezőnek, hogy tegye ezt, és még figyel is a tanácsra. Szóval ez mindenképpen pirospont neked.
Ez viszont továbbra is csúf:
$user->execute(array(":username" => $_GET['username'],));
nem jó praktika közvetlenül felhasználni a felhasználótól jövő adatokat, azt előbb validálni kellene, és megfelelő hibával visszatérni, ha például a username query string üres maradt. Pl. egy if(isset($_GET['username'])) ellenőrzés (esetleg empty($_GET['username']), és akkor egyben azt is ellenőrzöd, van-e valami üres értéknek számítótól eltérő értéke) valahol nem ártana, hogy egyáltalán be van-e állítva.
Az Androidos alkalmazásodban a .contains() előtt legalább azt debuggold, hogy egyáltalán mit kapsz válaszul... Szóval mit kapsz a szervertől?
Btw. UTF-8 without BOM a karakterkódolása a PHP-kódot tartalmazó fájloknak? Notepad++-ban könnyen tudod ellenőrizni és konvertálni, ha nem így lenne. -
Sk8erPeter
nagyúr
válasz
kemkriszt98 #15344 üzenetére
Akkor nézd meg még egyszer, nem maradt ki a linkelt tutorial. De ha már, akkor szerepeljen itt még egy link: [link].
-
Sk8erPeter
nagyúr
válasz
kemkriszt98 #15340 üzenetére
A "mysql_fetch_array() expects parameter 1 to be resource, boolean given in ..." hibaüzenet oka:
mysql_query() will also fail and return FALSE if the user does not have permission to access the table(s) referenced by the query.
Szóval a mysql_query FALSE-szal tért vissza.
De mondom, ezt ne is használd. Ott a linkelt tutorial a PDO-ról, amiből képbe kerülhetsz, ami szintén MySQL-adatbázishoz való csatlakozásról szól, melyik része nem tiszta?Amúgy az furcsa, hogy ha a $_GET['id']-t adod meg a username-nek, akkor megy, mert akkor vagy az id tartalmazza a usernevet, vagy pedig a usernév vár azonosító-paramétert, egyik sem normális.
De még egyszer mondom: NE fűzd össze a $_GET és hasonló jellegű paramétereket a query-vel, előtte szűrni kell, különben kapsz egy brokit a seggedbe. Így már elég figyelemfelkeltő, hogy miért ne csináld?Ha ragaszkodsz a mysql_* jellegű függvényekhez (ami továbbra is ellenjavallt), akkor legalább az összefűzögetős hülyeség előtt eressz a változódra egy mysql_real_escape_string()-et.
-
Sk8erPeter
nagyúr
válasz
trisztan94 #15341 üzenetére
Jaja, mindenképp jobb ez úgy, ha szigorúbbak a követelmények, csak nem tudtam, milyen alkalmazásról van szó, de természetesen indokolt, hogy megköveteled az irányítószámot. A júzer meg tanulja meg, hogy ne legyen kretén.
-
Sk8erPeter
nagyúr
válasz
trisztan94 #15338 üzenetére
"rossz az irányítószám -> error"
Ha geocodingról van szó, nem biztos, hogy feltétlenül kell irányítószám (pl. Google Maps-nek is beadhatsz címet irányítószám nélkül, adhat egyértelmű találatot is rá, igaz, van, amikor visszakérdez, hogy "így értette?", és felajánl mondjuk 4 lehetőséget).
Lehet, hogy egyből tesztelni kéne, ad-e vissza eredményt a használt térképszolgáltatás. Ha ez túlzott overhead, akkor persze ez nem pálya, és mondjuk ha mégis fontos az irányítószám, és várhatóan mindig megadnak, akkor ez gyorsabb szűrő, hogy van-e egyáltalán, az tuti.(#15337) kemkriszt98 :
ezt így semmiképp, mert konkatenálod a query-t egy felhasználótól jövő adattal, ezzel kapcsolatban nézz utána az SQL Injection fogalmának.
Használj a mysq_* kezdetű fv.-ek helyett pl. PDO-t: http://maerlyn.eu/2011/12/03/pdo.html
vagy mysqli-t.
Prepared statementeket használj. Paraméterezd a query-t, ne konkatenáld.
A mysql extension már egy ideje deprecated. Jó lenne, ha az ilyen mysql_query()-t és a többit javasoló tutorialok egyszerűen törlődnének a zzegész zzzinternetről. -
Sk8erPeter
nagyúr
válasz
moltam88 #15335 üzenetére
Na ja, én is ilyen esetekre gondoltam, amikor írtam, hogy nem triviális feladat a címre regexpet írni; nem beszélve a felhasználói hibázásokról. Persze az ideális eset, ha már eleve bevitelkor validálásra kerülnek a címek, de egy Excel-fájlnál ez nyilván nem téma.
A legjobb regexp-összepakoló és -értelmező, amivel eddig találkoztam - bár offline -, az a RegexBuddy (http://www.regexbuddy.com/).
Amikor egy komplexebb regexppel találkozol, csak bedobod, és ez lebontja neked szépen. Igen sokat segít, ha nincs kedved gondolkozni, és kinek van kedve gondolkozni, ha nem muszáj? -
Sk8erPeter
nagyúr
válasz
trisztan94 #15328 üzenetére
Nekem az nem tiszta, ezt miért switch-case-zel oldottad meg. Csak gyorsan néztem rá a kódra, de ahogy lejött, annyi a lényeg, hogy végigmész azokon az oszlopokon, amikben van valami, és összefűzöd az egészet. Na de akkor itt nem kell switch-case elméletileg, csak végigmész az első kitöltött oszloptól az utolsóig, a benne levő cellákat meg összefűzöd. Persze az más kérdés, hogy mivel kapod meg, hogy melyik oszloptól meddig van bármi eredményed.
(#15329): hát egy címre rohadt nehéz jó regexpet írni, mert ezerféle lehetőség van, ahogy írhatják. Például az irányítószám után lehet, hogy szerepel pont. Az utcanév után nem biztos, hogy a júzernek eszébe jut odatenni, hogy utcáról/körútról/akármicsodáról van szó. Lehet, hogy az utcát úgy írja, hogy "u." vagy úgy, hogy "utca", körutat úgy, hogy "krt.", "krt", "körút", és így tovább. Lehet, hogy a számozást úgy írja, hogy "7/b.", "7/b" "7b", "7b.", "7 b", "7-b", és még lehetne sorolni... Szóval ez elég necces kérdés.
Most ezt gyorsan bepötyörésztem, rettentő buta megoldás, de illeszkedik arra, hogy
1158 Budapest Késmárk u. 7/b.
-->
\d{4} [A-záéíóöőúüű]+ [A-záéíóöőúüű]+ [A-záéíóöőúüű.]+ [A-záéíóöőúüű0-9./]+Mondom, ez egyáltalán nem biztos, hogy jó, csak a mintádra illeszkedik. Ilyen kb. 20 másodpercnyi pötyögés volt benne, szóval ennél tuti létezik sokkal jobb megoldás is. Ékezet is lehet benne, kezeli azt az esetet, ha a négy számjegyből álló irányítószám után van pont, ilyesmik. Amúgy nem biztos, hogy foolproof megoldás.
Itt le tudod tesztelni gyorsan, ha akarod: http://regexpal.com/-------
SZERK.: hehe, ez jó
most látom, ezt a lapot kb. egy órája töltöttem be, aztán most visszaváltottam a böngészőben erre a fülre a többiről, és úgy írtam a választ, frissítés nélkül, hát vasárnap van, ez van, látom közben haladt a dolog, na mindegy, most már nem törlöm ki.
Amúgy annyi, hogy a regexpben az nem biztos, hogy a legjobb, hogy .* van, mert az BÁRMIRE illeszkedik, nem csak mondjuk a magyar ábécé betűire, és valami megkötést nem árt tenni. Persze nem tudom, nálad milyen adatok lehetnek. Viszont az a whitespace-eknél jobb, hogy \s+ van, nem csak egy darab szóköz, mert így akármennyi whitespace lehet közöttük. -
Sk8erPeter
nagyúr
válasz
Phvhun #15323 üzenetére
Jaja, félreértetted, ráadásul ez messze van a "tuti_jo()"-tól...
Meg egy kissé agyonbonyolított.
Próbáld ki a függvényedet erre:
tuti_jo('Anna, Kati ,, ,Elemér, Józsi, Akárki , Pista')
ebből ezt kapod:
array (
0 => 'Anna ,Kati ,,',
1 => 'Elemér ,Józsi',
2 => 'Akárki,Pista',
)Valszeg ez nem igazán felel meg az elvárásoknak, amit eredetileg szerettél volna kihozni belőle.
-
Sk8erPeter
nagyúr
válasz
fordfairlane #15321 üzenetére
Először én is erre gyanakodtam, de azt írta, explode()-ot használ, és a név UTÁN szerepel szóköz.
Ha azt használja, hogy
explode(',', 'Anna, Árpi, Aladár')
akkor abból az lesz, hogy
array (
0 => 'Anna',
1 => ' Árpi',
2 => ' Aladár',
)
ergo a név ELÉ kerül a szóköz. Ha azt használja, hogy
explode(', ', 'Anna, Árpi, Aladár')
magyarul a delimiter a vessző utáni szóköz, akkor eltűnnek a szóközök a név ELŐL.De igazából ezért írtam neki, hogy mutassa meg a megoldását, és akkor kiderül, mi van.
-
Sk8erPeter
nagyúr
válasz
Dave-11 #15317 üzenetére
Fentebb azt írtad, minek KELLENE benne lennie. De továbbra sem osztottad meg, hogy csinálod a feldolgozást. Mondjuk írogathatunk még pár hsz.-t oda-vissza, de jobb lenne, ha inkább egyből ellátnál minket a szükséges infókkal, hogy tudjunk neked érdemben segíteni, ne csak találgassunk.
Mutasd meg, hogy dolgozod fel azt, hogy "van egy sor, és abban vannak egymástól vesszővel majd egy szóközzel elválasztva". Kóddal, konkrétan, ne csak azt mondd el, hogy KELLENE működnie, hanem hogy csinálod most, és akkor több eséllyel jövünk rá, miért nem úgy működik, ahogy szeretnéd.
Amúgy Trisztán korábban javasolta már a trim() használatát is.Ezt csak most látom:
"A fájlt egyébként UTF-8-as kódolásban mentem, de majd rápróbálok a BOM nélkülire még egyszer."
Milyen racionális érvet tudnál felhozni amellett, hogy nem eleve "UTF-8 without BOM" a karakterkódolása a fájlodnak, és ami miatt tartalmaznia kell szerinted a BOM-karaktert? -
Sk8erPeter
nagyúr
válasz
trisztan94 #15313 üzenetére
"Sokat szptam korábban egy PostgreSQL adatbázis miatt. Miért nem MySQL-t használsz?"
Hajjaj, máris veszélyes vizekre eveztünk, nehogy elkezdd bebizonyítani, hogy a MySQL sokkal jobb, mint a PostgreSQL...
Eleve rossz a kérdés. Nincs jobb-rosszabb reláció a két adatbázis-kezelő között, mást tudnak, más előnyei és hátrányai vannak. Ha épp PostgreSQL használata a feladat, akkor nem jó kérdés, hogy miért nem MySQL-t használ az illető.(#15312) Dave-11 :
Fogalmunk sincs, mi van az $aktualis_nev változóban. -
Sk8erPeter
nagyúr
Nem tudok vitatkozni. Amit viszont egyszerűen nem tudok elhinni, hogy hogy lehet - fórumos hozzászólások alapján - többéves tapasztalat alapján ilyen ostoba szar hibákon elvérezni, hogy nem veszi észre, hogy kliensoldalon rossz elemmel játszadozik. Ha gyorsan meg akarom tudni, hogy jó-e a selectorom, fogom, és bedobom a böngésző fejlesztői panel konzoljába a megfelelő szintaktikával, és egyből megtudom, hogy milyen elemeket kapok vissza... Ami még rosszabb, hogy arra se sikerült rájönni, hogy egyáltalán szerveroldalon vagy kliensoldalon van-e a probléma, ami megint teljesen triviális volt. De biztos majd egy spagettikód megoldja, keressünk hát gyorsan egyet!
Amúgy majdnem írtam, hogy tényleg szar, hogy a topicban nincsenek szakmailag érdekes problémák, de aztán rájöttem, hogy valószínűleg azért, mert aki szakmailag érdekes problémával találkozik, az sanszos, hogy már megtanulta értelmezni a hibaüzeneteket, valami sejtése van a debuggolásról (ami NEM a die() és egyéb bullshitek), meg utánanéz, mielőtt nekiesne, mint tót az anyjának.
(#15294) moltam88 :
Hát bizony, ez valóban nem meglepő. -
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
válasz
trisztan94 #15290 üzenetére
Nincs az oldalra betöltve több olyan form is, amihez a .form-uploadXLS class van hozzárendelve?
Mellesleg az eredeti postodban még id-t használtál, ahol normális esetben tök felesleges a [0] index:
var formData = new FormData($('#form-uploadXLS')[0]);Egyébként ne szívasd magadat:
http://www.plupload.com/
https://github.com/moxiecode/plupload
(ugyanazok fejlesztik, aki a TinyMCE-t is)
HTML5 + fallback. -
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
válasz
trisztan94 #15258 üzenetére
Most akkor már azzal is gondjaid akadtak, hogy hogyan használj fel egy objektumpéldányt?
-
Sk8erPeter
nagyúr
válasz
Peter Kiss #15256 üzenetére
Mindegyik állítással egyetértek.
(#15251) trisztan94 :
Úgy kell érteni, hogy nyugodtan kidobhatod a kukába ezt az osztályt, mert semmi értelme. -
Sk8erPeter
nagyúr
válasz
trisztan94 #15246 üzenetére
Akkor valahol máshol cseszted el, mert ez a kód szintaktikailag elvileg nem hibás.
De egyébként most mi értelme is volt, hogy bebugyoláltad mindegyik metódust még egy másik metódusba?
Aztán van még egy ilyen switch-case-ed:switch (true) {
case is_int($value):
$type = PDO::PARAM_INT;
break;
case is_bool($value):
$type = PDO::PARAM_BOOL;
break;
case is_null($value):
$type = PDO::PARAM_NULL;
break;
default:
$type = PDO::PARAM_STR;
}Na ne má, ott a gettype(), és akkor nem 3 külön ellenőrzés, a meglehetősen ocsmány switch(true)-val.
-
Sk8erPeter
nagyúr
válasz
DNReNTi #15223 üzenetére
Bizony, minden alkalommal, amikor ilyen kódot osztasz meg, God kills a kitten.
"Hogyan lehetne másképp?
"
Úgy, hogy prepared statementeket használsz.
Meg a SELECT * FROM ... sem egy jó szokás, ne az legyen az alap, hogy minden mezőt lekérünk, mert az teljesítményromlással is jár, hanem soroljuk fel szépen azokat a mezőket, amikre szükségünk van.
Nem beszélve az elgépelésekről, de az mondjuk a legkisebb gond.(#15225) :
"Hüm. Ha esetleg a prepared statements-re gondolt akkor amiatt nem kell aggódni, ahol kell azt használom"
Jogos volt cucka korábbi kérdése, hogy hol nem kell."csak PDO helyett mysqli-t. Itt a példában nem akartam még azzal is karatézni. De jogos."
Teljesen mindegy, hogy PDO vagy mysqli (ez egyben válasz (#15224) mobalnak is), a lényeg a prepared statement volt.
Az pedig szerintem nem jó hozzáállás, hogy a kezdőnek jó lesz szarul is prezentálni, de mi közben a saját fejlesztéseink során jól használjuk. A kezdő ne tanuljon meg rossz példákat. Most pedig nyilvánvaló, hogy az alapján csinálta meg, amit te mutattál neki...(#15232) :
"Például olyan metódusokban nem szoktam használni ahol a szerver oldal ad át ellenőrzött paramétert, mondjuk egy user_id-t, azaz garantáltan nem jelent veszélyt."
Uhh, ez rossz megközelítés, ezt inkább felejtsd el, nincs olyan, hogy "garantáltan nem jelent veszélyt"... de látom ezt közben cucka kifejtette.(#15231) laceeeboy :
Ismerjük az atw.hu-t, komolytalan.Felejtős.
-
Sk8erPeter
nagyúr
válasz
don_peter #15197 üzenetére
"Az oldalamban igen erős html szűrés van így csak megbontva tudtam eddig betenni."
Hát akkor alakítsd úgy a kódodat, hogy whitelist alapján engedélyezz tageket, de szűrj bizonyos attribútumokat..."Mac laposom van és rohadt bonyolult benne ezen karakterek beírása
"
Pff... -
Sk8erPeter
nagyúr
válasz
don_peter #15158 üzenetére
""A szóközök a tageknél (pl. < div > nem jó, csak <div>)"
A saját oldalamra csak így tudtam beilleszteni, hogy megbontottam a HTML tagokat."
Akkor ott valami nagyon el van cseszve. Szóval ezt a < div > kódot javítanod kellene mindenképpen <div>-re, ha rosszul működik, akkor a probléma forrását oldd meg először. Már nem emlékszem az eredeti problémára, lehet, hogy csak a htmlentities() függvényt kellene használnod.Amúgy itt fura az a karakter egy kissé, amit használsz: $valtozo2-›akarmi($valtozo3); Miért ez a -› szerepel a kódodban, miért nem ->?
-
Sk8erPeter
nagyúr
válasz
PumpkinSeed #15194 üzenetére
http://hu1.php.net/manual/en/function.eregi.php
eregi()
Warning
This function has been DEPRECATED as of PHP 5.3.0. Relying on this feature is highly discouraged. -
Sk8erPeter
nagyúr
válasz
don_peter #15139 üzenetére
">>"mi az a H módosító a patternben"
Mi Jelen esetben a H opció annyit tesz, hogy az összes előfordulást figyeli.
Ha nincs ott a H, akkor csak az első előfordulást figyeli a többit figyelmen kívül hagyja."
Hát pedig jól emlékeztem, nincs ilyen modifier, kipróbálás után: "Warning: preg_match_all(): Unknown modifier 'H' in ........ on line 58"
Itt láthatod az összes PCRE pattern modifiert, itt sincs benne:
http://php.net/manual/en/reference.pcre.pattern.modifiers.phpAmúgy nem értelek, honnan jött ez a H modifier (ami nincs PCRE szerint), a kódodban Te sem azt használod, hanem az U-t, ami az ungreedy modifier:
"U (PCRE_UNGREEDY)
This modifier inverts the "greediness" of the quantifiers so that they are not greedy by default, but become greedy if followed by ?. It is not compatible with Perl. It can also be set by a (?U) modifier setting within the pattern or by a question mark behind a quantifier (e.g. .*?).
Note:
It is usually not possible to match more than pcre.backtrack_limit characters in ungreedy mode.""Természetesen a 4 helyére egy változó került ami a ciklus előtt ellenőrzi az előfordulások számát és az az érték került a helyére."
Szerintem ez továbbra sem indokolt, akkor a mintát kellene módosítani, ha a dolog még nem stimmel.
Hozzáteszem, továbbra sem értem, miért akarod feltétlenül helyettesíteni egy mágikus [pkod5]-jellegű szöveggel a stringben a kódblokkokat, az úgy mitől lesz jobb - aztán lehet rákeresni a pkod5-re is, azt lehet cserélgetni... szerintem túl sok overheadet teszel hozzá." $codekiir .= '< div class="'.$class.'" >';
$codekiir .= '< div class="rows" >'.$x.'< /div >';
$codekiir .= $row;
$codekiir .= '< /div >';
"
A szóközök a tageknél (pl. < div > nem jó, csak <div>) remélem, csak a paste-elt kódban vannak, de egyébként itt PH-n nem szükséges ezzel trükközni, mivel a PH a fostalicska BBCode-szerű (de mégsem BBCode, hát érted, biztos attól, hogy feltalálják a sajtban is a lyukat, sokkal biztonságosabb lesz bármi - NEM) szintaktikával működik.
Egyébként csak gyakorlásként csinálsz ilyen syntax highlight-szerűséget? Mert van jópár library ilyen célra.
Például a GeSHi - http://qbnz.com/highlighter/. -
Sk8erPeter
nagyúr
válasz
don_peter #15130 üzenetére
Szívesen, de mi az a H módosító a patternben? Most hirtelen nem ugrik be, hogy lenne ilyen (bár ez nem jelent még semmit).
Amúgy akartam is írni, csak aztán végül csak sikerült elfelejtenem, hogy a preg_match_all() függvényt is érdemes kipróbálnod, ha a preg_match() nem felel meg(#15131) :
miért 4 lépésből áll a ciklus?Honnan tudhatod előre, hogy 4-szer kell lefuttatni ezt a replace-t?
Amúgy őszintén szólva nem egészen értem, miért jó ez neked, hogy a kódokat teljesen kicseréled spec1..spec4 változókra... -
Sk8erPeter
nagyúr
válasz
don_peter #15117 üzenetére
Itt egy lehetséges megoldás:
$html_text = "Ide jön a szöveg
[codeon]
#codeform .coderow2{
float:left;
width:100%;
line-height:22px;
background-color:#d6d6d6;
border:0px solid yellow;
}
[codeoff]";
$pattern = '/(.+)?\[codeon](.+)?\[codeoff]/is';
$replacement = '$1___$2';
$nrOfMatches = preg_match_all($pattern, $html_text, $matches);
echo '$matches[1]: <pre>';
var_export($matches[1]);
echo '</pre>';
echo '$matches[2]: <pre>';
var_export($matches[2]);
echo '</pre>';__________________________________________________________________
Ennek a kimenete pedig ez lesz:
$matches[1]:
array (
0 => 'Ide jön a szöveg
',
)
$matches[2]:
array (
0 => '
#codeform .coderow2{
float:left;
width:100%;
line-height:22px;
background-color:#d6d6d6;
border:0px solid yellow;
}
',
)__________________________________________________________________
Magyarul a kódnál a $matches[1][0] tartalmazza azt, hogy "Ide jön a szöveg", a $matches[2][0] pedig magát a CSS-kódot.
=======================================================
(#15126) Athlon64+ :
Szintén szemfüles találat! -
Sk8erPeter
nagyúr
válasz
trisztan94 #15120 üzenetére
Ez tetszetős
Kár, hogy a deprecated mysql extensiont használja a kód, ami a képen látható, ez így sajnos nem vállalható.
-
Sk8erPeter
nagyúr
Szerintem nem trükközésekre van szükség, hanem a koncepciód átgondolására. Mi indokolja, hogy többezer naplózott sort kiírass egyetlen oldalra? Mi a probléma a paginationnel? Keresőmező?
Tényleg kíváncsi vagyok amúgy a magyarázatra, mert most nem jön át, milyen racionális indok lehet mögötte.Amúgy simán megvalósítható, amit írtál, hogy az oldal egy bizonyos pontjára elérve betöltesz újabb elemeket AJAX-szal.
Lehetséges megoldás:
jQuery Waypoints Infinite Scroll -
Sk8erPeter
nagyúr
Azt szabad megkérdezni, milyen lekérdezésről van szó? Csak kíváncsiságból kérdezem, hogy nagyjából milyen adathalmazról van szó, meg miért tart 30-40 mp-ig annak legenerálása, és miket állítotok elő, egymásba ágyazott táblázatok sokaságát? Csak mert utóbbi is jelentősen meg tudja dobni a generálás idejét.
-
Sk8erPeter
nagyúr
válasz
#68216320 #15065 üzenetére
"A DD-on látható kód ASCII kódokat csinál belőle?"
Igen. (Épp ezért csak ékezetmentes domainek esetén működik, mondjuk úgyis az a gyakoribb.)"Mert arra gondoltam, annál talán jobb, ha generálok egy tömböt a mail-ben használható karakterekkel és azokból rakom össze a címet. Esetleg lehetne, hogy mindig másképp keveri a karaktereket össze a tömbbe. Ez túlbonyolítás?"
A válasz megint csak igen.Jelen esetben nem sok értelme van korlátozgatni, hogy mik a használható karakterek: pontosan tudod előre, hogy milyen email-címet akarsz legenerálni, azoknak meg - ékezetmentes domaint feltételezve - pontosan tudod az ASCII-kódját. Akkor mi a gond?
ord() - Return ASCII value of character
Neked pontosan ez kell. Már ha úgy akarod, ahogy írtam egy lehetséges megoldást a nagyon sokból, hogy szerveroldalon ilyenformán előállítod az email-cím ASCII-karaktereit, aztán kliensoldalon (JavaScripttel) meg összerakod a rendes email-címet. Ennek a megoldásnak mondjuk annyi hátránya van, hogy a szerver- és kliensoldal megvalósítása email-cím generálása tekintetében függ egymástól, de hát na bumm, ez most belefér.
Mondjuk semmiképp sem a DynamicDrive-on látható ocsmány document.write-os megoldással kéne megcsinálnod, hanem úgy, hogy például adott osztállyal ellátott elemben végrehajtod ezt a konvertálást.De még csomóféleképpen meg lehet oldani, mint az előző hsz.-ben írtam.
-
Sk8erPeter
nagyúr
válasz
Tele von Zsinór #15035 üzenetére
"A nagy baj, hogy nem egyértelmű, mi lenne itt a helyes megoldás. A példádnál maradva: január 31-éhez egy hónapot adva mit vársz? Februárt? De hiszen ott nincs 31-e, ha meg a 28-át adod vissza, akkor nem egy hónapot adtál hozzá. Március? De hiszen én csak egy hónapot akartam hozzáadni."
Ebben igazad van, hogy nem egyértelmű, mégis én a MySQL-féle dátumkalkulációit sokkal értelmesebbnek találom a PHP-énál (legalábbis ilyen intervallumos számítgatásoknál többször kapom az általam elvárt eredményt, még ha az általam elvárt eredményt is lehet nyugodtan vitatni), ahol a SELECT DATE_ADD('2001-01-31',INTERVAL 1 MONTH); query eredménye éppen 2001-02-28 lesz - végül is ez is vehetjük úgy, hogy egy hónap hozzáadása, csak épp február hónap napjainak számát adtuk hozzá.Számomra az kevésbé tűnik logikusnak, hogy január 31-hez hozzáadva egy hónapot kijön március 3-a, de igazad van abban, hogy itt nincs "logikus" megoldás, DE mivel a hónap napjainak száma folyton eltér az adott hónaptól függően, ezért szerintem az sem tartozik a jó megoldások közé, hogy az egy hónap az feltétlenül 30 nap. Nincs jó megoldás.
-
Sk8erPeter
nagyúr
válasz
Lacces #15037 üzenetére
"De lemértem a feldolgozás idejét microtime()-al is, és hát érdekes módon az add(new DateInterval()) utasítással 10-ből 8 alkalommal gyorsabb volt, mint a modify()-os megoldás."
Ezt most ugye nem gondoltad komolyan?És akarsz róla beszélni, hány milliszekundumot nyertél vele?
-
Sk8erPeter
nagyúr
válasz
#68216320 #15061 üzenetére
Kiírathatod képként az e-mail-címet (persze ne generáld le a képet minden alkalommal nyilván). Kiírhatod a címet valami teljesen érthető, de mégsem komplett módon: peachman KUKAC dzsímél PONT com . Még azt is csinálhatod, hogy szerveroldalon picit obfuszkálod az e-mail-címet, aztán kliensoldali mutatvánnyal kalapálod össze újból. (Hasonló megközelítés lehet, ha összehozod szerveroldallal (bár nem pont ilyenre gondoltam, de teljesen mindegy): ez legenerál egy kliensoldali kódot az e-mail-cím kiíratására, mondjuk általában a dynamicdrive-on található kódok vagy elavultak, vagy undorítóak (itt se tudtak volna kitalálni jobbat a document.write helyett...), de az ötletet felhasználhatod.) Vagy akár Flash-sel kirakhatsz egy gombot, ami a cím vágólapra másolására szolgál. Neadjisten on-demand töltöd be a címet AJAX-szal... Meg ilyenek.
-
Sk8erPeter
nagyúr
válasz
Lacces #15030 üzenetére
$dateTime->add(new \DateInterval('P'.$dayNumber.'D'));
Szerintem ez elég ronda.Szebb lenne helyette így:
$dateTime->modify('+1 day');Érdemes egyébként odafigyelni rá, hogy a DateTime osztálynak nagyon szépen megvannak a maga hülyeségei, ahogy írják is php.net-en, a hivatalos doksiban:
http://www.php.net/manual/en/datetime.add.php"Example #3 Beware when adding months
<?php
$date = new DateTime('2000-12-31');
$interval = new DateInterval('P1M');
$date->add($interval);
echo $date->format('Y-m-d') . "\n";
$date->add($interval);
echo $date->format('Y-m-d') . "\n";
?>The above example will output:
2001-01-31
2001-03-03"Ez remek, hogy tudnak róla, de nem ártana talán némi korrekció, ahelyett, hogy felhívják a figyelmet erre a hülyeségére.
-
Sk8erPeter
nagyúr
válasz
trisztan94 #15027 üzenetére
Pontosan. A markdown TÉNYLEG segíti az egyszerűbb, sallangmentes és viszonylag kényelmes tartalom-létrehozást, annak is, aki egyébként ismeri a HTML-szintaktikát.
Na ez a BBCode-ról egyáltalán nem mondható el. A HTML-lel szemben sem a felhasználást nem teszi kényelmesebbé, sem a parse-olást, validálást, szűrést (se kliensoldalon, se szerveroldalon), tulajdonképpen csak macerás és korlátolt (lásd például az IMG tagnek az alap BBCode-szintaktikában nem tudsz title-t adni, csak a képhez tartozó URL-t, és hasonlók), ahelyett, hogy sima HTML whitelist lenne, ahogy egyébként manapság már az szerencsére sokkal inkább jellemző (ha valahol engedélyezett a HTML használata pl. kommentelőrendszerben). Tisztességes DOM-struktúrát sem lehet felépíteni belőle. A felhasználók így tényleg kapnak egy használhatatlan tudást, amikor ennyi erővel már megtanulhatták volna a HTML-t is, aminek még haszna is lenne.
(#15026) PeachMan :
"BBCode: Amúgy sem tetszett soha és nem is tudom lehet-e pl. img-t align paraméterrel ellátni."
Ugyan, hova gondolsz."Amúgy jelenleg is használok saját css-t az editorhoz, bár egyelőre csak az editor alap betűtípusa miatt, hogy az legyen, ami majd a főoldalon is lesz a tartalomnak."
Minden tekintetben érdemes a WYSIWYG editor iframe-jét olyanra formázni, amilyen a végleges környezetében lesz (hülye példával: ha sárga háttérszínt kap, akkor legyen sárga a szerkesztőfelületen is). De adott esetben (pl. blogtartalom szerkesztésekor, és hasonló esetekben) még egyszerűbb az inline-formázást használni:
http://www.tinymce.com/tryit/inline.php
http://ckeditor.com/demo#inline"Azt kellene valami számomra is teljesen átlátható módon megoldani mondjuk HTML tagokból minden paraméter eltűnjön, kivéve a class=""."
HTML Purifierrrel:
http://stackoverflow.com/questions/670031/how-to-whitelist-just-some-attributes-with-htmlpurifier
HTML.AllowedAttributes -
Sk8erPeter
nagyúr
válasz
#68216320 #15023 üzenetére
Amit én írtam, azt is láttad?
Nem azért írtam, hogy ignoráld."Felmerült bennem, hogy esetleg a bbcode nem volna-e megfelelő"
Mégis miért volna bármire is megoldás a BBCode? A BBCode úgy, ahogy van, egy f@szság, már születésétől kezdve értelmetlen volt a létezése. Ahelyett, hogy a felhasználókat a sokkal értelmesebb normál HTML-szintaktikára oktatták volna, beleerőltették a fejükbe tök feleslegesen a semmire nem használható BBCode-szintaktikát. Így az évek során kaptak egy használhatatlan, értéktelen fos "tudást". A Prohardveres BBCode-szerű szintaktika is egy értelmetlen fos, megérdemelne pár botütést, aki ezt bevezette, és aki még ezt a mai napig életben tartja. -
Sk8erPeter
nagyúr
válasz
#39417856 #15018 üzenetére
Jaja, van ilyen megoldás, a régi ajaXplorer, aminek a neve most már Pydio: https://pydio.com/. Nagyon fasza, én szeretem, használom, persze azért konfigurálni kell, de csak egyszer kell átfutni a dokumentációját, meg bújni az opciókat a fájlmegosztáshoz és egyebekhez.
Egyéb tekintetben semmit nem kell vele csinálni, beállítod, működik, ahogy kell. Lehet vele még tömörített állományok tartalmát is kotorászni, Flash-alapú videólejátszója van, képnézegetője, fájlszerkesztője, lehet vele másolni, mozgatni, letölteni más URL-ről, tömöríteni, meg kibontani, szóval elég sok funkciót ellát, kényelmes felületen.(#15019) fordfairlane :
nem is tudtam, hogy a TinyMCE doksijában is szerepel a HTML Purifier, attól függetlenül ajánlottam, de jó tudni. Ezek szerint biztos jóféle, sok helyen láttam már ajánlva. -
Sk8erPeter
nagyúr
válasz
#68216320 #15016 üzenetére
Szerintem valami meglévő library-t kellene felhasználnod a HTML-elemek szűrésére (lásd a korábbi linket, de lehet, hogy van jobb, mint a HTML Purifier), ez azért közel sem triviális feladat, és néhány regexp nem biztos, hogy elegendő rá. Bár azokkal is megoldható részben.
Az, hogy csak class-ok vannak megengedve, azért jelentősen egyszerűsíti a dolgot (mivel csak a class-attribútumot kell engedned), ezen pedig kliensoldalon úgy lehet segíteni, hogy jól jelenjenek meg ezzel a tartalmak, hogy a TinyMCE-ben különböző stílusokat definiálsz előre. Lásd a "Custom formats"-demót; ha a Formats-ba belenézel, ott például láthatod az Example 1, Example 2 stílusokat - ezek egyszerűen sima span-tagek, és class van hozzáadva:tinymce.init({
mode: "textareas",
plugins: "table",
content_css: "css/content.css",
style_formats: [
{title: 'Bold text', inline: 'b'},
{title: 'Red text', inline: 'span', styles: {color: '#ff0000'}},
{title: 'Red header', block: 'h1', styles: {color: '#ff0000'}},
{title: 'Example 1', inline: 'span', classes: 'example1'},
{title: 'Example 2', inline: 'span', classes: 'example2'},
{title: 'Table styles'},
{title: 'Table row 1', selector: 'tr', classes: 'tablerow1'}
],
formats: {
alignleft: {selector: 'p,h1,h2,h3,h4,h5,h6,td,th,div,ul,ol,li,table,img', classes: 'left'},
aligncenter: {selector: 'p,h1,h2,h3,h4,h5,h6,td,th,div,ul,ol,li,table,img', classes: 'center'},
alignright: {selector: 'p,h1,h2,h3,h4,h5,h6,td,th,div,ul,ol,li,table,img', classes: 'right'},
alignfull: {selector: 'p,h1,h2,h3,h4,h5,h6,td,th,div,ul,ol,li,table,img', classes: 'full'},
bold: {inline: 'span', 'classes': 'bold'},
italic: {inline: 'span', 'classes': 'italic'},
underline: {inline: 'span', 'classes': 'underline', exact: true},
strikethrough: {inline: 'del'},
customformat: {inline: 'span', styles: {color: '#00ff00', fontSize: '20px'}, attributes: {title: 'My custom format'}}
}
});Itt ez a két sor az érdekes persze:
{title: 'Example 1', inline: 'span', classes: 'example1'},
{title: 'Example 2', inline: 'span', classes: 'example2'},Ez jó példa arra, hogy simán megoldható, amit szeretnél, mármint kliensoldalon.
Ettől még szerveroldalon persze kell szűrni ugyanúgy.A TinyMCE-nek is egyébként van már inline szerkesztési funkciója, az egyszerűsíti a dolgot (az oldalra vonatkozó stíluselemek vonatkoznak akkor a szerkeszthető részre is).
De ha a szokásos, iframe-es megoldást választod (mint a fenti), akkor pedig egyszerűen meg kell mondani a TinyMCE-nek, hogy melyik CSS-fájlt használja fel a stílusok érvényesítésére, ezt a content_css opcióval tudod meghatározni (ezt is láthatod fentebb). Ebbe belerakhatod a class-okat, meghatározhatod, hogyan nézzen ki a textarea. Érdemes úgy kialakítani a textarea kinézetét, ahogy várhatóan ki fog nézni a végleges eredmény."Aztán az <img> tovább nehezíti a dolgot, hogy csak a tárhelyen lévő képet fogadja el."
Erre is biztos van már valami nagyon egyszerű függvény, vagy hasonló, vagy csak simán egy regexp is elég lehet (ilyet nem olyan nehéz egyébként írni); esetleg ezt még ki lehet egészíteni file_exists() ellenőrzéssel, ha szükséges (hogy egyáltalán létezik-e az a fájl a szerveren). -
Sk8erPeter
nagyúr
válasz
#68216320 #15009 üzenetére
Jaja, ismerem ezt a formázási lehetőséget TinyMCE-nél, de ezzel tényleg nem úsztad meg még a többi feladatot. Meg hát ez még csak kliensoldal, szerveroldalon így is-úgy is kell whitelist alapján szűrni a kapott inputot.
"Mivel font style választás esetén nem tudnám megúszni vele a css-t. Ha viszont hagynám a <span> tagot, akkor visszaélésre adna lehetőséget."
Milyen visszaélésre gondolsz? Igazából a spannél is a class- és style-attribútumot szabad csak meghagyni, és utóbbira ezenbelül is legyen whitelist, hogy milyen stílusformázásokat engedsz (a class-re mondjuk nehéz, meg feleslegesnek tűnik).
Például egy fórum hozzászólásainál nem lenne jó engedni mindenféle aláhúzásokat, betűszíneket, háttérszíneket, ilyesmiket, amivel elcsúfítható az oldal összképe. -
Sk8erPeter
nagyúr
válasz
#68216320 #15004 üzenetére
Illik ilyenkor megírni, mire jutottál.
Miket szeretnél kiszűrni?
Egyébként szerintem ilyen sanitizing feladatokra valami kész megoldást szokás használni, de úgy, hogy whitelisted van (nem blacklisted).
Ezt kéne kipróbálnod például (ha nincs kéznél másik jól működő megoldás):
http://htmlpurifier.org/Egyébként kliensoldalon úgy emlékszem, enged a TinyMCE is valami előszűrést (persze ez nem elég önmagában, csak egy első szűrőnek jó).
-
Sk8erPeter
nagyúr
válasz
DNReNTi #15005 üzenetére
Itt próbáld meg: WordPress topic.
-
Sk8erPeter
nagyúr
válasz
Speeedfire #14975 üzenetére
"Ez talán még jobb is, mint a pointer.
"
Ezt meg hogy érted, hogy "jobb, mint a pointer"?"Ezek után gyakrabban fogom alkalmazni, ahol ennek szükségét érzem.
"
Hát azért nem kell ennyire megörülni neki, akkor használd, ha valóban szükséges, erőltetni nem kell. -
Sk8erPeter
nagyúr
válasz
Speeedfire #14970 üzenetére
Az előzőekhez még annyit, hogy PHP-ben nincsenek - pl. C-ből, C++-ból megismert - mutatók. Referenciák vannak:
http://www.php.net/manual/en/language.references.whatare.php"What References Are
References in PHP are a means to access the same variable content by different names. They are not like C pointers; for instance, you cannot perform pointer arithmetic using them, they are not actual memory addresses, and so on. See What References Are Not for more information. Instead, they are symbol table aliases. Note that in PHP, variable name and variable content are different, so the same content can have different names. The closest analogy is with Unix filenames and files - variable names are directory entries, while variable content is the file itself. References can be likened to hardlinking in Unix filesystem."
Ezeket amúgy érdemes átfutni:
http://www.php.net/manual/en/language.references.php -
Sk8erPeter
nagyúr
válasz
pakriksz #14968 üzenetére
"Mint írtam, ha nincs benne azonos sor, akkor hozzá kell adni! Így az update nem jó ide."
Bocs, igazad van, én voltam a hülye, kevertem a REPLACE INTO ... SET ...-szintaktikával...Ami egyből be is illeszti az új sort, ha nincs olyan még.
De tulajdonképpen előnyt nem hoz ahhoz képest, amit most használsz, szóval a korábbit, amit írtam az UPDATE-tel kapcsolatban, inkább felejtsd el, bullshit, visszavonom."» "INSERT INTO stats (ip, user, downloads) VALUES (:userip, :user, 1)
ON DUPLICATE KEY UPDATE downloads = downloads + 1"
Erre már ír hibát, méghozzá hogy "You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ':userip, :user, 1) ON DUPLICATE KEY UPDATE downloads = downloads + 1' at line 1""
Azért az jó, hogy kihangsúlyoztam, hogy ezt direkt PDO prepared statement-es szintaktikával írtam, és hogy nézd meg, amit itt írtam...
Nyilvánvaló, hogy ez így nem fog működni, amíg nem megfelelő módon használod.
A :userip-nek és a :user-nek a query-ben szükséges egy megfeleltetés, értéket kell adni neki a query előkészítése után, így működnek a prepared statementek. Előnyük, hogy az SQL Injection általuk nem lehetséges.
Direkt azért linkeltem be azt a hsz.-emet, mert ott írtam példákat, hogy lehet átírni PDO-sra a lekéréseket.De akkor berakom neked ide is, a saját példádhoz igazítva (ha el nem írom):
// csatlakozás
$db = new PDO(
'mysql:host=localhost;dbname=test_db', // test_db-t módosítsd a megfelelő adatbázisnévre
'root', // módosítsd
'1234', // módosítsd
array(
PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES UTF8;', // egyből UTF-8-ra fogja állítani kapcsolódás után a karakterkódolást
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, // kivételeket fog dobálni probléma esetén
)
);
$query = 'INSERT INTO stats (ip, user, downloads) VALUES (:userip, :user, 1)
ON DUPLICATE KEY UPDATE downloads = downloads + 1';
$stmt = $db->prepare ( $query );
$stmt->bindValue( ':userip', $userip );
$stmt->bindValue( ':user', $user );
$stmt->execute();ez fog dobni egy exceptiont, amit try-catch-blokkal kellene lekezelned. A [B]rowCount[/B]-metódusra ez vonatkozik:
http://hu1.php.net/manual/en/pdostatement.rowcount.php#109891
"Daniel Karp ¶1 year ago
Note that an INSERT ... ON DUPLICATE KEY UPDATE statement is not an INSERT statement, rowCount won't return the number or rows inserted or updated for such a statement. For MySQL, it will return 1 if the row is inserted, and 2 if it is updated, but that may not apply to other databases."Tehát ha a korábbi kód után írsz egy ilyet:
$affected_rows = $stmt->rowCount();
Akkor ezek szerint MySQL esetén az $affected_rows 1-et fog tartalmazni, ha új sor lett beszúrva, illetve 2-t, ha update-elve lett egy korábban már beillesztett sor.
Így ellenőrizheted, mi a query-d eredménye. -
Sk8erPeter
nagyúr
válasz
pakriksz #14965 üzenetére
Pont itt tettem fel a kérdést költőien, ezelőtt 3 hsz.-szel, hogy hogyan lehetséges, hogy a mai napig ennyi összefűzött query van a kódokban, mikor a normális tutorialok első helyen kellene, hogy felhívják a figyelmet rá, hogy ez így gáz.
Ez a "nem csinál semmit, de hibaüzenet sincs" biztos? Hogyan kéred le a hibaüzeneteket?
Egyébként meg ennek a szintaktikának:$sql="INSERT INTO stats (ip, user, downloads) VALUES (:userip, :user, 1)
ON DUPLICATE KEY UPDATE downloads = downloads + 1";tulajdonképpen nem sok értelmét látom (még ha egyébként helyes is!), amikor a következő:
UPDATE stats SET downloads = downloads+1
WHERE ip=:userip AND user=:user;szerintem sokkal beszédesebb.
Itt a query-ben direkt használtam a prepared statementes szintaktikát, a másik belinkelt hsz.-emben láthatsz példát rá, hogyan kéne átírni ezt a kódodat, hogy ne legyen összefűzött a query (mivel lehet, hogy nem megbízható adat, ha pl. query stringből érkezik, mindig érdemes a legrosszabbra számítani).
Hogy hogyan ellenőrzöd, hogy sikeres volt-e a query, vagy pedig történt valami hiba, azt is meg kellene mutatnod.=========================
(#14966) PumpkinSeed :
nincs mit. -
Sk8erPeter
nagyúr
válasz
PumpkinSeed #14946 üzenetére
Ezt ugye vágod?
Igaz, itt nem core módosításáról van szó, hanem egy moduléról, de a modulok kódjába is csak végső esetben kéne beletákolni, hiszen egy update során úgy, ahogy van, elúszhatnak a módosításaid (hiszen update-eled a modul teljes könyvtárát) - aztán szenvedhetsz vele, hogy az azóta esetleg jelentősen megváltozott kódbázisba valahogyan megint belehegeszd. Tehát saját modulból vagy sminkből éri meg ilyenkor módosításokat végezni.
VAGY ha úgy nem megoldható, akkor megnézed, van-e frissebb változat a modulból; megnézed az issue queue-ban, nyitottak-e már topicot az adott problémának drupal.org-on, a modul vonatkozó hibalapján, született-e már patch a hiba megoldására; ha nem nyitottak, nyitsz issue-t, beleírod a problémát, és annak megoldását egy patch formájában. Elsőre bonyolultnak hangzik, de nem az, gyorsan megvan. Cserébe segítettél a közösségnek, ha jó a patch, akkor elfogadhatja a fejlesztő, és committolhatja, majd ha pusholja, akkor jó esetben feltünteti a nevedet; mindenesetre a dev-ágban máris elérhető lesz a javításod.Egyébiránt nekünk még azt sem árultad el, hogy a Drupalból és magából a modulból hányas változatot használod. Meg hogy egyáltalán milyen fájl sorairól beszélsz...
Ezenkívül van Drupal topic. -
Sk8erPeter
nagyúr
Nem nézegettem még a kódját ilyen szinten, de most elég nagyot csalódtam a WordPress-ben (legalább tudom, minek a kipróbálásával ne akarjam tölteni egy percemet sem
), hogy ilyen elképesztő ordas nagy baromság ott virít szépen a dokumentációban, ami elvileg arra való, hogy a fejlesztők és érdeklődők tanuljanak belőle. Először azt hittem, viccelnek, aztán majd ott lesz a vigyorgós fej, hogy jól van, csak vicceltünk, ne vegyél mindent olyan komolyan, de sajnos komolyan gondolják.
Ez az "olyan, mint a f*szom, egy igazi csődtömeg, bottal sem piszkálnám" mondatrészleted igen érdekesen hangzik, remélem, azt vágod.
Furcsa egy (ön)kritika.
Mondjuk ezen legalább jót röhögtem.
-
Sk8erPeter
nagyúr
válasz
csabyka666 #14955 üzenetére
$sql = "SELECT * FROM tabla WHERE id=$value"; //ez így persze nem fut le, de a lényeget értitek...
hogyan lehetséges az, hogy a mai napig látni összefűzött query-ket (NAGY HIBA!!), amik a potenciális veszélyforrásokat szépen magukba foglalják? Úgy értem, régen sokkal inkább tele volt a net akkora szar tutorialokkal, amikből az ember kezdőként sem győzött kukázni, szelektálni, hogy na most melyikben bízzak - de ma már van Google által nagyon jól indexelt Stack Overflow, ahol szerencsére legtöbbször a fejére koppintanak annak, aki ilyen csúfságokat akar elkövetni, meg van számtalan tutorial, ahol elsők között hívják fel a figyelmet arra, hogy sose bízz a felhasználótól érkező vagy általa bármilyen módon módosítható inputban, amikor adatbázis-lekéréssel foglalkozol.
Nézz utána az SQL Injection fogalmának, aztán pedig a PDO-nak és a prepared statementeknek. Így nem kell tartanod SQL Injectiontől.
Normális esetben ez valahogy így nézne ki csatlakozás után:// csatlakozás
$db = new PDO(
'mysql:host=localhost;dbname=test_db', // test_db-t módosítsd a megfelelő adatbázisnévre
'root', // módosítsd
'1234', // módosítsd
array(
PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES UTF8;', // egyből UTF-8-ra fogja állítani kapcsolódás után a karakterkódolást
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, // kivételeket fog dobálni probléma esetén
)
);
$query = 'SELECT ez, az, amaz FROM tabla WHERE id=:id'; // inkább sorold fel a valóban szükséges mezőket, ne mindig a *-ot használd!!
$stmt = $db->prepare ( $query );
$stmt->bindValue( ":id", $value, PDO::PARAM_INT );
$stmt->execute();
foreach ($stmt as $row) {
echo 'ez: '.$row['ez'].', az: '.$row['az'].', amaz: '. $row['ez'];
}Itt láthatsz még bőven példát PDO használatára:
http://wiki.hashphp.org/PDO_Tutorial_for_MySQL_Developers#Executing_prepared_statements_in_a_loopItt bindParam()-ot használ:
$values = array('bob', 'alice', 'lisa', 'john');
$name = '';
$stmt = $db->prepare("INSERT INTO table(`name`) VALUES(:name)");
$stmt->bindParam(':name', $name, PDO::PARAM_STR);
foreach($values as $name) {
$stmt->execute();
}Itt egy példa tranzakciók használatára:
try {
$db->beginTransaction(); // note that calling beginTransaction() turns off auto commit automatically
$db->exec("SOME QUERY");
$stmt = $db->prepare("SOME OTHER QUERY?");
$stmt->execute(array($value));
$stmt = $db->prepare("YET ANOTHER QUERY??");
$stmt->execute(array($value2, $value3));
$db->commit();
} catch(PDOException $ex) {
//Something went wrong rollback!
$db->rollBack();
echo $ex->getMessage();
} -
Sk8erPeter
nagyúr
Most eme kérdés kapcsán kíváncsiságból nézegettem néhány WordPress-doksit, és most kikerekedett szemekkel olvastam ezt a napiszar.hu-színvonalú állítást:
http://codex.wordpress.org/I_Make_Changes_and_Nothing_Happens#See_Where_You_Are
"The die() command is probably the single most useful debugging tool available."Az igen. Gratulálok, WordPress, elég szomorú, hogy ilyen szegénységi bizonyítványt sikerült kiállítani magatokról.
Xdebug, egy normális IDE, rendes debuggolási procedúra? Áááá, ugyan már, az luxus.
-
Sk8erPeter
nagyúr
Ez esetben én kérek elnézést, tényleg félreértettem a hozzászólásodat, eredetileg számomra eléggé oltósnak tűnt (mintha maga a gyorsmegoldás lenne a világ legrondábbja), de valószínűleg csak igen rossz pillanatban olvastam.
(#14918) fordfairlane :
Igaz, feleslegesen sértődtem be. -
Sk8erPeter
nagyúr
Szívesen!
Várj, egy kicsit elszégyellem magam, mert cucka kolléga azt mondta, dádá lesz, mert úgy írtam választ, hogy nem mérlegeltem egy cseppet sem, hogy az a hozzáállás, hogy ha nem minden szempontból kifogásolhatatlan a válaszoló megoldása, akkor bele se kezdjek. Ja, nem, mégsem.
Valahogy le tudom ejteni, ha neked megoldotta a problémádat.
Legközelebb meg majd legfeljebb rábízzuk a kollégára a megoldást. Majd ő megírja a tutit. De igazából nem akarom folytatni a kakaskodást, mert tök értelmetlen, de azért a kellemetlenkedését itthagyta nekünk rossz utóízként a kolléga.
Na, visszatérve: cseppet sem tökéletes a megoldás sem "szépség" szempontjából, ahogy a többiek "finoman" céloztak is rá, de a lényeg egyelőre, hogy menjen, majd írd meg, mire jutottál!
-
Sk8erPeter
nagyúr
Köszönöm, remek, hogy mindezt elmondtad
Mondjuk eleve vicc, hogy most akkor kezdhetek el mentegetőzni, de felmerül a kérdés, hogy 1. miért nem csináltad meg szépen, ahogy illik (talán mert sok idő lett volna, és nincs kedved hozzá?) 2. ha mindenki így áll hozzá, és saját seggét vakarászva, utólag okoskodva kritizál, akkor a kérdezőnek hogy oldódik meg a problémája. Igaz, utólag aztán elszégyellheti magát, hogy hát bizony ő milyen tudatlan, és akkor jól megmondtad. Neki is, de azért nekem is, hát nehogy már.
Elmondtam az elején, hogy pár percnyi szabadidőmben adtam tüneti gyorskezelést. Egy büdös szóval nem utaltam rá, hogy ezt így kellene csinálni (a Notepad++-ba gyorspötyögős dolgokat nem tartom annak). Az ilyen echózott megoldás gusztustalan lehet, igazad van, simán hívhatod spagettikódnak. Igazából szebb lett volna valami template-szerű megoldás, a fordfairlane által említett alternatív szintaktika, és így tovább. (De könyörgöm, nézz már rá a korábbi kódra. Remélem, nem várod el, hogy megtanítsam a kérdezőnek a PHP-alapokat is.) Jó, mondjuk a válaszolónak is felelőssége van abban, hogy az ember hogyan kódol a továbbiakban, ezt aláírom. (Ismét felmerül a kérdés: amennyiben mindenki minden architekturális és egyéb mintát, kódolási stílust a kérdezőknek meg akar tanítani, ki a tököm fog válaszolni? Nem beszélve arról, hogy a PDO-sítást sem végeztem el ilyen alapon, mert nincs se kedvem, se időm rá. Én rohadék.)
Viszont tényleg kíváncsian várom a gyorsmegoldásodat, amit 5 percbe sokkal szebben lehetett volna sűríteni, csak úgy, hogy ne használd fel a kódomat még csak részben sem, mert úgy utólag könnyű.Szóval kérlek, állj elő a mutatvánnyal 5 perc alatt, ami mindenféle architekturális elképzelésednek megfelel.
(#14913) fordfairlane :
Hidd el, én is külön szoktam tenni, template-ezni (vagy ahhoz hasonló megoldást használni) már csak azért is kell, hogy az ember saját magát ne szopassa, meg azért, mert egyébként undormány kód születik. Ja, ez is ronda. (Ja, én is használom az alternatív szintaktikát.) -
Sk8erPeter
nagyúr
válasz
fordfairlane #14910 üzenetére
patternekről sztem nincs sok értelme itt beszélni
Az én kódom is echózott gyorsmegoldás.
-
Sk8erPeter
nagyúr
Hali!
1. a deprecated mysql_ kezdetű függvényekről át kell állni mysqli-re vagy PDO használatára
2. a végéről szedd ki a <center> taget, nemcsak felesleges (mivel nincs nyitótag), hanem obsoleted elem is (nem használjuk ma már, CSS-sel oldjuk meg a középre igazítást)
3. a táblázatos megoldást elkészítettem neked egy kicsit rugalmasabbra, nem tudtam most kipróbálni, csak fejből írtam a dolgot, Notepad++-ba gyorsan bepötyögve, de remélhetőleg nincs benne hiba, tehát:AZ EREDETI
echo "<table>";
echo "<tr><th>ID</th><th>User</th></tr>";
while($row = mysql_fetch_array($result, MYSQL_ASSOC)){
echo "<tr><td><img src=\"gif/".$row['ID'].".gif\"></td><td>".$row['User']."</td></tr>";
}
echo "</table>";HELYETT írd ezt a kódban:
// elemek száma egy sorban
$nrOfItemsInARow = 10;
// megszámoljuk az elemeket a ciklusban, 0-ról indítunk
$nrOfItems = 0;
// táblázat nyitótagje
echo '<table>';
// ciklus (TODO: PDO+MySQL-re vagy mysqli-re minél előbb átállni)
while($row = mysql_fetch_array($result, MYSQL_ASSOC)){
if ($nrOfItems % $nrOfItemsInARow === 0) { // osztási maradék (akkor kezdünk meg egy sort, ha osztható $nrOfItemsInARow-val)
// lezárjuk az előző sort, amennyiben nem az első elemnél járunk
if ($nrOfItems !== 0) { // az első elemnél nyilván nem kell lezárni még semmit
echo '</tr>';
}
// megkezdjük a sort
echo '<tr>';
}
echo '<td>
<a href="http://prohardver.hu/tag/'.$row['ID'].'.html">
<img src="gif/'.$row['ID'].'.gif" alt="'.$row['ID'].' ('.$row['User'].')" title="'.$row['ID'].' ('.$row['User'].')" />
</a>
</td>';
$nrOfItems++; // elemek számát növeljük
}
// maradékos osztás
$rowsRemainder = $nrOfItems % $nrOfItemsInARow; // pl. 33 elem van, 33%10 === 3
$colspanFromRemainder = $nrOfItemsInARow - $rowsRemainder; // pl. 10-3 === 7 --> ennyi üres hely marad még, ezt ki kell tölteni
// kitöltjük a maradék oszlopokat is colspan-attribútum segítségével
// (lásd pl. korábbi példa: 7 elemnyi hely marad)
if ($colspanFromRemainder > 0) {
echo '<td colspan="'. $colspanFromRemainder .'"></td>';
}
// lezárjuk az utolsó sort
echo '</tr>';
// lezárjuk a táblázatot
echo '</table>';
echo '<hr />';
echo '<p>Összesen: <strong>'.$nrOfItems.'</strong> db</p>';
echo '<hr />';Kommenteztem is rendesen, így remélhetőleg gyorsan megérted a kód működését.
Ez így rugalmas, mert elméletileg (ha nem írtam el a kódot) amennyiben a táblázatban egy sorban lévő elemek számát 10-ről szeretnéd megnövelni vagy lecsökkenteni, akkor csak a $nrOfItemsInARow = 10; sorban kell megváltoztatnod a számot. A többi pedig igazodik ehhez, minden egyebet kiszámol.Ja, még egy pluszt hozzátettem: belinkeli a felhasználók adatlapját is (lásd <a> tag), ezt is tördeltem, amennyiben nincs rá szükséged, vagy nem jó az eredmény, egyszerűen szedd ki a linkelést. Ezenkívül az <img> tag kapott alt- és title-attribútumot, ahogy illik.
Ha valami nem tiszta, kérdezz.
-
Sk8erPeter
nagyúr
válasz
Speeedfire #14879 üzenetére
Nem tom, ha nincs a disable_functions direktívában beállítva (amit írt Tele von Zsinór), akkor annyi, hogy más is írt ilyen parát.
-
Sk8erPeter
nagyúr
válasz
Speeedfire #14877 üzenetére
Hogy érted azt, hogy "nem működik"?
Mi történik, amikor használod?
-
Sk8erPeter
nagyúr
válasz
PumpkinSeed #14875 üzenetére
A megfogalmazásod csöppet furcsa és érthetetlen.
Nyilván nem fog működni, ha az adatbázisban a következő elem id-je nem pont a soron következő, plusz 1-gyel növelt szám, illetve az előző kép azonosítója nem épp az 1-gyel levont érték. Gyakran lesz ez a helyzet, mivel az adatbázisból töröl olykor az ember fia vagy lánya rekordokat. (Kukázol képet, ami nem kő'.)
Magyarul írj olyan query-t, amivel megkapod az előző és a következő pár képet is, meg az aktuálisat. Nálad mondjuk csak három kép jelenik meg: az előző azonosítóval ellátott, az aktuális, valamint a következő, és kész. Írj olyan query-t, ami ezt a hármat lekéri.Annak a mondatnak nem sok értelme van, hogy "ÉN azt nem értem, hogyan működik a $p változó léptetése a tag-en keresztül." A tag, amire gondolsz, egy link. Egyszerűen belinkeled a következő képazonosítót, úgy, hogy beleteszed a query stringbe (http://example.com/kepek/index.php?image_id=345, ahol 345 a következő kép azonosítója) azt az azonosítót, ami a következő kép azonosítója; ezt kaptad meg az előző bekezdésben emlegetett query-vel az adatbázisból. Az előzőre linkelés ugyanígy történik, csak az előző képhez tartozó id-vel.
Ha nem oké még mindig, kérdezz. -
Sk8erPeter
nagyúr
válasz
PumpkinSeed #14873 üzenetére
"Hogyan tudok úgy változót deklarálni, hogy annak nem adok értéket?"
Mi a célod?Egyébként nyugodtan kérdezz vissza, ha nem tiszta a magyarázat. Ha nem érted, ne szégyellj kérdezni.
Amiről beszéltünk, hogy látsszon az URL-ben az a kép, amelyiket meg kell jeleníteni. Például http://example.com/images/index.php?image_id=65432Mint látható, itt $_GET['image_id'] == 65432, és legalább az URL könyvjelzőzhető, elküldhető másnak.
Tudsz úgy lekérést írni, hogy adatbázisból ezt a képet kérd le, és az előtte/utána lévő akárhány elemet, amelyiket mondjuk thumbnailként szeretnéd megjeleníteni.
Vágod? -
Sk8erPeter
nagyúr
válasz
PumpkinSeed #14871 üzenetére
Ezek szerint még mindig nem jött át, mit csinálsz rosszul. A query stringben legyen megadva a kép azonosítója. Ne sessionnel szórakozz, mert jelen feladatnál nem szabadna, hogy munkamenethez kötődjön, hogy melyik képnél jársz... Hogyan linkeled be az adott képet, ha mondjuk meg akarod mutatni ismerősödnek? Hogyan könyvjelzőzöd a megfelelő URL-t? (Az URL ugyanis jelen megoldásban BÁRMELYIK képnél is jársz, http://79.121.121.12:8080/imgshit/?elem=0 vagy http://79.121.121.12:8080/imgshit/?elem=1. SEMMI nem utal ebből arra, hogy pontosan melyik képet is kellene megjeleníteni.)
Ezeket gondold végig, és ennek alapján csináld meg.Korábban említetted, hogy GYŰLÖLÖD az adatbázis-kezelést (
). Ugye ezt nem valami fájlbaírós bohóckodással oldod meg?
-
Sk8erPeter
nagyúr
válasz
PumpkinSeed #14865 üzenetére
Akkor most próbáld meg végiggondolni, hogy mit és miért írt DNReNTi úgy, ahogy. Oka volt rá, hidd el.
-
Sk8erPeter
nagyúr
válasz
PumpkinSeed #14837 üzenetére
Mindenképpen.
Új hozzászólás Aktív témák
Hirdetés
- Steam Deck
- Autós topik
- Melyik tápegységet vegyem?
- Kerékpárosok, bringások ide!
- Elektromos cigaretta 🔞
- Formula-1
- Genshin Impact (PC, PS4, Android, iOS)
- Motorolaj, hajtóműolaj, hűtőfolyadék, adalékok és szűrők topikja
- Motorola Edge 60 és Edge 60 Pro - és a vas?
- 200 megapixeles zoomkamerát sem kap az S26 Ultra?
- További aktív témák...
- Xiaomi Redmi Note 10 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
- Bomba ár! HP EliteBook 830 G5 - i5-8G I 8GB I 256GB SSD I 13,3" FHD I HDMI I Cam I W11 I Gari!
- Xiaomi Redmi Note 14 5G
- 100 - Lenovo Yoga Pro 9 (16IRP8) - Intel Core i9-13905H, RTX 4070 (ELKELT)
- Samsung Galaxy A41 64GB Kártyafüggetlen, 1Év Garanciával
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest