Іноді, коли ви оновлюєте 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\F
Якщо ви використовуєте одне з розширень 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
У 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
http
Якщо ви використовуєте розширення 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
"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.
Перш ніж ми дійдемо до того, як ви
Якщо ви використовуєте 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 ven dor/google/recaptcha/src/ReCap tcha/RequestMethod/Post.php on line 72
Trace:
<pre>#1 file_get_contents() called at [vendor/google/recaptcha/src/ReCaptcha/RequestMethod/Post.ph p:72]
#2 ReCaptcha\RequestMethod\Post->submit() called at [vendor/google/recaptcha/src/R eCaptcha/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/Observ er/ReCaptchaObserver.php:93]
#5 MSP\ReCaptcha\Observer\ReCaptchaObserver->execute() called at [vendor/magento/framework/Even t/Invoker/InvokerDefault.php: 72]
#6 Magento\Framework\Event\Invoker\InvokerDefault->_callObserve rMethod() called at [vendor/magento/framework/Even t/Invoker/InvokerDefault.php: 60]
...
намагаючись ввійти в адмін панель, встановити новий пароль користувача, створити новий обліковий запис користувача тощо, ви можете швидко виправити ситуацію. Для цього виконайте наведені нижче дії:
У Magento 2 Блог v2.9.3 ми додали функцію, про яку запитували багато клієнтів, це «використання шаблону пов'язаних продуктів із каталогу за замовчуванням» (default catalog related products template) замість кастомного шаблону пов'язаних продуктів блогу. Це допомагає автоматично відображати пов'язані продукти на сторінці публікації блогу в дизайні теми. Коміт (commit), пов'язаний з цією зміною, можна знайти на GitHub.
На жаль, для Magento 2 існує тисячі тем і деякі з них мають специфічні JS та CSS (наприклад, тема Porto). Ось чому, якщо ви використовуєте розширення Blog 2.9.3 або новішої версії і блок пов'язаних продуктів виглядає дивно
Сьогодні (12 лютого 2020 р.) Ми отримали повідомлення про потенційну проблему безпеки в нашому модулі Magento 2 Login As Customer завдяки твіту Даніеля Слофа.
Переглядаючи код та спілкуючись з Дерріком Хісбіном, Льюїс Вонкен з сайту experus.nl виявив проблему в безпеці.
Зауважте, що дотепер жодної підтвердженої атаки, пов’язаної з цією проблемою, не відбулося, однак зловмисники потенційно могли увійти до облікового запису користувача за мінімальний проміжок часу після того, як адмін натиснув кнопку «Увійти як користувач» в адмін панелі та до того, як адмін був перенаправлений на вітрину ма
Бувають випадки, коли бічна панель Magento відсутня і не відображається. Найімовірніше, це через те, що контейнер "sidebar" або "sidebar.additional" видалено з макету вашої теми.
Щоб виправити цю проблему,
У Magento 2.3 і новіших версіях команда Magento змінила редактор WYSIWYG, замість TinyMCE 3 Magento почала використовувати TinyMCE 4.
На малюнку нижче ви можете побачити редактор Magento 2.0-2.2 TinyMCE 3:
Редактор Magento TinyMCE 4 не включає багато інструментів, наприклад, колір тексту або фон тексту, і це може бути незручно для контент менеджера.
Якщо пошук у Magento 2 Блог не працює, швидше за все, проблема полягає у вашій темі, яка переписує оригінальні шаблони блогу та файли макету.
Спробуйте виконати наступні дії щоб виправити проблему з пошуком у блозі:
1. Переконайтеся, що у вас остання версія модуля блогу Magento 2.
2. Спробуйте тимчасово видалити один за одним макет файлів XML та шаблонні файли PHTML зі своєї теми та запустіть static content deploy. Знайшовши файл, який викликає проблему, зверніть на нього увагу.
3. Перевірте, чи кнопка пошуку блогу у бічній панелі має атрибут "вимкнено", якщо так, то він відключений (неактивний), і це може бути коренем проблеми. У цьому випадку знайдіть код, який вимикає його. Вимкнений атрибут можна додати безпосередньо через .phtml файл у вашій темі або за допомогою JavaScript. Якщо ви не можете його знайти, ви можете вставити цей
Примітка: якщо ви придбали розширення на Magento Marketplace (маєте платне замовлення) і не можете знайти ключ продукту, зв’яжіться з нами та надайте номер свого замовлення.
Якщо з’являється повідомлення про помилку "Product Key is empty or invalid. The extension has been automatically disabled." зберігаючи розширення Magefan у Magento Community і не бачачи жодного поля ключа продукту, як на скріншоті:
Іноді замість реальної IP-адреси користувача в адмін панелі Magento 2 ви можете побачити 127.0.0.1 або іншу неправильну IP-адресу. Це може бути пов’язано з проксі-серверами, такими як Varnish, Cloudflare, які можуть бути включеними для вашого магазину Magento 2.
Щоб вирішити проблему з неправильною IP-адресою, потрібно:
1. Створити новий файл у каталозі M2:
app/etc/XIP/di.xml
2. Вставити цей код:
<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
<type name="Magento\Framework\HTTP\PhpEnvironment\RemoteAddress">
<arguments>
<argument name="alternativeHeaders" xsi:type="array">
<item name="x-client-ip" xsi:type="string">HTTP_X_REAL_IP</item>
Якщо у вас є проблеми з медіа-галереєю в публікації блогу, при використанні SmartWave Porto Theme, виконайте наступні кроки.
1. Перш за все, якщо в адмін панелі Magento 2 немає налаштувань галереї публікацій блогу, переконайтеся, що ви використовуєте останню версію модуля блогу.
2. Потім створіть новий файл у каталозі своєї теми:
app/design/ThemeVendor/themename/Magefan_Blog/templates/post/view/gallery.phtml
і додайте в нього цей код.
Коли ви виконуєте CLI команду Magento 2 "bin/magento ..." і отримуєте помилку:
Allowed memory size of xxxx bytes exhausted (tried to allocate xxx bytes)
Ви можете легко виправити це використавши настпуну команду замість bin/magento:
php -dmemory_limit=-1 bin/magento ....
Якщо ви встановили або оновили розширення Magento 2 і отримали повідомлення про помилку, напр.:
Module 'Company_Module' from 'app/code/Company/Module' has been already defined in 'vendor/company/module'.
це означає, що у вас є 2 версії розширення:
1) в папці app/code/Company/Module
2) в папці vendor/company/module
У папці vendor Magento зберігає всі компоненти (розширення, теми, мовні пакети), встановлені за допомогою композера (composer).
Оскільки встановлення або оновлення розширень за допомогою композера є кращим, вам потрібно видалити папку розширення app/code/Company/Module (будь ласка, не забувайте про резервну копію перед видаленням) і запустити інсталяційні команди.