Я использую Magento 2.0.4, и всякий раз, когда я нажимаю на Content> Elements> Blocks, я получаю следующее сообщение об ошибке: «Внимание! Что-то пошло не так».
Больше информации нет, и после нажатия кнопки «ОК» он переходит на страницу «Блоки CMS» с кружком загрузки и никогда не прекращает загрузку. Я могу нажать на Add New Block
кнопку, а затем создать и сохранить новый блок, но эти вновь созданные / сохраненные блоки не отображаются на странице блоков, потому что он никогда не загружается полностью.
Соответствующая информация об установке платформы (при необходимости можно редактировать больше): Magento версии 2.0.4, PHP версии 5.6.20
Браузеры, на которых я тестировал эту проблему: Firefox 45.0.1, IE 11.0.9600.18231, Chrome 49.0.2623.110
Это установка Magento непосредственно с веб-сайта magentocommerce, а не какая-либо загрузка с github. После обновления с Magento 2.0.2 до Magento 2.0.4 я уже все сбросил, удалил статический контент и выполнил команду для повторного развертывания статического контента.
Пожалуйста, дайте мне знать, что мне здесь не хватает. Это проблема с правами доступа на каком-нибудь сервере? , проблема с кодированием, известная проблема или что происходит? Кажется, я не получаю это сообщение об ошибке, когда нажимаю на что-либо еще в панели администратора (например, страницы, темы, виджеты и т. Д. Все загружаются правильно и не генерируют сообщение об ошибке).
Ответы:
Вы должны проверить
var/logs
папку, чтобы увидеть, если что-то пошло не так, а также журналы вашего сервера.Для меня проблема была связана с этим https://github.com/magento/magento2/issues/5418 .
Зайдите в таблицу базы данных cataloginventory_stock_item и удалите дубликаты, после чего проблема исчезнет.
Если это не решит проблему, вы можете попробовать:
1) CD в
pub/static
и запуститьfind . -depth -name .htaccess -prune -o -delete
2) Перейдите в корневую папку и запустите
rm -rf var/cache/ var/generation/ var/page_cache/ var/view_preprocessed/
3) бегать
php bin/magento setup:static-content:deploy
Если это не решит проблему, вы можете воспользоваться радикальным вариантом переустановки:
1) удалить папку вендора,
rm -rf vendor/*
а такжеcomposer.lock
файл в корне.2) бегать
composer install
источник
find -delete
опасна, она удалила все файлы моей установки Magento. Это должно быть удалено / исправлено в ответе.cd into pub/static
. если вы сделаете это, он будет удалять только файлы внутри статического. которые предназначены для удаления.Только что отлаживал точно такую же проблему. Когда вы видите
сообщение будет генерировать отчет об ошибке внутри
var/report
с более подробной информацией о том, что пошло не так. Я бы порекомендовал вам удалить все отчеты в этом каталоге и обновить страницу в своем бэкэнде. Это должно создать один отчет с более подробной информацией.В моем случае у некоторых
page_id's
из таблицcms_page
не было соответствующего,page_id
вcms_page_store
результате которого возникла следующая ошибка:Я смог обойти это, добавив отсутствующий
page_id's
&store_id's
путь.источник
На основании [ https://github.com/magento/magento2/issues/6602 ] вы можете:
источник
Если это кому-нибудь поможет, я решил эту проблему, отключив модуль отчетов NewRelic PHP.
На сайте была включена поддержка SSL, с заголовками HSTS и кодом отслеживания JavaScript, который модуль пытался внедрить, происходил из конечной точки без SSL. После удаления всех источников, не использующих SSL, страница «Блоки» успешно загружена.
Об ошибках не сообщалось в var / reports var / log / exception.log или var / log / debug.log.
Странно, что никакие другие страницы администрирования Magento, казалось, не были затронуты этим, возможно, ошибка, возникшая из-за того, что встроенный javascript не был введен, также нарушала вызов ajax Magento.
Чисто догадка, но как только NewRelic был отключен, страница загружается отлично
источник
Самое простое и простое решение, как упомянуто @Helal, просто перейти в базу данных и удалить все записи в таблице ui_bookmark.
Убедитесь, что вы создали резервную копию своей базы данных, чтобы вы могли восстановить ее, если что-то пойдет не так.
У меня нет дополнительной информации о том, почему это решение. Я попробовал решение для базы данных, как уже упоминалось, и это сработало. Может быть, кто-нибудь может объяснить причину этого?
источник
В моем случае это были разрешения на уведомления
источник
У меня есть простое решение для этого.
источник
У меня была ошибка "Что-то пошло не так" на Magento 2.1 при просмотре страницы редактирования продукта. В моем случае поиск сообщения об ошибке обнаружил, что оно было сгенерировано при неудачном ответе AJAX, поэтому я использовал инструменты разработчика Chrome, чтобы найти конкретный отказавший AJAX-ответ. Этот ответ имел код ошибки 500, что позволило мне заглянуть в журнал ошибок httpd (не в журналы magento), чтобы обнаружить, что произошла ошибка PHP (в моем случае, вызванная профилировщиком Magento - отключение профилировщика привело к ошибке уходи).
Ваши условия ошибки могут отличаться, но, надеюсь, этот процесс поможет вам найти причину.
источник
Для Magento CE 2.0.15 вы можете проверить файл:
Строка 110 ~ 112:
Надеюсь, это полезно.
источник