Feed aliases fail when max length of URL is the same as the size of the dest column

Updating version and priority - with no other reports or followups it's clear that this is not critical.

So, we now have an issue for extending the length of URL aliases in core. That is fine and hopefully I will find time to fix it in the next few months (it can't happen now because it's a feature and what not).

But, we still have your problem here which can be generally stated as:

If the max lenth of an alias is the same as the max length of the underlying DB, make sure aliases that add more to the end will still work. But, what is the best way to do that?

1. Should we limit the max length to 10 characters less than the length of the db column?
2. Should we chop off some of the node URL in order to fit on the /feed?
3. Some other solution?

I prefer item 1, but I welcome comments on other ideas.

This is somewhat fixed in HEAD by using 100 as the default max alias.

I'd like to provide more information about this decision in the user interface so here is some proposed text:

Maximum text length of aliases to generate. 128 is the maximum permissible. Using a length of 128 will not work with feed aliases, so a lower value such as 123 should be the highest value used if feed aliases are enabled.

"Should we limit the max length to 10 characters less than the length of the db column?"

I'd vote for this, as I tend to increase the default length of the db column, which is too small for my needs.

@FiReaNG3L - that would be nice, but a fair amount of work. I'm not going to do it, but I'd commit a patch.

@dkruglyak - it's user configurable within bounds. It can't be any bigger than the database column (128) so we set that as the max. If we allowed users to specify a max of 130 when their database only supported 128 characters then it would lead to misleading and confusing results. So, we hardcode the value.

If either of you have the means and motivation to provide code to create the max based upon the db column then that would be great.

Thanks.

And doesn't anyone want to comment about the proposed language in comment #2?

"so a lower value such as 123" - can I put 125? or 121? I don't like the 'such as', we should put a hard number on that (10?). Also, I would add 'is the maximum permissible with the default database schema - if you need longer aliases, modify the 'tablename' length to the value you need - and then describe that you need to leave some space for feed aliases.

Aside from that, the text is good.

@FiReaNG3L - thanks for the feedback. The reason I left it ambiguous is that /feed may not be the only additional item. For example, if someone uses xtracker and user aliases then they would need to limit aliases to 9 less than the db length. To be safe, we'd have to say "30" or something, but that is limiting. I guess I could provide a link to a handbook page on the subject.

So, here's my new attempt:

"Maximum text length of aliases to generate. The value is stored in the url_alias database table in the dst column In the default database schema this column is 128. Using a length equal to the length of the url_alias.dst column will cause problems with aliases that are added to the end of the URL such as feed aliases. You should enter a value that is the length of the url_alias.dst column minus the length of any strings that might get added to the end of the URL. The length of strings that might get added to the end of your URLs depends on which modules you have enabled and on your Pathauto settings. The recommended and default value is 100."

It's a mouthful, but it provides a mental model of the process so that users understand why and where the limitation exists.

Thoughts?

I hope this is still on the radar as I've just noticed this same issue too.

Greggles:

The proposed text seems far too wordy/verbose/technical IMO, not making for a usable experience.

Although just saying, 'Max word limit = 100' is limiting in itself; it's much easier to understand on a quick-read (I had to re-read the current text twice), and would probably satisfy most users. Maybe just leave the link to a handbook entry with the remark:

"If 100 characters is insufficient, please consult the handbook entry - Advanced users".

Having said that, I've attempted to clean-up the proposed text thus:

"Maximum text length of aliases to generate. This value is set within the dst column of the url_alias database table. The default database schema for this column is 128. If you set a length that is equal to that of the one set in the dst column, it will cause problems in situations where the system needs to append additional words to the aliased URL, in order for that function to work. For example... URL's generated for feeds will have "/feed" added to the end. You should enter a value that is the length of the dst column minus the length of any strings that might get added to the end of the URL. The length of strings that might get added to the end of your URLs depends on which modules you have enabled and on your Pathauto settings. The recommended and default value is 100."

... but like I say, still too much IMHO.

I hadn't dropped this, just waiting for more input/ideas and yours is a good one.

I put the help text inside of the site rather than a handbook page because that seems better to me.

I used more or less your text with a slight modification (e.g. instead of For example...).

I'm leaving this RTBC for a couple days but will then commit this.

dangit - my links go to the wrong spot. The should go to admin/help/pathauto then it will make more sense.

Ok, new patch.

Thanks Greggles

I've made a few more (small) additional alterations to (hopefully) minimise "geek-speak"' EG... "strings" to "characters".

"Maximum text length of aliases to generate. This value is stored within the 'dst' column inside of the 'url_alias' database table. The default setting inside this column is 128. If you set a length here that is equal to that of the one set in the dst column, it will cause problems in situations where the system needs to append additional words to your aliased URL, in order for that function to work; EG... URL's generated for RSS feeds will have "/feed" added to the end. When setting this value (here), you should take account of the length set in the dst column and then subtract the number of characters that might be added to the end of the URL. The number of characters added to any URL depends upon which modules you have enabled. The recommended value is 100 (default)."

The more I think about this, the more I think it should be hidden from the user and accomodated programmatically.

The reasoning behind this is that a path should never change because a user installs (or uninstalls) a module. For example: Where a user enables a feature (or module) at some future date that requires a higher string-length. This would mean that any future bulk-index operation would change the entire site navigation (with all that entails).

Additionally, we shouldn't assume a user will remember to set a new path-length (particularly when the user isn't expected to know what impact (if any) a new feature will have on any paths.).

Allied to the last paragraph is the additional burden placed on the user in determining how many strings (if any) is actually appended by any module (some of which - possibly/theoretically - might be conditional upon a certain action).

I realise that by highlighting all the above (and all that flows from it) it now makes the current proposed fix to be really just that - a fix - and not a permanent solution. I can also see how potentially far-reaching any "real" solution may reverberate if a programatic solution involves some form of system-wide declaration by modules needing extra URL space.

I leave it as food-for-thought but I strongly believe it's something that, once implemented (in whatever form), existing, and future aliases are protected against any changes influenced by any modules needing URL expansion (or contraction should the module be removed)... this is critical functionality.

(Phew!)

Whippingpost - I agree with your sentiments but it will be practically non-trivial to do what you are talking about. In the absence of a perfect solution I'm happy to take the imperfect one.

I don't think a solution like you describe would be reasonable until Pathauto is a part of Drupal core which is still quite a ways off in the future...

So, if you want to pursue that functionality I suggest the following path:
1. Create a new issue in pathauto for "provide a hook to ask other modules about the length of strings they will add onto the end of urls"
2. Create companion issues in modules that actually do that

Your improvements look good. I'm going to change the use of "here" to say the name of the settings box since this text will go on the help page which removes the context for "here".

Thanks very much for your thoughts on this issue and on the larger issue of making sure paths are stable.

@TheWhippingPost - also, what do you think about this as a solution to the problem of replacing/breaking old aliases: http://drupal.org/node/100835

I think that solves it in a way that could actually get implemented.

it will be practically non-trivial to do what you are talking about.

...

I don't think a solution like you describe would be reasonable until Pathauto is a part of Drupal core which is still quite a ways off in the future...

I agree, and thought as much as I was writing.

I'm going to change the use of "here" to say the name of the settings box since this text will go on the help page which removes the context for "here".

Ah right! I didn't realise it was going to appear in the help page, cool - good call.

Thanks very much for your thoughts on this issue and on the larger issue of making sure paths are stable.

Greggles, all of my Drupal troubles have been path one's - Setting Drupal up, learning and applying the theme engine and generally programatically shaping the beast to my whims has been a pleasure... but path troubles has nearly driven me to the bottle!

I won't rattle on but I really do believe they should be addressed once and for all - as a priority - given they are such a funndamental engine to Drupal's (indeed, any website's) operation.

I've been left quite shocked, I have to say, that at 4.7, there are so many issues surrounding URL-generation. I haven't tried v5 yet, largely because all I've really read about are the new whizz-bang UI-features - If I thought that some of the "real" issues had been addressed, I'd be onto in a shot... OTOH, if I do try it and find that I have to perform the same magnitude of hacking I ended up doing on 4.7, then I think I'd ditch the platform completely and diss it at every opportunity..

... so it's prolly best I wait a while ;)

If it wasn't for Pathauto though, I would have already ditched it months ago. It was the deal-breaker for me, and one only has to read the numerous blogs out there to see that the Pathauto name is up there often enough as a headline feature.

So I'm very much on your side here and the day this functionality makes core can't come soon enough. It's frustrating that, in essence, Pathauto is being held back and having to tip-toe around certain other deficiencies, when it probably could be introducing a whole raft of cool possibilities.

When things settle down, I'd like to try and help more below-the-bonnet but in the meantime, I'll contribute as I can.

(I think I rattled on a bit didn't I! ;) )

Well, these ideas are now committed to 5.x. I'm leaving a "sync" for head for a later date.

@TheWhippingpost - I can relate that I've also been frustrated with path problems in Drupal. I hope you'll keep providing your insight into these issues so that we can make paths work better.

I was just about to apply this patch but suddenly realised that by doing so, I was effectively going to change my site's URL's (I know, what did I say above!).

So I think it would be prudent to issue a caution somewhere for the attention of existing Drupal users warning of the impact the changes will entail.

Sorry, I didn't see your above post.

For the record, I was referring to v 4.7

... and you can rest-assured, now I'm wedded to Drupal for my main site, I will continue my quest for path righteousness(sp?)

Oh yeah - I'm definitely keeping these "changes function or basic ideas of pathauto" types of changes to 5.x only and basically only doing bugfixes in 4.7 at this point.