1. Читая чужой блог, мы листаем посты, ходим по страницам, по категориям, жмем на теги. Иногда мы проделываем довольно длинный пусть по сайту. И, например, страшно нам блог понравился. На следующий день мы открываем этот же блог и хотим продолжить чтение, но… не помним где мы остановились. Судорожно ищем место, не находим. Читать уже знакомые заголовки, когда ищешь что-то новенькое раздражает неимоверно. Листать страницы по 5 постов на каждой раздражает еще больше (ну почему нельзя было сделать по 20 постов хотя бы?!).

А почему бы автору блога не сделать следующее?

Например, где-то вверху есть галочка «Запомнить, что я читал последним». При нажатии на нее пользователь может покинуть сайт, а при повторном открытии браузера (хоть через год) он попадет на ту самую страницу, которую читал последней.

Девид Блейн, остановись, демон! Как это?! А очень просто. Когда пользователь жмет галочку, то на сайте врубается простой механизм: при переходе на очередную страницу пользователю записывается Cookie с URL или URI этой страницы. Когда пользователь заходит на сайт с другого сайта или из «чистого» браузера, мы проверяем реферер и если пользователь пришел не с нашего сайта, то делаем редирект на последний записанный URL. Конечно значение галочки «Запомнить, что я читал последним» тоже нужно записать в Cookie.

Или даже так: URL сохраняется в Cookie в любом случае, но если галочка не установлена, то редиректа не происходит (для того, чтобы всегда точно знать, что пользователь прочитал последним).

2. Еще более глобальная система закладок. Причем индивидуальная для каждого пользователя и, понятное дело, доступная без регистрации (я вообще регистрации ненавижу).

Скажем, в боковой колонке есть блок под названием «Вот это я читал», а в постах под заголовком есть ссылка «Запомнить этот пост». Когда пользователь жмет на «запомнить», то в блоке появляется ссылка на этот пост. Ну и, скажем, запомнить можно сколько угодно постов.

Реализация тоже простая. Для этого тоже достаточно одной только Cookie. Правда записывать туда придется уже не URI, а ID поста из базы данных, т.к. мы должны иметь возможность отобразить заголовок поста в блоке. В Cookie же можно просто записывать ID через запятую, а при неободимости разбивать строку через «разделитель «запятая»" функцией explode и считывать все, что нам нужно из БД.

Да, почему я не назвал это «Закладками» и «Добавить в закладки». Потому, что, очевидно, пользователи будут путать это с закладками браузера, а нужно сделать так, чтобы даже никаких ассоциаций в эту сторону не появлялось.

Эпилог. Вторая идея – это продолжение первой. И, к сожалению, на мой взгляд она немного сомнительна. Ее можно использовать, например, в инернет-магазинах в качестве функции а-ля «сравнить товары» или «отобрать понравившиеся». Но… Сами понимаете. А вот первая, я считаю, вполне себе идеища и достойна реализации. Она помогает и пользователю и повышает крутость ресурса в глазах пользователя («- Толян, смотри, какая там прикольная фишка!»). Главное, дать пользователю выбор, сохранять или не сохранять страницу последнего посещения.

Возник вопрос о том, что для каждой страницы надо как-то задавать title, description и keywords (для SEO). Нужно было быстро реализовать это решение.

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

За 0.0141 секунды раздумий я придумал следующую систему, которая позволяет не перерабатывать весь движок.

Понятно, что каждая страница сайта имеет свой URL. URI – это тот же URL, только без домена. Его можно получить из переменной $_SERVER["REQUEST_URI"]. Понятно, что для каждой страницы URI свой собственный (иначе это уже одна и та же страница).

И возникает очень простая система. Создаем таблицу в БД с полями «title, key, descr, uri». В том месте, где должны выводиться title, description и keywords пишем что-то вроде:

<?php
$uri = $_SERVER["REQUEST_URI"];
if ($uri == «/index.php») $uri = «/»;
$q = mysql_query («SELECT * FROM table WHERE uri=’$uri’;»);
if (mysql_num_rows ($q) > 0){
$str = mysql_fetch_array ($q);
$t = $str['title']; $k = $str['key']; $d = $str['descr'];
}
?>
<meta name=»keywords» content=»<?php echo $k; ?>» />
<meta name=»description» content=»<?php echo $d; ?>» />
<title><?php echo $t; ?></title>

