Move Custom Breadcrumbs Settings to Tab on Content Types

What does everyone think about this?

Since one of the goals of the 6.x.2.x is to handle breadcrumbs for non-node pages, I think keeping a single breadcrumb administration page is important. But I think we could also provide a breadcrumb tab for each content-type (or on each node for that matter...but that would be a different feature request) so you could set it up while you are creating the content type...

Opinions? Anyone want to write a patch to do this?

Thanks for the idea.

This is quite an interesting sugestion. would it show in a central place and also in the content type page?

I think it's important to keep a centralized adminstration.

A difficulty with this idea is that the mapping is not one to one. You can have several breadcrumbs for a given type of node and use php_visibility to determine which is displayed. So it wouldn't be as simple as showing the edit fields. You would also need to have a way to select which breadcrumbs is displayed/edited. This is still possible, but will take a little more work than I first imagined.

I also agree with Jolidog that the current centralized administration, bringing together all the custom breadcrumbs in a single administration page, is very important. Still, this could supplement that and make the interface a little more intuitive.

A similar approach would be to add a custom breadcrumb tab on a per-page basis. Each page would inherit the node-type breadcrumb (if defined), but could be changed (into a cb_paths breadcrumb)....

Yep. There are times when you work by feature, and other times when you work content by content. I think the best appraoch might be a hybrid of two. A centralized administration page for the former, and then a custom breadcrumbs fieldset when editing content that list the current breadcrumb for the content (or a table of breadcrumbs if more than one apply, for example when using php_visibility). I've implemented this in today's 6.x-2.x-dev commit and it should be available for testing in the next nightly snapshot. While you can't edit the breadcrumb on the content, you can see what it is and follow a link to edit it. If there are no custom_breadcrumbs for the node, then a message provides a link to the custom breadcrumbs administration page. Hopefully this will better tie together these two modes of site management and development.

The hybrid is a good method, thx! This should be made similar for the view display type "site" (implement custom breadcrumb in the site specific settings on the view edit page).

this is a great idea. if I can set the menu link right on the node add page, why can't I set the breadcrumb too? Specially when drupal lacks of a decent breadcrumb system.

For hybrid I understand an admin page for all the breadcrumbs (like the menu system has) and also a fieldset on the node add page to create the breadcrumb..

Hi lelizondob, this is already implemented for nodes and taxonomy terms in 6.x-2.x-dev. Have you had a chance to test that? If so, is this sufficient, or does it need improvement? I appreciate all the advice I can get. Thanks!

I tested the new changes in 2.x-dev and is not exactly what I was talking about in my last comment. I see if the node has a custom breadcrumb defined in a table, but my feature request is about having a field to set the breadcrumb right on the node/add page, just like the menu system does.

The way I see this is very simple, when you add a node, you can set the url alias or the menu link without having to go to the admin area. the user should be able to add the breadcrumb too. The functionality is already implemented (I think) since the module custom_breadcrumb_path lets you set a breadcrumb for a defined path. my guess is this wouldn't be too hard to implement and it would be a huge improvement to fix the lack of a decent breadcrumb system in drupal.

Here's a patch to show you what I mean.

There's a lot of comments in the patch to let you know what I've done since there's probably a better way to do it.

The patch is partially working, the biggest problem with it is that I'm using 'node/nid' to create a path on the node form and save it to the custom_breadcrumbs_paths table and since the nid is created after submitting the form I couldn't make it work so I just wrapped inside an if so new nodes can't have a breadcrumb, only nodes that already have an nid.

I'm sure you'll come up with a better way to do this. I'll change this issue to needs review but obviously you'll have to change it to needs work after you read the patch.

Thanks

Though the feature of #11 is really nice in some circumstances it should be optional (admin option or separate (sub)module). Otherwise it has the same problem like the menu form: In many cases it isn't needed so the node edit form has to be overridden by e.g. Panels to remove the menu form.

I agree, we could do a hook_form_alter in node_type_form to make it optional by content type just like the comments.

