Forums / Extensions / eZ Find / main_url_alias in solr fits not the lang., it's indexed at

main_url_alias in solr fits not the lang., it's indexed at

Next topic

Author	Message
Jens Görisch	Wednesday 15 October 2008 8:39:29 am In my solr index some objects exist in different languages, but all indexed documents have the same main_url_alias (top priority language of the siteaccess indexed at, i guess). Is it a bug or is this field not used at all? I use the trunk version of ezfind, if it's important. Further i wonder about how this field can be used effectively. When for example a parent nodes name of a some objects changes, theoretically all subitems must be reindexed recursively to keep the index up to date with the changed url alias. Is this done already by the eZ Publish or is it planned to implement such behavior, perhaps? I'm asking this, because this field would be really nice for multilanguage search and for now it's really hard to assemble a correct url alias path from the search result. I use /content/view/full at the moment, as this is the least complicated way to link objects outside the current siteaccess/language. But it's not the finest ;-)

Author

Message

Wednesday 15 October 2008 8:39:29 am

In my solr index some objects exist in different languages, but all indexed documents have the same main_url_alias (top priority language of the siteaccess indexed at, i guess). Is it a bug or is this field not used at all?

I use the trunk version of ezfind, if it's important.

Further i wonder about how this field can be used effectively. When for example a parent nodes name of a some objects changes, theoretically all subitems must be reindexed recursively to keep the index up to date with the changed url alias. Is this done already by the eZ Publish or is it planned to implement such behavior, perhaps?

I'm asking this, because this field would be really nice for multilanguage search and for now it's really hard to assemble a correct url alias path from the search result. I use /content/view/full at the moment, as this is the least complicated way to link objects outside the current siteaccess/language. But it's not the finest ;-)