Hirdetés
Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
válasz Speeedfire #15373 üzenetére
Őőő, vazze, ne nézz már full kreténnek. Szóval de, átjött, csak szerintem ez a topic is tele van hasonló vagy durvább hsz.-ekkel, így sajnos már cseppet sem meglepődve olvastam a kifigurázás céljából kiemelt írásokat.
Vannak benne elvétve viccesek, de mondom, ha ebből a topicból szemezgetnénk, akkor is találnánk ütősebbeket. Például "A minap azon agyaltam, hogy miképp lehetne egy js fájlba php kódot illeszteni." sztem annyira nem számít viccesnek, mint amilyennek szánta a blog készítője, mert ezek szerint az író nem ért hozzá, hogy lehet ilyet, a szerver egysoros átkonfigurálásával.(#15372) csabyka666
Szívesen! De amúgy az általad linkelt oldalon is működik a reguláris kifejezés tesztelése: http://www.rubular.com/r/AJLZHA9Msj
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz csabyka666 #15386 üzenetére
Ja, hogy így! Valóban, az jogos.
(#15387) DNReNTi :
Azért olyan jellegű kérdéseket nem láttam tőled, mint amilyeneket ez a blog kifiguráz. Egyébként meg meglehetősen érdekes felfogás, hogy akkor van _létjogosultsága_ ezeknek a SZAKMAI (!!!4444NÉGYNÉGYNÉGY) topicoknak, ha tele van olyan kérdésekkel, amikről messzire bűzlik, hogy a kérdező még csak meg sem próbált energiát beleölni, utánanézni, tanulni. Mindenki kérdezhet hülyeségeket, ha még csak most kezdte, de azért nem mindegy, hogy az jön le, hogy az illető alapból félhülye, vagy simán lusta, és szarik bele, vagy látszik, hogy valamit erőlködött, de nem jött össze, meg is osztja, mire jutott, és a továbbhaladásban kéri a segítséget. Nyilván az utóbbi a jó/jobb eset.
Érted te ezt.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz fordfairlane #15398 üzenetére
Vigyázz, mert mindjárt megkapod, hogy a Singleton qrva gáz.
"Majdnem olyan, mint egy Singleton"
Hogy érted azt, hogy majdnem olyan? Jelen formájában ez konkrétan Singleton-minta.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz fordfairlane #15402 üzenetére
Ebben igazad van, de tulajdonképpen ez ilyen Singleton+Factory minta egyvelege.
(#15403) DNReNTi :
"Mért lenne gáz? Adatbázis kapcsolat kezelésére szvsz nem igen van jobb megoldás."
Egyrészt szerintem az ironikus hangvételből kiderült, hogy nem feltétlenül tükrözi a véleményemet a dolog, még ha bőven van is igazsága az azt ellenzőknek, tehát nincs szükség a szemforgatásra (arra amúgy sincs, ha szakmai vitát akarunk nyitni), másrészt meg javaslom, keress rá a topicban (pl. Athlon64+ kolléga itt kardoskodik ellene: [link]), illetve Stack Overflow-n és más forrásokban is, hogy mik is az érvek a Singleton-minta ellen; az "Adatbázis kapcsolat kezelésére szvsz nem igen van jobb megoldás" mondatra meg az a válasz, hogy van, akik meg tudják oldani nélküle, tehát lehet jobb megoldás. Most is előkapható a sablon-érv, hogy "nincs legjobb megoldás".[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz DNReNTi #15427 üzenetére
"Nem kezel. Az adatbázis kapcsolat létrehozása előtt ki aztán pedig bekapcsolja az error_reporting-ot, hogy hiba esetén egy szépen megformázott hiba oldalra tudja dobni a felhasználót (header()). Ha nem kapcsolnám ki, akkor maga a php dobna hibát, ami után nem menne a header, ezért van benne. Ez ebből hiányzik, mivel: 1: nincs hibaoldal, 2: teszt."
Te ezt írtad:error_reporting(0);
$DB_Connect = new mysqli(self::$DB_Host, self::$DB_User, self::$DB_Pass, self::$DB_Name);
if ($DB_Connect->connect_error) {
echo 'Database connection failed. Code : ' . $DB_Connect->connect_errno;
}
$DB_Connect->set_charset(self::$DB_Char);
error_reporting(1);Tehát fogod, és 0-ra, majd 1-esre állítod az error_reportingot.
Egyrészt eleve milyen alapon nyúlkál az osztályod az error_reporting értékéhez, minek? Az ilyesmit felejtsd el gyorsan. A kód ne csináljon többet az elvártnál.
Másrészt sztem te az error_reporting()-ot a display_errors értékével kevered.
Harmadrészt miért állítod be az error_reporting szintjét pont az E_ERROR-ra? Az error_reporting(1); ugyanis ekvivalens azzal, ha azt írod, hogy error_reporting(E_ERROR); Mi van, ha korábban az error_reporting értéke szándékosan E_ALL-ra volt állítva, ami 32767? (Itt láthatod az értékeket.)"»»"Ha csak kiírsz egy üzenetet a képernyőre, attól az alkalmazásod még fut tovább"
Az előzőben benne a válasz. Élesben egy hibaoldalra dob."
Hát ez eleve rossz megközelítés. Most akkor itt echo-zol, de aztán majd élesben átírod normális hibakezelésre? Ez így nem lesz jó. Az ilyenből tuti, hogy az lesz, hogy tesztelésnél nem jelentkezik semmilyen hiba, tök jól működnek a dolgaid, aztán majd élesben jöhet a gebasz, és akkor szépen kiírtad a képernyőre a hibaüzenetet, ahelyett, hogy eleve normálisan kezelted volna a hibákat, már amikor megírtad a kódot.
Jótanácsként mondom, ne szopasd magad azzal, hogy "hát ezt majd átírom", mert úgyis elfelejted, vagy pedig később csak macerás lesz megcsinálni.
Szóval az echo-zás helyett dobj szépen egy exceptiont, hiszen komoly hiba, ha nem tudtál csatlakozni az adatbázishoz.A többit asszem mallee már leírta, például hogy tök értelmetlenek az if-else-be rakott exception-dobásaid.
Pont azért jó, hogy tudsz dobálni exceptionöket, mert elkerülheted az ilyen ocsmány if-else szerkezeteket.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz csabyka666 #15440 üzenetére
"Itt kaptam egy tanácsot a PH-n, hogy írjam oda minden adatbázis-kapcsolódás után, hogy:
mysql_query("SET NAMES SET 'utf8'");
mysql_query("SET CHARACTER SET 'utf8'");
"
Ilyen tanácsot sztem nem adtunk.
A mysql_* kezdetű függvényeket már nem használjuk, deprecated ahogy ezerszer ki lett tárgyalva a topicban.
Ilyesmi inkább elképzelhető:$db = new PDO(
"mysql:host=localhost;dbname=test",
"root",
"root",
array(
PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES UTF8;',
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
)
);Sk8erPeter
-
Sk8erPeter
nagyúr
válasz csabyka666 #15449 üzenetére
Még mindig (addig fogod kapni ezt a választ, amíg nem váltasz a mysql_ kezdetű függvényekről): használj PDO-t prepared statementekkel, és akkor elkerülöd az ilyen szerencsétlenkedéseket.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz csabyka666 #15453 üzenetére
Pont azért lenne érdemes időben átállnod a manapság is jól használható eszközökre, mert minél tovább húzod a dolgot, annál nehezebb lesz később átírni a projektet. Csak rá kell érezned, és nem lesz akkora katasztrófa átírni a mostani, kerülendő mysql_*-es megoldást.
Természetesen próbálgasd előbb localhoston, egy tök másik projekten, hogy hogy is működik a dolog, és meg fogod szokni.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz csabyka666 #15456 üzenetére
A cookie beállításához miért használsz mysql_real_escape_string()-et?
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz csabyka666 #15470 üzenetére
Milyen jó lett volna, ha megfogadod a tanácsunkat, és PDO-t használsz exception-kezeléssel.
(#15473) csabyka666 :
Könyörgöm, fejezd már be ezt a mentalitást! Bocs, de minek jössz ide kérdezgetni, ha tákolni akarsz, és ragaszkodsz a saját elképzeléseidhez? Azért nem érdemes használni a mail()-t, mert egyszerűen túl sok a problémalehetőség, formázási problémák vannak vele, olyan gondjaid fognak előfordulni, amit épp a javasolt SwiftMailerben vagy a PHPMailerben már régesrégen megoldottak. Korrekt kimenetet kaphatnál, és fordíthatnád az idődet HASZNOS tevékenységekre, HASZNOS önfejlesztésre, ahelyett, hogy ilyen baromságokkal szopatnád magadat.
Megint én vagyok a beszólogatós köcsög, de vállalom, valakinek meg kell mondania időben, hogy hülyeséget csinálsz.(#15476) Soak :
Notórius önszopató, mondhatjuk neki mi a magunkét, egyszerűen szarik rá, "jó lesz az"-alapon. Mindjárt jön a hosszú kifejtése annak, hogy "de hát én így meg úgy, ti meg úgy meg amúgy", szóval fűrészelhetjük majd vele a fingot keményen megint, ahelyett, hogy valami érdemi dologról lenne szó végre ebben a topicban.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Azt a qrva, de jó ronda. Hogy sikerült ezt így összehozni? Attól kifejezetten rossz minőségű lesz a kód, ha be van hányva egy sorba egy csomó minden - lásd azt a csodálatos while+regexp-tesztelés+változónak értékadás+sprintf+rand sort... Az ilyen hányadék kódhoz már szinte művészi tehetség kell.
Ha ezt meg így kaptad, hát az szívás, de itt az ideje, hogy átalakítsd valami áttekinthető formátumúra.$i=($QUERY_STRING)?($QUERY_STRING):"10";
helyette
$i=( isset($QUERY_STRING) ? $QUERY_STRING : 10 );
vagy
$i=( !empty($QUERY_STRING) ? $QUERY_STRING : 10);Amúgy minek ide a $QUERY_STRING változóhoz a nagybetű? És ez valami globális változós undormány? Miért nem kapta meg ezt paraméterként a függvény, és lett egy default értéke a paraméternek, ami jelen esetben 10 (amennyiben nem lenne az megadva a fvhíváskor; ja, és nem mindegy, hogy nem "10" stringként, hanem 10 intként)?
A $pwd változót meg deklaráld előre még az első while-ciklus előtt:
$pwd = '';A regexp betűiből szándékosan maradt ki az i és l (mint ló), I (mint Ilona) és O betű, meg a 0-s és 1-es szám, mert valaki azt gondolta, ettől biztonságosabb lesz a dolog?
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz DeltaPower #15493 üzenetére
"Ez mintha egy captcha generátor lenne, azokban szokták ezeket a betűket kihagyni a vizuális hasonlóságuk miatt..."
Jogos, hogy emiatt lehet, ez már valahogy fél 3-kor eszembe se jutott. Amúgy a pwdgen() névből ítélve inkább jelszógeneráló lehet. De lehet, hogy csak a név félrevezető, és neked van igazad, és a CAPTCHA-ban megadandó szöveget is jelszónak hívják náluk."A $QUERY_STRING-re nem csoda hogy sikít az interpreter, se paraméterként se global-al behúzva nincs ott a függvényben "
Az egész függvény tele van undormány megoldásokkal, úgyhogy ez csak egy része a sok parának...[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #15507 üzenetére
Sztem arra gondolt, hogy tök más lesz az API (erről infókat nem tudok), és így nem triviális a migrálás. Egyébként az ilyen radikális váltás sokszor gyümölcsöző tud lenni, egy tök más példát kiragadva például a Drupallal az a bajom, hogy rohadtul ragaszkodnak a nagyobb szintű API-kompatibilitáshoz, a könnyebb migrációhoz a különböző major verziók között, hogy nevezzék ugyanúgy, hogy lehessen ugyanúgy meghívni, hogy legyen ugyanúgy procedurális kód, blablabla, és mivel még mindig a PHP4 körül kialakult konvenciók vannak erősen belecuppanva a "rendszerbe", ezért a kód is kicsit kutyulmány-feeling. Mondjuk még mindig ezerszer jobb, mint egy Joomla.
Sk8erPeter
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
Ajjaj, mi készülhet ott a háttérben...
http://stackoverflow.com/questions/9496612/php-associative-arrays-keys-indexes-limitations
http://stackoverflow.com/questions/467149/what-is-the-max-key-size-for-an-array-in-phpSk8erPeter
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
válasz DNReNTi #15555 üzenetére
Egyetértek, teljesen értelmetlen szarakodni a mail() függvénnyel. Ezt akartam én is beírni, csak aztán visszafogtam magamat, mert ilyenkor jön egy ilyen válasz.
Vagy a PHPMaileren kívül még ott a Swift Mailer.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Phvhun #15584 üzenetére
XPath-t használj:
http://www.php.net/manual/en/domxpath.query.php(inspectorban egyébként ugyanúgy jobb klikk, csak Copy CSS helyett Copy XPath)
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz daninet #15587 üzenetére
"Simán mint excelben csinálsz egy táblázatot és irkálsz be függvényeket"
Miért kellene függvényeket beírni akárhova is? Nem lenne túl felhasználóbarát, ha ilyenről lenne szó."Ha pedig nincs akkor Google Doc-ból táblázatot beszúró bővítmény tuti van. "
Hát ez elég egyszerű, de nagyon béna megoldás. Főleg, hogy ez nem túl nagy rugalmasságot jelent az adatok különböző szempontok szerinti megjelenítésében.
Mindenesetre a Weblapkészítés topicban folytatódott a kapcsolódó eszmecsere, ott is megkérdezte.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Ne duplikáld már légy szíves a hsz.-eidet mindenhova... Elég lesz egyszer is.
(#15589) daninet :
Akkor valamit félreérthettél, mert Google Docs-szerű megoldást senki sem javasolt.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz TomyLeeBoy #15608 üzenetére
A sortöréseket GET-metódussal is lehet továbbítani természetesen (ez platformfüggő, pl. Windows esetén CRLF (vagyis carriage return-line feed): %0D%0A a query stringben), de ilyen formok esetében, ahol pl. már textarea van, tehát valószínűleg nagyobb tartalmakat fogsz továbbítani, nem indokolt a GET-metódus, sőt, ha túl hosszú a tartalom, az URL/query string hosszának limitáltsága miatt problémákat is okozhat, tehát használj POST-metódust. De pl. egy kereső esetén GET-metódus indokolt, így az URL kimásolható, elküldhető, könyvjelzőzhető.
Tehát esetedben érdemes lenne inkább POST-metódust használni (nem mintha ez okozná a problémádat, ez inkább csak javaslat).
A problémádra rátérve: azt írtad, "Ha a textarea-ban van sortörés, mentés és megjelenítés után már nincsen", hogyan mented el? Nem szeded ki a sortöréseket véletlenül? Megnézted már az elmentett tartalmat mondjuk tök egyszerűen phpMyAdminnal vagy valami másik adatbázis-kotorászóban? Debuggoltad már a tartalmat elküldés után?
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz TomyLeeBoy #15610 üzenetére
"A get-et igazából csak azért használtam, mert frissítés nélkül mentődik ez a tartalom, szóval ajaxos és így kézenfekvő volt."
A kettő között még csak minimális összefüggés sincs, AJAX-szal is tudsz mind POST-, mind GET-metódusok segítségével kommunikálni. Attól még, mert AJAX-szal küldöd el az adatokat, esetedben ugyanúgy a POST-metódus használata a kézenfekvő, és nem a GET, mivel nem egy keresőt vagy ahhoz hasonlót készítesz.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz TomyLeeBoy #15612 üzenetére
Még mindig nem értem, miért lenne "kézenfekvő". Amúgy nem kötekedésből írom, hanem hogy nehogy valaki fejében rossz infók maradjanak meg véletlenül.
Sk8erPeter
-
Sk8erPeter
nagyúr
Web Platform Installer segítségével pár kattintás összehozni, a pár másodperces telepítés után pl. pötyögd be, hogy WordPress vagy Drupal, hogy ez behúzza a számára szükséges függőségeit, telepít mindent egy-két perc alatt, aztán max. az átmenetileg felrakott CMS-eket letörlöd.
IIS+MySQL+FastCGI PHP
http://prohardver.hu/tema/weblap_keszites/hsz_11089-11089.htmlSk8erPeter
-
Sk8erPeter
nagyúr
válasz DNReNTi #15636 üzenetére
"Egy kérdésem még így is maradt: Miért? Tehát mi a gyakorlati funkciója ennek? "
A kérdésed teljesen jogos, feltételezem, a feladat valami fos tanfolyamon/számonkérésen lett kitalálva, és tipikus esete annak, amikor a magát tanárnak képzelő embert jól fel kéne képelni, hogy talán gondolkozzon már el azon, hogy a diákjai milyen feladatokból fognak tanulni - hát nem ilyenekből. Kezdők számára tök feleslegesen komplikált feladat, ahelyett, hogy valami gyakorlati haszonnal bíró miniwebalkalmazást fejlesztetnének velük, és így némi kedvet is adnának a szakmához, meg olyat gyakoroltatnának velük, aminek még valami értelme is van.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz trisztan94 #15644 üzenetére
"Hát mivel DOM-ot manipulálsz, ezért ez javascripttel kellene csinálni."
Sehol nem írta, hogy kliensoldalon szeretné manipulálni a DOM-ot. Szerveroldalon is lehet különböző feltételektől függően class-t generálni egy kódból kreált HTML-elembe.(#15647) lesaux :
"Szóval egy sima PHP-s levélküldéshez tényleg kell ekkora cirkusz, vagy valamit alapból rosszul csinálok?"
Egyáltalán nem nagy cirkusz, főleg PHPMailerrel vagy SwiftMailerrel. Valószínűleg VALAMIT te rontasz el, például éppen az elérési utat, mivel konkrétan az a hiba.
Amúgy nem a "mail() függvényeid" nem működnek most, hanem konkrétan nem található a PHPMailer osztály az általad megadott elérési úton.A kódodban ez van - ja, és légyszi használd legközelebb a "Programkód" gombot a kódod kijelölése UTÁN! Köszi! -:
$phpmailer_path = $_SERVER['DOCUMENT_ROOT'].'/../phpmailer/class.phpmailer.php';itt tehát a kellős közepén van egy /../, ami azt jelenti, hogy a rootkönyvtárhoz képest még visszafelé lépsz egyet. Ergo az előző tárhelyeden mások voltak az elérési utak, mint az új tárhelyen.
Próbáld ki azt, hogy ezt kiszeded belőle, így:$phpmailer_path = $_SERVER['DOCUMENT_ROOT'].'/phpmailer/class.phpmailer.php';
Persze ismerni kéne a tárhelystruktúrát. De első próbának jó lesz, vagy nem.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz lesaux #15649 üzenetére
Na várjál, mielőtt anyáznál a tárhelyszolgáltatódnál, azért előtte próbálkozz kicsit, vagy írd körül nekünk jobban a helyzetet, mert úgy tűnik, nem vágod az elérési utak mikéntjét.
"A mostaninál három darab /../ is van, ami mondjuk eleve gyanús, de hát egyszer vissza kell lépnem a public_html mappából, utána a domainnevemet leíró mappából, majd a domains nevűből, és ott figyel egy .php mappa, amiben 5 db php-mail.log fájl sorakozik, de mind 0 bájt hosszú."
Heh?
Most hogy jönnek ide a logfájlok? Te a phpmailer könyvtárban lévő class.phpmailer.php fájlt szeretnéd elérni, ennek kell a megfelelő elérési útja.Na, tehát hogy is van ez nálad?
Van a public_html könyvtárad, gondolom ebben van valahol a phpmailer könyvtár, nem eggyel vissza a public_html-től, na de kérdés, hogy konkrétan a public_html-en belül melyik könyvtárban van. Vagy ömlesztve van a public_html-be? Vagy hogyan?
Írd körül a könyvtárstruktúrát légyszi, és akkor szerintem a szolgáltató bevonása nélkül is meg tudjuk oldani a problémát. Persze az jó, ha ők is gyorsan válaszolnak.Sk8erPeter
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
válasz DeltaPower #15672 üzenetére
Na várj, de a path pont opcionális paraméter:
http://www.php.net/manual/en/function.setcookie.php
bool setcookie ( string $name [, string $value [, int $expire = 0 [, string $path [, string $domain [, bool $secure = false [, bool $httponly = false ]]]]]] )"path
The path on the server in which the cookie will be available on. If set to '/', the cookie will be available within the entire domain. If set to '/foo/', the cookie will only be available within the /foo/ directory and all sub-directories such as /foo/bar/ of domain. The default value is the current directory that the cookie is being set in."Sk8erPeter
-
Sk8erPeter
nagyúr
válasz DeltaPower #15674 üzenetére
Hú basszus, látszik, hogy rohadt fáradt vagyok, pont ott van a lényeg, abban, amit én magam idéztem, hogy "The default value is the current directory that the cookie is being set in", és így már összeállt, hogy miért mondtad, amit mondtál.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz TomyLeeBoy #15699 üzenetére
Két probléma van:
1. sprintf()-et használsz, ami UTF-8-as karakterekre nem működik megfelelően
2. a regexpben az "u" modifiert kellene használnod:
http://php.net/manual/en/reference.pcre.pattern.modifiers.php
"u (PCRE_UTF8)
This modifier turns on additional functionality of PCRE that is incompatible with Perl. Pattern strings are treated as UTF-8. This modifier is available from PHP 4.1.0 or greater on Unix and from PHP 4.2.3 on win32. UTF-8 validity of the pattern is checked since PHP 4.3.5."Röviden a megoldás: a külön $pattern változó helyett a cikluson belül így nézzen ki a $regex változód, hogy egyből be is helyettesíted az értéket, így kikerülöd az sprintf() használatát:
$regex = '/(?!<.*?)('.$needle_s.')(?![^<>]*?>)/iu';
Így már működni fog. (Ugyanazt csinálja, mint a korábbi kódod, csak össze van fűzve a string a %s behelyettesítése helyett, és elláttam az u modifierrel (lásd a case insensitivity-t jelölő i modifier után).)
Még egy fontos dolog: a font tageket ma már nem használjuk (nagyon régóta deprecated), szóval azt cseréld le span-re, és ugyanúgy működni fog.
Sk8erPeter
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
válasz trisztan94 #15704 üzenetére
Eddig nem amiatt panaszkodtál a másik topicban, hogy a Here-dokumentációk milyen gyenguszok? (Btw. ebből nem tudom, mi igaz egyáltalán, mert nem néztem sosem. )
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Drótszamár #15715 üzenetére
"Fórum szerint napi 2500-as a limit."
Nem csak fórum, ott van a hivatalos oldal, ahol biztos infókat kapsz:
https://developers.google.com/maps/licensingGeocoding Web Service
Maps API: 2500 requests per 24 hour period
Maps API for Business: 100 000 requests per 24 hour periodSk8erPeter
-
Sk8erPeter
nagyúr
Ettől még nyilván van értelme átültetni az egészet úgy, hogy legyen benne némi PHP, adatbázis-használat, meg egyebek, mivel épp ez a cél...
A kérdező viszont annyira általánosan tette fel a kérdését, hogy igazából nem tudom, mit lehet erre válaszolni. Nyilván meg lehet oldani, és fog működni, ha jól csinálja...
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz trisztan94 #15732 üzenetére
És az mégis mit oldana meg? Windows-on a PHP_EOL ugyanúgy "\r\n", más platformon "\n" (mert platformfüggő sortörés). DE a lényeg, hogy itt a probléma az, hogy hiába kerül sortörés a forráskódba, attól még ez a felületen nem fog látszani, ezért kell a HTML-es sortörés. (Egyébként a PHP_EOL tényleg jobban használható, mint a "\r\n", mert ugye az IDE-ben van hozzá autocomplete, na meg nem egy törékeny string, hanem egy kifejező konstans.)
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz DeltaPower #15734 üzenetére
Egyetértek, főleg, hogy nem a szerveroldal feladata az egész konkrét megjelenítésbeli dolgokkal foglalkozni.
Sk8erPeter
-
Sk8erPeter
nagyúr
Jaaa, bocs, félreértettelek, nem is ismertem a pixlr API-ját, azt hittem, hogy végül az időhiány miatt kissé egyszerűbb megoldást tákoltál bele valahogy az oldalba, iframe-mel, vagy fingom sincs.
De az fasza, hogy van API-ja, jó tudni: https://pixlr.com/developer/api/
Sk8erPeter
-
Sk8erPeter
nagyúr
A <font> tag ezer éve elavult, ahogy a color attribútum is. Használj helyette mondjuk <span> taget, aztán CSS-t.
A mail() függvénnyel szarakodni meg egyszerűen nem éri meg, wis már a hsz.-ének 4. pontjában javasolta a PHPMailert VAGY a Swift Mailert, mindkettő jó, és rohadt egyszerű velük a küldés, a hivatalos oldalukon jó példák találhatók.
"Másik, nem akarom semmiképp összezsúfolni a html-ben lévő cumót még ezzel is"
Semmi köze a szerveroldali kódnak ahhoz, amilyen HTML-kimenet a kliens gépére letöltődik. A levélküldős dolgot egyébként is illene valami másik fájlban elintézni, nem egybekutyulni a másikkal."Ezért nekem megfelelő ez a javascriptes dolog"
A PHP mail() függvényének abszolút semmi köze a JavaScripthez."Persze király lenne, ha mondjuk ezt egy java-s - mondjuk amolyan jquery-s képnézegetős formában - kapná a júzer"
A Java NAGYON nem ugyanaz, mint a JavaScript, ne keverd a dolgokat. Te a JavaScriptről beszélsz. A jQuery pedig egy JavaScript-könyvtár.
Ilyen galériákból pedig Dunát lehet rekeszteni.
Csak egy példa az n+1-ből: http://www.jacklmoore.com/colorbox/Sk8erPeter
-
Sk8erPeter
nagyúr
1. bekezdésre: mindegy, hogy valaki mennyire vágja a témát, vagy nem, a tény az tény, ha valami elavult, akkor nyilván itt azt fogjuk javasolni, hogy ne használd. Bár nem tudom, mit várnál helyette.
2. bekezdésre: Javát írtál JavaScript helyett a korábbi hozzászólásodban. Erre mondtam, hogy a kettő nem összetévesztendő, mert nagyon nem ugyanaz.
"Namost, ha valamit nem töltök ki, akkor kapok egy üzenetet, egy új, tök fehér lapon, fekete betűkkel, sima egyszerű betűtípussal, hogy mi a probléma. Utána nyomok a böngészőn egy "vissza" gombot, és megint ott vagyok a kapcsolat lapon, hogy "javíthassak"."
Ha JavaScript nélküli megoldás van, úgy szokás megoldani ezt egyszerűen, hogy a kérés validálása+feldolgozása után beállítasz mondjuk egy $_SESSION-változót (mondjuk $_SESSION['status'] és $_SESSION['message'], de tök mindegy), hogy mi a helyzet, jó volt-e a megadott paraméter, vagy sem, aztán visszairányítod (header('Location: http://www.example.com/innenjottel.php') segítségével) az eredeti oldalra, ahol pedig ezeket a $_SESSION-változókat lecsekkolod, hogy léteznek-e, ha igen, akkor valamilyen módon felhasználod az értéküket (pl. nyilván az üzenetet kiírod), majd megszünteted ezeket a beállított változókat (unset() segítségével)."Köszönöm egyébként a kioktatást, lehet hülyének is nézni, meg mondani, hogy menjek szakemberhez és fizessek neki, aztán majd megoldja, de ha ennyire bonyolult lenne a történet, akkor marad így aztán kész"
Te most tulajdonképpen mégis min sértődtél meg? Hol mondtam én neked ilyeneket, amiket kitaláltál? Nem is értem. Nem volt kioktatás, leírtam a tényeket. Már azon is érzékennyé váltál, hogy megemlítettem, hogy valamit ne használj, mert elavult. Ha nem jött át: ezek jótanácsok. Ha ilyenekre nincs szükség, akkor nem értem, miért kérdezed a véleményünket.Egyébként nem tudhatjuk így fejből, hogy konkrétan mi mennyire megy, így ismeretlenül kicsit nehéz megállapítani, hogy milyen megoldásokat javasolhatunk neked, pl. azt sem írtad, megy-e az angol, és hogy konkrétan melyik résznél akadsz el mondjuk az említett levelezőkkel (PHPMailer vagy Swift Mailer). Azért azt is vedd figyelembe, hogy itt a topicban mindenki a szabadidejében segít, valószínűleg jó szándékból (bár az előző hsz.-emet is sértésnek vetted).
Sk8erPeter
-
Sk8erPeter
nagyúr
Huh, kicsit túl hosszan sikerült mindezt leírnod.
Csak hogy tisztázzuk: én is magamtól, saját erőmből tanultam meg a webfejlesztést, úgy, hogy közöm nem volt hozzá, és SENKI nem vezette a kezemet, hogy ezt, meg azt csináld. Utánanéztem, olvastam, gyakoroltam, utánanéztem, olvastam, gyakoroltam, utá... Így megy ez.Sk8erPeter
Új hozzászólás Aktív témák
- Fűzzük össze a szavakat :)
- Ford topik
- Milyen okostelefont vegyek?
- Kertészet, mezőgazdaság topik
- Elektromos (hálózati és akkus) kéziszerszámok, tapasztalatok/vásárlás
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Autós topik
- DIGI kábel TV
- Samsung Galaxy Watch6 Classic - tekerd!
- iPhone topik
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft
Város: Debrecen
Cég: Ozeki Kft
Város: Debrecen