Виправлення помилок

Як вам відомо, Magento 2 за замовчуванням пропонує численні опції для створення онлайн магазину, а також надає достатньо гнучкості, щоб його кастомізувати. Але в процесі все ж можуть виникати певні помилки. І ви, як розробник, маєте знати як їх виправити.

Однією з найпоширеніших помилок, з якими ви можете зіткнутися, є "An error has happened during application run. See exception log for details". Причини її появи можуть бути дуже різними. Тому, відповідно, рішення теж будуть варіюватися.

Як що вам цікаво, як вирішити цю помилку, тоді ви потрапили на правильну сторінку. Сьогодні ви дізнаєтеся більше про саму помилку і знайдете рішення, до якого зможете звернутися.

Що викликає помилку?

Як ми вже зазначали, "An error has happened during application run. See exception log for details" є однією з найбільш поширених помилок в Magento 2.

Вона зазвичай виникає після встановлення Magento 2. Однак, ви також можете зіткнутися з нею після оновлення Magento до вищої версії. 

Згадану помилку може

Перше, з чим ви стикаєтеся, коли керуєте багатомовним магазином Magento 2, це переклад контентних та комерційних сторінок. Це допомагає зробити ваш сайт зручним для кожного з ваших цільових клієнтів.

Контент, який ви створюєте та публікуєте на вітрині — це не єдиний контент, який потрібно перекладати. Ось чому вам потрібно створити словник перекладів (translation dictionary), щоб сформувати список текстів для перекладу в шаблонах електронних листів, третьосторонніх розширеннях, JS файлах, тощо.

Хоча наш модуль Magento 2 Translation Plus допомагає вам керувати та створювати цей словник перекладів, ви всерівно можете зіткнутися з помилкою Magento "Missed phrase".

В основному вона з’являється, коли ви намагаєтеся згенерувати словник перекладу під час виконання такої команди:

bin/magento i18n:collect-phrases --magento

Найчастіше помилка "Missed phrase" виникає через сторонні розширення, коли система намагається перекласти порожній рядок, наприклад __('').

Відповідно, щоб дізнатися, який модуль

Ні для кого не секрет, що швидкість веб-сайту є одним із найважливіших факторів рейтингу SEO не лише через саме завантаження, але й через його вплив на досвід користувачів. Ось чому вам потрібно постійно тестувати швидкість сайту з різними інструментами, щоб визначити проблеми, які уповільнюють роботу вашого магазину Magento 2.

Найпоширенішим інструментом, з яким знайомі всі є Google PageSpeed Insights або PSI. Він пропускає вашу URL-адресу через сервери Google і надає звіт про роботу вашого сайту.

Сьогодні ми хочемо звернути вашу увагу на повідомлення "Defer Offscreen Images", яка часто заважає вашому сайту потрапити в зелену зону PSI. Ми обговоримо, що це означає, і як ви можете виправити це , щоб покращити швидкість Magento.

Що означає "Defer Offscreen Images"?

"Defer Offscreen Images" — це повідомлення, яке відображається в Google PageSpeed Insights і містить перелік усіх зображень, які слід завантажувати відкладено за запитуваною URL-адресою. Він також показує потенційну економію

Працювати в магазині Magento не так легко як для розробників, так і для адмін користувачів, якими б завданнями вони не займалися. І хоча помилки Magento 2 це те, з чим ніколи не хочеться стикатися, ви можете зіткнутися з ними під час встановлення розширень Magento 2, оновлення Magento, створення різних запитів, пов’язаних з продуктом, запуск певного скрипта чи файлу, що не має дозволу на виконання.

Ці помилки в Magento можуть варіюватися від простих до досить складних, що впливають на продуктивність вашого веб-сайту та досвід користувачів. Однак у більшості випадків з ними відносно легко впоратися, якщо ви вчасно виявите, чому вони з’являються.

Отже, ця стаття є поясненням найпоширеніших помилок Magento, з якими ви можете зіткнутися. Знаючи причини і типи помилок ви можете уникнути їх у майбутньому.

Помилка Magento 1: Access Denied

Magento Access Denied HTTP error 403 найчастіше з’являється в адмін панелі Magento. Вона з'являється, коли ви намагаєтеся отримати доступ до сторінки, на яку

Проблема з deadlocks (deadlock issue) є однією з найбільших і найскладніших помилок Magento 2, з якою рано чи пізно стикається кожен розробник Magento. Коли ви почнете шукати, як вирішити проблеми з deadlocks в Magento, вам буде важко знайти хорошу інструкцію.

Отже, я припускаю, мабуть, це не перша стаття, з якою ви стикаєтеся. Але, сподіваюся, ви знайдете тут остаточну відповідь.

