Closed (fixed)
Project:
Panels
Version:
6.x-3.x-dev
Component:
Code
Priority:
Minor
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
12 May 2009 at 23:19 UTC
Updated:
7 Aug 2009 at 02:30 UTC
Jump to comment: Most recent file
Hello,
panels is making great progress - thanks a lot. Upgrades work fine.
I noticed that on a fresh install, the requirements check does not seem to work.
As far as I can see, there should be "define('PANELS_REQUIRED_CTOOLS_API', '1.0.1');" inserted in panels.install. But somehow panels_requirements do not pass anyway, when installing via an installation profile using the following order 'ctools', 'delegator', 'panels'.
modules used:
panels-DRUPAL-6-3 and ctools-HEAD, both checked out today.
| Comment | File | Size | Author |
|---|---|---|---|
| #16 | panels-n460902.patch | 851 bytes | damienmckenna |
Comments
Comment #1
dawehnerits definied on the top of
panels.module
define('PANELS_REQUIRED_CTOOLS_API', '1.0.1');
Comment #2
merlinofchaos commentedI'm surprised that the requirements do not pass, though. I updated the demo site to -dev just a couple of nights ago, both using 1.0.1 and it *does* pass, so I am a little confused.
Comment #3
ano1 commentedI have experienced the same behavior that drupal24 noted in his post.
Comment #4
merlinofchaos commentedHm. Yes, it would appear that the install process does not load the .module file. That is obnoxious, as I thought it did. Not sure how to fix this offhand. Redefining the constant is a bad one, as then the version # has to be in 2 places and that's got a high chance of breaking.
Comment #5
merlinofchaos commentedOk, I believe I have this all fixed in Panels CVS now.
Comment #7
digi24 commentedHmm, I noticed another issue, closely related to the problem mentioned before. Feel free to close it if you consider it unimportant:
When using a custom installation profile, hook_requirements is being called before any databases are created. This implies that drupal_get_path cannot work, and
fails. as far as "include_once 'panels.module';" is concerned this is a minor issue, as we do not need the path, but with respect to ctools it cannot be assumed that the module is in the same folder hierarchy.
PS:
A possible solution would be to move the requirements phase from "install" to "runtime". Would this cause serious errors, in case a user with an outdated ctools module installed panels?
Or maybe something like this (untested)
Comment #8
damienmckenna@drupal24: the problem with using it in an installation profile is that the system table does not exist, therefore it cannot find the path to the directory, e.g.:
What might be worth doing is checking for whether one of the site installation functions, e.g. "install_verify_drupal", exists as that should only ever be available during site installation vs normal module installation. Of course, at that point I'm not sure how it could verify the paths without doing some crazy code?
Damien
Comment #9
damienmckennaFYI, what I did to limp through this was to change line 9 in panels.install to the following:
Definitely not a clean fix, but it at least allowed me to add Panels to an installation profile.
Comment #10
digi24 commentedThanks a lot Damien!
You actually showed me a flaw in my understanding of Drupal. I always assumed that entries in the system table are only created after the actual install of a module. That is why I thought we would have to get rid of drupal_get_path in the install files.
Thanks a lot for your suggestion this looks a lot easier and is probably a good best practice solution. If I use my install profile, I can assume that the other files match.
Comment #11
damienmckennadrupal24: glad to be able to help, though obviously what I provided should be considered a band-aid at best, it really needs a proper fix.
Comment #12
merlinofchaos commentedDoes something like this fix this? (I don't have a profile handy to test with:)
Comment #13
merlinofchaos commentedIf possible I'd like to have this fixed for the rc coming up soon. Anyone with an install profile handy to test?
Comment #14
damienmckennamerlinofchaos: To verify what was going to be available, I changed the panels_requirement to the following to see what would happen:
It gave the following error:
( ! ) Warning: Table 'mysite.system' doesn't exist query: SELECT filename FROM system WHERE name = 'panels' AND type = 'module' in mysite/includes/database.mysql.inc on line 128Next idea? Would it be too crazy to search the entire directory structure to find "ctools.module"?
Comment #15
damienmckennaAnother test.
I inserted the code provided so it looks like:
This results in the following error:
FYI line 20 is:
Comment #16
damienmckennaSeems there's a cleaner way of identifying whether running an installation profile after all.
Comment #17
James Andres commentedDamienMcKenna, panels-n460902.patch works well for me. Thanks.
Comment #18
merlinofchaos commentedCommitted! THanks!
Comment #19
dman commentedI got the same.
Thanks for the fix.
FTR, I've usually used :
before the days of module_get_include when I needed a nearby file. Saves trusting the absraction layer or requiring a database hit etc etc. Sometimes simple is simpler.