If you include bean_admin_ui as a dependency in an installation profile, the installation of the profile fails.

This is OK, and works:

dependencies[] = bean

This doesn't work, and results in the following errors:

dependencies[] = bean
dependencies[] = bean_admin_ui
An AJAX HTTP error occurred. HTTP Result Code: 200 Debugging information follows. Path: http://alumni.build/install.php?profile=alumni&locale=en&id=1&op=do StatusText: OK ResponseText: Home | Drupal @import url("http://alumni.build/modules/system/system.theme.css?0"); @import url("http://alumni.build/modules/system/system.menus.css?0"); @import url("http://alumni.build/modules/system/system.messages.css?0"); @import url("http://alumni.build/modules/system/system.base.css?0"); @import url("http://alumni.build/modules/field/theme/field.css?0"); @import url("http://alumni.build/profiles/alumni/modules/contrib/logintoboggan/logint..."); @import url("http://alumni.build/modules/node/node.css?0"); @import url("http://alumni.build/modules/user/user.css?0"); @import url("http://alumni.build/profiles/alumni/modules/contrib/views/css/views.css?0"); @import url("http://alumni.build/modules/system/system.admin.css?0"); @import url("http://alumni.build/modules/system/system.maintenance.css?0"); @import url("http://alumni.build/profiles/alumni/modules/contrib/ctools/css/ctools.css?0"); @import url("http://alumni.build/profiles/alumni/modules/contrib/date/date_popup/them..."); @import url("http://alumni.build/profiles/alumni/modules/contrib/date/date_api/date.c..."); @import url("http://alumni.build/themes/seven/reset.css?0"); @import url("http://alumni.build/themes/seven/style.css?0"); Home Installation tasksChoose profile(done)Choose language(done)Verify requirements(done)Set up database(done)Install profile(active)Configure siteFinished SQLSTATE[42S02]: Base table or view not found: 1146 Table 'alumni_build.bean_type' doesn't exist

I'm not sure why alumni_build.bean_type is being reported to not exist, as it should get created when the module is enabled. When the module is enabled manually from drush or the modules page, the table gets created without any errors.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

indytechcook’s picture

