Апгрейд: Статический сайты -> Полу-CMS

Сегодня была небольшая дискуссия на серче по поводу cms от автора cm2. Основно достоинство этой cms в быстроте и легковесности. И я вот подумал: в Зеброиде статический экспорт - быстрее и легче некуда, почему бы его не проабгрейдить до востребованных от CMS функций (кроме админки) и получить мега легкие, быстрые и функциональные сайты?

Что требуется обычно от CMS (с точки зрения оптимизаторов):

• Контроль мета тегов (есть)



• Возможность перелинковки (есть)



• Структурирование (есть)



• ЧПУ (есть)



• Карты сайта (есть)



• Поддержка комментариев (реализовывается с помощью разных сервисов вставкой кода в шаблон)



• Отложенная публикация



• Отсутствие битых ссылок



• Форма обратной связи
<\ul>

Реально последние 3 можно реализовать с помощью вставки в файл небольших скриптов и всё, имеем Полу-CMS (почему "полу-"? да потому что CMS без админки это не полноценно). К тому же, можно сделать так, чтобы даже ссылки на статьи из будущего показывались только тогда, когда это действительно можно. Таким образом можно получить легкие и быстрые сайты не требовательны к хостингу, автообновляемые, качественно перелинкованные, без битых ссылок.

Что еще нужно?

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

P.S. С того, что я слышал - гуглу тоже по барабану на мета теги (кроме тайтла)

к черту метки, архивы и т.п. дубли.

ну или сделать как модули, вкл/выкл.

Всё что мне не хватает в статике - это "Отложеная публикация постов", гуглу например очень нравятся часто обновляемые сайты.

Я считаю, что эту CMS-ку надо делать таким образом, чтобы она не имела признаков по которым можно было определить ее.

Как можно этого добиться?

1. Никаких стандартных(для этого движка) тегов, идентификаторов и классов css

2. Никаких стандартных путей

структура файлов: /data-secretkey/... (ссылка на эту папку не должна встречаться в HTML-коде)

/themename/index-secretkey.php

index.php

robots.txt

.htaccess

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

Если в движке будут модули типа комментариев, то задача, конечно, усложняется.

Мне кажется, что там где невозможно спрятать признаки таких модулей, надо делать их похожими на признаки популярных CMS (например WP)

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

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

Если в движке будут модули типа комментариев, то задача, конечно, усложняется.

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

Мне кажется, что там где невозможно спрятать признаки таких модулей, надо делать их похожими на признаки популярных CMS (например WP)

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

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

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

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

Предлагаю посмотреть лучшие движки такого плана и взять от них самое лучшее. Возьмем к примеру Румба XML и Зебрум лайт

CMS Румба XML, неплохая CMS, но дает нагрузку уже при 500 статей, потому что хранит все в одном файле, поэтому я предлагаю каждую статью хранить в отдельном файле XML.

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

Зеброидом можно генерировать XML файлы со статьями, а в CMS включить такой скрипт-парсер который будет парсить каталог с этими файлы и на основе их генерировать файл списка(БД) (лучше всего подойдет csv формат) примерно такого содержания:



Дата ;; file-name.xml ;; Заголовок ;; Категория::подкатегория

и сортировать его по дате.

Что это даст?

1. Всегда можно будет подлить еще файлов (или удалить ненужные) и переформировать список скриптом из CMS

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

3. Файл списка отсортирован по дате. Это также облегчит нагрузку при обработке функций вывода списков.

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

Еще раз: не планируется делать CMS. Это значит не будет никаких импортов, XML файлов и т.д. Всё будет так же как сейчас, только с php вставками в файлы.

Я не вижу смысла делать еще одну Зебрум лайт или румбу. Хотите CMS - выберите одну из списка поддерживаемых.

Еще раз: не планируется делать CMS. Это значит не будет никаких импортов, XML файлов и т.д. Всё будет так же как сейчас, только с php вставками в файлы.

Я не вижу смысла делать еще одну Зебрум лайт или румбу. Хотите CMS - выберите одну из списка поддерживаемых.

Совершенно правильно.

Еще раз: не планируется делать CMS. Это значит не будет никаких импортов, XML файлов и т.д. Всё будет так же как сейчас, только с php вставками в файлы.

Я не вижу смысла делать еще одну Зебрум лайт или румбу. Хотите CMS - выберите одну из списка поддерживаемых.

Полностью поддерживаю. Зебрум хороший инструмент, не стоит его этим портить.