I've created a simple migration to create a table for my plugin, but when I update the plugin via the CP, I get the following message:

Craft was unable to install this update :(

The site has been restored to the state it was in before the attempted update.

There was a problem updating your database.

As it's the only change to the plugin I think it's safe to say my migration isn't up to task.

How do I know exactly what's wrong with my migration though? There don't appear to be any logs generated to show the actual error being caused. I'm running in devMode, and I can't see anything in the browser console and there don't appear to be any errors in the standard logs.

For reference, here is the migration I'm trying to run, which was created manually rather than using yiic:

<?php
namespace Craft;

/**
 * The class name is the UTC timestamp in the format of mYYMMDD_HHMMSS_migrationName
 */
class m171129_103222_myplugin_createLogTable extends BaseMigration
{
    /**
     * Any migration code in here is wrapped inside of a transaction.
     *
     * @return bool
     */
    public function safeUp()
    {
        craft()->db->createCommand()->createTable('myplugin_log',
            array(
                'eventId' => array(AttributeType::Number, 'required' => true),
                'level' => array('column' => ColumnType::Varchar, 'maxLength' => 5, 'required' => true),
                'message' => array(AttributeType::String, 'required' => true),
                'date' => array(AttributeType::DateTime, 'required' => true),
            ));


        return true;
    }
}
  • 1
    You can execute the code where ever you wan't when I do it I receive the following error message "SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'number NOT NULL, level VARCHAR(5) NOT NULL, message varchar(255) NOT NULL,' at line 3" – Robin Schambach Nov 29 '17 at 13:57
  • @RobinSchambach Thanks, it wasn't so much what was wrong with the migration, more why isn't it logged, or if it is am I looking in the wrong place. It seems a bit of a longwinded process running it outside of the migration to see if it works first and then having to roll it back before creating the real migration. Is that what you normally do then? – Steve Holland Nov 29 '17 at 14:26
  • 1
    I only do this if there are errors I want to debug. Normally I create the migration file and if there is something wrong with it I debug my code step by step outsite of the migration file to see what's going on. – Robin Schambach Nov 29 '17 at 15:07
up vote 1 down vote accepted

Logs should be written to craft/storage/runtime/logs to help debug issues like this. It gets a little sketchy with fatal errors, though. Logs get flushed to disk when the onEndRequest event gets successfully fired. If it's a fatal error that kills script execution, that event will never get fired and the logs don't get flushed. That might have been what you're running into here.

Outside of that, to answer your original question, the absolute best way to debug stuff like this is with xDebug. PhpStorm has a native xDebug client built in and it's pretty fantastic.

  • Thanks Brad. At least I was looking in the right place. Getting myself setup with xDebug in PHPStorm sounds like a plan. – Steve Holland Nov 30 '17 at 8:49

One problem I see on that code is that you always return true; on safeUp. The migrations appear as successful if you return true and as failed if you return false. So with your code you will never see the migration fail even if it did.

For example, I added this to my migration:

    foreach ($fields as $field) {
        $isSaved = Craft::$app->fields->saveField($field);

        if (!$isSaved) {
            echo "Error while saving field {$field['name']}. Reverting...\n";
            self::safeDown();

            return false;
        }
    }

    return true;

I am not sure is the best approach (there's so little info about migrations that probably there's a better approach I don't know about), but at least I know if the migration fails, and it reverts all changes if something didn't work.

One more thing: you can use ->getRawSql() for dumping your query, so you are able to execute it directly on your database and see what might be the problem.

New contributor
Tyrannogina regina is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
  • I've removed the example code as it isn't really relevant to the question I was asking. – Steve Holland Dec 6 at 17:07

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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