Іван Клімчук

Я вот так и не смог воспроизвести. Все ок работает. Проверяйте браузер и расширения/плагины в нем, может какое расширение лишние классы навешивает?
В коде тоже все верно, там ничего менять не нужно. form.find('.error').html(''); выполняется для спана с текстом ошибки, а не для самого элемента.

расширение php_curl установлено?

Почитайте эту заметку документации rtfm.modx.com/revolution/2.x/case-studies-and-tutorials/developing-an-extra-in-modx-revolution/developing-an-extra-in-modx-revolution,-part-ii

У вас есть доказательства, что разработчики vk украли исходные коды facebook? Я думаю, что нет. То, что они скопировали бизнес-модель и сумели ее развить в России к исходному коду никак не относится, о чем я и говорил. Они нашли правильных людей на нужные позиции и построили правильный бизнес-процесс, который позволил вырасти и отхватить долю рынка.
Т.е. тут даже масштабы другие, а топикстартер говорил вообще про админа или разработчика со стороны, которому на самом деле нафиг сдался какой-то очередной сайт заказчика, где и красть-то по сути нечего (не в обиду Виталию сказано, но на деле сайты заказчиков как правило однотипные и редко что-то выдающееся там пишется).

Для начала есть понятие имущественных и не имущественных прав на результаты интеллектуального труда. Если работать по договору, то как правило заказчику передаются имущественные права (права на использование, воспроизведение, тиражирование, продажу), если иное не указано в договоре. Автором вы остаетесь всегда, как человек, который создал такое произведение. Поэтому проблем не вижу. Вы работу сделали, деньги получили, результат труда передали. Если хотите, чтобы сайт был вашим, тогда сдавайте сайт в аренду (но не везде это возможно, в Беларуси законодательная база не подходит, например). Либо сейчас популярно, когда делают сайт по определенной теме, продвигают его и прочее, а заказчикам продают «лидов» или покупателей, если по-русски.
Еще вариант — ваши наработки оформлять в отдельные пакеты, которые продавать отдельно через modstore.pro или свой репозиторий, либо просто в договоре указывать, что эти пакеты оплачиваются отдельно, на каждый пакет своя уникальная лицензия.
Что касается копирования, то я не вижу никакой проблемы абсолютно. Я не помню случаев, чтобы кто-то успешно скопировал facebook или vk или любой другой успешный сервис и на нем заработал миллионы бабла. Так как в чистом виде исходный код мало несет ценности, нужные еще и бизнес-процессы.

Вероятно проблема не в MODX, а в самом редакторе. Недавно у меня была проблема с TypoMCE, который не сохранял значения в ClientConfig, замена редактора решила проблему.

Оставлю свое мнение, но оно автору не понравится. Оно конечно похвально, что автор постарался и таки решил проблему (хоть и частично), но с кучей условий и ограничений, что в реальном мире выглядит как что-то, подпретое костылями, чтобы хоть как-то работало. Очень важно для решаемой задачи в самом начале подобрать правильные инструменты, чтобы еще на старте максимально уменьшить технический долг. Первым звоночом стала фраза про использование Tickets, потому что очень нравится этот компонент. А нужно было сделать нормальный анализ задачи и подумать, что какой компонент может, а что нет. Для задачи краудфантинга не подходит ни тикетс, ни miniShop, даже если их пытаться как-то объединять. Решение здесь одно — нормально спроектировать структуры данных (т.е. таблицы и из связи) для решаемой задачи и оформить это в виде отдельного компонента, который будет работать так, как ожидается, его можно будет легко дорабатывать и он будет независим от обновлений тикетс и минишоп, которые могут все сломать в любой момент, потому что автор этих дополнений ждет, что их используют по назначению, а не в каких-то изощренных схемах. Как я и говорил, мое мнение не понравится автору. Так вот, будущего в этом проекте я не вижу. На старте все здорово, но через какое-то время сложность и стоимость (время) поддержки всего количества «костылей» настолько превысит рентабельность, что ни у кого не будет желания этим заниматься.

