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

Прийняття обґрунтованих бізнес-рішень можливе лише за наявності точних даних про транзакції та замовлення. Згодні? Тоді, ймовірно, вам потрібна допомога у вирішенні проблеми з пропущеними транзакціями в Google Analytics 4 (GA4). 

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

У цій статті ми розглянемо найпоширеніші причини відсутності транзакцій в GA4 і що ви можете зробити, щоб підвищити точність даних.

Ті, хто використовує Magento, залишайтеся з нами, щоб дізнатися про рішення цієї проблеми за допомогою Magento 2 Google Tag Manager.

Причини відсутності транзакцій в Google Analytics 4

Універсальної відповіді щодо зникнення транзакцій і замовлень в Google Analytics 4 не існує. Причин може бути чимало, а може бути лише одна. Однак її виявлення допоможе вам усунути проблему та покращити відстеження даних у вашому магазині.

Давайте розглянемо, чому деякі дані

Вхід в обліковий запис користувача в Shopify без даних для входу економить ваш час і ресурси, необхідні для вирішення запитів клієнтів. Ви можете допомогти клієнтам укласти замовлення або своєчасно допомогти у вирішенні будь-яких проблем, пов’язаних з їхнім обліковим записом, за допомогою додатку Shopify Login as Customer App.

Однак інколи ви можете зіткнутися з проблемою "Incorrect email or password" після того, як вас буде перенаправлено на сторінку входу (login page) замість облікового запису клієнта.

Це трапляється, коли ви не використовуєте Multipass і клієнти не дозволяються вам ввійти в свій обліковий запис (require assistance), але ви всерівно намагаєтесь увійти в обліковий запис клієнта.

Що ви можете зробити, щоб нарешті увійти в обліковий запис клієнта в Shopify?

У вас є 2 варіанти:

1. Попросіть клієнта надати вам доступ (Ask the customer for assistance)
2. Змініть пароль і логін клієнта (Change customer password and login)

Якщо ви попросите клієнтів надати вам доступ, вони можуть

Перше, з чим ви стикаєтеся, коли керуєте багатомовним магазином 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 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 через композер, ви можете отримати наступну помилку:

