Сайтостроительство

Подписаться на эту рубрику по RSS

MaxSite МногоСайт? Продолжение...

Четверг, 30 апреля 2009 г.
Рубрика: Сайтостроительство
Метки: | |

Приветствую!

Сегодня расскажу о некоторых подробностях превращения MaxSite CMS в многосайтовую систему. Собственно продолжу рассказ.

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

Итак, сегодня расскажу, как сделать скрипты для динамического вывода файлов sitemap.xml и robots.txt, первый - карта сайта, второй - инструкции индексации.

Начну, пожалуй с sitemap.xml: поначалу долго мучался как сделать, потом допёрло: создаём в корневой директории папку, в ней ещё одну с названием сайта. Будет что-то типа http://AskName.ru/folder/AskName.ru/ В неё засовываем наш sitemap.xml. Далее нам нужно подправить плагин Макса (путь на сайте /application/maxsite/plugins/xml_sitemap/index.php). В самом конце файла меняем строчку:

  • $fn = realpath(dirname(FCPATH)).'/sitemap.xml';
На такую:
  • $fn=realpath(dirname(FCPATH)).'/folder/'.$_SERVER['HTTP_HOST'].'/sitemap.xml';
После этого ваш sitemap.xml будет лежать по примерно такому адресу: http://AskName.ru/folder/AskName.ru/

Как вариант можно сделать с помощью Mod Rewrite перенаправления так, чтобы поисковик думал, что он лежит в корневой папке сервера, но я пошёл по другому пути и поэтому мы рассмотрим способ динамического создания файла robots.txt

В корневой директории нужно создать файл robots.php, так как нам нет смысла делать разные robots.txt для каждого сайта (движок то один), имеет смысл воспользоваться моим простеньким кодом, вот он:

  • <?php
  • echo 'User-agent: *
  • Disallow: /system$
  • Disallow: /users$
  • Disallow: /admin$
  • Disallow: /login$
  • Disallow: /tag$
  • Disallow: /feed$
  • Host: '.$_SERVER['HTTP_HOST'].'
  • Sitemap: http://'.$_SERVER['HTTP_HOST'].'/folder/'.$_SERVER['HTTP_HOST'].'/sitemap.xml';
  • ?>
Отличаться у разных сайтов будут только директивы Host и Sitemap. Так и должно быть. Данный пример проходит проверку на правильность в яндексе. Но для того, чтобы robots.php отдавался по запросу robots.txt, нужно сделать следующее - прописать в .htaccess перенаправление:
  • RewriteRule ^robots.txt$ http://%{HTTP_HOST}/robots.php
В принципе абсолютно простое решение, возможно не такое совершеннои и идеальное, но свою задачу оно выполняет: сделать многосайтовую MaxSite CMS с минимальными исправлениями кода, с целью упрощения обновления системы, и как мне кажется я справился с задачей блестяще. Надеюсь знающие люди дадут оценку такому решению.

Существует ещё одна идея - можно sitemap.xml запихать в файлы шаблона. Технически легко осуществимо... Как то не подумал сначала. Завтра попробую сделать. В любом случае это решается простой правкой пары-тройки строк. На сегодня всё.

MaxSite МногоСайт?

Вторник, 21 апреля 2009 г.
Рубрика: Сайтостроительство
Метки: | | |

Здравствуйте друзья!

Недавно у меня родилось множество идей по созданию качественных сайтов. Причём все как-то разом, не к месту и не ко времени...  Однако родились и теперь терзают неокрепший ум:) К делу - мы ж все люди ленивые, а я, наверное, самый ленивый из всех... Чтобы не следить за обновлениями системы управления сайтами, обновлять не несколько систем, а  один раз, решил написать расширение для моей любимой системы. Для MaxSite. Тут возникают закономерные вопросы: не проще ли взять многопользовательский вордпресс или тот же би2, альтернатив множество... Однако, мне кажется, что за системой Макса будущее, при всех её недоработках, да и патриотизм сыграл некоторую роль.

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

Для начала нам нужно добиться использования одной базы данных. Экономика должна быть экономной! Для этого мы внесём некоторые поправки в файл /application/config/database.php:

  • $pref=$_SERVER["HTTP_HOST"];
  • $pref=str_replace("www.","",$pref);
  • $pref=str_replace(".","",$pref);
  • $pref=str_replace("-","",$pref);
  • $db['default']['dbprefix']=$pref."_";
Здесь мы формируем префикс в базе данных и он будет отличаться для каждого домена. В принципе этого достаточно, однако стоит воспользоваться ещё одним кодом, а именно редиректом через .htaccess на адрес без www. В принципе не обязательно, но лучше создать в корневой папке файл .htaccess и внести в него такие строки:
  • RewriteRule ^(.*)$ - [E=PROTOCOL:http]
  • RewriteCond %{HTTPS} ^on$ [NC]
  • RewriteRule ^(.*)$ - [E=PROTOCOL:https]
  • RewriteCond %{SERVER_PORT} ^80$
  • RewriteCond %{HTTP_HOST} ^www\.(.*) [NC]
  • RewriteRule ^(.*)$ %{ENV:PROTOCOL}://%1%{REQUEST_URI} [R=301,L]
  • RewriteCond %{HTTP_HOST} ^www\.(.*) [NC]
  • RewriteRule ^(.*)$ %{ENV:PROTOCOL}://%1:%{SERVER_PORT}%{REQUEST_URI} [R=301,L]
