Html-, css- és php-help

Elvileg nincs, az egyik csak egy alias a másikra. Ugyan az a kettõ. De ezeknek érdemes utánajárni, mert pl. a print és az echo között szignifikáns különbségek vannak. Sok fv csak kompatibilitásból eredõen szerepel/maradt elérhetõ, míg más fv-ek látszólag azonos mûködése eltérõ teljesítménnyel jár.

nem fontos, amit írtál az tökéletes, max akkor lenne baj ha tiltva lenne a cookie, kösz.

Elsõt thnx! -1 változó 😄
Ám exit és die között van lényegbeli különbség ? (php.net nem ír semmit)

+ elküldés ellenõrzésére az isset() fv-t használjuk. Ha nagyon precíz akarsz lenni, akkor a value értékét is lehet ellenõrizni.

Nekem is lenne egy kérdésem. 😊

Lehet úgy emailt küldeni, hogy a html levélben szereplõ képek ne függjenek egy külsõ tárhelytõl, hanem csatolmány formájában legyenek jelen? A levélhez tartozó képek csatolmányait pedig jó lenne elrejteni, tehát mint komponens legyen jelen, ne pedig hagyományos, letölthetõ, megjelenített csatolmány.

Válaszokat köszi elõre is!

Mûvelet végére:

header('Location: '.$_SERVER<'REQUEST_URI'>.'');
die();

vagy körülményektõl függõen $_SERVER<'PHP_SELF'>, aminek a végére odacsaphatod az URI paramétereket ha akarod.

A változásokat csak fogod tán látni, de ha biztosra akarsz menni, akkor munkamenetbe rakod a figyelmeztetések üzenetét a következõ módon:

$_SESSION<'sessErrorMsg'> = 'üzenet';

megjeleníteni pedig:

echo $_SESSION<'sessErrorMsg'>;
unset($_SESSION<'sessErrorMsg'>); // töröljük az üzenetet a megjelenítés után.

Írtam hogy Header locot nem akarok oda írni, mert akkor nem fogom tudni, végre hajtódót e a mûvelet vagy nem!

Szokás szerint nem értem mit akarsz írni, de nyomsz egy F5-öt akkor újra megnyitod a folyamatot. Ha el akarod kerülni a duplapostolást, akkor csináld azt, hogy mikor elküldöd akkor header-rel ellököd õt valahova, nem elegáns, illetve ha visszát nyomogat érthetik meglepetések, de megy.

Na ismét itt 😊
Remélem tudtok segíteni ebben a kis problémában 😊
Na szóval, van pár formos php sorom, és mindegyik ugyan olyan, a saját php fájlára mutat, és egy if ($_POST<'submit'>) al van ellátva, amikor elküldöm az üzenetet, és jó vagy nem, és végez a mûveletet, ott van egy meta ami visszatölti az eredeti php, ide raktam be 1 die parancsot, de nem müxik, legalább is ahogy én gondolom, ha F5 nyomok újra elakarja küldeni a POSTot, nem értem miért akarja hisz lezártam a folyamatot, mit írjak hogy az újra küldés ne legyen?

Tudok egy módot, Header location de ha azt íróm, akkor nem fogom látni hogy végbe ment e a mûvelet vagy nem.

Nagyon súlyos a srác😊 Nem tudom mi van mostanában, ez valami agresszív-istenkomplexus járvány lehet😊

😄

Jah.. a "Seggarc" normális reakció volt, egy alapvetõen mûködõ válaszra, ami kielégítetta a feltett kérdést.
Az, hogy nem voltál képes megfogalmazni a konkrét kérdést, miszerint az idõzónát szeretnéd változtatni illetve, hogy nem voltál képes megnézni a php.net doksiban a date/time függvények leírását, az valóban azt jelenti, hogy seggarcok vagyunk, és tûrnünk kell a kritikát. Vegyél vissza kicsit öregharcos.

Azért vannak kiakadva, mert teljesen jó (sokszor kényelmes) megoldást írtak számodra, te peddig válaszban leseggarcoztad azt, aki segíteni akart. Lehet választani, hogy melyik megoldásra van szükséged, melyik a legszimpatikusabb, de õ is segítséget nyújtott számodra, még akkor is, ha találtál rá jobb alternatívát. Válaszban meg nem éppen tûntél hálásnak, sõt.

