Т.е. не хватает знаний сделать правильный кастом, но хватает знаний сделать все, что нужно полностью с нуля.... ну ну.. :)
Не знаю чего вам там забанили, но репозиторий на githab "мастхев" в таких проектах. (Уже если каким то чудом вы реально там забанены - есть и аналоги). Это важно и для распространения, и для разработки особенно публичных решений.
Скрипт очень сырой. Он не дожидается загрузки картинок как следствие не гарантирует их подхватывание. В прочем сомнительный функционал сгребать все картинки со страницы. протестировать удалось только убрав из фильтра некоторые условия.
Зачем вы включили в него стили (те что отвечают за дизайн точно не стоит втаскивать внутрь скрипта), и саму верстку - не легче ли создавать скриптом ее, что б не было необходимости потом искать в DOM и навешивать обработчики. Крутящийся прогресс при каждой смене картинки - сомнительное решение. Зачем оно ведь картинки в данном случае уже загружены. Опять же: достаточно стандартное решение, что на старнице отображаются маленькие превью, а при открытии уже их полноразмерные варианты..... ну и в общем по мелочи не хватает некоторого функционала, который популярен в подобных скриптах.
И не только на странице. Есть у меня проект, там фоном идет обмен с несколькими внешними сервисами. Все три обмена готовые сторонние решения (и не дешевые). Но глядя на их реализацию (опять же вопрос алгоритмов) хочется кого то прибить...... Там такое ощущение, что люди сделали решение для каталога (вот как раз как выше говорили "до 1000 товаров" и с парой заказов в месяц) и им все ок.... И вот эти процессы идущие фоном на серваке - способны этот сервак загасить полностью
На проектах где высокий RPS (конечно если позволяет ситуация) вполне резонно в узких местах уходить от "типового поведения". Не скажу зв ВП, но в Битриксе это вполне нормально реализуемо. (у меня есть проект где бываю моменты когда приходит более 150К пользователей активных, при чем не размазано на все сутки, а именно норовят все разом). Ну, а далее все так: и алгоритмы и структура БД (Включая денормализацию), кеширование и т.д и т.п.
Инфоблоки прекрасно работают на 1000 :) и даже значительно больше. Т.е. при грамотном кешировании это не особо проблема. Например (из проектов на моем обслуживании) каталог порядка 150к товаров и примерно столько же торговых предложений, нормально работает, хотелось бы быстрее, но проблема скорее в шаблоне и его универсальности (в дополнение к самому битриксу). Второй пример (где напрягает уже именно кухня Битрикс - там чуть меньше товаров, но вот свойств несколько тысяч - исторически так сложилось. Но там ускорили переводом фронта на node.js.
Как итог, конечно же при необходимости "ускорения" урезать "универсальность" вполне себе путь и, полагаю, для любого проекта (где есть универсальность). Но опять же у каждого проекта свои возможности и варианты. Где то надо часть таблиц в отдельную БД вытащить, где то часть функционала вырезать в отдельный сервис и т.д. и т.п.
Пожалуй я для себя, как для пользователя, "заметил" один недостаток: домен с дефисом "сложнее" набирать на мобильном - приходится переключить в какой то момент клавиатуру на знаки :)
Хм. у меня два своих домена (рабочие сайты) с дефисом. С дефисом потому, что домен без оного был занят, а городить другое название было бы не логично, а дефис в обоих случаях пришелся "к месту". Есть и на обслуживании несколько сайтов рабочих с дефисами
Не пользовался (я вообще отказываюсь от задач с иными cms, последнее взаимодействие было вообще вытаскивание сайта после взлома). но интересно. Но объективно сейчас череда сложных задач - после работы мозг в положении выкл. :) Но если можно чуть позже обращусь, тут из интереса можно попробовать. Да и я например с "секундомером" сайт на Битрикс бы собрал тот, что выше говорили (с условием что возможно из коробки)
Но тут еще надо понимать, конечно, то обсуждаем мы с позиций разных сайтов. Те с которыми я работаю - там git. И даже, по хорошему и правильному, зарубить бы половину функционала из коробки битрикс для контент менеджеров :) А FSE ведь это редактирование не только контента (ну может согласно ограничениям) но и структуры страницы. А это уже по хорошему должно версионироваться (или там это реализовано?). Т.е. вот у меня есть три ветки в разработке: прод, тестовая - на которой вместе с заказчиком проверяем гипотезы или просто тестируем, и разработки. И могу этим жонглировать (например тестовая ни куда не идет, при этом может объединять изменения из всех версий... В общем то это в другую степь. Но пока меня беспокоит возможность контент менеджеру иметь слишком широкий спектр управления. А в случае ограниченного бюджета и когда владелец сам начнет ковырять. А потом дорастет до поддержки и доработках глубоких, и не может ли оказаться сайт в ситуации когда надо все переделать. :) Визивики ранее упоминал как яркий пример. Сначала в статьях делают "красивенькое оформление" (зеленый, красный цвет, шрифт разного размера), а потом " а давайте сделаем темную тему".. а там статей к 1000 уже накопилось :)
