Gorman

Как смог, попытался задачу понять. Вам нужно, чтобы основное изображение менялось при щелчке на миниатюру? Вот гляньте на известный шаблончик, так или как-то по другому? http://safesystem.pro/videonabludenie/camery/ip-camery/dahua-dh-ipc-hfw1220sp-0360b Если да, и мы говорим о базовом шаблоне, то нужно сделать следующее: 1. Из контроллера сформировать для всех изображений нужный для вывода размер (228х228) - сейчас он сформирован только для одного, главного изображения. Можно исхитриться и изображения 500х500, ссылки на которых сформированы в контроллере для галереи, с помощью js поджать до 228х228. Тогда не придется трогать контроллер. 2. Переопределить логику работы скриптов. Нужно сделать так, чтобы по щелчку на миниатюру не срабатывал плагин с галереей, а менялся src основного изображения на src дополнительного. src доп изображений можно хранить в любом параметре у доп изображений, брать оттуда же для подмены. 3. Не могу сказать точно, но кажется, что можно управиться без изменения верстки. 4. Галерею прицепить, например, к щелчку по текущему основному приложению - как на шаблоне по ссылке выше. То есть, резюмируя, все можно сделать только с помощью js. Не могу сказать, что задача прямо "проще некуда", но решаема, если увлекаетесь js Всплывающее окно - имеете ввиду галерею в модальном окне при щелчке на доп изображение? В плагин (библиотеку) я лично не лазил, может кто подскажет из коллег по кастомизации, но имхо это задача посложнее будет Иногда проще найти другой плагин галереи, который больше устраивает, и подключить его. Но возможно (часто так и бывает), что некоторые возможности кастомизации разработчики плагина уже предусмотрели, плагин галереи в опенкарте, если не ошибаюсь, называется magnific Popup - http://dimsemenov.com/plugins/magnific-popup/ . Возможно, там какие-то настройки присутствуют.

Так вы экспортируете или импортируете? В первом сообщении говорите про экспорт - части можно выбирать в настройках модуля. На скриншоте сейчас показываете импорт. Если Вы про импорт, то вот у Вас есть настройка, про которую Вы говорите. Называется она "Ступенчатый импорт" - звучит так, будто это то, что нужно. В настройке написано "Да (обновить и\или добавить данные)" и "Нет(удалить все данные перед импортом)". Логично, что нам нужна настройка "Да". Берете часть таблицы, один лист или пол листа, в зависимости от габаритности, и грузите сначала одну часть, потом вторую. И повторюсь, на 256 мегабайтах оперативки магазин может и выдержит импорт частями большого количества товаров. Но очень вероятно, что после того, как Вы прикрутите к магазину какой-нибудь фильтр, то поймете, что жизнь - боль.

"Обмануть" систему-то Вам удалось, только работать сам модификатор все равно не будет, он для версий 2.х.х

Поддержка третьей версии в модуле указана? Тройка архивы любит кушать, а не xml-ки

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

Подскажите, где конкретно и что хотите убрать.

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

Ответил в личку

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

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

А что за модуль? И поподробнее расскажите как устанавливали.

Я не точно понял в чем проблема, но на тройке замечал, что не меняется статус "Отключено" на "Включено" на странице со списком модулей (marketplace/extension). Кнопку с зеленым плюсиком нажал, и вроде установка произошла, появилась кнопка деактивировать, а слева надпись на поменялась, все также "отключено". При этом модули все работают корректно. У вас не такой случай?

Это на какой из страниц? Где все производители или конкретный?

А логи можно глянуть (связанный кусочек)? Вообще, чтобы грузануть сайт с одного ip нужно конкретно постараться. Или устанавливать многопотоковое соединение, или запрашивать какие-то очень тяжелые страницы. И если такие страницы вообще присутствуют - от них нужно избавляться. Во-первых, скрипт плохой. Даже сложно сказать, что в нем самое плохое - установление доп соединения с базой (потенциальные конфликты), отсутствие закрытия этого соединение, минимум +4 запроса в базу для каждого пришедшего посетителя, работа с файловой системой или авторедактирование .htaccess через пхп. Решение даже называться костылем не достойно. Во-вторых, решаться это, в идеале, должно не на уровне вебсервера. Так, например, даже если Вы даете вебсерверу установку "этому IP ничего не давать", то вебсерверу все равно придется на запросу злоумышленника отвечать. То есть дос-атаки возможны, как и ранее. Разве что теперь вебсервер отвечает быстро, и с одного ip сайт уже не положить. Для сложных случаев на серверах всегда присутствует утилита iptables. Это линуксовый брандмауэр (фаервол). Изучите его, или найдите тех людей, кто разбирается, и настройте сервер так, чтобы он не падал от запросов одного IP. И повторюсь, если проблема в создании мульти соединения от данного IP, то iptables легко режет их до нужного числа (например, с одного IP нельзя одновременно установить более чем 10 соединений), фильтрует зловредные IP и делает еще кучу сложных штук. Если проблема в отсутствии кэша или присутствии тяжеленных страниц, и Вас там кладут через f5 - то работать нужно в первую очередь над этим. Учитывая 1 IP, который вы баните руками, настройкой nginx можно реализовать не только защиту от мелкого досера, а еще и повысить быстродействие сайта.

У меня просто развернуты все версии опенкарта на локалке, для тестов - там и смотрю "значения по умолчанию" Вообще поглядывайте на медленные запросы и впредь. В этом запросе, если реально так отличается время (разница нереальная на самом деле, надо еще проверить будет), лишние индексы сыграли какую-то негативную роль. Какую - сказать затрудняюсь, запрос сам разобрать - надо времени конечно потратить уйму и быть большим спецом в SQL - если есть такие, то подскажут, тоже будет интересно послушать. По EXPLAIN-у запроса с доп индексами видно, что праймари используется не на всю катушку. Учитывая, что в запросе все части PK используются - конкретно этому запрос доп индекс не нужен. Но вот если какой-то запрос будет касаться только одного столбца (attribute_id, language_id), то тогда индекс должен выручить. Хороший вопрос - дергаются ли эти данные, учитывая что они втроем уже в составном праймари. Я лично не отвечу

Глянул, из коробки никаких доп индексов не стоит, только составной праймари, как у вас на скриншоте. А кто вам туда их поставил?

Может я позабыл html, но последний раз делал закладку через id, а не name. Попробуйте тоже. Хотя если Ваш вопрос в том, почему он плавно не скроллится, а просто перебрасывает вас на якорное место - то так и должно быть. Для плавного скролла действительно нужен скрипт.

Честно: если не понимаете что в методе написано даже примерно, то разбираться с тем, почему так работает удаление товара из корзины будете неделю в лучшем случае. Направление - копайте в сторону метода (функции), который я описал выше. Его можно найти в common.js. "Из коробки", редиректа в разделе выбора товаров быть не должно (собственно и в функции его нет), и если зайти на чистый магаз - то все будет добавляться и удаляться асинхронно, через ajax, без перезагрузки. У вас на сайте сделано что-то такое, что и добавление, и удаление вместо вызова (или вместе с вызовом) js-метода еще и перезагружает страницу. С наскока, без исходных файлов я не могу Вам сказать, что именно заставляет его прыгать. Нужно залазить и смотреть как и куда проходит запрос, какие ответы приходят, и в какой момент его кидает. Давайте еще проще опишу. 1. У вас есть кнопка-крестик, <a href="javascript:;" onclick="cart.remove('<?php echo $product['cart_id']; ?>');" 2. Кнопка вызывает по щелчку (onclick) функцию cart.remove (на самом деле метод remove объекта cart), которую Вы можете найти в файле common.js. Лежит он где-нибудь в catalog/view/javascript/common.js 3. Функция отрабатывает все, что в ней написано. Она отправляет запрос на удаление в контроллер (checkout/cart/remove), и если оттуда приходит ответ, что все сделано, то: 4. Принимает решение что с этим ответом сделать. Функция смотрит на роут (на урл), и если мы находимся в корзине или на этапе оформления товара, то она перезагружает страницу (и показывает новую корзину). Если мы находимся где-то в другом месте, то она просто обновляет эту мини-корзину, без перезагрузки страницы. Так должно работать из коробки. Что и где у вас намутили, что страницу по любому чиху перезагружается - нужно смотреть и отлавливать.

Модификаторы обновили? Удаляли как? Судя по данной ошибке, модификатор еще работает, но самих файлов, которые модификатор подгружает, уже нет.

Из коробки на таблице product только PK на product_id.

В вебмастере нужно глянуть что там с индексированием. Скорее всего да, страницы удалились из индекса как отдающие не 200ый код (недоступны), будет как новый сайт, разве что на руку сыграет возраст домена. Домен-то продлевали, кстати?

Вы не путайте 1. Тот файл, что вы указали - это движковая библиотека для формирования ответа сервера (Response). И редирект там описан как метод, который можно вызывать в нужных контроллерах. Самый простой пример: когда неавторизированный пользователь заходит в аккаунт (роут index.php?route=account/account), то контроллер редиректит его на логин (index.php?route=account/login). Вот код контроллера: class ControllerAccountAccount extends Controller { public function index() { if (!$this->customer->isLogged()) { $this->session->data['redirect'] = $this->url->link('account/account', '', true); $this->response->redirect($this->url->link('account/login', '', true)); } Теперь и подумаем, нужен ли там 301ый редирект? 2. Реврайт от апача - это совсем другая история. Самая частая и простая необходимость - "вырезать" index.php, по факту заменить его при ответе, что он и делает. К движковых библиотекам это особо отношения не имеет. Поэтому, если мы перешли на https и хотим видеть ссылки только такого типа в будущем всегда, то логично отдать эту работу апачу и возвращать 301ый.

Да, зп джунская, но что-то не припомню джунов с 3мя годами опыта, Ларкой, Вью и прочими радостями )) Хотя может кто-то из далеких регионов и попробует. Иной студент бы ухватился за возможность поработать, но вряд ли удовлетворит работодатели своим стеком знаний. На зп 50к в Москве берут совсем нулевых, кто сможет написать таблицу умножения через фор. Возможно, в Украине действительно мир другой, и там программист-новичок получает 25 тысяч.

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

Не очень понял процесс, в ходе которого возникает проблема, но ошибка говорит о том, что система ищет шаблон (view) с названием cod2.twig, и не может его найти.