Понятно, что в таблицу записывается заголовок, описание и ключевики для того адреса, для которого мы хотим задать их. И работать это будет для всех страниц, которые обрабатывает движок (то есть в данном случае – для всего сайта вообще). А администратор получает возможность задавать заголовки, ключи и описание даже для тех страниц, которые в ТЗ не предусмотрены, плюс в следующих модулях не нужно будет реализовывать «внутреннюю» поддержку title, keywords и description.

Конечно, не забудьте о безопасности! Проверяйте это выражение перед передачей его в базу. Обычно оно проверяется очень просто – нельзя использовать никакие символы, кроме слеша, точки, букв и цифр.

Считается, что готовые движки экономят время на разработку сайта. Так ли это на самом деле?

Сначала я поставил Drupal. Чего я не понял сразу – как добавлять статьи по категориям. То есть какое-то меню на сайте есть, а вот как привязать туда статьи, сделать подменю и т.п. не понял. Разбирался долго, выяснилось, что существует какая-то таксономия (или как ее), как она работает я до конца не вьехал, убив на это дня 2. Всем, кто скажет, «да это же просто, а ты лох» – засуньте свое мнение подальше. Для человека, первый раз попробовшего разобраться в друпале странно даже то, что администрирование происходит прямо на сайте, а ссылки на разные настройки и модули появляются прямо в меню сайта, если зайти под администратором.

Хотя вру, кое-как мне удалось привязать статьи. Даже предположим, что мне это удалось хорошо и все стало понятно. Едем дальше: документация для разработчика. По движку нет документации! Как и что работает приходится узнавать из гугла, причем никто из «гуру друпала», мудаки, подробно объяснять не хочет. Зато они направо и налево орут, какой друпал крутой. Выходит, чтобы разобраться в движке, нужно в нем самом и ковыряться. Это, мягко говоря, гораздо дольше, чем написать свой движок для сайта. Кстати, отзывы о книгах а-ля «Drupal for idiots» тоже не вдохновляют – не хочется полдня искать книгу, потратить рублей 600 на нее, а потом понять, что она не поможет. Большинство мнений за то, что в подобных книгах далеко не исчерпывающая, а иногда и вовсе неверная, информация. Что вряд ли поможет понять движок.

Теперь о шаблонах. Для старта не хочется заказывать дизайн, поэтому было бы логично поискать стандартный шаблон. По аналогии с WordPress’ом первым делом я полез на официальный сайт. Где ничерта не нашел. Вернее нашел штук 50 отвратительнейших шаблонов. Все усложняется еще и тем, что есть две версии-ветки друпала – пятая и шестая. Понятное дело, если шаблон для пятой, то для шестой он не подойдет. А брать пятую версию как-то не хочется, она же старая и не поддерживаемая разработчиками.

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

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

Следующей я установил Joomla. Расстрою наперед – после этого я ничего не устанавливал, т.к. бесплатные портальные движки на этом заканчиваются (делать портал на какой-нибудь SimpleCMS или DLE – бред). Немного уточню, я установил не Joomla, а Joostina (joostina.ru), один из уже многочисленных «детей» Joomla.

Здесь все намного лучше, чем в предыдущем варианте. Как добавлять материалы понятно сразу, админка вообще куда более понятная, не запутанная и даже приятная.

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

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

Слава богу, разрабы джумлы используют возможности актуальных версий PHP: код не процедурный (как в друпале), используются классы и всякие другие модные штуки. Это облегчает восприятие (во всяком случае мне) и читаемость кода. Книг по джумле, правда, я не видел.

Итог для джумлы: жить будет, попытаться что-то сделать на ней действительно можно. Не факт, что получится (см. ниже).

А можно ли сделать сайт, ничего в сайтостроении не понимая?

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

Максимум, что получится сделать, ничего ни в чем не понимая, это шаблонный сайт. Скорее всего он будет довольно страшным и организованным не так, как хочется. Например, я хочу, чтобы на главной выводились ссылки на последние статьи, а в шаблоне, который мне понравился, на главной вообще ничего не выводится. Нужно же лезть в код, что-то там писать. А как писать, если не понимаешь даже словосочетания «лезть в код»?

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

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

