А ведь так хочется уделять больше времени творчеству, а не убивать время на рутину. Вот эту нужную, но рутинную работу берет на себя контент-менеджер (Content Management System, CMS). Итак, если вы понимаете плюсы и минусы CMS, и своевременность его установки*, осталось ответить на вопрос "как". Как переходить на CMS? Есть три варианта.
а) поручить это дело профессионалам - людям, которые съели табун собак на ниве создания контент сайтов (включая дизайн и программную начинку). Но это достаточно дорогое удовольствие. Не каждый готов выложить 1000 или больше зеленых денег**.
б) найти уже готовый бесплатный или некоммерческий вариант***. Главный минус такого варианта состоит в том, что такой CMS написан на некий "стандартный сайт", каких нет в природе. Поэтому вам придется не только покопаться во внутренностях CMS (чтобы понять, как этот "агрегат" фурычит), не только внимательно изучить документацию (без документации CMS берут только мазохисты), но и настроить CMS под свои нужды и дизайн. Именно поэтому PhpNuke считается "ламерской штучкой" - поставить его легко, настроится он сам, но вот хорошо подогнать его под свои нужды... И вы остаетесь с "предустановленным" дизайном и неудобной системой обновлений контента.
в) написать CMS самому. Самый хороший вариант. Вы знаете, что вам нужно, как CMS должен работать, и какими ресурсами ему дозволяется пользоваться.
Вот о последнем варианте и пойдет речь дальше. Напоминаю, что практических и умных советов (на тему "Как правильно написать CMS") давать не планирую, зато попробую показать, на какие вопросы и аспекты нужно обратить внимание. Построение CMS начинается с простого вопроса - "Какие у вас есть ресурсы?" Это не банальный вопрос. Надо знать заранее, какие мощности доступны. Все CMS можно условно разделить на три группы:
а) динамические. Страница формируется динамически, как только приходит запрос. Кеширование не используется. Самый ресурсоемкий вариант, поскольку движок работает постоянно. Если посетителей много, то слабый сервер может быстро протянуть ласты. Основное преимущество подобной схемы - каждый посетитель получает самый свежий вариант контента. Кроме того, возможна индивидуальная настройка страницы под каждого пользователя.
б) с динамической сборкой. Динамически собранная (после запроса) страница кешируется до тех пор, пока не приходит для нее обновление. В этот момент кеш сбрасывается, и цикл повторяется. Другой вариант учитывает пользовательские предпочтения. Страница каждый раз собирается динамически, но из статических (закешированных) фрагментов. Если какой-либо фрагмент обновляется, то при следующем запросе он будет перегенерирован и занесен в кеш. Средняя нагрузка на сервер.
в) со статической сборкой. При обновлении CMS перегенерирует все связанные страницы. Поэтому при запросе выдается уже сформированная статическая (возможно, собранная SSI) страница. Понятно, что группа "а" рассчитана на постоянно изменяющийся контент (новостные сайты) или на небольшое количество посетителей, зато группа "в" выдержит большой наплыв (но используется, как правило, при нечастых обновлениях). Группа "б" - где-то между, но требует грамотного управления кешированием. Итак, какие у вас есть ресурсы? На какую нагрузку вы рассчитываете? Нужны ли вам дополнительные мощности, и готов ли хостер вам их дать? ---- * - некоторые умудряются сделать хоумпейдж из двадцати страничек на мощном движке с поддержком MySQL. ** - специалисты запытают вас кучей вопросов, чтобы понять, чего и как вы хотите. Но если их выводы (как и что делать) совпадут с вашими, первой мыслью будет "Я напрасно потратил деньги на то, о чем знал/догадывался". *** - к примеру, Communiware. Или выбрать что-то на Hotscript.
а) поручить это дело профессионалам - людям, которые съели табун собак на ниве создания контент сайтов (включая дизайн и программную начинку). Но это достаточно дорогое удовольствие. Не каждый готов выложить 1000 или больше зеленых денег**.
б) найти уже готовый бесплатный или некоммерческий вариант***. Главный минус такого варианта состоит в том, что такой CMS написан на некий "стандартный сайт", каких нет в природе. Поэтому вам придется не только покопаться во внутренностях CMS (чтобы понять, как этот "агрегат" фурычит), не только внимательно изучить документацию (без документации CMS берут только мазохисты), но и настроить CMS под свои нужды и дизайн. Именно поэтому PhpNuke считается "ламерской штучкой" - поставить его легко, настроится он сам, но вот хорошо подогнать его под свои нужды... И вы остаетесь с "предустановленным" дизайном и неудобной системой обновлений контента.
в) написать CMS самому. Самый хороший вариант. Вы знаете, что вам нужно, как CMS должен работать, и какими ресурсами ему дозволяется пользоваться.
Вот о последнем варианте и пойдет речь дальше. Напоминаю, что практических и умных советов (на тему "Как правильно написать CMS") давать не планирую, зато попробую показать, на какие вопросы и аспекты нужно обратить внимание. Построение CMS начинается с простого вопроса - "Какие у вас есть ресурсы?" Это не банальный вопрос. Надо знать заранее, какие мощности доступны. Все CMS можно условно разделить на три группы:
а) динамические. Страница формируется динамически, как только приходит запрос. Кеширование не используется. Самый ресурсоемкий вариант, поскольку движок работает постоянно. Если посетителей много, то слабый сервер может быстро протянуть ласты. Основное преимущество подобной схемы - каждый посетитель получает самый свежий вариант контента. Кроме того, возможна индивидуальная настройка страницы под каждого пользователя.
б) с динамической сборкой. Динамически собранная (после запроса) страница кешируется до тех пор, пока не приходит для нее обновление. В этот момент кеш сбрасывается, и цикл повторяется. Другой вариант учитывает пользовательские предпочтения. Страница каждый раз собирается динамически, но из статических (закешированных) фрагментов. Если какой-либо фрагмент обновляется, то при следующем запросе он будет перегенерирован и занесен в кеш. Средняя нагрузка на сервер.
в) со статической сборкой. При обновлении CMS перегенерирует все связанные страницы. Поэтому при запросе выдается уже сформированная статическая (возможно, собранная SSI) страница. Понятно, что группа "а" рассчитана на постоянно изменяющийся контент (новостные сайты) или на небольшое количество посетителей, зато группа "в" выдержит большой наплыв (но используется, как правило, при нечастых обновлениях). Группа "б" - где-то между, но требует грамотного управления кешированием. Итак, какие у вас есть ресурсы? На какую нагрузку вы рассчитываете? Нужны ли вам дополнительные мощности, и готов ли хостер вам их дать? ---- * - некоторые умудряются сделать хоумпейдж из двадцати страничек на мощном движке с поддержком MySQL. ** - специалисты запытают вас кучей вопросов, чтобы понять, чего и как вы хотите. Но если их выводы (как и что делать) совпадут с вашими, первой мыслью будет "Я напрасно потратил деньги на то, о чем знал/догадывался". *** - к примеру, Communiware. Или выбрать что-то на Hotscript.
Разделы:
Дополнительные разделы: