Custom Breadcrumbs has additional maintainers - planning for cb 2.0

I agree that there is a need for additional maintainers here, and would be happy to serve as co-maintainer.
I have recently become the maintainer of taxonomy_breadcrumbs, and think we should consider merging the functionality of these breadcrumb modules, including support for multiple breadcrumbs, taxonomy, views, panels, etc - most of this already exists in the issue queues and wouldn't be difficult to pull together into a single module that allowed customization for all drupal pages.

I agree with MGN, and I'd like to contribute too .. but I think that MGN is more qualified than me ;)
Merging the two modules can be a good idea, but keeping resulting module light! :)
Regards

We have tried to contact the current maintainer, but had no response. The last commit was months ago, and the issue queue is full of patches and feature requests that have gone unanswered.

Two of us are willing to take over maintainership of this module and continue developing it:thePanz and MGN. If possible we would like to work together to co-maintain it.

We have submitted numerous patches and have been providing support for this project for the last few months.

Here is link to the project homepage.

Any updates about this issue?
Regards

I would like to use Custom Breadcrumbs for my web site, and I will install it if I am sure there are developers working on it to keep it updated.

I hope one of the Drupal webmasters will reply to this report.

Hey there!

First, sorry for the lack of response on a number of the issues cited. Custom Breadcrumbs and Custom Links have both suffered a bit due to the fact that the use cases I've got for them on client sites and my own sites don't run into any of the problems that have been cited.

A couple of the issues (like the use of pathauto functions to clean url/title data) would introduce unnecessary dependencies; a couple of other issues have revolved around a long-term desire to turn Custom Breadcrumbs into a generic site-wide breadcrumb manager (for overriding the breadcrumbs on taxonomy pages, view pages, and more). Rob Loach presented a plan for that almost a year ago but was swamped by other work and unable to implement it. I'd hate to see incremental feature creep (like special tokens that expand into multiple links, like [term-path]) complicate the interface further.

I do carve out time to work on this module every month or two, but I think that more frequent care and attention would definitely benefit it. If someone is interested in becoming a co-maintainer to visit patches and other work between those times, I'm happy to bring them on board; if they have a specific vision for where the module should be going and want to take it there themselves, I'd be willing to turn it over entirely.

thePanz, MGN, what are your feelings on this?

As the maintainer has replied to this report, I would move it to the project issue queue.

Hi Eaton. Thanks for you work on this and so many other things Drupal. In the absence of custom breadcrumb support in core, there is a need for a module/modules like custom breadcrumbs for a wide variety of use cases. While I agree its important to keep custom breadcrumbs lean, I think it can also be developed to serve a broader audience - and there is certainly demand for that in the issue queues. I am currently maintaining taxonomy breadcrumbs and remember reading something of Rob Loach's plan that you refer to. I would like to revist that...Both modules perform their function well, and do not conflict, but I think they could also be made to work better together and to address use cases that fall in the cracks between these two modules. All this to say that it would be great to work with you and thePanz on maintaining and developing these modules.

How about this for a plan.

1. Only perform bug fixes on 5.x and 6.x-1.x - no new features, preserve the existing code base.
2. Establish a new 6.x-2.x-dev branch for new features and try to work in the feature requests that have been in the issue queues for the last few months.

I can't help out so much on the 5.x branch since I am completely over to 6.x now, but I'll still answer as many support requests as I am able.

[Also while we are on to bugs, Eaton if you have a minute could you check out http://drupal.org/node/334324 and see if I am on the right track here?]

MGN, I think the idea of implementing the 'big' stuff in a 2.0 version is definitely a good approach. I've added both you and MGN as maintainers -- and after some consideration I've set the project ownership to you. If it's alright, I'm sticking around as one of the CVS co-maintainers and I'd like to help brainstorm about some of the planned enhncements.

One of the reasons that CB is (relatively) streamlined and consistent right now is because it does one thing: maps node types to explicitly coded paths, like [foo]/[bar]/[baz]. The tricky part about taxonomy trail breadcrumbs is that they can be of variable length. I'm not sure there would be any overlap in the code between the two modules outside of the UI where breadcrumbs are created. "Make a taxonomy-based node breadcrumb" and "make a breadcrumb for a view that's based on its arguments" and "make a breadcrumb for a node based on its token data" require three pretty different UIs and code paths.

Are there any ideas on how this can be smoothed out? I'm scratching my head right now.

Thanks. Brainstorming would be much appreciated! I agree the codebases and UIs are different and what I envision is more of a package solution than single fat module. The problem is that to truly customize all breadcrumbs for a site you need several modules and probably some custom code to fill the gaps between the modules. This leads to still more modules trying to fill the cracks. A better approach would be to develop the breadcrumb modules together, even supplying a small api if it seems appropriate - (like a hook_breadcrumb), that 1) provides a complete solution that can grow with use cases, 2) guarantees the breadcrumb modules will work well together, 3) allows the user to enable only those modules in the package that are needed for a site. This would alleviate the patchwork semi-solution that exists right now, and would be a more coherent solution.

Hi, I'm sorry for my delay: it's my university exams session and I need to pass my last exam ;)

Thank you Eaton for your replyI I think that's the idea of a new branch 6.x-2.x is the right way to include new features. I also think that merging CB e Taxonomy_breadcrumbs may lead to a coding pain for the UI (like you said) and I'd suggest, instead, to follow the API idea: providing a hook_breadcrumbs() and three sub-modules (CB, TaxBreadcrumbs and ViewsBreadcrumb) that uses the new API will lead to a more flexible solution (not only for this module, but also for other modules/custom-code that can "fill the gaps").

Regards!

The idea of implementing a hook to set the breadcrumb is interesting; in that way, it would be also resolved the problem of having different modules which try setting a different breadcrumb for the same page. Making them part of a unique project would allow a central module to control them.

We can continue discussing the future of cb 2.0, but its time to commit those RTBC patches to 6.x-1.x-dev and update the issue title, etc.

Closing this issue now that custom breadcrumbs 2.0 has an official beta release.