Still, (don't know if you read the patch) there's the huge issue about not having the nid available when adding a node. Maybe the way to go should be a sub module that saves the nid in another table instead of using $bid or 'specific_path' like I'm doing in the patch to set the breadcrumb.

The $nid should be available by editing a node since the url is always node/nid/edit. Use arg(1); to retrieve it.

Yes, the $nid is available when editing a node, but not when adding a new node, since it hasn't been created yet.. That's why in the patch is only possible to set the breadcrumb when the node already exists.

@lelizondob thanks for contributing! I understand what you are looking for, but there are some major difficulties with this, primarily because this set of modules is so flexible.

The biggest difficulty with being able to define the custom breadcrumb on the node edit page, is that in principle a single node could have several breadcrumbs defined for it (See my comments in #3 above). Which one is viewed might depend on the breadcrumb visibility field, or the language (on a multilingual site), or the specific path that is taken to view the node. Assembling a form that reflects this kind of flexibility is a real challenge.

That's why the current module just lists all the custom breadcrumbs that are associated with the node (ideally - I think more needs to be done here), and links back to the appropriate breadcrumb edit page to edit these. If no breadcrumb is defined, the link takes you back to the add breadcrumb page for the specific node type. I guess additional links could be added by each submodule that could possibly provide a custom breadcrumb. But until you know which type of custom breadcrumb, you can't develop the form.

Now this could be accomplished (ultimately) with an "ajaxified" multistep form, and that would be really exciting, but the current patch doesn't appear to be going in that direction. If someone wants to work on that, I would be very interested in helping. Its easy to see how you could wind up developing something on the order of "variants" in the panels UI or "displays" in the views UI. The form should start out very simple and basic, but ultimately allow for that level of sophistication.

One specific problem that I see with the patch in #11 is that it places a dependency on custom_breadcrumbs_paths.

custom_breadcrumbs_paths is an optional module, so this will not work. Best practice would have the solution be self contained for each submodule. Or rather, the basic framework would be supplied in custom_breadcrumbs, but extensible so that each submodule can build on this framework.

Thanks again for stoking up the discussion, and the interest. I think a solid UI (worthy of core) is an important direction to take the module, and look forward to further discussion.

I would suggest fully discussing what the UI should allow the user to do, and what kind of form is necessary to do it. Let's get some agreement on the big idea before we get into the nuts and bolts.

@#15: Ah, I was short on time and only read parts of the patch and descriptions. Though this patch likely won't be used anymore, hook_nodeapi and using action 'presave' makes nid or $node->path available.

@#16:
User POV: The UI should allow the user to edit all assigned breadcrumbs of a certain node while editing/(creating) that node.
Admin POV: Admin should be able to assign the cb form to certain node types like CCK fields. Further customization/depencies of the form appearance can be done with Panel.

If someone wants to work on a multistep form have a look at ctools if you haven't already. It decreases development time for creating such forms and other UI elements.

@MGN I agree this patch needs a lot of work, it just was a simple way to demonstrate what I was talking about.

in principle a single node could have several breadcrumbs defined for it

I didn't know about this, is definitely a good idea because it makes the breadcrumb really flexible. I used custom_breadcrumbs before and just a couple of days ago I started to use the 2.x version so I didn't know about all the new functionality

One specific problem that I see with the patch in #11 is that it places a dependency on custom_breadcrumbs_paths.

I know about this, I even had to patch the module to make it work using the nid and not the alias, is not the best way to go.

the way I see it now, there's 2 ways to handle this

1. Work in the idea you said about an "ajaxified" multistep form
2. Create a new submodule that would take the nid and probably have only one breadcrumb by node and use module weights to set multiple breadcrumbs depending on the visibility if we want to.

Finally in my opinion a 'solid UI (worthy of core)' has to be really simple, even if some functionality has to be sacrificed.

I'm very interested in this since I consider the breadcrumb a very important part of every site and as I said before drupal lacks of a decent breadcrumb system.

Subscribing.