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

Як вам відомо, 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 до вищої версії.  Згадану помилку може викликати багато різних причин. Наприклад, не точне підключення

Перше, з чим ви стикаєтеся, коли , це переклад контентних та комерційних сторінок. Це допомагає зробити ваш сайт зручним для кожного з ваших цільових клієнтів. Контент, який ви створюєте та публікуєте на вітрині — це не єдиний контент, який потрібно перекладати. Ось чому вам потрібно створити словник перекладів (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. Ми обговоримо, що це означає, і як ви можете виправити це , щоб . Що означає "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. Коли ви почнете шукати, як вирішити проблеми з deadlocks в Magento, вам буде важко знайти хорошу інструкцію. Отже, я припускаю, мабуть, це не перша стаття, з якою ви стикаєтеся. Але, сподіваюся, ви знайдете тут остаточну відповідь. У цій статті ви дізнаєтеся все, що вам потрібно знати, щоб зрозуміти та вирішити проблеми з deadlocks. Або принаймні значно зменшити їх. Чому індекси Magento стають недійсними? Коли ви зіткнулися з проблемою Magento deadlock, перш за все перевірте індекси Magento та дізнайтеся, чому вони стають недійсними (invalidated). Для цього підіть у System > Tools > Index Management, переконайтеся, що ви правильно налаштували режим індексування та що ваші . Режими індексування Magento Magento має два режими індексування: Update on Save — реіндекс виконується під час збереження продукту (не рекомендується вмикати цей режим у production, оскільки

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 є складною системою, у неї є спеціальна функція для автоматичного планування та виконання завдань магазину — . Крім розсилки листів та сповіщень, оновлення правил цін у каталозі та курсів валют, завдання cron також запускають переіндексацію.

Іноді, коли ви використовуєте 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, Потім виконайте наступні команди: bin/magento setup:upgradebin/magento setup:di:compilebin/magento setup:static-content:deploy Якщо це не допомогло, то ви можете створити таблицю за допомогою цих запитів SQL (ви можете запустити їх, наприклад, у phpMyAdmin): Увага! Замініть "prefix_" і "PREFIX_" вашим фактичним префіксом бази даних Magento 2 або просто видаліть їх, якщо

Як і будь-яка помилка, що з’являється на будь-якому веб-сайті, внутрішня помилка сервера Magento 2 (internal server error 500) впливає на досвід ваших користувачів, трафік та конверсії. Хоча іноді вона може зникнути після перезавантаження сторінки, вам слід негайно усунути її, щоб вона не впливала на трафік вашого магазину годинами. Це одна з . Отже, перш ніж ми перейдемо до рішення для виправлення помилки 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; створюєте обліковий запис на локальному хості;  з багатьма дочірніми продуктами (child products); додайте багато пов'язаних, перехресних і додаткових (related, ) продуктів до будь-якого з продуктів; зберігаєте атрибут з кількома параметрами; призначаєте багато пов’язаних продуктів і публікацій до статті в блозі. Отже, в основному, помилка "Magento Invalid Form Key. Please refresh the page" з’являється, коли велика кількість даних передається на сервер під час надсилання форми. Ця стаття допоможе вам зрозуміти причини помилки сторінки "Invalid Form Key. Please refresh the page" в Magento і як ви можете легко її виправити. Чому з'являється помилка "Invalid Form Key. Please

Причиною, чому ви потрапили на цю сторінку є помилка Service Temporarily Unavailable у Magento 2, яка з’явилася, коли ви спробували зайти у адмін панель або на вітрину магазину. Будь-які помилки, які з’являються у вашому магазині Magento 2, можуть коштувати вам не тільки часу, але й грошей. Тому вашим першочерговим завданням є усунення цієї помилки. Для тих, хто стикається з цією помилкою або хоче дізнатись про неї заздалегідь, ми надаємо швидше рішення. Чому з'являється помилка Magento 2 Service Temporarily Unavailable? Помилка 503 Service Temporarily Unavailable у Magento 2 є однією з . Вона з’являється, коли ви , пробуєте налаштувати свій магазин Magento 2 або оновити Magento. Помилка Service Temporarily Unavailable зазвичай супроводжується такими повідомленнями: The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. The server is temporarily unable to handle the request. Це дає нам усе необхідне, щоб зрозуміти

Коли ви встановлюєте новий пакет розширення у 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","url":

Іноді, коли ви оновлюєте Magento, вона може змінити необхідні параметри областей (state parameters) та задати якісь обов’язкові області для кількох країн у Stores > Configuration > General. Більше того, цю опцію могли оновити ваші колеги або ви самі. Якщо у вас є магазин Magento 2, у вас є користувачі, які вже задавали адреси доставки та оплати під час здійснення покупки. Їхні адреси, збережені у вашому магазині, вже включають країну, але не мають заданих областей (регіонів). Крім того, іноді область задається як текстове поле (а не select box). Коли ви оновлюєте Magento, вона змінює обов'язкові області (required states) або ви задаєте їх для ряду країн самостійно.Таким чином, області будуть обов'язковими для задавання, навіть якщо у вашого користувача вже задано адресу з параметрами країни. Які у цьому недоліки? Коли ці користувачі хочуть знову зробити покупку, у них виникають труднощі при оформленні замовлення. Вони бачать повідомлення про те, що їхня адреса є невалідною і змушені йти

Якщо у вашому магазині 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)" , напр. private static $firsttime = null; public static function start($timerName, array $tags = null){    if (!self::$firsttime) {         self::$firsttime = time();     }    

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

