Мой совет как представителя компании, работающей и с MODX, и с Readyscript
Выбросьте minishop2 в ведро и работайте только с Readyscript

Пропадёт ваш разработчик - порог входа будет довольно высокий. И разбираться в костылях (а более никак сниппеты назвать нельзя) великое "удовольствие".
И дело всё в том, что minishop2 довольно куцый модуль, не обладающий базовой функциональностью. Импорт/экспорт через Ж, да даже хлебные крошки в виде отдельного модуля. Тему знаю довольно глубоко, но углубляться смысла не вижу, одно лишь напишу кратенько - у minisop2 нет ни одного плюса в сравнении с readyscript.

***
Порядок такой - ставите на поддомен ридискрипт. Переносите все товары. Не забываете про тексты на статичных статьях, описании категорий, карточках товаров, а также титлы и дескрипшны. Через модуль 301 редиректа настраиваете переадресацию (т.к. у ридискрипта будет другая структура директорий). Получаете интернет-магазин только на ридискрипт, который на 100% заменяет собой текущий сайт.

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

p.s. Главное меню, кстати, у вас обалденное - на фуллхд за границы экрана вылезает.

Если не ответит топикстартер - пишите мне, помогу. Парсинг всего и вся - это мой конёк, в т.ч. с многомерными комплектациями.
Правда, ценник зависит от сложности, не фиксированный.

278

(23 ответов, оставленных в Предложения по улучшению системы)

Сергей, а компы-то нормальные у менеджера и личный?
Просто очень похоже на то, что память оперативная закончилась (браузер съел), винда свопит на диск, а жёсткий диск устал, медленный
Поэтому в таком случае логично установить ssd, а жёсткий поставить вторым.
Тогда, если система и будет писать в своп - всё равно это будет происходить быстро. ssd всё-таки примерно раз в 8-10 быстрее нового жесткого диска.

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

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

279

(23 ответов, оставленных в Предложения по улучшению системы)

Бутаков пишет:

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

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

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

280

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

Присоединяюсь к вопросу - т.к. сворачивание пехапе-исходников в трубочку и медленная раскурка ни к чему не привела.
Оно просто и есть и оно просто экспортируется, а в остальных двух файлах закомментировано, да и при том unit_export": null

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

281

(23 ответов, оставленных в Предложения по улучшению системы)

Ярослав, я показал всего лишь один из приёмов продвижения интернет-магазина.

Тот же zipzip.ru тоже не заморачивается, Mvideo тоже.

Так зипзип в топах и нет. Зипзип - вообще помойка, там даже описаний нет. И икс всего лишь 1300.

А мвидео... пожалуйста
https://www.mvideo.ru/vstraivaemaya-teh … ilniki-580
https://www.mvideo.ru/vstraivaemaya-teh … nee-160-sm
https://www.mvideo.ru/vstraivaemaya-teh … nee-160-sm

Да, это фильтр, а не категории. Но их сео явно на эту тему "заморачиваются".

В ридискрипте же фильтр такой
https://mega.readyscript.ru/catalog/smartfony/?bfilter[isnum]=1
и это правильно для массового продукта. поэтому делаем через категории (обычные и спец, разницы особо нет)

Если такой подход мешает работе, требует бОльшего числа ресурсов, то нужен ли он? Нельзя объять необъятное

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

282

(23 ответов, оставленных в Предложения по улучшению системы)

Ярослав, тысяча категорий не так уж и много - электронные компоненты, кабели и прочее вам их обеспечат.
Также не стоит забывать о том, что для продвижения важны статичные урлы, а не результаты фильтра. Другими словами, в категории "Водонагреватели" появляются подкатегории "100 литров" и "Вертикальные", например.
Было 60 категорий в дереве, сделать из них 1200 - ерунда полная. Всего лишь надо в каждой из 60 категорий создать 20 подкатегорий.

И всё это для того, чтобы страница категории соответствовала запросу.

Вот пример
https://www.citilink.ru/catalog/compute … ts/memory/ -- вы полагаете, что одной категории достаточно? smile
https://www.citilink.ru/catalog/compute … i-800-mgc/
https://www.citilink.ru/catalog/compute … liya-komp/
https://www.citilink.ru/catalog/compute … liya-ddr4/
https://www.citilink.ru/catalog/compute … y/CRUCIAL/
и это только малая часть

283

(23 ответов, оставленных в Предложения по улучшению системы)

И ещё раз про количество пользователей.
С каталогом работает _каждый_ администратор интернет-магазина. Корзина важна, шаги оформления заказа, отображение товаров на сайте и так далее.

Мобильное приложение и CRM не относятся к тем модулям, с которыми работает _каждый_

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

284

(23 ответов, оставленных в Предложения по улучшению системы)

admin пишет:

Данная проблема в настоящее время касается далеко не большинства пользователей, а только тех, у кого количество категорий измеряется тысячами, а количество оперативной памяти на компьютере не позволяет комфортно загрузить такой объем DOM элементов в память.

На хорошем компьютере (и7, 16Гб) заметны подтормаживания уже ближе к 1 тысяче категорий. Собственно, тут не в компе дело, а больше в браузере - не способны они такие формы нормально отрисовывать, равно как с залипонами, допустим, XML открывают.

Тут больше вопрос личного восприятия "тормозов" и решаемых задач. Для контентщика при обработке товаров в каталоге любой "зависон" заметен, а для прогера - не важно.

