separate aliasing for forums and forum containers

Xano - this is an interesting bug.

You mentioned that it's intermittent so until it's more consistently reproducible we'll need to leave it "active (needs more info)".

Sure, provide what you can.

The point is: until there is a repeatable set of steps that can lead us to cause the problem we can't even begin to solve it. So, whatever you can provide that will lead other people to be able to repeat this consistently then that's great.

I have the same problem, and I can always reproduce it. This is what I do:

• Install Drupal 5.1
• Enable the Forum module
• Install and enable Pathauto 5.x-1.x-dev
• Configure the Pathauto pattern for category paths as [vocab]/[catpath]
• Add some forum containers, forums and discussions

When I view the alias table I notice that for each [vocab]/[catpath] pointing to forums/[tid], I also get a [vocab]/[catpath]-0 pointing to taxonomy/term/[tid].

except that's not the same problem (pathauto creates multiple aliases for one node) it's a similar but different problem (pathauto creates multiple aliases for one taxonomy).

TBarregren - can you create a new issue for your problem? I have a feeling it's related to forums. Also, when you create the new issue please test (and report on) whether the problem exists for all taxonomy terms or just for forum taxonomies.

Thanks.

Xano - this is still "needs more info".

I need concrete baby steps for what you did. Sentences like "let Pathauto generate every alias from scratch" doesn't tell me whether you used bulk update for categories or nodes or both. Or whether you just edited all the content. Within those ways are about 6 different possible paths to "let pathauto generate the aliases" and I don't want to play a guessing game.

Please share the exact steps and the list of patterns that you are using.

As you are creating the detailed set of steps, please "reduce" the problem to the smallest number of taxonomy terms (and nodes if necessary) that are necessary to reproduce the problem. That will make it easy for someone to reproduce and solve.

Well, yeah that's pretty clear to me. Now I just have to try to repeat it, but hopefully that won't be a problem.

xano - I work on fixing bugs when I feel like it. That usually comes in spurts about once a month. In between those spurts I spend time trying to understand the bug so that when a spurt comes along I can be productive in finding/fixing the bug (and if you look at my comments you can see that I've spent over an hour reading/writing about this bug - an hour of my free time that I gave to this bug).

If you want to help on this issue there are many things you can do to debug this yourself (if you are unfamiliar with debugging there are many great resources online to learn how to do it). Or you could help by "triaging" the other bugs in the pathauto issue queue. Now that you simplified your case down to a simple test case you are familiar with the process and level of detail that we need to get on other bugs and you could help other people get to this level.

Hi there, I'm having this problem but only (so far) with my category for forums. I'm using Drupal 5.1 and Pathauto 5.x-2.x-dev versions. I have one custom content type called "Column entry". I have my categories setup like so:

• Column (column entry)
  • (TBD)
• Discussion (forum topic)
  • FAQ
  • General
• Section (story, column entry)
• Music
• Movies
• Politics
• Other Distractions

Starting with a clean url_alias table, I configure pathauto thusly:

• General settings:
  • (Defaults)
• Blog path settings:
  • blog page paths: blogs/[user]
  • Create feed aliases
• Node path settings:
  • Default path pattern: [type]/[title]
  • Blog entry paths: blogs/[user]/[yyyy]/[mm]/[dd]/[title]
  • Forum topic paths: forums/[catpath]/[title]
  • Poll paths: polls/[title]
  • Column entry paths: columns/[user]/[yyyy]/[mm]/[dd]/[title]
  • Page paths: [title]
  • Story paths: stories/[user]/[yyyy]/[mm]/[dd]/[title]
• Category path settings:
  • Default path pattern: [vocab]/[catpath]
  • Create feed aliases
• User-tracker path settings:
  • user-tracker page paths: users/[user]/track
• User path settings:
  • user account page paths: users/[user]

What I end up with in my url_alias table is this:

 pid |          src           |                     dst                      
-----+------------------------+----------------------------------------------
 187 | node/2                 | license
 188 | node/1                 | about
 189 | node/3                 | blogs/administrator/2007/03/02/work-progress
 190 | node/5                 | contributors
 191 | node/4                 | forums/faq/whats-going
 192 | forum/2                | discussion/faq
 193 | forum/2/0/feed         | discussion/faq/feed
 194 | taxonomy/term/2        | discussion/faq-0
 195 | taxonomy/term/2/0/feed | discussion/faq-0/feed
 196 | taxonomy/term/3        | section/music
 197 | taxonomy/term/3/0/feed | section/music/feed
 198 | taxonomy/term/4        | section/movies
 199 | taxonomy/term/4/0/feed | section/movies/feed
 200 | taxonomy/term/5        | section/politics
 201 | taxonomy/term/5/0/feed | section/politics/feed
 202 | taxonomy/term/6        | section/other-distractions
 203 | taxonomy/term/6/0/feed | section/other-distractions/feed
 204 | forum/7                | discussion/general
 205 | forum/7/0/feed         | discussion/general/feed
 206 | taxonomy/term/7        | discussion/general-0
 207 | taxonomy/term/7/0/feed | discussion/general-0/feed
 208 | user/1/track           | users/administrator/track
 209 | user/2/track           | users/tristan/track
 210 | user/3/track           | users/suzanne/track
 211 | user/1                 | users/administrator
 212 | user/2                 | users/tristan
 213 | user/3                 | users/suzanne

The difference between forum/n and taxonomy/term/n isn't very easy to distinguish, and I'm also not sure about the forum/n/0/feed links vs. the taxonomy/term/n/0/feed links. Can someone explain this to me?

Hopefully this is just happening with the forum category. I am going to be adding test content to my site soon, and will report if it happens to the other categories.

@aigenta - thanks for the very complete feedback. First, please don't use the 5.x-2 branch unless you want to help in testing. That is an unstable branch where I will almost certainly break things a few times before it becomes stable. Use at your own risk! (though I appreciate testers ;) ...)

I believe that this issue is really a feature request - that pathauto should have special handling for forum listing pages (e.g. forum/tid). Right now it treats forums as just another vocabulary and hence aliases it the same (which leads to duplicates which leads to getting a number on the end).

If someone works on a solution for the 5.1 branch (which wouldn't be hard) then I'd be glad to review and commit it. Otherwise I will try to fix this as part of the work that I am doing in moving pathauto to use token module ( http://drupal.org/node/129482 )

One more thing:

Workaround: - make sure that the taxonomy pattern for your forum vocabulary is blank (and the default is blank) so that the forum taxonomy term does not get aliased. This will prevent them being the same alias which prevents them from getting the index appended.

Here is the solution, in case anyone wants to work on it:

Check to see if forum module is installed. If so, provide a group of settings for that module that allow a set of patterns specific to forums. Make sure that the default pattern will not collide with defaults for other patterns.

Then, it's just a matter of making sure that pattern is used in pathauto_taxonomy.inc when creating aliases.

For an example of code to copy look to the code in pathauto_user.inc for blogs and/or tracker.

Finally, this is a feature, not a bug, so it should be done on the 5.x-2 branch. I'm about to make a big commit on that branch related to using tokens so anyone working on this should wait for that to land to get into the pattern part of it, though the rest can be done now.d

I've written a patch (for 5.x-1.1) that solves this issue. Thanks to greggles for telling me what I should do to work-around this problem permanently! Tested on my site, it is all working perfectly now :) While I was busy, I also made some very minor changes to other code to comply with Drupal's coding standards, and I've refactored a piece of code that generates the [catpath] placeholder, since it's now being used by two functions.
So what exactly has changed in practice? You now get a separate configureation fieldset for "forum paths", i.e. for url aliases for forums and forum containers.

My set-up:
1) make sure the forum taxonomy is set as the vocabulary with the lowest weight for forum topics (if you're using multiple vocabularies for forum topics)
2) make sure pathauto is setup like this:
-forum (the forums and forum containers) paths: [vocab]/[catpath]
-forum topic (the nodes) paths: [vocab]/[catpath]/topic/[nid]
-forum taxonomy (the "forum" vocabulary) paths: forumtaxonomy/[catpath]

Now all topics are properly named like this: forum/other/site-feedback/topic/394. (My "Forum" vocabulary is named forum.)

Note that this patch only solves the problem for forums!

Nobody affected by this wants to test Wim's work?

I'm not affected by it, so it's harder for me to test.

@xano : repeatedly telling us that he is very busy so he cannot contribute any of his time, still wants everybody else to be busy (and fast) to resolve an issue that concerns him - not nice at all . . . .

I assume having tested this on 2 different sites isn't sufficient to mark it as RTBC?

Oh well... then we'll have to wait another month I guess...

folks, folks - no need to point fingers and criticize each other.

@abramo - you too could test and review the patch. I look forward to seeing that review.

@wimLeers - even drupal's core committers get a review from a second person prior to committing something.

this thread seemingly started out as a general pauthauto issue, and then developed into a forum/pathauto issue. I do not run a forum on my sites and/or local test site, so I have no possibility of helping out in this respect.

however I follow the discussion here as this is actually seems to be a general pathauto issue : meaning, ex., in an environment using categories module and cck module (such as mine), duplicate url aliases are created, whereby only a single one is functional (as also stated in the first post of this thread). the patch provided here is relevant only to sites using the forum module - but the issue is not only relevant to an environment that includes a forum.

Ok.

Abramo - can you submit a new issue to track your specific problem (and please provide a set of steps to repeat your problem).

There are several problems here, one of which is the forum problem. I'd like to have this issue focus only on the forum related issue (and have changed the title to reflect that).

@greggles : many thanks for your attention : shall create detailed new issue as requested.

First of all, thank you. I appreciate the effort from greggles and Wim Leers. I applied the patch on my sandbox. I hope this comes out as cohesive.

• The output from changing the config is inserted "above" the page. As it is put there via javascript I imagine this is intentional, but I wanted to point out it had changed. All of my changes had the bulk update box checked.
• I wasn't too sure if I should take the third part of your second step literally, Wim. At first I left out the category path settings for forums. Everything looked fine. Then I put in "forums/[catpath]". It created the _0 aliases. Then I put truncated the url_alias table and put the category settings for forums as "forumtaxonomy/[catpath]". All the aliases are correct, and as I would expect.

So, it is working, and I am about to put it on a live site. My question, which is curiosity, is this: Is the category setting for forum paths needed with this patch? I am of the notion of not configuring what I don't have to. No need to explain it if it is too much effort, it is not nagging me or anything, I am just trying to understand this module more (which is one of my favorites).

I am not sure if my testing qualifies as a second, but nothing is burning. ^_^

Again, thanks for the effort.

Basically you're asking what the difference is between "forum" and "forum taxonomy" (quoted from my folluw-up #19)?

• "forum taxonomy" -> this is the "real" taxonomy
• "forum" -> this is the additional layer added by forum.module, which allows it to display forums, instead of the default taxonomy term view

I hope this makes sense... if you don't understand it, just browse to one of the "forum taxonomy" pages. What you can see there is what would have been displayed if the forum module didn't add their "additional layer".

And... you've pointed to a valid point there. Thanks to this patch, you no longer have to set the "forum taxonomy" (as in my example), or "the category setting for forum paths" as you describe it! Why didn't I think of that? :|

P.S.: that "output above the page" are simple Drupal messages, they're not some hack or anything like that ;)

Marked as RTBC now. I think your testing qualifies as a second :) Thanks for testing!

We need another review before this can be marked as RTBC.

Wim, I loaded up the patch and everything works fine, except the information above the screen. Your last post said that was not a hack, I'm not clear on what you're saying since pauthauto didn't do that before.

Hope this helps.

I really wish you could edit your own posts. I just added a new forum and the path was not created for the forum until I went into pathauto and did a bulk update on forum path settings.

Nice find, Terry! I reproduced this bug. I'll try to come up with an updated patch.

I thought I had it fixed, but then it turned out to be not doing anything at all... Because of forum.module's custom administration pages. I'll have to find some work-around, but that'll be for tomorrow.

terrybritton, the issue you found is now fixed. While working on that fix, I saw that the [catpath] placeholder wasn't working properly. I've found a work-around and have included it in this same patch, because it's just one line of code. Since that was a critical bug, this issue is now marked as such.

A quick question on patching, do I patch the original module with this new one? Want would be the best way to make sure I am testing the changes?

@WimLeers - thanks for your continued efforts on this.

@maiki - yes, patch the version in the "Version: " dropdown on the issue (in this case 5.x-1.1).

Yay! This totally solved my _0 problem as I described earlier in the thread. Thank you very much!

@aigeanta: could you please confirm that the newest patch does not have the problem described in follow-up #31 & #32?

Wim, after adding the latest patch I still have the same problem. When adding a container and forum the forum taxonomy path is generated, but the forum path is not created until I do a bulk update.

Wim, I'm still having the same problem. When I add a container and forum the taxonomy forum path is created, but the forum path is not created until I do a bulk update.

I also still have my question about why I get all the info above the page when doing a bulk update, which did not happen before applying the patch.

Strange. It works perfectly for me now.

1) "all that info when you do a bulk update" should have been there before too, that part of the patch has not been touched at all.
2) If it's still not working for you, I have no clue, since it works fine for me now. Somebody else will have to either confirm that you're right or wrong.

