J'utilise Magento 2.0.4, et chaque fois que je clique sur Contenu> Éléments> Blocs, je reçois le message d'erreur suivant: "Attention, quelque chose s'est mal passé."
Il n'y a plus d'informations, et après avoir cliqué sur OK, il va à la page des blocs CMS avec le cercle de chargement, et n'arrête jamais le chargement. Je peux cliquer sur le Add New Block
bouton, puis créer et enregistrer un nouveau bloc, mais ces blocs nouvellement créés / enregistrés n'apparaissent pas dans la page Blocs car il ne se charge jamais complètement.
Informations d'installation de la plateforme pertinentes (peuvent être modifiées avec plus si nécessaire): Magento version 2.0.4, PHP version 5.6.20
Navigateurs sur lesquels j'ai testé ce problème: Firefox 45.0.1, IE 11.0.9600.18231, Chrome 49.0.2623.110
Il s'agit d'une installation Magento directement à partir du site Web de magentocommerce, et pas de tout type de téléchargement github. Après la mise à niveau de Magento 2.0.2 vers Magento 2.0.4, j'ai déjà tout vidé, supprimé le contenu statique et exécuté la commande pour redéployer le contenu statique.
Veuillez me faire savoir ce qui me manque ici. Est-ce un problème d'autorisations sur le back-end quelque part? , un problème de codage, un problème connu ou que se passe-t-il? Je ne semble pas recevoir ce message d'erreur lorsque je clique sur autre chose dans le panneau d'administration (par exemple, les pages, les thèmes, les widgets, etc. se chargent tous correctement et ne génèrent aucun message d'erreur).
Réponses:
Vous devriez vérifier le
var/logs
dossier pour voir si quelque chose s'est mal passé et aussi les journaux de votre serveur.Pour moi, le problème était lié à celui-ci https://github.com/magento/magento2/issues/5418 .
Entré dans la table db cataloginventory_stock_item et supprimer les doublons, puis le problème a disparu.
Si cela ne le résout pas, vous pouvez essayer:
1) cd dans
pub/static
et exécutezfind . -depth -name .htaccess -prune -o -delete
2) cd dans le dossier racine et exécutez
rm -rf var/cache/ var/generation/ var/page_cache/ var/view_preprocessed/
3) courir
php bin/magento setup:static-content:deploy
Si cela ne le résout pas, vous pouvez prendre l'option radicale de réinstaller:
1) supprimez le dossier du fournisseur
rm -rf vendor/*
ainsi que lecomposer.lock
fichier racine.2) courir
composer install
la source
find -delete
commande est dangereuse, elle a supprimé tous les fichiers de mon installation Magento. Il doit être supprimé / corrigé dans la réponse.cd into pub/static
. si vous faites cela, il ne supprimera que les fichiers dans static. qui sont censés être supprimés.Je viens de déboguer exactement le même problème. Quand vous voyez le
message, il générera un rapport d'erreur à l'intérieur
var/report
avec plus de détails sur ce qui n'a pas fonctionné. Je vous recommande de supprimer tous les rapports de ce répertoire et de rafraîchir la page de votre backend. Cela devrait générer un seul rapport avec plus de détails.Dans mon cas , certains
page_id's
de la tablecms_page
n'a pas eu un correspondantpage_id
dans cecms_page_store
qui a entraîné l'erreur suivante:J'ai pu contourner cela en ajoutant le chemin manquant
page_id's
&store_id's
à.la source
Sur la base de [ https://github.com/magento/magento2/issues/6602 ], vous pouvez:
la source
Si cela aide quelqu'un, j'ai résolu ce problème en désactivant le module de rapport PHP NewRelic.
Le site était compatible SSL, avec des en-têtes HSTS, et le code de suivi javascript que le module essayait d'injecter provenait d'un point de terminaison non SSL. Une fois que toutes les sources non SSL ont été supprimées, la page Blocs s'est chargée avec bonheur.
Aucune erreur n'a été signalée dans var / reports var / log / exception.log ou var / log / debug.log.
Étrange qu'aucune autre page d'administration de Magento ne semble être affectée par cela, peut-être que l'erreur soulevée par le javascript en ligne n'ayant pas été injecté rompait également l'appel ajax de Magento.
Purement conjecture, mais une fois NewRelic désactivé, la page se charge parfaitement
la source
La solution la plus simple et la plus simple consiste, comme mentionné par @Helal, à aller dans la base de données et à supprimer toutes les entrées de la table ui_bookmark.
Assurez-vous de créer une sauvegarde de votre base de données afin de pouvoir la restaurer en cas de problème.
Je n'ai aucune information supplémentaire sur la raison pour laquelle c'est la solution. J'ai essayé la solution de base de données comme mentionné et cela a fonctionné. Peut-être que quelqu'un peut expliquer la raison derrière cela?
la source
Dans mon cas, c'était des autorisations sur les notifications
la source
J'ai une solution simple pour cela.
la source
J'ai eu l'erreur "Quelque chose s'est mal passé" sur Magento 2.1 lors de l'affichage d'une page de modification de produit. Dans mon cas, une recherche du message d'erreur a révélé qu'il a été généré lorsqu'une réponse AJAX a échoué, j'ai donc utilisé les outils de développement Chrome pour trouver la réponse AJAX spécifique qui échouait. Cette réponse avait un code d'erreur de 500, ce qui m'a permis de regarder dans le journal des erreurs httpd (pas dans les journaux magento) pour trouver qu'il y avait une erreur PHP (dans mon cas, causée par le profileur Magento - la désactivation du profileur a fait l'erreur allez-vous en).
Vos conditions d'erreur peuvent varier, mais nous espérons que ce processus vous aidera à trouver la cause.
la source
Pour Magento CE 2.0.15, vous pouvez vérifier le fichier:
Ligne 110 ~ 112:
J'espère que cela vous sera utile.
la source