У цій статті ви дізнаєтеся все, що вам потрібно знати, щоб зрозуміти та вирішити проблеми з deadlocks. Або принаймні значно зменшити їх.

Чому індекси Magento стають недійсними?

Коли ви зіткнулися з проблемою Magento deadlock, перш за все перевірте індекси Magento та дізнайтеся, чому вони стають недійсними (invalidated). Для цього підіть у System > Tools > Index Management, переконайтеся, що ви правильно налаштували режим індексування та що ваші крони виконуються.

Режими індексування Magento

Magento має два режими індексування:

• Update on Save — реіндекс виконується під час збереження продукту (не рекомендується

Magento зберігає багато даних у базі даних для оптимізації роботи вашого магазину. Однак, як тільки ви оновлюєте будь-які з цих даних, система починає індексувати їх, щоб заповнити зміни в таблицях бази даних. Саме тоді у адмін панелі з’являється помилка "One or more indexers are invalid. Make sure your Magento cron job is running".

Це одна з найпоширеніших помилок Magento, з якою стикаються всі користувачі Magento під час роботи з нею.

Це може здатися просто дратівливим повідомленням в адмін панелі, але за цим стоїть набагато більше. Сьогодні ви дізнаєтеся, чому з’являється повідомлення "One or more indexers are invalid" і як це можна легко виправити з адмін панелі або через CLI.

Чому з'являється помилка "One or more indexers are invalid"?

Оскільки Magento є складною системою, у неї є спеціальна функція для автоматичного планування та виконання завдань магазину — Magento cron job. Крім розсилки листів та сповіщень, оновлення правил цін у каталозі та курсів валют, завдання cron також запускають

Працюючи з Magento 2, ви можете натрапити на численні помилки або повідомлення, які продовжують руйнувати або переривати процес керування системою. Однією з найпоширеніших помилок Magento є помилка Access Denied HTTP 403, яка з’являється під час роботи з адмін панеллю Magento 2.

Хоча багато хто з вас стикається з цією проблемою, мало хто дійсно знає, з чим вона пов’язана і як її вирішити. Отже, у цій статті ми надамо дійсно просте та швидке виправлення помилки "Access denied", щоб дозволити будь-кому з технічними навичками або без них легко впоратися з нею.

Однак давайте визначимо, що таке помилка Magento "Access denied" в першу чергу.

Що означає помилка Magento "Access denied"?

Помилка доступу Magento Access denied — це найпоширеніша помилка Magento, яка виникає, коли ви намагаєтеся отримати доступ до веб-сторінки, не маючи права на це. Зазвичай вона з’являється в адмін панелі Magento, коли ви використовуєте неправильні облікові дані адмін панелі, створюєте нового користувача з неправильною

Іноді, коли ви використовуєте Magento 2, ви можете отримати помилку Magento catalog_product_super_link table doesn`t exists . Вона з’являється через те, що якийсь модуль намагається зробити SQL запит із SQL query, який містить таблицю "catalog_product_super_link", а таблиці не існує. Тож насправді помилка сама себе пояснює.

Чому таблиці catalog_product_super_link може не існувати?

Ця таблиця визначена в модулі Magento 2 Magento_ConfigurableProduct. Тому, будь ласка, переконайтеся, що він увімкнений в app/etc/config.php. Якщо ні, увімкніть його, змінивши 0 на 1 у правій частині, наприклад:

'Magento_ConfigurableProduct' => 1,

Як і будь-яка помилка, що з’являється на будь-якому веб-сайті, внутрішня помилка сервера Magento 2 (internal server error 500) впливає на досвід ваших користувачів, трафік та конверсії. Хоча іноді вона може зникнути після перезавантаження сторінки, вам слід негайно усунути її, щоб вона не впливала на трафік вашого магазину годинами.

Це одна з найпоширеніших помилок Magento. Отже, перш ніж ми перейдемо до рішення для виправлення помилки 500 internal server error Magento 2, ви повинні знати, що це таке.

Що таке internal server error 500 у Magento 2?

Внутрішня помилка сервера Magento — це загальний HTTP status code, який з’являється, коли ви переходите за правильною URL-адресою або натискаєте посилання на веб-сайт і запитуєте сторінку з сервера. Щось йде не так, і сервер не може повернути запитувану сторінку і не знає, у чому проблема.

Оскільки сервер нічого не знає про проблему і відображає лише Internal Server Error 500, вам слід піти в журнал помилок сервера (server error logs), щоб отримати

Magento — це величезна платформа з великою кількістю функцій і коду відповідно. Отже, як і на будь-якій іншій платформі електронної комерції, ви зіткнетеся з помилками.

Magento Invalid Form Key. Please refresh the page – це одна з найпоширеніших помилок Magento, з якою ви, ймовірно, стикалися. Вона може з'явитися, коли ви:

• встановлюєте розширення Magento 2;
• оновлюєте Magento;
• створюєте обліковий запис на локальному хості;
• створюєте конфігурований продукт з багатьма дочірніми продуктами (child products);
• додайте багато пов'язаних, перехресних і додаткових (related, cross-sale, and upsell) продуктів до будь-якого з продуктів;
• зберігаєте атрибут з кількома параметрами;
• призначаєте багато пов’язаних продуктів і публікацій до статті в блозі.

Причиною, чому ви потрапили на цю сторінку є помилка Service Temporarily Unavailable у Magento 2, яка з’явилася, коли ви спробували зайти у адмін панель або на вітрину магазину.

Будь-які помилки, які з’являються у вашому магазині Magento 2, можуть коштувати вам не тільки часу, але й грошей. Тому вашим першочерговим завданням є усунення цієї помилки.

Коли ви встановлюєте новий пакет розширення у Magento 2 через композер, ви можете отримати наступну помилку:

[InvalidArgumentException] 
Package vendor/module-name exists in composer repo (https://repo.packagist.org) and composer repo (https://repo.magento.com) which has a higher repository priority. The packages with higher priority do not match your constraint and are therefore not installable. See https://getcomposer.org/repoprio for details and assistance.

Ця помилка пояснює сама себе і містить посилання на документацію композера.

Проблема в тому, що модуль, який ви намагаєтесь встановити, має стару версію у композер репозиторії Magento та нову версію у безкоштовній публічній репозиторії packagist.org. Проте репозиторія Magento має більш високий пріоритет, і тому композер не може встановити останню версію і викидає цю помилку.

Щоб вирішити цю помилку вам потрібно:

1. Відкрити файл composer.json у корені Magento 2.

2. Знайти розділ "repositories".

3. Замінити наступний код

"type": "composer",

Іноді, коли ви оновлюєте Magento, вона може змінити необхідні параметри областей (state parameters) та задати якісь обов’язкові області для кількох країн у Stores > Configuration > General. Більше того, цю опцію могли оновити ваші колеги або ви самі.

Якщо у вашому магазині Magento 2 з’являється повідомлення про помилку "An element with a “root” ID already exists", це, швидше за все, пов'язано з третьостороннім розширенням, яке викликає методи для повторного відтворення сторінки (page re-rendering).

Виконайте наступні кроки, щоб виправити помилку "An element with a “root” ID already exists":

1. Знайдіть PHP-файл і рядок, що викидає помилку (throw an exception).

2. Відкрийте CLI (термінал), перейдіть до кореневого каталогу Magento і виконайте наступні команди, щоб знайти потріний файл:

grep vendor/ -re ' ID already exists'
grep app/ -re ' ID already exists' 

Ви отримаєте результат, схожий до цього:

vendor/magento/framework/Data/Form.php: 'An element with a "' . $elementId . '" ID already exists.'
vendor/magento/framework/Data/Test/Unit/FormTest.php: $this->expectExceptionMessage('An element with a "1" ID already exists.');
vendor/magento/framework/Data/Structure.php: new \Magento\Framework\Phrase('An element with a "%1" ID already exists.',

Якщо ви використовуєте одне з розширень Amasty, напр. Amasty Layered navigation, ви можете зіткнутися з проблемою поламаних зображень блогу після їх завантаження.

Ми виявили проблему в розширені Amasty_Shopby, яке порушує роботу деяких інших розширень, що використовують завантаження зображень, включаючи й наше розширення блогу Magento 2.

Amasty_Shopby в наступному файлі:

app/code/Amasty/Shopby/etc/adminhtml/di.xml

додає плагін до моделі Magento\Catalog\Model\ImageUploader.

Судячи з коду в цьому файлі:

app/code/Amasty/Shopby/Plugin/Catalog/Model/ImageUploaderPlugin.php

виглядає на те, що Amasty додали якесь виправлення для Magento 2.3.4. і проблема полягає в плагіні beforeMoveFileFromTmp.

Оригінальна декларація Magento MoveFileFromTmp виглядає наступним чином:

public function moveFileFromTmp($imageName, $returnRelativePath = false)

і в плагіні Amasty не вистачає другого параметру $returnRelativePath:

public function beforeMoveFileFromTmp(\Magento\Catalog\Model\ImageUploader

У Magento 2 виникають ситуації, коли сторінка довго завантажєуться, і тоді ви отримуєте 500 фатальну помилку, обмеження пам’яті або помилку очікування (timeout error). Це  називається нескінченним циклом (infinite loop) в PHP-коді, коли той самий код виконується знову і знову. Це пов’язано з основними проблемами Magento або, швидше за все, третьостороннім розширенням .

Щоб виправити нескінченний цикл (infinite loop) і знайти вхід у цикл, виконайте наведені нижче дії:

1. Відкрийте файл app/bootstrap.php та додайте наступний код у наступному після відкриваючого PHP тегу <?php рядку: 

$_SERVER['MAGE_PROFILER'] = 'html';

2. Відкрийте файл vendor/magento/framework/Profiler.php та додайте наступний код на початок функції "public static function start($timerName, array $tags = null)" , напр.

Багато Magento магазинів дуже серйозно ставляться до швидкості сторінки, оскільки вона безпосередньо впливає на загальну продуктивність вашого веб-сайту. Тому всі постійно намагаються її вдосконалити і шукають найкращі способи це зробити.

Якщо ви перевіряєте швидкість свого веб-сайту в Google PageSpeed, ви можете зіткнутися із проблемою Serve images in next-gen formats. Відповідно до неї Google рекомендує зберігати зображення у форматах JPEG 2000, JREG XR та WEBP замість старих PNG та JPG. А найкраще - WebP.

Ніколи не чули про нього?

Дізнайтесь більше про те, що таке WebP, чому вам варто використовувати цей формат у вашому магазині Magento 2 та чим він відрізняється від PNG та JPG у цій статті про WebP зображення в Magento 2.

Якщо ви використовуєте модуль Magento 2 Блог із доданими featured images до публікації блогу, але ці зображення не відображаються на вітрині магазину, то, швидше за все, проблема у вашій темі. Багато тем містять власні макети для блогу та файли шаблонів, які переписують оригінальний вигляд. В них також може не бути деяких характеристик блогу як, наприклад, featured images. Щоб перевірити та виправити це, виконайте наступні кроки:

1. Відкрийте цей файл, якщо він існує (якщо його немає, пропустіть 2-3 кроки): 

/app/design/frontend/[ThemeVendor]/[themename]/Magefan_Blog/templates/post/list/item.phtml

2. Перевірте, чи файл містить код типу "getFeaturedImage". Ви можете знайти оригінальний код тут: 

https://github.com/magefan/module-blog/blob/master/view/frontend/templates/post/list/item.phtml
https://prnt.sc/tcl3sj

 3. Якщо цей код відсутній, додайте його до файлу вашої кастомної теми.

4. Відкрийте цей файл, якщо він існує (якщо його немає, пропустіть 5-6 кроки):

/app/design/frontend/

Якщо ви використовуєте розширення Magento 2 Блог і стикаєтеся з проблемою подвійних канонічних тегів на сторінках блогу, знайте, що це найчастіше відбувається, тому що ви використовуєте третьосторонні SEO модулі. І ці SEO модулі додають додаткові канонічні URL-адреси для сторінок вашого блогу.

Якщо SEO модуль, який ви використовуєте, є розширенням Mageworx SEO, вам потрібно перейти в Stores > Configuration > Mageworx > SEO Base > Canonical URL Settings та задати наступні елементи в полі Canonical URL won't be added for those pages:

blog_index_index
blog_post_view
blog_category_view
blog_archive_view
blog_author_view
blog_tag_view

Щойно ви їх додасте, другі канонічні URL-адреси не будуть задаватись для сторінок блогу. Натомість, будуть використані канонічні URL-адреси задані блогом.

Якщо ви використовуєте розширення для SEO від якоїсь іншої компанії, ми рекомендуємо вам зв’язатися з ними та попросити надати документацію або проконсультувати вас стосовно того, як видалити

"There has been an error processing your request" - це одна з найпоширеніших помилок Magento, яку ви можете отримати під час роботи з Magento 2. Ось приклад цього повідомлення:

Нещодавно ми отримали помилку "data-vocabulary.org schema deprecated and not supported by Google anymore. Please migrate to using schema.org types."  під час валідації однієї зі сторінок нашого веб-сайту. Таку ж саму помилку,  ми отримали і в Google Search Console.

Ця помилка "data-vocabulary.org schema deprecated" пов'язана з даними про структуру бредкрампів (breadcrumbs). Ми використовували схему "data-vocabulary.org/Breadcrumb" для структурованих даних, але Google більше її не підтримує.

Ви також можете отримати цю помилку, починаючи з 6 квітня 2020 року, якщо ви не конвертували свою структуровану схему даних з data-vocabulary.org на schema.org.

Перш ніж ми дійдемо до того, як виправити помилку "data-vocabulary.org schema deprecated", давайте прояснимо декілька речей.

Що таке структуровані дані?

Це специфічний HTML або JSON код на веб-сторінці, який допомагає роботам пошукових систем простіше аналізувати сторінку та краще структурувати іі вміст. Коли на вашій сторінці