Magento2: Magento EE 2.1.7 elements.xsd rules causes XSD validation errors on auto-generated block names.

[dfelton]

Preconditions

1. Fresh install of Magento 2.1.7 EE

Steps to reproduce

Due to the nature of the cause of the issue, there is not a way to consistently reproduce the problem. This is because the method used to generate the hash relies the md5 result of a constantly changing value. Therefore it is by chance that a block will have a invalid generated name.

Will provide additional information below.

Expected result

1. Log into the admin.
2. Save a new widget that will appear on the front end.
3. Widget shows on front end without causing var/log/support_report.log logs.

Actual result (on random occurrences)

1. Due to invalid block name (value starts with a digit instead of an alpha character) the block's name in the generated XML layout does not pass XSD validation and litters the var/log/support_report.log file.
2. To make matters worse, since the name of the generated block is stored in the database at the time of save, this invalid name is retained until the widget is modified. Therefore until that happens every page load containing the widget will continue to fill the support_report.log file with errors.

Additional Information

• Magento\WidgetModel\WidgetInstance::generateLayoutUpdateXml() is relying on \Magento\Framework\Math\Random::getUniqueHash() to generate a name for the block.

• Magento EE 2.1.7 is missing the updates to elements.xsd is missing the update from this commit which allows for block names to start with digits.

[korostii]

Actually, the commit is only present on the develop branch. Here's what this file looks like at the latest release on the stable branch (which is 2.1, by the way): https://github.com/magento/magento2/blob/2.1/lib/internal/Magento/Framework/View/Layout/etc/elements.xsd#L143

Which means that 2.1.7 CE hasn't received this update neither.
Hooray, EE users were not discriminated! CE users are neglected as well!
We're all being denied from timely deliverance of bugfixes equally!

Just an FYI: if you want it into the next release badly enough, here's what you could do:
making a pull request with this commit that would target 2.1-develop branch as described here. That might somewhat speed it up.
Otherwise it'll probably ship in 2.2 later this year.

[dfelton]

@korostii Thank you for this. This is very helpful. I was unaware of the purpose of the 2.1-develop branch so after you elaborated on this that does indeed make me feel better about the situation.

I may go ahead and do what you have suggested for a few XSD files. Locally I've resorted to updating a few vendor files directly but this approach obviously does not bode well for when I upgrade to future versions.

Thanks again this is very helpful to know how minor release versions are handled.

[korostii]

No problem, glad to help :)
Good luck with your future endeavors & have a nice day!

[dfelton]

Closing issue after gaining a better understanding of branches and their purpose.

[korostii]

Actually I'd advise to keep an issue open until it gets released. Otherwise the guys at Magento, Inc. probably won't stumble upon it, ever (nor will they care about backporting it).

[dfelton]

thanks again :)

[magento-engcom-team]

@dfelton, thank you for your report.
The issue is already fixed in 2.2.1