Я не разработчик, но сайт сделать очень хочется!

Хотя есть промежуточный этап. Вот, что надо знать для того, чтобы сделать относительно норальный сайт-портал (или сайт-не-портал):

• Знать, как «работает интернет»: что такое хостинг, что такое домен, как из связать (DNS)
• Как загружать файлы по FTP
• Что такое MySQL (не как с ней работать, а что это)
• Основы HTML
• Основы CSS
• Основы Photoshop или другого графического редактора
• [не обязательно, но очень поможет] Основы PHP

Таким образомы, появляется возможность: купить домен и хостинг, загрузить файло на сервер (FTP), нормально установить любой готовый движок (понадобится знание о MySQL), загрузить любой понравившийся шаблон (опять FTP), подредактировать его по-мелочи (HTML + CSS), подредактировать графику (Photoshop). Честно говоря, вообще, не знаю, чем может помочь знание ОСНОВ PHP, ведь без серьезной работы с ним сделать что-то умное не получится, даже исправить ошибки на сайте. Но для общего развития и для большей уверенности в своих силах не помешает.

Будет несколько частей, сколько – я не знаю. Если что-то хочется узнать или спросить – всегда пожалуйста.

Если до сих пор непонятно, что я буду вещать, поясняю: как «по кубикам» написать CMS портального типа, не зная программирования. Как сделать голосование, блоги пользователей, регистрацию пользователей, каталоги и прочее, прочее, прочее. Похоже, можно делать неограниченное количество таких постов.

Это первая часть, поэтому несколько моментов: я учту, что заботиться о безопасности скриптов нужно сразу, по совету умных людей (простите, уже запамятовал, с кем спорили), писать будем на PHP, и все-таки необходимо знать хотя бы основы программирования на PHP. Если непонятно, что читать, см. один из старых постов: Как стать программистом.

На серию статей планы наполеоновские:

1. Шаблоны. (этот урок)
2. Движок для вывода статических страниц.
3. Прикрутить Smarty.
4. Авторизацию пользователей.
5. Опросы.

Осталось писать регулярно. Итак, к уроку.

Шаблоны или встроенный дизайн?

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

Если отбросить детали, то есть 2 способа обработки дизайна (форматирования вывода данных). Первый – это встроенный в движок дизайн. Второй – шаблонизатор (и шаблон дизайна).

Встроенный дизайн.

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

Итак, к сути. Например, у нас есть какое-то оформление а-ля <div id=’aaa’></div>, а между <div> нам нужно вывести какую-то информацию. Тогда в этом случае, мы просто выводим ее с помощью операторов PHP прямо в файле сценария *.php: <div id=’aaa’><?php echo $a; ?></a>

Получается, что если у нас 30 разных файлов, то в них по кускам везде появляется оформление (HTML). И поменять его или найти именно тот сценарий, куда закралась ошибка оформления становится сложно.

Шаблонный дизайн.

При этом весь дизайн оформляется в виде отдельного файла с HTML-разметкой, куда вставляются метки для вывода информации. Часто файл с дизайном имеет расширение *.tpl, и его содержимое похоже на такое: <div id=’aaa’>{title}</div>. Потом PHP-сценарий должен обработать этот файл, считать его содержимое, заменить «метки» (для примера здесь {title}) на реальную информацию и вывести все это пользователю.

Все распространяемые CMS поддерживают шаблонный дизайн, что обеспечивает возможность создавать для них темы оформления. Тогда их нужно просто залить в отдельный каталог и включить через админку. Как видите – и править их легче, все в одном файле, наглядно и понятно.

Шаблонизаторы.

Обычно так называются скрипты (модули движка), обрабатывающие эти самые шаблоны из предыдущего пункта. Очень хороший пример такого шаблона – Smarty, очень рекомендую к рассмотрению и изучению. Хороший пример собственно написанного шаблонизатора – это DLE.

Часто программисты не пишут свой шаблонизатор, а встраивают в свой движок Smarty. Я думаю, что это лучший выход, т.к.:

