По запросу «генерация карты сайта» мы получаем множество ссылок на сайти с инструкциями и полуработающими или платными программами.

В своих поисках я наткнулся на програмку GSiteCrawler она не смотря на свою бесплатность – работает корректно и помимо генерации карты сайта имеет еще множество приятных моментов. Например, если указать доступы к ФТП – она сама после генерации обновит карту сайта.

Так-же поддерживается неограниченное количество проектов.

Теперь о плохом. GSiteCrawler не работает под Vista (и наверное под Win7) если запускать от имени обычного пользователя. Проблему легко решает запуск от имени администратора, но все таки маленька неприятность есть. Зато в остальном – она себя полностью оправдывает.

Сайт разработчика
Ссылка на скачивание

Помимо симптомов получит так-же заверения от владельца сайта, что это все работало буквально пол года назад.

То что проблема заключается на части клиента – практически понятно. Вспомнив что за последние пол года изменялось – был найден виновник – Flash 10.

Детализация проблемы показала, что она заключается в неправильности определения версии флеша (на всех подопытных использовался FlashObject).

Старый метод определял как 1 число и соответственно получалось, что версия = «1″. В то-же время Internet Explorer отдавал версию не так как все и там все работало нормально.

После некоторых раздумий на эту тему было принято решение дописать всего 2 строчки, которые хоть и являются возможным багом, но для большинства клиентов будут работать нормально.

Вот что получилось:

function getFlashVersion() {
var ua = navigator.userAgent.toLowerCase();
var isIE = (ua.indexOf(«msie») != -1 && ua.indexOf(«opera») == -1 && ua.indexOf(«webtv») == -1);
var version = 0;
var lastVersion = 15;
var i;
if (isIE) {
try {
for (i = 3; i <= lastVersion; i++) {
if (eval(‘new ActiveXObject(«ShockwaveFlash.ShockwaveFlash.’+i+’»)’)) {
version = i;
}
}
} catch(e) {}
} else {
for (i = 0; i < navigator.plugins.length; i++) {
if (navigator.plugins[i].name.indexOf(‘Flash’) > -1) {
version = ((navigator.plugins[i].description.charAt(16)) > version) ? (navigator.plugins[i].description.charAt(16)) : version;
if (version == 1){
version = parseInt(version+navigator.plugins[i].description.charAt(17));
}
}
}
}
return version;
}

Версию FlashObject с правильным обработчиком можно скачать flashobject_new.

1. Направленность сайта. Если этот сайт – визитка или каталог – начинать его надо с публичной части. Первый, тестовый, контент можно забивать в БД через PHPMyAdmin или даже оставлять в удобном для себя виде в ПХП файлах (самое главное не забыть его оттуда забрать). Если же это сайт, в админ зоне которого может работать больше людей чем в публичной (во всяком случае на первых порах) (например, сайт агенства недвижимости) первоочередное внимание необходимо приделить как раз админке.
2. Требование первых результатов. Если заказчику не терпится и он хочет произвести первую демонстрацию сайта как можно быстрее – снова же придется разрабатывать сначала публичную часть. Еще одно замечание – при первой демонстрации ВСЕГДА смотрят публичную часть (если она есть конечно).
3. Сложность той или иной части сайта. Чем сложнее и заковыристее админка тем более высокий приоритет она должна иметь. И дело тут не только в том, чтобы напоследок оставить часть попроще, а и в том что в связи с возникшими сложностями как правило приходиться частично менять логику, и если публичная часть уже сделана – ее тоже придется переделать. Например, у агентства недвижимости будет сложная админка, а у электронного магазина, который принимает оплаты и занимается еще целым рядом операций – публичная часть.
4. Наличие начальной документации (ТЗ, требование, виденье сайта). При наличии документации – писать лучше с админки. Если же возникают проблемы с окончательным видением сайта – за админку можно и не браться до первой демонстрации. Объяснение 1 – намного проще в шаблоне добавить к каталогу 10 маленьких картинок вместо 1 или разбить выводимый текст на 2-3 части чем менять структуру БД, все формы и их обработчики.
5. Наличие окончательного дизайна. Если дизайна нету, но заказчик хочет чтобы работа не стояла – лучше делать админку.

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

Приблизительная оценка в баллах:

Направленность публичная: +1
Направленность приватная: -2
Первые результаты быстро: +2
Первые результаты подождут: -2
Публичная чать сложная: +3
Админка сложная: -2
Документация есть: -1
Документации нету: +5
Дизайн есть: +1
Дизайна нету: -5

Если сумма больше нуля – начинать наверное стоит все таки публичную часть.
Если меньше – админку.

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

