Форум PHP

Введен учёт браузеров Firefox, Mozilla и MyIE, расширена таблица pages, для постепенного перехода с URL на названия страниц. Теперь добавив на вашу страницу название в переменной $titlepage вместо малопонятного URL, будут выводится названия.
Если перед файлом включением файла при помощи инструкции require_once поместить имя страницы в переменной $titlepage, в отчётах системы, данная страница будет участвовать под этим именем. Более того, вы можете объединять несколько страниц в одну строку, присваивая им одинаковые названия.

<?php   $titlepage = "Название страницы";   require_once("count.php"); ?>

PS Для обновления системы с версии 3.0 до версии 3.1 необходимо выполнить
SQL-запросы из файла update.sql

ALTER TABLE system_ip CHANGE browsers browsers ENUM( 'none', 'msie', 'opera', 'netscape', 'firefox', 'myie', 'mozilla' ) NOT NULL DEFAULT 'none' ALTER TABLE system_pages ADD title TINYTEXT NOT NULL AFTER name; ALTER TABLE system_arch_clients ADD browsers_firefox INT NOT NULL AFTER browsers_netscape, ADD browsers_myie INT NOT NULL AFTER browsers_firefox, ADD browsers_mozilla INT NOT NULL AFTER browsers_myie; ALTER TABLE system_arch_clients_week ADD browsers_firefox INT NOT NULL AFTER browsers_netscape, ADD browsers_myie INT NOT NULL AFTER browsers_firefox, ADD browsers_mozilla INT NOT NULL AFTER browsers_myie; ALTER TABLE system_arch_clients_month ADD browsers_firefox INT NOT NULL AFTER browsers_netscape, ADD browsers_myie INT NOT NULL AFTER browsers_firefox, ADD browsers_mozilla INT NOT NULL AFTER browsers_myie;

Не плохо бы также уничтожить все записи из таблицы system_pages.

Для Loki: система учёта новых страниц работала только если все страницы названы, иначе первую же страницу он называет пустой строкой, а потом ищет пустую же строку и в общем все страницы сыпались в одну, с названием пустой строки, переделал так

<?       if(empty($titlepage)) $titlepage = "http://".$_SERVER['SERVER_NAME'].$_SERVER['PHP_SELF'];       if (!get_magic_quotes_gpc()) $titlepage = mysql_escape_string($titlepage);       $query = "SELECT id_page FROM $tbl_pages                  WHERE title = '$titlepage'";        $pgs = mysql_query($query);        if ($pgs)        {         // Выясним, первичный ключ (id_page) текущей страницы  (по названию страницы)          if(mysql_num_rows($pgs)>0) $id_page = mysql_result($pgs,0);          // Если название данной страницы отсутствует в таблице pages          // то проверяем сраницу по ее адресу.          else          {              $query = "SELECT id_page FROM $tbl_pages                      WHERE name='".$_SERVER['PHP_SELF']."'";            $pgs = mysql_query($query);            if ($pgs)            {             // Выясним, первичный ключ (id_page) текущей страницы (по адресу страницы)              if(mysql_num_rows($pgs)>0)              {               $id_page = mysql_result($pgs,0);               $query = "UPDATE $tbl_pages SET title='$titlepage' WHERE id_page=$id_page";               mysql_query($query);              }              // Если данная страница отсутствует в таблице pages              // и не разу не учитывалась - добавляем данную страницу в таблицу.              else              {                  $query = "INSERT INTO $tbl_pages VALUES (NULL, '".$_SERVER['PHP_SELF']."','$titlepage', 0)";                                @mysql_query($query);                // Выясняем первичный ключ только что добавленной                // страницы                $id_page = mysql_insert_id();              }            }         }       } ?>

Не очень нравится блок

<?php             {               $id_page = mysql_result($pgs,0);               $query = "UPDATE $tbl_pages SET title='$titlepage' WHERE id_page=$id_page";               mysql_query($query);              }  ?>

особенно если страницы динамические... а может просто ещё не привык к новой системе...

Кстати пользуюсь случаем хочу сделать несколько замечаний. Возможно ошибки уже были исправлены. Сейчас у меня версия 2.9.0, поэтому не вините если что то упустил :). Так вот во первых: при очистке базы данных "статистика запросов остается", во вторых, постраничная навигация на главной странице сделана не очень удачно, во первых получается довольно много ссылок на страницы а во вторых в Mozilla эти ссылки вытягиваются в одну линию. Ну и неплохо бы было сэкономить время и трафик пользователей путем разбиения на страницы некоторых разделов.

Да постраничную навигацию будем вводить во всех отчётах - это будет дело ближайших версий, со страницами тоже что-нибудь придумаем... наверное следует ввести навигацию как ну нас на форуме.

Сейчас очистка базы данных происходит автоматически и поэтапно.

Наверное в следующих версиях стоит ввести дату в таблицу system_pages, чтобы можно было очень старые страницы удалять автоматически...

И все-таки наверное надо сделать последний пункт меню (Настройки счетчика) и на странице размещать все параметры настройки счетчика.
Один пункт на этой странице я знаю. Это, как я уже писал ранее, временной интервал после которого данные считаются потерявшими актуальность и автоматом удаляются или суммируются. А суточная недельная и помесячная статистика пусть работает автономно независимо от текущей статистики.
А что касается самого меню, то все подпункты логичнее было бы размещать на самих страницах, например в одну строку над таблицами со статистикой.

