Új hozzászólás Aktív témák
-
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.
Sk8erPeter
-
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?
Sk8erPeter
-
Sk8erPeter
nagyúr
-
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;"[ Szerkesztve ]
Sk8erPeter
-
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)[ Szerkesztve ]
Sk8erPeter
-
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."
[ Szerkesztve ]
Sk8erPeter
-
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ó...)
[ Szerkesztve ]
Sk8erPeter
-
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.
Sk8erPeter
-
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.
[ Szerkesztve ]
Sk8erPeter
-
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.Sk8erPeter
-
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?Sk8erPeter
-
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?
Sk8erPeter
-
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...Sk8erPeter
-
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.Sk8erPeter
-
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.)
[ Szerkesztve ]
Sk8erPeter
-
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.
Sk8erPeter
-
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.[ Szerkesztve ]
Sk8erPeter
-
-
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...
Sk8erPeter
-
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 )[ Szerkesztve ]
Sk8erPeter
-
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.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #7812 üzenetére
Ja hogy ez az (az eredeti verziója, Ash Young). Nem rossz.
Sk8erPeter
-
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".Sk8erPeter
-
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).[ Szerkesztve ]
Sk8erPeter
-
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.Sk8erPeter
-
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.Sk8erPeter
-
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 ."Sk8erPeter
-
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.Sk8erPeter
-
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.
[ Szerkesztve ]
Sk8erPeter
-
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...
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz wolandino #7869 üzenetére
Akkor az, ami most van nálatok, miért nem megfelelő? Az a plusz 100 sor lekérése adatbázisból nem hiszem, hogy szűk keresztmetszet lenne, így szerintem nem érdemes hozzányúlni ebben az esetben. Azt hittem, azért kérdezed, mert még kialakításra vár a dolog.
Sk8erPeter
-
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);
Sk8erPeter
-
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.Sk8erPeter
-
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.
Sk8erPeter
-
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.Sk8erPeter
-
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.Sk8erPeter
-
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.
[ Szerkesztve ]
Sk8erPeter
-
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.
Sk8erPeter
-
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...Sk8erPeter
-
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.[ Szerkesztve ]
Sk8erPeter
-
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?
Sk8erPeter
-
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.Sk8erPeter
-
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?Sk8erPeter
-
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!Sk8erPeter
Új hozzászólás Aktív témák
- Győr és környéke adok-veszek-beszélgetek
- Ilyen lehet a Samsung Galaxy Watch7 Ultra
- Luck Dragon: Asszociációs játék. :)
- HiFi műszaki szemmel - sztereó hangrendszerek
- CASIO órák kedvelők topicja!
- Notebook hibák
- Escape from Tarkov
- SSD kibeszélő
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Bestbuy játékok
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs