8

I'm getting following error "Cannot process definition to array for type tinytext" on Magento 2.3.0 when executing php bin/magento setup:upgrade command.

Thanks

  • Has a solution already been found? I have the same problem. Thanks Chris – Christoph Dec 1 '18 at 12:16
  • This does not really answer the question. If you have a different question, you can ask it by clicking Ask Question. You can also add a bounty to draw more attention to this question once you have enough reputation. - From Review – sv3n Dec 1 '18 at 13:04
25

You are getting this error because "data type" of any third-party extension's table's column is tinytext.

Note: Normally this error happens because of Fishpig Wordpress extension's wp_comment table has tinytext data type

So you need to find out the column name using debug in the following file.

Open this file /vendor/magento/framework/Setup/Declaration/Schema/Db/DefinitionAggregator.php and check this fromDefinition() method and then add debug code to find column name.

public function fromDefinition(array $data)
    {
        $type = $data['type'];
        if (!isset($this->definitionProcessors[$type])) {

            /* Add Code for Debug */

            echo "<pre>";
            print_r($data); exit();

            /* Code End */

            throw new \InvalidArgumentException(
                sprintf("Cannot process definition to array for type %s", $type)
            );
        }

        $definitionProcessor = $this->definitionProcessors[$type];
        return $definitionProcessor->fromDefinition($data);
    }

After that please run setup:upgrade command and you will get an array of column data in the console. so from this array, you will get the name of the column from your third party extension table.

Now from that table please change column's data type "tinytext" to "text" and issue will be fixed.

SECOND METHOD

Please export the database and search for keywords tinytext, you will found a table which uses this format, Now changed it to TEXT and the problem solved.

Note: You might also get issues from ENUM, TIME and MEDIUMINT data type as well, so do the same steps if get any other data type issue.

  • thanks for your clue. i had found that colum and i am sharing the answer how i resolved. +1 vote – Pradeep Sanku Dec 5 '18 at 9:38
  • 3
    This is clearly a regression and a bug. Any table declared in the magento database with a type of ENUM, TINYTEXT or MEDIUMINT will cause this problem even if it's not managed by magento. It should be possible to have magento and wordpress share the same database. They even suppord table prefixes for this reason. Has a bug been reported about this? – David Stone Dec 14 '18 at 23:52
  • @PradeepSanku please accept my ans if its usefull to you, so it will help others for this type of issues. and let me know if you have any question. Thanks! – Aasim Goriya Dec 31 '18 at 5:37
8

In my case, Wordpress was being used with the Fishpig integration. In wp_comments, the comment_author was set to TINYTEXT. The problem was resolved by changing that column declaration.

  • Thanks! This is the exact answer that I want! It worked on my end. – MazeStricks Apr 25 at 6:09
2

A handy little SQL script if anyone wants to know which columns have tinytext types defined.

SELECT TABLE_NAME,
   `COLUMNS`.`COLUMN_NAME`                       AS `name`, `COLUMNS`.`COLUMN_DEFAULT` AS `default`,
   `COLUMNS`.`DATA_TYPE`                         AS `type`, IF(IS_NULLABLE = "YES", true, false) AS `nullable`,
   `COLUMNS`.`COLUMN_TYPE`                       AS `definition`, `COLUMNS`.`EXTRA` AS `extra`,
   IF(COLUMN_COMMENT = "", NULL, COLUMN_COMMENT) AS `comment`
FROM `information_schema`.`COLUMNS`
WHERE (TABLE_SCHEMA = '<table_schema>') AND (`COLUMNS`.`DATA_TYPE` = 'tinytext');

Helped me find the offending third-party module quickly.

1

Magento 2.3 developers will not add support for tinytext data type. varchar type is recommended to use instead of tinytext.

1

If you do WordPress migrations frequently, changing the schema as suggested in some of the other answers is tedious and easy to forget, plus changing the schema seems hacky. To resolve this, I wrote a small plugin (Interceptor) so that Magento would ignore the WordPress Tables.

Per the docs, using "Around" Interceptors is not ideal, but in this particular case it seems fair - we'd just need to keep an eye on any changes to this method since we are completely replacing it.

Package/Module/etc/di.xml

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
    <type name="Magento\Framework\Setup\Declaration\Schema\Db\MySQL\DbSchemaReader">
        <plugin name="your-plugin-name" type="\Package\Module\Plugin\DbSchemaReaderPlugin" sortOrder="1" disabled="false"/>
    </type>
</config>

Package/Module/Plugin/DbSchemaReaderPlugin.php

namespace Package\Module\Plugin;
use Magento\Framework\App\ResourceConnection;
use Magento\Framework\Setup\Declaration\Schema\Db\DefinitionAggregator;
use Magento\Framework\Setup\Declaration\Schema\Db\MySQL\DbSchemaReader;

class DbSchemaReaderPlugin
{

    const WP_PREFIX = 'wp_'; //or switch to your prefix.

    /**
     * @var ResourceConnection
     */
    private $resourceConnection;

    /**
     * @var DefinitionAggregator
     */
    private $definitionAggregator;

    /**
     * Constructor.
     *
     * @param ResourceConnection   $resourceConnection
     * @param DefinitionAggregator $definitionAggregator
     */
    public function __construct(
        ResourceConnection $resourceConnection,
        DefinitionAggregator $definitionAggregator
    ) {
        $this->resourceConnection   = $resourceConnection;
        $this->definitionAggregator = $definitionAggregator;
    }


    /**
     * @param DbSchemaReader $subject
     * @param callable $proceed 
     * @param string $resource Argument from the original method call.
     *
     * @return array
     */
    public function aroundReadTables(
        DbSchemaReader $subject,
        callable $proceed,
        $resource
    ) {
        $adapter = $this->resourceConnection->getConnection($resource);
        $dbName  = $this->resourceConnection->getSchemaName($resource);
        $stmt    = $adapter->select()
                           ->from(
                               ['information_schema.TABLES'],
                               ['TABLE_NAME']
                           )
                           ->where('TABLE_SCHEMA = ?', $dbName)
                           ->where('TABLE_TYPE = ?', DbSchemaReader::MYSQL_TABLE_TYPE)
                           ->where('TABLE_NAME NOT LIKE "'.self::WP_PREFIX.'%"');

        return $adapter->fetchCol($stmt);
    }
}
  • Perfect solution for wordpress user! – MageLerner Dec 5 at 14:36
0

We've made a quick composer patch to tell the Magento declarative schema validator to ignore WordPress. Obviously this only fixes the issue if wordpress is the culprit.

You can see the patch here: https://www.cadence-labs.com/2019/08/magento-2-3-wordpress-fix-cannot-process-definition-to-array-for-type-tinytext/

0

All of these answers work, but the easiest and most secure fix is to install WordPress in a separate database to Magento.

This prevents Magento from applying it's DB schema system to the WordPress database and if you use separate DB users as well, it also has the added benefit of being more secure.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.