Говорю честно: код упёрт с одного из форумов, причём достаточно давно. Его преимущество в отличие от обычного редиректа в том, что он универсален - смело кидайте в корень и для всех сайтов он будет работать.

В принципе эти два пункта у себя я реализовал, сейчас будет работа по созданию robots.txt, оригинального для каждого сайта, а также xml-sitemap, карты сайта. Без этих пунктов о многосайтовости и говорить не стоит:) А об этом я напишу только тогда, когда сделаю сам и оно корректно заработает, хотя наброски у меня уже есть;-)

Первый Постовой:

Стоит почитать блог Антона

Немного о Mod Rewrite

Воскресенье, 19 апреля 2009 г.
Рубрика: Сайтостроительство
Метки: |
Думать одно, а говорить другое - это типичный симптом

раздвоения личности (Неизвестный)

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

Каждый раз вы видите в интернете ссылки типа такой:  http://askname.ru/page/maxsite-cms-404-nevernye-zagolovki Интересный адрес, не правда ли?:) На первый взгляд кажется, что действительно существует на сервере папка page, подпапка maxsite-cms-404-nevernye-zagolovki, в ней файл index.html... Конечно не исключено, что так и есть, но чаще всего это не так! Здесь и вылезает загадочный модуль Mod Rewrite. Поставляется он в комплекте с программным обеспечением Apache, хотя есть аналоги под другие http-сервера. В принципе его цель одна - перенаправить запрос на какой-либо скрипт. То есть, к примеру, вы набираете в строке браузера вышеуказанный URL а Mod Rewrite переадресует запрос на файл index.php, который разбирает и обрабатывает его. Без него URL представлял бы собой нечто такое: http://askname.ru/index.php?dir=game/assault.url&scr=next&sess=1 Это, так называемый, динамический URL. Как видно, скрыты передаваемые параметры. Зачем? Разница вроде невелика... Для людей особой разницы нет. Хотя на самом деле здесь проскальзывает значимость первого варианта для поисковиков. Если гугл как-то научился справляться с URL с параметрами, то яндекс, мягко говоря, на этом глючит. Есть опыт.

Итак, я подхожу к тому, что Mod Rewrite важен для любого оптимизатора! Это действительно так, ведь с помощью него можно перенаправлять не только запросы пользователей, но и поисковых ботов;-) А уж обладая некоторыми навыками, можно очень многое наворотить. Неспроста все лучшие системы управления контентом используют данную возможность, кто-то в качестве одной из настроек, а MaxSite CMS вообще изначально построена под Mod Rewrite.

Собственно, я долго не писал ещё по причине изучения данного инструмента. Вскоре начну выкладывать свои наработки в этой области. Но уже сейчас скажу: изучайте! Незаменимый инструмент для веб-мастера!

Maxsite CMS 404 Неверные заголовки

Воскресенье, 12 апреля 2009 г.
Рубрика: Сайтостроительство
Метки: | |

Здравствуйте друзья!

Совершенно неожиданное развитие получила тема Maxsite CMS на моём сайте... Как я уже писал, сайт построен на ней и ни на что другое менять пока не собирался. В принципе и сейчас не собираюсь, однако хочу предупредить вас, если собираетесь её использовать, необходимо провести небольшую ревизию стандартного шаблона. Или того который будете использовать вы, ибо большая часть копируется из стандартного. Так вот - недавно обнаружил несоответствие заголовков, отдаваемых сервером - HTTP HEADER. На несуществующей странице, рубрике, теге, а может и других типах страниц отдаётся код 200 - страница существует, при этом на самом сайте исправно выводится сообщение "ничего не найдено". По этому поводу я писал Максу, и вот что наша переписка с Гугла, которая позже была удалена (точнее спрятана - ссылка у меня осталась и она рабочая):

UmFal Mar 10, 2009:

Какие действия приводят к появлению ошибки? 1. ввод несуществующей рубрики в строке браузера

Какой результат? Что отображается? на сайте 404 - правильно, но HTTP заголовок. там 200 - норма. думаю нужно проверить и другие типы. обнаружилось случайно. Яндекс проиндексировал мне тестовую рубрику. вот адресок для примера: http://askname.ru/category/456 версия системы - 0.29

Мах Mar 10, 2009:

Если нарушены ссылки, то выводится надпись «Извините, ничего не найдено». Для неё отдается тот же хидер, что и для нормальной страницы (200). Я не вижу здесь проблемы, потому что система не генерирует «пустых» ссылок, то есть никто не будет ссылаться на несуществующую страницу. В принципе если строго нужен header-404, то решается это сразу же после получения $pages.

...
$pages = askname_ru_get_pages(...);
if (!$pages) header('HTTP/1.0 404 Not Found');
...

