I noticed database backups for a D8 site in production started to get incredibly large (before launch, the database was a few MB in size; now it's more than 10 GB—with no substantial change in the amount of content, users, or blocks on the site in that time).

Glancing through the database, I noticed that after launch, the cache_render table has grown enormous—currently 9.6GB and growing—and the only way to trim it's size is to run a cache clear (e.g. drush cr).

It seems others have run into this issue as well:

• Help! cache_render grows extremely big in Drupal 8
• Why is cache_render very big?
• Help, my Drupal 8 database is huge

When I was digging through the table, I noticed a couple of blocks with views exposed forms seemed to take up 100,000+ rows; I'm guessing there's a row for every exposed filter permutation on every page/URL where the block appeared...

Two questions as a result:

1. Should this cache table ever be cleaned up / garbage collected? (Or do I need to run a cache clear on a regular interval...?)
2. Is there any way to easily exclude a given block or other renderable object from being cached in the cache_render table?

More Seven Theme issues:#1986434: New visual style for Seven

Short version: The style guide for the updated default Seven admin theme proposes to use the Source Sanse Pro font. Source Sans Pro is not only free but open source, available under the SIL Open Font License (OFL). We propose to include a webfont version of Source Sans Pro be included with the Seven theme.

1. Figure out if we can, license-wise
2. Decide if we will (our rationale below)
3. If so, do it

Rationale for the use of Source Sanse Pro

This guide proposes all text be set in Source Sans Pro from Adobe. Similar in character to Lucida Sans (the existing typeface specified by Seven), Source Sans is a professionally designed, fully open-source type family that falls into the general category of “humanist sans-serif”. Fonts of this type combine the modern geometric and industrial-age characteristics of sans-serif typefaces with the calligraphic and handwritten qualities of Renaissance letterforms. This balance of the engineered and the human matches well with the Drupal brand.

Seven’s original choice of Lucida was a good one for those same reasons, but also for a very practical one: legibility in UI. Source Sans is arguably even better in this respect, with glyphs such as lowercase L and upper/lower I all easily distinguishable from one another, even at small sizes. This is one of many details to consider when choosing a typeface for UI work, and where some common choices – like Helvetica – fare poorly.

Source sans also provides a versatile set of weights, including a semibold.

Licensing

Source Sans is one of the few professionally-designed typefaces that is not only free but open source, available under the SIL Open Font License (OFL). However, it is unclear whether the OFL would allow it to be included as part of Drupal core. The Wikipedia page on OFL states that it is not GPL-compatible. However, SIL’s own FAQ states, under a question about bundling with GNU/Linux that “Fonts licensed under the OFL can be freely included alongside other software under FLOSS (Free/Libre and Open Source Software) licenses. Since fonts are typically aggregated with, not merged into, existing software, there is little need to be concerned about incompatibility with existing software licenses.”

Provided the OFL license is compatible and the community supports it, this guide proposes that a webfont version of Source Sans Pro be included with the Seven theme. To keep file size and HTTP requests down as well as to simplify the design system, not all of the fonts that make up the complete type family would need to be included. This guide uses the Regular, Italic, Semibold and Bold fonts.

So to repeat the main points:

1. Figure out if we can include the font files in the Drupal project, license-wise
2. Decide if we will
3. If so, do it!
4. If not, figure out if we can find a way to download the files from an external server without harming UX.

Related Issues

• #1986434: New visual style for Seven

Problem/Motivation

Noticed as part of #2501683-46: Remove SafeMarkup::set in _update_message_text()

the words "available updates" linking to two different pages in the same paragraph

Unknown release date (version 8.0.0-beta11 available)
There was a problem checking available updates for Drupal. See the available updates page for more information and to install your missing updates.

steps to reproduce

1. install d8 head
2. log in as admin
3. go to admin/reports/status

Proposed resolution

change one of the links to better indicate where it goes

Remaining tasks

User interface changes

No new patterns. Change in links in text.

API changes

No.

Data model changes

No.

The template file links.html.twig has a lot of whitespace modifiers. These dashes here, {%- if heading -%}

They were originally added when the template was converted, but don't seem to serve a purpose and can be removed. They might have been there originally for tests but joelpittet confirmed they aren't needed for that now. See the patch here, https://www.drupal.org/node/2465399#comment-9829099

If they can be removed, remove them from the template in the System module, and the template in Classy. To determine if they can be removed we need to look for any instances where links might be rendered inline. That is a place where whitespace could be an issue.

Also, this template has a wrapping if statement:

{% if links -%}
...
{%- endif %}

The if was a direct copy of functionality from when this was a theme function. We cannot verify why it is still needed. Investigate whether it can be removed, and, if so, remove it.

If this issue is worked on after #2455211: Comment field displayed last regardless of assigned weight gets committed, investigate removing the if from the links template in Bartik, as well.

Update : Made the changes in the core links.html.twig template to fix the white-spaces issue as mentioned by Cottser
https://www.drupal.org/node/2472591#comment-10878510

Beta phase evaluation

Problem/Motivation

This is mostly a follow-up to #2112679: getUsername() should return the username getDisplayName() for the formatted user name where some minor consensus was reached about removing hook_user_format_name_alter(). See: https://www.drupal.org/node/2112679#comment-10356635

This comes about because we let contrib change the user name through hook_user_format_name_alter() for reasons that have a lot of down-side and not a lot of up-side, mostly inherited from the time before there were fieldable user entities.

Proposed resolution

Remove hook_user_format_name_alter() and keep the account name as something only core can touch.

Remaining tasks

1. Cogitate.
2. Confab.
3. Consense.
4. Commit.

User interface changes

API changes

Data model changes

Hi,

I just spotted a small error in the Drupal documentation: http://cgit.drupalcode.org/drupal/tree/core/modules/language/src/Form/Ne...

The following patch fixes it.

In drupal_http_request(), the request body must be provided as a URL-encoded query string. It would be more convenient to be able to provide this as an array and have the function call http_build_query() on it automatically. Patch coming.

Problem/Motivation

All our render cache entries like page, entities, blocks, views and so on are by default cached forever.

That's great. Except when you have a lot of data + a lot of variations and a cache backend that doesn't support something like LRU like the default database backend. Then your cache table will grow and grow and it's suddenly not so great anymore :)

You could argue that sites with a lot of data should use redis/memcache and not the database but also medium-sized with not so many users could run into problems eventually, also in regards to copying the database around since only few people remember to ignore cache tables.

Proposed resolution

Either the render cache service or the database backend (per-bin) should support an upper limit for the max-age. E.g. a day or a week. It would probably be great to vary that slightly for every write, e.g. +/- 5% so not all cache entries expire at the same time.

Remaining tasks

User interface changes

API changes

Data model changes

The unit tests of Block_content's Migrate source plugins should be changed to the base class introduced in #2791119: Write meaningful Migrate source tests.

Problem/Motivation

Url::toUriString() doesn't work properly for user input. User input is expected to contain the leading slash. The toUriString() method does not render it out.

Proposed resolution

???

Remaining tasks

???

User interface changes

None.

API changes

None.

Data model changes

None.

Problem

Variable caching has a number of inter-related issues.

Memory and cache object size
All variables are loaded from the {variables} table regardless of whether they're in use or not, and some older Drupal sites can have over 2,000 variables in the table since many dynamic variables (and etc.) are not properly tracked between upgrades and module uninstalls. This leads to a large cache item, and since it is assigned to a global, also high memory usage in the critical path. The cache item size ranges from around 100k on a brand new site to 1.4mb or more on a site with lots of contrib modules that has been around for a while.

Locking
When variable_set() is called (which some modules and even core doa lot, the variable cache is cleared entirely. It then has to be rebuilt in full by the next request. In Drupal 7 we added a lock so that only one request does this at a time, which prevents a stampede on the variable cache itself, but can also mean processes hanging around waiting until the single process that acquired the lock is done - since it is a global read lock on every single process that hits the Drupal install.

If you have an operation that involves a large number of variable_set() - for example rebuilding css and js aggregation with a large number of bundles - #886488: Add stampede protection for css and js aggregation, or a failing drupal_http_request() due to a third party service going down, #959620: drupal_http_request() can lead to variable_set() stampede, then this happens:

* Process 1 calls variable_set(), clears the cache.
* Process 2 acquires a lock, starts to rebuild the cache.
* Processes 3-200 all get a cache miss and fail to acquire the lock - since this is variable_initialize() that's for every single request to the site - cached pages, imagecache generation, you name it.
* Process 2 frees the lock after 100ms or so.
* Process 4 acquires the lock since it wants to do a variable_set() again.
* process 5-200 are still waiting.
* Despite load being low, apache runs out of spare threads, connections get backed up etc.

Proposed solution
Since the variable cache is a single array that includes lots of stuff that is rarely used, it is a good candidate for DrupalCacheArray. This has the following benefits:

- variables that are stale in the database or only requested very rarely don't get put into the cache item.
- there is no longer a need for a global read lock on the site (however we add a write lock for writes to reduce race condition windows - something that does not exist in core now).
- The variable cache is converted to write-through - so there is no need to do a full rebuild each time there is a cache clear.
- Because DrupalCacheArray builds up the cache object over time, the first few requests can issue a dozen or three small database queries instead of waiting for a massive db_query() and unserialization of hundreds or thousands of items before they're able to complete, which should reduce performance spikes on cold starts (with the trade off of some extra writes to the cache as it gets built).

Problem/Motivation

The module install form (admin/modules) has two buttons that do different things:

• Install new module downloads and installs a module
• Install installs the modules that were selected on the form

At the top is:

In HEAD, the bottom link is:

But the consensus is to change it to:

This has confused at least a few people on this issue.

Proposed resolution

Rename the first button "Add new module".

Remaining tasks

User interface changes

Yes, button rewording.

API changes

Data model changes

Problem/Motivation

We want Drupal 8 to be fast by default. One aspect of being fast by default is the front-end performance, and one aspect of that is the amount of data we send to the browser. JavaScript minification can be a huge help in that regard, but has long been impossible, for multiple reasons:

1. The most fundamental blocker. Drupal <8 used to be developer-friendly by default rather than fast by default, which meant that if we'd ship with JS aggregation/minification enabled by default, we'd have to detect file system changes on every request, which would be detrimental for performance. #2226761: Change all default settings and config to fast/safe production values changes that: aggregation can be enabled by default, and when developing, it's easy to disable aggregation.
2. The secondary blocker. Far too often, we don't know and cannot determine the license of an asset!#2276219: Asset libraries should declare their license addresses that.
3. The tertiary blocker. The license problem: proper minification deletes all non-essential data, including license information. That's the part this issue addresses.
4. The last mile. We couldn't find consensus on which JS minification tool to use. This issue doesn't aim to solve that, it only aims to make it possible to add JS minification at a later point in time to Drupal 8, since adding that is not an API change, it's improving an existing feature. (Our current "minification" strategy is: "just use the entire file, and append a defensive semi-colon".) That could even happen after beta 1 (see #3).

Proposed resolution

Required reading:

• http://www.gnu.org/licenses/javascript-labels.html (referred to as "JSLWL" from now on)
• http://www.gnu.org/philosophy/javascript-trap.html#AppendixA
• Live examples of JavaScript License Web Labels: https://www.eff.org/librejs/jslicense, https://weblabels.fsf.org/www.fsf.org/CURRENT/

In essence, JSLWL requires us to list every JS file on the site, with its license and full source.

So, the proposed solution takes these steps:

1. #2276219: Asset libraries should declare their license associates the license information with each asset library.
2. This allows us to generate a "JavaScript License Information" page, as mandated by JSLWL. We link to that page on every Drupal page that contains any JS. And on that page, we can list every JS asset along with its license, thanks to 1.
3. However, we must also list the license and source for aggregated JavaScript assets (which we want to be minified in the future). JSLWL allows us roughly 2 ways of doing that:
   

   The source code file can be a single, unminified JavaScript file, a .tar.gz archive, or a .zip archive. If a source archive includes multiple JavaScript files, the archive must include a file named 00-INDEX that lists the order in which individiual source files should be concatenated to produce a single file that's equivalent to what's hosted on the site.

   So either: an unminified aggregate, or an archive containing all aggregated JS files and a describing file. The latter is much more painful to do, so we choose the first, for which we already have the necessary infrastructure. The JS asset collection optimizer (asset.js.collection_optimizer) tracks its aggregated (and minified) JS files (we can get them via AssetCollectionOptimizerInterface::getAll()); by adding a secondary JS asset collection optimizer asset.js.collection_optimizer_license_web_labels_annotator which annotates each contained asset (with a link to the license information) without minifying it, we effectively get two key-value maps with the same keys (because the same collections of JS assets are passed to them and they use the same JS collection grouper) but with different files (one minified, another annotated and unminified). On the JSLWL "JavaScript License Information" page, we can now list the unminified annotated aggregate as the source for the minified aggregate.

Remaining tasks

Review.

User interface changes

None that are visible, but a new "JavaScript License Information" page at /system/jslicense.

API changes

1. (Not really an API change, but an internal behavior change.) An unminified aggregate is generated for every minified aggregate.
2. Route/response addition: /system/jslicense.
3. (Not really an API change, but a markup addition.) Each page has a <link rel="jslicense" href="/system/jslicense" /> tag in the HTML head.

With DBTNG we are extending the build in PHP PDO way of communication with different databases. The name for the build in method for rolling back transactions is PDO::rollBack() (with a capital B).
The corresponding method in D8 is called Drupal\Core\Database\Connection::rollback() (without the capital B). Lets correct that. This will not be an API change we can do this in a minor version.

The original find of this bug is from @axel.rutz, so please give him commit credits for it.

Problem/Motivation

Follow-up to #2779939: Cleanup the ModerationInformationInterface

ModerationInformationInterface::loadBundleEntity() is unnecessary and dangerous - it shouldn't be providing an API to load bundle entities. That's the job of other services.

Proposed resolution

Remove it and just load the bundles properly.

Remaining tasks

User interface changes

None

API changes

Removals:

• Rename ModerationInformationInterface::loadBundleEntity()

Data model changes

None

Problem/Motivation

1. Create a contact form, hide the default e-mail field. Configure an auto-reply response.
2. Send a message as anonymous user.
3. you get an error message about failed to send e-mail.

I had to debug this *twice* in the last two weeks on different client projects ;)

Proposed resolution

Check that there is an e-mail to send the auto-reply. If not, skip mail and log a *slient* error that tells you what wrong.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Drupal\Tests\Core\Database\UrlConversionTest started failing today on PHP 7 environments (all supported databases) on a docs commit with no functional code change since the last pass. @Mixologic suggested this might be a regression in PHP 7 itself

https://www.drupal.org/pift-ci-job/494059

There were 2 errors:

1) Drupal\Tests\Core\Database\UrlConversionTest::testDbUrltoConnectionConversion with data set #0 ('', 'mysql://test_user:test_pass@t...tabase', array('mysql', 'test_user', 'test_pass', 'test_host', 'test_database', '3306'))
InvalidArgumentException: Minimum requirement: driver://host/database

/var/www/html/core/lib/Drupal/Core/Database/Database.php:460
/var/www/html/core/tests/Drupal/Tests/Core/Database/UrlConversionTest.php:21

2) Drupal\Tests\Core\Database\UrlConversionTest::testDbUrltoConnectionConversion with data set #1 ('/var/www/d8', 'sqlite://test_user:test_pass@...tabase', array('sqlite', 'test_user', 'test_pass', 'test_host', '/var/www/d8/test_database', 3306))
InvalidArgumentException: Minimum requirement: driver://host/database

/var/www/html/core/lib/Drupal/Core/Database/Database.php:460
/var/www/html/core/tests/Drupal/Tests/Core/Database/UrlConversionTest.php:21

Proposed resolution

TBD

Remaining tasks

Mixologic proposed overriding test discovery so that only this test is run, to confirm that it also happens in isolation.

Could also be confirmed (or not) locally by someone with a PHP 7 dev setup with the latest PHP 7 dev version.

Drupal 8.2.0.

Field label appears even though marked as "hidden" under display settings for the relevant content type.

Can vanish in CSS display: none but there's a bug here I guess.

The CSS The drupal_html_class() function should allow uppercase characters to pass through. Currently it passes all strings through drupal_strtolower() without any clarifying reason as to why this is done. Also, our CSS standards do not clarify this point either.

