Hirdetés
Új hozzászólás Aktív témák
-
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.[ Szerkesztve ]
Sk8erPeter
-
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ő.
[ Szerkesztve ]
Sk8erPeter
-
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.[ Szerkesztve ]
Sk8erPeter
-
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?
[ Szerkesztve ]
Sk8erPeter
-
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.
Sk8erPeter
-
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.Sk8erPeter
-
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ó. )
Sk8erPeter
-
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)).[ Szerkesztve ]
Sk8erPeter
-
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?[ Szerkesztve ]
Sk8erPeter
-
-
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.
Sk8erPeter
-
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.Sk8erPeter
-
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.[ Szerkesztve ]
Sk8erPeter
-
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.)Sk8erPeter
-
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.
[ Szerkesztve ]
Sk8erPeter
-
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.Sk8erPeter
-
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.Sk8erPeter
-
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.)[ Szerkesztve ]
Sk8erPeter
-
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."Sk8erPeter
-
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.Sk8erPeter
-
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.Sk8erPeter
-
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.Sk8erPeter
-
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ó. )
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #16442 üzenetére
Lépj már feljebb legalább a nagycsoportos óvodásokhoz.
"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ó. OraveczCoelhoNó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. ))Sk8erPeter
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
válasz PumpkinSeed #16447 üzenetére
Szerencsére a többiek elég alaposan válaszoltak az érdemi részre.
"Illetve egy függvény, hogy tud több String típust is visszaadni, például egy adatbázisból kiolvasott név és lakcím adatot például?"
Csak a pontosság kedvéért: nincs olyan, hogy "több String típus", string van, és kész, szerintem Te arra gondoltál, hogy mondjuk több string "értéket" szeretnél visszaadni. Tehetsz ilyet összetett típussal, tömbbel vagy objektummal is vissza tudsz térni egy függvényből. Egy függvénynek egy darab visszatérési értéke van.
Szerk.: ja, most látom, disy68 ezt is leírta neked.
Amúgy ilyen, hogy "adatbázisból kiolvasott név és lakcím adat", tipikusan valami objektumhoz kellene, hogy tartozzon ahhoz, hogy ez normálisan kezelhető legyen (ne pedig többdimenziós asszociatív tömbborzalmakat kelljen kezelned), például van egy Person osztályod (most csak a példa kedvéért), és ezt megfelelően példányosítod (példányosítás után lesz belőle objektum). Ha sok személy van, akkor objektumok tömbje is egy jó megoldás lehet (értsd: egy tömbbel térsz vissza, ebben pedig egy vagy több objektum van).(#16451) disy68 :
Szépen összeszedett válasz![ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz tothjozsi96 #16457 üzenetére
"Lehet valahogy úgy átalakítani szöveget, tehát nem str_replace-el hanem ilyen fgv.-ek nélkül?"
Direkt idéztem a kérdésedet, csak hogy még egyszer lásd - szerinted mi értelme van ennek a kérdésnek?Sk8erPeter
-
Sk8erPeter
nagyúr
válasz tothjozsi96 #16462 üzenetére
Nem fogsz tudni kitalálni jobb általánosan alkalmazható, bizonyos szabályokat megfogalmazni képes "egyedi kivitelezést". Azért ez nem egy triviális feladat. Maradj csak a könyvtári függvényeknél, vagy max. keress valami komplex library-t... Amúgy a javasolt strtr sem tudom, mitől lenne jelen esetben jobb, mint az str_replace...
Mellesleg a te esetedben pont nem az str_replace a probléma, ami a lassúságot okozza, hanem az iszonyat sok smiley és hozzá tartozó külön-külön reguláris kifejezés, preg_replace-szel annak illeszkedésére való keresgélés és csere... (Magyarul a preg_replace jobban lassít, mint az annál jóval egyszerűbb cserére alkalmas str_replace.)
De ezt már egyszer kifejtettem neked. Ismétlés a tudás anyja.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz DNReNTi #16466 üzenetére
Nézd meg a linken található kódot, ott nem nagyon van olyan rész, amire ez megoldást jelentene... Amúgy meg korábban azt írta a srác, hogy megoldódott a probléma, mert eleve feltöltésnél átalakítja a szövegeket (amit párszor korábban is javasoltam neki, de akkor valamiért neki nem jött át ), és akkor nem észrevehető a különbség, szóval most nem tudom, miért került elő újból a probléma...
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz disy68 #16469 üzenetére
Mondjuk sokkal jobban is tenné, ha nem ilyen módon adna meg elérési útvonalakat, mint a /var-ral kezdődő, ami igencsak rossz megoldás, akkor már legyen a webalkalmazáshoz képest relatív (és persze az az útvonal legyen helyes is) - pl. ez ilyen módon kb. lehetetlenné teszi egy Windows-os szerverre való átköltöztetést (hacsak ott nincs var könyvtár az adott partíció rootjában (még a forward slash nem lenne probléma az útvonalnál, hiába Windows)).
Szerk.: félre ne értsd, ez nem neked szól, mert Te a lehetséges problémát tártad fel, inkább a kérdezőnek.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz disy68 #16473 üzenetére
Igen, a DIRECTORY_SEPARATOR atombiztos megoldás, de mivel Windows-on is nyugodtan lehet használni a forward slash-t (/) az elérési útvonalaknál (attól még, mert Windows esetén a backslash (\) a bevett konvenció), ezért nem biztos, hogy megéri vele szenvedni (pl. ronthatja az olvashatóságot). Tudsz mondani olyan esetet, ahol a forward slash használata elvérezne?
(Windows+IIS alatt én még nem találkoztam ilyen esettel (vagy csak nem emlékszem ), de ettől még lehet.)(#16471) fordfairlane:
Ja igen, az végül lemaradt, köszi a kiegészítést.
Mondjuk azért az esetek nagy részében a feltöltött kép elég közeli viszonyban van a konkrét webalkalmazással, szóval a webalkalmazás rootjához képest relatív útvonal talán az esetek többségében talán egy fokkal használhatóbb.(#16472) PumpkinSeed :
Mi az, hogy "más lehetőséget oda nem tudok elképzelni"? Ezt mire írtad?
"uploaded_img/-el kezdtem"
Az épp futtatott szkripthez képest az uploaded_img könyvtár elérhető volt, jól adtad meg az útvonalat? Oda tudsz bármit is írni? Pl. csak próbából file_put_contents() segítségével tudsz egy akármilyen fájlt létrehozni a célkönyvtárba?[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz PumpkinSeed #16475 üzenetére
Az utóbbi két hibaüzenet alapján elég egyértelmű: a $file_name változód üres. A $target = $target.$file_name; soroddal tehát ez esetben olyan, mintha azt írtad volna, hogy $target = target;, mivel nem fűztél hozzá semmilyen nevet (így marad a könyvtárnév). Így nem csoda, hogy nem tudja mozgatni.
Az első hibaüzenet meg csak annyit mond, hogy nem létezik uploaded_img/people.txt fájlod... Az igazából nem tudom, hogy jött ide, a lényeg az volt, hogy a célkönyvtárba tudsz-e írni. (file_put_contents() használatát javasoltam) Gondolom valóban nem létezik a people.txt fájl, vagy még mindig rosszul adod meg az elérési útvonalat... Ez esetben nem ártana, ha elmondanád, hogy milyen a könyvtárszerkezet (mi hol van), akkor még meg is tudnánk mondani, mit rontasz el.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz PumpkinSeed #16477 üzenetére
Jó, és a tanácsokat elolvastad, hogy hogyan javítsd ki az útvonalat? Akár relatív útvonalakat használva a webalkalmazáshoz, akár $_SERVER['DOCUMENT_ROOT']-ot felhasználva. Nyilván amíg az elérési utat nem javítod ki, és még egy egyszerű tesztcélú fájlírás sem működik a célkönyvtárba, addig hiába megy az oda-visszaírogatás.
Amúgy meg kéne tanulni az Xdebug használatát, nem pedig kiírogatni, hogy épp milyen a változó értéke, hanem normálisan debuggolni, arra találták ki, hogy egyszerűbb legyen a fejlesztés, és az ember rájöjjön a hibáira. Korábban is javasoltam, a kolléga igen gyorsan rá is jött, hogy kell használni. Követhetnéd a példáját, és akkor menetközben kapásból látnád, milyen útvonalakra próbál írni, az egyes visszatérési értékeket pedig korrektebb módon ellenőrizhetnéd.
Azt sem ártana tudni, milyen HTML-kód van a frontenden. Pl. a mező neve (name attribútum) valóban egyszerűen "file"? Hogy néz ki akkor a most használt, komplett kódod (miután elvileg javítottad)?(#16483) tothjozsi96 :
Hol olvastad ezt a hülyeséget? Nem árt megnézni, az ember milyen forrásokból tájékozódik, és milyen fórumos kommentárokat vesz komolyan.(#16478) tothjozsi96:
Akkor már végképp nem értem, most épp milyen kódról beszélsz, mert
ez a kód, amit ide bemásoltál, tele van preg_match-csel és preg_replace-ekkel.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Peter Kiss #16505 üzenetére
Szerintem mindenki jobban jár, ha leírod a megfelelő megközelítést.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz PumpkinSeed #16526 üzenetére
Jól mondod. Ez a kód szerintem az utóbbi idők összes példaként linkelt kódját felülmúlja ocsmányságban. Megkapja a PHP topic Arany Málna díját.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz tothjozsi96 #16552 üzenetére
"Nem tudom mi folyik itt."
Igazából ebből a leírásodból ember legyen a talpán, aki megérti, miről beszélsz, hogyan is tesztelted, úgyhogy mi sem tudjuk, mi folyik nálad.==========================
(#16554) mrpiko :
Egy ilyen igénytelenül összeb@szott "álláshirdetésre" ne várd, hogy értelmes ember jelentkezzen. Nem túl jó ómen, ha még egy becsábító üzenet megfogalmazásába sem vagy hajlandó fektetni 30 másodpercnél többet, és még egy vesszőt sem vagy képes használni a tagmondataid elválasztásához.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz tothjozsi96 #16556 üzenetére
"Így írtam bele.
echo password_hash($_POST["password"], PASSWORD_DEFAULT);
Alapból így van megadva amúgy:
$password = !empty($_POST["password"]) ? $_POST["password"] : '';
Azt hittem hogy valami baja lesz az empty-vel, de nem ..."
Már kapásból ennek a pár sorodnak sincs értelme. Ellenőrzöd a kulcs meglétét, átadod a tömbben ezalatt található értéket egy változónak, csak azt a változót ($password) nem használod fel a password_hash()-nél... ezért mondom, hogy ember legyen a talpán, aki érti a gondolatmenetedet. Egyébként meg nyilván ellenőrizni kell egy kulcs/változó meglétét, mielőtt felhasználod, nem tudom, mit kell csodálkozni az Undefined index-szel kapcsolatos Notice-on.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz tothjozsi96 #16559 üzenetére
Jó, és mivel ellenőrizted, hogy valóban 63 karakter lett? Mikor lett annyi, adatbázisba való feltöltés után, vagy még az alkalmazás "szintjén"? Az a baj, hogy csomószor harapófogóval kell kiszedni belőled az érdemi, nem mellébeszélő infókat, még sokszor így sem sikerül, és így az embernek csomószor elmegy a kedve a segítéstől.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz tothjozsi96 #16561 üzenetére
"Kiírattam a takelogin-ban és nyomtam egy CTRL+A-t, és beraktam egy Notepad++-ba ami kiírja hogy hány chars pontosan."
Atyaég... stringhossz-visszaadó függvényekről hallottál már?Sk8erPeter
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
válasz PumpkinSeed #16567 üzenetére
Mostanában kb. hasonló szinten tartunk a topicban ezekkel a "kimásoltam Notepad++-ba, és úgy láttam, milyen hosszú a karaktersorozat"-jellegű megnyilvánulásokkal.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz honda 1993 #16571 üzenetére
"szugsegem lesz -e meg masra", "megirom az ehez szugseges kodot", "szugseg lehet Mysql-re is, (en pedig azt sem tudom hogy az pontosan mi is lehet)"
Ne szívassál már, először még jóindulatúan azt hittem, csak elgépelés volt a "szugseg" (még leírni is nehézkes ezt a szart, szóval elgépelés kilőve), akkor megpróbálom a fejedbe verni, szóval így a helyes: SZÜKSÉG. K-val, érted?! NEM G-vel!! Az "ehhez" pedig KÉT DARAB H! Hogy akarod megtanulni a PHP nyelvet, ha még a saját anyanyelvedet sem ismered?
Az meg már a szinte kommentálhatatlan kategória, hogy fogalmad sincs, mi az a MySQL. Mégis mi a lóf@szra való a Google? Asszem tényleg abba kéne hagyni a topic követését, mert ez már szánalmas, hogy hol tartunk. De még egy rohadt kérdést sem képesek mostanában megfogalmazni értelmesen az emberek, hogy mégis mi a frászt akarnak tudni. Most már bennem is eltört valami.Sk8erPeter
-
Sk8erPeter
nagyúr
Szerintem meg teljesen felesleges a perjel a végére. Mégpedig azért, mert ha van a végén, akkor az azt az érzetet kelti, hogy annak az oldalnak vannak még további aloldalai is (például nemcsak example.com/about/ van, hanem example.com/about/foo is). Persze ha így van, akkor még oké, de egyébként szebb úgy, hogy egy útvonal be van fejezve. Ez amúgy is az általánosan bevett szokás, nem igazán látni olyan nagyobb site-ot, ahol oda lenne erőltetve még egy perjel is az URL végére, akkor is, ha a felhasználó azt eredetileg nem adta meg.
(#16593) CSorBA:
Dehogyis, rájöttem, hogy inkább nem szívatom magam. Van, amikor és akinek megéri, és van, amikor egyszerűen hatástalan, úgyhogy csak a saját időmet szúrom el vele. (Mondjuk végül is szigorúan véve simán az önzetlen segítségnyújtás amúgy is saját időm elszúrása. )(#16602) DNReNTi:
Szerintem megérdemelne összefoglalót, de a nyelv alapvető dolgainak összeszedése annyira hosszú lenne, hogy nem hiszem, hogy beleférne egy összefoglalóba, így lehet, hogy inkább valami jó linkgyűjteményt kellene első körben belerakni. Még mielőtt megkérdeznéd, nekem nincs időm ilyesmire, úgyhogy skippelem.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz tothjozsi96 #16612 üzenetére
Miért nem ellenőrzöd először még beszúrási kísérlet előtt, hogy van-e már ilyen felhasználó?
Szerk.: ja, látom (#16615) PumpkinSeed ugyanezt írja.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz tothjozsi96 #16619 üzenetére
"Nem szeretem a lekérdezéseket, az az igazság"
Akkor hagyd abba a webfejlesztés tanulását még most.(#16617) tothjozsi96:
EZ MI? (Szerk.: nehogy elkezdd magyarázni, tudom, mi ez a hibakód.)
Persze biztos ennél ocsmányabbul is megoldhattad volna, végül is jó úton jársz a spagettikód felé. Drukkolok, hátha lehet még rosszabb is.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz tothjozsi96 #16649 üzenetére
"Én ezt ajánlom: [link]
Bocs, de engem rohadtul tud zavarni ha valaki nem használ ékezetet, vagy az hogy ilyeneket ír hogy "XD"."
Hú, hogy mennyire szívemből szóltál.
Ez az ikszdézés amúgy különösen rettentő retardált dolog, amikor ott vannak az előredefiniált smiley-k, ha nagyon akarja. Mondjuk felőlem ikszdézhetne többet is, ha legalább tudna magyarul és értelmesen írni+fogalmazni.(#16657) tothjozsi96:
Igaz, hogy ez JavaScripthez kapcsolódik, de a különböző nyelvek (itt: HTML, CSS, JS) tényleges elválasztásáról szerintem egy nagyon jó link (amit még régen berakattam a JavaScript topic összefoglalójába is, hogy szem előtt legyen):
http://www.slideshare.net/fgalassi/refactoring-to-unobtrusive-javascript
Most nyilván egy PHP-kódot totálisan szétválasztani a generált HTML-kódtól igen nehéz lenne, és a template-ezéssel sincs szétválasztva, csak legalább kezelhetőbbé van téve a kód, nincs totális kutyulódás a kódban, így a logika elválik. A rétegezést nem véletlenül találták ki.(#16659) fordfairlane:
"Jó akkor úgy írom, hogy szétebbenválasztani. A nézetet széttebben szokták választani"
Azért ezek is szép magyar szavak.[ Szerkesztve ]
Sk8erPeter
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Ozeki Kft
Város: Debrecen
Cég: Ozeki Kft
Város: Debrecen