Problems with the tree, URL aliases, paths...

Author Message

Piotrek Karaś

Tuesday 19 February 2008 6:04:59 am

I've got a very strange case. One node started to behave odd: when clicked in the tree, the user got "redirected" to its parent node. After some analysis it turned out, that it was not a redirection - the url alias simply did not contain the node's part. Not only that, in the subitems list, the node is not a link, like all other nodes, it is just a text. It still has proper name and it is still possible to view this node with system URL.

My guess was that something got messed up with tree and/or URLs. I started digging through the database and the only inconsistency I found was that in the ezcontentobject_tree table there is no path_identification_string specified for the node (while there are for objects of the same depth and class). I attempted to put it there via SQL query, but it didn't help much and disappeared again after re-editing the object.

BTW. It's eZ Publish 4.0.0 with 3 langauges.

Anyone has any suggestion what to do with that?
Any help much appreciated!
Thanks!

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

Piotrek Karaś

Wednesday 20 February 2008 9:51:02 am

Well, not so sure about my earlier observations any more. One thing is sure, though - problems that are discussed and apparently are upgrade-related, are not necessarily so. The 4.0 installation I mentioned has no upgrade history.

Because it seems to me that the problem is PathPrefix-related, could someone please provide a quick but solid explanation of how things work with URL aliases and this PathPrefix setting? I'm willing to dig a bit myself, but it looks like it's a wide subject and I could use some introduction.

