URL translation to extension URL w/user parameters?

Tuesday 27 February 2007 10:39:19 am - 3 replies

3 replies

Author	Message
Xavier Dutoit	Wednesday 28 February 2007 12:20:41 am Hi And just calling /foo works ? The syntax is /module/view not just /module ? Otherwise, you can do the redirect from the apache mod rewrite config. Might be easier... X+ http://www.sydesy.com
Luis Cruz	Wednesday 28 February 2007 4:27:01 am Yes, both /foo and /foo/(bar)/foobar work if I enter them directly in my browser. The page renders as I would expect. I have found a partial solution at the moment; I first have to create the URL translation as /foo/(bar)/foobar. Then, I have to edit it to read /foo//(bar)/foobar. For some reason, creating it as /foo//(bar)/foobar does not work; it will only work after you hit the "apply changes" button after it has already been created. However, it does not seem to be passing the parameters along to the extension. As for mod_rewrite, sure, I could do it that way, but it would be counterproductive for my purposes. I want people skilled enough to use eZ but not nearly skilled enough to mess around with Apache configuration to be able to see and manage URL translations in one place.
Luis Cruz	Wednesday 28 February 2007 8:33:04 am I believe I have found a solution that requires a slight kernel hack. Now, I can define a system URL forward rule for /foo to go to /foo/(bar)/foobar, /foo/(foobar)/bar, etc. To do this, I modified kernel/classes/ezurlalias.php, starting line 812, eZURLAlias::translate() from if ( get_class( $uri ) == "ezuri" ) { $uri->setURIString( $uriString, false ); } to if ( get_class( $uri ) == "ezuri" ) { $uri->setURIString( $uriString); //, false ); } I have run through my site and have not seen any issues caused by this change. Existing URL translations continue to work, and non-translated URLs continue to work. However, any change deep in the kernel bowels gives me pause. I'm hoping an official eZ rep/developer will see this and comment on if this has any repercussions for the overall system (or why you would want to not have full initialization going on in setURIString at this point). EDIT: It does affect the system; if I type /foo/(bar)/foobar directly into my browser, the user parameters are not passed in. So, this definitely breaks something, but I don't know why. Back to the drawing board...

Author

Message

Xavier Dutoit

Wednesday 28 February 2007 12:20:41 am

And just calling /foo works ? The syntax is /module/view not just /module ?

Otherwise, you can do the redirect from the apache mod rewrite config. Might be easier...
X+

http://www.sydesy.com

Luis Cruz

Wednesday 28 February 2007 4:27:01 am

Yes, both /foo and /foo/(bar)/foobar work if I enter them directly in my browser. The page renders as I would expect. I have found a partial solution at the moment; I first have to create the URL translation as /foo/(bar)/foobar. Then, I have to edit it to read /foo//(bar)/foobar. For some reason, creating it as /foo//(bar)/foobar does not work; it will only work after you hit the "apply changes" button after it has already been created. However, it does not seem to be passing the parameters along to the extension.

As for mod_rewrite, sure, I could do it that way, but it would be counterproductive for my purposes. I want people skilled enough to use eZ but not nearly skilled enough to mess around with Apache configuration to be able to see and manage URL translations in one place.

Luis Cruz

Wednesday 28 February 2007 8:33:04 am

I believe I have found a solution that requires a slight kernel hack. Now, I can define a system URL forward rule for /foo to go to /foo/(bar)/foobar, /foo/(foobar)/bar, etc.

To do this, I modified kernel/classes/ezurlalias.php, starting line 812, eZURLAlias::translate() from

        if ( get_class( $uri ) == "ezuri" )
        {
            $uri->setURIString( $uriString, false );
        }

        if ( get_class( $uri ) == "ezuri" )
        {
            $uri->setURIString( $uriString); //, false );
        }

I have run through my site and have not seen any issues caused by this change. Existing URL translations continue to work, and non-translated URLs continue to work. However, any change deep in the kernel bowels gives me pause. I'm hoping an official eZ rep/developer will see this and comment on if this has any repercussions for the overall system (or why you would want to not have full initialization going on in setURIString at this point).

EDIT: It does affect the system; if I type /foo/(bar)/foobar directly into my browser, the user parameters are not passed in. So, this definitely breaks something, but I don't know why. Back to the drawing board...

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