v7.0.1 - Unwanted comcode tags in ULRs

I don't know if the problem is in the "Short URLs" or "URL monikers" feature, but my gallery image URLs contain comcode tags instead of the text which the comcode tags surround.

for example, this URL:

you can see is built up from the bf comcode tag from the following content:

I don't know if this problem is restricted to galleries, but that's the only place I have noticed it so far.

I'm not having this problem with my galleries and I have both "Short URLs" and "URL Monikers" checked. However, I have "Single public zone" checked which it appears you do not.

Even then, I get different URLs depending on whether flow-mode is enabled (URLs with query strings) or not (my file names but shortened if they are over some number of characters).

The software should leave the file name intact if "URL Monikers" and "Short URLs" are checked just removing all query strings and using a simplified path. I have carefully namedmy files and don't need the software making "improvements".

Bob

BobS said

I'm not having this problem with my galleries

That's probably because you don't have any comcode in the start of your image description. That's what it appears to be using to generate the URL.

I don't see how "Single public zone" has any bearing on the URL's apart from consolidation.

BobS said

The software should leave the file name intact if "URL Monikers" and "Short URLs" are checked just removing all query strings and using a simplified path.

That's probably true for "Short URLs", but for "URL monikers" it states:

Whether textual identifiers should be used in content/category URLs, instead of numeric IDs.

implying that it's the most likely cause.

Good call. In sources/urls2.php:
–>


i.e. we're adding that strip_comcode line.

Thanks Chris!

Chris, don't you think that a 24 byte moniker is a bit on the low side?

Also, need to replace \n with "-" otherwise you will get nonsense words in the URL as two words blur/merge into one.

Does this change work for you as expected? (same file)
–>

24 byte seems fine to me, I don't think people want long URLs.

Chris Graham said

24 byte seems fine to me, I don't think people want long URLs.

I don't think most people mind long URLs, they just don't like unintelligible URLs with query strings and meaningless tokens in them.

On my site, I am getting URLs that end with "julian-ritter-painting_6.htm". How is this preferable to "julian_ritter_painting_model_janet_in_1975.htm" which matches the page title, keywords and page content? Which of thee URLs would you prefer to receive in an email, especially if there was a list of URLs?

The above is only true when "flow-mode" is not enabled. When "flow-mode" is enable, the URLs are even less intelligible with query strings like this: "julian_ritter_pics.htm?probe_type=image&probe_id=9"

Bob

BobS said

I don't think most people mind long URLs, they just don't like unintelligible URLs with query strings and meaningless tokens in them.

My thoughts exactly. Also more real words in the URL helps search engine indexing.

I'm thinking a minimum of 50, and preferably say 64. That should give plenty of room for a few words as prefixes.

Yeah, I thought to myself earlier that 60 made sense (which, of course, translates to 64 in the computer world).

And, yes, having keywords as part of the URL will help with SEO.

I hope Chris will see that this is really a necessary change.

Bob

Chris Graham said

Does this change work for you as expected? (same file)

Code

$moniker=strtolower(preg_replace('#[^\w\d\_\-]#','',$moniker));


–>

Code

$moniker=strtolower(preg_replace('#[^\w\d\_\-]#','-',$moniker));


That results in trailing "-". But with a bit or order re-jigging, we get: Note that with the strtolower line now in line 3, we no longer need to replace ' ' in row 2.

Chris, looks like there is a bug in the suggest_new_idmoniker_for function which is resulting in multiple monikers for the same resource _id.

While the function test for uniqueness across all resource types, it does an insert without first checking if it can do an update for the specific resource_id.

This might be a deliberate attempt to maintain historical links, and if it is I don't think it should. Old out-of-date links are better of 404ing.

@ suggested further code changes – yes, agreed thanks, and done a bit more tweaking

@ lengthening. I am not opposed in principle but you have the benefit of looking from a very limited set of criteria. I can almost guarantee that if we change it things will break for people. For example, long URLs may make DB fields overflow, may break in email software that doesn't handle multi-line wordwrapping right, may force people on some Twitter clients to go through a URL shortener, may annoy people on screenreaders in some situations, and so on. If we do allow longer ones, it would have to be an option, but as there is no new release coming soon, it's not going to happen so I suggest considering making/commissioning an addon or working out how to manually change the code.

@ temp1024 latest comment. It absolutely must not 404 if the links change. Imagine someone changing a title and suddenly a load of links being broken. ocPortal tracks this and does proper 301 redirects to the new URLs. It only goes through this function if it knows that the moniker is no longer ideal after an edit, which would be caused by editing the title, or in this case simply by the code changes resulting in better monikers.

Chris Graham said

@ suggested further code changes – yes, agreed thanks, and done a bit more tweaking

Yea, I saw other white space related tweaks that could have been done, but restrained myself from looking too hard at it .

Can you please post the updated version.

@ lengthening. I am not opposed in principle but you have the benefit of looking from a very limited set of criteria. I can almost guarantee that if we change it things will break for people.

I was afraid that that might be the case. I know any time the length of something changes it can be dicey if its not thought out properly.

@ temp1024 latest comment. It absolutely must not 404 if the links change. Imagine someone changing a title and suddenly a load of links being broken. ocPortal tracks this and does proper 301 redirects to the new URLs. It only goes through this function if it knows that the moniker is no longer ideal after an edit, which would be caused by editing the title, or in this case simply by the code changes resulting in better monikers.

OK, so its deliberate and I see your point.

I suppose because I wasn't seeing any notifications about a change in URL, I thought that it could have been an oversight.

Attachment

» Download: urls2.php (20 Kb, 40 downloads so far)

Thanks!

Chris Graham said

@ lengthening. I am not opposed in principle but you have the benefit of looking from a very limited set of criteria. I can almost guarantee that if we change it things will break for people. For example, long URLs may make DB fields overflow, may break in email software that doesn't handle multi-line wordwrapping right, may force people on some Twitter clients to go through a URL shortener, may annoy people on screenreaders in some situations, and so on. If we do allow longer ones, it would have to be an option, but as there is no new release coming soon, it's not going to happen so I suggest considering making/commissioning an addon or working out how to manually change the code.

This is understandable but quite unfortunate. The added keywords in the URLs would be a significant benefit for SEO while to shorter ones might even see a slight penalty for what appears as very similar (possible duplicates) URLs.

Bob