Yoda

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

Ребят, я ни на что не намекаю, но по моему, использовать модули от саддиста, это так же как дружить с женщиной с низким уровнем социальной ответсвенности, про которую известно, что у нее СПИД. Уже не раз не два и не три этот человек подвергает уязвимости всех людей, которые купили его дополнения. Ну со всем уважением "ну сколько же вас еше лохов нерезанных" будут на это все вестись?

Я видел верстку и магазины Waha - они таки стоят 700 долларов. То что продает ТС - это УГ в стиле 80х. Я подозреваю, что вы все таки имеете какое-то отношение к этому проекту и хитрите. Но как бы там ни было, поверьте - этот проект УГ - гроша ломанного не стоит.

Ну такой хостер и так проверил. Неужели вы думаете что у хостеров в саппорте все поголовно сеньор-девелоперы со стажем в 15 лет? Или вы думаете что неграмотному студенту на зарплате как в макдональдсе есть дело до вашего htaccess ? У них задача основная - отписаться на ваше сообщение.

По каким то причинам у вас Ajax-запрос фильтра возвращает пустой результат. Соответственно фильтр не может распарсить данные на страницу и зависает. А вот почему он отдает пустые данные - это уже к автору.

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

А еще есть парадигма Mobile First. Но вопрос не в этом. Если вы позиционируете себя как Web-Designer, так или иначе вы должны думать элементами, а не "вот вам картина". Вот вам ссылка на хабр раз https://habrahabr.ru/post/321312/ Вот отличная статья на VC https://vc.ru/12635-ui-kit А здесь отличнейший материал про то, как один седовласый зашкваренный банкир нанял умных чуваков и они сделали нормальную вещь. https://habrahabr.ru/company/tinkoff/blog/326782/

Читая ваши сообщения - пахнет полиграфистом. Дизайн магазина, да и дизайн любого проекта, который чуть больше чем одностраничный лендинг - это непросто. Это очень непросто. Тут не нарисуешь psd, который потом можно порезать и сказать готово. Здесь все идет от дизайна микроэлементов. Сначала берете рисуете кнопочки, потом стили для заголовков h1-h6, потом формы, модальные окна, потом меню, шапку, футер, потом это все в четырех вариантах под разные типы устройств. Потом делаете прототип на демо-проекте. Смотрите свои косяки, опять же на четырех разрешениях. Понимаете, что русское название "CупперСмартфонАпплИФОН297 Плюс Турбо мега Блек" немного отличается от короткого английского Iphone 8p+, и оно сломало вам всю верстку и никуда не влазит, перерисовываете, смотрите что получилось. Потом кладете все в корзину и у вас ОЙ.. все разьехалось. Но корзину рисуете не для FlyCart, которая есть не у всех а для базового шаблона. Потом сталкиваетесь с тем, что вам не хватает данных, к примеру ID товара, для того чтобы сделать какую нибудь рамзетку. Лезете в код, осваиваете Ocmod и понимаете, что у вас будет самый лучший дизайн и вы сейчас схватили удачу за хвост и продажи аж попрут. Продаете два шаблона, а вам ООООЙ МИСТЕР, У МЕНЯ НЕ ЗАВЕЛОСЬ, У МЕНЯ КОНФЛИКТЫ, У МЕНЯ МАГАЗИН ГРУЗИТЬСЯ 10 СЕКУНД. И вы судорожно думаете, зачем мне все это, лучше бы я рисовал Лендосы!

Пошел натирать мозоли.

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

И подход в саппорте клиентов? Вот так взяли и исправили, и теперь неделями не будете футболить людей с текстами - "ваши проблемы"? И редирект с на success страницу сделали? И echo (какой то текст убрали)? И системный контейнер $this->request вместо $_POST использовать начали? Прилетел волшебник в голубом вертолете видимо.

В продолжение историй с Fondy и "технических причин". Поставили их модуль. И он - о чудо не работает - не отдает callback. Их представитель пишет ПРОСТО ГЕНИАЛЬНЫЙ ТЕКСТ! Смотрим в код и видим. $callback = $this->url->link('payment/oplata/callback'); Внимание. МЫ ОТДАЕМ!!! С САЙТА НА HTTPS, колбек ссылку, которая не формируется через https протокол заведомо в принципе! Платежная система. Предоставляет официальный модуль, который не ИСПОЛЬЗУЕТ ЗАЩИЩЕННОЕ СОЕДИНЕНИЕ! OMG - ваши деньги в безопасности! Ваши данные защищены. Мне даже представить страшно, где завтра могут оказаться ваши деньги и личные данные ваших клиентов. Т.е. вдумайтесь, вместо того чтобы максимально быстро попытаться разобраться в проблеме и ее исправить, представитель платежной системы и их команда разработчиков, даже не дернулись, заглянуть в собственный код. Возможно в европейском офисе у них все по другому. Но иначе как халатность и полное пренебрежение принципами безопаности, я это назвать не могу.

Стукни мне в скайп - я тебе покажу два примера подобной реализации с сохранением персистентности.

Мне кажется тут вопрос из разряда - сколько стоит автомобиль. Кому то и ДэуМатиз - предел мечтаний. А для кого то CayeneGT отстой, потому что был давеча изнасилован заряженным X6. У меня есть достаточно обширная база наблюдений, как своих так и чужих проектов в различных регионах от КЗ до NY. Могу сказать однозначно - все плюшечки, свистелки-перделки, функционал - абсолютно вторично и он может стоить любую цифру, но без трафика - это бесполезные вложения. А если у вас есть где взять, или вы знаете как взять трафик, то дефолтного функционала из коробки достаточно для того чтобы заработать первый миллион, без единого стороннего модуля! И у меня есть такие примеры с магазаном в ру-сегменте, на котором стоит дефолтный шаблон, 3000 хостов в день, и на текст "может вам шаблон получше" владелец твердо завявил - "ВЫ ЧТО ДИЗАЙН МЕНЯТЬ? У нас отличный дизайн" а там 1.5.3 дремучая. К тому же стоит подходить к оценке проекта с точки зрения специфики и тематики. Если у нас монобренд на 100 товаров - это один момент, а если агрегатор на 50 000 - совершенно другая история, когда вопросы навигации, удобного поиска и наличия вменяемого фильтра - равнозначны жизнеспособности всего проекта. Так что вопрос СТОИМОСТЬ СОЗДАНИЯ САЙТА С НУЛЯ. Это из серии - сколько стоит проститутка. Где - в Москве или в Челябинске, кривозубая или не очень, с подружкой или без, на час или на всю ночь, с доп-услугами или без. А так если что на Мкаде по 500 рублей Наташ завозят вагонами. Это ж не значит что всем Наташи подходят.

Да вы не оправдывайтесь, я понимаю что у вас на варзеопомойках не принято читать суть сообщений и вникать смысл, а цель переходить только на личности. Но на всякий случай напомню. Для быстрого старта нужен только движок. Он самодостаточен. Шаблоны, модули - это все вторично. И симпл в том числе. И прежде чем начинать дальше нести вашу классическую ересь, откройте собственный магазин и сделайте оборот хотя бы тысяч в 50 долларов за месяц. Потом поговорим.

Да что ты КЭП, правда? А зачем тогда он нужен simple при пошаговом оформлении. По моему у нас опять кружок вредных советов.

Мама, моя дорогая, какой умный... А ничего что 99% американцев не понимают как оформить заказ на одной странице и им нужно пошагово? А ничего что у нас есть магазин в котором мы проводили эксперименты и детальный анализ показал, что пошаговое оформление (с урезанным набором данных) более эффетивно и понтяно для покупателя чем одностраничная колбаса? А ничего что, если убрать меню и хлебные крошки на странице заказа, конверсия может увеличиться на 20-50%. Какие 90%.... Это вас на варезопомойках ваших такому бреду учат?

Модуль текдок, работает через api поставщика. Лог запросов тут не при делах совсе. Не давайте глупые советы. Вам повезло. Но вы даете советы на 99% владельцу вареза... Так как изначально эти вопросы надо отправлять поставщикам сервиса... Вы всегда за варез ? Давайте выложим ваш шаблон бесплатно и дадим на него ссылку на форуме.

