Drupal core announcements: Priorities for the upcoming Drupal 8 critical issue sprint (Dec. 10-14 in Ghent, Belgium)
Our top priority for the sprint will be to make progress on D8 upgrade path blockers (critical issues with the 'D8 upgrade path' tag) that affect the Entity Field API, Views, and the Configuration System. Here are the specific issues we have targeted:
- #2372855: Add content & config entity dependencies to views
- #2341357: Allow the entity area to use UUIDs instead of IDs and provide autocompletion
Discuss and plan our approach. (The second issue, #2341357, is a soft blocker that covers part of the scope of the first, #2372855.)
- [PP-1] Figure out what to do in Views when entity schema changes
Discuss and plan our approach.
- #1934152: Figure the out if we want global config overrides to stick (settings.php overrides don't work on all pages)
Discuss, make a decision, and move forward.
- #2278017: [PP-1] When a content entity type providing module is uninstalled, the entities are not fully deleted, leaving broken references
- #2338873: [PP-2] Modules providing non-configurable field storage definitions can be uninstalled, leaving orphaned unpurged data
These issues are postponed on #2335879: Change SqlContentEntityStorageSchema::requiresEntityDataMigration() to ask the old storage handler if it has data rather than assuming yes unless NULL storage, but that will hopefully land before the sprint. The first issue (#2278017) is proceeding well and can hopefully be wrapped up in the sprint, and then the second (#2338873) will hopefully be a straightforward application of the same pattern. In addition to these issues, we may also want to create a new issue to add a config validator that does the same validation check during a config deployment.
- #2183983: Find hidden configuration schema issues
- #2387149: Display extenders are not possible to describe with config schema
- #2387157: Cloning display into another display also stores options that are not supported by the new display type
Agree on the API needed for the Views child issues. Then, continue to resolve outstanding failures in the main issue. It would be great to either finish these by the end of the sprint or get far enough to know the reason for each remaining failure to have confidence there's no lingering huge problem! (#2387141: Missing field configuration schemas across core tests should be hopefully done before the sprint starts.)
- #2232477: Fatal when adding new fields with NOT NULL constraints in a base table that contains existing entities
This issue was discussed in Amsterdam, committed, and then reverted. yched has been working on the patch since; we could probably focus on this issue together and discuss the issues with the previous patch to move this forward.
Another goal of the sprint is to triage critical issues in the core queue to assess their relevance and priority. (You can help by making sure any open critical issues you are following have up-to-date issue summaries.)Sponsors
If you have any questions about the upcoming sprint, contact xjm.
Anecdotally, Drupal 8 is slower than anything before it - maybe 4x slower. While installing Drupal 8.0.0-beta3 so I could work on upgrading the Masquerade module, I found the installer dreadfully slow. I started a timer when I got to the Batch API-enabled "Install site" page. The installer ran for 10 minutes to get as far as step 32 of 37. Then it errored-out.
An AJAX HTTP error occurred. HTTP Result Code: 200 Debugging information follows. Path: http://localhost/drupal8/core/install.php?langcode=en&profile=standard&i... StatusText: OK ResponseText: ( ! ) Fatal error: Maximum execution time of 30 seconds exceeded in /Users/davidnorman/Sites/drupal8/core/lib/Drupal/Core/Extension/ModuleHandler.php on line 261
I've installed Drupal probably thousands of times and I knew my MacBook Pro Retina, 3rd-generation quad core i7 processor with a SSD wasn't a bottleneck. At the time, I only had one extra PHP extension enabled - Xdebug (see my phpinfo()). It only had a basic configuration. Sometimes I enable things like xdebug.collect_assignments or xdebug.show_local_vars, but even those weren't enabled at the time.[xdebug] zend_extension="/usr/local/Cellar/php56-xdebug/2.2.6/xdebug.so" xdebug.auto_trace = On
To get Drupal to install, I commented the Xdebug zend_extension at /usr/local/etc/php/5.6/conf.d/ext-xdebug.ini, did a brew install php56-apcu, and restarted my MacBook.
After I swapped Xdebug for APCU, the "Install site" portion of the Drupal 8 installer took only 30 seconds to complete and did not time-out, versus the 10 minutes with ultimate failure while Xdebug was enabled.
At this point, I'm seem to be left to conclude that if I wanted to use Xdebug to debug the installer, that my only option is to increase the default 30 second timeout in my /usr/local/etc/php/5.6/php.ini. Alternatively, if I want to use Xdebug for day-to-day module development, that I'll need to disable Xdebug temporarily to get a local install setup.
Drupal 8 does a lot more stuff to process a page. Core developers have succeeded in moving most of the code to use object oriented methods with namespaces and protected variable spaces, but at the expense of turning a vanilla install into about 76MB. Drupal 7.34 is only 15MB.
To make a point, I inserted a debug_print_backtrace() in EntityAccessControlHandler::access(). This is a basic call in core that would check access on anything that's an entity - users, nodes, etc. After Firefox choked on the resulting output, I attempted to make a snapshot of the page using Evernote to link to in this article. Instead, even Evernote told me that the page was too big to capture.
I guess I don't really have any other point to make. It's not like this article is going to make Drupal 8 faster. I don't have advice for making it lightweight. It's what we have to live with now in the supposed pursuit of progress and modern sophistication. I'm just leaving my breadcrumb for other developers who might find it impossible to even get Drupal 8 installed using an environment that worked for Drupal 7 since I was able to get through the "Install site" part of the Drupal 7.34 installer with Xdebug enabled and with APCU disabled in only 14 seconds.Post categories Drupal
What happens when a user bookmarks an access-protected page? If their session expires before they next visit the bookmark, they'll see an "Access Denied" message with no login form. How confusing for the end user! Let's change that.
today I had a short chat with a fellow DD living in a neighbouring country. nothing spectacular in itself; but it reminded me again that debian is more than creating an operating system together for me – it's also about a couple of friendships that grow out of it & which are dear to me.
this posting is part of GDAC (gregoa's debian advent calendar), a project to show the bright side of debian & why it's fun for me to contribute.