Иван Климчук

У меня нет ответа на этот вопрос, я не зацикливаюсь на конкретных инструментах. При случае, если так будет быстрее/дешевле/удобнее, выберу MODX без зазрений совести. Лично я собираюсь развиваться в сторону управления людьми — Team Lead с перспективой CTO (это другие навыки, не код). Относительно кода — предпочитаю PHP+Golang.

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

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

Wat? Какие еще твиги?

Что именно? Гугл, насколько я знаю, в России еще не банили, можно воспользоваться. Но касательно ваших выпадов в заметке, все еще хуже, чем с fenom, вам не понравится.

Более того, в 3 версии пока без изменений, но будущие версии MODX будут использовать twig в качестве основного шаблонизатора. Хотите кататься на паровозах, пожалуйста, но прогресс тормозить лично я не позволю, будучи одним из разработчиков системы.

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

Вас никто не заставляет.

Я исхожу из того, что у вас описано в вопросе, что у вас там еще накручено дополнительно, я не знаю и знать не могу, поэтому это уже вам решать. Написано было, что количество задается метрами, без всяких count. А следовательно можно купить либо 0.5 м либо 1.5 метра. Это дроби, но ничего не мешает указывать в поле количество сантиметры, как и цену выставить за сантиметр, тогда вообще ничего менять не нужно, кроме форматирования на сайте (там да, нужно будет цифры разделить на 100, цену — уможить на 100).

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

Так вот со Stripe и беда, потому что они дают просто виджет на JS, который нужно впиндюрить на свой сайт, а там хоть и iframe, снифать не проблема ввод с клавы. В случае перехода на защищенную страницу такой проблемы нет.

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

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

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

Честно отвечаю — не знаю.

Вопрос был не в сравнении MODX с Laravel. MODX однозначно проигрывает Laravel по организации кода, но сама архитектура и подходы в Laravel спорные даже по сравнению с той же Symfony. Laravel модный и в меру простой для «пользователя», но не лучший, имхо.

На всякий случай уточнить — это сарказм или нет? :) А то сложно распознать, тем более ссылка тоже особенная, но к счастью ее хотя бы можно объяснить.

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

Самое простое — написать хук для formit (он вызывается внутри ajaxform), который будет собирать данные и делать с ними что угодно и слать куда угодно.

Форкайте, я не готов взять на себя такую ответственность. И другие тоже. Это на словах легко.