- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Honor Magic5 Pro - kamerák bűvöletében
- Profi EKG-s óra lett a Watch Fitből
- Samsung Galaxy S24 FE - később
- Samsung Galaxy S21 és S21+ - húszra akartak lapot húzni
- Samsung Galaxy A36 5G - a középső testvér
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Magisk
- Milyen okostelefont vegyek?
- iPhone topik
Új hozzászólás Aktív témák
-
DNReNTi
őstag
válasz
CaNNa3IS #18355 üzenetére
Eskuszom mostmar raszanom magam, hogy kiprobaljam egyszer, annyian irtak mar itt PH-n.
A MAMP amugy nagyon handy tool, igazi OSX felhasznalokra szabott software. Zero konfig file turas, UI-on osszedobod a hosztokat, akar kulonbozo PHP verziokkal, es start. Siman megerte az arat.
-
DNReNTi
őstag
válasz
concret_hp #18328 üzenetére
A legegyszerűbb ha felteszel egy wamp-ot.
-
DNReNTi
őstag
-
DNReNTi
őstag
Sziasztok,
OSX-en mi a bevált környezet PHP futtatáshoz? Van itt is Wamp-hoz hasonló komplett csomag, vagy egyesével kell telepíteni mint Linuxon? Igen ki tudnám guglizni, de inkább a tapasztalatra hagyatkozom.
Thx -
DNReNTi
őstag
válasz
fordfairlane #18238 üzenetére
Köszi a megerősitést, mobal neked szintén, le fogom csekkolni a JWT-vel.
Ha lesz időm... -
DNReNTi
őstag
Sziasztok,
Keresek nagyon lightweight PHP micro framework-öt kimondottan csak REST fejlesztésre. Kicsi legyen és gyors. Lumen szerintem nem lightweight, a Slim esetleg? Vagy valami más?
Thx! -
DNReNTi
őstag
+1
(#18220) repvez
Fing nélkül nem lesz egyszerű. -
DNReNTi
őstag
válasz
Sk8erPeter #18106 üzenetére
Abszolút jogos, csak most a félkész projekten nem akarok változtatni az elnevezési konvención, mert egy év múlva azt se fogom tudni ki van kivel.
A legjobb tényleg az lenne ha felismerné az "is"-t, vagy valahogy be lehetne rá konfigolni, hogy felismerje, és akkor mehetne az isAkármi(). Lesz egy kis időm utána is nézek, hogy lehet ezt megcsinálni, vagy plugint írni rá.
-
DNReNTi
őstag
válasz
Sk8erPeter #18104 üzenetére
Aha zsír, erre gondoltam amikor azt írtam: "írjam be konstans szövegként".
Thx. -
DNReNTi
őstag
Sziasztok,
PhpStorm 10 user van rajtam kívül?
Bevezettek egy új fícsört, ami engem kimondottan zavar, a getter setter generator figyelembe veszi, hogy a property boolean e, hogyha az, akkor nem getXy() lesz hanem isXy(), ami engem két okból zavar: egy: mindig gettel kezdem beírni amikor a gettert használni akarom, kettő: konzekvensen a boolean tulajdonságok neve nálam is_valami, pl is_draft, aminek eredményképpen én a getIsDraft() függvényt akarom generálni nem pedig az isIsDraft()-ot... First world problems...A code template-ben mire írjam át ezt: "${GET_OR_IS}", ez a ludas ugyan is. Van simán ${GET}, vagy írjam be konstans szövegként?
Thx! -
DNReNTi
őstag
válasz
#68216320 #18074 üzenetére
Írtam rá egy sima egyszerű random string generátort, egy while ciklusban 32 karaktert dob össze, kisbetű-nagybetű-számok kombinációból, aztán ellenőrzi hogy létezik e már, ha igen kezdi elölről. Elég kicsi az esélye amúgy, hogy bármikor is újat kelljen generálni, de az ördög nem alszik, így üzembiztos. Ezenkívül persze az adatbázisban a hash mező unique. Ezzel nekem még sosem volt gond.
-
DNReNTi
őstag
válasz
#68216320 #18072 üzenetére
Nálam erre a bevált módszer egy random, de egyedi hash generálása adott eseményhez, ilyen az aktiválás, elfelejtett jelszó, fiók törlés, email cím változtatás. Külön táblában tárolom ezeket a felhasználóhoz és az eseménytípushoz kötve. Én törölni sem szoktam, de nagyobb felhasználóbázisnál, azért érdemes egy ütemezett archiválás.
-
DNReNTi
őstag
válasz
fordfairlane #18069 üzenetére
Most már összeállt mire gondolsz. Elbeszéltünk egymás mellett.
Én nem konkrétan a típus meghatározására értettem, vagy céloztam a hozzászólásaimat hanem arra, hogy egy tulajdonság lehet objektum, mivel ez volt a témaindító. No túl van tárgyalva.
-
DNReNTi
őstag
válasz
fordfairlane #18067 üzenetére
Bakker.
Úgy kiforgattad a szavaimat mint egy Blikk újságíró.
-
DNReNTi
őstag
válasz
fordfairlane #18065 üzenetére
A runtime nem, de az IDE-nek jól jön a segítség, hogy tudja mi az ott. Lehet nem fogalmaztam egyértelműen.
A lényeg, hogy lehet objektum típusú egy tulajdonság.
-
DNReNTi
őstag
válasz
PumpkinSeed #18063 üzenetére
Amúgy remélem nem mondok f*szságot, de szerintem lehet egy objektum tulajdonsága egy másik objektum típusú. Ezért szoktam annotálni és akkor az IDE is vágja. Tehát pl ez így nekem mindig szuperül működik:
class Osztaly {
/** @var $egyeb_osztaly EgyebOsztaly */
protected $egyeb_osztaly;
}Szerk: typo
-
DNReNTi
őstag
válasz
PumpkinSeed #18059 üzenetére
Nem tudom jól értem e mire gondolsz, de:
class Articles{
protected $articles = array();
private function initArticles() {
//inicializálod a tömböt vmi alapján, pl:
$this->articles = Article::getByGroupID($this->id);
//ez visszatér egy tömbbel a megfelelő Article objektumokkal
}
}Az initArticles() metódust én a getterbe is be szoktam tenni, ha üres, vagy nem inicializált a property akkor futtatom, illetve azért private, mert ha kívülről akarod meghívni elég a gettert hívni, az feltölti ha még nincs. Ha nem túl nagy az objektum fa, vagy biztosan nem rekurzív akkor be lehet tenni konstruktorba is, de ezt én inkább elkerülném.
Remélem erre gondoltál.
-
DNReNTi
őstag
[codeigniter] [hmvc] [routing]
Sziasztok,
Készítenem kell egy tök egyszerű kis specifikus CMS-t. Codeigniter + HMVC extension a backend, angular a frontend. Utóbbi teljesen irreleváns. Lényeg a lényeg, szeretném megvalósítani az alábbit:Ha az URL pl "admin/login", akkor a "modules/admin/login/controllers/Login.php" osztályt (index metódus) akarom meghívni. Lehetséges ez valahogy? Alapesetben ugye az "admin/login" a "modules/admin/controllers/Admin.php" osztály "login" metódusát hívná, de én nem ezt a struktúrát akarom felépíteni, mert így az egész (igaz nem sok) adminisztrációs logikát egyetlen osztályba kellene belezsúfolnom, ami szvsz nem szép.
Thx! -
DNReNTi
őstag
válasz
PumpkinSeed #18027 üzenetére
Velem is az egyetem utáltatta meg a Java-t.
De azon a sérelmen már túltettem magam, így az évek múltával, már egészen szerethető.
-
DNReNTi
őstag
válasz
szupermacs #18024 üzenetére
Szigorúan személyes tapasztalat: nem jellemző. Nem hátrány ha van, de kb senkit nem érdekel, és a fizetést sem befolyásolja. Tőlem még soha senki nem kérte, illetve én sem kértem, ha én ültem az asztal másik oldalán. Egyetlen dolog számít: a szakmai tapasztalat. Arra azért érdemes számolni, hogy bár nagy a kereslet a Java programozókra, pályakezdőként nehéz elhelyezkedni. Ha már van egy valamekkora tudásod, érdemes keresni gyakornoki pozikat, vagy programokat. Nyilván akkor nem az a szempont hogy rádszakadjon az aranyvonat, hanem, hogy legyen releváns tapasztalatod vállalati környezetben ne csak otthon "hobbiprogramozásban". Erre rá kell szánni az időt. Ha így sikerül lenyomni egy évet, akkor már eséllyel lehet menni junior pozíciókra.
-
DNReNTi
őstag
válasz
PumpkinSeed #18020 üzenetére
Kereslet-kínálat. Igaz nem toronymagasan, és ráadásul nem is magyarországi statisztika, de a Java-s programozó a legkeresettebb ha álláskeresésre kerül a sor. Persze nem csak ez a szempont, fizetni is jól fizetnek érte, illetve a tudásbázis is elég nagy az interneten. Cserébe viszont komolyan kell venni az elméleti alapokat, és egészen biztosan nem 2 év egy magabiztos, munkaerőpiacon versenyképes tudás megszerzése. Jelenleg ha időm engedi én is éppen "átképzem" magam, Java+Angular jómunkásemberré, mert itt (Debrecen) erre most kereslet van.
-
DNReNTi
őstag
Plusz felokosítod annyira, hogy ha nagyobb mint x akkor megkeresi az x előtti legutolsó szóközt, vagy mondatvégi írásjelet és ott vágod el, és majd aztán jöhet a "...".
Így azé szebb, meg érdemes a multibyte stringfüggvényeket használni, bár a szóközkeresés kiküszöböli, hogy mondjuk kettévágj egy "ő" betűt.
-
DNReNTi
őstag
válasz
PumpkinSeed #17928 üzenetére
Aww ne, ez nagyon rossz volt.
No offense.
-
DNReNTi
őstag
válasz
supercow #17872 üzenetére
Az ár sajnos tényleg nő, de a betűmérettel vitatkoznék: nagyobb képernyőn a nagyobb felbontás kb ugyanakkora pixelméretet eredményez mint kisebben a kisebb. Na ez lehet így nem érthető, a lényeg, hogy mondjuk a 22"-on 1920x1080, és a 27"-on 2560x1440 pixelmérete nagyjából ugyan az, tehát nem nehezebb olvasni. Mondjuk ez nem változtat azon, hogy 2x annyiba kerül.
-
DNReNTi
őstag
válasz
PumpkinSeed #17869 üzenetére
Ha már témánál vagyunk:
Azért ez a setup már kissé overkill.
-
DNReNTi
őstag
válasz
SwissBread #17704 üzenetére
Szvsz a legjobb ilyenkor ha kitűzöl magad elé valami célt, már úgy értem valami kis hobbi projektet. Annak a megvalósításából fogsz a legtöbbet tanulni. Nem kell világmegváltó dolgokra gondolni, elég mondjuk egy fórum, vagy valami hasonló általános dolog. Azt írtad az angol nem gond. Többet fogsz tanulni egy-egy ilyenből, mint bármelyik könyvből.
-
DNReNTi
őstag
válasz
Peter Kiss #17547 üzenetére
Jogos.
-
DNReNTi
őstag
válasz
PumpkinSeed #17541 üzenetére
Lehet hülyeséget írok, de nem lehet hogy esetleg a virtual host van elkúrva azért hasal el a require?
-
DNReNTi
őstag
válasz
PumpkinSeed #17528 üzenetére
Ha más nem, írj bele egy faék file szintű log-ot, azzal determinálhatod hol dobja le a láncot.
-
DNReNTi
őstag
Halló,
Régen vótam erre.
Egyből bekezdek egy extrém kérdéssel:
Roppant etikusan parse-olunk egy oldalt PHP-val (most a Java/Selenium nem opció sajnos) megvan minden, viszont épp a lényeg egy landing URL nem elérhető a DOM-ból. Úgy oldották meg, hogy a gomb ami átdob a landing page-re az egy form submit-ja, a form pedig tartalmaz egy hidden inputot, benne egy random karaktersorral, ami azonosítja a céloldalt. A form POST-ban küldi el az adatokat, majd a szerveroldal a random karaktersor alapján egyből átirányít a céloldalra. Tehát a céloldal URL egyetlen helyen, az átirányítás header-ben olvasható. Lehetséges e hogy ezt a headert mi PHP-val kiolvassuk?Valószínű, hogy nem mi vagyunk az elsők akik leparse-oljuk őket (de szíp magyar szó), mert egyéb okosságokkal is védekeznek, de azokon már túl vagyok. Ez viszont fejtörő, nem csináltam még ilyet.
-
DNReNTi
őstag
Ez a Lumen tényleg ígéretes kis projektekhez.
Thx.
(#17325) biker
Fuu.(#17320) mobal
Szvsz Laravel (vagy Yii), de ez vallási kérdés is, ráadásul ezt úgy mondom, hogy még nem használtam Symfony-t. -
DNReNTi
őstag
válasz
fordfairlane #17299 üzenetére
Mint tudjuk az ügyfélnek mindig igaza van. Namármost, ha ő azt mondja, hogy az adatbáziskezelés biztonsági okokból, adatbázis nélkül kell megvalósuljon, akkor az úgy is van.
Aztán lehet neki sok sikert kívánni, hogy találjon valakit, aki implementálja.
-
DNReNTi
őstag
válasz
Joci93 #17296 üzenetére
Kíváncsi lennék mivel magyarázza meg, hogy ott lehet biztonsági rés. Arra is kíváncsi lennék mégis mit javasol akkor helyette, ami biztonságosabb. Abban meg egészen biztos vagyok, hogy biztonsági rés sokkal hamarabb keletkezik kliens oldalon, vagy akár szerver oldalon - lásd nem régiben a YouTube fatális béna hibája. Na mindegy, szerintem ne foglalkozz vele, de asszem ezt már a többiek is javasolták.
-
DNReNTi
őstag
válasz
fordfairlane #17294 üzenetére
Jogos, erre nem gondoltam. De legalább már van (lesz).
-
DNReNTi
őstag
válasz
Sk8erPeter #17292 üzenetére
Ez is gyönyörű:
function order_func($a, $b) {
return ($a->$x <=> $b->x) ?: ($a->y <=> $b->y) ?: ($a->foo <=> $b->foo);
}Viszont a típusdeklaráció várós! Sőt díjaznám ha kötelező lenne, nem optional.
-
DNReNTi
őstag
válasz
Heimdallr75 #17273 üzenetére
Sokaknak sajnos az adatbázis = PhpMyAdmin.
Az is lehet csak egy csavaros megfogalmazása annak, nem e lehet kiváltani a MyAdmint. Ha így van, akkor: má' hogyne lehetne. Sőt. Ajánlott. Workbench például. -
DNReNTi
őstag
válasz
Sk8erPeter #17253 üzenetére
Jaja. Epik. A Chrome pl mindig kereste 2x, ezért volt a konstans 3 bejegyzés, a Firefox ebből a szempontból okosabbnak tűnt, az beletörődött az első alkalom után, hogy nincs. Na de nézzük a jó oldalát, láttam egy böngészőfüggő szerver oldali hibát.
Tanulság: tesztnél körültekintően kell kiszórni a "nem szükséges" kottát.
-
DNReNTi
őstag
Igen, mindezt tudom. És közben meg is van a megoldás. Gyakorlatilag egész idő alatt - nincs erre szebb szó, bocsánat - saját magamat szopattam. Már a kezdettől fogva. Van egy Router nevű osztályom, gondolom a szerepét nem kell magyarázni. Ez az ami az URL paraméterek alapján a megfelelő oldalakat építi fel, illetve nem megfelelő kérés esetén hiba oldalra dob. Pl: egy nem létező favicon esetén is. No én voltam annyira ügyes, hogy ezt kikommenteltem a teszt miatt, ráadásul az index-be írtam magát a tesztet, mer már annyira bepukkantam.
Tehát a htaccess átirányított mindent az indexre ahogy addig is, de nem volt ami feldolgozza. Magyarul kezdettől fogva minden jól működött, egyszerűen csak láma voltam.
-
DNReNTi
őstag
Ahan, így érthető, köszi!
Akkor utánajárok, hogy tudom megakadályozni ha fizikailag nem létező fájlra hivatkozik valaki, akkor 404 legyen. Jó irány? Vagy teljesen rossz felé megyek?"Teória a kétszeres favicon betöltésre: mivel elsőre 200-as kódot kap, de a tartalom nem érvényes kép, így újra megpróbálja."
A teóriád valszeg helyes, ha a htaccess 404-et dob a favicon-ra, akkor nem próbálja meg újra. -
DNReNTi
őstag
"Gondolom egyrételmű, hogy maga a probléma, hogy szar a htaccess-ed."
Igen, arra már rájöttem korábban: "Kiderült: hibás volt a htaccess-em".Egy másik szabály amivel szintén jó:
RewriteCond $1 !favicon.ico$"ha a kliens lekérdezi a favicont, az miért eredményezi egy php program futását"
Na igen. Csak arra tudok gondolni, hogy mivel maga a fájl nem létezik így a RewriteCond %{REQUEST_FILENAME} !-f szabály nem vonatkozik rá (hiszen az csak a létező fájlokra igaz, ha nem tévedek). Az ikon request valamiért 200-as HTTP statust kap. Azaz annak ellenére, hogy valójában nincs, így gondolom mivel a fentebb írt szabályon már túl van, és a szerver OK statust ad neki, így a htaccess átirányítja. Ilyet nem mostanában szívtam.Tehát a valódi kérdés inkább: miért ad a szerver 200-as statust egy nem látező fájlra?
Szerk:
A szerkesztett írás alapján kipróbáltam egy nem létező fájlra hivatkozva: ugyan úgy megszívat. -
DNReNTi
őstag
válasz
DNReNTi #17241 üzenetére
No hát, így több óra szerencsétlenkedés után, ezzel a kiegészítéssel most jónak látszik:
RedirectMatch 403 favicon.icoNagyon rohadék, nem is értem.
1: miért keresi a favicon-t ha én nem mondom?
2: ha már keresi és nem találja, mér' 200-as statust ad rá?A legegyszerűbb mondjuk valszeg az, ha van favicon...
-
DNReNTi
őstag
válasz
Sk8erPeter #17240 üzenetére
A jelenlegi .htaccess:
<IfModule mod_rewrite.c>
Options +FollowSymlinks -Indexes
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteBase /
RewriteRule ^([^?]*)$ index.php?path=$1 [NC,L,QSA]
</IfModule>Ez a célnak tökéletes lenne. De ezzel megy a 3 request. Egyszerűen nem értem az egészet. Ha egy tök más php fájlt nyitok meg, vagy pl a képet amit az előbb feltoltam ez az access log eredménye:
127.0.0.1 - - [20/Mar/2015:20:33:13 +0100] "GET /code.jpg HTTP/1.1" 304 -
127.0.0.1 - - [20/Mar/2015:20:33:13 +0100] "GET /favicon.ico HTTP/1.1" 200 2157
127.0.0.1 - - [20/Mar/2015:20:33:13 +0100] "GET /favicon.ico HTTP/1.1" 200 2161Honnan jön az a favicon.ico request? Meg ha már jön, miért fut le az index.php? Mert lefut ez 100%, abban van a tesztlekérdezés. Hozzáteszem ha az index.php-t magát nyitom meg, akkor is lefut újra kétszer.
Már az agyvérzés kerülget.
Persze az "oldalon" sehol nincs favicon, plain php fájlokról van szó.
SO-n is találtam a témában kérdéseket, de még nem találtam megoldást, az már megvan, hogy a rohadék böngészők keresik ha nincs is. Szétmegyek.
-
DNReNTi
őstag
válasz
fordfairlane #17238 üzenetére
Köszi a tanácsot, megnéztem a naplót tisztán látszik, hogy egy kérést 2 másik követ 1 mp-el később. Erre egyébként a további teszteléssel rájöttem, mert insert után ki is írattam az egész tábla tartalmát, és úgy tűnt valóban csak egy insert van. Ám ha megnéztem az adatbázist ott már három volt. Ha frissítettem az oldalt, megjelent a 2 új. Tehát azt sikerült determinálni, hogy valamiért, valahogyan a háttérben még kétszer leszalad a szkript. Kiderült: hibás volt a htaccess-em. Illetve működött csak nem jól. Kijavítottam. Most minden jó. Szívesen leírnám most amit gondolok, de szerintem örökké kitiltanának az oldalról.
Viszont vannak dolgok amiket nem tudok megmagyarázni:
1. ez miért böngészőfüggő?
2. a htaccess miért generált két plusz lefutást? (miért nem csak egyet?)
3. miért működött másik táblával?Ezek már csak költői kérdések. Agyfasz az egész, elkúrtam rá a fél napomat, örülök, hogy végre jó. Bontok is egy sört.
-
DNReNTi
őstag
Sziasztok,
Hardcore (vagy épp noob) kérdés következik:
Egy hiba (több sor kerül be az adatbázisba insert-kor, egy helyett) miatt írtam egy halál egyszerű tesztet, mert már sehogy nem tudtam rájönni mi a baj. A teszt lényege: oldalbetöltéskor bever egy sort egy adatbázis táblába. No de ahogy az eredeti hibánál itt sem egy sort hanem random 1-3 sor kerül be.A teszt kód maximálisan leegyszerűsítve:
try {
$DBC = new PDO(
'mysql:host=localhost;dbname=local_db',
'root',
'root',
array(
PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES UTF8;',
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
)
);
$SQLquery = "INSERT INTO temp(cont) VALUE(:content);";
$SQLstmt = $DBC->prepare($SQLquery);
$SQLparams = array(
'content' => 'content'
);
$SQLstmt->execute($SQLparams);
$DBC = null;
} catch(PDOException $e) {
die($e);
}És akkor jönnek a csavaros dolgok:
A lekérdezés perfekt működik mysql terminálban is, workbench-ben is.
A $SQLstmt->rowCount() mindig pontosan : 1.
Ha megnézem a táblát 3 új sor van benne.
Megnézem a MySQL system status-t, az insert-ek száma hárommal nő.
Olyan mintha többször nyitnám meg az oldalt, ekkor gondoltam kipróbálom a többi böngészővel is, és most kapaszkodj: Különböző böngészőkben (!!!) teljesen másképp viselkedik a szerver oldali kód.
Chrome: mindig 3 sor megy be.
FF: első alkalommal 3, aztán 1-1 sor megy be frissítésenként.
Safari, Opera, IE: első alkalommal 3, aztán random 1-3 sor megy be frissítésenként.Hab a tortán, csináltam még egy táblát, azzal meg jó.
Valaki pls explain, mert én hamarosan széjjelverem a laptopom.
Apache 2.4.9
MySQL 5.6.17
PHP 5.5.12 -
DNReNTi
őstag
válasz
fordfairlane #17177 üzenetére
Én most a konkrétan a -> operátorra gondoltam.
Ettől még teljesen jogos. Mostanában csak sz*patom magam a PHP topikban.
-
DNReNTi
őstag
Most lehet hülyeséget írok, és ki sem próbáltam, sőt ráadásul végig se mentem a kottán, de sztem az operátorod rossz, illetve az egyből szemet szúrt.
Mindenhol így szerepel:
$m - > akarmi...
Na de (szerintem) helyesen:
$m -> akarmi
Tehát nincs szóköz.A kis apróságra pedig:
$m -> Subject = 'A tárgy az lesz amit itt beállítasz';
Lehet az egy változó is, beírt szöveg is (mint ahogy én is beírtam), vagy konkatenálhatsz is statikus szöveget változóval. Pl:
$m -> Subject = 'Kapcsolatfelvétel: ' . $felado_neve;Szerk: typo
-
DNReNTi
őstag
válasz
Sk8erPeter #17133 üzenetére
Én meg a php.ini módosításáról beszéltem, ha kicsit visszaolvasol.
Oh. Jogos. -
DNReNTi
őstag
Megpróbálom leegyszerűsíteni neked, amit Péter írt.
1. Különüljön el egymástól az űrlap (már ami megjelenik), és a fájl ami az onnan érkezett adatokat kezeli. MVC level egy. Konkrét példaként:
form_view.php - ebben a fájlban van amit a felhasználó lát, a HTML form.
form_controller.php - ebben a fájlban kezeled majd a felvitt adatokat.A form.php-d az alábbi módon fog adatokat küldeni a form_controller.php-nek:
<form method="post" action="form_controller.php"></form>2. MINDIG, de tényleg mindig, le KELL ellenőrizni a kapott adatokat. Hiába a HTML required attribútum, hiába a JS, ezek mind megkerülhetőek. A szerver oldal nem.
Példa: Az email küldő űrlapodon kötelező megadni nevet, e-mail címet, és persze az üzenetet. Az adatok meglétét (és megfelelőségét) a form_controller.php-ban le kell csekkolni, különben nem kívánt, nem várt hibákra léphetsz.3. Kijavítanám Brian-t a hibajelzésekkel kapcsolatban:
Helyesen: ini_set('display_errors', '1');"Vagy hol az a határ, "amit még jó ha tud" az ember PHP-s alapskillként, ha Frontendbe képzeli el a jövőjét? És mi az ami már általánosságban a Backendes kollégákra vár?"
Szerintem továbbra sem lehet ennyire szigorúan határt húzni a kettő közzé. Ez kéz a kézben van, nincs egyik a másik nélkül. -
DNReNTi
őstag
XAMPP-ot sosem használtam, még csak nem is láttam, de ötletek:
Nem e felejtetted az index.php mellett az index.html-t? Apache konfigtól függően, lehet a html kiterjesztés az elsődleges. Készíts egy teljesen különálló php fájlt, pl : test.php, abba írd bele a helloworld példát. A print(); helyett használj echo();-t.Tehát:
test.php:
<?php
echo 'Hello World!';
?>Ha ez sem jól működik, tuti a szerverrel nem oké valami. Így persze a böngészőben a fájlra hivatkozz, teszem azt: localhost/project/test.php.
-
DNReNTi
őstag
Egy kis kieg:
Fake SMTP-nek én a PaperCut-ot használom, korábban már linkeltem a topikban, amilyen egyszerű annyira király. Pontosan annyit tud amennyire az embernek szüksége van, alap esetben konfigurálni sem szükséges.Nem elég ha pl. a honlapom gyökérkönyvtárába kicsomagolom a githubról letöltött phpmailer.zipet, majd pl. az index.html oldalának a legtetejére behúzom az PHPMailer example fájlt php tagek közé, és ott szépen módosítgatom? Vagy erre mindenképp hozzak létre egy külön php fájlt?
Először is: amíg az index.html, az HTML és nem PHP - tehát index.php - addig teljesen okafogyott bármit belehúzni. Magyarul, most, hogy webszervert használsz és PHP-t tanulsz, itt az ideje elfelejteni a html kiterjesztést.
Másodszor: A PHPMailernek van saját autoloader-e.
Így használd:
require_once('/phpmailer_eleresi_utja/PHPMailerAutoload.php');
Ezt követően már használhatod az osztályt. Pl:
$mailer = new PHPMailer();
Így a $mailer egy PHPMailer objektum lesz (vagy ha úgy tetszik egy példány). Hogy ezzel a továbbiakban mit kezdj, abban segít a saját doksija -
DNReNTi
őstag
válasz
PumpkinSeed #17114 üzenetére
Hát épp az ilyen feladatok miatt lett kitalálva.
Tipp: érdemes a CRON-oknak is készíteni egy log-ot, hogy rendben lefutottak e, és ha igen milyen eredménnyel, ha nem akkor milyen hibával. Megkönnyíti az életet. -
DNReNTi
őstag
válasz
PumpkinSeed #17112 üzenetére
Ha a szolgáltatónál van lehetőség CRON-t beállítani akkor persze, hogy menni fog. Időszakos feladatokhoz, például heti rendszerességgel egy tábla truncate, tökéletes megoldás.
-
DNReNTi
őstag
válasz
Sk8erPeter #17109 üzenetére
Igen-igen. Én kicsit leegyszerűsítettem a menetet, de végül is (most már) ugyanarról beszélünk, és egy log használatával már az oldalbetöltés legelején le lehetne ellenőrizni, hogy adott felhasználó, az elmúlt X időben, látogatta e az adott oldalt. Ha nem, akkor jár az Y mennyiségű pont, ami ugye egyből megjelenik a profiljában, tehát a vállveregetés sem akadály.
-
DNReNTi
őstag
válasz
Sk8erPeter #17107 üzenetére
Nem pont erre gondoltam, hanem a pontok lekérdezésre, ami ugye a felhasználók táblában egy mezőben kényelmesen elfér, így még join-ra sincs szükség. A jóváírásra nem is gondoltam, de így hirtelen arra hogy melyik felhasználó mikor melyik oldalon járt, bevezetnék egy log-ot. Az alapján eldönthető lenne kinek mikor jár pont, persze ez így már valóban egy másik lekérdezés.
-
DNReNTi
őstag
válasz
honda 1993 #17094 üzenetére
""Max pár óra" igen annak aki ért a php-hoz."
Nem. Összedobni nulla tudással. Idézem magam: "maximum néhány óra összedobni pár doksi elolvasásával."Továbbá, csak a tisztánlátás végett. Had idézzem magam ismét, illetve az eredeti posztot:
"Már az is előrelépés lenne, ha az oldalt egy PHP fájl rakná (include-ozná) össze, és a linkben megadott paraméternek megfelelő tartalmat húzná be, teszem azt egy fájlból. Ez persze sehol sincs még a portálmotorhoz, nevezzük inkább szakócának (pattintott kő), az orvosi robotok korában."
Kulcs: Ez még sehol nincs egy portálmotorhoz. DE előrelépés!Ahhoz hogy ezt meg tudd csinálni az alábbiakra van szükség:
- PHP minimális alapok.
- include();
- paraméterátadás ($_GET).
- minimális hibakezelés.Na ezt összeguglizni max pár óra. )
Hajrá hajrá! -
DNReNTi
őstag
válasz
honda 1993 #17092 üzenetére
Bakker. Kicsit próbáld má' meg megerőltetni magad.
Amit én leírtam példaképp az igazán nem nagy kaland, maximum néhány óra (!!! óriási túlzással, lvl80-as lustasággal számolva) összedobni pár doksi elolvasásával. Gyakorlatilag elegendő egy minimál PHP tudás, amit én írtam még adatbázist sem igényel.
"Valaki esetleg elvállalná?"
Teszem azt valaki elvállalja, te meg kifizeted, borítékolható mondjuk, hogy zsebbe kell nyúlni. Szóval, kész a portálmotor. Egyrészt: Mit kezdesz vele? Mert, hogy azt se fogod tudni az most jön vagy megy az 100%. Másrészt: Ha nem akarsz a megírásával kínlódni, akkor megint ott tartunk amiben a másik topikban már volt szó: Ingyenes tartalomkezelő rendszer. -
DNReNTi
őstag
válasz
PumpkinSeed #17090 üzenetére
Igazából még csak nem is plusz lekérdezés, ha ügyesen csinálod, akkor az egész felhasználó objektumodat annak minden tulajdonságával létre tudod hozni egyetlen lekérdezéssel. Kb nulla plusz terhelés.
Új hozzászólás Aktív témák
Hirdetés
- Milyen házat vegyek?
- PROHARDVER! feedback: bugok, problémák, ötletek
- DJI topic
- Az áremelések és a GTA VI késése miatt nem költekeznek a játékosok?
- Eredeti játékok OFF topik
- OLED monitor topik
- PlayStation 3
- Nvidia GPU-k jövője - amit tudni vélünk
- Bejelentette az Arc A sorozat nyugdíjazását az Intel
- Goddess of Victory:Nikke
- További aktív témák...
- Samsung Galaxy S24 Ultra 5G 256GB, Kártyafüggetlen, 1 Év Garanciával
- Eladó Konfig Ryzen 7 7700 32GB DDR5 1TB SSD RTX5070 12GB!
- Precision 5550 15.6" 4K+ IPS érintő i7-10750H Quadro T1000 16GB 512GB NVMe ujjlolv IR kam gar
- Amazon Kindle (10. gen) eBook olvasó
- Latitude 5550 15.6" FHD IPS Ultra 5 135U 16GB 512GB NVMe magyar vbill ujjolv IR kam gar
- BESZÁMÍTÁS! SAPPHIRE VEGA 64 8GB HBM2 videokártya garanciával hibátlan működéssel
- ÚJ Apple Macbook Air 15,3 M4 10C CPU/10C GPU/16GB/256GB - Ezüst -(2025) - 3 év gari - MAGYAR
- Targus Universal USB 3.0 DV1K-2K Compact docking station (DisplayLink)
- Samsung Galaxy S21 Ultra , 12GB , 128 GB , Kártyafüggetlen
- PlayStation Plus Premium előfizetések
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged