Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
Problem with migrating auth tables
  • I'm having some trouble migrating the auth tables with oil refine migrate --packages=auth

    Here is the errors i'm getting.


    I've used oil a couple of times a while back but didn't have any problems with it then. I checked the db connection and it works so that can't be it. Not sure what it could be.
  • That link does not exist, so I don't know what the problem is...

    Note that you need to setup Auth first (i.e. copy the auth.php and the config file for your chosen auth type to app/config) and set them up. The migration files use the config to determine which tables to create.
  • I have both the auth config and the ormauth config file in my app configs folder and the driver is set to Ormauth.

    Here is the errors again, hopefully the link works this time, http://bin.fuelphp.com/~fy
  • Your db config is not ok, or oil either picks the wrong environment (unless you set the environment, it will use 'development').
  • I've tried querying the db in the default welcome controller and printing it out and it works fine. Also running oil -v says "Fuel: 1.6 running in "development" mode" and it's the development db config i've set up with proper values and using.
  • The error message is pretty clear: fuel/core/classes/database/pdo/connection.php(89): PDO->__construct('', NULL, NULL, Array)

    so it's gets an empty DSN string passed, and NULL for username and password.

    if you run "oil console", and then execute "DB::list_tables();" (without quotes), does that list all your tables, or give the same error message?
  • Yeah, i noticed that too. Tried running "DB::list_tables()" and i get "Parse Error - Database method Fuel\Core\Database_PDO_Connection::list_tables is not supported by Fuel\Core\Database_PDO_Connection"

    Tried doing a regular query too and got "Parse Error - invalid data source name".

    Maybe something is wrong with the php version used for the CLI on osx.
  • Hmm... Yeah, bad suggestion.

    On OSX, it's a common problem that the CLI version of PHP loads a different php.ini file from the SAPI version, which can cause a lot of misery too. But usually it already stops before this, and complains about PDO not being available.

    What happens if you try this in the console:

    Fuel::$env;

    Does this say "development"? and

    \Config::load('db');

    should dump the contents of your development db.php file...
  • Doing "Fuel::$env;" gives me "development".

    And doing "\Config::load('db');" returns false :/

    This is my db.php file in the development folder.


    <?php
    /**
    * The development database settings. These get merged with the global settings.
    */

    return array(
    'default' => array(
    'connection' => array(
    'dsn' => 'mysql:host=localhost;dbname=fuel_dev',
    'username' => 'root',
    'password' => '',
    ),
    ),
    );
  • And the website itself runs fine, including database access? Now this is weird.

    You haven't changed locations (paths) of Fuel components? And forgot to change APPPATH etc in the oil script?
  • Yeah, website works. I've been playing around with orm models all day yesterday. Not having any problems at all.

    The only things i've moved around is the modules and themes folder. Other than that it's all from stock.

    I tried replacing everything with a totally clean version of fuel now, only getting the composer packages and copying the auth and ormauth config files. Now when i run "Config::load('db')" i get the config file but running "DB::list_tables()" gives me "Parse Error - Database type not defined in configuration" and if i try loading the config after that i get false.

    And doing the auth migrate command still gives me the same errors :/
  • If load() returns false, then you're not on the latest version.

    Old versions would only return the loaded config on first load, and would return false if the config is already loaded. This behaviour has been changed on Aug 28, 2012, so almost a year ago.
  • Thats not possible, i downloaded the 1.6 version from the frontpage and have to do a composer install. If i were running an old version i would't have to do that.
  • Why not?

    As of 2.0, Composer will be required for everything, including the framework itself.

    But running composer is a one-time thing, and you can even do that on a different system and copy fuel/vendor over if you can't. Our production servers don't have an outgoing internet connection either, so we can't run composer in production as well...

    If you want to stick to an old version, fine, but then you have to live with the bugs present in that version, and backport fixes yourself (if possible). You can't expect us to fix this for you.
  • I did a install on my windows 7 desktop pc also, get the same behavior from Config::load('db') there, returns the config the first time, false after that.

    Doing the migration works here tough even if i get an error message.

    "Error - Class 'Auth' not found in PKGPATH/auth/migrations/005_auth_create_authdefaults.php on line 93"

    Looking at the line giving the error i see that the admin account is created here so no admin account has been created.

    Edit: Forgot to put the auth package on the always loaded list, might have been why i got the error so i did another clean install om the win7 pc and now it works here at least.

    And its not possible that i'm on an older version when i downloaded the 1.6 package directly from here on fuelphp.com. The filename is even fuelphp-1.6.zip
  • Looked into the code, and it seems to be changed some time ago.

    The first time you load a config file, it will return the loaded config. After that, any attempt to load the same file will return false.

    If you get false returned when you try to load the config file in the console, that means the file is already loaded. Which begs the question what is loading the config, since the console doesn't do any database queries...
  • I've solved it now.

    Must have been something wrong with php. I removed xampp, installed latest version of mamp instead with never versions of everything and also changed the php install used in the CLI and now it all works good :)
  • You should check out Vagrant. You'll never go back to XAMPP/MAMP again.
  • Cool, will definitely have a look at that! Haven't been very pleased with either xampp or mamp.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion