I realized that I had written some other modules for 6-x-2.x that could potentially be included with the NodeHierarchy module. I also realized the 6.x-2.x was starting to creep away from my slightly older copy, so I figured I'd better get these up here quicker!

The first, "nodehierarchy_recursive_pathauto," was an update of the 5-x code. I was running into some PHP timeout and memory issues, so I converted it to use Drupal 6's batch processing. It does unnecessarily run when the path hasn't been updated or the parent hasn't changed, but I haven't had the time to fix that yet. There is also a conditional for the revisioning module which stopped the recursive update if the node wasn't being published.

The second, "nodehierarchy_add_children_only" (which is kinda a misnomer now), adds two new permissions: 'can change existing nodes parent' and 'can add root level node'. Most of this originated from my work with the NodeHierarchyAccess module. I wanted the two new capabilities:

  • Allowing users to edit node's that use node hierarchy but not giving them the ability to change the parents. Users should not be prevented from creating new nodes and connecting them with a parent, but should be stopped from reassigning parents if they don't have the proper permissions.
  • Preventing users from adding a root level node. It will check to see if the content type's hierarchy settings apply; content types with node hierarchy's "Show item in menu" set to "Never" are ignored.

I've tested them against the latest 6-x-2.x (2010-May-18 ) but I have not tested them with the multiple parent feature. I imagine that could go bonkers, so it might be beneficial to check them out :) I hope these can help somebody out along the way.

CommentFileSizeAuthor
#9 811274_9.patch11.49 KBjbylsma
nodehierarchy_modules.tgz2.32 KBjbylsma

Comments

markhalliwell’s picture

markhalliwell
Primary language English
commented

Subscribing to this. I'm particularly interested in incorporating "nodehierarchy_recursive_pathauto" natively.

mustanggb’s picture

mustanggb commented

+1
I would all find all three features a welcomed addition

jbylsma’s picture

jbylsma commented

First off, sorry about being slow to respond.

I did have to make some changes to "nodehierarchy_recursive_pathauto," as the recursive function that got children was broken and was not getting beyond the first level of children. I updated it and it's available at github. I'd have no problem implementing it into NodeHierarchy; the main reason it was done outside was that I wasn't sure about maintenance of the module. I'm happy to be wrong here.

I haven't touched "nodehierarchy_add_children_only," but I don't expect anything to have changed much here. Again, if it is desired, I think it'd be great to have natively.

I still haven't done any testing of the code against the "multiple parents" stuff. My only immediate concerns would be updates with recursive looping within children and pathauto against children with multiple parents (potential for multiple paths). I'll hopefully be getting a little bit more time to checking out the functionality (and necessary workarounds) in the future, but I also thought the same thing in May :)

dan3h’s picture

dan3h commented

I just downloaded your module from github, enabled it, and my problem was solved!

I had pathauto populating the url_alias based on the node hierarchy, but when you edit the title of a node halfway down in the hierarchy, suddenly all of its children have out-of-date url_aliases.

But now it is fixed. Thanks!

markhalliwell’s picture

markhalliwell
Primary language English
commented

I almost added nodehierarchy_recursive_pathauto to the latest patch in #921198: Rework administration and node create/edit with new features and clean design

However, that patch is already huge and there still needs to be some work done with this feature. I have installed the module on this issue, but yet have to install the github version to see if this issue has been addressed:

When updating a parent node, children paths are updated as expected based on the new parent path. Unfortunately, this module doesn't check first to see if any child paths are static (not automatic). Example:

Page 1 (/page-1)
-- Sub Page 1 (/page-1/sub-page-1)
-- Sub Page 2 (/page-1/sub-page-2)
-- Sub Page 3 (/my-custom-path)

If you change Page 1 to New Page:

New Page (/new-page)
-- Sub Page 1 (/new-page/sub-page-1)
-- Sub Page 2 (/new-page/sub-page-2)
-- Sub Page 3 (/new-page/sub-page-3)

I was briefly looking at this in the PathAuto module and noticed they have an algorithm in place that checks to see if the URL should be auto or static, but haven't looked at this too deeply yet. I would imagine that it's a pretty straight forward fix, just check to see if the path of the children match what they would be with the current parent's path and if they don't, exclude them from the update.

Just my two cents, but I really have to get to bed :) I can't wait to see this committed!

jbylsma’s picture

jbylsma commented

I got it working :) The updates are on github. I initially was trying to filter out custom path nodes in the "presave" part of nodeapi, but there wasn't any way to pass values from one batch to another. Instead, during the update process, the child node is checked to see if the beginning of the path matches the original parent's node's path. I've run a couple test cases at it and it seems like everything it working properly.

I also added a conditional in the nodeapi "update" so that it won't run if the node's old alias and it's current one are the same, which prevents the recursive pathauto from running unnecessarily. I did a lot of cleanup too, so hopefully the module is easier to read and documented nicer.

markhalliwell’s picture

markhalliwell
Primary language English
commented

Sweet, I can't wait to take a look at it this week and possibly create a patch for including this the native NH module.

djac’s picture

djac commented

I am currently looking for a recursive pathauto solution and this looks great!

I did discover one issue while testing. When modifying a node's menu position (/admin/build/menu-customize/[menu-name]), the node hierarchy 'parent node' is updated correctly, however, it does not seem to call pathauto to regenerate the node's alias (as well as any of its child's aliases).

Since hook_nodeapi() is not invoked when making changes to the menu structure, is a hook_menu_link_alter() required to handle this case?

jbylsma’s picture

jbylsma commented
StatusFileSize
new 811274_9.patch11.49 KB

Two things:

In response to djac's comments, I figured out the nodehierarchy menu code and implemented the functionality to get it working in the menu overview and the edit menu item. It appears that everything is working properly so far. The updates currently go through the same nodeapi function. I've thrown some pretty oddball situations at it and have had it not work completely right only once or twice (three content types, one with hierarchy tokens, one without hierarchy tokens but still tokens, one completely without, with massive changes to the menu system in one save). Even when that happened, editing the node and clicking "Automatic Alias" reverts it back to good.

The other thing is I've fully integrated the recursive pathauto code into the node hierarchy module. I've done very light editing to the module itself, mainly changing the submits on the hook_menu functions and tacking on a trigger to the pathauto code from the nodeapi's update. I tried to include some helpful comments in there, too!

Beyond reviewing the code, I did run across one curiousity. Whenever the menu system is altered with the menu overview (admin/build/menu-customize/{menu}), the behavior of menu_overview_form_submit marks any altered menu item as "customized." Even though this patch doesn't use menu_overview_form_submit anymore, it is the basis for the new submission code, and I have included the customized part.

I haven't found a definitive answer, but it seems like the customized flag is mainly used for module-provided menu items. It seems like its primarily used to allow users to reset a menu item to its default state, be it from a new location or an edited title. Node Hierarchy, however, primarily uses the customized flag to indicate that the menu title is not currently based off of the node's title. So, this being the case, should a condition be put in place not to mark Node Hierarchy menu item as custom when they are changed within the menu overview? I'm of the opinion that they should, but I could be missing something important!

einkahumor’s picture

einkahumor commented

I haven't tested the permissions part of this patch but the recursive pathauto part works nicely. Thanks a lot.

Pillhuhn’s picture

Pillhuhn commented

The issue with not updating the children URLs was driving me nuts, but after installing this module, it works great (at least the recursive part). Now it would be great if it could be integrated into the Node Hierarchy module.
Thanks for all your help!

jbylsma’s picture

jbylsma commented

Thanks! Glad it is working. I probably should have separated out the modules in the initial post, but I was more concerned about getting them posted and didn't want to pollute the boards. As for getting the recursion module incorporated, dgorton cleaned up my patch in #9 and included it in his review patch at #955148-17: 6.x-2.0 Roadmap . It most likely will be included at some point in the future.