Dotrox

А можно это как-то перефразировать, чтоб было понятно не только вам? Да вопрос не в цифрах. У Мозиллы, например, есть беты, ночные сборки, до недавнего времени ещё была Аврора. У Хрома - Канарейка. Смысл в том, что если есть версии для ознакомления и тестирования в кругу продвинутых пользователей, но не для массового использования, то это должно чётко выделяться. А не выпускать под видом полноценного релиза то, что даже не бету не тянет (как в случае 2.0).

Ну, так если Дэниэль сам не знает, что там добавили и не умеет использовать новые возможности даже последних версий пятёрки, не то, что семёрки, то какой ему смысл поднимать требования до актуальной версии? Кажется, я нашёл недостающее звено. Я изначально смотрел в сторону массивов, которыми ОК действительно сильно злоупотребляет, но не увидел изменений, которые бы могли затронуть ОК с его ассоциативными массивами. Хеш таблицы и zval - это как раз недостающее звено между ассоциативными массивами и packed arrays c интежер ключами, которые дают существенный прирост производительности в семёрке.

Читайте внимательней: https://github.com/opencart/opencart/issues/5102#issuecomment-300260066 Или у вас какая-то секретная информация о планах вообще не релизить 3.0 и сразу выпустить 3.1? В каком смысле?

Так, а при чём тут освоение? Чтоб переключиться на новую версия не обязательно знать все её новые фичи. Код написанный под 5.3 будет спокойно работать и под 7.0, если автор обращал внимание на рекомендации и депрекейтед уведомления.

Для кого? Разработчики и так могут наблюдать за ходом работы на Гитхабе и взять оттуда код при желании потестировать, а конечных пользователей к этой версии подпускать нельзя. Ну, и в любом случае это делается не так. Например, у Nginx есть ознакомительные версии - каждая нечётная версия не предназначена для продакшн использования и не попадает в стабильные репозитории. И это официальная концепция, которая известна всем, кто достаточно продвинут, чтоб устанавливать софт не из стандартных репов (а остальные до этих версий просто не доберутся). А у ОК получается, что это что-то прописанное между строк и известное только тем, кто и так наблюдает за Гитхабом ОК. Например, сколько людей установило себе 2.0, и многие до сих пор на ней сидят! И с 3.0 будет та же история. А для кого он тогда вообще работает? Или это надо перефразировать как "если вы такие дураки, что пользуетесь ОК, то сами виноваты"? Мне кажется, он вообще не понимает смысл опенсорса.

@DronENG , здесь все и без вас умеют пользоваться Гуглопереводчиком. Более того, у большинства в этой теме (по крайней мере, я на это надеюсь) даже нет необходимости им пользоваться, чтоб прочитать это в оригинале. А вот то, что вы выложили - это бессмысленный набор слов. Twig ещё легче в освоении! А на счёт скорости: в той статье сравнивается Smarty 3.1.1 и Twig 1.2.0, в то время как актуальные версии 3.1.30 (релиз в августе прошлого года) и 2.3.2 (релиз меньше месяца назад), соответственно. Возможно у Smarty за эти 6 лет и не произошло каких-либо заметных изменений (и вообще, похоже, он уже почти мёртвый), но у Twig сменилась мажорная версия, так что глупо что-то доказывать статьёй шестилетней давности, где предыдущая ветка. Я не вижу связи между Twig и маркетплейсом. Маркет могли влепить и без добавления Twig. Что и всегда. Велосипедостроение - это характерная черта ОК. Но меня больше "радует" другое: если в 3.0 не будет кеширования, потому что он пишет собственный кешер шаблонов, который появится в 3.1, то зачем вообще выпускать 3.0? То есть, вот этот его подход, когда он выпускает версии просто так, чтоб были, но не для реального использования. История с 2.0 повторяется.

А ещё легче не делать предположений высосанных из пальца! Работы там почти никакой, только поставить php-fpm, что делается одной командой в терминале и конфиг nginx поправить. В плане самого ОК вообще ноль изменений. Два из трёх бенчмарков там показали приблизительно одинаковую разницу между 5.3 -> 5.4 и 5.6 -> 7.0. А многие до сих пор сидят на 5.3. Но в любом случае, это тесты без I/O, так что реальная разница для ОК не должна была быть такой ощутимой. Разве что ОК очень сильно злоупотребляет чем-то, что в семёрке сильно оптимизировали.

https://github.com/opencart/opencart/issues/5382 В общем, дело таки в пустой строке. Надо самостоятельно установить место хранения сессий.

Тогда ошибка должна быть ещё в конструкторе. И путь странный. Будто session_save_path() возвращает пустую строку.

Я думаю, лучше всего с проблемой поможет автор модуля

С чего вы это взяли? Я ни разу не использовал WooCommerce (как и сам WP) для создания магазинов, но работать с ним всё же приходилось (поскольку часто приходиться допиливать чужие работы). И я могу однозначно сказать, что никогда бы не взял WooCommerce (как и сам WP) при самостоятельном выборе основы для магазина. Но это не значит, что за недостатками я должен закрывать глаза на всё остальное. На самом деле, главный недостаток WooCommerce - это сам WP и желание разработчиков WooCommerce максимально следовать его стандартам. В результате получается, что все объекты магазина (товары, заказы) реализованы через посты. Это создаёт хаос в БД и существенные дополнительные расходы на обработку этого хаоса. Ну и, плюс в код примешивается функциональный стиль, но это уже "религиозный" вопрос. Но, в плане кода, если закрыть глаза на особенности продиктованные WP, WooCommerce всё же на чуть более высоком уровне, чем ОК. Нет. Достаточно даже вышеописанного нюанса с товарами/заказами и базой, чтоб категорически не рекомендовать его. А вдобавок сам WP, который я бы тоже не рекомендовал. При чём не из-за таких "религиозных" причин, как глобальные переменные и функциональный стиль (хотя глобальные переменные, на самом деле, не просто так были признаны злом), а из-за более практичных недостатков: например, его алгоритм работы с плагинами, когда загружаются сразу все, даже если не все они нужны для обработки текущего запроса (отсюда и лишнее потребление ресурсов и возможность для любого плагина из-за внутренней ошибки завалить весь сайт с админкой полностью, даже если сам плагин реально используется в каких-то совсем редких случаях). Это лучше вы подумайте, почему он так сделал. А сделал он так потому, что неймспейсов в пыхе не было на момент выхода ОК. То есть, он их в принципе не мог использовать. Ну, а не использование неймспейсов сейчас воспринимается ничем не лучше, чем функциональный стиль. И неймспейсы - это не какое-то сомнительное новшество, а то, что в других языках является абсолютным стандартом. Например, в Python нечто подобное реализовано изначально в виде модулей: import os print(os.getcwd()) #print current working dir И альтернатив там просто нет! Хотя с новшеством это я загнул, неймспейсы в пыхе появились ещё в далёком 2009. И тоже уже стандарт: например, любая библиотека, устанавливаемая через композер (который тоже стандарт) их использует по умолчанию. Чего в ОК никогда не было и нет до сих пор. И уже никогда не будет, потому что с событиями в этом отпадает смысл. Но главный вопрос в другом: вы ведь не понимаете как работают неймспейсы? Иначе вы бы знали, что в случае неймспейсов с этим тоже нет никаких проблем! Ну, и override - это плохая практика. В PrestaShop давно был подобный механизм, но в 1.7 разработчики призвали отказаться от него (хотя он не удалён) и использовать вместо подмены стандартного кода его расширение. Более того, и раньше в доках была рекомендация использовать оверрайд исключительно для собственных проектов, но никак не для коробочных модулей для распространения! Кстати, пока в ОК существуют модификаторы, использование какого-либо механизма оверрайда, в принципе, невозможно, потому что получиться, что модификатор модифицировал стандартный файл, а лоадер загрузил кастомный. А раз Дэниэль сделал модификаторы частью ОК, то о каком оверрайде может вообще идти речь? "Архитектура, архитектура" и других слов вы не знаете. Перефразируя известную поговорку: за архитектурой кода не видно Вы ведь так и не смогли ответить на мой вопрос, какой дизайн паттерн использует ОК (и нет, речь не про MVC, который, кстати, вообще не паттерн дизайна), зато слово "архитектура" не устаёте повторять, ничего при этом в ней не понимая. Кстати, вы тут так затаптывали фреймворки, но для справки: Дэниэль, которым вы так восхищаетесь, содрал архитектуру ОК, которой вы так восхищаетесь, у CodeIgniter, первый релиз которого вышел как раз перед тем, как Дэниэль начал работать над ОК (и он этого не отрицает). Но увы, сдирать оттуда Query Builder он поленился (а он там есть). И за 11 лет в ОК эта архитектура так и осталась неизменной. CodeIgniter, кстати, в отличии от ОК поддерживает override. А CodeIgniter - это отличный пример смерти от устаревания: в своё время он был достаточно популярным, сейчас же он практически не используется. И это при том, что его разработка не прекращена.

Под семёрку на самом деле нет Девятый энкодер поддерживает кодирование под интерпретатор семёрки, но не поддерживает новые возможности семёрки. Поддержка именно возможностей будет в десятом энкодере. Но, конечно, в данном случае это не имеет значения поскольку возможности и так не используются, если модуль написан под пятёрку. Но, мне кажется, что далеко не все понимают эту разницу, отсюда и растут ноги мнения, что ИонКуб не поддерживает семёрку.

Там может быть BOM. Хотя, если вы этот файл сами не редактировали, то не должно. Пересохраните этот файл в кодировке UTF-8 без BOM.

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

Это какой-то эпический фейл Вы выдрали геттер - один из базовых компонентов ООП. Ну да, если вы не знаете, что такое неймспейсы, то для вас это, конечно, бред

А почему Magento? Почему не PrestaShop? Или всё дело в том, что PrestaShop наиболее популярен в Западной Европе и разводить демагогию о населении уже не получится? И если уж вы хотите мерить населением, то где ОК имеет наибольшую популярность: СНГ и... те же Индия с Китаем! Да, хорошо, что напомнили. Вот https://github.com/woocommerce/woocommerce/tree/master/includes Открываем любой файл, название которого начинается с class и что мы видим? А что же мы видим, пусть каждый желающий сам посмотрит. И, кстати, о ужас, код документирован - ещё одно "зло", которого в ОК нет. Ну, а в плане того, что наскребли вы: не стоит забывать, что WooCommerce - это всё же плагин к WP и он не может совсем игнорировать то, что диктует WP. А я не только "здесь" что-то делаю! Если вам сильно интересно, то вот список того, с чем мне в той или иной степени приходилось работать. PHP: OpenCart, PrestaShop, osCommerce, Joomla, WordPress, Drupal, MODX, Yii, отдельные компоненты Symfony. Python: Flask, Django. Так что мне есть с чем сравнивать. И да, ОК в моём рейтинге не последний в списке, но совсем не потому, что он такой идеальный, а просто потому, что он не самый худший. Кстати, WP, с которого вы постоянно стебётесь, очень давно имеет систему расширений похожую на события, благодаря которой он без проблем обновляется, а плагины сохраняют полную совместимость на протяжении многих версий. И установка плагинов из маркета, которую сейчас впиливают в ОК у WP тоже есть очень давно. И ОК не только в этом идёт стопами WP, но и в устаревании кодовой базы. Когда WP вышел в первой половине нулевых, и глобальные переменные и функциональный стиль - это всё было нормой, он просто не успел во время избавиться от этих архаизмов. То же самое происходит сейчас с ОК. Простой примитивный пример. Как сейчас: $this->load->model('catalog/product'); $product_info = $this->model_catalog_product->getProduct($product_id); Как должно быть: $product = new \Model\Catalog\Product(); $product_info = $product->getProduct($product_id); В идеале, должно быть даже не так, потому что модель не должна быть свалкой функций (что вы там говорили, вам в WP не нравится? ) и тогда вместо getProduct будет просто find. Я ж молчу, какой из вариантов просто легче для понимания. При чём, просто интуитивно легче, а не потому, что второй вариант описан в PSR. Правда, кое в чём ОК всё же "превзошёл" WP: у WordPress никогда не было такого идиотизма, как модификаторы! И история с модификаторами - это иллюстрация, почему ОК в итоге загнётся: Дэниэль видит, что из-за отсутствия в ОК нормальной системы расширений люди начали использовать костыль в виде vQmod и что он делает? Может быть нормальную систему расширений (было бы довольно логично)? Нет, он делает свою собственную версию vQmod и интегрирует её в ОК! Наверное, если бы он был на месте Форда, то вместо авто начал бы производство лошадиного допинга.

Тем не менее, если кто-то уже перенёс магазин на php7, его не волнует, что там официально поддерживается движком - его волнуют модули. Так что смысл в этой идее есть. Но лучше всё же писать не совместимость с php7, как отдельную опцию, а просто список поддерживаемых версий php, потому что даже в рамках пятой версии не всё однозначно, но главное, что на php7 изменения то не останавливаются. Кроме того, к тому времени, когда в ОК появится поддержка семёрки, уже будет php8 Переход с какой именно версии? Там же и в рамках пятой версии от 5.4 до 5.6 каждая следующая версия наращивала производительность по сравнению с предыдущей. Хотя основной скачёк, вроде, был между 5.3 и 5.4. Слабо верится, что разница даже в полтора раза может быть при переходе с 5.6 на 7.0 (разве что на 5.6 опкеш был зачем-то выключен). Код ОК слишком примитивен для такой разницы.

Эти ошибки не попадают в лог ОК, ищите их в логе сервера. А где он у вас - знает только хостер.

Всё сложнее: он не видит разницу между простотой и примитивностью. DRY - это простота, а многократно повторяющаяся лапша - это примитивность, но Дэниэль уверен, что отсутствие лапши - это уже слишком сложно (и это почти цитата из его ответов на упрёки в тоннах лапши в ОК). Среди школоты А в код 80% модулей страшно заглядывать. Magento как-то умудрился стать популярным и без простоты (даже без намёков на неё). И с PrestaShop та же история (хотя он всё же попроще Magento, но до "простоты" ОК ему ооочень далеко). Стоит напомнить, что когда-то мегапопулярным был osCommerce, где была и простота и куча форков (а-ля сборок) и толпы школоты роились вокруг, а теперь над ним только мухи роятся. PrestaShop прямо сейчас переходит на Symfony! В результате имеем, что два из трёх самых популярных коробочных e-commerce движков на фреймворках. И тот третий лишний - это ОК. Вы, наверное, не понимаете, что в сегменте низкобюджетного старта, который всегда был для ОК основной нишей, сейчас происходят кардинальные изменения (самый яркий пример Shopify) и в конечном счёте этот сегмент переместиться на SaaS. А у Дэниэля никакого SaaS не получится, ибо SaaS - не для любителей "простоты". А для крупного бизнеса ОК в текущем виде не пригоден (и без фреймворка не будет пригоден, потому что фреймворк, кроме прочего, обеспечивает ещё и качество и актуальность кодовой базы). У каждого, кто видел это ваше заявление, теперь каждый раз, когда вы будете называть себя профессионалом - будет вырываться истерический хохот! Если б вы сделали хотя бы один проект на фреймворке, вы бы никогда так не сказали! Вы вообще понимаете, что такое фреймворк? ОК - это даже не CMF! А то, что на нём делают не только магазины, а всё подряд, так это эволюция "программистов одного языка": раньше люди ограничивались одним языком, который использовали для всего подряд, а теперь вообще одной CMS. Собственно, результатом именно этой эволюции деградации мы и имеем WP (WooCommerce) как один из самых популярных e-commerce движков. Зачем разбираться со специализированным e-commerce движком (тем же ОК), если уже знаком с WP? И люди делающие на WP магазины тоже будут уверять, что используют WP для всего подряд не потому, что больше ничего не знают и не хотят учить, а только лишь потому, что WP - это почти предел совершенства. Я ещё не видел ни одного модуля устраняющего лапшу в ОК (это ирония, ибо такой модуль перелопатил бы все файлы попутно сломав совместимость со всеми модулями, которые работают через модификаторы). Вопрос то совсем не в функционале, а в качестве кода! Не хорошо так отзываться о самом популярном на текущий момент e-commerce решении Это ведь такой хороший пример популярного e-commerce движка без фреймворка!

Есть ещё https://craftcommerce.com/ - расширение к CraftCMS, который на Yii (но версия на Yii2, вроде, ещё в разработке). Минимальная лицензия стоит 700 баксов и CMS тоже не бесплатна, если не для персонального использования (сделать сайт не для себя, а для кого-то). Но код в открытом доступе, так что посмотреть можно. Перенос на Yii2 не увеличит порог входа (хотя зависит от фантазии переносящего), а стоимость доработок наоборот уменьшиться (по крайней мере уменьшится затрачиваемое на них время, а остальное уже вопрос жадности ), потому что большую часть работы будет выполнять либо сам фреймворк, либо тонна его бесплатных расширений. Вы не представляете, как смешно звучит эта фраза! Он упрям настолько, насколько это вообще возможно. И не только читает, но и отвечает периодически, рассказывая всем, кто критикует довольно очевидные недостатки, что они все аматоры и ничего не понимают и именно то, как есть сейчас - это совершенно идеальное решение. Если определять направление развития кодовой базы будет и дальше Дэниэль, то ОК в конце концов загнётся и этот конец настанет не позднее четвёртой версии, если она от третей будет отличаться настолько же, как третья от второй.

Ну, этот пример то правильный, но здесь ведь нет QueryBuilder Всё происходит через User, который потомок ActiveRecord. Кроме того, это модель поиска - она не является репрезентацией объекта User (все атрибуты и правила их обработки уже объявлены в классе User). А методы типа andFilterWhere - это часть QueryTrait, который используется многими классами, в том числе ActiveQuery, который под капотом у ActiveRecord. QueryBuilder - это более низкоуровневый интерфейс, вся суть которого отражена в названии: он просто помогает писать запросы к базе не используя в коде SQL (без крайней необходимости). Главное логическое отличие между ActiveRecord и QueryBuilder в том, что ActiveRecord понимает с чем он работает и знает как правильно эти данные обрабатывать, а QueryBuilder - просто абстракция над SQL, для которой все данные формально одинаковы. Для получения максимальной пользы от фреймворка нужно использовать именно ActiveRecord, потому что QueryBuilder добавляет много механической работы (а точнее, он её в отличии от ActiveRecord не убавляет). В случае ОК даже интеграция QueryBuilder была бы уже значительным шагом вперёд (и реализовать можно было бы достаточно безболезненно, хотя и пришлось бы проделать большую механическую работу), но если писать новый движок, который должен ощутимо превзойти ОК, надо постараться использовать ActiveRecord.

Ну, одно другому не мешает. Главное, чтоб проверка лицензий не влияла на работу сайта. В остальном к лицензиям нет претензий.

ActiveRecord, как любая ORM, требует изначальной информации о всех существующих полях, их типах и правилах работы с ними. Именно это позволяет большую часть работы делать автоматически и без необходимости писать какой-то дополнительный код, например, для валидации. Так нельзя делать. Если Product - это потомок ActiveRecord, он не должен использовать QueryBuilder. По крайней мере не для работы с собственными же полями! Да и такая смесь сильно усложнит архитектуру моделей. Для начала нужно попытаться реализовать всё через ActiveRecord. Если окажется, что это невозможно, тогда использовать только QueryBuilder. Собственно, вопросов на самом деле достаточно много. Взять Yii2 и написать на нём магазин для собственного использования - это не проблема, но вот сделать публичный движок - это уже совсем другая история (и вместо Yii2 можно подставить название любого фреймворка - это не изменит суть).

Исходники - это отдельный вопрос. Эта тема возникла не из-за ИонКуба. А главный вопрос - модули по прежнему проверяют лицензию в реальном времени с вашего сервера при каждой загрузке страницы?

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