Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Multiwebsite broken in 2.1.9 on CentOS 6.9 with RH-SCL PHP 7.0.10 #10892

Closed
thomvanderboon opened this issue Sep 15, 2017 · 7 comments
Closed

Multiwebsite broken in 2.1.9 on CentOS 6.9 with RH-SCL PHP 7.0.10 #10892

thomvanderboon opened this issue Sep 15, 2017 · 7 comments
Labels
Issue: Clear Description Gate 2 Passed. Manual verification of the issue description passed Issue: Format is valid Gate 1 Passed. Automatic verification of issue format passed

Comments

@thomvanderboon
Copy link

thomvanderboon commented Sep 15, 2017 •
edited
Loading

After update to 2.1.9 the multiwebsite functionality is broken.

Preconditions

  1. Running 2.1.8 with multiple websites (one installation, multiple websites)
  2. CentOS 6.9
  3. MariaDB 10.2
  4. SCL PHP 7.0.2

Steps to reproduce

  1. Update to 2.1.9
  2. Modify the index.php to facilitate multiple websites:
<?php
/**
 * Application entry point
 *
 * Example - run a particular store or website:
 * --------------------------------------------
 * require __DIR__ . '/app/bootstrap.php';
 * $params = $_SERVER;
 * $params[\Magento\Store\Model\StoreManager::PARAM_RUN_CODE] = 'website2';
 * $params[\Magento\Store\Model\StoreManager::PARAM_RUN_TYPE] = 'website';
 * $bootstrap = \Magento\Framework\App\Bootstrap::create(BP, $params);
 * \/** @var \Magento\Framework\App\Http $app *\/
 * $app = $bootstrap->createApplication('Magento\Framework\App\Http');
 * $bootstrap->run($app);
 * --------------------------------------------
 *
 * Copyright © 2015 Magento. All rights reserved.
 * See COPYING.txt for license details.
 */

try {
    require __DIR__ . '/app/bootstrap.php';
} catch (\Exception $e) {
    echo <<<HTML
<div style="font:12px/1.35em arial, helvetica, sans-serif;">
    <div style="margin:0 0 25px 0; border-bottom:1px solid #ccc;">
        <h3 style="margin:0;font-size:1.7em;font-weight:normal;text-transform:none;text-align:left;color:#2f2f2f;">
        Autoload error</h3>
    </div>
    <p>{$e->getMessage()}</p>
</div>
HTML;
    exit(1);
}

$params = $_SERVER;
$myserverstring = $_SERVER['SERVER_NAME'];

$pos = strpos($myserverstring, 'myfantasticwebsite.com');
if ($pos !== false) {
  $params[\Magento\Store\Model\StoreManager::PARAM_RUN_CODE] = 'fantastic';
  $params[\Magento\Store\Model\StoreManager::PARAM_RUN_TYPE] = 'website';
}
$bootstrap = \Magento\Framework\App\Bootstrap::create(BP, $params);
/** @var \Magento\Framework\App\Http $app */
$app = $bootstrap->createApplication('Magento\Framework\App\Http');
$bootstrap->run($app);

Expected result

  1. Show the requested website

Actual result

  1. Show the default website
@magento-engcom-team magento-engcom-team added the Issue: Format is valid Gate 1 Passed. Automatic verification of issue format passed label Sep 15, 2017
@korostii
Copy link
Contributor

Wow, that's big. Can anyone else confirm this issue?

@hostep
Copy link
Contributor

hostep commented Sep 16, 2017

Hmm, just out of curiosity I tested this on a shop we maintain with multiple domainnames and websites where we also changed the pub/index.php file and manipulate the $params in the same way @thomvanderboon is doing.

Results:

  • Upgraded from 2.1.7 => 2.1.8: no problem
  • Upgraded from 2.1.8 => 2.1.9: no problem

@thomvanderboon: can you double check if your index.php or pub/index.php is still correct, because every time you upgrade Magento using composer, it will rewrite that file, so be sure your code is still in there.

If this still doesn't help, please test with a clean Magento 2.1.9 installation and try to provide more details about every step you have taken, so the support people can reproduce your issue.

(Just for completeness sake: we have patched some parts of Magento to make multiple domains work correctly, because there are bugs in a vanilla Magento installation where it writes the incorrect storecode to the cookies, which I explained over here)

@thomvanderboon
Copy link
Author

I checked it.... my index.php was correct. It looks like it is something platform specific to CentOS 6.9 + RH-SCL PHP 7.0.10.

Tested on Ubuntu 16.04 LTS (PHP 7.0.22) and upgrade 2.1.8 -> 2.1.9 of multi store shop works without problems

@thomvanderboon thomvanderboon changed the title Multiwebsite broken in 2.1.9 Multiwebsite broken in 2.1.9 on CentOS 6.9 with RH-SCL PHP 7.0.10 Sep 17, 2017
@hostep
Copy link
Contributor

hostep commented Sep 17, 2017

@thomvanderboon: it might be something different in the webserver setup and/or configuration, I don't think a different php version can cause this problem.

@thomvanderboon
Copy link
Author

@hostep I copied the apache config from the CentOS vm to the Ubuntu vm (both running apache 2.4) so difference in webserver setup is quite unlikely. PHP more likely,

I am currently creating a fresh vm with the CentOS setup for further testing.

@magento-engcom-team magento-engcom-team added the Issue: Clear Description Gate 2 Passed. Manual verification of the issue description passed label Sep 21, 2017
@thomvanderboon
Copy link
Author

After quite some testing over the last month, I came to the conclusion that this issue is moste likely opcache related. If you run opcache with the settings which are recommended, a edited index.php is only picked up after restart of the webserver.

@hostep
Copy link
Contributor

hostep commented Nov 6, 2017 •
edited
Loading

@thomvanderboon: you're probably talking about these settings: http://devdocs.magento.com/guides/v2.2/config-guide/prod/prod_perf-optimize.html?

And the problem is then probably caused by the setting opcache.validate_timestamps=0.
Just a hint, everytime you change a (php) file, it's best if you clear the opcache, using a function call like this: opcache_reset(); using a webserver request, don't perform this call on the cli as it might clear the wrong cache.
Best is to do this in an automated script during the deploy.

This might help in your case :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Issue: Clear Description Gate 2 Passed. Manual verification of the issue description passed Issue: Format is valid Gate 1 Passed. Automatic verification of issue format passed
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@hostep @thomvanderboon @korostii @magento-engcom-team