- Lalikiraly: MSI Cyborg 15 - Tényleg Kiborg.
- antikomcsi: Való Világ: A piszkos 12 - VV12 - Való Világ 12
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- bb0t: Gyilkos szénhidrátok, avagy hogyan fogytam önsanyargatás nélkül 16 kg-ot
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
Új hozzászólás Aktív témák
-
CSorBA
őstag
Korábban javasolták itt többen az IntlDateFormatter osztályt. Sajnos nem nagyon felelt meg mégsem, mivel (lehet én voltam figyelmetlen, de) nem nagyon tudtam beállítani a megjelenést, azaz kb kimerült 4 megjelenítési módban. Mivel nekem ez nem volt elég, így maradtam a saját fordító osztálynál, ami előre definiált patternek szerint jeleníti meg a dátumot. Sajnos nem vagyok benne biztos, hogy nyelvtanilag sikerült eltalálnom minden lehetőséget, de azért próbálkoztam. Ha valakit érdekel, megtekinthető [itt], ha valakinek kellene, az dobjon rám egy privit.
-
CSorBA
őstag
Sziasztok!
Van egy stringem: "string[szám]"
Ebből szeretnék egy tömböt, azaz mintha ez lenne:
$string = array();
array_push($string, szám);És akkor lehet ilyet, hogy:
$szam = $string[0]Van erre valami egyszerű megoldás? Ne kérdezzétek mire kell Preg matchel meg tudom csinálni, csak érdekel, hogy van-e esetleg valami konverzió,
-
CSorBA
őstag
válasz Sk8erPeter #10668 üzenetére
Majdnem:
$string = 'kedvenc_szamom[4]';
var_dump($string);
//string(17) "kedvenc_szamom[4]"
$string = (array)$string;
var_dump($string);
//array(1) { [0]=> string(17) "kedvenc_szamom[4]" }Én pedig ezt várom:
array(1) { ["kedvenc_szamom"]=> int(4) }
Nem tudom mennyire érthető
Szóval ebből:
$string = 'kedvenc_szamom[4]';
ez legyen:
$string =array();
$string['kedvenc_szamom'] = 4; -
CSorBA
őstag
válasz PazsitZ #10670 üzenetére
Az én megoldásom ez lett végül:
$key= preg_replace("/[^a-z]/", '', $string);
$value= preg_replace("/[^0-9]/", '', $string);Aztán megcsinálom a tömböt belőle. Annyira nem gáz, csak azt hittem van valami konverzió, ami forma alapján felismeri, vagy nem is tudom Köszönöm a segítségeket.
-
CSorBA
őstag
válasz Sk8erPeter #10672 üzenetére
Meg persze Lehet én pörögtem túl, és bebonyolítottam.
A lényeg, hogy van 1 területválasztó selectboxom. Benne 2 típusú optionokkal. Az egyik a várost jelöli, a másik az országot. És mivel ajaxosan is posztolom, meg simán is. Nem nagyon tudtam, hogy vihetnék át 2 információt egy option value-ban. Így gondoltam, hogy tömbösítem, mert korábban már valahol csináltam ilyesmit, hogy konkrétan ez van a value-ban: value="country[id]" vagy value="city[id] (id tetszőleges szám).
Jah közben beugrott hol csináltam ilyet, egy hírlevélküldő cuccnál. Ott ajax-al így tudtam posztolni őket legkönnyebben, aztán php oldalon egy foreach ($valami as $k->$v)-ként feldolgozni.
-
CSorBA
őstag
válasz Sk8erPeter #10679 üzenetére
Ez jó ötlet! Annál is inkább, mivel value mezőben w3 szerint nem jó a [] Szóval most a következő ötlet, hogy városok két betűs kódok, ország 3 betűs. És ez alapján már különbséget is tudok tenni. Annyi a hátránya, h. figyelni kell rá város és ország felvitelekor, h. nehogy olyanba fussak, ami már foglalt.
-
CSorBA
őstag
válasz Lacces #10750 üzenetére
Szia!
Pont most csinálok egy ilyen jellegű oldalt. Biztos így gondoltad, hogy "1 hirdetőhöz, 1 hirdetés tartozik?" Szerintem gondold át, egy hirdetőnek lehet több "terméke", azaz több hirdetései is, nem?
Nálam úgy van, hogy van egy user tábla, hátha mondok érdekeset (vagy ti nekem ):
id (auto increment)
email, passhash, (emaillel lép be)
email publikus-e? email meg van-e erősítve (csak akkor tud belépni, ha ezt megteszi előtte)
számlázási cím, postázási cím (mindkettő lebontva irányítószám, város, utca)
telefonszámok (előhívó, körzet, szám)
online (engedélyezve van-e?)
regdate, utoljára itt, utolsó belépés
ügyfél típusa (vég v. magánszemély),
ügyfél titulus, keresztnév, vezetéknév, cégnév (ha nem magánszemély)Illetve van maga a termékek táblája. Aminek persze van egy id-je (ez a termék azonosítója), meg van egy userid-je, ami ugye mondhatni foreign key a usertábla id mezőjéhez.
Ha user adatlapon vagyok, akkor lekérdem a termékek táblájából a userem idjének megfelelő userid mezővel egyező sorokat.
Ha a termék adatlapján vagyok, akkor pedig a termék táblájának userid mezője alapján kérem le a users táblából a felhasználót.
Jah igen, a szerkesztés: Én úgy oldom meg, hogy sessionban tárolom az épp belépett user id-jét. Így mindig ezt ellenőrzöm, mikor szerkeszt egy terméket. Azaz ha a termék userid-je egyezik a sessionban tárolt id-vel, akkor jelenik meg csak a szerkesztési lehetőség. Meg persze a tényleges szerkesztésnél ezt megint le kell ellenőrizni (nehogy valaki átírja az url-ben, vagy postnál a postolt azonosítót, stb stb. ).
[ Szerkesztve ]
-
CSorBA
őstag
Jah ok, tiszta
-
CSorBA
őstag
válasz Forza_JUVE #10984 üzenetére
Szia!
Mi a baj a google recaptchával? Szerintem nagyon jól használható és könnyű. Ha elmondod hol akadtál el, tuti segítünk benne. Vagy már az elején gondban vagy? (Most így hirtelen nem tudom én sem, de már csináltam, és 10-15perc alatt implementálni lehetett első nekifutásra is, pedig én is kezdő vagyok)
[ Szerkesztve ]
-
CSorBA
őstag
Én egy helyzetérzékeny nyelvváltót csináltam meg így. Nem olyan szép, de egye fene. Gondoltam először, hogy referert nézek. De akkor mi van, ha linkelik? Vagy épp egyszerre több oldal van? Így gondoltam h. get-el küldöm a uri-t base64-ezve, és egész egyszerűen oda irányítom nyelvváltás után a usert vissza.
Szóval pl.::
(Csak részletek)$encoded_uri = base64_encode($_SERVER['REQUEST_URI']);
<li><a href="?lang=hu_HU&uri='.$encoded_uri.'" title="hu_HU"></a></li>
<li><a href="?lang=en_GB&uri='.$encoded_uri.'" title="en_GB"></a></li>
<li><a href="?lang=de_DE&uri='.$encoded_uri.'" title="de_DE"></a></li> -
CSorBA
őstag
Szerintem, ha lokálisan kell csak, akkor nem kell php-t belekeverni. Van pl a JAlbum, nagyon kis ügyes galéria készítő. Annyi a hátránya, hogy ha új képek kerülnek be, akkor csinálhatod (emlékeim szerint, 2-3 éve nem használtam) az egészet újra. Egy próbát megér.
-
CSorBA
őstag
Értem, így világos. Látszik rég használtam ilyen galéria dolgot, a saját oldalaimra egyszer nekiestem és megírtam, azóta az van Ígéretes ez a linkelt, elkönyvjelzőztem mindenesetre.
Más:
Nézni szeretném az oldalamra látogatókat, honnan jönnek. Esetleges bannercsere esetén tudjam ellenőrizni. A kérdésem az, hogy érdemes-e globálisan nézni a linkeléseket, vagy nézzem csak a főoldalamon?
Nem nagy valami, ezt ötlöttem ki:
if ((isset($_SERVER['HTTP_REFERER'])) && (!strstr($_SERVER['HTTP_REFERER'], $_SERVER['HTTP_HOST']))) {
<db-be mentem>
} -
CSorBA
őstag
válasz Speeedfire #11017 üzenetére
Adott munkamenetet kicsit feleslegesnek érzem. Annyira nem hinném, hogy egymás után kétszer jönne az oldalamra egy bannerre kattintva Jó, hogy említed, el is felejtettem, a google is tudja... Köszi Akkor tárgytalan.
-
CSorBA
őstag
válasz Speeedfire #11028 üzenetére
$ertek = 1/3;
echo $ertek;=> 0.333333333333
Hmm?
-
CSorBA
őstag
Mert nem lehet művelet az osztály változóinak értékadásánál. Ha lentebb állítod be, vagy konstruktorban, akkor ott menni fog.
class Test{
private $ertek;
public function __construct(){
$this->ertek = 1/3;
}
public function foo(){
echo $this->ertek;
}
}
$test = new Test();
$test->foo();[ Szerkesztve ]
-
CSorBA
őstag
Gondolkodtam melyik topik legyen, de végül php lett:
Apróság csak, de azért még is na:
Unicorn - W3C egyesített helyességellenőrző (micsoda név, lol), hibát dob W3C Internationalization Checker részen. Amit abszolút nem értek:
Non-UTF-8 character encoding declared
Explanation
The page currently uses the following non-UTF-8 character encoding declaration(s):
Content-Type: text/html; charset='UTF-8'Conflicting character encoding declarations
Explanation
The following character encoding declarations are inconsistent:
Content-Type: text/html; charset='UTF-8'
<meta charset="UTF-8"/>Pedig van egy ilyen headerem:
header("Content-Type: text/html; charset='UTF-8'");A HTML headem eleje:
<!doctype html >
<html lang="hu">
<head>
<meta charset="UTF-8">Ötlet? Mert már szétkeresgéltem magam, de fogalmam sincs. Ja, és minden fájl UTF-8 without BOM
-
CSorBA
őstag
válasz SektorFlop #11072 üzenetére
Szvsz nem jó megközelítés. Legyen az online aki 1 perce még itt volt. Szóval ne 1 v. 2-őt jelölgess. Hanem minden oldalfrissítésnél szúrd be az aktuális időpontot, mondjuk lastseen mezőbe.
És az online, akinek a lastseen mezője nagyobb, mint a mostani időpont-1perc.
szerk.: Látom, Athlon64+ megelőzött, valóban lehet az 5 perc praktikusabb.
[ Szerkesztve ]
-
CSorBA
őstag
válasz Dave-11 #11116 üzenetére
Nálam még van egy ilyen az index elején:
header("Content-Type: text/html; charset='UTF-8'");Illetve bevallom őszintén, nem tudom pontosan mire jó, de anno volt valami ilyesmi problémám, azóta benne van a db kezelésemnél az alábbi pár sor és kész:
mysql_query("SET NAMES 'UTF8'");
mysql_query("SET CHARACTER SET 'UTF8'");
mysql_query("SET COLLATION_CONNECTION='utf8_general_ci'");
mysql_query("SET character_set_results = 'UTF8'");
mysql_query("SET character_set_server = 'UTF8'");
mysql_query("SET character_set_client = 'UTF8'");Majd egy okosabb megmondja, hogy mi mire jó.
-
CSorBA
őstag
Lehet már volt, vagy csak én nem figyeltem rá. De elérési útvonal megadása érdekelne.
Pl, ha be akarok húzni egy fájlt, akkor az így néz ki:
require_once('phpmailer/class.phpmailer.php');
De cron esetében ez nem jó, helyette teljes útvonal kell, pl.:
require_once('public_html/csorba/mail/phpmailer/class.phpmailer.php');
Hogy tudom úgy megadni, hogy mindét esetben jó legyen? Azaz ha én nyitom meg, vagy a cron nyitja meg, akkor is működjön, és megtalálja.
[ Szerkesztve ]
-
CSorBA
őstag
válasz Peter Kiss #11132 üzenetére
Ne haragudj, nem értelek.
Ha teljes útvonallal adom meg, akkor a cron-ban jó lesz. Viszont közvetlen megnyitva a fájlt, nem.
-
CSorBA
őstag
válasz Peter Kiss #11136 üzenetére
Jah hogy az a teljes, és nem a public_html-ig. Értem. Köszönöm, működik
-
CSorBA
őstag
válasz SektorFlop #11139 üzenetére
Kicsit bővebben írd le. Mi az, hogy fb-n nem klappol? Mikor pl megosztasz egy cikket? Vagy alkalmazást írtak erre külön? Vagy akkor sem passzol, mikor az url-t bemásolod és megosztod?
Ha itt tartunk, akkor erre valaki: 11070
-
CSorBA
őstag
válasz Brown ügynök #11142 üzenetére
Igen, tudom. 4 validator van, az unicorn mind a négyre ellenőrzi. Természetesen a markup hibátlan. Csak kiváncsi voltam, emezt miért írja, hátha tudja valaki. Nálam minden jó, meg minden működik. Csak érdekel, miért kapok warningot. Egyébként ha nincs a header sor a kódban, akkor is ugyanúgy kapom a warningot.
szerk.: ini_set zavarta meg. Szóval
Ha van header v. ini_set UTF-8 és html5 féle megadás van a meta tagnél, akkor warningol az Internationalization Checker. Ha csak html5 féle megadás van, akkor nem. De én ebben nem bízok annyira, a header biztosabbnak tűnik
[ Szerkesztve ]
-
CSorBA
őstag
válasz Brown ügynök #11148 üzenetére
Akkor csak én nem voltam figyelmetlen, elnézést. Majd előbb utóbb fogja gondolom.
Őszintén? Nem tudom, csak rossz emlékek, és tudom, hogy valahol megoldotta már a nyűgöm, azóta úgy van mindig.
-
CSorBA
őstag
válasz pvt.peter #11215 üzenetére
<input type="reset" name="torol1" id="torol1" value="Töröl" onclick="torol('input1')"/>
Ez nem anomália, hanem a kód azt csinálja amit kell A hiba az, hogy reset az input típusa, amire a torol() eseményt kötöd. Mivel formban van, speciális dolgot csinál, vagyis alapból is resetel. Épp ezért nem szerencsés ehhez még pluszban ilyen eseményt rendelni, mert tök mindegy, hogy ellenőrzöd js-el, a reset ki fogja resetelni, mivel erre való
Így jó lesz:
<input type="button" name="torol1" id="torol1" value="Töröl" onclick="torol('input1')"/>szerk.: Offba raktam, mert ez nem a Javascript hanem a PHP topic.
[ Szerkesztve ]
-
CSorBA
őstag
válasz Brown ügynök #11148 üzenetére
Ok, nem biztosabb a header:
Safari, ajaxos selectbox feltöltés, db-ből lekérdezés. Ha bent volt a header, hiába minden utf8, fájl utf8, db utf8, valami miatt mégis elrontotta a kódolást. Kiszedtem, a headeres állítást. És jó most minden. Nem értem.
-
CSorBA
őstag
válasz Brown ügynök #11233 üzenetére
Ahh. Tényleg jó leírás, de akkor az alábbi miért van:
Minden fájl UTF-8 Without BOM-al mentve.
fájlok elején:
header("Content-Type: text/html; charset='UTF-8'");
HTML elején:
<meta charset="UTF-8" />Szép és jó a karakterkódolás.
Ajax-os hívás történik.
Egy olyan fájlt töltök be, ami:
- UTF-8 Without BOM-al mentve.
- van header az elején.Mindenhol betöltődik, kivéve Safari. Ott rossz a kódolás.
Viszont ha kiszedem a headert, jó a kódolás. -
CSorBA
őstag
válasz CSorBA #11234 üzenetére
Most őrülök meg.
nem kell a plusz aposztróf a headerben a charsethez. Szóval így a jó:
header("Content-Type: text/html; charset=UTF-8");És most már a W3C Internationalization Checker is hibátlanul fut le.
Akkor egy kis összegzés UTF-8-ból, hátha másnak is jól jön:
1,
Minden fájlt lehetőleg UTF8 BOM nélkül mentünk2,
xHTML esetén a html head részben a karakterkódolás megadása:<meta http-equiv="Content-Type" content="application/xhtml; charset=UTF-8" />
HTML5 esetén a html head részben a karakterkódolás megadása:
<meta charset="UTF-8" />
3,
PHP fájl elejére a header beállítás:
header("Content-Type: text/html; charset=UTF-8");4,
MySQL kapcsolódásnál a set names:
mysql_query("SET NAMES 'UTF8'");[ Szerkesztve ]
-
CSorBA
őstag
válasz Brown ügynök #11239 üzenetére
Ez jó kis összefoglaló, de a php Session kezelésén azóta nem javítottak már? (Nem tudom, ezért kérdezem.)
-
CSorBA
őstag
válasz Brown ügynök #11244 üzenetére
Még a sima, alap sessionnal lenne pár kérdésem.
Ugye arról van szó, hogy a gépen a PHP SESSION id-jét egy sima Cookie-ban tárolja, pl:
PHPSESSID=valamimd5számÉs ugye a fő probléma, ha valaki megszerezné ezt az ID-t, akkor a támadó a belépett felhasználónak tudná magát mutatni. Jól értem, hogy ez az ID megszerezhető csupán a hálózati forgalom figyelésével? Vagy mindenképpen találgatós módszer van? (Lenne még több kérdésem, csak ezt tisztázni szeretném.)
Mindenesetre a támadó dolgának megnehezítése az lenne, hogy a SESSION id-n kívül figyelem mondjuk az alábbiakat:
- Figyelem a felhasználó UserAgentét.
Ezzel csak az a bajom, hogy ezt sem túl nehéz kitalálni. Mondjuk legyen win7 vagy xp alatt legfrissebb Chrome vagy Firefox. Gondolom ebben semmi egyedi nincs, csak kb ennyi adatot tárol. Igaz? Pl.: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0.1 Itt kapásból itt vannak a legelterjedtebbek: [link]- A következő lehetőség, hogy figyelem a felhasználó IP címét.
Ez egyértelmű, azonban még sem teljesen jó.: Mi van, ha mondjuk egy létesítményen belül van a támadó és a felhasználó, és a külső IP címük ugyan az.
Illetve mi van, ha a felhasználó mobil eszközről van, és esetlegesen felváltva használ több hálózatot, így váltakozik az IP címe.[ Szerkesztve ]
-
CSorBA
őstag
válasz Brown ügynök #11249 üzenetére
A gyakori mit takar? Minden oldaltöltés, vagy x időnként?
-
CSorBA
őstag
Brown ügynök:
Szóval kb annyit csinálok, hogy:1, Berakom a sessiont tartalmát egy változóba.
2, Változtatok sessionid-t.
3, Visszarakom a változóból a tartalmat az új sessionba.mobal:
Ok, ezt berakom. Végül is elég valószínűtlen, hogy valaki folyamatos IP-t váltogató mobileszköztől akarna belépni.
De nem elég ezt is a sessionban tárolni? Miért rakjam adatbázisba?
Ha ellopja a támadó még is a sessionid-t, akkor összehasonlításkor a sessionban tárolt md5 hashelt useragent és ip úgysem fog stimmelni. Miért queryzzek még db-ből?[ Szerkesztve ]
-
CSorBA
őstag
Ezzel nem teljesen értek egyet, bár az is lehet, hogy én gondolom rosszul.
Szerintem a SESSION biztonságosabb, mint az adatbázis, de csak abban az esetben, ha védjük a SESSION id lopásától. (most tételezzük fel, hogy a szerveren teljesen védve van a sessiont tároló fájlrendszer)
Itt eleve pont ettől védem. Nézzük mi van a sessionunkban:
- ugye alapból van neki egy id-je
- userid (ha ez létezik, akkor be van lépve, illetve tudom, hogy kiről van szó)
- security_token - md5(IP-USERAGENT)Minden oldalletöltésnél legenerálom a felhasználóm (vagy támadóm) md5(IP-USERAGENT) hashét, és összehasonlítom a jelenlegi SESSION-ban security_tokenjével. Ha nem egyeznek, kidobom.
Ha ellopja a session id-t, akkor jó esetben el fog térni ez a security_token. És kidobom.
Emellett csinálhatom azt, amit Brown Ügynöknek írtam, hogy folyamatosan változtatom a SESSION id-t.
Most nem értem, miért kellene adatbázisban tárolnom? Ha ellopja az id-t, és még sikerült ugyanazon ip-t, user agentet is előállítania, akkor már olyan mindegy, hogy db-ből nézem, vagy sessionból. (de pont ezt fogom megakadályozni a folyamatos id váltással) Feleslegesnek érzem a táblás tárolást.
Az már más kérdés, hogy mi van akkor, ha folyamatosan váltom az id-t, és a támadom ÉPPEN elkapja a jót, épp belép, épp oldalt tölt le, és Ő fogja megkapni onnantól a valid id-t, és a felhasználómat vágja ki... Bár valljuk be, ennek nagyon kevés esélye van. Az alábbiaknak kellene teljesülni:
- Hálózati forgalom figyelésével, két oldalletöltés között elkapni a session id-t.
- Egy ip-ről lenni.
- Eltalálni a User agentet. -
CSorBA
őstag
válasz Sk8erPeter #11331 üzenetére
FB-nél régen meg lehetett szabni teljesen. Külön meg lehetett adni az API-nak a CSS fájlt, és azt behúzta és feldolgozta, és színezgetett pl egy Comment boxban mindent. Az újnál már nem lehet :S
-
CSorBA
őstag
Privátban kaptam kódot, de visszaterelem a fórumtársat inkább ide:
Ajjjajajajajj.Hol is kezdjem
1,
1 formban 1 submit lehet csak.2,
A submit csak elküldi a formot, ahhoz hogy adatot is küldj vele, bele kellene raknod az adatokat "valamibe" (pl.: input, textarea, checkbox, radio). /Ezért lehet kapok még leszólást a fórumtársaktól, csak megpróbáltam érthetően elmagyarázni.../
Szóval ha te megnyomod a "Törlés!" gombot, akkor attól honnan tudná a php, hogy mit töröljön? Kellene neki küldeni valamit. Mondjuk nálad a tetel_id-t bele kellene rakni egy hidden inputba, mert attól, hogy ott a táblázatban van, nem fogja elküldeni.<input type="hidden" value="<?=$sor["mozgastetel_id"]?>">
(a html részben helyettesíthető a print parancs közvetlen egyenlőségjellel, ahogy itt írtam)Mellesleg, $id = $_POST['mozgastetel_id']; itt is tessék escapelni!!!
-
CSorBA
őstag
Az egy dolog, de nem jó.
Gondold el van egy oldalad, amin van két tevékenység:
Törlés
Szerkesztés
És mindkettőnél a formban küldesz valamit, amit ugyanúgy nevezel el. A php honnan tudja, hogy most te melyiket akartad küldeni, ha mindkettőt elküldted. Még most az elején szokj le róla, és szedd szét a formot, annyira, ahány submited van. -
CSorBA
őstag
válasz Sk8erPeter #11362 üzenetére
Tény, hogy ez nem teljesen helytálló kijelentés volt, de érted hogy értettem na. Most nem akarom még jobban megkavarni, mikor tényleg az alap html sem megy neki. Jobb ha külön csinál mindent.
-
CSorBA
őstag
Logikus, a die azért van benne, ha nem sikerül, akkor "haljon meg/lépjen ki" és ne csináljon semmit. Ha ezt kiszeded, akkor nem lép ki, de nem is tud mit csinálni, mert már előtte van valami hiba
mondtam már, hogy ne csak táblázatba rakd, hanem vmi inputba is:
írd át azt a sort erre:
<td><?php echo "<input type=\"hidden\" name=\"mozgastetel\" value=\"" . $sor['mozgastetel_id'] . "\"/><a href=\"inc/teteltorles.php?id=" . $sor['mozgastetel_id'] . "\">Törlés</a>";?></td>
De ebbe a ronda kódba már kezdek belezavarodni, szóval inkább erre:
<td><input type="hidden" name="mozgastetel" value="<?=$sor['mozgastetel_id']?>" /><a href="inc/teteltorles.php?id=<?=$sor['mozgastetel_id']?>">Törlés</a></td>
[ Szerkesztve ]
-
CSorBA
őstag
válasz Peter Kiss #11424 üzenetére
Azt nem is néztem. Igazából erőm sincs az egészet nézni
-
CSorBA
őstag
válasz RootRulez #11426 üzenetére
Elsőnek nézd meg, hogy milyen php verzió fut. Csinálj egy fájlt ezzel a tartalommal, majd futtasd:
<?php phpinfo();
Lehet még 4-es php fut, azon pedig ez a funkció nem támogatott. Nekem mintha úgy rémlene, hogy lehet változtatni vmi admin menüben, hogy melyik php fusson. Bár erre nem esküdök meg, régen láttam uw-s oldalt.
-
CSorBA
őstag
válasz Peter Kiss #11438 üzenetére
Mondjuk számtípusoknál én cast-olnék vagy filtereznék, nem escape-elnék.
+1
-
CSorBA
őstag
Cron jobnál nincs SERVER tömb, hogy tudom akkor kinyerni a HTTP_HOST-ot?
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs