In the name of full disclosure, as I have mentioned in a previous post, I am paid by 10gen to make Drupal more MongoDB friendly. This does not just mean the contrib modules (mongodb and efq_views) but core work as well. Our goal is to make Drupal 8 work with just MongoDB, without any SQL. It just so happens that the cornerstones for this are things the community wants anyways: the configuration management initative happens to remove a lot of reliance during the boot process -- no system table, no date_format* tables, no variable table.

In Chapter 1 I have deliberately not mentioned where the dependency injection container gets built because I knew it'll change. The new hotness is the existence of Bundles. Roughly, what Drupal provides in modules (a package of related code and functionality), is a bundle for Symfony. Bundles expose their contents through the dependency injection container and subscribe to events. All the kernel functionality described in chapter 1 is now added in the CoreBundle class. Modules can have their own bundles, too.

Dries in a comment says that the priorities of Drupal core are "content editors over site builders over designers over developers over theoretical purity." On the other hand, the majority of Drupal core developers, including yours truly here, know it much much better what developers need than content editors or site builders or designers. Acquia is doing Spark so I think content editing is covered. But, we need core developers who are passionate about site builder and designer experience.

So I got some update tests fail as we upgrade to Symfony 2.1. The failures were coming from update_parse_xml complaining about malformed XML. I have quickly found a drupal_http_request in the calling function and dumped the URLs it tried to fetch into a file. The test apparently calls a page provided by the update_test.module.

This is not documentation. This is literally the 30000ft high (I have written it on a Calgary-London flight) overview about Drupal 8 page flow as it stands on July 28, 2012. This doesn't mean it will be fully valid even a week later. Also, I am not writing out all the namespaces for classes, it's not necessary.

Two weeks ago I posted two brain teasers about extending ReflectionClass. Let's see the results -- after the break so people not having fun with them yet can.

Progress on what? Glad you asked... let's first go through a few important concepts:

Entity

If you have ever tried EFQ Views and it didn't work you might've thought it does not worth filing an issue because it was abandoned. It is no longer. Please file an issue telling me how it didn't work. Thanks.

Starting May 1, 10gen, the company developing MongoDB will pay me to make Drupal more MongoDB friendly. This will, in the shortest term mean a new release of the mongodb module and the EntityFieldQuery Views backend module. Longer term, I will try to help Drupal 8 make MongoDB friendly.

When we moved to git, at last year's DrupalCon NA in Chicago I asked dww to let me set up a bzr-git two-way mirror on drupal.org He said no, this is what it is, get with the program. As months passed, I have learned about git reflog and git log -S and git blame --reverse and git and I became uneasy friends although I still consider rebase the work of the devil itself. Similarly I disagree with a lot that's happening on the WSCCI side of the core development but what I am taking home from Denver DrupalCon: that's what it is and I will get with the program. I will resume core work to make sure the OOP-ifying of Drupal is done throughly and the render arrays of doom disappear from Drupal 8. Do it or do not, there is no try, and the community decided to do so I must help it doesn't become a try. See you in http://groups.drupal.org/drupal-8-blocks-layouts-everywhere-initiative http://drupal.org/node/1499460