MultiSite Module Support Thread

And if anyone is still reading v1.3 compatible with zc158 is now available ...

https://www.zen-cart.com/downloads.php?do=file&id=378

Throughout the history of this plugin the shopping cart has not been distinct between your shops - ie you could put some items in your cart in shop 1, logout, login to shop 2 and they'll still be there.

The original author saw this as a positive and even created the 'site links' to promote your shops to each other.

However this might not suit everyone - for example you might have a business model where each shop represents a geographical region and items are hand delivered - and the product range and pricing may vary.

From personal experience I've had users exploit this loophole to gain a cheaper price or attempt to buy a product that isn't actually available.

So v1.3.1 now offers the option to make the shopping cart distinct to each of your shops

This is the only change since 1.3 - so don't bother installing if you have it running and don't require this feature.

https://www.zen-cart.com/downloads.php?do=file&id=378

Nice feature, @royaldave. I no longer have clients that use this plugin, but those that do will find that useful.

lat9:

Nice feature, @royaldave. I no longer have clients that use this plugin, but those that do will find that useful.

thanks, i've been needing this for a while...

V1.4 now available.

https://www.zen-cart.com/downloads.php?do=file&id=378

It's specifically for zen cart 2.0.1, and also contains support for the bootstrap template.

If you're not ready to upgrade to zen cart 2 then ignore this update - it offers no new functionality over v1.3.1 (except for the bootstrap bit which is minor).

Tested with php 8.2 & 8.3.

royaldave:

V1.4 now available.

https://www.zen-cart.com/downloads.php?do=file&id=378

It's specifically for zen cart 2.0.1, and also contains support for the bootstrap template.

If you're not ready to upgrade to zen cart 2 then ignore this update - it offers no new functionality over v1.3.1 (except for the bootstrap bit which is minor).

Tested with php 8.2 & 8.3.

It is been awhile since i used this mod. With the new update, I thought about using it again to make things easier to manage.

However, I don t remember how do you ( if still possible) specify a different method of payment for each site:

Site 1 = Paypal
site 2 = Square
....

How do you achieve this?

Thank you

nicksab:

It is been awhile since i used this mod. With the new update, I thought about using it again to make things easier to manage.

However, I don t remember how do you ( if still possible) specify a different method of payment for each site:

Site 1 = Paypal
site 2 = Square
....

How do you achieve this?

Thank you

Turn on both payment modules in admin, but then in the shop where you don't want paypal, in the config file for it add a line -

define('MODULE_PAYMENT_PAYPAL_STATUS','false');

and in the other one

define('MODULE_PAYMENT_SQ_WEBPAY_STATUS','false');

BTW I never considered doing this before and it's not in the documentation so I will amend to include an example such as this.

Also I discovered a bug in the shopping_cart.php of the latest release so will be submitting an update shortly - this only affects the zc 2.0.1 version.

If you are one of the two people who've downloaded 1.4 please pm me for a copy of the file if you can't wait for the resubmitted version to show up.

Is the module on github?
Then you could link to the commit.

royaldave:

Turn on both payment modules in admin, but then in the shop where you don't want paypal, in the config file for it add a line -

define('MODULE_PAYMENT_PAYPAL_STATUS','false');

and in the other one

define('MODULE_PAYMENT_SQ_WEBPAY_STATUS','false');

Awesome

Thank you very much

Shop Suey:

Is the module on github?
Then you could link to the commit.

I think it is on github, but I'm not - if that matters.

I need to my head around it one day.

Hello, I've been using this module since version 1.0 and I'm doing an update from 1.5.5 to 2.1

The logs will show an error unless I change the line 29 of admin/multisite.php

from this:

while($multisite_cat_desc[0]=="\n") {

to this:

while (!empty($multisite_cat_desc) && $multisite_cat_desc[0] == "\n") {

Also, when assigning categories on the MultiSite Tool, I have a ">->-" before the name of the site assigned. In the previous version, those symbols didn't appear there. Is there a way to get rid of them?

ideasgirl:

Hello, I've been using this module since version 1.0 and I'm doing an update from 1.5.5 to 2.1

The logs will show an error unless I change the line 29 of admin/multisite.php

from this:

while($multisite_cat_desc[0]=="\n") {

> 
> to this:
> ```php
while (!empty($multisite_cat_desc) && $multisite_cat_desc[0] == "\n") {

Also, when assigning categories on the MultiSite Tool, I have a ">->-" before the name of the site assigned. In the previous version, those symbols didn't appear there. Is there a way to get rid of them?

Hi

I didn't write this plugin, although I have done the last couple of updates.

I'm very time poor of late and have not yet investigated how well this works under 2.1, that said I've acknowledged that the admin tool needs work in the documentation - it has been ignored for a very long time.

It is not essential to use this tool - you can manually update the category descriptions yourself and I'd recommend doing this until such time as myself (or somebody else) can fix it.

I've discovered a bit of a loophole in multisite you might want to be aware of.

Background -

I might be imagining things, but I swear until recently if I pressed the back button on chrome it would reload the page it was going back to.

In recent times I've noticed it doesn't do this anymore, it goes back to a cached page. I've noted this in particular when switching off redundant products, ie I might do a search that will bring up that product, I go into that product to get that product id, and after switching it off in admin and pressing back, the removed product is still visible on the search page.

I think this may have changed in recent chrome updates.

Anyway why is this relevant you ask? Actually it might not be, but in the last week or so customers have been able to order products they should not have been able to - ie they've managed to checkout products that were in a different shop. (I'm using the distinct shopping cart option so this should not be possible)

After having a bit of a play I worked out that if for example your viewing a category, eg -

https://www.xxx.com/zencart/index.php?main_page=index&cPath=26

and you change that cpath to a category that might be valid in one of your other shops then zencart will happily display it because this bypasses the cat_filter.

I'm guessing that recent browser updates might be allowing users to view a cached page that looks similar to one previously viewed. In any event I will look at how this can be tightened up.

And if you think i'm crazy please say so...

royaldave:

And if you think i'm crazy please say so...

It might have started... Seeing you now are advertising ######## site in ZC forum... :)))

pilou2:

It might have started... Seeing you now are advertising ######## site in ZC forum... :)))

oops. too late for me to edit too....

should've had my coffee first...

Regrardless of my sanity, I have a solution to the little loophole I found - whether it solves the browser issues or not I don't know as I haven't been able to replicate it.

So in particular if you're using the distinct shopping cart option of multisite you might want to add this code to includes/modules/pages/index/header_php.php - this will prevent manipulation of the url giving the user access to a category that shouldn't be available in the shop they're browsing.

//bof multisite
//check that a cPath from another store is not attempting to be used.
    if ($cPath > 0) {
      $categories_query = "SELECT c.categories_id, cd.categories_name, c.categories_image, c.parent_id
                         FROM   " . TABLE_CATEGORIES . " c, " . TABLE_CATEGORIES_DESCRIPTION . " cd
                         WHERE      c.categories_id = :parentID
                         AND        c.categories_id = cd.categories_id
                         AND        cd.language_id = :languagesID
                         AND        c.categories_status= '1'
                         ORDER BY   sort_order, cd.categories_name";

      $categories_query = $db->bindVars($categories_query, ':parentID', $cPath, 'integer');
      $categories_query = $db->bindVars($categories_query, ':languagesID', $_SESSION['languages_id'], 'integer');
      $category_status = $db->Execute(cat_filter($categories_query));
      if ($category_status->RecordCount() == '0') {
        $current_category_not_found = true;
      }
    }
//eof multisite

Put this in just above -

    // -----
    // Give an observer the chance to override the default handling for the category.
    //

royaldave:

I've discovered a bit of a loophole in multisite you might want to be aware of.

I'm guessing that recent browser updates might be allowing users to view a cached page that looks similar to one previously viewed. In any event I will look at how this can be tightened up.

And if you think i'm crazy please say so...

OK, i've discovered what the real problem is....

And it might depend on what your domain name is..

In my example I use multisite because I have geographic splits in my shop, so eg I've got perth.fb.com.au , adelaide.fb.com.au etc

If I google pokemon adelaide for example, and adelaide doesn't have it, but perth does, then google might yet give a result substituting the perth subdomain.

I think I'm affected by this because really I have one domain name and use subdomains for my shops - if you're using different domain names google might not do this.

Probably not many people affected by this, and if you're not using distinct shopping cart feature you probably don't care.

I'll have a think on the best way to approach solving this.

OK, if you are affected by this issue this is what you can do -

(this is for zencart 2.0.1)

in includes/functions/functions_products.php, edit the beginning of function zen_product_set_header_response as follows ....

function zen_product_set_header_response($product_id, $product_info = null)
{
//bof multisite
    global $zco_notifier, $breadcrumb, $robotsNoIndex, $db;
//eof multisite

    // make sure we got a dbResponse
    if ($product_info === null || !isset($product_info->EOF)) {
        $product_info = zen_get_product_details($product_id);
    }
    // make sure it's for the current product
    if (!isset($product_info->fields['products_id'], $product_info->fields['products_status']) || (int)$product_info->fields['products_id'] !== (int)$product_id) {
        $product_info = zen_get_product_details($product_id);
    }

    $response_code = 200;


    $product_not_found = $product_info->EOF;
    $should_throw_404 = $product_not_found;


//bof multisite - check product actually belongs to this site - this stops people fudging a product id from another of your shops into the url - or incorrect search engine results.
    if ($should_throw_404 === false) {
      $categories_query = "SELECT c.categories_id, c.categories_image, c.parent_id, cd.categories_description
                         FROM   " . TABLE_CATEGORIES . " c, " . TABLE_CATEGORIES_DESCRIPTION . " cd 
                         WHERE      c.categories_id = " . $product_info->fields['master_categories_id'] . "
                         AND        c.categories_id = cd.categories_id
                         AND        c.categories_status= '1'
                         ORDER BY   sort_order";

      $categories = $db->Execute(cat_filter($categories_query));
      if ($categories->RecordCount() == 0) { $should_throw_404 = true; }
    }
//eof multisite

    if ($should_throw_404 === true) {
        $response_code = 404;
    }

further to this, never seen this issue before in 10 years or so of using multisite with zen cart - but have had users able to buy the wrong products from the wrong shop numerous times in the last 2 months or so. I feel google has amended its algorithm in some respect for subdomains which has caused this - that said it had exposed a loophole in multisite that could be exploited. i'm no seo expert but if you are splitting your multisites over subdomains you may want to see if there's a better way of doing things because the reality is google will be displaying false results. at least the user will get to your site, be shown product not found, and if they have a brain they will look for something else within your site.