1) Уже все написано, не тратится время на создание шаблонизатора;
2) Он работает быстро. Если новичек попробует написать свой шаблонизатор, он, возможно, будет работать медленнее;
3) Он бесплатно распространяется и бить Вас за это не будут;
4) Очень важно, что другой разработчик сразу будет знать как работать с ним.

Конечно, этот пост кажется совсем не для новичков :) Но это первое, на что мы наткнемся на «практических занятиях», т.к. оформление (вывод) информации в браузер есть даже в самом минималистическом скрипте.

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

Пришло время второй части саги о создании собственного движка блога.

Первая часть здесь. Но перед этим пара слов на отвлеченную тему.

В предыдущем посте я просил помочь моей супер-черепахе на домик для нее, и уже через несколько часов откликнулся замечательный человек – Илья, пожертвовал в фонд 70 рублей. Он по «призванию» СЕОшник и недавно открыл свой блог, который обещает быть очень неплохим: SEO in Soul.ru, Душевный Блог о SEO и Заработке.

Теперь о создании своего движка блога. Я реализовал следующее: создание/редактирование/удаление постов, создание/редактирование/удаление категорий, написание комментариев и их редактирование через систему администрирования. Скачать то, что получилось можно по ссылке в конце поста (там пока что архив без редактирования комментариев из админки). Когда дойдем до безопасности, я залью этот движок на тестовый поддомен и можно будет посмотреть, что вышло. И опять эта статья обещает быть очень длинной. Боюсь, что придется ее разрезать еще на три части – авторизация в админке (эта статья), действия с постами и категориями, действия с комментариями и комментирование. А потом еще две части – вывод всего этого на сайт и безопасность движка. Пора писать книгу. (Если кого-то не устраивает такая «санта барбара» – пишите, буду делать статьи длиннее)

Для начала замечу, что все GET-параметры передаются через .htaccess и «откуда они берутся» вопрос не принимается :) Это я объяснил в первой части.

Создание системы администрирования.

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

Располагается она по адресу /vrotmnenogi-admin/, как заявлено в ТЗ (см. первую часть). Я довольно быстро раскаялся в своей дурацкой шутке, т.к. писать везде такой длинный адрес не особенно удобно :). Но от ТЗ мы не будем отступать принципиально, это полезный навык. Простите мне такой бред, я честно не хотел :lol:

Конечно, для начала нужно сделать в админке систему входа, чтобы кто попало не мог редактировать содержимое блога. Авторизация будет вполне обычная – через логин и пароль. Их md5-хеш будет сохраняться в Cookie и по нему пользователь будет проверяться каждый раз, когда что-то делает в админке.

MD5 – в данном случае применяется как однонаправленный алгоритм шифрования строк произвольной длины и получения 128-битного хеша. Другими словами, если зашифровать любое слово этим алгоритмом, то обратно расшифровать его уже нельзя. Понятно, что для проверки нужно зашифровать введенный пользователем логин/пароль и сравнить его с уже имеющимся хешем. Если они совпадают, то пользователь ввел правильный логин/пароль.

Храниться имя и пароль будут прямо в скрипте в виде переменных (файл /vrotmnenogi-admin/index.php, самый верх). Для еще большей путаницы мы будем добавлять в эту связку секретный ключ (произвольный набор символов), чтобы хакер совсем сломал голову, расшифровывая данный хеш.

Итак, как мы будем проверять вход? Для этого создан файл logintest.php, лежащий прямо в корне админки. Первой строкой в этом файле мы смотрим, не пытается ли пользователь залогиниться? Логин передается в переменной $_POST['login'] и если она не пуста, значит – пытается. Соответственно первым ветвлением IF мы проверяем, что он нам такого прислал и сравниваем с хешем строк пароля, логина и секретного ключа:

if ($_POST['login']){
	if ($_POST['login'] == $admin_login &&
		$_POST['password'] == $admin_password){
		setcookie ("admin_login", $protection_combo,
                                 time() + 60*60*24*7);
		header ("location: /vrotmnenogi-admin/");
	}
}

Если проверка пройдена, то мы устанавливаем куки, в которую и записан этот хеш. Куки ставится на неделю и работает только для каталога /vrotmnenogi-admin/ нашего движка. И потом отправляем заголовок, который переадресовывает нас на главную страницу. То есть – для пользователя не видно, что выполняется какой-то скрипт, все происходит «мгновенно».