Кстати говоря, если по 2000 товаров в каталоге админки показывать, то работает относительно нормально. Т.к. товары в таблице, а категории - в форме.
В текущей ситуации "ускорить" каталог можно уменьшив размер формы. Мы часто вырезаем из шаблона, например, "три точки и всё, что вложено". Или отображаем вплоть до 1 или 2 уровня.

285

(23 ответов, оставленных в Предложения по улучшению системы)

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

У меня теперь возникла проблема с недовольствами тех ,кто не использует CRM, а данный пункт меню занимает первую строчку меню)

Модуль удалите, да и всё.

286

(23 ответов, оставленных в Предложения по улучшению системы)

admin пишет:

Насчет других улучшений

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

Понимаете, вот строите вы дом. Если у вас фундамент дом не тянет, то нечего лезть наверх, наличники новые выпиливать, да систему автономного отопления ставить. Сначала фундамент надо сделать, иначе всё рухнет.

Каталог товаров - это как раз тот, фундаментальный модуль, на котором держится весь интернет-магазин.
Понимаете, каталог товаров нужен всем. Абсолютно всем. Он же несильно поменялся с двоечки.
А вы вваливаете ресурсы в CRM, в мобильное приложение, которое, если и нужно, то только единицам.

robots.txt

288

(23 ответов, оставленных в Предложения по улучшению системы)

Господа, давайте обсудим нововведения.

Начну по порядку, заданному в новости.
1. CRM
Не знаю, зачем это здесь - сторонние CRM на несколько порядков выше функционалом. Лучше думать о новых и поддерживать существующие синхронизации со сторонними CRM. Даже, извините, битра оформила црм как сторонний продукт. Кривой, косой, тяжелый, но сторонний продукт.

2. Складской количественный учет
Да, это важная вещь, чтобы конкурировать с другими распространённым движками, однако, когда компания вырастает, логично уйти к жёлтым продуктам. Но начинать с жёлтых продуктов - очень сложно, поэтому, я категорически за простой складской учёт.

3. Обновленное мобильное приложение
Не знаю, кому это может быть нужно. Наверное, кому-то нужно. Разработчикам виднее.
Однако, ни на форуме, ни в пожеланиях особо вопросов на эту тему нет. Видимо, это такое конкурентное преимущество и мегафича.

4. Новая система прав
Это очень хорошее нововведение, его мне как сисадмину в прошлом очень не хватало.

5. Очередная новая тема оформления
Оставлю без комментариев. Если бы 30 тем было, можно было бы и каментнуть. В маркетплейсе практически пустое место там, где темы.

***
Остальное не затрагиваю - добавлю свою головную боль. Решение которой мы всё сами пытаемся реализовать, но нас заваливают клиенты проектами.
Это - админка/каталог товаров, и её работа при большом количестве категорий. Тему я поднимал более полугода назад, но до сих пор в каталоге мы видим перегруженную форму. Каталог товаров начинает тупить примерно при 1000+ категорий. Вернее, не сам каталог - тупит браузер, пытаясь отобразить форму.
В тпльке "замечательное" решение - рекурсия в файле
/templates/system/admin/html_elements/tree/tree_branch.tpl
include file="%system%/admin/html_elements/tree/tree_branch.tpl
есть дочерняя категория? себя же отображаем
Из-за этого ползёт до сих пор косяк, если дочерней указать себя же :]

Есть нормальное решение для такой ситуации - подгрузка категорий post-запросом. Но воз, как говорится, и ныне там.
Может, кто-то займётся?

289

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

Бутаков, не все мы - даже немножко сисадмины и обладаем определёнными знаниями.
Я - обладаю. И всегда первым делом смотрю в логи. А ещё у меня версия nginx с дебагом в песочнице.

Но нельзя решать за всех. Общий уровень довольно низкий.

290

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

admin, такие вещи надо в текст ошибки заносить явно.
Мол, Ошибка расшифровки лицензии, а дальше варианты решения проблем. Сильно дистрибутив это не раздует, а сколько проблем решит в будущем, не перечесть.

291

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

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

Тут же ситуация идентичная. Даже, если бы сервер проверки лицензии проверял каждый раз лицензию - ну дал бы ему старый сервер валидный ответ.

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

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

Каспер, арендуйте VPS, устанавливаем nginx+php, повышаем скиллы, если ещё не повышены.
И смотрим в /var/log
На vps лимиты можно выставить в бесконечность при желании.
Это не средства RS, это средства вебсервера. Т.к. RS не идеален местами, об этом тоже надо помнить.

RS нарисует красную строчку при импорте, Ошибка передачи данных, в консоли светится 500 - что делать будете?!
А тут самый правильный путь смотреть логи сервера, ридискрипт тут вообще ни при делах.

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

***
Короче, ребята, настраивайте среду - чтобы на любой чих в /var/log/ падало сообщение об ошибке в лог. Ваша, не ваша, нотисы - вообще всё.

Советую просто посмотреть логи веб-сервера.
Если ошибку вызывает веб-сервер, то смотреть надо логи веб-сервера, а не включать/отключать отображение ошибок на фронтенде.

Я предлагаю универсальный способ для любого движка и необходимо учиться смотреть ошибки именно так
У меня в /var/log/nginx всё валится, включая нотисы.

п.с. и только нубы отключают все ошибки.