14

In our Multiwebsite / Multistore(view) Magento 1.9.2.2 configuration one of the websites, including it's store and storeview had to be removed.

While the removal itself went fine (I've done this before), I've ended up with a backend that 404's if you change your Current Configuration Scope to any but two Websites.

Selecting a new Configuration Scope results in a request for the following url (admin path + key are changed):

/index.php/mymageadmin/system_config/edit/section/dev/website/<WEBSITE>/key/1221231/

where <WEBSITE> is equal to the code field in core_website table.

With mysql query logging on I see that the two websites that can be loaded successfully have these queries in regards to selecting the website/storeview:

SELECT `main_table`.* FROM `core_config_data` AS `main_table` WHERE (`scope` = 'websites') AND (`scope_id` = '4') AND (`path` LIKE 'dev/%')
SELECT `core_website`.* FROM `core_website` WHERE (`core_website`.`code`='working_store_code')

Other websites that give a 404 start with the same first query - but of course a different scope_id, but in the second query Magento thinks it has to look for a scope storeview instead of website! It actually seems to try twice.

SELECT `main_table`.* FROM `core_config_data` AS `main_table` WHERE (`scope` = 'websites') AND (`scope_id` = '3') AND (`path` LIKE 'dev/%')
SELECT `core_store`.* FROM `core_store` WHERE (`core_store`.`store_id`=3) ORDER BY `sort_order` ASC
SELECT `core_store`.* FROM `core_store` WHERE (`core_store`.`store_id`=3) ORDER BY `sort_order` ASC

My core_website table looks as follows:

website_id code           sort_order     default_group_id  is_default
0          admin          0              0                 0
1          working_one    1              1                 1
3          failing_one    2              4                 0
4          working_two    3              9                 0
6          failing_two    4              16                0
7          failing_three  5              15                0
8          failing_four   6              17                0
9          failing_six    7              18                0

working_xxx = these load OK, failing_xxx = these give a 404 / try to select a non-existing store_id.

My core_store table looks as follows: (code + name removed as not relevant)

store_id website_id group_id sort_order is_active
0        0          0        0          1
1        1          1        0          1
4        3          4        1          1
5        3          4        2          1
10       4          9        0          1
19       7          15       0          1
20       4          9        1          1
21       4          9        2          1
22       4          9        4          0
23       6          16       1          1
24       6          16       2          1
26       4          9        4          1
28       7          15       0          1
29       1          1        2          1
30       8          17       0          1
31       9          18       0          1
32       9          18       0          1
33       8          17       2          1
34       8          17       3          1
35       8          17       4          1
36       4          9        10         1

And this is core_store_group:

group_id website_id name            root_cat_id default_store_id
1        1          working_one     50          1
4        3          failing_one     44          4
9        4          working_one     77          10
15       7          failing_two     70          19
16       6          failing_three   46          23
17       8          failing_four    50          30
18       9          failing_five    96          31

I have compared these three tables to my backup copy of the DB before I removed the website/storeview and -except for the removal of said website/storeview- everything looks exactly the same. Same ID's, same codes etc.

As far as I know these three tables are the only ones that are checked by Magento for storeview/website code and ID's.

As for troubleshooting I've done the following: To ensure no caches with old configuration where left: emptied var/cache, flushed caches, reindexed, rebooted the server etc, all to no avail.

Even with all php/magento logging on, developer mode etc, I get zero clues as to why this is happening. No exceptions are logged.

So the two questions are: Why is Magento trying to select a non-existent storeview scope instead of the website scope and how to fix this?

Update 1 / Workaround

After a long day of troubleshooting, including but not limited to the magento-db-repair tool, recreating core_store, core_store_group and core_website tables, with all original websites and store views I finally noticed the following:

For all website_id that load fine there is a store_id with the same number. website_id 1 and 4 are loading as expected, and indeed there are (unrelated) store_id 1 and 4 defined.

For website_id 3, 6,7,8 and 9 there is no store_id with the same number.

However, once I created a fake entry into store_id, for instance 3, loading the Configuration Scope of website_id 3 started working again.

So while I have now successfully put a workaround in place, I did end up with one extra (disabled) website and 5 (disabled) store views....

To be sure this wasn't a problem before, I went to one of the older copies of our site that I keep on my dev server (magento version 1.9.1.0).

Here everything works perfectly, i.e. website_id 6 loads without needing a store_id 6 in the core_store table.

  • I have to ask, have you ran URL indexing when you changed everything? – Anthony Cicchelli Mar 19 '16 at 17:33
  • Hey @AnthonyCicchelli, thanks for asking. This was actually one of the first things I tried to resolve the issue, but to no avail :( – Ottonet Mar 19 '16 at 17:35
  • It's hard to tell from here as there is a lot of factors, have you flushed all your URL from the DB and re run the URL. Sounds linked based to me.Be VERY Careful working directly with the DB like that above. Make sure you have a backup otherwise it could break everything. – Anthony Cicchelli Mar 19 '16 at 17:39
  • I'm pretty sure it's not a "frontend" issue (e.g. URL-index), but more a "backend" issue, somewhere deep in the magento code. To me it feels like Magento expects a certain sequence/combination of website_id/store_id, where if you remove some id's "in the middle", magento is unable to match and load those website_id's. – Ottonet Mar 19 '16 at 17:48
2

I had similar issue on single-website store, and solved with the following query.

SET SQL_SAFE_UPDATES=0;
SET FOREIGN_KEY_CHECKS=0;
UPDATE `core_store` SET store_id = 0 WHERE code='admin';
UPDATE `core_store_group` SET group_id = 0 WHERE name='Default';
UPDATE `core_website` SET website_id = 0 WHERE code='admin';
UPDATE `customer_group` SET customer_group_id = 0 WHERE customer_group_code='NOT LOGGED IN';
SET FOREIGN_KEY_CHECKS=1;
SET SQL_SAFE_UPDATES=1;

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.