magento2: Constant critical errors in system.log

Critical errors constantly logged in var/log/system.log:

[2016-02-22 14:36:09] main.CRITICAL: Broken reference: the 'header' tries to reorder itself towards 'global.notices', but their parents are different: 'page.wrapper' and 'notices.wrapper' respectively. [] []
[2016-02-22 14:36:09] main.CRITICAL: Broken reference: the 'page.breadcrumbs' tries to reorder itself towards 'notifications', but their parents are different: 'page.wrapper' and 'notices.wrapper' respectively. [] []
[2016-02-22 14:36:09] main.CRITICAL: Broken reference: the 'global.search' tries to reorder itself towards 'notification.messages', but their parents are different: 'header.inner.right' and 'header' respectively. [] []
...
[2016-02-22 14:39:46] main.CRITICAL: Broken reference: the 'catalog.compare.sidebar' element cannot be added as child to 'sidebar.additional', because the latter doesn't exist [] []
[2016-02-22 14:39:46] main.CRITICAL: Broken reference: the 'sale.reorder.sidebar' element cannot be added as child to 'sidebar.additional', because the latter doesn't exist [] []
[2016-02-22 14:39:46] main.CRITICAL: Broken reference: the 'wishlist_sidebar' element cannot be added as child to 'sidebar.additional', because the latter doesn't exist [] []
[2016-02-22 14:39:46] main.CRITICAL: Broken reference: the 'paypal.partner.right.logo' element cannot be added as child to 'sidebar.additional', because the latter doesn't exist [] []
[2016-02-22 14:39:46] main.CRITICAL: Broken reference: the 'bml.right.logo' element cannot be added as child to 'sidebar.additional', because the latter doesn't exist [] []
[2016-02-22 14:39:46] main.CRITICAL: Broken reference: the 'store.settings.currency' tries to reorder itself towards 'store_language', but their parents are different: 'store.settings' and 'header.panel' respectively. [] []
...
[2016-02-22 14:40:18] main.CRITICAL: Broken reference: the 'store.settings.currency' tries to reorder itself towards 'store_language', but their parents are different: 'store.settings' and 'header.panel' respectively. [] []

From what I can tell - it happens from both adminhtml and frontend. Magento version 2.0.2 with default theme and pretty much default setup(except 3 store views and couple of products imported).

About this issue

Original URL
State: closed
Created 8 years ago
Reactions: 6
Comments: 59 (13 by maintainers)

Links to this issue

Most upvoted comments

It’s worth noting that there are two distinct problems here. The first: Magento ships with code that triggers these CRITICAL log messages. I just installed Magento CE 2.1.4 via the composer create-project method, turned on developed mode, and when I load and then refresh the admin page, I get the following in my logs

[2017-02-14 16:59:25] main.CRITICAL: Broken reference: the 'header' tries to reorder itself towards 'global.notices', but their parents are different: 'page.wrapper' and 'notices.wrapper' respectively. [] []
[2017-02-14 16:59:25] main.CRITICAL: Broken reference: the 'page.breadcrumbs' tries to reorder itself towards 'notifications', but their parents are different: 'page.wrapper' and 'notices.wrapper' respectively. [] []
[2017-02-14 16:59:25] main.CRITICAL: Broken reference: the 'global.search' tries to reorder itself towards 'notification.messages', but their parents are different: 'header.inner.right' and 'header' respectively. [] []

Magento shouldn’t ship with code that drop critical warnings in the logs immediately after a fresh install with no third party extensions.

The second problem here is third party code that introduces layout rules that cause similar problems. Some of the previous comments in this thread send the message that since Magento Inc. can’t control what other people do, that this isn’t worth pursuing. While that’s certainly a problem, until Magento fixes the initial problem (the default themes ship with layout rules that trigger these error), third party developers will have zero incentive to fix these problems in their own module. That’s probably where the initial effort should go.

It would also be nice if people could tell folks like @thdoan that the problem they’re seeing in the admin console is probably not related to these specific errors, but instead related to something else that may not be logged. Also also, fixing the problem with the dirty logs means folks like @thdoan will have clean logs and be less likely to attribute an unrelated admin error to problems with the structure of their layout handle XML files.

/cc @maksek @piotrekkaminski

+11

astorm on Feb 14, 2017

Please reopen, it is obviously not fixed.

mattcoz on Dec 2, 2016

@piotrekkaminski - Please re-open this; it’s still a pervasive problem for a large number of users (including every one of my client instances)

Morgon on Nov 18, 2016

Ok, guys. There is no bug here ) Really. There are two reasons, why you all see such a logs.

Reason 1 People keep forgetting remove “before” and “after” attributes for blocks which have been moved to another parent, so those are no longer relevant. Internal ticket in progress MAGETWO-53410 and we will clean up legacy references soon.

Reason 2 As an example, let’s take <referenceContainer name="sidebar.additional"> Such references mostly (if not all) reside in default.xml files (so will be applied to all pages without exclusions), while the container "sidebar.additional” is added by 2columns-left.xml layout only. So, on pages where different page layout is used, the reference will lead to nowhere, and you will see CRITICAL error logged (while it is not critical at all).

The tricky thing is that sometimes that could be a normal case and developer understands why it happens (if want to add a block to specific container to all pages on which target container available, and don’t need that block to be added to the pages where target container is not available).

Short excerpt from internal ticket description: “Stop logging such cases at all, or at least stop marking them as CRITICAL (ensure that it’s not logged in production mode). Also it will be helpful if logged message will say the URL of the page where target container is missed”.

So, as you see, we still think that logging such “broken” references is a right thing to do, since some of them are really could be caused by misspells in layout files.

vkorotun on May 24, 2016

Reopened for review.

maksek on Feb 13, 2017

Please get this fixed! It’s very difficult to detect real problems in the logs when it’s spammed with things that can be ignored. @astorm is absolutely right, how can Magento report many CRITICAL errors right out of the box after a fresh install?

pantaoran on Feb 17, 2017

I totally agree, these messages should have been fixed a long time ago. Get it fixed Magento. It’s over 1 year since release!

csdougliss on Feb 15, 2017

definitively usefull having the url in order to investigate what is the real issue thanks

springerin on May 24, 2016

@magento-team Please take a look at this. It creates bloated system logs and creates so much noise it’s impossible to tell what are real errors and which ones are not.

Ctucker9233 on Mar 24, 2017

@PaulodoPorto @haitaoseven TL;DR: these log entries are not that critical in fact and are present even in vanilla Magento installation without any customizations. Thus they do not mean anything works wrong in your store.

Proper implementation approach to fix this problem is described here: https://github.com/magento/magento2/issues/5627#issuecomment-279440749

This is something that should be fixed on Magento Team side, or at least enforced on CI as I described and then announced as 'up for grabs'. I did not try to fix by myself but I doubt that simple patch eliminating all such problems even exist, most of the problems are caused by wrong layout XML files.

orlangur on Mar 7, 2017

Great answer, @astorm ! Long story short, this issue should’ve been marked as acknowledged long time ago by Magento team.

pguedesbr on Feb 14, 2017