Új hozzászólás Aktív témák
-
cucka
addikt
válasz Jano_023 #2237 üzenetére
Értelmes lehetőségek a probléma megoldására
- htaccess-el véded a filet.
- olyan helyre rakod a filet, ami kívül esik a webszerverben beállított wwwroot könyvtáron, de a php el tudja érni.
- file helyett adatbázisban tárolod a kényes információkat.Ingyenes tárhelyen általában az első kettőre nincs lehetőséged .
-
cucka
addikt
Mindenképp kell ellenőrzés a szerver oldalra, méghozzá az előtt, hogy az adatokat feldolgoznád (pl. bekerülnének egy adatbázisba).
Lehet bohóckodni ajax-al meg javascript-el, de a konkrét adatfeldolgozás akkor is úgy kezdődik, hogy a szerver kap egy POST vagy GET kérést. Ilyen kérést pedig nem csak böngészőből lehet küldeni, tehát az egész kliens oldali ellenőrzés könnyedén kikerülhető. -
cucka
addikt
Meggyűlik a bajom egy látogató számláló scripttel, az egyedi látogatókat, és a mai egyedi látogatókat nem számolja valamiért és nem tudok rájönni miért, az oldal találatokat és az oldalletöltéseket méri szépen ha ráfrissítek ugrik egyet az is, de az egyedi látogatószám nem. Megakadt 1 főnél.
Szerintem ez pont hogy így kell működjön. Az egyedi látogató pontosan azt jelenti, hogy egyedi (ip cím és/vagy cookie szerint), tehát ha ráfrissítesz, akkor nem kell növekedjen az értéke.
Például te ma megnézed az oldaladat 30-szor, én pedig 15-ször, akkor az egyedi látogatók száma 2 kell legyen, az oldalletöltések száma pedig 45. -
cucka
addikt
A következő sort:
$line = $REMOTE_ADDR . "|" . $mday . $month . $year . "\n";
Cseréld ki erre:
$line = $_SERVER['REMOTE_ADDR'] . "|" . $mday . $month . $year . "\n";
A hiba oka, hogy a letöltött script-ed meglehetősen szarul van megírva és csak akkor működik, ha a szerveren a register_globals be van kapcsolva. A bekapcsolt register_globals egy óriási biztonsági lyuk, ezért jó ideje alapból ki van kapcsolva a php-ban, sőt, a fejlesztés alatt álló 6-os php-ból ki is lesz szedve teljesen.
Egyébként bohóckodni jó ez a log file-al működő látogató számlálás, de javaslom, minél hamarabb cseréld ki egy olyanra, ami adatbázist használ.
[ Szerkesztve ]
-
cucka
addikt
válasz emitter #2256 üzenetére
Ha teljesen korrekt ellenőrzést akarsz az űrlapodra, amely mindenhol kijelzi a releváns hibaüzenetet, akkor az sok meló. Mindent ellenőrizni kell, esetleg azokat a műveleteket/ellenőrzéseket összevonhatod, amelyeket több mezőnél is használsz. (Tipikusan ilyen pl. az, hogy üres-e a mező. Csinálsz egy tömböt azokból a mezőnevekből, amelyeknek nem szabad üresnek lenni és foreach-el megnézed mindegyikre, hogy valóban nem üres-e a $_POST tömbben. Persze ez csak akkor segít, ha sok mezőre kell ugyanezt ellenőrizni..)
Viszont lenne egy másik kérdésem: ki lehet-e nyerni valahogyan a $_POST elemeinek a nevét?
Például array_keys() függvénnyel kapsz egy tömböt a $_POST-ban található kulcsokról. Vagy foreach ($_POST as $kulcs => $ertek) formában is végigiterálhatsz rajta.
Egyébként azt javaslom, hogy ne a $_POST elemein menj végig az ellenőrzésnél, hanem a programod tudja, hogy milyen elemeknek kéne ott szerepelniük. Egy php programnak bármikor bármit el lehet post-olni, ezért ne a post-olt adatok alapján ellenőrizd a post-olt adatokat. (Ez kicsit hülyén hangzik, de pontosan ezt írtad le)[ Szerkesztve ]
-
cucka
addikt
válasz emitter #2305 üzenetére
Az előttem leírt módszer is jó, de javascript-el is eltűntetheted. Például a gomb onclick-jére rákötsz egy olyan függvényt, ami összerakja neked az url-t és odaküldi a böngészőt.
Az üres mezők nem feleslegesek, mert az is információ, ha valahova nem írt semmit a felhasználó. A submit gomb pedig azért kell benne legyen, hogy például tudd, melyik form-ot post-olták el éppen. Teszem azt, két különböző form ugyanoda post-ol és valahogy meg szeretnéd különböztetni őket. Nem minden fölösleges, ami annak tűnik. Amúgy meg miért zavar, hogy ott van az url-ben?
-
cucka
addikt
válasz emitter #2309 üzenetére
hogyan lehet kódolni és dekódolni az url-be kerülő sztringeket?
urlencode() és urldecode()hogyan tudom megoldani, hogy az url egy újabb get-mezővel bővüljön
például hidden mezővel, ami nem látszik a böngészőben, de amúgy úgy viselkedik, mint egy sima szöveges mező.
input type="hidden" -
cucka
addikt
válasz emitter #2317 üzenetére
A böngészőnek elvileg automatikusan kódolnia kéne. Hogy hogyan kódolja le az adatokat, az a form enctype paraméterétől függ. [link]
Azt meg nem értem, miért nem kell használni az urlencode()-ot. Az arra való, hogy a php-ból biztosan jó url-eket tudj összeállítani. Nem csak a magyar ékezetes karaktereket kell lekódolni, hanem más spec. karaktert is. A böngésző van annyira okos, hogy a hibásan beírt url-t lekódolja neked, ettől függetlenül célszerű helyes url-ekkel linkelni az oldalakat.
[ Szerkesztve ]
-
cucka
addikt
válasz vakondka #2393 üzenetére
Igazából nem értem, hogy az a preg_replace mit kéne csináljon, de az biztos, hogy ezt a beneti string-et szépen kinullázza.
Én valami hasonlóra cserélném. Ez lényegesen fapadosabb, cserébe működik..$text = preg_replace('([^A-Za-z0-9]+)', '-', $text);
Amúgy meg sokkal jobb megoldás az ékezetes betűk ékezet nélkülire cserélése, ezt sajnos csak a korábban általad írt borzalmasan kinéző függvénnyel tudod megoldani.
-
cucka
addikt
válasz Paulie86 #2438 üzenetére
Warning: Cannot modify header information - headers already sent by (output started at /nfs/x0201/b/be/bercsenyi-ijasz/wwwroot/index.php:6) in /nfs/x0201/b/be/bercsenyi-ijasz/wwwroot/loginsys/login.php on line 65
Benne van a hibaüzenetben.
Itt kezdődött el a kiírás a szabványos kimenetre:/nfs/x0201/b/be/bercsenyi-ijasz/wwwroot/index.php:6
Itt próbáltad módosítani a HTTP header-eket.
/nfs/x0201/b/be/bercsenyi-ijasz/wwwroot/loginsys/login.php on line 65
Amúgy nem tudom, hogy mi milyen sorrendben fut le és mit csinál a filejaid közül, szóval ennél konkrétabbat nehéz mondani.
[ Szerkesztve ]
-
cucka
addikt
válasz Paulie86 #2440 üzenetére
A setcookie() ebből a szemponbtból pontosan ugyanúgy viselkedik, mint a header(), vagyis amikor meghívod, létrehozza (és kiküldi a böngészőnek) a http fejlécet.
A problémát az okozza, hogy amikor legelőször kiírsz valamit a standard kimenetre (ez lenne más szóval az output buffer), akkor szintén elküldi a http fejlécet. Elküldött fejlécet pedig már nem lehet módosítani.Namost egy rendesen megírt weboldal struktúrája valahogy a következő módon néz ki
- bemeneti adatok ellenőrzése
- bemeneti adatok feldolgozása, html/css kód előkészítése, fejléc beállítása
- html/css kód kiírásaHa a tiednél a kiírás nem az utolsó, akkor a kód nem jó. Ettől még működhet, arra gondolok, hogy minőségileg nem megfelelő a kód.
de elvileg ha ob_start() és ob end flush között van akkor nincs gond.
Az ob_start annyit csinál, hogy az output buffer-t (a programod standard kimenetét) leállítja, az ob_end_flush pedig kiírja a bufferben felhalmozott, még ki nem írt szöveget. Tehát hiába van a login.php-d végén az ob_end_flush, ha a login.php-t a header hívás előtt include-olod, mert a flush hamarabb fog lefutni, mint a header.Amúgy egy jó tanács: normálisan strukturált php kódnál nagyon ritkán van szükség az output buffer-t kezelő függvényekre, ezért használatuk helyett javaslom, inkább strukturáld át a kódot.
-
cucka
addikt
válasz Paulie86 #2442 üzenetére
talán azért rossz , mert igyekszem mindent DIVekbe pakolni, ez a login kód is div tagek között van, azért is mert más megoldást nem találtam hogy oda pozícionáljam ezt a loginos ablakot ahova akarom.
Nem, rosszul közelíted meg.
A szép php kód írásának talán a legfontosabb feltétele, hogy a php részeket különválaszd a html sablonoktól. Erre egyébként nehéz tuti tippet adni, mert ugye a feladattól is függ.
Itt például arról lenne szó, hogy minden alkalmazáslogikához tartozó kód a html előtt legyen. Ha el kell dönteni, hogy átirányítod-e valahova a felhasználót vagy sem, azt ne valamelyik html tag-be berakott php kóddal tedd. Ennek előnye, hogy a programod és a program által előállított html között minél lazább legyen a kötődés. (Igazából a php nyelvnek semmi köze a html-hez, csak a legtöbb esetben arra használjuk, hogy html kódot gyártsunk vele. Ha egy php file-ban a sok html részbe be vannak iktatva rövid php kódok, az nem azt jelenti, hogy az html lenne. A <?php ?> tag-eken kívül eső szövegekre tekints úgy, mint ha php-ban print-el iratnád ki őket.)[ Szerkesztve ]
-
cucka
addikt
válasz Fire/SOUL/CD #2451 üzenetére
100%-os megoldás valóban csak a próba email kiküldése, de azért nézd meg ezt, elég jó eséllyel leszűri a tuti rossz címeket:
[link] -
cucka
addikt
válasz cellpeti #2462 üzenetére
Tele von Zsinór köszönöm. Még annyit,hadd kérdezzek,hogy ok,hogy azt jelenti,de miért kell oda?
echo "-2.7 abszolút értéke <b>" . abs($elso_szam) . "</b>";
Az echo az arra való, hogy kiírj egy (azaz pontosan 1 darab) stringet.
A programodban egy stringet, egy függvény visszatérési értékét és utána még egy stringet kell kiírj. Ezt meg tudod oldani 3 darab echo-val is, vagy egy echo-val úgy, hogy egymás után fűzöd a 3 értéket. Tehát a fenti sornál a következő történik
- a php meghívja az abs() függvényt
- észreveszi, hogy az abs() értékét stringekkel szeretnéd összefűzni. A string összefűzés operátor mindkét paramétere string kell legyen, tehát az abs() eredményét átalakítja string típusúra.
- összefűzi a 3 stringet, tehát az echo paramétere 1 string lesz.
- elvégzi az echo-t (kiírja az összefűzött stringet)Ha nem lenne ott a pont, akkor egyszerűen szintaktikai hibás lenne a programod.
-
cucka
addikt
válasz cellpeti #2467 üzenetére
Nálam is működnek. A php kódban egy print_r($_POST)-al ki tudod írni, hogy mit kapott a $_POST-ban a programod. (A print_r tömbök/objektumok kiírására való, tehát nyilván nem csak a $_POST-ra működik)
Amúgy én wamp helyett az appServ nevű mindent egybe csomagot használnám. A wamp-ban csomó egyedi beállítás és eszköz van, emiatt nehéz látatlanban megmondani, mi a gond.
Másik tanács: a hibajelzést kapcsold be. Ezt a php.ini-ben tudod megcsinálni, az error_reporting résznél. Esetleg magában a script-ben is megoldhatod, ha úgy kezded a kódot, hogy error_reporting(E_ALL);
Harmadik: az <input type=submit-nál mindig add meg a name paramétert. Ekkor az űrlap elküldésénél a gombra vonatkozó adatokat is el fogja küldeni.[ Szerkesztve ]
-
cucka
addikt
válasz cellpeti #2470 üzenetére
Amikor kirpóbáltam a Wamp-ot, nekem sem ment rajta a munkámhoz használt saját framework. Megmondom őszintén, nekem semmi kedvem nem volt szívni a mindenféle custom dologgal, amit beleraktak, úgyhogy inkább leszedtem a gépről.
Az appserv azért ajánlott, mert kb. ugyanazt a végeredményt adja, mint ha külön-külön telepítenéd a dolgokat, néhány start menüs shortcut-ot leszámítva semmi egyéni extra nincs benne. -
cucka
addikt
A simplePie nem dokumentumkezelő, hanem egy rss/atom kezelését megkönnyítő függvénykönyvtár és egyáltalán nem alkalmas arra, amire szeretnéd használni.
A leírásod alapján nem nagyon érted még az alapfogalmakat sem a php-val kapscolatban, tehát javaslom, vegyél egy php könyvet és kezdj el tanulni, vagy bízz meg a feladattal szakembert. -
cucka
addikt
válasz Benmartin #2495 üzenetére
Amúgy ez így nem teljesen igaz. (sőt, tulajdonképpen egyáltalán nem igaz )
Az isset() nyelvi elem (figyelem, ez még csak nem is függvény) azt nézi, hogy a paraméterként kapott változó(k) értéke NULL-e vagy sem. Php-ban egy nem létező változó értéke mindig NULL, tehát ezekre az isset false-t fog visszaadni, ahogy az elvárható.Nade mi van, ha a változó definiált és értéke null? És ha egy tömb egyik eleméről beszélünk. Itt van pár érdekesebb példa, megjegyzésként odaírtam, hogy mit fog rá kiírni a var_dump.
<?php
$a=null;
var_dump(isset($a)); //FALSE
var_dump(isset($b)); //FALSE
var_dump($b===null); //TRUE
var_dump($a===$b); //TRUE
$t=array('ureselem' => null);
var_dump(isset($t['ureselem'])); //FALSE
var_dump(array_key_exists('ureselem',$t)); //TRUE
?>[ Szerkesztve ]
-
cucka
addikt
Kapcsold be a hibajelzést: error_reporting néven keresd meg a php.ini-ben és állítsd E_ALL-ra. Utána olvass vissza pár odlalt, kb. 1-2 hete volt erről szó, hogy a http header-öket módosító műveletek előtt (pl. ilyen a header() függvény) nem szabad kiírni semmit a standard kimenetre.
mod: még valami. mikor kell exit utasítást használni?
Alapvetően nem kell sehol exit-et használni. Amúgy pont ugyanazt csinálja, mint a die(), két néven fut ugyanaz a nyelvi elem. -
cucka
addikt
Localhosthoz hozzá lehet férni megosztott webhosting esetén?? Sztem nem.
Kb, mintha az extra.hu-n dolgoznék, csak fizetős, és reklámmentes.
A localhost az a saját géped, tehát ennek a mondatodnak nincs értelme, természetesen a saját gépedhez hozzáférhetsz.Miért, és mire jó ez az escape cucc? Erről van szó?
Ez arra jó, hogy a fölös karaktereket eltávolítsa? Ezt a js már megteszi.
SQL injection. Olvass utána, igencsak fontos tudni, hogy működik és hogy lehet védekezni ellene.A bekapcsolt register_globals azt jelenti, hogy műxik a változók globálissá tétele?
Kipróbáltam, műxik. Miért ne építsek rá? Nem megbízható, vagy lehet, hogy kikapcsolják?
A register_globals bekapcsolás után azt csinálja, hogy a $_POST és $_GET tömbökben kapott paramétereket globlális változóként is el lehet érni. Tehát a $_GET['param'] értékét a $param nevű globális változóba pakolja.
A global kulcsszónak (amit amúgy totál rosszul használsz) semmi köze ehhez. -
cucka
addikt
válasz cellpeti #2524 üzenetére
Gondolom a php 24 óra alatt című könyvből tanulsz, ott magyarázzák ilyen marha jól a kódot..
Először is, az else nem utasítás. Önmagában nem is létezik. Amiről te beszélsz, az az if..else vezérlési szerkezet. Az if így néz ki:
if (feltétel){
kód1
} else {
kód2
}Az if úgy működik, hogy fogja a feltételt és kiértékeli, ami azt jelenti, hogy a feltétel értékét átalakítja bool típusúra. (Ez azért fontos, mert a feltételben bármi lehet, amit a php bool típusúra tud alakítani. Megjegyzem, a php-ban nem létezik olyan változó vagy kifejezés, amit ne lehetne bool-ra alakítani)
Ha a feltétel értéke true, akkor a kód1 fog lefutni, különben a kód2.A te programodban a feltételben az szerepel, hogy elküldték-e az űrlapot. Ha ez teljesül, akkor feldolgozod az adatokat (pl. kiírod, hogy elfogadtad-e a kölcsönkérési igényét). Ha nem teljesül, akkor pedig kirakod neki a képernyőre az űrlapot (ez a kód2 rész). Az if szintaxisából látszik, hogy miért van a program végén az a } karakter. És igen, általában ilyen szerkezettel szokás megoldani az űrlapokat egyszerűbb oldalakon, tehát máshol is használhatod ezt a sémát.
Ez a sor: <input name="eletkor" type="text" size="3"> => ide miért kell? A méretet nem a text parancs határozza meg?
Megint kevered a dolgokat. Az a sor egy html részlet, ahol megint nincsen semmiféle parancs vagy utasítás, hanem tag-ek vannak és azoknak paraméterei. Az input tag például egy űrlapelemet ír ki a képernyőre. Az input tag type paramétere határozza meg, hogy milyen típusú űrlap elemről van szó (text esetén pl. sima szöveges mező). A size paraméter azt mondja meg, hogy hány betű kerülhet bele abba a szövegmezőbe. A szövegmeződ méretét a rá érvényes css stílusok határozzák meg. Tehát ha 100 pixel szélesre akarod megcsinálni, akkor<input name="eletkor" type="text" size="3" style="width:100px;">
És elnézést mindenkitől, akinek úgy tűnik, hogy a szavakon lovagolok, de véleményem szerint érdemes jól és pontosan megtanulni az alapfogalmakat. Tehát az if-re nyugodtan el lehet kezdésnél is mondani, hogy vezérlési szerkezet, mert a kézikönyvben is ezen a néven szerepel, nem pedig "utasítás", "parancs" meg egyéb kamu neveken.
[ Szerkesztve ]
-
cucka
addikt
válasz Benmartin #2518 üzenetére
Csak pontosítottam, egyrészt azért, mert érdekesnek találom a php viselkedését a null típusnál, másrészt mert marhára nem egyértelmű elsőre, hogy mit is csinál az isset(). (meg hogy mit is jelent az, hogy definiált-e egy változó vagy sem)
Amúgy meg tényleg nem függvény, csak függvényként lehet használni, mint ahogy az include-ot vagy a print-et. (ezek sem függvények)[ Szerkesztve ]
-
cucka
addikt
válasz @Pirate@ #2540 üzenetére
Az első elseif-ed feltétele logkailag tuti rossz, de szintaktikailag amúgy helyesnek tűnik a kód. (Konkrétan, a stringekre ráeresztett bitenként vagy kicsit meredek, próbáld inkább összefűzni őket, az az átlalad várt megoldást fogja adni)
(#2541) lezso6
Php-ban nincsenek többszálúságot támogató megoldások. Exec-el mondjuk meg lehet hívni egy másik php szálat, de kicsit körülményes lehet így dolgozni. (plusz rengeteg hibaforrás, és amúgy is teljesen fölösleges)
Természetesen ha egyszerre két ember kéri le ugyanazt a php-s weboldalt, akkor azt párhuzamosan fogja kiszolgálni az apache/php.[ Szerkesztve ]
-
cucka
addikt
válasz @Pirate@ #2540 üzenetére
Még pár megjegyzés:
- a break-ek teljesen fölöslegesek. A break azt csinálja a programodban, hogy az aktuális if-ből kilép. Azért fölösleges, mert előtte a return már kilépett a teljes függvényből.
Igazából normálisan megírt programnál a break-re semmi szükség, kivéve természetesen a switch-es szerkezeteket.
- Bitenkénti műveletek helyett mindig használd azok logikai párját. Tehát jelen esetben a feltételeidben | helyett || . A bitműveletek az automata típuskonverziójukkal nagyon csúnya dolgokat tudnak művelni. Természetesen van, amikor kifejezetten bitműveleteket kell használni, de ez nem az az eset.
(A bitműveletekről tudni kell, hogy a két operandusuk int típusú, tehát bármit is adsz meg nekik, azt a php int-re alakítja át. Bool típusú operandusnál ez nem rejt buktatókat, más típusúaknál azonban előfordulnak érdekes dolgok, amivel nagyon könnyen tudsz megtalálhatatlan, ritkán előforduló hibákat kódolni a programodba). -
cucka
addikt
válasz zhagyma #2556 üzenetére
Bizonyos kódmennyiség- vagy méret felett úgyanolyan nehéz változtatni OOP-ben megírt programot, mint struktúrált / moduláris programot.
Ezt cáfolnám. Az OOP-s kód nem feltétlenül egyszerűbb, mint a strukturált (sőt, sokszor bonyolultabb), de azt tapasztaltam, hogy minél nagyobb a kód mérete, annál könnyebb dolgozni egy normálisan megírt/dokumentált OOP-s rendszerrel, mint egy ugyanakkora strukturálttal.A profi php programozó meg az, aki ebből él. Ennek előfeltétele, hogy elég jól kell érteni a php-hoz, mert ugye a hozzá nem értést nem nagyon fizeti meg senki.
[ Szerkesztve ]
-
cucka
addikt
De pl.: oo szemlélettel php-ben még sose programoztam, tudom megvan rá a lehetőség, de igazából web fejlesztésnél nem vettem volna még túl sok hasznát.
Hogyne lehetne hasznát venni. Mondok egy egyszerű példát.
Van egy űrlap osztályod, ami annyit tud, hogy kiírja a benne található űrlap elemeket egy táblázatba bizonyos rendszer szerint. (A kiírás úgy történik, hogy odaszól mindegyik űrlap elemnek, hogy "írd ki magad"). Ugyanígy ellenőrzésnél is az űrlap elemek ellenőrzését hívja meg, és az adatbázisba való mentésnél is odaad az űrlap elemnek egy tömböt, hogy "írd bele a saját adataidat és add vissza a tömböt", majd a visszakapott tömböt simán berakja a táblába.Az űrlap elemek egy közös osztályból származnak, ahol fel vannak véve az általános tulajdonságok (név, érték, stb..) illetve általános viselkedési formák (pl. űrlap mentésnél alap esetben annyit csinál, hogy $tomb[$this->name]=$this->value). Az egyes űrlap elemeknél definiálva van a saját egyedi viselkedésük.
Ez a fenti forma azért király, mert egy megfelelően felparaméterezett/példányosított űrlapnál a kiírás, az adatfeldolgozás és az adatbázisba való mentés is mindössze 1-1 függvényhívás.
Sőt, ha úgy véled, hogy az adatbázis kezelésedre is írsz pár osztályt (tábla, mező, szűrő.), akkor egyenesen a táblából fogsz tudni automatikusan, 1 függvényhívással űrlapokat gyártani.[ Szerkesztve ]
-
cucka
addikt
Jól látod, igazából OOP-s és strukturált programozással is lehet jó és gyalázatos minőségű kódot írni. Amúgy én is ismerek profi programozót, aki szakmailag ott van a szeren, mégis olvashatatlan a kódja. (pl. nem használ indentálást, minden sor ugyanabban az oszlopban kezdődik. )
-
cucka
addikt
válasz VladimirR #2595 üzenetére
Más nyelvekkel ellentétben a PHP-ban a futás közben fellépő hibáknál (notice, warning és error) nem jön létre exception. Igazából exception-ökkel csak akkor tudsz dolgozni, ha te írod meg hozzá azt a részt is, ahol létrejön az exception, a beépített függvények/osztályok ugyanis jellemzően nem dobnak soha kivételeket.
(Tehát a throw new exception.. rész helyett a trigger_error függvényt használják hibakezelésre) -
cucka
addikt
válasz vakondka #2598 üzenetére
Ha úgy adod meg neki, hogy fopen('/könyvtár/másik/valami.jpg', ..), akkor a szerver filerendszerében fogja keresni. (Tehát itt a / jel nem a wwwroot-ot jelenti). Ha relatív útvonalat adsz meg, akkor a futtatott szkript útvonalához viszonyítva keresi a filet a filerendszerben.
Általában véve az fopen az csak akkor nyit meg url-t, ha a paraméterébe url-t adsz meg, pl. fopen('http://weboldal.hu/valami.jpg',...)
-
cucka
addikt
válasz vakondka #2602 üzenetére
Akkor még egyszer, mert úgy látom, nem volt világos.
Az fopen alapesetben nem url-t kér, hanem a szerveren található file útvonalát.Általában véve úgy tudod megcsinálni, hogy fopen-nél a kapott abszolut url elé berakod a webszerver gyökérkönyvtárának a relatív útvonalát. Tehát jobban jársz, ha nem alakítod át a tinyMCE-ben az url-t
Például a programod a http://oldalneved.hu/dolgok/feldolgozas/index.php néven fut. A program megkapja a "/kepek/thumb/valami/asd.jpg" relatív url-t. Ekkor a következő módon tudod megnyitni:
$rootdir='../../';
$filename='/kepek/thumb/valami/asd.jpg';
$filename=ltrim($filename, ' /');
$f=fopen($rootdir.$filename, 'r');
....Ez így azért jó, mert a programodnak csak annyit kell tudnia, hogy a weboldal gyökeréhez képest hol helyezkedik el, amit akár automatizálva is ki tud találni, nem kell mindenhova kézzel odaírni.
-
cucka
addikt
válasz blast3r #2627 üzenetére
A Php fekete könyvet ajánlom.
Az ilyen "24 óra alatt" könyvek nagyon felületesek, gyakorlatilag csak gányolni lehet megtanulni azok alapján, a php4-et pedig egyenesen felejtsd el, php5-el foglalkozó könyvből tanulj.
(A gányolás azért lényegi kérdés, mert a php teljes mellszélességgel támogatja a rossz minőségű kód írását, ami egy fél oldalas szkriptnél nem gond, nagyobb rendszereknél viszont igen)Szövegszerkesztő: ingyenesből a notepad++ nálam nagyon bevált, fizetősből meg ott a zend, ami mondjuk jóval több, mint egy egyszerű szövegszerkesztő..
[ Szerkesztve ]
-
cucka
addikt
Bár a Session kezelés picit fura, néha bejelentkezés után vagy 2-3 mp és ki is lépett, néha meg akár 5-6 percig is bejelentkezve marad. Session időt tudom valahogy manipulálni, ha nem férek hozzá a szerverbeállításokhoz?
Szerintem valószínűleg a session kezeléseddel van a probléma, pl. van olyan aloldal, ahol hiányzik a session_start().
Az ini_set nagyon kevés szerveren van engedélyezve, a phpinfo()-val viszont meg tudod nézni a szerver session beállításait. -
Új hozzászólás Aktív témák
- AMD Navi Radeon™ RX 7xxx sorozat
- A régi node-okra koncentrál a szankciók miatt Kína
- Vodafone otthoni szolgáltatások (TV, internet, telefon)
- Kerékpárosok, bringások ide!
- Vezetékes FEJhallgatók
- OLED TV topic
- Xbox Series X|S
- Óra topik
- Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
- További aktív témák...