Наверное действительно так и стоит поступить - параметров может быть до чёрта - выбор между PHP_SELF и REQUEST_URI, число архивируемых рефереров, и поисковых запросов...

>А что касается самого меню, то все подпункты логичнее было
>бы размещать на самих страницах, например в одну строку над
>таблицами со статистикой.
Да, вероятно... но тогда не будет видно, что они есть - тут подумать нужно...

>система учёта новых страниц работала только
Ну вопрос стоял как это реализовано сейчас, а не как это должно бы быть:)

>Не очень нравится блок
Как раз если страницы динамические - он особенно актуален. Потому что название пожно поменять совершенно не задумываясь о последствиях.

Правда, надо признать, что в коде есть узкое место: если название страницы поменялось, а в базе она учтена, допустим, как index.php?id=0, то страницу index.php?id= счетчик посчитает как новую. Так что в пределах сайта надо следить за единообразием ссылок.
А механизм удаления старых страниц действительно нужен! Точнее, даже не механизм удаления, а механизм оповещения о них: страница может быть скрыта от пользователей для доработки, а может быть и просто потеряна при смене навигации.

А в новой версии опять старый глюк
Только установил все с нуля, а
Система работает: 13167 дн.

> А в новой версии опять старый глюк.
У меня тоже такое было, но по истечении суток всё становиться на свои места.

Сутки пройдут - всё устаканится... в следующем релизе, который будет выложен не сегодня завтра (база данных изменена не будет) это постараемся исправить.

А в какой версии планируется убрать поле searches в system_ip?

Я подумал, что хорошо бы при любых изменениях базы данных изменять второй номер версии, а при файловых изменениях - третий. Тогда убирание поля searches в system_ip произойдёт в версии 3.2 или 3.3, но предварительно я бы хотел ещё одну версию 3.1 выпустить, в которой будет устранена ошибка подсчёта процентов в браузерах, ошибка, связанная с переходом на зимнее/летнее время и ошибка отображения дикого количества дней при запуске счётчика с чистого листа. Либо сегодня ночью выложу её, либо завтра днём.

Поставил сейчас новую версию, прежде пользовался 2.9.0, сразу возникла проблема: страницы стали грузиться неимоверно долго, хотя я сижу на локальном хосте, и прежде все страницы открывались с одного клика. Если на локальном хосте система грузится так долго, что будет, когда я перенесу счетчик на удаленный хост?
Функционально изменений на первый взгляд не много, но таблиц прибавилось значительно.
Может быть, подскажет кто, с чем связана такая медлительность в работе скрипта.
Win32
Apache 1.3.23
PHP 4.4.0
MySQL 3.23.54
Все расположено на локальном хосте

Систему с нуля ставили или апгрейдили с предыдущей версии?

Это кстати да.
Я ставил с нуля, но переход по ссылке IP занимает неимоверное время (дольше всего)

-

Файл count.php

if(substr($useragent, 0, 6) == "msnbot")        $os = 'robot_msnbot';

у нас нет такого. есть robot_msn
Об этой ошибке я вроде как писал несколько месяцев назад...

Странно, а у меня с версии 2.3 идёт как robot_msnbot...

Только что посетил меня (crawl-66-249-65-140.googlebot.com)
Я так понимаю это какой то робот гугля,
так вот кроме ip адресов он нигде не отображается,
ни в роботах, ни в других местах.

Будем отлавливать.

crawl-66-249-71-17.googlebot.com
sfront35.yandex.ru

вот ещё

Значит так. Загрузил на хотинг архивированную статистику недельной давности. После чего попытался войти в отчеты. Войти удалось раза с седьмого. И это при том, что нужно было выгрузить даные всего за неделю. Ладно, мы не гордые.
Последующие замеры показали следующее:
время генерации отчета: 9.153 с
время генерации отчета при заблокированном модуле archive.php 0.970
То есть больше 8 секунд у нас уходит на всякого рода проверки, при том что архивировать ничего не требуется!
Короче, надо подумать как все это добро оптимизировать...

В отчете "Хосты и Хиты" данные за 7дн, 30дн и все время суммируются и по архивным и по неархивным таблицам. в итоге показатели удваиваются.

Еще раз хотелось бы обратить внимание:
"Просмотрел блок архивации. Что не понравилось: сначала выцепляем все данные, а потом их вносим в архив... Получается, что если у нас большой объем данных и set_time_limit не работает, то счетчик просто перестает работать: выгрузить данные мы не можем, а при попытке войти в админку у нас запускается архивация."

А у меня не удваиваются... странно...

а у вас, наверное, таблица ip после архивации очищается. я пока ей пожертвовать не готов:)
хотябы до тех пор, пока не будут выгружены все поисковики (это я снова про mail.ru)

Вообще говоря по уму archive.php следует запущать при помощи cron, но результаты странные - у меня очень быстро грузится даже не смотря на все проверки... может у хостера машина могучая стоит - нужно будет перенести базу на локальную машину и потестировать.