The website encountered an unexpected error. Please try again later.
Recoverable fatal error: Argument 1 passed to Drupal\Core\Field\WidgetBase::massageFormValues() must be of the type array, string given, called in core/lib/Drupal/Core/Field/WidgetBase.php on line 376 and defined in Drupal\Core\Field\WidgetBase->massageFormValues() (line 513 of core/lib/Drupal/Core/Field/WidgetBase.php).
Drupal\Core\Field\WidgetBase->massageFormValues('', Array, Object)
Drupal\Core\Field\WidgetBase->extractFormValues(Object, Array, Object)
Drupal\Core\Entity\Entity\EntityFormDisplay->extractFormValues(Object, Array, Object)
Drupal\Core\Entity\ContentEntityForm->copyFormValuesToEntity(Object, Array, Object)
Drupal\Core\Entity\EntityForm->buildEntity(Array, Object)
Drupal\Core\Entity\ContentEntityForm->buildEntity(Array, Object)
Drupal\Core\Entity\ContentEntityForm->validateForm(Array, Object)
call_user_func_array(Array, Array)
Drupal\Core\Form\FormValidator->executeValidateHandlers(Array, Object)
Drupal\Core\Form\FormValidator->doValidateForm(Array, Object, 'node_edit_form')
Drupal\Core\Form\FormValidator->validateForm('node_edit_form', Array, Object)
Drupal\Core\Form\FormBuilder->processForm('node_edit_form', Array, Object)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
call_user_func_array(Object, Array)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1)
Stack\StackedHttpKernel->handle(Object, 1, 1)
Drupal\Core\DrupalKernel->handle(Object)