Dotrox

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

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

Что-то не то вы читали. CDN как раз и предполагает. что статика выносится на другой сервер, который может быть не только в другом ДЦ, но и в другой точке земного шара. Есть множество модулей для интеграции с различными CDN (специализированными).

Хватит манипулировать фразой о контексте - это как раз вы и вырываете слова из контекста! А ваш контекст это не просто "сумма обсуждаема", а "обсуждаема в адекватных пределах". Под "адекватными пределами" явно не подразумевается увеличения бюджета в 5 - 10 раз. А именно таким оно будет, если вы действительно хотите делать собственный фильтр. Вы, вероятно. невнимательно читали подпись под лого форума. Там написано не "российское" сообщество, а русскоязычное. Так вот, 2/3 специалистов этого форума находятся за пределами РФ. Кроме того, в IT принято все цены озвучивать в долларах (и все транснациональные расчёты вести в них же), потому что заказчики и исполнители довольно часто находятся в разных странах, а доллар универсальный ориентир, который к тому же помогает прицениваться без калькулятора. А час работы специалиста - это действительно $15 - $20. Причём, это расценки СНГ. На западных биржах фриланса уже даже индусы берут от $20 за час. Ну, если в магазине все модули будут полностью самописными (и написанными конкретно под этот магазин), то это не предел. А в вашем примере фильтр как раз совсем не самописный и не с нуля написан. На глаз он выглядит, как стандартный фильтр ОК с некоторыми допилами.

И только они. В ОК нет какого-то отдельного инструмента для работы с куки.

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

А сами как думаете? Тема о поиске, а вы спрашиваете разве о нём? Для того, о чём вы спрашиваете не нужно ничего переделывать. Сделайте отдельный товар и добавьте к нему опцию с типом "файл, для заливки фото и опции с вариантами рамки, а данные свои покупатель оставит через обычный процесс оформления заказа.

Белая страница - это, скорее всего. ошибка 500. Права проверили?

У вас сайтмап - это экселевская таблица? У него расширение должно быть xml, а не xls. Если на сайте по ссылке на сайтмап пусто, значит правильно Гугл ругается. И что значит пусто? Там просто белая страница или 404 или какая-то ошибка? И ещё проверьте права на файл сайтмапа, должно быть 755 или 777.

А это вы зачем убирали? Это нужно убирать только в одном случае: если ваш сайтмап - это статический файл, который генерируется, например, по крону!

Да я понял. Просто ТЗ обычно составляется до макетов и заказчики о нём не думают общаясь с дизайнером, а только радуются всему, что дизайнер понапридумывает, а потом происходит столкновение с реальностью и оказывается, что доплачивать за бурную фантазию дизайнера заказчик не хочет (а то и не может ввиду уж слишком высокого полёта этой фантазии), а вдобавок ещё и макет оказывается непригодным для вёрстки, ибо после выкидывания последствий дизайнерской фантазии там возникают дыры и нестыковки. А дизайнер, конечно же, тоже бесплатно не хочет подгонять уже оплаченный макет под реалии движка. Так что, работу дизайнера нужно контролировать.

А надо затрагивать! Пример из собственного опыта: дизайнер что-то нарисовал в макете (не помню уже что), чего и в помине нет в ОК. Я говорю заказчику, что этого нет и потому, если делать, то нужно доплатить. Ответ (более-менее дословно): так у Розетки же это есть и я думал, что это везде есть. А ещё знакомство с движком для дизайнера нужно потому, что если новый функционал то действительно можно допилить, если дизайнер что-то нафантазирует, но он может тупо не нарисовать то, что в движке есть. В абстрактной дискуссии - это всё, вроде, мелочи, но по опыту работы с разными заказчиками и разными дизайнерами могу сказать, что из-за этих мелочей бывает хочется дизайнера придушить, а ещё раздолбать кирпичом голову PM (в тех случаях, когда взаимодействие с дизайнером происходит через него), ибо он то, в отличии от заказчика, должен всё это понимать и следить. И тут ещё один красноречивый пример: показываю PM вёрстку первой из страниц макета, он спрашивает, а что должна делать вот эта кнопка (которая на тот момент ничего не делала), отвечаю, что понятия не имею, ибо в макете никаких намёков нет. Через время он пишет, что "дизайнер сказал", что она делает то то. То есть, дизайнер выдумал кнопку (забыв при этом нарисовать тот блок, который она выводила на экран) и никто на неё не обращал внимания пока она не оказалась в вёрстке. При чём это была огромная кнопка (одна из всего трёх) в шапке мобильной версии сайта, а не что-то малозаметное.