то есть до любого вывода в браузер. Если же страница вообще не определена по типу данных, то выводится как положено 404-header. Он указывается прямо в шаблонном page_404.php.

UmFal Mar 10, 2009:

спасибо за быстрый ответ. просто столкнулся с ситуацией что яндекс проиндексировал страницу, которой сейчас не существует, но заголовок отдаётся 200. Мне казалось, что если страница не найдена она не должна индексироваться, и выдавать себя за существующую. К примеру конкуренты могут проиндексировать вручную ошибочные страницы, а Я забанит за дублированный контент. так что думаю стоит при обновлении внести

$pages = askname_ru_get_pages(...);
if (!$pages) header('HTTP/1.0 404 Not Found');

в дефалтные настройки. Может я чего то недопонимаю, но у себя сделаю так. Мусор в индексе яндекса плодить не будем ;-)

Больше ответов я не получал...

Итак, недавно у меня всё-же дошли руки всё проверить и исправить. Вышла версия 30, затем 31 Maxsite CMS. И как я увидел, ничего так и не было исправлено! Как я убедился, не только рубрики страдают этим, но и все остальные типы...

Вам, друзья, такой совет - если будете использовать систему, впишите в файлы типов в шаблоне (находятся в ваш_шаблон/type) перед выводом ошибки на страницу ещё и оператор:

header('HTTP/1.0 404 Not Found');

Зачем так надо сделать написано в переписке: Дабы избежать дублирования контента и пессимизации Яндексом. Однако хотелось бы услышать мнение людей более близких к сео, чем я. Думаю моя позиция правильнее, чем у Макса

Как говорится, доверяй да проверяй!

Спасибо! На этом всё.

Альтернатива Wordpress

Понедельник, 9 марта 2009 г.
Рубрика: Сайтостроительство
Метки: |
Всякое излишество портит

или нравы, или вкус

Приветствую вновь друзья!

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

Хочу повториться: вордпресс достаточно сильная и функциональная система, но её недостаток в чрезмерном ресурсопотреблении.

Очень долго юзеры и веб-мастера плевались, но использовали его, брали выделенный сервер под единственный блог!

Альтернативы в принципе не было очень долго и создатели тем и плагинов сосредоточились на Вордпрессе. При этом мало кого устраивала эта система.

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

Этого хорошего человека зовут Максим, а его творение Maxsite CMS. Об этой системе можно почитать подробно на его сайте: max-3000.com а я расскажу свои впечатления от увиденного.

Начну пожалуй с того, что этот сайт работает на Maxsite CMS и переходить на что-то другое я не собираюсь. В принципе система проста в установке и использовании, однако осваивается не по формуле: "вписал пароль в настройки и занимайся блоггингом", повозиться всё-таки придётся.  Опять же всё относительно и у меня на всё ушло минут 15 от силы. Я бы не сказал что система только для программистов, но порог знаний для использования её всё-же повыше чем у вордпресса. Вообще это правильно и лишняя заточка под пользователя с кривыми руками это лишнее. Моё мнение такое: если ставишь самостоятельный блог, то хотя бы должен понимать азы вёрстки и программирования, иначе используй блогосервисы, благо их развелось много.

В целом система получилась удачной (всё сделано логично и удобно), быстрой (в среднем 5 мегабайт, 10 запросов на страницу)и расширяемой (плагинами). Однако есть немало недостатков, я расскажу о некоторых. Думаю они все связаны с молодостью системы - ей около года и на момент написания существовала только версия 0.30

  • Одним из первых можно назвать отсутствие документации. Лекции на официальном сайте не в счёт. Их мало и они не охватывают всех аспектов работы системы.
  • Главным минусом можно назвать отсутствие нормальной регистрации. Но это я думаю можно исправить.
  • Некоторая сложность админки, может просто с непривычки, не знаю.
  • Отсутствие сторонних шаблонов и плагинов (они есть но мало) - это как результат малой распространённости Maxsite CMS - то есть если устанавливаете, готовьтесь к тому, что шаблон придётся либо верстать либо адаптировать к системе.
  • Сложное добавление картинок и файлов на сайт - нужно сначала загрузить файл, потом вставить в текст полученную ссылку...
  • Кстати достаточно спорный пункт. По мне так очень правильное решение, но вот ламерам оно конечно не по душе.

Итак, как можно видеть, Maxsite CMS это достаточно сложная система, требующая вдумчивого изучения, желательно с чтением сайта разработчика. Для обычного блоггера рекомендовать её пока я бы не стал. Но для продвинутого пользователя проблем с освоением этой перспективной системы не будет.

Чем плох Wordpress?

Четверг, 19 февраля 2009 г.
Рубрика: Сайтостроительство
Метки: |
Любая программа должна иметь ровно столько недоработок,

чтобы и сама работала, и позволяла неплохо зарабатывать программистам на её улучшениях.

А действительно, чем плох Wordpress?

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

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

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

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

Совсем забыл про напутствие читателю! Не ставьте Wordpress!

Рубрики

Поиск

Статистика

Rambler's Top100