» mojito cms

Church
В DL независимое дерево! ЧПУ - это именно логические урлы, отображающие путь по сайту, а не модуль. Современная CMS как раз и отличается тем, что юзера не грузят наличием каких-то там модулей, что он находится в модуле статей и т.п. Это должно быть smooth с возможностью размещения на одной странице нескольких модулей, как в DL.

Добавлено
Кстати, Вы уверены, что КЯП можно назвать деревом сайта? Это скорее совокупность иерархий нескольких модулей. То есть у Вас по логике несколько точек входа, зависящих от установленных модулей. В DL и других современных системах эта грань стирается. "Красивые" урлы без отражения пути к странице - бессмыслица и чисто эстетический компонент.

Цитата:

Но в КЯП не требуется бегать по дереву сайта для того, чтобы определить, какой модуль "мы имели ввиду"...

В DL это настолько быстро, что можно и сбегать.

Так как?
1. CMS уже реально можно использовать? Для каких целей?
-1.1 Можно ли использовать её как форум/галерею/файловый архив?
2. Нет ли желания добавить функцию вики? То есть, без всей этой ерунды с форматированием и вики-именами, но с возможностью контроля версий документов?
3. Есть ли возможность регистрации разных пользователей?

Harzah

Цитата:

CMS уже реально можно использовать? Для каких целей?

Цитата:

Можно ли использовать её как форум/галерею/файловый архив?

Те типы контента, которые Вы перечислили, в данный момент не реализованы в качестве модулей. Система в том варианте, как она есть сейчас, предназначена в основном для текстовых типов контента. DeeLight подвергнется полному рефакторингу кода в феврале и выйдет пара бета-версий с добавлением core-функционала. Таким образом, новые модули появятся только в феврале-марте.

Цитата:

возможностью контроля версий документов?

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

Цитата:

Есть ли возможность регистрации разных пользователей?

Это предусмотрено уже в настоящей версии, но не реализован интерфейс и не введена в действие система прав.

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

Скачал build 20041204. Установил...
Объясните, плиз, как войти в админку?
Какие пароль и логин по умолчанию?

/admin/
логин: admin, пароль: pass
fathersGrave не я один этого не увидел

Я же уже на страницу загрузок запихнул инфу?..

хорошо бы продублировать это и в readme.txt
кстати, там же можно и исправить адрес Официального сайта системы: .ru поменять на .org

Спасибо.

fathersGrave
Можно еще предусмотреть следущее:
Допустим есть раздел "Контакты". Цель чтобы этот раздел редактировать мог, только пользователь с соответствующими правами, и администратор...

AucT

Цитата:

Официального сайта системы: .ru поменять на .org

Привычка Я сегодня обновлю архив. Спасибо.
Thomas78

Цитата:

соответствующими правами, и администратор...

Возможность разграничения прав для каждого материала уже запланирована и будет реализовна в 1.1b.

Хаппинуя всем!
Прелестная вещица эта DeeLight CMS, огромный респект автору!
Единственное, что не помешало бы, это тип переменной "image", и какого нить-леееегенького интерфейсика для выбора картинки с локального винта и автоматической закачки и подстановки правильного путя к закачанной картинке. Ну, в стиле уже существующего дополнительно устанавливаемого плагина для TinyMCE - IBrowser http://prdownloads.sourceforge.net/tinymce/tinyMCE_ibrowser.zip?download

Понятно, что можно обозвать переменной image обычный тип переменной text, включить для него TinyMCE, к нему прикрутить тот IBrowser и при редактировании указывать картинку и больше ничего. Но это не изящно.

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

И еще раз респект автору, который не пишет очередную фанерную Нюку для ламеров, а ваяет очень гибкую и универсальную систему, которой, не побоюсь этих слов, еще вообще не было! B-) (А я CMS-ок видел очень много)

GomesAddams
Спасибо!
DL 2.0 ожидается в первой половине февраля. Хочу предупредить, что она уже будет на MySQL. Одновременно, скорее всего, выйдет и продолжение линейки 1.0.

Контент-поле image помимо загрузки файла будет обладать опцией создания превью через gd. Размер превью (ну и необходимость его генерации вообще) будет задаваться при добавлении поля image в контент-тип. Так можно создавать галерею изображений или присоединять изображение к каждой новости.
В плагине ibrowser я просто перепишу его php-часть и подключу к TinyMCE -- это для картинок непосредственно в тексте материала.

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