PHP 7 в официальных репозиториях только в последней Ubuntu 16.04 LTS появился, так что просто так поставить не получится. Но можно использовать launchpad и поставить отсюда launchpad.net/~ondrej/+archive/ubuntu/php
Как ставить и настраивать придется разбираться, туториалов на деле хватает. Если не хватает знаний и есть важные сайты, лучше обратиться за помощью к знающим людям.

Так делай :) Делов то

Установкой одного компонента проблему не решить, будь он написан хоть самим богом. Задачу нужно решать с инженерным подходом: искать по порядку слабые места и bottleneck-и и закрывать постепенно проблемы. Несколько десятков тысяч статей и 3k уников в сутки — это детская нагрузка на самом деле. Верно посоветовали заменить apache на nginx и настроить правильно отдачу статики (+кеширование). Для старых статей можете попробовать подключить кешер Varnish (c MODX пока его не дружил, но апи вроде как удобное). Minishop2 ставить ради интеграций смысла не вижу, так как он для других целей и в вашем случае там в плагинах будет делаться бесполезная работа, которая создаст лишнюю нагрузку.
Если касаться тех же тикест, то там все довольно оптимизировано, но можно выпилить отдельные куски или потимизировать. С обновлением пакета конечно потом могут быть сложности, но я еще не встречал хорошо работающего высоконагруженного проекта со стоковым набором плагинов. Обычно что-то допиливается и потимизируется под себя.

Ну так ошибки ж там не просто так, нужно чинить то, что там пишет.

Подскажите где стоит покопаться и на что смотреть)

Вот прямо там в логе и написано где копаться и что чинить.

Можете взять за основу мой Slackify и на базе него сделать подобный пакет. Идея примерно такая же, только на Slack

По первому абзацу отвечу. Таких готовых решений не будет никогда. А если что-то и будет, то оно вам с долей вероятности в 90% не подойдет. Потому что такие кабинеты строятся, как правило, под нужды конкретного заказчика и под его процессы и сделать универсальный компонент для этих целей почти невозможно. Либо настолько сложно и труднозатратно, что экономически нецелесообразно. Ибо, как я уже написал выше, подойдет от силы 10% заказчиков и то не факт.

Как и любой кешер — это дает прирост скорости.

Дело ж не в самой проблеме, а в ресурсах, затраченных на ее решение. Я без проблем напишу подобные запросы, если будет нужно, но ведь можно разобраться в проблеме и решить ее кардинально и один раз. За решение большое спасибо, между прочим.

Идеальный сферический сайт в вакууме мне еще не встречался :) А на деле зачастую сайт нужен вчера и как можно быстрее, потому иногда случается.

24 чанка, фига ты крутой! Я вот, например, так не умею и сам постоянно меняю уже готовые чанки.

Ну так а документация и исходники на кой черт тогда? Зато я меньше глупых вопросов задаю :)

Решение:
UPDATE modx_site_content SET content = '' WHERE class_key = 'msCategory';

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

Я вредный пользователь, да, ну и не новичок. Чанки пишу по памяти и заготовки не использую, так как все равно потом почти всегда переписываю, потому что мне не нравится реализация ))

Про tickets знаю, но я им реже пользуюсь, потому пока не наболело.

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

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

Ну и напоследок,

Универсально, это тянуть 2 пакета вместо одного и усложнять установку.

в новых версиях MODX это 1 строчка в конфиге зависимостей

Я бы пометил эту фичу как deprecated и выпилил бы через релиз. Как промежуточный вариант — оставил бы возможность выставить настройку в empty при установке. Понятно, что обратную совместимость ломать не хочется и жалобы будут, да, но раз системно все переписывается, хотелось бы стройности во всем. Как фича — это да, удобно для новичков на старте, но не универсально.
Развивая мысль, можно было бы вынести оформление магазина в отдельный пакет, а в самом miniShop оставить голое ядро и учитывая, что с 2.4 версии есть возможность указывать зависимости, ставить пакет оформления по умолчанию, но при этом давать возможноть отказаться от него. В таком случае в пакете оформления можно было бы реализовать полценный демо-магазин (аля сборка) для желающих посмотреть, а как оно что работает.
Для конечно пользователя все остается так же — установил одной кнопкой, открыл сайт — о! магазин работает.
Для сайтоделов, вроде меня и других — при установке снял галку и голова не болит, делаешь что нужно и лишнего на сайте ничего нет.

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