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.


  • 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

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.


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.


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.

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

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.

  • 1
    Thanks! This is the exact answer that I want! It worked on my end. – MazeStricks Apr 25 '19 at 6:09
  • Yes, Working this one. Thanks. – Vrajesh Patel Nov 23 '20 at 12:45

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.


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


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,
    ) {
        $adapter = $this->resourceConnection->getConnection($resource);
        $dbName  = $this->resourceConnection->getSchemaName($resource);
        $stmt    = $adapter->select()
                           ->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 '19 at 14:36
  • This one really works! It is ignoring WordPress tables upon running setup: upgrade Thanks for this! – MazeStricks Jul 14 '20 at 16:03

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

   `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`,
FROM `information_schema`.`COLUMNS`
WHERE (TABLE_SCHEMA = '<table_schema>') AND (`COLUMNS`.`DATA_TYPE` = 'tinytext');

Helped me find the offending third-party module quickly.

  • 2
    or just 'SELECT t.* FROM information_schema.COLUMNS t WHERE DATA_TYPE = 'tinytext'' – asherrard Jan 22 '20 at 23:50
  • Yeah if you are ok with heaps of fields in the output and want the output for all schemas that user has access to sure. – Nathaniel Rogers Jan 23 '20 at 2:09

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

  • What about TIME? – Ricardo Martins Mar 8 '19 at 1:02
  • sorry, I have no info about TIME :( – Alex Gusev Mar 8 '19 at 14:24

For users of the FishPig WP module you can resolve the problem with the following mysql query:

ALTER TABLE wp_comments MODIFY comment_author VARCHAR(250);


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/


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.