getbootstrap.com/customize/ Поменять @grid-columns на 15 и все.

А не проще ли это было встроенными средствами TB сделать? Там как бы это все переменными в less файлах можно задать и все будет работать полностью на стандартном коде и без всяких костыльных файлов

Замечание принято. Постараюсь быстренько исправиться)

А что помешало верстку поправить перед тем как в продакшн выкладывать?

А что на github-то не выложишь? Хочется посмотреть, а скачивать себе не хочется) Да и найти потом проще будет, когда понадобится.

больше документации с примерами, а не «вон там посмотрите» или «скачайте и разбирайтесь»

Это какие, интересно? У MODX уже есть документы, пользователи, права доступа. Нужно что-то еще?

Блоги, топики, комментарии и т.п. Хорошо, ты можешь сказать, что это все расширенные ресурсы. ОК. Комментарии как минимум — не расширенные ресурсы. А они здесь необходимы.
Но не будем придираться к словам.

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

Мило.

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

Вот как-то так. Мы и пишем. Что-то уже готовое берем, а что-то дописываем. Это нормально. Зато управляемость 100%.

На счет политик. Понял. Спасибо.

Самое главное отличие — это работа, основанная не на использовании чанков/сниппетов, а на процессорах+Smarty

Окей.

В MODX-е не хватает базовых сущностей для реализации блого-социальных проектов. modSociety их добавляет.

Это какие, интересно? У MODX уже есть документы, пользователи, права доступа. Нужно что-то еще?

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

Мило.

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

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

Например, у нас в магазине есть техподдержка, и там всё чётко разделено: админ видит все тикеты и комменты, автор дополнения только темы по своим дополнениям, а покупатель — только то, что сам написал. Задать вопрос можно только по тому дополнению, что купил.

Всё нужное для этого у MODX уже есть, не знаю, каких сущностей может не хватать.

реализуется ли у тебя механизм проверки прав на комментарии на уровне политик безопасности MODX-а, или как

Комментарии не бывают сами по себе, они к чему-то привязаны: к ресурсу, товару, или фотографии. Я ограничиваю права на эти объекты, а не на сами комментарии.

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

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

Например, на моём сайте ты не увидишь комментариев из тех платных курсов у юзера на странице.

На этот вопрос лучше отвечу я.
1. Самое главное отличие — это работа, основанная не на использовании чанков/сниппетов, а на процессорах+Smarty. Собственно, большинство наших компонентов основывается на этом. Я сейчас не говорю о том, что чанки — плохо. Я просто говорю о принципиальном отличии.
2. Справедливости ради конечно же имеет смысл сказать, что Tickets «из коробки» имеет значительно больше. modSociety — это только расширение ядра MODX-а. В MODX-е не хватает базовых сущностей для реализации блого-социальных проектов. modSociety их добавляет. Но это только ядро. Конечный проект однозначно придется дописывать самому. Как уже говорила Даша выше, в процессе мы как раз и будем описывать задачи, с которыми будем сталкиваться, и описывать как мы их решали. Это даст больше понимания что и как здесь выполняется.
3. Безопасность и логика. В новой версии нашего сайта мы ставили перед собой задачу реализовать поддержку блогов и топиков с различными уровнями доступов. То есть чтобы любой мог создать свой блог, и определить кто какие права будет на него иметь. Эту задачу мы успешно реализуем. К примеру, в списке всех комментариев у каждого пользователя выводятся только те комментарии, которые он имеет право читать. Вот тут как раз к тебе вопрос: реализуется ли у тебя механизм проверки прав на комментарии на уровне политик безопасности MODX-а, или как? Реально интересно. В процессоре получения комментариев я не увидел никаких проверок прав.

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

Интересно, какие принципиальные отличия есть у modSociety по сравнению с Tickets?

Понял, спасибо!

А не вариант было сначала доделать, а потом презентовать?
Ливстрит давал представление о том, что делает ваше сообщество (клуб), а собственный ваш модуль не дает даже представления что он может, не говоря что ваш сайт, на вашем модуле, (вот именно сейчас) буквально, превратился в нечто несуразное, после понятного и легко читаемого.
Удачи, однако:)

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

Да мы не соревнуемся, просто это факт: 4 дня. Вот и все. Компонент, когда полностью допилим, будет отдан в массы. Если есть вопросы/пожелания по компоненту — мы открыты к такого рода дискуссиям.

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

ништяк

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

Да, сайт пока очень ограниченный, НО: он создан за 4 дня с нуля, не считая контент со старого сайта ;).

а вот на это мне, как и наверное большинству — все равно, вы продукт делаете, а не соревнуетесь с кем-то в скорости.

Мы не агитируем никого) Вы вправе сидеть где нравится, мы же просто на примере показываем, как работает modSociety.

Четким пацанам тут ништяк.

Оживлю тему.
В общем условия такие:
если:
— адрес не содержит «sitename.ru/*.*» (т.е. в конце адреса *.html или *.jpg или еще какое-то расширение)
и
— в конце адреса нет слеша
и
— адрес не содержит «sitename.ru/manager*»
и
— это не главная страница (sitename.ru)
то добавлять в конец адреса слеш.

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

На самом деле, за сематическое ядро стоит браться еще до начала создания самого сайта.

Постараюсь пояснить:
1. Собираем ядро и узнаем, что к нам должны ходить не только по названиям фильмов, но и по жанрам, актерам, рецензиям и т.д.
2. На основе этой информации мы создаем посадочные страницы, то есть те страницы которые отвечают некой группе запросов из нашего ядра, давая развернутый ответ на запрос пользователя.
3. Формируем всю структуру сайта исходя из набора посадочных страниц.
4. И только после этого начинаем думать как нам избежать ошибок, приведенных Алексеем Карташовым при сформированной структуре.

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

Ну тут, наверное, всё понятно — на киносайты народ ходит по названиям фильмов.

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