Мы начинаем большую работу по переработке визуальной части комплектаций.
Все изменения коснуться закладки "Комплектации" в карточке товаров в административной панели. В основном изменения будут полезны тем, кто использует большое число комплектаций.

"Новые комплектации" получат следующие возможности:

• Отображение списка комплектаций постранично с возможностью указать размер страницы. Это позволит очень значительно ускорить время открытия карточки редактирования товара в случае, если комплектаций 500 и выше.
• Фильтр комплектаций. Комплектации можно будет отфильтровать прямо в карточке товаров.
• Групповое редактирование комплектаций в рамках товара.
• Визуально будет компактный список комплектаций. Только одна комплектация будет редактироваться в одно время, для этого нужно будет кликнуть по ней.
• Значительно будет облегчен JavaScript, обслуживающий карточку товара.
• Количество переменных уходящих на сервер будет очень значительно снижено.
• Для разработчиков: Объект комплектации можно будет расширять аналогично любому другому ORM-объекту в системе и все изменения будут отражаться в форме редактирования комплектации

В связи со скорыми введением 54-ФЗ для интернет-магазинов неплохим решение была бы интеграция с NextPay. В данном случае нет необходимости в кассе, так как средства от клиентов приходят обычным безналичным платежом с полной суммой перевода. NextPay, в отличии от формы приема платежей Яндекс, делает оповещение интернет магазину о совершенном платеже.
Не все клиенты готовы сейчас интегрировать онлайн-кассы. Особенно это касается тех, кто впервые открывает интернет-магазин.

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

Необходимо экспортировать в csv товары, а именно чтобы было Название - Полный УРЛ (сайт-категория-товар), сейчас же почему-то экспортируется неполный УРЛ, так как с большими объёмами работа идет с помощью exel и программы Директ Командер

У russianpostcalc.ru есть API для печати форм для нужд Почты России.

Отправляем туда запрос с параметрами, в ответ получаем ссылку на pdf файл.

Подробная информация по API: http://russianpostcalc.ru/api-devel.php
Основная форма, которая всем требуется, Ф116.

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

Скрин результата работающего примера прицеплен.

Яндекс доставка обновила апи, и сильно толкает продукт как доставку для интернет магазинов,
с учетом того что Озон-доставка закрывается,
а цены у яндекс доставки низкие
это было бы хорошей альтернативой почте и озону

https://dostavka.yandex.ru/integrations/ecommerce/

Здравствуйте, столкнулся с тем, что нужно добавить дополнительное поле в Orm объект catalog-product. Для этого у API есть событие orm.init.КОРОТКОЕ_ИМЯ_ORM_ОБЪЕКТА. Однако в базе поле хранится в сериализованом виде, а для работы с объектом product его нужно обратно преобразовать в массив. Отсюда и необходимость в дополнительном событии по типу orm.afterobjectload.КОРОТКОЕ_ИМЯ_ORM_ОБЪЕКТА. Тем более у RS::ORM::AbstractObject есть такой метод. Будет достаточно в этом классе сгенерировать новое событие. Например так:

public function afterObjectLoad()
{
/**
* Event: orm.afterobjectload
* paramtype \RS\Orm\AbstractObject
*/
\RS\Event\Manager::fire('orm.afterobjectload.' . $this->getShortAlias(), $this);
}


И во всех потомках этого класса в методе afterObjectLoad (если он там переопределен) вызывать:
parent::afterObjectLoad()

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

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

Пожелание пишу, так как проблема, на самом деле, серьёзная, а в тикет системе получил ответ "В данный момент такая функциональность не ожидается".

Когда мы создаём алиасы (оно же URL-имя) для товаров, брендов, категорий, задействуется функция \RS\Helper\Transliteration
Когда мы вручную из карточки создаём алиас, работает js /resource/js/jquery.rs.autotranslit.js
И всё вроде хорошо, пока кириллица и латиница присутствует.
Но бренд "Baumüller" превращается в "baum-ller"
Косяк? Да. Подобных брендов навалом. Если делать интернет-магазин двуязычным, нарваться на названия категорий и товаров элементарно. Даже, если просто парсить, отследить наличие всяких умляутов и прочих диакритических символов нереально.

Проблема тут в том, что RS не знает о таких символах. И ставит вместо них дефис. А ставить надо ближайший латинский символ.
Реализовать подобное очень просто, я не понимаю, почему это вдруг "такая функциональность не ожидается".

Вот эти символы. Полный список.
¡¿
ÄäÀàÁáÂâÃãÅåǍǎĄąĂăÆæĀā
ÇçĆćĈĉČč
ĎđĐďð
ÈèÉéÊêËëĚěĘęĖėĒē
ĜĝĢģĞğ
Ĥĥ
ÌìÍíÎîÏïıĪīĮį
Ĵĵ
Ķķ
ĹĺĻļŁłĽľ
ÑñŃńŇňŅņ
ÖöÒòÓóÔôÕõŐőØøŒœ
ŔŕŘř
ẞߌśŜŝŞşŠšȘș
ŤťŢţÞþȚț
ÜüÙùÚúÛûŰűŨũŲųŮůŪū
Ŵŵ
ÝýŸÿŶŷ
ŹźŽžŻż

p.s. я понимаю, что мультиязычности по факту нет, но мультисайтовость есть и вот официальная позиция по этому поводу
https://helpdesk.readyscript.ru/wish/Podklyuchenie-vtorogo-yazyka-13.html

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