[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 2 Login as Customer від Magefan  було інтегровано з ядром Magento 2.4.0 core, і ми передали Adobe авторські права на модуль "Login as Customer". Ви можете прочитати більше про це here.

Тож, якщо ви використовуєте Magento 2.4.x або вище у вас є дві опції:

1. Видалити модуль Magefan Login as Customer  і використовувати фукцію Login As Customer ядра Magento.

2. Вимкнути функцію Login As Customer в ядрі Magento  і продовжити використовувати оригільнальний модуль Magefan Login as Customer.

Щоб вимкнути модуль в корені Magento ви можете виконати такі конманди:

bin/magento module:disable Magento_LoginAsCustomer
bin/magento module:disable Magento_LoginAsCustomerAdminUi
bin/magento module:disable Magento_LoginAsCustomerApi
bin/magento module:disable Magento_LoginAsCustomerAssistance
bin/magento module:disable Magento_LoginAsCustomerFrontendUi
bin/magento module:disable Magento_LoginAsCustomerLog
bin/magento module:disable Magento_LoginAsCustomerPageCache

Якщо ви використовуєте одне з розширень 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 магазинів дуже серйозно ставляться до швидкості сторінки, оскільки вона безпосередньо впливає на загальну продуктивність вашого веб-сайту. Тому всі постійно намагаються її вдосконалити і шукають найкращі способи це зробити.

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

Якщо ви вже використовуєте WebP зображення для HTML-тегів <img> і хочете також увімкнути WebP для фонових малюнків у CSS, правильним буде використати кілька фонів в CSS стилях.

Наприклад, у вас є елемент із фоновим CSS .png:

.minicart-wrapper .action.showcart.desktop .fa-shopping-cart:before {
     background: url(../images/icon-cart.png) no-repeat;
}

Щоб переключити його на WebP, вам потрібно вручну конвертувати PNG/JPG/GIF зображення у формат WebP, використовуючи один із безкоштовних інструментів доступних в Інтернеті. Збережіть його в тій же папці та використовуйте CSS ось так:

body.webp-supported .minicart-wrapper .action.showcart.desktop .fa-shopping-cart:before {
     background: url(../images/icon-cart.webp) no-repeat;
}
body.no-webp .minicart-wrapper .action.showcart.desktop .fa-shopping-cart:before {
     background: url(../images/icon-cart.png) no-repeat;
}

У цьому випадку всі браузери отримуватимуть WebP зображення, за винятком тих, які не підтримують

У Magento 2 Блог v2.9.3 ми додали функцію, про яку запитували багато клієнтів, це «використання шаблону пов'язаних продуктів із каталогу за замовчуванням» (default catalog related products template) замість кастомного шаблону пов'язаних продуктів блогу. Це допомагає автоматично відображати пов'язані продукти на сторінці публікації блогу в дизайні теми. Коміт (commit), пов'язаний з цією зміною, можна знайти на GitHub.

На жаль, для Magento 2 існує тисячі тем і деякі з них мають специфічні JS та CSS (наприклад, тема Porto). Ось чому, якщо ви використовуєте розширення Blog 2.9.3 або новішої версії і блок пов'язаних продуктів виглядає дивно, спробуйте зробити наступне:

1. Створіть новий файл у каталозі своєї теми:

app/design/frontend/ThemeVendor/themename/Magefan_Blog/layout/blog_post_view.xml

2. Додайте до нього цей код:

<?xml version="1.0"?>
<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:View/Layout/etc/page_configuration.xsd">

Соціальні мережі - це потужні платформи, які щодня генерують тонни інформації у всьому світі. Ось чому такі мережі, як Facebook і Twitter, часто використовуються в маркетингових цілях багатьма магазинами. Це дозволяє їм привертати більше уваги до свого контенту і відповідно залучати більше трафіку на свої веб-сайти за допомогою Open Graph тегів.

Однак іноді трапляється, що теги Facebook OG працюють не так, як передбачається. Замість чудового зображення та тільки-но написаного заголовка та опису ви бачите застарілу інформацію або взагалі нічого не бачите.

Якщо ви гадаєте, що може призвести до того, що Facebook витягує неправильні OG дані  замість нових, відповідь досить проста. Facebook Open Graph Cache. Отже, щоб переконатися, що Facebook показує актуальну інформацію OG, вам просто потрібно очистити кеш у Facebook.

Виконайте ці кроки, щоб очистити кеш Open Graph у Facebook:

1. Підіть в Facebook Sharing Debugger, вставте URL-адресу сторінки, яка не відображається належним

Сьогодні (12 лютого 2020 р.) Ми отримали повідомлення про потенційну проблему безпеки в нашому модулі Magento 2 Login As Customer завдяки твіту Даніеля Слофа.

Переглядаючи код та спілкуючись з Дерріком Хісбіном, Льюїс Вонкен з сайту experus.nl виявив проблему в безпеці.

Зауважте, що дотепер жодної підтвердженої атаки, пов’язаної з цією проблемою, не відбулося, однак зловмисники потенційно могли увійти до облікового запису користувача за мінімальний проміжок часу після того, як адмін натиснув кнопку «Увійти як користувач» в адмін панелі та до того, як адмін був перенаправлений на вітрину магазину та фактично ввійшов в цей акаунт.

Час дійсно важливий для відтворення цієї проблеми. Проблема безпеки може виникнути у всіх версіях модуля Login as Customer до версії 2.2.3 протягом декількох секунд після натискання кнопки "Увійти як користувач".

Ми закликаємо всіх, хто використовує розширення Login As Customer v2.0.0 - v2.2.2, оновити його принаймні до v2.2.3 або застосувати це швидке виправлення

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

Коли ви тестуєте свою сторінку за допомогою Facebook Sharing Debugger  і отримуєте попередження "The following required properties are missing: fb:app_id",

вам треба додати мета тег fb:app_id до <head> тегу сторінки:

<meta property="fb:app_id" content="ХХХХХХХХХХХХХХХ" />

Вставте ваш Facebook App ID замість ХХХХХХХХХХХХХХХ.

Бувають випадки, коли ви ділитеся посиланням у Facebook, і зображення не відображається або з’являється, але це не те зображення, яке ви очікували. Для виправлення цього слід виконати такі кроки:

1. Перевірте, чи є на вашому веб-сайті OG теги.

Знайдіть код <meta property = og:, натиснувши комбінацію клавіш Ctrl + U, щоб відкрити вихідний код сторінки, приклад:

<meta property="fb:app_id" content="102143277123049" />
<meta property="og:type" content="website" />
<meta property="og:title" content="Development team for your Magento 2 store | Magefan" />
<meta property="og:description" content="Magefan is development team, gathered together in October 2015 shortly before Magento 2 release. We&#039;ve all been waiting for Magento 2 and this is it. Now we can surprise you with our solutions." />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:image" content="https://cm.magefan.com/default/default/solutions-for-magento-stores-min.jpg"

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

Спробуйте виконати наступні дії щоб виправити проблему з пошуком у блозі:

1. Переконайтеся, що у вас остання версія модуля блогу Magento 2.

2. Спробуйте тимчасово видалити один за одним макет файлів XML та шаблонні файли PHTML зі своєї теми та запустіть static content deploy. Знайшовши файл, який викликає проблему, зверніть на нього увагу.

3. Перевірте, чи кнопка пошуку блогу у бічній панелі має атрибут "вимкнено", якщо так, то він відключений (неактивний), і це може бути коренем проблеми. У цьому випадку знайдіть код, який вимикає його. Вимкнений атрибут можна додати безпосередньо через .phtml файл у вашій темі або за допомогою JavaScript. Якщо ви не можете його знайти, ви можете вставити цей скрипт JS, щоб відключити кнопку:

<script>
require(['jquery', 'domReady!'], function($) {
    setInterval(function(){
        $('#blog_search_mini_form

Іноді замість реальної 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>
                <item name="x-cf-connecting-ip" xsi:type="string">HTTP_CF_CONNECTING_IP</item>
                <!-- <item name="x-cf-mfcustom-ip" xsi:type="string">SOME_CUSTOM_SERVER_KEY</item> -->
            </argument>
        </arguments>

Якщо з якоїсь причини вам потрібно скопіювати дані Magento 2 Блогу з однієї бази даних (DB1) до іншої (DB2) (фактично імпортувати дані Блогу з однієї інсталяції Magento до іншої), виконайте такі дії:

1. Переконайтеся, що інсталяція Magento 2, яка використовує DB2, має ту саму версію розширення блогу, що й інсталяція, яка використовує DB1. Якщо ні, будь ласка, оновіть модуль блогу Magento 2 на одному з них.
2. Створіть резервну копію таблиць magefan_blog_* у DB2.
3. Видаліть усі таблиці magefan_blog_* з DB2.
4. Зробіть експорт (дамп) усіх таблиць magefan_blog_* з DB1
5. Імпортуйте дамп DB1 до DB2.

Використовуючи цю інструкцію, ви легко перенесете ВСІ дані блогу з DB1 до DB2. Для маніпуляцій з базою даних ви можете використовувати phpMyAdmin, Adminer.