1. Скрыть товар
2. В настройках каталога товаров - Отдавать 404 ответ сервера у скрытых товаров?
Тогда их в каталоге не будет, а по прямой ссылке карточка откроется.

Но вообще мы уже давно делали так - если даже остатки не учитываются, всем товарам ставим 9999, если товар снимается с производства, остаток 0. А в шаблоне - если остаток 0, под заказ или иной текст и подсказки. Можно скрыть цену, вообще кнопку заказа убрать и т.п. От ситуации зависит.
Также можно привязать ко всем товарам характеристику "снято с производства" и во всех шаблонах поставить условие отображения элементов. Но это совсем старый способ, имхо.

Ярослав пишет:

Поддерживаю Константина. Сейчас все магазины друг на друга похожи

Ога

https://www.citilink.ru/
https://www.eldorado.ru/
https://www.mvideo.ru/
https://www.svyaznoy.ru/
https://euroset.ru/
https://www.wildberries.ru/
https://www.lamoda.ru/
и на сладкое
https://www.nix.ru/

Это я даже не парился, первые на ум пришедшие вбил. Где тут похожее?
Ну да, компоновка более-менее, но всё остальное, стили, мелочи, слайдеры и так далее. Вы вообще о чём?

Элементарно. Покупаете хостинг, запрашиваете бекап с облака и разворачиваете его на вашем хостинге. Дел на 10 минут.

179

(13 ответов, оставленных в Вопросы по работе с системой)

Daniel пишет:

попробуйте пойти по моему пути

Пробовать можно, но иногда вы получите чёта типа

https://mediatemple.zendesk.com/hc/article_attachments/202382660/500ise.jpg
https://user-images.githubusercontent.com/19474557/42318259-06719a20-8081-11e8-9027-1a9c0f09c231.png

(не буду картинкой втыкать)
Это те моменты, когда ошибка возникла до того, как её смог обработать RS.
И тогда ваш способ через _local_settings.php ничем не поможет.

А я на этом форуме постоянно предлагаю всем смотреть в корень, а не скакать по верхушкам.
Знаете, есть такая штука - бороться с причинами проблем, а не со следствием. Так и тут, я предлагаю смотреть на уровень ниже, а именно в /var/log, а именно в /var/log/php - если настроили, конечно.

Да, и ещё. Если отображать подробные ошибки в _local_settings.php, вы потеряете красивую страничку 404.

Вот, сегодня "ошибка передачи данных" при попытке добавить пользователя в RS, установленном неделю назад, куда я полез? Конечно в
/var/log/php/php-errors.log
а там картина маслом

[30-Apr-2019 20:09:13 Europe/Moscow] PHP Fatal error:  Cannot use Shop\Model\Orm\Reservation as Reservation because the name is already in use in /var/www-dev/***/modules/shop/model/notice/supplytouser.inc.php on line 9

Константин, пусть разработчики занимаются разработкой, а темы дизайна - это лишнее. Или вы хотите, чтобы получилось как у битрикса? Куда ни плюнь, если на битриксе, то 90% немного переделанный шаблон. Или вообще тупо шаблон.
Если хочется особой темы, закажите у нас или коллег разработку, это не так дорого стоит подвернуть флетлайнс под хотелки заказчика.

Ридискрипт тем и хорош, что внутри прекрасен - при этом постоянно внутри улучшается. Чего стоит только последнее обновление, когда каталог причесали - вообще огонь! Я такого второго движка не знаю, хотя знаю их десятки.

Ярослав пишет:

Потому что взломав сайт можно получить доступ к базе, что не есть хорошо для безопасности.
Я до создания сайтов на RS (спасибо Набиуллина) занимался Oracle, АБС Банк XXI век и интеграцией с процессингом пластиковых карт.  Если бы я дал доступ к базе извне, меня бы уволили, может бы и дело завели. Как минимум можно за DDOS-ить  запросами к базе.

А если база прямо тут лежит, че, типа сильно лучше?
ТС что предлагает? Как RSом подключаться к mssql.

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

Если "взломав сайт", то получаешь доступ ко всему, куда имеет доступ пользователь, который крутит сайт. Логично, что ппц. И какая тут база будет - внешняя, внутренняя или под кучей проверок - пофиг, поимеешь доступ ко всему.

Ярослав пишет:

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

Это ещё почему? Ограничение по айпи на уровне mysql и чем-то типа iptables закрыт порт для всех, кому не положено.

Ярослав пишет:

Для каталога товаров в 10 000 позиций я делал выгрузку в csv файл каждый 5 минут, затягивал его в таблицу средствами Mysql LOAD DATA INFILE (это встроенный механизм MySQL для загрузки больших объемов данных.). Затем скриптом обновлял остатки и цены. Этот метод работает молниеносно.  Временная таблица создается в доли секунды.
В моем случае скрипт загрузки вызывался внешней системой, но можно и cron у RS использовать.
Можно хоть раз в минуту выгружать. Фактически остатки и цены будут синхронизированы в режиме реального времени.

Похожим образом на вордпрессе цены обновляют smile и товары загружают. Там толком механизмов встроенных нет.
Однако, 5 минут - это не есть режим реального времени.
Реального времени - это при загрузке страницы идёт куда-то запрос, где данные актуальные.

Хотите пример подобного велосипеда, где данные через джонсик прилетают на страницу? И там не только цены, там весь каталог прилетает.

https://rs24.ru/catalog.htm

Явно у них внутри какой-то динозавр типа оракла всё крутит и ничего умнее придумать не смогли.
И ещё монстрик

https://b2b.el-com.ru/catalog

(требуется регистрация, бесплатно)
256 тыщ товаров

Так что, если хотите реального времени - пишем велосипед подобного рода. И выбор движка тут никакой роли не играет, чем легче движок (а rs тут сильно вне конкуренции), тем лучше.

Кстати говоря, по элкому - в б2б всё барахло навалено, что даже с производства снято, а вот что они снаружи сваяли на битре

https://www.el-com.ru/catalog/

и пропихнули туда всего 13256 товаров (на 7 марта)
может, им и хотелось больше (судя по выгрузкам актуальным, что для дилеров предоставляют), но усё, видимо, битра больше не шмагла.

Я думаю, что тут необходимо идти по привычному пути "rs+mysql", а вот из mssql обновлять в mysql остатки через выгрузки не проблема.

Но режим реального времени... мне кажется, тут нужен костыль вида: js на странице товара долбится в php, а тот долбится в вашу mssql и получает цифры остатков - такие решения я встречаю регулярно, только с фронтэнда это выглядит как "js долбится в непубличный api", а на чём этот апи реализован дело десятое, хоть на фокспро.

Если пойти с другой стороны - ваш mssql должен выплёвывать из себя что-то типа json, который кушает js на странице товара. Остатки вполне себе можно реализовать на публичной части, не обязательно всё внутри формировать.

п.с. и эта, имхану - лезть с mssql в мир линуксов какой-то неверный путь.

admin пишет:

Вебсокеты не совсем подходят, так как на шаред хостингах их не развернешь.

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

Так что, про сокеты не забывайте :]

186

(13 ответов, оставленных в Вопросы по работе с системой)

С чем это может быть связано?

С отсутствием опыта

Пустая страница в любой системе означает, что скрипт ничего не отдаёт. Скорее всего, это ошибка 500 или 503.
Для полного понимания надо смотреть логи системы. Т.е. /var/log и поехали.

В системе есть обработка ошибок, которая по умолчанию отключена.
https://readyscript.ru/faq/#faq-errors
Только здесь будет верхушка айсберга

187

(3 ответов, оставленных в Вопросы по работе с системой)

На производительность никак не влияет. Грубо говоря.
Вот, допустим, у вас есть виртуальный хостинг, где вам положено N условных единиц нагрузки
Что два сайта с общим числом в 10000 товаров, что один сайт, где 6000 и 4000 товаров - разницы никакой. Да и сайт с 10000 товаров - тож самое.
Кстати говоря, товары для мультисайтов хранятся в одной таблице, просто у товара указан ИД сайта, для которого он.

188

(25 ответов, оставленных в Вопросы по Маркетплейсу)

Герман пишет:

Даже сама система кривая настолько, что слов не хватает.

Да ну? Можно хотя бы один пример.

189

