categories don't get aliases
luco - August 20, 2008 - 17:22
| Project: | Edit term |
| Version: | 5.x-1.0 |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
Description
hey there,
I've noticed that although posts, images etc. get aliases automatically, the same doesn't happen for categories. what's worse, if you click the category name anyway expecting to go to category/tid/# you get a nice "page not found" error.
maybe I'm missing something there? I'm running Drupal 5.10 .
this is isevere and I'm in a rush to finish a website for a client, so I apprerciate any help with it.
best regards,
Luciano

#1
I also noticed that I can go to admin/settings/pathauto and under "Category path settings" check the "Bulk generate" box; when I save, category paths do get generated automatically.
but that's not very handy for a client who just wants to enter some content, now is it?
#2
I don't know if running cron has anything to do with it, but I ran it and nothing happened.
#3
@Lucoweb - are you using the "category" module or just plain taxonomy module?
Also, I tried creating a term on a 5.x-2.3 site just now and it created the alias. So, there is some more information missing about what actually causes the problem.
Also, we're all under deadlines from clients. Stating yours doesn't make me interested in giving more attention to this issue ahead of other community things I have to work on...
#4
Greggles, I'm using the taxonomy module.
yes, the version is up to date. and yes, Token module is up to date as well. perhaps my using image 5.x-2.0-alpha2? gonna have to check on that.
I understand you have quite a lot of things on your mind, we all do. sorry about that. matter of fact I am looking for some projects/users in the community I could contribute to, in a paypal sense of the word.
regards,
Luciano
UPDATE: got it! there was a conflict with http://drupal.org/project/edit_term . I'll notify that module's maintainer. anyway, thanks for the promptness. I reckon I coulda looked more into this.
#5
OK.
Should you decide that you like and want to support Pathauto in a payPal sort of way, Freso is accepting donations towards working on a particularly annoying bug: http://drupal.org/node/180440#comment-974176
#6
Not sure how edit_term could be stopping the pathauto bulk actions from happening. It only acts on one term at a time, and should not interfere with any actions that set aliases in other ways.
Have you looked at the alias table (in normal admin)? are the aliases not being created?
Or are they created and it seems that edit_term is somehow blocking access to them? ... which is almost possible to imagine., and would explian how you might you get a problem accessing it even though the link is displayed. Still isn't something that should happen...
What is the URL it's trying to take you to?
#7
dman, bulk editing goes normally. it's creating new categories that goes wrong if edit term is switched on.
here's the step-by-step:
1) you have a bunch of normally-working categories
2) then you install and activate edit_term
3) you create a new content (image, blog post or whatever) and assign to it some categories - some old, some new
4) old categories work as they should (ie they already have aliases: example.com/category/my-category-name)
5) new categories get no aliases
6) links for these new categories (example.com/category/tid/#), even though not even aliased, don't work anyway
that's about it... hope this helps clear the mess. I really like edit_term and I'm trying to help make it better.
regards,
Luciano
#8
I'm experiencing the same issue.
--------------
1) I have a replacement pattern set in pathauto for the term's vocabulary.
2) I create a new term in that vocabulary. Because I have pathauto turned on, I don't put in my own alias.
3) When I hit submit, messages display telling me that the term has been aliased per my replacement pattern in pathauto.
HOWEVER...
4) Going to the alias returns a 404 page.
5) Going to taxonomy/term/termid for that term returns a 404 page.
THE KLUGEY WORKAROUND
6) Running the bulk update in pathauto generates the correct aliases and everything then works as it should.
---------------
I hope this additional information helps track down the problem. The ability to add terms to the menu is just what I need, but this URL alias issue is a dealbreaker -- running pathauto's bulk update every time I create a term is not an acceptable solution.
#9
I'm aware of it, but not sure what's causing it :(
#10
I think that what may be happening is that pathauto comes through and aliases the new term, but then edit_term follows, sees nothing in its URL alias field, and blanks out the alias pathauto had just created.
It seems there's a step missing where the user gets to decide whether to let pathauto handle the aliasing, or to overwrite pathauto's pattern with a custom alias. Is there a reason why edit_term's URL alias interface doesn't use the same mechanism as the interface on node forms?
#11
I think I figured it out.
I don't know how to make a patch, but here's what worked for me.
In the edit_term_taxonomy function at line 375 replace:
<?phpcase 'insert':
?>
with:
<?php
case 'insert':
if (module_exists('path')) {
// Don't try to insert if path is NULL. We may have already set
// the alias ahead of time.
if ($term->path) {
path_set_alias("taxonomy/term/$term->tid", $term->path);
$termpath = $term->path;
}
}
// If the checkbox is set, create/update a menu
if ($term->menu['domenu']) {
if (! $term->menu['title']) {
$term->menu['title'] = $term->name;
}
$term->menu['path'] = $termpath;
menu_edit_item_save($term->menu);
menu_rebuild();
}
break;
?>
The only problem is that when it creates the menu item, it doesn't use the aliased path, which means that the item doesn't show as selected until the the term is updated.
Thoughts?
#12
Yeah, I had a look.
It is to do with the point at which pathauto does its thing.
The thing is - I want and intend for this UI to be able to delete an alias just by blanking it.
Pathauto is making an alias but I'm seeing a blank submission, like you say.
I can disable that behaviour altogether if pathauto is enabled - I guess it's OK that pathauto is forcing the alias to exist, and that starts to help, but..
I also think this UI should be able to expose and correct, override or edit any pathauto-created aliases. It looks like pathauto doesn't like me doing that, as even on editing, the automatic alias is re-created. Sometimes as a duplicate according to the pathauto settings apparently (although it's not working as expected for me either - pathauto pathauto_create_alias() only expects to find one pre-existing alias, more than one confuse it).
I don't mind duplicate aliases, they are perfectly legal to me, but I'd like to be able to choose the primary one myself.
Because the current conflicting behaviour is actually damaging, and I can't see the way to resolve it in the UI, I'm tempted to just remove that box and say "Sorry, pathauto is controlling your aliases - you can't touch them!"
- the URL Alias interface is modelled very closely on the node form version. It's the update process (hook_taxonomy rather than form submission processing) that is a very different process flow under the hood.
- the MENU widget however is a radical rewrite for (what I thought was) a cleaner UI. And have proposed as a rewrite
#13
For my purposes, removing the URL Alias section if pathauto is enabled would work, but I can definitely see the value in being able to customize the alias as needed.
I think that what's missing between the two URL Alias interfaces is the checkbox that lets you choose whether to let pathauto take care of it, or create your own. That's really what I was referring to in my question about why it doesn't act like the node form interface.
#14
Yes, I need to be able to disable path-auto from updating my taxonomy term URL, please make it as option.
For me "Some long term name" with "name" alias is much better than some-long-term-name.
#15
Current release includes a fix for paths going missing (was deleting aliases if a term was saved programatically)
[#589934]
This MAY probably fix this issue.