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

Здорово, спасибо!
А как обстоят дела с кармой и всем что с этим было связано? :)

Все остальное — после перехода на jQuery.

jQuery и Все остальное — это будет событие! Жду с нетерпением.

Да, мне надо к этому моменту подойти еще, потому что очень многое потребуется переписать.

Хмм. странно. Дмитрий, отчего может быть такая ситуация.
Только что скачал последний cogear. Во-первых оставленных коментариев не вижу. И один раз по ссылке site.com/comments/admin/ вылезла ошибка:
A PHP Error was encountered Severity: Warning Message: krsort() expects parameter 1 to be array, null given Filename: comments/index.php Line Number: 165 Так понимаю что коментарии были (1 точно был), но переменная output ничего не передала. Сейчас не могу поймать ошибку, попробую еще чуть позже.
(Win/Denwer) — раньше такого не было

Что за глюк. И статьи написанные не вижу

в базе вижу. в заголовках Коментарии (2) и Блоги(3). Статьи вижу если обращаться по пути site.com/blogs/admin/testpage-4.html. Облако отображает все тэги.

Вы обновились полностью? После обновления файловый кеш на забудьте почистить.

Длинна комментария неограничена?

Ограничена длиной поля text в БД.

Может сделать настраиваемой эту опцию с min-max значениями?

Нужно ли это? Пишешь ты коммент развернутый и полный, и, вдруг, появляется оповещение «Пожалуйста, не больше 500 символов!» :-)
Минимальное значение для коммента в 5 символов установлено изначально, чтобы избежать комментов-смайлов :-)

Здравствуйте, скачал новую версию и решил не перезаписывать все файлы, а скопировать каталог tags в gears, скопировал, в панели управления сайта установил. При написании статьи отображается поле тэги, а на главной странице блока Тэги не показывается, какой файл надо ещё заменить, чтобы не менять все файлы, именно для того, чтобы заработали теги?

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

Спасибо.

cogear.ru/tags
A PHP Error was encountered Severity: Warning Message: Missing argument 1 for Index::index() Filename: tags/index.php Line Number: 29
Так и должно быть?

Конечно, нет. Сейчас внесу коррективы.

Исправил.

Скажите, пожалуйста, какие компоненты mootools используются подсветчиком кода Lighter?
mootools.net/core/

Да, конечно. Используются библиотеки ядра (core).

Небольшое пожелание. Давайте чтоле создадим сообщество Идейница и как пунктик меню сделаем. Чтобы каждый мог туда свои предложения реализации постить или что нибудь подобное.
Ну и парочку идей. Насчёт мультисайтовости.
1. Сделать возможность мультисайтовости по анологии с друпалом.
к примеру
структура директорий.

• gears
• machines/
  
  • default/
    
    • gears/
  • sitename1/
    
    • gears
  • sitename2/
    
    • gears/

И сделать приоритетность шестерёнок. чтобы к примеру можно было подменить к примеру шестерёнку tags, просто создав для default/gears такуюже
2. Настраиваемая главная страница. Чтобы можно было самому настраивать выводимый контент на главной или может быть сделать реализацию хука hook_index для модулей, который предоставлял бы контент для главной, а там уже админ выбирал бы какой контент модуля или нескольких модулей выводить на главную.

1. Хорошая идея. Хочется движок заново написать очень часто — быстрее реализовать такие идеи с нуля, чем внедрять в уже готовое пространство.
2. Просто надо в роутере шестеренки поставить правило ":empty = gear_name" :-) Ну, и чтобы у нее позиция было ранняя, чем у шестеренки index.

Ещёб убрать уклон на Соц сети. некоторые при таковых признаках, пишут «очередной хабраклон» и даже дальше не интересуются движком.(Эт я всё про тему настраиваемой главной страницы =) )