Следующий блок в этом файле – это как раз вывод формы ввода логина и пароля. То есть, если не передано поле $_POST['login'] и данные в куки не совпадают с хешем (попытка взлома или просто нет куки – не залогинен), то выводится форма входа:

// Проверка, введен ли пароль админа
if ($_COOKIE['admin_login'] != $protection_combo){
	?>
	<form action="./index.php" method="post">
		Логин: <input name="login"><br>
		Пароль: <input name="password" type="password"><br>
		<input type="submit" value="Зайти на огонек">
	</form>
	<?php
	exit;
}

Кстати, обратите, пожалуйста внимание на то, что после вывода формы обязательно должна быть команда exit. Иначе после формы выведется сама админка. После нажатия кнопки «Войти» все данные как раз и проверяются блоком кода, описанным чуть выше.

Теперь выход. Тут все очень просто. В файле index.php я создал кнопку, при нажатии на которую выполняется скрипт logout.php. Кнопку назвал незатейливо – «Выйти» :)

<form action="./logout.php" method="post">
	<input type="submit" value="Выйти">
</form>

Никакого криминала :) Ну и сам скрипт выхода. Он просто убивает куки с хешем логина, пароля и секретного ключа, из-за чего пользователь не пройдет проверку в файле logintest.php:

<?php
setcookie ("admin_login", "");
header ("location: /vrotmnenogi-admin/");
?>

Убиваем куки (передав ей пустое значение) и отправляем пользователя на главную страницу. Вот так.

С админкой на этом все. Следующая статья в этой серии будет, как я и сказал, о постах и о категориях. Удачи!

Скачать архив с движком dblog. Используйте как угодно, только название dblog остается за мной ;) В архиве, кстати, функционала больше, чем я здесь описал.

__________________________

Если никто не против, чуть-чуть личного. Заметил, что писать в блог для меня стало чем-то нужным. То есть меня мучает ощущение «надо бы написать в блог». Приятное ощущение, что-то вроде тяги к наркотикам для наркоманов :lol: При этом, когда пишешь в блог, это ощущение на день-два отпускает. Мне страшно :shock:

Кстати, я вроде бы пошел на поправку (болел тут несколько дней). Моя девушка подарила мне забавную картинку :)

Спасибо ей большое, очень классно получилось : )))

А еще по поводу болезней. Трехчасовой рабочий день пишет в своем блоге другой взгляд на лень (медицинский, так сказать). После чего (по совету ТРД?) Кишиневский бомж проверяется у врача и у него находят опухоль щитовидной железы.

Дорогой Кишиневский бомж, во-первых: мы все с тобой, держись! А во-вторых, я спросил у знающих людей, говорят, что эти опухоли доброкачественные и с ними живет чуть ли не половина жителей Санкт-Петербурга и даже не знает об этом. Все будет хорошо ;)

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

Официальный сайт движка BigStreet (Большая Улица). Вот что пишет на сайте его создатель: «Большая Улица это сайт разработки движка для организации социальных сетей и тематических сообществ.
Здесь мы обсуждаем каким должен быть движок социальной сети и пишем его.»

Почему я решил упомянуть этот движок у себя? На это есть ряд причин.

1) BigStreet – движок новый и пока что не известный, а значит – скоро наберет популярность (т.к. сам по себе вполне неплох). Чем быстрее Вы узнаете о нем, тем лучше (во всех смыслах).

2) Движок OpenSource, то есть – пользователи сайта самостоятельно дорабатывают его, разбираются. В нем сейчас есть и ошибки и недоработки – просто рай для девелоперов-энтузиастов :)

3) Движок отлично показывает модель MVC (model-view-controller, модель-представление-контроллер). То есть – в нем очень сильно разделены такие части, как внешний вид, работа с базой, модули и прочее. ИМХО, реализация «модульности» очень неплохая. Подобного я не видел ни в DLE, ни в WordPress, ни в Joomla. Вроде бы – нигде не видел.

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

