Syrnik.com

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

Можно после того, как заказ будет создан.

Увы :-(

[`...`] и {_w(...)} аналогичны по действиям. Первое — просто более удобный хелпер для второго.

В шаблонах плагинов, соответственно {_wp(...)} нужно использовать

Искать в шаблонах строку 

[`здесь строка для локализации`]

и менять на 

{_w("здесь строка для локализации")|escape}

Увы, это долго и нудно :(

Ещё и в плагинах такое проделывать

Ну, HEIC вы загнули — поддержки этого кодека ни в gd, ни в imagik нету (кажется)

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

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

В php.ini настроена директива 'open_basedir'. Она разрешает доступ из скриптов только к перечисленным путям. Однако к файлам, которые перечислены в сообщениях об ошибках, фреймворк пытается обратиться по полному пути (либо наоборот по относительному типа ../../LC_MESSAGES...) и он не подпадает в список разрешённых. 

Ошибки о том, что не удалось получить доступ к файлам локализации (бОльшей частью) ил-за ограничений в директиве open_basedir

интернет-магазин и производство чего-либо по индивидуальному заказу — это всё же разные вещи.

Получать объект плагина shopMyPlugin надо как-то так

$plugin=wa('shop')->getPlugin('my');

shopMyRun.cli.php должен быть отнаследован от waCliController и реализовывать метод execute()

Ну и запускать его нужно

php cli.php shop myRun

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

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

Атрибут-то я уберу, но осадочек останется. При переделке редактирования заказа под UI2 надо бы как-то учитывать такую ситуацию.

А смысл? Там всего один вариант. Т.е. этот контрол всегда должен показываться. `customFieldsForService` имел бы смысл, если бы плагин выдавал несколько вариантов и контрол надо показывать для одного варианта, и не показывать для другого.

Это ладно. Вот зачем ВА группирует по значению сортировки (cp1.sort) -- никак не могу сообразить.

Есть идеи о том, что делать дальше?

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

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

Мы видим, что Shop-Script меняется и развивается. Да, большие изменения происходят не каждый год, но мы всё равно продляем подписку и убеждаем делать это наших клиентов, т.к. понимаем, что внедрение серьезных изменений может потребовать длительного периода. И добавление дробных+ед.измерения уже оплачены авансом, по подписке.

Что произойдет, если мы включим каждому продукту возможность делать обновления платными? Разумеется, подавляющее большинство разработчиков их включит. Почему бы нет, если это просто легкие дополнительные деньги? Куда же проще — поставить галочку в свойствах продукта. Но как увидит это пользователь, который купил ранее несколько плагинов и тем (а у нас есть пользователи, у которых несколько десятков и даже более сотни купленных плагинов!)? Очевидно, он будет поставлен перед фактом, что теперь он вынужден дополнительно платить некоторую (с учетом количества покупок — ощутимую!) сумму, чтобы продолжить нормально работать. Какие обновления? Тут нет никаких гарантий, что вообще продукты будут продолжать обновляться. Какие-то будут, какие-то нет — это неизбежно.

Есть 2 варианта.

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

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

Вместо этого нам предлагают распространить схему «Либо аренда, либо вечная лицензия» на плагины. Зачем? Это невыгодно. При аренде пользователь платит примерно треть (по сложившейся практике), но в случае прекращения аренды теряет вообще всё. Либо он покупает «вечную лицензию» по довольно высокой цене, в которую заложены и расходы на поддержку, и будущие обновления. При этом схема работает только при кратном увеличении аудитории. Нынешняя схема уже не позволяет запустить быстро и недорого микро-магазин, требуя серьезных финансовых вложений, отсекая от Shop-Script значительную аудиторию, традиционную для Shop-Script.

Ещё предлагается «выпустить другой продукт» вместо платного обновления. Это означает, что всем клиентам надо будет не просто доплатить (или заплатить повторно), это значит, что клиентам нужно будет заново установить и настроить в то время, как многие конфигурации годами живут будучи настроены один раз. Это вообще не решение.

Есть и технические трудности для Инсталлера. Нужно обеспечить возможность для пользователей установить ту версию, которую он оплатил. А в идеале так и получить хотфикс к ней — помните, что ВА теоретически обещал фиксы безопасности к старым версиям Shop-Script? Ну ладно. Хотя бы возможность получить оплаченное. Случаи разные бывают, случается и требуется установка с нуля.

"Покупка навсегда" vs "Аренда на год" это немного не то. 

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

Как у phpStorm. Даже если я не оплатил продление обновлений, лицензия у меня остаётся и я всегда могу загрузить версию ту, что я оплатил. 

Поддерживаю забастовку Евгения

Есть ещё предложение.

В честь выхода новой мажорной версии Shop-Script увеличить минимальную требуемую версию PHP до 8.1

Про "приоритетное размещение в каталоге понятно".

Проверка и доработка существующих продуктов могут потребовать серьезных затрат времени и сил. Когда будет возможность выпускать платные обновления плагинов либо подписка на их обновления?

Если плагин поддерживает все функции "Премиум", то владельцы "Про" будут переплачивать за функционал плагина, которым никогда пользоваться не будут. Когда будет возможность публиковать разные "редакции" плагина для разных типов лицензий? Теоретически и сейчас можно делать два разных продукта, но было бы желательно иметь возможность из хотя бы на карточке продукта в маркете объединять. А также за доплату мигрировать с "плагина про" на "плагин премиум".

плагин экспорта будет создавать файл экспорта для конкретного профиля. в профиле выбрана одна витрина. 100 профилей -- 100 запусков экспорта с указанием ID профиля. Нет?

конечно нет, не должны

Это потому, что настройки в бд хранятся в json. и когда они из бд считываются, то декодируются. ну и ваш сохранённый текст тоже декодируется. когда мне припёрло, я перед сохранением добавлял к строке с json префикс типа "_#webasyst-bugfix#_", а после чтения его отрезал.

Наш с тобой сео-гуру вообще считает, что многоартикульные товары зло и надо по-любому создавать отдельные карточки товара ;-)

Да и размер должен бы выглядеть как «60×50×40 мм.», а не с единицами измерения у каждого значения.

Проверка вовсе не формальность, зря ты так.

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

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

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

Вы точно посчитали всё или только первый абзац и пример?

Обычная OAuth 2.0 авторизация, как везде

Открываtте в редакторе файл wa-config/SystemConfig.php и дописываете нужные директивы. Перед этим неплохо посмотреть про функцию ini_set (https://www.php.net/ini_set )

Ну или поставьте бесплатное приложение Логи и включите логирование ошибок php. Приложение нужные команды само добавит