Nem értem mi a probléma. Tök normálisat kérdeztem... A timzeone tökéletes válasz volt.. Most nem értme mit kell ezen felháborodni. Ez az srttostring függvény meg alapból nem tetszik. Bocs hogy ekkora gyökér vagyok de ha nem bírjátok ti se a kritikát akkor haljatok éhen.. Szerintem tök normálisan reagáltam....

Ahozz képest hogy pl te is egyeseket figyelmen kivül hagysz meg ahogy bánsz másokkal a fórumon én nem jártatnám a szám.
De persze nem errõl van szó.

Annak aki a timezone-t írta küöszönöm a segítséget a többieknek meg további kellemes napot. Remélem hozzájuk nem lesz szereéncsém többet és remélem többet nem kell itt a fórumban segítséget kérnem..
Kössz mindent.

Jól szuperál, az is csak 1 módszer az egész weboldal is futhatna egy hagyományos php fájlból csak azért szedjük szét mert úgy egyszerûbb.

Mindenképp jobbnak tartom mint a headert, de inkább javaslom az adott ellenõrzést elõbb tenni mikor még nincs kimenet.

gondoltunk mi is az MVC-re, de ahogy mondtad, eléggé késõn, és nem lett volna értelme újrakezdeni. majd kiderül hogy szuperál 😊

tehát azt mondod, hogy gyorsabb és jobb megoldás ilyen esetekben a document.location? hm. lehetséges.
a die-t meg kipróbálom majd!
köszönöm szépen a tanácsokat!!

De vigyázz mert a multi ie és társai nem megbízhatóak, nekem van egy olyan flash es oldalam a menü flash, hogy opacityvel animálva rakom be a flasht, és natív ie6 al jól megy és az összes emulált carban nem.

Minden script amely headert dob mindig le kell fusson a doctype elõtt, és header után mindig használj die() dögölj meg függvényt, hogy tovább ne menjen, mert néha képes header ellenére tovább menni böngészõtõl függõen.

MVC elv szerint érdemes dolgozni el kell és érdemes választani a megjelenítést a mûködéstõl, tehát a mûködés mindig a megjelenítés elõtt van, ez így egy kész projektnél már késõ kicsit neki látni, de majd a következõnél erre is kell gondolni. Mindig minden ellenõrzés legyen a doctype elõtt, ha meg semmiképp sem tudod oda tenni, akkor mikor rájöttél hogy baj van át kell irányítani, akkor ha head részen van az oldal akkor használhatsz meta vagy script tagot és rögtön utána zárod a headert nyítsz bodyt és zársz és zársz html-t és die. ha body részen vagy már akkor meg script átírányítás document.locationnal body és html zárása és die. Szerintem ez így korrekt, de mindenképp ha csak 1 lehetõség van a header-es átírányítások mindig kimenet elõtt végezzék el a munkájukat, és ne használj ob get és ob flasht annak is van szerepe, de nem erre való, sokat ront a weboldal megjelenítési idején, növeli a szerver memóriaigényét, stb. Persze ezt mondják a google a youtube és társai, akiknél az ezredmásodpercel több az 10 új szervert jelent, itt nekünk 20 msec semmit nem számít, de akkor sem érdemes használni, mert elbonyolítja a kódot, átláthatatlanságot eredményez, pont ez által hogy bárhol lehet még egy header rész.

Pl érdemes használni mikor van egy kigenerált oldalad, és valamit hozzá kell füzz, vagy átírj de nincs kedved megkeresni hol van vagy csak 2-3 napra kell kivenni és nincs értelme átírni akkor a kimenetet megszûröd. vagy generálsz egy képet és a kép adatára van szükséged de nem vagy biztos hogy van jogod bárhova is írni, akkor is ez egész jó. pl data href írásánál egész jól használható. De semmiképp sem javaslom én, hogy erre használd amire használtad, persze lehet és mûködik, de nem elegáns, nem professzionalista. De mûködik és én legtöbbször azt mondom ami mûködik ha nem én kell majd javítsak benne akkor tökéletes.

az szép lesz... 😄DDDDDDDDDDDDD

Miért nem 5.5-el? 😄