Это пока так, пара мыслей навскидку.
Когда что-то делаем, то определяемся, для кого делаем, правильно?
Ибо если только для себя, то всех можно смело посылать подальше.
Какой-то лекторский тон получается, но это я так шучу.
Так вот, эта CMS выгодно отличается (и собирается выгодно отличаться) от других своей гибкостью. Значит, она предназначена не только для полного ламера, желающему с нуля создать свой сайт по шаблону (вот таких CMS действительно, как грязи), а должна послужить и вебмастеру, который хочет оставить возможность как доверить редактировать сайт своему клиенту (либо жене, соседу, кошке), так и самому максимально быстро рулить и наполнять сайт.
Как мне кажется, вот, что для этого нужно.

1) Легко прикручивать свой дизайн к CMS-ке.
Здесь с этим проблем вроде нет, - создавай себе template1.php, template2.php, и все такое и выбирай нужный темплейт для создаваемой страницы. Неплохо только считывание наличествующих темплейтов дописать и выводить это в выпадающий список. Но это будет, я понимаю.

2) Возможность редактирования страниц не через CMS, а ручками.
Вот с этим пока лажа. Найти нужный документ в /DATA под поэтичным названием 113 можно, но там же переменная содержит длину строки, это ж потом ручками пересчитывать и вписывать, иначе-ошибка.
Идея хороша, потому что позволяет включать в документ нормальный html без обратных слэшей и прочих предосторожностей для PHP. Но хорошо бы добавить проверку длины переменной при ее считывании на случай, если файл меняли руками, что ли.
Или как нибудь еще, но сохранить главный потенциал не-MySQL версии - возможность править содержимое страниц ручками.

fathersGrave

Цитата:

. Хочу предупредить, что она уже будет на MySQL.

Версию для любителей без МуСКуЛов - тоже оставь...

Цитата:

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

Опеределенно. Все основные опции при создании нода будут списками.

Цитата:

Возможность редактирования страниц не через CMS, а ручками.

А вот с этим -- проблема.. Дело в том, что тот формат (сериализация), в котором сейчас хранятся данные материала позволяет наглядно хранить в одном файле несколько полей и быстро считывать данные. В принципе, можно сделать просто через разделитель: поля разделены чем-нибудь типа <-~()~->, но скорость немного упадет из-за необходимости подключения конфига с именами полей. Я еще думал про XML, но с ним производительность вообще никакая с учетом использования php4-парсеров/генераторов.

Antuan

Цитата:

Версию для любителей без МуСКуЛов - тоже оставь...

Да, я помню, ты старый "любитель"

fathersGrave

Цитата:

В принципе, можно сделать просто через разделитель: поля разделены чем-нибудь типа <-~()~->, но скорость немного упадет из-за необходимости подключения конфига с именами полей.

Ну я думаю, господа присяжные заседатели, что на это пойтить можно, ведь система предназначена для малых и средних сайтов, а не на сайты-миллионеры.
Так что выгода явно больше, говорю как вебмастер.
Гораздо быстрее и проще наполнять можно будет и поддерживать администратору.
А если еще и имена файлов не 1, 2, 3 , а что-нить вразумительное и ассоциирующееся с теми ЧПУ, что будут присваиваться страницам, вообще будет супер. Но это сложнее, а вот если можно будет вскорости пошшшупать данные с разделителями, а не с цифрами, описывающими длину строки, будет здорово.
И мне кажется, что с этим нужно определиться раз и навсегда для версии без Мускуля, чтобы система потом спокойно поддавалась апгрейду на следующую версию.

Цитата:

А если еще и имена файлов не 1, 2, 3 , а что-нить вразумительное и ассоциирующееся с теми ЧПУ

Что-то типа "about.hello.world" подойдет для страницы "/about/hello/world"?
Имена файлов 1, 2,.. просто работают по принципу индексов в БД -- коротко и быстро =)

fathersGrave


Цитата:

Что-то типа "about.hello.world" подойдет для страницы "/about/hello/world"?

Это было бы вообще идеально!

P.S. Если будут какие-то бета-версии, то могу потестить их не просто дома, а на реальных кроли... людях...

