- Szárba szökken a Galaxy Buds 3 Pro
- Vodafone mobilszolgáltatások
- Az iPhone 15 frissítésgaranciát, a 16 szép rendereket kapott
- MIUI / HyperOS topik
- Google Pixel topik
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Android alkalmazások - szoftver kibeszélő topik
- Xiaomi Mi 11 Ultra - Circus Maximus
- KuKirin G4 - a sebesség ára
- Az Apple is mesterséges intelligenciával turbózza fel a teljes kínálatot
Hirdetés
-
Computex 2024: újfajta tápdizájn a Lian Li boszorkánykonyhájáról
ph Az L alakú Edge széria három kapacitással közeleg, és a legszerényebb variánsa kap egy picit olcsóbb kiadást, ami levehető mesh hálóval jön.
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
-
UbiForward24 - Jön az Anno 117: Pax Romana
gp Folytatódik a híres sorozat, jövőre egy teljesen új epizóddal jelentkeznek a készítők.
Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
"mivel máskor exportáltam ki xls-be, pdfbe táblátokat php-vel, és ott kellett mókolni a htacces file-okkal."
Ezekhez minek kell .htaccess fájl?Egyébként ha meg akarod kapni a választ a kérdésre, hogy valóban működik-e, akkor ugyan ne spórold már meg azt az 5 percet, míg kipróbálod az általam előbb linkelt dolgot... így csak szenvedés az egész probléma-megoldás.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
válasz Speeedfire #7415 üzenetére
mondjuk a fenti próbálkozások annak, aki már legalább egyszer csinálta, legfeljebb 15 percét veszik el, a support meg nem hinném, hogy ennyi idő alatt válaszol
Sk8erPeter
-
Sk8erPeter
nagyúr
Joggal. A supportjuk legalábbis katasztrófa. Én leveleztem párat egy ügyintézővel (elég gonosz lenne, ha beírnám ide a nevét ), és kifejezetten bunkó paraszt stílusa volt. Még neki állt feljebb, amikor nem teljesítettek valamit, amit vállaltak - konkrétan a rendelkezésre állással (volt, hogy órákra elment az oldal) és egy nameservercím-átirányítással volt probléma, és a reakció az volt, hogy ha nem tetszik, akkor válthatok szolgáltatót, és kábé menjek az anyámba. Persze akkor is vitatkozott az a f@sz, amikor később kiderült, hogy nekem van igazam. Hát gratulálok nekik, hogy így akarnak megtartani egy ügyfelet...
Ja, és a hivatkozási alap röviden összefoglalva: "ingyenesek vagyunk, tehát fogd be a pofád".(#7419) Speeedfire : majdnem egyszerre írtunk.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
"csinálnék egy sajátot"
Teljesen egyetértek cuckával, ez pont az a kategória, hogy egyáltalán nem éri meg sajátot írni, akármilyen nagy mókának is tartod így elsőre.
Elképesztő sok szopás árán fogsz írni egy olyat, ami még mindig tele van hibákkal és/vagy hiányosságokkal.
Ezentúl már csak azért sem éri meg sajátot írni, mert meglévő viszonylag népszerűbb keretrendszereket sem egyszerű elsajátítani, de az legalább ér is valamit a munkaerőpiacon.Sk8erPeter
-
Sk8erPeter
nagyúr
Bocs, de ezeket a lekezelő válaszaidat igazán mellőzhetnéd, főleg, ha nincs benne érdemi tartalom.
(#7464) haromegesz14 : én is ajánlom a Drupalt, bár még viszonylag gyakorlott PHP-snek is szívás eleinte jól megérteni a működését, modulokat írni, stb., de amikor rákapsz, onnantól nagyon beindul a szekér. Szerintem mindenképp megéri kipróbálni. Mondjuk én csak ezzel szereztem hosszabb távú tapasztalatot, a többi CMS-t csak futólag ismerem, de én többségi szavazatok alapján döntöttem a Drupal mellett (pl. a Joomlával szemben nagyon dicsérték - ez is régóta tartó vita, hogy Joomla vagy Drupal, de utóbbinak igényesebb a kódja, bár még mindig nem igazán objektumorientált. Ettől függetlenül én megszerettem.).
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Brown ügynök #7476 üzenetére
Teljesen felesleges a statikus, egyáltalán nem változó dolgokat is PHP-vel kiíratni.
Amit írtál, le lehetne egyszerűsíteni így:
<style type="text/css">
a img:focus, a img:hover, a img:active { background: #<?php echo $valtozo;?> }
</style>Sk8erPeter
-
Sk8erPeter
nagyúr
válasz daninet #7472 üzenetére
Nem ártott volna, ha leírod, hogy most ezt külön CSS-fájlban szeretnéd megvalósítani, vagy "inline" módon. Gondolom inkább utóbbi.
Akkor pl. lehetséges mód a kiíratásra:
<?php
function generateRandomColor(){
$randomcolor = '#' . strtoupper(dechex(rand(0,10000000)));
if (strlen($randomcolor) != 7){
$randomcolor = str_pad($randomcolor, 10, '0', STR_PAD_RIGHT);
$randomcolor = substr($randomcolor,0,7);
}
return $randomcolor;
}
// ....
?>
...
<head>
...
<style type="text/css">
a img:focus, a img:hover, a img:active { background: <?php echo generateRandomColor(); ?>; }
</style>
...
</head>
<body>
....Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #7473 üzenetére
"Ez nem lehet egyszerű dolog. Ha külön css fájlban a kivágott kód, legalábbis én nem tudok róla, hogy csináltak volna már ilyet."
Külső CSS-fájlnak megfelelő header küldése esetén nyugodtan megadhatsz PHP-fájlt is.
Példa:
...
<head>
...
<link href="ez_a_css_fajlod.php" type="text/css" rel="stylesheet" />
...
</head>
....A PHP-fájl tartalma meg a következő (daninet példakódját felhasználva):
ez_a_css_fajlod.php
<?php
header('Content-type: text/css');
function generateRandomColor(){
$randomcolor = '#' . strtoupper(dechex(rand(0,10000000)));
if (strlen($randomcolor) != 7){
$randomcolor = str_pad($randomcolor, 10, '0', STR_PAD_RIGHT);
$randomcolor = substr($randomcolor,0,7);
}
return $randomcolor;
}
$background_color = generateRandomColor();
$body_text_color = 'red';
?>
a img:focus, a img:hover, a img:active { background: <?php echo $background_color;?> }
body {
color:<?php echo $body_text_color;?>;
}Mondjuk gondolom kevésbé jellemző, hogy ilyet túl sűrűn alkalmaznának, de ez is működik!
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Brown ügynök #7489 üzenetére
Szerintem szebb megoldás, ha pl. egy PHP-tömböt json_encode-olsz, azt visszaadod a kliensoldalnak (JSON-formátumban), majd itt, a kliensoldalon generálod le az option elemeket is. Felesleges PHP-ra bízni a sok-sok sztring-konkatenálást, annak ebben az esetben csak annyi a feladata, hogy lekérje a megfelelő adatokat az adatbázisból.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Brown ügynök #7498 üzenetére
Én meg nem hiszem, hogy attól bonyolultabb lenne, hogy szebben valósítod meg, sőt.
Ha PHP-ben megcsináltad a konkatenálást, akkor ugyanezt megteheted kliensoldalon is, csak annyi a különbség, hogy akkor gyorsabb lesz, és kevesebb sávszélt kajál.
Annyi, hogy a JSON-nel visszakapott eredményhalmazt bejárod, és ciklikusan hozzácsapod az option tageket, ez miért lenne olyan bonyolult?
Egyébként nem mondtam, hogy hibás lenne az, amit csináltál, de van rá jobb módszer is."Szerintem tökéletes ahogy csináltam."
Ilyet fejlesztő nem mondhat, csak ha túl sok az egója! (nehogy megsértődj, csak viccelek, de sosincs tökéletes megoldás )===
(#7499) holinorby :
<td align="right"><?php echo $product_price ?><br />
</td>Itt nem túl szép megoldás, hogy beraksz egy <br />-t. Inkább növeld a paddinget CSS-sel, vagy hasonló, de így nem túl "rugalmas" a stílus átszabása.
===
(#7504) Alukard :
Ne mondd, hogy ez szebb megoldás, mint amit Brown ügynök mond, mert nem az.
Egyébként CMS-eknél nagyon sokszor egyszerűen adatbázisban tárolják az URL aliasokat. Valószínűleg a D@ni88 által linkelt oldalon is ugyanezt alkalmazzák.
Pl. Drupalnál van egy url_alias tábla az adatbázisban: ezek olyan címekre képeződnek le, mint pl. a node/30. Ez utóbbi cím meg már mod_rewrite segítségével képeződik le a megfelelő query stringgé, PHP-vel meg ezt dolgozzák fel, majd kiszedik adatbázisból a 30-as id-jú node tartalmát."Ja, majdnem lemaradt... egy szintén fontos apróság:
header("HTTP/1.1 200 OK");"
Ez meg mi a jó büdös francnak?
Eleve 200 OK állapotkódot kap a böngésződ abban az esetben, ha a kérés hibátlanul lefutott, ÉS a szerver nem küldött más status code-ot. Ergo ez a sorod teljesen felesleges!!===
(#7506) Alukard :
"De ez legalább több helyen működik mint a mod_rewrite -os megoldás. Sok esetben futottam bele abba, hogy vagy le volt tiltva vagy nem apache futott."
A 2. mondat első felére: ahol le van tiltva, ott szólni kell a rendszergazdának, vagy szolgáltatót váltani.
A második felére: nem csak Apache-on működik az URL-átírás... IIS-nél is működik a rewrite, lásd pl. ezt: [link].Jobb CMS-eknél van is támogatás hozzá, pl. Drupalnál, Joomlánál is van IIS-támogatás.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Peter Kiss #7508 üzenetére
De a 404-es állapotkódot nem véletlenül küldi vissza a szerver a kliensnek.
Pont ezzel jelzi a szerver, hogy a kért tartalom valamilyen okból nem található.
Nem is igazán látom be, mi értelme van erőszakosan megváltoztatni a 404-es állapotkódot 200 OK-ra...
Egy példa: http://drupal.org/asdasdasd
Ez a tartalom nyilván nem létezik, ki is írja a válaszban, hogy "Page not found", ÉS ezzel együtt 404-es HTTP-kódot küld vissza. Így is van ez rendjén!!Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Brown ügynök #7512 üzenetére
Addig becsülöd le a szerver által visszaküldendő adatmennyiség méretét, amíg nem kell komolyabb adathalmazt áttolnod a hálózaton... Egyébként nem is csak a végleges méretről beszéltem, hanem arról, hogy PHP-ben a sztringkonkatenálás lassú, tehát plusz időbe is kerül...ezért nem érdemes vele elvégeztetni ott, ahol totálisan felesleges.
...és de, kliensoldalon nagyon nagy valószínűséggel gyorsabban fogja előállítani a kis listádat, ha ráküldöd egy for ciklusra, hogy pakolja össze a kapott adathalmaz alapján.Amúgy ezeket ne vedd kötekedésnek, inkább szakmai vitának, amiről érdemes beszélni.
===
(#7513) Athlon64+ : megnézted, kinek címeztem azt a hozzászólást, amire válaszoltál? Nem neked.
Neked én EZT küldtem. És még egyszer mondom, totálisan felesleges explicite elküldeni a 200 OK állapotkódot, MINDIG ez lesz az állapotkód, ha a fájl hibátlanul elejétől a végig lefutott, legenerálta a kimenetét (vagy nem), a böngésző megkapta azt, ÉS nem volt semmilyen kifejezett egyéb állapotkód-küldés.===
(#7515) Alukard :"Ízlések és pofonok, lényegét tekintve most variációkat taglalunk egy témára, szerintem teljesen fölöslegesen"
Szerintem egyáltalán nem felesleges egy, a témát érintő fórumban átrágni a megoldási lehetőségeket, a különböző gondolkodásmódokat. Egymástól is tanulhatunk.Egyébként oké, érthető, ha semmiképp nem tudsz mod_rewrite-ot használni, akkor nyilván az egyéb lehetőségekről kell beszélni, épp azt is tesszük.
"amint később említve lett a 404es átirányítás végett"
Milyen átirányítás? Nincs itt semmiféle átirányítás. Az arra vonatkozó kódok a 3xx-esek.
És akkor ötvenedjére is elmondom, hogy ha nem létezik a fájl, és ezt jelezni akarod a kliens felé, attól még nem biztos, hogy jó megoldási módszer az, ha ennek ellenére kiadod a 200 OK-t, sőt, attól még lehet egyéni hibaoldalad, hogy 404-es hibakódot dobsz vissza...
Pont erre linkeltem a Drupalos oldalt: http://drupal.org/asdasdasd. Nézd meg mondjuk Firebuggal vagy ehhez hasonlóval, 404-et ad vissza a nem létező oldal miatt, mégis egyéni hibalapja van...[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz BullZeye #7547 üzenetére
Visszatérve a JavaScript topicból:
nem kötelező az adatbázis, de sokkal szebb lenne.
Megoldhatod akár XML- vagy JSON-fájlba írással is (most azért ezt a kettőt mondtam, mert ezek feldolgozásához, írásához nagyon jó eszközök állnak rendelkezésre).
JSON-fájl olvasásáról és írásáról itt írtam: [link].
Azt szeretnéd tehát beállítani, hogy mondjuk adott sorozat adott epizódját (vagy évadját) már láttad-e, így az erre vonatkozó adatot módosíthatod a JSON beolvasása után, majd újból fájlba írhatod a módosult adatokat (felülírva mondjuk a korábbi fájlt). Ennél egyszerűbbet nehéz lenne mondani fájlbaírós módszerrel.Szerk.:
amúgy akár SQLite-ot is használhatnál erre, és akkor még meg is könnyíted a későbbi esetleges átállást "rendes" adatbázisra.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz BullZeye #7556 üzenetére
"Na meg ez, ha jól sejtem olyan, hogy megnyitja a TXT-t online, és ott szerkeszthetem, és nem olyan, hogy rákattolok, és elszíneződik."
Nyilván nem olyan, hogy kézzel kell beleszerkesztgetni, f@szságokat nem ajánlanék...
Úgy lenne megoldva, hogy amikor rákattintasz arra a számra, ami jelezné, hogy már láttad, elküldené az adatokat egy feldolgozó fájlnak, az meg a háttérben megcsinálná a fájlba írást, átírva a megfelelő változót, hogy azt az epizódot mondjuk már láttad. Te meg ugye ebből a fájlból olvasnál, így a megfelelő helyen látszana, hogy már láttad az epizódot, annak megfelelően jelenítené meg.Kész scriptet nem tudok rá mutatni, mert nyilván egyedi igényeid alakítják a kódot. Ha nem vágod a PHP-t, akkor így nehéz lesz (értsd: akkor nem lesz most működő megoldásod)... (hacsak nem találsz valakit, akinek van ideje megírni a kódot, igaz, ezt nem lenne olyan hosszú idő megírni)
"Btw jelenleg ezt a feladatot egy 634 bájtos TXT játssza el, de mondanom sem kell mennyire gáz, ha olyan gépen nézném, amin nincs ez a TXT, vagy hogy összehangolni 2-3 gép között"
Itt lenne mondjuk egy fájl, ami felelős ezért (lehet szabdalni mondjuk akár sorozatok szerint is, de minek... akkor már inkább adatbázis), abból olvasnál, abba írnál. Egyelőre elég, amíg kevés adatod van.
De mivel állításod szerint nem fogsz tudni ilyen scriptet írni, akkor csak legalább megbeszéltük, hogy elméletben sima ügy ilyet írni.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz lafaty80 #7561 üzenetére
Innen nehezen fogja tudni kitalálni bárki is, hogyan konfiguráltad. Pl. php.ini-ben az extension=php_mssql.dll sor szerepel-e, az ehhez tartozó dll (ntwdblib.dll) megvan-e, stb.
Sk8erPeter
-
Sk8erPeter
nagyúr
"ez miatt"
Az mit jelent?Egyáltalán be van állítva a $_GET['hash']? Ha nincs, akkor nem csinál lószart se. De legalább az else ágat is kezelnéd... vagy épp dobnál egy exceptiont, ha nincs beállítva, vagy bármi egyéb, ennél ezerszer szebb megoldás is jobb lenne.
Amúgy fontold meg, amit a többiek írtak (nem ismétlem őket), hogy ne gány megoldást készíts.
Igazából ezzel a megoldással teljesen feleslegesen raktad objektumba, úgy akarod használni, mintha egy sima statikus függvényt meghívnál, és kész.
Ha nem lesz több metódusod, nyilvántartani való tagváltozód benne, akkor tökéletesen felesleges emiatt objektumot példányosítanod, ne gondold, hogy attól szebb lesz a megoldásod. Hangsúlyozom, ebben az esetben. Akkor már szebb, ha többször is hozzá akarsz mondjuk nyúlni egy eltárolt változóhoz, és ezt burkolni szeretnéd, vagy több metódust is meghívnál egyetlen összetartozó feladaton belül, és a többi, amit az ember tanul, amikor az objektumorientáltság előnyeit tanulja (hadd ne soroljam fel)...Sk8erPeter
-
Sk8erPeter
nagyúr
válasz lafaty80 #7563 üzenetére
1.) Néztél error logot? (webszerver logját, PHP logját, stb.)
2.) *nts_vc6 - ez a verzió tuti stimmel?
3.) Különben mi a célod? 32 bites oprendszeren használni Apache-ot, PHP-t, MSSQL-t, és ennyi?
Kész, külön konfigurációs lépéseket és időelb@szásokat nem igénylő megoldásokat, mint az EasyPHP, AppServ, XAMPP, próbáltál már?[ Szerkesztve ]
Sk8erPeter
-
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.
[ Szerkesztve ]
Sk8erPeter
-
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...
Sk8erPeter
-
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.
[ Szerkesztve ]
Sk8erPeter
-
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á'.[ Szerkesztve ]
Sk8erPeter
-
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.
Sk8erPeter
-
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...Sk8erPeter
-
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.Sk8erPeter
-
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!Sk8erPeter
-
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...Sk8erPeter
-
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'?Sk8erPeter
-
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].[ Szerkesztve ]
Sk8erPeter
-
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ő...[ Szerkesztve ]
Sk8erPeter
-
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.[ Szerkesztve ]
Sk8erPeter
-
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.
Sk8erPeter
-
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...
[ Szerkesztve ]
Sk8erPeter
-
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...Sk8erPeter
-
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);[ Szerkesztve ]
Sk8erPeter
-
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.
Sk8erPeter
-
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.
Sk8erPeter
-
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.[ Szerkesztve ]
Sk8erPeter
-
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.[ Szerkesztve ]
Sk8erPeter
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen