Hi. What about implementing hook_depend(). I mean module that depends on some module (e.g. taxonomy) must define function modulename_depend() { return array('taxonomy'); } Then if user has no taxonomy module turned on - he/she will be asked to do so or not. If not - he/she will be told that modulename can't be installed. Also when user disables taxonomy module then he/she will be told that modulename depends on taxonomy module and so modulename will be also turned off.
If this was to be implemented, it should be taken further to include versioning. As more modules are interconnected, this will become more of an issue. ~Rob Doq Doques wrote:
Hi. What about implementing hook_depend(). I mean module that depends on some module (e.g. taxonomy) must define
function modulename_depend() { return array('taxonomy'); }
Then if user has no taxonomy module turned on - he/she will be asked to do so or not. If not - he/she will be told that modulename can't be installed.
Also when user disables taxonomy module then he/she will be told that modulename depends on taxonomy module and so modulename will be also turned off.
-- ---------------------------------------------------------- It is by Caffeine alone that I set my mind in motion It is by the beans of Java, that my thoughts acquire speed The hands acquire shakes; the shakes become a warning It is by Caffeine alone that I set my mind in motion
I think the install system that is under development does have dependancy checking as part of it. On 5/27/06, Robert Wohleb <rob@techsanctuary.com> wrote:
If this was to be implemented, it should be taken further to include versioning. As more modules are interconnected, this will become more of an issue.
~Rob
Doq Doques wrote:
Hi. What about implementing hook_depend(). I mean module that depends on some module (e.g. taxonomy) must define
function modulename_depend() { return array('taxonomy'); }
Then if user has no taxonomy module turned on - he/she will be asked to do so or not. If not - he/she will be told that modulename can't be installed.
Also when user disables taxonomy module then he/she will be told that modulename depends on taxonomy module and so modulename will be also turned off.
-- ---------------------------------------------------------- It is by Caffeine alone that I set my mind in motion It is by the beans of Java, that my thoughts acquire speed The hands acquire shakes; the shakes become a warning It is by Caffeine alone that I set my mind in motion
The 4.7 install system does not contain this. I'll have to check CVS. Even then, I still think this would make more sense as a module hook. It would be nice to at least see module versions on the admin/modules page. Such a system could also allow for a new module to notify admins of module updates ;) Versioning will really be important for the API modules that don't have their own interface. It would be nice to be able to release a new API under the same module name. ~Rob Khalid B wrote:
I think the install system that is under development does have dependancy checking as part of it.
On 5/27/06, Robert Wohleb <rob@techsanctuary.com> wrote:
If this was to be implemented, it should be taken further to include versioning. As more modules are interconnected, this will become more of an issue.
~Rob
Doq Doques wrote:
Hi. What about implementing hook_depend(). I mean module that depends on some module (e.g. taxonomy) must define
function modulename_depend() { return array('taxonomy'); }
Then if user has no taxonomy module turned on - he/she will be asked to do so or not. If not - he/she will be told that modulename can't be installed.
Also when user disables taxonomy module then he/she will be told that modulename depends on taxonomy module and so modulename will be also turned off.
-- ---------------------------------------------------------- It is by Caffeine alone that I set my mind in motion It is by the beans of Java, that my thoughts acquire speed The hands acquire shakes; the shakes become a warning It is by Caffeine alone that I set my mind in motion
-- ---------------------------------------------------------- It is by Caffeine alone that I set my mind in motion It is by the beans of Java, that my thoughts acquire speed The hands acquire shakes; the shakes become a warning It is by Caffeine alone that I set my mind in motion
On 5/27/06, Robert Wohleb <rob@techsanctuary.com> wrote:
The 4.7 install system does not contain this. I'll have to check CVS.
Not the 4.7 one. The one under development. Here is a (dated?) document about the goals and design: http://drupal.org/node/22472
Even then, I still think this would make more sense as a module hook. It would be nice to at least see module versions on the admin/modules page. Such a system could also allow for a new module to notify admins of module updates ;)
That has value, but better coordinate with Adrian to avoid duplication of effort/code.
Versioning will really be important for the API modules that don't have their own interface. It would be nice to be able to release a new API under the same module name.
Agree. I am not debating the value of this. I am trying to avoid having efforts wasted, or having two ways of doing the same thing.
Khalid B wrote:
I think the install system that is under development does have dependancy checking as part of it.
On 5/27/06, Robert Wohleb <rob@techsanctuary.com> wrote:
If this was to be implemented, it should be taken further to include versioning. As more modules are interconnected, this will become more of an issue.
~Rob
Doq Doques wrote:
Hi. What about implementing hook_depend(). I mean module that depends on some module (e.g. taxonomy) must define
function modulename_depend() { return array('taxonomy'); }
Then if user has no taxonomy module turned on - he/she will be asked to do so or not. If not - he/she will be told that modulename can't be installed.
Also when user disables taxonomy module then he/she will be told that modulename depends on taxonomy module and so modulename will be also turned off.
-- ---------------------------------------------------------- It is by Caffeine alone that I set my mind in motion It is by the beans of Java, that my thoughts acquire speed The hands acquire shakes; the shakes become a warning It is by Caffeine alone that I set my mind in motion
-- ---------------------------------------------------------- It is by Caffeine alone that I set my mind in motion It is by the beans of Java, that my thoughts acquire speed The hands acquire shakes; the shakes become a warning It is by Caffeine alone that I set my mind in motion
On 27 May 2006, at 3:20 PM, Doq Doques wrote:
Hi. What about implementing hook_depend(). I mean module that depends on some module (e.g. taxonomy) must define There is a patch on drupal.org that does this already. It has the problem that you need to load the module to get this, and at that point it's already too late. You need to be able to build the dependency tree without the module being loaded.
I have code in the bryght svn* that does this through introducing ini files in each of the module directories, including multiple types of dependencies , ie: depends, suggests, recommends (like debian does it). This code will also support stuff like virtual packages (ie: provides: installl-profile) , for putting together install profiles and things. At the moment progress on dependency.inc has stalled a bit, because me and vlado are busy working on the proper split mode for templates (in the same repository, as each module in it's own directory is a requirement for both, and i am implementing the dependency stuff in dependencies.module* first). I hope to get back to dependency.inc soon, as the most basic setup is very simple. The code can already scale the dependency tree and find missing dependencies, but at the moment it is only testing if the module is available, (ie: in the modules directory) It needs to make a distinction between modules being available, modules already enabled, modules being enabled in the same step, AND it also propbably needs to have some knowledge on whether a module is installed already. I still need to integrate the dependency checking with the form_alter interface provided by dependencies.module too (although the library is working fine). bryght svn : https://dev.bryght.com (in the repo it's in the /templates branch) Dependencies module: http://drupal.org/project/dependencies
Also when user disables taxonomy module then he/she will be told that modulename depends on taxonomy module and so modulename will be also turned off. That's wrong, there's definite user interaction there (ie: yes/no)
in fact, probably the hardest part of the dependencies project is intelligent user interface design for the modules screen. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On 27-May-06, at 3:41 PM, Adrian Rossouw wrote:
bryght svn : https://dev.bryght.com (in the repo it's in the /templates branch)
or... if you want to see it for real you could try: https://svn.bryght.com/dev/browser/templates -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
Hi all, I just got this issue on a module of mine:- http://drupal.org/node/65893 I have managed to reproduce the error and as far as I can see the fix is trivial. However, it raises something I'm not 100% sure on. The Drupal API docs state for hook_node_info(): "The 'name' value is a human-readable name for the node..." Now, the error as reported to me is the name I use is "Jan's node" which I believe to meet the criteria in the hook definition. The problem comes in nmoderation.module due to this line:- $types = implode("','", variable_get('nmoderation_node_types', node_get_types())); which feeds through to the SQL query thus .. WHERE n.type IN ('$types') .. I can fix my module and remove the quote in the name but as far as I can tell nmoderation is not escaping before imploding. If the API says "human-readable" then "Jan's node" complies. So, is the bug my quote in the name or is the bug in nmoderation for not escaping a "human-readable" string? I'm normally careful about my quotes and do avoid them but in this case when I wrote the module I interpreted the spec a little too literally perhaps? Just looking for clarification. best regards --AjK
AjK wrote:
Hi all,
I just got this issue on a module of mine:-
I have managed to reproduce the error and as far as I can see the fix is trivial. However, it raises something I'm not 100% sure on. The Drupal API docs state for hook_node_info():
"The 'name' value is a human-readable name for the node..."
Now, the error as reported to me is the name I use is "Jan's node" which I believe to meet the criteria in the hook definition. The problem comes in nmoderation.module due to this line:-
$types = implode("','", variable_get('nmoderation_node_types', node_get_types()));
which feeds through to the SQL query thus
.. WHERE n.type IN ('$types') ..
I can fix my module and remove the quote in the name but as far as I can tell nmoderation is not escaping before imploding. If the API says "human-readable" then "Jan's node" complies. return array('janode' => array('name' => t("Jan's node"), 'base' => 'janode'));
is the code in question. IMHO there is a bug there somewhere, as "janode" should be used as the node type when inserting into the database. Cheers, Gerhard
return array('janode' => array('name' => t("Jan's node"), 'base' => 'janode'));
is the code in question. IMHO there is a bug there somewhere, as "janode" should be used as the node type when inserting into the database.
Gerhard Are you saying 'base' should be returned by node_get_types() and not 'name' in this case? If so, I can look at this and provide a patch if needed. best regards --AjK
AjK wrote:
return array('janode' => array('name' => t("Jan's node"), 'base' => 'janode'));
is the code in question. IMHO there is a bug there somewhere, as "janode" should be used as the node type when inserting into the database.
Gerhard
Are you saying 'base' should be returned by node_get_types() and not 'name' in this case?
I think so, yes. Cheers, Gerhard
Are you saying 'base' should be returned by node_get_types() and not 'name' in this case?
I think so, yes.
Gerhard, Thanks for your response, traced the "bug". best regards --AjK http://drupal.org/node/65893 http://drupal.org/node/65989 (with nmoderation patch to fix)
On May 27, 2006, at 9:20 AM, Doq Doques wrote:
Hi. What about implementing hook_depend(). I mean module that depends on some module (e.g. taxonomy) must define
function modulename_depend() { return array('taxonomy'); }
What would also be useful, at least potentially, is some way to indicate what order hooks should be evaluated in. Suppose that foo.module uses hook_form_alter() to add something to the node creation form. In order to write a module that changes the default value of that addition, you need to have the module name come after 'foo' in the alphabet (presumably in the local LOCALE, but perhaps by ASCII order). It would be nice to be able to have: function hook_depends() { return array('hook_form_alter' => array('foo', 'taxonomy')); } This would indicate that this module requires foo and taxonomy, and that hook_form_alter should be called after foo and taxonomy's have already been called. If there is a cycle that gets established, you would fall back to the current sorting order. Does this make sense? Ricky
On May 27, 2006, at 6:20 AM, Doq Doques wrote:
function modulename_depend() { return array('taxonomy'); }
for something like this for 4.7.x and the current HEAD of the cvs trunk, check out: http://drupal.org/node/54463 -derek (dww) p.s. anyone got any suggestions for a similar work-around/trick/best- practice for doing this kind of thing in 4.6.x?
participants (9)
-
Adrian Rossouw -
AjK -
Derek Wright -
Doq Doques -
Gerhard Killesreiter -
James Walker -
Khalid B -
Richard Morse -
Robert Wohleb