Magento 2 Impossible de tracer l'erreur de la grille d'administration: erreur fatale: la méthode Magento \ Ui \ TemplateEngine \ Xhtml \ Result :: __ toString () ne doit pas lever d'exception

En raison de la forte dépendance des fichiers XML, j'ai du mal à trouver la cause de cette erreur lors de la création d'une grille d'administration personnalisée:

Erreur fatale: la méthode Magento \ Ui \ TemplateEngine \ Xhtml \ Result :: __ toString () ne doit pas lever d'exception dans C: \ wamp64 \ www \ mage2 \ vendor \ magento \ module-ui \ Component \ Wrapper \ UiComponent.php on line 0

J'essaie de créer une grille d'administration pour la sales_shipment_itemtable.

Jusqu'à présent, j'ai:

1. Utilisé xdebug et le mettre dans la __toString()méthode de la classe Result, il ne montre pas quelle est l'erreur réelle

2. J'ai var_dump-ed les variables dans la __toString()méthode

3. J'ai activé le mode développeur dans Magento 2

4. J'ai vérifié var/logset cela ne montre rien d'utile

J'ai réussi à créer d'autres grilles d'administration personnalisées, mais essayer de comprendre l'erreur réelle est comme une aiguille dans une botte de foin. Quelqu'un at-il trouvé un meilleur moyen de déboguer ces derniers? J'ai regardé tous les xml de la grille di.xml, et les modèles et tout semble ok.

L'erreur que vous obtenez est en effet déclenchée vendor\magento\module-ui\Component\Wrapper\UiComponent.php.

Cependant, il n'est pas déclenché à la ligne 0 mais lorsque le résultat est converti en chaîne dans la méthode suivante dans l'instruction return :

protected function _toHtml()
{
    foreach ($this->getChildNames() as $childName) {
        $childBlock = $this->getLayout()->getBlock($childName);
        if ($childBlock) {
            $wrapper = $this->blockWrapperFactory->create([
                'block' => $childBlock,
                'data' => [
                    'name' => 'block_' . $childName
                ]
            ]);
            $this->component->addComponent('block_' . $childName, $wrapper);
        }
    }

    $result = $this->component->render();
    return (string)$result;
}

Voici ce que vous pouvez essayer de déboguer votre problème:

• vérifier ce qui $resultcontient avant que la conversion de chaîne et l'instruction return ne soient appelées
• obtenir des informations sur le composant à l'origine d'un problème en appelant $component->getName(), $component->getComponentName()et $component->getData()pour vous aider à identifier le problème

Cette erreur fatale s'est également produite lorsque j'ai ajouté une liste / grille personnalisée. J'ai résolu ce problème en changeant de constructeur et en lançant une collecte correcte pour ma liste / grille de données dans le constructeur du fournisseur de données. Exemple de grille personnalisée DataProvider.php

use Acme\CustomModule\Model\ResourceModel\Entity\Listing\CollectionFactory;

class DataProvider extends \Magento\Ui\DataProvider\AbstractDataProvider
{
    public function __construct(
        $name,
        $primaryFieldName,
        $requestFieldName,
        CollectionFactory $collectionFactory,
        array $meta = [],
        array $data = []
    ) {
        parent::__construct($name, $primaryFieldName, $requestFieldName, 
        $meta, $data);
        $this->collection = $collectionFactory->create();
    }

    public function getData(): array
    {
        $collection = $this->getCollection();
        return $collection->toArray();
    }
}

Mais vous devez créer \ Acme \ CustomModule \ Model \ ResourceModel \ Entity \ Listing \ Collection pour obtenir ses données dans le fournisseur de données

SI vous avez migré M1 vers M2, vous êtes confronté à un problème inférieur à l'erreur lors de l'exécution de cmd Le magasin demandé n'a pas été trouvé. Vérifiez le magasin et réessayez.

veuillez ne pas modifier les fichiers du magasin de modules du fournisseur :

• /vendor/magento/module-store/Model/StoreManager.php ou

  /vendor/magento/module-store/Model/StoreRepository.php

appliquez simplement les étapes ci-dessous:

Je suis récemment tombé sur cette même situation après la migration de Magento 1.9.3.8 vers 2.3.0 et j'espère que ma réponse pourra être utile. Le problème est venu de supprimer plusieurs magasins 96 d'entre eux pour être exact. J'ai essayé toutes les autres réponses ici mais obtenais toujours la même erreur.

Le correctif pour moi supprimait les anciennes données du magasin de l'intérieur du "core_config_data" . Le problème est que lorsque Magento charge les données de configuration d'exécution, il trouve les anciens magasins et essaie de les résoudre. Avant de nettoyer les données de la base de données, je vous recommande fortement d'exécuter la requête SELECT ci-dessous pour vous assurer de supprimer les magasins corrects.

SELECT * FROM core_config_data WHERE scope = 'stores';

AVERTISSEMENT: ASSUREZ-VOUS DE SAUVEGARDER VOTRE BASE DE DONNÉES AVANT DE L'EXÉCUTER!

DELETE FROM core_config_data WHERE scope_id! = 1 AND scope = 'stores';

Maintenant, exécutez toutes les commandes magento, vous pouvez voir le "Le magasin demandé n'a pas été trouvé. Vérifiez le magasin et réessayez" fixé par la requête

Erreur fatale: la méthode Magento \ Ui \ TemplateEngine \ Xhtml \ Result :: __ toString () ne doit pas lever d'exception dans C: \ wamp64 \ www \ mage2 \ vendor \ magento \ module-ui \ Component \ Wrapper \ UiComponent.php on line 0

Maintenant, vérifiez votre administrateur au-dessus d'une erreur fatale également résolu blahhh ... blahh ...

(Remarque: - fatal error_Magento \ Ui \ TemplateEngine \ Xhtml \ Result :: __ toString () en fonction du module de stockage, donc ne changez pas / vendor / module-store sinon la grille / le catalogue de la liste côté administrateur vous ne pouvez pas voir les données appropriées)

Après d'innombrables heures et beaucoup de coups sur la tête contre le bureau, j'ai découvert que j'obtenais cette erreur, car j'utilisais xdebug (ce qui est incroyable!) Pour atteindre un point d'arrêt à une fonction de bas niveau, notamment Magento\Ui\TemplateEngine\Xhtml\Result::__toString()pour tester.

Apparemment, d'une certaine manière, la sortie du débogueur lançait en fait une erreur qui a fait crier la méthode __toString.

J'étais devenu fou parce que l'erreur ne se manifestait que lorsque le débogueur était allumé et pensais que cela avait peut-être quelque chose à voir avec l'appel AJAX dans le remplissage de la liste d'interface utilisateur. Le désactiver semblait le faire fonctionner, il vaut donc la peine de l'essayer. Je ne sais pas trop comment fonctionne la fonctionnalité de point d'arrêt de xdebug (dans les produits IntelliJ en particulier ... éventuellement), à part que vous pouvez invoquer un point d'arrêt avec la ligne xdebug_break(). Il est très probable qu'avoir un point d'arrêt dans la méthode __toString soit juste une chose idiote à faire dans tous les cas.

Je suppose que nous ne pouvons pas encore tout déboguer dynamiquement ... Un jour!

J'espère vraiment que cela aide quelqu'un d'autre.