Якщо ви використовуєте модуль 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.phtmlhttps://prnt.sc/tcl3sj  3. Якщо цей код відсутній, додайте його до файлу вашої кастомної теми. 4. Відкрийте цей файл, якщо він існує (якщо його немає, пропустіть 5-6 кроки): /app/design/frontend/[ThemeVendor]/[themename]/Magefan_Blog/templates/post/view.phtml

Якщо ви використовуєте розширення 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_indexblog_post_viewblog_category_viewblog_archive_viewblog_author_viewblog_tag_view Щойно ви їх додасте, другі канонічні URL-адреси не будуть задаватись для сторінок блогу. Натомість, будуть використані канонічні URL-адреси задані блогом. Якщо ви використовуєте розширення для SEO від якоїсь іншої компанії, ми рекомендуємо вам зв’язатися з ними та попросити надати документацію або проконсультувати вас стосовно того, як видалити канонічні

"There has been an error processing your request" - це одна з , яку ви можете отримати під час роботи з Magento 2. Ось приклад цього повідомлення: Найбільш поширені причини появи повідомлення "There has been an error processing your request"? Встановлення нової теми або розширення Magento 2. Оновлення розширення Magento 2 або Magento 2. Зміни в коді шаблону. Встановлення налаштувань. Перевантаження пам'яті сервера. Отже, якщо ви виконали будь-яку із вищезазначених дій, ви можете побачити повідомлення про помилку Magento за замовчуванням "There has been an error processing your request", так як exception printing вимкнено з міркувань безпеки. Хоча ви бачите це повідомлення, ви все ж не знаєте, яку помилку слід виправити. Для того, щоб виправляти, спочатку потрібно з’ясувати джерело проблеми. Виправлення помилки "There has been an error processing your request"    Виконайте наступні кроки, щоб виправити помилку "There has been an error processing your request" у 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 код на веб-сторінці, який допомагає роботам пошукових систем простіше аналізувати сторінку та краще структурувати іі вміст. Коли на вашій сторінці

Якщо ви використовуєте Magento 2 і отримуєте таку помилку: Warning: file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages:error:14095126:SSL routines:ssl3_read_n:unexpected eof while reading in vendor/google/recaptcha/src/ReCaptcha/RequestMethod/Post.php on line 72Trace:<pre>#1 file_get_contents() called at [vendor/google/recaptcha/src/ReCaptcha/RequestMethod/Post.php:72]#2 ReCaptcha\RequestMethod\Post->submit() called at [vendor/google/recaptcha/src/ReCaptcha/ReCaptcha.php:156]#3 ReCaptcha\ReCaptcha->verify() called at [app/code/MSP/ReCaptcha/Model/Validate.php:79]#4 MSP\ReCaptcha\Model\Validate->validate() called at [app/code/MSP/ReCaptcha/Observer/ReCaptchaObserver.php:93]#5 MSP\ReCaptcha\Observer\ReCaptchaObserver->execute() called at [vendor/magento/framework/Event/Invoker/InvokerDefault.php:72]#6 Magento\Framework\Event\Invoker\InvokerDefault->_callObserverMethod() called at [vendor/magento/framework/Event/Invoker/InvokerDefault.php:60]... намагаючись ввійти