Ecommerce <@ofbizUrl> Problem

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Ecommerce <@ofbizUrl> Problem

samhamilton
Hey Guys,

I am wondering how other people get over this problem?

If you have multiple websites running in OFBiz at the same time then
they will all be mounted at different urls e.g. /ecommerce & /ecommerce2
& /ecommerce3 for three different websites.

Now its easy to setup ajp/httpd to point www.ecommerce.com to /ecommerce
and then www.ecommerce2.com to /ecommerce2 etc.

But when you do this then go to www.ecommerce.com and try and click any
of the links it has automatically added the mount point back into the
url e.g. www.ecommerce.com/ecommerce/control/view/showcart but these 404
because we have done the trickery with ajp to try and hide the mount point.

I have found that it is something to do with <@ofbizUrl> tags in the FTL
but I am not sure how to alter them to drop the /ecommerce/

Thanks
Sam




Reply | Threaded
Open this post in threaded view
|

Re: Ecommerce <@ofbizUrl> Problem

rajsaini
Hi Sam,

It is complicated and short answer is ProxyPass directive of mod_proxy
does not rewrite the absolute links embedded in the pages whereas OFBiz
links are absolute links. The solution is to use  mod_proxy_html module
to rewrite the links embedded links
http://www.apachetutor.org/admin/reverseproxies

Regards,

Raj


On 15/07/10 08:19, Sam Hamilton wrote:

> Hey Guys,
>
> I am wondering how other people get over this problem?
>
> If you have multiple websites running in OFBiz at the same time then
> they will all be mounted at different urls e.g. /ecommerce&  /ecommerce2
> &  /ecommerce3 for three different websites.
>
> Now its easy to setup ajp/httpd to point www.ecommerce.com to /ecommerce
> and then www.ecommerce2.com to /ecommerce2 etc.
>
> But when you do this then go to www.ecommerce.com and try and click any
> of the links it has automatically added the mount point back into the
> url e.g. www.ecommerce.com/ecommerce/control/view/showcart but these 404
> because we have done the trickery with ajp to try and hide the mount point.
>
> I have found that it is something to do with<@ofbizUrl>  tags in the FTL
> but I am not sure how to alter them to drop the /ecommerce/
>
> Thanks
> Sam
>
>
>
>
>
>    

Reply | Threaded
Open this post in threaded view
|

Re: Ecommerce <@ofbizUrl> Problem

samhamilton
Cheers will go have a read

Sam

On 15/07/2010 12:27, Raj Saini wrote:

> Hi Sam,
>
> It is complicated and short answer is ProxyPass directive of mod_proxy
> does not rewrite the absolute links embedded in the pages whereas OFBiz
> links are absolute links. The solution is to use  mod_proxy_html module
> to rewrite the links embedded links
> http://www.apachetutor.org/admin/reverseproxies
>
> Regards,
>
> Raj
>
>
> On 15/07/10 08:19, Sam Hamilton wrote:
>> Hey Guys,
>>
>> I am wondering how other people get over this problem?
>>
>> If you have multiple websites running in OFBiz at the same time then
>> they will all be mounted at different urls e.g. /ecommerce&  /ecommerce2
>> &  /ecommerce3 for three different websites.
>>
>> Now its easy to setup ajp/httpd to point www.ecommerce.com to /ecommerce
>> and then www.ecommerce2.com to /ecommerce2 etc.
>>
>> But when you do this then go to www.ecommerce.com and try and click any
>> of the links it has automatically added the mount point back into the
>> url e.g. www.ecommerce.com/ecommerce/control/view/showcart but these 404
>> because we have done the trickery with ajp to try and hide the mount
>> point.
>>
>> I have found that it is something to do with<@ofbizUrl>  tags in the FTL
>> but I am not sure how to alter them to drop the /ecommerce/
>>
>> Thanks
>> Sam
>>
>>
>>
>>
>>
>>    
>

Reply | Threaded
Open this post in threaded view
|

Re: Ecommerce <@ofbizUrl> Problem

Scott Gray-2
In reply to this post by rajsaini
It's an interesting problem for sure.  Currently the URL writing method RequestHandler.makeLink(...) (which the ofbizUrl transform delegates to) uses the _CONTROL_PATH_ request attribute to add the control path portion of the URL.  

As a short term test you could try overwriting that attribute from within a groovy script in the actions of your global decorator.  That would solve the problem for URL generation but I'm not sure what else uses that attribute and could be affected by such as change.

As a longer term solution, we could possibly look at adding another field for this purpose to the WebSite entity which if defined, would override the control path used in the makeLink method.

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

On 15/07/2010, at 4:27 PM, Raj Saini wrote:

> Hi Sam,
>
> It is complicated and short answer is ProxyPass directive of mod_proxy does not rewrite the absolute links embedded in the pages whereas OFBiz links are absolute links. The solution is to use  mod_proxy_html module to rewrite the links embedded links http://www.apachetutor.org/admin/reverseproxies
>
> Regards,
>
> Raj
>
>
> On 15/07/10 08:19, Sam Hamilton wrote:
>> Hey Guys,
>>
>> I am wondering how other people get over this problem?
>>
>> If you have multiple websites running in OFBiz at the same time then
>> they will all be mounted at different urls e.g. /ecommerce&  /ecommerce2
>> &  /ecommerce3 for three different websites.
>>
>> Now its easy to setup ajp/httpd to point www.ecommerce.com to /ecommerce
>> and then www.ecommerce2.com to /ecommerce2 etc.
>>
>> But when you do this then go to www.ecommerce.com and try and click any
>> of the links it has automatically added the mount point back into the
>> url e.g. www.ecommerce.com/ecommerce/control/view/showcart but these 404
>> because we have done the trickery with ajp to try and hide the mount point.
>>
>> I have found that it is something to do with<@ofbizUrl>  tags in the FTL
>> but I am not sure how to alter them to drop the /ecommerce/
>>
>> Thanks
>> Sam
>>
>>
>>
>>
>>
>>  
>


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ecommerce <@ofbizUrl> Problem

BJ Freeman
using the website entity was the direction I was going.
since it is defined in the web.xml of the ecommerce webapp,
I would like to see the websited first Identified by the incomming URL
http://mydomain.com, then the mountpoint appended.
the problems I see is going to the the backend  for say customer orders.
the myportal has its own webstite entity and is only good for defining
one incomming URL.
it is clunky but maybe defining in the eccommerce context the website
enity for myportal would solve this.

any way if that could be accomplished they apache httpd would not be needed.

just thinking outloud.

Scott Gray sent the following on 7/14/2010 10:53 PM:

> It's an interesting problem for sure.  Currently the URL writing method RequestHandler.makeLink(...) (which the ofbizUrl transform delegates to) uses the _CONTROL_PATH_ request attribute to add the control path portion of the URL.
>
> As a short term test you could try overwriting that attribute from within a groovy script in the actions of your global decorator.  That would solve the problem for URL generation but I'm not sure what else uses that attribute and could be affected by such as change.
>
> As a longer term solution, we could possibly look at adding another field for this purpose to the WebSite entity which if defined, would override the control path used in the makeLink method.
>
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 15/07/2010, at 4:27 PM, Raj Saini wrote:
>
>> Hi Sam,
>>
>> It is complicated and short answer is ProxyPass directive of mod_proxy does not rewrite the absolute links embedded in the pages whereas OFBiz links are absolute links. The solution is to use  mod_proxy_html module to rewrite the links embedded links http://www.apachetutor.org/admin/reverseproxies
>>
>> Regards,
>>
>> Raj
>>
>>
>> On 15/07/10 08:19, Sam Hamilton wrote:
>>> Hey Guys,
>>>
>>> I am wondering how other people get over this problem?
>>>
>>> If you have multiple websites running in OFBiz at the same time then
>>> they will all be mounted at different urls e.g. /ecommerce&   /ecommerce2
>>> &   /ecommerce3 for three different websites.
>>>
>>> Now its easy to setup ajp/httpd to point www.ecommerce.com to /ecommerce
>>> and then www.ecommerce2.com to /ecommerce2 etc.
>>>
>>> But when you do this then go to www.ecommerce.com and try and click any
>>> of the links it has automatically added the mount point back into the
>>> url e.g. www.ecommerce.com/ecommerce/control/view/showcart but these 404
>>> because we have done the trickery with ajp to try and hide the mount point.
>>>
>>> I have found that it is something to do with<@ofbizUrl>   tags in the FTL
>>> but I am not sure how to alter them to drop the /ecommerce/
>>>
>>> Thanks
>>> Sam
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Ecommerce <@ofbizUrl> Problem

samhamilton
Could you put it in ofbiz-component.xml?

Something like this?

<webapp name="ecommerce_uk"
        title="eCommerce UK"
        server="default-server"
        location="webapp/ecommerce_uk"
        mount-point="/ecommerce_uk"
        app-bar-display="false"/>
               
<webapp name="ecommerce_uk"
        title="eCommerce UK"
        server="default-server"
        location="webapp/ecommerce_uk"
        mount-point="/"
        app-bar-display="false">
        <virtual-host host-name="www.ecommerce.co.uk"/>
</webapp>

Sam

On 15/07/2010 17:16, BJ Freeman wrote:

> using the website entity was the direction I was going.
> since it is defined in the web.xml of the ecommerce webapp,
> I would like to see the websited first Identified by the incomming URL
> http://mydomain.com, then the mountpoint appended.
> the problems I see is going to the the backend  for say customer orders.
> the myportal has its own webstite entity and is only good for defining
> one incomming URL.
> it is clunky but maybe defining in the eccommerce context the website
> enity for myportal would solve this.
>
> any way if that could be accomplished they apache httpd would not be
> needed.
>
> just thinking outloud.
>
> Scott Gray sent the following on 7/14/2010 10:53 PM:
>> It's an interesting problem for sure.  Currently the URL writing
>> method RequestHandler.makeLink(...) (which the ofbizUrl transform
>> delegates to) uses the _CONTROL_PATH_ request attribute to add the
>> control path portion of the URL.
>>
>> As a short term test you could try overwriting that attribute from
>> within a groovy script in the actions of your global decorator.  That
>> would solve the problem for URL generation but I'm not sure what else
>> uses that attribute and could be affected by such as change.
>>
>> As a longer term solution, we could possibly look at adding another
>> field for this purpose to the WebSite entity which if defined, would
>> override the control path used in the makeLink method.
>>
>> Regards
>> Scott
>>
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> On 15/07/2010, at 4:27 PM, Raj Saini wrote:
>>
>>> Hi Sam,
>>>
>>> It is complicated and short answer is ProxyPass directive of
>>> mod_proxy does not rewrite the absolute links embedded in the pages
>>> whereas OFBiz links are absolute links. The solution is to use
>>> mod_proxy_html module to rewrite the links embedded links
>>> http://www.apachetutor.org/admin/reverseproxies
>>>
>>> Regards,
>>>
>>> Raj
>>>
>>>
>>> On 15/07/10 08:19, Sam Hamilton wrote:
>>>> Hey Guys,
>>>>
>>>> I am wondering how other people get over this problem?
>>>>
>>>> If you have multiple websites running in OFBiz at the same time then
>>>> they will all be mounted at different urls e.g. /ecommerce&  
>>>> /ecommerce2
>>>> &   /ecommerce3 for three different websites.
>>>>
>>>> Now its easy to setup ajp/httpd to point www.ecommerce.com to
>>>> /ecommerce
>>>> and then www.ecommerce2.com to /ecommerce2 etc.
>>>>
>>>> But when you do this then go to www.ecommerce.com and try and click any
>>>> of the links it has automatically added the mount point back into the
>>>> url e.g. www.ecommerce.com/ecommerce/control/view/showcart but these
>>>> 404
>>>> because we have done the trickery with ajp to try and hide the mount
>>>> point.
>>>>
>>>> I have found that it is something to do with<@ofbizUrl>   tags in
>>>> the FTL
>>>> but I am not sure how to alter them to drop the /ecommerce/
>>>>
>>>> Thanks
>>>> Sam
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Ecommerce <@ofbizUrl> Problem

