Т.к. это крупные магазины, тут с удобством все более-менее нормально.

Конечно, поэтому я эти примеры и показал.

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

Денис пишет:

Да, приходит false , но в php.ini опция включена. С чем еще это может быть связано

С настройками хостинга. Я бы задал вопрос в техподдержку.

Есть ещё масса способов, но они не для форума.

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

Денис пишет:

Но при этом сайт на битриксе с тем же окружением работает отлично

У битрикса совершенно иная система тестовой разработки.

Олег пишет:

Хостинг есть, а вот дальше можно чуть развернуть ответ?! Как бекап сделать в облаке и как развернуть на хостинге?

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

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/

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

181

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

Если виртуальный, мы кидаем всех на таймвеб - лучше в России просто ничего нет. По соотношению качество/цена/техподдержка/соверменность.
Если же виртуального не хватает, тогда vps, только тут админ нужен, а сути особой, где vps - нет. Лишь бы там, где клиенты. То есть, если клиенты в России, то и хостинг должен быть в России.

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

183

(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 позиций можно сделать на шареде, а вот всё остальное - выше.

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

190

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

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

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

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

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

191

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

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

192

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

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

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

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

193

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

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

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

194

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

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

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

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

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

195

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

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

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

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

196

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

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

197

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

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

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

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

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

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

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

199

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

admin пишет:

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

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

200

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

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

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

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

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