Развитие CMS Textpattern и кому оно нужно

[edogs]

в этом и его сила, и его слабость. Код страниц сайта хранится не в отдельных файлах, как например в Wordpress, или Smarty, а правится в админке

На заметку. То что в Wordpress код хранится в файлах — нисколько не мешает править его в админке.

[pewpew]

Код страниц сайта хранится не в отдельных файлах, как например в Wordpress, или Smarty, а правится в админке и хранится в базе. Это с первого взгляда усложняет подъём готового шаблона (в том же Wordpress можно просто скопировать шаблон на хостинг), но в практике сильно упрощает правку и отладку. Что экономит уйму сил и времени в итоге.

Как это может хоть что-нибудь упростить? Textarea в админке удобнее моего любимого IDE?

[kupidonkhv]

В Textpattern нет в классическом понимании шаблонов. Есть интересная мысль: любое преимущество рождает равный по силе недостаток.
Это я к чему. В идею Textpattern заложена простота. Везде. Иногда доходящая до аскетизма. Что позволяет любому человеку, знающему html разобраться практически с ходу и включиться в работу. Даже если ты в глаза не видел проект. Даже если ты не видел сам движок.
Старт с IDE или фреймворком требует значительного времени в освоении инструмента.

[CodeByZen]

Это с первого взгляда усложняет подъём готового шаблона

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

[ankane]

[kupidonkhv]

Уж сколько мне пришлось в своё время допиливать WordPress — это жуть! Каждый движок не идеален и хорош в своей области. Я же хочу привлечь внимание к CMS Textpattern, как надёжному и простому в старте, освоении и поддержке.
А свои усилия я прилагаю к развитию этой системы.

[kupidonkhv]

За что минус?

[valemak]

Надо посмотреть… Ищё шустрый лёгкий движок для блога.

По поводу функционального подхода, из Вики:

>>> Ведётся работа над Textpattern 5, в котором будет изменена внутренняя архитектура CMS: вместо используемого сейчас подхода основанного на отдельных функциях будет использована объектно-ориентированная MVC-архитектура.

[kupidonkhv]

Пока эта работа ведётся в виде диалога с пользователями. Переложить Textpattern в MVC и оставить все его преимущества не простая задача.

[valemak]

Меня интересует есть хорошая бесплатнsq плагин для подключения систем внешнего комментирования (наподобие Loginza для WP)? Чтобы просто имея аккаунты в соцсетях (FB, VK, ОД, LJ, TW), не регистрируясь на сайте можно было комментировать?

[kupidonkhv]

В Textpattern встроена своя готовая система комментирования. Там нет необходимости регистрироваться для публикации коммента.
В одном из своих проектов я использую disqus, как дополнительную систему комментирования. Её встроить на сайт просто.
Возможно, вам подойдёт она.

[valemak]

В целом, заинтриговали. Простота, скорость, аскетизм и комментирование через социальные сети. Это всё что мне нужно для проекта.

[jigpuzzled]

Попробуй тогда Jekyll. Статически генерит весь сайт, нагрузка на сервер 0

[jigpuzzled]

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

Друпал 6 тоже фактически на функциях написан и от того ничем легче не стал. А чем функции настолько быстрее ООП на ПХП? Ставишь кеш опкода и никакой разницы точно не будет.

будет использована объектно-ориентированная MVC-архитектура

Стоит ли теперь считать что легким он уже не будет?

Код ужасно перемешан с версткой ( смотри txp_auth.php 95 строку)

Безопасности никакой нет, открыты двери иньекциям! Почему?

1) safe_update(«txp_users», «pass = '».doSlash($phpass->HashPassword($password))."'", «name = '$safe_user'»);
Вместо doSlash пора уже использовать prepared statement

2) Все функции работы с базой данных не используют параметры в кверях. Все делается как в прошлом веке и експлойты давно всем известны

[kupidonkhv]

Спасибо за интерес и вашу критику!

Стоит ли теперь считать что легким он уже не будет?

Спору нет. Но поживём — увидим. На текущий момент идёт только формирование идей, как TXP 5 должен работать. До реализации ещё очень далеко. Думаю, мы увидим ещё несколько версий на текущем ядре.

Код ужасно перемешан с версткой ( смотри txp_auth.php 95 строку)

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

Второй пункт мне непонятен в принципе.
Да и левые вставки банально не доходят до SQL запросов. Можно теоретически нашкодить, выполняя код из плагинов. А для этого нужно УЖЕ иметь доступ к админке. Да и это решается распределением ролей и разрешений пользователям.

[kupidonkhv]

ООП неэффективен в смысле распределения памяти. Каждый объект имеет невидимый указатель на дескриптор типа для своего класса. Значит, в ООП требуемая дополнительная память выражается в одном указателе для объекта и в одном дескрипторе типа для класса.
С кешированием согласен, но и это не панацея.
Не буду развивать холивар на тему «Почему объектно-ориентированное программирование — это отстой!» или «Функции рулят!»…
У каждого метода программирования есть как плюсы, так и свои минусы.

[jigpuzzled]

Я конечно не спорю что ООП сожрет чуть больше памяти, но у меня контрвопрос: сколько классов там бы было? Скажем с запасом 100. Дескрипторы в памяти займут от силы несколько килобайт.

Посмотрим на банальные вставки:
1) txp_validate() использует doSlash на юзернейме
2) txp_validate передается $p_userid в doTxpValidate
3) $p_userid создается посредством функции ps() которая читает из POST

то есть я вполне могу вставит иньекцию в это поле

[butschster]

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

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

Очень хочу поскорее написать статью про свою CMS, которая думаю на голову выше textpattern, но ей всего год с небольшим и разработкой занимаюсь я один. www.kodicms.ru

[kupidonkhv]

— нет нормального файлового менеджера

Для Textpattern он и не нужен — и плагины, и CSS и Html страниц редактируем в админке

— нет подсветки синтаксиса

Уже есть — есть замечательный плагин spf_codemirror

— навигация и дизайн в админке тоже оставляют желать лучшего

Решается отличными темами для админки. Моя любимая — Hive

— при установке создавать конфиг вручную?!

Решил в своей сборке Textpattern. К сожалению она пока не публична.

— написан функциями? Думаю для серьезных проектов это минус.

И ФП, и ООП — это инструменты, методика, если хотите. Тут вопрос в правильном использовании и понимании преимуществ и недостатков каждого из них.

Искренне желаю вам сделать конфетку из своей CMS. На базе Kohana может получиться действительно очень стоящая вещь.

[v_eroshenko]

Когда мне нужна была cms на Кохане нашёл в т.ч. и Вашу. Но не осилил «по быстрому». Что-то где-то не работало, где-то мануалов не хватило, где-то обратной связи не получил. Так и забил. А думал за день разобраться. Сайт горел. Так и пришлось просто на Кохане пилить)