Кстати, есть еще забавная вещь. Как работает движок знает только автор и никому не рассказывает. То есть у него нет времени написать документацию. :) У Вас есть реальный шанс приблизиться к статусу бога в плане понимания работы движка, без шуток.

Вступление.

Собственный движок блога обладает многими преимуществами. В нем можно поменять вообще все, до мелочей и уйдет на это в 10 раз меньше времени, чем ковыряться в чужих движках, таких как WordPress или DLE (DLE особенно страшен в этом плане на мой взгляд). Для него легко поставить собственный дизайн. К нему легко прикрутить собственные другие наработки, например, портал, каталог статей и прочее.

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

Да, это палка о двух концах – если плохо написать движок с точки зрения безопасности, ломаться он будет довольно легко. Но я лично не собираюсь писать его плохо ;) А Вы?

Еще плюсы? Например, скорость работы. Тот же огромный и «тяжелый» WordPress будет работать в разы медленнее, чем заточенный под конкретные задачи собственный движок.

Я расскажу, как написать свой движок за пару часов. А если копировать код у меня из статьи – за 15 минут. А если сразу скачать исходник – за 30 секунд :)

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

Недостатки есть?

Есть, не без этого. Главным недостатком своего движка и огромным плюсом для стандартных движков я считаю плагины. То есть для собственного движка их просто нет и быть не может, пока автор движка сам их не напишет. Например, в WordPress можно за 1 минуту установить плагин для вывода последних комментариев, вывода смайликов, голосования (и вообще чего угодно), а в своем блоге придется писать это все самому. И если вывод последних комментариев и смайликов – задача не сложная, то, например, с голосованием уже посложнее.

Зачем Вам все это?

В любом случае, даже если Вы выбираете стандартный движок, я все равно рекомендую прочитать статью – особенно начинающим программистам. Эта статья фактически описание создания несложной CMS, которую можно превратить из блога во что угодно ;)

И еще момент. После этого небольшого цикла статей я напишу, как сделать генератор сателлитов! И по плану – там как раз пригодится этот собственный движок ;) Запахло деньгами?

Составляем ТЗ.

(ТЗ – Техническое Задание, документ, по которому программист пишет программу, скрипт, сайт и т.п.)

Даже в таком несложном деле лучше составить небольшое ТЗ и не отходить от него в процессе разработки. Мы просто опишем, что хотим видеть в движке, а потом сделаем ровно так, как написали. Я считаю, что это полезная практика – иначе можно «расплыться» (захотеть сделать и то и се и пятое и десятое, в итоге не сделать ничего или сделать частично и плохо).

«Нужны возможности: 2* добавлять категории, редактировать их названия, вывод категорий по алфавиту, вложенность не нужна. Добавлять, редактировать или удалять посты. В посте есть заголовок и основной текст. Визуальный редактор не нужен, разрешить HTML-теги. 3* Возможность комментировать пост, вводя имя, почту, сайт и комментарий. Регистрация пользователей не нужна. Все адреса в виде ЧПУ (человеку понятный URL, а-ля dimoning.ru/hello.html). Категории открываются по адресам /category/catname/, где catname – имя категории. Посты открываются по адресам /postname.html, где postname – адес поста. Эти адреса тоже можно редактировать. *4 Прикрутить RSS последней версии протокола. Весь блог в кодировке UTF-8. Все изменения администратор вводит через админку по адресу /vrotmnenogi-admin/. Добавить постраничный вывод постов.»

Вот такое тех-задание. Сделаем четко по нему ;)

Я решил разделить создание собственного движка блога на четыре части – первая – это проектирование и еще три отмечены звездочками в ТЗ [сначала хотел 3 части, но эта статья уже вышла довольно большой, а для понимания читать большую статью, я думаю, тяжеловато]. У меня еще нет готового движка (на момент написания этих строк), поэтому исходник каждый раз будет все более дополняться.

Начнем с начала.

В начале работы я обычно прикидываю, какие мне нужны таблицы в базе данных и как их будет использовать движок. Например, здесь. Я перечислю поля и тип данных в них записываемый, а также объясню – для чего то или иное поле. Для простоты мы будем использовать только int и text.

Категории:
id (int auto increment) | url (text) | title (text)