(3 ответов, оставленных в Вопросы по работе с системой)

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

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

190

(8 ответов, оставленных в Вопросы по работе с системой)

Да просто надо wiki внедрять и всю админку обтыкать ссылками на wiki
Сделать статью "Округление цен" - и со всех округлений ссылка туда. Новичок прочитает статью и поймёт всю ситуацию в целом.

С прибавлением нуля я как-то делал. Я по-всякому делал. Просто, перед тем, как создать эту тему, я полагал, что есть большая кнопка ОКРУГЛИТЬ ЦЕНЫ - и все цены округлятся. Типа я её не нашёл wink

В итоге, получается, хотим мы цены округлить, есть способы:
1. Округляйте в csv, потом загружайте заново
2. Создавайте ещё один тип цены, базовая остаётся как есть, а новый тип цен показывайте на сайте.
3. Выделяете все товары и "Розничная = Розничная цена + 0 ед"

Вроде всё, экзотические способы вроде
4. MySQL for Excel - открываете вашу базу на листе экселя и округляем экселем
оставим в сторонке big_smile

191

(8 ответов, оставленных в Вопросы по работе с системой)

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

Часто бывает, что цены берем с прайсов поставщиков или с их сайтов сразу.
А там с копейками.
Конечно, можно округлить до заливки, но импортируем всего столько, что подобное просто забываешь, а клиент уже после сдачи сайта говорит - вот, округлить бы до десятков, а то смотрится не очень.

Я всё понял. Просто задача округления уже на сайте не так часто возникает. Более того, частенько в самом начале закладывается помимо базовой несколько цен - розница, уровни опта и т.п.
Но иногда задача чётко возникает - округлить. Тип цены - один, валюта одна, цены залиты полгода назад. И какой-то ступор. Вроде округлить есть тут, есть там - но ни черта не округляется.
Вам бы этот момент в админке обыграть как-то более понятно. Хотя бы пару строчек в подсказку добавить.

192

(8 ответов, оставленных в Вопросы по работе с системой)

То есть, если у товаров всего лишь одна цена, в системе одна валюта, (при этом нет комплектаций) то округления цен не происходит?
Базовая цена товара как была, так и остаётся.

193

(8 ответов, оставленных в Вопросы по работе с системой)

Хочется разобраться с округлением.
Каша какая-то.

Опция есть "Округлять цены при внутренних пересчётах до" в настройках модуля каталога
А также есть опция "Округление" в настройках типа цены

Я не понимаю, как работает первая опция.

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

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

Крутое начало.  Но у меня какая-то нелюбовь в form и table, прям глаза режет.

195

(6 ответов, оставленных в Вопросы по работе с системой)

admin пишет:

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

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

196

(6 ответов, оставленных в Вопросы по работе с системой)

Ярослав пишет:

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

По мне тоже. Мне вообще нравится напрямую в mysql работать. Тот же самый импорт длится в несколько раз дольше, чем из csv взять столбец и сунуть в базу (отсортировать по артикулу, например и проверить, совпадает ли количество элементов)
Но есть такая работа, как, например, фотки подвязать. Автоматически это сделать во многих случаях ну вообще никак. Поэтому садятся 2-3 человека и хренак-хренак, и за пару дней есть все фотки на 1000 категорий.

10000 категорий в 1С? Никогда такого не видел. Но, я думаю, нормально должно работать. Вот только сколько будет длиться выгрузка подобных каталогов стандартным обменом - просто боюсь представить. Обычно, если более 100000 товаров, да и меньше тоже, пишется велосипед для обмена - чтобы стандартные механизмы не участвовали. Я и на других движках с подобными велосипедами периодически сталкиваюсь. Например, для обновления цен куда быстрее снять запросом данные с одной базы и залить в другую, чем корячиться с обменом, импортом, экспортом. Только тут должно быть чёткое понимание, что мы берём, откуда и как и для массового использования такое рекомендовать даже глупо.

197

(6 ответов, оставленных в Вопросы по работе с системой)

admin пишет:

1. Форма никуда не делась, а куда она должна деваться, как же без нее? Что такое lastpass и почему оно сходит с ума (причем тут мы)?

