Extending Layout .xml files not working in child theme in different <vendor> as to parent theme: Magento 2.0.4.

[shashankitsoft]

Root cause description

Steps to reproduce

1. Add a theme to app/design/frontend folder (i.e. clone https://github.com/sivaschenko/magento2-sample-theme to app/design/frontend/Sivaschenko/default/)
2. Login to Admin panel (or just reload the admin panel page)
3. select * from theme to ensure theme is added to the database (type is 0 as it is a physical theme)
4. Remove the theme files/folder
5. Reload the admin panel page
6. select * from theme (type for the theme is now changed to 1 - virtual theme)
7. Return the theme files back
8. Reload the admin panel page
9. select * from theme

Actual Result

type for the theme is still 1 - virtual theme

Expected Result

type for the theme should be 0 - it's a physical theme

Issue description

Summary (*)

1. Install Magento 2.0.4 on WAMP server 3.0 , Windows 10 Pro - 32bit, PHP 5.6.15, MySQL 5.7.9
2. Created a child theme themeparent of Magento_blank in app\design\frontend*Vendor1*\themeparent with several layout xml files for extending, along with template .phtml files. Activated from admin. Working Fine.
   theme.xml => <parent>Magento/blank</parent>
3. Created another child theme themechild of above theme themeparent (which is itself the child of magento blank). This childtheme is created in different vendor folder, i.e. Vendor2
   This theme path is app\design\frontend*Vendor2*\themechild . Created layout .xml file inside to extend its parent theme layout. Activated this second level child theme from admin. The .xml files not even processed. Not working.
   theme.xml => <parent>Vendor1/themeparent</parent>

3b. Although template .phtml files or .css files existing in childtheme are working fine if corresponding layout containers/blocks called in from the Vendor1\themeparent layout files.

1. If for a test, the same child theme childtheme put inside same vendor of its parent i.e. Vendor1 , the theme path becomes app\design\frontend*Vendor1*\themechild and then the same layout .xml files works fine.

Already tried with clearing public/static and var folders. Also, tried after running with cli commands
php bin/magento setup:static-content:deploy
php bin/magento indexer:reindex
php bin/magento setup:upgrade

But nothing solved it.

Examples (*)

The required theme inheritance is in this way:
Magento_blank => Vendor1_themeparent => Vendor2_childtheme . (note vendor differ)
Layout .xml fail to load in childtheme.

But if for a test, inheritance made this way:
Magento_blank => Vendor1_themeparent => Vendor1_childtheme . (note vendor same)
Layout .xml load properly and work fine in childtheme.

As per Magento 2 guidelines on http://devdocs.magento.com/guides/v2.0/frontend-dev-guide/themes/theme-inherit.html#set-a-parent-theme it is clearly mentioned that "A parent and a child theme can belong to different vendors. For example, your custom theme can inherit from the Magento Blank theme." . So, if I am creating a second level child theme (in vendor 2) from a parent theme (in vendor 1) which is a child of Magento_blank (vendor: Magento), this should ideally work fine. But its not happening. None of the layout .xml files processed to output if they are under different vendors. If I put both themes in same vendor, they are working fine.

Actual result

Extending layout .xml files in the 2nd level child theme in different vendor folder is not working.

Proposed solution

Why Magento 2.0.4 not working properly for 2 level theme inheritance with different vendor names?
This is a serious issue, as if you suppose purchased a paid theme from somewhere (which they have created by inheriting Magento_blank), and now you want to create your child theme of that paid theme but in different vendorname folder (obviously under your companyname), you will not able to do so!
You have only two choices left, either make your child theme inside their vendor name; or edit their theme .xml files to call your child theme template files or .css/.js (if in ur vendorname); the second case will obviously loose updates, weird way and not recommended.

Then what is the solution??

[odubovyk]

When trying to reproduce the issue in the ticket #4274, we tested it the way you described in current ticket (each theme with different vendor name). As we mentioned in referenced issue, we could not reproduce the issue.
Maybe you will find our attachment useful. The are two dummy themes configured as you described.
Each theme outputs a stripe on page with the theme name on it.
frontend.zip

[shashankitsoft]

Hi, Thank you very much for giving me the sample code. I have checked it on same installation and it worked!
I was amazed, matched the way to what I have done in my themes; your and my way both exactly same. Again activated my childtheme, and surprisingly it not worked. More surprised and fedup. :(

Then I digged into the magento database, and I found out one amazing thing. In the 'theme' mysql table of magento database, somehow the 'type' column corresponding to my childtheme had value set as '1' and all others were set '0'. Under suspicion, I tried to find what it means by comment in table column name which shows..

0 => Physical
1 => Virtual
2 => Staging

I guessed it may be a reason, and manually set the 'type' column value to 0 corresponding to my childtheme. Cleared var and public/static folders. Re-tested, and voila! it worked!!

This small issue has wasted my 4-5 days, with no solution. Even deactivation-activation or switching themes from admin was not resetting its value to 0 (it always remained 1) and so it never worked.

For a cross check to confirm, I deleted that row from database theme table, and reinstalled the theme, ran php bin/magento setup:upgrade, and now its setting the value to 0, which is perfect and working automatically.

Don't know how it was set to 1 and when.

Anyways, the issue is solved now, and

I found a very tiny thing but a VERY BIG thing

, which can waste every developers time if not known.
But, surprisingly this silly point is no where mentioned on the internet and not even on the magento documentation, which must be there.
Hope this explanation and solution will help more people later who are getting frustrated with the same issue. :)

Thanks.

[odubovyk]

Hi, shashankitsoft, we are glad that the sample code helped you a lot. And we are sorry that it took so much of your time and efforts. Thank you for the explanation, it will be passed to the team responsible for themes.

[piotrekkaminski]

I'm closing it for now. If someone can find a way to reproduce the issue, please notify me to reopen.

[firestorm23]

I guess I found what was the problem.

If you have your theme fresh installed e.g.

1. You placed your theme in the app/design/frontend dir
2. You entered admin section with Design configs
3. This time themes are checked and this particular class engaging theme register

https://github.com/magento/magento2/blob/6ea7d2d85cded3fa0fbcf4e7aa0dcd4edbf568a6/app/code/Magento/Theme/Model/Theme/Registration.php

4. Because themes exist both in code and in Database, described class checkes if theme fetched from Database exist in files.
5. If it does - Type of theme set as 0 => Physical
6. If it's not - Type of theme set as 1 => Virtual

The problem is that if theme is set as Virtual, for example you temporary removed theme directory from app/design/frontend, it's cannot be set again as Physical and you can see it in described class code

So if you removed theme files from app/design/frontend and returned it there after some operations, or if you did some stuff that could re-register your theme - check the type field in the database.

By myself, I'd say that this is very unsafe to set those type of field, which could affect frontend rendering according to file operations done by site developers and not documenting it, nor giving any recommendations or warnings that theme is set to Virtual. I mean, really? This field exist in database and can cause serious problems, without any documenting or warnings.

[krzysztofkacela]

@shashankitsoft Thank you. Had same problem. It's look like on updating magento it removed theme and set it as 'virtual'. So when I've added back my theme it was not reading xml files.
You saved my time and hairs ;)

