Welcome Guest, Not a member yet? Register   Sign In
How to debug migration config issues
#1

Hey guys,

I'm currently ramming my head against the wall, trying to break through "Migrations has been loaded but is disabled or set up incorrectly."  I know it isn't disabled (code to follow), so what does this mysterious "not set up correctly" mean?  I guess it makes sense to END USERS (it means the developer made an ID-10-T error someplace lol - but they shouldn't see this kind of message anyway IMO) but is there any way to get some additional info?  Nothing is logged, there is no stack trace, it may as well just say "dude, here's yer solution - git reset --hard $ID10T" lol

As promised, here's my config file:

Code:
<?php defined('BASEPATH') OR exit('No direct script access allowed');

/*
|--------------------------------------------------------------------------
| Enable/Disable Migrations
|--------------------------------------------------------------------------
|
| Migrations are disabled by default for security reasons.
| You should enable migrations whenever you intend to do a schema migration
| and disable it back when you're done.
|
*/
$config['migration_enabled'] = TRUE;

/*
|--------------------------------------------------------------------------
| Migration Type
|--------------------------------------------------------------------------
|
| Migration file names may be based on a sequential identifier or on
| a timestamp. Options are:
|
|   'sequential' = Sequential migration naming (001_add_blog.php)
|   'timestamp'  = Timestamp migration naming (20121031104401_add_blog.php)
|                  Use timestamp format YYYYMMDDHHIISS.
|
| Note: If this configuration value is missing the Migration library
|       defaults to 'sequential' for backward compatibility with CI2.
|
*/
$config['migration_type'] = 'timestamp';

/*
|--------------------------------------------------------------------------
| Migrations table
|--------------------------------------------------------------------------
|
| This is the name of the table that will store the current migrations state.
| When migrations runs it will store in a database table which migration
| level the system is at. It then compares the migration level in this
| table to the $config['migration_version'] if they are not the same it
| will migrate up. This must be set.
|
*/
$config['migration_table'] = 'migrations';

/*
|--------------------------------------------------------------------------
| Auto Migrate To Latest
|--------------------------------------------------------------------------
|
| If this is set to TRUE when you load the migrations class and have
| $config['migration_enabled'] set to TRUE the system will auto migrate
| to your latest migration (whatever $config['migration_version'] is
| set to). This way you do not have to call migrations anywhere else
| in your code to have the latest migration.
|
*/
$config['migration_auto_latest'] = FALSE;

/*
|--------------------------------------------------------------------------
| Migrations version
|--------------------------------------------------------------------------
|
| This is used to set migration version that the file system should be on.
| If you run $this->migration->current() this is the version that schema will
| be upgraded / downgraded to.
|
*/
$config['migration_version'] = 20190112182800;

/*
|--------------------------------------------------------------------------
| Migrations Path
|--------------------------------------------------------------------------
|
| Path to your migrations folder.
| Typically, it will be within your application path.
| Also, writing permission is required within the migrations path.
|
*/
$config['migration_path'] = APPPATH.'migrations/';

I don't see anything blatantly wrong here, but apparently it saw something somewhere it didn't like.  I tried rolling back to a previous migration, updating to the migration I want, and nothing so far seems to get past this.  The only idea (that just now occurs to me) is maybe set the log level to EVERYTHING, and pray that generates some information.  Any other ideas?  Thanks.
Reply
#2

(This post was last modified: 02-12-2019, 08:22 PM by php_rocs.)

@mfox,

What version of CI are you running? PHP version? Where any changes made to the core files?
Reply
#3

@php_rocs

PHP version is 5.4 (I know it's outdated, still working on that lol), CI version is 3.1.9, and I haven't made any changes to the core ("system" folder). And none of that has changed since I started getting this error. My idea about increasing the logging level didn't do anything, so it's back to Google Drawing Board. Big Grin
Reply
#4

LOL wow this is embarrassing... I was looking at the wrong app! Big Grin Sorry for posting regarding an obvious ID-10-T error lol
Reply




Theme © iAndrew 2016 - Forum software by © MyBB