Majd nekiesünk IE6-tal ne félj ^^

😄DDDDD

Készíts elõ egy üveg vörös szárazat, aztán rántsd le a leplet😊

az sem rossz ötlet 😄DD igen, egyébként átirányításra gondoltam. 😊
egyébként ha minden jól megy, jövõhét elején belinkelném a webshopot, aztán meg majd jól tûrjük a kritikákat 😄D

Nem tudom milyen login kezelésre gondolsz, de ha a átirányításra, én azt tróger módon kliens oldalon "document.location.href"-el végzem általában😊

Nem szép megoldás, de @session_start(); mellett elvileg elnyelõdnek az "already sent" üzenetek😊

hmm majd megnézem.

a Header helyett mit javasolsz akkor login kezelésére?

Nemtom, nem láttam a scriptet, de ez is lehet probléma:
php.net, ob_start manual, piros vastag keretben:

"Some web servers (e.g. Apache) change the working directory of a script when calling the callback function. You can change it back by e.g. chdir(dirname($_SERVER<'SCRIPT_FILENAME'>)) in the callback function."

Az is lehet, hogy rossz helyen nyomod neki a flush-t/zárod be, session_start alatt van közvetlenül, stb.

Illetve ha sûrûn használod, php.ini-ben is be lehet kapcsolni az output bufferinget és egy gonddal kevesebb. Mondjuk biztonsági szempontból lehet nem túl elõnyös.

Én speciel nem igen szeretek játszani a header-ekkel, így ritkán használom.

+ azon gondolkozom hogy ezzel, hogy kiszedtem nem lesz-e benne valamilyen biztonsági rés :|

viszont még mindig nem értem, hogy miért csak és kizárólag az én ff-omnál volt ez a hiba.
Ability : gondoltam erre én is, töröltem mindent, még kínomban flushdns-t is nyomtam 😄DD

Én csak a firefoxnál a beállításokra gondoltam, hogy kivan kapcsolva a cookie kezelés.
De ha user oldalon meg megy akkor más a problem 😄

tiéd a sör!
viszont magyarázat követlek érte!
[ viszont ezzel annyi a gond, hogy ugye így van kiment a header elõtt, ha nem él a session, és akkor header already sent-tel elszállhat a location parancs ]

megnézem

Próbáld úgy hogy kiveszed az ob-t és flush-t és simán session_start(); -al indítod.

meg akkor a user oldalon sem menne a session.

Ha ki lenne kapcsolva a session cookie, akkor a többi böngészõben sem lenne jó.

jah értem mire gondolsz, de nem az a hiba, és a sessid süti és él.

De magához a session kezeléshez bekell, hogy legyen kapcsolva a cookie-k, hacsak nem GET-el van átadva a sessid. Vagy rosszul tudom? Most teljesen elbizonytalanodtam.<#conf>

admin részen egyáltalán nincs cookie, nem véletlenül.
user részen opcionális loginnál, és az is mûködik vele is, nélküle is.

Hulyeseget fogok mondani de cookie-k fogadasa bevan kapcsolva?

ugye. 😄
és tuti, hogy a session-nel van baj, mert ha kiveszem a kódból a header-es eldobást, behozza a menük tartalmát meg ugyebár nem dob el más oldalra, viszont semmilyen session nem él, és minden ahhoz kötõdõ mûvelet azonnal hibát jelez.
tehát teljes mértékben értetlenül állok a dolog elõtt.

hmm <#confused>

nincsen.
a session_start és ob_start elõtt nincs semmi, az utolsó header hívások után pedig ottvan az end flush

Nincs véletlenül BOM karakter a szóban fogó php fájl elején?

a lényeg, hogy az admin login elpostolja az adatokat egy feldolgozónak, ami megejti az ellenõrzéseket, és ha rendben van, dob egy Header:location-t. eddig rendben van. rálép az admin fõoldalra. DE!
ugye a fileokban a belépést egy validáló file ellenõrzi, ami a session-t ellenõrzi ha nincs, vagy nemjó az érték, akkor headerrel elvág.
na most ha bármilyen menüpontra kattintok elvág. és csak az itthoni gépemen, és csak a FF.

én is erre gondoltam, viszont user felületen meg él a session... komolyan, ilyet még nem láttam / hallottam soha.