[shoshweb]

I've got this same issue. And actually, the one thing I haven't done is change the setting to/from virtual. I don't know if this is best practice tho?
Hmm.
I'm a bit desperate to get this sorted out. Any fresh ideas?

[shashankitsoft]

@shoshweb Do it, as I have found and already suggested. Change virtual to physical, . It will be solved.

[shoshweb]

Thank you so much.
Would you be able to give me a little description on how to do that? Or point me to somewhere that describes how?
And thank you Shashankitsoft!

[shashankitsoft]

@shoshweb You should have red this post comments first before asking again, its already there.
Anyways, #4330 (comment)

[shoshweb]

Um. lol.. I did read it.
It's not enough information for me.
Do you know where I can find more information about how to change 'type' column corresponding to my child theme? I had a look in phpmyadmin - I cant find a type table nor my child theme.. but I may not know how to look.
I am not as advanced as you and need a few clues.
Thanks.

[shashankitsoft]

@shoshweb 'type' is column name, table name is => 'theme', already mentioned. Reading plain english doesn't need advanced user.

[shoshweb]

I'm always quite put off about writing on here, It's like a rule to be rude first and ruder later. Odd.

[Ctucker9233]

@shoshweb I'll help you out. Go into phpMyAdmin. Click on the name of your database. You should see a search bar. Search for theme. Sometimes you have to click on the results to see the results. Click on the one that has _theme in the name. Click on that file. Once the table is loaded, look at the "type" column. That's the column you want to edit. There should be an edit button or link at the beginning of the row. Click that and you will be able to edit that column. Hope this clarifies what you need to know.

