Új hozzászólás Aktív témák
-
#16445
Sk8erPeter
nagyúr
Speeedfire
#16444
Sk8erPeter
nagyúr
válasz
Speeedfire
#16444
üzenetére
Nagyon szép idézet lett így a végére.
-
#16443
Sk8erPeter
nagyúr
Speeedfire
#16442
Sk8erPeter
nagyúr
válasz
Speeedfire
#16442
üzenetére
Lépj már feljebb legalább a nagycsoportos óvodásokhoz.
![;]](//cdn.rios.hu/dl/s/v1.gif)
"Erre csak azt tudom írni, hogy minden nyelvben vannak pozitív és negatív dolgok."
---- Speeedfire Coelho "Nem lehet azt kimondani, hogy márpedig az xy a legjobb."
Még szerencse, hogy senki nem beszélt arról, mi a legjobb."»» Az nem túl erős érv a nyelv jósága mellett, hogy a weboldalak nagy része PHP-ben íródott.
Márpedig ez egy igen erős indok, szerintem."
Ja értem, tehát attól lesz jó valami, ha sokan csinálják.
(Mr. Bustát is sokan szeretik - leginkább a kiskamasz korosztályból -, aztán mégis szar zenét csinál. A celeblóf@sz és valóságshow műsorokat is sokan bambulják, de attól nem lesz jó. Oravecz CoelhoNóra idézeteit is rengetegen zabálják, pedig röhejesen közhelyesek. Még szerencse, hogy a PHP mindezeknél tényleg sokkal jobb.
(Csak hogy félreértés ne essék, hogy összevethető lenne. )) -
#16439
Sk8erPeter
nagyúr
honda 1993
#16438
Sk8erPeter
nagyúr
válasz
honda 1993
#16438
üzenetére
Igen, természetesen PHP-kódot HTML-kódba is lehet ágyazni (nyilván), meg lehet egy csupa PHP-kódból álló fájlod is, amiben egy sor HTML-kód nincs... (és egyébként a záró ?> opcionális, csupa PHP-kódból álló fájlnál nem is érdemes használni egyáltalán) Az viszont nem mindegy, milyen a fájl kiterjesztése, mert ahhoz, hogy például a .html vagy más kiterjesztésű fájlokban is az elvártak szerint lefusson a PHP-kódod, megfelelően konfigurálni kellene a szervert (ami esetedben az Apache, de lehetne ez IIS és más is, tök mindegy, a lényeg, hogy megfelelően kiszolgálja a tartalmat). Alapértelmezetten nem ez a helyzet, .html-kiterjesztésű fájlnál alapból nem értelmeződik a PHP-kód, tehát ha egy .html-kiterjesztésű fájlba beleírsz egy PHP-kódot, akkor azt látni fogod kliensoldalon a forráskódban, amikor megnyitod az oldalt. (Az meg nem jó.
) -
#16437
Sk8erPeter
nagyúr
honda 1993
#16434
Sk8erPeter
nagyúr
válasz
honda 1993
#16434
üzenetére
Hogy mi van?!
Tehát szerinted most az számít, hogy a fájlt miben hoztad létre, és konkrétan a PHP Stormnak melyik beállításai alatt? Teljesen mindegy. Akár Notepadben is létrehozhattad volna a .php-kiterjesztésű fájlt, amíg a kód megfelelő benne. Nagyon valószínű, hogy valami mást csináltál, amitől helyrejött, mondjuk úgy tűnik, már sosem fogunk rájönni, mi volt az."A tanacsotokat kovetve letrehoztam egy uj HTML fajlt, aminek .php kiterjesztest irtam a vegere."
Igazából nem értem, minek emelted ki a két félkövérített szót. Ha a fejlesztőkörnyezetben mondjuk véletlenül vagy direkt stylesheetet hozol létre (CSS-fájlt), és utána a fájlkezelőben megváltoztatod ezt a fájlt úgy, hogy a .css-kiterjesztés helyett .php-t írsz a végére, majd beleírsz ebbe a fájlba egy PHP-kódot (persze a <?php azért minimum legyen benne), az is tökéletesen kell, hogy működjön."(Es itt megjegyeznem, hogy direkt kerdeztem hogy ha html fajlt nyitok, akkor miert kell .php-t irni a vegere, es miert nem jo ha php fajlt nyitok, es annak a vegere irom be a .php-t)"
Heh? Erre lásd előbbi bekezdésem."Tehat en most ugy hiszem, hogy amikor megkerdeztem hogy nem -e hulyeseg az hogy a megnyitott html fajlt mentem el .php kiterjesztessel, akkor jogos volt a gyanum, miszerint igen is hulyeseg volt"
Sajnos a gyanúd alaptalan.
-
#16436
Sk8erPeter
nagyúr
Speeedfire
#16422
Sk8erPeter
nagyúr
válasz
Speeedfire
#16422
üzenetére
"Semmi extra, szívből jött.
Néha unalmas, hogy mindenki lehúzza a php-t, holott a legtöbb weblap ez fut. Vannak hibái, de nem szabad elfelejteni, hogy folyamatosan fejlesztik."
Ja értem, tehát szerinted egy szakmai véleményre személyeskedéssel válaszolni pont jó reakció...
De örülök, ha ezzel hozzájárulhattam a boldogságodhoz.
Az nem túl erős érv a nyelv jósága mellett, hogy a weboldalak nagy része PHP-ben íródott. Minden jöttment hostingcég is kínál PHP-futtatási lehetőséget olcsón vagy akár ingyen (egy domainnévért cserébe, bár ASP.NET-nél is vannak akár ingyenes lehetőségek, persze korlátokkal), a PHP ingyenes, open source, relatíve könnyű nekiesni a fejlesztésnek a segítségével, a felkapottsága további népszerűséget generált, PHP-fejlesztőből pedig iszonyat sok van, csak a mennyiség ugye nem mindig minőség. Természetesen sok előnye van a PHP-nek, pl. pont a népszerűségéből következő nagyon komoly támogatottsága. Viszont a gyengén típusossága és a nyelv helyenkénti koncepcionális hibái hátrányosak és idegesítőek tudnak lenni. Tudod, hogy én is fejlesztgetek benne, de ettől még látom a hibáit (és szerintem semmiben nem jó az elvakultság). Ja, de tudom, most akkor az erre a szerinted jó reakció, hogy húzzak el, nem fogsz hiányolni. -
#16420
Sk8erPeter
nagyúr
Speeedfire
#16419
Sk8erPeter
nagyúr
válasz
Speeedfire
#16419
üzenetére
Amire reagáltál, abban mondjuk én a webszerver megírására gondoltam, nem a kész progi elindítására, mármint ez csak azért volt érdekes, mert nem valami mágia van a hordozható webszerver mögött sem. De végül is ez a beépített webszerver is ezt igazolja.
Mi ez a túláradó jóindulat?
Úgy örülök, hogy hosszú idő után megjelentél, hogy gyorsan lecsapj erre a lehetőségre... (#16418) Zedz :
Áh, hosszú, bevallom, lusta vagyok összeszedni a szempontokat, volt is már sok szó a topicban a nyelv furcsaságairól, a gyengén típusosságából és magának a nyelvnek a hibáiból vagy rossz koncepcióiból sok kényelmetlenség adódik. De az tény, hogy nekiesni magának a fejlesztésnek pofonegyszerű a segítségével, ez előnye is és hátránya is egyben. -
#16416
Sk8erPeter
nagyúr
Speeedfire
#16415
Sk8erPeter
nagyúr
válasz
Speeedfire
#16415
üzenetére
Hát biztos, én abban tuti nem csinálnék.
(Mondjuk az is igaz, hogy minél többet tevékenykedik az ember tisztességes programozási nyelvekben, annál kevésbé vágyik pl. PHP-ra. ) Amúgy van ilyen is:
http://php.net/manual/en/features.commandline.webserver.php
"As of PHP 5.4.0, the CLI SAPI provides a built-in web server." -
#16414
Sk8erPeter
nagyúr
DNReNTi
#16412
Sk8erPeter
nagyúr
válasz
DNReNTi
#16412
üzenetére
"hogy fut szolgaltataskent?"
Úgy, hogy nem szolgáltatásként fut...
Egy nagyon egyszerű webszervert például Javában vagy C#-ban is össze lehet dobni elég rövid idő alatt. (Most azért írtam pont ezt a két nyelvet, mert ezekhez aztán tényleg nem kell különösen megerőltetnie magát az embernek, hogy összehozza, meg nem szükséges n+1 library-t keresgélni. Meg azért, mert Javában már szórakoztam ilyennel.) Szokásos alkalmazásként fut (ergo nem szolgáltatásként, ami felhasználói belépéstől függetlenül is tudna futni), fogadja és feldolgozza a kéréseket.
Most ez csak azért érdekes, mert azért nem akkora mágia, hogy hogyan tud portable módban futkorászni.Hogy érted, hogy hogy kezel aliasokat? URL aliasokra gondolsz? Vagy a VirtualHostokra?
============
(#16410) PumpkinSeed :
Használtam már XAMPP-ot, nem ennyire szenvedős...============
(#16407) honda 1993 :
Az ilyen szintű türelmetlenség valóban nem nagy erény egy fejlesztőnél. Már feltettem a költői kérdést a másik topicban, mit csinálsz majd, amikor ennél sokkal komplexebb problémákat kell megoldani, meg ennél milliószor bonyolultabb dokumentációkat kell olvasni,hogy megértsd valaminek a működését, és hogy tudj is fejleszteni hozzá? (Mondjuk egy keretrendszer, egy API, egy library vagy akármicsoda.) -
#16406
Sk8erPeter
nagyúr
Peter Kiss
#16400
Sk8erPeter
nagyúr
válasz
Peter Kiss
#16400
üzenetére
Valszeg jól sejted.
(#16394) DS39 :
Teljesen mindegy, mindkettő kb. ugyanolyan, és nem kellene, hogy ekkora gondot jelentsen a beüzemelése. -
#16393
Sk8erPeter
nagyúr
honda 1993
#16392
Sk8erPeter
nagyúr
válasz
honda 1993
#16392
üzenetére
Azért a PHP-t is tedd fel...
Meg a phpMyAdmin is kelleni fog.
Vicces, hogy mondják, hogy a XAMPP hű de egyszerű, ahhoz képest egy IIS-nél hármat kattintottam, és volt egy jól működő webszerverem, amit aztán szintén pár kattintással könnyen át tudok konfigurálni. Bár elvileg normális esetben a XAMPP alapvető működéséhez is ennyi kéne az installerrel, de elég gyűlöletes az Apache konfigfájljait bűvölni. -
#16382
Sk8erPeter
nagyúr
honda 1993
#16381
Sk8erPeter
nagyúr
válasz
honda 1993
#16381
üzenetére
Az a baj, hogy úgy, hogy nem látjuk, mi van az Apache vonatkozó konfigurációs fájljaiban (például httpd.conf és az egyes VirtualHostokra vonatkozó fájlok), nehéz bármit is mondani. Ha gondolod, tedd fel ezeket pastebinre, hátha úgy egyből látjuk, mi a gond.
-
#16380
Sk8erPeter
nagyúr
honda 1993
#16376
Sk8erPeter
nagyúr
válasz
honda 1993
#16376
üzenetére
A 404-es hiba azt jelenti, hogy nem találja az elemet, amit szeretnél elérni. Akkor tehát konkrétan hogyan is próbálkozol? Mert leírtad a hibaüzenetet, csak azt nem, hogy egész pontosan milyen címen akarod elérni a kívánt tartalmat. Úgy próbálod, hogy http://localhost/valami/index.php?
(#16372) tothjozsi96 :
Nincs mit, de amúgy pont ezzel kezdtem még kb. a téma elején, hogy eleve feltöltésnél alakítsd át a szöveget, és megvagy... (Mivel akkor nem kell minden egyes kiolvasásnál azt az óriási mennyiségű preg_replace-rettenetet végrehajtani.) -
#16370
Sk8erPeter
nagyúr
honda 1993
#16369
Sk8erPeter
nagyúr
válasz
honda 1993
#16369
üzenetére
Ha a szerveren nincs külön beállítva, hogy a .html-kiterjesztésű fájlok esetén is menjen át a kód a PHP-értelmezőn, akkor nyers formában fogod látni a PHP-kódjaidat.
Szóval nevezd csak át szépen .php kiterjesztésűre a fájlodat, így legalább a PHP-kódjaid is fognak működni.
Nyilván a kolléga csak a helyzet megfelelő kontextusában mondta azt, hogy nevezd át a megfelelő kiterjesztésűre azt a fájlt... Biztos, hogy nem úgy értette, ahogy te most. Szerk. után:
"Vagy lehet hogy pont az ellenkezojet mondtatok, es en emlekszem rosszul?"
Az esélyesebb. -
#16367
Sk8erPeter
nagyúr
PumpkinSeed
#16358
Sk8erPeter
nagyúr
válasz
PumpkinSeed
#16358
üzenetére
Nézd meg, a Gmailnél milyen hosszúra van állítva a session cookie-k lejárata.
Ott elég ritkán kell belépegetni, miután egyszer megtetted. Persze lehet, hogy ők már a másik véglet.(#16338) tothjozsi96 :
Ez a téma eléggé abbamaradt, mert a felvetéseimre érdemben nem reagáltál.(#16339) Athlon64+ :
Az első felét nem értettem, mire reagáltad, mert az előzőben arról volt szó, hogy egyszerűen lehagyta az execute-ot, és erre nem figyelmeztette az IDE - Te pedig arra hivatkoztál, hogy biztos inicializálatlan változója volt, és fos IDE-t használ, pedig a változó inicializálva van, és normális IDE-t használ, csak egy metódushívás lemaradt. Szívás, de előfordulhat bárkivel, még veled is, max. nem PDO-val."database generated kulcsot sem képes minden esetben kezelni"
Asszem ezzel én is találkoztam.
Hát amúgy ja, egyetértek, hogy sok tekintetben tákolmány feelingje van (még ha nem is találkoztam annyi problémával, mint Te), mint úgy általában a PHP-nak. -
#16337
Sk8erPeter
nagyúr
PumpkinSeed
#16336
Sk8erPeter
nagyúr
válasz
PumpkinSeed
#16336
üzenetére
He? Ne már. Tessék:
http://php.net/manual/en/function.urldecode.php
"urldecode — Decodes URL-encoded string
string urldecode ( string $str )
Decodes any %## encoding in the given string. Plus symbols ('+') are decoded to a space character.[...]
WARNING
The superglobals $_GET and $_REQUEST are already decoded. Using urldecode() on an element in $_GET or $_REQUEST could have unexpected and dangerous results."Nincs szükséged semmiféle manuális replace-elgetésekre...
(#16335): Hogy jön ide a reguláris kifejezés?
Kb. köze nincs a témához. Ez egy URL-encoded string, amiről beszélsz. -
#16331
Sk8erPeter
nagyúr
DNReNTi
#16330
-
#16329
Sk8erPeter
nagyúr
Peter Kiss
#16328
Sk8erPeter
nagyúr
válasz
Peter Kiss
#16328
üzenetére
Hát Te biztos érted, mire gondolsz.
Itt most elvileg pont az volt az érdekes, hogy igazából a lényeget hagyta le (nem hajtotta végre); az IDE mégsem figyelmeztette semmire, mert a változó egyébként inicializálva volt, gondolom volt bindParam/bindValue is, blabla, csak a vége (execute) úgy, ahogy van, lemaradt. Szóval valóban nem ellenőrizte annak a visszatérési értékét, amit nem is írt le."PDO-hoz a büdös életben nem nyúlok többet"
Magyarázat? -
#16327
Sk8erPeter
nagyúr
tothjozsi96
#16326
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16326
üzenetére
Mi az, hogy akkor mi van?
Mi köze a kettőnek egymáshoz? 
- egyrészt itt írtam már, hogy amúgy is érdemes a tisztításra valamilyen kész library-t használnod (mert most nem tisztogatod a feltöltött üzeneteket egyáltalán? Mert az ugyebár nem túl jó.)
- másrészt hogy jönnek ide a <script>-tagekben elhelyezett rondaságok, XSS ahhoz, hogy te :), :D és ehhez hasonló emoticonnak megfelelő karaktersorozatokat keresgélsz, majd átalakítod őket <img>-tagekké?
- harmadrészt amúgy is whitelist-jelleggel kellene csupán engedned bizonyos limitált tageket (vagy egyáltalán nem), aszerint szűrni (ez kapcsolódik az első ponthoz), na meg létezik strip_tags függvény is, aminek pont ilyen whitelistet megadhatsz (első, legegyszerűbb megközelítés, de mondom, a tisztításra amúgy is illene használnod valamilyen library-t (pl. HTML Purifier és hasonlók)). -
#16325
Sk8erPeter
nagyúr
tothjozsi96
#16323
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16323
üzenetére
Ezt már korábban írtam, de az, hogy minden egyes megjelenítésnél minden egyes üzeneten végigmész, és még azonbelül is iszonyatosan sok reguláris kifejezésre keresgélsz, teljesen érthető, hogy rohadt lassúvá teszi az egészet. A reguláris kifejezés keresgélése amúgy sem egy gyors állat. Lehet egyrészt egyszerűbbé is tenni magát a reguláris kifejezést is (bár elég bonyolult egyszerűvé tenni
), meg lehet csökkenteni is a keresendő kifejezések számát (nem biztos, hogy érdemes 314 emoticon használatát lehetővé tenni), illetve lehet javítani a használt módszeren is, erről is írtam már, hogy egyből feltöltéskor alakítanád át a smiley-kat <img>-tagekké, eleve úgy mentenéd el az üzenetet, így azért jópár lépést megspórolsz, nem kell állandóan, minden megjelenítésnél újból és újból kikeresgélni ezeket. Ez utóbbira még mindig nem reagáltál, pedig már legalább harmadjára írom le. Vagy legalább akkor írd le, az miért nem jó megoldás. (Lehet olyan eset simán, csak legalább tudjam, hogy eljutott hozzád az információ. ) -
#16324
Sk8erPeter
nagyúr
DNReNTi
#16316
Sk8erPeter
nagyúr
válasz
DNReNTi
#16316
üzenetére
"valamint számtalan var_dump() után, rájössz"
Meg kellene szokni, hogy a var_dump() csak egy olyan tool, amit akkor érdemes csak használni, ha egyébként nem áll rendelkezésedre NORMÁLIS fejlesztőkörnyezet. Ott van az Xdebug, amit pont arra találtak ki, hogy PHP-kódokat lehessen debuggolni (és profilozni), a legtöbb népszerű IDE-vel egyszerű a belövése, sőt, a honlapján van egy olyan oldal is, ami a phpinfo-d kimenete alapján kideríti, neked pontosan melyik verzióra is van szükséged belőle:
http://xdebug.org/wizard.php
Komolyan, jótanács, hogy tanuld meg a rendes debuggolást minden programozási nyelvnél, ahol lehetséges, PHP-nál is. Bár a PHP-nál sajnos a legtöbb helyen ilyen béna var_dumpolást (/var_export, stb.) látni "debuggolás" címén, az nem debuggolás, itt is lehet az IDE-ben breakpointokat elhelyezni, az aktuális sornál megnézni a változó tartalmát az IDE-ben a watch-résznél, és így tovább; miután egyszer kellő időt eltöltöttél a használatával, nagyon durván fel tudja gyorsítani az időt, és segítségével elfelejtheted az ilyen kódokban itt-ott elhelyezett, akár véletlenül benthagyott kiíratásokat, bénázásokat. Tényleg megéri a befektetett időt (és ez minden programozási nyelvre igaz, hogy meg kell tanulni benne debuggolni, amennyiben lehetséges tisztességes módon is).(#16317) Athlon64+ :
Speciel egy inicializált változóról van szó, nem tudom, melyik IDE hívja fel a figyelmet rá, hogy elfelejtetted meghívni rajta az execute-ot... Persze lehet, hogy beállítható ez is. -
#16322
Sk8erPeter
nagyúr
tothjozsi96
#16315
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16315
üzenetére
Van magyarra fordított PHP-doksi is:
http://szabilinux.hu/php/function.preg-quote.htmlAz a lényeg, hogy ha a stringed tartalmazhat olyan karaktereket (mint a dollárjel ($), csillag (*), pont (.), stb.), amelyek egy reguláris kifejezésben speciális jelentéssel bíró karakterként értelmezhetők lennének, akkor előtte ezeket egy backslash-sel (\) escape-elni kell (hogy ne rontson el pl. egy egyébként jól megírt reguláris kifejezést, hogy valamilyen substringben vannak "félreértelmezhető" karakterek); pont ezt csinálja ez a függvény.
Remélem, így nagyjából érthető.(#16311) :
Nem tudok ilyen egész konkrét doksit, de Dunát lehet velük rekeszteni, én annak idején össze-vissza gugliztam mindenféle regexpekkel kapcsolatos olvasmányért, és jó sok gyakorlás után ráállt az agyam. Tényleg nem egy kétperces valami, amit csak úgy megért az ember, rá kell állítani magadat, de ez nyilván nem csak úgy megy, ha sokat olvasgatsz (nyilván az se árt), hanem ha ki is próbálgatod egyesével a különböző eseteket. Voltak különböző feladatok, amikhez nagy hasznát tudtam venni a regexpeknek, így jó gyakorlati feladatok voltak.Nagyon sokat segít egyébként a RegexBuddy (elmagyarázza a reguláris kifejezést, nagyon hasznos!), a RegExr, Regex101, RegexPal, stb.
-
#16306
Sk8erPeter
nagyúr
Des1gnR
#16304
Sk8erPeter
nagyúr
válasz
Des1gnR
#16304
üzenetére
http://php.net/manual/en/function.is-a.php
5.3.9 Added allow_string parameter
5.3.0 This function is no longer deprecated, and will therefore no longer throw E_STRICT warnings.
5.0.0 This function became deprecated in favour of the instanceof operator. Calling this function will result in an E_STRICT warning.http://stackoverflow.com/questions/10722484/strict-standards-is-a-deprecated-please-use-the-instanceof-operator/10722560#10722560
"This function was deprecated in 5.0, but since there are valid usecases for it, not covered by instanceof, it was re-introduced in 5.3. I suggest you upgrade your installation of PHP."
Magyarul a Te PHP-verziód valahol az 5.0 és az 5.3 között van, így E_STRICT warningot kapsz, ami egyébként nem állítja meg a script futását, de persze nem jó, hogy van. A megoldás a minimum PHP 5.3-verzióra upgrade-elés, ami amúgy is javasolt. (Persze az is megoldható, hogy elnyomod az E_STRICT warningokat, de szerintem fejlesztésnél egyáltalán nem jó gyakorlat, sőt.)Amúgy ez meglehetősen ronda kód, nem kicsit érdekes ez a behányt XML-mentés, inline style-ok, stb.
De ami a lényeg: létrehozza a fájlt a módosítás után?
-
#16297
Sk8erPeter
nagyúr
tothjozsi96
#16291
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16291
üzenetére
Hát ja, sajnos nem meglepő, hogy rohadt lassú, mert tele van regexpekkel, egyenként újból és újból végigkotorássza a szöveget arra a kifejezésre, amelyik esetleg illeszkedik (mármint mindegyik regexpre külön-külön), stb., plusz elég karbantarthatatlan is a kód, mert nem valami tömbszerű megoldás van, vagy bármi általánosabb, hanem az str_replace-ekhez vagy épp preg_replace-ekhez be van drótozva stringként az adott smiley - ezenkívül belerak további lassításokat, ilyenekkel, hogy előbb preg_match-csel ellenőrzi, van-e illeszkedés, és AZUTÁN preg_replace-el. Szerintem keress valami jobb kódot/library-t, rengeteg szócikk van Stack Overflow-n. Hozzáteszem, ez a smiley-cserélős móka egyáltalán nem triviális probléma, nehéz általános megoldást írni rá szerintem, ami minden esetet lefed.
(#16281) tothjozsi96 :
"Próbáld meg kivenni a strlen-t, szerintem az lesz a baja ..."
Miért lenne már az strlen a baja?(#16292) Des1gnR :
Hibajelzés be van kapcsolva?
"Viszont ha oda illesztem be ezt a kis kódot ahová kellene, akkor nem hozza létre az XML-t"
És ennyi a hibajelenség, semmi több?
Amúgy mondom, nagyon gáz ez a megoldás, hogy a rendeles.php fájlodba be van okádva minden. Rakd már egy globális függvénybe legalább, amit include-olás (/require) után meghívsz, még az is jobb.
Amúgy ha már ilyen jellegű kódbeillesztés, akkor inkább require_once()-t használj, az garantáltan csak egyszer include-olja a kódot.A kódot sem ártana legalább nagyvonalakban ismernünk... (Nem kell az egész, csak legalább valami útmutatás, hogy mi történik a fájlodban.)
(#16293) tothjozsi96 :
"Az include("rendeles.php")-t próbáltad már?"
Ugye tudod, hogy mi a különbség a require() és az include() között? Semmit nem oldana meg lecserélni a require()-t include()-ra. Annyi különbség lenne, hogy abban az esetben, ha nem létezne a fájl, nem produkálna egy fatális hibát. -
#16290
Sk8erPeter
nagyúr
Des1gnR
#16289
Sk8erPeter
nagyúr
válasz
Des1gnR
#16289
üzenetére
Ja, akkor sorry, ezek szerint félreértettem azt, hogy a "Van egy PHP fájlom amely létrehoz egy XML fájlt az ftp-n. Ezt egy másik PHP-n keresztül szeretném meghívni, de nem tudom hogyan kell." mondatban az "ezt" mire vonatkozik.
Ha jól értem, most nálad az van, hogy van egy fájlod, aminek a kódja egy az egyben ki van dobálva, az kreálja az XML-fájlt. Te pedig ezt a műveletet valamilyen másik fájlból szeretnéd végrehajtani.
Hát akkor tedd ezeket a kódokat egy függvénybe/osztály metódusába, valami értelmesen szervezett struktúrába, include-old ezt a fájlt a másik PHP-fájlból, majd egyszerűen csak hívd meg a megfelelő függvényt/metódust, és meg is vagy.
Gondolom így értetted...Bár elvileg lehetne simán include-olni is, de az ilyen egy az egyben, bármi normálisan kitalált struktúra nélkül kidobált kód mindenképp kerülendő.
-
#16288
Sk8erPeter
nagyúr
norby10
#16278
Sk8erPeter
nagyúr
válasz
norby10
#16278
üzenetére
A HTML-kódodat is meg kellene mutatnod, mármint konkrétan a form vonatkozó elemét, vagyis a fájlmezőt. Ha azt írod, 1 elemmel működik, többel nem, az így elsőre arra utal, hogy nem tömbszerűen adtad meg a name HTML-attribútum értékét. Vagy valami hasonló. Szóval jó, hogy a backendet megmutattad, de kellene az is, amit a kliens lát.
(#16287) Des1gnR :
Mit jelent az, hogy XML-t "meghívni"?
Szerk.:
a köv. üzenetből úgy tűnik, én értettem félre, és a PHP-fájlt akarod meghívni, az úgy más.(#16276) tothjozsi96 :
Mit tartalmaz ez a format_comment() függvény?
Másik kérdés, hogy van-e értelme állandóan átalakítgatnod, ahelyett, hogy eleve átalakítva mentenéd el. Persze lehet, hogy nálad pont arra van szükség, hogy a "nyers" formában töltődjön fel, de úgy tűnt, elég egyszerű esetről van szó nálad, tehát feltölthetnéd a sorokat eleve formázva is. Így megjelenítéskor nem kéne átalakítgatni semmit. Már ha jól értem a gondodat.
Meg megmutathatnád, egészen konkrétan, kódszinten hogyan alakítod át.
A tisztításra (pl. script-tagek eltávolítása, stb.) meg rengeteg kész library van, lehet, hogy érdemes lenne megfontolni ilyenek használatát, pl. olyat, ami a teljesítményt sem veti vissza. -
#16262
Sk8erPeter
nagyúr
tothjozsi96
#16258
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16258
üzenetére
1. légyszi használd a "Válasz" linket, még a saját hozzászólásodhoz is, hogy bárhonnan követhető legyen az üzenetszál, hogy most ez melyik téma folytatása
(jelen esetben kitalálható, de akkor is )
2. ez tipikusan olyan kérdés volt, amire semmi értelmeset nem lehet válaszolni Nulla konkrét részlet, hogy mi nem működik, mi a pontos hiba (kb. ilyen "nem működik, mi lehet a gond"-szintű hibajelzés), nulla konkrét kód, stb. Szóval így nem fogjuk kitalálni, mi lehet a gond nálad.(#16252) Lacces :
isset($data[$key])
--> a foreach-ciklusban ennek a feltételnek nem sok értelme van. Nyilván igaz lesz, miután ezeken a kulcsokon mész végig. -
#16251
Sk8erPeter
nagyúr
tothjozsi96
#16250
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16250
üzenetére
Felhasználói szemszögből egyáltalán érzékelhető ez a különbség?
Egyébként egy kerülő megoldás az lehetne, hogy egyből, még feltöltés előtt cseréled ezeket a szövegeket. -
#16249
Sk8erPeter
nagyúr
tothjozsi96
#16248
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16248
üzenetére
De attól még akkor sem jó így, az előző magyarázatot továbbra is fenntartom...
Úgy szokás, hogy hozzárendelsz egy-egy szerepkört a júzerekhez, ami egy tágabb fogalom, benne foglaltatik pl. az is, hogy ő törölhet, módosíthat, blabla, ő csak módosíthat, de nem törölhet, és így tovább... tehát azt érdemes ellenőrizni, hogy az adott júzernek van-e konkrétan olyan joga (nem szerepköre, mert a szerepkör tágabb fogalom, amiben több jogosultság is benne lehet), hogy töröljön. Na mindegy, ez csak egy javaslat, érdemes lehet megfontolni, hogy később ne legyenek problémáid belőle. -
#16247
Sk8erPeter
nagyúr
tothjozsi96
#16246
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16246
üzenetére
Hát itt 20-at jelenítesz meg, 40-et akartál.
De végül is oké. Amúgy azt hittem, csak a csatlakozott kliensnek akarsz megjeleníteni ennyit, az fura, ha pont az adminnak kevesebbet jelenítesz meg, mint amennyi van, legalább biztosíts lehetőséget a továbbiak törlésére (lapozásra) is az adminnak.
Ez az >= UC_MODERATOR kicsit fura feltétel, szerepköröknek kellene lennie, és akinek van joga törölni, csak az törölhessen, ebből még gond származhat, ha ilyen "nagyobb-egyenlő, mint valami konstans" feltételt raksz be (mi van, ha bővíted a szerepköröket, és nagyobb számot kell rendelni valami másik szerepkörnek, akinek nem kéne, hogy joga legyen a törléshez) - csak egy szerepkör legyen, aki tud törölni, ezt rendelgesd hozzá júzerekhez, és annak az egyenlőségét ellenőrizd inkább.
És ez továbbra is csak egy átmeneti megoldás, csak hogy működjön a dolog legalább, ennél azért jóval szebben is lehet, hogy ne mindig nagy tömbökkel operálj, szóval majd később ezt a megoldást azért szépítsd.
De örülök, ha sikerült működésre bírni, szívesen. -
#16245
Sk8erPeter
nagyúr
tothjozsi96
#16244
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16244
üzenetére
Fasza, ha működik.
Általános gyakorlat az, hogy a szuperglobális tömböket NEM használjuk fel közvetlenül, alaposan validáljuk előtte.
"Már csak egy utolsó dolog van vissza, nem tudom hogy limitáljam max. 40 üzenetet akarok megjeleníteni, de nem tudom hogy tudnám így a tömbök miatt."
Hát úgy, hogy a tömb utolsó 40 elemét veszed. Pl. array_slice-t használhatsz erre a célra. Egy egyszerű példa:
http://stackoverflow.com/questions/5468912/php-get-the-last-3-elements-of-an-array/5468954#5468954
Természetesen neked nem 3 kell, hanem 40.
DE arra figyelj, hogy előtte count()-tal ellenőrizd le, hogy több eleme van-e, mint 40, és ha igen, csak akkor szabdald fel, és vedd az utolsó 40 elemét.Viszont az is lehet, hogy ezt már érdemes lenne vagy a memcache-nek egy külön kulcsa alatt tárolni, vagy adatbázisba pakolni, és kitörölni a memóriából, mert ha úgysem érdekes jelen esetben, akkor minek terpeszkedjen a memóriában feleslegesen.
-
#16243
Sk8erPeter
nagyúr
tothjozsi96
#16242
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16242
üzenetére
Szívesen!
Jó a felvetés, legegyszerűbb (még ha nem is szép) megoldás jelen esetben az lenne, ha maga az azonosító lenne a tömbindex, és annak értéke pedig az adatokat tartalmazó tömb lenne. Ez továbbra is tömbök tömbje, ahogy a korábbi megoldás is volt, csak annyi különbséggel, hogy itt explicite meghatározod a tömbindexet, nem pedig az automatikus számozásra bízod (mivel eddig numerikus indexek voltak használva, 0, 1, 2, ...).
Tehát valahogy így, pszeudokóddal:$conversations = array(
AZONOSÍTÓ1 => array(
"text" => "asdasd",
),
AZONOSÍTÓ2 => array(
"text" => "blabla",
),
AZONOSÍTÓ3 => array(
"text" => "qweqwe",
),
);az AZONOSÍTÓ1, AZONOSÍTÓ2, stb. kulcs lehet szám, vagy lehet egy string is (attól függően, milyen típusú azonosítót használsz).
Akár redundánsan is tárolhatod az azonosítót, úgy, hogy pl.:AZONOSÍTÓ3 => array(
'id' => AZONOSÍTÓ3,
'text' => 'qweqwe',
),Ez bizonyos esetekben leegyszerűsítheti a dolgot, persze figyelni kell rá, hogy ez konzisztens maradjon, ne legyen egyik helyen ilyen azonosító, másik helyen amolyan.
Egyébként tényleg érdemes lehet bevezetni egy osztályt, hogy szebben tudd tárolni és kezelni az adatokat.Jelen esetben ezzel az egyszerű megoldással tehát úgy tudnád törölni, hogy egyszerűen írsz egy unset($conversations[AZONOSÍTÓ3]); sort, ezzel kitörölve az adott tömbindexet, és ezután replace-eled a korábbi tömböt a memcache-ben, és meg is vagy.
Itt is egyébként figyelni kell arra, nehogy egy másik csatlakozott kliens egy korábbi kiolvasott adatból tudjon beírni, úgy, hogy visszarakja valahogy ezt az értéket a tömbbe...
Ezért is mondom, hogy szebb megoldást továbbra is valamilyen NoSQL-megoldással lehetne készíteni. -
#16241
Sk8erPeter
nagyúr
tothjozsi96
#16240
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16240
üzenetére
Tehát akkor mégis működik a kódom, amit mutattam?
Ahogy elnézem, csak annyi különbség van, hogy a get-metódusnál nem array-t használsz, és hogyha ez így működőképes, az számomra arra utal, hogy hibás/hiányos a hivatalos dokumentáció:
http://hu1.php.net/manual/en/memcache.get.php
itt ezeket a fejléceket írja:
string Memcache::get ( string $key [, int &$flags ] )
array Memcache::get ( array $keys [, array &$flags ] )
Magyarul ezek szerint ha string kulcsot adsz meg, akkor stringet is kapsz vissza; de Te a kódod szerint tömböt kaptál vissza. Akkor itt a hivatalos doksiban kéne lennie még legalább egy mixed Memcache::get ( string $key [, int &$flags ] ) sornak is... Ez így logikus is lenne, hiszen a set-metódussal is mixed állítható be, így lekérésnél is nyilván mixed lehetne. Na, ezt is megtudtuk.DE:
- jól érzed, ez az 'id' => rand(1,999999999) sor teljesen rossz. Mi van, ha a rand() eredményeként éppen olyan azonosító jön ki, ami már létezik? Sehol nem ellenőrzöd. De amúgy sem szokás sehol így generálni az azonosítót. Ja, és az azonosító nem feltétlenül kell, hogy szám legyen (lásd uniqid()), vagy ha mégis az kell, akkor oldd meg, hogy inkrementálva legyen, de akkor meg figyelni kell arra is, hogy ha több kliens is csatlakozik, akkor atomikusan történjen az inkrementálás, ne tudjanak korábbi/"kettő közötti" állapotot kiolvasni. Cél egyáltalán ezt feltölteni majd valami adatbázisba, hogy meglegyenek a régi adatok? Mert ha nem, szerintem simán használhatnád a uniqid() függvényt, és meg is vagy. Ha adatbázisba feltöltöd, ott max. akkor problémás, ha az id-hez egy automatikusan inkrementálódó int van beállítva; az nyilván nem fogadja el az angol ábécé karaktereit.
Az inkrementálós megoldáshoz nem ártana valami lockolás, hogy egyszerre csak egy kliens tudja módosítani az értéket, de simán megtehetnéd azt, hogy egyszerűen a set/replace-szel egy MÁSIK kulcsot állítasz be, ami ezt a számot tárolja, azt lekéred, megnöveled, stb.
- minek kéred le a replace/set után még egyszer az adatokat a get-metódussal? Hiszen már ott van a $conversations-tömbödben. Mondjuk annyiból jó lehet, hogy ha közben más kliens módosította az adatokat, akkor azt is megkapod...
- erre a feladatra szerintem tényleg jobb lenne valami NoSQL-megoldás, amiről korábban írtam."Amúgy ez a compress asszem valami tömörítés a memcache-ben."
Igen (MEMCACHE_COMPRESSED), de ezt szerintem hagyd ott szépen, ahogy mutattam, lásd:
http://stackoverflow.com/questions/2105663/what-is-compression-for-in-phps-memcache/2106096#2106096 -
#16239
Sk8erPeter
nagyúr
tothjozsi96
#16238
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16238
üzenetére
Szívesen, de akkor másold már be légyszi azt a kódot (legalább egy körülbelülit), ami működik, ha már ennyit szenvedtünk vele...
(Nekem most nincs kedvem agyalni a témán, de a megoldás érdekelne.)(#16237) : Ja, nyilván nem jó, mert ötezerszer szerepel benne az "uzenofal" kulcs...
-
#16236
Sk8erPeter
nagyúr
tothjozsi96
#16235
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16235
üzenetére
"Mellesleg felesleges a replace mert mindennek van külön ID-je és ahogy mondtam ez üzenőfal ..."
Ez hogy jön ide, hogy mindennek van külön id-je? Sehogy: eddig az volt a problémád, hogy a korábbi értékek egyszerűen törlődnek, mert szimplán felülírtad őket a Memcache::set metódussal. Arra kellett a replace, hogy a korábbi és az új értékek egyesítéséből keletkező tömbbel helyettesítsd a régebben feltöltött tömböt.
Így meg tudod tartani a régebbi és az új értékeket is. (Persze itt majd figyelj a memóriahasználatra, erre írtuk, hogy a túl régieket törölni kéne a memóriából, előtte esetleg beírva adatbázisba, ha meg akarod tartani hosszú távon, hogy visszakereshető legyen később.) -
#16234
Sk8erPeter
nagyúr
tothjozsi96
#16233
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16233
üzenetére
Ez egy brutálisan egymásba ágyazott tömb (nem "dupla tömb", hanem sokszorosan egymásba ágyazott darab, az "uzenofal" kulccsal ellátott tömbbe beírtál egy másik "uzenofal" kulccsal ellátott tömböt, és abba egy továbbit, stb...), amiből egyértelműen következik, hogy rosszul történik a beírás. Ergo nem igaz az, hogy "szépen beírja", mert rossz.
-
#16232
Sk8erPeter
nagyúr
tothjozsi96
#16231
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16231
üzenetére
De már megint mi a frász ez a kód?
Miért raksz egy foreach-ciklust a tömb-definiálásba?Csak hogy konkretizáljuk, én így értettem, hogy merge-ölöd a tömböt (tehát összefűzöd) a korábbi értékekkel, először lekérve a korábbi értéket, majd replace-elve (persze ellenőrizd először, hogy van-e már feltöltve egyáltalán ilyen érték!):
// korábbi értékek
// http://hu1.php.net/manual/en/memcache.get.php
// eszerint a get-nek array-t kell megadni, ha array-t vársz
$conversations_before = $memcache->get(array('uzenofal'));
// új értékek
$conversations_current = array(
array('id'=>1, 'text'=>'qwe'),
array('id'=>1, 'text'=>'ret'),
);
// ellenőrzöd, hogy van-e egyáltalán már ilyen érték feltöltve, mert csak akkor lehet replace-elni ezzel a kulccsal később!
// összefűzöd a két tömböt
$conversations = ($conversations_before !== FALSE) ? array_merge($conversations_before, $conversations_current) : $conversations_current;
// replace, ha van már ilyen kulcs, set, ha nincs még
if($conversations_before !== FALSE) {
$memcache->replace('uzenofal', $conversations, MEMCACHE_COMPRESSED, 999);
}
else {
$memcache->set('uzenofal', $conversations, MEMCACHE_COMPRESSED, 999);
}Persze ezt most csak kézzel írtam, nem teszteltem, de a gondolatmenet remélem átjött.
Szóval vág? -
#16230
Sk8erPeter
nagyúr
tothjozsi96
#16228
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16228
üzenetére
Én értelek, csak te nem értesz.
Miért nem kéred le felülírás ELŐTT az előző értéket, fűzöd hozzá ehhez a tömbhöz az új értékeket, és replace-eled EZUTÁN a korábbi tömböt? Első körben.
Vagy most az a baj, hogy ha csatlakozik egy másik kliens, akkor annál még nincs beállítva ez az érték, vagy mi? -
#16227
Sk8erPeter
nagyúr
tothjozsi96
#16225
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16225
üzenetére
Jó, hát most nem tudom tesztelni, akkor használd a replace-t, úgy, hogy a módosított tömböt rakod a helyére, és kész, első megközelítésként jó lesz, aztán szépíted, ha lehet. Direkt azért linkeltem az előbb, ne csak a hsz. felét olvasd el.
(#16226) : Ez a kód most remélem csak egy rossz vicc volt!
-
#16224
Sk8erPeter
nagyúr
tothjozsi96
#16223
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16223
üzenetére
Fontolóra vehetnéd a Memcache::add metódust is, így az előbbi megoldás helyett, ahol egy nagy tömbben töltöd fel a beszélgetéseket, akár egyenként is feltölthetnéd, tehát így:
foreach($conversations as $conversation) {
echo $conversation["id"] . " - " . $conversation["text"] . "<br />";
$memcache->add('beszelgetes', $conversation, MEMCACHE_COMPRESSED, 99);
}Próbát megér, még nem használtam, majd írd meg, ez mit eredményez, ha lekéred az adatokat. Így elvileg bármikor tudsz hozzáadogatni, nem írja fölül, mint a set.
(Ott van még a replace-metódus is egyébként, ha majd az kéne, de ezt próbáld meg előbb.)Egyébként fontolóra vehetnéd valamilyen NoSQL-megoldás használatát is (mint pl. a mongoDB), az ilyen feladatokra szintén nagyon hatékony tud lenni (lásd Facebook).
-
#16222
Sk8erPeter
nagyúr
tothjozsi96
#16221
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16221
üzenetére
Ő, de miért nem magát a $conversations tömböt tárolod, úgy, ahogy van?
http://php.net/manual/en/memcache.set.php
a függvény fejléce a doksiban:
bool Memcache::set ( string $key , mixed $var [, int $flag [, int $expire ]] )
Mint látható, a második paraméter "mixed", tehát nincs korlátozva, hogy milyen típust állíthatsz így be.
Próbáld ki ezt (nem tudom most tesztelni):foreach($conversations as $beszelgetes) {
echo $beszelgetes["id"] . " - " . $beszelgetes["text"] . "<br />";
}
$memcache->set("beszelgetes", $conversations, false, 99);A $conversations tömbhöz meg értelemszerűen hozzáadhatsz, illetve abból törölhetsz, aztán újból beállíthatod az előbbi módon (elvileg jónak kéne lennie).
Egyébként itt a harmadik paraméternél nem lenne jobb false helyett használni esetedben pl. a MEMCACHE_COMPRESSED vagy más konstanst?
http://stackoverflow.com/questions/2105663/what-is-compression-for-in-phps-memcache/2106096#2106096U.i.: plíz használd a Programkód gombot, miután kijelölted a kódot! Köszi!
-
#16219
Sk8erPeter
nagyúr
tothjozsi96
#16218
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16218
üzenetére
Úgy értettem, hogy nem stimmel az a mondat, hogy "Nyilván jquery-vel látszik csak a különbség", mert nincs köze a jQuery-nek ahhoz, hogy miért gyors a dolog. Azért gyors, mert a memóriában tárolsz, onnan olvasol, és nincs ott az adatbázis-kezelési overhead. Plain JavaScripttel, meg teljesen más megközelítéssel is meg lehetne írni az egészet, a lényeg a gyorsaságban jelen esetben a szerveroldal (mert az a szűk keresztmetszet, a kliensoldali kód nyilván gyors, hacsak nem egy szutyok).
Jé, most lettem PH! félisten, atyaúristen.
-
#16217
Sk8erPeter
nagyúr
tothjozsi96
#16214
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16214
üzenetére
Ennek itt mi értelme van? Ha már tényleges felhasználás a cél, akkor miért nem egyértelműen használod fel a kulcsokat, miért általánosan akarsz végigmenni a tömbön? A másik, hogy remélem, ez a tömb csak példa, és nem úgy néz ki a gyakorlatban, hogy összekutyulva asszociatív tömb és numerikus kulcssal ellátott tömb egyben. Akkor már miért nincs az 5-nek, meg a "mégvalami"-nek is valami normális indexe? Ha tényleg nincs, hát akkor adjál nekik (nem egy CMS által generált kódot használsz, ahol néha ilyen ocsmány kutyult tömböket használnak, hanem te írod az egész kódot), ha van, akkor meg aszerint használd a kulcsokat, ne általánosan akarj végigmenni foreach-ciklussal. Legalábbis az elég furcsa, ha az a valódi felhasználás, hogy igazából nem is tudod egyértelműen már a kódból, hogy mi is van a tömbben.
Egyébként már írták neked, hogy használd tömbök tömbjét, miért nem teszed?
Most nem is tudom, hogy működik a megoldásod (vagy ez csak példakód?). Sőt, ami szebb lenne, miért nem használod inkább objektumok tömbjét?
A tömbök tömbje mondjuk ilyen lehetne:
$conversations = array(
array("id" => 5, "text" => "asdasdasd"),
array("id" => 6, "text" => "blabla"),
);
de ez finoman szólva nem valami szép, inkább objektumok tömbje kéne. Szóval definiálnál egy osztályt, amiben értelmesen tárolhatnád az adatokat, lenne több attribútuma, aztán példányosítanád. Ezerszer nagyobb rugalmasságot kapnál cserébe.(#16213) : Nem "ágyazott" foreach-ciklus, hanem EGYMÁSBA ágyazott ciklus. Ha nem lenne egyértelmű, ez két egymásba ágyazott foreach-ciklus (és ezt a végtelenségig lehet bővíteni):
foreach(...) {
foreach(...) {
// ...
}
}(#16216) :
"Nyilván jquery-vel látszik csak a különbség"
Hogy mi van? Mégis mi a frász köze lenne a jQuery-nek a dolog gyorsaságához? -
#16212
Sk8erPeter
nagyúr
tothjozsi96
#16211
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16211
üzenetére
Már szó volt a tömbök tömbjéről, és ehhez értelemszerűen két egymásba ágyazott foreach-ciklusra lesz szükséged, hogy normálisan elérd a tömbben tárolt tömb kulcsait/értékeit. Már ha jól értem, mit szeretnél, hogy először csak mindent jól ki akarsz íratni, és annyi; bár lehet, hogy félreértelek, jó lenne tudni, nálad mit jelent az, hogy $value...
(Na, látod, ez a hátránya az ilyen fos változóneveknek. ) Egyébként hogy értelmesen lásd, mit tartalmaz egy tömb, csak egy gyorsteszt erejéig debuggolhatnál, vagy írasd ki az értékét var_export()-tal, print_r()-rel, var_dump()-pal, stb... (Nyilván aztán amint megtudtad, mi van benne, ezeket a sorokat selejtezd ki, amúgy is illik inkább normálisan debuggolni a kódot, nem kiíratni minden hülyeséget.)
De lehetőleg felejtsd el az ilyen változóneveket, mint az $array, meg $value, mert ezek a nevek semmit nem mondanak a változók tartalmáról, így ha ránézel a kódra, mindig előbb el kell gondolkodni rajta, az mit is tartalmaz pontosan. Nem kell félni a hosszú, beszédes változónevektől, SŐT."Elég sokat terhel az SQL fal, és így szinte 0% load.
"
Hát ha minden a memóriában tárolódik, és onnan is kell kiolvasni, akkor nem csoda, mivel semmiféle adatbázis-kapcsolódási, oda való feltöltési (lockolási, stb.) overhead nincs a dologban. Viszont ahogy Athlon64+ említette, épp emiatt ne felejtsd el a túl régieket törölni, különben szép kis memóriahasználatod lesz.(#16205) kemkriszt98 :
Akkor fasza, ha megoldódott, viszont az echo után használj már szóközt, háthogynézezmárkianélkül. -
#16203
Sk8erPeter
nagyúr
kemkriszt98
#16189
Sk8erPeter
nagyúr
válasz
kemkriszt98
#16189
üzenetére
Ez az if($send) egy elég értelmetlen feltétel, főleg, hogy már ezelőtt a sor előtt az execute-tal végre próbálsz hajtani egy műveletet, és ha ez a változó mondjuk NULL, akkor már korábban kapsz erre az arcodba egy hibaüzenetet (mivel nyilván NULL értékkel rendelkező változón nem igazán lehet metódust meghívni). Meg azt írtad, dobódik egy kivétel, "Connection timed out" üzenettel. De másold már be a PONTOS, teljes hibaüzenetet!
Még valami:
$con = new PDO('mysql:host=mysql5.hostbase.net;dbname=artclubl_luminita','*','*');HELYETT így kellene inicializálnod a PDO-t:
$con = new PDO(
'mysql:host=mysql5.hostbase.net;dbname=artclubl_luminita',
"*",
"*",
array(
PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES UTF8;',
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
)
);A PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION azért érdekes, hogy kivétel dobódjon probléma esetén, és ne ilyen béna if-else ellenőrzésekre legyen szükség. Emiatt pedig try-catch blokkba kell raknod az egészet, és megfelelően loggolni a hibaüzeneteket.
Itt azt írod, hogy "direkt URL-lel" megy. Tehát ha szépen beírod a böngésződ címsorába, akkor az UPDATE-művelet is sikeresen lefut, nincsen időtúllépés?
Sőt, ha parancssorból hajtod végre, akkor is sikeresen lefut az UPDATE-művelet?
Magyarul egyedül akkor van probléma, ha a tárhelyszolgáltató admin-felületén szerkesztgetett, oda beírt ütemezett feladat futna le? Igazából erről olyan sok részletet nem osztottál meg, hogy hogyan csináltad, arra lehetne tippelni, hogy elrontottál valamit a szerkesztéskor, de tényleg csak tippelgetni lehet ennyi alapján.(#16199) PumpkinSeed:
"Nem láttam még olyan oldalt aminek ez hozta volna meg a sikert."
Én igen, SoundCloud, YouTube, ...
(Jó, értem én...) -
#16183
Sk8erPeter
nagyúr
kemkriszt98
#16175
Sk8erPeter
nagyúr
válasz
kemkriszt98
#16175
üzenetére
"nem volt világos, hogy mit is kellene parancssorból futtatni"
Te magad írtad be azt a sort, amit le kellene futtatni, ezzel leellenőrizve, hogy az milyen eredményt ad. Nyilván azt a fájlt (is) nézd meg, amibe a parancs kimenetét beleirányítod."Amúgy annyira nem értek hozzá de gondolom osztott tárhelyen van..."
Ne gondold, hanem tudd. Osztott tárhelyre általában nem lehet beSSH-zni, de erre írtam az alternatív megoldást, hogy esetleg futtasd lokálisan, Linuxos környezetben (vagy virtuális gépen, Linuxos környezetben).
Amúgy magát a cron-működést (hogy jól csináltad-e az ütemezett feladat ütemezését) ellenőrizheted egy garantáltan működő paranccsal is, mondjuk csak annyit csinálsz, hogy echózol (hozzáfűzve) valami fájlba teszt gyanánt, aztán kész; ha ütemezetten megtörténik a beleírás, akkor láthatod, hogy ez a rész oké, csak a másik parancs nem fut le valamiért. Szóval kezdd el leszűkíteni a problémát. -
#16174
Sk8erPeter
nagyúr
kemkriszt98
#16172
Sk8erPeter
nagyúr
válasz
kemkriszt98
#16172
üzenetére
"Parancsból?"
Azt írta, hogy "parancssorból"... Tényleg nem tiszta, mi az a parancssoros felület/CLI? Vágod, amit Windows-ban a cmd-vel hívsz elő, Linuxon defaultból a Ctrl+Alt+T-vel (Terminal)...
Ide kéne bedobni az általad előbb írt sort, és megnézni, mi a kimenete... Nyilván ha valami osztott tárhelyen van a cuccod, nem kapsz hozzá ilyen felületet, nem tudsz beSSH-zni, stb., de saját környezetben is kipróbálhatod, nyilván behelyettesítve az útvonalakat.Nyilván itt a lényeg az lenne, hogy az általad írt előbbi parancsot, meg a cron.php kódját lefuttasd "kézzel" (tehát nem cronnal), és megnézd, helyesen lefut-e, na meg kerül-e valami az stdoutx.txt fájlba.
Ja, egyébként azt sem ártana, ha megosztanád, hogy ezt most milyen környezetben próbálod tesztelni (osztott tárhely, VPN, saját szerver, mi ez?), nagyon nem mindegy, milyen útvonalakat használsz.
-
#16081
Sk8erPeter
nagyúr
PumpkinSeed
#16078
Sk8erPeter
nagyúr
válasz
PumpkinSeed
#16078
üzenetére
Láthatóan elgépelés... Amúgy sosem néztem a magyar részét.
(#16080) PumpkinSeed :
"Már előre látom, hogy várhatóan mást fogtok javasolni, hogy ne a mail() függvénnyel csináljam, de egy sima URL-t kell csak elküldjek amire kattintva megnyit egy új oldalt.
Na szóval a mail() függvénnyel szenvedek már tegnap este óta."
Ha azóta szenvedsz vele, akkor most komolyan, van még kérdés? Egyszerűen annyira nem éri meg szarakodni a sima mail() függvénnyel, rájönni, mi a nyűgje, amikor vannak ilyen library-k, mint a PHPMailer vagy a SwiftMailer, amik pár sample code átírása után csak úgy simán működnek, hogy nyilván azt fogjuk javasolni, hogy ne a mail() függvénnyel csináld. Attól, hogy a két említett library közül valamelyik ott csücsül a tárhelyeden, nem lesz lassabb a szervered, vagy nem tudom, mi miatt aggódsz. -
#16077
Sk8erPeter
nagyúr
kemkriszt98
#16075
Sk8erPeter
nagyúr
válasz
kemkriszt98
#16075
üzenetére
Azért azóta biztos sokat változott a helyzet, a w3fools.com-on már "megengedőbben" fogalmaznak: "W3Schools still has issues but they have at least worked on the primary concern developers had. For many beginners, W3Schools has structured tutorials and playgrounds that offer a decent learning experience. However, it would be a mistake to continue your education without learning from more reputable sources, so when you're ready to level up, move on."
Mindenesetre én továbbra is inkább a Mozilla Developer Networköt (MDN) ajánlanám. -
#16074
Sk8erPeter
nagyúr
PumpkinSeed
#16055
Sk8erPeter
nagyúr
válasz
PumpkinSeed
#16055
üzenetére
"Ez a valami.php POST metódussal fogadja az email nevű inputban megadott karaktersorozatot"
Nem, a kliens küldte POST-metódussal a szerver felé. A valami.php nem "fogad" POST-metódussal semmit; legfeljebb feldolgozza a kapott adatokat.(#16058) kemkriszt98:
"Mi baj a W3Schools - al?"
https://web.archive.org/web/20130501070306/http://w3fools.com/Itt még régebben leírtam.
-
#16073
Sk8erPeter
nagyúr
19.Norbika
#16021
Sk8erPeter
nagyúr
válasz
19.Norbika
#16021
üzenetére
Sok erőszakosan önigazoló és kioktató megjegyzést tettél, mint a "falba csak akkor verd a fejed, ha tájékozódtál is", "Márpedig ha kicsit is utána néztél volna ( amit vélhetően nem tettél meg ) akkor belátnád", "Az már végképp érdekes, hogy ezzel neked mi a bajod. Keveset aludtál?", amikre igazából nem tudom, mi szükség (az ilyen oviszintű vitakultúrából sztem kinőttünk, és ezek nélkül is szerintem tök jól lehet vitázni
), de inkább felnőtt módjára lépjünk tovább, az érdemi kérdésre továbbra sem válaszoltál: szerinted jó, ha valaki 2014-ben úgy tanul PHP-ben MySQL-adatkapcsolatot kezelni, query-ket küldeni az adatbázisszerver felé, hogy még csak nem is hall a prepared statementekről? Ha igen, akkor szerinted mi lenne a megfelelő módja ennek? Fűzögessen össze stringeket, escape-elgessen, mint az ősidőkben?
Hogy ne érje megint szó a ház elejét, utánanéztem, milyen is ez a könyv (már kíváncsivá tettél): csapnivaló. Pontosan azt csinálja, amit nem szabadna: konkatenálja a query-ket, de tudod, mi a legrosszabb? Hogy még csak nem is escape-eli a $_POST-tömbből érkező változókat! 
(pl. 439-441. o.) Tényleg remek ez a könyv kezdőknek! Ja, nem. De továbblapozgattam, gusztustalanok a kódok, komplett óriásformokat echóz a kódban, escape-elgetve az idézőjeleket, erőlteti a táblázatok használatát, elavult attribútumokat használ a HTML-kódban a formázásra, ahelyett, hogy a CSS-formázást javasolná, magyar változóneveket használ a kódokban, de van, hogy inkább aktuális kedvétől függően keveri az angol változónevekkel (akkor már legalább lenne következetes ), közvetlenül használja fel a szuperglobális változók indexeit (amit szerintem nagyon nem illik, még ha ellenőrzi is a kulcsok meglétét + validálja azok értékét (remélem, azért művel ilyeneket), egyszerűen rossz szokásra nevel), a tömböket nagyon sok helyen nem bejárja, hanem azok indexeit "szépen" egyenként átadogatja változóknak, tovább nem volt kedvem nézegetni. Ezeket csak így random módon belelapozgatva fedeztem fel, nem is nagyon kellett sajnos keresni.
Na, szóval utánanéztem "kicsit is", és nem tudom belátni, hogy milyen remek ez a könyv.Az is tök mindegy, hogy mi volt régen, és hogy nem minden van benne egy könyvben, amit mi jónak tartanánk, születtek 2010 óta is könyvek/e-bookok/tutorialok/akármik (bevallom, nincs kedvem más helyett guglizni), és a fenti hibák régen is hibák voltak. Ha meg már a nyelvi alapokat elmagyarázó anyagokról beszélünk, a BDD, TDD, stb. nem nagyon kapcsolódik ide.
Remélem, ezúttal nem fogod úgy érezni, mintha téged sértegetnének.(#16031) honda 1993 :
"És mi az a form?"
Erre a kérdésre már nehéz szavakat találni... Itt még azt írtad, hogy a HTML is "normálisan megy"...
Néha abban reménykedem, hogy csak trollkodsz, és egyszer beírod, hogy na jó, bocs mindenkitől, csak szopattalak titeket. -
#16020
Sk8erPeter
nagyúr
19.Norbika
#16018
Sk8erPeter
nagyúr
válasz
19.Norbika
#16018
üzenetére
És az általad ajánlott "PHP és MySQL webfejlesztőknek" című könyv címében, összefoglalójában hol kellene látni bármilyen utalást arra, hogy kifejezetten "kezdőknek szóló könyv" lenne? De tök mindegy, basszus, 2014 augusztusa van, te egy 2010-es könyvet ajánlasz, ami egész konkrétan a PHP és MySQL kapcsolatát taglalgatja, és komolyan elfogadhatónak tartod, hogy egy büdös szó nem esik a prepared statementekről (aztán még ki is oktatsz, hogy én tájékozódjak)?
Miért, mégis szerinted hogy kéne oktatni BÁRKINEK azt, hogy hogyan paraméterezzen fel egy query-t? Fűzögesse össze a stringet, escape-elgessen csak manuálisan? Ezt nem gondolhatod komolyan.
Igenis essen már szó egy PHP-ről és MySQL-ről szóló könyvben a prepared statementekről, nehogy már ez az elvárás legyen túlzott.(#16019) :
"$stmt->get_result() -> ez a metódus tudomásom szerint csak 5.0 - 5.3-as verzió között volt elérhető. Mérget nem vennék rá, csak félig"
Itt még be is linkeltem a hivatalos oldalát (meg a hibák elnyomását is írtam, de mindegy), idézem: "(PHP 5 >= 5.3.0)". A fél mérget nem javaslom, de ahogy érzed.
A PDO-preferálással legalább egyetértek. -
#16016
Sk8erPeter
nagyúr
PumpkinSeed
#16013
Sk8erPeter
nagyúr
válasz
PumpkinSeed
#16013
üzenetére
Erről beszélsz, amire azt írtad, hogy még a prepared statementeket is b@szik megemlíteni a könyv?
Hát valóban remek lehet... Mondjuk ha teljesen kihagytad ebből a könyvből az OOP-részt, akkor nem tudom, miért állítottad nagy magabiztossággal, hogy nincs is szó bennük erről, lehet, hogy ott említésre kerül (még ha a mysqli-t procedurális stílusban is lehet használni, lásd mysqli_prepare())...(#16015) PumpkinSeed :
Különösebben nem gondolkodtam el a kódodon, de
1. a hibajelzések tutira nincsenek elnyomva? Vágod, az fejlesztés idején mindig legyen E_ALL értéken (E_ALL | E_STRICT).
2. a get_result miatt kérdezem, hogy 5.3.0-s vagy annál magasabb verziószámú PHP-d van telepítve? -
#15992
Sk8erPeter
nagyúr
honda 1993
#15988
Sk8erPeter
nagyúr
válasz
honda 1993
#15988
üzenetére
"oppaa. akkor mar megint en voltam a hulye."
A CSS topicban is ugyanezt az ámokfutást művelted: alapvető dolgokra kérdezel rá, olyanokra, amik a mások által már belinkelt anyagokban, és még ötezer helyen alaposan részletezve vannak, türelmetlenkedsz, idegbetegen reagálsz, mintha meg sem próbálnál elgondolkozni a kapott tanácsokon, aztán amikor az elgurult gyógyszeredet végre megtalálod, kicsit lehiggadva lerendezed utólag az egészet azzal, hogy hát ez van, amikor nem találod a megoldást egyből, akkor ideges vagy. Hát ez nem így működik, egyrészt így az ember inkább nem szívesen pazarolja rád az idejét (így is hálás lehetsz a kollégáknak, hogy ilyen türelmesen reagáltak eddig), másrészt ha már ilyen alapvető dolgokon ennyire felhúzod magaad, mi lesz később, amikor valóban összetettebb problémákba futsz, amik kiderítéséhez kitartás, türelem, meg némi gondolkozóképesség kell? -
#15938
Sk8erPeter
nagyúr
PumpkinSeed
#15937
Sk8erPeter
nagyúr
válasz
PumpkinSeed
#15937
üzenetére
Mi az, hogy "minden alkalommal"?
Már megint fogalmi zavarokat érzek nálad. Azt a bizonyos hű de komoly kétkattintós valamit megcsinálhattad volna úgy is, hogy egyszer beállítsa az ütemezett feladatot automatizáltan, vágod, lehet olyat is, egy rohadt egyszerű batch-programból. Pl. -
#15936
Sk8erPeter
nagyúr
PumpkinSeed
#15933
Sk8erPeter
nagyúr
válasz
PumpkinSeed
#15933
üzenetére
"Miért kellene? Van egy ilyen script amit csináltam, hogy a számítógép indulásakor elindul és figyeli az időt este 8:00-kor pedig automatikusan kikapcsolja a gépet. Szerintem ilyen módszerrel a PHP állomány megnyitása se lehetetlen, vagy mégis? Nem tudom.
"
Ja, tehát szerinted az egy elfogadható módszer, amit csináltál, hogy a saját kis alkalmazásod egész nap figyelgeti, mennyi az idő, és akkor lép érdemi működésbe, amikor detektálja, hogy már 8 óra van, amikor az operációs rendszerbe beépített ütemezett feladatok pont erre lettek sokkal értelmesebben kitalálva? -
#15935
Sk8erPeter
nagyúr
sztanozs
#15930
Sk8erPeter
nagyúr
válasz
sztanozs
#15930
üzenetére
"Igen viszont a mysqli_stmt_fetch nem array-be pakol, hanem a táblamezőneveknek megfelelő változókba (ami szerintem legalább akkora probléma, mint az összefűzött sql string)."
A kettő még csak össze sem hasonlítható. Hogy lenne ugyanakkora probléma? Az összefűzött query konkrétan komoly biztonsági kockázatot jelenthet bármilyen escape-elés nélkül (ahogy te mutattad), míg az, hogy a mező nevét "bedrótozod" az alkalmazásod kódjába, az csak egy igazodás egy kialakult struktúrához, de biztonsági kockázatot nem jelent.A másik felére: MySQLi helyett PDO-t használ az embör (fetch), és meg van oldva.
Én legalábbis sokkal értelmesebbnek találom (amennyiben ORM és hasonlók még szóba se kerülnek). Persze ez az eredeti problémát nem oldja meg, tudtommal ilyen esetben a mysqli_stmt_bind_result nem elkerülhető. -
#15928
Sk8erPeter
nagyúr
edari
#15925
Sk8erPeter
nagyúr
Lehetne erőlködni más lehetőségekkel, de az általad említett feladat megoldására pontosan a többiek által már említett cron vagy Windows-os környezetben Task Scheduler való.
(#15927) PumpkinSeed :
Vigyázz, mert még valaki komolyan veszi. Egyébként ha VBScript-szarság lenne, akkor is kéne, hogy valaki annak a lefuttatását ütemezze...(#15919) sztanozs :
Úgy érted, nem tudtad beírni Google-be, hogy "mysqli prepared statement example"?
Ott a példa a hivatalos oldalon procedurális és objektumorientált módszerre is:
http://php.net/manual/en/mysqli.prepare.php
(szerk.: ja, és kipróbáltam, Google 1. találata konkrétan a fenti kifejezésre) -
#15903
Sk8erPeter
nagyúr
Joci93
#15902
-
#15901
Sk8erPeter
nagyúr
Speeedfire
#15887
Sk8erPeter
nagyúr
válasz
Speeedfire
#15887
üzenetére
"Az újabb jQuery-ban csak aszinkron van, itt nem lehet gond szerintem."
Csak deprecated lett az 1.8 óta, de az opció még elérhető. Ezt igazolja, hogy a 2.1.1-rc2-ben is megtalálható:
https://github.com/jquery/jquery/blob/2.1.1-rc2/src/ajax.js
Amúgy itt van egy jó kis source browser:
http://james.padolsey.com/jquery/#v=2.0.3&fn=jQuery.ajax
Persze továbbra is messziről kerülendő bármilyen szinkron kérés - ha már AJAX. De ha nálad úgy tűnik, szinkron módon működik, megnézhetnéd, hogy nincs-e beállítva ez a paraméter valahol mégis, akár $.ajaxSetup() segítségével (aminek a használata egyébként szintén inkább kerülendő)."Illetve egy ilyen rendszert milyen nehéz lehet lefejleszteni pluszban. Mert egyszerűbb message táblán én is agyaltam már, amihez lenne egy ajax kérés pl setTimeout-tal, ami mindig bekérdez. Ez lenne a legegyszerűbb, de gondolom nem túl elegáns és erőforrás igényes."
Szerintem érdemes elolvasnod néhány beszélgetést arról, hogy hogyan csinálja a Facebook vagy a Gmail, van pár thread róla Stack Overflow-n:
http://stackoverflow.com/questions/1086380/how-does-facebook-gmail-send-the-real-time-notification
http://stackoverflow.com/questions/732705/how-is-gmail-chat-able-to-make-ajax-requests-without-client-interaction
http://stackoverflow.com/questions/5359773/how-to-implement-facebook-like-notification -
#15900
Sk8erPeter
nagyúr
Joci93
#15894
Sk8erPeter
nagyúr
válasz
Joci93
#15894
üzenetére
"Részletes keresést $_GET[""]-el vagy $_POST[""]-al érdemes csinálni?"
A kérdés így kicsit furán hangzik. Most az a kérdésed, hogy GET-metódussal vagy POST-metódussal érdemes-e egy keresésre szolgáló űrlapot megadni (method-attribútumban)? Mert ha igen, akkor a GET-metódust szokás általános keresésekre használni, így a keresések könyvjelzőzhetők, elküldhetők másnak, stb., de ha elég összetett az űrlap, akkor nyilván az sem jó, ha minden be van hányva az URL-be, így ez esetben POST-metódus használható.
DE ami fontos, és ami miatt a kérdésed nem helyes, hogy a HTML-oldalnak semmi köze a PHP szuperglobális változóihoz, a GET és POST csupán HTTP-metódusok (amiket jelen esetben a form tag method-attribútumában adsz meg), a szerveroldal pedig az űrlap adatait fogadhatja bármi más szerveroldali nyelvvel, nem csak a PHP létezik; csak a PHP az ilyen nevű szuperglobális változókon keresztül teszi elérhetővé az ilyen metódussal - kliensoldalról - kapott adatokat. Ergo a kérdésed inkább úgy hangzana jól, hogy az ilyen-olyan keresőűrlapok adatait GET- vagy inkább POST-metódussal érdemes-e elküldeni szerveroldalra. -
#15886
Sk8erPeter
nagyúr
fordfairlane
#15884
Sk8erPeter
nagyúr
válasz
fordfairlane
#15884
üzenetére
Hát igen, igazából értelmetlen ilyen hosszú műveletre GUI-t alapozni, feltételezve, hogy majd a felhasználó addig megnyitva tartja. Bár lehet, hogy valami webes alapú távoli admin-felületről van szó, ahol mehet a dolog, de akkor is; másik megoldás pl. adatbázisban tárolva bizonyos eseményeket, aztán frissítéskor ellenőrizni, van-e új, és ha igen, akkor értesítőket kirakni a felületre.
-
#15883
Sk8erPeter
nagyúr
Speeedfire
#15880
Sk8erPeter
nagyúr
válasz
Speeedfire
#15880
üzenetére
"Felületről küldök egy kérést a szerver felé ajax-al, ami dolgozik olyan 20-30 percet viszont arra az időre teljesen lehal a felület nem válaszol semmire sem."
Ez esetben az AJAX-nak pont az első A betűs része van elrontva, vagyis a kérés nem aszinkron. Ennek nézz utána a kódban, nem ajánlott szinkron kérést intézni ilyen esetben a szerver felé, mert ellentmond épp a lényegnek.
Kerülő megoldás lehet a pollozás, nyilván figyelve arra, hogy ha elindítottál már egy valakihez tartozó requestet, akkor annál ez a hosszas folyamat ne induljon el újból, hanem adjon vissza valami státuszinfót arról, hogy hol tart a request feldolgozásánál. -
#15872
Sk8erPeter
nagyúr
Joci93
#15871
Sk8erPeter
nagyúr
válasz
Joci93
#15871
üzenetére
Szívesen.
"Jelenleg Eclipse-t használok."
Az is teljesen jó.Még szerkesztettem az előző hsz.-t, beleírtam, hogy tudod normálisabban kezelni a hibákat, még azt azért nézd meg.
Mondjuk én a mysqli-ről a helyedben inkább áttérnék PDO-ra, mint előbb látható volt, szebb tud lenni. A PDO-nál az előbb írt felparaméterezéssel ráadásul hibák esetén exceptionök dobódnak, az ilyen jellegű hibákat meg egy try {...} catch(...) {...} blokkban tök szépen le lehet kezelni.
(Amúgy a fentebbi kódot kézzel pötyögtem be, nem próbáltam ki, de remélhetőleg működik egyből.) -
#15870
Sk8erPeter
nagyúr
Joci93
#15869
Sk8erPeter
nagyúr
válasz
Joci93
#15869
üzenetére
Akkor már csináld objektumorientáltan, ha a lényege szintén az (és amúgy is sokkal szebb):
$mysqli = new mysqli('localhost', '*****', '******', 'test');
A hibaellenőrzés mondjuk nem objektumorientált, de még mindig jobb, mint az "or die(...)":
// check connection
if (mysqli_connect_errno()) {
$errorMsg = mysqli_connect_error();
// hiba volt, csinálj valamit a hibával ($errorMsg-ben lévő hibaüzenetet naplózd, írj ki felhasználóbarát üzenetet, ne hagyd folytatni a script vonatkozó részének végrehajtását, stb.)
}"Az "egyedi" változónevekről én tudom, hogy micsoda és az szerintem bőven elég"
Hát ez egy nagyon rossz hozzáállás. Nem elég! A kódod legyen később általad és akár más által is olvasható. Amúgy meg semmivel nem kerül több időbe normális változóneveket adni (jó, néha nem jut eszébe azonnal a legfrappánsabb név az embernek, akkor lehet, hogy 1-2 másodperccel több).
És ne Notepad++-t vagy valami hasonlót használj, hanem olyan fejlesztőkörnyezetet (IDE), ami normális támogatást ad a kódolásodhoz, és pl. Ctrl+Space-re kiegészíti a kódodat. -
#15868
Sk8erPeter
nagyúr
Joci93
#15866
Sk8erPeter
nagyúr
válasz
Joci93
#15866
üzenetére
A $bd->prepare előtti részt is oszd meg légyszi, hogy hogyan csatlakozol az adatbázishoz (nyilván a felhasználónév-jelszó infót csillagozd ki, vagy valami), és hogyan inicializálod a $bd változót. Egyébként ne használj ilyen változóneveket, mint a $bd, mert nem lehet belőle tudni, hogy az micsoda. Egy változónév legyen beszédes. Olyanokat se használj, hogy $res3, $uzenet2, $uzenet3, mert ez így katyvasz (miért pont 2? Miért pont 3?). Bár remélem csak a demókódodban vannak ilyenek. Illetve elírások: reciever --> receiver, RECIEVED --> RECEIVED.
Amúgy annyira gusztustalan ez a mysqli-s szintaktika (ezzel az $uzenet->bind_param('si', $uzenetszam, $zero); résszel), ha már ilyesmi, akkor PDO-val ezt sokkal szebben meg lehetne oldani, valami ilyesmi lenne ($idOfReceiver változó megfelelője a te kódodban az $uzenetszam):$idOfReceiver = 123123;
$hasReceivedMessage = 0;
$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,
)
);
$stmt = $db->prepare("SELECT COUNT(reciever) AS uzenet FROM uzenet WHERE reciever =:receiver AND RECIEVED =:received");
$stmt->bindValue(':receiver', $idOfReceiver); // vagy bindParam
$stmt->bindValue(':received', $hasReceivedMessage); // vagy bindParam
$stmt->execute();
/*
// vagy egyben:
$stmt->execute(array(
":receiver" => $idOfReceiver,
":received" => $hasReceivedMessage,
));
*/
$numberOfMessages = $stmt->fetchColumn();
echo 'Number of messages: ', $numberOfMessages; -
#15864
Sk8erPeter
nagyúr
Sleed
#15863
Sk8erPeter
nagyúr
Nagyon egyszerű a dolog DOMDocument és DOMXPath használatával is, most meló utáni agypihentetőnek megcsináltam.
Elég könnyű volt:A PHP-fájl, ami az átalakítást elvégzi:
<?php
$originalFilename = './test.html';
$newFilename = './test_MODIFIED.html';
$dom = new DOMDocument();
$dom->loadHTMLFile($originalFilename);
$xpath = new DOMXPath($dom);
$nodes = $xpath->query("//table[@id='starwars-table']/tbody/tr/td");
foreach ($nodes as $tdNode) {
$anchorNode = $dom->createElement('a', $tdNode->nodeValue);
$anchorNode->setAttribute('href', 'http://starwars.com/' . $tdNode->nodeValue . '-robot/' . strtolower($tdNode->nodeValue) . '.php');
$anchorNode->setAttribute('target', '_blank');
$tdNode->nodeValue = '';
$tdNode->appendChild($anchorNode);
}
// Create new file
//$dom->saveHTMLFile($newFilename);
// Print output
echo $dom->saveHTML();A tesztbemenet HTML-kódja, vagyis a kódban hivatkozott test.html tartalma:
<!DOCTYPE html>
<html>
<head>
<title>Asdasd</title>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
</head>
<body>
<div>
<table id="starwars-table">
<thead>
<tr>
<th>Test table header 1</th>
<th>Test table header 2</th>
<th>Test table header 3</th>
<th>Test table header 4</th>
</tr>
</thead>
<tbody>
<tr>
<td>TR-25-A</td>
<td>TR-25-B</td>
<td>2-2-SA</td>
<td>2-2-QWE</td>
</tr>
</tbody>
</table>
</div>
</body>
</html>A kód által előállított kimenet:
<!DOCTYPE html>
<html><head><title>Asdasd</title><meta charset="UTF-8"><meta name="viewport" content="width=device-width, initial-scale=1.0"></head><body>
<div>
<table id="starwars-table"><thead><tr><th>Test table header 1</th>
<th>Test table header 2</th>
<th>Test table header 3</th>
<th>Test table header 4</th>
</tr></thead><tbody><tr><td><a href="http://starwars.com/TR-25-A-robot/tr-25-a.php" target="_blank">TR-25-A</a></td>
<td><a href="http://starwars.com/TR-25-B-robot/tr-25-b.php" target="_blank">TR-25-B</a></td>
<td><a href="http://starwars.com/2-2-SA-robot/2-2-sa.php" target="_blank">2-2-SA</a></td>
<td><a href="http://starwars.com/2-2-QWE-robot/2-2-qwe.php" target="_blank">2-2-QWE</a></td>
</tr></tbody></table></div>
</body></html>Kicsit összenyomja a kódot, de gondolom ez nem para, az elvártak szerint lesz így már linkelve a szöveg.
Persze itt a táblázat azonosítója a starwars-table, ezt rögzítettem az XPath-ban.
Arra figyelj, hogy itt a HTML-kódban megadtam az egyébként opcionális <tbody> taget is (amúgy érdemes használni, szemantikailag picit szebb a kód tőle, ha van fejléc is, akkor meg azt érdemes <thead>-be rakni, úgy főleg szépen elkülönül a törzstől), ezt az XPath-ban is rögzítettem, de ha nálad nincs <tbody> tag használva, akkor szedd ki az XPath-ból is a tbody/ részt.
Ja, és kommentezve direkt odaraktam a $dom->saveHTMLFile($newFilename); sort is, amely a $newFilename változó tartalmában megadott névvel új dokumentumot hoz létre az új kimenettel (magyarul el tudod menteni másik fájlba a lecserélt változatot).Demonstrálás céljából felraktam neked ide a komplett kódot:
Itt persze a sima loadHTML metódust használtam a loadHTMLFile helyett, mivel itt nem fájltartalmat töltök be.
-
#15862
Sk8erPeter
nagyúr
PumpkinSeed
#15861
Sk8erPeter
nagyúr
válasz
PumpkinSeed
#15861
üzenetére
Nem biztos, hogy kell reguláris kifejezés, a DOM-bejáró módszerek is simán elegendőek lehetnek ([link]), ez lenne a szebb/hatékonyabb/biztosabb módszer, de ehhez a korábbinál egy fokkal pontosabb specifikáció kellene.
-
#15860
Sk8erPeter
nagyúr
Sleed
#15859
Sk8erPeter
nagyúr
"a többit is hasonlóan"
Milyen a többi? Azt is ismerni kell, különben nehéz általános átalakítást javasolni rá. Legalább még pár példát mondanod kéne.Például ha van egy <td>kutya-füle</td>, akkor abból lesz
<td><a target="_blank" href="http://starwars.com/kutya-füle-robot/kutya-füle.php">kutya-füle</a></td>
? Vagy mi? Mert az alapján, amit írtál ("többit is hasonlóan"), ez lenne a logikus.
-
#15856
Sk8erPeter
nagyúr
kemkriszt98
#15855
Sk8erPeter
nagyúr
válasz
kemkriszt98
#15855
üzenetére
Látod, már megérte szólnom érte.
Muszáj mindig kijavítanom az ilyesmit! Mivel az eredeti problémádat már megoldották, nekem nem maradt más hátra, mint javítani a helyesírási hibát. -
#15854
Sk8erPeter
nagyúr
kemkriszt98
#15851
Sk8erPeter
nagyúr
válasz
kemkriszt98
#15851
üzenetére
mindíg--> mindig, szép rövid i-vel -
#15803
Sk8erPeter
nagyúr
kemkriszt98
#15802
Sk8erPeter
nagyúr
válasz
kemkriszt98
#15802
üzenetére
Köszönjük, hogy ilyen szépen részletezted az esetet, hogy milyen hibaüzenetet kapsz, ha kapsz egyáltalán, és belekerülsz-e a feltételblokkba, vagy sem.
-
#15759
Sk8erPeter
nagyúr
Vikus
#15758
Sk8erPeter
nagyúr
Huh, kicsit túl hosszan sikerült mindezt leírnod.
Csak hogy tisztázzuk: én is magamtól, saját erőmből tanultam meg a webfejlesztést, úgy, hogy közöm nem volt hozzá, és SENKI nem vezette a kezemet, hogy ezt, meg azt csináld. Utánanéztem, olvastam, gyakoroltam, utánanéztem, olvastam, gyakoroltam, utá... Így megy ez. -
#15757
Sk8erPeter
nagyúr
Vikus
#15756
Sk8erPeter
nagyúr
1. bekezdésre: mindegy, hogy valaki mennyire vágja a témát, vagy nem, a tény az tény, ha valami elavult, akkor nyilván itt azt fogjuk javasolni, hogy ne használd.
Bár nem tudom, mit várnál helyette.2. bekezdésre: Javát írtál JavaScript helyett a korábbi hozzászólásodban. Erre mondtam, hogy a kettő nem összetévesztendő, mert nagyon nem ugyanaz.
"Namost, ha valamit nem töltök ki, akkor kapok egy üzenetet, egy új, tök fehér lapon, fekete betűkkel, sima egyszerű betűtípussal, hogy mi a probléma. Utána nyomok a böngészőn egy "vissza" gombot, és megint ott vagyok a kapcsolat lapon, hogy "javíthassak"."
Ha JavaScript nélküli megoldás van, úgy szokás megoldani ezt egyszerűen, hogy a kérés validálása+feldolgozása után beállítasz mondjuk egy $_SESSION-változót (mondjuk $_SESSION['status'] és $_SESSION['message'], de tök mindegy), hogy mi a helyzet, jó volt-e a megadott paraméter, vagy sem, aztán visszairányítod (header('Location: http://www.example.com/innenjottel.php') segítségével) az eredeti oldalra, ahol pedig ezeket a $_SESSION-változókat lecsekkolod, hogy léteznek-e, ha igen, akkor valamilyen módon felhasználod az értéküket (pl. nyilván az üzenetet kiírod), majd megszünteted ezeket a beállított változókat (unset() segítségével)."Köszönöm egyébként a kioktatást, lehet hülyének is nézni, meg mondani, hogy menjek szakemberhez és fizessek neki, aztán majd megoldja, de ha ennyire bonyolult lenne a történet, akkor marad így aztán kész"
Te most tulajdonképpen mégis min sértődtél meg? Hol mondtam én neked ilyeneket, amiket kitaláltál? Nem is értem. Nem volt kioktatás, leírtam a tényeket. Már azon is érzékennyé váltál, hogy megemlítettem, hogy valamit ne használj, mert elavult. Ha nem jött át: ezek jótanácsok. Ha ilyenekre nincs szükség, akkor nem értem, miért kérdezed a véleményünket.Egyébként nem tudhatjuk így fejből, hogy konkrétan mi mennyire megy, így ismeretlenül kicsit nehéz megállapítani, hogy milyen megoldásokat javasolhatunk neked, pl. azt sem írtad, megy-e az angol, és hogy konkrétan melyik résznél akadsz el mondjuk az említett levelezőkkel (PHPMailer vagy Swift Mailer). Azért azt is vedd figyelembe, hogy itt a topicban mindenki a szabadidejében segít, valószínűleg jó szándékból (bár az előző hsz.-emet is sértésnek vetted).
-
#15755
Sk8erPeter
nagyúr
Vikus
#15754
Sk8erPeter
nagyúr
A <font> tag ezer éve elavult, ahogy a color attribútum is. Használj helyette mondjuk <span> taget, aztán CSS-t.
A mail() függvénnyel szarakodni meg egyszerűen nem éri meg, wis már a hsz.-ének 4. pontjában javasolta a PHPMailert VAGY a Swift Mailert, mindkettő jó, és rohadt egyszerű velük a küldés, a hivatalos oldalukon jó példák találhatók.
"Másik, nem akarom semmiképp összezsúfolni a html-ben lévő cumót még ezzel is"
Semmi köze a szerveroldali kódnak ahhoz, amilyen HTML-kimenet a kliens gépére letöltődik. A levélküldős dolgot egyébként is illene valami másik fájlban elintézni, nem egybekutyulni a másikkal."Ezért nekem megfelelő ez a javascriptes dolog"
A PHP mail() függvényének abszolút semmi köze a JavaScripthez."Persze király lenne, ha mondjuk ezt egy java-s - mondjuk amolyan jquery-s képnézegetős formában - kapná a júzer"
A Java NAGYON nem ugyanaz, mint a JavaScript, ne keverd a dolgokat. Te a JavaScriptről beszélsz. A jQuery pedig egy JavaScript-könyvtár.
Ilyen galériákból pedig Dunát lehet rekeszteni.
Csak egy példa az n+1-ből: http://www.jacklmoore.com/colorbox/ -
#15750
Sk8erPeter
nagyúr
biker
#15749
Sk8erPeter
nagyúr
Jaaa, bocs, félreértettelek, nem is ismertem a pixlr API-ját, azt hittem, hogy végül az időhiány miatt kissé egyszerűbb megoldást tákoltál bele valahogy az oldalba, iframe-mel, vagy fingom sincs.
De az fasza, hogy van API-ja, jó tudni: https://pixlr.com/developer/api/
-
#15736
Sk8erPeter
nagyúr
DeltaPower
#15734
Sk8erPeter
nagyúr
válasz
DeltaPower
#15734
üzenetére
Egyetértek, főleg, hogy nem a szerveroldal feladata az egész konkrét megjelenítésbeli dolgokkal foglalkozni.
-
#15733
Sk8erPeter
nagyúr
trisztan94
#15732
Sk8erPeter
nagyúr
válasz
trisztan94
#15732
üzenetére
És az mégis mit oldana meg?
Windows-on a PHP_EOL ugyanúgy "\r\n", más platformon "\n" (mert platformfüggő sortörés). DE a lényeg, hogy itt a probléma az, hogy hiába kerül sortörés a forráskódba, attól még ez a felületen nem fog látszani, ezért kell a HTML-es sortörés. (Egyébként a PHP_EOL tényleg jobban használható, mint a "\r\n", mert ugye az IDE-ben van hozzá autocomplete, na meg nem egy törékeny string, hanem egy kifejező konstans.) -
#15727
Sk8erPeter
nagyúr
DS39
#15726
Sk8erPeter
nagyúr
Ettől még nyilván van értelme átültetni az egészet úgy, hogy legyen benne némi PHP, adatbázis-használat, meg egyebek, mivel épp ez a cél...
A kérdező viszont annyira általánosan tette fel a kérdését, hogy igazából nem tudom, mit lehet erre válaszolni. Nyilván meg lehet oldani, és fog működni, ha jól csinálja...
-
#15716
Sk8erPeter
nagyúr
Drótszamár
#15715
Sk8erPeter
nagyúr
válasz
Drótszamár
#15715
üzenetére
"Fórum szerint napi 2500-as a limit."
Nem csak fórum, ott van a hivatalos oldal, ahol biztos infókat kapsz:
https://developers.google.com/maps/licensingGeocoding Web Service
Maps API: 2500 requests per 24 hour period
Maps API for Business: 100 000 requests per 24 hour period -
#15705
Sk8erPeter
nagyúr
trisztan94
#15704
Sk8erPeter
nagyúr
válasz
trisztan94
#15704
üzenetére
Eddig nem amiatt panaszkodtál a másik topicban, hogy a Here-dokumentációk milyen gyenguszok?
(Btw. ebből nem tudom, mi igaz egyáltalán, mert nem néztem sosem. ) -
#15702
Sk8erPeter
nagyúr
TomyLeeBoy
#15701
Sk8erPeter
nagyúr
válasz
TomyLeeBoy
#15701
üzenetére
Szívesen!
-
#15700
Sk8erPeter
nagyúr
TomyLeeBoy
#15699
Sk8erPeter
nagyúr
válasz
TomyLeeBoy
#15699
üzenetére
Két probléma van:
1. sprintf()-et használsz, ami UTF-8-as karakterekre nem működik megfelelően
2. a regexpben az "u" modifiert kellene használnod:
http://php.net/manual/en/reference.pcre.pattern.modifiers.php
"u (PCRE_UTF8)
This modifier turns on additional functionality of PCRE that is incompatible with Perl. Pattern strings are treated as UTF-8. This modifier is available from PHP 4.1.0 or greater on Unix and from PHP 4.2.3 on win32. UTF-8 validity of the pattern is checked since PHP 4.3.5."Röviden a megoldás: a külön $pattern változó helyett a cikluson belül így nézzen ki a $regex változód, hogy egyből be is helyettesíted az értéket, így kikerülöd az sprintf() használatát:
$regex = '/(?!<.*?)('.$needle_s.')(?![^<>]*?>)/iu';
Így már működni fog. (Ugyanazt csinálja, mint a korábbi kódod, csak össze van fűzve a string a %s behelyettesítése helyett, és elláttam az u modifierrel (lásd a case insensitivity-t jelölő i modifier után).)
Még egy fontos dolog: a font tageket ma már nem használjuk (nagyon régóta deprecated), szóval azt cseréld le span-re, és ugyanúgy működni fog.
-
#15675
Sk8erPeter
nagyúr
DeltaPower
#15674
Sk8erPeter
nagyúr
válasz
DeltaPower
#15674
üzenetére
Hú basszus, látszik, hogy rohadt fáradt vagyok, pont ott van a lényeg, abban, amit én magam idéztem, hogy "The default value is the current directory that the cookie is being set in", és így már összeállt, hogy miért mondtad, amit mondtál.
-
#15673
Sk8erPeter
nagyúr
DeltaPower
#15672
Sk8erPeter
nagyúr
válasz
DeltaPower
#15672
üzenetére
Na várj, de a path pont opcionális paraméter:
http://www.php.net/manual/en/function.setcookie.php
bool setcookie ( string $name [, string $value [, int $expire = 0 [, string $path [, string $domain [, bool $secure = false [, bool $httponly = false ]]]]]] )"path
The path on the server in which the cookie will be available on. If set to '/', the cookie will be available within the entire domain. If set to '/foo/', the cookie will only be available within the /foo/ directory and all sub-directories such as /foo/bar/ of domain. The default value is the current directory that the cookie is being set in." -
#15671
Sk8erPeter
nagyúr
norby10
#15670
-
#15650
Sk8erPeter
nagyúr
lesaux
#15649
Sk8erPeter
nagyúr
válasz
lesaux
#15649
üzenetére
Na várjál, mielőtt anyáznál a tárhelyszolgáltatódnál, azért előtte próbálkozz kicsit, vagy írd körül nekünk jobban a helyzetet, mert úgy tűnik, nem vágod az elérési utak mikéntjét.
"A mostaninál három darab /../ is van, ami mondjuk eleve gyanús, de hát egyszer vissza kell lépnem a public_html mappából, utána a domainnevemet leíró mappából, majd a domains nevűből, és ott figyel egy .php mappa, amiben 5 db php-mail.log fájl sorakozik, de mind 0 bájt hosszú."
Heh?
Most hogy jönnek ide a logfájlok? Te a phpmailer könyvtárban lévő class.phpmailer.php fájlt szeretnéd elérni, ennek kell a megfelelő elérési útja.Na, tehát hogy is van ez nálad?
Van a public_html könyvtárad, gondolom ebben van valahol a phpmailer könyvtár, nem eggyel vissza a public_html-től, na de kérdés, hogy konkrétan a public_html-en belül melyik könyvtárban van. Vagy ömlesztve van a public_html-be? Vagy hogyan?
Írd körül a könyvtárstruktúrát légyszi, és akkor szerintem a szolgáltató bevonása nélkül is meg tudjuk oldani a problémát. Persze az jó, ha ők is gyorsan válaszolnak. -
#15648
Sk8erPeter
nagyúr
trisztan94
#15644
Sk8erPeter
nagyúr
válasz
trisztan94
#15644
üzenetére
"Hát mivel DOM-ot manipulálsz, ezért ez javascripttel kellene csinálni."
Sehol nem írta, hogy kliensoldalon szeretné manipulálni a DOM-ot. Szerveroldalon is lehet különböző feltételektől függően class-t generálni egy kódból kreált HTML-elembe.(#15647) lesaux :
"Szóval egy sima PHP-s levélküldéshez tényleg kell ekkora cirkusz, vagy valamit alapból rosszul csinálok?"
Egyáltalán nem nagy cirkusz, főleg PHPMailerrel vagy SwiftMailerrel. Valószínűleg VALAMIT te rontasz el, például éppen az elérési utat, mivel konkrétan az a hiba.
Amúgy nem a "mail() függvényeid" nem működnek most, hanem konkrétan nem található a PHPMailer osztály az általad megadott elérési úton.A kódodban ez van - ja, és légyszi használd legközelebb a "Programkód" gombot a kódod kijelölése UTÁN! Köszi! -:
$phpmailer_path = $_SERVER['DOCUMENT_ROOT'].'/../phpmailer/class.phpmailer.php';itt tehát a kellős közepén van egy /../, ami azt jelenti, hogy a rootkönyvtárhoz képest még visszafelé lépsz egyet. Ergo az előző tárhelyeden mások voltak az elérési utak, mint az új tárhelyen.
Próbáld ki azt, hogy ezt kiszeded belőle, így:$phpmailer_path = $_SERVER['DOCUMENT_ROOT'].'/phpmailer/class.phpmailer.php';
Persze ismerni kéne a tárhelystruktúrát.
De első próbának jó lesz, vagy nem. -
#15641
Sk8erPeter
nagyúr
DNReNTi
#15636
Sk8erPeter
nagyúr
válasz
DNReNTi
#15636
üzenetére
"Egy kérdésem még így is maradt: Miért? Tehát mi a gyakorlati funkciója ennek?
"
A kérdésed teljesen jogos, feltételezem, a feladat valami fos tanfolyamon/számonkérésen lett kitalálva, és tipikus esete annak, amikor a magát tanárnak képzelő embert jól fel kéne képelni, hogy talán gondolkozzon már el azon, hogy a diákjai milyen feladatokból fognak tanulni - hát nem ilyenekből. Kezdők számára tök feleslegesen komplikált feladat, ahelyett, hogy valami gyakorlati haszonnal bíró miniwebalkalmazást fejlesztetnének velük, és így némi kedvet is adnának a szakmához, meg olyat gyakoroltatnának velük, aminek még valami értelme is van. -
#15615
Sk8erPeter
nagyúr
mobal
#15614
Sk8erPeter
nagyúr
Web Platform Installer segítségével pár kattintás összehozni, a pár másodperces telepítés után pl. pötyögd be, hogy WordPress vagy Drupal, hogy ez behúzza a számára szükséges függőségeit, telepít mindent egy-két perc alatt, aztán max. az átmenetileg felrakott CMS-eket letörlöd.
IIS+MySQL+FastCGI PHP
http://prohardver.hu/tema/weblap_keszites/hsz_11089-11089.html
![;]](http://cdn.rios.hu/dl/s/v1.gif)
(Mr. Bustát is sokan szeretik - leginkább a kiskamasz korosztályból -, aztán mégis szar zenét csinál. 
(Csak hogy félreértés ne essék, hogy összevethető lenne. 
De örülök, ha ezzel hozzájárulhattam a boldogságodhoz. 
Úgy örülök, hogy hosszú idő után megjelentél, hogy gyorsan lecsapj erre a lehetőségre... 
(pl. 439-441. o.) Tényleg remek ez a könyv kezdőknek! 
Erre a kérdésre már nehéz szavakat találni... 
Új hozzászólás Aktív témák
Hirdetés
- Lenovo ThinkCentre M720s SFF / M920T tower -Számla, garancia, WIN11
- ÁRGARANCIA!Épített KomPhone i5 10600KF 16/32/64GB RAM RX 7600 8GB GAMER PC termékbeszámítással
- Telefon felvásárlás!! Samsung Galaxy A70/Samsung Galaxy A71/Samsung Galaxy A72
- Csere-Beszámítás! Gamer PC Számítógép! R9 3900X / RX 6700XT / 32GB DDR4 / 1TB SSD
- Bomba ár! Dell Latitude 5400 - i5-8GEN I 16GB I 512SSD I 14" HD I HDMI I Cam I W11 I Gari!
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest