Атрибут required, как пример, элементарная семантика, встроенная в браузеры валидация. При чем здесь js.

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

Движок как раз и генерит "мусор" из коробки: теги, размеры полей, намертво вкорячен bootstrap/jquery - это ли не свистоперделки?

Честно говоря не понял, от чего так бомбит)

Сворачиваюсь на этом с улучшениями.

Так а помогать-то тебе зачем? Ну вот ты сделал отличную админку (с какого хрена на Pico CSS, правда, не знаю, но это так, риторический вопрос). Запилил там все по-джедайски. Я только не совсем понял про 'required' и про костыли. Валидатор в админке "серверный" для всех форм, так что пустое имя и так не прокатит, и пояснений что это обязательное поле вполне достаточно. Зачем там еще JS-проверки? Если я правильно понял.

Если костыли это ресурсные строки и функции типа cor_rc_modify(), то это не костыли, а функционал, который позволяет тебе кастомизировать разметку и использовать классы для своего CSS-фреймворка. В дефолтных, видимо, можно найти "некрасивую" разметку и стайлзы, но это либо просто не мешает отлаживать какой-то функционал или просто не мешает. Я многие дефолтные ресурсы переопределяю и не чувствую себя униженным)

То, что находится в папке system/admin/tpl, это заготовка, которая должна одинаково подходить для:

1. Разработчика движка (минимум всего + кроссбраузерно)
2. Разработчика админки для сайта (п. 1 + максимально универсально)

Я бы ее еще почистил, но пока не совсем решил как сделать ее по-настоящему удобной и рабочей по этим двум пунктам.

Не надо считать, что system/admin/tpl это, @#$%ь, готовое решение, особенно для домохозяек. Как, собственно, и сам движок. Ты скачал конструктор, выбрал на свой вкус админку и сделал сайт под свои требования. Зашло? Со временем наработал свои плагины, собрал свою админку, поделился с другими и пошел дальше по схеме.

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

На всякий случай, всем миль пардон))

P.S. Не забудь про выкладку.

Я читал по диагонали)

Вопрос - имею ввиду запрос на помощь в приведении в порядок форм.

Что не так с формами на вскидку:

• отсутвуют required для обязательных , вместо этого такое требование отмечено рядом подписями
• нет более ясных подсказок - placeholder
• нет логической группировки fieldset, legend
• кое-где жестко зашиты размеры size, cols, rows

Касательно UX/UI

Например, форма добавления группы юзеров.

Что есть сейчас:

Что здесь не так:

• Что такое уровень?
• Что значит "Пропустить права для этой группы"?

Что примерно ожидает домохозяйка, когда заходит поадминить:

Также внутри генерации элементов форм местами зашито форматирование, теги типа br, заданы стили.

Но это реашаемо костылями. Понятно, что тянется из прошлого века и выпиливается по мере возможностей.

Вообщем это был запрос на помощь с приведением в порядок форм.

#48633 Kort: 

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

Так именно этим я занят. Выложил тему и выразил надежду на помощь в улучшении UX.

Никаких споров о вкусах.

Если вы не видите необходимости, значит вопрос не к вам.

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

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

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

PicoCSS просто тест, решил проверить, как он.

Простой, легкий, ничего лишнего. Можно даже class-less использовать, т.е. чистый семантичный html, что-то вроде

<body>
  <main>
    <h1>Hello, world!</h1>
  </main>
</body>

Файлы - ок, выложу, спасибо за предложение)

#48628 Edward: 
В планах поменять отображение форм, т.к. текущими пользоваться сложновато, никаким UX не пахнет даже близко 😀

Привет, а что не так с формами? Почему Pico CSS? Надо бы и на сайт выложить в "Файлы". Стукни в личку если надо помочь с переводом)

В теме только стандартные плагины, идущие в коробке.

🎨 Легковесный CSS фреймворк Pico CSS + SVG Tabler Icons

📱 Адаптивная верстка (Mobile-first)

🌓 Cветлая/темная темы

🎯 Flexbox/CSS Grid макеты

♿ WCAG 2.1 Level AA accessibility

🚀 Оптимизированная производительность

💅 Семантичный HTML5

Точно работает в Cotonti >= 0.9.23.

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

В планах поменять отображение форм, т.к. текущими пользоваться сложновато, никаким UX не пахнет даже близко 😀

Есть желающие, а главное умеющие в UX/UI буду рад помощи.

Тема на Github:

https://github.com/Edd-G/cotonti-butterfly-admin-theme

А почему тогда пишется дата публикации , а не обновления ?

вызовы несуществующих функций - людям не понарвится , что она как бы "глючит"

<!-- IF {PHP.cot_plugins_active.PLUGIN_NAME} -->PLUGIN_NAME_ROWS

<!-- IF {PHP.function_exists.SOMEFUNC} -->function_exists.SOMEFUNC

Вообще-то вопрос был про frontend-тему. А если нравится тема, сделай и поделись с остальными. Не думаю, что это сложно.

