Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
válasz
akopacsi #3635 üzenetére
1.) Először mindenképp a PHP-s ellenőrzést csináld meg, hogy az működjön, hiszen a JavaScript a böngészőben kikapcsolható, a PHP nem. Aztán utána jöhet a JavaScript-es ellenőrzés elkészítése, hiszen annak a működése kliens oldali, így értelemszerűen gyorsabb.
A legegyszerűbb, ha a $_POST adatok (vagyis az űrlap által elküldött mezők tartalmának) meglétét ellenőrzöd, az isset() és/vagy empty() függvénnyel.
Pl. if( !isset($_POST['az_egyik_urlapmezo']) ) { /* hibaüzenetek tárolása, vagy akármi hasonló... */ }
Ezután a következő lépés attól függ, a felhasználó számára szeretnéd-e felsorolni az összes hibát, vagyis az összes mezőt, ami még kitöltetlen, vagy sem (pl. csak kijelzed, hogy valahol hiba van, és kész). Erre is van többféle megoldás is, egyik egyszerűbb az, hogy mondjuk egy $hiba=""; változót inicializálsz az elején, és mindig hozzáfűzöd az aktuális hibasztringet, ha valahol hibát észleltél ($hiba .= 'Nem adta meg a nevét! <br />'; és ehhez hasonlók), és aztán mielőtt elküldenéd pl. adatbázisba az adatokat, ellenőrzöd, hogy a $hiba sztringed üres vagy sem. No meg attól is függ a dolog, hogy azonos oldalon dolgozod-e fel a kapott adatokat, vagy kiküldöd valami másik fájlnak, ami csak a feldolgozásért felel. Ha másik fájlba küldöd a feldolgozást, akkor egyik lehetséges megoldás a $_SESSION változók használata - pl. a hibasztringnek is beállíthatsz akár egy külön $_SESSION['hiba'] változót, aztán ezt kiíratod a form előtt; vagy azt is csinálhatod, hogy minden mezőnek külön $_SESSION változója van, és akkor akár rögtön a hiányos mező mellett is kiírathatod az üzenetet.
Utóbbi esetben (ha más fájlnak küldted ki a feldolgozást, és $_SESSION változókat használsz) csinálhatod azt is, hogy a júzernek ne kelljen még egyszer begépelni az adatokat, hogy
<input name="az_egyik_urlapmezo" type="text" id="az_egyik_urlapmezo"<?php if(isset($_SESSION['az_egyik_urlapmezo'])) echo ' value="'.$_SESSION['az_egyik_urlapmezo'].'" ';?> />A Javascriptes ellenőrzés: tételezzük fel, hogy van egy label mező is az input előtt (persze egyébként XHTML szabvány szerint a labelnek valami külön elemben kéne lennie, pl. div vagy táblázatmező vagy ilyesmi):
<label for="from_name" id="az_egyik_urlapmezo">Az egyik űrlapmező</label>
<input name="az_egyik_urlapmezo" type="text" id="az_egyik_urlapmezo"<?php if(isset($_SESSION['az_egyik_urlapmezo'])) echo ' value="'.$_SESSION['az_egyik_urlapmezo'].'" ';?> />Akkor ilyesmi lesz a Javascript erre vonatkozó egyik ellenőrző sora:
function formcheck(){
var hiba = '';
/***** Az egyik űrlapmező ellenőrzése******/
var urlapm = document.getElementById('az_egyik_urlapmezo');
var urlapm_label = document.getElementById('az_egyik_urlapmezo_label');
if ( ( urlapm.value.length==0 ) || (urlapm.value==null) ) {
hiba+='Nem adta meg a nevét!\n';
urlapm_label.style.color="#FF0000"; //red
}
else{
urlapm_label.style.color="#000000"; //black
}if(hiba!=''){
alert(hiba);
return false;
}
else {
return confirm('Kész?');
}
}Ez azt csinálja, hogy piros lesz a label mezőben található szöveg, így egyértelműen látszik, hol a hiba.
Persze a submit gombodhoz tedd be ezt:
<input onclick="return formcheck();" type="submit" name="send" id="send" value="Elküldés" />Az, hogy hányadikra küldték el a formot, mindegy kell, hogy legyen.
2.) Ha kisebbet kellene készítened a képből, nézz körül az imagecopyresampled() függvénynél, ott a felhasználói hozzászólások között biztos, hogy van egy-két kész megoldás, amit akár elég, ha kimásolsz.
Remélem nem fogalmaztam túl nehézkesen, vannak a leírtaknál szebb megoldások is, de most szerintem ez a legegyszerűbb.
-
Sk8erPeter
nagyúr
válasz
Sk8erPeter #3630 üzenetére
"ahol mondjuk változó a tartalom" Nem mintha csak ettől függne, de számomra nem igazán érthető, miért van szükség aláíratlan tanúsítványra, ennyire paráznak, hogy valaki jól meghekkeli a BME-s tanulmányi oldalakat mondjuk bosszúból, hogy kirúgták?
-
Sk8erPeter
nagyúr
Valóban rosszul tettem fel a kérdést, nyilván számít, hogy milyen típus. Egyelőre mindegyik mezőnek TEXT típust adtam meg, itt nem kell méretkorlátot megadni, és valszeg biztos belefér. Kivéve persze az azonosítószámot tartalmazó mezőt, ahol int típust adtam meg. Persze a dátumnál lehet, hogy DATE típust kellett volna megadni, stb., de ott valszeg figyelni kellett volna a formátumra, sajna nem volt időm utánanézni. Csak gondoltam hátha van valami javaslatod az egyes mezőtípusokra ebben a konkrét esetben.
(#3629): "A másik, hogy ha nem igényelsz (pénzért) egy hitelesített cert-et, akkor inkább csak bosszantó lesz az egész a felhasználónak."
Tanúsíthatom, egyes BME-s oldalaknál rohadt idegesítő a nem hitelesített tanúsítvány meg a https-es forma, statikus tartalmaknál (órarendek, tárgyi adatlapok, stb.) nem is értem, minek ragaszkodnak annyira hozzá...(meg ez is egy példa, ahol mondjuk változó a tartalom, de nem értem, miért muszáj hozzá https)
-
Sk8erPeter
nagyúr
válasz
Tele von Zsinór #3626 üzenetére
Köszi szépen, ezeket mindenképp kipróbálom!
Amúgy valóban, nem is annyira az egész oldal betöltődési sebességére voltam kíváncsi, hanem a scriptek lefutási sebességére.
Egyébként gondolom ez ugyanúgy függ a szerver aktuális leterheltségétől, nem? Vagy attól nem lesz olyan releváns a különbség? -
Sk8erPeter
nagyúr
A dolog hibátlanul működik, cucka, ismét nagyon köszönöm a segítséget!
Még annyival kiegészítettem, hogy belepakolom az adatbázisba a user agentet is, statisztikai célokból.--
Abban tudnátok segíteni, hogyan tudnám PHP segítségével pontosan mérni az oldal betöltődési sebességét? Akár microsecundumos pontossággal. Érdekelne, hogyan változnak a betöltődési sebességek, bár tudom, ez összetett, nemcsak az oldalon történhetnek változások, ami miatt átmenetileg lassabbnak tűnik a letöltés, stb... Na meg azt is vágom, hogy a Google Chrome Developer Tools-ával lehet különböző méréseket végezni, de akkor is érdekel.Köszi az ötleteket!
-
Sk8erPeter
nagyúr
válasz
Tele von Zsinór #3616 üzenetére
Akkor ezek szerint mégis igazam volt, ha XHTML-ről van szó.
-
Sk8erPeter
nagyúr
Kérdésem még pluszban ezzel kapcsolatban:
az egyes adatmezőknél számít bármit is az, hogy milyen típust határozok meg: VARCHAR, TEXT, stb.?
A select count(*) as cnt résznél az "as cnt" csak annyit jelent, hogy a lehívás után cnt-ként hivatkozhatok rá?
Nemsokára el tudok kezdeni foglalkozni a dologgal, ezért érdekelne. Köszi! -
Sk8erPeter
nagyúr
válasz
raczger #3607 üzenetére
Hű, tényleg nem szintaktikai hiba, inkább ajánlás. Igazad van.
Most a szabványt keresgéltem, egyelőre nem találtam, csak ezt a két cikket: [Why attribute values should always be quoted in HTML, or the saga of the slashed validators], [Should I put quotes around attribute values?]
Ha egyáltalán nem rakja valaki idézőjelekbe, az para lehet elérési utaknál (pl. a linkelt példában: SRC=foo.gif elmegy, SRC=images/foo.gif már nem).
Egyébként szerintem jó, ha következetes az ember, én pl. mindig macskakörmöt használok, így szoktam meg, számomra így átláthatóbb. Ha valakinek a sima aposztróf, az is oké, csak használja következetesen. -
Sk8erPeter
nagyúr
válasz
Speeedfire #3598 üzenetére
Nem nagyon tanulmányoztam át a kódodat, de ami már első ránézésre igencsak feltűnt, és NAGYON rossz megoldás:
- nincsen <body> elemed, viszont lezárod a törzsrészt a </html>-lel, és utána még kiíratsz dolgokat;
a megfelelő struktúra:
<html>
<head>
<!-- meta tag-ek -->
<title>Az oldal címe</title>
<!-- meghívandó scriptfájlok, JS-függvények, CSS-fájlok, stb. -->
</head>
<body>
<div>Az oldal érdemi része, megjelenítendő elemek</div>
</body>
</html>- szintaktikai hibának minősül, ha a HTML-ben az átadott paramétereket NEM "macskakörmök" közé rakod:
echo "<table width=100% border ='0' bordercolor='#cccccc' cellpadding='10' cellspacing='6'>
<tr>";
HELYETT akkor már
echo '
<table style="width:100%;border:0px" cellpadding="10" cellspacing="6">
<tr>
'; //nincs értelme border-color-t meghatározni, ha 0px szélességű amúgy is..., stb.
- biztos lenne még mit javítani, most nincs időm átnézni -
Sk8erPeter
nagyúr
Köszönöm a válaszokat, ez alapján már meg tudom csinálni!
Holnap meg is csinálom. Szerintem az egész próbálgatása nem lesz több 20 percnél.
Köszi a segítséget!
(#3597) 1ed: neked is many thanx, hogy megnézted!
Majd holnap még jelzek a próbálkozásaimról, most már a holnapi mérés laborra kell tanulnom.
A Zend_mailt ezen az oldalon nem tartom érdemesnek használni, mert így is csupán "önszorgalomból" raktam bele az oldalba az "Elérhetőségek" részhez, hogy ha valaki nagyon akarja, el tudja érni őket. Előreláthatólag nem lesz rajta nagy forgalom. Ezért szeretném minél jobban leegyszerűsíteni a dolgot, ez működik, legfeljebb ékezetek nélkül lesz, ha mégse sikerülne megoldani.
-
Sk8erPeter
nagyúr
válasz
fordfairlane #3595 üzenetére
Sajnos ezzel is teljesen zagyva szöveget kapok.
"akĂĄrki teniszĂźtĹ�"Majd holnap még próbálkozom, köszi az eddigieket!
Ha esetleg közben még eszedbe jut valami, szólj.
-
Sk8erPeter
nagyúr
Köszi, ez így tényleg egyszerűbb!
(hozzátok képest mindig túlbonyolítom a dolgokat, ti biztos, hogy mindig tudtok mutatni tömörebb kódokat
Mondjuk ez biztos kialakul majd, amikor csupán pár hónaposnál több tapasztalatom lesz.
)
A látogatószámot egyébként emberünk azt szeretné, ha kiraknám az oldalra, jól látható helyre. Akkor ha a konkrét látogatószámra vagyok kíváncsi, akkor csak annyi, hogy csökkenő sorrendbe rendezem a sorokat, és simán kiolvasom az első találat id-jét? (hogy megtudjam, hanyadik sornál tart az automatikusan inkrementálódó sor?)
Még egy fontos kérdés, amire a válasz szerintem igen, de lehet, hogy tévedek: minden egyes új session_id-jű júzernél teljesen üres sessionnel kezdünk, ugye? Tehát a $_SESSION['user_visit_stored'] még véletlenül sem maradhat 1-ben korábbi látogató miatt, ugye? -
Sk8erPeter
nagyúr
válasz
fordfairlane #3590 üzenetére
Áhh, nem hiszem el, hogy ilyen hülye vagyok. Az eredeti kódban jól tüntettem fel a neveket, csak itt annyit módosítgattam már, hogy aztán végül sikerült átírnom, és így meg nyilván azokat a hibaüzeneteket kaptam, amiket írtam...
Még ott is volt kommentben az eredeti, akkor láttam, hogy elkövettem azt az állatságot, hogy végül valahogy átírtam.
Bocs, ide is így másoltam be.
Látszik, hogy 4 órát aludtam.
--
Na, most kipróbáltam a jó kóddal, a példánál maradva ismét "Akármi teniszütő" névnél maradva (ebben sok az ékezet), és ezt kaptam eredményül a freemailnél a feladó mezőben:
QWvDoXJraSB0ZW5pc3rDvHTFkQ==Outlook Express-ben lehívva ismét egyáltalán nincs feladó.
Pedig most így van:
$headers .= "From: =?ISO-8859-2?Q?".base64_encode($felado_neve)."?= <$felado>" . "\r\n";
(A $felado_neve és a $felado voltak az eredeti változók, ide fórumra csak azért nem akartam így bemásolni, nehogy kapjam az oltást, hogy milyen már, hogy angol neveket keverek magyarral - és ebből következett a korábbi félreírás...)
Valóban, a quoted_printable_encode() 5.3-asnál régebbi verziókhoz való megírt függvényt nem is láttam...
-
Sk8erPeter
nagyúr
Köszi! Akkor tehát az lenne a megfelelő, ha már az oldal megnyitásakor csatlakoznék az adott adattáblához, és az ott tárolt mezőkben megnézném, hogy létezik-e már adott session id, ha igen, akkor következik az, hogy nem kell csinálnom vele semmit, ellenkező esetben viszont eltárolom az adott mezőbe, és létrehozok mondjuk egy változót, ami tárolja, hogy adott id-jű session már kipipálva?
Most sebtiben ilyesmire gondoltam, még persze nem próbáltam ki, csak agyalok, így lehetnek benne hibák:
//tételezzük fel, hogy már csatlakoztunk az adatbázishoz
$id = session_id();
$query = "SELECT * FROM visit_table WHERE visit_id = '$id' ";
$query = mysql_query($query);
if( isset($_SESSION['visited']) && ($_SESSION['visited'] == true) && mysql_num_rows(query)>0)
; //nem csinálunk semmit
else{
$query = "INSERT INTO visit_table ( visit_id, date )
VALUES ( '$id', '$date' ) "; //tételezzük fel, hogy $date már beállított
if ( !mysql_query ($query) ){
//hibaüzenetek...
}
$_SESSION['visited'] = true;
}Ilyesmire gondoltál?
Újabb session_id-jű emberkénél már nem lesz beállítva a $_SESSION['visited']?
Szólj, ha valami nem stimmel.
Előre is köszi ismét! -
Sk8erPeter
nagyúr
Megköszönném, kíváncsi vagyok, azzal jó-e.
Bár mint látjuk az se mindegy, milyen levelezőt használsz
Gmailnél tökéletes, de másnál nem, akkor valami mégis sántít.
______________________
Még egy feladatban kérném a segítségeteket:
látogatószámlálót kellene készítenem, és emberünk ragaszkodik ahhoz, hogy semmiféle IP-cím alapján történő szűrés ne legyen, vagy ehhez hasonló, hanem mindig növekedjen eggyel a látogatószám, ha UGYANAZ a felhasználó akár még aznap visszatér az oldalra.
Ingyenes számlálóknál nem tetszett neki, hogy ez nem történik meg, ha ő mondjuk aznap visszatér, de volt, hogy akár másnap is maradt ugyanolyan a látogatószámláló értéke (még tesztelés alatt álló honlap, így nyilván nincs nagy látogatószám). Az a megoldás meg nagyon gáz, ha minden kattintásra nő egyet a látogatószám.Egyelőre arra gondoltam, hogy esetleg lehetne session id-ket tárolni, és az alapján megnézni, hogy amennyiben az nem volt még, akkor nőhet eggyel a látogatószám.
De persze lehet, hogy van sokkal jobb megoldás is erre. Na meg kérdés, hogy adatbázist (automatikusan inkrementálódó mezővel, vagy ilyesmi) érdemes használni, vagy fájlba írást.Ti hogy oldanátok meg a látogatószámlálót? Jól jönne egy-két ötlet.
-
Sk8erPeter
nagyúr
válasz
fordfairlane #3586 üzenetére
A quoted_printable_encode() csak 5.3.0-nál vagy afelett elérhető, ennél sajnos pont eggyel régebbi van, így más megoldáshoz kell folyamodnom.
"Az lehet a probléma, hogy nem szabályosan van megformázva a From mező"
Mire gondolsz? A következő sor vonatkozik a headernek a from mezőjére:
$headers .= "From: $sender_name <$sender_name>" . "\r\n";
Itt a $sender_name részt RegEx(p)-sz(/p)el ellenőrzöm, az alábbi kódot innen megfelelőnek találtam:
preg_match('/^[A-z0-9\-_]+(\.[A-z0-9\-_]+)*@(([A-z0-9]+\-?[A-z0-9]+)+\.)+[A-z]{2,6}$/', $input);
az inputba meg nyilván a $_POST cucc kerül.
Az e-mail cím maga helyes.Ellenőrzés után következik a fejléc elküldése.
Próbálkoztam már igen sokféleképpen, már teljesen össze vagyok zavarodva, lehet, hogy még a példákat az általad linkelt cuccból is félreértettem:
SAJÁT példák, egyik se jó:
$headers .= "From: =?ISO-8859-2?Q?".base64_encode($sender_name)."?= <$sender_name>" . "\r\n";
Vagy a másik:
$headers .= "From: =?UTF-8?Q?".base64_encode($sender_name)."?= <$sender_name>" . "\r\n";
Vagy a Q helyett B-t írva (őő mi is a különbség?):
$headers .= "From: =?UTF-8?B?".base64_encode($sender_name)."?= <$sender_name>" . "\r\n";
ezt dobja (jó, mondjuk érthető, mert ez már nagyon zagyva):
=?UTF-8?B??=@freemail.hu, UNEXPECTED_DATA_AFTER_ADDRESS@.SYNTAX-ERROR.Szóval nem tudom, mi lenne a helyes megoldás.
-
Sk8erPeter
nagyúr
válasz
Sk8erPeter #3583 üzenetére
Megnéztem a freemail új webmail-felületén (csak most látom, hogy már nem is olyan ratyi, mint régen), ott maga a törzsrész jól jelenik meg, de a feladónál ezt írja:
INVALID_ADDRESS@.SYNTAX-ERROR
Érdekes. És nem értem.OE-ben továbbra sem vágom, mi lehet a baj. Rosszul gondolkozom, hogy hozzáfűzöm az előbb említett sorokat?
-
Sk8erPeter
nagyúr
válasz
fordfairlane #3582 üzenetére
Ez most ismét a TÁRGYra vonatkozik, nem? Nekem a FEJLÉCCEL van a bajom.
_________________________________________________________________
Újdonság: Gmailben teljesen normálisan jelenik meg. Már kínomban próbálkoztam mindenféle függvénnyel, iconv()-vel és társaival (amik átkódolnak), most visszaraktam az eredetire, és jó, de CSAK Gmailen, a T-Online-os szerveren szar.Ez most miért van?
Így néz ki a kód:
$headers = 'MIME-Version: 1.0' . "\r\n";
$headers .= 'Content-type: text/html; charset=utf-8' . "\r\n";
$headers .= "From: $sender_name <$sender_name>" . "\r\n";A $sender_name meg egy űrlapból származik.
Tehát a t-online-os webmail-felületen a feladónál így jelenik meg az "Akárki teniszütő":
"Akårki teniszßt�"
Gmailen teljesen normálisan, jó ékezetekkel. A Gmail ezek szerint "le tudja ezt kezelni"?
Vagy mi más?Feltételezem, hogy a freemailen is bajok lennének... Mindjárt kipróbálom.
Az a gáz, hogy nem várhatom el, hogy a levél fogadója most emiatt térjen át a Gmail használatára.
Van tippetek, mi az oka, hogy Gmailben okés a dolog? Csak annyi, hogy a t-online beleszarik az ilyen dolgokba, hasonlóan ahhoz, ahogy a webmail felület kinéz? (aki nem ismeri: egy gány fos, olyan, mint a régi freemail)Szerk.: ez egyre érdekesebb. Kipróbáltam freemailen a cuccot, és ennyire gagyin még nem nézett ki a dolog egyiknél se.
Arról van egyébként szó, hogy van egy felület, ahol TinyMCE-vel lehet szöveget formázgatni, majd a júzer elküldi a formot, én meg a PHP-ben hozzáfűzöm a
<html><head><title>akármi</title><body>$message</body></html>
tageket, hogy "rendes" HTML-formátumú levél legyen.
Csak hogy a júzer örüljön, hogy milyen jó, hogy még félkövéríteni is lehet, blabla...Ez még t-online-os és gmailes szerveren teljesen jól is jelenik meg, freemailnél, ha a levelet fogadom Outlook Express-ben (direkt próbáltam ezzel), akkor a levélnek nincs feladója (!!), tök üres az a rész, ráadásul a levél törzsrésze így néz ki:
Content-type: text/html; charset=utf-8
From: <>
Message-Id: <20091210144029.D21B617789D@server1.newhosting.hu>
Date: Thu, 10 Dec 2009 15:40:29 +0100 (CET)
X-Freemail: message scanned
<html><head><title>Akårki teniszßt� ßzenete</title></head><body><p>123</p></body></html>Ennek mi lehet az oka?
-
Sk8erPeter
nagyúr
Hali!
Nem ezzel van a gond, hanem a "headers" résszel. A tárgy és maga az üzenet is helyesen jelenik meg, köszönhetően a '=?UTF-8?B?'.base64_encode($subject).'?=' résznek (tárgynál!!), tulajdonképpen ugyanezt használom, DE ettől még a headerben a feladónál az ékezetek nem jelennek meg. És ha erre nincs megoldás, akkor kénytelen vagyok az ékezetes betűket átalakítani ékezet nélkülivé.Ezenkívül a pear.php.net egyik bejegyzésében ezt olvastam: [link]
"Header values have to be ascii - you need to encode them properly first (see RFC 2047)."
Ezek szerint nem lehetnek benne ékezetes betűk? Akkor nem igazán vágom, hogy oldják meg mégis az ékezetes feladónevek küldését a Zend_Mail-nél meg hasonlóknál? Vagy utóbbiaknál sem működik az ékezet, azt egyszerűen levágja? Még nem próbáltam.(#3578) lezso6: Nálam ha megnyitom, akkor ugyanazt látom (most épp t-online-os fiókon próbálom, webmail-felületen): példa: "Akárki" (Akárki). Vagy: TeniszütÅ‘ (Teniszütő). iconv()-vel: "Ak?rki Tenisz?t??".
-
Sk8erPeter
nagyúr
Hali!
A mail() függvény használata során merült fel az a problémám, hogy ha a feladó nevét elküldöm a headerben, és ékezeteket is használok, akkor helytelen formában küldi el. A tárgy és üzenet részt már sikerült megoldani, de hogyan lehet a headerben küldött infókat is ékezettel együtt elküldeni? Azt hiszem, php.net-en azt olvastam, hogy ASCII-nek kell lennie - de akkor magyarul nem lehet benne ékezet? Furcsállnám, ha nem oldották volna meg, hogy lehessen PHP-vel is ékezetes header-infókat küldeni.Előre is köszi!
-
Sk8erPeter
nagyúr
válasz
chubby1980 #3565 üzenetére
Egyébként van valami különleges oka, hogy frame-eket használsz? Sokat lehet vele szívni.
-
Sk8erPeter
nagyúr
válasz
lakisoft #3543 üzenetére
Newhosting. Ingyenes! Elégedetten használom már egy ideje (3 domainnel!), PHP (5.2.9. verzió) és MySQL hibátlanul működik.
Tényleg ingyenes, nincs reklámcsík, és nem kötelező felpakolni az oldalra a bannert sem. Hogy hogyan éri meg NEKIK, ne kérdezd.(csak tipp: esetleg ezáltal akarják vonzóvá tenni a későbbi fizetős csomagjaikat, hogy akinek betelt a tárhelye, az vegyen pluszban még náluk)
- 3000 MB ingyen tárhely
- egyedi domain név használata
- másodlagos domain név használata
- reklámmentes tárhely
- ispCP alapú kontrol panel
- egyéni hibaoldalak használata
- részletes statisztikák
- PHP/MySQL használat
- POP3/IMAP email fiók
- FTP hozzáférés
- CMS rendszerek használata
- spam, és vírus szűrés
- napi adatmentés
- gigabites kapcsolat
- 99,9%-os rendelkezésre állás -
Sk8erPeter
nagyúr
válasz
Sk8erPeter #3539 üzenetére
Áhh, második rész tárgytalan. Rájöttem, hogy mégis sikerült elcseszerinteni a .htpasswd fájl elérési útját... Amilyen suta voltam, a fájlt .htpassword néven mentettem el, és a .htaccess-ben pedig .htpasswd néven hivatkoztam rá, még jó, hogy hibát dobott (nem létezett az általa keresett fájl). Jól beírva működik.
A kérdés első része továbbra is megoldatlan.
Még egy kérdés: a .htaccess-szes levédés (mondjuk .htpasswd-del titkosítva/hashelve, akár ilyen módon) van ugyanolyan jó vagy ugyanolyan rossz, mint az adatbázisból való jelszólekérés?
Tehát van különbség a kettő között (egyik jobb vagy rosszabb)? Vagy mindkettő pontosan ugyanannyira feltörhető?
Ahogy arról korábban beszéltünk, "gyorsabb" módszerek esetén nem a jelszó visszafejtésével próbálkoznak, hanem máshogy. Melyik a jobb? Vagy tök mindegy?
Most nyilván nem érdekes, mennyire "szép" vagy nem az a bejelentkező felület. -
Sk8erPeter
nagyúr
Kicsit OFF, de esetleg meg tudjátok mondani, Notepad++-ban az FTP synchronize beépülőben hogyan jeleníthetők meg a .htaccess és .htpassword rejtett fájlok?
Total Commanderben meg tudom jeleníteni FTP-n is a rejtett fájlokat, mivel ott nem túl nehéz megtalálni (Hálózat menü » "FTP rejtett fájl látszik"), de Notepad++-ban valahogy nem találom ezt az opciót. Notepad++-ban szeretném szerkeszteni, és egyből feltölteni.
Gugliztam már eleget, de nem leltem rá a megoldásra.Még egy:
a .htpassworddel való levédés az egyik oldalon tökéletesen működik, a másikon (másik domainnel!) Error 500-at dob. Ezzel kapcsolatban csak a kiszolgáló tud segíteni, hogy megoldja? Próbáltam már mindenféleképpen beállítani a rootot (nyilván a helyes beállítás volt az első, a másik oldalon ugyanígy csináltam), de nem hajlandó működni. A jelszó elfogadása után történik az Error 500. -
-
Sk8erPeter
nagyúr
Most miről beszélsz? Egyetlen sorrol, a tr class-nál? Nem én gányoltam össze, javítottam egy korábbi, egyáltalán nem működő verziót, ez működik, nem azt mondtam, hogy tökéletes. Egyébként is, az eredeti (nem az általunk módosított) kód gány, nem én hánytam így össze...
Na meg a franc fog a szépítgetéssel törődni éjfél közeledtével. -
Sk8erPeter
nagyúr
válasz
Gyuri16 #3495 üzenetére
Pont hasonlót akartam írni, de ha már megtetted, akkor én nem fárasztom vele magam
de akkor már javítom a Tiédet:
if $szam % 2 = 0
HELYETT
if ($szam%2 == 0)És érdemes inkább a td-t (nem a tr-t) class-ba rakni, hogy működjön.
$szam=0;
while ($sor = mysql_fetch_array($eredmeny,MYSQL_ASSOC)) {
if ($szam%2 == 0) {
echo "<tr><td class="zold">${sor['evf']}</td><td>${sor['szak']}</td>.......<td>${sor['k6']}</td></tr>";
} else {
echo "<tr><td class="piros">${sor['evf']}</td><td>${sor['szak']}</td>.......<td>${sor['k6']}</td></tr>";
}
$szam++;
}És a dokumentum HEAD részébe pedig ezt kell tenni:
<style type="text/css">
td.zold
{
background-color: green;
}
td.piros
{
background-color: red;
}
</style>__________
Szerk.: hehe, frissíteni kellett volna, valaki gyorsabb volt...
(#3496) fordfairlane:
echo "<tr class='zold'>";
HELYETT inkább így szabványos (macskakörömmel), nemde?
echo '<tr class="zold">';
És akkor az echo-nál meg lehet sima aposztróf... Persze, működik eredetivel is, de hát ha már...
VAGY
echo "<tr class=\"zold\">"; -
Sk8erPeter
nagyúr
Hát nyilván, mivel sehol sem ellenőrzöd, hogy egyáltalán be van-e állítva bármi is, írt-e a felhasználó valami adatot. Csak azt ellenőrzöd, hogy ha írt, akkor azon belül szám-e, stb...
Lehetne egy olyan feltételed is, hogy
if ( $menteni==0 && isset($pix, $menyibe, $ftmenyi, $menyirend) )
{
//... adatbázis feltöltése...
} -
Sk8erPeter
nagyúr
Első észrevétel: kapásból rossz a hibafeltételed, mivel !isset($_POST["pix"]) szerepel benne, vagyis épp rosszat vizsgálsz, ha valamit megadott a júzer, soha nem fog belelépni ebbe a feltételágba, mivel itt azt nézed, hogy mi van, ha NEM adtak meg semmilyen adatot, és a SEMMILYEN adat szám-e vagy sem, stb.
Tehát szedd ki azt a felkiáltójelet!Második észrevétel: döntsd el, hogy $pix VAGY $_POST["pix"]-et használsz, és használd azt következetesen.
Harmadik észrevétel:
"Azt, hogy lehet meg oldani, hogy elsőre mikor üres a form ne fusson le a az adatbázis írása?"
Hát nyilván ne így tedd be az adatbázisírás műveletét, hogy mindenféle feltétel-ellenőrzés NÉLKÜL lefut... Csak akkor engedélyezd, ha minden feltétel stimmelt, a felhasználó minden megkövetelt mezőt kitöltött.
Igencsak gány megoldás, de jelenleg ennél a tök egyszerű cuccnál akár változót is figyelgethetsz, ezt persze komolyabb rendszereknél már nem így csinálják, hogy mit tudom én, elején beállítod, hogy $mehet=1; aztán ha hiba van, akkor $mehet=0; -ra állítod, és azt vizsgálod az írásnál, hogy if($mehet), vagyis ha a $mehet értéke 1, csak akkor írjon az adatbázisba... De mondom, ez kicsit ratyi, mindjárt úgyis leolt érte valaki.Sőt, még olyat is csinálhatsz, hogy beállítod az elején, hogy $hibasztring = '';, aztán ha hiba van, akkor abban a feltételágban: $hibasztring = $hibasztring . "Hibásan van ki töltve a 4.2-es kérdés, értéke:".$pix;, a legvégén pedig if(empty($hibasztring)), akkor mehet a feltöltés, egyébként pedig írja ki a hibaüzenetet ( else echo $hibasztring; ).
Persze lehet azt is, hogy egyből return-ölsz az adott hibaüzenettel, de akkor kapásból az első hibánál vissza fog térni.
Szépen kivételkezeléssel szokták megoldani, de ez még valszeg bonyolult lenne neked. -
Sk8erPeter
nagyúr
Pont erre írta cucka: [link] --> "Extract() függvény használata nagyon nem javasolt"
És még egy, amire már cucka felhívta a figyelmet: "az empty() a 0-ra és az üres tömbre is boolean true-val tér vissza".
Tehát térj vissza az isset() használatára, hogy ne dobjon hibát, ha a felhasználó 0-t ír az adott mezőbe.
if ( isset($_POST["pix"]) && !is_numeric($pix) )Egyébként a "mennyi" szóban két n van...
Utsó kérdésedre pedig: nyilván csak akkor engedélyezd bármilyen adatbázis-művelet elvégzését, ha nincs hiba, minden szükséges adat megvan. Ez csak feltétel-ellenőrizgetések kérdése.
"Esetleg egy "brake" oldaná meg a gondomat?"
Én még brake utasításról nem hallottam.Valószínűleg a break-re gondolsz...
De amúgy nem kell break, bár tehetsz bele, ha nagyon szeretnélha nem teljesülnek a feltételek, egyszerűen nem töltöd fel az adatbázist, és kész. Feltételeket vizsgálgatsz, ha teljesül a feltétel (pl. megvan minden adat), akkor belelép az adott "utasításcsomagba" (most jobb szó nem jutott eszembe), ha nem, akkor megy a következőre.
_____________________________
(#3472) 8nemesis8: örülök, hogy megy, bár nem nagyon értem, miért nem az előző értéket update-eled, de a lényeg, hogy működik, és Te érted.
-
Sk8erPeter
nagyúr
válasz
8nemesis8 #3470 üzenetére
Most nem nagyon értem a kavarodás okát. Ha van mondjuk egy olyan oszlop, hogy "kolcsonozheto", és azon belül igaz-hamis feltétel jelzi, hogy kölcsönözhető-e, és ez ha igen, akkor 1, ha nem, akkor 0, ebben az esetben nyilván ha visszahozták a videót, akkor ez az állapot 1-esre változik, hiszen akkor már kölcsönözhető. Ha viszont kivették, akkor 0 az állapot, mivel nem kölcsönözhető. Ennek az állapotát nyilván jóváhagyja az, aki felel azért, hogy visszahozták-e az adott videót. Ha pl. rányom, hogy visszahozták, akkor automatikusan 1-esre változik a mező, vagy ha rányom, hogy épp kivették, akkor 0-ra, stb.
________________
(#3469) cucka: köszi megint.
Látom elég komoly projectekben is részt vettél.
-
Sk8erPeter
nagyúr
Na, ezek a szempontok még nem jutottak eszembe, de teljes mértékben érthetőek, köszi.
Itt tulajdonképpen akkor csak arra kell figyelni, hogy a MySQL-kapacitást ne lépd túl. Egyébként meglévő adatbázisnál hogyan lehet megnézni, még meddig terpeszkedhetsz? Mert a tárhelyem fenntartójának honlapján semmiféle erre utaló info nincs, admin felületen meg ezt a szempontot nem találtam meg. Gondoltam hátha van valami utasítás, amivel ez az információ lekérhető.
A több százezer kép tárolása adatbázisban mennyivel foglal ilyen módon több/kevesebb helyet? -
Sk8erPeter
nagyúr
válasz
Sk8erPeter #3456 üzenetére
ÓÓÓ basszus, észre se vettem, hogy meone, beletettél egy pontosvesszőt az if mögé, én meg azt másolgattam itt... Hát akkor nyilván minden esetben echo-zni fog.
Szedd ki a pontosvesszőt, és jó lesz.
Szóval akkor ez már az, amit eredetileg írni akartam:
if ( !empty($_POST["pix"]) && is_numeric($pix) )
{
echo "Hibásan van ki töltve a 4.2-es kérdés értéke:".$pix;
} -
Sk8erPeter
nagyúr
válasz
8nemesis8 #3458 üzenetére
Nem, miért lenne butaság. De most pontosan nem tudom, mire gondolsz, ha visszahozták a videót, akkor gondolom mindenképp nyom az admin valami gombot, ami igazolja, hogy oké, visszahozva, ekkor lefuthatna többek közt a dátumkészítő függvény, és az eredményt pedig betehetnéd a MySQL-tábla megfelelő oszlopába.
-
Sk8erPeter
nagyúr
"Ezt a két részt viszont már nem tudom összekötni"
if ( isset($_POST["pix"]) && is_numeric($pix) ) ;
{
echo "Hibásan van ki töltve a 4.2-es kérdés értéke:".$pix;
}
Azt, hogy pirosan keretezze be, én legegyszerűbben CSS segítségével szoktam megoldani, hogy PHP-vel megváltoztatom a mezőre vonatkozó stílust, amit CSS-ben megadtam, hogy piros legyen. -
Sk8erPeter
nagyúr
válasz
8nemesis8 #3447 üzenetére
Persze, erre való a date() függvény.
Pl. meg lehet csinálni így:$ev = date("Y");
$honap = date("m");
$nap = date("d");
$nap_neve = date("l");
switch ($nap_neve) //nap nevének átalakítása magyarra
{
case 'Monday' : $nap_neve = 'hétfő'; break;
case 'Tuesday' : $nap_neve = 'kedd'; break;
case 'Wednesday': $nap_neve = 'szerda'; break;
case 'Thursday' : $nap_neve = 'csütörtök'; break;
case 'Friday' : $nap_neve = 'péntek'; break;
case 'Saturday' : $nap_neve = 'szombat'; break;
case 'Sunday' : $nap_neve = 'vasárnap'; break;
default: break;
}
$ora = date("H");
$perc = date("i");
//és a végeredmény:
$datum = "$ev.$honap.$nap. ($nap_neve), $ora:$perc";Ezt beteheted mondjuk egy "datumkeszito" nevű függvénybe, és akkor mindig csak ezt kell meghívogatni. Pl. térjen vissza a $datum értékével.
-
Sk8erPeter
nagyúr
válasz
8nemesis8 #3441 üzenetére
Most csak első kósza ötlet, ami eszembe jutott, persze ennél lehetnek elegánsabb megoldások is, pl. csinálsz egy külön oszlopot "allapot" névvel, és ott mindig változtatod az állapotot, attól függően, hogy épp kölcsönözhető vagy sem. Ez szerintem így nagyon egyszerű. És amikor pedig lekérdezést hajtasz végre, akkor valahogy így:
SELECT * FROM videotekatabla WHERE allapot = 'kolcsonozheto';___________
Szerk.:
(#3442) cucka: rendben, köszi az eddigi válaszokat is, tényleg utánaolvasok, mindenesetre elég sokat segítettél.
(#3443): hmm, akkor sorry. Valszeg le vagyok maradva.
"Én már megcsináltam párszor"
És milyen célból?Nekem elsőre kicsit feleslegesen bonyolultnak tűnik, persze biztos valamilyen szempont nem jutott még eszembe. Pl. az, hogy mondjuk egy fájlt nem akarsz tárolni, hanem csak a tartalmát.
"Egy file tartalma is adat." Jó, ezt valóban félreérthetően írtam, my fault.
-
Sk8erPeter
nagyúr
válasz
8nemesis8 #3437 üzenetére
Hogyan tárolsz képet az adatbázisban?
Valószínűleg azért ajánlják mindenhol a link tárolását az adatbázisban, mert csak azt lehet megcsinálni.
(ha valaki megcsinálná azt, hogy mondjuk egy jpeg képnek a szerkesztőben látható tartalmát tárolná el adatbázisban, majd úgy hívná elő, hogy abból jpeg-kép szülessen, akkor hááát igencsak ki lehetne nevetni
)
Ott adatot tárolsz, nem konkrétan fájlokat, majd ezeket előhívogatod, ahol szükséged van rá.
A dolgod csak annyi, hogy oldd meg, hogy képfeltöltéskor a kép elérési útja automatikusan pontosan úgy kerüljön be az adatbázisba, ahogy az a tárhelyeden megtalálható. Akár relatív, akár abszolút hivatkozást is betehetsz. Aztán az oldalon a neked megfelelő módon hívod elő, ha több kép elérési útja is kell, akkor mondjuk ciklussal... de eleve a MySQL utasítást is lehet úgy finomítgatni, hogy csak azoknak a képeknek az adatait tudd előhívni, amikre épp szükséged van.
Ha konkretizálnád, mit is szeretnél, úgy könnyebb lenne segítséget nyújtani. -
Sk8erPeter
nagyúr
válasz
ArchElf #3427 üzenetére
"a felhasználónak adsz pl egy Session ID-t ami alapján meg tudod mondani, hogy a már be van lépve."
De mondjuk ez biztonsági szempontból kicsit kevés ellenőrzésnek, nem? De más gépről hogyhogy működhet ugyanaz a Session ID?(#3432) cucka: a feltörésnél igazából még az nem tiszta, hogy ha tételezzük fel megvan az md5-hash-ed, akkor abból miért nem lehet visszafejteni az eredeti jelszót, ha mindig ugyanazon az algoritmuson alapszik a hash legyártása. Ez is túl hosszú ideig tartana?
-
Sk8erPeter
nagyúr
válasz
Sk8erPeter #3424 üzenetére
Ja, egyébként a "session lopás"-t hogy kell elképzelni? Hogy tudják megszerezni ilyen módon az adatokat?
Még egy: (#3420) fordfairlane:
"de nem érdemes csak emiatt elbonyolítani egy egyszerűbb rendszert."
Igazából a jelszavak md5-titkosítással történő bevitelével töltöttem kb. a legkevesebb időt. Volt legalább 2 perc, miután megnéztem valahol, hogyan kell, szóval ez tulajdonképpen nem igazán bonyolította el az amúgy igencsak egyszerűnek mondható rendszeremet.Még ami nem igazán tiszta számomra:
$nick = addslashes($_POST['user']);
$pass = md5($_POST['pass']);
$query = " SELECT DISTINCT * FROM users
WHERE (nick='".$nick."' AND jelszo='".$pass."'); ";
//stb.
Ez egy egyszerűbb módja a jelszó leellenőrzésének, amit bevittek a bejelentkező űrlap elküldésekor.
De ha itt md5-tel ismét "titkosítom" azt a karaktersorozatot, amit a felhasználó bevitt, és az eredményt összevetem az adatbázisban tárolt adatokkal, akkor ezt miért nem tudják ugyanezzel a módszerrel automatizáltan feltörni? Most ez kábé olyan, mintha nem is lenne titkosítva, mert a bevitelkor úgyis a titkosított eredményt veti össze a már korábbban titkosítottal.
Remélem érthető, mire akarok kilyukadni -
Sk8erPeter
nagyúr
válasz
8nemesis8 #3421 üzenetére
Szerencsére a CSS elég egyszerű, gyorsan elsajátítható nyelv. És ezzel együtt nagyon komplex.
"A következő lépés képek beszúrása a videotékába. Ha ehhez is van hasonlóan jó kis linked akkor szívesen fogadom."
Most itt konkrétan mire gondolsz? Képeket beszúrni többféleképpen is lehet, most az a kérdés, hogy pl. adatbázisból hogy lehet kinyerni az adatokat (ha pl. ott tárolod a képek linkjét)? Kicsit egyértelműbben írd le, mit szeretnél.Lehet, hogy akkor nem is kell külön link, itt is megkapod a választ. Meg persze az is tisztázandó, hogy milyen módon szeretnéd berakosgatni a képeket.
Én korábban úgy szerettem volna betenni a képeket, hogy mindig van egy nagy kép, alatta pedig kisképek, majd egy leírás, és utána pontosan ugyanígy a következő elemnél.
Ehhez cucka nyújtott nagy segítséget (nélküle nem jutott volna eszembe a külön tömbbe rendezés egyébként igen kézenfekvő gondolata): [link]
-
Sk8erPeter
nagyúr
Milyen gyorsabb módszerekre kell gondolni? Nem azért kérdezem, mert kódfeltörés lesz a hobbim, hanem érdekel, hogy mi ellen, hogyan szokás védekezni.
(#3414) fordfairlane: "Sok év tapasztalata odáig vezetett nálam, hogy a webes alkalmazásaimnál plaintextben tárolom a jelszavakat
"
Ez azért meglepettMost akkor kissé már össze vagyok zavarodva, akkor lényegében azt is mondhatnánk, hogy tök feleslegesek a titkosítások, mert úgyis mindent meg lehet kerülni.
És ez egyben azt is jelenti, hogy felesleges játszadozni az md5-titkosítgatásokkal meg hasonlókkal... Na de valami célja mégis van, nem?
Nem épp az, hogy legalább megnehezítsük a dolgát a támadóknak? Mindketten azt mondjátok, hogy inkább elméleti, mint gyakorlati "haszna" van a dolognak.
-
Sk8erPeter
nagyúr
válasz
fordfairlane #3407 üzenetére
Uhh, tényleg, ezt eddig észre se vettem, akkor bocsi a cikkért...
És köszi, hogy szóltál!
Ettől függetlenül a cikk többi része nem baromság, nem? Ahol a konkrét megvalósításra tér ki.Ha már itt tartunk, van esetleg valami hiteles cikk, amit tudnál a témával kapcsolatban ajánlani?
-
Sk8erPeter
nagyúr
válasz
8nemesis8 #3395 üzenetére
Egyelőre én is csak md5-tel titkosítottam a jelszavakat, mert én is ezzel kezdtem, azóta nem is változtattam meg. De most komolyan, ki a t×köm akarná pont az én oldalamat feltörni?
Egy kutyatenyésztő oldalnak csináltam admin felületet. Azért tudtommal annyira nem egyszerű az md5-öt se feltörni...
Sőt:
"Az MD5 ellenőrző számok az angol ábc betűiből (26) és számokból (10) állnak. Ez ugye 32 felvehető érték, 32 karakternél (32 karakteresek az MD5 ellenőrző számok). Tehát összesen 3632 [kb. 1,46 * 1048] lehetséges MD5 ellenőrző szám van."
Biztos pont az én oldalamnál fogják eltalálni az egyik lehetséges számot...Szvsz nem kell olyan nagyon parázni az md5-titkosításnál, csak akkor, ha már sok-sok felhasználó jelszavát tárolod. Én összesen kettőét.
Szerk.: ja, és ez volt a forrás az idézethez.
-
Sk8erPeter
nagyúr
Ott volt az utóbbi cikk, mint ajánlott link, ott épp ezt ajánlják. Az md5-öt első lehetőségnek írtam, a választás az övé. Gondolom egyébként nem szupertitkos aktákat fog először tárolni, hogy attól parázzon, hogy valaki idejét nem sajnálva feltörje az md5-tel titkosított jelszavait.
-
Sk8erPeter
nagyúr
válasz
8nemesis8 #3390 üzenetére
Kell MySQL-tábla (így a legegyszerűbb), ott pedig kezdetnek md5-titkosítással mentsd el a jelszavakat.
Itt van egy leírás az alapokhoz, ebből már el lehet indulni: [link]Ha ezzel már megvagy, akkor esetleg érdemes elolvasni ezt: Biztonságosabb jelszó tárolás.
De kezdetnek bőven elég az előző cikk. -
Sk8erPeter
nagyúr
válasz
8nemesis8 #3387 üzenetére
Szóval összefoglalva:
számít az is, hogy maga a fájl kódolása milyen, ezt pl. Notepad++-ban a Formátum menüben tudod megnézni (melyik előtt van a pötty). Ami neked kell, az az "UTF-8 kódolás BOM nélkül", ha nem erre van beállítva, akkor menj az "Átalakítás UTF-8 kódolásra BOM nélkül" menüpontra (így nem kell újraszerkesztened a fájlodat az ékezeteknél...).
Magán az oldalon legyen a headerben a <html> előtt, a MySQL csatlakozás után egy
mysql_query('SET NAMES utf8');
sor, majd a <html><head> után pedig már egy
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
sor.Tételezzük fel, hogy függvénybe írtad a MySQL-csatlakozást, csatlakozas() névvel, akkor a következőképpen nézne ki:
<?php
header('Content-Type: text/html; charset=utf-8');
//függvényeket leíró fájl meghívása
require_once('functions.php');
//MySQL-kapcsolat létrehozása
csatlakozas();
//Adatbázissal történő kommunikáció karakterkódolásának beállítása
mysql_query('SET NAMES utf8');
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="hu" lang="hu">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Language" content="hu" />
<!-- és a többi... -->
</head>
<body>
<!-- és a többi... -->
</body>
</html>Szerk.: ajánlott olvasmány lehet a következő két cikk:
Karakterkódolási problémák kiküszöbölése
MySQL 5.0: karakterkódolások -
Sk8erPeter
nagyúr
válasz
8nemesis8 #3378 üzenetére
Hát akkor egyszerűen nem kell jelszó. Próbáld meg anélkül.
Egyébként minek van külön sorban ez: $kapcsolat= mysql_connect();?
---
Én így szoktam csinálni, szerintem jól áttekinthető:$felhasznalo = "Akarki";
$jelszo = "******";
$kapcsolat = mysql_connect("localhost", $felhasznalo, $jelszo);
if (!$kapcsolat)
{
//hibaüzenet...
}
//itt pedig már jöhet az adatbázis kiválasztása:
$adatbazis = "akarmi";
mysql_select_db($adatbazis, $kapcsolat)
or die("Nem sikerült kiválasztani a \"$adatbazis\" adatbázist! <br />Hiba: ". mysql_errno() . "\n\r" .mysql_error()."<br />"); -
Sk8erPeter
nagyúr
válasz
Protezis #3365 üzenetére
De az első "átirányítás" így is-úgy is megtörténik a form elküldésekor, tök mindegy, hogy másik fájlba, vagy "önmagába".
Jobban belegondolva ha másik fájlba irányítom át, aminek kizárólag a feldolgozás a dolga, semmi más, akkor talán gyorsabb is lehet adott esetben, még ha utána vissza is irányít az eredeti oldalra, ami felelős a szövegek megjelenítéséért is. Maga a folyamat számomra gyorsnak tűnik, és legalább nem fordulhat elő olyan eset, hogy F5-nél rákérdez, hogy ismét elküldöm-e a form adatait. Itt PH-n hozzászólás elküldése után viszont ezt teszi.
Valaki írta, hogy ez a sessionös átmeneti tárolás kicsit gány, de nem igazán értem, miért is. -
Sk8erPeter
nagyúr
válasz
Sk8erPeter #3326 üzenetére
Csak megerősítő kérdés a májsztróktól: az itt leírt kétszer átirányítós, session-ös megoldás véleményetek szerint jó megoldásnak tűnik? Működni működik, de kíváncsi vagyok, hogy oldaná meg egy profi. Vagy legalább hogy mi a véleménye.
-
Sk8erPeter
nagyúr
Csak próbaként: működik az "upload/" könyvtár megadása NÉLKÜL? Próbáld ki, hogy azt kiszeded (persze a konkatenáló pont ('.') karakterrel együtt), hogy úgy feltölti-e.
Szerk.: ja, de most látom, hogy a temp file-od elérési helye:
C:\xampp\tmp\php121A.tmp
te pedig a
C:\xampp\htdocs könyvtárba szeretnél feltölteni.
Először is: lehet, hogy simán a xampp főkönyvtárba próbálja feltölteni, ott meg esetleg nincs upload könyvtár.
Ezt is próbáld meg. Mármint hogy a sima xampp könyvtárban hozol létre upload névvel könyvtárat. (Ezt még a fenti kiszedés előtt tedd meg.) Ki tudja, hátha valami hülye beállítás eredménye.
Egyébként nem igaz, hogy nem lehet szóköz a fájl nevében, simán töltöttem már fel csomószor szerverre ilyen fájlt. -
Sk8erPeter
nagyúr
válasz
cellpeti #3343 üzenetére
Leírom a hibákat, amiket első körben észrevettem:
11. sor:
if (isset($_GET['melyikodal"])) {
"melyikodal"-t írtál, kimaradt egy l betű, ráadásul döntsd el, aposztrófot ( ' ) vagy macskakörmöt ( " ) akarsz használni...Aztán a kettővel utána lévő sorban (13. sor) már egyáltalán nem használod egyiket sem a $_GET-nél...
Tehát az eredeti koncepció szerint így lenne "helyes" ez a 3 sor:if (isset($_GET['melyikoldal'])) {
echo "<b>Jelenleg a következő oldalon tartózkodik:
$_GET['melyikoldal'].</b><br><br>\n";így, hogy tele van hibával, még jó, hogy elszáll...
még hiba, amit így gyorsan átfutva észrevettem:
alkalommal tekintett meg.<BRy\n";
helyettealkalommal tekintett meg.<BR>\n";
(bár én a <br /> változatot, az xhtml-szabványost szoktam használni)
és ezt követően még ez is teljesen hibás:
echo "\n\n<br>\n\n";
echo "</body></html>";
?>
?>
</body>
</html>előbbi helyett ezt írd:
echo "\n\n<br>\n\n";
echo "</body></html>";
?> -
Sk8erPeter
nagyúr
válasz
Sk8erPeter #3335 üzenetére
"Ami hátrány lehet, hogy a könyvet még a PHP5 megjelenése előtt adták ki. (2004. februárban, a PHP5 júliusban jött ki)"
Korrigálom ezt a hsz.-emet, nem hátrány, mivel a PHP5-ről van benne szó.Itt megtalálható az egész könyv online formában!
-
Sk8erPeter
nagyúr
"gondolom azt hogy megtetszik azt letudodd abból is szűrni ha csak beleolvasol! [...] És ha akarod akkor megveszed!"
Vicces, hogy pont én tanácsoltam neked ezt az előbb, és most ugyanazt visszaírod nekem
Nekem nem nagy különút a könyvtár, úgyis mindig a környékén járok (egyetem), és elég sok könyv bent van. De egyébként most Te kértél tanácsot, nem én
Mondom, azóta már megtaláltam neten(nem volt túl nehéz)
-
Sk8erPeter
nagyúr
Abból, amit leírtál, nem volt egyértelmű, de akkor OK.
Nem értem, mi köze a könyvtárnak ahhoz, hogy gépen megvan egy anyag?Te is azt írtad, hogy nem szeretsz gépről olvasni, én is így vagyok vele. Meg a könyvet útközben is lehet olvasni (persze okostelefonokkal lehet a pdf-et is, de nem dobom ki a pénzem ilyesmikre
). PHP4 könyv nekem is megvan gépen, de kb. egyszer, ha olvastam gépről.
De egyébként köszi, végül is jöhet, ki tudja, mikor kell...
Szerk.: azóta megtaláltam neten -
Sk8erPeter
nagyúr
Itt beleolvashatsz, van pár bemutató oldal pdf-ben: [link]
Ami hátrány lehet, hogy a könyvet még a PHP5 megjelenése előtt adták ki. (2004. februárban, a PHP5 júliusban jött ki)
Ebből következően én a helyedben azt tenném (sőt, most ha már beszélünk róla, én is ezt fogom tenni), hogy kivenném könyvtárból, ha van rá lehetőséged. Egy könyvtári jegy befizetése olcsóbb, mint több könyvvel is próbálkozni.
Érdemes több könyvből is tanulni. Ha összerakod az abból szerzetteket + a php.net-en olvashatóakat, akkor szerintem már nagy meglepetések nem érhetnek.
Mostanában én is inkább azt csinálom, hogy több könyvet is kiveszek könyvtárból, így megúszom a könyv árát, ha esetleg nem túl jó, aztán ha nagyon megtetszik a könyv, akkor meg is veszem.Ja, egyébként remélem a HTML és a CSS alapjaival tisztában vagy, mert szerintem igazán csak azután érdemes webfejlesztésbe kezdeni. Ez gyorsan elsajátítható, hiszen viszonylag egyszerű nyelvekről van szó. A PHP már komolyabb dolog.
-
Sk8erPeter
nagyúr
Nem olvastam, nem tudom, de a függvények elmagyarázására ilyen alapon a PHP.net is jó...
Mondom, a PHP5 24 óra alatt az alapok elmagyarázására talán jó lehet, de felelősséget nem vállalok érte, mert a PHP4 könyvben is előfordultak hibákEttől függetlenül utóbbi is érthetően, konyhanyelven elmondja az alapokat, amikkel tisztában kell lenni.
Majd ha valaki itt a fórumon olvasta valamelyiket az újabbak közül, az remélhetőleg megírja.
De érdemes lenne simán elmenned egy boltba, és szépen megnézegetni a könyveket, átlapozni, hogy mi a tematikája, ha a PHP felsőfokon könyv is elmondja az alapokat, akkor biztos jó lehet. Úgy tudod meg leggyorsabban, ha megnézed. Nem kell feltétlenül egyből megvenni, ha könyvesboltba mész, előbb nézz bele -
Sk8erPeter
nagyúr
Hali! Itt PH-n többen ajánlották a PHP Fekete könyvet, de a Weblaboron meg jól lehúzzák, azt mondják, sok hiba van benne, helyette a "PHP fejlesztés felsőfokon" c. könyvet ajánlják. Itt van az ebben a témában indított thread, olvasd el, nem hosszú.
Én a "Tanuljuk meg a PHP4 használatát 24 óra alatt" c. könyvet olvasgattam, DE az ma már nagyon elavult, helyenként hiányos, hibás. Ugyanebből a PHP5 könyv lehet, hogy nem rossz, mert az még nem elavult, az alapok elmagyarázására (pl. egyáltalán mi az a függvény, mi az a tömb, stb.) szerintem használható. Az már más kérdés, hogy a példaprogramok mennyire hibásak, vagy nem azok, a PHP5 könyvvel kapcsolatban még nincs tapasztalatom.
De ha Weblaboron a "PHP fejlesztés felsőfokon" c. könyvet ajánlották, akkor rossz már csak nem lehet.
Mindenesetre figyelj arra, hogy ne olyan könyvet vegyél, ami régebbi verziójú PHP-példaprogramokat tartalmaz, hanem olyat, ami aktuális, mert bár a nyelv többnyire visszafelé kompatibilis, vannak olyan dolgok, amik azóta megszűntek, emellett viszont már vannak olyan lehetőségek, melyek az újabb verziókban már megvannak, a régebbiekben nincsenek.
Tehát arra is kell figyelni, hogy a szerveren, amire a cuccaidat feltöltögeted, milyen PHP-verzió van. Ezt megtudhatod a phpversion() függvénnyel.
Létrehozol egy sima PHP-kiterjesztésű fájlt, amiben elég, ha csak a következő szerepel:<?php
echo 'Jelenlegi PHP verzió: ' . phpversion();
?>Ez kiírja az aktuális telepített verziót.
-
Sk8erPeter
nagyúr
Hali!
Na, végül sikerült!Úgy döntöttem, hogy már csak az átláthatóság kedvéért is szétboncolom kicsit a kódot, és a feldolgozást átrakom másik fájlba. Tulajdonképpen maradhatott volna az eredetiben is, de már a t×köm tele volt, hogy annyi kód van egy helyen...
Amivel korábban a problémám volt, ami miatt rinyáltam, az az, hogy lényegében így kétszeri átirányítás történik így is-úgy is, amennyiben azt szeretném, hogy a böngésző ne kérdezgessen vissza, hogy el szeretném-e küldeni ismét a POST adatokat.
Mert így zajlik a feltöltés, ha az általad javasolt SESSION-ös trükkel oldom meg (ami egyébként nekem tetszik):
1.) form elküldése feldolgozásra, átirányítás a feldolgozó fájlba (ami adott esetben lehet uaz a fájl is) -> 2.) form kiértékelése, feldolgozása, hibamentesség esetén feltöltés, tetszőleges SESSION változó beállítása adott értékre, majd átirányítás (már a második) az eredeti fájlba -> 3.) eredeti fájlban a SESSION feltételágba lép (mivel az beállított értékkel rendelkezik a sikeres feltöltés miatt), kiírja a SESSION-be beállított cuccokat, majd unset-eli.Ez így most már tökéletesen működik, de mondom, eddig valahogy azon paráztam, hogy most kétszeri átirányításra van szükség, és ez esetleg lassíthat. De kb. 1-2 másodperccel tart így tovább a feltöltés, nem releváns, és egy admin felületen amúgy sincs nagy forgalom...
Egyébként minden esetben így szokták megoldani, hogy kétszeri átirányítás történik a feldolgozás miatt?Az ob_start() használata milyen esetekben ajánlott?
Lényeg: köszönöm a segítséget, most már végre működik!
Ez a session-ös beállítás bevált.
Én nem érzem úgy, hogy ez gányolás lenne, ha mégis az, akkor indokokat kérek!(#3320) fordfairlane: köszi neked is, végül maradt a session-ös megoldás.
-
Sk8erPeter
nagyúr
válasz
fordfairlane #3316 üzenetére
Hali!
Az alapproblémám az volt, hogy egy fájlban jelenítem meg az űrlapot, és dolgozom fel annak tartalmát, amennyiben elküldték a formot az adatokkal. Ha minden mező megvan, akkor feltölti az adatbázist (egyéb esetben hibaüzenet).
Ez a része működik, átlátható, de F5-ös frissítésnél a legtöbb böngésző (Opera 9.64 pl. NEM) megkérdezi, ismét el szeretnénk-e küldeni a POST adatokat. És az elég gáz, ha még egyszer feltölti az adatbázist ugyanazokkal az adatokkal. Ezért is ajánlotta lezso6 a SESSION-ös trükköt. De az gond, hogy nem unsettelem sehol ezt a SESSION-be eltárolt értéket, pedig azt kéne, csak nem tudom, hol.
Elküldi a júzer a formot, ellenőrzöm, megvan-e minden érték, ha igen, feltöltöm a képfájlt, amit a júzer hozzácsatolt, megmutatom az ebből készített thumbnailt, stb., MAJD feltöltöm a megfelelő értékekkel az adatbázist, aztán beállítom a SESSION változót.
A POST adatok ellenőrzésénél pedig beraktam, hogy akkor töltse fel, ha az ominózus SESSION változó nincs beállítva, de ugye ha előtte nem unsetteltem, akkor az isset mindig 1-et ad eredményül... Valahova be kéne állítani az unsetet. -
Sk8erPeter
nagyúr
Oké, egyetértünk, de van pl. az MVC-ről valahol jó leírás (NEM Wikipédiás)? Hogy az egészet hogyan is kell elképzelni a gyakorlatban. Nyilván ez nem feltétlenül azt jelenti, hogy használj Joomla-t vagy ehhez hasonlót, hanem gondolom át lehet ültetni saját modellbe/keretrendszerbe. Ha Joomla-t vagy ilyesmit használnék, akkor kb. azt is mondhatnám, hogy mi a francnak dolgoztam annyit, "készen" is kaphattam volna
(de szerettem volna belelátni a működésébe, nem egy "előre legyártott" valamit használni)
-
Sk8erPeter
nagyúr
Az a helyzet, hogy valóban nem látom még át teljesen jól a korrekt megoldást, és az is való igaz, ahogy cucka is mondta, hogy esetleg ez egy gányolt fos kód így. Főleg annak lehet esetleg rossz látni egy ilyen kódot, akinek már azért bőven van tapasztalata hasonlók megírásában, de az nem én vagyok.
Igazából ez az első komolynak nevezhető munkám PHP-ben - sőt, továbbmegyek: az első normális honlapom -, és nemrég kezdtem el tanulni az egész PHP-nyelvet, ezért bőven előfordulhatnak hibák, és hülye kérdések is, ezekért elnézést kérek, de az viszont nagyon jól jön, hogy mindig megpróbáltok segíteni.Nélkületek lassabban haladnék egyes problémákkal.
Úgy próbáltam bizonyos feladatokat megoldani, hogy php.netről vagy gugliról keresett cikkekből, esetleg abból a szar PHP4 könyvből megpróbáltam ellesni trükköket, módszereket, és azt átültetni a saját oldalamra, több-kevesebb sikerrel.Nyilván már egy komplexebb űrlapfeldolgozási feladatnál már azért nem elég beérni a gány technikával, de próbálom egyelőre a jelenlegi tudásomból kihozni a legtöbbet. Az admin felületet már átadtam, természetesen folyamatosan módosítgatom, javítgatom, toldozom-foldozom a kódot. Mivel haverom apjának készítem a honlapot, nem nyakaznak le, ha nem tökéletes a kód, mivel fingjuk nincs az egészhez - mint általában az emberek többségének
-, és ők már ettől is el vannak ájulva
Rengeteg dolgot kellett rendkívül rövid idő alatt, iszonyú kevés szabadidő mellett, megfeszített tempóban csinálni, ezért sok dolognak egyszerűen nem volt időm utánajárni, meg kellett csinálni, működjön.
Működik, de ezt majd lehet továbbfejleszteni, hogy úgy működjön, hogy attól egy jó programozó sem sírja el magátCsak gondoltam elmondom, miért is teszek fel olykor amatőr kérdéseket PHP-vel kapcsolatban, hogy ne verjétek a fejeteket a falba ezek láttán...
Ha azt mondjátok, érdemes megvenni a PHP fekete könyvet, megteszem, mert valószínűleg jóval összeszedettebb írás van benne, mint a netről összeszedegetett információmorzsák és a PHP4 könyv egyvelege...
(persze php.net fasza, de azért nem minden célra)
_____________________________________________________Szóval a problémát az okozta, hogy csekkoltam, hogy a felhasználó lenyomott-e gombot, és ha igen, akkor egyből elvégeztem mindenféle műveletet, feltölteni kívánt fájl ellenőrzése, ha minden rendben, akkor feltöltése, majd egyből vízjelezése, az eredmény azonnali megmutatása, thumbnailek készítése, ezek megmutatása, stb...
Tehát magyarán minden egy fájlban van, az űrlap megjelenítése és feldolgozása is. Ez gond lehet.
Lehet, hogy csak fel kéne töltenem, a háttérben elvégezni a vízjelezést, thumbnailek készítését, ezek eredményét pedig valahogyan eltárolni, aztán a későbbiekben megmutatni, de már fingom nincs, milyen sorrendben, hogyan kéne...(minél jobban belemerülök, annál jobban elveszek a részletekben)
Ha ezt az MVC-módszert alkalmaznám, valószínűleg nem lenne probléma, de egyelőre csak a körvonalait látom, hogy mi a lényege, rendes leírás (nem Wikipédia) sokat segítene...
Egyébként mindig az van, hogy elkészítem, örülök, hogy faszán működik, ahogy kéne, aztán rájövök, hogy mégis mennyire hiányos/kifogásolható a kód...
Gondolom a kezdeti tapasztalatgyűjtéseknél sűrűn van ez, nem csak velem van a hiba...
-
Sk8erPeter
nagyúr
Ezek szerint az előző hsz. kicsit túl hosszúra sikeredett, sorry...
Igazából annyi lenne a lényeg, hogy hogyan tudom megoldani ezt a SESSION-ös trükköt úgy, hogy nem a headerbe, még a <html> cuccok megjelenése előtt szeretném kiíratni a sikeres feltöltésre utaló üzeneteket, hanem úgy, hogy rendesen megjelenjen az oldalon, menükkel, mindennel együtt.
Aztán frissítéskor viszont ne akarjon minden POST üzenetet újra elküldeni.Amielőtt még a lényeget feltölteném adatbázisba, elvégzek olyan műveleteket, mint a kép vízjelezése, felbontás kiíratása, thumbnailek készítése, és egyben megmutatása (tehát hogy megjelenik a kép több elkészített verziója is a felhasználó számára az oldalon), valamint egyéb megadott adatok kiíratása, majd ezt követően történik csak meg az adatbázisba való feltöltés.
Érdekes lenne, ha még azelőtt átirányítanám a júzert, mielőtt ezekből a feliratokból, képekből bármit is látna.
Akkor hogyan kéne megoldani szépen? -
Sk8erPeter
nagyúr
Hmm, akkor az a gáz, hogy ebben az esetben valamit nagyon át kéne írni az egész űrlapkezelésben.
Ez egyébként egy admin felület. Most egyelőre az a struktúrája a dolognak, hogy még a <html> kiírása előtt lecsekkolja, hogy az illető be van-e jelentkezve, ha igen, akkor megyünk tovább, ha nem akkor kirakja a bejelentkező formot, semmit nem is ír ki.
Elindít egy sessiont a session_start() fv.-nyel, stb...
Utána már kezdődik az oldal tényleges megjelenítése, és a középső részbe íratom ki a dolgokat, tehát már nem a headerben vagyunk, itt már nem adhatok ki header-re vonatkozó módosítgatásokat. Mindenképp ide kell jönnie a szövegnek, hogy sikeres blabla...
Itt következik a php-részben egy feltétel-ellenőrzés:1.) ha a $_POST üzenetek el vannak küldve, és minden adat megvan a megkövetelt elemek közül (kitöltötték, stb.), akkor megkísérlem feltölteni a fájlt, a megadott adatokat az adatbázisba, ha valamiért nem sikerül (pl. túl nagy a fájl), hibaüzeneteket íratok ki.
2.) ha a $_GET értékekbe elküldték már korábban (még egy form segítségével, aminél GET action van), hogy pontosan melyik elemhez is szeretnénk képet feltölteni, akkor azt megjelenítjük az adatbázisból, csak hogy látható legyen (megjelenítjük a már feltöltött adatokat, már fent lévő képet, stb.), itt jelenítjük meg azt a formot is, amivel konkrétan ki tudjuk választani a fájlt, amit feltöltünk!
3.) egyébként pedig megjelenítek egy formot (rádiógombokkal), amelyik tartalmazza a megfelelő szempontok szerinti ÖSSZES már meglévő elemet (csak egy kiskép és egy név van fent, ami utal rá, ez így a felhasználó számára egyértelmű), azok közül kiválaszthatjuk, melyikhez szeretnénk képet (és esetleg adatot) feltölteni.
Ez a struktúra így jól is van rendjén, jól is működik, a követelményeknek megfelelő, csak azt nem tudom, hogyan kellene úgy beilleszteni akkor ezt a SESSION-ös ellenőrzést úgy, hogy frissítés UTÁN ki tudjam íratni az adatokat, meg a sikerre utaló üzenetet, a headerben ez a rész NEM szerepelhet, mivel szükséges, hogy megjelenjen a fenti menü, stb...
MOST úgy csináltam meg azt, amiről beszéltünk, hogy az 1. részben miután konkrétan feltöltöttem az adatbázisba az adatokat, beteszem a $_SESSION['siker'] = true; értéket.
Aztán, ha mégis frissít a júzer, akkor van az a feltétel-ellenőrzés, hogy ez az érték true, akkor átirányít.Igazából már nem vágom, hogyan kellene akkor mégis szépen megoldani, hogy unset is legyen, átirányítás is legyen, és ne akarjon semmiféle POST adatot újból küldeni.
A jelenlegi működik, de így valóban kicsit gagyibb.
-
Sk8erPeter
nagyúr
válasz
Sk8erPeter #3290 üzenetére
bocs, lejárt a mod.
Ja, de végül is akkor nem is használtam az unset() függvényt, de ebben az esetben, ha átirányítás történik, akkor kell egyáltalán?
Az oldal tetején ott van a start_session(). A próba alapján nem muszáj, vagy csak épp szerencsém volt, vagy hogy is van ez? -
Sk8erPeter
nagyúr
Tökéletes!!
(nem is tudom, ez ebben a formában miért nem jutott eszembe már korábban
)
Az adatbázis feltöltése után betettem a $_SESSION['siker'] = true; sort, majd a fejlécbe, még a <html> cuccok elé betettem a header-re vonatkozó sort:if (true === $_SESSION['siker'])
header('Location: ', $_SERVER["PHP_SELF"]);és kipróbáltam, ha feltöltök, kiírja a szokásos sikeres feltöltés blabla szöveget, majd megnyomom a frissítést, a böngésző felteszi a szokásos kérdést, hogy még egyszer elküldöm-e a $_POST adatokat, és az OK-ra kattintva a kezdőoldal jön be.
Ja, és oda, ahol annak ellenőrzése zajlik, hogy megvan-e minden $_POST cucc, ami kell, betettem még azt a feltétel-ellenőrzést, hogyif ( //blabla...........
&& !isset($_SESSION['siker'])
)Nagyon köszönöm lezso6, sokat segítettél!
-
Sk8erPeter
nagyúr
Igaz, nem kell az egész sessiont destroy-olni, én is arra gondoltam egyébként, hogy $_SESSION['post'] vagy ehhez hasonló nevű változóba adom meg az értékeket. Ez így jó megoldás lenne?
Van egy űrlapom, ott elküldöm az értékeket, ugyanazon az oldalon fel is dolgozom őket, aztán szeretném, ha többé nem lehetne ugyanezeket az értékeket elküldeni frissítésnél.
No de akkor az konkrétan hogyan is néz ki?
$_SESSION['post'] = $_POST;
és aztán végül is mit csekkolok?(az oké, hogy aztán sikeres lefutásnál gondolom unset($_SESSION['post'])
Vagy mégis inkább pakoljam át külön php-fájlba a feldolgozást, és a form action-nél állítsam be annak az elérési útját? Igazából azért gondoltam arra, hogy ugyanazon az oldalon dolgozom fel az adatokat, hogy ha hiba van, tehát nem adtak meg minden szükséges értéket, akkor egyszerűen írja ki a form fölé a hibákat, aztán jelenítse meg ugyanúgy, a már megadott értékekkel (! hogy ne kelljen újra begépelni), ne kelljen mindig "vissza" linkekre kattogni hibánál.
Na de ha átirányítom az oldalt feldolgozás érdekében, akkor az eredeti oldalon hogy fog megjelenni a szükséges kimenet, ha a feldolgozás után ismét visszairányítás történik? -
Sk8erPeter
nagyúr
áá, bocs, nem vágom, hogy sikerült pont a lényeget lehagynom róla...
Arra gondoltam, hogy nem sima változónak, hanem egy SESSION-nek adod át a POST értékeit, aztán amikor megtörtént az adatbázis feltöltése, akkor meghívod a session_destroy() függvényt.
Ez így nem jó? Vagy hogyan kéne? (Huhh, mostanra már úgy összezavartam saját magamat, hogy azt se tudom, mit is akarok kihozni ebből.)
-
Sk8erPeter
nagyúr
válasz
Sk8erPeter #3266 üzenetére
Egyébként igazából ez a böngészőfrissítős dolog azért volt érdekes, mert akkor igazán szép megoldást nehéz találni arra, hogy űrlapokat egy fájlban írassunk dolgozzunk fel, hogy a felhasználó ne küldhesse el minden egyes frissítésnél a korábban megadott adatokat. (nem is lenne biztonságos, így könnyen ki lehetne akasztani az oldalt
)
Mivel ebben az esetben a $_POST változók értékeit át kell adni egy másik változónak, és akkor azt vizsgálni:$akarmi = $_POST['valami'];
if ( !empty($akarmi) )
{ //pl. adatbázisba való feltöltés (persze kritériumok teljesülése esetén)
}
else
{ //űrlap kiíratása
}Azt viszont ebben az esetben NEM lehet csinálni, hogy:
if ( isset($_POST['valami']) ) //vagy akár !empty($_POST['valami']) is lehetne
{ //pl. adatbázisba való feltöltés (persze kritériumok teljesülése esetén)
}
else
{ //űrlap kiíratása
}Mivel akkor a $_POST-nak nyilván minden egyes böngészőfrissítésnél mindig van értéke, se nem üres (empty), se nem beállítatlan (unset).
Vagy tudtok valami elegáns megoldást az _első_ példa helyett?
-
Sk8erPeter
nagyúr
Hali!
Azt el lehet érni valahogy, hogy a böngészők frissítésekor a korábban már elküldött $_POST adatok ne legyenek elküldhetők még egyszer? Erre a dologra egyes böngészők (pl. Chrome, FF) fel is hívják a figyelmet, ha $_POST adatokat tárol, rákérdez, biztos el akarjuk-e küldeni megint az adatokat.
Szóval lehet úgymond törölni a böngésző "agyából" a korábban elküldött értékeket?
Vagy ez csak böngészőfüggő, annak a memóriájához ilyen módon a PHP program nem tud hozzányúlni? -
Sk8erPeter
nagyúr
Hali!
Csak egy rövid kérdés:
a függvénydefinícióban hogyan tudok megadni "nem kötelező" paramétert?
Ugyanúgy, ahogy a round() vagy az imagefilter() vagy ezernyi más függvénynél azok közül, melyek a PHP alapfüggvényeinek számítanak.
Megadhatok saját függvényt is hasonlóan nem kötelező paraméterekkel?Tehát egy függvényt pl. meg lehet hívni úgy is, hogy
valami(1,2);
és úgy is, hogy valami(1,2,3,4); (Amennyiben van több, mint pl. 2 paraméter, akkor használjuk fel azokat is, de egyébként nem muszáj.) -
Sk8erPeter
nagyúr
válasz
maLakai #3212 üzenetére
Hmm, hát nem tudom, hogy gyakoribb-e, de adott esetben felesleges. Én most végül megoldottam a vendégkönyvet úgy, hogy ugyanazon az oldalon dolgozom fel az adatokat, nem adok meg az actionnek címet, így volt a legegyszerűbb, és PazsitZ által mutatott módon random számokat generálok, és sessiontömbben tárolom a randomösszeget, így frissítésnél már más lesz az összeadandó eredmény, tehát nem küldi el még egyszer ugyanazt a hsz.-t, ha frissítgetek F5-tel. Működik, és kényelmes megoldás.
-
Sk8erPeter
nagyúr
válasz
Sk8erPeter #3205 üzenetére
Hoppá, lejárt a limit, kissé gyorsan írtam, véletlenül szóközt raktam az alsóvonás helyett, sorry, nem tudom, hogy sikerült, tehát a formnál a helyes action:
action=\"'.$_SERVER['PHP_SELF'].'\"
-
Sk8erPeter
nagyúr
Azt a formot, amit korábban kiírattál, eltárolod akár egy változóba is, vagy csak simán kiíratod (vagy akár függvényt is írhatsz az űrlap elkészítésére, és akkor még a korábban megadott adatokat újból beteheted a formba), és a form-nál a PHP_SELF-fel babrálsz, pl.:
//első legyen a program eredményeinek kiíratása előtt (!) az alábbi (csak példaként szolgáló) form-megjelenítés:
$form = '<form enctype=\"multipart/form-data\" action=\"'.$ SERVER['PHP SELF'].'\" method=\"POST\"><input name=\"valami\" type=\"text\" /><input type=\"submit\" value=\"Mehet\" /></form>';
if ( empty($_POST['valami']) )
{
echo $form;
}
else
{
echo $form;
//aztán ide jöhetnek a kiszámolt eredmények...
}Persze ez csak egy gyors, leegyszerűsített verzió, többféle megoldás is van, ez csak az egyik. Nem tudom, ezzel jutottál-e előrébb, ha nem, akkor konkretizáld a kérdést. Ha igen, akkor öröm és bódottá'.
-
Sk8erPeter
nagyúr
Hali!
<?php
echo '10 random generált szám -100 és +100 között: <br />';
$min=-100;
$max=100;
$szum = 0; //segédváltozó az összeghez
for($i=1; $i<=10; $i++)
{
$rand = rand($min,$max);
$szum+=$rand;
echo "$i: $rand <br />";
}
echo "<br />";
echo "A 10 random generált szám összege: $szum";
?>A random függvényt a for cikluson belülre tedd, úgy jó. Én i-t 1-től indítottam, és minden cikluslépésben ki is írtam az aktuális számot, és a random generált számot a $szum változóhoz minden lépésben hozzáadogattam. Az értékadás egyébként így is jó lett volna: $szum = $szum+$rand; de így szebb ($szum += $rand).
A legvégén, a ciklus végeztével pedig kiírattam az összeget (a $szum változót).
-
Sk8erPeter
nagyúr
válasz
PazsitZ #3088 üzenetére
Itt az if ($op != "ds") feltétel-ellenőrzéssel csak azt ellenőrizzük le, hogy egyáltalán el lett-e a küldve a form, és ha igen, akkor mehet tovább az ellenőrzés?
"wrap=virtual" ez micsoda?
Egy fontos kérdés: ha nem állítok be ilyen számellenőrzős cuccot, viszont van egy form, amit kitöltve elküldök, majd frissítem a böngészőt, akkor hogyan kerülhetem el, hogy még egyszer ugyanazokat az adatokat elküldje? (Pl. vendégkönyv esetén [tudom, hogy egyébként is érdemes itt valami captcha-t vagy hasonló számellenőrzős cuccot berakni].)
Múltkor csodálkoztam rá, hogy még egyszer ugyanazt az adatot elküldi, és bővíti az adatbázist, ha F5-tel frissítek. Az meg ugye nem jó.
A $PHP_SELF-fel küldöm "önmagának" az adatokat, szóval ugyanazon az oldalon dolgozom fel...
Ez lehet, hogy kicsit amatőr kérdés, de egyelőre akkor sem tiszta számomra.Köszi!
-
Sk8erPeter
nagyúr
Istencsászár vagy!
Pontosan így képzeltem el!
Valahogy nem akart eszembe jutni az a megoldás, amit Te csináltál, hogy simán lehet külön ciklusba rakni a tömb feltöltését a $row adattáblasorok adataival.
És az ezt követő ciklus dolga a konkrét megjelenítés, ez így tökéletes. Ráadásul a név szerinti rendezés és a többdimenziós tömb is nagyon elegáns megoldás.
Köszönöm szépen, hálám üldözni fog!---
Kérdés:
1. Egyébként azt gondoltam, hogy a tömbfeltöltéshez ($tomb[] = $row) is szükség van egy segédváltozóra a while cikluson belül (pl. így: $tomb[i], és az i-t növelgetjük a while cikluson belül), de ezek szerint a tömb értékadásakor mindig a legutolsó tömbelem UTÁN (és a lezáró /0 elé) rakja az adott elemet? (tehát számomra az volt az újdonság, hogy nem írja felül a 0. elemet)2. És mi a teendő abban az esetben, ha adott esetben túllépi a memóriaküszöböt? Valamint milyen esetben fordulhat ez elő?
-
Sk8erPeter
nagyúr
válasz
Sk8erPeter #3189 üzenetére
Az a rész már megvan, hogy egy tömbbe le tudtam kérni a kutyák neveit, és megtisztítani a duplikátumoktól, ez nem volt túl nehéz.
Ha egy külön while-ciklusba betenném, hogy pl. amíg ez a tömb első eleme megegyezik a "név" adatmezőben található névvel, amelyik adatsornál a táblából épp jár a "while ($result = mysql_fetch_assoc($query))", addig mutogassa az 50px-es képeket, az nem lenne jó?
Egyelőre érdekelne, hogy valami ilyesmi gondolatmenet nem lenne-e célravezető. -
Sk8erPeter
nagyúr
válasz
ArchElf #3188 üzenetére
Hű, ezt nem lehet valahogy egyszerűbben megoldani?
A tag táblánál miért van szükség "típus" mezőre? Csakis kutyák neveinek az eltárolásáról lenne szó, ami a kép többi adatával együtt bekerül egy táblába (ahogy nálad a "kép tábla" esetén látható).
Valami olyasmi megoldással nem lehetne a rendelkezésre álló adattáblákból és feltöltött képekből kinyerni és rendezni az adatokat, hogy mondjuk egy tömbbe gyűjtöm pl. a "kép tábla" - "név" mezőinek összes adatát, az újból előfordulókat kiszűröm, és mondjuk amíg a név mező első eleme (pl. a "Vauvau" nevű kutya) tartozik az adott sorhoz, addig gyűjtse ki belőle az 50px-es képek elérési útját?
Ez nem megoldható?Most nagyon nagyvonalakban, csak a lényeget kiemelve ilyen módon jelenítem meg a képeket, de ezzel az a baj, hogy csak egymás mellé rendezgeti div-ekbe az adattábla sorainak megfelelően, még akkor is, ha egy kutyanév többször is előfordul (csak adott sorhoz más kép tartozik):
<?php
$menupont = "kolykok";
$parancs = "SELECT * FROM kepek WHERE menupont = '$menupont'";
$query = mysql_query ($parancs)
or die ("Nem lehet lekérni az adatot a MySQL-táblából.<br />Hiba: ". mysql_errno() . "\n\r". mysql_error() ."<br />");
echo "
<!-- Nagy div eleje -->
<div class=\"images\">";
while ($result = mysql_fetch_assoc($query))
{
print "
<!-- Kutya adatainak eleje -->\t
<div class=\"doggie\">\n
<ul class=\"kutya_lista\">
<li><a href=\"".$result['kep']."\" title=\"$cim\">
<img src=\"".$result['kep_200']."\" width=\"". round($result['kep_felbontas_0']/$result['kep_felbontas_1']*200) ."\" height=\"200\" alt=\"dogs\" />
</a></li>
<li>
<img src=\"".$result['kep_50']."\" width=\"". round($result['kep_felbontas_0']/$result['kep_felbontas_1']*50) ."\" height=\"50\" alt=\"dogs\" />
</li>
<li>Név: ".$result['nev']."</li>
<li>Apa: ".$result['apa']."</li>
<li>stb....... (itt még include-olok egy, az adott kutyához tartozó törzskönyvet is!)</li>
</ul>
</div>
<!-- Kutya adatainak vége -->\n\r";
}
echo "
<div style=\"clear: both;\"></div>
</div>
<!-- Nagy div vége -->";
?>A lényeg: azt szeretném, hogy az adattáblában szereplő azonos nevű kutyák képei egymás mellett legyenek, és ugyanígy rendezve legyen a többi kutya neve is, a hozzátartozó képekkel.
Ilyesmi módon:
A nagy piros keret a 200px-es nagykép, az alatta lévők az 50px-es kisképek, melyekre rá lehetne kattogni, alatta pedig az adatok; végül mellette a következő nevű kutya.Azért másoltam be a kódot is, hogy hátha így jobban látható, mit szeretnék, és hátha van rá egyszerű módszer is.
Tehát az a tömböt nevekkel feltöltős módszer (amíg a "nev" mezőben a tömb első eleme szerepel, addig jelenítse meg az 50px-es képet) vagy valami hasonló nem működik?Előre is köszi!
Megj.: persze hibák a kódban még előfordulhatnak, szóljatok, ha láttok ilyet...
Egyébként a kommenteket sok helyen azért raktam oda, hogy átlássam (meg Ti is) a dolgot, majd a végsőből kiszedem. -
Sk8erPeter
nagyúr
Hali!
Most az istenért sem akar beugrani a megoldás, PHP+MySQL kérdés:
egy adattáblában sok-sok oszlop van, a legfontosabbak az azonosítószám (automatikusan inkrementálódik), a név, valamint a nevekhez tartozó képek elérési útja, az egyik a 200px magasaké, a másik meg az 50px magasaké.
Amikor a júzer feltölt egy képet adott névvel, akkor egy függvény automatikusan készít 200 és 50px magas thumbnaileket, ezek elérési útját eltárolja az adattáblában.Egy oldalon pedig úgy szeretném megjeleníteni a képeket, hogy először jelenjen meg az adott nevű képből egy 200px magas, majd alatta azok az 50px-es kisképek, amik még ugyanehhez a névhez tartoznak, vagyis amíg ezeknek a képeknek a "név" oszlopában ugyanaz az érték szerepel. (A kisképekre meg már Javascripttel intézném el, hogy jelenjenek meg a 200px magas résznél rákattintás esetén.)
Hogy kézzelfoghatóbbá tegyem a dolgot: van egy oldal, ahol a júzer feltöltheti kutyák képeit, a neveket meg feltöltéskor ő gépeli be (tehát mindig lehetnek újak, nem előre eltárolt nevű kutyákból kell megjeleníteni a képeket, mert akkor egyszerű lenne a problémát megoldani, pl. while ($kutyanev='Vauvau') {...} ciklussal), egy oldalon meg szeretném megjeleníteni ezeket a képeket úgy, hogy van egy nagy kép a "Vauvau" nevű kutyáról, alatta meg ugyanerről a "Vauvau" nevű kutyáról jelenjenek meg az 50px-es thumbnailek.
Emellett megint ugyanebben a felépítésben pedig pl. a "Vuffvuff" nevű kutya képei jelennének meg, először a 200px, majd 50px-esek. És így tovább, amíg a név adatmező összes értékét ki nem merítettük.Maga az adattáblából való adatlekérés természetesen megy, a képeket meg tudom jeleníteni, de egyelőre csak úgy megy, hogy külön-külön jelennek meg, ugyanaz a kép először 200, majd alatta 50px méretben.
Remélem érthető volt a leírás, hogy mit is szeretnék, ha nem, akkor szóljatok, és megpróbálom érthetőbben...
Köszi!---------------------------------------------------------------------------------------------------------------------
Kicsit OFF (sima HTML-kérdés), de a másik topicban nem válaszoltak, Ti meg itt nagyon vágjátok a dolgokat, esetleg erre a kérdésre rá tudnátok nézni? Hátha van valami ötletetek --> [link]Köszi!
Új hozzászólás Aktív témák
Hirdetés
- Samsung Galaxy S23 Ultra 256GB fekete, szép állapotban
- Dell Precision 7560 15.6" FHD IPS i5-11500H RTX A3000 32GB 512GB NVMe gar
- SAMSUNG 1TB 990 PRO M.2 NVME PCI-E 4.0 x4 - Új - 7450-6900 MBs - Eladó!
- Thinkpad T14 Gen4 14" FHD+ IPS i5-1345U 16GB 256GB NVMe magyar vbill gar
- L14 Gen1 27% 14" FHD IPS Ryzen 5 4500U 16GB 256GB NVMe ujjolv új akku gar
- Beszámítás! Apple Mac Studio M2 MAX 2023 32GB 512GB SSD számítógép garanciával, hibátlan működéssel
- ÁRGARANCIA!Épített KomPhone i7 14700KF 32/64GB RAM RTX 5070Ti 16GB GAMER PC termékbeszámítással
- Eredeti, új Lenovo 330W töltők - ADL330SDC3A
- Creative Sound BlasterX G5 (70SB170000000) (Sound Blaster) (DAC)
- 24" Eizo FlexScan EV2146W, 1920X1200 szép, hibátlan nélkül
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest