» mojito cms

Цитата:

Посмотрел все запросы: основная масса уходит на генерацию меню (особенно на выяснение активного пункта).

А теперь подумай, как часто будет меняться меню и не имеет ли смысл его кэшировать... Вообще советую выводить все запросы внизу страницы, желательно с подсветкой и временем выполнения каждого запроса, это может значительно упростить жизнь
Я тут тоже делаю свой движок (точнее новую версию), сейчас как раз над шопом работаю, так посмотрел ради интереса oscommerce и... ужаснулся 97 запросов для главной страницы, причем, что самое интересное много запросов повторяются...

fathersGrave
Внешне - мне понравилось. Готов по мере возможностей помочь с тестированием.
Можно слать на RuCMS[@]ZiLot.ru

fathersGrave
Тоже интересно. Шли на webmaster[@]kindgood.ru

fathersGrave
и про меня не забудь egorka[@]newmail.ru

fathersGrave
Интересная разработка))
Шли и мне dacuan(собака)yandex.ru

Хм!!! Сколько заинтересовавшихся! Вот вам и наше коммунити.
Да, конечно для начала форум нужен - надеюсь на счёт хостинга договорились.

zapimir
Пока кэшируются все страницы сайта на один срок, я не вижу смысла кэшировать что-то отдельно. Вы просто попали на время устаревания кэша, все последующие генерации страницы -- это 1 запрос (разбор uri).
В следующих версиях для каждой страницы можно будет выбрать срок жизни кэша, а меню, возможно, будет кэшироваться отдельно.

Цитата:

посмотрел ради интереса oscommerce и... ужаснулся 97 запросов для главной страницы, причем, что самое интересное много запросов повторяются...

Ну oscommerce же для е-палаток и е-ларьков и предназначена

а разве нужно кэширование на срок, всего что есть? по-моему всё должно кэшироваться отдельно бессрочно: при добавлении новости очищаем весь news_cache, должел быть ряд функций управления им, например для тех же плагинов меню, например в headlines (экспорт RSS) - даём промежуток времени между очисткой. Это всё конечно скажется на скорости системы, но какже обеспечит модульность?!

psati
Такой вариант тоже возможен.
В 0.1а система кэширования элементарная -- ее в любом случае еще нужно развивать.

Цитата:

Вы просто попали на время устаревания кэша, все последующие генерации страницы -- это 1 запрос (разбор uri).

Это ладно, но такое кэширование подойдет только для почти статического сайта, и зачем тогда делать один запрос для разбора uri? Кешируй и его, а то в случае падения базы из-за этого одного запроса не будет ничего работать. А вообще не столь важно сколько запросов там при кэшировании, почему при выводе новости их 14, для сравнения _http://forinsurer.com/news/04/08/25/1608 там без всякого кеширования используется только 9 запросов, это несмотря на то что там значительно больше инфы выводится (кроме самой новости, новости и статьи по теме, список тем, календарик, новости дня плюс еще счетчик просмотров новости увеличивается)...

Цитата:

Ну oscommerce же для е-палаток и е-ларьков и предназначена

Хороший движок должен уметь делать всё

Цитата:

я не вижу смысла кэшировать что-то отдельно.

Вот и напрасно... Что касается срока действия кэша, тоже не совсем понятно зачем, движок просто должен отслеживать изменение контента, если он обновился тогда и чистить кэш.

zapimir

Цитата:

почему при выводе новости их 14, для сравнения _http://forinsurer.com/news/04/08/25/1608 там без всякого кеширования используется только 9 запросов

Потому, что тот движок писал не я =)
Буду обязательно сокращать количество запросов. 14 -- это же не stable релиз, а первый блин

Цитата:

Вот и напрасно...

Фраза была выдрана из контекста.

Цитата:

движок просто должен отслеживать изменение контента, если он обновился тогда и чистить кэш

Это уже обязательно будет. Спасиб!

Стрёмно конечно как-то жаловаться и просить о помощи, но вот эта конструкция чего-то у меня не проходит (index.php):

//----- START INCLUDE COMMON LIBS --------------------------------------------
$dir_name = "$CFG->dir_root/libs";
$dir = dir("$dir_name/");
$dir->read(); $dir->read();
while (false !== ($lib = $dir->read())) {
require_once("$dir_name/$lib");
}
$dir->close();
//----- END INCLUDE COMMON LIBS ----------------------------------------------

Для мое сервера выдаёт:
Warning: dir(/usr/local/www/usrs/psati/data/public_html/rucms/libs/): failed to open dir: No such file or directory in /usr/local/www/usrs/psati/data/public_html/rucms/index.php on line 21

Fatal error: Call to a member function on a non-object in /usr/local/www/usrs/psati/data/public_html/rucms/index.php on line 22

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

psati
Если установка была в поддиректорию rucms, то просто не был прописан путь, включающий системную папку "cms". Кстати, XMMS уже сообщил, что этот билд не работает в поддиректориях -- только с собственным доменом, но если у Вас домен привязан к папке (rucms.domen.ru -> /rucms), то нужно поправить только пути.

Добавлено
Билд 20040826 с исправлениями скоро будет разослан всем.

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

Можно ссылочку на лицензию BSD?

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

То же самое по поводу кэширования. Кэширование имхо это уже вылизывание и доводка. Тем более каждый блок в идеале надо кэшировать своим механизмом.

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

5-10-хх минутное обновление некоторых имхо резонно. Например... ну количество прочтений ветки форума не обязательно обновлять каждый раз при просмотре.

Вообще то что успели посмотреть - симпатично.
Некоторое недоумение вносит структура <?=$a?>. Точнее её использование само по себе. Это удобно? Можем ошибаться, но как-то фигово читается

Возможно имеет смысл под пхп5 затачивать? Ну хотя бы что бы не анноится по поводу скл инъекций и самих переменных. Методы обращения к базе, классовость и т.д.. mysqli и т.д.

Цитата:

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

* Поперхнулся и продолжительно закашлялся *

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

Цитата:

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

Цитата:

* Поперхнулся и продолжительно закашлялся *
Вы когданибудь держали высокопосещаемый ресурс при таких показателях?

Угу. Вы зря фразу из контекста выдрали, смысл потерялся. Прочитайте пожалуйста бакграунд, он важен.
Тут мысль именно в том, что если для удобства разработки нужно оставить бОльшее количество запросов, то не надо в бете напрягатся с их утаптыванием. При чем именно утаптыванием, то есть не надо конечно писать абы как, но и спецоптимизация ни к чему. А уж 20 запросов топтать в 8... Да дешевле выделенный сервер купить

Если хочешь сделать лучший CMS, обязательно учти следующее:

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

Второе, статические адреса с заданными параметрами (названиями).

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

Четвертое, настраиваемое меню, листинг, вывод листинга из любого раздела/подраздела, top-новости и т.п.

Обрати внимание - в CMS должны отдельно настриваться шаблоны и макеты. И масштабируемость! Сборку страниц вообще желательно делать по умному. Т.е. если имеется некая статья её текст должен вызываться статично. Не нужно его брать из базы. А вот меню и прочие топ-новости - должны генериться/вставляться динамически.

POLL

Цитата:

Во-первых

- V У Вас понятие "масштабируемости" сводится к загрузке своего файла в любой раздел(контента) что-ли?

Цитата:

Второе

- V

Цитата:

Третье

- V

Цитата:

настраиваемое меню, листинг

- V

Цитата:

вывод листинга из любого раздела/подраздела

- будет


Цитата:

Т.е. если имеется некая статья её текст должен вызываться статично. Не нужно его брать из базы. А вот меню и прочие топ-новости - должны генериться/вставляться динамически.

По этому поводу уже очень логично высказался выше zapimir (например, что навигация меняется не чаще раза в месяц, и ее просто неразумно каждый раз генерить).
Кстати, я уже подумываю о возможности делать статичную копию сайта (как MT).

Добавлено
edogs

Цитата:

Можно ссылочку на лицензию BSD?

Система теперь под GPL -- файл LICENSE в дистрибутиве.

Цитата:

Некоторое недоумение вносит структура <?=$a?>. Точнее её использование само по себе. Это удобно? Можем ошибаться, но как-то фигово читается

<?=текст?> -- сокращение от <?echo "текст"?>
Чтобы улучшить читаемость, можно оставлять отступы: <?= $post[content] ?>.


Цитата:

Возможно имеет смысл под пхп5 затачивать? Ну хотя бы что бы не анноится по поводу скл инъекций и самих переменных. Методы обращения к базе, классовость и т.д.. mysqli и т.д.

Когда соотношение хостингов php5(не cgi) к php4 будет хотя бы 30 к 60 % и выйдет нормальная книжонка по php5 (например, котеровская) -- то без проблем. Кстати, XMMS отрепортился, что у него вроде php5.. и ничего.

Так, что там насчет инъекций? Еще забыл отрубить в .htaccess register_globals..

нееее... нужно срочно переделывать систему шаблонов, ибо я уже просто задолбался делать дизайн... во-первых не выбора для темы - стоит один; во-вторых - не лучше ли сделать типа theme.php и писать в нём echo "HTML"; чем мутить в этом base.html; в-третьих такие конструкции не пойдут <?=$a?> - нужно {MENU=1}, {MENU=login}, {LOGIN_FLAT}, {SITEDISCAIMER} и.т.д.

fathersGrave

Цитата:

Возможно имеет смысл под пхп5 затачивать? Ну хотя бы что бы не анноится по поводу скл инъекций и самих переменных. Методы обращения к базе, классовость и т.д.. mysqli и т.д.

Цитата:

Когда соотношение хостингов php5(не cgi) к php4 будет хотя бы 30 к 60 % и выйдет нормальная книжонка по php5 (например, котеровская) -- то без проблем. Кстати, XMMS отрепортился, что у него вроде php5.. и ничего.

Э. Не переводить под пхп5 а подтачивать Запросы к базе в стиле mysqli переписать сразу, что бы потом класс подменил работы и всё ок сразу. А так прийдется и запросы переписывать.

Посмотрели бету. Выглядит симпатично. Жаль что бета Будем ждать некст релиза.
Кстати, при попытке установки, сначала навернуля апач, потом ИИС. Карма?


Цитата:

Некоторое недоумение вносит структура <?=$a?>. Точнее её использование само по себе. Это удобно? Можем ошибаться, но как-то фигово читается

Цитата:

<?=текст?> -- сокращение от <?echo "текст"?>
Чтобы улучшить читаемость, можно оставлять отступы: <?= $post[content] ?>.

Да нет. Что _значит_ структура мы знаем.
Но лично нам это читается жутко неудобно, очень трудно врубиться в логику. Отсюда и вопрос, это мы с непривычки неудобимся или таки будут изменения в будующем?

psati

Цитата:

во-первых не выбора для темы - стоит один;

Выбор есть -- в свойствах страницы.

Цитата:

в-третьих такие конструкции не пойдут <?=$a?>

Я уже объяснял, что "такие конструкции" -- часть идеи. {ляля} потребует.. угадайте с трех раз: ereg_replace.. чего я допустить не могу. Потом: зачем изобретать велосипед в виде конструкций {if sadf}{asdf}{/if} если это все есть в php. Это с непривычки <?= 123 ?> кажется неудобным.

edogs

Цитата:

А так прийдется и запросы переписывать.

Да.. это пора бы уже спасиб!

Цитата:

Кстати, при попытке установки, сначала навернуля апач, потом ИИС. Карма?

Хм.. посмотрю, что там может быть, но не сталкивался..

Цитата:

очень трудно врубиться в логику

А какие трудности возникают? Это же простой принт.. воспринимайте теги <?= и ?> как простое обрамление -- как будто это { и }.

Вот пробовал делать дизайн для системки: http://psati.samara.ws
Это возможно, но тем не менее не выдержал стандартных настроек и теперь base.html стал theme.php; весь текст выводится через echo; управ. структуры (if, else) аккуратно записаны через {}; для удобства вызова рисунков и стилей всё же использовал константы, и теперь это выглядит как: <img src='".THEME."images/logo.gif' />

Ещё неплохо бы НЕ ОСОБО НУЖНЫЕ header и footer содержащие: 1) от доктайпа до титла, 2) <!--some counters--></body></html> - содержать в отдельных файлах, а в самом theme.php так же хранить стили для отдельных менюшек.

Так же для каждой темы своя папка в templates/. Style и JS в папке темы (проверяются if(file_exist...)).

Добавлено
кстате на этом хосте почему-то отказались работать "Блог" и "Привет", хотя на локалке всё окей..? Может ему тут какой-нить _GET нужен или как там ещё?

psati

А почему фигурные скобки? Тогда логичнее использовать <!-- AAA --> - при крахе движка будут дыры в дизайне, а не непонятные пользователю {AAA}

Вообще-то тип шаблона fathersGrave предназначен для экономии системных ресурсов.
А более-менее развитая система, построенная на предложенном тобой варианте - это попытка написать подобие РНР используя PHP.
Вообще - основное достоинство РНР - встраиваемось в HTML - теряется при твоей системе шаблонизации!

psati

3BEP уже все сказал
Альтернативный синтаксис php вписывается в html просто идеально, наравне со всякими искусственными синтаксисами вида {hello}.

