Create hierarchy in book pages
nikle - December 8, 2006 - 00:11
| Project: | freelinking |
| Version: | 6.x-3.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | fixed |
Jump to:
Description
Request:
1) If a freelink is created in a book page, creating a new link would create it as a child page.
2) Ability to specify a different path would also be very useful. For example if you were on the book page "Topic1" you could then create or link to different pages eg: "[[Topic2/Childpage]]"
Outcome:
This small contribution would allow the book module to be used as a real wiki with namespaces.
Future:
Integrating this into TinyMCE would make my head explode.

#1
I need the same thing more or less. I see it as taking advantage of the book.module's ability to put any node in the hierarchy. Ideally this would be configurable for the module, and on a per-node basis, e.g. a checkbox for "place in book hierarchy for referring node _______"
I'll work on a patch. Any input from the module maintainer?
#2
> Any input from the module maintainer?
nope. :)
Other than to say +1, I'd like to see a patch for this; I won't be doing any coding until after the first of the year.
#3
I have a patch brewing that will do this if book nodes are used as the freelinking target. If book.module gets smart enough in 5.0 to pick up parent data on any old node, this could be even more flexible. Need to test a bit and will submit a patch soon.
#4
Here's a patch. It also includes the change to HEAD to use node_access and some normalization of single-quotes (I'm a stickler for style :P).
Basically, this only fires if book pages are the freelinking target type. If so, when a freelink turns into node/add, it reconstructs the referring node and sets the parent bit. It will also put the referring node in book hierarchy if it's not there already to prevent a chain of orphan pages.
Let me know what you think. I think this is a powerful new feature and would love to deploy it with confidence!
#5
Although, I haven't even begun to address the namespacing issue... ideally this would want to play nicely with pathauto...
#6
Hi Josh, I am delighted with your interest in developing this project. For the life of me I can't find the link to download the patch, also are you using 4.7 or 5.0?
Am I correct in my understanding that this patch will address item 1 above
Another thought to make the patch more powerful:
If the target is not a book page but is in a book outline (hierarchy) it can still have children pages.
1a) Would looking to see if the target exists in a book outline be difficult?
1b) What if a the item appears more than once in an outline?
1c) Can we look at the breadcrumb for the target's specific path in the outline and use that?
#7
Whoops. Looks like the patch didn't attach before. Doh!
I'm currently mucking about in 4.7, but this will be easy to port to 5.0. I have a better version that uses book's own node/add/book/parent/ to set the parent rather than hacking an additional arg into $_GET and using formapi to set the parent.
The problem with placing targets that are not books in the outline is that unless the node is a book page, there's no way to get it into the outline until after it's been created. This is actually a flaw in book.module IMHO: it should allow you to choose what node types are eligible to be outlined (similar to how upload.module defines what node types can have attachments), and handle everything through nodeAPI.
#8
Also, the way I'm working this is that if you have book set as the default target type, the node with the [[freelink]] on it which generates the new book page will get stuck into hierarchy so that the target is a child in any case. This will prevent a lot of orphaned book pages if using these two together.
I'll reroll my 4.7 patch shortly.
#9
Hey Josh, I didn't quite get what you were getting at in comment #8 but am nonetheless very excited to test a patch for you.
Does drupal 5 overcome the book outline creation issues you mentioned in #7, I think it would be a killer feature.
Let me know if there is anything I can do in the meantime to help, I'm happy to work on workflows with you, unfortunately my programming is extremely rusty at this point.
Cheers,
N
#10
Any progress on the patch ?
Like Nikle I'm very interested in this and willing to test any patch (preferably a 5.x version).
#11
Any progress here? This would be very useful for a new site I am working on. I have a D5 install to test on if needed, tx
#12
Umm, no patch, and a lot of time gone by. Upped the version to the latest, and am setting this back to active. I'm still interested in this functionality.
#13
Just a wild idea: perhaps this functionality can be implemented via a contrib module implementing the custom_url_rewrite_outbound function. However, since this function can only be used once it might be better to use the new PURL API module.
Delegating all these different use cases to contrib might be better to keep the freelinking module lean and mean, and therefore easier to maintain.
#14
#15
Working on functionality that will allow you to designate that missing pages be added as children of the current node. This only works on a full node view.
Followup functionality to specify a Book or Menu hierarchy, or an Organic Group is on the drawing board.
#16
Step one: You can now activate "Book Integration" which should make create node links appearing on a given page preset the node form to be a child page. Similar functionality is in place for Organic Groups, and Taxonomy.
Specifying a book path by stepping through the book page hierarchy is not planned anytime soon, though I am looking at ways to use the URL Alias in a FL3 plugin to perform something similar.
Marking this Fixed, as the primary request has been resolved, and the second request folded in a different direction. Please reopen if book pathing is specifically desired.
TinyMCE integration won't happen, but #633842: Wysiwyg API Integration is on the table.