I'm adding a Rules conditions form to my page like this:
$conditions = rules_config_load('uc_taxes_' . $rate_id);
if ($conditions) {
$conditions->form($form, $form_state);
}
($form is the Forms API array that will be returned from the builder function where this code appears.) The result is shown in the attached image, and the result appears correct.
BUT, the problem is that all the links are wrong - the "edit", "delete", "Add condition", "Add or", and "Add and" links all look like:
admin/config/workflow/rules/manage/ ...
whereas they should really be:
admin/config/workflow/rules/components/manage/ ...
(Note that "components" should appear in the path, but it doesn't.)
Specifically, the "edit" link points to:
admin/config/workflow/rules/manage/uc_taxes_2/edit/2 which is a dead link. It should be:
admin/config/workflow/rules/components/manage/uc_taxes_2/edit/2
The attached image also shows the bad link.
I'm running off the 7.x-2.x branch in the repository. I've pulled the latest changes but this is still an issue.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | rules_base_path_default.patch | 964 bytes | fago |
| rules.png | 1.21 MB | tr |
Comments
Comment #1
klausiMake sure to set the UI base path before generating the form:
RulesPluginUI::basePath = 'admin/config/mymodule/foo';
I think that is missing in the documentation, please add that at http://drupal.org/node/905262 if it works for you.
I'm part of the Rules Issue Squad, helping out in the issue queue. You can join, too!
Comment #2
tr commentedNote that "mymodule" has nothing to do with the problem - Rules is generating the form and generating the links on that form using its own internal paths to the Rules-specific configuration pages.
RulesPluginUI::$basePath is empty by default, so Rules is generating the incorrect
admin/config/workflow/rules/managepart of the path somewhere inside the Rules code if and only if $basePath is not defined. My contention is that Rules should be generating the correctadmin/config/workflow/rules/components/manageinstead.It seems very very wrong and not object-oriented at all for me to have to tell Rules where the Rules configurations pages are. What happens when Rules changes its internal path - do all modules that use Rules break at that point? Why should I have to care (or even know) what paths Rules uses internally? If this is the solution, it represents a flaw in the Rules architecture.
The following works - note the $ before the member variable name - but as you can see I'm not adding anything that's specific to my module; it is all a Rules path:
If I don't specify this, Rules defaults to
admin/config/workflow/rules, so it seems that Rules' default $basePath is wrong for this form.Comment #3
klausiThe idea of $basePath is that third party modules can embed Rules plugins easily on their configuration pages while maintaining a consistent path scheme.
Example: The configuration page of my module is at "admin/config/mymodule" where I list some Rules components. If a user clicks on such a component, she would expect to get to a path like "admin/config/mymodule/manage/component_xy/edit" and not to a completely different path like "admin/config/rules/components/component_xy/edit". Is also good for preserving bread crumbs etc.
However, you are right that the default is broken. We have to add "/components" to the path if we are dealing with components.
Comment #4
fagoIndeed, a better default makes sense. What about that?
Comment #5
tr commentedTested this patch with Ubercart and it fixes all the issues with Rules paths. Thank you.
Comment #6
fagoGreat, committed.