Replace the node listing at /node with a view

Here's what I have so far, but it needs the empty behavior, which might have to be either a specific area plugin, or dumbed down. I think I'll write the plugin first, and then we can decide if we really want it to stay the same.

So here is a start:

* Created a custom area handler which handles all this custom logic for the frontpage
* Fixed some other stuff which occurred on this node listing.

+++ b/core/modules/node/config/views.view.frontpage.ymlundefined
@@ -0,0 +1,169 @@
+          alter:
+            absolute: '0'
+            alter_text: '0'
+            ellipsis: '0'
+            html: '0'
+            make_link: '0'
+            strip_tags: '0'
+            trim: '0'
+            word_boundary: '0'

Are we going to export all this crap each time? :(

+++ b/core/modules/node/node.views.incundefined
@@ -678,6 +678,19 @@ function node_views_data() {
+function node_views_data_alter(&$data) {

Why isn't this just part of node_views_data()?

+++ b/core/modules/node/node.views.incundefined
@@ -678,6 +678,19 @@ function node_views_data() {
+      'id' => 'node_listing_empty'
+    )

Missing trailing commas

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/area/AreaPluginBase.phpundefined
@@ -98,9 +98,7 @@ public function query() { }
-  function render($empty = FALSE) {
-    return '';
-  }
+  abstract function render($empty = FALSE);

Nice.

+++ b/core/modules/views/theme/views-view-rss.tpl.phpundefined
@@ -8,6 +8,7 @@
 <?php print "<?xml"; ?> version="1.0" encoding="utf-8" <?php print "?>"; ?>
+
 <rss version="2.0" xml:base="<?php print $link; ?>"<?php print $namespaces; ?>>
   <channel>

Uh?

Are we going to export all this crap each time? :(

Well we could go through each item and remove default values out before saving.
As i realized we will not get rid of defineOptions even with metadata, because jose
told me that default values are out of scope of the metadata issue.

I manually removed the fields from this export, because actually the view is not using any field
at all (the wizard just adds at least one field all the time, so the user don't get some validation errors).

Why isn't this just part of node_views_data()?

It is using the global area scope, but i agree it doesn't make sense to be on that as it is too specific.

The last change need for sure some explaination: If you print out <?xml you get also rss in the same line,
the new line fixes that, but i'm open to revert this change.

Missing trailing commas

This happens if you have written to many annotations :p

Once the actual patch is ready i will remove the node module code and have a look whether the node tests still run fine.

Updated issue summary.

added blockers

There are a couple of issues that will make this patch easier/better I think:

#1808542: Allow area handlers to override the page title when used in an empty area.
#1807624: Saving and rendering in empty region for 'Global: unfiltered' text does not work

Assignment for tonight.

As mentioned in VDC IRC (Just so it's in here too); We should remove the call to drupal_set_title (in favour of our new area handler) and also remove the code changes to AreaPluginBase.

Updated issue summary.

Rerolled the patch against some current changes and started to realize that a lot of tests
actually rely on the existence of /node to check for example a link to the title.
Due to that all of these tests would require views to work.

Here is a beginning which let use views in two of the identified tests.

Committed the current version so see what all is broken.

Thanks for you work!

Based on our experience with the coupling of the tests with the /node page we might should create an issue in the core queue
to discuss a proper decoupling?

In http://drupalcode.org/sandbox/tim.plunkett/1799554.git/commitdiff/6be6883 I worked to get more tests passing.
My theory was to not add Views as a dependency if possible, but to not spend hours decoupling.
Once We get this as close as possible, we can revisit each of those and re-evaluate.

Also, many of these fixes belong in the meta issue, but this is at least an easy way to identify them.

I'm done for now. The rest are standard profile tests or upgrade tests, I think.

Here's a patch of work to date

Let's benchmark the listing already: #1811816: Benchmark node_page_default vs. node view

Here's a new patch, just rerolled after #1026616: Implement an entity render controller

Rerolled.

This is blocked on #1807020: Add Views and Views UI to the standard install profile

Is #1806370: Do full performance testing on the main node listing before and after it is converted to a view really postponed on this, and this really postponed on the standard install profile? I'd like to get some performance testing done of Views 8.x pretty quickly, and before/after front page testing is usually a pretty good example.

@catch
It is for sure not really blocked as the node listing itself is working so #1811816: Benchmark node_page_default vs. node view is an issue with a propoer performance testing.

promoted, node and teasers are very Drupally words that we've seen new users struggle with, lets not cram those all into something that should clarifiy things. The first rewrite in #40 seems better to me.

I don't understand why this patch requires Views UI, Shouldn't only Views be enough?

Are you referring to #36? Otherwise, I can't see where the dependency is coming from in this issue? :)

#36 and the issue description: "Switch to the VDC sandbox installation. Be sure to enable the Views and Views UI modules (necessary until they are added to the standard profile)"

check Admin Views for ideas and code
http://drupal.org/project/admin_views

Just posting a rerole to see whether the tests are green.

Let's fix a bunch of the views related tests by decoupling them from the frontpage view.

Totally forgot to add the new base class. The interdiff is relative to comment #51

@xjm: Can you provide the debug_backtrace() for that call?

I've seen that update.php exception while working on and debugging many other patches in the meantime - definitely not related to this issue, and thus we should create a separate, dedicated issue for it. (update.php has not been adjusted for the kernel at all recently, which clear appears to be the cause, but then again, update.php cannot boot a regular kernel in the first place, which gets us into a very hairy situation... anyway, separate issue.)

Provided an upgrade test for the frontpage view.

Quite important consideration, as I noticed the "Convert" in the issue title only now:

This patch attempts to actually remove and replace the non-views-based listing of nodes on /node with a views-based listing.

Consequently, this adds a relatively huge dependency on Views module to Node module. Essentially, you will not be able to use Drupal in any basic/sensible way without Views module anymore.

I'm not sure whether that is a good idea. Views is nice and all for creating and overriding custom, user-configurable listings. But Views is also a mammoth thing. Doing this conversion here, instead of overriding the route/path with a view, would essentially set the precedent for "convert all listings into views" — having the end result of rendering Drupal unusable without Views module being enabled - which in turn would make Views a required module. I do not think that Views is ready for that yet. I always assumed that to be D9+ material (if at all).

For D8 it would make more sense to me if Node module would ship with a default view that allows to replace the /node listing with a views-based listing. I wouldn't really care whether that default view is enabled or disabled by default. However, the essence is that there is only a views-based listing if Views module is enabled. If Views module is not enabled, then Node module is still fully operational and able to provide basic content functionality, which includes a basic listing of nodes.

If you want to pursue the full conversion/replacement idea, then I think there should be a separate issue first to discuss the consequences of doing so (which are much larger than creating and supplying this simple node default view).

"Consequently, this adds a relatively huge dependency on Views module to Node module. Essentially, you will not be able to use Drupal in any basic/sensible way without Views module anymore."

I actually don't think that's true. With Node module you can create content types, you can pull them into Panels pages, you can list them within an Organic group, you can request them with REST-based web services, etc. The fact that core has in the past shipped with a non-turn-offable page + RSS feed called "node" that arbitrarily exposed teasers of all nodes on your site that have an arbitrary checkbox checked, is what the bug is, IMO. I don't see a "dependencies[] = views" line added to node.info, so IMO the patch is fine.

Product vs Framework. This is about the default we want Drupal to ship with. With the default config of a Drupal 8 installation we're making the choice here to provide a configurable collection of nodes at /node.

Don't want that? Think we're hard-wiring a dependency of node.module on views.module?

Here's the litmus test:
1. install Drupal 8 with minimal installation profile
2. Create a content type
3. Add a bunch of nodes of that content type
4. Create a display of a collection of nodes without views.

It CAN be done. Therefore, no dependency.

Reading through... especially #83 and #87 are upgrade path tests still needed?

We can add @dawehner's assertions in a ViewsUpgradePathTest once update.php is fixed.

Was there another issue number for "once update.php is fixed"? Or was that to be part of this issue?

There is so much done already here. I know xjm is super busy (blocks!!!). Maybe some detailed next steps will help bring in someone more people to support this?

I'm sure anyone eager could try a reroll of #87 to continue the chase of head.

See #1848998-81: Problems with update_module_enable()

+++ b/core/modules/views/lib/Drupal/views/Tests/Handler/RelationshipTest.phpundefined
@@ -7,12 +7,14 @@
+class RelationshipTest extends RelationshipJoinTestBase {

+++ b/core/modules/views/lib/Drupal/views/Tests/Plugin/JoinTest.phpundefined
@@ -13,8 +13,11 @@
+class JoinTest extends RelationshipJoinTestBase {

If we need some time anyway we could move this to another issue, as it's actually unrelated to that issue.

We certainly need a rerole after that time, if it's not done until monday I'm happy to split it up.

Just a plain old rerole and codestyle fix.

Just let's wait on #1848998: Problems with update_module_enable() and a lot of them should get green.

A list of follow ups:

• #1893844: Mark AreaPluginBase::render as abstract
• #1893850: Cleanup relationship tests and don't use the node module

Rerolled against lot of changes, and fixed many of the failures.

It feels like we should really get at least one conversion in before feb 18th?

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/area/Title.phpundefined
@@ -65,4 +65,12 @@ public function render($empty = FALSE) {
+  }
+
+
 }

1 extra newline. (non-blocking)

+++ b/core/modules/views/lib/Drupal/views/Tests/Handler/RelationshipTest.phpundefined
@@ -24,6 +24,7 @@ class RelationshipTest extends RelationshipJoinTestBase {
   public static $testViews = array('test_view');
 
+
   /**
    * Maps between the key in the expected result and the query result.

1 extra newline (non-blocking)

+++ b/core/modules/views/lib/Drupal/views/Tests/Plugin/PagerTest.phpundefined
@@ -17,7 +17,7 @@ class PagerTest extends PluginTestBase {
-  public static $testViews = array('test_store_pager_settings', 'test_pager_none', 'test_pager_some', 'test_pager_full', 'test_view_pager_full_zero_items_per_page');
+  public static $testViews = array('test_store_pager_settings', 'test_pager_none', 'test_pager_some', 'test_pager_full', 'test_view_pager_full_zero_items_per_page', 'test_view');
 

@@ -44,13 +44,16 @@ public function testStorePagerSettings() {
-    $this->drupalGet('admin/structure/views/view/frontpage/edit');
-
+    $this->drupalGet('admin/structure/views/view/test_view/edit');

test_view seems not specific enough. I suggest test_frontpage

(I'm not sure. Why is a test view being tested instead of testing the actual view being added?)

+++ b/core/modules/views/lib/Drupal/views/Tests/UI/DefaultViewsTest.phpundefined
@@ -33,7 +33,7 @@ public static function getInfo() {
     // Make sure the front page view starts off as disabled (does not appear on
     // the listing page).
-    $edit_href = 'admin/structure/views/view/frontpage/edit';
+    $edit_href = 'admin/structure/views/view/glossary/edit';

glossary?

Oh, is it that the frontpage is enabled by default, so to test some views are disabled by default and can be enabled, so use a different view than frontpage?

Probably the comments need to change.

Thanks for the review! Please testbot run that patch :)

1 extra newline. (non-blocking)

Fixed

1 extra newline (non-blocking)

Fixed

(I'm not sure. Why is a test view being tested instead of testing the actual view being added?)

The idea is to not use the frontpage anymore, so if you test against a generic view, we use test_view.

Probably the comments need to change.

Adapted the comments.

writing down some things from an irc conversation with @dawehner

+++ b/core/modules/views/lib/Drupal/views/Tests/AnalyzeTest.phpundefined
@@ -41,10 +48,8 @@ public function setUp() {
   function testAnalyzeBasic() {
     $this->drupalLogin($this->admin);
-    // Enable the frontpage view and click the analyse button.
-    $view = views_get_view('frontpage');
 
-    $this->drupalGet('admin/structure/views/view/frontpage/edit');
+    $this->drupalGet('admin/structure/views/view/test_view/edit');

this and other substitutions of using the test_view (already existing, and not introduced as part of this patch) instead of the frontpage view makes sense.

previously the frontpage was used for test unrelated to the frontpage because it was a view that was handy.

+++ b/core/modules/views/lib/Drupal/views/Tests/UI/DefaultViewsTest.phpundefined
@@ -31,34 +31,34 @@ public static function getInfo() {
   function testDefaultViews() {
-    // Make sure the front page view starts off as disabled (does not appear on
-    // the listing page).
-    $edit_href = 'admin/structure/views/view/frontpage/edit';
+    // Make sure the view starts off as disabled (does not appear on the listing
+    // page).
+    $edit_href = 'admin/structure/views/view/glossary/edit';

this also makes sense, is replacing the use of the frontpage view to do some (non-frontpage specific) testing with a different default view that starts disabled.

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/area/Title.phpundefined
@@ -65,12 +65,4 @@ public function render($empty = FALSE) {
-  /**
-   * Implements \Drupal\views\Plugin\views\area\AreaPluginBase().
-   */
-  public function render($empty = FALSE) {
-    // Do nothing for this area handler.
-  }
-
-

from the interdiff, due to some merge problems this render function have been twice in the title.php. So this is just removing that.

+++ b/core/modules/views/lib/Drupal/views/Tests/AnalyzeTest.phpundefined
@@ -41,10 +48,8 @@ public function setUp() {
   function testAnalyzeBasic() {
     $this->drupalLogin($this->admin);
-    // Enable the frontpage view and click the analyse button.
-    $view = views_get_view('frontpage');
 
-    $this->drupalGet('admin/structure/views/view/frontpage/edit');
+    $this->drupalGet('admin/structure/views/view/test_view/edit');

So, far, to me, the code makes sense, comments are updated, coding standards look good, and the recent interdiff looks good. this is rtbc except...

next steps:
@dawehner says one test is failing locally, but might be unsure of how to fix it.
also, a manual test of the frontpage would be good

This will potentially fix like 90% of the problems.

Oh! Those are the same failures I fixed in #1851086: Replace admin/people with a View. Which makes sense.

Okay, that fails just because config('system.site')->get('page.front') == 'node', and views is not on.

In #83 and #84 this was discussed, but there was never an upgrade path added.

Please!

So let's test the patch now.

- $this->assertTrue($this->container->get('module_handler')-moduleExists('views'), 'Views is enabled after the upgrade.');
+ $this->assertTrue($this->container->get('module_handler')->moduleExists('views'), 'Views is enabled after the upgrade.');

:)

That'll teach me to run tests locally first.

I should have done this as well :)

Let's stop forward.

I know #1811816: Benchmark node_page_default vs. node view is open but it'd be good to get a before/after before this goes in.

Both for xhprof profiling, and also for the difference in the page size since the markup will change here as well.

Looked at the code and it looks good to go. I agree that we should look at the profiling results first though.

tagging for profiling

Profiling is work :)

I did a simply xhprof run with 50 total nodes and came to the following result.

I also redid some of my original benchmarks, so those are comparable with old data (http://drupal.org/node/1811816#comment-6675896);

=== core-node-50..core-views-50 compared (512563c5e130a..51256415a891a):

ct  : 94,685|101,963|7,278|7.7%
wt  : 328,388|361,731|33,343|10.2%
cpu : 328,020|360,023|32,003|9.8%
mu  : 9,195,584|12,082,464|2,886,880|31.4%
pmu : 9,554,600|12,529,240|2,974,640|31.1%

ct = function calls, wt = wall time, cpu = cpu time used, mu = memory usage, pmu = peak memory usage

This was with 1000 runs - same results. APC autoloader is off.

Views is and keeps being 32 ms worse in this benchmark, but with 50 nodes and no caching on that is not too bad.

But that overhead I already explained in http://drupal.org/node/1811816#comment-6670756 and it keeps being valid.

On mu/pmu you basically see how much memory a full loaded view object needs.

In general 32ms worse seems to be acceptable, especially if you can turn on caching. If we do that though, we need first a better support for cache tags, as currently you might end up with new nodes not appearing on the node listing page, as the page is cached.

Set back to RTBC? (Not sure whether that is the proper status).

2mb for a fully loaded view object seems a bit wrong to me, or at least maybe that's gone up rather than down since 7.x. I'm trying to remember when I lasted tested this for 7.x-3.x but can't find the issue at the moment. Might try to look myself another time (unfortunately no chance this week).

#1605290: Enable entity render caching with cache tag support is probably going to have to move to being independently critical between Views, EntityNG and Twig.

I've been doing some tests too and it looks quite nice here

Disclaimer:
* I'm using the APC class loader, which removes those 10% class loader stuff from @dawehner's screenshot.
* I've disabled views_ui although that didn't seem to make such a big difference.
* Something that needs to be kept in mind is that function calls have a considerable cost when profiling. So when having more function calls, then it's actually less bad than it looks with xhprof.

Notes:
* The time difference is quite small for me, actually (overview.png)
* Seeing a handful of additional cache loads for the plugins, but that's about it for queries.
* I can confirm the additional 2MB in the overview but I can't really track them down. There's a lot of "movement" in theme functions, it looks like the main node rendering happens now in theme@2 and no longer theme@3, so one level less nesting but it seems to sum up. There's a lot of red (more memory) lines below then but it's a lot of small stuff, so nothing obvious to improve (functions.png)

So, it looks quite good to me. Will try to do another round of "What happens if I add 20 recent comment views blocks on a page" in the other issue to see if there some generic overheads but I think a lot was already improved.

Also did a quick try with a field based view (title, image, body) which looks visually very similar to the node listing but is 34% faster (still 1MB more memory, though). No idea how that will work with an EFQ backend but I think it's a nice example for the "we're comparing apples with oranges" argument. I think the number of sites that have to worry about performance (apart from the crappy shared host performance problems) and are using the default node view are very low. Even simple blogs often use views because they want a different sort order, or a filter or something like that.

Therefore, having a view there by default instead of an arbitrary node listing that nobody uses makes *a lot* of sense, because it means the typical frontpage profiling is profiling the same thing that real sites will use. So in short, a lot of words for saying +1 :)

Mmm... @Berdir's bench shows a 6% "improvement" in ModuleHandler::load().

That looks highly suspicious.

#137: This is within error margin. Without doing a test 1000 times and then use aggregate or minimum, you'll always have such "error margins".

And even then it can happen. I check for mine (minimum of 1000 runs) and I have "1" ms difference.

#136: Creating a field based view is a great idea and I'll benchmark that as well. Also I'll redo benchmarks with APC classloader on.

I also had an error in my benchmark :-/ as my min code did not actually run:

Here is new and now accurate numbers, I'll fix xhprof-kit and will retest more automatically soon:

This now is benchmarked like:

XHProf_Start
index.php
XHProf_End

while the previous benchmarks had been just using "devel".

Benchmak setup - No APC autoloader

* PHP 5.3
* APC Autoloader - Off
* node vs. frontpage (view) vs. frontpage-fields (view with fields)

Benchmark results: /node vs. /frontpage

=== core-node-50..core-frontpage-50 compared (512a1f7f217a6..512a20b11c1ab):

ct  : 99,800|107,952|8,152|8.2%
wt  : 352,534|385,851|33,317|9.5%
cpu : 352,023|384,024|32,001|9.1%
mu  : 14,421,096|17,745,512|3,324,416|23.1%
pmu : 14,801,280|18,206,632|3,405,352|23.0%
--
ct = function calls, wt = wall time, cpu = cpu time used, mu = memory usage, pmu = peak memory usage

Permalink for easy browsing: http://www.lionsad.de/xhprof/xhprof_html/?run1=512a1f7f217a6&run2=512a20...

Benchmark results: /node vs. /frontpage-fields

=== core-node-50..core-frontpage-fields-50 compared (512a1f7f217a6..512a226436ce4):

ct  : 99,800|77,394|-22,406|-22.5%
wt  : 352,534|303,343|-49,191|-14.0%
cpu : 352,023|300,019|-52,004|-14.8%
mu  : 14,421,096|17,365,568|2,944,472|20.4%
pmu : 14,801,280|17,639,176|2,837,896|19.2%
--
ct = function calls, wt = wall time, cpu = cpu time used, mu = memory usage, pmu = peak memory usage

Permalink for easy browsing: http://www.lionsad.de/xhprof/xhprof_html/?run1=512a1f7f217a6&run2=512a22...

----------

Benchmak setup - With APC autoloader

* PHP 5.3
* Classloader: APC
* node vs. frontpage (view)

Benchmark results: /node vs. /frontpage

=== core-node-50-apc..core-views-50-apc compared (512a40915a5dd..512a40ad78082):

ct  : 95,421|101,134|5,713|6.0%
wt  : 341,765|370,369|28,604|8.4%
cpu : 340,021|368,023|28,002|8.2%
mu  : 14,438,832|17,763,760|3,324,928|23.0%
pmu : 14,818,488|18,225,384|3,406,896|23.0%

--
ct = function calls, wt = wall time, cpu = cpu time used, mu = memory usage, pmu = peak memory usage

Permalink for easy browsing: http://www.lionsad.de/xhprof/xhprof_html/?run1=512a40915a5dd&run2=512a40...

----------

I will now always give both numbers and permalinks to XHProf Runs. :-)

Discussed our results with FabianX in IRC, some more conclusions and thoughts.

- As you can see in the updated benchmarks, 7ms of the additional time is spent in the classloader and they go away when you use APC as I did.
- I'm doing the profiling manually ( usually run 3 times and use the fastest run) so there is a higher chance of errors. That said, my numbers seemed to be relatively stable.
- I'm using PHP 5.4, which probably contains a few performance improvements.
- We were testing with 50 nodes. That means that the code path where there actually is a difference between node_default_page() and views is a relatively small part of the total execution, ~80% of the time is spent in drupal_render_page. So small differences there (e.g. if you have different users that need to be loaded or a single one, logged in or not) change the total execution time and therefore the procentual difference between node_default_page() and views.
- FabianX and I also did an example test with just a single node, where we had comparable results of ~20% overhead despite quite different absolute numbers.
- @msonnabaum also mentioned in IRC that the used flags and whether xdebug is enabled or not have huge difference in xhprof. I had xdebug enabled on my laptop and it slowed it down ~30% (not used that in the published results, just an example). Did a test without XHPROF_FLAGS_CPU on my desktop and it was another ~25% faster.

All that said, I'm still not sure what a fair comparison would be, 1 node certainly isn't. And 50 is too much. And a single listing as a whole is tricky because views has a one-time overhead and many many sites will also have a view listing or two (or 10) in a block anyway.

IMHO, the shown regression in terms of performance ( be it my numbers of those of others) are worth it. Especially because we showed that there are various ways to make that up again for sites that care. Enable caching, switch to a field based view, ...

I agree with berdir. +1 for RTBC

I agree with berdir. +1 for RTBC

Still need a diff of page size here, that's something that could be done by a novice contributor, so tagging novice.

50 Nodes displayed:

Node: 95.02 KB (14.76 KB compressed)
Views: 98.58 KB (15.11 KB compressed)

Measured with Chrome Network tab as anonymous user.

Installation still shows some debug messages :(

After some debugging the problem is the following: The moduleHandler sort of caches hook_hook_info way to early, so there is no file included for node.views.inc

On later time of the installation (for example another batch request) the modules are enabled, so the hook info is there and views can fire it's hooks.

taking novice off since the page size comparison was done.

#1929656: ModuleHandler::setModuleList() should call resetImplementations() in order to avoid edge cases is an issue to solve the problem.

I think that means we are back to rtbc.

#126: vdc-1806334-126.patch queued for re-testing.

Well, It's more like that this issue is blocked on the other one :)

#126: vdc-1806334-126.patch queued for re-testing.

Rerolled.

debug messages still there:(

+++ b/core/modules/views/lib/Drupal/views/Tests/UI/DefaultViewsTest.phpundefined
@@ -77,22 +77,22 @@ function testDefaultViews() {
-    // $this->drupalGet('frontpage');
+    // $this->drupalGet('glossary');

@@ -102,19 +102,19 @@ function testDefaultViews() {
     // $this->assertUrl('admin/structure/views');
     // $this->assertNoLinkByHref($edit_href);

maybe these are the debug messages referred to?

they were not introduced by this issue though..

oh #144 says installation. So I'll try manually testing.

here they are:

Debug:
'Missing handler: node created sort'
in views_get_handler() (line 934 of core/modules/views/views.module).
Debug:
'Missing handler: node sticky sort'
in views_get_handler() (line 934 of core/modules/views/views.module).
Debug:
'Missing handler: node promote filter'
in views_get_handler() (line 934 of core/modules/views/views.module).
Debug:
'Missing handler: node status filter'
in views_get_handler() (line 934 of core/modules/views/views.module).
Debug:
'Missing handler: views area area'
in views_get_handler() (line 934 of core/modules/views/views.module).
Debug:
'Missing handler: node node_listing_empty area'
in views_get_handler() (line 934 of core/modules/views/views.module).
Debug:
'Missing handler: views title area'
in views_get_handler() (line 934 of core/modules/views/views.module).

Now, after applying the patch installer dies:
Fatal error: Call to a member function id() on a non-object in /var/www/d8/core/modules/menu/menu.module on line 210
Lets see what bot says, mybe my installation is messed up
#153: drupal-1806334-153.patch queued for re-testing.

this should take care of that..no idea yet what happens with the debug messages

@rootatwc

How should that fix the messages when install drupal? I would love to understand that :)

No, this is to fix the fatal error (see #158)...debug messages are still there..i am still investigating, but i have an idea

Ah great. In general I still think we should have tests for that behavior.

#160: drupal-1806334-159.patch queued for re-testing.

3kb is a fair bit, although in context it's unfortunately not that much.

What about the difference in document.getElementsByTagName("*").length ?

this should get rid of debug messages..getHookInfo acts on a full moduleList, but none of this modules is loaded yet..and then hookInfo is cached

+++ b/core/lib/Drupal/Core/Extension/ModuleHandler.phpundefined
@@ -235,6 +235,8 @@ public function getHookInfo() {
+      // Make sure that the module is loaded before checking.
+      $this->load($module);

As we iterate over all modules anyway, can't we just do $this->reload() before the foreach?

#168: drupal-1806334-168.patch queued for re-testing.

i am gonna rtbc this, since it would be great to have it for the sprint weekends..i think we just need sun's feedback on this last change on moduleHandler..if he is fine with it i dont see any reason not to commit this...but, i ll leave the rest on maintainers:)

Edit:
document.getElementsByTagName("*").length:

Before:
Logged in: 451
Logged out: 100

After:
Logged in: 457
Logged out: 102