Najlepiej (ze względu na wysyłanie nagłówków, cookies) byłoby wstawić w pierwszej linii, zanim cokolwiek trafi do przeglądarki (choćby nawet spacja).
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Forum projektu eStats » Posty przez Emdek
Najlepiej (ze względu na wysyłanie nagłówków, cookies) byłoby wstawić w pierwszej linii, zanim cokolwiek trafi do przeglądarki (choćby nawet spacja).
Najlepiej po prostu spróbować np. z testową instalacją skryptu (np. z użyciem SQLite) żeby nie namieszać sobie w danych na czas testów.
Nie znam budowy tego CMSa (w ciemno zakładam, że to jakiś autorski) i mogę najwyżej wyobrazić sobie konflikty związane np. z użyciem tej samej bazy danych MySQL.
Jak i nie ma dla nich strony odsyłającej (a to jest niezbędne dla tej funkcji), takie wady używania kodu JS (kiedy to tylko możliwe najlepiej używać wersji podstawowej, PHP).
Ale nie jest to coś nie do zrobienia (atrybut document.referrer), ale wymaga dość sporych zmian, więc najprawdopodobniej trzeba będzie na to poczekać do kolejnego dużego wydania (chociaż możliwe, że będzie jakiś backport do obecnej gałęzi, zależy jak się to uda rozwiązać).
Ujdzie na sucho do czasu kolejnej dużej aktualizacji (testowe wersje pojawią się mam nadzieję już w listopadzie, jak tylko dokończę ten cyrk zwany studiami ;-)), kiedy to zmieni się kod zbierania danych, a opisana wyżej metoda i tak by dalej działała. ;-)
Nie jest to zabronione, ale nie jest także zalecane z oczywistych względów. ;-)
Sugerowałbym nałożenie na obrazek / link atrybutu CSS visibility:hidden; (np. przez objęcie kodu znacznikiem DIV lub SPAN z odpowiednią klasą / identyfikatorem / bezpośrednio wstawionymi instrukcjami z pomocą atrybutu style), jeśli twórcy przeglądarek nie zoptymalizowali nic za mocno ostatnimi czasy to powinno nadal pozwalać na ładowanie się kodu zbierającego dane, a przy okazji schować grafikę.
Dodatkowo można to schować z position:absolute; i ewentualnie z odpowiednim z-index schować pod coś (to już zależy od konstrukcji strony).
Żeby poprawili. ;-)
Bo o ile nie mają jakieś niestandardowej konfiguracji (pewnie da się zmienić ścieżkę za pomocą jakiejś flagi przy kompilacji), to ta ścieżka jest nieprawidłowa. Ewentualnie mogą zrobić dowiązanie symboliczne folderu do /usr/share/GeoIP. Ostatecznie mogą też sprawdzić w liście plików pakietu geoip gdzie trafiły jego domyślne pliki danych (podstawowe, nieprzydatne w tym wypadku).
Jeśli nie ma problemów z brakiem /nieprawidłowymi nazwami plików danych, to powinno już zadziałać.
Ta ścieżka nie wygląda zbyt dobrze, u mnie są to odpowiednio ścieżka:
/usr/share/GeoIP
I lista plików (nie wszystkie są potrzebne):
GeoIPASNum.dat GeoIPCity.dat GeoIP.dat GeoLiteCity.dat
Żeby działała geolokalizacja musi być spełniony poniższy warunek:
(function_exists('geoip_record_by_name') && geoip_db_avail(GEOIP_CITY_EDITION_REV0)Czyli Twój serwer powinien spełniać przynajmniej jego pierwszą część (załadowanie rozszerzenia), ale do prawidłowego działania potrzebne są jeszcze pliki danych (zainstalowane systemowo, ale z tego co wiem nierozprowadzane z rozszerzeniem lub w najbardziej podstawowej i okrojonej formie).
Najlepiej napisz do nich z pytaniem czy doinstalowali pliki danych:
http://www.maxmind.com/app/geolitecity
http://www.maxmind.com/app/installation?city=1
Niewielka aktualizacja (rewizja 121), przynosząca kilka nowych reguł wykrywania przeglądarek i robotów sieciowych.
Zmiany:
- dodane wykrywanie przeglądarek IceCat, Skyfire, UC Browser oraz wersji mobilnych Opery i Safari;
- dodane wykrywanie robotów sieciowych Covario, DoCoMo oraz Exabot;
Pobieralnia:
ZIP: 1077.86 KB.
TAR.BZ2: 765.8 KB.
Kolejna aktualizacja (rewizja 111) zawierająca trzy poprawki, w tym jedną istotną.
Zmiany:
- Sudan Południowy dodany do listy krajów;
- poprawione wykrywanie przeglądarki Chrome;
- poprawione alternatywne wywołanie GeoIP;
Pobieralnia:
ZIP: 1069.71 KB.
TAR.BZ2: 760.23 KB.
No tak, ale można już to wymuszać bez konieczności poprawiania tego za każdym razem kiedy pojawi się nowa wersja. ;-)
Ale skoro wcześniej było w porządku, od razu po aktualizacji i zauważeniu problemu postanowiłem napisać. Od tego jest ten dział.
Dokładnie, przynajmniej do czasu aż się dorobimy jakiegoś prostego systemu zgłaszania błędów.
Już od razu po zobaczeniu, że problem nadal występuje stosowne zmiany wykonałem, dziwny problem... W końcu nie jest to tak konieczne, ale zawsze jakoś wygodniej czytać po polsku.
Tzn. pomaga ustawienie tej stałej, czy nie? Bo już się pogubiłem. ;-)
Dzięki, poprawione (poprawka wyjdzie najpóźniej pierwszego, tutaj poprawiony plik, położenie i nazwa taka jak część ścieżki po estats-4.9/), trochę się popsuła kolejność reguł wykrywania (a Chrome ma w swoim tekście identyfikacyjnym też ten z Safari).
Problemy z ikonkami wynikały z problemów z zapisem cache ich listy.
Co do tłumaczeń, to nie czytamy historii zmian... ;-)
zezwolenie na kontrolę używania gettext z użyciem stałej konfiguracyjnej ESTATS_GETTEXT
Dodaj do pliku konfiguracyjnego:
define('ESTATS_GETTEXT', FALSE);Przyszedł czas na kolejną aktualizację (rewizja 100), główne zmiany to poprawki dwóch problemów związanych z przywracaniem kopii zapasowych (sprawdzanie poprawności pliku oraz naprawienie przywracania kopii wysyłanych na serwer) ale i całkowicie przebudowany kanał informacyjny.
Zmiany:
- ulepszone kanały informacyjne Atom;
- dodane wykrywanie przeglądarki WebPositive oraz systemu operacyjnego Haiku;
- zezwolenie na kontrolę używania gettext z użyciem stałej konfiguracyjnej ESTATS_GETTEXT;
- poprawki związane z przywracaniem kopii zapasowych;
Pobieralnia:
ZIP: 1069.23 KB.
TAR.BZ2: 759.9 KB.
No tak, to dość gigantyczna liczba danych... ;-)
Co do Ogólnych, to "spowalniaczem" jest tabela stron, tutaj może pomóc dodanie dodatkowego indeksu (ale nie unikalnego) dla kolumny address (tabela sites), dla testowej bazy danych (podziękowania dla Kobera) zawierającej 147465 krotek w tej tabeli dało to zejście z 11 do 8 sekund, warto spróbować. Więcej się raczej nie wyciągnie, sprawdziłem jak to wygląda na silniku InnoDB i tam wypada niemalże tak samo (tylko pół sekundy gorzej).
Dla strony szczegółów powinno pomóc dodanie indeksu (ale nie unikalnego) do tabeli details, kolumny id, na testowej bazie zawierającej w tabelach odwiedzających 225 i 246 tysięcy krotek.
W przypadku kopii zapasowych to mamy problem, bo tam jest już zabezpieczenie przed dużą ilością danych (zapytania zwracają tylko "uchwyt" do zbioru danych, nie same dane), ale widocznie nie da się tą drogą tego obejść do końca, trochę to dziwne zresztą, bo wygląda na to, że PHP od razu pobiera dane i trzyma je po swojej stronie zamiast odbierać krotka po krotce... Jedyne co mi przychodzi do głowy, to sprawdzanie ilości danych przed próbą ich pobrania i dzielenie na kawałki, ale tu mamy dwa inne problemy, możliwość modyfikacji danych pomiędzy pobraniami (w sumie małe ryzyko i małe szkody, przynajmniej przy obecnej strukturze danych, ostatecznie można zasugerować albo automatycznie zablokować zbieranie danych na czas wykonywania kopii) i groźniejszy, możliwość skończenia się czasu na wykonanie skryptu (na niektórych hostingach nawet jedynie około pięciu sekund). To drugie też można by spróbować ominąć, jakimś etapowym wykonywaniem, z porównywaniem czasu wykonywania do limitu i przekazywaniem "współrzędnych" do rozpoczęcia następnego etapu, ale to dość skomplikowane i w najbliższym czasie raczej się nie pojawi (najwcześniej w 5.0).
Przy takich ilościach danych najlepiej używać narzędzi zewnętrznych, które nie są limitowane ustawieniami PHP.
PS. Udało Ci się tak wstrzelić z tym postem, że nie zdążył załapać się na mój czytnik RSS, a tego samego pewnie dnia wystąpił problem z konfiguracją mojego konta i nie zauważyłem tego aż do wczoraj. :-D
Forum projektu eStats » Posty przez Emdek