updateniceurls.php could update path_string.

Next topic

Author	Message
Erik Weinmaster	Thursday 13 January 2011 11:25:37 am Hello, I've run into a couple problems with the ezcontentobject_tree table. Mainly, the two fields of 'path_identification_string' and 'path_string' seem to be inaccurate from time to time. The 'path_identification_string' is the least of the worries since this can be easily rectified by running the mentioned script (updateniceurls.php). However, I do see on occasion an incorrect 'path_string'. I think this mainly happens when an upgrade to the database is attempted. Nevertheless, if one is going to the trouble of running the script in general, It would be nice to see 'path_string' included in the process. I've already created a function and added it to my own install. I listed the function here: function updatePathString( $node ) { $parentNode = $node->attribute( 'parent' ); $pathString = $parentNode->attribute( 'path_string' ).$node->attribute( 'node_id' ).'/'; if( $node->attribute( 'path_string' ) != $pathString ) { $node->setAttribute( 'path_string', $pathString ); $node->sync(); } } The call would be as shown: foreach ( array_keys( $nodeList ) as $key ) { $node = $nodeList[ $key ]; updatePathString( $node ); $hasChanged = $node->updateSubTreePath(); As you can see, its fairly simple and does the job. Thanks, -erik
Christian Rößler	Friday 14 January 2011 8:57:42 am Erik, this looks good. Did you encounter errors in var/log/error.log as below or did you just dig into the database and fell over this issue? [ Jan 14 2011 17:25:33 ] [66.249.71.228] :eZContentObjectTreeNode::pathWithNames() failed to fetch path of node 17898, falling back to generated url entries. Run updateniceurls.php to fix the problem. In other words, did your patch solve the url-alias problems above? Those errors I got an a fresh installed ezPublish 4.3 which runs now some months and is used by some editors - but could not determine a real ez-error. Searching the forums did in fact show some threads with users having the same issue i have, but now solution or even a source for those errors. Cheers, chris Hannover, Germany eZ-Certified http://auth.ez.no/certification/verify/395613
Erik Weinmaster	Friday 21 January 2011 1:08:01 pm Christian, To answer your first question, I found this issue by digging into the database itself. I noticed that some nodes didn't have the friendly url link even though there was a path_string. So, I made this patch because I found some nodes whos path_string was something like '/1/2/345654/543' and it needed to be '/1/2/345/654/543'. It appears that sometimes a slash '/' doesn't get copied over and you end up with the system thinking you have a different node_id. I really don't know if prolonged used or multiple upgrades is the cause of the problem. Also, your error that you submitted is an output when path_identification_string is not set. This is easy to fix by running the upgradeniceurls.php script. As for your second question. I don't really know if this hits much of the url_alias. Like I said before, if the path_string isn't correct, then instead of getting a nice friendly url to click on '/folder/myfolder/' you'll get what this should be mapped to '/content/view/234/'. This is also a good point of why this is sort of a minor issue. Even if the path_string doesn't work (which I think helps provide the friendly url), you'll end up with the controller url of '/content/view/234/'. Both of which will take you to your node. Hope I cleared things up, erik

Author

Message

Thursday 13 January 2011 11:25:37 am

Hello,

I've run into a couple problems with the ezcontentobject_tree table. Mainly, the two fields of 'path_identification_string' and 'path_string' seem to be inaccurate from time to time. The 'path_identification_string' is the least of the worries since this can be easily rectified by running the mentioned script (updateniceurls.php).

However, I do see on occasion an incorrect 'path_string'. I think this mainly happens when an upgrade to the database is attempted. Nevertheless, if one is going to the trouble of running the script in general, It would be nice to see 'path_string' included in the process.

I've already created a function and added it to my own install. I listed the function here:
function updatePathString( $node )
{
$parentNode = $node->attribute( 'parent' );
$pathString = $parentNode->attribute( 'path_string' ).$node->attribute( 'node_id' ).'/';
if( $node->attribute( 'path_string' ) != $pathString )
{
$node->setAttribute( 'path_string', $pathString );
$node->sync();
}
}

The call would be as shown:

foreach ( array_keys( $nodeList ) as $key )
{
$node = $nodeList[ $key ];
updatePathString( $node );
$hasChanged = $node->updateSubTreePath();

As you can see, its fairly simple and does the job.

Thanks,

-erik

Christian Rößler

Friday 14 January 2011 8:57:42 am

Erik, this looks good.

Did you encounter errors in var/log/error.log as below or did you just dig into the database and fell over this issue?

 [ Jan 14 2011 17:25:33 ] [66.249.71.228] :eZContentObjectTreeNode::pathWithNames() failed to fetch path of node 17898, falling back to generated url entries. Run updateniceurls.php to fix the problem.

In other words, did your patch solve the url-alias problems above?
Those errors I got an a fresh installed ezPublish 4.3 which runs now some months and is used by some editors - but could not determine a real ez-error. Searching the forums did in fact show some threads with users having the same issue i have, but now solution or even a source for those errors.

Cheers,
chris

Hannover, Germany
eZ-Certified http://auth.ez.no/certification/verify/395613

Erik Weinmaster

Friday 21 January 2011 1:08:01 pm

Christian,

To answer your first question, I found this issue by digging into the database itself. I noticed that some nodes didn't have the friendly url link even though there was a path_string. So, I made this patch because I found some nodes whos path_string was something like '/1/2/345654/543' and it needed to be '/1/2/345/654/543'. It appears that sometimes a slash '/' doesn't get copied over and you end up with the system thinking you have a different node_id. I really don't know if prolonged used or multiple upgrades is the cause of the problem. Also, your error that you submitted is an output when path_identification_string is not set. This is easy to fix by running the upgradeniceurls.php script.

As for your second question. I don't really know if this hits much of the url_alias. Like I said before, if the path_string isn't correct, then instead of getting a nice friendly url to click on '/folder/myfolder/' you'll get what this should be mapped to '/content/view/234/'. This is also a good point of why this is sort of a minor issue. Even if the path_string doesn't work (which I think helps provide the friendly url), you'll end up with the controller url of '/content/view/234/'. Both of which will take you to your node.

Hope I cleared things up,

erik