У меня дежа-вю :) А как по французски "слышать", хю?, вообщем у меня дежа-хю У меня такие размышления имели место (при создании L). Я их вкратце сейчас приведу.
1) Сериализация (serialize()):
Преимущества: 1. Можно "запаковать" любой тип данных; 2. "Распаковка" без проблем (сохраняются ключи, в L4 это был не аргумент). Там так: одна новоcть - один файл.
Недостатки: 1. Размер больше; 2. Скорость "распаковки" ниже; 3. практически нельзя править файлы вручную.
Разделители "~"
Тут дела обстоят с точностью до наоборот.
Преимущества: размер меньше, скорость выше, правка вручную.
Недостатки: "запаковывать" только одномерный массив, ключи - цифры.

---

GomesAddams

Цитата:

по шаблону (вот таких CMS действительно, как грязи)

Не совсем так. Вы перепутали понятия ШАБЛОН и ТЕМА (или скин), шаблонных, на самом деле не так много, а вот CMS которые используют темы, их действительно куры не клюют.

Sindel
Да. Все правильно. Меня вообще колышет только сохранение ключей, что позволяло генерировать страницу, не подключая набор полей. Ну и с удалением полей будет неудобно, т.к. пойдет смещение их порядка.. Нужно планировать свой формат на основе explode().
А скорость у serialize() не намного ниже, кстати. Я тестил.

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

По поводу советов. Наверно было бы не плохо если бы шаблоны для нее делались как для МАМБЫ.

Anderson2004

Цитата:

Наверно было бы не плохо если бы шаблоны для нее делались как для МАМБЫ.

Ты имеешь ввиду как _темы_ для Мамбы? Я не уважаю технологию тем оформления и прочие скиновые решения, ну а в особенности их реализацию в *nuke. В Мамбе это дело немного упростили, но все равно могли бы и лучше реализовать. Тот же Хупс2, например, спасся через переход на Smarty.
В DeeLight никогда не будет стандартизации шаблонов. Это просто не дело CMS. Как верстальщик желает, так он и называет свои шаблоны, картинки, папки и т.п.
Вот в Мамбе можно сделать шаблон не html, а валидного xml вывода? Нет. У нее есть только RSS-экспорт на несколько десятков строк кода, да и не для всех материалов.

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

Вот тот же phpWebSite (http://phpwebsite.appstate.edu/)
Там скины, они типа на основе шаблонов, templates.
Как и все практически CMS-ки.
Но полностью разрулить дизайн сайта там - фиг. Да, он типа на SMARTY, но заданные тэги работают очень выборочно, условно говоря, {Left_top_block} cработает в начальном шаблоне, но не в шаблонах, которые вложены в него. {TEXT} сработает наоборот, только во вложенном. И так во всех, потому что они генерят блоки по готовому образцу, а не данные, которые могут содержать эти блоки.

И я не видел НИ ОДНОЙ CMS-ки, где можно в готовый дизайн вставить нужные пометки и таким образом сделать эту страничку шаблоном, причем нормальным, а не только один блок текста + в некоторых - блок картинки.

К примеру, я хочу в template1.php в левой колонке новости и баннеры, в средней - картинки (не всегда) и текст, в правой - меню, к примеру.
Вот поэтому я готов молиться на любого автора CMS, который сделает систему, генерящую чистые ДАННЫЕ, а не создающую трехколоночник из своих блоков.


fathersGrave


Цитата:

Меня вообще колышет только сохранение ключей

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

GomesAddams
Ну так что?

Anderson2004
Да я тоже разные вещи на php ваял c горем пополам , телепрограмму, "динамические сайты", как пишут вебстудии... Вот на CMS своей мечты кишка тонка, хорошо, что у людей тоже бывают правильные мечты.

Но коли что, свистну, конечно.

GomesAddams, донт ворри, я же не говорю, что это не будет реализовано, а объясняю свой выбор в пользу сериализации.

Anderson2004
Если ты не понял, DL выводит чистые данные так, как хочет верстальщик. В страницу можно включить любые страницы ($API->inc_node()) с возможностью переопределения шаблона. Это значит, что на странице в любом месте можно вывести неограниченное количество "блоков" в любом формате. Я уже не говорю о произвольных текстовых полях..

fathersGrave Эх, осталось дожить до первой половины февраля...

Хм. Я тут прикинул.. а как вам такой формат файлов:

Код:
<?php
array(
"text1" => "blablablablablablablablabla",
"text2" => "blablablablabla...",
)
?>

То есть где сейчас

Код:
a:2:{s:5:"title";s:13:"Как нас найти";s:4:"body";s:54:"Мы сами вас найдем!<br />";}

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