developer mode throws an exception, but production mode is good

[yssource]

My working environment looks like this. And I run magento with a fresh installer by composer create-project. Fedora 23 kernal: 4.4.9-300.fc23.x86_64

| Name             | Magento                          |
| Version          | 2.0.7                            |
| Edition          | Community                        |
| Application Mode | developer 

PHP 5.6.21 (cli) (built: Apr 28 2016 06:17:51) 
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
    with XCache v3.2.0, Copyright (c) 2005-2014, by mOo
    with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies
    with Xdebug v2.3.3, Copyright (c) 2002-2015, by Derick Rethans
    with XCache Optimizer v3.2.0, Copyright (c) 2005-2014, by mOo
    with XCache Cacher v3.2.0, Copyright (c) 2005-2014, by mOo
    with XCache Coverager v3.2.0, Copyright (c) 2005-2014, by mOo

It is reporting the following warnings, when I was debugging and found it was caused by

$schema = 'urn:magento:module:Magento_Ui:etc/ui_definition.xsd'
/home/jimmy/www/magento2/porto/vendor/magento/module-ui/etc/ui_definition.xsd

Warning: DOMDocument::schemaValidate(): Invalid Schema in /home/jimmy/www/magento2/porto/vendor/magento/framework/Config/Dom.php on line 290
#0 [internal function]: Magento\Framework\App\ErrorHandler->handler(2, 'DOMDocument::sc...', '/home/jimmy/www...', 290, Array)
#1 /home/jimmy/www/magento2/porto/vendor/magento/framework/Config/Dom.php(290): DOMDocument->schemaValidate('/home/jimmy/www...')
#2 /home/jimmy/www/magento2/porto/vendor/magento/framework/View/Element/UiComponent/Config/DomMerger.php(350): Magento\Framework\Config\Dom::validateDomDocument(Object(DOMDocument), 'urn:magento:mod...')
#3 /home/jimmy/www/magento2/porto/vendor/magento/framework/View/Element/UiComponent/Config/DomMerger.php(326): Magento\Framework\View\Element\UiComponent\Config\DomMerger->validateDomDocument(Object(DOMDocument))
#4 /home/jimmy/www/magento2/porto/vendor/magento/framework/View/Element/UiComponent/Config/DomMerger.php(393): Magento\Framework\View\Element\UiComponent\Config\DomMerger->createDomDocument('<?xml version="...')
#5 /home/jimmy/www/magento2/porto/vendor/magento/framework/View/Element/UiComponent/Config/Reader.php(60): Magento\Framework\View\Element\UiComponent\Config\DomMerger->merge('<?xml version="...')
#6 /home/jimmy/www/magento2/porto/vendor/magento/framework/View/Element/UiComponent/Config/Reader.php(47): Magento\Framework\View\Element\UiComponent\Config\Reader->readFiles(Array)
#7 /home/jimmy/www/magento2/porto/vendor/magento/framework/ObjectManager/Factory/AbstractFactory.php(101): Magento\Framework\View\Element\UiComponent\Config\Reader->__construct(Object(Magento\Framework\View\Element\UiComponent\Config\FileCollector\AggregatedFileCollector), Object(Magento\Framework\View\Element\UiComponent\Config\Converter), Object(Magento\Framework\View\Element\UiComponent\Config\DomMerger))
#8 /home/jimmy/www/magento2/porto/vendor/magento/framework/ObjectManager/Factory/Compiled.php(88): Magento\Framework\ObjectManager\Factory\AbstractFactory->createObject('Magento\\Framewo...', Array)

[mazhalai]

@yssource production mode does suppress errors and warnings. http://devdocs.magento.com/guides/v2.0/config-guide/bootstrap/magento-modes.html

We have created MAGETWO-53770 to investigate and fix the warning.

[devonto]

Is there any update on this issue?

[tmotyl]

@maksek Would be awesome to push it forward during hackathon.

[okorshenko]

Please, look at: 237e54d79c70d8954f16556a3a8195a8b7b6d942 7bed7ef0277a82552051c769afe054708c56bde7 397fa26f775ebe93c742fe3e4937d68571abf4b5

[veloraven]

I'm closing this issue as we were not able to reproduce it on develop branch. If you can still reproduce this issue, please create a new GitHub issue report.

[tmotyl]

Does it mean that the next version of Magento 2.2 will be released from branch develop?

[NadiyaS]

@tmotyl yes, 2.2.0 version will be created from branch 'develop'

[korostii]

Does it mean 2.1's issues will be ignored unless they exist on 2.2 as well?

[NadiyaS]

@korostii , no, it does not. Bugs with high priority are being fixed and they are delivered in patch releases for 2.1.

[korostii]

Hi @NadiyaS, thanks for the timely response. I am sorry to continue bothering you, but i have couple of follow-up questions and @veloraven seems to mostly ignore me for whatever reason.

1. Is there a definition of "high priority" which I could look up somewhere? Does "security only" sound about right?

2. Since you seem to be representing Magento, I presume that you're saying that developers from Magento, Inc. won't be putting any resources into bugs they consider "low priority". But in this case there is a developer from the community is working on the backport: see PR #9718. Will such voluntary outside effort be denied from appearing on 2.1 branch, as well?

3. I mean, the issue clearly exists and there is someone working on it. I understand the reasoning behind not wanting to put any internal resources on it (and not creating a corresponding internal ticket \ having it on low priority or whatever), but why close the public GitHub issue altogether?

[vkublytskyi]

Hi, @korostii. Let me try to answer your questions.

1. Priority of issues reported at GitHub defined by the community as described at blog post. Priority of an issue also may be raised based on requests to support or any other feedback. Not only security issue may be back-ported to 2.1-develop branch. The only difference to 2.1-develop branch compared to develop is higher requirements for backward compatibility. And, of course, all issues fixed in 2.1 should be fixed in 2.2 as well.
2. Magento Inc. continuously working on fixing issues and back-porting them. We are struggling for the Magento without bugs but, as all, we have limited resources we have to burn them one by one based on priorities. Community contribution is highly appreciated and you may search such PRs by develop-2.1 label. Any PR that follows code contibution requirements will be accepted.
3. This issue already resolved on develop branch (so for 2.2.0 release) and this was a reason to close this bug report. Back-port for 2.1-develop branch (PR #9718) will be accepted as soon as all requirements for contribution are followed.

[korostii]

Hi @vkublytskyi, thank you for the detailed response!

I am well aware of the points 1 and 2 you mention, and I do understand the reasoning behind them. However, if those policies are still in place, I do not fully understand why does it make sense to close an issue like this one.

Closing an acknowledged issue commonly means that the issue is resolved and there's no more work to be done (which is not true, if you do still allow the backporting step). I don't think there is a way to track resolved-on-develop-but-not-backported issues if they are being closed instaed of assigning an "up for grabs" label. Finally, there is this comment to the blog post about upvoting in which @maksek states, that:

In terms of upvoting on closed issues - at the moment we are not monitoring (or rarely monitoring such issues), due overload on opened issues.

And that, kind of, invalidates the whole point about upvoting if the issue is being closed.

[okorshenko]

We have open Pull Request for this issue. We should not close it. https://github.com/magento/magento2/pull/9718

[magento-team]

Internal ticket to track issue progress: MAGETWO-70394

[orlangur]

@okorshenko and now it can be closed or we should wait for the next 2.1.x release? Would be nice if issue status transition rules are described somewhere.

[okorshenko]

we will close the issue once MAGETWO-70394 released. We will describe issue status transition rules after 2.2 release