Мы будем Вам признательны, если Вы поддержите проект Open SLAED и используя Ваши возможности, разместите наш пресс-релиз на страницах своих сайтов, проектов, форумов, блогов. Текст пресс-релиза, возможно, видоизменить под Ваш формат, не искажая смысл. Пресс-релиз можно взять на данной странице.
1. Войдите в панель управления системой, отдел: Панель администратора >> База данных
2. В окне запросов в базу данных Вы можете произвести свой запрос.
Обратите внимание на то, что использование стандартного префикса не обязательно, за место его Вы можете использовать {pref}. В этом случае переменная {pref} будет автоматически заменена Вашим префиксом.
В качестве примера, рассмотрим запрос, который удалит всех зарегистрированных пользователей, не посещавших проект, начиная с: 2007-10-05 18:15:00.
Иногда возникает необходимость перенаправления определённого посетителя, допустим пришедшего с определённого сайта или определённой страны, на определённую страницу. Данную потребность, возможно, реализовать стандартными средствами системы. В качестве примера, ниже мы рассмотрим несколько вариантов.
Перенаправление посетителя пришедшего с определённого сайта
1. Войдите в панель управления системой, отдел: Панель администратора >> Редактор
2. В файл внедрения в шапку системы: config_header.php
Добавляем следующую запись:
$reflink - Отвечает за адрес нужного нам сайта
Заместо: slaed.net укажите свой домен.
$metlink - Отвечает за страницу, куда будет перенаправлен посетитель
Заместо: news.html укажите необходимую страницу или сайт.
Перенаправление посетителя из определённой страны
1. Войдите в панель управления системой, отдел: Панель администратора >> Редактор
2. В файл внедрения в шапку системы: config_header.php
Добавляем следующую запись
$userlang - Отвечает за нужную нам страну
Название страны не должно быть произвольным и должно соответствовать стандартам использования класса. Правильность написания той или иной страны можно проверить в переменной $COUNTRY_NAMES файла: function/geo_ip.php
$metlink - Отвечает за страницу, куда будет перенаправлен посетитель
Заместо: news.html укажите необходимую страницу или сайт.
В качестве примера форум оформлен с общей темой оформления. Таблицы стилей сведены в одну. Теперь можно изменив стили изменять оформление форума и сайта одновременно.
Замените только файл overall_header.tpl в modules/Forums/templates/subSilver чтобы отключить таблицу стилей форума.
В качестве примера форум оформлен с общей темой оформления. Таблицы стилей сведены в одну. Теперь можно изменив стили изменять оформление форума и сайта одновременно.
Замените только файл overall_header.tpl в modules/Forums/templates/subSilver чтобы отключить таблицу стилей форума.
В качестве примера форум оформлен с общей темой оформления. Таблицы стилей сведены в одну. Теперь можно изменив стили изменять оформление форума и сайта одновременно. Замените только файл overall_header.tpl в modules/Forums/templates/subSilver чтобы отключить таблицу стилей форума.
Добавление информации о фирме для пользователей.
Размещение прайс-листов, после разрешения администратора.
Размещение информации о товаре услуге производимой фирмой, с возможностью загрузки фотографии товара. Загрузка логотипа фирмы.
Для возможности выбора категории смотрите структуру базы, для примера оставлена моя база.
Готовится к запланированному выходу новая, профессиональная версия SLAED CMS 3.4 Pro. При работе над этой версией были учтены пожелания клиентов относительно существующих функций и в соответствии с этим были произведены необходимые модификации, обновления, улучшения. Глобальным изменениям и модификациям были подвергнуты основные функции ядра системы, такие как определение администратора, его прав, функции работы с RSS каналами, парсинг ББ кода, а именно PHP, HTML, сортировка файлов редактора и многое другое.
Изменениям были подвергнуты почти все модули и файлы системы. Частично были затронуты шаблоны тем оформления. Несмотря на это, работа системы с выпущенными ранее модулями, блоками, темами оформления осталась без изменений.
В виду большого количества изменений внесённых в основные функции системы будет выпущена Beta версия, предназначенная исключительно для тестирования и отладки. Скачать данную версию сможет любой желающий в каталоге файлов. Если Вы нашли ошибку, у Вас появились какие либо проблемы касательно установки или использования системы, рекомендуем, обратится в отдел форума, специально посвященный этой теме.
Общие изменения, новые возможности, модификации
В панели пользователя отдела для клиентов добавлена возможность просмотра актуального статуса приобретенного продукта.
В систему интегрирована новая технология использования поисковых систем непосредственно в браузере пользователя. Это даёт возможность интегрирования поиска на Вашем сайте по типу Google, MSN и т.д., непосредственно в браузере посетителя по его желанию.
Частично переписана система рейтинга, изменено оформление рейтинг баров с возможность просмотра существующего состояния рейтинга до установки своей оценки.
Написана новая система генерации RSS каналов с учётом новых стандартов с использованием категорий, авторов, даты и сортировки в соответствии с ними. Использование каналов возможно для модулей: Вопросы и ответы, Каталог файлов, Каталог сайтов, Медиа каталог, Статьи, Магазин, Новости проекта.
Модифицирована функция автоматической генерации ключевых слов сайта, установлен фильтр, исключающий проблемы при использовании специальных символов в содержании статей.
Модифицированы функции кэширования, таким образом, исключена возможность попадания и запись в папку кэша не существующих или пустых страниц.
Переписаны все функции обработки и записи RSS потоков в базу данных при их использовании в блоках. Теперь RSS каналы не используют базу данных, все конфигурации записываются в файлы, что в свою очередь снижает нагрузку на базу данных системы.
Написан новый модуль панели администратора для создания и работы с RSS потоками. Установлено использование и редактирование своего шаблона для отображения каналов на сайте. Установлена возможность добавления нужных Вам каналов, которые будут добавлены в код сайта для определения и их дальнейшего использования браузерами.
Расширена функция работы с темами оформления. Добавлена возможность уникального оформления главной страницы независимо от установленного на ней модуля.
Добавлена проверка на размер кэшированных страниц, если размер равен нулю, то кэш в этом случае не создаётся, страница генерируется заново и создаётся повторно.
Для повышения удобства в использовании, модифицирована визуальная часть ББ редактора. Панель разделена на две части и размещена сверху и снизу окна ввода.
Полной модификации подверглись функции парсинга PHP кода, обычного кода, цитат, скрытого кода. Значительным образом снижена скорость генерации страниц, в местах, где используется большое количества ББ кода. Улучшена визуальная часть.
Для улучшения понимания и сферы использования, произведены языковые корректировки названий модулей новостей и статей, произведена смена графических элементов в панели администратора для этих модулей.
Разработана новая система установки, и использование дополнительных полей, применение которых на данный момент возможно в пользовательском и новостных модулях. Настройка и установка дополнительных полей предусмотрена в отделе администратора системы.
Модификации подверглись стили тем оформления, используемые в формах системы. Таки образом реализована корректная и идентичная работа оформления форм во всех популярных браузерах.
Модификации подвергся модуль пользователей системы. Изменениям подверглись настройки пользователя и некоторые языковые константы.
Разработана новая функция автоматического определения и установки базы данных модуля непосредственно из панели администратора. Добавлены три основных действия, это: Установка таблиц базы данных модуля, Удаление таблиц базы данных модуля и Обновление таблиц базы данных модуля. Более подробная информация для разработчиков модулей будет описана в документации на проекте. В качестве примера в новостном модуле реализована данная возможность.
Глобальным образом модифицирована функция динамической (AJAX) работы с файлами в ББ редакторе. Произведена смена принципа сортировки файлов (Теперь сортировка производится по дате), что значительно улучшает удобство использования и сокращает время генерации и определения файлов.
Написан совершенно новый модуль заказов, предназначенный для заказа товаров, услуг или других сервисов Вашего проекта. Данный модуль имеет возможность установки дополнительных, своих полей, а значит, может быть применён в широкой сфере. Существует панель управления модулем, которая имеет возможность хранения, редактирования, добавления заказов, а так же необходимое количество конфигураций, таких как: Отключение заказов, Подтверждение заказов администратором, дублирование заказов, выводимая и отправляемая информация.
Значительным изменениям подверглись функции ядра системы, которые используются для определения пользователей и администраторов системы. Более удобному разграничению подверглись права администраторов проекта по тем или иным модулям. Дополнительно к этому, упрощено их использование при написании своих модулей.
В конфигурациях панели администратора системы добавлена возможность установки модуля для главной страницы панели администратора по умолчанию.
Значительным образом переписана и централизованна система рейтингов. Написана новая панель администрации рейтингом. Таким образом, рейтинг сталь ещё удобней, функциональней, получил возможность дальнейшего расширения для других модулей без глобальных изменений в ядро системы.
Добавлена возможность интеграции с актуальной версией форума Invision Power Board 2.3.1
Исправления и корректировки
Исправлена ошибка, связанная с редактированием внедрений в систему при активированном HTML редакторе, который внедрялся и мешал корректному редактированию внедрений.
Исправлена ошибка в комментариях системы, проявлявшаяся при работе с браузером Firefox, связанная с добавление ника пользователя, в текстовое поля для ответа.
Исправлена неточность в панели администрирования новых анекдотов, добавленных посетителями сайта. Проблема появлялась при их одобрении администратором.
Представляю Вашему вниманию новую версию системы SLAED CMS 2.4 Lite. Основной акцент при работе над данной версией делался на исправление ошибок и не точностей предыдущих версий, а так же несколько глобальных нововведений, на которых хотелось бы остановиться более подробно. Основное из них, это дополнительные поля, которые значительно повышают удобство в использование системы, дают возможность создания, и установки своих полей в новостном и пользовательском модулях.
Предусмотрено три типа полей, это одна строка, поле с текстом и список с выбором. Опытные пользователи и знатоки PHP, без особых трудностей смогут расширить данный функционал для других модулей, так как функции, используемые дополнительными полями являются централизованными, независимыми от модулей и могут, применятся по всей системе в целом.
Следующее изменение предусмотрено для упрощения установки модулей с базой данных. Даёт возможность установки и обновление модулей непосредственно из панели администрации моделей системы. Данная возможность будет работать только в случае, если модуль разработан с учётом нового стандарта, а именно:
1. База данных должна храниться в папке модуля sql/
2. База данных должна иметь название: table.sql
3. База данных обновления должна иметь название: update.sql
Содержание файлов с таблицами базы данных стандартное, с учётом специфики MySQL. Как Вы заметили, требования минимальные и не требуют сверх дополнительных усилий от разработчиков моделей. В качестве примера, можно взять новостной модуль, который написан с учётом нового стандарта.
Общие изменения, новые возможности, модификации
При использовании ББ тег и редактора, появилась возможность выравнивания графических элементов, а так же добавление описания и альтернативного текста к ним.
Произведены изменения дающие возможность добавления неограниченного количества смайлов, которые будут определены и установлены в автоматическом режиме.
Модифицирован ББ редактор, произведена добавка шрифтов, цветов, количество размеров.
Для улучшения понимания и сферы использования, произведены языковые корректировки названий модулей новостей и статей, произведена смена графических элементов в панели администратора для этих модулей.
Модифицирована подсветка отключённых модулей в панели администратора системы. Таким образом, снижена скорость генерации и размер используемых графических элементов.
Разработана новая функция автоматического определения и установки базы, данных модуля непосредственно из панели администратора. Добавлены три основных действия, это: Установка таблиц базы данных модуля, Удаление таблиц базы данных модуля и Обновление таблиц базы данных модуля. Более подробная информация для разработчиков модулей будет описана в документации на проекте. В качестве примера в новостном модуле реализована данная возможность.
Встроенный HTML редактор, используемый в системе, обновлён до актуальной версии. Исправлены неточности в его работе при редактировании содержания в коде.
Разработана новая система установки, и использование дополнительных полей, применение которых на данный момент возможно в пользовательском и новостных модулях. Настройка и установка дополнительных полей предусмотрена в отделе администратора системы.
Исправления и корректировки
Исправлена ошибка, связанная с некорректным чтением не существующей директории в отделе загрузок панели администратора системы.
Проработаны каналы RSS, приведены к общему стандарту, исправлены не точности, добавлено отображение комментариев при просмотре в браузере.
Исправлена ошибка с просмотром каналов RSS в профиле зарегистрированного пользователя системы, в случае если данная возможность активирована администратором.
Откорректированы все функции работы с каналами RSS, произведена смена фильтрации и определение даты публикации материалов.
Исправлена ошибка AJAX связанная с предварительным просмотром. Удалены лишние, не используемые компоненты.
Исправлена проблема с просмотром не активированных блоков в панели администратора системы.
Откорректирован файл интеграции с форумами. Исправлена проблема появлявшееся при регистрации новых пользователей в случае использования нестандартных префиксов таблиц базы данных.
Исправлена проблема в модуле опросов связанная с голосованием. Проблема присутствовала на версии PHP 5 и была связанна с передачей переменной с идентификатором опроса.
Откорректировано отображение кнопок добавления и редактирования в панели администратора модуля вопросов и ответов.
Исправлена ошибка, связанная с редактированием внедрений в систему при активированном HTML редакторе, который внедрялся и мешал корректному редактированию внедрений.
Исправлена проблема с некорректной работой ББ редактора под браузерами Firefox, Opera в случае использования двух окон ввода.
Откорректировано отображение файлов статистики ошибок и нападений в отделе безопасности панели администратора системы.
Идея состоит в том, чтобы дать пользователю полную свободу действий при формировании темы оформления системы. Обычно управление формирование внешнего вида сайта ложится на систему, сама тема оформления влияет на этот процесс лишь косвенно, то есть она пассивна. Мы уже делали шаги в сторону интерактивности тем оформления вставляя переменные в HTML код и обрабатывая их, но тем не менее заставить тему управлять сайтом было невозможно. Кроме того, оформление сайта разбросанное по отдельным файлам не позволяло выстроить общей картины и затрудняло разработку тем. Даже человеку знакомому с HTML достаточно сложно, было, нарезать готовый HTML шаблон на куски.
Продолжая в том же духе, уместно будет сказать о том, что внешний вид сайта очень сильно зависит от разработчиков системы, другими словами существуют жестко вшитые куски, которые достаточно сложно менять или перемещать, чтобы изменить некоторые из них нужно править саму систему, что прямо скажем не всем и не всегда удобно. Для примера можно назвать такие вещи как табличная структура, модуль, лицензия, генерация страниц, левые правые верхние нижние блоки, а также банеры.
Другими словами задача стояла такая
1. Создать симбиоз ядра системы и темы оформления, когда не только ядро жестко задает правила поведения и отображения элементов системы, но и тема активно управляет видимостью и управлением элементов.
2. Позволить дизайнеру воплощать любые дизайнерские идеи без оглядки на ядро. То есть, хочет чтобы, верхние блоки отображались слева, правые и левые блоки были расположены вместе справа - нет проблем.
3. Не тормозить продвинутых пользователей в реализации различных способов форматирования текста, таких как HTML - различных версий. XHTML и даже XML, то есть наиболее полно реализовать CMS, так как CMS - это система управления контентом, а вот отображение этого контента может быть любым.
4. Решив задачу 2 и 3 увести систему от табличного дизайна и подготовить к отображению на различных устройствах, таких как мобильных, наладонных и так далее...
5. Жестко разграничить понятия оформление и данные.
Итог
Выполнив все поставленные задачи, мы можем смело сказать, что система не будет тянуть пользователей назад, даже тогда когда все дружно решат перейти на DIV, никаких изменений в движке не потребуется нужно будет только поправить дизайн.
Реализация и как всё работает
В пользовательской теме оформления должен присутствовать файл index.html. Это обычный HTML файл, предназначенный для формирования внешнего вида системы. Соответственно надобность в файлах: header.html, footer-close.html и footer-open.html отпадает.
Синтаксис, простейший файл оформления будет иметь вид:
Естественно, верстальщик и дизайнер могут наполнить его любым HTML оформлением и применить все возможные и известные приемы верстки. Как мы видим, табличная структура отсутствует, и мы можем все построить на дивах (DIV) или переписать код в XHTML.
В данном случае и в целом все понятно, просто и наглядно. Остается только объяснить какие переменные вида {%XXXX%} за что отвечают. Расставить эти переменные естественно можно по всему файлу, в каком угодно порядке.
{%HEAD%} - Стандартное формирование шапки - меты и титлы, а также содержание, которое присутствует в системе по умолчанию.
{%MODULE%} - Нарезка для модуля, который должна подставить система.
{%LICENSE%} - Копирайты системы.
{%BLOCKS banner%} или {%BLOCKS b%} - Верхний банер.
{%BLOCKS left%} или {%BLOCKS l%} - Левые блоки.
{%BLOCKS center%} или {%BLOCKS c%} - Верхние блоки.
{%BLOCKS down%} или {%BLOCKS d%} - Нижние блоки.
{%BLOCKS right%} или {%BLOCKS r%} - Правые блоки.
{%BLOCKS foot%} или {%BLOCKS f%} - Нижний банер.
{%BLOCKS time%} или {%BLOCKS t%} – Время генерации страницы.
{%BLOCKS none,ХХХ%} или {%BLOCKS n,ХХХ%} - Произвольный блок системы или свободный блок без оформления, где ХХХ - это либо ID блока, либо название файла блока.
{%BLOCKS standart,ХХХ%} или {%BLOCKS s,ХХХ%} - Произвольный блок системы или свободный блок с оформлением свободного блока, где ХХХ - это либо ID блока, либо название файла блока.
{%BLOCKS message%} или {%BLOCKS m%} – Сообщение на главной странице.
{%BLOCKS variables%} – Анализатор переменных.
{%BLOCKS query%} – Анализатор запросов в базу данных.
Новая система оформления тем будет доступна, начиная с версии SLAED CMS 2 Pro.
Современные тенденции развития “Warez-порталов” поражают, но еще большее удивление вызывают методы, которые используют их администраторы. Для тех, кто еще не понял о чем пойдет речь, приведу простой пример: существует простой сайт, относящийся к категории обзоров программного обеспечения, ничем существенным не выделяется, прибыли не приносит, и, следовательно, ни какой пользы его владельцу не дает. Стандартные методы раскрутки: раздача “халявных” icq-номерков, размещение материалов категории “warez” – не помогают.
Перед администратором подобного ресурса встает непростой вопрос о дальнейшем развитии и даже существовании сайта. Выход есть – западные ресурсы, а вернее их методы раскрутки. Безусловно, это самый простой способ привлечения новых посетителей на свой сайт и получения прибыли от рекламных баннеров. Ведь намного сложнее публиковать собственные обзоры, чем просто копировать их с других, подобных источников.
Отдельное внимание, я думаю, стоит уделить этим самым методам. Вышеуказанные (стандартные) способы, как уже было отмечено, мало, кого интересуют, и являются именно стандартным атрибутом. Портальные системы вида *Nuke, установленные на этих сайтах приходят в негодность. На их смену грядет новая эра – DDL. Выражаясь научным языком, DDL – это Data Definition Language, язык описания данных, используемый для создания и редактирование таблиц в базе данных SQL. Я бы сказал иначе, DDL (в понимании “движка” для сайтов) – это всепоглощающая чернь сети Интернет, заставляющая поголовно, почти каждого администратора или целую группу ведущих софт-обзорного сайта переходить на этот новый “супер-пупер-мегамощный” движок, сводя всю работу к нулю! Основные принципы работы такой системы заключаются в следующем: вместо привычных всем новостных таблиц, здесь располагается лишь одна, содержащая, как правило, три, четыре колонки (название объекта, дата добавления и адрес отправителя), материалы добавляются администраторами других сайтов, при чем им достаточно лишь указать ссылку на объект. Таким образом, все материалы на DDL-движке НЕ имеют описания и скриншотов! И в 50-70% случаев есть реальная возможность получить вместе со скачиваемым объектом, какую-нибудь “дрянь”, и в данном случае речь идет не только о вирусах или троянах. Обусловлена такая ситуация тем, что именно администраторы других ресурсов добавляют новые материалы. Зачем им это надо? Ответ прост – размещение ссылки на их сайт. А если добавить 10 ссылок на программы, “warez”, порнографические материалы, то отдача будет еще больше. И не важно, какие ссылки там размещаются, главное, чтобы имена архивов совпадали с заголовками объектов. А значит можно размещать там что угодно и в каких угодно количествах. А если у недовольных посетителей появятся вопросы или негативные отзывы, то всех их дружно пошлют в… не менее стандартный уже раздел “Disclaimer”, что в переводе значит “Отмазка”, повествующий, грубо говоря, о том, что администраторы ни в чем не виноваты, потому что размещают все бесплатно, и если у Вас после использования предоставленных на сайте материалов ОС вообще не запускается – это Ваши проблемы.
На англоязычных сайтах такая система существует уже приличное количество времени и подобных ресурсов появилось просто немеренное количество. Вот примерный список основных DDL и “warez-порталов”, активно рекламирующих свои сайты с помощью их систем: limneos.net, katz.ws, phazeddl.com, directdownloads.ws, ddldestination.com, ddloutpost.com, ddlgalaxy.com, ddl2.com, xtremedl.com, gotwarez.net, ddlspot.com, warezbs.com, datowarez.info, warezcollector.com, directdl.com, qualityddl.com, ddlworld.com, muchwarez.com, ddlnow.com, warezdownloads.info, warezterminal.com, robowarez.com, directwarez.com, ddl.phrozex.com , atomicddl.com, warezddl.mtvgr.com, novoting.com, ddlporn.com, ddlnetwork.net, submissionz.com, antoddl.com, warezfreaks.com
В рунете же DDL’щиков можно сосчитать буквально по пальцам. Ведь не каждый готов вот так запросто отдать 40, а то и все 60$ за уже готовый движок. Но наши “пытливые умы”, помимо размещения своих материалов на таких сайтах, нашли не менее хороший способ раскрутки – обмен ссылками с DDL-сайтами. Безусловно, он обеспечивает моментальную раскрутку и привлечение нескольких тысяч посетителей. Но! Стоит отметить, что это зарубежная аудитория и ей на врят ли понравиться читать русские новости. И опять встает вопрос, что же делать? И опять наши, русские “умники” находят ответ – перевести весь сайт на английский язык, и новости добавлять в том же стиле. А что, ведь это очень просто! Теперь больше не надо просматривать несколько десятков сайтов в поисках нужного тебе описания, чтобы просто скопировать его себе, без указания авторского права, разумеется. А нужно всего лишь найти официальный сайт программы, который зачастую и предоставляет описание на английском языке, и скопировать оттуда весь текст. Технология “copy / paste” все больше и больше процветает, сокращая работу news-maker’ов до абсолютного минимума! Таким первопроходцем стал AntoSoft.net – гнусный, никчемный сайт, соорудивший недавно свой DDL-отдел.
И вот теперь наступает самое главное – заработок на партнерских программах. Ни одна уважающая себя российская компания вроде Clx.ru или Txtbanner.net не станет регистрировать сайт, размещающий “warez-материалы” в столь откровенном виде. И на смену им приходит новый диктатор условий заработка – Zna.ru. C момента образования партнерской программы вышеуказанного сайта, администраторы чуть ли не всех сайтов с обзорами ПО (на сегодняшний день в базе zna.ru зарегистрировано более 10000 сайтов), решили заполучить таки вожделенные 50 WMZ, от привлечения новых посетителей, а в дальнейшем может быть и клиентов этого “магазина”. Посетителей нужно заставить переходить по ссылкам, а значит, для начала нужно привлечь их внимание. Вот тут то и идут вход самые изощренные методы: раньше, все использовали такую “фишку” как раздел “Девушка дня” (лишь на Debri.ru выкладываются настоящие материалы), за тем вход пошло добавление в раздел “Друзей” и “Партнеров” этой самой реферальной ссылки под заголовком, например, “Free Porno” или “ДеФФки”, а затем и вовсе добавление картинок порнографического характера, ссылающихся на Zna, в каждую новость. А умоляющие просьбы админов сайта 700mb.ru и угрожающие слова о закрытии столь “суперского” раздела, как “эротика”, вызывали широкую улыбку на моем лице.
Таким образом, более 80% сайтов словно сменили тематику, обзоры “софта” – это уже лишь мелочь, главная цель которой заключается в показе того, что сайт регулярно обновляется. Ни в коем случае не подумайте, что я имею в виду сайты типа SoftPortal.com, Soft-Best.net и др. Эти то, как раз никогда не участвовали в подобного рода затеях, и по сей день сохраняют отличную репутацию и места настоящих лидеров в сфере размещения обзоров программного обеспечения. Речь идет о так называемых “порталах”. Настоящий, смысл этого слова, увы, давно утерян, осталось лишь новое “понятие” этого термина, включающее в себя такие аспекты, как построение сайта на движках *Nuke и размещение “warez’a”. Единственный на сегодня стоящий портал (в лучшем смысле этого слова) – WoWeb.ru – зайдите, посмотрите.
Для примера, возьму конкретную историю одного сайта – SoftObzor.net. Составил я ее давно, но нигде не размещал. “Начну, прежде всего, с того, что с момента существования проекта на нем действительно были интересные и полезные материалы, администраторы общались на равных с пользователями. Но после обмена с так называемыми “гигантами” по посещаемости, авторы получили большой прирост в это области, который поднял их с нескольких сотен, до ни одной тысячи посетителей в день. Это их право, и обвинять их в этом было бы совершенно беспочвенно и не обоснованно. Но то, что стало с сайтом после этого, лучше даже и не видеть. Его заполнили “тонны” рекламы, новости выкладывались лишь по принципу “главное, чтобы было, а не то, что есть”, в каталоге программ массовость программ создавалась обманным путем, новости просто копировались с других сайтов схожей тематики (в том числе и с моего), грамматика стала совершенно чуждым понятием news-maker’ов, размещались материалы порнографического характера, причем такие, что хотелось побыстрее уйти с оттуда и не возвращаться никогда! А после вступления в партнерскую программу сайта Zna.ru сайт полностью превратился в “помойку”. Жажда наживы, желание получить таки вожделенные 50$ довели сайт до нынешнего состояния. А с недавнего времени авторы решили, что удобнее всего будет идти по принципу так называемых “собратьев” и на главной странице публиковать новости для англоязычной аудитории. Хороший ход, особенно если учесть обмен ссылками с таким сайтом, как PhazeDLL2, принявшим ту же политику.
Итог - совершенно никчемный сайт с ворованными материалами, администраторами, возомнившими себя чуть ли не богами и презирающими всех, у кого посещаемость меньше 4000 человек в день. У многих вызовет удивление тот факт, что и по сей день у сайта сохраняется стабильная посещаемость в районе 10-12 тысяч. Объясню, обусловлено это всего лишь обменом ссылками с хорошо посещаемыми сайтами – не больше. Ведь зайдя туда один раз, возвращаться уже мало кому захочется. А ведь у сайта было перспективное будущее…”
Эта история размещена в качестве поучительного материала, прежде всего для администраторов web-ресурсов, чтобы они не повторяли эти ошибки. Обращаясь к Вам, уважаемые web-мастера, хочу отметить, что 10-12 тысяч посетителей в день – это не круто, это лишние проблемы. Связано это с тем, что ни одна хостинг-компания не будет предоставлять Вам свои услуги на тех же условиях, как и раньше, при посещаемости, допустим 1000-2000 уникальных посетителей в день. Ежедневный расход траффика в таких случаях составляет 10-15GB трафика! Умножьте это число на 30 и получите ежемесячные затраты. Порой они превышают прибыль, получаемую от рекламы. В итоге, сайт возвращается к ситуации, что и в самом начале нашего с Вами разговора, только в другом обличии: более известном (отнюдь не в русскоязычной среде) и репутацией “помойки”. Подумайте, нужно ли Вам все это.
Чтобы создать собственный модуль для сайта, построенного с использованием SLAED, достаточно простейших знаний HTML и PHP, а также соблюдение их синтаксиса. Кроме этого потребуется правильная постановка задачи и внимательность. В качестве примера ниже приведены коды модулей, созданные для использования на всех версиях системы SLAED. При реализации модулей учитывайте, любой PHP код должен начинаться c <?php и заканчиваться ?>
1. Создание простейшего модуля
1.1. Представим себе, что Ваш сайт только на русском языке. Вы хотите для этого сайта сделать модуль «О компании». Для этого Вам нужно в директории http://www.ваш_сайт.com/modules/ создать поддиректорию «About_Company». В этой поддиректории должен находиться файл index.php. Вот как это должно выглядеть:
(Кроме модуля «About_Company» на скриншоте представлен ещё и модуль «Account».)
В файле index.php для простейшего модуля должен быть такой код:
Без комментариев код модуля «О компании» выглядит так:
В содержимое модуля можно вставлять не только текст, но и HTML-код, а также PHP-код. HTML-код нужно вставлять с соблюдением синтаксиса языка PHP.
1.2. Допустим, Вы хотите кроме текста на русском языке вставлять в модуль ещё и какие-то картинки. Для этого нужно добавить в директорию «About_Company» модуля «About_Company» поддиректорию «images», в которой будут храниться графические файлы. Структура директорий и файлов модуля «About_Company» будет выглядеть так:
building.jpg — это фотография здания компании company_logo.gif — это логотип компании director.jpg — это фотография директора фирмы index.html — это пустой файл, который нужен для того, чтобы невозможно было просмотреть браузером содержимое директории «images» map.gif — это карта проезда к зданию компании
Разумеется, могут быть и другие графические файлы. Вы можете задавать свои имена графическим файлам.
1.3. Предположим, что Ваш сайт не на одном языке (только на русском), а на нескольких языках (русском, английском и немецком). В этом случае структура директорий и файлов модуля «About_Company» будет выглядеть так:
language — это директория, содержащая в себе языковые файлы
.htaccess — этот файл запрещает всем доступ в директорию «language», в этом файле должна быть такая строка:
Файл .htaccess нужно создавать, редактировать и сохранять только в программе «Блокнот» (Notepad) под Windows, так как этот файл должен быть сохранён в кодировке Unix, что обеспечивает его правильную работу на web-сервере, использующего операционную систему Unix или ей подобную (Linux, FreeBSD).
index.html — это пустой файл, который нужен для того, чтобы невозможно было просмотреть браузером содержимое директории «language» lang-english.php — языковый файл модуля на английском языке lang-german.php — языковый файл модуля на немецком языке lang-russian.php — языковый файл модуля на русском языке
Код модуля «About_Company» в этом случае будет иметь вид:
Без комментариев код модуля «About_Company», который работает на мультиязычном сайте, имеет вид:
В языковых файлах lang-english.php и lang-german.php информация, представленная в файле lang-russian.php, должны быть переведена на соответствующие языки.
В данном примере всё содержимое (контент) и внутреннее оформление (дизайн) модуля «About_Company» находится в языковых файлах. Для более сложного содержимого модуля (таблицы, например) целесообразно размещать HTML-код в файле index.php модуля «About_Company», а в языковые файлы нужно выносить только языковые константы (define("_ABOUT_COMPANY_TITLE","О компании");, например), что существенно облегчит работу с языковыми файлами, а также позволитс меньшими затратами времени вносить изменения в контент и дизайн модуля.
1.4. Для доступа к страничке со списком учредителей компании нужно применить оператор switch.
Код файла index.php модуля «About_Company» должен иметь вид:
Без комментариев код модуля «About_Company» будет выглядеть так:
В языковом файле http://www.ваш_сайт.com/modules/About_Company/language/lang-russian.php (а также в файлы lang-german.php и lang-russian.php) должна быть языковая константа _ABOUT_COMPANY_FOUNDERS. Файл lang-russian.php будет иметь вид, как было указано выше.
Указанный модуль не хранит информацию в базе данных, что позволяет чуть быстрее выводить эту информацию на страничку в браузер посетителя сайта, к тому же такой способ хранения информации меньше загружает MySQL-сервер хостера.
Для внесения новой информации, для редактирования существующей информации в файлах модуля (языковые файлы http://www.ваш_сайт.com/modules/About_Company/language/lang-russian.php) требуются начальные знания синтаксиса HTML и PHP.
Чтобы создать собственный блок для сайта, построенного с использованием SLAED, достаточно простейших знаний HTML и PHP, а также соблюдение их синтаксиса. Кроме этого потребуется правильная постановка задачи и внимательность. В данной статье мы рассмотрим варианты ручного создания файловых блоков. В качестве примера ниже приведены коды, созданные для использования на всех версиях системы SLAED.
Для начала необходимо создать файл в директории блоков blocks/ Для того, что бы система идентифицировала данный файл как файловый блок, название файла должно быть такого типа: block-ваше_название.php В самом файле, для вывода информации необходимо использовать переменную $content за место стандартных методов echo или print, это единственная отличительная особенность которую нужно учитывать. Всё остальное реализуется при помощи стандартных методов и функций PHP и HTML. При реализации блоков учитывайте, любой PHP код должен начинаться c <?php и заканчиваться ?>
Ниже мы рассмотрим варианты реализации блоков на примерах реализованных в коде, с комментариями участков.
Пример 1
Пример 2
В примерах ниже мы рассмотрим варианты вывода информации в блок из других файлов.
Для работоспособности примеров:
1. Создаём файл demo.txt в директории blocks/ Директория значения не имеет, файл может находиться на другом сайте. Важно указать точный путь к файлу!
2. В файле напишите произвольный текст на своё усмотрение. Содержание данного файла может быть любым.
В качестве содержание файла demo.txt предлагаю использовать изначальный текст:
Пример 3
Пример 4
После того как файловый блок создан и находится в директории blocks/ необходимо добавить и активировать его в панели администратора системы, в отделе блоков: Панель администратора >> Блоки и баннеры >> Добавить новый блок
Заголовок – Указываем название для блока
Ссылка на канал RSS – Оставляем пустым
Время обновления – Оставляем как есть
Имя файла – Выбираем созданный файловый блок
Содержание – Оставляем пустым
Позиция – Выбираем на своё усмотрение
Отображать блок в модулях - Выбираем на своё усмотрение
Язык - Выбираем на своё усмотрение
Активировать? – Да
Время работы, в днях – 0 без ограничений
После истечения – Если без ограничений, оставляем как есть
Кто это будет видеть? - Выбираем на своё усмотрение
В двух предыдущих частях мы познакомились с основами «правил перезаписи» URL и «условиями правил». Позвольте предложить к рассмотрению два примера, иллюстрирующих более сложные приложения. Первый пример имеет дело с динамическими страницами, а второй показывает возможности вызова «.txt» файлов и произведение различных действий над ними.
Предположим, что у нас есть виртуальный магазин по продаже каких-то товаров. Клиенты обращаются к описаниям товаров через скрипт:
Эти адреса представлены как ссылки на большинстве страниц сайта.
А теперь допустим, что вы решили добавить сайт для индексации в поисковые системы. Тут вас поджидает небольшая неприятность – не все поисковики принимают, понимают и индексируют URL, в которых содержится символ «?».
Более естественным и приемлемым для поисковика является URL вида:
http://www.yoursite.com/cgi-bin/shop.cgi/product1
В данном случае символ «?» заменяется на «/».
Еще более комфортабельный URL с точки зрения поисковика будет иметь вид:
http://www.yoursite.com/shop/product1
Для поисковика, «shop» теперь как-бы является директорией, содержащей товары product1, product2 и т.д.
Если пользователь, со страницы результатов запроса в поисковике проследует по такой ссылке, то эта ссылка должна будет трансформироваться в ссылку: shop.cgi?product1.
Чтобы добиться такого эффекта можно использовать mod_rewrite, используя следующую конструкцию в файле .htaccess:
Переменные $1 и $2 составляют так называемые "backreferences". Они связаны с текстовыми группами. Вызываемый URL разбивается на части. Все, что находится перед «shop», плюс все что находится после «shop/» определяется и хранится в этих двух переменных: $1 и $2.
До этого момента, наши примеры использовали «правила» типа:
Однако мы еще не достигли истинной перезаписи URL адресов, в смысле того, что один URL должен перенаправлять посетителя на другой.
Для нашей записи вида:
применяется общий синтаксис: RewriteRule текущийURL перезаписываемыйURL
Как видите, эта директива выполняет действительную «перезапись» URL адреса.
В дополнение к записям в файл .htaccess, нужно еще заменить все ссылки на сайте, которые имеют формат «cgi-bin/shop.cgi?product», на ссылки вида: «shop/product»
Теперь, когда поисковик найдет страницу с подобными ссылками, он проиндексирует сайт без всяких видимых проблем.
Таким образом вы можете превратить чисто динамический сайт в сайт, имеющий статическую структуру, что явно принесет пользу в вопросе индексирования различными посковыми машинами. Обратите внимание на вид URL адресов на данном сайте. Вдобавок ко всему, они имеют еще и легкочитамую для человека структуру - ЧПУ (человекопонятный УРЛ). Но об этом мы поговорим в другой статье.
В нашем втором примере мы обсудим, как переадресовать запросы «.txt» файлов к сценарию программы.
Многие хостинг провайдеры, работающие с Apache предоставляют лог-файлы в общем формате. Это означает то, что они не будут соджержать поля с ссылающимися страницами и юзер-агентами.
Однако, относительно запросов к файлу «robots.txt», предпочтительно иметь доступ ко всем этим данным, чтобы иметь больше информации о посещении поисковиков, чем просто знать их IP адреса. Для того, чтобы оганизовать это, в «.htaccess» должны быть следующие записи:
Теперь при запросе файла «robots.txt» наш RewriteRule переадресует посетителя (робота) к обрабатывающему запросы скрипту text.cgi. Кроме того, переменная передается скрипту, которая будет обработана в соответствии с вашими нуждами. «REQUEST_URI» определяет имя запрашиваемого файла. В данном примере это – «robots.txt». Скрипт прочтет содержание «robots.txt» и отправит его web-браузеру или роботу поискового сервера. Таким образом, мы можем считать хиты посетителей и вести свои лог-файлы.
С этой целью, скрипт будет использовать переменные окружения «$ENV {'HTTP_USER_AGENT'}» и т.д. Это обеспечит получение всей требуемой информации. Вот исходный текст для сценария cgi, упомянутого выше (пример взят с сайта http://fantomaster.com):
Загрузите файл с данным содержимым в корневую или в DocumentRoot директорию сервера и установите права доступа у файлу (chmod) 755. Затем, создайте каталог «stats». Более детальное описание о том, как установить скрипт вы можете получить на сайте разработчика.
Если настройки вашего сервера не позволяют исполнять cgi-сценарии в главной директории (DocumentRoot), то попробуйте следующий вариант:
Обратите внимание, что в этом случае, будет необходимо изменить пути в коде скрипта!
Наконец, вот решение задачки, данной в предыдущей части этой публикации:
Если мы пишем в регулярном выражении «^212.37.64» вместо «^212.37.64.» (с точкой в конце), то даст ли это тот же самый эффект, и будут ли исключены те же самые IP адреса?
Регулярное выражение ^212.37.64 удовлетворяет и применимо к следующим строкам:
Следовательно, последняя цифра «4» может сопровождаться любой символьной строкой. Однако, максимальным значением IP является адрес 255.255.255.255 – который подразумевает, что например 212.37.642.12 – неправильный (недопустимый) IP. Единственный допустимый IP в вышеприведенном списке – 212.37.64.12!
В прошлой главе мы познакомились с основами модуля mod_rewrite. В примере, который был рассмотрен, мы использовали конструкцию, которая в буквальном смысле означает следующее: «Если кто-то пытается получить доступ к файлу .htaccess, выдается ошибка, сообщающая, что доступ к файлу запрещен».
Это «правило» глобально, то есть каждый получит указанное сообщение об ошибке. Напомню, что mod_rewrite является модулем, который предоставляет «основанный на правилах механизм динамического изменения запрашиваемых URL-ов».
Мы можем ограничивать «правило» при помощи различных «условий правила». «Правило» будет выполнено только в том случае, если перед ним будет встречен ряд условий.
Синтаксис: условие должно предшествовать правилу!
Возьмем еще один пример (запись в файле .htaccess):
Назначение первых трех записей было подробно разобрано в первой части публикации. Их функция - включение «движка перезаписи», то есть самого модуля.
Последние две строки запрещают доступ поисковому роботу под кодовым названием «EmailSiphon» (имеется ввиду имя юзер-агента). Данный робот является сборщиком почтовых адресов с различных веб страниц.
Проверочная строка – переменная сервера, которая может быть записана в общей форме: «% {ИМЯ_ПЕРЕМЕННОЙ}».
Образец условия – регулярное выражение. Для более полного понимания темы стоит рассмотреть регулярные выражения как класс.
Регулярные выражения – это механизм, позволяющий задать шаблон для строки и осуществить поиск данных, соответствующих этому шаблону в заданном тексте. Кроме того, дополнительные функции по работе с такими выражениями позволяют получить найденные данные в виде массива строк, произвести замену в тексте по шаблону, разбиение строки по шаблону и т.п. Однако главной их функцией, на которой основаны все остальные, является именно функция поиска в тексте данных, соответствующих шаблону (образцу), описанному в синтаксисе регулярных выражений.
Регулярные выражения подобны маленькому, компактному языку программирования со своими правилами.
Например, регулярное выражение:
заменит строку «abc», на строку «xyz» во всем тексте.
Вот краткий обзор наиболее важных элементов с некоторыми примерами:
. (точка) - текст (любой символ)
| - чередование (то есть/abc|def/)
* - квантификатор (разрешено любое число)
^ $ - якоря строки
s - оператор (string1 заменить на string2)
g - модификатор (искать по всему тексту)
Регулярные выражения конструируются с помощью этих элементов и других «обычных» символов. Они не являются отдельным языком, а используются другими средствами, например языками программирования типа Perl или PHP, а также текстовыми редакторами (Emacs).
Если говорить о связи регулярных выражений и модуля mod_rewrite, то они используются в директивах RewriteRule и RewriteCond.
«^» обозначает начало строки. Из этого следует, что UserAgent должен начинаться со строки «EmailSiphon» и ни с чего другого («NewEmailSiphon», например, не работал бы).
Но, поскольку данное регулярное выражение не содержит символ "$" (якорь конца строки), UserAgent мог бы быть, например, «EmailSiphon2».
Последняя строка нашего примера:
определяет, что именно нужно делать, когда робот запросит доступ.
Регулярное выражение «^.*$» означает: «Доступ ко всем файлам запрещен».
Точка «.» в регулярном выражении – мета символ (подстановочный знак), означающий любой случайный символ.
«*» означает то, что строка может встречаться неограниченное количество раз. В этом случае, независимо от имени запрошенного файла, будет выдана ошибка.
«EmailSiphon», конечно, не единственный почтовый сборщик. Другой известный член этого семейства - «ExtractorPro». Допустим мы хотим запретить доступ и этому роботу. В таком случае нам необходимо еще одно условие.
Теперь файл .htaccess будет выглядеть так:
Третий аргумент [OR] (в первой строке RewriteCond) называется «флагом». Существуют два возможных флага:
NC – не учитывать регистр букв.
OR – означает «или следующее условие».
Флажок NC позволяет игнорировать регистр букв в искомом образце. Например:
Эта строка определяет, что и "emailsiphon" и "EmailSiphon" будут признаны как идентичные выражения.
Вы можете использовать сразу несколько флажков, разделяя их запятыми.
Нет никаких ограничений по числу условий. Таким образом, Вы можете блокировать 10, 100, 1000 или более известных почтовых сборщиков. Определение этих 1000 условий – просто вопрос загрузки сервера и прозрачности файла «.htaccess».
В вышеупомянутом примере используется глобальная переменная «HTTP_USER_AGENT». Существуют также другие переменные: REMOTE_HOST, REMOTE_ADDR
Например, если Вы хотите заблокировать паука пришедшего с www.site.ru, Вы можете использовать глобальную переменную «REMOTE_HOST» таким образом:
Если Вы хотите заблокировать определенный IP адрес, условие будет выглядеть так:
В регулярном выражении по проверке точного и полного IP адреса нужно использовать начальные и конечные якоря.
Также можно исключить целый диапазон:
Этот пример показывает, как можно заблокировать диапазон IP адресов с 212.37.64.0 по 212.37.64.255.
А вот маленькая задачка для проверки приобретенных знаний (решение будет дано в следующей части):
Внимание, вопрос!
Если мы пишем в регулярном выражении «^212.37.64» вместо «^212.37.64.» (с точкой в конце), то даст ли это тот же самый эффект, и будут ли исключены те же самые IP адреса?
До сих пор мы использовали простой RewriteRule, который генерирует сообщение об ошибках. В третьей части публикации мы проанализируем, как можно использовать RewriteRule для переадресации посетителей к определенным файлам.
Вы наверняка встречали в сети термин «mod_rewrite». Для наших читателей, которые не до конца знакомы с этим модулем веб сервера Apache, а также для тех, кто вообще первый раз об этом слышит – постараюсь рассказать в этой публикации (в нескольких частях) подробнее о данном модуле.
Модуль mod_rewrite является программным модулем веб сервера Apache (обратите внимание, что он не будет выполняться под другими веб серверами!). Его первичная функция - манипуляция действий с URL. Модуль очень универсален и разносторонен, поэтому я постараюсь показать здесь множество реальных примеров.
Mod_rewrite является замечательным модулем, который предоставляет «основанный на правилах механизм динамического изменения запрашиваемых URL-ов». Это действительно мощный инструмент, и поэтому, его знание принципиально важно, если вы хотите стать подлинным веб мастером или веб программистом. Не столько принципиально, будете ли вы использовать его в своей работе, сколько важно то, что вы знаете, что он может делать, и сможете поведать об этом своему боссу, когда появится желание сделать что-нибудь странное с веб сервером.
Однако нужно быть очень осторожным и даже дотошным при работе с этим модулем! Некоторые ошибки, которые Вы способны допустить, могут привести к логической петле, причиняя непрекращающуюся 100%-ую загрузку ценрального процессора (CPU).
Чтобы не казаться пространным в рассуждениях, приведу некоторые очень простые примеры.
Прежде, чем мы сможем приступить к работе, Вы должны будете проверить, установлен ли модуль на вашем веб сервере или нет.
Есть несколько способов проверить это:
1. Спросить вашего системного администратора - знает ли он (или она) о наличии этого модуля на веб сервере. Они действительно должны знать, но как показывает практика – попадаются и не очень сведующие сисадмины ...
2. Не напрягайте других: если Вы используете ваш веб сервер с сотнями других доменов, ваши действия могут разбудить некоторых спящих собак, поскольку использование mod_rewrite будет всегда влечь за собой некоторую увеличенную загрузку ценрального процессора.
3. Проверить ваш файл конфигурации Apache (httpd.conf), если Вы имеете к нему доступ. Один из возможных стандартных путей может быть: /etc/httpd/httpd.conf
Однако, ваш путь может очевидно отличаться от этого. Проверить работу вашего сервера с ниже приведенными примерами. Если сервер работает без ошибок – mod_rewrite действительно установлен на вашей системе. Если нет, Вы получите следующее сообщение при запросе любой web-страницы с вашего сервера: «Внутренняя ошибка сервера» Также, Вы увидите такую запись в файле «error.log»: «Invalid command 'RewriteEngine', perhaps mis-spelled or defined by a module not included in the server configuration».
Теперь давайте копнем поглубже и посмотрим первый практический примерчик.
Предположим, что Вы будете использовать mod_rewrite только для вашего собственного сайта, то есть не как обобщенную перекрестную установку сервера.
Для нашего примера потребуется использование файла .htaccess. Для работы этого метода, Вы должны загрузить файл под названием «.htaccess» (пожалуйста, обратите внимание на точку в начале имени файла!) в папку сервера, с которой Вы будете работать. Это можно сделать через telnet или ftp. (Предупреждение: .htaccess должен быть загружен в «режиме ASCII», то есть не в бинарном режиме!)
Если у Вас уже имеется файл «.htaccess», например со следующими записями:
то просто добавьте снизу наш образец кода к уже существующему (Важно: редактируйте ваш файл .htaccess в ASCII-редакторе типа Notepad).
Первые две записи запустят сам модуль:
Совет: запись «RewriteEngine off» отменит все последующие команды. Это - очень полезная особенность: вместо необходимости комментировать все последующие строки – все, что Вы должны сделать, это установить «off».
Если ваш системный администратор запрещает Вам использование «Options +FollowSymlinks», Вы не сможете ограничить использование mod_rewrite для отдельных каталогов, вместо этого изменения будут действовать на весь сервер.
Следующая необходимая запись - это:
«/» является корневым (основным) URL. Если у Вас какой-то другой URL, Вы можете указать это в данной директиве, однако «/» – обычно эквивалентно адресу «http://домен.ру».
А теперь, господа, перейдем к более интересным записям!
Предположим, что вы хотите защитить от несанкционированного доступа ваш файл .htaccess. На некоторых серверах Вы можете легко читать этот файл просто вводя URL следующего формата в поле адреса вашего браузера: http://www.domain.com/.htaccess – серьезное упущение защиты, так как содержание вашего .htaccess может показать важную информацию об установках и настройках вашего сайта человеку, знающему как эти знания применить против вас.
Чтобы блокировать этот доступ, запишем следующее:
Это правило переводится так:
Если кто-то пробует обращаться к файлу .htaccess, система должна произвести код ошибки «HTTP response of 403» или «403 Forbidden - You don't have permission to access /.htaccess on this server».
Конструкция ^.htaccess$ в этом регулярном выражении означает:
^ – якорь начала строки
$ – якорь конца строки
. – в регулярных выражениях точка «.» обозначает мета-символ и должна быть защищена обратным слэшем (backslash), если Вы все-таки хотите использовать именно фактическую точку.
Имя файла должно быть расположено точно между начальным и конечным якорем. Это будет гарантировать то, что только это определенное имя файла и никакое другое, сгенерирует код ошибки.
[F] – специальный «запрещающий» флажок (forbidden).
В этом примере, файл ".htaccess" теперь будет состоять из таких строк:
Если мы добавим наш код (в примерах) к существовавшему ранее файлу «.htaccess», то получим следующую конструкцию:
Это введение затрагивает лишь основы, требуемые для того, чтобы работать с модулем mod_rewrite. Во второй части этой обучающей серии статей постараюсь объяснить использование различных условий в конфигурировании модуля.
Ссылка по теме: URL Rewriting Engine
Автор статьи: Denveroid
Источник: sitemaker.ru