У меня есть переделанная Фронт тема которая использует современные плагины а не коробочные.  Как создать некий список зависимостей , чтобы тема сигнализировала, что необходимо наличие таких-то плагинов и ничего не сломала при переходе на неё ?

Это адаптивная и красивая тема которую приятно открыть с телефона и почитать, что там нового)))

в каком виде могут или должны выкладываться в свободный доступ front-end темы.

Желательно, чтобы как минимум в них была реализована поддержка всего, что есть в коробке. Разве что за искобчением форума, он нужен далеко не всегда.

такой ресурс для вас это только заготовка для дальнейшего творчества или вы готовы использовать его как готовый продукт для своего проекта

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

Хотя нет, мы видим больше "структур", есть ещё "структуры" у коментов и звёздочек (даже не представляю, что эти "структуры" делают)

Исправлено в мастер ветке

После обновления, нужно обновить модули Forums и Pages в админке.

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

Приятно, что сообщество по весне оживает и движок + этот сайт улучшается.

Благодарю за возвращение нормального поиска на этом сайте.

Как приятно и позитивно расписал! 

Приятно, что сообщество по весне оживает и движок + этот сайт улучшается.

Благодарю за возвращение нормального поиска на этом сайте.

Не в обиду, но это, как показывает опыт самого Котонти, не лучший путь. Он предполагает наличие очень подробной документации, которой нет, т.к. это скучный и крайне затратный по времени элемент работы.

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

В то же время, дефолтный вариант движка (не смотря на очень достойную подкапотную часть) выглядит как стрёмная древняя заготовка (уж извините).

Новая красивая, адаптивная админка и дефолтная темы просятся уже давно. Админка есть готовая процентов на 30.

И на этот сайт нужна тема по свежее.

Вопрос в нехватки времени и рук.

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

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

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

 Движок развивается не только как крутая вещь в себе, но и (обязательно) применительно к конкретным реализациям. Интересная задача даст интересное обсуждение и крутое решение. Если хочется прикрутить голосовалки к страницам, создавай тему и будем придумывать. Или если есть другие идеи. А бессмысленные обсуждения в стиле "а вот мне тут не нравится" обычно малопродуктивны и отнимают время у всех участников.

Так именно так и сделал и там уже предложили вполне разумное универсальное решение и даже набросок кода.

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

Для других

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

Еще раз: блок "управление" не есть настройки. Поэтому по умолчанию именно так. Иначе было бы больно.

Админ видит все. Если в жопе очень свербит и админка своя, порядок блоков навигации можно поменять. Если все нормально, на это внимание просто не обращаешь.

Для себя

Здесь все плохо. Приходит человек, который мыслит категориями "черточки / вкладочки" и негодует по причине того, что все:

1. Круто
2. Непонятно и сложно

Его надо или отговаривать по первому пункту или учить по второму ))) Если учиться нет желания или времени (или есть варианты), начинается хроническая стадия.

Аргумент

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

С другой стороны, Котонти это не элитарный клуб, никогда таким не был и, надеюсь, не будет. Но главная проблема у нас -- это неумение / нежелание сообщества задавать правильные вопросы. Например, "я понимаю,что это херня, но прикольно же". ))) Или просьбы раскомментировать весь код до последней переменной. Ну блинский жеж!

Вывод

Движок развивается не только как крутая вещь в себе, но и (обязательно) применительно к конкретным реализациям. Интересная задача даст интересное обсуждение и крутое решение. Если хочется прикрутить голосовалки к страницам, создавай тему и будем придумывать. Или если есть другие идеи. А бессмысленные обсуждения в стиле "а вот мне тут не нравится" обычно малопродуктивны и отнимают время у всех участников.

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

Вот теперь пошёл более осмысленный разговор и понятны мотивы и суть обсуждения.

Далее по пунктам уточнения с моей колокольни которая не претендует на истину в последней инстанции и понятие "у всех так как у меня"

#47870 Sergeich:

2. Конфигурация - безусловно важно, но лазить вы туда будете один раз при настройке и, возможно при обновлении. А он на втором месте.

В моих проектах это в корне не так. Ну точнее не совсем так. Часто бывает что в конфигурации некоторого числа плагинов хранится настройки АПИ которые регулярно подвергается изменениям и дабы держать функционал в рабочем состоянии их нужно регулярно обновлять. Ну вот чисто как пример почему доступ к конфигурациям может быть не такой не востребованный как вы думаете.

#47870 Sergeich:

3. Структура - важно, но посещается даже реже "конфигурации" после настройки.

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

#47870 Sergeich:

4. Расширения

А вот тут как раз может быть и обратная ситуация. Туда могут заходить реже чем ви считаете. Хотя бы потому что единожды настроенная система потом редко требует установки\отключения расширений. Все зависит от специфики сайта

#47870 Sergeich:

5. Пользователи - вообще не понимаю, почему этот модуль вынесен отдельно. Единожды настроенный он больше и не используется никак.

Есть проекты где это популярный раздел. Доказательство этому даже является не мой опыт а тот факт что в комюнити достаточно активно обсуждается сторонний функционал управления пользователями поскольку нужно больше возможностей управления учётными записями (плагин кажется называеться Usermanager)

#47870 Sergeich:

6. Прочее

Ну тут уже конечно всё зависит от конкретного сайта. Да в некоторых случаях как вы говорите там сосредоточен основной функционал админки а в некоторых туда редко заходят из-за другой более удобной и заточеной под заказчика структуры админки.

Вообщем если помнить что для многих разработчиков Котонти это уже давно не CMS'ка а уже полноценная CMF то и ваши подходы к пониманию "популярности" разделов админки могут быть не актуальны.

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

Возьмём админку Котонти. Шесть больших разделов:

1. Главная - раздел текущей статистики и быстрый доступ к самым востребованым функциям. Хорошо. 

2. Конфигурация - безусловно важно, но лазить вы туда будете один раз при настройке и, возможно при обновлении. А он на втором месте.

3. Структура - важно, но посещается даже реже "конфигурации" после настройки.

4. Расширения - без вопросов, единственное не хватает кнопки "Установить" в общем списке плагинов, щёлкать по названию плагина для установки вообще не очевидное решение.

5. Пользователи - вообще не понимаю, почему этот модуль вынесен отдельно. Единожды настроенный он больше и не используется никак.

6. Прочее - не смотря на пренебрежительное название, именно этот раздел отвечает за управление сайтом, именно сюда пользователь будет чаще всего бегать. Но опять же, нафига здесь блок информации "Ядро", по логике ему самое место в разделе "Конфигурация".

Ну вот как-то так, взгляд со стороны :). 

Вопросы ко всем, кто давно использует различные CMS: 

1 .Какие блоки информации вам реально нужны на главной странице админки?

2. Какие функции управления в админке вы чаще всего используете на рабочем сайте?

Рассматриваем не конкретно Котонти, а сферическую CMS в вакууме :).

Ответы:

1) В моем случае админки (в большинстве речь о главной её странице) рабочих проектов всегда кастомизируются под каждый конкретный случай (если это не делается то значит сайт создаётся только ради того что бы поставить галочку "есть сайт" и он умрёт в сроки очерченные жадностью заказчика на содержание хостинга\домена). Уходя от конкретики и специфики разных сайтов то на главную выводятся или ссылки на часто используемые разделы админки (может быть заменено\продублировано сквозной боковой панелью) или шортлист "последнего" (аля последние комменты\страницы и т.п. чисто для контроля пульса и развития сайта) или наиболее важная статистика (полная статистика находится в отведённых конкретными расширениями или задачами локациях). Во всех трёх вариантах полные наборы находятся уже в отведённых для них местах. Это так, сильно унифицируя очень разные по назначению сайты. Я не говорю что не создаются типовые но живые сайты но видимо этим занимаются другие и вероятно на других движках (не трудно догадатся что основным для меня является кот).

2) Вопрос не понятен с точки зрения кому он задаётся - вебмастеру который создаёт и сопровождает сайт или пользователю для которого он создан. Как бы ответ сильно зависит от категории пользователя к которому он задан. Поскольку здесь сидят вебмастера то их ответы могут идти в разрез ответам тех кто пользуется этими сайтами и под кого кастомизируется админка.

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

#47856 Sergeich:

Мне не нравится внутренняя структура админки Котонти - она где-то избыточно запутана, где-то неочевидна, где-то повторяется. 

Судя по поставленным вопросам претензия больше к главной странице чем ко всей админке и её структуре в целом и исходя из позиционирования "я чайник и плагины писать не умею" то подозреваю что основная жалоба на то что как для чайника готовых плагинов для кастомизации главной админки не хватает !?

Конфиги от всего, что имеет конфиги

Ок, конфиги от модулей и плагинов. Заходим в "Расширения" и снова видим конфиги от модулей и плагинов, заходим в "Разное" и опять кофиги модулей и плагинов. Ещё и на главной админки может быть.

Структура всего, что имеет структуры

Ок, заходим в "Расширения" и снова видим "структуры". Хотя нет, мы видим больше "структур", есть ещё "структуры" у коментов и звёздочек (даже не представляю, что эти "структуры" делают)

Лишние структуры исправятся, а в "Разное" ака "Управление" конфигов нет -- там тулзовые части. Это фича, коих в других движках навалом.

Главная админки кастомизируется от 0 до 100, так что там можно вообще все что угодно.

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

Хотя нет, мы видим больше "структур", есть ещё "структуры" у коментов и звёздочек (даже не представляю, что эти "структуры" делают)

эмм... такие очевидные баги можно сразу на гитхаб в issues.

Конфиги от всего, что имеет конфиги

Ок, конфиги от модулей и плагинов. Заходим в "Расширения" и снова видим конфиги от модулей и плагинов, заходим в "Разное" и опять кофиги модулей и плагинов. Ещё и на главной админки может быть.

Структура всего, что имеет структуры

Ок, заходим в "Расширения" и снова видим "структуры". Хотя нет, мы видим больше "структур", есть ещё "структуры" у коментов и звёздочек (даже не представляю, что эти "структуры" делают)