У меня получилось поднять все и завести как-то... Подчеркиваю как-то. С десятой попытки. Потратил я на эксперименты наверное недели три..

Мне очень давно не попадались магазины с parseMX. Но вот модуль @usergio, дай бог ему здоровья, стоит на каждом втором магазине. И я думаю, что каждый владелец его модуля подтвердит, что в момент работы парсера, магазин ложится на слабых хостингах, или начинает существенно подтормаживать на нормальных. А цифры и выкладки - это не ко мне в данной ситуации. Потому что такими темпами, придется делать собственный парсер, а мне это не интересно.

Извините, может я вас расстрою но с таким подходом у вас вылезет тьма подводных камней. Во первых у Ukraine VPS устарели. Актуальное железо, если мне не изменяет память у них было в 2013 году, я как раз в тот момент задался для себя поиском сервера и остановился на их железе, так как оно было самое быстрое. Сейчас есть масса впс-хостингов в 2-3 раза дешевле и мощнее... Во вторых. ISP панель и сборка конфигурации, которую они устанавливают устарела, при чем критично. Даже не столько с точки зрения самой панели, сколько с точки зрения дырявых пакетов самой операционной системы, которые создают потенциальную уязвимость вашему магазину. В третьих. ISP 4 и ISP5 - это как старый запорожец и новый мерседес. В пятой версии они сделали безумный скачок. И пятая панель действительно закрывает нехватку навыков администрирования. Четвертая - это ад и Израиль. И еще. Кроме переноса на VPS ему требуется настройка. Почта, бекапы, кеширование статики, тюнинг mysql, изменение потенциально уязвимых портов и так далее...

Да при чем тут пафос. Таблица на 200-300 000 записей умирает при частых операциях чтения не только из-за локов а из-за перестроения индексов. И о чем мы ща спорим? А мы спорим, о том что долбить в нее по одной записи абослютно неэффективно, когда можно пихнуть 1000 записей за один запрос, и закрыть в принципе все проблемы с локами. Что касается ботов и задержки. Ну не ходят они равномерно и по графику. У пассивной нагрузки всегда есть рапределенные стохастические всплески, которые при постоянном обновлении легко валят голые проекты. На InnoDB мешает перейти full-text индексы, который поддерживает только mariadb10, которая недоступна в большинстве хостинг-платформ. И опять же я не понимаю в чем суть спора. Я долблю про технологию партицированного парсинга уже четвертый год. Какая сложность это реализовать ? У меня есть пример магазина, в котором 500 000 товаров. В нем весь каталог товаров подвешен в Sphinx, при этом база постоянно обновляется - ни единого разрыва. Разнесенные хранилища в разные контейнеры - это абсолютно минус головная боль... Да вы сейчас скажете, что сфинкс надо еще поставить настроить. Ок не вопрос. Кто мешает вам сделать два контейнера в рамках Mysql ?

Прочитайте выше внимательнее. Я вас ничего не просил мне объяснять, а просил показать пример проекта, к которому вы имели отношение, который можно было бы хотя бы с натяжкой назвать успешным магазином. Вместо этого вас как остапа понесло и вы начали переходить на личности. Это говорит о вашем "уровне квалицикации более чем". Но к сожалению ваша квалификация высока только в навыках высокопарно разглагольствовать ни о чем. Думаю, что не у меня одного сформировалось подобное мнение. А что я в состоянии или не в состоянии понять и что мне делать, извините, я уж решу без сопливых специалистов разговорного жанра. Спасибо.

