Problem

1. The current password hashing library is a custom fork of phpass.
2. It has to be maintained by Drupal. Drupal should not be in the business of developing/maintaining a password hashing library.
3. The hashing algorithm is 100% custom. 0% interoperability.

Proposed resolution

1. Replace the custom password hashing library with PHP 5.5's password_hash().
2. Fall back to password_compat backport on PHP 5.4.

Remaining tasks

1. Plan to migrate custom hashed passwords from D7.

API changes

1. Drupal\Core\Password\* is replaced by password_hash() + password_verify() functions.

.

Original report by @cweagans

Rob Loach mentioned in http://drupal.org/node/1463624#comment-6750938 that there was a third party library that provides PHPass functionality. Let's look into adopting it as a replacement to our library.

https://github.com/rchouinard/phpass

Problem/Motivation

All classes are produced in PHP that makes it hard for a themer to manipulate these into whatever they need.

Proposed resolution

Copy the item-list.html.twig class into Classy.
Rename it to item-list--search-results.html.twig

Add the class at the top of the Twig templates.

Follow-up to #2483319: [META] Remove unnecessary markup from core templates, a.k.a. divitis

Problem/Motivation

After the removal of CSS classes from the core templates, many unnecessary HTML tags were left behind. They were not removed in the process of removing classes and other work, because removing them requires paying particular attention to any affect on the output.

Beta phase evaluation

Proposed resolution

Go through each core template and remove any unnecessary markup. This will require looking at the output to see if things shift around in unwanted ways. Various CSS files may also need checking. For example, if there is CSS like .some_class > div > .some_other_class the CSS should be adjusted, or deleted.

Evaluation criteria, not set in stone but up for discussion:

• divs and spans with no additional attributes should be removed mercilessly unless they justify their existence.
• Semantic tags (footer, article, etc.) should be retained even if they have no attributes.

This child issue will tackle most of the core module templates. Other issues will be added to the parent meta to remove tags from system, views, and other places.

User interface changes

Two small visual changes in Stark.

block--system-branding-block.html.twig, before & after

link-formatter-link-separate.html.twig, before & after

API changes

None

Problem/Motivation

There are a few related problems with the FieldItemInterface::insert() and FieldItemInterface::update():

• They are invoked, together with FieldItemInterface::delete() and FieldItemInterface::deleteRevision() from within SqlContentEntityStorage, which handicaps the development of alternative storage engines.
• Their behavior is inconsistent with the corresponding hooks: while the hooks are called after entity insert/update, field item methods are invoked before. The rationale behind this behavior, is that field items may need to act before field values are written to perform some final massaging, but they may also need to know the entity identifier. However supporting this use case is no longer possible in D8, because with the default SQL storage we store base field values while allocating the entity ID, during the initial base table write. In fact at the moment, we have an inconsistent behavior between shared table fields and dedicated fields: field methods are run after write for the former, and before write for the latter. This is a critical flaw and the only actual difference between them and FieldItemInterface::preSave(), which makes sense only for the default SQL storage.
• FieldItemInterface::delete() is called before deletion, while the corresponding hook is invoked after deletion. Additionally, there is a pre-delete hook which is invoked before deletion, but there is no corresponding field method. A similar problem exists for FieldItemInterface::deleteRevision().

Proposed resolution

• Remove the ::update() and ::insert() methods, since they happen to be currently broken for base fields, and replace them with a ::postSave() method that will act after field values are written to the storage.
• The ::postSave() method will return a value telling the storage handler whether its item values should be rewritten to the storage. This will cover those (rare) use cases needing the entity ID to implement massaging for their item values.
• Move the method trigger points from SqlContentEntityStorage to ContentEntityStorageBase.

Remaining tasks

• Find consensus around a solution for the FieldItemInterface::delete() and related.
• Validate the proposed solution
• Write a patch
• Reviews

User interface changes

None

API changes

FieldItemInterface::insert() and FieldItemInterface::update() are removed.

<?php
interface FieldItemInterface {
  ...
 /**
   * Defines custom post-save behavior for field values.
   *
   * This method is called during the process of saving an entity, just after
   * values are written into storage.
   *
   * @param bool $update
   *   (optional) Whether the parent entity is being updated or inserted.
   *   Defaults to the former.
   *
   * @return bool
   *   Whether field items should be rewritten to the storage as a consequence
   *   of the logic implemented by the custom behavior.
   */
  public function postSave($update = TRUE);
  ...
}
?>

<?php
interface FieldItemListInterface {
  ...
  /**
   * Defines custom post-save behavior for field values.
   *
   * This method is called during the process of saving an entity, just after
   * values are written into storage.
   *
   * @param bool $update
   *   (optional) Whether the parent entity is being updated or inserted.
   *   Defaults to the former.
   *
   * @return bool
   *   Whether field items should be rewritten to the storage as a consequence
   *   of the logic implemented by the custom behavior.
   */
  public function postSave($update = TRUE);
  ...
}
?>

The built in cron runner just runs at the end of the request, which is horrible. See #1554872: "Run cron every" setting (cron_safe_threshold) is not an interval but a Boolean for amusing things you can run into now due to this.

It was originally put in running from a 1px gif, but this was reverted later since that 1px gif meant a full Drupal bootstrap every time it was requested (including when that 1px gif was served from a cached page, so you'd hit Drupal even if you were serving pages from varnish).

However there's new tricks now, so we don't need to do either. If we have this, then it'll also be most of the necessary infrastructure for #1189464: Add a 'poor mans queue runner' to core.

This depends on #1447736: Adopt Guzzle library to replace drupal_http_request() since one of the criteria for finding a new http client is that it can handle non-blocking HTTP requests. So marking postponed, but leaving at major since this is a nasty gotcha on sites that don't want it, and crappy performance for those users who are unlucky enough to be the ones to trigger the cron run.

We could also fire each cron hook in its own separate PHP runner to keep memory usage down and prevent an error in one cron job killing the others, doesn't necessarily need to be done here though.

Hey guys,

I just tried to install Drupal 8 for test purposes using PHP 5.6 and all it showed me was a "Select language" message, nothing else, it might be related to deprecated functions in PHP 5.6, but please take a look at it.

Thanks.

Problem/Motivation

The toolbar takes ~15 ms and ~17,000 function calls to render. On every page load. That's ridiculously slow. See #21.

The Toolbar module has optimized the rendering of the menu tree, by aggressively caching it. But… the rendering of the "main" toolbar (the black bar at the top of the page, with the white trays underneath it if you click any of the black items) is not yet cached.

Proposed resolution

We have cache context bubbling (#2429257: Bubble cache contexts). Use that: let every item returned by hook_toolbar() specify cache contexts if it depends on contextual information.

See #22 for detailed performance numbers. But here's the gist of it:

Remaining tasks

Review.

User interface changes

None.

API changes

There's a case of "API refinement":

• Roughly speaking: no API changes.
• Strictly speaking: we now require hook_toolbar() implementations to associate cache contexts if they are dynamic. Since that would be an API break in Drupal 8.x.0, marking this is as critical.

Original report by Wim Leers

Problem/Motivation

Given a relatively optimized setup (PHP 5.5 with OpCache enabled, no xdebug/xhprof), super simple pages like /contact take 190–200 ms on my computer to generate. That's ridiculously slow.

So I did some profiling and easily found a piece of tasty low-hanging performance fruit: toolbar_pre_render().

The Toolbar module has optimized the rendering of the menu tree, by aggressively caching it. But… the rendering of the "main" toolbar (the black bar at the top of the page, with the white trays underneath it if you click any of the black items) is not yet cached.
Render caching the "main" toolbar seems easy enough, but the user tray is personalized for each user and the shortcuts tray is not by default, but might be. The easiest solution for that is to cache the toolbar per user, but that easily becomes very expensive.

Proposed resolution

The only mechanism that we have to cache per role but still be able to personalize per user is #post_render_cache. If we apply that, we get the following improvements (measured using the excellent https://drupal.org/project/webprofiler), using PHP 5.5 with OpCache enabled:

/

	Before	After	Δ
DB queries	183	150	-33
Response time (ms)	Variance too high.
Memory (MB)	13.8	13.2	-0.6
Cache gets	74	66	-8
Config gets	50	46	-4

/node/1

	Before	After	Δ
DB queries	173	140	-33
Response time (ms)	Variance too high.
Memory (MB)	13.8	13.2	-0.6
Cache gets	73	65	-8
Config gets	54	50	-4

/contact

	Before	After	Δ
DB queries	136	103	-33
Response time (ms)	~190	~170	-~20
Memory (MB)	11	10.2	-0.8
Cache gets	46	38	-8
Config gets	41	37	-4

Remaining tasks

Review.

User interface changes

None.

API changes

None.

Postponed until

#2099131: Use #pre_render pattern for entity render caching

Create Files to enable end user to migrate Content Types from Drupal 7 to Drupal 8.

Problem/Motivation

TBD

Proposed resolution

TBD

Remaining tasks

TBD

User interface changes

None.

API changes

None.

General summary

• This is not considered a beta blocker or critical issue for D8.
• While patches exist in this thread for D7 (and may work for you), official fix will be to D8 first -- please do not switch issue metadata until we are ready to start the D7 backport.

Problem/Motivation

When you have a template suggestion available and are using that template, preprocess functions following naming conventions provided via hook_theme_suggestions_HOOK() are not being recognized, for example:

MYTHEME_preprocess_node__article()
MYTHEME_preprocess_block__search_form_block()
MYMODULE_preprocess_page__front()
MYMODULE_item_list__search_results()
etc.

Proposed resolution

Add a post-process step to the theme registry build to look for these types of preprocess functions and add them to the theme registry.

Remaining tasks

Patch needs review.

User interface changes

N/A

API changes

Removes the global drupal_group_functions_by_prefix() (moves it to a class to make things testable) which was added May 13, 2015: #2339447: Improve theme registry build performance by 85%

Beta phase evaluation

Related Issues

• #2229355: Field template suggestions are colliding
• #2307103: Follow-up: remove explicit comment field theme hook suggestion implementation via #1962846: Use field instance name for header of comment list, drop comment-wrapper template
• #2231853: Rename maintenance-page template into page--maintenance + install-page into page--maintenance--install is working around this issue
• this issue is blocking #1885714: Remove theme_install_page()
• also appears to be blocking #2231853: Rename maintenance-page template into page--maintenance + install-page into page--maintenance--install?

Problem/Motivation

Last week, at Drupal Dev Days Montpellier, we (@klausi, @fago, @derhasi, @fubhy, @bojanz, @mariancalinro, and @Xano) had a long and fruitful discussion about managing Composer dependencies for modules in Drupal 8. We learned a lot, but also discovered that allowing modules to be placed into applications the 'old' way (putting a package in a modules folder) will inevitably lead to critical failures (fatal errors if required classes do not exist) if those modules require Composer packages.

As Composer Manager is only a temporary solution (I will yield the floor to @bojanz here, as he can explain its limitations much better than I can), we realized that Composer-driven development is possibly the only solution that prevents people's sites from breaking badly because of missing dependencies. This means that Drupal applications can no longer be built by putting contributed modules in a modules folder, but that the application requires one primary Composer file that manages all dependencies, including Drupal core and contributed modules.

There are several reasons why we should allow modules to specify dependencies through Composer:

• Getting off the island (better integration with other PHP systems)
• Reducing maintainers' workloads by allowing them to reuse much more existing code than they've been able to use before. This reduces development time, increased quality, and could go a long way to prevent burnouts.

This proposal leaves the functionality to enable and uninstall modules through the module handler (and therefore the administrative UI) intact. It only covers the approach we use to assemble the code base.

Proposed resolution

• Remove the update manager (#2352637: Remove the UI for installing/updating modules from update module if it is not fixed in time for release).
• Make http://packagist.drupal-composer.org/ an official Drupal Packagist repository (and document it is).
• In order to help non-coders, develop a browser plugin or drupal.org functionality that lets people 'shop' for contributed projects and assemble a composer.json file using point-and-click actions.
• Document that to build a Drupal site, people will now be able to run Composer (and therefore PHP) on any computer/server they have access to, so the Composer dependencies can be pulled in.
• Remove packaged modules with Drupal 8 compatibility from drupal.org and replace them with Composer instructions.

Remaining tasks

To be determined.

User interface changes

• #2352637: Remove the UI for installing/updating modules from update module if it is not fixed in time for release
• drupal.org will no longer feature file downloads for Drupal 8 modules, but instructions on how to build Composer files instead.

API changes

Modules can no longer simply be downloaded and placed in a modules directory, but have to be placed within a Drupal application to Composer.

Steps to reproduce:

1. D8 standard install on a single web server, with a decent amount of procs (mine had 40)
2. Send a bunch of traffic at it
3. rm the container
4. Watch it rebuild endlessly

This has been a tricky issue to track down, and I'm not 100% sure what the cause is, but I think it might be something like this:

When one web detects that the container doesn't exist (for whatever reason), it starts to build the new one, which involves unlinking the containing directory. Another process tries to load the container, sees it is missing (because the directory was unlinked), so it also starts the process of rebuilding. Processes continue this cycle of rebuilding.

I just triggered this in my test environment where I rm'd the container at 15:18. It's been constantly rebuilding itself since. Last line in my log is 16:05, but it's showing no signs of stopping.

This also results in a buildup of temporary containers written to files/php/service_container/ with a "." prefix. For some reason these get left behind in a stampede. That directory is currently at 400M in my test env, but I've seen it get to a few gigs before.

Problem/Motivation

MAINTAINERS.txt still uses the old machine URLS, e.g. user/1 to link to user profiles.

Proposed resolution

Update MAINTAINERS.txt to use the new human URLS e.g. u/dries.

Remaining tasks

1. Update for 8.0.x
2. Update for 7.x

User interface changes

API changes

Follow-up to #2389735: Core and base theme CSS files in libraries override theme CSS files with the same name

Problem/Motivation

stylesheets-override and stylesheets-remove as is don't necessarily give you the level of granularity needed to meet real world use cases.

Proposed resolution

From @Wim Leers in #9

We discussed this before at some point. I think the solution lies in fully embracing the asset-library-based Drupal 8, and thus removing any remnants from the individual-asset-based past.

That means:

libraries-override

The ability to override entire libraries and parts of libraries:

libraries-override:
  # Replace an entire library
  core/drupal.collapse: mytheme/collapse<br>
  # Replace one particular library asset with another.
  subtheme/library/css/theme/css/layout.css: css/layout.css
  # Remove one particular asset.
  drupal/dialog/css/theme/dialog.theme.css: false

Note that we could even omit libraries-remove if we'd allow

libraries-override:
  # Remove an entire library.
  core/modernizr: false

That would cover the use cases of stylesheets-override and stylesheets-remove.

(Note that this is basically a declarative form of hook_library_info_alter().)

Remaining tasks

1. Add libraries-override

User interface changes

N/A

API changes

API additions.

Beta phase evaluation

Problem/Motivation

LanguageManager::getDefinedLanguageTypesInfo() calls t() 52 times on an anonymous request to node/1 with the standard profile and warm caches.

This is to translate... the human readable names of the language types, of which we have two.

Proposed resolution

Two options:

1. Move this to a class property, that would save 50 calls.

2. Move the responsibility of translating the strings to the code that renders them (in practice,hardly ever on any occasion for this). They could be marked as translatable strings using nt() or similar. I'd prefer this, and then using it for other things as well. With render caching fully implemented, we should not be translating any strings at all with warm caches - which will save some service/cache initialization as well as the function calls.

Remaining tasks

User interface changes

API changes

Follow-up to #2407195: Consider removing template_preprocess_html() by modifying HtmlRenderer::renderResponse() and introducing HtmlResponse

Problem/Motivation

<?php
       $ajax_page_state = $this->requestStack->getCurrentRequest()->request->get('ajax_page_state');
?>

is wrong.

Proposed resolution

Should be:

<?php
       $ajax_page_state = $this->requestStack->getCurrentRequest()->get('ajax_page_state');
?>

but needs tests coverage.

Remaining tasks

- Fix it
- Write tests
- Commit

User interface changes

- None

API changes

- None

Problem/Motivation

Visiting node/1 with the standard install, anonymous, no page cache, warm caches, takes 39,000 function calls.

Equivalent Drupal 7 requests are between 5-10,000 function calls.

One of the worst offenders is Drupal::service() - this is called 397 times, and there are stack calls underneath it, so it's responsible for thousands of function calls.

One of the biggest callers of Drupal::service() is t()

One of the biggest callers of t() is system_region_list()

system_region_list() is called three times during the request. It has no static cache. It ends up translation the region names 60 times. 60 calls to t() = ~542 function calls.

We never print the region names except in block admin.

Proposed resolution

Don't translate the fucking human readable region names when we only want the machine names anyway.

Don't know exactly how much this saves, but it's probably 2-3ms per request. However this is for every single request assuming a site has block module enabled.

There's an extra hidden bonus. Once this is removed, we only have 21 calls to t() on this page. If we remove those, we'd also save initializing the translation service, and fetching the locale cache (when not viewing the site in English) - this is very feasible to get to I think.

Remaining tasks

TBD.

User interface changes

None.

API changes

Extra param to system_region_list()

Proposed commit message (D7)

Problem/Motivation

Drupal occurs a performance deficit when multiple filenames (ie. modules, themes) are missing or moved. The deficit occurs because we do a file scan perpetually to look for missing modules on certain pages, such as admin/config.

Proposed resolution

For D8: We remove the "missing file scan" that happens in drupal_get_filename() altogether and do various workarounds to deal with this scan in places where we haven't cached file locations yet, such as in the installer and in some tests (see #351). Instead of a file scan, we now do a trigger_error(), informing the developer/administrator about the missing file.

For D7: We cache any missing files in a static variable as well as in cache_bootstrap (for 24 hours, or until we visit the themes/modules overview page). We also do a trigger_error() as soon as we find a missing file in the drupal_get_filename() call.

In a followup issue we can check for this in hook_requirements() as well.

Remaining tasks

None.

User interface changes

None.

API changes

In D8, we remove the file scan from drupal_get_filename(), which also affects drupal_get_path(). The lack of this is only a "problem" in the installer, in tests and during module rebuild, which are not part of the API.

Original report by mfb

This patch provides a performance boost for sites that are missing modules (common on old sites which have been maintained for many years). In this case, drupal_system_listing() and file_scan_directory() will be called over and over looking for missing modules on certain pages, such as admin/config.

This patch adds an additional static variable to drupal_get_filename() to store an array of mask-directory combinations that have been scanned. Once one scan has been performed for a particular extension in a particular directory, there is no need to run the same scan later in the same request.

This information will be cached in 'drupal_get_filename:missing' in cache_bootstrap as well. Invalidation of this cache happens upon running cron, and upon visiting the themes/modules overview pages.

Beta phase evaluation

Problem/Motivation

Steps to reproduce.

Install 8.x
drush pm-uninstall page_cache
Visit front page
drush cr
Visit front page again
Notice (in xhprof) that twig templates have to be compiled again - takes more than 1 second on my machine.

Proposed resolution

Add an intermediate cache, probably using FileCache. Check there first before re-compiling.

There are two things that determine the compiled template;

1. The contents of the twig template (easy)
2. Any changes to how Twig compiles the templates (not so easy to account for and I'm not up to date on that at all)

Additionally, consider whether it is worth pre-compiling these in the d.o packaging script.

Remaining tasks

User interface changes

API changes

Problem/Motivation

ConditionManager uses the ContextAwarePluginManagerTrait, which contains the public method getDefinitionsForContexts().
However, that method isn't backed by any interfaces.

Most code uses ExecutableInterface, which is only a subset of the methods available.

Proposed resolution

Add a ConditionManagerInterface that implements both ExecutableManagerInterface and ContextAwarePluginManagerInterface
Use that interface for typehinting throughout

Remaining tasks

User interface changes

API changes

Beta phase evaluation