id – уникальный, автоматически увеличивающийся при добавлении записи, идентификатор категории
url – адрес категории, который будет подставляться /category/сюда/
title – название категории, которое будет выводиться в браузер

Посты:
id (int auto increment) | url (text) | title (text) | post (text) | dt (datetime)

id – уникальный, автоматически увеличивающийся при добавлении записи, идентификатор поста
url – адрес поста, который будет подставляться /сюда.html
title – заголовок поста, выводится в браузер
post – содержимое поста, выводится туда же
dt – дата и время написания поста, проставляется автоматически и изменению не подлежит

Комментарии к постам:
id (int auto increment) | post_id (int) | nick (text) | email (text) | site (text) | comment (text) | ip (text) | dt (datetime)

В ТЗ ничего не сказано про запись IP комментатора, но я считаю, что это необходимо. Может помочь отловить злого спамера или забанить по IP. В общем, если «враг» появится, лучше знать про него как можно больше.

id – уникальный, автоматически увеличивающийся при добавлении записи, идентификатор комментария
post_id – идентификатор поста, к которому написан комментарий
nick – имя комментатора (никнейм)
email – почта комментатора
site – сайт комментатора
comment – сам комментарий
ip – IP-адрес комментатора
dt – дата и время написания комментария. Так. Для протокола. :)

Знатоки из Что-Где-Когда, конечно, заметили бы, что IP адрес можно хранить в виде long-числа, а я храню его в виде текста. Я считаю, что так нагляднее и вообще редко храню его в виде числа. Говорят, что по использованию памяти это лучше, не знаю, я не замерял. Но знаю, что это хуже по производительности – нужно преобразовывать число в IP и обратно. Я так не делаю, в общем.

С базой данных все. Теперь пара слов о ЧПУ.

Из ТЗ видно, что должны быть ЧПУ (человеку понятный Url). Для этого нам нужно создать .htaccess, который мог бы разбирать адреса вида /category/name/ и /post.html и передавать в скрипт значения этих полей в виде переменных. Например, пусть имя категории передается в переменной category, а имя поста в переменной post из массива $_GET.

Заметьте, нужно предусмотреть и постраничный вывод! Лучше подумать об этом сразу. Я предлагаю сделать примерно так же, как сделано в WordPress. А именно, для категорий страницы показываются по адресу /category/name/page/1/, где 1 – номер страницы. А если категория не выбрана (главная страница), то адреса для вывода страниц будут иметь вид /page/1/ – прямо от корня.

И еще нужно предусмотреть зарезервированное имя для RSS. Я предлагаю сделать простой адрес: /rss.html, почему бы и нет?

Какой же .htaccess файл нам понадобится? Я бы сделал такой:

RewriteEngine On
1 RewriteRule ^(rss).html$ rss.php [L]
2 RewriteRule ^([A-Za-z0-9_]+).html$ index.php?post=$1 [L]
3 RewriteRule ^(category)/([A-Za-z0-9_]+)/$ index.php?category=$2 [L]
4 RewriteRule ^(category)/([A-Za-z0-9_]+)/(page)/([0-9+])/$ index.php?category=$2&page=$4 [L]
5 RewriteRule ^/(page)/([0-9+])/$ index.php?page=$2 [L]

Я пронумеровал строки. В рабочей версии нумерации, конечно, нет.

Строка 1. Перекидывает с rss.html на rss.php прозрачно для пользователя. В rss.php будет генерироваться сама RSS.

Строка 2. При открытии адреса вида /some.html передает все между слешем и .html в скрипт index.php в переменной $_GET['post'];

Строка 3. При открытии категорий (адрес вида /category/имя/) передает в скрипт index.php имя категории в перменной $_GET['category'];

Строка 4 и строка 5 – аналогичное действие, только для других видов URL.

Ключ L не позволяет серверу идти дальше по списку, если нужное нам совпадение с адресом найдено.

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

На этом с «проектированием» покончено, ровно как и с первой частью. В следующей статье мы сделаем добавление категорий, их редактирование, вывод. Добавление постов, их редактирование и отображение.

Пока что все. Всем удачи и до связи :) Подписывайтесь на RSS, а то что за дела ))) Я еще не набрал даже сотни подписчиков, жуть! ))

__________________________
Посмеялся ))