Development

#1561 (defect: AdminGenerator sfGeneratorConfigHandler.class.php can't find module name)

You must first sign up to be able to contribute.

Ticket #1561 (closed defect: fixed)

Opened 5 years ago

Last modified 4 years ago

defect: AdminGenerator sfGeneratorConfigHandler.class.php can't find module name

Reported by: Karl.Katzke Assigned to: fabien
Priority: major Milestone:
Component: generator Version: 1.0.0
Keywords: Cc:
Qualification: Unreviewed

Description

Directly after initing a new admin-generated module from the command line, going to the module in either dev or live mode will generate an exception:

[sfParseException] You must specify a "moduleName"

The trace is below:

stack trace at () in SF_SYMFONY_LIB_DIR/generator/sfCrudGenerator.class.php line 52 ...

$error = 'You must specify a "%s"';

$error = sprintf($error, $entry);

throw new sfParseException($error);

}

}

at sfCrudGenerator->generate(array('model_class' => 'User', 'theme' => 'default', null)) in SF_SYMFONY_LIB_DIR/generator/sfGeneratorManager.class.php line 55 ... at sfGeneratorManager->generate('sfPropelAdminGenerator', array('model_class' => 'User', 'theme' => 'default', null)) in SF_SYMFONY_LIB_DIR/config/sfGeneratorConfigHandler.class.php line 76 ... at sfGeneratorConfigHandler->execute(array('/Applications/MAMP/bin/php5/lib/php/data/symfony/config/generator.yml', '/Users/karlkatzke/work/corpworlds/apps/backend/config/generator.yml', '/Users/karlkatzke/work/corpworlds/apps/backend/modules/user/config/generator.yml')) in SF_SYMFONY_LIB_DIR/config/sfConfigCache.class.php line 103 ... at sfConfigCache->callHandler('modules/user/config/generator.yml', array('/Applications/MAMP/bin/php5/lib/php/data/symfony/config/generator.yml', '/Users/karlkatzke/work/corpworlds/apps/backend/config/generator.yml', '/Users/karlkatzke/work/corpworlds/apps/backend/modules/user/config/generator.yml'), '/Users/karlkatzke/work/corpworlds/cache/backend/dev/config/modules_user_config_generator.yml.php') in SF_SYMFONY_LIB_DIR/config/sfConfigCache.class.php line 190 ... at sfConfigCache->checkConfig('modules/user/config/generator.yml', '1') in SF_SYMFONY_LIB_DIR/config/sfConfigCache.class.php line 248 ... at sfConfigCache->import('modules/user/config/generator.yml', '1', '1') in SF_SYMFONY_LIB_DIR/controller/sfController.class.php line 194 ... at sfController->forward('user', 'index') in SF_SYMFONY_LIB_DIR/controller/sfFrontWebController.class.php line 48 ... at sfFrontWebController->dispatch() in SF_ROOT_DIR/web/backend_dev.php line 10 ...

The problem is a typo within sfGeneratorConfigHandler.class.php - line 69 looks like:

preg_match('#'.sfConfig::get('sf_app_module_dir_name').'/([/]+)/#', $configFiles[1], $match);

... $configFiles[1] should be $configFiles[2], because $configFiles[0] is $projectroot/config, $configfiles[1] is $projectroot/apps/$project/config/generator.yml, and $configfiles[3] is $projectroot/apps/$project/modules/$module/config/generator.yml -- it would be rather difficult to get the modulename from the $configFiles[1] variable.

Either way, that's kind of a nasty hack that depends on a config file being present for the generated files, and really should be thought hard about. A good solution would be to add the module name to the generator.yml or the actions.class.php file, as it's known when we do the propel-init-admin... but has to be hacked out later.

Attachments

sfGeneratorConfigHandler.class.php.patch (0.7 kB) - added by blerou on 04/02/08 10:31:34.

Change History

02/08/08 23:27:32 changed by dwhittle

  • qualification set to Unreviewed.

Can you create a patch for 1.0 and 1.1 please?

04/02/08 10:31:20 changed by blerou

PATCH I ran into the same problem with 1.0.12 (and 1.0.13), 1.0.11 works fine.

The solution: in config/sfGeneratorConfigHandler.class.php change the index of $configFiles array from 0 to 1 in line 69.

04/02/08 10:31:34 changed by blerou

  • attachment sfGeneratorConfigHandler.class.php.patch added.

04/02/08 10:53:41 changed by fabien

The index is ok. You must have another problem. Can you give use more information. Are you using symfony 1.0 and 1.1 on the same machine?

04/03/08 16:44:15 changed by blerou

I use 1.0

When I upgrade the symfony 1.0.11 to 1.0.12 (PEAR install), I noticed the followings:

( ! ) Notice: Undefined offset: 1 in C:\xampp\htdocs\xxx\lib\symfony\config\sfGeneratorConfigHandler.class.php on line 70 Call Stack # Time Memory Function Location 1 0.0009 69864 {main}( ) ..\backend_dev.php:0 2 0.1777 3588824 sfFrontWebController->dispatch( ) ..\backend_dev.php:10 3 0.1791 3608256 sfController->forward( ) ..\sfFrontWebController.class.php:48 4 0.1795 3613936 sfConfigCache->import( ) ..\sfController.class.php:194 5 0.1795 3613936 sfConfigCache->checkConfig( ) ..\sfConfigCache.class.php:248 6 0.1840 3616576 sfConfigCache->callHandler( ) ..\sfConfigCache.class.php:190 7 0.2200 4195072 sfGeneratorConfigHandler->execute( ) ..\sfConfigCache.class.php:103

( ! ) Warning: Cannot modify header information - headers already sent by (output started at C:\xampp\htdocs\xxx\lib\symfony\config\sfGeneratorConfigHandler.class.php:70) in C:\xampp\htdocs\xxx\lib\symfony\exception\sfException.class.php on line 101 Call Stack # Time Memory Function Location 1 0.0009 69864 {main}( ) ..\backend_dev.php:0 2 0.1777 3588824 sfFrontWebController->dispatch( ) ..\backend_dev.php:10 3 0.3611 5024376 sfException->printStackTrace( ) ..\sfFrontWebController.class.php:57 4 0.3611 5027240 header ( ) ..\sfException.class.php:101 [sfParseException] You must specify a "moduleName" stack trace

  • at () in SF_ROOT_DIR\lib\symfony\generator\sfCrudGenerator.class.php line 52 ...
    1. $error = 'You must specify a "%s"';
    2. $error = sprintf($error, $entry); 51.
    3. throw new sfParseException($error);
    4. }
    5. }

55.

This killed all of my admin generator based pages. Then i compared the sfGeneratorConfigHandler.class.php in 1.0.11 and 1.0.12, and i saw the only difference is the $configFiles array index. So i changed it, and now i'm happy :).

04/03/08 19:33:22 changed by fabien

  • status changed from new to closed.
  • resolution set to fixed.

Check that when upgrading via PEAR, the file symfony/data/config/generator.yml in PEAR is deleted. Looks like it's not the case.