Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
válasz Des1gnR #17386 üzenetére
Most úgy érdemes nézelődnöd, hogy a webfejlesztő panel hálózati fülén bekapcsolod, hogy őrizze meg a korábbi requesteket is, így újratöltődésnél nem fog mindig "elölről" kezdődni a requestek felsorolása, hanem megőrzi a lap-újratöltődés előttieket is, így láthatod, hogy az űrlap elküldésekor milyen adatok utaztak ide-oda.
Pl. Chrome vagy Opera esetén a Network fülön a "Preserve log" checkboxot most érdemes bepipálni, hogy lásd az eredményeket, pl. látszik, hogy a Keresés gomb megnyomása után először a
http://ujmenetrend.cdata.hu/uj_menetrend/volan/ajax_response_gen.php
címre megy egy request, megnézheted, itt milyen adat utazik, majd a talalatok.php-ra kattintva is meg tudod nézni a küldött/fogadott adatokat:Ez sokat segíthet a nyomozásban.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Des1gnR #17388 üzenetére
Jé, csak nem mégis van valami API-szerűség a Volánnál? Magyar állami szervezetnél ez egészen meglepő.
Azt sikerült leszűkíteni, hogy konkrétan milyen kulcsokra van szükség ahhoz, hogy a dolog működjön? Nekem nem volt kedvem próbálkozni, csak gyorsan indítottam egy Postmant, a honnan, hova, honnan_settlement_id, honnan_eovx, honnan_eovy és ennek hova_* változataival simán nem működik, üres objektum a válasz a JSON-változatnál. A Postmanhez telepített Postman Interceptor pedig cookie-kat is beállít, szóval annak hiánya elvileg nem para, de összesen az egésszel töltöttem kb. 3 percet, szóval annyiból nem derült ki, mi a hiány.
Felraktam inkább ide a képedet (szétvágva kettőbe), mert az ilyen külső képmegosztók kényükre-kedvükre egy idő után simán törlik a képeket (pl. ha egy ideje nem nézték):
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz MineFox54 #17424 üzenetére
Ezt elkerülheted egy normális fejlesztőkörnyezet használatával - de ilyet akár egy szintaktika-kiemelős szövegszerkesztő is egyértelműen mutat, mint pl. a Notepad++ -, meg azzal, hogy bekapcsolod a hibajelzést fejlesztés idejéig... (pl. ezért parse errort kellett volna, hogy kapj fehér képernyő helyett, a fehér képernyő fejlesztés idején ugyebár nem túl beszédes)
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz cidalain #17428 üzenetére
A forráskód csak akkor érdekes, ha te magad akarod buildelni a PHP-t, megkapva a szükséges futtatható állományokat és a többi szükséges fájlt. Nyilván nem akarsz ezzel szarakodni, ez esetben meg ott van a letölthető zip, abban van egy install.txt, van egy manual installation része, az jó részletesen leírja a teendőket. Tulajdonképpen "csak" a meglévő webszerveredhez kell igazítani az itt kibontott cuccot.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz cidalain #17430 üzenetére
"+1 kérdés: mit jelent az hogy "thread safe" meg "non thread safe" verzió?"
Guglizás megvolt már?
http://php.net/manual/en/faq.obtaining.php#faq.obtaining.threadsafety
"What does thread safety mean when downloading PHP?
Thread Safety means that binary can work in a multithreaded webserver context, such as Apache 2 on Windows. Thread Safety works by creating a local storage copy in each thread, so that the data won't collide with another thread.So what do I choose? If you choose to run PHP as a CGI binary, then you won't need thread safety, because the binary is invoked at each request. For multithreaded webservers, such as IIS5 and IIS6, you should use the threaded version of PHP."
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz creation #17433 üzenetére
http://prohardver.hu/tema/programozas_forum/hsz_8649-8649.html
Végül is itt is folytathatjuk.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz creation #17444 üzenetére
Itt már írtam neked, de nem találtad fontosnak a válaszadást... (Lehet, hogy más reakciójára vársz, de akkor is illene legalább böffenteni valamit válaszként. ) Akkor hogyan haladjunk tovább? Le kéne szűkíteni a potenciális problémákat, tudni kéne, nézegettél-e naplókat, a szerver beállításainak változtatgatásaival próbálkoztál-e, vagy csak default módban üzemel, mivel próbálkoztál a probléma megoldásának érdekében, stb., de persze nekem teljesen mindegy, nem nekem kell.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz creation #17457 üzenetére
Ezek szerint továbbra sem sikerült kideríteni, mi a frász köze van a használt kliensnek ahhoz, hogy szerveroldalon nem működik az autentikálás? Pedig engem érdekelt volna, brühüh.
A levelezős problémára annyi a megoldás, hogy valami normális library-t használsz hozzá, mint például a Swift Mailer vagy a PHPMailer, és nem szenvedsz azzal a fostos beépített mail() függvénnyel önmagában. Tégy jót az emberiséggel, és ne próbáld vérrel és verítékkel megoldani azt a problémát, amit más már megtett helyetted.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz creation #17459 üzenetére
"Sajnos nem jöttünk rá mi lehet az ok. Ráment két napunk, viszont nincs ilyenre idő"
A Programozás topicban nem véletlenül mondtam már a legelején, hogy DEBUGGOLJATOK egy normális fejlesztőkörnyezet bevetésével. Ne csak próbálkozzatok, szenvedjetek, toporogjatok egy helyben, hanem vizsgáljátok meg normálisan az ügyet, a klienstől a szerver felé utazó adatokat, azokat a körülményeket, amiktől a szerveroldalon elvérzik az autentikáció. De úgy tűnt, erre nem vagy nyitott, meg még azt sem mondtad meg sokszori kérdéseimre sem, hogy egész pontosan hol is vérzik el a dolog, plusz ugye normális hibakezelés sem volt a kódodban.(#17461) creation:
"Valóban nem, de legalább működik "
A Swift Mailer is működik, nem tudom, miért ne működne. Meg hogy honnan van egyáltalán összehasonlítási alapod, ha egyiket sem használtad még soha.(#17460) fordfairlane:
Lehet, szerencsére nem nézegetem egy ideje, direkt raktam előre a Swift Mailert.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz fordfairlane #17465 üzenetére
Atyaisten, csak most néztem bele én is a PHPMailer kódjába, ez tényleg brutális, tényleg egy gigantikus osztály, semmi tisztességesen szétválasztott kód. A SwiftMailer Swift_Message osztálya pl. picit rövidebb, és ez csak osztály a sok közül, itt legalább Dependency Injection van.
(#17480) don_peter:
"Magyar Angol keverék a jó "
Ez viccnek is rossz. Főleg, hogy ha már "magyar" vagy "angol", akkor kis kezdőbetűvel írjuk. (De a kód legyen angol, a programozás nyelve angol, akár tetszik, akár nem. )[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Igazából a feladat egyszerű, mint a lepkefing, pár perc alatt megoldható.
Végigmész az adott könyvtár fájljain (az alapján, amit írtál, feltételezem, hogy egy helyre vannak ömlesztve, nem kell rekurzíve bejárni a könyvtárakat), reguláris kifejezéssel ellenőrzöd, hogy illeszkedik-e a fájlnév az általad megadott mintára, ha igen, akkor space mentén "szétrobbantod" a stringet, majd ebből kiszeded. Legalábbis ez egy nagyon gyorsan bepötyöghető megoldás. Szépségével nem foglalkoztam a kódnak, ez működik:$filename_pattern = '/^[a-z]+ \d+ \S+\.asd\.txt$/';
$dir = '.';
$filenames = scandir($dir);
foreach($filenames as $filename) {
if (!is_dir("$dir/$filename")) {
if(preg_match($filename_pattern, $filename)) {
$filename_pieces_by_space = explode(" ", $filename);
$measurement_location = $filename_pieces_by_space[0];
$measurement_id = $filename_pieces_by_space[1];
echo $measurement_id, ': ', $measurement_location . PHP_EOL;
}
}
}A reguláris kifejezés jelentése: a string eleje és vége között a következők vannak: bármilyen a és z közötti karakter egynél többször, szóköz, bármilyen szám egynél többször, szóköz, bármilyen nem whitespace karakter egynél többször, majd pont, "asd", pont, txt.
Itt az explode eredményeként a harmadik elem a tömbben ilyen lesz, mint a "90n00004.asd.txt", ha ebből további infó kell, akkor nyilván pontok mentén kell szétrobbantani.(#17485) biker:
Hát ennyi infóból ember legyen a talpán, aki megmondja, mi a baj.
Azért remélem, azóta nem vágtál eret.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz MineFox54 #17497 üzenetére
Ennek mi köze a PHP-hez? Legalábbis az itt írt további hsz.-ed alapján bőven elég beágyazni az útvonalat, aztán annyi.
Ha viszont valahogy dinamikusan szeretnéd megtervezni az útvonalat, nem egy konkrét, rögzített útvonalat akarsz megjeleníteni, akkor tedd fel értelmesebben a kérdésedet.(#17495) biker:
És a Macesek nagy sztárolt IDE-jében (már ha az, nem csak egy szerkesztő, fogalmam sincs a Mac-cuccokról, nem is nagyon izgatnak) nem lehet PHP-kódot debuggolni?[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz MineFox54 #17499 üzenetére
Ez remek, még mindig fogalmunk nincs, mit akarsz. Egy iframe beágyazásához önmagában semmilyen PHP-kód nem kell, az színtiszta HTML, hogy egy előre rögzített kódot bedobsz.
Kattints alul a fogaskerék ikonra, ott lesz a beágyazási lehetőség - "Térkép megosztása vagy beágyazása":[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz cidalain #17502 üzenetére
Szerk.:
(#17499) MineFox54:
Most látom a szerkesztés után írott szövegedet."én abban kézzel be tudom állítani az útvonalat"
Úgy érted, szeretnél egy űrlapot, azon szeretnél két mezőt kiindulási ponthoz és célponthoz, és úgy szeretnéd működtetni az egészet? Mert akkor módosítja a dolgot, ez esetben Google Maps API-ra lehet szükséged, de simán JavaScript elég hozzá, nem kell PHP.
Szóval ha jól értem, kb. azt akarod, hogy a Google Maps weboldalán (https://www.google.hu/maps) látható működést átültesd a sajátodra.A hivatalos példák hasznodra lehetnek:
https://developers.google.com/maps/documentation/javascript/examples/Szükséges lesz viszont JavaScript-tudás.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
Ja, lehet, hogy az Xcode-ra, nem vágom. (Sorry, nem szimpatizálok az Apple-cuccok agyatlanul túlárazott jellegével, meg a hozzá kapcsolódó sznob kultúrával. )
A PhpStorm szerintem is jó, meg úgy általában a JetBrains-cuccok (pl. Python-fejlesztéshez a PyCharm is nagyon bejött, korábban az Eclipse PyDev pluginjét használtam, de a PyCharmban fejlesztés sokkal jobbnak és pörgősebbnek bizonyult; Java-fejlesztéshez az IntelliJ IDEA-val még nincs érdemi tapasztalatom, de azt is nagyon dicsérik).
Sk8erPeter
-
Sk8erPeter
nagyúr
Tehát azért szenvedsz, azért nem tudsz debuggolni (lévén, hogy csak egy szövegszerkesztőt használsz (amiért amúgy fizettél), nem egy IDE-t), és azért nem tudsz rengeteg egyéb műveletet elvégezni, olyanokat, amiket egy IDE nyújt (tehát ha feltételezünk egy normális fejlesztői környezetet), hogy ne terhelje a gépedet? Nem tom, nekem ezek az érvek viccesek, amikor valaki ezen spórol, miközben lóvéért fejleszt, és a saját munkaideje saját magának kerül pénzbe (pl. ha egyéni vállalkozó vagy). Csak mert ugye léteznek ugye olyan alternatívák is, amik egy fillérbe sem kerülnek, és integrált fejlesztőkörnyezetek, mint például az Eclipse vagy a NetBeans - igen, ezek nem kíméletesek az erőforrásokkal, de működnek, gyorsítják a fejlesztést, ingyenesek, tudsz bennük PHP-kódot debuggolni (ezzel a ráfordítandó munkaóráid számát adott esetben jelentősen csökkentve = profit).
(#17511) fordfairlane:
Ebben tökéletesen igazad van, de általában ezek a műveletek kellőképpen felhasználóbarát módon vannak megoldva egy IDE-ben, nem beszélve arról, hogy normális fejlesztőkörnyezetben az ember úgyis IDE-t használ. Persze akár más kliens is lehet, ami a műveletet felhasználóbaráttá teszi. Itt említ lehetőségeket.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz fordfairlane #17513 üzenetére
Hát ez elég furcsa, hogy a munkahelyen nem IDE-ket használtok, hanem szövegszerkesztőket.
"Két kollégám használ Netbeanst, és ők sokat szidják a lassúsága miatt"
A sok fájlművelet miatt komoly szűk keresztmetszet tud lenni a HDD - ahogy az Eclipse-nél is. Persze sok munkahelyen nem adnak sajnos SSD-ket a fejlesztők "alá". Meg persze számít szerintem a JVM miatti relatív lassúság is. Ettől függetlenül nem kell mai szemmel komoly erőgépnek tekinthető konfiguráció - de mondom, tényleg nem bánik kíméletesen az erőforrásokkal, sima szövegszerkesztőnél viszont mindenképp SOKKAL hatékonyabb fejlesztést tesz lehetővé - ez mondjuk nem is kérdés, ezért furcsállom, hogy nem IDE-ket használtok egy munkahelyen, ahol kifejezetten a fejlesztés van a középpontban. (Ha nem bírná a céges gép, hogy IDE-t használok, komolyan, saját laptopomon nyomnám a fejlesztést bent is (pedig az én laptopom sem mondható egy erőgépnek, de néha tapasztalt röccenésen kívül bírja az iramot), hacsak céges policy nincs, ami ezt nem engedi.)És nem hiányzik nektek a tisztességes refaktorálási lehetőség, a runtime kódanalizálás, gyorssegítség a hibák kijavítására, számtalan kódírást gyorsító feature, az annotált kommentek alapján történő dokumentáció-tippek és igazából minden olyan, amit egy IDE nyújt, de egy szövegszerkesztő nem? Hát hogyan fordulhat az elő? Kódírást gyorsító szolgáltatások nyilván sok sima szövegszerkesztőben is léteznek, de ezek legtöbbször nem gondolkodnak normálisan "projektszinten", vagy csak részleges támogatást nyújtanak (pl. valamilyen módon van lehetőség fájlok logikai összeszervezésére, egyfajta projektnézetre, de az alapján sokszor csak részleges kódkiegészítési lehetőségek vannak, valahol korlátokba lehet ütközni, legalábbis én ezt tapasztaltam, pedig sokat kipróbáltam).
Igazából annyi plusz feature van egy IDE-ben egy szövegszerkesztőhöz képest, hogy nem is érdemes végigmenni rajta... de hogy nélküle miért jó fejleszteni, azt nem értem.Konkrétan egyébként milyen szövegszerkesztőket használtok?
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
"beleszocializálódtam a Visual Studioóba, más már azután "szar". No offense "
Na ezzel az állítással nem tudok vitatkozni. Gyorsan meg lehet szokni a jót, a gyorsat. Egyébként az Eclipse és NetBeans egyáltalán nem tökéletesek, sőt, például a Visual Studio kategóriáján belül sokkal jobb és sokkal gyorsabb, de előbbiek előnye, hogy ingyenesek (persze nyilván E.-ben és NB.-ben C#-támogatás nincs, Visual Studióban meg nincs Java-támogatás, de érted ).(#17517) biker:
Hát ez bizony ilyen ("szörnyű"), hogy meg kell szokni, hogy másik szoftverben nagy eséllyel máshol vannak a dóóógok...
Amúgy nem akarlak én meggyőzni semmiről, de ebben a topicban már nem is tudom, hányszor szenvedtél azzal, hogy próbálsz echózni, loggolni, kísérletezgetni, másképpen futtatni, átmenetileg sorokat kikommentezni, ahelyett, hogy debuggolnál. Tök mindegy, mit használsz a célra, de nem árt megtanulnod az előnyeit, egyszer melós lehet, de aztán rengeteg időt spórolhatsz vele.Sk8erPeter
-
Sk8erPeter
nagyúr
Hoppá, tényleg, teljesen igazad van, a Visual Studio Community tök ingyenes, tegnap megfeledkeztem róla, ráadásul a fejlesztők többségének elegendő is ez az ingyenes változat (nem is csak alapvető dolgokra!).
(#17523) mobal:
PHP után főleg megváltás.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz PumpkinSeed #17537 üzenetére
Mi van a /php/controller.php fájl 19. sorában? Ott csatlakozol az adatbázishoz, vagy mi történik?
Fel tudsz amúgy dobni egy phpinfo-t az oldaladra?
"Amúgy miért működik a JS rendellenesen azért mert ez nem jó?"
Be sem töltődik a teljes dokumentum, 500 Internal Server Error van 1,1 perc után (durva timeout), az okozhat ilyet, például ha a dokumentum "ready" eventjének elsülése hatására futna le a JavaScript-kódod.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz cidalain #17568 üzenetére
Pedig ebben semmi misztikus nincs, többek közt az Accept-Language fejlécből megállapíthatóak a böngésző nyelvi beállításai - a böngésző ugyanis elküldi a szervernek, hogy a felhasználó - a beállítások szerint - melyik nyelvet preferálja, illetve mely további nyelveket kívánja elfogadni a kliens (ami a böngésző):
http://www.w3.org/International/questions/qa-accept-lang-localesAztán persze a szerver azt kezd ezzel az információval, amit akar - például ignorálhatja, vagy épp ennek felhasználásával állapítja meg az épp megjelenítendő nyelvet.
PHP esetén az Accept-Language fejléchez a $_SERVER['HTTP_ACCEPT_LANGUAGE'] változón keresztül férsz hozzá.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz #68216320 #17587 üzenetére
Hát igen, az az egyik példa phpMyAdmin-alternatívának, úgy tudom, a phpMyAdmin egyáltalán nem működik MySQLi-kiterjesztés nélkül (pl. PDO-val).
Igazából ha korábban MySQLi-t használtál, akkor nem szabad, hogy nagy érvágás legyen átállni PDO-ra. A PDO-nak más szintaktikája van, szerintem egy fokkal könnyebben használható (számomra legalábbis jobban "kézreáll" az API), a prepared statementeknél használhatóak nevesített placeholderek (érdemes használnod, nem pedig a MySQLi-ből megszokott kérdőjeleket, persze ezek is működnek, sőt, van olyan eset, amikor pont erre van szükség (pl. amikor dinamikusan állít össze az ember egy előkészített utasítást)), és egyéb előnyei is vannak, valószínűleg nem lesz túl sok problémád az átállással.
Szoktam linkelgetni a topicban Tele von Zsinór kolléga PDO-val kapcsolatos cikkét, fusd át, mert igazából minden lényeges dolog benne van az elinduláshoz (pl. ami fontos, hogy a kapcsolat inicializálásakor a karakterkódolást kapásból UTF-8-ra állítja, ÉS hiba esetén exceptionök dobására utasítja a PDO-t).[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
"http://x-profit.hu ezt ismeri valaki? amilyen gáz a honlapjuk, nem tudom, mit tudhat a cucc"
Ezt látom, amikor megnyitom, mivel szándékosan Click to play-re vannak állítva a Flash-tartalmak:Gratulálok nekik. 2015-ben még mindig egy full Flash-alapú oldal.
Utána azért kíváncsiságból már rákattintottam, de mivel a dizájn is ilyen borzasztó gusztustalan 2000-es évek eleji (az izgő-mozgó gifek korát idézi), ezért nem is néztem tovább. Most tényleg egy ilyen igénytelen szar után képes lennél még fizetni is nekik?Sk8erPeter
-
Sk8erPeter
nagyúr
válasz MineFox54 #17627 üzenetére
1. Nem konkatenálunk SQL-utasítást escape-eletlen inputtal, SOHA, semmilyen körülmények között (azt sem érdemes felhozni mentségnek, hogy de hát az szerintem megbízható adat, mert nincs olyan kívülről érkező adat, amit megbízhatónak érdemes tekinteni - ez a paranoiás szemlélet célravezetőbb), és amennyiben lehetséges, prepared statementeket KELL használni a különböző paraméterekre. És jelenleg lehetséges, mivel MySQLi-t használsz, szóval mindenképp állj át arra.
2. Az ilyen jellegű mezőkhöz aliasokat illik használni (pl. itt SUM(tav) AS distance vagy hasonló), aztán az aliasnak megfelelően hivatkozni rájuk (pl. itt $row['distance'] - szándékosan nem használtam magyar változónevet ).A konkrét érdekes eltéréshez nehéz többet hozzátenni, több infót kellene tudni, mi változhat a különböző futtatások között.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
"debuggolj. írasd ki echo-val a különböző változók értékeit"
Ezen azért kuncogtam. A debuggolás NEM AZ, hogy kiíratsz!!! Persze része lehet a hibakeresésnek, adott esetben nem para, ha nem a képernyőt írod tele, hanem legalább naplózol, de pont ez a baj, hogy számtalan PHP-fejlesztő azt hiszi, hogy az a jó hibakeresési módszer, ha telerakja a kódját echózásokkal (persze nem is naplóz véletlenül se), és nem tudja, hogy léteznek valódi debuggolási módszerek egy fejlesztőkörnyezetben (IDE), az Xdebug felhasználásával. Tehát bármily meglepő, PHP-ban is ugyanúgy lehet debuggolni, mint másik nyelvekben. Tök jól végig lehet lépkedni a kódon, hogy épp hol tart, vagy csak kifejezetten az általad manuálisan elhelyezett töréspontokon (breakpoint) megállni, lehet watch expressionöket elhelyezni (így a kód adott pontjára érve bizonyos változók értéke kiírásra kerül egyből a fejlesztőkörnyezetben), sőt, jó fejlesztőkörnyezetben lehet feltételes töréspontokat is elhelyezni (conditional breakpoint), ami azt jelenti, hogy csak bizonyos feltételek teljesülése esetén áll meg a kód adott pontján (ezzel például tök jól lehet rászűrni a problémás esetekre, amikor mondjuk nem akarsz minden esetben megállni, hanem csak akkor, amikor gáz van).
Igazából az van, hogy szerintem nagyon sokan úgy vannak a debuggolással, hogy "na majd egyszer azt is kipróbálom, most addig is jó lesz az echo", pedig egyszer kell belőni a környezetet - ehhez segítségnek ott van az Xdebug wizardja -, meg egyszer kell kipróbálni, ez mire is jó - tehát megtanulni debuggolni -, aztán rengeteg időt tud megspórolni.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
válasz PumpkinSeed #17677 üzenetére
Igazából miért ezzel a borzalmasan ronda spagettikóddal oldod meg a problémát?
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz TigerCat #17736 üzenetére
"PHP, CSS5"
Hát lehetőleg a CSS5-öt ne írd bele, mert jelenleg olyan még nem létezik. Szerintem a HTML5, CSS3-ra gondoltál.
Amúgy nem Javascript, hanem JavaScript, nem Ajax, hanem AJAX (mozaikszó). Ezek hibás leírása zavaró lehet egy álláshirdetésben.
Mellesleg nem biztos, hogy érdemes ragaszkodni a PHP-hoz, nem az a webfejlesztés alfája és omegája. Más területekről is komoly szakemberek érkezhetnének.
Egyébként nem biztos, hogy érdemes úgy keresni, hogy valaki ne csak komoly fejlesztő, hanem egyben jó rendszergazda is legyen, mert bár lehet, hogy utóbbi feladatok közül a nálatok érdekeseket is lazán elvégezné (pl. a mailszerver beállítását), de mondjuk nem akar oprendszereket telepíteni (amire nálatok nincs is szükség gondolom az ő esetében, de ezt nem tudhatja), és megijedhet a "rendszergazdai feladatok" kulcsszótól...Mellesleg szerintem is nagyon rossz ötlet, hogy mindenféle népszerű keretrendszert is (nemcsak a CMS-eket) kizártok a játékból.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz supercow #17761 üzenetére
"A másik részt nem értem."
Mivel odaírtad, hogy max="50", ezért a böngésző helyes implementáció esetén már vagy eleve a bevitel során, vagy a fókuszváltás/elküldés/stb. során jelzi a validációnál, hogy érvénytelen számot adtál meg, ergo nem is enged tovább, nem tudod elküldeni az űrlapot (csak ha trükközöl webfejlesztő panel segítségével, vagy ha például a böngésző nem is támogatja a HTML5-öt). Itt meg nem ez a cél, hanem a figyelmeztetés arra, hogy a felhasználó nagy számot adott meg - de ettől még egyébként elfogadható a nagy szám is, csak meg kell győződni róla, hogy a felhasználó tényleg azt akarta-e.
Igaz, a javasolt ellenőrzési módszer is csak kliensoldalon zajlik, tehát ez sem egy atombiztos megoldás, de lehet, hogy a kérdezőnek ez is elegendő, ez nem derült ki.Sk8erPeter
-
Sk8erPeter
nagyúr
"persze hogy sql hívások set names nélkül, hogy törne le a keze aki írta a php jquery naptárat"
A többesszámot a hívásoknál nem értem, a SET NAMES 'valamilyen_karakterkészlet' (pl. SET NAMES 'UTF8' (aposztróf nélkül is működne itt amúgy)) utasítást egyszer kell csak kiadni, a csatlakozás után, és kész.
Persze lehet, hogy erre utaltál, csak félreérthetően hangzott.
(Ahogy a "php jquery naptár" is furán hangzik. )Sk8erPeter
-
Sk8erPeter
nagyúr
válasz PumpkinSeed #17777 üzenetére
Pont most írta, hogy "A xampp\mysql\data\mysql\user.frm, user.MYD, user.MYI felülírása friss telepítésből származóval megoldotta."
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz fordfairlane #17867 üzenetére
Uhh, ez igen minőségi darab, de a 220 ezres ára miatt valószínűleg nem fogok rárepülni. (Pedig jól jönne egy 27"-es a 24" mellé.)
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz fordfairlane #17890 üzenetére
Pedig itt sztem igaza van Trisztánnak, valami feedback azé' legalább egy header formájában nem ártana. (Még egy sima echózás is jobb lenne még exit előtt, mint egy tök üres lap hiba esetén, ami akármi mástól is lehetne (pl. fatal error elrejtett hibaüzenetekkel), kezdő jól beszophatja az ilyeneket, amikor elírja mondjuk a query stringet, vagy ilyesmi.)
(#17881) fordfairlane:
Hát igen, ez így elég jól hangzik, de 220 ezret akkor sem szánnék monitorra (csak ha fürdenék a lóvéban). Jelenleg elégedetten használok egy Dell P2414H-t, árkategóriáján belül az is igen jóféle (legalábbis az volt, amikor vettem), az én igényeimet szerencsére kielégíti, bár lehet, hogy azért, mert nincs is túl sok igényem. Csak a színhűség (kalibrálás megoldotta), meg a minimum 24" (el tudnék viselni mondjuk 27"-et...), plusz hogy ne legyen túlzottan széjjelvilágított, ronda feketéje a monitornak, meg persze ne legyen durva utánhúzása (alacsony késleltetés), legalábbis most ami eszembe jut (meg nyilván digitális csatlakoztatási lehetőségek).
Egyébként abszolúte elhiszem, amit írsz, hogy igényesebb szemnek feltűnnek ezek a zavaró tényezők, sok fanatikus nem véletlenül ragaszkodik a jobbfajta CRT-monitorjához. Örülök, hogy számomra ezek nem zavaróak, meg is őrülnék akkor minden monitortól, amihez oda kell ülnöm. Ha kicsit odafigyelek erre, még így is zavar pl. melóhelyen a 24"+19" monitorokból az utóbbi, ami távol áll az igényes monitortól (az is Dell, de az önmagában nem jelent semmit).Sk8erPeter
-
Sk8erPeter
nagyúr
válasz PowerBuldog #17903 üzenetére
Hát ez aztán rettentően értelmes feladat, ha tényleg azt kellett csinálni, hogy be kell olvasni egy XML-fájl tartalmát DOMDocumenttel, aztán úgy, hogy SEMMIT nem csináltál vele, csak simán kiíratni a tartalmat... Remélem, csak Te értettél félre valamit, és nem ilyen retardált feladatot kaptál.
Mellesleg ez szinte semmiben nem különbözik a korábbitól, mi a frász értelme van ennek, hogy most csak annyit változtattál, hogy másképpen olvasod be, és beállítasz egy fejlécet is (mellesleg helyes, hogy beállítod)?Amúgy korábban nem véletlenül tanácsolta neked fordfairlane, hogy ellenőrizd már azt a nyomorult query stringet, hogy azonbelül az elvárt bemeneti paramétert megkapod-e egyáltalán...
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz don_peter #17917 üzenetére
"Kiíratásnál pedig ezt:
localStorage.getItem("lastname");
Az oldal frissítése után nem ír ki semmit."
És ennek mégis mi a frászért kellene bármit is kiírnia? Nem tároltad el sehova a függvény visszatérési értékét, nem használtad fel sehol... mit vársz, mit kellene tennie ettől a sortól?
Szóval nem, nem jól használod.(#17910) don_peter:
"És igen, megfeledkeztem arról, hogy a PHP az szerveroldali megoldás bár ajax-al nyilván megoldható a textarea kiolvasása, de sokkal jobb és közelibb egy javascript."
Ennek a mondatnak mi értelme van? Az AJAX az Asynchronous JavaScript and XML-ből alkotott mozaikszó, szóval hogy miért választod külön a kettőt, az rejtély. Mi az, hogy "sokkal jobb"? Minél jobb? Mi az, hogy "közelibb"? Mihez képest van közelebb, és az miért lesz bárkinek is jó?Tehát: van a kliensoldali, böngészőfüggő mentés, meg a szerveroldali. Ha nem para, hogy böngészőadatok ürítésekor elvész az addig megírt piszkozat, vagy hogy egyáltalán böngészőfüggő a dolog, tehát nem folytathatja az emberke bárhol az addig megkezdett szövegét, akkor maradhat a kliensoldali tárolás. Ha nem szeretnéd, hogy klienshez, böngészőhöz kötődjön a tartalom, vagy hogy a böngésző oldalspecifikusan tárolt adatainak törlésekor elvesszen a tartalom, akkor küldd el a piszkozatot szerveroldalra, és ott tárold (lásd Gmail-piszkozat). Persze itt azért figyelj rá, hogy ne tudjon kismillió darab piszkozatot tárolgatni a júzer, hogy tömködje feleslegesen piszkozatokkal az adatbázisodat, mármint ha ez gondot jelent.
IP-cím változása hatására nem kell, hogy a session is megszűnjön, erre ismét jó példa a Gmail. Vagy a Drupal is így oldja meg. Nézz utána, hogy kell megoldani.
(#17905), (#17907):
"elmegy a NET"
Akarod mondani net. Ez a szó NEM egy mozaikszó! Nem értem, emberek miért írják csupa nagybetűvel, nem kell. Lásd ezt."COOKIE lehet járható út?"
Akarod mondani cookie. Ez sem mozaikszó."persze mehet egy kis ajax-al is a dolog"
Akarod mondani AJAX. Pont azt nem írod csupa nagybetűvel, amit meg kell?Sk8erPeter
-
Sk8erPeter
nagyúr
A file függvény fájlnevet vár első paraméterül, Te pedig a $current változót passzolod át neki, ami a beolvasott fájl tartalmát, meg az ahhoz fűzött további adatokat tartalmazza. Ez így eleve nem lesz jó.
Azt írod, hogy fopen($path), de közben a $path változó értéke nincs beállítva (vagy legalábbis itt nem osztottad meg velünk). Ha a kódodból és hsz.-edből jól vettem le, az eredeti fájlt szeretnéd módosítani úgy, hogy hozzáírsz még adatot, tehát akkor az általad $file-nak nevezett változót kellene átadnod neki. De szerencsésebb lenne ezt inkább $filename-nek elnevezni, hiszen épp csak egy fájlnév, nem a fájlt reprezentáló objektum vagy ilyesmi (tehát félrevezető a név).
Az fopen két paramétert vár, csak egyet adtál meg. Ez a hibaüzenetekből egyértelműen kiderül, ha nincsenek kijelezve a hibaüzenetek, fejlesztés idejéig igazából kötelező (hogy időben észrevedd, meg hogy ne legyen ilyesmi, hogy nem érted, mi van). Mivel csak írni szeretnél a fájlba, passzold át még neki a "w" paramétert.
Aztán a foreach-ben ha jól értem ilyen jó fáradt fejjel, ki akarod szedni a már meglévő sorokat. Na de aztán nem teszed bele igazából azokat az értékeket, amik "újak", csak kiszedsz - tehát pl. egy üres fájlnál nem írsz vissza a fájlba semmit. Így nem meglepő, hogy az egész nem is működik.Sk8erPeter
Új hozzászólás Aktív témák
- Milyen széket vegyek?
- Politika
- Garancia kérdés, fogyasztóvédelem
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- TCL LCD és LED TV-k
- Ez a telefon lehet a Moto G85 egy átnevezés után
- Kerékpárosok, bringások ide!
- Elektromos (hálózati és akkus) kéziszerszámok, tapasztalatok/vásárlás
- Futás, futópályák
- Hisense LCD és LED TV-k
- További aktív témák...
- Alaplap,Processzor,RAM egybe vagy külön
- Lenovo Thinkpad T14s Gen3 - i5-1240p/16GB/512GB Nvme SSD
- Vadonatúj iPhone 14 128GB midnight kártyafüggetlen! Apple garancia!
- HP játékra is,core i5 5200u, Nvidia 4!!!/6GB VGA,8GB Ram,240 GB SSD,Új töltő
- PEAQ(MSI)vékony,gyors laptop,core i3 6100 (4X2,3Ghz),8GB DDR4 RAM,240SSD,Új 10 órás!akku,nagyon szép