Кстати, все эти хедеры и футеры замечательно инклюдятся, а то, что каждая темка лежит в своей директории -- так это в свойствах страницы просто прописываешь Template не "base.html", а "theme/theme.php" и никакого вмешательства в код.
Такое использование констант -- вещь спорная.. например, я не хочу, чтобы у меня в адресах картинок был прописан адрес /cms/templates/mytheme/images/lala.gif. Для нормальных сайтов никто темами не пользуются. Создается нормальный дизайн, картинки кладутся в корень сайта (в /images или в /i), а не в системную папку cms, куда ничего класть не рекомендуется, кроме самих шаблонов. На самом деле эту папку лучше хтаксессом защитить.


Цитата:

кстате на этом хосте почему-то отказались работать "Блог" и "Привет"

Попробуй другой способ ЧПУ в хтаксессе.

Цитата:

А почему фигурные скобки? Тогда логичнее использовать <!-- AAA --> - при крахе движка будут дыры в дизайне, а не непонятные пользователю {AAA}

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

Цитата:

Это с непривычки <?= 123 ?> кажется неудобным.

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

Цитата:

Тогда логичнее использовать <!-- AAA --> - при крахе движка будут дыры в дизайне, а не непонятные пользователю {AAA}

Вообще-то при крахе движка, должно либо выдаться сообщение о ошибке, либо вообще ничего, но никак не необработанный шаблон.

Покажите мне плиз как всё же должен выглядеть .htaccess, т.к. работы я не добился, чтоб я знал: я ли неправильно записал или сервер не даёт!

Цитата:

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

Тогда будет этап компиляции шаблонов, а автор хочет этого избежать, как я понимаю.
fathersGrave я правильно Вас понял?

zapimir

Цитата:

И что мешает при сохранении шаблона, преобразовывать его в вид удобный для php?

Это хранить 2 его версии? Усложнение идет серьезное -- и изобретение велосипеда в плане нового синтаксиса, и хранение кучи маловажной информации. В конце концов можно посмотреть в сторону Smarty, если хочется загрузить систему по полной.

Цитата:

Просто хороший движок должен быть не только быстрым и функциональным, но и удобным для админов

Я изначально хотел "использовать PHP в качестве синтаксиса для шаблонов", как бы это по идиотски не звучало. Разработчики PHP сделали все для его полного и безболезненного погружения в html. Еще хотел заметить, что я не делаю out-of-the-box движок. Имхо, любой веб-девелопер/верстальщик обязан знать основы хотя бы сишного синтаксиса, поэтому построение элементарной логики на php с использованием таких неудобных 3х символов как "<?=" не должно вызывать у такого человека затруднений, тем более что к стабильному релизу по шаблонам будет подробный ман.

psati
Там в дистрибутиве есть дефолтовый хтаксесс: все, что после символа "#" -- это комментарий. В README есть инструкции в примечаниях к установке. Если что -- ICQ 171128248.

voll

Цитата:

fathersGrave я правильно Вас понял?

Абсолютно

fathersGrave

Цитата:

И что мешает при сохранении шаблона, преобразовывать его в вид удобный для php?

Цитата:

А потом назад конвертить?

А зачем назад? Ведь работа будет только с {шаблоном} идти. Можно сделать как smarty. Если шаблон сменился - компилить, исходник оставлять, а не стирать, обратно конвертить не прийдется.

Цитата:

Я изначально хотел "использовать PHP в качестве синтаксиса для шаблонов", как бы это по идиотски не звучало. Разработчики PHP сделали все для его полного и безболезненного погружения в html. Еще хотел заметить, что я не делаю out-of-the-box движок. Имхо, любой веб-девелопер/верстальщик обязан знать основы хотя бы сишного синтаксиса, поэтому построение элементарной логики на php с использованием таких неудобных 3х символов как "<?=" не должно вызывать у такого человека затруднений, тем более что к стабильному релизу по шаблонам будет подробный ман.

Понимаешь, трудностей это не вызывает. У нас. Никаких. Так же как не вызывает трудностей задним ходом на машине по городу ездить, но приятнее передним
Такой синтаксис для нас выглядит как программа испорченная вставлением html кода.

Цитата:

Так же как не вызывает трудностей задним ходом на машине по городу ездить, но приятнее передним

Тише едешь -- дальше будешь.

Цитата:

Такой синтаксис для нас выглядит как программа испорченная вставлением html кода.

Тогда нужно переходить на perl.. вот там оно так и выглядит, а здесь в php -- полная интеграция с html. Что бы вы делали с PHP3 без буферизации вывода, я не знаю..