Оговорим сначала то, что писаться это все будет на PHP. В дальнейшем, возможно портируем еще куда-то, но пока только пхп. База данных – MySql. Разработка физически будет происходить на сервере, предоставленном компанией svai.net. Предусматривается 4 варианта работы системы. Поэтому и все возможности будут распределяться на 4 типа:

1. Сайт будет физически находиться на том-же хостинге и его домен будет запоичен на каталог с самой CMS. В таком случае через конфиг будет рассатриваться домен и результатом будет обычная мультисайтовость.
2. Сайт будет находиться на ином хостинге, или просто в иной папке. В этом случае он будет обращаться к основной БД. На хостинге будет размещаться обрезаная версия фреймворка + темплейты.
3. Сайт храниться на хостинге с которого нельзя присоединиться к БД CMS. В этом случае обновления информации приходят как кеш сайта в виде ассоциированого массива.
4. На хостинге есть только ФТП, но нету возможности работы с БД и ПХП тоже нету (например народ или еще куча хостингов). В этом случае при обновлении информации производиться генерирование HTML кода и его заливка на сам хостинг. соответсвенно компоненты, которые могут давать пользователям возможность самовырадения (голосование, добавление информации и т.д.) работать не будут (хотя не факт, может какой-то хитрый AJAX нам поможет )

0. Все запросы, которые приходят от браузера к серверу через .htaccess переправляются на php-файл, который занимается автоматической разборкой системных событий.

1.Системные события. Т.к. некоторые сайты могут быть отключены или запрещены по ИП для пользования мы должны определять их до начала загрузки всех компонент надо ли пользователю вообще что-то показывать. для этого с мы смотрим по в БД и проверяем надо ли показывать пользователю что-то или сразу средиректить на страница ошибки.

2. Служебные события. Если пользователь имеет право на открытие данного сайта – проводится анализ пути (url). По запросу к таблицам menu, componens определяется ответственный компонент, которому относиться данная страница. В случае если компонента не найдено или же он отключен пользователь перенаправляется на главную страница сайта и добавляется сообщение что страница, запрошеная им – не найдена. Если все хорошо – вызывается сам компонент.

3. Контентные события. Обрабатываются компонентом, который был определен на предыдущем шаге. Проводится дальнейший анализ url. Результатом которого мы получает параметры вывода информации. Данная информация выводиться компонентом на саму страницу.

4. Пользовательские события. Возникают когда прользователь произвел действия, отличные от обысного клика по ссылке (заполнил форму, ввел запреженный url, проголосовал в обросах или добавил информацию в галерею и т.д.). Данные события должны быть обработаны ответственным компонентом или модулем. Результатом как правило является изменение контента на странице, поэтому необходима перезагрузка страницы (без изменения url).

таблица информации о сайтах sites
site_id
порядковый номер сайта в системе
site_url
url-адресс сайта
site_name
название сайта
site_slogan
слоган сайта
site_dizign
номер дизайна
site_mode
режим работы сайта
ключи: site_id автоинкримент
примечания: каждый сайт будет идентифицироваться по уникальному номеру, это даст возможность нормально работать всеми компонентами сайта. + некоторые дополнительные поля дадут возможность избежать нескольких запросов к БД.

таблица параметров сайтов configs
config_id
порядновый номер поля конфигурации
site_id
порядковый номер сайта в системе
config_name
название переменной
config_value
значение переменной
config_desc
описание переменной
ключи: config_id, site_id уникальные
примечания: дополнительные ключи конфигурации делаю возможным персонализировать сайт без изменения конфигурационного файла. Здесь безт храниться все. от размеров картинок до разрмещения блоков в дизайне

типы страниц сайта (компонент)  components
порядновый номер компонента
component_name
название компонента
component_desc
описание компонента
component_access
режим работы компонента
ключи: component_id автоинкримент
примечания: унификация описания компонент даст возможность ральнейшего развития системы путем дописывания новых компонент

меню сайтов menu
menu_id
порядковый номер пункта меню
site_id
порядковый номер сайта в системе
component_id
порядновый номер компонента
menu_pid
родительский пункт меню
menu_name
отображаемое название меню
menu_path
путь к пункту меню
menu_mode
режим работы меню
menu_order
порядок меню
примечания: данная страктура позмолит сделать любую схему навигуции от линейной до дерева.

Описывать структуру БД компонент будем в статьях, посвещенных этим компонентам.

Основные требования к системе:

• Административная часть:

1. Создание/подключение нового сайта исключительно с админки.
2. Публикация статей, новостей и т.д. на 1 или нескольких (всех) сайтах одновременно.
3. Быстрая смена дизайнов.
4. Просмотр общей статистики посещений по всех сайтах.

• Публичная часть:

1. Использование 1 БД.
2. Индивидуальные дизайны сайтов.
3. Функционал: новости, статьи, каталог, галерея.
4. Дополнительные блоки: опросы, баннерокрутилка, линкопродажничество.

Для реализации этого всего будет использоваться разработанный ранее фреймворк, параллельно постараюсь его описать в соседней ветке.

Приблизительные затраты времени: 7-дней.

По окончанию разработки – будет осуществлен перенос на данную систему некоторых личных проектов и так-же будет предоставлена возможность использовать данную систему для проектов сторонних разработчиков (правда пока не решил на каких условиях).

Как дополнительные условия необходимо предвидеть:
1. Возможность работы без БД.
2. Возможность работы без PHP .
3. Возможность использования на разных площадках.

Скачать Multiple IE можно ссылке

Перед установкой необходимо поставить себе IE 7.0.

Важное замечание:

Проблемы с Vista (слава богу не критические).  В следующем посте постараюсь описать как поставить IE 6.0 на машину с Vista.

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

По принципу действия есть 2 самых популярных типа:

1. Статистика собирается на стороне самом сайте. При этом как правило она пишется в локальную БД и обрабатывается самим сервером.

• Плюсы таких систем:

1. Как правило невозможно зайти на сайт таки образом чтобы посетитель не защитался. (Большая надежность)
2. Статистика имеет сиюсекундное значение. Тоесть если пользователь зашел на сайт, мы сразу его можем увидеть в статистике. (Высокая актуальность данных)
3. Нету никаких инородных кодов с исходном коде страницы. (Чистота кода)
4. Самое главное ее можно показать на любой странице в любом виде (ограничение – фантазия).

• Минусы:
  1. Надо писать самому или использовать чужое решение. Скриптов для сбора и обработки статистики достаточно много, но проблема в том что их все равно надо просматривать на предмет корректности работы.
  2. Для модернизации скрипта иногда приходиться переписывать практически весь код.
  3. При большом количестве посетителей сама статистика занимает достаточно много места в БД (за несколько лет вполне может получиться больше чем занимает сам контент сайта).
  4. Вся нагрузка по обработке статистики ложиться на локальный сервер и при пиковых нагрузках возможно подвисание БД как минимум (а современные хостеры ой как это не любят).

2. Статистика собираеться на стороннем сервере. Все нюансы и сложности сбора и обработки статистики пологаються на платную/бесплатную тех.поддержку.

• Плюсы:

1. Очень простая установка и подключение. Как правило достаточно зарегистрироваться на сайте и установить код на свой сайт.
2. Нету нагрузок на локальный сервер, нету никаких простоев и проблем с хостингом.

• Минусы:

1. Не все пользователи могут быть засчитаны. Банальное отключение картинок может привезти к тому что данные о посетителе просто не попадут на сервер статистики. Если при этом еще и отключить ява-скрипты – шансов быть замеченым практически нету.
2. Для просмотра статистики необходимо переходить на отдельную страницу на сервере статистики (а это долго, не удобно да и лень многим владельцам).
3. Статистика как правило отображается за период «до вчера». А количество посещений на текущий момент можно узнать разве что по «счетчику» на сайте.

Поэтому одним с вариантов как поступить в этой ситуации – сделать экспорт собраной статистики себе на сайт, и на основании этого уже построить необходимые графики. Это даст возможность корректно отобразить на самом сайте информацию о посетителях.

Dropbox

Одним с вариантов, которые вдохновили автора написать эту статью – возпользоваться условно-бесплатным сервисом DropBox.

После регистрации даеться: софтика, которая устанавливаеться на компы, которые надо синхронизировать, 2Гб места на удаленном сервере – для самой нинхронизации. Надо больше места? Нет проблем. Покупаем премиум-акаунт за 9.99 у.е. (или 99 за год) и получаем 50Гб. Этого уже долно хватить .

После установки на станции – получаем каталог «My Dropbox» (Win) (размещение каталога – можно выбрать, а вот название, к сожалению, менять нельзя). Все что будет находиться там – будет синхронизироваться с сервером и всеми копиями Dropbox, на которых выполнен вход под этим аккаунтом.

Помимо самой синхнонизации данных есть еще возможность просмотра ревизий файла. Тоесть можно:
1. Просмотреть кто и когда создавал, изменял, удалял файл/каталог и т.д. (эта возможность являеться очень нужно при групповой работе).
2. Восстановить удаленный файл (при этом – удаленный файл места не занимает, вернее оно не считается).

Что касается групповой работы – помимо синхронизации – можно переместить файл в каталог Public и для через контекстное меню – получить для него ссылку, по которой можно этот файл открыть. Этот способ пересылки не конфиденциальной информации достаточно прост и так-же позволяет економить время.