Forum Moderators: coopster
The client wants to consider moving the Euro subsites into their own domains, i.e.
www.mysite.com/de/ would move to www.mysite.de
Of course, I want the framework library (php files) and all our php scripts, images, etc to be hosted on the mysite.com main account. All secure transactions would still need to take place via mysite.com as well. So in other words,
www.mysite.de (German site) would be its own separate account, but on the same server to that it can include the core php files and all other necessary files...but it would be used as the main domain for the German site. All products and SEO-related pages would be shown on mysite.de for this subsite. However when the customer clicks "checkout" he/she will move to [mysite.com...] because of the SSL certificate.
Questions/issues:
a) Can anyone think of simpler solutions? Perhaps use htaccess to share all code and retrieve code based on the url?
b) I'm not sure if this will work 100% with the Zend framework, I am yet to try. I have done this for non-framework sites but I see no reason why it shouldn't work. Does anyone have experience or advice on achieving this?
c) Maintaining sessions and cookies would be an issue. If we store a session on mysite.de - then we need to ensure it is maintained when moving between mysite.com and mysite.de as explained above. This could get complex and/or messy. Does anyone have any advice on the best way to achieve this? We try to keep most data in the database, but some session data is indeed maintained via sessions as the site is quite big and some areas of the site have been best coded partially with the use of sessions. Does anyone have experience with this or a recommended 'best way' to tackle this potential problem?
Many thanks!
Instead look into mod_alias to map various client-requested URLs to files and scripts.
This will allow 'URL includes' to work transparently within the server.
Symbolic links can be used to make 'files' appear in the filespace of multiple server instances.
However, if you include objects by URL, then you have to deal with the 'sessions problem.' Look into moving the critical session data from the client cookie(s) into a query string if necessary to 'cross over' into a different domain. Some sessions-based software already includes this option, intended to support users (and search robots) that run with cookies disabled.
Two key points:
1) URLs and filepaths are entirely different things. They are not equivalent, they are only "associated" by the server's configuration.
2) The client state (i.e. the session) must be stored by the client because HTTP is a 'stateless protocol' and provides no built-in mechanism for the server to keep track of it. So state-tracking is be done either by using client-side cookies, or by feeding the client 'special' query strings or URLs depending on its state.
So that's basically what you have to work with unless your customer is willing to pay for multiple security certificates.
Jim