Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comments
Comment #1
indytechcook CreditAttribution: indytechcook commentedWith all of the latest patches (including #1160056: Make Bean types exportable) is this still an issue?
Comment #2
mrfelton CreditAttribution: mrfelton commentedNope. Seems to work without issue now.
Comment #3
mrfelton CreditAttribution: mrfelton commentedInfact. 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.
Comment #4
adamdicarlo CreditAttribution: adamdicarlo commentedI 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.
Comment #5
adamdicarlo CreditAttribution: adamdicarlo commentedThe 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 callsctools_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.
Comment #6
adamdicarlo CreditAttribution: adamdicarlo commentedHere'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).
Comment #7
adamdicarlo CreditAttribution: adamdicarlo commentedComment #8
adamdicarlo CreditAttribution: adamdicarlo commentedRerolled 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.
Comment #9
indytechcook CreditAttribution: indytechcook commentedThanks 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.
Comment #10
indytechcook CreditAttribution: indytechcook commentedThis patch is applied to the 7.x branch
http://drupal.org/commitlog/commit/22232/75e251868f8185e160f96165ab5a232...
Comment #11
adamdicarlo CreditAttribution: adamdicarlo commentedWell, 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!
Comment #13
stijndm CreditAttribution: stijndm commentedI 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.
Comment #14
gmclelland CreditAttribution: gmclelland commentedI tested with beta-6(works fine) and beta-9(works fine), but beta-10 threw errors.
Here is the drush error:
Hope that helps
Comment #15
Steven Jones CreditAttribution: Steven Jones commentedThis 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.
Comment #16
Steven Jones CreditAttribution: Steven Jones commentedAnd a patch that applies against beta10.
Comment #17
gmclelland CreditAttribution: gmclelland commentedPatch provided in #16 worked for me when installing my install profile. Thanks Steven
Comment #18
indytechcook CreditAttribution: indytechcook commentedWow, that's odd. Setting to needs review to let tests run.
Comment #19
Steven Jones CreditAttribution: Steven Jones commentedBut, 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.
Comment #20
gmclelland CreditAttribution: gmclelland commentedThe 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.
Comment #21
devonwarren CreditAttribution: devonwarren commentedThanks, gmclelland! This patch fixed my issue with the rc1 bean release
Comment #22
gmclelland CreditAttribution: gmclelland commentedFYI.. I'm not seeing this issue anymore with 1.0-rc4
Comment #23
kaizerking CreditAttribution: kaizerking commentedI 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
Comment #24
indytechcook CreditAttribution: indytechcook commented@kaizerking did that patch from #20 fix your issue?
Comment #25
kaizerking CreditAttribution: kaizerking commented#patch20 solved the issue
Comment #26
saltednutBean 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.
Comment #27
saltednutThis 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.
Comment #29
saltednutWhitespaces?
Comment #30
saltednutTestbot: Don't hate.
Comment #31
indytechcook CreditAttribution: indytechcook commentedMake 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.
Comment #32
saltednutReroll of #29 w/ added update hooks.
Also fixed missing file declaration
files[] = plugins/BeanDefault.class.php
in bean.infoComment #33
saltednuttagging
Comment #34
saltednutCommitted to 7.x