Посмотрите в админке вебасиста. Там обёрнуто в div. Вообще, при всём при том, там нет никакого массового редактирования категорий, но, по факту его и в рс особо нет, один фиг в базу лезть или через импорт.
Ластпасс - это популярный менеджер паролей. Отслеживает формы и втыкает в них сохраненные пароли. Когда форма огромная - тормозит браузер. А вы тут при том, что сделали возможным создать огромную форму. Вот и всё. Хотя, можно возразить, что это пользователи такую огромную форму создают.

admin пишет:

2. Решили, что удобнее, когда открытые категории остаются в браузере, так как повторно они мгновенно отрываются.

Сомнительное преимущество, на самом деле. Если один раз секунду подождали до открытия, то и другой раз подождут [контентщики], а вот что дерево пухнет - это намного важнее.

admin пишет:

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

Ясно-понятно smile Вообще, особо ничего удобного в шифт+клик нет, когда категорий овердохрена. Намного удобнее напрямую в базе ковыряться. Но это дело вкуса. Хотя "можно развернуть список и кликнуть вначале" - ну, попробуйте развернуть на 95й категории, а закончить на 768й. Это несерьёзно как-то и кейс работает только для небольшого числа категорий.

Несмотря ни на что, огромное спасибо!

198

(6 ответов, оставленных в Вопросы по работе с системой)

Кто-нибудь затестил?
Разработчикам респект за работу с каталогом!
Обновил проблемный проект, где 150000 товаров и почти 4000 категорий.
ХО-РО-ШО

Но посмотрел исходный код, и что-то поумерилось счастье.
Проблема 1. Форма никуда не делась. Я про тег <form>, в котором строится дерево, id="tree-form". Дело в том, что от большой формы с ума сходит lastpass.
Проблема 2. Которая, на самом деле, и не особо проблема. Просто, если есть возможность её решить, то лучше решить (у вебасиста не решено, и там не удобно иной раз). При раскрытии категории появляются подкатегории, но если закрыть, то им просто ставится display:none. И когда, при работе с контентом, активно открывают-закрывают категории, страница пухнет, и пухнет сильно в случае большого количества категорий и длительного времени работы. Но достаточно обновить страницу и всё ок.

И вопрос, который можно было бы затестить, но мне просто не на чем пока.
Каким образом решено (и решено ли) массовое редактирование категорий? До какого-то момента массовое редактирование было только для отмеченных категорий, подкатегории игнорировались. А, сами понимаете, если категорий 1000 штук, из них 600 отметить сложно. Хотя, тут я, может, что-то упустил.

199

(5 ответов, оставленных в Сайт ReadyScript)

admin пишет:

Можем развернуть у нас на поддомене.
Какой движок предпочитаете (DocuWiki)?

Конечно, поддомен wiki.readyscript.ru будет смотреться отлично
Движок... да не принципиально, я уже и забыл, какие есть-то :]

200

(5 ответов, оставленных в Сайт ReadyScript)

Ребята, давайте замутим wiki-систему по платформе.
Вместе будем дополнять, а то слишком много белых пятен - я всё понимаю, разработчики не могут объять необъятное. И так "документация для разработчика" настолько подробная, что я боюсь предполагать, сколько времени угрохали на её составление.

Я, например, часто занимаюсь импортом/экспортом, объединением всего и вся - но почему-то часто забываю о том, как правильно импортировать категории, как правильно импортировать комплектации. Специально для таких забывашек тему создал на форуме.
А сейчас начал возиться на одном из проектов с категориями - и понял, что в документации про импорт категорий нет вообще ничего. Конечно, я вспомнил, что импорт идёт по родителю и названию, но, блин, о таких вещах надо черным по белому написать один раз и забыть. И пусть народ через гугл эти темы находит, через общий поиск.

Вот, есть, допустим, форум. Здесь поднимаются хорошие темы, особенно для начинающих. Но ничего не структурировано, да и как на форуме структурируешь?

Также, есть раздел
https://readyscript.ru/faq/
но это так, верхушечка айсберга затронута.

Мне лично подобная wiki ппц как нужна. Иной раз начинаешь новый проект - что-то делал год, два назад, а тупо забыл, как делал. И начинаешь часто заново.
Поддержку тоже дёргать иной раз не хочется.