Corrupted url_alias strings, all links on site are broken

Next topic

Author	Message
Mark Marsiglio	Thursday 22 February 2007 6:45:04 am 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? http://www.thinkcreative.com Turning Ideas Into Strategic Solutions
Claudia Kosny	Thursday 22 February 2007 7:25:34 am 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
Mark Marsiglio	Thursday 22 February 2007 7:46:47 am 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. http://www.thinkcreative.com Turning Ideas Into Strategic Solutions
Nicolas Ottavi	Friday 23 February 2007 9:37:27 am 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
Claudia Kosny	Friday 23 February 2007 12: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
David Broadfoot	Friday 23 February 2007 1: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.
Mark Marsiglio	Friday 23 February 2007 1:29:56 pm BTW - David and I work together, which is how he was able to solve my problem. http://www.thinkcreative.com Turning Ideas Into Strategic Solutions