- NTFS, exFAT, FAT32 – Melyiket válaszd és miért?
- Steam Deck
- Milyen alaplapot vegyek?
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- UHD filmek lejátszása
- Azonnali informatikai kérdések órája
- Autós kamerák
- Milyen billentyűzetet vegyek?
- Apple asztali gépek
- Nem tetszik a Procon-SP-nek, hogy a Nintendo távolról kivégezheti a Switch 2-t
Új hozzászólás Aktív témák
-
#8115
Sk8erPeter
nagyúr
Tele von Zsinór
#8114
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#8114
üzenetére
Ki az a dsp_, és miért érdemes tudni róla egyáltalán?
-
#8104
Sk8erPeter
nagyúr
coco2
#8102
Sk8erPeter
nagyúr
Azért ez annyiban sántít, hogy nem igaz, hogy csak ezekből lehet megélni, és "pénzt szedni". C#-os (webfejlesztésre fókuszálva ASP.NET-es), de akár Objective C-s (ld. IPhone) megoldások is bőven születnek; még mindig él a C++programozás, és még nyilván lehetne sorolni. Mindenféle területen lehet "pénzt szedni". De tény, hogy webfejlesztésben nem lehet elmenni a PHP mellett.
-
#8101
Sk8erPeter
nagyúr
trickyy
#8100
Sk8erPeter
nagyúr
válasz
trickyy
#8100
üzenetére
Mivel a PHP az egyik legnépszerűbb nyelv a webfejlesztés terén, ezért ez bőven kínál munkalehetőségeket is. Na meg nagyon nagy mértékű támogatottságot élvez, így bőven találsz segítséget is hozzá (könyvek, e-tutorialok, e-bookok, fórumok, blogok, stb.), és szoftveres támogatást is (CMS-ek, keretrendszerek, stb.).
Mindenképp megéri tehát belefogni, persze attól is függ, mennyire gondolod komolyan - ha jól csinálod, nagyon is kifizetődő lehet. Gondolj csak bele: valószínűleg honlapokra még nagyon sokáig szükség lesz... -
#8099
Sk8erPeter
nagyúr
raczger
#8098
Sk8erPeter
nagyúr
válasz
raczger
#8098
üzenetére
Hát ennyiből nem tudom, mondjuk azt nem írtad, az Android app helyesen megkapta-e minden alkalommal az adatokat, nem volt-e 404, vagy hasonló, ami miatt mégis a főoldal nyílt meg mondjuk, stb. - meg nem indított-e az Android-app túl sok requestet mindemellett...
Majd írd meg, ha újból tesztelted, és ezeket mind vágod.
-
#8095
Sk8erPeter
nagyúr
CSorBA
#8094
Sk8erPeter
nagyúr
A phpMyAdminnak van egy config.inc.php fájlja a főkönyvtárában.
Ebben néhány beállítás található, többek közt a blowfish_secret is, ezt nálam az a setup generálta, ami ott van a /setup cím alatt... ez generálta a config.inc.php-met is.
Nálam localhoston így néz ki ez a blowfish_secret kód (egy sor a sok közül):
$cfg['blowfish_secret'] = '4efe8f2e64de52.06461375';Valszeg ez nálad nincs beállítva. Vagy valami hasonló.
-
#8093
Sk8erPeter
nagyúr
raczger
#8086
Sk8erPeter
nagyúr
válasz
raczger
#8086
üzenetére
Szóval akkor röviden összegezve: az az alkalmazás, ami az Androidos proginak szolgáltat adatokat 2 mp-enként, állításod szerint egyáltalán nem is kapcsolódik adatbázishoz, csak megkavar egy tömböt, kiírja az egyik tartalmát, meg csinál egy fájlba írást, igaz? ... és annak ellenére, hogy az Androidos progihoz semmiféle adatbázis-baszkurálás nem kell, azt mondják, durván túl van terhelve az adatbázisszerver. Eddig stimmel?
"a két sql lekérdezés amit beszúrt nekem az az eredeti oldalamon szokott meghívódni"
Ezalatt az "eredeti oldalam" alatt mit értesz? Úgy érted, a főoldalon lefut mondjuk egy látogatást mérő szkript, ami beszúrogat adatbázisba, a kis Androidos alkalmazás meg csak valami alkönyvtárban van? Annak a bizonyos scriptnek a lefutása függ sessiontől? (úgy értem, egy session alatt csak egyszer fut le?) Vagy úgy tűnik, minden alkalommal új sessiont kezdeményez? Mert mondjuk ilyen akkor elő szokott fordulni, ha az ember pl. DOMDocument segítségével olvasgat be adott URL-ről visszakapott adatokat. Ehhez hasonló esetben meg, ha valamiért mégis először a főoldalon le tud futni az a bizonyos script, akkor akár előfordulhat, hogy mindig újból és újból lefut... Látható is, hogy az adattábláid durván telítődnek? Vagy milyen változásokat látsz az adatbázisban?
Bocs, hogy ennyi kérdéssel válaszoltam a kérdésedre, de ezek ismerete nélkül elég nehéz behatárolni szerintem így "külsősként" a problémát...==
(#8091) Athlon64+ : mutass kódot, ahogy raczger is írta.
===
(#8090) CSorBA:
Gyors guglizás alapján hátha ez segít, tapasztalatom nincs benne: [link]. -
#8078
Sk8erPeter
nagyúr
Lacces
#8068
Sk8erPeter
nagyúr
Szerintem használd azt, ami neked kényelmesebb. Az Eclipse és a NetBeans egyaránt teljesen jó lehet. Nem hinném, hogy az Eclipse kevesebbet tudhatna a NetBeans-nél PHP-fejlesztéshez, szerintem mindkettő beállítható úgy, hogy hasonló képességű legyen, de majd szól valaki, ha mégis komoly hiányosságot fedezett fel valamelyikben.
... és mindkettő ingyenes... ez eléggé mellettük szól.
-
#8067
Sk8erPeter
nagyúr
PazsitZ
#8065
Sk8erPeter
nagyúr
válasz
PazsitZ
#8065
üzenetére
Ez a PHP-vel utólagosan eltávolítós módszer szerintem csak akkori végső megoldás, ha Te nem férsz hozzá a beolvasandó fájlokhoz, és annak eleve el van cseszerintve a karakterkódolása.
#8066 Lacces: a preg_replace-es megoldást csak akkor használd, ha nagyon muszáj.
"Notepad++ -ot már akartam, de linuxra nem jön fel a Wine nélkül. Keresek egy linuxos megfelelőt."
Hasonlóan alacsony erőforrásigénnyel rendelkező, funkciógazdag szövegszerkesztőt én valahogy nem találtam Linuxra, meg mindegyiknek megvolt a maga hülyesége vagy hiányossága (Notepad++-hoz képest, ami elég jól bővíthető pluginekkel is), de most nincs kedvem egyenként felsorolni, mik voltak azok; kényelmi és egyéb szempontok is szólnak részemről a Notepad++ mellett - Wine-nal kicsit nyakatekert megoldásnak tűnik, de én sokszor Linuxon akkor is inkább a Notepad++-t használtam, pont így.
Vagy ha komplett IDE-t akartam, amire a kis erőforrásigény kevésbé jellemző, akkor NetBeans-t használtam (ahhoz már nem kell Wine). -
#8064
Sk8erPeter
nagyúr
Lacces
#8062
Sk8erPeter
nagyúr
Szerintem rossz a fájlod (vagy fájljaid) karakterkódolása.
Rakd fel a Notepad++-t, nyisd meg a fájljaidat, és az "Encoding" menüpontban menj rá, hogy "Convert to UTF-8 without BOM". Ennek megfelelően a meta tagekben is legyen UTF-8 karakterkódolás.
Meg nyomathatsz egy ilyen headert a PHP-fájljaid elején:
header('Content-Type: text/html; charset=utf-8');Szerk.: Athlon64+ 16 másodperccel előbb írt.
(#8057) Retekegér: ja, szerkesztettem, mert eszembe jutott, mi van, ha az UW kicsit elmaradt a fejlődésben, és még mindig csak PHP 4 van fent... Mondjuk azért remélem nem.
-
#8056
Sk8erPeter
nagyúr
Retekegér
#8055
Sk8erPeter
nagyúr
válasz
Retekegér
#8055
üzenetére
Egyéni preferenciáktól, és attól, hogy a szerveren egyáltalán fent van-e és engedélyezve van-e (php.ini-ben) a MySQLi-kiterjesztés. Persze PHP 4-es verziójában még egyáltalán nem fogod tudni használni, mivel ott még nincs, de aki manapság 4-es PHP-t használ...az valahol leragadt az őskorban.
Egyébként ha választani kell és lehet, érdemes inkább a MySQLi-kiterjesztést használni a klasszikus MySQL-kiterjesztés helyett.
-
#8052
Sk8erPeter
nagyúr
PazsitZ
#8050
Sk8erPeter
nagyúr
válasz
PazsitZ
#8050
üzenetére
Amit most mutattál, az más, mint amiről én beszéltem! Abban a példakódban, amit Lacces mutatott, ott egy stringbe úgy erőszakoltak bele egy változót, hogy bohóckodtak a kapcsos zárójelekkel, amikor totál felesleges, lehetne átlátható módon konkatenálni is egy másik stringet (az általad mutatott példakódban Te meg épp ezt csináltad, jól), és akkor nincs belőle kavarodás. De szerintem korábban is pont ezt írtam, csak más szavakkal.
-
#8048
Sk8erPeter
nagyúr
Lacces
#8047
Sk8erPeter
nagyúr
"Főleg, hogy jobb is a konkatenálás, azt a szebb példát, annak külön örülök
Így van egy Java feelingje az egésznek"
Attól lesz Java feelingje, hogy van benne egy konkatenálás? Hmm.Ja, assign - hozzárendeli egy $temp, vagyis átmeneti változóhoz a $_POST tömb aktuális értékét. Itt a foreach ciklusban ugyanis bejár egy tömböt, vizsgálja a tömb értékeit. De gondolom ezt nem kell magyaráznom, ha csináltál már ilyet Java-ban.
"az expected tömbben található értékek alapján, létrehoz változókat"
Na, akkor elölről. Az első if-nél azt vizsgálja, a $_POST aktuális tömbindexének értéke ($temp-ben van most) nem üres-e és szerepel-e a $required tömbben. Ha a két feltétel teljesül, akkor valamit mondjuk nem töltöttél ki az űrlapon, berakhatjuk a $missing tömbbe, jelezvén, hogy ez a kulcs hiányzik mondjuk, pampogunk a júzernek, hogy töltse már ki legyen szíves az adott mezőt.
Egyébként ha a $temp nem üres, az adott kulcs az $expected tömbben van, (pl. kitöltötte az elvárt mezőt), akkor hozzuk létre az azonos nevű változót (pl. $name)."Ha létrehozza is őket, akkor ezek sima egyszerű változók"
Azok milyenek?![;]](//cdn.rios.hu/dl/s/v1.gif)
Gondolom azt a szót keresed, hogy "lokális" változó.
Attól függ. Ha ez az egész pl. egy függvényben szerepel, akkor csupán lokális scope-ja lesz, a függvényen belül. De lehet akár globális is, ha mondjuk ez egy fájlban "kívül" szerepel ez az egész Onnantól a függvények számára a global kulcsszóval ezek a változók elérhetők, amennyiben nem szüntetted meg azóta pl. unsettel. -
#8045
Sk8erPeter
nagyúr
Peter Kiss
#8044
Sk8erPeter
nagyúr
válasz
Peter Kiss
#8044
üzenetére
Hát ez kellemetlen.
Ettől függetlenül nem értem, minek egy sorba nyomorítani az egészet. De félre ne értsd, nem fikázni akarom a kódolási szokásaidat. Ízlések és pofonok, csak nekem a hajam kettéáll a bogozandó kódoktól. (főleg, hogy feleslegesnek tartom a túlzott rövidítéseket) -
#8043
Sk8erPeter
nagyúr
Peter Kiss
#8042
Sk8erPeter
nagyúr
válasz
Peter Kiss
#8042
üzenetére
Ez minek a kódjából származik? Gondolom valami nagyobb keretrendszerszerűség. Persze ezt is szét lehetne bontani, hogy ne kelljen bogozgatni későbbi kódmódosításkor, de biztos az rengeteget gyorsít a kódon, ha egy sorba tömörítünk mindent.
-
#8041
Sk8erPeter
nagyúr
Lacces
#8040
Sk8erPeter
nagyúr
Szerintem meg itt köze nincs a mutatókhoz a dolognak (hogy azt akarná "visszahozni").
Mindenesetre én úgy gondolom, hogy ezzel csak olyan szinten érdemes foglalkozni, hogy tudd, ilyen szintaktika is van, értsd is meg, ha valakinek a kódjában ezt látod, de Te lehetőleg kerüld el messzire. Tök feleslegesen teszi nehezen olvashatóvá a kódodat, nem tudok olyan esetről, ahol ezt ne lehetne kiváltani másik, szebb, átláthatóbb módszerrel. Pl. egy stringnél tök felesleges beleerőszakolni ilyen módon egy összetettebb változót, akkor már inkább válassz alternatívákat.
Pl. konkatenáld:
vegyük az általad említett példát átalakítva:
eredeti:
echo " {$startYear}–{$thisYear} ";
helyette szebb:
echo $startYear . '-' . $thisYear . ' ';
Nem kell szenvedni vele, hol is ér véget a kapcsos zárójel, plusz egy fejlesztőkörnyezetben jobban láthatóan ki van emelve a változónév (persze, felismeri az IDE, ezt is kiemeli, de amennyiben egyedi módon nem állítottad át valami nagyon elütő színre, akkor a stringen belül, a string default színével csupán félkövéríti, vagy hasonló, tehát akkor is nehezebben észrevehető egy ilyen változónév), ez is segíti az átláthatóságot.
A printf, sprintf-hez hasonló behelyettesítős módszerek is ezerszer szebbek ennél a kapcsos zárójeles bohóckodásnál. -
#8018
Sk8erPeter
nagyúr
Lacces
#8017
Sk8erPeter
nagyúr
Most kezdőként komolyan webáruház fejlesztésével akarsz kezdeni? Szerintem tegyél le róla. Nem azért, mert képtelen lennél megcsinálni, hanem mert olyan szinten komplex, és elképesztő időelkúró tevékenység, de legfőképp azért, mert nagyon jó webshopmotorok vannak készen, amiket folyamatosan foltozgatnak az esetleges felfedezett biztonsági vagy egyéb hibák miatt. Így egyre nehezebb feltörni és megborítani őket.
Ha PHP-t szeretnél tanulni, ne webshoppal kezdd, hanem előbb tanulgasd meg, hogy kell formokat validálni, feldolgozni, adatbázisba tölteni az adatait, onnan lekérni a feltöltött adatokat, aztán jöhetnek a komplikáltabb dolgok is.
Persze ahogy érzed, de én a helyedben tuti, hogy a meglévő igen széles ingyenes webshop-kínálat ismeretében NEM épp webshop kódolásával cseszném el az időt.
De ez igaz szerintem haladókra is, ha nem muszáj, akkor nem elejétől kezdve kellene megírni egy webshopmotort, hanem inkább továbbfejleszteni egy meglévőt. -
#8006
Sk8erPeter
nagyúr
Lacces
#8005
Sk8erPeter
nagyúr
Ennek semmi köze a XAMPP-hoz! Legfeljebb annyiban, hogy ott alapból a php.ini-ben nem voltak elnyomva a hibajelzések.
De ez nem "debugger", ne keverjük a fogalmakat. Ez csak simán kiírja a hibaüzeneteket.
Kotord elő a php.ini-t, és keresd meg az error_reporting részt.
Nézd meg, hogy jelenleg mi van beállítva.
Én ezt a beállítást javaslom fejlesztésre:
error_reporting = E_ALL | E_STRICT
Ez a "legszigorúbb" hibajelzés, mindent kiír.
Egy igényes programozó megszünteti a hibajelzések okát, nem pedig láthatatlanná teszi őket.
Engem személy szerint kiráz a hideg attól a mentalitástól, hogy "ugyan már, ki nem szarja le a notice-okat, nyomjuk el, nem kell annak látszania, szedjük ki az error_reportingból, azt kész, meg van oldva". Na persze, majd amikor azzal fog a fejlesztő időt elkúrni, hogy rájöjjön, vajon miért nem működik valami (pl. tömbindexelésnél elgépelés miatt), akkor változtat a hozzáállásán. (vagy nem, az a menthetetlen eset)
Aztán keresd meg a display_errors-t:
display_errors = On
Ha még alaposabban szeretnéd:
display_startup_errors = OnViszont fontos hozzátenni, hogy ezek a hibajelzési beállítások csak a fejlesztési fázisra vonatkoznak. Utána szigorúan tilos kiíratni ezeket a hibákat! Többek közt az is egy sebezhetőségi pont. Az éles rendszeren kezeld a hibákat megfelelően, csakis belső naplózást használj a hibajelzések tárolására, ne írass ki belőlük egyet sem.
-
#8004
Sk8erPeter
nagyúr
Siriusb
#8003
Sk8erPeter
nagyúr
válasz
Siriusb
#8003
üzenetére
Hát igen. Amúgy miután ezeken a fázisokon végigment az ember, még mindig könnyű hibát véteni a konfigfájlban, aztán nézni, hogy most mi van má' megint (persze kellő szopás után viszonylag gyorsan rájössz a hibaüzenetekből, de akkor is idő megy vele). Ezért volt nekem felüdülés, vagy inkább kellemes meglepetés az IIS admin-felülete (alapvetően eléggé ódzkodtam tőle, míg ki nem próbáltam). Összekattintgatod, és egyszerűen mennek az oldalaid.
Nem is igazán világos, normális grafikus felület miért nem készült még Apache-hoz - csak ilyen: [link], de próbáltam, még mindig elég silány, csak a konfigfájlt állítod, még mindig el lehet cseszni, és ettől kezdő nem kattintgatja össze az oldalt -, azért ennyire senki nem lehet konfigfájl-buzi. (na jó, de) -
#8000
Sk8erPeter
nagyúr
Lacces
#7999
-
#7986
Sk8erPeter
nagyúr
Sk8erPeter
#7984
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#7984
üzenetére
Na basszus, erre csak elrontottam, tehát korrigálnám magamat:
"Pl. konzolból futtatva, ha nem akarom, hogy bármit is írjon az stdoutra: curl example.com/cron.php"
NEM, hanem:
curl example.com/cron.php>NUL
Tehát legyen átirányítva az stdout a NUL-ra, ha Windows-ban batch-fájlból vagy konzolból hívom meg az említett cURL-t. -
#7985
Sk8erPeter
nagyúr
Lacces
#7983
Sk8erPeter
nagyúr
Nincs baj a XAMPP-pal, valóban jó kezdőknek, de mondjuk szerintem ez inkább Windows-nál igaz, mert Linux-disztribúciók esetén ahogy Tele von Zsinór említette, többnyire lehetőség van arra, hogy egyszerre lehúzd az összes függőséget pl. phpMyAdminhoz, ez ugyanúgy telepít is mindent, amire szükséged lehet. Windows-nál meg ez megoldandó kérdés, így ott EasyPHP, XAMPP, AppServ, amit általában elsők között említenek, mert ez egy csomagban felrak mindent, ami egy alapvető webszerverhez kellhet.
Mondjuk IIS-nél is van ilyen függőség-ellenőrzés, erre példa a Drupal vagy Joomla, ha rámész Web Platform Installer használatánál, hogy töltse le őket, akkor eleve függőségként lehúzza a PHP-t és MySQL-t is. (Amúgy érdekes, hogy úgy tűnik, a Microsoft nyit az opensource-dolgok felé is.)"Furcsa mód, itt kérte telepítésnél a mysql, egy felhasználót, és egy jelszót! (úgyhogy így utólag értem már mire gondolsz, ha erre gondoltál)"
Nem, nem erre gondoltam. Amikor telepíted a MySQL-t, kell egy root felhasználó is, aki az egésznek az adminisztrátora, mindenféle joggal. A phpMyAdminnál van egy kontrollfelhasználó is, ami pl. "könyvjelzőzni" tud bizonyos query-ket, naplózni különböző szempontok alapján, stb., ennek nem szabad megadni a root-jogot (ne legyen már mindenhez joga, mi van, ha pl. biztonsági rés vagy egyéb hiba maradt a "rendszerben", akkor ne csinálhasson bármit). Kell a phpMyAdminnak egy külön tábla MySQL-ben (persze ez elvileg nem kötelező), ebbe írogathat, de ahhoz hozzá is kell férnie.
Amúgy egyáltalán nem fértél hozzá a MySQL-hez?"Tudom, hogy a var/www-ben kell lenni a weboldalnak amit kezelni akarok."
Nem, oda rakod, ahova akarod, csak legyen elérhető a webszerver számára, és konfigold úgy a webszervert, hogy az adott domain document rootja ide legyen irányítva."1. HOgyan tudom ezekután a böngészőből elérni a phpmyadmin-t?"
Nem értem a kérdést.
Húzd le az egész csomagot úgy, ahogy Tele von Zsinór mondta.2. kérdésre: a PHP futtatásához webszerver kell (vagy konzolon keresztül is tudod futtatni, de ezt most hagyjuk), különben nem fog futni a PHP interpretere, értelmezője/"fordítója", így a kódod nem fog "lefordulni".
A HTML-kódok megjelenítéséhez ez nem szükséges, azok kódját a böngésző értelmezi és megjeleníti. -
#7984
Sk8erPeter
nagyúr
modder
#7981
Sk8erPeter
nagyúr
Ja, ezzel jó lehet: [link].
Köszi!
Nem tudom, miért nem jutott eszembe, hogy mivel nem webszerveren keresztül futtatom a scriptet, nem állítódnak be a megfelelő változók...
Ahtlon64+: na ez az argumentumos megoldás viszont nagyon melósnak tűnik. Ha tételezzük fel, lenne 30 site, annak mindegyikénél be kéne állítani a megfelelő argumentumokat, az annyira nem lenne szimpi. Persze ugyanúgy, mint a cURL-es megoldásnál, végig lehet rohangászni akár batch-fájlon keresztül az ütemezendő fájlokon, ciklussal, rögzített könyvtárstruktúra esetén, mindegyik szükséges változót beállítva, argumentumként átadva, de ennél a cURL-es megoldás szerintem ezerszer egyszerűbb.
Pl. konzolból futtatva, ha nem akarom, hogy bármit is írjon az stdoutra: curl example.com/cron.php. De köszi az ötletet! -
#7980
Sk8erPeter
nagyúr
Peter Kiss
#7966
Sk8erPeter
nagyúr
válasz
Peter Kiss
#7966
üzenetére
Ó, ez egy jó magyarázat lehet, még nem tudom, miért nem jutott eszembe, köszi!
Ebben az esetben nincs kerülő megoldás? Pl. a DOCUMENT_ROOT környezeti változót elég nehezen tudnám globálisan beállítani, mivel több site is fut a szerveren, elméletben többhöz is kellene cront használni. Ugyanez igaz a többi környezeti változóra is.
Nem láttam még példát rá, hogy szokták ezt megoldani. Valahogy biztosan, mert nem én vagyok az egyetlen, aki ilyen módon szeretne "cron"-t futtatni.
Ötlet? -
#7979
Sk8erPeter
nagyúr
Lacces
#7975
Sk8erPeter
nagyúr
Nem a Linux-disztribúcióval van a baj, hanem a beállításaiddal.
Szerintem épp az a gond, amit ír, hogy nem létezik MySQL-ben a "kontrollfelhasználó".
Van egy ilyen rész a phpMyAdmin config.inc.php-jében (egyáltalán van ilyened?!):
$cfg['Servers'][$i]['user'] = 'phpmyadminkontrollfelhasznalo';
$cfg['Servers'][$i]['password'] = 'ezmegazajelszo';
(nyilván a megfelelő nevet és jelszót változtasd meg, ez csak példa)
Itt eszerint léteznie kell a "phpmyadminkontrollfelhasznalo" felhasználónak MySQL-ben, aki "ezmegazajelszo" jelszóval tud belépni. Legyenek meg a jogosultságai a megfelelő phpMyAdmin táblához.
Egyébként ez kb. 10 perces szívás max., ha használod a phpMyAdminhoz mostanában alapból adott setupot, ezt simán a phpMyAdminon belüli setup könyvtárban éred el.
Ez elkészíti neked a megfelelő config.inc.php konfigfájlt, úgy, hogy Te grafikus felületen pötyögöd be a szükséges adatokat (több fülön kitöltöd, és készen vagy). A folyamat végén le kell tölteni az elkészített konfigfájlt, és berakni a phpMyAdmin gyökérkönyvtárába.
Kérdezz, ha elakadtál. -
#7958
Sk8erPeter
nagyúr
Peter Kiss
#7957
Sk8erPeter
nagyúr
válasz
Peter Kiss
#7957
üzenetére
Meg IIS oldalán is vannak esetleges szükséges lépések, de ha Web Platform Installeren keresztül rakod fel, elvileg csomó mindent beállít magától is. Ettől függetlenül szerintem végigmentem a lépéseken, de konkrétan arra vonatkozó részre nem emlékszem, ami kifejezetten az általam említett változókkal kapcsolatos problémák forrása lehetne. De mint mondtam, csak akkor tapasztalom a problémát (a $_SERVER tömbben lévő egyes indexek elérhetetlenségét), amikor ütemezőn keresztül futtatom a php-cgi.exe-t. Valami simán kimaradhatott, de továbbra sem tudom, mi, pont ez a baj - így ezzel a tanáccsal sajnos nem lettem előrébb...
Esetleg valami konkrétabb? -
#7956
Sk8erPeter
nagyúr
Sk8erPeter
nagyúr
Sziasztok!
Erre a kérdésre van bármi ötletetek?
Nem másolom be ide is a teljes kérdést, de a lényeg, hogy FastCGI PHP-t használunk IIS szerveren. Ha böngészővel futtatok alkalmazásokat (most konkrétan Drupalról van szó), nincs probléma, de ha a Windows feladatütemezőjébe beteszek egy ütemezett feladatot, és php-cgi.exe-vel futtatom, néhány, a $_SERVER tömbben megtalálhatónak vélt környezeti változó hiányzik - SCRIPT_NAME, SCRIPT_FILENAME, REMOTE_ADDR, amik most hirtelen előkerültek; plusz a DOCUMENT_ROOT sem létezik így futtatva, ami szintén elég problémás lehet.
Itt is szó van erről, hogy IIS alatt olykor nem léteznek ezek a változók, ez nem tudom miért vagy így. Ide kommenteltem is egy kérdést: Xdebug használata esetén is időnként (de csak időnként!!) előfordul, hogy F5 nyomkodásakor egyszerűen nem töltődik be, aminek látható jele van egy var_dump esetén, mert alapból az Xdebug ugye színezi a változókat.Ezeket a problémákat nem értem IIS-nél.
Valaki tud rájuk magyarázatot, vagy bármi ötletet?
Lehet, hogy valamit egyszerűen elfelejtettem konfigurálni.Ez már OFF, de:
egyébként félreértés ne essék, szerintem manapság már kifejezetten ajánlott Windows-on IIS alatt futtatni a PHP-t (ha már van Windows, akkor az IIS ugye nem kerül plusz pénzbe hozzá), és nem rászenvedni az Apache-ot - számomra elég meglepő volt, de azt tapasztaltam, hogy most már mindenképp igaz, hogy Windows alatt IIS-sel gyorsabb a PHP, mint Windows alatt Apache-csal. Nem is térnék vissza itt a régi konfigfájl-buzerálós módszerhez, miután van egy ilyen szinten kézenfekvő adminisztrációs felülete az IIS-nek. Sajnos viszonylag tapasztaltnak mondhatom magam Apache-állítgatás+szenvedés terén, és őszintén megmondom, hogy nagyon utálom, így felüdülés volt grafikus felületen ugyanazt beállítani újoncként max. 10 perc alatt. Lásd Web Platform Installer, stb...
Nem vagyok MS-buzi, de ez nagyon meggyőzött. -
#7916
Sk8erPeter
nagyúr
zalyy
#7915
Sk8erPeter
nagyúr
Ez a kérdés már abszolúte nem PHP-s témakörbe tartozik. Írd le a kérdésed ide, hátha valaki ránéz.
Amúgy helyesírási hibákat abban az ominózus HD-minőségű bemutatkozó videóban is lehetne bőven javítani... -
#7898
Sk8erPeter
nagyúr
zalyy
#7897
Sk8erPeter
nagyúr
1. mivel az oldalad nem megy, elég nehéz ránézni.
2. UTF-8 vagy milyen kódolást használsz? Lényeg, hogy következetesen mindenhol az legyen, ha kell, PHP-val adj ki egy headert.
"vannak helyek ahol mutassa a magyar ékezetes karaktereket"
ez fájt...
3. milyen chaten, milyen fórumon? Szerinted így kód vagy legalább minimális iránymutatás nélkül ki fog rájönni a hiba okára?
+1: ha linket dobsz be, akkor használd a Link gombot.
-
#7894
Sk8erPeter
nagyúr
Louloudaki
#7893
Sk8erPeter
nagyúr
válasz
Louloudaki
#7893
üzenetére
"de legalább annyi látszik, hogy php alapú, nem rejtették el az urlben mod_rewrite-tal szerencsére"
Miért számít az neked a lényeg szempontjából, milyen alapú?===========
(#7892) wolandino: 350 ezer sort egyszerre?
Az sok lesz már egy kicsit. -
#7883
Sk8erPeter
nagyúr
Louloudaki
#7881
Sk8erPeter
nagyúr
válasz
Louloudaki
#7881
üzenetére
Ugyanazt a kódot használod a Google-nél is, amit írtam az imént?
Ha nem, mutasd a teljes kódodat. -
#7882
Sk8erPeter
nagyúr
wolandino
#7880
Sk8erPeter
nagyúr
válasz
wolandino
#7880
üzenetére
Igen, gyorsabb lehet. De most itt már kicsit keverjük a dolgokat... Eddig csak arról volt szó, hogy akkor egyszerre jelenítsd meg az adatokat, és aztán szűkítsd simán kliensoldalon, vagy pedig kevesebb adatot jeleníts meg, és utána a többi adatot AJAX-szal kérd le.
Aztán arra jutottunk, hogy mivel nem egy szervert megterhelő adatmennyiségről van szó, amit annyira nagyon szűkíteni kéne, plusz már megoldottad a kliensoldali szűrögetést, ezért ezen a struktúrán egyelőre (az adathalmaz jelentős növekedéséig) nem is nagyon érdemes változtatni. Ahogy elmondtad, most a felhasználó így is megkapja az ömlesztett és szűrt adatait is, teljes oldalfrissítés nélkül. -
#7879
Sk8erPeter
nagyúr
wolandino
#7877
Sk8erPeter
nagyúr
válasz
wolandino
#7877
üzenetére
"Nyilván a javascript "lassabb""
Már hogy lenne lassabb?
Gondolj bele, AJAX-híváshoz fel kell építened a kapcsolatot a távoli szerverrel, az reagál, feldolgozza az adataidat, majd visszaküldi a választ, és bontja a kapcsolatot. Kliensoldalon meg még fel is kell dolgozni a kapott választ.
A sima JavaScriptes (távoli kommunikációt nélkülöző) megoldással meg eleve csak kliensoldalon kell átrendezni a már megjelenített adatokat, a DOM-ban rohangászva. Ez mindenképp gyorsabb.A Tele von Zsinór átal mutatott jQuery-plugin meg nagyon hasznosnak tűnik.
-
#7876
Sk8erPeter
nagyúr
wolandino
#7874
Sk8erPeter
nagyúr
válasz
wolandino
#7874
üzenetére
Nem vagyok én olyan tapasztalt róka, de köszi.
Azt kell átgondolni, a felhasználónak milyen adatokra lesz nagy valószínűséggel elsősorban szüksége, ettől függ, melyik a praktikusabb megoldás.
Ha mondjuk a legutóbbi 1 hónapra vonatkozó adatoknál több úgysem fogja az esetek többségében érdekelni a felhasználót, akkor nem is érdemes többet lekérni és megmutatni. A nagyon sok ömlesztett adatot úgyis nehéz átlátni, és azt nem nagyon szeretik a felhasználók, ennek megfelelően kell szűrni. -
#7875
Sk8erPeter
nagyúr
Louloudaki
#7871
Sk8erPeter
nagyúr
válasz
Louloudaki
#7871
üzenetére
Ne írd elé a 'http://' stringet (host nevet vár paraméterül), és ne írd mögé ezt: '/:80', ez ebben a formában amúgy sem jó (így még jó lenne: www.google.com:80), meg a második paraméter amúgy is a portszám, tehát pl. így próbálkozz:
$fp=fsockopen ('www.google.com', 80, $fsockopen_errno, $fsockopen_errstr, 30);
-
#7873
Sk8erPeter
nagyúr
wolandino
#7869
Sk8erPeter
nagyúr
-
#7872
Sk8erPeter
nagyúr
Brown ügynök
#7870
Sk8erPeter
nagyúr
válasz
Brown ügynök
#7870
üzenetére
Hát ez pont nem arra való, amire Speeedfire-nek szüksége van, ugyanis nem veszi figyelembe a HTML-tageket...
Próbáld ki pl. így:
var_dump( firstNChar(35, 'Ez egy <span style="color:red">szöveg</span>', null) );Eredménye:
string(40) "Ez egy <span style="color:red">szöv ..."Ez így lezáratlanul nem túl fasza...
-
#7868
Sk8erPeter
nagyúr
Speeedfire
#7866
Sk8erPeter
nagyúr
válasz
Speeedfire
#7866
üzenetére
A kódban most nem keresgéltem hibát, de én azt javasolnám, hogy használd fel a Drupal truncate_utf8 függvényét - kiszedheted innen az oldalról is, minden felhasznált függvényre ott a hivatkozás. Nagyon jól működik HTML-elemekre is, ott vágja el, ahol kell.
-
#7867
Sk8erPeter
nagyúr
wolandino
#7864
Sk8erPeter
nagyúr
válasz
wolandino
#7864
üzenetére
Ahogy joker írta, erre általános recept nincs, de esetedben mivel a felhasználó számára már jó eséllyel nehezen áttekinthető adatmennyiségről van szó, érdemes lenne széjjelbontani.
A felhasználói élményt mindenképp növeli, plusz a felhasználók valószínűleg nem fognak agyatlanul kattogtatni ide-oda, így nem lesz nagyobb terhelés, mintha teljes újratöltéssel szűrve kapnák meg a látogatók az őket érdeklő adatot.
Szűrni gondolom amúgy is kellene, akkor meg abban az esetben, ha teljes oldalbetöltéssel lehetne megtekinteni az új tartalmat, nem AJAX-szal, akkor meg olyan elemeket is be kellene tölteni, amiket jól megírt AJAX esetén nem (fejléc, lábléc, stb.), így annál meg az jelentene plusz terhelést.
Több a pro, mint a kontra. A felhasználói élmény javítása szempontjából meg mindenképp érdemes lenne belevágni. -
#7861
Sk8erPeter
nagyúr
JLK_
#7856
Sk8erPeter
nagyúr
wix.com-ról, a Wix Team tagjától válasz:
"The editor needs constant connection to our servers, it is not possible to work with it offline or save your pages to your computer.
If you still want to save them, you can use the "print screen" option.Please note: Wix does not support the option of exporting files created using Wix to an external destination or host.
We host all your Wix creations on our servers. The advantages of using Wix as your host includes improvements to your site's loading time, search engine optimization and more."== még egy:
[link]
"Can I host a Wix site on my own server?
No. Wix doesn't support the option of exporting files created using Wix to an external destination / Hosts .
We host all your Wix creations on our servers. The advantages of using Wix as your host include improvements to your site's loading time, search engine optimization and more.
You can find more options such as using your own domain, how to connect it, Google analytics and the removal of Wix ads with Wix premium upgrade. Learn more here .
Please note: Wix hosts all of the content of the website (pictures/MP3/files)! However, we don't host external domains- you will have to ask your domain hosting company to point your domain to DNS 216.139.213.144 ." -
#7858
Sk8erPeter
nagyúr
JLK_
#7856
Sk8erPeter
nagyúr
Siriusb hozzászólásához csatlakozva: HTTrack-kel és ehhez hasonló módszerekkel csak a statikus tartalmakat fogod tudni lementeni, de mivel ez dinamikus oldal, ez ebben az esetben nem működőképes megoldás.
Ha Te csináltad az oldalt, akkor eddig is kellett, hogy legyen hozzáférésed az FTP-szerverhez, vagy legalább valami webes fájlkezelőhöz. -
#7848
Sk8erPeter
nagyúr
Tele von Zsinór
#7846
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#7846
üzenetére
"Egyébként ez nem hiba, hanem csak egy E_NOTICE - arról megoszlanak a vélemények, hogy ezekre érdemes-e figyelni fejlesztés közben. Én azt vallom, hogy igen"
Huhh, de örülök, hogy ezt írtad... Amúgy továbbmegyek, szerintem fejlesztés közben legjobb az error_reporting( E_ALL | E_STRICT ) beállítás, nem árt, ha ezek a hibajelzések vagy figyelmeztetések némi szigorúságra nevelik az embert kódolás során. Ezzel a további anyázások meg fejfalbaverések is nagyobb eséllyel elkerülhetők. -
#7842
Sk8erPeter
nagyúr
rt06
#7833
Sk8erPeter
nagyúr
"a font utvonalat ne uri-kent add meg, hanem file-kent:
/mnt/ultraweb/h/hu/hunapk/khand.ttf"
Ehelyett inkább:
$_SERVER['DOCUMENT_ROOT'].'/khand.ttf'...és akkor még költöztethető is az oldal...
Egyébként még egy gondolat az említett oldalon most látható CAPTCHA-val és az ehhez hasonlókkal kapcsolatban: még egy nagyon buta robot is gond nélkül felismeri ezeket a karaktereket, így ugyanúgy simán szanaszét-spammelhető egy vendégkönyv, mintha ott se lenne.
Nem véletlenül bonyolultabbak ennél a Google-ös reCAPTCHA karakterei. De mint mondtam, ez még mindig nem az olvashatatlan kategória (egy-két kivételt leszámítva - ekkor kérhető új kép egy gombnyomásra). -
#7826
Sk8erPeter
nagyúr
rt06
#7825
Sk8erPeter
nagyúr
hát ezzel nem értek egyet, a reCAPTCHA még nem olyan katasztrofálisan szarul olvasható, mint mondjuk a Facebookon szereplő CAPTCHA-k.
Amúgy mindig úgy van, hogy két szót kell begépelni - ebből az egyik csak olyan, amit felhasználnak könyvek scannelésénél későbbi referenciának, tehát csak az egyiket kell "eltalálni". -
#7813
Sk8erPeter
nagyúr
Speeedfire
#7812
Sk8erPeter
nagyúr
válasz
Speeedfire
#7812
üzenetére
Ja hogy ez az (az eredeti verziója, Ash Young).
Nem rossz. -
#7811
Sk8erPeter
nagyúr
Speeedfire
#7810
Sk8erPeter
nagyúr
válasz
Speeedfire
#7810
üzenetére
Ebben mi van?
Most nincs kedvem kibontani és kipróbálni, saját kód vagy valami előre megírt cuccos? Csak kíváncsiságból. -
#7808
Sk8erPeter
nagyúr
Brown ügynök
#7807
Sk8erPeter
nagyúr
válasz
Brown ügynök
#7807
üzenetére
Te szándékosan ignorálod, amiket ugatok neked?
Nem kis illetlenség, amikor az ember segíteni próbál neked...
(ezentúl segítsen neked a hóhér
) -
#7806
Sk8erPeter
nagyúr
Brown ügynök
#7805
Sk8erPeter
nagyúr
válasz
Brown ügynök
#7805
üzenetére
Jó, hogy reagáltál az előzőre... azért is lenne jobb megoldani a PEAR-en keresztüli installálást, mert az gondolom az ilyeneket elintézi...
-
#7804
Sk8erPeter
nagyúr
Brown ügynök
#7803
-
#7802
Sk8erPeter
nagyúr
Tele von Zsinór
#7801
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#7801
üzenetére
Hirtelen nem is nagyon tudok mit hozzátenni, teljesen egyetértek.
Én is inkább amellett vagyok, hogy először működjön minden JS nélkül, utána lehet rápakolni a "csicsát". Persze ez is esetfüggő, nekem pl. kellett olyat is csinálnom, ahol különböző gombokra való kattintgatások esetén rajzolt emberalakokat tudsz összeállítani (testrészeket cserélgetni, stb.), tehát full JavaScript-alapú az egész, itt nyilván egyetlen lehetőség leszarni, ha valakinél ki van kapcsolva a JS. A <noscript> tagben viszont benne van a buzinagy felirat, hogy ne szopassa már a júzer magát a JS nélküli használattal, mert szart se fog látni az alapfunkciókból. -
#7800
Sk8erPeter
nagyúr
cucka
#7799
Sk8erPeter
nagyúr
"Kivéve ha automatizálni szeretnéd a form feldolgozását."
Na de ez még mindig nem mond ellent annak, amit írtam. Automatizáltan is ugyanúgy benne lehet az isset() VAGY !empty() ellenőrzés...A felhasználótól érkező információ megbízhatatlanságáról meg szerintem nem kell különösképpen tárgyalnunk, ez evidens...
Nyilván kliensoldali ellenőrzés sehol nem vált ki semmiféle szerveroldali ellenőrzést, ezt mindketten tudjuk, nem is tartozik szorosan a témához.
Arról beszéltem, hogy az isset ellenőrzés azért sem hülyeség, mert kliensoldalon kiszedhet a formból a júzer elemeket, úgy postolja el, Te meg mondjuk ha nem nyomatsz egy isset() ellenőrzést, akkor lehet, hogy vizsgálod a POST tömb olyan indexét, ami nem is létezik, így kaphatsz egy notice-t.A JavaScript hiányával egyetértek, hogy manapság már nem érdemes foglalkozni, legfeljebb szerveroldali validálás szintjén. Mégsem értek egyet feltétlenül a checkbox hidden mezővel való kiegészítésének szükségességével, ez a lényeg.
-
#7798
Sk8erPeter
nagyúr
meone
#7796
Sk8erPeter
nagyúr
Hű, már nagyon kezded összekutyulni, most már az index.php-be is beletetted ezt, aminek a JSON-generáló fájlban kéne lennie?
Mé', minek?
Korábban ezt írtad: "Ha magát a fájlt linkelem be direktbe nem feldolgozva a PHP által akkor azt se olvassa be." Először azt oldd meg, hogy saját tartalmat mindenféle generálás nélkül egyszerűen kiíratsz, a megfelelő formátumban.
Kezdd azzal, hogy simán a cucc.php fájlodba másold bele ennek a fájlnak a tartalmát (persze először kommentezd ki átmenetileg a saját megírt kódodat), és próbáld ki, úgy működik-e. Ha nem, akkor már eleve itt van valami gáz! Először ezt szűrd ki. Lehet, hogy elérési útvonal, vagy bármi más, de mindenképp figyeld a böngészőben a developer tool konzolját (pl. Chrome-ban F12, FF-ban ugyanez, ha telepítve van a Firebug, esetleg Ctrl+Shift+I Operában Dragonfly-hoz), hogy kiír-e valami hibaüzenetet! (pl. 404, vagy bármi más hiba, JS-exception, stb.)Még annyit esetleg kipróbálhatnál (bár kétlem, hogy ez önmagában megoldja, de ki tudja manapság
), hogy az adatgeneráló PHP-fájlod (nálad cucc.php) elején kiküldesz egy JSON-headert:
header('Content-type: application/json');Ja, még egy, hogy ugye nem tartalmaz BOM-ot az UTF-8-fájlod (ha UTF-8-kódolású egyáltalán)? (Notepad++-ban ezt meg tudod nézni.)
-
#7797
Sk8erPeter
nagyúr
cucka
#7795
Sk8erPeter
nagyúr
Há' vágom én.
De a többi elpostolt értékhez tartozó alkalmazáslogikába beletenni egy isset() vagy !empty() (ez úgyis lefedi az isset-et) ellenőrzést nem kerül semmibe. Ez az ellenőrzés úgysem árt, pl. mi van, ha valaki elpostol úgy adatokat, hogy belegányol a kódba kliensoldalon, kiszed elemeket belőle, Te meg a nem létező elemekre futtatsz mondjuk további vizsgálatokat - ezzel legalább az ilyen rosszindulatú szándék elé is teszel plusz egy szűrőt. (Félre ne érts, itt nem azt mondom, hogy ezzel kivédsz bármilyen támadást, vagy hasonló, de legalább plusz egy lépés afelé, hogy teljes körű ellenőrzésed legyen.)
Én is úgy vagyok vele manapság, hogy k@pja be, aki kikapcsolja a böngészőjében manapság a JavaScriptet, de azért még mindig gondolni kell erre az esetre is. -
#7794
Sk8erPeter
nagyúr
cucka
#7788
Sk8erPeter
nagyúr
Minek hidden mező és JS ehhez?
Miért nem elég, ha csekkoljuk isset()-tel, hogy megvan-e egyáltalán a checkbox típusú input (name szerint)?===
(#7789) meone:
"amit belinkeltél abban vannak kommentek nálam meg nincsenek. Ennyi a külöNbség."
... meg amit már mondtam párszor... A zárójeleket és a pontosvesszős lezárást még mindig lehagytad... -
#7784
Sk8erPeter
nagyúr
meone
#7781
Sk8erPeter
nagyúr
"a fájlom nekem is úgy épül fel majdnem teljesen mint a belinkelt"
Hát ne MAJDNEM teljesen úgy épüljön fel. Egyezzen meg szintaktikájában. Mibe telne kiegészíteni azzal,ami még hiányzik? (pl. hiányzó zárójel, lezárás)
Simán lehet, hogy valami van még, ami nem tűnik fel. Nem tudnál jsfiddle-re vagy máshova felrakni egy példakódot, azzal a konkrét legenerált tartalommal, ami a tiéd?
Mondjuk az oldalon, amit linkeltél, szerepelt egy jsFiddle-link: [link].(#7782) biker: hmm, hát ez tanulságos. És akkor hogy oldod meg ilyen esetekre a kérdést?
-
#7780
Sk8erPeter
nagyúr
meone
#7779
Sk8erPeter
nagyúr
Mondjuk annyi különbség tűnt fel, hogy a linkelt JSON-fájlban úgy van meg a tartalom, hogy ezek zárójelek közé vannak ékelve (meg kérdőjel az elején):
?( // itt kezdődik...
[ // ez már a tiéd
[1314347520000, 30.8],
[1314348120000, 30.1],
......................
]
);Nem tudom, ez okoz-e igazán releváns különbséget, de nem tartom elképzelhetetlennek...
Ha a belinkelt fájlt teszed be a getJSON-be a sajátod helyett, akkor azzal működik? -
#7778
Sk8erPeter
nagyúr
meone
#7776
Sk8erPeter
nagyúr
Valószínűleg helytelen a formátuma a JSON-nek, amit kinyomsz, ezért nem tudja feldolgozni, és úgy tűnik, nincs megoldva a rendes hibakezelés, hogy egyértelmű legyen a hiba oka.
Itt a példa JSON-fájl: [link], ilyesmit kellene kiíratnod.
Rakd fel mondjuk pastebinre, hogy Te mit kapsz, milyen formátumú lesz az általad kiíratott $out változó kimenete, hátha abban megtaláljuk a hibát.
--
Még egy gyors megjegyzés:
echo "http://localhost/megj/Hs/examples/basic-line/cucc.php";
Soha ne használj ilyen szinten kötött címeket!! Mi van, ha már költözteted egy éles szerverre a cuccaidat, akkor mindenhol majd szépen kicserélgeted a "http://localhost" címet? Nagyon kényelmetlen megoldás. Ne legyen benne a domain, se a protokoll (http/https). Ez nyugodtan lehetne pl. simán "/megj/Hs/examples/basic-line/cucc.php" (a localhostos rész nélkül), ha már - localhoston - szerverről futtatod. -
#7773
Sk8erPeter
nagyúr
wolandino
#7769
Sk8erPeter
nagyúr
válasz
wolandino
#7769
üzenetére
"ezért nem akartam betenni, mert ha kiszedem az ordert úgy ahogy van, akkor se sokkal jobb a helyzet, 15 mp körüli."
Ezek szerint nem jött át, mire jó az EXPLAIN... Azért akartuk látni, mert hátha ott MEGMAGYARÁZZA, hogy mi is az oka, hogy ilyen lassú fostalicska..."és nem szeretnék olyan lekérdezést tenni az alkalmazásba, ami több mint fél másodperc, mert engem már nagyon szokott idegesíteni, amikor többet kell várni."
Hát vazze, miért, szerinted az a normális, hogy max. fél másodperc legyen egy 150 ezres agyonrendezgetett adatmennyiség fájlba (???? ezt sem írtad) exportálása? Komoly adatbázisszervereknél simán, de az nem kevés teljesítményre képes akkor. 15 mp tényleg sok, ezen lehet faragni. De nehogy már napi probléma legyen (vagy ha az, fusson időzítve), és bárki pampogjon egy kicsit több idő miatt, pár másodpercet tud várni, amikor nem kis adatmennyiség kiírásáról van szó...Mellesleg nem értelek, segítséget kérsz, akkor miért kell ennyire fukarkodni az infókkal. Gondolhatod, hogy nem ebből fogunk itt meggazdagodni, hogy beraksz egy komplett screenshotot az explainről... meg különösebben senkit nem érdekelnek az adataid, csak segíteni szeretnénk megoldani a problémádat.
-
#7763
Sk8erPeter
nagyúr
Speeedfire
#7762
Sk8erPeter
nagyúr
válasz
Speeedfire
#7762
üzenetére
Kivételesen ebben tényleg találtam említésre méltó tippeket, pedig nagyon sokszor haszontalanok ezek a "100 tipp arról, hogyan tudsz minél több időt elkúrni ennek a cikknek az elolvasásával"-jellegű rovatok.
-
#7759
Sk8erPeter
nagyúr
wolandino
#7745
Sk8erPeter
nagyúr
válasz
wolandino
#7745
üzenetére
"explaint is nyomtam:
150k-s tábla 150k lekérdezést ad"
És ez önmagában miért lenne bizonyíték arra, hogy jók az indexek? Nem értem a logikát."Az indexek rendben vannak."
Ezt honnan veszed? Esélyes, hogy mégsincsenek rendben, azért lassú a query.A többire: ha rejtélyeskedsz, és a lehető legkevesebb infót adod arról, hogy mi, miért, hogyan van megoldva, akkor nem fogunk tudni segíteni... lehetőleg ne tőmondatokban válaszolj, hanem írj le mindent részletesen, akkor érdemi segítséget is tudunk adni.
Pl. hadd lássunk már legalább részletet a query-ből (pastebinre fel tudod nyomni), meg elárulhatnád, milyen mezőid vannak, mi szerint indexeltél.Egyébként az exportálás nem időzítve, cronnal történik? Hanem egy felhasználói felületen?
Mert ha ilyen szinten sok adat van, és úgyis csak exportálás céljára használod, akkor a felhasználó ne sírjon, ha 150k adatra többet kell várnia... Nyilván nem félnaponta exportálgatod az adatokat.
A "chart" alatt itt most mit értesz? Egy Excel-fájlt? Legalábbis remélhetőleg nem egy felhasználói felületen megjelenő valamit...===
(#7747) Speeedfire : Itt is ír az EXPLAIN-ről és sok hasznos trükkről: [link] (azért linkelem megint ezt a cikket, mert kivételesen nem egy terjengős, felesleges idióta tippekkel teli cikkről van szó...)
-
#7720
Sk8erPeter
nagyúr
biker
#7719
Sk8erPeter
nagyúr
Szerkesztettem még a hsz.-t, hozzácsaptam még linkeket, lásd a hsz. végét, hátha azoknak hasznát veszed.
Lehet, hogy ez is f@szság lesz, de itt ezt írják: [link]
"unfortunately InnoDB does not support FULLTEXT indices, so sometimes it is not an option…"
Nem lehet, hogy véletlenül a tábla szerkezetét átállítottad?Na, már megint egy: [link]
"Watch out for the VARIABLE ft_min_word_len -- it defaults to 4."
-
#7718
Sk8erPeter
nagyúr
Sk8erPeter
#7717
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#7717
üzenetére
Itt is hasonló van:
"If you modify full-text variables that affect indexing (ft_min_word_len, ft_max_word_len, or ft_stopword_file), or if you change the stopword file itself, you must rebuild your FULLTEXT indexes after making the changes and restarting the server. To rebuild the indexes in this case, it is sufficient to do a QUICK repair operation:
mysql> REPAIR TABLE tbl_name QUICK;Alternatively, use ALTER TABLE with the DROP INDEX and ADD INDEX options to drop and re-create each FULLTEXT index. In some cases, this may be faster than a repair operation.
Each table that contains any FULLTEXT index must be repaired as just shown. Otherwise, queries for the table may yield incorrect results, and modifications to the table will cause the server to see the table as corrupt and in need of repair."
==
Még ezt is nézd meg a témában: [link], [link], [link] (alul, az incorrect results rész) -
#7717
Sk8erPeter
nagyúr
biker
#7716
Sk8erPeter
nagyúr
Lehet, hogy oltári nagy f@szság, de nem lehet, hogy REPAIR-elni kellene a table-öket? (de szépen hangzott
)
csak mert itt van ilyen, egy változó megváltoztatásánál:
[link]
"FULLTEXT indexes must be rebuilt after changing this variable. Use REPAIR TABLE tbl_name QUICK."
Mondom, lehet, hogy ennek semmi köze ehhez, csak egy próbálkozás...itt mondjuk nagyobb verzióra upgrade-elésről van szó, de itt is hasonlót írnak, hogy esetleg REPAIR kell, ha hülye eredményeket kapsz: [link]
"Incompatible change: For utf8 columns, the full-text parser incorrectly considered several nonword punctuation and whitespace characters as word characters, causing some searches to return incorrect results. The fix involves a change to the full-text parser in MySQL 5.1.12, so as of 5.1.12, any tables that have FULLTEXT indexes on utf8 columns must be repaired with REPAIR TABLE:
REPAIR TABLE tbl_name QUICK;" -
#7710
Sk8erPeter
nagyúr
Speeedfire
#7708
Sk8erPeter
nagyúr
válasz
Speeedfire
#7708
üzenetére
Hát simán lehet, honnan tudjam
-
#7707
Sk8erPeter
nagyúr
Speeedfire
#7706
Sk8erPeter
nagyúr
válasz
Speeedfire
#7706
üzenetére
Most már semmi, ezek szerint sikerült megcsinálnia.
Tegnap még a szokásos Newhostingos átirányítós oldalt lehetett ugyanitt látni.mobal: na, végül mi volt a megoldás?
-
#7705
Sk8erPeter
nagyúr
mobal
#7701
Sk8erPeter
nagyúr
Hát először azt nézd meg, hogy egy bármilyen index.php-vel ("Hello world") működik-e... Kétlem, hogy a Yii lenne a hibás, vagy ha mégis, akkor legalább valami hibát ki kéne írnia. Szerintem valamiért továbbra sem elérhető az index.php a yii-vel kezdődő aldomainen, azért rinyál.
(#7703) biker : ezt is próbáltam, annak idején ezt sem tudtam megszeretni annyira a kis erőforrásigényű progik közül, mint a Notepad++-t - de adok neki még egy esélyt, majd megnézem még.
-
#7700
Sk8erPeter
nagyúr
mobal
#7699
Sk8erPeter
nagyúr
Gondolom arra gondolsz, hogy milyen a sortörés, Windows-os (\r\n), vagy UNIX-os (\n).
"Valami oknál fogva én a Linuxot pártolom."
Most itt nem tudom, általánosságban beszélsz-e, vagy konkrétan a sortörésekre gondolsz, de szerintem érdemes inkább a Windows-kompatibilis \r\n-t használni.
Bár gondolom normális ember nem nézeget forráskódot sima Notepadben (HOGY MICSODÁBAN??) manapság. 
Szerk.:
hát ennyiből kicsit nehéz lenne megállapítani, miért nem megy az a domain...
Az is lehet, hogy nincs index.php rajta, vagy ... nem vágom.
Mindenesetre nem is dobál hibát jelző headereket (sőt, 200 OK-t dob), most néztem meg developer tools-zal. -
#7698
Sk8erPeter
nagyúr
mobal
#7697
Sk8erPeter
nagyúr
Hát ne tőlem kérdezd, nem nálam van a probléma, egyébként meg a BOM-ra már én is rákérdeztem az imént, bár arra választ nem kaptam.
(#7695) biker : a Notepad++ tele van igen hasznos karakterformázó, -átalakító pluginekkel, amire szintén nem találtam alternatívát.
Meg az alap szintaktikakiemelése is áttekinthető, bár azt még le lehet "másolni" (beállítani azoknak a színeknek megfelelően, bár tökölős) a többi programhoz is.
Meg ott a konverzió ANSI-ra, UTF-8-ra, meg mittudomén, csomó minden van, ami nincs meg a hasonló kategóriájú Linuxos progikban (legalábbis amiket eddig találtam, elég sok), ami most úgysem fog eszembe jutni, mondjuk annyira nem is akarom törni a fejem rajta. -
#7694
Sk8erPeter
nagyúr
biker
#7692
Sk8erPeter
nagyúr
speciel a Notepad++ egy nagyon hasznos program, egy nagy hibája, hogy sajnos csak Windows-alapú. Van, hogy Linuxon is Wine-nal használom, mert a legtöbb Linuxos szövegszerkesztő nem tetszik, és/vagy nem olyan funkciógazdag, mint a Notepad++. (ha nem memóriazabáló programokról beszélünk, mint a NetBeans, ami szintén fasza, de durván erőforrásigényes, a szolgáltatásokért cserébe, amit nyújt)
A karakterkódolás elcsesződésének okára most hirtelen nincs konkrét ötletem, körül kéne nézni a szerver beállításainál, nincs-e .htaccess-es vagy globális szerveroldali felülbírálás, vagy bármi, ami az éles szerveren beleszól a folyamatba, a localhostos szerveren meg nem. Valami különbség biztos van.
-
#7691
Sk8erPeter
nagyúr
biker
#7690
Sk8erPeter
nagyúr
hmm, hát ez fura. És még nem derült ki az oka, hogy miért csesződik el?
Amúgy a Notepad++-ban van sima UTF8-kódolásra átkapcsolás, meg konvertálás is. Ha az előbbit választja az ember fia, akkor az esetek többségében elkúródik a kódolás.
De gondolom nem ez a para.
Valami beállítás mégis eltérhet.
Ja, amúgy BOM nélküli UTF-8 minden fájl esetén?
Milyen szerver van egyik ill. másik tárhelyen?Ja, sokszor előfordulhat, hogy eszedbe jut valami nem épp a legaktívabb meló közben, és módosítanád, úgy, hogy nem vagy gépednél, akkor meg nagyon nem praktikus a localhostos módszer.
-
#7689
Sk8erPeter
nagyúr
Peter Kiss
#7686
Sk8erPeter
nagyúr
válasz
Peter Kiss
#7686
üzenetére
"Másik, hogy nem a tárhelyen kellene fejleszteni."
Semmi baj nincs a tárhelyen való fejlesztéssel, ha még nem élesben fut a projekt. Annyiból legalábbis jó, hogy akkor tuti, hogy a tesztkörnyezet megegyezik az éles környezettel.
Persze tény, jobb localhoston próbálgatni, de akkor meg az a szopás, hogy ha nem vagy saját gépnél, nem tudsz bárhonnan dolgozni. Vagy külön tárhelyet tartasz fenn a fejlesztési céloknak.
Én most épp utóbbit választottam egy projektnél, így bárhonnan tudok dolgozni, és van egy jól működő szerver mögötte. Ez úgysem megy ki élesbe.
Windows-on WinSCP-t használok, Ubuntu alatt meg becsatolom a távoli könyvtárat Nautilus-ba, így a fájlokon történő módosítások mentése egyből szinkronizálódik a szerverre is. Ez így nagyon kényelmes.
Persze ha nagyon kell, akkor localhoston nyomatom.===
(#7682) D@ni88 :
Athlon64+ kérdése teljesen jogos volt, ha már OOP, annál is kellene maradni.
- Akkor már [link]
$mysqli = new mysqli('localhost', 'my_user', 'my_password', 'my_db');
- ugyanezen a linken van egy példaosztály is a leszármaztatásra:
class foo_mysqli extends mysqli {
public function __construct($host, $user, $pass, $db) {
parent::__construct($host, $user, $pass, $db);
if (mysqli_connect_error()) {
die('Connect Error (' . mysqli_connect_errno() . ') '
. mysqli_connect_error());
}
}
}
$db = new foo_mysqli('localhost', 'my_user', 'my_password', 'my_db');
echo 'Success... ' . $db->host_info . "\n";
$db->close();- tulajdonképpen feleslegesen nevezed el select()-nek a metódust, ugyanoda nyugodtan be lehetne adni akár UPDATE, INSERT utasításokat is... Ha már wrapper vagy ORM-hez hasonló osztályt szeretnél írni, akkor írd is meg úgy, vagy ne erőltesd: a mysqli egy osztály, tehát nyugodtan felhasználhatnád annak az objektumorientáltságát.
- ezentúl én azt javasolnám, hogy használd inkább a PDO-t: [link], [link]
Egyrészt tök logikus a használata, másrészt OOP-s, harmadrészt ezzel sokkal rugalmasabb a kódod, ugyanis akár későbbiekben is átállhatsz más adatbázisra, hasonló szintaktikával (rosszabb esetben csak a query-ket kell átírni a másik adatbázisnak megfelelően, de legalább magát a lekérdezés módját nem - míg ebben az esetben az összes mysqli_*-vel kezdődőt le kell cserélni).- hibajelzés:
ini_set('error_reporting', E_ALL|E_STRICT); -
#7677
Sk8erPeter
nagyúr
wolandino
#7675
Sk8erPeter
nagyúr
válasz
wolandino
#7675
üzenetére
Szívesen!
Hmm, hát ez fura. A phpmyadmin nem szokott ilyen lassú lenni. Amúgy milyen szerveren van a cuccotok? Apache?
Az 1280M beállításban biztos vagy? Nem véletlenül szokták lent tartani mondjuk 128M-nál, hanem "önvédelemből" is, nem túl jó, ha a kódod annál többet kajál... Persze egy-kétszer elmegy, de akkor is legfeljebb a duplájára állítsd, ne a 10x-esére... -
#7671
Sk8erPeter
nagyúr
wolandino
#7667
Sk8erPeter
nagyúr
válasz
wolandino
#7667
üzenetére
"Az egyik ismerősöm szerint azért lehet, mert az easyphp amit használok nagyon kevés cache-t enged a mysql-nek, és ezért lassú."
Hogy ismerősödet korrigáljam, az EasyPHP-nek ehhez legfeljebb annyiból van köze, hogy milyen default beállításokat tartalmaz a benne foglalt MySQL- és PHP-konfiguráció... Ezt viszont úgy bírálod felül, ahogy akarod. Fogod a my.ini, illetve php.ini fájlt, és tetszés szerint átkonfigurálod.
Az EasyPHP azért nem hibás, hogy bizonyos default beállításokkal érkezik, ha külön-külön telepíted a MySQL-t, PHP-t, azt is pontosan ugyanúgy át kell állítgatni igény szerint.
Az EasyPHP viszont kicsit megkönnyíti a dolgodat, monitorozza egy minta php.ini fájlban a változásokat, és aszerint módosít egy másik fájlt, amit végül is a PHP figyelembe vesz. Aztán újraindítod az Apache-ot, és megvagy.
Vagy ha my.ini-n változtattál, újraindítod a MySQL-t, hogy érvénybe lépjenek a változások.
Ehhez az EasyPHP kínál egy admin-felületet, hogy ezeket az újraindítgatásokat megtehesd (megteheted services.msc-ből is, amennyiben szolgáltatásként vannak telepítve a szerverek).Érdemes lehet beállítani MySQL-ben a query cache-t, valami ilyesmi módon:
query_cache_size = 268435456
query_cache_type=1
query_cache_limit=1048576Elvileg így legalábbis kihasználhatja néhány lekérdezésed a query cache szolgáltatást.
Itt van egy-két trükk még MySQL-hez: [link]. Itt megmutatja azt is, hogy érdemes néha az EXPLAIN-t használni, hogy megkukkantsd, hol lassú esetleg a lekérdezés, pl. valahol nincs indexelve egy mező.(#7668) wolandino: ezt írja: "Allowed memory size of 134217728 bytes exhausted". Eszerint 134217728 byte = 128 MB memória van beállítva nálad. Ezt lépte túl. Az a memóriahasználat sok. Valami nem stimmel a kódodban, ha ennyire leakel. Vagy óriásképeket kezelsz, vagy nem vágom...
-
#7670
Sk8erPeter
nagyúr
biker
#7663
Sk8erPeter
nagyúr
Mondjuk a még szebb egy prepared statement lenne: [link], de ezt már nem is mertem említeni, mert az a kód úgyis szerteszéjjel van szórva hibákkal...
Amúgy amikor tanultam a PHP-t, én is a mysql_real_escape_string, mysql_query és hasonlókkal szopattam magam, mert a net tele van ilyen példákkal, többek közt azért, mert a PHP 4-es verziójában még nem volt OOP. Nincs nagy baj ezekkel a függvényekkel, csak az, hogy sokkal nehézkesebb: az ilyen wrapperclass-szerűségek (a PDO is olyan, mint egyfajta wrapper a különböző adatbázisokhoz tartozó műveletekhez) használata ezerszer praktikusabb lehet, ráadásul ha a fenti linket bárki megnézi, igazából a szintaktikája sem bonyolultabb, mint egy mysql_* függvényhasználatnak, csak ehhez kell szoktatnia magát az embernek.
Plusz a PDO a "hagyományos" hibakezelést elkerülendő már kivételek dobálására is képes, míg a mysql_* függvényeknél ezeket a hibákat a megfelelő módon - elég macerásan - le kell tudni kezelni. Hozzáállás kérdése, de így utólag már azt mondom, gány. Visszanézem pár évvel ezelőtti kódjaimat, és fogom a fejem, hogy mennyivel egyszerűbben is lehetett volna csinálni dolgokat.
Amúgy a legjobb az adatbázisok kezeléséhez még mindig az ORM-ek használata. Ezt már kicsit nehezebb lehet eleinte megtanulni, de megtérül.Bár sokan szidják az OOP-s megközelítést, hogy az nem jó, mert lassú... bullshit! Normális esetben nem észrevehető a különbség. Bár biztos vannak, akiknek feltűnik pár ezred/századmásodperces eltérés a betöltési időben...
Ja, amúgy ez most nem konkrétan neked szólt, hanem csak úgy általánosságban.
A post írása közben mindenfélék eszembe jutottak még a témával kapcsolatban, szerencse, hogy megálljt parancsoltam az írókámnak. -
#7650
Sk8erPeter
nagyúr
Speeedfire
#7643
Sk8erPeter
nagyúr
válasz
Speeedfire
#7643
üzenetére
"Ip, ország, böngésző, url, ahonnan jött url stbstb."
Ja, kábé ezek az adatok is kellenek. Az ország kivételével, bár utólag azt is megtudhatod IP alapján, ha nagyon akarod: [link]. De ez most nem kell neked.
Egyébként kicsit túlmisztifikálod ezt a plusz 5-6 mezőnyi letárolást. Még két tábla sem kell, ha nem feltétlenül akarod összekötni a júzerekkel az IP-címüket... bár azt is megteheted, pl. az első mező a uid, és anonim (nem bejelentkezett) user id-ja meg a 0. De ahogy elnézem, Te totál egyszerűt szeretnél, tehát kell neked a $_SERVER tömbön belül a 'REMOTE_ADDR' ($_SERVER['REMOTE_ADDR']), 'HTTP_REFERER', 'HTTP_USER_AGENT', esetleg 'REQUEST_URI', meg ami tetszik... Ezek a felsoroltak fontosak lehetnek. Meg természetesen egy időmező (default CURRENT_TIMESTAMP értékkel! Így ezzel sem kell foglalkozni, explicite értéket hozzárendelni, mert alapból kap egy értéket. Bár a query cache miatt elvileg jobb lenne PHP-vel átadni neki, de itt tök mindegy sztem...) Ráadásul így aszerint is tudnál szűrni, hogy mondjuk keresőrobot kereste-e fel az oldaladat, vagy akár spammotor. Szóval nem egy olyan nagy csoda ez, egy tábla, azt' kész. Nincs itt semmi mini Google Analytics. -
#7641
Sk8erPeter
nagyúr
Speeedfire
#7640
Sk8erPeter
nagyúr
válasz
Speeedfire
#7640
üzenetére
Ja, most értettem meg, hogy ezek szerint tulajdonképpen lesz@rod, hogy még egyszer bekerül, még ha ugyanaz a felhasználó nézi is meg...
Mivel pont Te írtad le, hogy az fog történni, hogy session megszűnése után már újabb látogatónak számít... ("Ha kilép a böngészőből és 20 perc múlva megint felmegy akkor az már még 1, még ha az ip ugyan az is.") Azt hittem, pont azt szeretnéd, hogy ez ne így történjen, legalábbis így volt értelmezhető, amit írtál..."Nem akarok több 100 táblát egy sima statisztika miatt."
Nem igazán látom be, miért lenne szükség többszáz táblára emiatt?
Igazából több táblára sincs feltétlenül szükség.
Vagy ez költői túlzás akart lenni? A többszáz bejegyzés még stimmel, de ki a francot érdekel, ha többszáz sor van egy adatbázisban, rég rossz lenne, ha nem lehetne könnyen és gyorsan kezelhető... -
#7639
Sk8erPeter
nagyúr
Speeedfire
#7637
Sk8erPeter
nagyúr
válasz
Speeedfire
#7637
üzenetére
Akkor ezek szerint pont Te írtad az ellenkezőjét, amikor azt írtad, hogy "ha 5x megy fel akkor 5x kellene bekerülnie a táblába", és pont ezért borult az egész logikája...
mert ezek szerint ha most fix IP-ről beszélünk, akkor pont, hogy 1x kellene bekerülnie a táblába.
A dinamikus IP pedig (épp a session megszűnése miatt) - szopás. Ilyen esetben le kell tárolnod egy cookie-t hosszú lejárati idővel (miért olyan nagy para ez? Akkor gond, ha törli a júzer), meg session.cookie-lifetime (ez is sütialapú végül is). Itt van egy topic amúgy a session lejárati idejéről: [link]. -
#7636
Sk8erPeter
nagyúr
Speeedfire
#7623
Sk8erPeter
nagyúr
válasz
Speeedfire
#7623
üzenetére
Na várj, akkor most mit is szeretnél? Nekem legalábbis őszintén szólva ellentmondásos, amit írsz.
Először azt írtad, nem akarod, hogy csak a lap minden egyes betöltését számolja. Aztán azt írod, hogy nem 1x kéne eltárolnia júzerenként, hogy hányszor látogatott meg egy lapot, hanem ha 5x ment fel, akkor 5x tárolja el. Aztán írod, hogy "Viszont ha csak kattintgat ide-oda az oldalon akkor az 1nek számítsa." Most akkó' mi va'? -
#7609
Sk8erPeter
nagyúr
lafaty80
#7599
Sk8erPeter
nagyúr
válasz
lafaty80
#7599
üzenetére
Akkor örülök, hogy segíthettem.
(#7598) letix : nincs mit, írj, ha elakadtál, szerintem akár kész scriptekkel is tudunk szolgálni. Meg azt is meg tudjuk mutatni, hogy a sessionben hogy tárold, hogy adott júzer adatai már el vannak mentve (ne legyen még egyszer).
(#7597) Speeedfire : végül is megszokás kérdése, hogy melyik feldolgozás egyszerűbb.
Ez is szemlélet kérdése: vannak, akik azt vallják, hogy pl. egy MySQL- (vagy más alapon működő) adatbázis szolgáljon csak puszta adattárolásra, ne legyen feladata (bonyolultabb) számítások elvégzése, azt bízzuk rá más szerveroldali nyelvre. Lehet akár még inkább csökkenteni az adatbázisra bízott feladatokat a query cache kihasználásával is, lásd itt az első tippet: [link] (meg a többit, érdemes megfontolni őket).
Máshol komplex tárolt eljárásokat használnak, összetett lekérdezéseket, bonyolult számításokat végeznek adatbázis oldalon.
Tulajdonképpen nehéz eldönteni, melyik a jobb megközelítés, mindkettőnek van előnye és nyilván hátránya is. Attól is függ, lehet-e kellőképpen terhelni az adatbázisszervert, stb... -
#7596
Sk8erPeter
nagyúr
Speeedfire
#7594
Sk8erPeter
nagyúr
válasz
Speeedfire
#7594
üzenetére
Nem is rossz ötlet.
==
Más:
ez nem is egy túl komplex lekérdezés (meg gondolom csak valami szemléltető példa, nem?), az a durva, amikor valaki többszáz soros lekérdezésekkel bíbelődik===
(#7595) lafaty80 : ennek örülök, mondjuk gondolom az én hozzászólásomtól függetlenül csináltad, de akkor végül beigazolódott, amit az utóbbi két linkben írtak, hogy a dll kicserélése megoldja. Nincs mit! -
#7593
Sk8erPeter
nagyúr
Speeedfire
#7590
Sk8erPeter
nagyúr
válasz
Speeedfire
#7590
üzenetére
"érdemes lenne mellé egy dátum mező és a végén csak szummázni kellene az adatokat."
Pontosan ez a jó megoldás.
Ezerszer jobb, mintha ahhoz hasonló lenne, ahogy most csinálja fájlba írással, hogy mondjuk lenne egy táblája, abban egyetlen mező, és mindig azt update-elgetné... az nagyon gáz. Inkább legyen több(száz)ezer sora, amit század(/ezred)másodpercek alatt megszámol az adatbázisszerver, mint hogy egyetlen mezőbe gányolgasson. Ráadásul így sokkal bőbeszédűbb az adatnyilvántartása, és nem nagyobb meló megcsinálni (csak kb. 5 perccel )."Csakhogy ezt a google sokkal szebben megcsinálja."
Na de a JavaScript nem mindenkinél van engedélyezve. Tudom, azok dögöljenek meg. De ha saját nyilvántartás kell, és tényleg mindenkit (keresőrobotokat, spammereket, stb. is, amiknél mondjuk tényleg nincs engedélyezve a JS) nyilván akar tartani, akkor nem árthat PLUSZBAN egy ilyen megoldás. -
#7591
Sk8erPeter
nagyúr
lafaty80
#7589
Sk8erPeter
nagyúr
válasz
lafaty80
#7589
üzenetére
Itt elég sok ötletelés van az általad bemásolt hibával kapcsolatban: [mssql_connect()], keress rá, igazából sajnos egész pontosan én sem tudom, mi lehet a gond nálad, de remélhetőleg ezek közül valamelyik tanács megoldja. Vagy itt egy dll kicseréléséről beszél: [link], itt szintén: [link].
Majd írj, sikerült-e valamelyik... -
#7588
Sk8erPeter
nagyúr
lafaty80
#7582
Sk8erPeter
nagyúr
válasz
lafaty80
#7582
üzenetére
Ja OK, így már világos. Igazából ez volt a lényeg, hogy akkor tök különböző gépeken vannak az adatbázisszerverek, meg az Apache+PHP, és kívülről szeretnél csatlakozni az adatbázisszerverekhez, mindez saját Windows 7-es gépeddel ezek szerint mindkét db-szerverhez teljesen jól sikerül, míg Win2003 R2 SP2 x86 esetén a 64 bites MSSQL-szerverhez nem. De egész konkrétan mi a hibaüzenet, mit kapsz rá? A "nem működik"-nél gondolom kicsit bővebbet.
-
#7587
Sk8erPeter
nagyúr
letix
#7584
Sk8erPeter
nagyúr
Szia!
Igen, mindenképp működjön SQL-alapokon. A tárhelyszolgáltatók többsége eleve biztosít MySQL-hozzáférést ingyenesen (általában phpMyAdmin-felülettel együtt), nálad van ilyen? (persze jelszóval, felhasználónévvel)
Ha igen, akkor kellene egy `visitors` tábla, auto_increment id-val (melyik sor), látogatási dátumhoz, IP-cím tárolásához tartozó mezővel, esetleg user agent nyilvántartásához tartozó mezővel (most hirtelen más nem jut eszembe). Ez alapján már sok szempont szerint nyilván tudod tartani a látogatóid adatait.
Amikor új látogató érkezik az oldalra, egyszerűen hozzáadsz egy sort ehhez a táblához, eltárolod $_SESSION változóban (session_start() után), hogy az ő látogatási adatai az adott munkamenetre vonatkozóan már el vannak tárolva, aztán az adatbázisban a látogatók táblájában eddig található sorokat összegezve kiíratod, így megtudod, hány látogatód volt eddig.Először derítsd ki, MySQL-adatbáziskapcsolattal rendelkezel-e, aztán segítünk a dolog technikai részében!
Egyébként a korábbi kódodban nem látok sessionben való tárolást, hogy az adott felhasználó "látogatását" legalább a munkamenet erejéig elmentetted, így elméletileg ez alapján minden egyes felhasználói oldalfrissítés növelte a fájlban található változó (látogatottságot mutató szám) értékét. Hacsak nem oldottad meg valami kerülő módszerrel...
===
(#7586) Speeedfire :
"szerintem itt felesleges lenne egy id"
Szerintem meg ritkább az, amikor ne lenne hasznos egy valamilyen szintű egyediséget jelölő id. Például kapcsolótábláknál nyilván nem feltétlenül kell (bár persze ártani nem használ ), de a látogatók tárolására szolgáló táblákban legyen má'. -
#7581
Sk8erPeter
nagyúr
letix
#7578
Sk8erPeter
nagyúr
Napi átlag 80-180 látogatónál szerintem már bőven érdemes megfontolni az átállást adatbázisban való nyilvántartásra. Ilyenekre is lehet találni tonnányi kész kódot a neten. Cserébe egy fokkal (inkább sokkal) megbízhatóbb lesz a nyilvántartásod, mint sok-sok fájlba írogatással.
-
#7580
Sk8erPeter
nagyúr
lafaty80
#7573
Sk8erPeter
nagyúr
válasz
lafaty80
#7573
üzenetére
Most számomra már nem kicsit zavaros a dolog. Kezdjük elölről. Akkor most hol van a 64 bites MSSQL szerver? Nyilván nem a Win2003 x86-on, nem is a saját Win7 x86-osodon. Akkor hol? Most akkor egy külső adatbázisszervert akarsz elérni saját gépről? Tehát maga az adatbázisszerver fut gond nélkül a saját helyén, de Te kívülről akarsz csatlakozni hozzá? Vagy mi va'? Kicsit egyértelműbben légyszi...
-
#7579
Sk8erPeter
nagyúr
Tele von Zsinór
#7572
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#7572
üzenetére
Én egy éles szerverre felraktam a XAMPP-ot, és megfelelően konfiguráltam.
"Részben igen, részben pedig mert ezek fejlesztői gépre kitalált csomagok, ennek megfelelő biztonsági beállításokkal."
Nem igazán értem, miért okozna több kínszenvedést ezeknek a kész csomagoknak az utólagos biztonsági beállítása, mint ha minden egyes összetevőt külön-külön raksz fel? Biztonsági szempontból szerintem pontosan ugyanannyi beállítást igényel mindkét megoldás. Csak annyi különbséggel, hogy ezekben a kész csomagokban ott van az összes általában szükséges dll (ami nincs benne, nyilván ritkábban kell, így külön erőfeszítés), nagy valószínűséggel azok a konfigfájlok is megvannak (legalább félkészen, vagy van benne egy minta), amiket alapvetően neked kéne megírni, beállítgatni egyenként - így meg ott van készen, csak módosítani kell, kevesebb az esély, hogy elcseszed. Ami meg neked nem kell az eredeti fájlokból, egyszerűen kommentezed, vagy törlöd.
Példa: Apache HTTP Servert kellett összehoznom Tomcat szerverrel. Alapból a kettő összehozásához konfigfájlokban való pötyögésre van szükség, sok szerverújraindítgatásra, próbálgatásra, anyázásra (jó, ez igaz, hogy az első igazán jó beállításig tart, amíg már órák árán sikerül megtanulnod, korábban mit kúrtál el), míg ha felraksz egy újabb XAMPP-ot, ott eleve adott a Tomcat "add-on", a megfelelő beállításokkal, meg egy működő mintával, amit már csak saját szád ízére kell átalakítani.
Szóval szerintem mindkét megoldásban oda kell figyelni a biztonsági résekre.
Persze a kész csomagok néha több összetevőt is tartalmazhatnak, mint amire alapvetően szükséged van, ezért azokra az összetevőkre is oda kell figyelni, hogy megfelelően legyenek konfigurálva - vagy egyszerűen kiszedni őket, és kész.Amúgy milyen grafikus felületről beszélünk? A XAMPP és az EasyPHP esetén is van egyetlen külön adminfelület-féleség, amin elindíthatod a service-eket, de ennyi. Meg hát a localhostos próbaoldal, amin csekkolhatod a beállításokat (és nem a default "It works!" felirat fogad), de az nem egy komoly grafikus felület.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Gondolom azt a szót keresed, hogy "lokális" változó.
Esetleg valami konkrétabb?
Az sok lesz már egy kicsit. 
)
Új hozzászólás Aktív témák
Hirdetés
- Samsung Galaxy S23 , 8/128GB, Kártyafüggetlen
- Csere-Beszámítás! MSI Gaming X RTX 4060Ti 16GB GDRR6 Videokártya!
- REFURBISHED és ÚJ - HP USB-C/A Universal Dock G2 docking station (5TW13AA) (DisplayLink)
- DELL PowerEdge R730xd 12LFF+2SFF rack szerver - 2xE5-2680v3,64GB RAM,4x1GbE,H730 RAID v ZFS
- Apple iPhone 13 . 128GB , Kártyafüggetlen , 100% akku
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest