Code Keeper

Проверь что у тебя из консоли выполняется 7.1, а не 7.2

Про какую именно компиляцию мы говорим?
Если про "компиляцию" как пример в первой, для увеличения производительности, то во второй такого нет. Если говорим про setup:di:compile то это необходимость для кодогенерации(я считаю что это было самое тупое решение со стороны мадженты), то она не отключается, а папки в которых она ищет файлы жестко забиты в коде и не конфигурируются как в symfony.

У тебя там какая-то дичь по конфигурации. Вот пример config.xml сделай по примеру и проверь.

Нужно делать еще один метод доставки. Именно метод доставки отвечает за расчет доставки для заказа.
https://inchoo.net/magento-2/creating-a-shipping-m...
https://www.mageplaza.com/magento-2-create-shippin...

Для начала можно попробовать решить проблему с помощью стандартных magento средств(без varnish)
devdocs.magento.com/guides/v2.0/config-guide/prod/...

Логичный вывод, что дело именно в теме, но ведь огромное количество шопов используют коммерческие темы, в том числе и market. Я так понимаю, если бы это было нерешаемо, никто бы не использовал такие темы, верно?

Я так скажу, что тема может идти в довесок с кастомными модулями, а там никто не застрахован от неоптимальных решений типа вызова напрямую objectManager, игнорирование proxy, игнорирования кеширования отдельных блоков и т.д.

Переводы находятся в папках i18n(тема, модуль, перевод), сделай поиск по проекту по фразе Search for product. Переводы могут быть как в файле csv так и в файле js поскольку со старой версии отдельно переводы для js компонентов. Так же фраза может не перевестись сели она не обернута в глобальную функцию перевода __()

devdocs.magento.com/guides/v2.0/frontend-dev-guide...
devdocs.magento.com/guides/v2.0/frontend-dev-guide...

Вангую, что cron со стороны сервере вообще не настроен. inchoo.net/magento-2/running-cron-jobs-in-magento-2

Для начала нужно понимать что такое EAV сущности и как они работают.
https://alanstorm.com/magento_advanced_orm_entity_...

Extesndion Attribute не что иное как eav атрибут для сущности и работать с ним можно так же как и с любым другим Eav атрибутом.

Сделав реализацию для Repository, для чтения и записи отдельно, - а как вы думали?

Что еще за отдельная реализация?

внезапно оказывается что в коллекциях атрибуты... правильно, === null. Не, ну а кто любит чтобы сразу и удобно.

Нет, методы добавить-то можно, но атрибуты могут быть не загружены что убивает всю возможность

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

Предлагают загружать сущность [заказ] еще раз. Отлично, после стольких оптимизаций разработчикам приходится загружать сущности на каждом углу ради атрибутов.

Потому что они не знают про то как работает EAV и про addAttributeToSelect

$collection->addAttributeToSelect('unit_of_sale', 'catalog_product_entity_varchar')

Проверь наличие .htaccess в папке pub/static а так же что модуль mod_rewrite подключен если используется apache. Если nginx то конфиг для него лежит в корне magento

https://symfony.com/doc/current/form/embedded.html

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

как это сделать? НУ первое поискать где в импорте создается продукт и попробовать подлезть туда или с помощью observer или plugin'ом. В противном случае зареврайтить и расширить класс.

Почему нельзя сделать уникальные ключи?
Например

<handlers>
    <{handler1_alias}>SomeHandler</{handler1_alias}>
    <{handler2_alias}>SecondHandler</{handler2_alias}>
</handlers>

Как один из вариантов, сделать конфиг с кастомным env, например config_db2.yml, в котором указать нужную бд и делать миграцию с ключем --env db2.

Второй вариант, залезть внутрь бандла отвечающего за миграции и посмотреть каким образом он достает конфига к бд.

Нужно вывести все мини-карточки товаров в едином шаблоне

Я правильно понимаю что под словом "мини карточки товаров" имеется ввиду - вывести так как на категориях, только весь товар без фильтра по данным категориям?

Или это сделать в виде модуля

Если то что я описал выше верно, то да это лучше сделать в виде модуля с отдельным контроллерои и темплейтом для вывода, что бы не нарушить основную логику работы magento

Есть задача на группировку заказов с возможностью выводить эти заказы в группе.

Не совсем понятно о каких группах идет речь?

docs.doctrine-project.org/projects/doctrine-mongod...