You are here: Home > CMS на файлах и плагины для Direct Admin

CMS на файлах и плагины для Direct Admin

By on 15 Август 2009 in В интернете, Мысли

В последнее время, стал обращать внимание, что заказчикам нужно как можно более простое и дешевое решение. Например, зачем ставить для сателлитов WP? Он ведь громоздкий, требует базу данных, настройки. В том числе, в WP при создании сателлитов убирают из шаблонов даты, авторов и прочую не нужную информацию. Конечно, можно найти ПО для установки блогов на разные сервера в один клик (мы написали свой вариант такого установщика. Примерно за 1 минуту ставится 5 блогов, с темами, переводами  и вырезанием не нужных частей шаблона. Если кому-то интересен такой софт, можете обращаться, цена в районе 100$).

Так вот, возвращаясь к сателлитам. WP — громоздкое решение. Средний движок (не PowerPack) весит около 3мб. Если сателлитов нужно установить 10, то трафика будет 3*10мб. Можно конечно поступить по хитрому и скопировать движок в папки доменов через панель хостинга. Но затем, их нужно будет ещё и проинсталлировать и настроить, что, согласитесь, тоже время. И здесь многие веб-мастера, сошлись во мнении, что CMS на файлах — это лучший вариант. Шакин предложил свой список CMS на файлах, за что ему отдельное спасибо. Однако недостатки есть в каждой из них: одна уже устарела, другая не развивается, третья совсем громоздкая, четвёртая без ЧПУ, пятая вообще с непонятным интерфейсом.

Посмотрев на это дело, решили написать свою CMS на файлах. Она будет содержать следующий функционал: интерфейс добавления страниц (адаптированный для SEO нужд), обратную связь, неограниченную вложенность меню, карту сайта, удобный и простой графический редактор, ЧПУ. Поскольку система будет модульной, то расширить функционал можно будет запросто. Так же феноменальный вес самой системы: в архиве система будет занимать около 300кб, а в распакованном порядка 500-700кб. Так же, отмечу простоту работы с шаблонами. Чтобы установить новый шаблон, достаточно найти «free css templates», в нём расставить спец-маркеры и можно уже использовать. А цена этой системы в базовой комплектации модулей 10$. Правда, по поводу Open Source пока ничего не скажу :)

А ещё, на днях клиент обратился, с просьбой написать плагин для Direct Admin. Забыл как приятно это делать (писать плагины для DA). Удобный API позволяет гибко переделывать и писать свои модули. К примеру, в своём портфолио сейчас есть плагин, который делает копии сайтов по заданному списку, а сейчас ещё добавится плагин специфического добавления пользователей. В общем, август обещает быть насыщенным на работу :)

Рекомендую прочитать:

About arti

Php-программист со стажем в 5 лет. Люблю путешествовать и знакомиться с новыми людьми. Женат на самой красивой и лучшей девушке в мире: Дашеньке.
View all posts by arti →

Subscribe

Subscribe to our e-mail newsletter to receive updates.

Related Posts:

, , ,

  • Vic

    хе-хех, теперь я понимаю к чему ты интересовался моей cms. :)

    я тебе на днях отпишусь — покажу что получилось в первом приближении, надо тока выложить в сеть...

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

  • Артур

    @Vic , согласен, что SQL — удобнее. Даже если взять поиск, к примеру. На файлах это будет очень ресурсо-затратно. Но с другой стороны, перед такими сайтами не ставится задача поиска. Для них важнее быть SEO-дружелюбными. И вот к примеру переезд такого сайта займёт пару минут, если не считать время копирования файлов. И без головных болей по поводу кодировок.

    Наша система есть в 2-х вариантах heavy и light. Хеви ветка уже опробована и работает на ура (уже 3-е поколение), а вот лайт решили потестить поскольку она будет рассчитана на массовость. Исходная кодировка UTF-8 (может зря?) и храним всё в XML.

  • Vic

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

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

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

  • http://wwwlab.biz Артур

    @Vic , здесь не вопрос прибыли. Больше хочется протестировать рынок такого софта (дешёвого и не фукнционального).

    Забыл написать, что heavy версия естественно работает с SQL. Просто хотим заменить источник данных и посмотреть что получится.

    В версии на файлах присутствует 1 режим просмотра: статья целиком. Т.е. в таком варианте количество статей не сказывается на производительность системы. Вот сейчас думаем, что для наращивания страниц, хорошо было бы добавить теги к записям, но для этого нужно придумать как хранить весь этот индекс тегов наиболее оптимально. Интересен вопрос: стоит ли так сильно доверять XML файлам? Поскольку я просмотрел с пяток систем разных и ни одна из них не была реализована при помощи XML.

    И ещё, ты пишешь, что лучше написать небольшую php оболочку. Мы специально сделали модульность, чтобы позволить максимально «кастомизировать» сборку CMS. Т.е. на базе такой схемы, можно сделать что-то похожее на «кисточку», с автоматическим наполнением контентом и эта вся прелесть в исходных кода врядли будет превышать объём в 1мб кода. Простота расширяемости тоже важный факт. Зачем «хакать» ядро постоянно, чтобы получить непонятный и неудобочитаемый код?

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

    Важно понимать, что мы делаем её не для рядовых пользователей сети, которые хотят установить себе блог, варезник, новостной сайт или «портал». Мы делаем её для SEO-шников в первую очередь, затем для дорвейщиков (не бросайте камнями, просто деньги они всегда не лишние), а уже затем, для тех кому не позволительно тратится на хостинг с наворотами (хотя в наше время mysql — это уже жизненная необходимость).

  • Vic

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

    хотя нет — картинки к статьям кранятся как есть...

  • 4el

    разве бд работает быстрее файлов? ( :

    нет, я конечно это не оспариваю, но сомнения у меня вызывает тот факт, что сами базы данных хранятся где бы вы думали? ( :

    так что вот так (( :

  • http://wwwlab.biz Артур

    @4el , тут скорее имеется ввиду реализация алгоритмов: поиск, выборка.

    Если для поиска по 100.000 файлам тебе нужно «прошерстить» регуляркой каждый из этих файлов, то в MySQl (MsSql, PoStgreSQl) это делается через один файл базы данных и по до дыр заезжанному способу (методу), который работает эффективней чем простой перебор файлов.

    Думаю, что sql сервер победит даже по нагрузке, т.е. она будет меньше

  • Vic

    @4el , к тому что сказал Артур добавлю — да, базы хранятся в файлах (как правило в одном файле — уже первый плюс от многофайлового хранилища). также базы индексируются, т.е. для нужной тебе выборки не надо шерстить все файлы и все данные а достаточно пройтись по маленькому индексу.

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

    надеюсь я развеял твои сомнения.