Есть еще такая идея/пожелание - при обновлении движка, лог с результатами обновления, который отображается на экране хотелось бы видеть в более читаемом варианте. Т.е. чтобы сразу было понятно, что обновилось, а что осталось без изменений. Сейчас очень нейдобно просматривать этот список и вчитываться в каждую строку (тем более на зеленом фоне). Как вариант, для читаемости выделить текст цветом, или выводить только ту информацию, которая касается обновленных компонентов.

Ждем реализации. :)

Структура не так часто меняется. Да и контроль версий какой-никакой будет.

Пусть уж разработчики скриптов берут работу на себя, тем более, что конечный функционал, о котором идет речь нужен именно им (читай нам).

Да и делится скриптами никто не мешает.

Я только думаю, Macik, что SQL скрипты не гибки - ведь даже за последний год менялась структура таблицы cot_page и, по-моему, cot_users. Может быть, возможно будет добавлять юзеров, категории и страницы через Cotonti API, чтобы разработчику скрипта не надо было думать про все поля в таблицах и про AUTH?

Двумя руками за!

Думаю, что и реализация не будет сильно трудной. Механизм подгрузки и исполнения sql и php скриптов уже есть в движке. Придумать правило именования этих SQL скриптов (чтобы запускались в определенном порядке), а описание скрипта брать из первых строчек коментария в скрипте.

Например файл 001_add_user.sql:

-- COTONTI: 0.9.1-0.9.8
-- RU: Создает запись тестового пользователя в группе 'members', имя 'test', пароль 'test'
-- EN: Creates test user with name 'test' in 'members' group, password 'test', 

INSERT INTO `cot_users` (`user_name`, `user_password`, `user_maingrp`, `user_country`, `user_text`, `user_timezone`, `user_birthdate`, `user_gender`, `user_email`, `user_hideemail`, `user_theme`, `user_scheme`, `user_lang`) VALUES
('test', '41da76f0fc3ec62a6939e634bfb6a342', 6, '', NULL, '4.0', '0000-00-00', 'U', 'test@example.com', 1, 'nemesis', 'default', 'ru');

Файл 001_more_rocknroll.inc:

<?php
/**
 * COTONTI: 0.9.1-0.9.8
 * RU: Наш чудо скрипт
 * EN: Our mega code
 */

defined('COT_CODE') && defined('COT_INSTALL') or die('Wrong URL');

// тут производим более тонкие настройки

?>

было бы здорово увидеть это решение в движке... но мой 7летний опыт с sed|cot - позволяет предугадать реакцию главных разработчиков...   поэтому, я думаю, стоит просто сделать это на уровне плагина... )))

#33195 Macik:

• ...
• приветственное личное сообщение
• ...

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

2,3. 50/50

4. за

5. не вижу смысла

6,7. за

В идеале, при инсталяции создание всех тестовых данных должно быть отключаемым (например чебокс «создать тестовые данные»). Это тоже упростит жизьнь. В частности тем админам, которые настраивают движок клиенту и, как правило, все равно удаляют ненужные разделы, пееркраивают форум и т.д.

-За

Сейчас после установки CMS автоматом создаются некоторые данные, например: 

• структара разделов и приветственная страница для модуля pages
• структура разделов для модуля форума

Предлагаю их немного расширить, например такими:

• тестовый пользователь (с минимальными правами)
• тестовое сообщение в форуме
• тестовый комментарий к приветственной странице
• тестовые теги для приветственной страницы и сообщения в форуме
• меленький тестовый файл уже загруженный в PFS (для наглядности картинка, которую вставить в приветственную страницу)
• приветственное личное сообщение
• тестовое голосование

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

Для чего это нужно - для того чтобы новый пользователь после установки мог быстро и во всей красе оценить возможности движка, вживую увидев как примерно будет выглядеть «живая» CMS и что в нее включено. (Мог бы потыкать голосовалку, открыть комментарии или помотреть личные сообщения).

Это же (IMHO) упростит разработку тем оформления и их отладку, т.к. можно сразу увидеть «как оно».

В идеале, при инсталяции создание всех тестовых данных должно быть отключаемым (например чебокс «создать тестовые данные»). Это тоже упростит жизьнь. В частности тем админам, которые настраивают движок клиенту и, как правило, все равно удаляют ненужные разделы, пееркраивают форум и т.д.