Dotrox

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

Ну, так на то и есть опенсорс, чтоб пользоваться помощью сообщества. Вот только он ею довольно грубо пренебрегает: на гитхабе можно найти кучу пулл реквестов, которые либо молча отклонены, либо отклонены с комментарием типа "плохая идея". Так можно на форуме ответить, но когда человек уже потратил время и предлагает готовое решение, а не просто озвучил хотелку, не объяснить причину отклонения - это уже грубость и неуважение к сообществу. Вот пример молча отклонённого пулл реквеста, который просто фиксит баг, а не вносит какие-нибудь спорные изменения: https://github.com/opencart/opencart/pull/4984 А вот молча отклонённый пулл реквест, который добавляет в ОК чуточку так ненавистного Дэниэлю DRY: https://github.com/opencart/opencart/pull/4974 Кстати, там неплохая идея, как хоть немного сократить простыни кода во многих контроллерах. У кого после многочисленных таких примеров возникнет желание контрибутить в ОК?

Это действительно не баг, а просто тупость. Такое можно встретить у школьников, которые не до конца понимают, как работает их код. В двойке то это исправили, но сколько лет оно жило в ОК. И вопрос же не в том, что это, а в том, как пользоваться магазином, где не выключается подсчёт товаров. И чтоб получить из-за этого подсчёта нереальные тормоза не нужно 200к товаров - даже на 2к эффект будет уже хорошо заметен. И опять же, вопрос не в том, зачем там добавились изображения, а в том, как пользоваться картой сайта... которая не работает вообще? Основная аудитория ОК как раз те, для кого он ещё и система учёта. Либо он, либо экселевский файл. Ну, и дело не только в том, что положившись только на учёт в ОК можно получить кашу - как минимум он просто может показывать не в наличии товары, которые есть в наличии и, как результат, потеря продаж этих товаров даже, если у тебя идеальный учёт в Экселе (либо где угодно, но без двухсторонней онлайн синхронизации). Кстати, на счёт реалий их мира: их мир - это Китай. Дэниэль хоть и британец, но уже не первый год живёт в Китае и именно в Азии ОК наиболее популярен. Хоть с этим сталкиваться не приходилось. Но там, вроде, тоже по слухам без багов не обошлось.

Откройте шаблон home.tpl в нормальном редакторе (Notepad++, SublimeText) и при сохранении изменений убедитесь, что сохраняете в кодировке utf-8.

Например, нормальной генерации сайтмап. При чём, если в 1.5 для ощутимых тормозов нужно было ещё какое-то не самое минимальное количество, то в двойке с добавлением в сайтмап изображений, генерация может вываливаться с ошибкой даже на сотне товаров. Ну, и из былых "заслуг": в 1.5 невозможно было отключить подсчёт товаров в категории - опция в админке отключала только вывод этого количества, но не его подсчёт, который продолжал создавать тормоза. При удалении товара из заказа в админке его количество не прибавлялось обратно к наличию. Не помню, исправили ли это в 1.5. Про ЧПУ уже сказал выше. Это то, что сейчас первым вспомнилось. И это всё не касается какого-то нового недостающего функционала, а только исключительно баги и недоработки, которые либо вообще не исправляются или даже ухудшаются (как с сайтмап), либо до исправления кочуют годами из версии в версию.

Начните с того, что проверьте отсутствие модулей в боковых колонках (в обоих), потому что текущие классы указывают таки на не пустую переменную одной из колонок. Короче, тупо удалите все модули со страницы товара. В stylesheet.css вашего шаблона.

Путь не должен быть пустым. В случае подключения через клиент путь автоматически определяется для вашего пользователя при подключении. А тут надо спросить путь у поддержки.

Для модулей и так места хватит. Сравнить, например, что есть из коробки в ОК и в ПрестаШоп. ОК до коробочного состояния ПрестаШопа модулями пихать и пихать. Но там другая беда: излишне сложный код и огромная прожорливость на любом количестве товаров (особенность архитектуры). Так вот, если коробочный функционал настолько беден по сравнению с конкурентами, почему бы не сделать, чтоб хоть то, что есть, работало нормально? Мне кажется, разработчику просто должно быть стыдно, если его продукт для нормальной работы требует посторонних модулей, которые просто приводят и так имеющийся функционал в приемлемый для реального использования вид.

Ну, от тебя то это слышать странно. Я сам сталкивался, когда магазин на 3к товаров еле открывался. Добавление индексов в базу его ускорило на порядок. Ну, и дело ж не только в проблемах с количеством. А оригинальная система ЧПУ? А куча весёлых багов? Если ожидание ответа сервера (TTFB) для тела страницы занимает больше 500мс - это уже не нормально! А генерация сайтмап - это вообще отдельная история. Каким идиотом надо быть, чтоб использовать для этого те же перегруженные методы моделей, которые выводят товары в каталог (и тянут тонны ненужной для сайтмапа информации подцепляя для этого ненужные таблицы). Ещё более странно, что со всей своей любовью к дублированию кода, Дэниэль поленился сделать отдельную модель для сайтмапа. Как это ещё объяснить, если не тем, что он не подозревает, что бывают магазины, где больше тысячи товаров (да и на тысячи такой сайтмап генерируется не особо моментально).

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

Кто-то в стилях покопался. Там в Бутстрапе есть такое правило: @media (min-width: 768px) .col-sm-6 { width: 75%; } Тут должно быть 50%. И правку делал явно школьник, иначе б не полез в файл бутстрапа, а просто переопределил, если уж понадобилось зачем-то такое значение. И с вёрсткой тоже косяк. У блока с id content должен быть класс col-sm-12, а не col-sm-6. А внутри должно быть не два col-sm-6, а col-sm-8 + col-sm-4.

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

Здесь есть список ошибок, в том числе и связанных с повреждённым архивом: http://php.net/manual/en/zip.constants.php Ошибка CRC будет указывать на повреждение данных.

Видать маленький у вас опыт общения с серверами. Есть куча разных серверов и их комбинаций и ещё большая куча вариантов, как они могут быть настроены. Данные, которые пых берёт у веб-сервера в массив $_SERVER могут называться не так, как вы ожидаете, могут иметь не те значения, которые вы ожидаете, их просто может не быть. Вот, например, посмотрите недавнее обсуждение связанное с $_SERVER['HTTPS']: https://opencartforum.com/topic/67981-%D1%80%D0%B5%D0%BB%D0%B8%D0%B7-ocstore-2302/?do=findComment&comment=627639 (от этого сообщения и почти до конца второй страницы). А про конфиги это не вы писали? У вас к раздельным конфигам в ОК, оказывается, притензий нет? Если бы вы внимательно читали, что вам отвечают, то поняли бы, что никакой это не постфактум и уж тем более не неожиданность:

Там должны быть те же данные, которые вы используете для подключение к хостингу через FTP клиент. Или вы ОК на сервер заливали в браузере через панель хостинга? Сервер на скрине точно указан неправильно и путь, я практически уверен, тоже. Если не знаете, что туда вписывать, спросите у поддержки хостинга.

Хранить вишлист в сессии бессмысленно: посетитель через пол часа вернётся на сайт, а вишлист уже пустой. Для незарегистрированных его нужно хранить либо в куки, либо в localStorage (лучше в последнем). Ну, и полноценное решение данной задачи чуть объёмнее, чем то, что можно просто подсказать на форуме. Этот модуль хранит в сессии. Но его можно взять за основу для реализации описанного мною выше варианта.

Ну как же при чём?! Разве упоминая в соседней теме Yii2, вы не хотели сказать, как в ОК всё плохо по сравнению с ним (в том числе)? Странно, что после Yii2 вы вообще упомянули про раздельные конфиги в ОК! Каждый раз звучит слишком громко. Для меня это, пожалуй, самый маленький недостаток ОК, который абсолютно не проблема устранить самостоятельно.

То есть, вы считаете, если ядро общее, то и конфиг должен быть обязательно общий сколько б приложений ни было? А с Yii2 вы, похоже, таки не знакомы, хотя в соседней теме говорили, что работали с ним.

Вы создали эту тему, чтобы призвать всех контрибутить в код ОК? :) Видимо, вы плохо знаете Дэниэля Керра (автор ОК). Если вы скажите ему, что в ОК что-то неправильно - он вам расскажет, какой вы аматор ничего не понимающий в разработке. Попробуете сделать пулл реквест с какой-то концептуальной правкой - он его отклонит без каких либо вразумительных объяснений.

Какие ошибки пишет, когда стоит локалхост? На скринах у вас ошибки связанные с неправильным хостом.

Настроить нормально FTP. Сделайте скрин своих настроек.

А в Yii2 вас конфиги не смущают? :) Вот уж где действительно весело. Смысл двух конфигов в том, что в ОК админка и каталог - два абсолютно разных приложения на общем ядре. Ну, у вас получился довольно уродливый вариант. Вы знаете, о существовании такой конструкции: dirname(__DIR__) ?

Вот так бы выглядело, например, получение данных товара: $product = Product::find()->where(['id' => '111'])->one(); А использование полученных данных выглядело бы так: $product->name $product->price Создание товара: $product = new Product; $product->name = $name; $product->price = $price; $product->insert(); А оптимизация происходит под капотом в зависимости от полученных параметров. Ну и Active Record - это наивысший уровень абстракции, где все данные представлены в виде объекта модели. Вот пример с меньшей абстракцией (выборка товаров из категории): $products = (new Query()) ->select(['id', 'name']) ->from('product') ->leftJoin('product_to_category', 'product.product_id = product_to_category.product_id') ->leftJoin('product_description', 'product.product_id = product_description.product_id') ->where(['product_category_id' => '55']) ->limit(10) ->all();

Это просто очень плохой пример. В реальности Active Record намного удобней, понятней и читабельней, чем голый SQL.

Ну, возьмём, например, какой-то метод в какой-то модели, где параметры передаются через массив $data. Как нам узнать, какие там могут быть параметры (имена) и какие у них могут быть значения? Да, узнать достаточно просто - просмотреть полотнище кода этого метода выискивая глазами все вхождения элементов из $data и по контексту пытаясь угадать, что там может быть. Либо искать, где этот метод используется в движке и смотреть, чем там заполняется массив параметров (а в разных местах он может заполняться разным набором элементов) И это всё конечно же "намного лучше", чем если б перед методом просто был комментарий содержащий список всех возможных элементов в $data и их возможных значений. Я уж не говорю, что иногда, чтоб понять, что возвращает какой-то метод в модели, нужно просмотреть весь его код. Повторяются только между admin и catalog. В остальном можно положиться на название класса, просто учитывая, что оно относительно текущей директории (admin или catalog). А есть для пыха что-то лучше? А зачем, если в phpStorm есть автовыгрузка при сохранении и при коммите?