<p>Logs should be written to <code>craft/storage/runtime/logs</code> to help debug issues like this.  It gets a little sketchy with fatal errors, though.  Logs get flushed to disk when the <code>onEndRequest</code> 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.</p>

<p>Outside of that, to answer your original question, the absolute best way to debug stuff like this is with <a href="https://xdebug.org/" rel="nofollow noreferrer">xDebug</a>.  <a href="https://www.jetbrains.com/help/phpstorm/configuring-xdebug.html" rel="nofollow noreferrer">PhpStorm</a> has a native xDebug client built in and it's pretty fantastic.</p>

CC BY-SA 3.0
2017-11-30T08:49:09.150Z
Thanks Brad. At least I was looking in the right place. Getting myself setup with xDebug in PHPStorm sounds like a plan.
Steve Holland
CC BY-SA 3.0
2017-11-29T19:08:40.653Z
2017-11-29T19:08:40.653Z
Brad Bell
<p>One problem I see on that code is that you always <code>return true;</code> on <code>safeUp</code>. The migrations appear as successful if you return <code>true</code> and as failed if you return <code>false</code>. So with your code you will never see the migration fail even if it did. </p>

<p>For example, I added this to my migration: </p>

<pre><code>    foreach ($fields as $field) {
        $isSaved = Craft::$app-&gt;fields-&gt;saveField($field);

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

            return false;
        }
    }

    return true;
</code></pre>

<p>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. </p>

<p>One more thing: you can use <a href="https://www.yiiframework.com/wiki/857/show-raw-sql-query" rel="nofollow noreferrer"><code>-&gt;getRawSql()</code></a> for dumping your query, so you are able to execute it directly on your database and see what might be the problem.</p>

CC BY-SA 4.0
2018-12-06T17:07:42.660Z
I've removed the example code as it isn't really relevant to the question I was asking.
Steve Holland
CC BY-SA 4.0
2018-12-05T15:15:23.090Z
2018-12-05T15:15:23.090Z
Tyrannogina regina
<p>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:</p>

<blockquote>
  <p>Craft was unable to install this update :( </p>
  
  <p>The site has been restored
  to the state it was in before the attempted update.</p>
  
  <p>There was a problem updating your database.</p>
</blockquote>

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

<p>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 <code>devMode</code>, and I can't see anything in the browser console and there don't appear to be any errors in the standard logs.</p>

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

<pre><code>&lt;?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()-&gt;db-&gt;createCommand()-&gt;createTable('myplugin_log',
            array(
                'eventId' =&gt; array(AttributeType::Number, 'required' =&gt; true),
                'level' =&gt; array('column' =&gt; ColumnType::Varchar, 'maxLength' =&gt; 5, 'required' =&gt; true),
                'message' =&gt; array(AttributeType::String, 'required' =&gt; true),
                'date' =&gt; array(AttributeType::DateTime, 'required' =&gt; true),
            ));


        return true;
    }
}
</code></pre>

CC BY-SA 3.0
2017-11-29T13:57:22.483Z
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
CC BY-SA 3.0
2017-11-29T14:26:25.193Z
@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
CC BY-SA 3.0
2017-11-29T15:07:04.867Z
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
<plugin-development><migration>
How do you debug problems with a migration?
# How do you debug problems with a migration?

(Asked by: username_0 on 2017-11-29)

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:
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;
    }
}

**Tags:** plugin-development, migration

> **Comments:**
> **username_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"  
> **username_0**: @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?  
> **username_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.  

---

## 2 answers

### Answer by username_2 on 2017-11-29. Score: 2 | Accepted answer

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](https://xdebug.org/). [PhpStorm](https://www.jetbrains.com/help/phpstorm/configuring-xdebug.html) has a native xDebug client built in and it's pretty fantastic.

> **Comments:**
> **username_0**: Thanks Brad. At least I was looking in the right place. Getting myself setup with xDebug in PHPStorm sounds like a plan.  

---

### Answer by username_3 on 2018-12-05. Score: 1

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.

> **Comments:**
> **username_0**: I've removed the example code as it isn't really relevant to the question I was asking.  

---