Да, с главной страницей согласен и не только главная страница должна быть настраиваемой! Учитывать, что только компоненты будут в будущем настраивать страницу мне кажется зря, сторонние и разные виджеты должным планироваться на любую страницу. По поводу соц сети, развивать и перерождать в что-то большее, как только появится своя изюминка, возрастет интерес и от хабра-запаха не останится и следа.
Зы.: Взять хотя бы респективу, соц сеть, но иная. примеров масса.

И еще, еще, еще… :-)
У меня есть стойкое желание отделиться от CI, чтобы от него не зависеть и превратить cogear в CMF.

Я только за =), главное хорошая документированность и всё будет гуд. =) ЫЫ

Как это отразится на уже запущенном проекте?

Думаю над будущим. Если и переходить на jQuery, почему бы тогда не сменить столь же координальные моменты? Можно вести два форка. Или сделать открытый доступ к разработке данного движка, оставив базовые момент «как есть», а самому на базе полученного опыта делать более монументальные шаги, такие как фреймворк.

Cogear Managment Framework =)

Поздравляю, у вас подрос ТИЦ! Идете в гору :) Мне кажется веточку начинаем с тегами засорять.

Спасибо.

По поводу 2х движков. Я думаю нужно CMF, но в ключе CMS и проще чем друпал. Т.е админский интерфейс из которого и делаете весь ресурс, а компоненты, это инструменты разработчика. В любом случае мне как человеку далекому от программирования данный движок интересен как CMS и я буду настаивать на его развитии. Мне нужен модуль разделов :) Вот почему на этом сайте есть разделы меню, а в сборке нету? По поводу кармы, считаю что должен быть модуль, а вообще отменять ненужно! Захотел включил, нет так нет! И все таки, «Мне нужен модуль разделов». :)

Сейчас попытался активировать плагин «Теги», но не получилось, пишет «Неудача. Задание не выполнено».? (

Проверяем загружен ли дамп tag в БД, и включен ли модуль в файлах конфигурации «TRUE», все работает.

Скорее всего права на файлы загруженные не проставлены верно.

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

gears/tags/templates/ если я не ошибаюсь

Нужно в конфигурационном файле виджета убрать класс стиля «white».

спасибо

Я конечно прошу прощения, но при установки системы с нуля у меня сразу несколько проблем. Постараюсь описать их ниже.
Первое это залогинившись и нажав на название поста я не попадаю в него! Я не могу добавить комментарии, потому что даже формы нет.
Второе, это я перетаскиваю в боковую панель облако тегов и о чудо у меня ошибка!
A Database Error Occurred Error Number: 1146 Table 'soc.nodes_tags' doesn't exist SELECT COUNT(nodes_tags.nid) as count, tags.name FROM (nodes_tags) INNER JOIN tags ON tags.id = nodes_tags.tid GROUP BY tid ORDER BY tags.name asc LIMIT 50
это если залогинившись, а вот если не залогинившись:
A PHP Error was encountered Severity: Notice Message: Undefined property: stdClass::$name Filename: user/_hooks.php Line Number: 38
почти уверен что проблема не в скрипте а в архиве, обновите, если не сложно!

Обновите дистрибутив.
Для того, чтобы виджет тегов активировать необходимо включить модуль «Теги». Исправил ненужную видимость виджета неактивного модуля.

Окей, теги мы скажем победили :)
Но вот по поводу первой проблемы так ничего и не прояснилось. Я добавляю запись. Перехожу на главную страницу и счелкаю по ее заголовку который ведет примерно на следующий адрес: demo.ru/blogs/admin/12312-3.html#cut
Но при этом открывается не сам пост с подкатом, а блог пользователя его создавший.

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

Исправил. Это был лишний символ в .htaccess. На днях боролся с проблемами одного пользователя на хостинге РБК с ошибкой «No input file specified», которая по-умолчанию получается при использовании CI. Оказалось, что у них PHP запущен через php-fpm, поэтому пришлось найти решение на просторах Сети.

Как на счёт того что бы перенести все шаблоны от всех модулей в одну папку? Я думаю гораздо проще было бы создавать новые, нежели рыскать в куче папок, подпапок…

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

Теги будут более выражены, когда их будут использовать много раз. Вы хотите два-три раза тег использовать и чтобы он был на половину «Облака тегов» по размеру?

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

Я думаю проще всего сделать чтобы шаблоны модулей можно было подменять, из шаблона, создав папку <название модуля> и туда поместить все шаблоны с <название модуля>/templates после их модифицировать. Если такая функция уже есть, то извините за тавтологию =)

Согласен. Скоро сделаю.

Ну а как же шаблонность CMS?
Как мне создавать, верстать шаблоны, да и не только мне если они разбросаны по куче папок? Это же не логично и как минимум не удобно внедрять новые дизайны. Я бы с радостью выложел в паблик новый шаблончик если бы все было в одной папке или как минимум расписана документация где какие лежат и где какие элементы верстать!

Думаю в скором времени будет реализована эта возможность

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

Вы меня конечно извините но в папке templates я не нашел то что подразумивает ее название…
Может вы меня всё таки пнёте в верном направлении и скажете где и что редактировать?

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

Я с самого начала первой публикации о когуаре слежу за его развитием и вижу, что широкой популярности он не набирает, а даже наоборот.
Почему так происходит? Я не знаю) но у меня есть свои предположения:
1. Очередной Хабраклон. Зачем, если есть более функциональный LiveStreet с нормальным сообществом? Думаю нужно уйти от этого и вообще смотреть в сторону развития CMS типа djem.
2. Коммерческая лицензия. Русский человек любит бесплатность, когда видишь на сайте в первом абзаце слово OpenSource или GPL, на душе становиться как-то теплее) видно, что тебя ни к чему не обяжут и уж темболее ни за что не накажут. Пусть она и не действует пока оффициально, но на подсознании это работает в положительную сторону.
3. Нет сообщества. Думаю что именно из-за 2 пункта его и нет. Либа делать OpenSource, либа как на LiveStreet привлекать людей призами/деньгами.
4. Шаблоны. Как тут уже заметили проблема с полной сменой дизайна есть, я сам с ней столкнулся и стал смотреть в сторону других CMS или даже писать свою под свои нужды, после того как запутался в куче открытых файлах шаблонов в разных папках, да еще когда обнаружил верстку даже в файлах хуков. А представте что произойдет при обновлении движка.
5. Модули. Создать раздел с модулями. И разрабатывать новые модули. Посмотреть какие модули популярны в других CMS и делать аналоги.
6. Перестать страдать перфикционизмом и думать о переписывании движка заного или уходе от CI, это может продолжаться бесконечно, а наращивать функциональность.
Ну вот примерно такое мое мнение.
p.s. что то давно не было никаких новостей, создается впечатление, что вы забросили свое детище? интересно было бы узнать планы по дальнейшему развитию, над чем работаете сейчас.

Почти со всем согласен, а вот с этим:

p.s. что то давно не было никаких новостей, создается впечатление, что вы забросили свое детище? интересно было бы узнать планы по дальнейшему развитию, над чем работаете сейчас.

на все 100000%

Быстро, только мухи женятся! А место того чтобы разводить руками тут и там посодействуйте развитию.
Разработчик средств не получает, делает ЧТО-то по возможности в свободное время, скажем проще хобби. В таком случае чего с него спрашивать? Конкурсы, тоже на что-то нужно проводить! И потом вам дали лего, стройте! Автор так и заявляет, что все очень просто.
Я по прежнему за отладку и развитие движка!

