Дам сразу наводку - ни одна cms не может сдеать такую мультиязычность, как джумла. У всех это будут нереальные кастыли, дубли и падения, т.к. никто это не тянет в коробке. А те кто тянут (привет, битрикс!) сделали это через жопу

да все, вопрос снят, извините. А так да, у меня 82 джумшоп и 88 опекарт, без сжатия пока, из коробки

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

ну по сути это урл. Второй язык нужен формально, украина понимаетели )

ВП вообще для такого нужно кастыльные плагины доставлять

ВП вообще для такого нужно кастыльные плагины доставлять

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

Вот дядька очень неплохо рассказал https://zaurmag.ru/joomla/multiyazychnost-v-joomla3-kak-sdelat-multiyazychnyj-sajt-na-joomla.html

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

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

просто у нас будет своё решение в ближайшее время

Хм. Как скоро? Сколько стоит?

На счёт object не скажу, а так values может принять массив Либо вызвать много раз сам values. Например, создать объект запроса, потом в цикле много раз values ему передать, а за циклом выполнить. И, не знаю, почему Дима считает, что это будут разные запросы, т.к с формируется 1 sql запрос на insert и будет передан в СУБД. А уж как там СУБД разбирается с многострочной вставкой, я не скажу

все кто начнёт делать сайты во время бета теста - получат бесплатно

готов попробовать! Да, еще может быть вопрос по разделам, в самой джумле нельзя привязать к нескольким разделам. Но то такое

готов попробовать! Да, еще может быть вопрос по разделам, в самой джумле нельзя привязать к нескольким разделам. Но то такое

пиши после праздников

Спасибо, Артем 👍 Это как раз то, что меня интересовало. Ещё бы по вставке через объекты понять. Может и с этим что-то предусмотрели.

Собрать пул из инсертов и потом запушить их одним коммитом в базу

я просто не понимаю, зачем юзать объекты для запросов, если в них нет гибкости

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

А зачем покупка без регистрации?

когда у тебя вход и регистриаця одна форма

то что ты пишешь - это вот

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

ну да

Палево =)

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

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

Спасибо, Артем 👍 Это как раз то, что меня интересовало. Ещё бы по вставке через объекты понять. Может и с этим что-то предусмотрели.

База все равно будет выполнять по срочно. А подключение не создаёт много нагрузки. Так что разница между 1 000 000 отдельных запросов и 1 000 000 в одном запросе минимальна. Более того при вставке отдельными запросами будет надёжнее.

Проверю это в текущих реалиях )

А. Ну тобишь на самом деле она с регистрацией =)

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

Ну вот об этом я и думаю

А не проще ли в чекауте при нажатии на оформить спросить зарегатьчя или авторизоваться. Ибо связь по email или телефону не обязательно будет совпадать. К примеру оформил заказ на кого-то из домашних кому будет проще забрать

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

А. Ну тобишь на самом деле она с регистрацией =)

Возможно, вы уже знаете об этом, но я все равно напишу: Проверять свои composer зависимости на предмет известных уязвимостей можно просто добавив в dev зависимости пакет: composer require --dev roave/security-advisories:dev-latest Это простой metapackage, в котором в директиве conflict описаны известные версии библиотек с уязвимостями. Т.е. при попытке установить пакет с уязвимостью вы получите ошибку на уровне composer require. Ссылка на github: https://github.com/Roave/SecurityAdvisories