BJ Freeman
No need to duplicate data.
https://demo-trunk.ofbiz.apache.org/content/control/EditWebSite?webSiteId=WebStore


Sam Hamilton sent the following on 7/15/2010 3:12 AM:

> Could you put it in ofbiz-component.xml?
>
> Something like this?
>
> <webapp name="ecommerce_uk"
>          title="eCommerce UK"
>          server="default-server"
>          location="webapp/ecommerce_uk"
>          mount-point="/ecommerce_uk"
>          app-bar-display="false"/>
>
> <webapp name="ecommerce_uk"
>          title="eCommerce UK"
>          server="default-server"
>          location="webapp/ecommerce_uk"
>          mount-point="/"
>          app-bar-display="false">
> <virtual-host host-name="www.ecommerce.co.uk"/>
> </webapp>
>
> Sam
>
> On 15/07/2010 17:16, BJ Freeman wrote:
>> using the website entity was the direction I was going.
>> since it is defined in the web.xml of the ecommerce webapp,
>> I would like to see the websited first Identified by the incomming URL
>> http://mydomain.com, then the mountpoint appended.
>> the problems I see is going to the the backend  for say customer orders.
>> the myportal has its own webstite entity and is only good for defining
>> one incomming URL.
>> it is clunky but maybe defining in the eccommerce context the website
>> enity for myportal would solve this.
>>
>> any way if that could be accomplished they apache httpd would not be
>> needed.
>>
>> just thinking outloud.
>>
>> Scott Gray sent the following on 7/14/2010 10:53 PM:
>>> It's an interesting problem for sure.  Currently the URL writing
>>> method RequestHandler.makeLink(...) (which the ofbizUrl transform
>>> delegates to) uses the _CONTROL_PATH_ request attribute to add the
>>> control path portion of the URL.
>>>
>>> As a short term test you could try overwriting that attribute from
>>> within a groovy script in the actions of your global decorator.  That
>>> would solve the problem for URL generation but I'm not sure what else
>>> uses that attribute and could be affected by such as change.
>>>
>>> As a longer term solution, we could possibly look at adding another
>>> field for this purpose to the WebSite entity which if defined, would
>>> override the control path used in the makeLink method.
>>>
>>> Regards
>>> Scott
>>>
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> On 15/07/2010, at 4:27 PM, Raj Saini wrote:
>>>
>>>> Hi Sam,
>>>>
>>>> It is complicated and short answer is ProxyPass directive of
>>>> mod_proxy does not rewrite the absolute links embedded in the pages
>>>> whereas OFBiz links are absolute links. The solution is to use
>>>> mod_proxy_html module to rewrite the links embedded links
>>>> http://www.apachetutor.org/admin/reverseproxies
>>>>
>>>> Regards,
>>>>
>>>> Raj
>>>>
>>>>
>>>> On 15/07/10 08:19, Sam Hamilton wrote:
>>>>> Hey Guys,
>>>>>
>>>>> I am wondering how other people get over this problem?
>>>>>
>>>>> If you have multiple websites running in OFBiz at the same time then
>>>>> they will all be mounted at different urls e.g. /ecommerce&
>>>>> /ecommerce2
>>>>> &    /ecommerce3 for three different websites.
>>>>>
>>>>> Now its easy to setup ajp/httpd to point www.ecommerce.com to
>>>>> /ecommerce
>>>>> and then www.ecommerce2.com to /ecommerce2 etc.
>>>>>
>>>>> But when you do this then go to www.ecommerce.com and try and click any
>>>>> of the links it has automatically added the mount point back into the
>>>>> url e.g. www.ecommerce.com/ecommerce/control/view/showcart but these
>>>>> 404
>>>>> because we have done the trickery with ajp to try and hide the mount
>>>>> point.
>>>>>
>>>>> I have found that it is something to do with<@ofbizUrl>    tags in
>>>>> the FTL
>>>>> but I am not sure how to alter them to drop the /ecommerce/
>>>>>
>>>>> Thanks
>>>>> Sam
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>
>