Если кто не в курсе, то Etomite была создана в Нидерландах, так что у них есть кое-какие исторические права на MODX =)

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

Лет 10 назад я бы просто поступил как Василий, начал бы писать свой магазин и выложил бы его на Гитхаб. Он бы не был лучше или хуже, просто был бы другой подход, который кому-то может и понравился. Но сейчас, к сожалению, я так не могу поступить по ряду причин

МОДЕКС классная система, но рано или поздно (по мере собственного развития в профессии) понимаешь, что её возможности ограничены, и становишься перед выбором: пытаться расширить эти возможности, потратив время, ресурсы итд (которого не так много, когда нужно кормить семью), или найти готовое решение в других CMS, CMF итд.

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

МОДЕКС классная система, но рано или поздно (по мере собственного развития в профессии) понимаешь, что её возможности ограничены, и становишься перед выбором: пытаться расширить эти возможности, потратив время, ресурсы итд (которого не так много, когда нужно кормить семью), или найти готовое решение в других CMS, CMF итд.

@bezumkin а modstore.pro мултиязычность babel?

Ну так это обычный подход потребителя, при этом с неограниченным ЧСВ касаемо запросов к разработчикам. У вас этого нет, значит система говно, пойду делать на том, что знаю. А чтобы было круто, нужно добавить то, что я уже знаю, иначе не торт. Но сам добавлять ничего не буду, времени нет и вообще семью кормить нужно. Отговорки за 10 лет не меняются. И не только в MODX. Мне и Васе тоже семью кормить нужно, но как-то не жалуемся. Так что не нужно винить разработчиков, а начать с себя.

Через контексты, но всё управляется своими собственными процессорами, которые влю логику работы берут на себя

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

Просто тикетс, сендекс выплал, прям мультиязычность напрашивается 😉😊

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

я об этом думал, но ничего хорошего не придумал, увы

а как насчёт моего поста про мультиязычность через сериализацию в полях? это реально?

а как насчёт моего поста про мультиязычность через сериализацию в полях? это реально?

МОДЕКС классная система, но рано или поздно (по мере собственного развития в профессии) понимаешь, что её возможности ограничены, и становишься перед выбором: пытаться расширить эти возможности, потратив время, ресурсы итд (которого не так много, когда нужно кормить семью), или найти готовое решение в других CMS, CMF итд.

Ну поля в БД текстовые, через LIKE или MATCH

В смысле, прямо по сериализации через LIKE искать? Мне кажется, это несерьёзно как-то

Как ты найдешь совпадения по английскому варианту pagetitle и longtitle, но исключишь по description или alias?

https://modstore.pro/packages/utilities/localizator

Поиск по отдельным полям БД как обычно, а на уровне PHP уже фильтровать из результата нужный язык

Как мне найти bla именно в longtitle?

Смысл такой: в поле pagetitle сохранено не "бла бла титул, а "{'ru': 'бла бла титул', 'en': 'bla bla title'}"

В базе в ТВ есть поле ЗНАЧЕНИЕ, вот там хранить не одну строку значения на русском, например, а строку в виде JSON массива, как и для полей ресурсов. Какая разница, всё равно поля в базе все текстовые

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

Учитывая, что нужно переписать в MODX вообще всё - так себе преимущество, на мой взгляд

В базе в ТВ есть поле ЗНАЧЕНИЕ, вот там хранить не одну строку значения на русском, например, а строку в виде JSON массива, как и для полей ресурсов. Какая разница, всё равно поля в базе все текстовые

В вашем случае, чтобы отстоять свое мнение - стоит сделать прототип и продемонстировать его работоспособность

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