Это не паттерны, а просто файлы. А паттерн - это, например, MVC, на принципах которого построен ОК. Не надо пихать контроллеры в директорию шаблона! Если вам нужно создать новую страницу (новый тип), создайте контроллер там же, где и все остальные лежат и ОК автоматически его подхватит при обращении по прямой ссылке (без ЧПУ), а для ЧПУ добавьте в таблицу url_alias для него алиас. И не забудьте создать под него схему (макет), чтоб туда можно было модули выводить.

Его не настраивать надо, а переделывать. У вас там сейчас в самом начале ошибка: <b>Notice</b>: getimagesize(): Read error! in <b>/hsphere/local/home/sashabob80/dorojka.com/catalog/model/tool/image.php</b> on line <b>32</b> <b>Notice</b>: getimagesize(): Read error! in <b>/hsphere/local/home/sashabob80/dorojka.com/system/library/image.php</b> on line <b>14</b> Вот это и вам должно помочь: https://opencartforum.com/topic/62389-sitemap/?do=findComment&comment=564838 Только не добавляйте строку с <lastmod> - это из 2.2.

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

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

Как я уже писал выше: откройте в браузере ваш сайтмап и убедитесь, что там именно то, что должно быть. Открывайте с сайта, а не с компа! И если там именно то, что и должно быть, то проверьте ваш файл здесь: https://webmaster.yandex.ua/sitemaptest.xml

Вероятно, у вас какая-то сборка и это вопрос к её автору. Грустно, но просто до примитивности.

RewriteRule ^sitemap.xml$ index.php?route=feed/google_sitemap [L]

Версия в index.php. А контакты - это не модуль, а стандартный контроллер движка. Карту, вероятно, придётся менять/настраивать ковыряясь в шаблоне этой страницы.

Если вы используете статический файл, удалите из .htaccess редирект на контроллер динамической генерации. Затем попробуйте открыть ваш сайтмап в браузере. Если увидите то же, что и в файле, то и с Гуглом проблем быть не должно.

А для юзабилити нужен UX дизайнер. У нас даже не все дизайнеры (и не только они) хотя бы просто знают смысл этой аббревиатуры :) Некоторые (и с этим приходиться сталкиваться чаще, чем хотелось бы) вообще рисуют просто, чтоб "было красиво" и даже не пытаются подумать, как этим потом пользоваться, когда оно из картинки превратится в живой интерфейс.

Ошибка указывает на то, что модуль рассчитан на ветку 1.5. Вероятно, все модули, которые у вас не работают, рассчитаны на ОК 1.5. А обычный vQmod в двойке работать не будет, под неё есть модифицированный, но лучше его не использовать, ибо в двойке есть свой аналог (но модули под vQmod с ним несовместимы).

Там не настраивать нужно, а изменить код генерации, ибо по дефолту он жрёт невероятное количество лишних ресурсов и при относительно большом количестве товаров упирается в лимиты (либо времени выполнения скрипта, либо памяти). А в ОК 2 добавили в сайтмап ещё и изображения товаров и теперь дефолтная генерация вообще практически не пригодна для реального использования

Попробуйте вместо всего этого такой код: ini_set('date.timezone', 'Europe/Berlin'); Кстати, а зачем вы date_default_timezone_set в условие обернули? Оно, вероятно, потому и не работает. На шаредах редко поддерживаются пользовательские php.ini (а если и поддерживаются, то называются обычно .user.ini)так что при такой проверке на наличие временной зоны в ini файле вы получаете значение из общего конфига сервера. Вы ведь не конкретную зону проверяете, а только её наличие в конфиге. Да, всё корректно и соответствует стилю кода шаблонов ОК. Как-то так: $time1 = DateTime::createFromFormat('H:i', '9:30'); $timeNow = DateTime::createFromFormat('U', time()); $time2 = DateTime::createFromFormat('H:i', '23:30'); if($timeNow > $time1 && $timeNow < $time2){ } И точно так же на странице с инструкцией к date_default_timezone_set есть ссылка на временные зоны. Но логичней начинать с функции установки зоны, а затем смотреть, как зоны называются. Собственно: ищем функцию под нашу задачу и, если возникают вопросы по её параметрам, ищем информацию тогда уже по ним, а не сначала ищем информацию по параметрам, а потом ищем куда бы их впихнуть.