With all of the latest patches (including #1160056: Make Bean types exportable) is this still an issue?

mrfelton’s picture

Status: Active » Fixed

Nope. Seems to work without issue now.

mrfelton’s picture

Status: Fixed » Active

Infact. I take that back. If you add bean_admin_ui as a dependency in an installation profile it works ok. If you have bean_admin_ui as a dependency inside a feature that is included in an installation profile, then you get the problem. The may be an issue with the features module. Sems like it's doing stuff in the wrong order or something.

adamdicarlo’s picture

I can confirm that I'm experiencing the same thing as @mrfelton on an installation profile -- if the Feature module declares bean_admin_ui as a dependency, the installation crashes, with that bean_type table missing error.

I've also just run into the exact same thing with mediafront_preset and the MediaFront module, so I'm thinking Features/CTools are probably at fault.

adamdicarlo’s picture

The issue is that:
* Drupal (module_enable) starts enabling bean_admin_ui
* module_enable() starts rebuilding Drupal's registry
* CTools' registry_info_alter is triggered, which enumerates plugins and in doing so...
* CTools calls bean_admin_ui_bean_types() which calls...
* bean_admin_ui_get_types() which calls ctools_export_load_object('bean_type');...
* which queries the bean_type table, which is not yet installed, due to...
* module_enable calling registry_update() before installing the module's database schema.

The crash occurs intermittently but removing the bean_admin_ui dependency from a feature module usually does NOT fix the problem. The reason the crash is intermittent must have to do with non-determinism in the batch system (page loads occurring at different parts of the install process when enabling modules).

This is a real pain in the ass, seriously (I've spent several hours diagnosing this), and now I'm doubting that it could be considered a CTools bug. I think I can write a hacky patch to prevent this crash and illustrate more clearly where Bean Admin UI is screwing the pooch.

adamdicarlo’s picture

Here's a patch that fixes the crash for me, as best as I can tell (I've installed several times with it, with different modules sets, not seeing the crash).

adamdicarlo’s picture

Status: Active » Needs review
adamdicarlo’s picture

Rerolled the patch to avoid crashing when not in installation mode (drupal_get_installed_schema_version() isn't around during a normal page load), and added a descriptive comment.

Edit: I haven't actually experienced this crash even once, but I'd think there's a potential for it, and this patch deserves a decent explanation -- thus the reroll.

indytechcook’s picture

Thanks for the patch adamdicarlo. I didn't experience this because I don't really use the UI :)

Not exactly sure it's this modules fault though. Shouldn't making the bean_admin_ui a dependency on bean be enough? That is a discussion for another day.

indytechcook’s picture

Status: Needs review » Fixed
adamdicarlo’s picture

Well, it's not that Bean isn't properly installed first -- bean_admin_ui is the module that creates the bean_types table. In other words it's its OWN table it was trying to query during installation before Drupal installed its schema.

Great to see the patch get in. Thanks!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

stijndm’s picture

Version: 7.x-1.x-dev » 7.x-1.0-beta9
Status: Closed (fixed) » Needs work

I am having this issue again with the current beta9 release. This time an error is triggered trying to write something to the watchdog table which doesn't exist yet. It seems to be coming from a ctools type plugin.

gmclelland’s picture

I tested with beta-6(works fine) and beta-9(works fine), but beta-10 threw errors.

Here is the drush error:

Starting Drupal installation. This takes a few seconds ...                                                   [ok]
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'tester_dev.watchdog' doesn't exist: INSERT INTO {watchdog} (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9); Array
(
    [:db_insert_placeholder_0] => 0
    [:db_insert_placeholder_1] => ctools
    [:db_insert_placeholder_2] => Plugin @plugin of plugin type @owner:@type points to nonexistent file @file for class handler @class.
    [:db_insert_placeholder_3] => a:5:{s:7:"@plugin";s:4:"bean";s:6:"@owner";s:4:"bean";s:5:"@type";s:5:"types";s:5:"@file";s:54:"profiles/da7/modules/contrib/bean/BeanPlugin.class.php";s:6:"@class";s:7:"handler";}
    [:db_insert_placeholder_4] => 5
    [:db_insert_placeholder_5] => 
    [:db_insert_placeholder_6] => http://tester.dev/index.php
    [:db_insert_placeholder_7] => 
    [:db_insert_placeholder_8] => 127.0.0.1
    [:db_insert_placeholder_9] => 1325804100
)
 in dblog_watchdog() (line 157 of /home/quickstart/websites/tester.dev/modules/dblog/dblog.module).
Drush command terminated abnormally due to an unrecoverable error.                                           [error]

Hope that helps

Steven Jones’s picture

This is a really odd bug that occurs during install using a profile, a fix is to add a dependency on the dblog module, but that might not always be desirable, so I've removed the dependency in a hook_system_info_alter in the attached patch.

The installer is so weird.

Steven Jones’s picture

And a patch that applies against beta10.

gmclelland’s picture

Patch provided in #16 worked for me when installing my install profile. Thanks Steven

indytechcook’s picture

Version: 7.x-1.0-beta9 » 7.x-1.0-beta10
Status: Needs work » Needs review

Wow, that's odd. Setting to needs review to let tests run.

Steven Jones’s picture

Status: Needs review » Needs work

But, to be clear that code should probably not be committed, not without huge signs about why it's needed etc. etc.

I would really like to know how dblog modules comes to be enabled before its DB tables have been created, thus leading to the error we're seeing. I wonder if this is a bug in the core installer or logging subsystem somewhere.

gmclelland’s picture

The patch in #16 wouldn't apply to the rc1 release so I made a reroll of the patch. Here you go. I tested it on my install profile and it works.

devonwarren’s picture

Thanks, gmclelland! This patch fixed my issue with the rc1 bean release

gmclelland’s picture

FYI.. I'm not seeing this issue anymore with 1.0-rc4

kaizerking’s picture

Version: 7.x-1.0-beta10 » 7.x-1.0-rc4

I am unable to install on erecruiter install profile on rc4 tried on dev too same error
Fatal error: Maximum function nesting level of '100' reached, aborting! in E:\wamp\www\includes\database\database.inc on line 429
removing the module and running update.php restores site back

indytechcook’s picture

@kaizerking did that patch from #20 fix your issue?

kaizerking’s picture

#patch20 solved the issue

saltednut’s picture

Title: Unable to install Bean Admin UI from an installation profile. » Unable to install Bean plugins from an installation profile.
Status: Needs work » Active

Bean Admin UI introduces the generic plugin. So the problem is when included any Bean plugins with an install profile.

@Steven Jones - this patch at least allows install profiles to run, but there must be something wrong with ctools thats causing these errors. Even on a site where I enable a bean plugin after the install, I'm seeing the ctools errors where it looks for the wrong include file.

Ex: "Plugin bean_tax_listing of plugin type bean:types points to nonexistent file sites/all/modules/bean_tax/plugins/bean/TaxListingBean.class.php for class handler handler."

I see this every time I enable that plugin - during an install profile run, it kills everything. On a regular site, just enabling the module is fine... but why fill the log with these errors?

The only way I've gotten around this is to actually rename my plugin's file to match the [ClassName].class.php format. But in all bean API docs up to this point, we've used [plugin_machine_name].bean.inc for the format.

So we're doing something wrong on the Bean plugin end. It's not a ctools problem.

IRC transcript to follow:

10:53 < brantwynn> Plugins -- tools to make it easy for modules to let other modules implement plugins from .inc files. The plugin I am using is Bean. I made a plugin for it. I follow the API and delcare my include. It works. Yet, ctools gives this watchdog error: "Plugin bean_tax_listing of plugin type bean:types points to nonexistent file sites/all/modules/bean_tax/plugins/bean/TaxListingBean.class.php for class handler handler." Should I rename my file?

10:53 < brantwynn> This is the module code where 'file' is set: http://drupalcode.org/project/bean_tax.git/blob/refs/heads/7.x-2.x:/bean_tax.module

10:57 < merlinofchaos> brantwynn: When using OO plugins, the system assumes that the class will be in a separate file. This allows it to use Drupal 7's autoload system, so I *highly* recommend doing that (though you can, in fact disable this assumption if you really want).

10:59 < merlinofchaos> brantwynn: So you've got, for example, bean_tax.listing.inc -- that would include the $plugin = array() part. Then TaxListingBean.class.php would contain the class definition.

10:59 < merlinofchaos> brantwynn: CTools will register the file for you, so all you need to do is do a drush cc registry when you've set that up, and the class (and most importantly, all parent-chains if you use inheritance at all) will be autoloaded correctly.

This sounds then like we need to update the API, docs, example modules, etc. I don't think a patch is needed to dance around dblog if plugins are handled a little differently.

saltednut’s picture

Status: Active » Needs review
FileSize
10.78 KB

This was talked about in IRC and agreed to do the autoloading the ctools way for 1.x.

I thought it best to update both bean itself and the bean_admin_ui plugin for consistency.

Will update docs, bean_examples and my plugins if this is approved.

Status: Needs review » Needs work

The last submitted patch, bean-use-ctools-style-plugin-names-1179420-27.patch, failed testing.

saltednut’s picture

Version: 7.x-1.0-rc4 » 7.x-1.x-dev
FileSize
10.77 KB

Whitespaces?

saltednut’s picture

Status: Needs work » Needs review

Testbot: Don't hate.

indytechcook’s picture

Status: Needs review » Needs work

Make sure you add an update statement that runs registry_rebuild().

I'd like some more testing on this on an env with several beans and from more people.

saltednut’s picture

Status: Needs work » Needs review
FileSize
11.73 KB

Reroll of #29 w/ added update hooks.

Also fixed missing file declaration files[] = plugins/BeanDefault.class.php in bean.info

saltednut’s picture

Issue tags: +demo_framework

tagging

saltednut’s picture

Status: Needs review » Closed (fixed)

Committed to 7.x