BTW. Nice URL update does not help... ;(

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

Piotrek Karaś

Saturday 23 February 2008 5:28:14 am

I reported this as a bug here:
http://issues.ez.no/IssueView.php?Id=12577&activeItem=1

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

Yannick Dupuis

Monday 25 February 2008 3:02:50 am

Hi Piotrek,

I have the same problem as you with a native install of eZ Publish 4.0.
On my site, I have 5 languages and I would check one think with you.
Have you not translated parents nodes in all languages for content that loose url alias???

Personal website : http://bit.ly/Yannick-Dupuis
Company : Openbridge - http://www.openbridge.fr

Piotrek Karaś

Monday 25 February 2008 7:57:31 am

Hello Yannick,

Not 100% sure, but it seems to me that in one case no translations were made prior to the problem occurrence, and the other case looks like this:

# ROOT (pol-PL, eng-GB, nor-NO), valid
## Polish (pol-PL) <b>this one is broken</b>
### more valid nodes
## English (eng-GB)
### more valid nodes
## Norwegian (nor-NO)
### more valid nodes

It seems that in our case it has something to do with PathPrefix and lack of proper method of regenerating all URL aliases after the PathPrefix is changed. I've just edited all the nodes, but by their depth (root -> deepest), it fixed the problem... still, this seemed the easier case from the start... the other one remains a problem.

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

Piotrek Karaś

Wednesday 27 February 2008 10:40:25 am

Ok, I have partially beat it. It wasn't as much a problem with PathPrefix, as with RootNode content.ini setting. As the matter of fact, I had an invalid site configuration and the problem resulted from that. It's fine again now. I've moved my RootNode thoughts to another topic:
http://ez.no/developer/forum/developer/the_essence_of_nodesettings_rootnode_variable

Sorry for the alert.

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

Yannick Dupuis

Monday 03 March 2008 10:42:00 am

Finaly, I don't think we have the same problem Piotrek.
Indeed, all my sites access use the same root node (the default root node 2) and I don't use the PathPrefix parameter.
I look forward in database to find a explanation and I found this:
Nodes are not accessible with path uri because they have a false parent ID in ezurlalias_ml. This explain why I can access to the content with a content/view/full or un content/edit but not with the URL. The updateniceurls.php (with --update-nodes params) doesn't solve the problem, but if I edit and change the name of my content and publish it, the problem disappear.
In my error.log, I have:

eZMySQLDB:
Query error: Duplicate entry '342-5fb2eb281a089ddeb57c3cd32fd5f5da' for key 1. Query: UPDATE ezurlalias_ml SET parent = 342
WHERE parent = 367

Anybody have a idea how the ezurlalias_ml table could have duplicate entries with id/md5_text???

PS: The problem arrived randomly on a node and not to all published language version of a node.

Personal website : http://bit.ly/Yannick-Dupuis
Company : Openbridge - http://www.openbridge.fr

Rune Langseid

Tuesday 18 March 2008 12:36:29 am

Hi Yannick,

What does this SQL give you?

SELECT * from ezurlalias_ml where parent = 367;

Yannick Dupuis

Tuesday 18 March 2008 4:07:43 am

Hi Rune,

Without solution, I use the classic update process from the documentation to regenerate all nices urls (even if I have a native eZ 4 setup):

UPDATE ezurlalias SET is_imported=0;
TRUNCATE ezurlalias_ml;

and after

php bin/php/updateniceurls.php --import  -s siteAccess
-> where siteAccess is a admin site access with all languages support in site.ini:
[RegionalSettings]
Locale=eng-GB
ContentObjectLocale=eng-GB
ShowUntranslatedObjects=enabled
SiteLanguageList[]=eng-GB
SiteLanguageList[]=fre-FR
SiteLanguageList[]=ger-DE
SiteLanguageList[]=esl-ES
SiteLanguageList[]=ita-IT
TextTranslation=disabled 

After the end of updateniceurls process, I have some errors in error.ini like :

Tried to store path 'Rose4' but the path already exists (ID: 12634) but with action 'eznode:10728', the new action was 'eznode:10824'

and

Query error: Duplicate entry '8-e59d6834e86cee752ed841f9cd8d5baf' for key 1. Query: UPDATE ezurlalias_ml SET parent = 8
WHERE parent = 12400

With the query:

SELECT * from ezurlalias_ml where parent = 12400;

I have the result:

| eznode:54 | eznode      | 12401 |        0 |           0 |         1 |   12 |  12400 | common_ini_settings | e59d6834e86cee752ed841f9cd8d5baf |

If I go to some content, I always have url alias errors (buggy contents can be seeing with content/view/full but not with nice url in back or front office).
The error.ini log some errors like that when I go on a buggy content in front office:

The parent ID 16944 of element with ID 33 does not point to the last entry which had ID 21, incorrect path would be calculated, aborting

eZContentObjectTreeNode::pathWithNames() failed to fetch path of node 12851, falling back to generated url entries. Run updateniceurls.php to fix the problem.

I tried to change the transform group "urlalias" to the old system "urlalias_compact" but I have the same problem.
Now, if someone have another solution to regenerate all my nice url, don't hesitate...

Personal website : http://bit.ly/Yannick-Dupuis
Company : Openbridge - http://www.openbridge.fr

Yannick Dupuis

Tuesday 18 March 2008 10:25:07 am

I found a solution to solve my database integrity for url alias:

Hack the updateniceurls.php script at the line 1096:
replace
$hasChanged = $node->updateSubTreePath( false );
by
$hasChanged = $node->updateSubTreePath( true );

truncate ezurlalias_ml;

Run php bin/php/updateniceurls.php --update-nodes -s siteAccess

It's a solution for the problem but not for causes and maybe it will go back again as it's arrived randomly...

Personal website : http://bit.ly/Yannick-Dupuis
Company : Openbridge - http://www.openbridge.fr

infolox GmbH

Tuesday 08 April 2008 5:31:52 am

We have the same url alias errors as described above. At first it seemed to occur randomly but now we have found out how to reproduce the issue. It seems that if the attribute which is used to generate the name of the node is changed any later translation of the node will produce invalid entries in the ezurlalias_ml table. The whole subtree starting at the translated node will not be accessible by the url alias anymore. You have to use "content/view/full/*". It's possible to repair the node by fixing the column values of “id” and “link” of the table ezurlalias_ml. This way the subtree can be accessed by the url alias again. But this does not fix the actual problem. We have created an issue for the problem: http://issues.ez.no/IssueView.php?Id=12829. Probably other issues like http://issues.ez.no/IssueView.php?Id=12577 or http://issues.ez.no/12720 are related to the same or similar problem.

florian bellenger

Monday 01 December 2008 10:37:56 am

I have the same problem (http://issues.ez.no/12720).

I would like to understand what the table ezurlalias_ml is, what are the meaning of its attributes, what does the columns "parent" and "text_md5" contain exactly?.

What do you mean by " It's possible to repair the node by fixing the column values of “id” and “link” of the table ezurlalias_ml." ?

I'm using ezpublish 4.0.0.

Florian.

I am not sure to have understood: Does this happened only when a parent node is modified?

if I delete the subtree of node when the problem occurs and create again all the node ( parent first,children after), will it fix the problem?

Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2014 eZ Systems AS (except where otherwise noted). All rights reserved.