I've got multi store all setup running 2 subdomains, OC v1.5.5.1 with a wildcard SSL. The main store works just fine but I've got a slight issue with the 2nd store. Whenever I want to go to any of the https pages, it shows the correct URL but displays all of the content from the other site. It also causes the checkout to not work (works just fine with SSL disabled) I have a .htaccess file in my public_html folder with the following:
RewriteEngine on
RewriteBase /
RewriteCond %{SERVER_PORT} ^443$
RewriteCond %{HTTP_HOST} ^subdomain1\.domain\.com$ [NC]
RewriteCond %{REQUEST_URI} !^1551/
RewriteRule ^(.*) /1551/$1
RewriteCond %{SERVER_PORT} ^443$
RewriteCond %{HTTPS_HOST} ^subdomain1\.domain\.com$ [NC]
RewriteCond %{REQUEST_URI} !^1551/
RewriteRule ^(.*) /1551/$1
RewriteCond %{SERVER_PORT} ^443$
RewriteCond %{HTTP_HOST} ^subdomain2\.domain\.com$ [NC]
RewriteCond %{REQUEST_URI} !^1551/
RewriteRule ^(.*) /1551/$1
RewriteCond %{SERVER_PORT} ^443$
RewriteCond %{HTTPS_HOST} ^subdomain2\.domain\.com$ [NC]
RewriteCond %{REQUEST_URI} !^1551/
RewriteRule ^(.*) /1551/$1
Hoping someone can help me sort this out. Thanks.
DL
Last edited by cwswebdesign on Sat Aug 24, 2013 8:13 pm, edited 1 time in total.
This account is inactive. Look for us under the name 'EvolveWebHosting' and contact us under that username.
Thanks!
What happens if you flip the pairs of tetrads, from AB CD to CD AB? That would seem to show whether it looked up "1" and skipped the part about "2" (if so, then flipping would cause the reverse in correct URLs but wrong content). Then if that happens the problem would be to make it look at all four entries before exiting .htaccess en route to ?route. Otherwise, more noodling; that one was just an immediate stray thought.
I think I tried what you suggested and nothing different. I tried the shared cookie option and when I view the source code, the 2nd URL doesn't show https
I keep wondering if it's to do with my routes? I've tried so many different things today....... and I'm going to walk away for a few hours and see if something else makes sense.
I emailed OpenCart support as well, so I'm crossing my fingers that they'll have a solution.
DL
I keep wondering if it's to do with my routes? I've tried so many different things today....... and I'm going to walk away for a few hours and see if something else makes sense.
I emailed OpenCart support as well, so I'm crossing my fingers that they'll have a solution.
DL
This account is inactive. Look for us under the name 'EvolveWebHosting' and contact us under that username.
Thanks!
Among the sorts of things that may be too obvious while working on something, are both subdomains set up formally, all the way, such as with DNS A, and are both set up that way, and neither as the basic www. (default first sub), and has propagation time for DNS A run?
Likewise, are the index.php?routes sidetracked by product assignments to categories?
Likewise, are the index.php?routes sidetracked by product assignments to categories?
I haven't done any of that but I'm convinced it's something I have or they have setup in OpenCart. If I take out the first two groups in that .htaccess file (for the main subdomain), the 2nd subdomain still tries to link over to the main subdomian.butte wrote:Among the sorts of things that may be too obvious while working on something, are both subdomains set up formally, all the way, such as with DNS A, and are both set up that way, and neither as the basic www. (default first sub), and has propagation time for DNS A run?
If I change both config files to define HTTP and HTTP to the 2nd subdomain and not the first, as well as removing the .htaccess SSL port code for the first subdomain, it still tries to link to the first subdomain.
DL
This account is inactive. Look for us under the name 'EvolveWebHosting' and contact us under that username.
Thanks!
Checking just a couple of products for category assignments might show whether the or a product table, and the or a category, should be segregated into more than one table so as to avoid any confusion among product IDs and among category IDs.
I'm not sure if I need to do that? Everything works great without SSL (every single page, function, etc). Once I enable SSL, I have the issues with the account and checkout pages. Should I still check there?butte wrote:Checking just a couple of products for category assignments might show whether the or a product table, and the or a category, should be segregated into more than one table so as to avoid any confusion among product IDs and among category IDs.
DL
This account is inactive. Look for us under the name 'EvolveWebHosting' and contact us under that username.
Thanks!
I thought that the problem occurs in any event ("as well as removing the .htaccess SSL port" -- but now "works great without SSL"). IF when you turn SSL off there is no problem, but with it on both stores land on one store's products, then since SSL and non-SSL will be following paths derived from the self-same database, then segregating tables would seem overkill or maybe even a bad idea. Except as to customer account's store assignments, that could be a shunt off course.
If there is anything different in drawing paths that SSL does or decided upon its own to do and relates to database, then there would still be reason to look at the database. There shouldn't be anything different as to product and category paths. There could be a switchover hidden in there by way of customer accounts' store assignments.
It can be tricky, of course, protecting too much of OC with SSL.
If there is anything different in drawing paths that SSL does or decided upon its own to do and relates to database, then there would still be reason to look at the database. There shouldn't be anything different as to product and category paths. There could be a switchover hidden in there by way of customer accounts' store assignments.
It can be tricky, of course, protecting too much of OC with SSL.
butte wrote:I thought that the problem occurs in any event ("as well as removing the .htaccess SSL port" -- but now "works great without SSL"). IF when you turn SSL off there is no problem, but with it on both stores land on one store's products, then since SSL and non-SSL will be following paths derived from the self-same database, then segregating tables would seem overkill or maybe even a bad idea.
Sorry, I'll try to be more clear here:
All works fine with the following:
SSL on for the main store (works 100% proper - products, categories, modules, account, checkout, etc)
No SSL on 2nd Store (everything works the way it should without SSL enabled)
As soon as I enable SSL for the 2nd store (leaving SSL enabled on the first store of course), the account pages and checkout (for the 2nd store) display the correct URL in the browser URL field but the actual page content displayed are from store 1.
DL
This account is inactive. Look for us under the name 'EvolveWebHosting' and contact us under that username.
Thanks!
Three thoughts come to mind, and are mainly for triggering the old light bulb.
SSL.-- Is the wildcard SSL given any preference that would favor one o the two? What happens if each subdomain is given its own SSL (the question may be academic)?
DB.-- Do the two have all or partly their own table prefixes in the DB, notably as to categories, products, and accounts?
Geometry.-- Is the arrangement in effect a V or a lopsided Y? Are there still four indices and four configs? That is, is there anything unusual in how they share anything?
Best guess at the moment is that the wildcard SSL is where to start.
SSL.-- Is the wildcard SSL given any preference that would favor one o the two? What happens if each subdomain is given its own SSL (the question may be academic)?
DB.-- Do the two have all or partly their own table prefixes in the DB, notably as to categories, products, and accounts?
Geometry.-- Is the arrangement in effect a V or a lopsided Y? Are there still four indices and four configs? That is, is there anything unusual in how they share anything?
Best guess at the moment is that the wildcard SSL is where to start.
The SSL was created for *.domain.com and then in public_html, there is an htaccess for the secure port configs. I haven't done anything to the database to duplicate or designate specifics for each store. I did that with the layouts and it's pretty much narrowed down to the SSL configuration that's giving me problems. At the moment, 2 SSL's aren't an option because the wildcard was recently purchased.butte wrote:Three thoughts come to mind, and are mainly for triggering the old light bulb.
SSL.-- Is the wildcard SSL given any preference that would favor one o the two? What happens if each subdomain is given its own SSL (the question may be academic)?
DB.-- Do the two have all or partly their own table prefixes in the DB, notably as to categories, products, and accounts?
Geometry.-- Is the arrangement in effect a V or a lopsided Y? Are there still four indices and four configs? That is, is there anything unusual in how they share anything?
Best guess at the moment is that the wildcard SSL is where to start.
Going back to the database, why would I need those separations of table prefixes when everything works great on both stores with SSL off for the second?
DL
This account is inactive. Look for us under the name 'EvolveWebHosting' and contact us under that username.
Thanks!
Given SSL as best guess here and a usual suspect anywhere, and given that aspect narrowed to SSL on for only "2", I don't see any compelling reason to fiddle with the tables now, unless doing so comes up over something else. Tables and IDs came to mind while it seemed that the index.php?routes were bound to show "1" no matter what.
I'm wondering if this guy was onto something?
http://forum.opencart.com/viewtopic.php ... 20#p189212
It doesn't work for 1.5.5.1 but I wonder if it can be modified a little bit some way and it'll work?
DL
http://forum.opencart.com/viewtopic.php ... 20#p189212
It doesn't work for 1.5.5.1 but I wonder if it can be modified a little bit some way and it'll work?
DL
This account is inactive. Look for us under the name 'EvolveWebHosting' and contact us under that username.
Thanks!
After reading that other whole thread and the links from it, I think you're right, it would probably work with whatever adjustments might be required for version. The version difference might reside in a subtlety of link or args elsewhere in the file setting up what the solution does. Maybe it's staring out from what is flipped.
The solution seems almost counterintutitive in a way, in flipping the sequence. He said, "I forgot to add that I don't use ssl," and then flipping the sequence brought about "now work on main domain and all multistores." You have SSL and the flipped sequence accordingly shouldn't work except for the if else being affected by the SSL or NOTSSL. I'm not sure how to put it, so maybe this, "dumb idea" or not, will spark a thought. If car then drive car, else if truck then drive truck. If truck then drive truck else if car then drive car. If want drive car and if car then drive car else if truck then drive truck. If want drive truck and if truck then drive truck else if car then drive car. The SSL and the want seem to correspond in shunting SSL or NOTSSL. What might correspond to the implied double-if (i.e., just how conditional is the conditional?) and want (i.e., single or double state of if?) may differ in versions. The nesting is simple, maybe it shouldn't be simple, for the sake of version.
The solution seems almost counterintutitive in a way, in flipping the sequence. He said, "I forgot to add that I don't use ssl," and then flipping the sequence brought about "now work on main domain and all multistores." You have SSL and the flipped sequence accordingly shouldn't work except for the if else being affected by the SSL or NOTSSL. I'm not sure how to put it, so maybe this, "dumb idea" or not, will spark a thought. If car then drive car, else if truck then drive truck. If truck then drive truck else if car then drive car. If want drive car and if car then drive car else if truck then drive truck. If want drive truck and if truck then drive truck else if car then drive car. The SSL and the want seem to correspond in shunting SSL or NOTSSL. What might correspond to the implied double-if (i.e., just how conditional is the conditional?) and want (i.e., single or double state of if?) may differ in versions. The nesting is simple, maybe it shouldn't be simple, for the sake of version.
catalog/controller/common/seo_url.php
Lines 11-113
return $url_info['scheme'] . '://' . $url_info['host'] . (isset($url_info['port']) ? ':' . $url_info['port'] : '') . str_replace('/index.php', '', $url_info['path']) . $url . $query;
} else {
return $link;
If I remove this:
else {
return $link;
it sends me to the home page of my 2nd store which isn't what I want, but it makes me think that line of code needs to be altered. It does the same thing on store 1, so is there a way to differentiate $link between the two stores?
When I'm on store 2, this is the source code:
<base href="http://store2.domain.com/" /><link href="http://store1.domain.com/" rel="canonical" />
Lines 11-113
return $url_info['scheme'] . '://' . $url_info['host'] . (isset($url_info['port']) ? ':' . $url_info['port'] : '') . str_replace('/index.php', '', $url_info['path']) . $url . $query;
} else {
return $link;
If I remove this:
else {
return $link;
it sends me to the home page of my 2nd store which isn't what I want, but it makes me think that line of code needs to be altered. It does the same thing on store 1, so is there a way to differentiate $link between the two stores?
When I'm on store 2, this is the source code:
<base href="http://store2.domain.com/" /><link href="http://store1.domain.com/" rel="canonical" />
This account is inactive. Look for us under the name 'EvolveWebHosting' and contact us under that username.
Thanks!
Two quicky thoughts.
The
base href="http://store2
part suggests that maybe each one's .htaccess might be manipulable for the purpose, although since that part is pretty well working I would leave it alone for now before playing it against $link.
As I recall the $link is picked up dynamically anyway but if two counterparts, $link1 and $link2, were hard-coded to be picked up statically as-is, defined equivalent to store1 and store2, that might play against other wigglies and suggest something that works. I'd rather tinker with link than arg. I can see arg going to argh sooner than link.
The
base href="http://store2
part suggests that maybe each one's .htaccess might be manipulable for the purpose, although since that part is pretty well working I would leave it alone for now before playing it against $link.
As I recall the $link is picked up dynamically anyway but if two counterparts, $link1 and $link2, were hard-coded to be picked up statically as-is, defined equivalent to store1 and store2, that might play against other wigglies and suggest something that works. I'd rather tinker with link than arg. I can see arg going to argh sooner than link.
So I figured it out!!!!
There is NOTHING wrong with the OpenCart coding at all. I had OC installed in public_html/folder/ and as soon as I moved everything from there to public_html and edited my config files, it worked!
DL
There is NOTHING wrong with the OpenCart coding at all. I had OC installed in public_html/folder/ and as soon as I moved everything from there to public_html and edited my config files, it worked!
DL
This account is inactive. Look for us under the name 'EvolveWebHosting' and contact us under that username.
Thanks!
Good! That puts one of them in the driver's seat over the other(s). The OC code itself was always okay, but there are inevitably situations it will not anticipate, and the trick was relative to the SSL and the nesting. Above, "Geometry.-- Is the arrangement in effect a V or a lopsided Y?" Was V, now is lopsided Y.
The only thing wrong is the canonical for the 2nd store. It shows the first stores domain..... gonna have to get that figured out.
DL
DL
This account is inactive. Look for us under the name 'EvolveWebHosting' and contact us under that username.
Thanks!
Since "the first" subdomain is http://www., that adds subtleties that are easily either overlooked or given just a wee tad less attention than they will demand. The SSL context is unforgiving, in the same maddening way that a keyboard does exactly what one told it.
Who is online
Users browsing this forum: No registered users and 12 guests