Какие цифры... О чем вы сейчас. Я говорю о базовых принципах работы msysql. Когда мы пишем в таблицу, если она в Myisam - она лочится на чтение. В принципе... Если лочится таблица oc_product и у нас есть хоть какой-то трафик даже от ботов, этот лок вызывает лавинообразный поток наслоения процессов apache, потому что php стоит и ждет. Поэтому если происходит нон-стоп парсинг, то у нас постоянно заперта то одна то вторая то третья таблица, а таблиц с товарами допустим пусть будет 10... Соответсвенно 10 мс превращаются в 100. А в это время нас все время ждет очередь запросов на чтение... В итоге нагинается целиком весь проект. Что мешает сделать промежуточные клоны таблиц p2c p2s ps pd и так далее. Загонять в них 500-1000 наборов данных и одним большим запросом мерджить это с боевыми таблицами - я не знаю. Это достаточно просто. Но видимо все очень уверены в своем скиле. Кроме этого. При изменении данных в любой таблице, сбрасывается внутренний кеш mysql, который мог бы работать на тех запросах которые не используют NOW(). К сожалению, вам лень читать мануал. Давайте все таки начнем с того, что вы внимательно изучите принцип работы MySql с таблицами MYISAM, изучите механизм блокировки и работы кеша. А потом мы начнем говорить дальше.... 2.1 ЕЩЕ РАЗ!!! КЕШИРОВАТЬ нативно ЗАПРОСЫ Mysql средствами PHP, это как мыть голову шампунем, одевая резиновую шапочку. Можно - но сродни идиотизму. 2.2 Если сайт непосещаем. Это не значит что он не будет посещаем в будущем. Если мы говорим о проекте даже на 20 000 товаров. То раз в три дня его должны обойти два бота гугл и яндекс. А это 40 000 посещений за 72 часа... А это 555 заходов в час и 9 заходов в минуту. Это при идеальном роботсе и настроенном сео, а так умножайте на 4, и получаем 36 pageview в час. А кроме этого есть другие боты. А кроме этого есть какие-никакие посетители и так далее... Любой проект, должен быть живым "на холодную". Кеширование - это приятный бонус для повышенной нагрузки на повторяющийся контент. Разработка парсера не так страшна, если у вас есть готовая бизнес-логика обновления товаров и вам достаточно поменять драйвер API поставщика контента. По сути ничем не будет отличаться от смены классов используемого хранилища для кеша в в 2.3 opencart. Обновлять реал-тайм данные в контейнере - да легко. Вот тут подробнее: http://sphinxsearch.com/docs/current/rt-overview.html

2 - нет нет и еще раз нет. Во первых это возможно только для Яндекса, гугл в упор не видит эту директиву. Во вторых. Снижать частоту посещения ботов - это равнозначно грызть себе руку. 2.1 - так же в корне неправильно, читаем мануал к mysql. Она отлично сама кеширует запросы, но в формает постоянно обновляемых данных и данных о просмотре товаров, данная техника неактуальна от слова совсем. 2.2 - в нынешних реалиях от memcache есть прирост только при обращении к повторяющимся данным, как-то например в сео про с кешем от фрилансера. Но на 50 к товаров в сео про кеш вреден больше чем полезен. А в остальных ситуациях, когда происходит одинарное чтение данных из кеша, прирост от memcache по сравнению с файловым кешем ssd - минимален. А при небольшом тюнинге библиотеки файлового кеша и вовсе нивелируется в рамках статистической погрешности. 3. У ботов нет дня и ночи, они не спят. Получить от яндекса пессимизацию с его новым оценочным алгоритмом, который требует ttfb < 3 сек - можно автоматически при такой технике. Топик стартер совершенно верно формулировал мысль но не довел ее до конца. Если мы говорим о идеальном парсинге. Нам обязательно нужен промежуточный контейнер. В виде какого-то хранилища. Либо мы можем использовать технику перевода front-end выдачи каталога на индекс sphinx целиком, а не только поиска, и парсинга товара в базу данных с периодической переиндексацией сфинкса. Для регулярного real-time обновления данных о товарах opencart в коробке и существующие парсеры к сожалению, не сильно подходят. Я обсуждал концепции порционного обновления боевых таблиц как с @usergio так и с @MaxD несколько лет назад. Дядя Сережа покивал головой, сказал круто и забыл. А второй персонаж даже не понял зачем нужны какие то промежуточные таблицы, ведь и так же все вроде работает.