Hirdetés
- Luck Dragon: Asszociációs játék. :)
- Mr Dini: Mindent a StreamSharkról!
- sidi: 386-os Chicony gázplazma laptop memóriabővítése
- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- Pitterix: Gyógytorna
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Brogyi: CTEK akkumulátor töltő és másolatai
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- GoodSpeed: Kell-e manapság egérpad vagy sem?
Új hozzászólás Aktív témák
- 
			
			  Sk8erPeter nagyúr válasz  Thrawnad
							
							
								#18380
							
							üzenetére Thrawnad
							
							
								#18380
							
							üzenetéreA mysql_* kezdetű függvényeket felejtsd el, elavult, nem támogatott, és amúgy is 2016 van, használj PDO-t vagy MySQLi-t, ÉS paraméterezett lekérdezéseket, változóbehelyettesítés (mint nálad a nap='$ma') a query-ben egyáltalán nem szabad, hogy szerepeljenek. Ez az első lépés, még ha kényelmetlen is lesz az átírás, ez már szinte kötelező (tisztább, szárazabb, biztonságosabb érzés).
- 
			
			  Sk8erPeter nagyúr "Ezek működnek. De egyik sem scriptet hív." 
 Ez mondjuk elég fontos lehet, hogy van már olyan, ahol műxik. Van futtatási jogosultsága annak a júzernek, aki ezt futtatni próbálja? Pl. az a júzer benne van olyan csoportban, akinek van joga ehhez, vagy van explicit joga a futtatásra?
 Ha nincs, az para."Viiszont amin most túrázok, az sem scriptként meghívva, sem a konkrét parancsot meghívva shell_exec-cel, nem megy." 
 Nem túl konkrét, hogy min túrázol. 
- 
			
			  Sk8erPeter nagyúr 
- 
			
			  Sk8erPeter nagyúr 
- 
			
			  Sk8erPeter nagyúr 
- 
			
			  Sk8erPeter nagyúr válasz  DiabloCorsa
							
							
								#18160
							
							üzenetére DiabloCorsa
							
							
								#18160
							
							üzenetéreDOMDocument::loadXML-lel betöltöd az XML-fájlt, getElementsByTagName segítségével a tageket tudod betölteni, bejárod az így kapott eredményhalmazt, getAttribute segítségével pedig az attribútumok értékeit tudod lekérni. Az utóbbi oldalon a kommentek között egy egész értelmes példakódot is találsz. 
 Írj, ha ez alapján sem jön össze.
- 
			
			  Sk8erPeter nagyúr válasz  Speeedfire
							
							
								#18155
							
							üzenetére Speeedfire
							
							
								#18155
							
							üzenetéreSejtem, hogy ilyesmi módon akarja futtatni a scriptet, csak az nem derült ki, hogy a kép elérési útja pontosan mitől nem jó, és hogy azonos szerveren találhatóak-e a képek és maga a script - ha nem, akkor a relatív elérési út nyilván nem lesz jó, meg engedélyek is közbeszólhatnak, ezért kérdezem tőle, hogy pontosan hogyan próbálkozik, hátha így gyorsabb lesz az oknyomozás. 
