- Parci: Milyen mosógépet vegyek?
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Luck Dragon: Asszociációs játék. :)
- vrob: Az IBM PC és a játékok a 80-as években
- bambano: Bambanő háza tája
- Gurulunk, WAZE?!
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- vrob: 1991 - játék a PC-n
- gban: Ingyen kellene, de tegnapra
- Argos: Szeretem az ecetfát
Új hozzászólás Aktív témák
-
DNReNTi
őstag
válasz
fordfairlane #17299 üzenetére
Mint tudjuk az ügyfélnek mindig igaza van. Namármost, ha ő azt mondja, hogy az adatbáziskezelés biztonsági okokból, adatbázis nélkül kell megvalósuljon, akkor az úgy is van.
Aztán lehet neki sok sikert kívánni, hogy találjon valakit, aki implementálja.
-
DNReNTi
őstag
válasz
Joci93 #17296 üzenetére
Kíváncsi lennék mivel magyarázza meg, hogy ott lehet biztonsági rés. Arra is kíváncsi lennék mégis mit javasol akkor helyette, ami biztonságosabb. Abban meg egészen biztos vagyok, hogy biztonsági rés sokkal hamarabb keletkezik kliens oldalon, vagy akár szerver oldalon - lásd nem régiben a YouTube fatális béna hibája. Na mindegy, szerintem ne foglalkozz vele, de asszem ezt már a többiek is javasolták.
-
Joci93
senior tag
Köszönöm a sok választ.
Próbáltam meggyőzni, hogy használjuk adatbázist, de hallani sem akar felőle, mert ott keletkezhet biztonsági rés...Hiába hoztam fel, hogy prepared statementeket alkalmazok a beviteli mezőknél, akkor sem akart róla hallani... egyre inkább azon vagyok, hogy ezt el kellene felejteni...
Tegnap volt még 1 nagyon jó megszólalása... egy másik projectben kérték, hogy valamilyen adat jelenjen meg grafikusan is, ehhez Angular-Charts-ot használtam, mert egész szép grafikonokat lehet vele megjeleníteni + a használata sem bonyolult. Erre megkérdezi tegnap, hogy lehet-e ezt úgy bővíteni, hogy ha szeretné, akkor egy állatnak a részei jelenjenek meg. Pl.: Egy ló 2D nézetben és ha rávisszük a testrészeire az egeret, akkor azt tooltip-ben kiírja. Na ekkor majdnem mondtam, hogy köszönöm, ne keressen tovább... -
DNReNTi
őstag
válasz
fordfairlane #17294 üzenetére
Jogos, erre nem gondoltam. De legalább már van (lesz).
-
fordfairlane
veterán
válasz
DNReNTi #17293 üzenetére
Sőt díjaznám ha kötelező lenne, nem optional.
Ez nyilvánvalóan hülyeség lenne. Senki nem migrálna az új verzióra, mert az összes kód hibás volna.
Egyébként a PHP 7 -be is akarnak pár olyan változást eszközölni, ami a korábbi programokkal kompatibilitási problémákat eredményezhet, ami oda fog vezetni, hogy még töredezettebb lesz a platform. A core-team viszont ragaszkodik hozzá, csak mert csak.
-
DNReNTi
őstag
válasz
Sk8erPeter #17292 üzenetére
Ez is gyönyörű:
function order_func($a, $b) {
return ($a->$x <=> $b->x) ?: ($a->y <=> $b->y) ?: ($a->foo <=> $b->foo);
}Viszont a típusdeklaráció várós! Sőt díjaznám ha kötelező lenne, nem optional.
-
Sk8erPeter
nagyúr
Things you must know about PHP7 --> hát ez a "spaceship operator" rettentő értelmes:
https://wiki.php.net/rfc/combined-comparison-operatorTehát most már tudok olyat csinálni, hogy
if( ($a <=> $b) === -1 || ($a <=> $b) === 0) { ... }Hát csodálatos.
-
Sk8erPeter
nagyúr
válasz
Joci93 #17285 üzenetére
cidalainnal értek egyet, van olyan feladat, ami eleve értelmetlen, így nem biztos, hogy megéri elvállalni, szépen türelmesen el kell magyarázni a megrendelőnek, hogy baromságot akar. Aztán hátha meggondolja magát, vagy tovább kell állni (már ha van választási lehetőség). Nem akar adatbázist valami degenerált indokból, de azért valahol mégis, meg szeretne query-ket is írni kézzel, amit ja, akár phpMyAdminban is megtehetne, ha ez a kattanása, de nem, ő a spanyolviaszt akarja felfedezni.
De ha már muszáj elvállalnod, és valahova menteni kell, illetve fel is kell tudni dolgozni a tárolt adatot, akkor a txt-t vagy bármi behányt szöveget azonnal felejtsd el, valami normálisan és hatékonyan feldolgozható formátumban mentsd el, legyen az JSON, XML, stb. Ha már az SQLite is szóba kerülhet, mint lokális, fájlba írós adatbázis, akkor már nem igazán értem, miért ne lehetne egy tisztességes adatbázis (nem lebecsülve az SQLite-ot, de nagyobb adatmennyiség esetén már nyilván nem ez a hatékony megoldás), onnantól már csak egy lépés.
Mi is pontosan az indoka a megrendelőnek arra, hogy nem lehet adatbázist használni?Amúgy ha már SQL parsert kell használnod, akkor nehogy elkezdd kézzel összetákolni, mert rohadt nagy szopás tud lenni egy parser, inkább használj fel egy kész könyvtárat:
https://code.google.com/p/php-sql-parser/
http://stackoverflow.com/questions/283087/php-mysql-sql-parser-insert-and-update/283115#283115Szerk.:
(#17290) PumpkinSeed: pont megelőztél.Amúgy egyetértek.
-
PumpkinSeed
addikt
válasz
Joci93 #17285 üzenetére
"Ahogy mondod. Meg kéne írni, hogy a SELECT,FROM, WHERE mit csináljon
"
Elnézést kedves Edgar F. Codd elsőre nem ismertem meg önt, az a helyzet, hogy nem 1970-ben vagyunk, rossz időben tetszik lenni. Már létezik az SQL, nem most kell kitalálni.
Na de most komolyan, miért kér egy megrendelő ilyen ostobaságot? Látszólag azt se tudja miről beszél, te meg hagyod, hogy ilyen hülyeségeket kérjen tőled. Az más lenne, ha komolyan megmondaná mit használj mondjuk NoSQL-t vagy valami de így, hogy ne használj adatbázist ez csak értelmetlen szavakkal való dobálózás. Fel kell világosítani, hogy kell ha adatokat akar tárolni és reális időn belül akarja visszakeresni. Használhattok .txt-t is, de ha az adatbázist a biztonságtalansága miatt nem kedvelte akkor ez azonnal meg is bukott, sőt még lassú is.
-
-
cidalain
veterán
hát pont ezaz. én biztosan nem hagynám így elkanászodni a megrendelőt.
biztos lehet nemet is mondani egy felkérésre. van az a pont hogy valami értelmetlen. ez pont olyan szitu.
vagy bemondanék egy rohadt nagy számot + hosszú fejlesztési időt, aztán szívjon vele más. ha meg mégis elfogadják, na mondjuk akkor gáz van, de legalább lesz pénz, és van rá idő -
cidalain
veterán
válasz
Joci93 #17285 üzenetére
űrlap lehet a sima text beviteli mező is, az meg nem kötött. azt ír be amit akar.
az a baj hogy adott a tárhely, és nincs rajta adatbázis?
ha igen, én nem szarakodnék fájl alapú tárolással, elő kell fizetni egy normális adatbázisos tárhelyre. 10/év alatt már vannak. nem éri meg a vesződséget, amit nyerne a vámon a megrendelő elbukná a réven... -
Joci93
senior tag
válasz
cidalain #17277 üzenetére
Az a baj az űrlappal, hogy oda csak előre definiált 'szavakat' lehet beírni..a megrendelő maga akarja beírni ezeket.
Igen..pont ez a bajom, hogy nincs adatbázis...és így honnan nyerem ki az adatot? Gondolkodtam, hogy .txt-be pakolom be, de az meg nem túl eredményes.Zedz: A megrendelő szerintem nem túl biztonságos..
Heimdallr75: XML még nem is gondoltam, utánanézek.
PumpkinSeed: Ahogy mondod. Meg kéne írni, hogy a SELECT,FROM, WHERE mit csináljon
fordfairlane: Pontosan.
-
biker
nagyúr
válasz
Sk8erPeter #17282 üzenetére
Hátha megteszi, bár ahol mysql nincs, ott sanszos, hogy ez sem könnyű
Mondjuk mongodb?
Max kifekszik az ékezeteknél -
biker
nagyúr
noSQL???
-
PumpkinSeed
addikt
válasz
Joci93 #17276 üzenetére
Szögezzük le: Nem akarsz DB-t! De...
- "kiadja a lekérdezés eredményét"
Milyen lekérdezés eredményét? Nincs adatbázis amiből adatokat kérdezzen le.- "SELECT name FROM Test WHERE id = 1"
Hogy kerül ide SQL, mikor nincs adatbázis kezelő program se ami feldolgozza... vagy van adatbázis kezelő programod adatbázis nélkül?- "hogy a szintaxisa hasonló"
Esetleg te írod meg az adatbázis kezelőt és a hozzá tartozó strukturált lekérdező nyelvet illetve az adatok tárolására szolgáló állományokat is te generálod? Vagy hogy van ez? -
cidalain
veterán
-
Joci93
senior tag
Heimdallr75 jár a legközelebb a tervhez. Az SQL lekérdezésnél csak arra gondoltam, hogy a szintaxisa hasonló. Egyszerűsítve van egy SELECT, FROM és WHERE rész. A megrendelő beírja például, hogy "SELECT name FROM Test WHERE id = 1" és kiadja a lekérdezés eredményét, de mindezt úgy, hogy semmi nem lehet mögött, csak HTML és PHP...adatbázis nem.
-
DNReNTi
őstag
válasz
Heimdallr75 #17273 üzenetére
Sokaknak sajnos az adatbázis = PhpMyAdmin.
Az is lehet csak egy csavaros megfogalmazása annak, nem e lehet kiváltani a MyAdmint. Ha így van, akkor: má' hogyne lehetne. Sőt. Ajánlott. Workbench például. -
cidalain
veterán
válasz
Heimdallr75 #17270 üzenetére
En ugy veszem le hogy a lekerdezesek keszen vannak.
Tobb is van mindegyikre egy kulon kulcsszoval szeretne hivatkozni.
Csak a szovegszerkesztot nem ertem. Oda kene beirodnia a lekerdezesek eredmenyenek? De a szovegszerkesztonek nincs koze php-hoz.
Vagy wysiwyg editorrol van szo? -
Joci93
senior tag
Hali,
Létezik olyan megoldás adatbázis nélkül, hogy a szövegszerkesztő felismer egy adott kulcsszót és a kulcsszóhoz tartozó, előre definiált parancsot végrehajtja? SQL lekérdezéseket kellene létrehozni (amik lefutnak, és valahogy kiírják az adatot) phpMyAdmin nélkül..
-
biker
nagyúr
cakePHP használatában van itten valaki?
-
cucka
addikt
válasz
#68216320 #17264 üzenetére
Ez esetben generáld le a képeket on-the-fly. Nem tudom, minek kell sz*pasd magad a base64-el. PHP-ból ugyanúgy ki tudsz szolgálni egy bináris jpeg filet, mint egy sima html-t, csak be kell állítani a megfelelő header-öket.
(Arra gondolj, hogy ha van egy html oldalad ahol van 100 ilyen generált kép, na az lassú lesz. Ez esetben fizess be egy nagyobb tárhelyre és generáld le előre a különböző verziókat. Esetleg csinálhatsz intelligens cache-elést, ahol a gyakran használt fileokat legenerálod előre, a ritkábbakat meg ad-hoc. Ez van, szarból nem lehet ostort fonni.) -
#68216320
törölt tag
A tárhelyem mérete kötött, a CPU és RAM használatért nincs külön díjazás.
Akkor segítséget kérnék, hogy a következő helyzetet milyen megoldással lehetne kezelni:
- kötött (kicsi) tárhelyméret
- feltöltött kép sokféle (majdnem tetszőleges) megjelenítése a weboldalon
- képcsere esetén az új kép megjelenítése biztosan (erre a fájlnév kiegészítése megoldás)
- a képek megjelenítéskor bizonyos helyzetekben crop-olva vannak
- a képekre logo kerül, más-más helyzetben más-más logo -
wis
tag
válasz
#68216320 #17258 üzenetére
A CPU idő és RAM többe kerül mint a tárhely, de te tudod...
Ha pedig komolyan probléma a sok kép kezelése, akkor CDN használatát javaslom.(#17260) PeachMan
ha az oldal betöltődik már nem kell a képre várni, az egész egyben jelenik meg
A base64 kódolás 33%-kal nagyobb méretet eredményez, az nem probléma ha tovább tart az oldal betöltése?másrészt nincs cache-elve és képcsere esetén rögtön az újat látom
A cache használatának oka van.A problémák elkerülésére új fájlnevet szokás adni pl. img.jpg?v=123
-
-
#68216320
törölt tag
Egy készülő weboldalamban a képeket a tárhelyen egyetlen méretben (méretezve max 2048x2048px) tárolom és a különböző helyeken a kívánt méretben adom a böngészőnek base64 formában. Ez mennyire járható út így? Tudom, hogy plusz terhelést jelent a szervernek, de tárhelyet spórolok vele, illetve egy későbbi design csere esetén kevesebb a macera, ha más képmérettel jelenik meg az oldal.
-
wopi
aktív tag
Sziasztok!
Adott egy Linux alapú otthon gépem, amin fut http szerver, php támogatással. Szeretnék egy php scriptet, ami segít abban, hogy http-n keresztül tudjak 1-1 fájlt feltölteni a gépre. Fontos volna, hogy listából kiválaszthassam a feltöltendő fájl helyét, illetve a maximalizált legyen a mérete. Esetleg jelszókérés is legyen, bár ez megoldható htaccess fájlból is.
Nem feltétlenül kész kódot várok, csak egy kis iránymutatást, esetleg olyan oldalt, ahol erre találok segédletet.
Köszönöm szépen!
-
Terminus_
aktív tag
Sziasztok! Van köztetek ZF2 Form-okat aktívan használó guru?
Sikerült elakadnom a Fieldset-ek használatával. Történetesen a form-ot szuperül kirajzolom, az (összetett) objektumom adatait szépen bele is tölti, de amikor a user változtat ezeken és elküldi a formot, akkor (bár a post adatokban látok minden válktozást) nem populálódnak az új adatok az objektumomban. Természetesen, ha van valaki, aki ebben járatos, akkor kódot is tudok mutatni.
Van aki ért ehhez a témához?
-
pbert
csendes tag
Weblapfejlesztéssel és szerkesztéssel foglalkozó, magas technikai színvonalú vállalat keres Senior PHP fejlesztőt külföldre
Ezen cég kiemelkedő fizetés és juttatási csomagot és nyelvi készségfejlesztési lehetőséget biztosít leendő munkavállalója számára.
Jelentkezni a fa@pbert.eu címen, fényképes önéletrajzzal lehet! -
DNReNTi
őstag
válasz
Sk8erPeter #17253 üzenetére
Jaja. Epik. A Chrome pl mindig kereste 2x, ezért volt a konstans 3 bejegyzés, a Firefox ebből a szempontból okosabbnak tűnt, az beletörődött az első alkalom után, hogy nincs. Na de nézzük a jó oldalát, láttam egy böngészőfüggő szerver oldali hibát.
Tanulság: tesztnél körültekintően kell kiszórni a "nem szükséges" kottát.
-
Sk8erPeter
nagyúr
válasz
DNReNTi #17252 üzenetére
Vaze.
Egyébként a favicon.ico fájl lekérése a gyökérből (amennyiben pl. nincs beállítva favicon egyéb módon) böngészőfüggő, van, amelyik cseszegeti érte a szervert, van, amelyik nem. Szóval ez esetben, tehát most, hogy kiderült, hogy többek közt a favicon.ico-ra irányuló requestek is lefuttatták az index.php-dben lévő adatbázis-tömködést, nem meglepő, hogy több beillesztés is történt, és hogy ez böngészőfüggő volt.
-
DNReNTi
őstag
Igen, mindezt tudom. És közben meg is van a megoldás. Gyakorlatilag egész idő alatt - nincs erre szebb szó, bocsánat - saját magamat szopattam. Már a kezdettől fogva. Van egy Router nevű osztályom, gondolom a szerepét nem kell magyarázni. Ez az ami az URL paraméterek alapján a megfelelő oldalakat építi fel, illetve nem megfelelő kérés esetén hiba oldalra dob. Pl: egy nem létező favicon esetén is. No én voltam annyira ügyes, hogy ezt kikommenteltem a teszt miatt, ráadásul az index-be írtam magát a tesztet, mer már annyira bepukkantam.
Tehát a htaccess átirányított mindent az indexre ahogy addig is, de nem volt ami feldolgozza. Magyarul kezdettől fogva minden jól működött, egyszerűen csak láma voltam.
-
Des1gnR
őstag
válasz
Sk8erPeter #17236 üzenetére
Végül úgy oldottam meg, hogy HTTrack-el lehúztam az egész oldalt. A termékadatlapokat kigyűjtötte szerencsére egy mappába, majd összefűztem az összes html állományt és onnan már a notepad++-t izzasztottam makrókkal.
-
PumpkinSeed
addikt
válasz
Sk8erPeter #17230 üzenetére
Meg köszönöm, csak most a suli miatti Java tanulás meg annak a sebesség optimalizálás miatt merült fel bennem a kérdés.
(#17231) cucka
Értem, bár nem terveztem semennyit fizetni a programozónak, hogy megcsinálja a kevesebb függvényhívást.
-
cucka
addikt
válasz
DNReNTi #17244 üzenetére
A kérdésedre a válasz egyértelmű lesz, amint megérted, hogy mit is csinál a htaccess-ed.
Röviden: a mod_rewrite apache modult használod. Ez arra jó, hogy ha bejön egy kérés a webszervernek, akkor azt bizonyos feltételek esetén átváltoztatja egy másik request-é.
Például adott egy ilyen URL, hogy http://itcafe.hu/tema/php_kerdesek_2/hsz_17201-17300.html
Valószínű, hogy ez nem egy létező filera mutat egy szerveren, hanem a mod_rewrite átírja valami hasonlóra:
http://itcafe.hu/forum.php?name=php_kerdesek_2&from=17201&to=17300
Csak példa, nem tudom, hogy működik valójában a RIOS..Alapesetben az Apache webszerver egy adott könyvtárban található fileokat tud kiszolgálni. Tehát fenti esetben ha nem lenne mod_rewrite, akkor a hsz_17201-17300.html nevű filet kerené az URL-ben megadott könyvtárban.
A te esetedben ugyanez történik. Létrehozol egy rewrite szabályt, ami csak akkor teljesül, ha a hivatkozott tartalom nemlétező file és nemlétező könyvtár (ez a két RewriteCond). Az átírási szabály az átdobja a PHP-nek a kérést. (Ez a RewriteRule sor)Namost ez azt eredményezi, hogy MINDEN olyan kérést, ami egy nemlétező filera vagy könyvtárra mutat, azt át fogja dobni a PHP-nak. Ha írok egy szkriptet ami random fileokat kérdezget a szerveredtől, kb. mindegyik kérésem be fog hívni a php szkriptedbe (hacsak nem találom ki randomra egy létező file nevét a szerveren). Remélhetőleg innen te is össze tudod rakni, hogy az általad vázolt plusz szabály miért csak látszólagos megoldás a problémádra.
A valódi megoldást már leírták, ha így akarod használni a mod_rewrite-ot, akkor a PHP le kell tudja kezelni a hibás request-eket is. Pl.
<?php
function isRequestValid(){
//ezt neked kell megirni
}
if (!isRequestValid()){
http_response_code(404);
die();
}
//a program többi alkatrésze..
?> -
DNReNTi
őstag
Ahan, így érthető, köszi!
Akkor utánajárok, hogy tudom megakadályozni ha fizikailag nem létező fájlra hivatkozik valaki, akkor 404 legyen. Jó irány? Vagy teljesen rossz felé megyek?"Teória a kétszeres favicon betöltésre: mivel elsőre 200-as kódot kap, de a tartalom nem érvényes kép, így újra megpróbálja."
A teóriád valszeg helyes, ha a htaccess 404-et dob a favicon-ra, akkor nem próbálja meg újra. -
wis
tag
válasz
DNReNTi #17244 üzenetére
Mivel a nem létező fájlnál továbbfut az index.php-ra ami létezik így 200. Innentől a te kódod felelőssége, hogy nem létező oldalnál 404-et dobjon.
Egyes böngészők pedig automatikusan betöltik a /favicon.ico-t.
Teória a kétszeres favicon betöltésre: mivel elsőre 200-as kódot kap, de a tartalom nem érvényes kép, így újra megpróbálja.
-
DNReNTi
őstag
"Gondolom egyrételmű, hogy maga a probléma, hogy szar a htaccess-ed."
Igen, arra már rájöttem korábban: "Kiderült: hibás volt a htaccess-em".Egy másik szabály amivel szintén jó:
RewriteCond $1 !favicon.ico$"ha a kliens lekérdezi a favicont, az miért eredményezi egy php program futását"
Na igen. Csak arra tudok gondolni, hogy mivel maga a fájl nem létezik így a RewriteCond %{REQUEST_FILENAME} !-f szabály nem vonatkozik rá (hiszen az csak a létező fájlokra igaz, ha nem tévedek). Az ikon request valamiért 200-as HTTP statust kap. Azaz annak ellenére, hogy valójában nincs, így gondolom mivel a fentebb írt szabályon már túl van, és a szerver OK statust ad neki, így a htaccess átirányítja. Ilyet nem mostanában szívtam.Tehát a valódi kérdés inkább: miért ad a szerver 200-as statust egy nem látező fájlra?
Szerk:
A szerkesztett írás alapján kipróbáltam egy nem létező fájlra hivatkozva: ugyan úgy megszívat. -
cucka
addikt
válasz
DNReNTi #17242 üzenetére
A helyedben inkább az érdekelne, hogy ha a kliens lekérdezi a favicont, az miért eredményezi egy php program futását, ami ráadásul turkál valamit az adatbázisban.
(Gondolom egyrételmű, hogy maga a probléma, hogy szar a htaccess-ed.)mod: most látom, hogy pár hsz-el előbb bemásoltad. Én ebből azt olvasom ki, hogy ha a request se nem egy létező file, sem pedig létező könyvtár, akkor átdobja a kérést a php-nak. A fenti feltételek pont teljesülnek, ha egy nemlétező favicon.ico-t kérek a szerveredtől, ezért fog behívni a php-ba.
-
DNReNTi
őstag
válasz
DNReNTi #17241 üzenetére
No hát, így több óra szerencsétlenkedés után, ezzel a kiegészítéssel most jónak látszik:
RedirectMatch 403 favicon.icoNagyon rohadék, nem is értem.
1: miért keresi a favicon-t ha én nem mondom?
2: ha már keresi és nem találja, mér' 200-as statust ad rá?A legegyszerűbb mondjuk valszeg az, ha van favicon...
-
DNReNTi
őstag
válasz
Sk8erPeter #17240 üzenetére
A jelenlegi .htaccess:
<IfModule mod_rewrite.c>
Options +FollowSymlinks -Indexes
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteBase /
RewriteRule ^([^?]*)$ index.php?path=$1 [NC,L,QSA]
</IfModule>Ez a célnak tökéletes lenne. De ezzel megy a 3 request. Egyszerűen nem értem az egészet. Ha egy tök más php fájlt nyitok meg, vagy pl a képet amit az előbb feltoltam ez az access log eredménye:
127.0.0.1 - - [20/Mar/2015:20:33:13 +0100] "GET /code.jpg HTTP/1.1" 304 -
127.0.0.1 - - [20/Mar/2015:20:33:13 +0100] "GET /favicon.ico HTTP/1.1" 200 2157
127.0.0.1 - - [20/Mar/2015:20:33:13 +0100] "GET /favicon.ico HTTP/1.1" 200 2161Honnan jön az a favicon.ico request? Meg ha már jön, miért fut le az index.php? Mert lefut ez 100%, abban van a tesztlekérdezés. Hozzáteszem ha az index.php-t magát nyitom meg, akkor is lefut újra kétszer.
Már az agyvérzés kerülget.
Persze az "oldalon" sehol nincs favicon, plain php fájlokról van szó.
SO-n is találtam a témában kérdéseket, de még nem találtam megoldást, az már megvan, hogy a rohadék böngészők keresik ha nincs is. Szétmegyek.
-
Sk8erPeter
nagyúr
válasz
DNReNTi #17239 üzenetére
Meg tudod mutatni a .htaccess vonatkozó részletét, ami a hibát okozta?
Hogy mitől lehet böngészőfüggő, de ez csak tippelgetés: ha ez a teszt az adatbázisba való beillesztésre csak simán be volt dobva egy akármilyen oldalra, tehát minden oldalbetöltéskor lefutott, akkor lehet akár a böngészőnek egy előtöltési mechanizmusa, tehát pl. amint beírtad a megnyitandó URL-t, máris elindulhatott egy előtöltés a teljesítmény növelése érdekében, pl. Chrome-nál van ilyen opció:
https://support.google.com/chrome/answer/1385029?hl=hu-HU
"Hálózati műveletek előrejelzése az oldalbetöltések teljesítményének növelése érdekében"
vagy angolul "Predict network actions to improve page load performance”
Ha minden egyes kérést figyelgetsz, akkor látható, hogy már abban a pillanatban elindul egy request, amikor csak bepötyögted az URL-t, vagy amint kiegészítette autocomplete segítségével a böngésző - tehát még meg sem nyomtad az Entert, máris megpróbál egy részletet előtölteni gyorsítótárba, hogy aztán amikor ténylegesen megnyitod, akkor gyorsabban betöltsön az oldal.
De most ez csak ötlet, a (század)másodpercre pontos adatokból, meg egyéb infókból lenne kideríthető, hogy pont ez lehetett-e az oka, vagy valami más. -
DNReNTi
őstag
válasz
fordfairlane #17238 üzenetére
Köszi a tanácsot, megnéztem a naplót tisztán látszik, hogy egy kérést 2 másik követ 1 mp-el később. Erre egyébként a további teszteléssel rájöttem, mert insert után ki is írattam az egész tábla tartalmát, és úgy tűnt valóban csak egy insert van. Ám ha megnéztem az adatbázist ott már három volt. Ha frissítettem az oldalt, megjelent a 2 új. Tehát azt sikerült determinálni, hogy valamiért, valahogyan a háttérben még kétszer leszalad a szkript. Kiderült: hibás volt a htaccess-em. Illetve működött csak nem jól. Kijavítottam. Most minden jó. Szívesen leírnám most amit gondolok, de szerintem örökké kitiltanának az oldalról.
Viszont vannak dolgok amiket nem tudok megmagyarázni:
1. ez miért böngészőfüggő?
2. a htaccess miért generált két plusz lefutást? (miért nem csak egyet?)
3. miért működött másik táblával?Ezek már csak költői kérdések. Agyfasz az egész, elkúrtam rá a fél napomat, örülök, hogy végre jó. Bontok is egy sört.
-
DNReNTi
őstag
Sziasztok,
Hardcore (vagy épp noob) kérdés következik:
Egy hiba (több sor kerül be az adatbázisba insert-kor, egy helyett) miatt írtam egy halál egyszerű tesztet, mert már sehogy nem tudtam rájönni mi a baj. A teszt lényege: oldalbetöltéskor bever egy sort egy adatbázis táblába. No de ahogy az eredeti hibánál itt sem egy sort hanem random 1-3 sor kerül be.A teszt kód maximálisan leegyszerűsítve:
try {
$DBC = new PDO(
'mysql:host=localhost;dbname=local_db',
'root',
'root',
array(
PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES UTF8;',
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
)
);
$SQLquery = "INSERT INTO temp(cont) VALUE(:content);";
$SQLstmt = $DBC->prepare($SQLquery);
$SQLparams = array(
'content' => 'content'
);
$SQLstmt->execute($SQLparams);
$DBC = null;
} catch(PDOException $e) {
die($e);
}És akkor jönnek a csavaros dolgok:
A lekérdezés perfekt működik mysql terminálban is, workbench-ben is.
A $SQLstmt->rowCount() mindig pontosan : 1.
Ha megnézem a táblát 3 új sor van benne.
Megnézem a MySQL system status-t, az insert-ek száma hárommal nő.
Olyan mintha többször nyitnám meg az oldalt, ekkor gondoltam kipróbálom a többi böngészővel is, és most kapaszkodj: Különböző böngészőkben (!!!) teljesen másképp viselkedik a szerver oldali kód.
Chrome: mindig 3 sor megy be.
FF: első alkalommal 3, aztán 1-1 sor megy be frissítésenként.
Safari, Opera, IE: első alkalommal 3, aztán random 1-3 sor megy be frissítésenként.Hab a tortán, csináltam még egy táblát, azzal meg jó.
Valaki pls explain, mert én hamarosan széjjelverem a laptopom.
Apache 2.4.9
MySQL 5.6.17
PHP 5.5.12 -
Sk8erPeter
nagyúr
válasz
Des1gnR #17232 üzenetére
Általános tanácsot nem lehet adni, mivel minden webshop más lehet, de mindenesetre az összes termékoldal összes HTML-kódját lementeni nyilván értelmetlen, ebből ki kell bányászni első letöltés után a szükséges adatokat, aztán eldobni a HTML-kimenetet. Vagy DOMDocument osztállyal, vagy erre/másra építő library-vel, mindenesetre valamilyen DOM-feldolgozó módszerrel.
-
Des1gnR
őstag
Sziasztok!
Egy webshopból szeretném kinyerni a termékeket (név, leírás, ár, kép).
Először arra gondoltam, hogy termékkategóriánként lementem a html kódot és egy makró segítségével kinyerem a szükséges adatokat (ilyet már csináltam korábban), de a kategória oldalon nincsenek ott a termékleírások és egyébként is lehet van egyszerűbb módja ennek.Van ötletetek?
-
cucka
addikt
válasz
PumpkinSeed #17229 üzenetére
A php-ban valóban lassúak a függvényhívások, de ez adottság, nem kell vele foglalkozni. Egy tíz meg százezer soros OOP kódhalmazban nem tudsz mit kezdeni ezzel. Ha elég hardkór vagy, itt elolvashatod, hogy miért van pontosan: [link]
Ha olyan szinten vagy, hogy ez a szűk keresztmetszet, akkor használj HHVM-et, de a PHP7-be igért JIT compiler is hozhat javulást. Vagy egyszerűen vegyél még szervert, olcsóbb, mint azért fizetni a programozót, hogy csökkentse a függvényhívások számát.
Arról nem is beszélve, hogy a jó minőségű kód egyik jellemzője, hogy a függvények elég rövidek és pontosan egy dolgot csinálnak. Szóval sok a függvényhívás és jó mély a stack. -
Sk8erPeter
nagyúr
válasz
PumpkinSeed #17229 üzenetére
"Igen tudom, bár javasoltam egy alternatív megoldást a problémára."
Ami hibás.Az str_split()-nek az egész tömböt adod át, nem indexelted. Egyébként van foreach-ciklus, ami ennél sokkal szebb kódot eredményez, és az ilyen jellegű indexeléssel sem kell foglalkoznod.
"Amúgy nem lehetséges, hogy néha az ilyen alternatív megoldás gyorsabb? Tegyük fel, hogy a kód
ugyan olyanugyanolyan hatékonysággal van megírva mint a függvényben, de mivel itt függvényhívás nélkül fut le, ezért valamivel gyorsabb."
Nem valószínű, mivel a PHP könyvtári függvényeit C-ben írják, aztán optimalizált kód lesz belőle a buildelés során, nagy eséllyel ez gyorsabban fog működni, mint a Te kódod, amit már PHP-ben írsz (a fenti kódodnál meg aztán végképp gyorsabban fog működni...). Persze ettől még a különbséget nem biztos, hogy megérzed. (Na meg el lehet képzelni rossz implementációt is még a beépített függvényeknél is.)
Ha arra vagy kíváncsi, hogy azonos környezetben, azonos feltételekkel, ugyanolyan hatékonysággal van valóban megírva a kód, de még valaki hozzátesz egy függvényhívást is, akkor melyik lesz a győztes, akkor igen, jól sejted, ELMÉLETBEN az, amelyik nem teszi hozzá a függvényhívás overheadjét - a gyakorlat viszont megint más, mert ez már olyan minimális különbség, hogy nem fogod tudni mérni sem, hogy melyik a gyorsabb, sőt, aktuális szerverterheltségtől függően össze-vissza fog változni a különbség.
Szóval azon nem éri meg agyalni, hogy inkább a könyvtári függvényt használod, vagy feltalálod a spanyolviaszt.
Azon, hogy milyen overheadet teszel hozzá egy-egy függvényhívással, akkor éri meg agyalni, amikor pl. egy helyen ugyanazt az értéket kéred le többször is, tök feleslegesen. Rengetegen elkövetik azt a hibát, hogy egy értéket/referenciát/akármit eltárolhatnának egy változóban, és később felhasználhatnák, de ugyanazt a kódot leírják többször is (erre is vonatkozik a DRY (Don't Repeat Yourself) elv).
Na, kezdek elkalandozni, remélem, megválaszoltam a kérdésedet. -
PumpkinSeed
addikt
válasz
Sk8erPeter #17226 üzenetére
Igen tudom, bár javasoltam egy alternatív megoldást a problémára. Amúgy nem lehetséges, hogy néha az ilyen alternatív megoldás gyorsabb? Tegyük fel, hogy a kód ugyan olyan hatékonysággal van megírva mint a függvényben de mivel itt függvényhívás nélkül fut le ezért valamivel gyorsabb. Bár ilyen kis dolog esetén az idő jelentéktelen, mert emberi mértékkel felfoghatatlan sebesség különbség van a kettő között, de elméletben gyorsabb ha nem függvényből hívjuk meg nem?
-
Speeedfire
félisten
válasz
Sk8erPeter #17224 üzenetére
Hasonlóan oldottam meg, csak a konstruktornak adtam egy paramétert.
-
Joci93
senior tag
válasz
Sk8erPeter #17224 üzenetére
Így van, egy tömb, amiben tömb string található. Köszi, holnap ránézek:
PumpkinSeed: Neked is köszönöm.
-
Sk8erPeter
nagyúr
válasz
PumpkinSeed #17225 üzenetére
Ja, strpos(), strstr() és társai, vagy multibyte stringeknél ezek megfelelői, tehát mb_strpos(), mb_strstr(), stb...
Amúgy ne vedd sértésnek, de azért mielőtt olyanokat állítasz, hogy "erre szerintem nincs beépített függvény", miközben ez eléggé alapvető elvárás, hogy beépített könyvtári függvény/metódus legyen egy stringben keresős módszer, nem árt utánanézni...
-
PumpkinSeed
addikt
válasz
Joci93 #17223 üzenetére
Erre szerintem nincs beépített függvény de ha azt csinálod, hogy a egy for-al végigjárod a tömböd tartalmát majd az str_split() beépített függvénnyel azt egy karaktertömbbé alakítod és úgy vizsgálod meg akkor valószínűleg menni fog. pl.:
for($i = 0; $i<valamennyi;$i++){
$charArray = str_split($array);
for($j = 0; $j<count($sharArray);$j++){
if("}" == $charArray[j]){
echo "valami";
}
}
}(#17224) Sk8erPeter
Nem tudtam, hogy van erre függvény,
meg lehet kérdezni, hogy mi az?Gondolom az strpos(), most találtam meg.
-
Sk8erPeter
nagyúr
válasz
Speeedfire #17222 üzenetére
Nem tiszta ennyiből a feladat, de akkor mondjuk annak a mindig meghívogatott metódusnak legyen egy default értékkel ellátott második paramétere is, ellenőrizd ezt a paramétert a metódus törzsében, és ha ez egy egyéb értékkel egyenlő, akkor csináld meg azt a másik esetet. Persze csak ha ez nem vezet gányoláshoz, de ennyi infóból ezt lehetett kihozni kerülő megoldásként, amivel még nincs is nagy para.
(#17223) Joci93:
Ez stringek tömbje? Tehát egy tömb, amiben több string is található?
Menj végig a tömbelemeken, és stringtartalom-keresős függvényekkel nézd meg, benne van-e az általad keresett string az aktuális elemben... -
Joci93
senior tag
Hali,
Olyat lehet csinálni, hogy egy tömbön belül rákeresni egy karakterre és ha az létezik, akkor kiíratni valamit?
Én ezzel próbálkoztam:
if (in_array("{", $text)) {
echo "Found!";
}Ezzel az a baj, hogy csak akkor találja meg, ha a tömb egyik eleme a '{', ha már úgy van benne, hogy 'valami { ', akkor már kihagyja. Esetleg van valami megoldás arra, hogy a 'valami { ' részt is megtalálja?
-
Speeedfire
félisten
válasz
Sk8erPeter #17221 üzenetére
Az adott osztály összes metódus hívása előtt lefuttatok egy másik metódust a konstruktorban és szerettem volna egy kivételt csinálni.
-
Sk8erPeter
nagyúr
válasz
Speeedfire #17219 üzenetére
Engem is nagyon érdekelne, hogy mit akarsz csinálni, ami miatt ilyen felmerült.
És hogy miért nem más módszerrel csinálod - amúgy ha ez nem volt tiszta egyből, hogy ilyet konstruktorból nyilvánvalóan nem lehet, akkor nem ártana legalább egyszer szépen végigdebuggolnod egy példány létrehozásának folyamatát, azt, hogy mikor melyik metódusba ugrik bele, és így tovább, meg átnézni az OOP-t jobban, mert itt valami alapok nagyon hiányoznak.
-
fordfairlane
veterán
válasz
Speeedfire #17219 üzenetére
Nem borultam ki, csak nem értem, mit akarsz ezzel megoldani.
-
Speeedfire
félisten
válasz
fordfairlane #17217 üzenetére
Csak kérdés volt, nem kell kiborulni.
-
Peter Kiss
őstag
válasz
fordfairlane #17217 üzenetére
A megoldás valahol az Inception és az Interstellar között van.
-
fordfairlane
veterán
válasz
Speeedfire #17216 üzenetére
Nem értem már a kérdésfeltevést sem. Honnan tudná előre ezt a konstruktor? Időutazás?
-
Speeedfire
félisten
válasz
fordfairlane #17215 üzenetére
Sejtettem, hogy nem fogja tudni.
Köszi a választ.
-
fordfairlane
veterán
válasz
Speeedfire #17214 üzenetére
A konstruktorban nyilván sehogy, mivel a metódusokat csak a példányosítás után tudod meghívni, a konstruktor meg a példányosításkor fut le.
-
Speeedfire
félisten
Egy osztály konstruktorában honnan lehet megtudni, hogy az adott osztály mely metódusát hívja meg valami?
class Test {
public function __contruct() {
//itt szeretném megtudni, hogy a valami vagy az egyeb lett meghívva
}
}
$test = new Test();
$test->valami();
$test->egyeb();Létezik ilyen? A backtrace()-t néztem, de az csak az eddigieket adta vissza.
-
biker
nagyúr
válasz
sztanozs #17212 üzenetére
Igazabol arra gondoltam, hogy amit a sessionben tarolok, azokat az adatokat omlesztve, sozva elkodolva letarolom cookieba, de ez rovid lejaratu lenne, pl egy ora. Ha a lapot ujratoltik, nincs lejarva a cookie, akkor expire frissul, igy utolso aktivitas +1 ora lenne mindig
Ha nem el a session, de el a cookie, akkor a cookiebol kibanyaszott adatokkal visszafrissitem a sessiont -
sztanozs
veterán
Szvsz attól, hogy hogy tárolod a session-t kliens oldalon (cookie / url / hidden form field) még ugyanúgy el tud tűnni a session a szerver oldali tárolóból. Valószínűleg szerver oldalon maximalizálva van a nyitott session-ök száma, ha ezt eléri, akkor a legrégebbieket a rendszer akkor is törli, ha te hosszább lejárati időt definiáltál. Esetleg az lehet megoldás, ha nem szerver default session menedzsmentjét használod, hanem te kezeled a session-t adatbázisba.
-
biker
nagyúr
Tartok tőle, hogy valami megváltozott az "erőben", és valamiről lemaradtam, de kéne némi tanács.
már a harmadik tárhelyen járok úgy, hogy hiába a session max lifetime 86400 (egy nap) és hiába minden kapcsolódó beállítás, a session ID megmarad, de a tartalma "eltűnik" ezáltal a belépett állapot is úszik a levesbe.
gy.k. ugyanazt a belépéses kódot alkalmazom évek óta, és eddig jól ment, sőt, volt olyan, ahol az 1nap úgy volt értendő hogy utolsó aktivitástól 1 nap, van ahol belépéstől egy nap, már ezt sem értettem, de mostanság van, hogy mondjuk be van lépve az ember, kattingat ezerrel, és egyszercsak kivágja a belépő oldalra a rendszer
ez mondjuk 1 óra és 4 óra közt véletlenszerű idő, nem függ browser lezárástól, gép altatástól, semmitől, pukk, vége.
Eddig azért "szerettem" a sessiont, mert azt nem befolyásolja, ha letiltja a cookiekat, de ez most kicsit visszavetett.
Mitől veszhet a session tartalma, ha az id nem változik, és nincs másnak kiosztva?
Mindent így kezdek:
session_set_cookie_params(86400);
ini_set('session.gc_maxlifetime',86400);
ini_set('session.cookie_lifetime',86400);
session_start();ezt követően ugye ellenőrzöm, megvannak e az elmentett változók, ha nincs, go to login, ha igen, akkor tatalomfüggően mehet tovább (jogosultság, név, stb tárolva)
Már kínomban egyik tárhelyen saját webrootba mentek minden sessiont, és ott láttam ezt, hogy a file maga üres lesz hirtelen.
Találtam egy cikket (2009-es) ami szerint a garbage collection ha elindul a háttérben, az nézhet bizonyos adatokat szemétnek, de a javasolt beállításokkal sok változás nem történt.
ini_set('session.gc_probability', 1);
ini_set('session.gc_divisor', 1000);Ugyanúgy kiléptetett az egyik site idővel.
Mégis cookie a jó megoldás? mi a 100% megoldás? (hiába tilt mondjuk cookiet?)
-
disy68
aktív tag
válasz
#68216320 #17208 üzenetére
Ez már erősen a javascript topicba való, ha további kérdés lesz, azt inkább oda:
Az első a DOM manipuláció. Ajánlani tudom ennek kezelésére (és sok egyéb feladathoz is) a jQuery használatát. Nagyon jól lehet vele a DOM elemeket kezelni a CSS-ből is ismerős selectorok segítségével. Így el tudod érni az általad kívánt elemeket (form-ot pl. id vagy class alapján) és azt csinálsz vele, amit szeretnél.
A második a DOM események felhasználása. Az eseményekhez különböző (akár több) eseménykezelőt köthetünk, amiben az esemény hatására csinálunk dolgokat (pl. egy select változás eseményére megváltoztatjuk a formunkat).
És egy kis szemléltető form változtatásra jQuery segítségével.
-
#68216320
törölt tag
Van az egyik oldalamon egy form. Ebben van olyan select aminek a hatására változik a form többi része. Ha mondjuk az '1' van kiválasztava egy újabb select jelenik meg, ha a '2' akkor checkbox-ok. Elképzelhetőek később újabb ilyen választások még ebben a form-ban.
Jelenleg a onChange="this.form.submit()" eseménykezelővel és a form elküldésével oldom meg.
Ezzel az a problémám, hogy az egész oldal újratöltődik.
Van valami elegánsabb megoldás, hogy csak a form vagy div-en belüli részek töltődjenek újra? -
sztanozs
veterán
#17200 - PeachMan
Illetve akkor kellhet, ha túloldalon HTML-be lesz beillesztve (persistent XSS-t elkerülendő) - de akkor nem sima escape kell, hanem html encode.
Új hozzászólás Aktív témák
Hirdetés
- Melyik tápegységet vegyem?
- Miért vezet mindenki úgy, mint egy állat?
- Milyen egeret válasszak?
- Parci: Milyen mosógépet vegyek?
- Debrecen és környéke adok-veszek-beszélgetek
- Formula-1
- Autós topik
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Nyaralás előtti hardverszemle
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- További aktív témák...
- AMD Ryzen 7 7700X - Új, 1 év garancia - Eladó!
- Apple Watch ultra 2 49mm Natur Titanium, Új, 1 év Apple garanciával
- Gamer PC - R5 5600, RTX 3060 és 16gb RAM + GARANCIA
- HP Zbook 14 laptop (14FHD/I7-G5/8GB/128SSD/MagyarVilágítós)
- Jó áron ÁRON ELADÓ! Üzleti HP Elitebook 1040 G9 Laptop! / i5-1245U 16GB 256GB
- AKCIÓ! Gigabyte H610M i5 13600K 16GB DDR4 512GB SSD RTX 3060Ti 8GB Zalman S2 TG Seasonic 650W
- Dixit 4 Eredet (bontatlan, fóliás kártyacsomag)
- Csere-Beszámítás! Asztali számítógép PC Játékra. I5 12400F / RTX 3070 / 32GB DDR4 / 1TB SSD
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- ASUS TUF Gaming F15 FX506 - 15.6"FHD IPS 144Hz - i5-11400H - 8GB - 512GB - RTX 3050 Ti - 1,5 év gari
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest