This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit ezplatform.com

eZ Community » Forums » General » Corrupted url_alias strings, all...
expandshrink

Corrupted url_alias strings, all links on site are broken

Corrupted url_alias strings, all links on site are broken

Thursday 22 February 2007 3:45:04 pm - 6 replies

Site is running eZ 3.7.3 on windows...

I need some help troubleshooting a url_alias problem. It started yesterday when links in the admin interface were coming up "Kernel 20" - not found. The problem was a bad link. Instead of the link looking like this (generic example):

/main_page/sub_page/sub_item

It looks like this:

/users/guest_accounts/some_guest_user/main_page/sub_page/sub_item

After a while this morning now I see some links that have two different strings prepended:

/main_page/other_section/other_page/other_subpage/users/guest_accounts/some_guest_user/main_page/sub_page/sub_item

Strangely, links in media and users tabs all work fine.

It is prepending some other url alias to the beginning of the url in both the content structure menu and the sub items list in the admin interface. Upon publishing content, the urls also get broken on the live site. Luckily, this site uses static caching so I have a working copy of the cache from the previous day.

I worked on the problem yesterday by running updateniceurls.php, which updated all URLs and removed the offending strings, but instead started each URL with a // when rendered in the admin interface, but only in the treemenu (not in subitems).

Where do I look to find out what might be corrupting the url_alias generation?

Thursday 22 February 2007 4:25:34 pm

Hi Mark

is it really the url_alias that is wrong or does the ezurl() operator create a wrong url out of a correct url_alias?

Claudia

Thursday 22 February 2007 4:46:47 pm

The incorrect aliases are in the ezurlalias table in the db. There seem to be some that are correct and some that have the prepended errors.

There are nearly 20,000 url aliases, so it is hard to review them all.

Yesterday, I emptied the url_alias table in the db and ran updateniceulrs.php to repopulate it. That seemed to fix the problem, but as new users register for accounts, or new pages are published the urls become corrupted again.

For instance, the urls now all have a users name in the url in the contentstructuremenu for the content tree, but in the sub-items view of that content, the URLs are all ok except for pages that have been republished today.

Friday 23 February 2007 6:37:27 pm

Hi there,

I got this problem one day, and it was hard to solve it.

The problem occured when a new user registered, and then every url was redirected to a module with the name of the user object name.

What I did to solve the problem was to find in ezurlalias the record where source_url was * and delete it.

I am not sure if this will solve your troubles, but it did for me.

I assume something is going wrong when a new object is published. It seems that at one time source_url is set to * and if for any reason publication process is stopped all url (*) will be redirected to this object ...

Hope it helps,

N

Friday 23 February 2007 9:40:02 pm

Hi Mark

I haven't seen any likely reason for this problem, so if Nicolas' suggestion does not help I think you have to do some serious debugging. First I would add some debug messages in the class kernel/classes/ezurlalias.php, especially at create, store and updateChildAliases. Then publish one node with a very distinctive name and see what is exactly happening.

In the ezcontentobjecttreenode.php is also a function updateURLAlias which might be worth checking as well.

Good luck

Claudia

Friday 23 February 2007 10:18:37 pm

I *seem* to have fixed this one...

Data corruption was in the ezcontentobject_tree table - the path_identification_string field to be precise. It's not clear how this happened, but I suspect it could be to do with a script timeout while trying to move large numbers of nodes to new locations in the content structure tree. For some reason incorrect data was being appended to the contents of that particular field.

Running a few manual queries on the database resolved the problem.

Friday 23 February 2007 10:29:56 pm

BTW - David and I work together, which is how he was able to solve my problem.

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from