Давайте будем менее эмоционально реагировать) Я ни в коем разе нихочу никого обидеть.
К сожелению помочь в разработке не могу, т.к. имею очень небольшой опыт разработки на PHP и никаким на CI. Но я бы помог материально, если бы 2ой пункт соответствовал моим принципам. Также я бы с удовольствием поучаствовал в безвоздмездной разработке шаблонов, но в 4ом пункте я написал как это проблематично и думаю что сначала нужно решить эту проблему.
А что сделали Вы для развития когуара?)
А лего думаю всеже дал EllisLab, а Дима собрал из него велликолепный продукт. И еще раз желаю ему не сдаваться!

Свои возможности я уже давно предложил разработчику, на данный момент тишина, может в скором времени я смогу быть полезен, не знаю. У меня же в процессе разработки 5 модулей на этом движке. Второй пункт, если честно то я его вообще не воспринимаю буквально.

Каталог модулей уже есть, но до того, как его активировать, я бы хотел, пока не поздно, внести базовые коррективы.
Что хотят пользователи:
1. jQuery.
2. Мультисайтовость.
3. Возможность переопределять любые шаблоны безболезненно для обновлений.
Для меня данный шаг видится следующим образом:
1. Переписывается ядро — исключается CI. 1-2 недели плотной работы. Уже знаю что и как сделать, благодаря полученному опыту, и сколько времени на что уйдет.
2. Реализуется возможность использовать любые сторонние компоненты для скорости разработки — классы хоть от CI, хоть от Kohana.
3. Быстрым темпом базовый функционал переносится на новое ядро (перенос включает в себя миграцию на jQuery).
4. Сайт обновляется, и появляется каталог компонентов.
5. Благодаря правильному направлению развития движок становится популярным.

Самое главное.

• Все буду делать без спешки. Мне интересен сам процесс разработки — контролировать его «от и до». Лучше свести количество ошибок к минимуму, а возможностей — к максимуму.
• Учесть все требования пользователей.
• Поступать по совести. Текущая производительность, как и некоторые другие аспекты движка, меня не устраивают. Знаю, что можно сделать лучше — и сделаю, прежде чем начинать движение вверх.

Ну вот теперь на душе стало спокойней). Может продублировать комментарий в новости?

Как только сяду за работу, скорее всего на днях, так и отпишусь.

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

Добрые слова на хорошую перспективу благое дело. :)
ЗЫ: в моем случае главное чтобы ядро не повлияло на новоиспеченные модули, основательно!

1. Согласен, с самого начала держу курс на уход от клонировая Хабра. Для этого есть *-стриты и иже с ними.
2. Лицензия двойная — бесплатная/коммерческая. Она практически равносильна поправке «снятие копирайтов за взнос от 1000 рублей».
3. Почитайте Википедию по поводу того, что же такое OpenSource. cogear как раз относится к такому рода проектам — с открытым исходным кодом.
4. Если пользователь меняет базовую структуру вывода компонентов, а не глобальные шаблоны («темы»), то данное действие можно назвать уже веткой их развития, потому что оно отходит от замысла автора компонента. Базовый код разметки в коде программы допустим в тех случаях, когда требуется расширяемость и скорость работы. Ради вывода одной только ссылки не стоит создавать отдельный шаблон — дороже обойдется.
5. Пока есть много идей по развитию архитектуры (в том числе со стороны пользователей) — стоит реализовать их сначала, а после строить каталог модулей.
6. Как раз в данный момент и пытаюсь решить данный вопрос — что же лучше: написать ядро самому или дальше уходить от CI, таща за собой его корни.
После плодотворной летней работы в начале августа ушел в свадебный отпуск. Как только абстрагировался от проделанной работы — появилось желание устремиться к коренным изменениям (jQuery на свое ядро). В таком состоянии пребываю и сейчас, пытаясь усесться за работу. Пришла осень, хорошая погода покинула наш город, и теперь появилась возможность продолжить свой труд. Самое трудное — сесть и снова войти в рабочий режим.

Я тоже за, только вот не понимаю упрямства автора по поводу шаблонов… Это единственный момент который меня отталкивает и всё. Какая разница динамический, статический контент, все шаблоны должны лежать в одном месте. ИМХО

Как модули обновлять будете в таком случае? Целостность нарушается.

А что не так простите с обновлением модулей? Расскажите, может я правда тупой. Но во всех системах которые я использовал обновление идёт в основной только программных файлов, которые отвечают за функционал модулей. А шаблоны прикладываются уже дополнительно с описанием что нового обновилось относительно предыдущих версий. Человек уже В СВОЙ шаблон их вносит если ему это надо или необходимо.
А теми стандартами что существуют сейчас вы загоняете ВСЕХ своих пользователей юзать один шаблон только с разными логотипами. Кому это надо? По-моем личному мнению ваш стандартный шаблон даже не красивый, но это не к тому что я хочу вас зацепить или обидеть, вовсе НЕ ТАК! Это к тому что дайте нам, простым пользователям, возможность творить, создавать — представлять вашу систему в самых разных проявлениях, а не только лишь в одном дефолтном стандарте!

Когда один модуль является одной папкой — обновить его очень легко. Можно, например, загрузить обновленный модуль поверх существующего. А если модуль не один, а их десятки?
Имея разные наборы установленных компонентов на разных сайтах, вы можете легко изменять общий дизайн (глобальные шаблоны), сохраняя модульность нетронутой. Иначе вам придется строго следовать тому, чтобы новая «тема» сайта содержала необходимые шаблоны для всех установленных компонентов.
Вы можете в файле стилей глобального шаблона переопределить любой стиль на сайте (в модулях), сохраняя модульную структуру при этом.
В скором времени будет сделана возможность переопределения шаблона компонента в глобальном шаблоне, если пользователь хочет и внести коренные изменения, и сохранить модульность системы целостной.

Ну и еще если интересно моё мнение, не стоит отказываться от CI, отличный фреймворк. Вам просто он приелся за долгое время работы с ним, и вы чувствуете что можете сделать больше и что то свое. Это всё понятно, но думаю вряд ли ЭТОТ проект станет значительно лучше если вы все же решитесь на этот шаг. Опять же это лично мое мнение. А вот за jQuery скажу только тёплые слова :)

CI , безусловно, хорош, но в своих рамках. Мы же уже некоторое время стараемся за рамки эти выйти.
Лучше использовать собственное ядро, которое сможет использовать классы любых других движков (при соответствующей лицензии).

Как я уже говорил — разработчик из меня никудышный, поэтому я тоже судил о когуаре со стороны конечного пользователя и думаю, что таких людей большинство, поэтому нужно все же ориентироваться на удобство движка не для веб-разработчиков, а простых пользователях, которые обычно знают немного по немногу).
По поводу шаблонов, может глупость сморозю, (а вдруг упустился из виду такой вариант) но мне кажеться было бы удобно сделать как например в ExpressionEngine, шаблоны в БД.

«Шаблоны в БД» так или иначе придется кешировать, что равносильно файловым шаблонам. К тому же, файловые шаблоны удобное редактировать — редакторы с подсветкой синтаксиса на любой системе есть. Пробовали редактироваться шаблоны в БД в таких продуктах, как, например, vBulletin — удобно? :-)

сверстать можно в оффе в редакторе и скопировать в БД, а подправить, так нестрашно, можно стерпеть. Просто в реализации кажется это проще чем перекрывать шаблоны и собновлением проблема вроде решается. Я не утверждаю, просто предполагаю)

сверстать можно в оффе в редакторе и скопировать в БД, а подправить, так нестрашно, можно стерпеть.

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

у меня в свое время была булка, с шаблонами я намучился порядком, а по сему для меня лучше разбросанные шаблоны по папкам модулей, чем а бд

Повторяю, я сделаю переопределение стандартных шаблонов, используя схожую структуру папок в глобально шаблоне.
То есть, если существует файл "/templates/имя_шаблона/gears/nodes/node.tpl", то он использован вместо "/gears/nodes/templates/node.tpl".

А на производительности это не скажется?

+1 запрос «file_exists» на шаблон роли не играет.

Они не «разбросаны», а лежат упорядоченно.
Например, если вы хотите отредактировать шаблон ноды, то идете в "/gears/nodes/templates/node.tpl". Если постраничной навигации — в "/gears/pager/templates/pager.tpl". И так далее — все по логике.

Не всё так просто как кажется, я вот захотел отредактировать шаблон блока вывода облака тегов, и по логике заелз в папку gears/tags/ и что? Где там шаблоны? Их там даже близко нет! Поэтому я и прошу инструкцию, которую вам как разработчику не сложно будет написать и даже не займет много времени где что лежит, а если сделаете переопределение шаблонов подписать какой файл за что отвечает, у всех CMS которые хоть более менее себя уважают есть такие FAQ, я хоть и программист от части и с CI работал, но тратить лишнее время ковырять сошки что бы узнать где нужный мне шаблон считаю извращением.
P.S. спасибо, что отвечаете, и за переопределение :)

Что такое «облако тегов»? Это виджет! «gears/tag/widgets/tag.php» :-)

И всеже мне не понятно чем эта модульность в шаблонах так хороша, неужели так удобно ковыряться в десятке открытых файлах. Ведь все равно они в итоге собираются в один файл.
По мне так самая удобная схема шаблонов выглядит примерно так:
/templates/ default/ css/ style.css img/ logo.png js/ tooltip.js primary.tpl secondary.tpl 404.tpl
Во всех нормальных цмс так сделано. Думаю, если бы Дима сделал так, то на несколько шагов приблизился к пользователям.

Если вы посмотрите на структуру глобальных шаблонов — у меня сделано точно также :-)
Модульность хороша, спору нет. Вы по-любому будете «ковыряться в десятке открытых файлов», потому что все шаблоны в один файл никто размещать не станет — это антиудобно.
А разницей в путях между «templates/default/tags/tag.tpl» и «gears/tags/templates/tag.tpl» можно пожертвовать ради безболезненного обновления компонентов.

Также, но верстка каждого модуля отдельно, а мне как раз удобнее, когда все в одном файле) Но сколько людей столько и мнений.
Когда делаешь простой дизайн типа хабры то впринципе можно помучиться и с десятком файлов, а когда дизайн сложный и имеет значение каждый пиксель, то удобнее когда вся верстка в одном файле.
Думаю пора заканчивать эту тему) Я рад уже хотябы тому варианту, который ты предлагаешь, нормальный компромисс. И желаю тебе плодотворной, творческой недели :) с нетерпением жду результатов.

Обычно не пишу таких тупых комментариев но:
ПЛЮС ОДИН!

Дмитрий, спасибо огромное Вам за труд. Хотелось бы в скором времени увидеть каталог модулей (gears), уж очень нужен функционал топиков-опросов и топиков-ссылок, как у Вас на usemac.ru.
Успехов Вам и терпения.
p.s. быть может стоит сделать страничку «помощь проекту»? К сожалению мой нынешний уровень знаний php пока не позволяет писать модули или вносить какие-либо исправления в движок (с CodeIgneter не знаком совершенно), пока помочь могу лишь небольшим пожертвованием…

На жизнь хватает пока, спасибо! :-)
Пожалуйста. Приятно, что мой труд полезен вам.
Будет все, просто надо немного подождать, пока вектор внутри меня примет верное направление.

небольшой вопрос, пока не пробовал вставлять больших изображений в новость, но заметил у вас на usemac.ru в новости «Заказываем Mac OS X Snow Leopard» текст сдвинут из-за большого изображения (или только у меня так отображается), так вот к чему это я, нельзя ли сделать так, чтобы при загрузке больших изображений устанавливался определенный максимальный размер рисунка, ну или в админпанели такую функцию включить.

Там это большое изображение отцентровано по центру.
Параметры изображений находятся в файле "/gears/upload/upload.info".

там указано соотношение 640x480, т.е 4:3, значит нужно указывать определенный размер чтобы рисунок смотрелся нормально, а нельзя указать допустим только ширину а высота автоматом подгонялась под нее?

Попробуйте. Насколько мне помнится — можно. Там также можно указать стандартные параметры для CI — соблюдение пропорций, кроп и т.д.

Шаблоны, шаблоны, только отвлекаете от мыслёв Диму.
По поводу всё в одной папке, даже в одном файле.
Покажите мне CMS у которой всё в одной папке?
Joomla — один index.php в нём определены области для модулей, вывод модулей и шаблоны лежат в папках с модулями
Drupal — каждый модуль имеет свои tpl, которые подменяются в папке с шаблоном, если нужно.
А если вам нужно целостность картины, то лучше вначале сверстать HTML макет, после уже разделять и вставлять по файлам, по крайней мере я так делаю. =)

Покажите мне CMS у которой всё в одной папке?

Сразу сходу — DLE.

Сколько времени уходит на обновление DLE на новую версию, если на ней установлено хотя бы парочку сторонних дополнений? :-)

Для серьезного проекта который сделан для людей, а именно в этом главная ценность хорошей CMS найти лишних 15-20 минут на обновление, даже для нуба — я думаю не проблема.
Думаю не мне говорить, не вам слушать — но нет абсолютно идеальных решений… Так почему бы не использовать оптимальные, проверенные временем?

Серьезно говорю, многие годы работаю c DLE. Обновить DLE нафаршированный модулями — та еще морока.

У DLE плохая слава. Не видел поистине достойных проектов на этой CMS (достойный значит не варез не корпоратив не то что видим каждый день везде и всюду)

Общеизвестный факт. Если проанализировать код DLE, то мнение формируется еще более худшее :-)

Тем не менее, популярность DLE растёт с каждым днём. Вместо того что бы плеваться в ее сторону, по-моему стоит проанализировать ситуацию и найти эти самые причины. Доступность (в большинстве своем null-версии), второе это — простота знакомства и понимания принципов работы, третье — стабильность и НЕбажность скрипта, открытый код, простота разработки и внедрения доп.модулей, дизайн, шаблоны — их просто дохрена(уж простите за скудность речи), есть из чего выбрать, если это переносить в плоскость «нашей» системы, то необходим хороший, качественный, красивый, валидный шаблон! Ведь какого бы не была ахеренного функционала система, она оттолкнет потенциального пользователя если у нее будет не красивый дизайн — это не просто выдумки, а реальный опыт и результаты не одного опроса ни на одном форуме!
JiLiZART, если ты не видел достойных проектов — это не значит что их нет, если так сильно интересно — напиши мне в личку приведу тебе примеры хороших, качественных сайтов, но в ответ от тебя попрошу ссылки на «поистине достойные проекты», как ты выражаешься, проекты на системах cogear, livestreet, bigstreet, explay или подобных системах, идёт?

я про cogear, livestreet, bigstreet, explay ничего не писал. Я писал про Joomla и Drupal =0. А DLE популярен из-за своей доступности. И то что его легко занулить, это его не украшает.

Привет! Как дела?
ЗЫ Я тебе одно — ты мне другое.

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

Можно я тоже ключивеки будут тегом «B» выделять? ;)

Посмотрите список ключевых слов — DLE там нет.
Для ясности текста.
Хотите — пожалуйста.

Вы меня извините, если это прозвучало грубо. Вовсе не хотел.
Но если слово на странице выделено жирным — оно для поисковиков становиться практически ключевым ;)

Все в порядке. Одного лишь выделения слова жирным не достаточно для поисковой оптимизации.

И все же плюсов не хватает =)