- 
			
			  Sk8erPeter nagyúr válasz  fordfairlane
							
							
								#18116
							
							üzenetére fordfairlane
							
							
								#18116
							
							üzenetéreNem árt felhívni a kolléga figyelmét, hogy ez csak akkor működik, ha a második és harmadik tömbnek legalább annyi eleme van, mint az elsőnek. Persze az elvárt, hogy mindnek ugyanannyi eleme legyen. (#18126) deedetette: 
 Ez általános algoritmizálási kérdés, érdemes végiggondolnod, hogy oldanád meg pszeudokóddal.
 - az első feladat esetén növelgetsz egy változót, ha 60-nál nagyobb számot találsz
 - a második feladatnál pedig tárolnod kell a ciklusban való rohangászás során az addig megtalált maximális számot (első legnagyobb), illetve a második legnagyobbat, és hasonlítgatni a ciklusban épp vizsgált új tömbelemmel, meg az eddig megtalált első és második legnagyobb számmal (nagyobb-e, mint az addigi második legnagyobb szám, illetve még kisebb-e, mint az első legnagyobb). Persze mindig frissítgetned kell az első/második legnagyobb számot is, ha találsz azok korábbi értékeinél még nagyobbat a ciklusban való lépegetés során.
- 
			
			  Sk8erPeter nagyúr válasz  DNReNTi
							
							
								#18105
							
							üzenetére DNReNTi
							
							
								#18105
							
							üzenetéreAmúgy a PHP Stormnak annyiból teljesen igaza van, hogy az a jó konvenció, hogy a boolean változók getterei is-zel kezdődnek (isXY()). A getXY() elnevezés kevésbé tűnik szépnek kódolvasáskor. (Pl. mittomén, leírva a $user->isAdmin() sokkal jobban mutat és logikusabban olvasható, mint pl. a $user->getIsAdmin().) 
 Mondjuk az isIsDraft tényleg hülye név, ezt igazán felismerhetné a PHP Storm, hogy épp is az eleje a változónak is... 
- 
			
			  Sk8erPeter nagyúr válasz  DNReNTi
							
							
								#18102
							
							üzenetére DNReNTi
							
							
								#18102
							
							üzenetéreSzerintem ez jó kiindulási alap: 
 https://gist.github.com/Maaiins/0d39341d6cd61718e8de
 Itt például a function ${GET_OR_IS}${NAME}() részt átírhatnád function get${NAME}()-re, hátha ez megoldja.
- 
			
			  Sk8erPeter nagyúr válasz  #68216320
							
							
								#18085
							
							üzenetére #68216320
							
							
								#18085
							
							üzenetéreAz első mindenképpen ocsmány megoldás, mivel így nem válik szét a megjelenítés és az adatok validálása, feldolgozása, adatbázisba írása (meg hasonló műveletek). A form kiírásának semmi köze nem szabadna, hogy legyen ahhoz, hogy aztán mit kezdesz az adataiddal. Szóval mindenképp válaszd külön a kettőt. Ezért szokás szétválasztani a különböző rétegeket (lásd MVC-szemlélet és társai). 
- 
			
			  Sk8erPeter nagyúr válasz  PumpkinSeed
							
							
								#18061
							
							üzenetére PumpkinSeed
							
							
								#18061
							
							üzenetére"error-t dobott arra, hogy objektumot nem akar tárolni és azt hittem, hogy nem lehet" 
 Az elég durva lenne... Egyébként nem valószínű, hogy az volt a hiba, hogy objektumot "nem akar tárolni", hanem valami ennél PICIKÉT konkrétabb és értelmesebb hiba fordult elő. 
- 
			
			  Sk8erPeter nagyúr válasz  martin66
							
							
								#18029
							
							üzenetére martin66
							
							
								#18029
							
							üzenetére"A baj, pedig az, hogy ez mögé illeszti be a plugin magát" 
 Nem a the_content() függvényhívás részeként kerül kiírásra?A WordPress lelkivilágának ismerete nélkül elég nehéz erre a kérdésre válaszolni, igazából végig kellene debuggolni, hogy hol kerül beszúrásra a plugined tartalma, meg érteni kéne, az általad idézett rész, tehát hogy "Add WP filter for automatic shortcodes" mire vonatkozik (milyen automatic shortcodes, mi az?), mert nem tűnik túl logikusnak, hogy egy SZŰRŐ adjon hozzá tartalmat egy posthoz (ettől még persze működhet így a WordPress ![;]](//cdn.rios.hu/dl/s/v1.gif) ), látni kéne a plugined kódjának többi részét, hátha abból összeállna a kép, mert az általad berakott kódrészletek és a screenshot nem sokat segít. ), látni kéne a plugined kódjának többi részét, hátha abból összeállna a kép, mert az általad berakott kódrészletek és a screenshot nem sokat segít.Egyébként ahol tuti értenek hozzá, az a WordPress Development Stack Exchange site: http://wordpress.stackexchange.com/ 
 Itt is megkérdezhetnéd - angolul -, itt sokkal valószínűbb, hogy belátható időn belül kapsz hathatós segítséget.(#18031) PumpkinSeed: 
 Pályakezdőként is nyugodtan lehet jelentkezni megfelelő Java-tudással egy junior pozícióra. (Ezt az első bekezdésedre írom.) Persze ez más nyelvre is igaz. Jó esetben az ilyen szinten elvárható tudást nézik (legyenek stabilak az alapok, értsd, mi miért működik úgy, ahogy, legyenek azért ismereteid a többszálúságról is, stb.), meg a képességet, hogy alkalmas vagy látszólag arra, hogy aztán később a cég jó szakembere legyél, ha belejössz. Megértem, hogy neked nem jött be a nyelv, van ilyen, a lényeg, hogy abban fejlessz, ami közelebb áll hozzád. (Ezt az első bekezdésedre írom.) Persze ez más nyelvre is igaz. Jó esetben az ilyen szinten elvárható tudást nézik (legyenek stabilak az alapok, értsd, mi miért működik úgy, ahogy, legyenek azért ismereteid a többszálúságról is, stb.), meg a képességet, hogy alkalmas vagy látszólag arra, hogy aztán később a cég jó szakembere legyél, ha belejössz. Megértem, hogy neked nem jött be a nyelv, van ilyen, a lényeg, hogy abban fejlessz, ami közelebb áll hozzád.
 Egyébként az oktatás színvonalával kapcsolatos felháborodás természetesen jogos, mert elvárható lenne, hogy adott egyetem/főiskola/OKJ-s képzés/stb. az embernek valóban naprakész (!), használható tudást adjon, sajnos ritkán mondható ez el, és sajnos el kell fogadni, hogy az ember kénytelen kőkeményen képezni saját magát, így kell áthidalnia a problémát, erre utaltam. (#18032) mobal: 
 Nem tudom, hogy elolvastad-e az egész hozzászólásomat. Éppen ott van, hogy - idézem - "Ettől még egy egyetem elvégzése sem garancia semmire"... Éppen ott van, hogy - idézem - "Ettől még egy egyetem elvégzése sem garancia semmire"... De azért ha valaki végigcsinál egy nevesebb egyetemet, az talán annyira utal, hogy képes valahogy átszenvedni magát a megpróbáltatásokon. De azért ha valaki végigcsinál egy nevesebb egyetemet, az talán annyira utal, hogy képes valahogy átszenvedni magát a megpróbáltatásokon.
 Egyébként nem értem, miért kellene befejezni a témát, még ha OFF-ba is kell rakni, ez programozáshoz kapcsolódó beszélgetés, nem pedig a karácsonyi bejgliről dumálunk, és bőven érintheti a PHP-fejlesztőket is (mint a mellékelt ábra mutatja), és így megoszthatjuk egymással a gondolatainkat, ettől is pörögnek a topicok. (Meg amúgy mostanában vagy csend van, vagy érdektelen kérdés sajna.)
- 
			
			  Sk8erPeter nagyúr válasz  PumpkinSeed
							
							
								#18027
							
							üzenetére PumpkinSeed
							
							
								#18027
							
							üzenetére"meg is értem, hogy nagy a kereslet Java szakember irányába, mert abból tényleg szinte nulla a szakember" 
 Ekkora hülyeséget hogy lehet leírni? Már hogy lenne nulla szakember Javából? Lehet, hogy Te nem találkoztál komoly, hozzáértő szakemberekkel abban a jelenleg még kicsi világban, amiben szakmai téren mozogsz, de rengeteg ilyet találni - ha már itt tartunk, inkább nehéz kifogni jó szakembert PHP-s területről, mint Javásról. Nem véletlenül fizetik meg jól. Nyilván itt is bőven vannak kóklerek, mint mindenhol. És ugyanez igaz lehet C#-vonalra (nagyon jó és nagyon rossz szakemberek is vannak, és jók tudnak lenni a fizetések), felesleges is azon rugózni, melyik a jobb. Ott dől el igazán a kérdés, hogy valaki melyikre állt rá jobban - aztán lehet később váltani, csak nehézkes (meg ugye az adott nyelvből tudsz felmutatni igazán komoly szakmai tapasztalatot, és akárki akármit mond, hogy nem a nyelv számít, hanem az algoritmusok, meg a programozási szemlélet, blabla, ez a gyakorlatban bullshit, mert igenis számít, hogy mennyire vagy ráállva a nyelvhez kapcsolódó infrastruktúrára). Sőt, egyébként C/C++ területen is van kereslet, és ott is komoly fizetéseket el lehet érni, mivel ezek sokszor kapcsolódnak speckó területekhez (pl. beágyazott fejlesztés, ilyesmik), meg léteznek jó Python-állások, stb., de ha megnézed az állásajánlatokat, akkor tényleg brutálisan sok Javás kínálat van. Már hogy lenne nulla szakember Javából? Lehet, hogy Te nem találkoztál komoly, hozzáértő szakemberekkel abban a jelenleg még kicsi világban, amiben szakmai téren mozogsz, de rengeteg ilyet találni - ha már itt tartunk, inkább nehéz kifogni jó szakembert PHP-s területről, mint Javásról. Nem véletlenül fizetik meg jól. Nyilván itt is bőven vannak kóklerek, mint mindenhol. És ugyanez igaz lehet C#-vonalra (nagyon jó és nagyon rossz szakemberek is vannak, és jók tudnak lenni a fizetések), felesleges is azon rugózni, melyik a jobb. Ott dől el igazán a kérdés, hogy valaki melyikre állt rá jobban - aztán lehet később váltani, csak nehézkes (meg ugye az adott nyelvből tudsz felmutatni igazán komoly szakmai tapasztalatot, és akárki akármit mond, hogy nem a nyelv számít, hanem az algoritmusok, meg a programozási szemlélet, blabla, ez a gyakorlatban bullshit, mert igenis számít, hogy mennyire vagy ráállva a nyelvhez kapcsolódó infrastruktúrára). Sőt, egyébként C/C++ területen is van kereslet, és ott is komoly fizetéseket el lehet érni, mivel ezek sokszor kapcsolódnak speckó területekhez (pl. beágyazott fejlesztés, ilyesmik), meg léteznek jó Python-állások, stb., de ha megnézed az állásajánlatokat, akkor tényleg brutálisan sok Javás kínálat van.
 Egyébként uncsi picit visszatérően olvasgatni a topicokban, hogy sokan mindig valaki másokat hibáztatnak azért, ha nem sikerült kiképezni magukat valamilyen nyelvből. Igen, az oktatás többnyire szar, ritka a pozitív kivétel, ezért kell autodidakta módon tanulni, jó forrásokból, és rengeteg energiát, időt, szorgalmat kell rááldozni, és folyamatosan képezni magadat, utánanézni, megérteni, ha valamit nem látsz át. Ez ilyen, nem fogja megtanulni helyetted senki. (BTW nekem sem tanította senki a webfejlesztést, és nem a BME-t szidtam azért, amiért elhanyagolható a jó webfejlesztés-oktatás (konkrétan ASP.NET-hez kapcsolódóan találkoztam csak ilyennel egy szabvál keretében).)
 Hogy egy olyan szeletével találkoztál a Java-programozásnak, ami épp az adott területhez kapcsolódó gyengébb infrastruktúra (keretrendszerek, fejlesztőeszközök, és minden egyéb, ami befolyásolja a fejlesztést) miatt nagyon nagy szopókör volt, vagy rosszul választottad meg az eszközöket, az még önmagában egyáltalán nem minősíti magát a nyelvet (mert arról nem írtál, hogy maga a nyelv miért lenne hibás ezért).(#18024) szupermacs: 
 Annyiból szokott számítani a szakmailag RELEVÁNS papír, hogy legalább annyiról tanúskodik, hogy képes vagy magad átvergődni különböző megpróbáltatásokon, tehát képes vagy tanulni, megoldani problémákat. Ettől még egy egyetem elvégzése sem garancia semmire, olyan ocsmány munkát végző emberekkel lehet találkozni még komoly egyetemeken is, hogy elkeserítő, de itt legalább szerencsére számtalan nagyon jó példával is lehet találkozni. Egyébként jó esetben állásinterjún úgyis kiderül, hogy mennyire lehetsz alkalmas a feladatok elvégzésére (azért írom, hogy "jó esetben", mert van, hogy élesben kiderül, hogy mégsem az igazi a munkavállaló, vagy épp az interjú menete van elcseszve, és az interjúztató szopatja feleslegesen a munkakeresőt).
 A Python tanulásnak egyébként azért lehet jó, mert hozzászoktat a megfelelő kódstrukturáláshoz (kényszerítve vagy az indentálásra (behúzásra)), meg viszonylag gyorsan tanulható, és nem túl nehéz belekezdeni sem a kódolásba (mint általában a scriptnyelveknél).(#18001) PeachMan: 
 Valami ilyesmi, de azért a user is tudja módosítani a saját avatarját. De maga a feltöltés menete nyilván ne a felhasználó osztályában legyen implementálva, csak áthív egy másik osztály megfelelő metódusára. De maga a feltöltés menete nyilván ne a felhasználó osztályában legyen implementálva, csak áthív egy másik osztály megfelelő metódusára.
- 
			
			  Sk8erPeter nagyúr válasz  #68216320
							
							
								#17999
							
							üzenetére #68216320
							
							
								#17999
							
							üzenetéreNem, nem az a baj vele, hogy nem "hordozható", hanem hogy túl sok mindent akar csinálni az osztályod - éppen ahogy j0k3r! írta, és tök igaza van -, olyat is, ami nem tartozik az ő hatáskörébe, és hogy idézzem a kollégát, "A te esetedben a User osztálynak csak annyi dolga kellene, hogy legyen, hogy egy ilyen entitást leírjon". Tehát ha van egy felhasználó osztályod, akkor az írjon le felhasználóra vonatkozó attribútumokat (milyen tulajdonságai vannak) és műveleteket (miket tud a felhasználó csinálni), de ne lehessen vele tök más felhasználókat is szerkesztgetni, törölgetni, hozzáadni, mert az már nem tartozik rá, hogy az adatbázisban milyen egyéb felhasználók vannak, főleg nem szabad itt, hogy azokat még kezelgetni is tudja. Ilyesmire tényleg egy külön osztály való, aki kezeli ezeket az entitásokat egy "magasabb" szinten, és ő tudhat is róla, hogy milyen felhasználók vannak. 
- 
			
			  Sk8erPeter nagyúr válasz  #68216320
							
							
								#17993
							
							üzenetére #68216320
							
							
								#17993
							
							üzenetéreEz így tényleg ronda, eleve kerülendő globális változókat használni, de miért nem passzolod át egyszerűen akár a konstruktorban, akár valamelyik metódus paramétereként a szükséges változót? (#17989) mobal: 
 Jól hangzik elméletben, de a szolgáltatók többségénél még mindig nem MariaDB van, hanem MySQL.
- 
			
			  Sk8erPeter nagyúr Elméletileg nem, aztán a gyakorlat lehet, hogy adott esetben mást mutat, de ha még jobb esetekben nincs is probléma az átállással, gondolj bele, a weben fent lévő cuccok közül vajon hány készülhetett olyan módon, hogy ott nem jelent gondot egy komolyabb váltás... hát olyanokból arányaiban elég "kevés" lehet (a nagy többséghez képest). 
- 
			
			  Sk8erPeter nagyúr válasz  Speeedfire
							
							
								#17985
							
							üzenetére Speeedfire
							
							
								#17985
							
							üzenetéreVégül is a MariaDB sem ismert a "kommersz körökben", akármi legyen is az.  A hostingcégek többsége még mindig a MySQL-t nyomatja érthető módon, mivel pl. a szintén népszerű PHP-alkalmazások többsége is erre alapoz, ez az örökség még elég sokáig fent fog maradni, nehéz elképzelni hirtelen váltást, mert így menne a kukába az összes régi webes cucc is, ami MySQL-re épített. Ha viszont alternatívák után kell nézni, akkor a PostgreSQL elég népszerű, az nem valószínű, hogy ennél a MariaDB népszerűbb lenne, főleg már csak amiatt sem lehet az, mert utóbbi JÓVAL újabb, a PostgreSQL-re rengeteg alkalmazás épül. Persze abban igazad van, hogy valószínűleg kevésbé fájdalmas az átállás MariaDB-re MySQL-ről, mint pl. PostgreSQL-re, gondolom erre gondoltál. A hostingcégek többsége még mindig a MySQL-t nyomatja érthető módon, mivel pl. a szintén népszerű PHP-alkalmazások többsége is erre alapoz, ez az örökség még elég sokáig fent fog maradni, nehéz elképzelni hirtelen váltást, mert így menne a kukába az összes régi webes cucc is, ami MySQL-re épített. Ha viszont alternatívák után kell nézni, akkor a PostgreSQL elég népszerű, az nem valószínű, hogy ennél a MariaDB népszerűbb lenne, főleg már csak amiatt sem lehet az, mert utóbbi JÓVAL újabb, a PostgreSQL-re rengeteg alkalmazás épül. Persze abban igazad van, hogy valószínűleg kevésbé fájdalmas az átállás MariaDB-re MySQL-ről, mint pl. PostgreSQL-re, gondolom erre gondoltál. 
- 
			
			  Sk8erPeter nagyúr válasz  Speeedfire
							
							
								#17983
							
							üzenetére Speeedfire
							
							
								#17983
							
							üzenetéreNem azt kérdeztem, hogy miért MariaDB a MySQL helyett, mert az értelemszerű, hogy "jobb", azt kérdeztem, miért pont MariaDB, miért nem mondjuk PostgreSQL (vagy más). De pont ezt így le is írtam.  "Mármint MySQL oké, hogy nem, csak miért MariaDB, miért nem PostgreSQL, vagy ilyesmi" "Mármint MySQL oké, hogy nem, csak miért MariaDB, miért nem PostgreSQL, vagy ilyesmi"
- 
			
			  Sk8erPeter nagyúr válasz  GGAllin
							
							
								#17974
							
							üzenetére GGAllin
							
							
								#17974
							
							üzenetére"Linux(Xubuntu) alól akarom futtatni a Wamp Servert de valami nem jó" 
 Jaja, az eléggé nem jó, hogy Windows-cuccot akarsz Linuxra erőltetni, olyat, aminek ráadásul tökéletes alternatívái vannak Linux-oldalon. Érdekelne, hogy mi az oka?Egyébként a Wine-emulációk még mindig nagyon korlátosak, még ha egész sok Windows-progi fut is így Linuxon, az esetek többségében tapasztalható valamiféle hiányosság. Persze nem is elvárható, hogy minden menjen. (#17979) mobal: 
 Miért épp az? Mármint MySQL oké, hogy nem, csak miért MariaDB, miért nem PostgreSQL, vagy ilyesmi. Mármint MySQL oké, hogy nem, csak miért MariaDB, miért nem PostgreSQL, vagy ilyesmi. Azért, mert újabb, vagy csak mert MySQL-utód, vagy van valami egyéb oka, pl. szakmai vagy simán ízlésbeli szempontok? (Csak kíváncsi vagyok, félre ne értsd, nem azért kérdezem, hogy aztán vitatkozzak, hogy hádepedignemis, csak érdekel. Azért, mert újabb, vagy csak mert MySQL-utód, vagy van valami egyéb oka, pl. szakmai vagy simán ízlésbeli szempontok? (Csak kíváncsi vagyok, félre ne értsd, nem azért kérdezem, hogy aztán vitatkozzak, hogy hádepedignemis, csak érdekel. ) )
- 
			
			  Sk8erPeter nagyúr válasz  The DJ
							
							
								#17957
							
							üzenetére The DJ
							
							
								#17957
							
							üzenetéreÉn a helyedben megkérdezném itt: 
 Joomla Stack Exchange
 http://joomla.stackexchange.com/
 Biztos vannak olyan arcok, akik még ilyen ősrégi fosokhoz is értenek, mint az 1.5-ös Joomla. Vagy érdemibbet tudnak mondani, mert ahogy elnéztem az itt aktív közösséget, senki nem ért a Joomlához (és ez javukra legyen mondva ). ).
- 
			
			
- 
			
			  Sk8erPeter nagyúr A file függvény fájlnevet vár első paraméterül, Te pedig a $current változót passzolod át neki, ami a beolvasott fájl tartalmát, meg az ahhoz fűzött további adatokat tartalmazza. Ez így eleve nem lesz jó. 
 Azt írod, hogy fopen($path), de közben a $path változó értéke nincs beállítva (vagy legalábbis itt nem osztottad meg velünk). Ha a kódodból és hsz.-edből jól vettem le, az eredeti fájlt szeretnéd módosítani úgy, hogy hozzáírsz még adatot, tehát akkor az általad $file-nak nevezett változót kellene átadnod neki. De szerencsésebb lenne ezt inkább $filename-nek elnevezni, hiszen épp csak egy fájlnév, nem a fájlt reprezentáló objektum vagy ilyesmi (tehát félrevezető a név).
 Az fopen két paramétert vár, csak egyet adtál meg. Ez a hibaüzenetekből egyértelműen kiderül, ha nincsenek kijelezve a hibaüzenetek, fejlesztés idejéig igazából kötelező (hogy időben észrevedd, meg hogy ne legyen ilyesmi, hogy nem érted, mi van). Mivel csak írni szeretnél a fájlba, passzold át még neki a "w" paramétert.
 Aztán a foreach-ben ha jól értem ilyen jó fáradt fejjel, ki akarod szedni a már meglévő sorokat. Na de aztán nem teszed bele igazából azokat az értékeket, amik "újak", csak kiszedsz - tehát pl. egy üres fájlnál nem írsz vissza a fájlba semmit. Így nem meglepő, hogy az egész nem is működik.
- 
			
			  Sk8erPeter nagyúr válasz  don_peter
							
							
								#17917
							
							üzenetére don_peter
							
							
								#17917
							
							üzenetére"Kiíratásnál pedig ezt: 
 localStorage.getItem("lastname");
 Az oldal frissítése után nem ír ki semmit."
 És ennek mégis mi a frászért kellene bármit is kiírnia? Nem tároltad el sehova a függvény visszatérési értékét, nem használtad fel sehol... mit vársz, mit kellene tennie ettől a sortól? Nem tároltad el sehova a függvény visszatérési értékét, nem használtad fel sehol... mit vársz, mit kellene tennie ettől a sortól?
 Szóval nem, nem jól használod.(#17910) don_peter: 
 "És igen, megfeledkeztem arról, hogy a PHP az szerveroldali megoldás bár ajax-al nyilván megoldható a textarea kiolvasása, de sokkal jobb és közelibb egy javascript."
 Ennek a mondatnak mi értelme van? Az AJAX az Asynchronous JavaScript and XML-ből alkotott mozaikszó, szóval hogy miért választod külön a kettőt, az rejtély. Mi az, hogy "sokkal jobb"? Minél jobb? Mi az, hogy "közelibb"? Mihez képest van közelebb, és az miért lesz bárkinek is jó? Tehát: van a kliensoldali, böngészőfüggő mentés, meg a szerveroldali. Ha nem para, hogy böngészőadatok ürítésekor elvész az addig megírt piszkozat, vagy hogy egyáltalán böngészőfüggő a dolog, tehát nem folytathatja az emberke bárhol az addig megkezdett szövegét, akkor maradhat a kliensoldali tárolás. Ha nem szeretnéd, hogy klienshez, böngészőhöz kötődjön a tartalom, vagy hogy a böngésző oldalspecifikusan tárolt adatainak törlésekor elvesszen a tartalom, akkor küldd el a piszkozatot szerveroldalra, és ott tárold (lásd Gmail-piszkozat). Persze itt azért figyelj rá, hogy ne tudjon kismillió darab piszkozatot tárolgatni a júzer, hogy tömködje feleslegesen piszkozatokkal az adatbázisodat, mármint ha ez gondot jelent. IP-cím változása hatására nem kell, hogy a session is megszűnjön, erre ismét jó példa a Gmail. Vagy a Drupal is így oldja meg. Nézz utána, hogy kell megoldani. (#17905), (#17907): 
 "elmegy a NET"
 Akarod mondani net. Ez a szó NEM egy mozaikszó! Nem értem, emberek miért írják csupa nagybetűvel, nem kell. Lásd ezt."COOKIE lehet járható út?" 
 Akarod mondani cookie. Ez sem mozaikszó. "persze mehet egy kis ajax-al is a dolog" 
 Akarod mondani AJAX. Pont azt nem írod csupa nagybetűvel, amit meg kell? Pont azt nem írod csupa nagybetűvel, amit meg kell? 
- 
			
			  Sk8erPeter nagyúr válasz  PowerBuldog
							
							
								#17903
							
							üzenetére PowerBuldog
							
							
								#17903
							
							üzenetéreHát ez aztán rettentően értelmes feladat, ha tényleg azt kellett csinálni, hogy be kell olvasni egy XML-fájl tartalmát DOMDocumenttel, aztán úgy, hogy SEMMIT nem csináltál vele, csak simán kiíratni a tartalmat...  Remélem, csak Te értettél félre valamit, és nem ilyen retardált feladatot kaptál. Remélem, csak Te értettél félre valamit, és nem ilyen retardált feladatot kaptál.
 Mellesleg ez szinte semmiben nem különbözik a korábbitól, mi a frász értelme van ennek, hogy most csak annyit változtattál, hogy másképpen olvasod be, és beállítasz egy fejlécet is (mellesleg helyes, hogy beállítod)? Amúgy korábban nem véletlenül tanácsolta neked fordfairlane, hogy ellenőrizd már azt a nyomorult query stringet, hogy azonbelül az elvárt bemeneti paramétert megkapod-e egyáltalán... 
- 
			
			  Sk8erPeter nagyúr válasz  fordfairlane
							
							
								#17890
							
							üzenetére fordfairlane
							
							
								#17890
							
							üzenetérePedig itt sztem igaza van Trisztánnak, valami feedback azé' legalább egy header formájában nem ártana.  (Még egy sima echózás is jobb lenne még exit előtt, mint egy tök üres lap hiba esetén, ami akármi mástól is lehetne (pl. fatal error elrejtett hibaüzenetekkel), kezdő jól beszophatja az ilyeneket, amikor elírja mondjuk a query stringet, vagy ilyesmi.) (Még egy sima echózás is jobb lenne még exit előtt, mint egy tök üres lap hiba esetén, ami akármi mástól is lehetne (pl. fatal error elrejtett hibaüzenetekkel), kezdő jól beszophatja az ilyeneket, amikor elírja mondjuk a query stringet, vagy ilyesmi.)(#17881) fordfairlane: 
 Hát igen, ez így elég jól hangzik, de 220 ezret akkor sem szánnék monitorra (csak ha fürdenék a lóvéban). Jelenleg elégedetten használok egy Dell P2414H-t, árkategóriáján belül az is igen jóféle (legalábbis az volt, amikor vettem), az én igényeimet szerencsére kielégíti, bár lehet, hogy azért, mert nincs is túl sok igényem. Csak a színhűség (kalibrálás megoldotta), meg a minimum 24" (el tudnék viselni mondjuk 27"-et...), plusz hogy ne legyen túlzottan széjjelvilágított, ronda feketéje a monitornak, meg persze ne legyen durva utánhúzása (alacsony késleltetés), legalábbis most ami eszembe jut (meg nyilván digitális csatlakoztatási lehetőségek). Csak a színhűség (kalibrálás megoldotta), meg a minimum 24" (el tudnék viselni mondjuk 27"-et...), plusz hogy ne legyen túlzottan széjjelvilágított, ronda feketéje a monitornak, meg persze ne legyen durva utánhúzása (alacsony késleltetés), legalábbis most ami eszembe jut (meg nyilván digitális csatlakoztatási lehetőségek). 
 Egyébként abszolúte elhiszem, amit írsz, hogy igényesebb szemnek feltűnnek ezek a zavaró tényezők, sok fanatikus nem véletlenül ragaszkodik a jobbfajta CRT-monitorjához. Örülök, hogy számomra ezek nem zavaróak, meg is őrülnék akkor minden monitortól, amihez oda kell ülnöm. Ha kicsit odafigyelek erre, még így is zavar pl. melóhelyen a 24"+19" monitorokból az utóbbi, ami távol áll az igényes monitortól (az is Dell, de az önmagában nem jelent semmit). Ha kicsit odafigyelek erre, még így is zavar pl. melóhelyen a 24"+19" monitorokból az utóbbi, ami távol áll az igényes monitortól (az is Dell, de az önmagában nem jelent semmit).
- 
			
			  Sk8erPeter nagyúr válasz  fordfairlane
							
							
								#17867
							
							üzenetére fordfairlane
							
							
								#17867
							
							üzenetéreUhh, ez igen minőségi darab, de a 220 ezres ára miatt valószínűleg nem fogok rárepülni.  (Pedig jól jönne egy 27"-es a 24" mellé.) (Pedig jól jönne egy 27"-es a 24" mellé.)
- 
			
			  Sk8erPeter nagyúr válasz  PumpkinSeed
							
							
								#17777
							
							üzenetére PumpkinSeed
							
							
								#17777
							
							üzenetérePont most írta, hogy "A xampp\mysql\data\mysql\user.frm, user.MYD, user.MYI felülírása friss telepítésből származóval megoldotta."  
- 
			
			  Sk8erPeter nagyúr "persze hogy sql hívások set names nélkül, hogy törne le a keze aki írta a php jquery naptárat" 
 A többesszámot a hívásoknál nem értem, a SET NAMES 'valamilyen_karakterkészlet' (pl. SET NAMES 'UTF8' (aposztróf nélkül is működne itt amúgy)) utasítást egyszer kell csak kiadni, a csatlakozás után, és kész.
 Persze lehet, hogy erre utaltál, csak félreérthetően hangzott. 
 (Ahogy a "php jquery naptár" is furán hangzik. ) )
- 
			
			  Sk8erPeter nagyúr válasz  supercow
							
							
								#17761
							
							üzenetére supercow
							
							
								#17761
							
							üzenetére"A másik részt nem értem." 
 Mivel odaírtad, hogy max="50", ezért a böngésző helyes implementáció esetén már vagy eleve a bevitel során, vagy a fókuszváltás/elküldés/stb. során jelzi a validációnál, hogy érvénytelen számot adtál meg, ergo nem is enged tovább, nem tudod elküldeni az űrlapot (csak ha trükközöl webfejlesztő panel segítségével, vagy ha például a böngésző nem is támogatja a HTML5-öt). Itt meg nem ez a cél, hanem a figyelmeztetés arra, hogy a felhasználó nagy számot adott meg - de ettől még egyébként elfogadható a nagy szám is, csak meg kell győződni róla, hogy a felhasználó tényleg azt akarta-e.
 Igaz, a javasolt ellenőrzési módszer is csak kliensoldalon zajlik, tehát ez sem egy atombiztos megoldás, de lehet, hogy a kérdezőnek ez is elegendő, ez nem derült ki.
- 
			
			  Sk8erPeter nagyúr válasz  TigerCat
							
							
								#17736
							
							üzenetére TigerCat
							
							
								#17736
							
							üzenetére"PHP, CSS5" 
 Hát lehetőleg a CSS5-öt ne írd bele, mert jelenleg olyan még nem létezik. Szerintem a HTML5, CSS3-ra gondoltál. Szerintem a HTML5, CSS3-ra gondoltál.
 Amúgy nem Javascript, hanem JavaScript, nem Ajax, hanem AJAX (mozaikszó). Ezek hibás leírása zavaró lehet egy álláshirdetésben.
 Mellesleg nem biztos, hogy érdemes ragaszkodni a PHP-hoz, nem az a webfejlesztés alfája és omegája. Más területekről is komoly szakemberek érkezhetnének.
 Egyébként nem biztos, hogy érdemes úgy keresni, hogy valaki ne csak komoly fejlesztő, hanem egyben jó rendszergazda is legyen, mert bár lehet, hogy utóbbi feladatok közül a nálatok érdekeseket is lazán elvégezné (pl. a mailszerver beállítását), de mondjuk nem akar oprendszereket telepíteni (amire nálatok nincs is szükség gondolom az ő esetében, de ezt nem tudhatja), és megijedhet a "rendszergazdai feladatok" kulcsszótól...Mellesleg szerintem is nagyon rossz ötlet, hogy mindenféle népszerű keretrendszert is (nemcsak a CMS-eket) kizártok a játékból. 
- 
			
			  Sk8erPeter nagyúr válasz  PumpkinSeed
							
							
								#17677
							
							üzenetére PumpkinSeed
							
							
								#17677
							
							üzenetéreIgazából miért ezzel a borzalmasan ronda spagettikóddal oldod meg a problémát? 
- 
			
			  Sk8erPeter nagyúr válasz  rantottsajt
							
							
								#17655
							
							üzenetére rantottsajt
							
							
								#17655
							
							üzenetéreHogy jött ki a 10000?  
- 
			
			  Sk8erPeter nagyúr "debuggolj. írasd ki echo-val a különböző változók értékeit" 
 Ezen azért kuncogtam. A debuggolás NEM AZ, hogy kiíratsz!!! Persze része lehet a hibakeresésnek, adott esetben nem para, ha nem a képernyőt írod tele, hanem legalább naplózol, de pont ez a baj, hogy számtalan PHP-fejlesztő azt hiszi, hogy az a jó hibakeresési módszer, ha telerakja a kódját echózásokkal (persze nem is naplóz véletlenül se), és nem tudja, hogy léteznek valódi debuggolási módszerek egy fejlesztőkörnyezetben (IDE), az Xdebug felhasználásával. Tehát bármily meglepő, PHP-ban is ugyanúgy lehet debuggolni, mint másik nyelvekben. Tök jól végig lehet lépkedni a kódon, hogy épp hol tart, vagy csak kifejezetten az általad manuálisan elhelyezett töréspontokon (breakpoint) megállni, lehet watch expressionöket elhelyezni (így a kód adott pontjára érve bizonyos változók értéke kiírásra kerül egyből a fejlesztőkörnyezetben), sőt, jó fejlesztőkörnyezetben lehet feltételes töréspontokat is elhelyezni (conditional breakpoint), ami azt jelenti, hogy csak bizonyos feltételek teljesülése esetén áll meg a kód adott pontján (ezzel például tök jól lehet rászűrni a problémás esetekre, amikor mondjuk nem akarsz minden esetben megállni, hanem csak akkor, amikor gáz van).
 Igazából az van, hogy szerintem nagyon sokan úgy vannak a debuggolással, hogy "na majd egyszer azt is kipróbálom, most addig is jó lesz az echo", pedig egyszer kell belőni a környezetet - ehhez segítségnek ott van az Xdebug wizardja -, meg egyszer kell kipróbálni, ez mire is jó - tehát megtanulni debuggolni -, aztán rengeteg időt tud megspórolni.
- 
			
			  Sk8erPeter nagyúr válasz  MineFox54
							
							
								#17627
							
							üzenetére MineFox54
							
							
								#17627
							
							üzenetére1. Nem konkatenálunk SQL-utasítást escape-eletlen inputtal, SOHA, semmilyen körülmények között (azt sem érdemes felhozni mentségnek, hogy de hát az szerintem megbízható adat, mert nincs olyan kívülről érkező adat, amit megbízhatónak érdemes tekinteni - ez a paranoiás szemlélet célravezetőbb), és amennyiben lehetséges, prepared statementeket KELL használni a különböző paraméterekre. És jelenleg lehetséges, mivel MySQLi-t használsz, szóval mindenképp állj át arra. 
 2. Az ilyen jellegű mezőkhöz aliasokat illik használni (pl. itt SUM(tav) AS distance vagy hasonló), aztán az aliasnak megfelelően hivatkozni rájuk (pl. itt $row['distance'] - szándékosan nem használtam magyar változónevet ). ).A konkrét érdekes eltéréshez nehéz többet hozzátenni, több infót kellene tudni, mi változhat a különböző futtatások között. 
- 
			
			  Sk8erPeter nagyúr "http://x-profit.hu ezt ismeri valaki? amilyen gáz a honlapjuk, nem tudom, mit tudhat a cucc" 
 Ezt látom, amikor megnyitom, mivel szándékosan Click to play-re vannak állítva a Flash-tartalmak:Gratulálok nekik. 2015-ben még mindig egy full Flash-alapú oldal. 
 Utána azért kíváncsiságból már rákattintottam, de mivel a dizájn is ilyen borzasztó gusztustalan 2000-es évek eleji (az izgő-mozgó gifek korát idézi), ezért nem is néztem tovább. Most tényleg egy ilyen igénytelen szar után képes lennél még fizetni is nekik?
- 
			
			  Sk8erPeter nagyúr válasz  fordfairlane
							
							
								#17589
							
							üzenetére fordfairlane
							
							
								#17589
							
							üzenetéreOszd meg majd a szerzőkkel is, hátha átemelik.  
- 
			
			  Sk8erPeter nagyúr válasz  #68216320
							
							
								#17587
							
							üzenetére #68216320
							
							
								#17587
							
							üzenetéreHát igen, az az egyik példa phpMyAdmin-alternatívának, úgy tudom, a phpMyAdmin egyáltalán nem működik MySQLi-kiterjesztés nélkül (pl. PDO-val). Igazából ha korábban MySQLi-t használtál, akkor nem szabad, hogy nagy érvágás legyen átállni PDO-ra. A PDO-nak más szintaktikája van, szerintem egy fokkal könnyebben használható (számomra legalábbis jobban "kézreáll" az API), a prepared statementeknél használhatóak nevesített placeholderek (érdemes használnod, nem pedig a MySQLi-ből megszokott kérdőjeleket, persze ezek is működnek, sőt, van olyan eset, amikor pont erre van szükség (pl. amikor dinamikusan állít össze az ember egy előkészített utasítást)), és egyéb előnyei is vannak, valószínűleg nem lesz túl sok problémád az átállással. 
 Szoktam linkelgetni a topicban Tele von Zsinór kolléga PDO-val kapcsolatos cikkét, fusd át, mert igazából minden lényeges dolog benne van az elinduláshoz (pl. ami fontos, hogy a kapcsolat inicializálásakor a karakterkódolást kapásból UTF-8-ra állítja, ÉS hiba esetén exceptionök dobására utasítja a PDO-t).
- 
			
			  Sk8erPeter nagyúr válasz  cidalain
							
							
								#17568
							
							üzenetére cidalain
							
							
								#17568
							
							üzenetérePedig ebben semmi misztikus nincs, többek közt az Accept-Language fejlécből megállapíthatóak a böngésző nyelvi beállításai - a böngésző ugyanis elküldi a szervernek, hogy a felhasználó - a beállítások szerint - melyik nyelvet preferálja, illetve mely további nyelveket kívánja elfogadni a kliens (ami a böngésző): 
 http://www.w3.org/International/questions/qa-accept-lang-localesAztán persze a szerver azt kezd ezzel az információval, amit akar - például ignorálhatja, vagy épp ennek felhasználásával állapítja meg az épp megjelenítendő nyelvet. PHP esetén az Accept-Language fejléchez a $_SERVER['HTTP_ACCEPT_LANGUAGE'] változón keresztül férsz hozzá. 
- 
			
			  Sk8erPeter nagyúr válasz  PumpkinSeed
							
							
								#17537
							
							üzenetére PumpkinSeed
							
							
								#17537
							
							üzenetéreMi van a /php/controller.php fájl 19. sorában? Ott csatlakozol az adatbázishoz, vagy mi történik? Fel tudsz amúgy dobni egy phpinfo-t az oldaladra? "Amúgy miért működik a JS rendellenesen azért mert ez nem jó?" 
 Be sem töltődik a teljes dokumentum, 500 Internal Server Error van 1,1 perc után (durva timeout), az okozhat ilyet, például ha a dokumentum "ready" eventjének elsülése hatására futna le a JavaScript-kódod.
- 
			
			  Sk8erPeter nagyúr Hoppá, tényleg, teljesen igazad van, a Visual Studio Community tök ingyenes, tegnap megfeledkeztem róla, ráadásul a fejlesztők többségének elegendő is ez az ingyenes változat (nem is csak alapvető dolgokra!). (#17523) mobal: 
 PHP után főleg megváltás. 
- 
			
			  Sk8erPeter nagyúr "beleszocializálódtam a Visual Studioóba, más már azután "szar". No offense  " "
 Na ezzel az állítással nem tudok vitatkozni. Gyorsan meg lehet szokni a jót, a gyorsat. Egyébként az Eclipse és NetBeans egyáltalán nem tökéletesek, sőt, például a Visual Studio kategóriáján belül sokkal jobb és sokkal gyorsabb, de előbbiek előnye, hogy ingyenesek (persze nyilván E.-ben és NB.-ben C#-támogatás nincs, Visual Studióban meg nincs Java-támogatás, de érted Gyorsan meg lehet szokni a jót, a gyorsat. Egyébként az Eclipse és NetBeans egyáltalán nem tökéletesek, sőt, például a Visual Studio kategóriáján belül sokkal jobb és sokkal gyorsabb, de előbbiek előnye, hogy ingyenesek (persze nyilván E.-ben és NB.-ben C#-támogatás nincs, Visual Studióban meg nincs Java-támogatás, de érted ). ).(#17517) biker: 
 Hát ez bizony ilyen ("szörnyű"), hogy meg kell szokni, hogy másik szoftverben nagy eséllyel máshol vannak a dóóógok...![;]](//cdn.rios.hu/dl/s/v1.gif) 
 Amúgy nem akarlak én meggyőzni semmiről, de ebben a topicban már nem is tudom, hányszor szenvedtél azzal, hogy próbálsz echózni, loggolni, kísérletezgetni, másképpen futtatni, átmenetileg sorokat kikommentezni, ahelyett, hogy debuggolnál. Tök mindegy, mit használsz a célra, de nem árt megtanulnod az előnyeit, egyszer melós lehet, de aztán rengeteg időt spórolhatsz vele.
- 
			
			  Sk8erPeter nagyúr válasz  fordfairlane
							
							
								#17513
							
							üzenetére fordfairlane
							
							
								#17513
							
							üzenetéreHát ez elég furcsa, hogy a munkahelyen nem IDE-ket használtok, hanem szövegszerkesztőket. "Két kollégám használ Netbeanst, és ők sokat szidják a lassúsága miatt" 
 A sok fájlművelet miatt komoly szűk keresztmetszet tud lenni a HDD - ahogy az Eclipse-nél is. Persze sok munkahelyen nem adnak sajnos SSD-ket a fejlesztők "alá". Meg persze számít szerintem a JVM miatti relatív lassúság is. Ettől függetlenül nem kell mai szemmel komoly erőgépnek tekinthető konfiguráció - de mondom, tényleg nem bánik kíméletesen az erőforrásokkal, sima szövegszerkesztőnél viszont mindenképp SOKKAL hatékonyabb fejlesztést tesz lehetővé - ez mondjuk nem is kérdés, ezért furcsállom, hogy nem IDE-ket használtok egy munkahelyen, ahol kifejezetten a fejlesztés van a középpontban. (Ha nem bírná a céges gép, hogy IDE-t használok, komolyan, saját laptopomon nyomnám a fejlesztést bent is (pedig az én laptopom sem mondható egy erőgépnek, de néha tapasztalt röccenésen kívül bírja az iramot), hacsak céges policy nincs, ami ezt nem engedi.)És nem hiányzik nektek a tisztességes refaktorálási lehetőség, a runtime kódanalizálás, gyorssegítség a hibák kijavítására, számtalan kódírást gyorsító feature, az annotált kommentek alapján történő dokumentáció-tippek és igazából minden olyan, amit egy IDE nyújt, de egy szövegszerkesztő nem? Hát hogyan fordulhat az elő?  Kódírást gyorsító szolgáltatások nyilván sok sima szövegszerkesztőben is léteznek, de ezek legtöbbször nem gondolkodnak normálisan "projektszinten", vagy csak részleges támogatást nyújtanak (pl. valamilyen módon van lehetőség fájlok logikai összeszervezésére, egyfajta projektnézetre, de az alapján sokszor csak részleges kódkiegészítési lehetőségek vannak, valahol korlátokba lehet ütközni, legalábbis én ezt tapasztaltam, pedig sokat kipróbáltam). Kódírást gyorsító szolgáltatások nyilván sok sima szövegszerkesztőben is léteznek, de ezek legtöbbször nem gondolkodnak normálisan "projektszinten", vagy csak részleges támogatást nyújtanak (pl. valamilyen módon van lehetőség fájlok logikai összeszervezésére, egyfajta projektnézetre, de az alapján sokszor csak részleges kódkiegészítési lehetőségek vannak, valahol korlátokba lehet ütközni, legalábbis én ezt tapasztaltam, pedig sokat kipróbáltam).
 Igazából annyi plusz feature van egy IDE-ben egy szövegszerkesztőhöz képest, hogy nem is érdemes végigmenni rajta... de hogy nélküle miért jó fejleszteni, azt nem értem.Konkrétan egyébként milyen szövegszerkesztőket használtok? 
- 
			
			  Sk8erPeter nagyúr Tehát azért szenvedsz, azért nem tudsz debuggolni (lévén, hogy csak egy szövegszerkesztőt használsz (amiért amúgy fizettél), nem egy IDE-t), és azért nem tudsz rengeteg egyéb műveletet elvégezni, olyanokat, amiket egy IDE nyújt (tehát ha feltételezünk egy normális fejlesztői környezetet), hogy ne terhelje a gépedet? Nem tom, nekem ezek az érvek viccesek, amikor valaki ezen spórol, miközben lóvéért fejleszt, és a saját munkaideje saját magának kerül pénzbe (pl. ha egyéni vállalkozó vagy). Csak mert ugye léteznek ugye olyan alternatívák is, amik egy fillérbe sem kerülnek, és integrált fejlesztőkörnyezetek, mint például az Eclipse vagy a NetBeans - igen, ezek nem kíméletesek az erőforrásokkal, de működnek, gyorsítják a fejlesztést, ingyenesek, tudsz bennük PHP-kódot debuggolni (ezzel a ráfordítandó munkaóráid számát adott esetben jelentősen csökkentve = profit). (#17511) fordfairlane: 
 Ebben tökéletesen igazad van, de általában ezek a műveletek kellőképpen felhasználóbarát módon vannak megoldva egy IDE-ben, nem beszélve arról, hogy normális fejlesztőkörnyezetben az ember úgyis IDE-t használ. Persze akár más kliens is lehet, ami a műveletet felhasználóbaráttá teszi. Itt említ lehetőségeket. Itt említ lehetőségeket.
- 
			
			  Sk8erPeter nagyúr Ja, lehet, hogy az Xcode-ra, nem vágom.  (Sorry, nem szimpatizálok az Apple-cuccok agyatlanul túlárazott jellegével, meg a hozzá kapcsolódó sznob kultúrával. (Sorry, nem szimpatizálok az Apple-cuccok agyatlanul túlárazott jellegével, meg a hozzá kapcsolódó sznob kultúrával. ) )A PhpStorm szerintem is jó, meg úgy általában a JetBrains-cuccok (pl. Python-fejlesztéshez a PyCharm is nagyon bejött, korábban az Eclipse PyDev pluginjét használtam, de a PyCharmban fejlesztés sokkal jobbnak és pörgősebbnek bizonyult; Java-fejlesztéshez az IntelliJ IDEA-val még nincs érdemi tapasztalatom, de azt is nagyon dicsérik). 
- 
			
			  Sk8erPeter nagyúr 
- 
			
			  Sk8erPeter nagyúr válasz  cidalain
							
							
								#17502
							
							üzenetére cidalain
							
							
								#17502
							
							üzenetéreSzerk.: 
 (#17499) MineFox54:
 Most látom a szerkesztés után írott szövegedet."én abban kézzel be tudom állítani az útvonalat" 
 Úgy érted, szeretnél egy űrlapot, azon szeretnél két mezőt kiindulási ponthoz és célponthoz, és úgy szeretnéd működtetni az egészet? Mert akkor módosítja a dolgot, ez esetben Google Maps API-ra lehet szükséged, de simán JavaScript elég hozzá, nem kell PHP.
 Szóval ha jól értem, kb. azt akarod, hogy a Google Maps weboldalán (https://www.google.hu/maps) látható működést átültesd a sajátodra.A hivatalos példák hasznodra lehetnek: 
 https://developers.google.com/maps/documentation/javascript/examples/Szükséges lesz viszont JavaScript-tudás. 
- 
			
			  Sk8erPeter nagyúr 
- 
			
			  Sk8erPeter nagyúr válasz  MineFox54
							
							
								#17497
							
							üzenetére MineFox54
							
							
								#17497
							
							üzenetéreEnnek mi köze a PHP-hez? Legalábbis az itt írt további hsz.-ed alapján bőven elég beágyazni az útvonalat, aztán annyi. 
 Ha viszont valahogy dinamikusan szeretnéd megtervezni az útvonalat, nem egy konkrét, rögzített útvonalat akarsz megjeleníteni, akkor tedd fel értelmesebben a kérdésedet.(#17495) biker: 
 És a Macesek nagy sztárolt IDE-jében (már ha az, nem csak egy szerkesztő, fogalmam sincs a Mac-cuccokról, nem is nagyon izgatnak) nem lehet PHP-kódot debuggolni? 
- 
			
			  Sk8erPeter nagyúr Igazából a feladat egyszerű, mint a lepkefing, pár perc alatt megoldható. 
 Végigmész az adott könyvtár fájljain (az alapján, amit írtál, feltételezem, hogy egy helyre vannak ömlesztve, nem kell rekurzíve bejárni a könyvtárakat), reguláris kifejezéssel ellenőrzöd, hogy illeszkedik-e a fájlnév az általad megadott mintára, ha igen, akkor space mentén "szétrobbantod" a stringet, majd ebből kiszeded. Legalábbis ez egy nagyon gyorsan bepötyöghető megoldás. Szépségével nem foglalkoztam a kódnak, ez működik:$filename_pattern = '/^[a-z]+ \d+ \S+\.asd\.txt$/'; 
 $dir = '.';
 $filenames = scandir($dir);
 foreach($filenames as $filename) {
 if (!is_dir("$dir/$filename")) {
 if(preg_match($filename_pattern, $filename)) {
 $filename_pieces_by_space = explode(" ", $filename);
 $measurement_location = $filename_pieces_by_space[0];
 $measurement_id = $filename_pieces_by_space[1];
 
 echo $measurement_id, ': ', $measurement_location . PHP_EOL;
 }
 }
 }A reguláris kifejezés jelentése: a string eleje és vége között a következők vannak: bármilyen a és z közötti karakter egynél többször, szóköz, bármilyen szám egynél többször, szóköz, bármilyen nem whitespace karakter egynél többször, majd pont, "asd", pont, txt. 
 Itt az explode eredményeként a harmadik elem a tömbben ilyen lesz, mint a "90n00004.asd.txt", ha ebből további infó kell, akkor nyilván pontok mentén kell szétrobbantani.(#17485) biker: 
 Hát ennyi infóból ember legyen a talpán, aki megmondja, mi a baj. 
 Azért remélem, azóta nem vágtál eret. 
- 
			
			  Sk8erPeter nagyúr válasz  fordfairlane
							
							
								#17465
							
							üzenetére fordfairlane
							
							
								#17465
							
							üzenetéreAtyaisten, csak most néztem bele én is a PHPMailer kódjába, ez tényleg brutális, tényleg egy gigantikus osztály, semmi tisztességesen szétválasztott kód. A SwiftMailer Swift_Message osztálya pl. picit rövidebb, és ez csak osztály a sok közül, itt legalább Dependency Injection van. (#17480) don_peter: 
 "Magyar Angol keverék a jó " "
 Ez viccnek is rossz. Főleg, hogy ha már "magyar" vagy "angol", akkor kis kezdőbetűvel írjuk. Főleg, hogy ha már "magyar" vagy "angol", akkor kis kezdőbetűvel írjuk. (De a kód legyen angol, a programozás nyelve angol, akár tetszik, akár nem. (De a kód legyen angol, a programozás nyelve angol, akár tetszik, akár nem. ) )
- 
			
			  Sk8erPeter nagyúr válasz  creation
							
							
								#17459
							
							üzenetére creation
							
							
								#17459
							
							üzenetére"Sajnos nem jöttünk rá mi lehet az ok. Ráment két napunk, viszont nincs ilyenre idő" 
 A Programozás topicban nem véletlenül mondtam már a legelején, hogy DEBUGGOLJATOK egy normális fejlesztőkörnyezet bevetésével. Ne csak próbálkozzatok, szenvedjetek, toporogjatok egy helyben, hanem vizsgáljátok meg normálisan az ügyet, a klienstől a szerver felé utazó adatokat, azokat a körülményeket, amiktől a szerveroldalon elvérzik az autentikáció. De úgy tűnt, erre nem vagy nyitott, meg még azt sem mondtad meg sokszori kérdéseimre sem, hogy egész pontosan hol is vérzik el a dolog, plusz ugye normális hibakezelés sem volt a kódodban.(#17461) creation: 
 "Valóban nem, de legalább működik![;]](//cdn.rios.hu/dl/s/v1.gif) " "
 A Swift Mailer is működik, nem tudom, miért ne működne. Meg hogy honnan van egyáltalán összehasonlítási alapod, ha egyiket sem használtad még soha. (#17460) fordfairlane: 
 Lehet, szerencsére nem nézegetem egy ideje, direkt raktam előre a Swift Mailert. 
- 
			
			  Sk8erPeter nagyúr válasz  creation
							
							
								#17457
							
							üzenetére creation
							
							
								#17457
							
							üzenetéreEzek szerint továbbra sem sikerült kideríteni, mi a frász köze van a használt kliensnek ahhoz, hogy szerveroldalon nem működik az autentikálás?  Pedig engem érdekelt volna, brühüh. Pedig engem érdekelt volna, brühüh.
 A levelezős problémára annyi a megoldás, hogy valami normális library-t használsz hozzá, mint például a Swift Mailer vagy a PHPMailer, és nem szenvedsz azzal a fostos beépített mail() függvénnyel önmagában. Tégy jót az emberiséggel, és ne próbáld vérrel és verítékkel megoldani azt a problémát, amit más már megtett helyetted. 
- 
			
			  Sk8erPeter nagyúr válasz  creation
							
							
								#17444
							
							üzenetére creation
							
							
								#17444
							
							üzenetéreItt már írtam neked, de nem találtad fontosnak a válaszadást...  (Lehet, hogy más reakciójára vársz, de akkor is illene legalább böffenteni valamit válaszként. (Lehet, hogy más reakciójára vársz, de akkor is illene legalább böffenteni valamit válaszként. ) Akkor hogyan haladjunk tovább? Le kéne szűkíteni a potenciális problémákat, tudni kéne, nézegettél-e naplókat, a szerver beállításainak változtatgatásaival próbálkoztál-e, vagy csak default módban üzemel, mivel próbálkoztál a probléma megoldásának érdekében, stb., de persze nekem teljesen mindegy, nem nekem kell. ) Akkor hogyan haladjunk tovább? Le kéne szűkíteni a potenciális problémákat, tudni kéne, nézegettél-e naplókat, a szerver beállításainak változtatgatásaival próbálkoztál-e, vagy csak default módban üzemel, mivel próbálkoztál a probléma megoldásának érdekében, stb., de persze nekem teljesen mindegy, nem nekem kell. 
- 
			
			  Sk8erPeter nagyúr válasz  creation
							
							
								#17433
							
							üzenetére creation
							
							
								#17433
							
							üzenetérehttp://prohardver.hu/tema/programozas_forum/hsz_8649-8649.html 
 Végül is itt is folytathatjuk. 
- 
			
			  Sk8erPeter nagyúr válasz  cidalain
							
							
								#17430
							
							üzenetére cidalain
							
							
								#17430
							
							üzenetére"+1 kérdés: mit jelent az hogy "thread safe" meg "non thread safe" verzió?" 
 Guglizás megvolt már? 
 http://php.net/manual/en/faq.obtaining.php#faq.obtaining.threadsafety
 "What does thread safety mean when downloading PHP?
 Thread Safety means that binary can work in a multithreaded webserver context, such as Apache 2 on Windows. Thread Safety works by creating a local storage copy in each thread, so that the data won't collide with another thread.So what do I choose? If you choose to run PHP as a CGI binary, then you won't need thread safety, because the binary is invoked at each request. For multithreaded webservers, such as IIS5 and IIS6, you should use the threaded version of PHP." 
- 
			
			  Sk8erPeter nagyúr válasz  cidalain
							
							
								#17428
							
							üzenetére cidalain
							
							
								#17428
							
							üzenetéreA forráskód csak akkor érdekes, ha te magad akarod buildelni a PHP-t, megkapva a szükséges futtatható állományokat és a többi szükséges fájlt. Nyilván nem akarsz ezzel szarakodni, ez esetben meg ott van a letölthető zip, abban van egy install.txt, van egy manual installation része, az jó részletesen leírja a teendőket. Tulajdonképpen "csak" a meglévő webszerveredhez kell igazítani az itt kibontott cuccot. 
- 
			
			  Sk8erPeter nagyúr válasz  MineFox54
							
							
								#17424
							
							üzenetére MineFox54
							
							
								#17424
							
							üzenetéreEzt elkerülheted egy normális fejlesztőkörnyezet használatával - de ilyet akár egy szintaktika-kiemelős szövegszerkesztő is egyértelműen mutat, mint pl. a Notepad++ -, meg azzal, hogy bekapcsolod a hibajelzést fejlesztés idejéig... (pl. ezért parse errort kellett volna, hogy kapj fehér képernyő helyett, a fehér képernyő fejlesztés idején ugyebár nem túl beszédes) 
- 
			
			  Sk8erPeter nagyúr válasz  Des1gnR
							
							
								#17388
							
							üzenetére Des1gnR
							
							
								#17388
							
							üzenetéreJé, csak nem mégis van valami API-szerűség a Volánnál?  Magyar állami szervezetnél ez egészen meglepő. Magyar állami szervezetnél ez egészen meglepő. Azt sikerült leszűkíteni, hogy konkrétan milyen kulcsokra van szükség ahhoz, hogy a dolog működjön? Nekem nem volt kedvem próbálkozni, csak gyorsan indítottam egy Postmant, a honnan, hova, honnan_settlement_id, honnan_eovx, honnan_eovy és ennek hova_* változataival simán nem működik, üres objektum a válasz a JSON-változatnál. A Postmanhez telepített Postman Interceptor pedig cookie-kat is beállít, szóval annak hiánya elvileg nem para, de összesen az egésszel töltöttem kb. 3 percet, szóval annyiból nem derült ki, mi a hiány. Felraktam inkább ide a képedet (szétvágva kettőbe), mert az ilyen külső képmegosztók kényükre-kedvükre egy idő után simán törlik a képeket (pl. ha egy ideje nem nézték): 
- 
			
			  Sk8erPeter nagyúr válasz  Des1gnR
							
							
								#17386
							
							üzenetére Des1gnR
							
							
								#17386
							
							üzenetéreMost úgy érdemes nézelődnöd, hogy a webfejlesztő panel hálózati fülén bekapcsolod, hogy őrizze meg a korábbi requesteket is, így újratöltődésnél nem fog mindig "elölről" kezdődni a requestek felsorolása, hanem megőrzi a lap-újratöltődés előttieket is, így láthatod, hogy az űrlap elküldésekor milyen adatok utaztak ide-oda. 
 Pl. Chrome vagy Opera esetén a Network fülön a "Preserve log" checkboxot most érdemes bepipálni, hogy lásd az eredményeket, pl. látszik, hogy a Keresés gomb megnyomása után először a
 http://ujmenetrend.cdata.hu/uj_menetrend/volan/ajax_response_gen.php
 címre megy egy request, megnézheted, itt milyen adat utazik, majd a talalatok.php-ra kattintva is meg tudod nézni a küldött/fogadott adatokat:Ez sokat segíthet a nyomozásban. 
- 
			
			  Sk8erPeter nagyúr Önmagában az, hogy GET-metódussal vagy POST-tal küldöd az adatokat a szerver felé, az tökéletesen mindegy. Szóval nem értem, az eltérő metódus miatt miért változtatna a megoldáson. A válasz feldolgozása már érdekesebb. Valószínűleg pont olyan változóneveket várnak, ami az űrlap elemeinél látható, tehát ezt is lehet tudni. Ami viszont már valóban gondot jelenthet, az az, ha az adatok megjelenítése, az eredménytáblázat felépítése csak JavaScripttel történik, és nincs benne a törzsben az elvárható módon az adat, tehát a válasz kikotrása egyáltalán nem biztos, hogy triviális egy szarul felépített oldalnál. Egyébként vicc, hogy nincs egy normális hivatalos API-ja a Volánnak. (#17371) DS39: 
 Regexszel kiszedni a választ valami brutális overkill. Vannak rendes dokumentum-feldolgozó könyvtárak, azokat kell használni.Hogy Google Translate-hez minek csináltál ilyen regexes adatkiszedős valamit, az meg számomra rejtély, amikor van rendes API-ja (elég régóta).  
- 
			
			  Sk8erPeter nagyúr válasz  Des1gnR
							
							
								#17369
							
							üzenetére Des1gnR
							
							
								#17369
							
							üzenetéreHa Windows Phone-ra szeretnél fejleszteni, akkor miért a PHP topicban vagy?  A feladat megoldásának semmi köze nincs hozzá, a szervertől kapott választ kell feldolgoznod az általad használt nyelvvel. (A Te szempontodból teljesen mindegy, hogy a VOLÁN-nál milyen szerveroldali nyelvet használnak.) A feladat megoldásának semmi köze nincs hozzá, a szervertől kapott választ kell feldolgoznod az általad használt nyelvvel. (A Te szempontodból teljesen mindegy, hogy a VOLÁN-nál milyen szerveroldali nyelvet használnak.)
- 
			
			
- 
			
			  Sk8erPeter nagyúr válasz  CSorBA
							
							
								#17344
							
							üzenetére CSorBA
							
							
								#17344
							
							üzenetéreHa beépített megoldást is találnál rá, annak is végig kellene szaladnia a tömbön (igaz, a beépített megoldás minimálisan gyorsabb lehet, mint a saját kódod), szóval nem fogod tudni megspórolni, de nem túl bonyolult: $testArray = array( 
 0 => array(
 "id"=> "214",
 "valami"=> "asd"
 ),
 1 => array(
 "id"=> "123",
 "valami"=> "asd"
 ),
 2 => array(
 "id"=> "982",
 "valami"=> "asd"
 ),
 );$newArray = array(); 
 foreach($testArray as $currentItem){
 $newArray[$currentItem['id']] = $currentItem;
 }Eredménye: array ( 
 214 =>
 array (
 'id' => '214',
 'valami' => 'asd',
 ),
 123 =>
 array (
 'id' => '123',
 'valami' => 'asd',
 ),
 982 =>
 array (
 'id' => '982',
 'valami' => 'asd',
 ),
 )Lehetne még array_walk segítségével is, de itt pár mérés alapján sokkal lassabb tud lenni, mint a foreach, úgyhogy inkább csak érdekességként mutatom: $newArray = array(); 
 array_walk($testArray, function($item, $key){
 global $newArray;
 $newArray[$item['id']] = $item;
 });
- 
			
			  Sk8erPeter nagyúr Rakj fel kérlek egy olyan jsFiddle-példát, amit én is linkeltem neked, bővítsd az enyémet, vagy valami (aztán mentsd is el, és linkeld be ide), hogy látható legyen, a saját kódodnál mi is a gond, és milyen opciókat szeretnél pluszban betenni, mert az általam korábban mutatott kód működik. Amúgy ez már sokkal inkább a JavaScript topicba hajlik, folytathatjuk ott is.  
- 
			
			  Sk8erPeter nagyúr válasz  Sk8erPeter
							
							
								#17316
							
							üzenetére Sk8erPeter
							
							
								#17316
							
							üzenetéreBővítettem még tök random adatokkal, és itt is teljesen jól jelenik meg a dátum: 
 http://jsfiddle.net/8vkse4bu/1/
- 
			
			  Sk8erPeter nagyúr Itt úgy tűnik, hogy maga a dátum jól jelenik meg, felraktam a példádat: 
 http://jsfiddle.net/8vkse4bu/
 Több adattal nem próbáltam ki, segítene, ha felraknál több adatot is mondjuk pastebinre, vagy ugyanígy bedobnád jsFiddle-példán, ami nálad rosszul jelenik meg.Amúgy az egyik hivatalos példában is ilyen bénán jelenik meg a dátum, ahogy említetted: 
 http://jsfiddle.net/gh/get/jquery/1.7.2/highslide-software/highcharts.com/tree/master/samples/stock/rangeselector/input-format/
- 
			
			  Sk8erPeter nagyúr Mi a hozzá tartozó kliensoldali kódod? 
 Egyébként azt nézem, hogy az összes demóban dátumnál alapértelmezetten az 1970. január 1. óta eltelt milliszekundumok számát használják fel (pl. ennél a demónál, ebben a fájlban), szóval valszeg be kellene explicite állítanod, hogy te milyen dátumformátumot használsz, VAGY tök felesleges az adatbázis-oldali átalakításod (inkább utóbbira tippelek).
 Szóval milyen JavaScript-kódot használsz hozzá?
 Ja, és a dátumot hol, hogyan szeretnéd megjeleníteni?Szerk.: 
 http://api.highcharts.com/highstock#rangeSelector.inputDateFormat
 Itt azt írja:
 "inputDateFormat: String
 The date format in the input boxes when not selected for editing. Defaults to %b %e, %Y. Defaults to %b %e %Y,."
 Hogy most akkor melyik, azt nem tudom. Érdekes, hogy két formátum van. Érdekes, hogy két formátum van.Még ezek lehetnek érdekesek: 
 inputDateParser: Function
 A custom callback function to parse values entered in the input boxes and return a valid JavaScript time as milliseconds since 1970.inputEditDateFormat: String 
 The date format in the input boxes when they are selected for editing. This must be a format that is recognized by JavaScript Date.parse. Defaults to %Y-%m-%d.
- 
			
			  Sk8erPeter nagyúr Megnézted a fogadott JSON-adatokat, az alapján a kapott adatok helyesek? Kliensoldalon hogy jeleníted meg a chartot? Nekem kicsit furcsa, hogy behánysz össze nem illő adatokat egymás mellé, pl. dátumot a valamilyen downstream/upstream csatornák adataival, persze nem is ismerem a library API-ját, de mielőtt utánanéznék, nem ártana legalább egy kis példakimenet (a kapott JSON-adatok legalább egy része, hogy el tudjuk képzelni, milyen adatokat is akarsz megjeleníteni). Amúgy angolul a data már eleve többesszám, nem kell odatenni még egy s-t is a végére, hogy az legyen...  
- 
			
			  Sk8erPeter nagyúr Things you must know about PHP7 --> hát ez a "spaceship operator" rettentő értelmes: 
 https://wiki.php.net/rfc/combined-comparison-operatorTehát most már tudok olyat csinálni, hogy 
 if( ($a <=> $b) === -1 || ($a <=> $b) === 0) { ... }Hát csodálatos.  
- 
			
			  Sk8erPeter nagyúr válasz  Joci93
							
							
								#17285
							
							üzenetére Joci93
							
							
								#17285
							
							üzenetérecidalainnal értek egyet, van olyan feladat, ami eleve értelmetlen, így nem biztos, hogy megéri elvállalni, szépen türelmesen el kell magyarázni a megrendelőnek, hogy baromságot akar. Aztán hátha meggondolja magát, vagy tovább kell állni (már ha van választási lehetőség). Nem akar adatbázist valami degenerált indokból, de azért valahol mégis, meg szeretne query-ket is írni kézzel, amit ja, akár phpMyAdminban is megtehetne, ha ez a kattanása, de nem, ő a spanyolviaszt akarja felfedezni. 
 De ha már muszáj elvállalnod, és valahova menteni kell, illetve fel is kell tudni dolgozni a tárolt adatot, akkor a txt-t vagy bármi behányt szöveget azonnal felejtsd el, valami normálisan és hatékonyan feldolgozható formátumban mentsd el, legyen az JSON, XML, stb. Ha már az SQLite is szóba kerülhet, mint lokális, fájlba írós adatbázis, akkor már nem igazán értem, miért ne lehetne egy tisztességes adatbázis (nem lebecsülve az SQLite-ot, de nagyobb adatmennyiség esetén már nyilván nem ez a hatékony megoldás), onnantól már csak egy lépés.
 Mi is pontosan az indoka a megrendelőnek arra, hogy nem lehet adatbázist használni?Amúgy ha már SQL parsert kell használnod, akkor nehogy elkezdd kézzel összetákolni, mert rohadt nagy szopás tud lenni egy parser, inkább használj fel egy kész könyvtárat: 
 https://code.google.com/p/php-sql-parser/
 http://stackoverflow.com/questions/283087/php-mysql-sql-parser-insert-and-update/283115#283115Szerk.: 
 (#17290) PumpkinSeed: pont megelőztél. Amúgy egyetértek. Amúgy egyetértek.
- 
			
			  Sk8erPeter nagyúr válasz  DNReNTi
							
							
								#17252
							
							üzenetére DNReNTi
							
							
								#17252
							
							üzenetéreVaze.  Egyébként a favicon.ico fájl lekérése a gyökérből (amennyiben pl. nincs beállítva favicon egyéb módon) böngészőfüggő, van, amelyik cseszegeti érte a szervert, van, amelyik nem. Szóval ez esetben, tehát most, hogy kiderült, hogy többek közt a favicon.ico-ra irányuló requestek is lefuttatták az index.php-dben lévő adatbázis-tömködést, nem meglepő, hogy több beillesztés is történt, és hogy ez böngészőfüggő volt. Egyébként a favicon.ico fájl lekérése a gyökérből (amennyiben pl. nincs beállítva favicon egyéb módon) böngészőfüggő, van, amelyik cseszegeti érte a szervert, van, amelyik nem. Szóval ez esetben, tehát most, hogy kiderült, hogy többek közt a favicon.ico-ra irányuló requestek is lefuttatták az index.php-dben lévő adatbázis-tömködést, nem meglepő, hogy több beillesztés is történt, és hogy ez böngészőfüggő volt.
- 
			
			  Sk8erPeter nagyúr válasz  DNReNTi
							
							
								#17239
							
							üzenetére DNReNTi
							
							
								#17239
							
							üzenetéreMeg tudod mutatni a .htaccess vonatkozó részletét, ami a hibát okozta? Hogy mitől lehet böngészőfüggő, de ez csak tippelgetés: ha ez a teszt az adatbázisba való beillesztésre csak simán be volt dobva egy akármilyen oldalra, tehát minden oldalbetöltéskor lefutott, akkor lehet akár a böngészőnek egy előtöltési mechanizmusa, tehát pl. amint beírtad a megnyitandó URL-t, máris elindulhatott egy előtöltés a teljesítmény növelése érdekében, pl. Chrome-nál van ilyen opció: 
 https://support.google.com/chrome/answer/1385029?hl=hu-HU
 "Hálózati műveletek előrejelzése az oldalbetöltések teljesítményének növelése érdekében"
 vagy angolul "Predict network actions to improve page load performance”
 Ha minden egyes kérést figyelgetsz, akkor látható, hogy már abban a pillanatban elindul egy request, amikor csak bepötyögted az URL-t, vagy amint kiegészítette autocomplete segítségével a böngésző - tehát még meg sem nyomtad az Entert, máris megpróbál egy részletet előtölteni gyorsítótárba, hogy aztán amikor ténylegesen megnyitod, akkor gyorsabban betöltsön az oldal.
 De most ez csak ötlet, a (század)másodpercre pontos adatokból, meg egyéb infókból lenne kideríthető, hogy pont ez lehetett-e az oka, vagy valami más.
- 
			
			  Sk8erPeter nagyúr válasz  Des1gnR
							
							
								#17232
							
							üzenetére Des1gnR
							
							
								#17232
							
							üzenetéreÁltalános tanácsot nem lehet adni, mivel minden webshop más lehet, de mindenesetre az összes termékoldal összes HTML-kódját lementeni nyilván értelmetlen, ebből ki kell bányászni első letöltés után a szükséges adatokat, aztán eldobni a HTML-kimenetet. Vagy DOMDocument osztállyal, vagy erre/másra építő library-vel, mindenesetre valamilyen DOM-feldolgozó módszerrel. 
- 
			
			  Sk8erPeter nagyúr válasz  PumpkinSeed
							
							
								#17229
							
							üzenetére PumpkinSeed
							
							
								#17229
							
							üzenetére"Igen tudom, bár javasoltam egy alternatív megoldást a problémára." 
 Ami hibás. Az str_split()-nek az egész tömböt adod át, nem indexelted. Egyébként van foreach-ciklus, ami ennél sokkal szebb kódot eredményez, és az ilyen jellegű indexeléssel sem kell foglalkoznod. Az str_split()-nek az egész tömböt adod át, nem indexelted. Egyébként van foreach-ciklus, ami ennél sokkal szebb kódot eredményez, és az ilyen jellegű indexeléssel sem kell foglalkoznod."Amúgy nem lehetséges, hogy néha az ilyen alternatív megoldás gyorsabb? Tegyük fel, hogy a kód ugyan olyanugyanolyan hatékonysággal van megírva mint a függvényben, de mivel itt függvényhívás nélkül fut le, ezért valamivel gyorsabb."
 Nem valószínű, mivel a PHP könyvtári függvényeit C-ben írják, aztán optimalizált kód lesz belőle a buildelés során, nagy eséllyel ez gyorsabban fog működni, mint a Te kódod, amit már PHP-ben írsz (a fenti kódodnál meg aztán végképp gyorsabban fog működni... ). Persze ettől még a különbséget nem biztos, hogy megérzed. (Na meg el lehet képzelni rossz implementációt is még a beépített függvényeknél is.) ). Persze ettől még a különbséget nem biztos, hogy megérzed. (Na meg el lehet képzelni rossz implementációt is még a beépített függvényeknél is.)
 Ha arra vagy kíváncsi, hogy azonos környezetben, azonos feltételekkel, ugyanolyan hatékonysággal van valóban megírva a kód, de még valaki hozzátesz egy függvényhívást is, akkor melyik lesz a győztes, akkor igen, jól sejted, ELMÉLETBEN az, amelyik nem teszi hozzá a függvényhívás overheadjét - a gyakorlat viszont megint más, mert ez már olyan minimális különbség, hogy nem fogod tudni mérni sem, hogy melyik a gyorsabb, sőt, aktuális szerverterheltségtől függően össze-vissza fog változni a különbség.
 Szóval azon nem éri meg agyalni, hogy inkább a könyvtári függvényt használod, vagy feltalálod a spanyolviaszt.
 Azon, hogy milyen overheadet teszel hozzá egy-egy függvényhívással, akkor éri meg agyalni, amikor pl. egy helyen ugyanazt az értéket kéred le többször is, tök feleslegesen. Rengetegen elkövetik azt a hibát, hogy egy értéket/referenciát/akármit eltárolhatnának egy változóban, és később felhasználhatnák, de ugyanazt a kódot leírják többször is (erre is vonatkozik a DRY (Don't Repeat Yourself) elv).
 Na, kezdek elkalandozni, remélem, megválaszoltam a kérdésedet. 
- 
			
			  Sk8erPeter nagyúr válasz  PumpkinSeed
							
							
								#17225
							
							üzenetére PumpkinSeed
							
							
								#17225
							
							üzenetéreJa, strpos(), strstr() és társai, vagy multibyte stringeknél ezek megfelelői, tehát mb_strpos(), mb_strstr(), stb... Amúgy ne vedd sértésnek, de azért mielőtt olyanokat állítasz, hogy "erre szerintem nincs beépített függvény", miközben ez eléggé alapvető elvárás, hogy beépített könyvtári függvény/metódus legyen egy stringben keresős módszer, nem árt utánanézni...  
- 
			
			  Sk8erPeter nagyúr válasz  Speeedfire
							
							
								#17222
							
							üzenetére Speeedfire
							
							
								#17222
							
							üzenetéreNem tiszta ennyiből a feladat, de akkor mondjuk annak a mindig meghívogatott metódusnak legyen egy default értékkel ellátott második paramétere is, ellenőrizd ezt a paramétert a metódus törzsében, és ha ez egy egyéb értékkel egyenlő, akkor csináld meg azt a másik esetet. Persze csak ha ez nem vezet gányoláshoz, de ennyi infóból ezt lehetett kihozni kerülő megoldásként, amivel még nincs is nagy para. (#17223) Joci93: 
 Ez stringek tömbje? Tehát egy tömb, amiben több string is található?
 Menj végig a tömbelemeken, és stringtartalom-keresős függvényekkel nézd meg, benne van-e az általad keresett string az aktuális elemben...
- 
			
			  Sk8erPeter nagyúr válasz  Speeedfire
							
							
								#17219
							
							üzenetére Speeedfire
							
							
								#17219
							
							üzenetéreEngem is nagyon érdekelne, hogy mit akarsz csinálni, ami miatt ilyen felmerült.  És hogy miért nem más módszerrel csinálod - amúgy ha ez nem volt tiszta egyből, hogy ilyet konstruktorból nyilvánvalóan nem lehet, akkor nem ártana legalább egyszer szépen végigdebuggolnod egy példány létrehozásának folyamatát, azt, hogy mikor melyik metódusba ugrik bele, és így tovább, meg átnézni az OOP-t jobban, mert itt valami alapok nagyon hiányoznak. És hogy miért nem más módszerrel csinálod - amúgy ha ez nem volt tiszta egyből, hogy ilyet konstruktorból nyilvánvalóan nem lehet, akkor nem ártana legalább egyszer szépen végigdebuggolnod egy példány létrehozásának folyamatát, azt, hogy mikor melyik metódusba ugrik bele, és így tovább, meg átnézni az OOP-t jobban, mert itt valami alapok nagyon hiányoznak. 
Új hozzászólás Aktív témák
- Black Friday november 29. / Cyber Monday december 2.
- TCL LCD és LED TV-k
- Xiaomi 15 - kicsi telefon nagy energiával
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Munkahelyek tízezreit szünteti meg az AI
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Xiaomi 15T Pro - a téma nincs lezárva
- One otthoni szolgáltatások (TV, internet, telefon)
- Milyen egeret válasszak?
- Genshin Impact (PC, PS4, Android, iOS)
- További aktív témák...
- HIBÁTLAN iPhone 12 mini 128GB Purple -1 ÉV GARANCIA - Kártyafüggetlen, MS3392, 94% Akkumulátor
- 13-14" Új és használt laptopok , üzletitől a gamerig , kedvező áron. Garanciával !
- RÉSZLETRE , KAMATMENTES , BANKMENTES Panasonic TOUGHBOOK FZ-55 MK3 FZ-55G6601BG Notebook
- BESZÁMÍTÁS! Gigabyte H610M i5 12400F 32GB DDR4 512GB SSD RTX 3070 8GB Zalman Z1 PLUS A-Data 750W
- Samsung Galaxy A32 5G 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: NetGo.hu Kft.
Város: Gödöllő
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
 
								 
							
 
							 
							
 
							 "
" 
							 
							 
							 
							 
							 
							 
							
 
							![;]](http://cdn.rios.hu/dl/s/v1.gif) ), látni kéne a plugined kódjának többi részét, hátha abból összeállna a kép, mert az általad berakott kódrészletek és a screenshot nem sokat segít.
), látni kéne a plugined kódjának többi részét, hátha abból összeállna a kép, mert az általad berakott kódrészletek és a screenshot nem sokat segít. 
							 
							 
							 
							 
							 
							 Remélem, csak Te értettél félre valamit, és nem ilyen retardált feladatot kaptál.
 Remélem, csak Te értettél félre valamit, és nem ilyen retardált feladatot kaptál. (Még egy sima echózás is jobb lenne még exit előtt, mint egy tök üres lap hiba esetén, ami akármi mástól is lehetne (pl. fatal error elrejtett hibaüzenetekkel), kezdő jól beszophatja az ilyeneket, amikor elírja mondjuk a query stringet, vagy ilyesmi.)
 (Még egy sima echózás is jobb lenne még exit előtt, mint egy tök üres lap hiba esetén, ami akármi mástól is lehetne (pl. fatal error elrejtett hibaüzenetekkel), kezdő jól beszophatja az ilyeneket, amikor elírja mondjuk a query stringet, vagy ilyesmi.) 
							 
							 
							 
							 
							 
							 
							

 
							 
							 
							


 
							 
							 
							 
							