[typotraum]

I wasted only 2 days! -> set 1 to 0 -> everything works fine! There should be a hint in the official magento docs. Or is there a hidden switch where you can set this value in the magento backend?

[vdmtrv]

@piotrekkaminski is there a commit related to this bug in 2.3-develop? This is still an annoying issue in 2.2.2

[danemacmillan]

@firestorm23 's description is very on point.

Also, this issue is not fixed, and I'm using 2.2.4.

It's very easy to reproduce. Take my example:

1. Install a fresh version of M2 with empty DB, which M2 will then populate with schema data.
2. Install various physical themes.
3. Delete the entire codebase, keeping the DB intact. For various reasons, this can happen, like when migrating data to a fresh server, or development.
4. Install a fresh version of the M2 codebase, pointing to that DB with all the newly created schema (and those themes added, with type:0), and run the standard magento setup:install.
5. Note that the Magento install works, however the custom theme codebases have not been added yet, which means those once-physical custom themes are now virtual types.

Steps 5 happens in the Magento_Theme module, which is executed during the setup:install command. The method responsible for setting the the physical theme to a virtual theme is: https://github.com/magento/magento2/blob/2.2-develop/app/code/Magento/Theme/Model/Theme/Registration.php#L160

[KevinGimbel]

I'd like to add that we experienced the same issue with Magento 2.2.6 lately.

We were migrating a system to a new server and somehow during the installation the "main" theme was set to type = 1 in the database which effectively made it unusable and resulted in us spending quite some time debugging because it looked like only half of our changes were applied since we inherit from a parent theme.

[maierb]

Bump for 2.2.x release fix?

[magento-engcom-team]

Hi @engcom-backlog-tomash. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: 👇

• 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).

  Details

  If the issue has a valid description, the label Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.

• 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.

• 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• 4. Verify that the issue is reproducible on 2.3-develop branch

  Details

  - Add the comment @magento-engcom-team give me 2.3-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.3-develop branch, please, add the label Reproduced on 2.3.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!

• 5. Verify that the issue is reproducible on 2.2-develop branch.

  Details

  - Add the comment @magento-engcom-team give me 2.2-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.2-develop branch, please add the label Reproduced on 2.2.x

• 6. Add label Issue: Confirmed once verification is complete.

• 7. Make sure that automatic system confirms that report has been added to the backlog.

[magento-engcom-team]

Hi @engcom-backlog-nazar. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: 👇

• 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).

  Details

  If the issue has a valid description, the label Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.

• 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.

• 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• 4. Verify that the issue is reproducible on 2.3-develop branch

  Details

  - Add the comment @magento-engcom-team give me 2.3-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.3-develop branch, please, add the label Reproduced on 2.3.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!

• 5. Verify that the issue is reproducible on 2.2-develop branch.

  Details

  - Add the comment @magento-engcom-team give me 2.2-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.2-develop branch, please add the label Reproduced on 2.2.x

• 6. Add label Issue: Confirmed once verification is complete.

• 7. Make sure that automatic system confirms that report has been added to the backlog.

[moni921]

We faced similar issue after upgrading to magento 2.4. We replaced value to 0 in table and theme started showing. However now header is missing in child theme. It is coming in parent theme.

Please let me know if there can be a fix for it

[kerlama]

We faced similar issue after upgrading to magento 2.4. We replaced value to 0 in table and theme started showing. However now header is missing in child theme. It is coming in parent theme.

Please let me know if there can be a fix for it

Same here, upgraded from 2.3.5-p2 and still, layouts are loaded from parent.

[sivaschenko]

Added root cause steps, actual and expected result to the description

[ioweb-gr]

I think the issue I'm experiencing is also related to this issue. On 2.4.1 I'm facing an issue where I can't override the default_head_blocks.xml in a Child of a Child theme.

E.g.

Vendor1
----Theme

Vendor2
----Child of Vendor1_Theme (default_head_blocks.xml works here)
----Child of Vendor2 -> Vendor1_Theme (this one can't (default_head_blocks.xml doesn't work here)

I'm assigning the second child to a category and trying to load a custom css for that child theme only.

[almr]

@shashankitsoft Thank you very much you saved my days.

[stefanskotte]

So this is still an issue on 2.4.5-p1 - what gives ? - can it be fixed without having to modify the theme type in the db ?