I didn't add any new containers, just a new forum, and it seemed to create the path fine.

greggles, did you ever get to testing this?

Hey Wim, sorry about the delay in getting back to you, I was off on a fly-in fishing trip in Canada. I'm not sure what I was doing before, so I reloaded pathauto, installed your patch and everything works fine. Hope this is enough to get it incorporated. Now if I can just get og_forum to work with pathauto.

Thanks Terry!

@wim - your patch doesn't apply. 2 hunks fail. How can that be RTBC?

I've rerolled it so that it should apply.

Also, "works for me" is not a review. A review is a review. Please, people, review the code under a variety of situations.

Sorry about the not-so-applying patch. I simply haven't checked it again.

Two reviews of "it's working" is better than nothing and at least proves the code is working. And it's not working at all right now, so I don't see why this patch should not be committed (except for the not applying part of course).
Granted, reviews are good, they guarantee code quality. But if *they* say it works and you take a look at the code and it looks good and it's clear (or properly commented) what it does, then why keep postponing a commit? It's not like it touches hundreds of lines.

I can understand your point of view and respect it. But I've had it with this patch. I hope you understand me.

Thanks for the reroll btw.

Ok, I committed it. I don't use 5.x-1 any more, so if it causes problems it's problems for someone else ;)

Thanks for all your help, I do appreciate it.

I also suggest that if people haven't then they do read the "how to review a patch". Testing and reviewing a patch is not just installing it and getting 1 test case to work. If I only tested one test case we'd have an even buggier module. Which is certainly a scary thing.

Sorry for the review-that-wasn't, I will do better next time. I was just very excited that it worked and fixed a nasty problem and wanted it to be committed rather than me continuing to hand edit paths or keep it patched up myself. I would rather it got committed and introduced some subtle bugs that would have to be addressed in new issues than keeping it around as a patch forever because fewer people are likely to test it, just the ones following that particular bug. But everyone has different development styles, and it's not my project, so I should just be quiet :-)

This issue has popped up again in the latest 5.x-2.x-dev version, so I am setting it to active again. The patch fix was only provided for the 5.x-1.1 version and never propagated into the new tokens branch. I am willing to test any new patches with my drupal 5 dev mysql install and provide my configuration info. This bug shall be vanquished!

That's the proper status. We no longer need a solution to the catpath problem (it wasn't a perfect solution anyway).

And for the record, I don't plan to work on this now.

I'm getting this issue with the new version also.

There is a bigger problem now. When I EDIT a forum that doesn't have a alias on the forum admin screen and then save it, the -0 path is created. I then cannot edit the forum again as it just returns me back to the original screen!!

The path before aliasing: /admin/content/forum/edit/forum/119
The path after aliasing: /admin/content/forum/edit/category/forums/projects/msnet-0

The path after aliasing doesn't work so I cannot edit my forums unless I delete all aliases, edit my forums and then re-create the aliases (not feasible in reality!).

Well, that was a hell of a lot easier to fix than I thought... The attached patch appears to fix the issue by preventing Pathauto from creating a taxonomy term alias if an alias for the forum was created.

The above patch won't work with Bulk Updates. If you delete all your aliases and then bulk update the category path aliases, forum aliases WON'T be created.

I find that I have to delete all category aliases, go into the forum administration and edit then submit each of my forums (this creates the forum aliases) and then I can go and bulk update my category path aliases with Pathauto.

@denney - your patch is quite different from what we implemented in 5.x-1. As long as we do this for compatibility we should do it similarly, right?

I've rebuilt the patch that Wim and I created in #47 for the 5.x-2.x branch.

Please test and let me know if it achieves what you need.

Your right. We should keep them in the same vein. My patch was more of a "quick fix" I guess.

Your updated patch appears to work fine. I was able to delete all my current aliases and re-create them.

Great - thanks for testing, Denney. I do appreciate you making that patch. In general, it would be helpful if you said "this isn't a perfect solution it's just a quick fix" or something like that so people know what they are dealing with.

Anyone else care to test? Or do I just apply and pray ;)

To be clear:

1) This patch prevents creating an alias for taxonomy/term/TID if that TID is the forum navigation vocab.
2) It creates a separate section of settings in admin/settings/pathauto which has options and guidance specifically for the Forum module which creates aliases for the forum/tid path
3) It supports both regular creation and bulk generation

If you don't review the code please at least review those ideas.

This has now been applied.

Hi there, sorry I'm late to the party. Here's my review of this fix, which is an answer to a bug I was experiencing in previous versions of pathauto so I have a little knowledge of the situation.

1) This patch prevents creating an alias for taxonomy/term/TID if that TID is the forum navigation vocab.

Yes, it does that. It also prevents creating an alias for taxonomy/term/TID/0/feed, which is the proper feed to alias to, so the RSS link at the bottom of each forum does not have a nice pretty pathauto-generated url alias. The url alias being generated, to forum/TID/0/feed, just gets you to the forum page on forum/TID and so it doesn't really do the right thing; it's not RSS output that feed readers could subscribe to, and is basically worthless.

2) It creates a separate section of settings in admin/settings/pathauto which has options and guidance specifically for the Forum module which creates aliases for the forum/tid path

The separate section was nice to have, and it made sense in its placement on the settings form. Thanks for the UI improvement.

3) It supports both regular creation and bulk generation

...And I only tested the bulk generation, which worked great.

So my overall review of this patch is that it works as advertised with the exception of the path for the forum feed, which needs to be rethought and fixed up.

@aigeanta - thanks for your detailed review and for finding that issue. It was also in the original patch for 5.x-1.x I believe.

I've created a new issue for the problem you found here: http://drupal.org/node/188762 Let's move the discussion there.