When developing Kernel test, it was found that after applying the patch, that the time to run Kernel test was reduced by between 25% and 33%. Before applying the patch, the code created a file database called ':memory:' in the application root directory and to remove it and not use the SQLite in memory database functionality.

Here is example XML element in phpunit.xml for file based SQLite database in the /tmp directory called test.sqlite.
<env name="SIMPLETEST_DB" value="sqlite://localhost//tmp/test.sqlite"/>

Here is example XML element in phpunit.xml for file based SQLite database in the application root directory called test.sqlite.
<env name="SIMPLETEST_DB" value="sqlite://localhost/test.sqlite"/>

Here is example XML element in phpunit.xml for in memory SQLite database
<env name="SIMPLETEST_DB" value="sqlite://localhost/:memory:"/>;

See http://php.net/manual/en/ref.pdo-sqlite.connection.php for more information about using a in memory database.

Please note

• In memory database is not shared between the client and server programs when running Functional or Functional-JavaScript unit tests and hence failures.
• A database is not needed for Unit tests.

Problem/Motivation

Originally, some work was started in #2430335: Browser language detection is not cache aware to resolve a caching issue. A language redirect was introduced, but the implementation was more general than just adding the language prefix. The target redirect URL was constructed from current route. This caused some test fails (especially, in case if this redirect is enabled always even if the language module is not installed, see 2430335#89). And this issue was created.

Current implementation

There is a new route_normalizer_request_subscriber service that perform redirects like the Global Redirect module. On a GET request, it construct a URL from the current route and the current route/query parameters, and redirects to that URL if it does not match the incoming URL. This causes:
- language redirect, for example from "/" to "/en", this resolves #2430335: Browser language detection is not cache aware
- path alias redirect, for example from "node/1" to "content/my-node"
- front page redirect, for example from "/node" to "/"
There can be more cases, but they are unknown at the moment.

Also, the patch contains some fixes for bugs caught during development, and some documentation changes.

Arguments for this feature:
- globalredirect has a lot of installations, people might need this feature in the core
- better SEO
- less cache entries
- it allows to catch bugs at early development stage (check the fixes provided in the patch)

Remaining tasks

- fix remaining test fails
+ write tests
- try to use CacheableRedirectResponse

User interface changes

The default Drupal installation will behave like the one having the Global Redirect module enabled.

API changes

The "disable_route_normalizer" request attribute can be set to disable the route normalization:

$request->attributes->set('disable_route_normalizer', TRUE);

Data model changes

none

$this->t() should be used for translation.

Problem/Motivation

Labels defined in a module's module.layouts.yml are not translatable.

Proposed resolution

N/A

Remaining tasks

Make labels (and possibly other strings defined in module.layouts.yml) translatable.

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Problem/Motivation

Revisionable entities with custom layout override only track layout changes incidentally when an entity is saved via the entity's edit form. In order to provide full layout revisioning, we should check that the entity type's bundle is revisionable and whether or not a new revision should be created before calling entity save in the Section Storage object.

Proposed resolution

Section storage for the field should determine if the entity's bundle is RevisionableEntityBundleInterface and check shouldCreateNewRevision(). If this is "true" then a new revision should be set on the entity before saving.

Remaining tasks

Write a patch
Write tests
Convince people

User interface changes

No direct changes to the UI. Layout saves for entity override would prompt the creation of new revision which would display the entity's revision tab. That "ui change" is incidental and expected.

API changes

None

Data model changes

None

Problem/Motivation

Since #2957425: Allow the inline creation of non-reusable Custom Blocks in the layout builder (for a lot of use cases), the per-entity layout override page became the primary interface a content author might use to create and manage content that is displayed when a user is viewing an entity.

At the same time, discussions are taking place around how the layout pages are going to fit in with other modules like content moderation, core features like optionally creating new entity revisions and the existing CRUD entity access permissions and APIs.

A lot of the solutions proposed so far have been around enhancing the functionality of the per-entity layout builder form in order to bring it closer in line with the existing ways that entities are treated during standard content editing in the "Edit" tab. That is, we've seen proposals across various issues such as:

• Load the latest revision of an entity (to mimic the changes content_moderation applies to entity forms).
• Create new revisions of an entity automatically when updating a layout (when the user has selected such an option on the bundle form).
• Add additional access checks to the override storage for the "update" operation based on the layouts host entity.

I think these are all good initiatives to enhance layout builder and increase integration, but I wonder if the root of what we're trying to accomplish here is to mimic all of the semantics that have already been built into entity forms. Could the layout builder override page be some kind of special entity form, that has easy or even automatic integration with other modules that have an expectation that entity forms are the primary mechanism of content authoring?

Using content moderation as a case study (since I am most familiar with this module), I believe the existing proposals to integrate with layout builder fall short because:

• The layout override form is the encouraged mechanism for authoring new content.
• Applying a moderation workflow to fields on the entity is redundant if those fields can be replaced with a non-reusable block and skip moderation altogether.
• If a user transitions an item of content to state "Foo", they are not necessarily allowed to create new content revisions while leaving the state unchanged (think of something going into review, with an author no longer able to make changes to that content until a review has been completed).

The only way I see these two modules integrating in a way that is true to the sprit of both feature sets: rich content driven layouts/moderated content workflows, is if:

• Entity "update" access is respected. (see related issue)
• The latest revision is loaded. (see related issue)
• The same moderation state transition widget is visible and available when saving the layout override form which allows the authoring of new content. (no related issue in discussion)

I believe if the layout override page was an entity form, we would almost get this level of integration automatically/for free. I also believe there are probably a lot of other authoring related contrib modules which would also benefit from such an affordance.

It would also flip the requirement for layout builder to integrate with every other module, it would instead use entity forms as the common and existing pattern for controlling the lifecycle of content authoring as the basis for compatibility and integration.

Proposed resolution

This part would largely be open for discussion. One possible approach could be:

1. Allow the layout builder form to operate as a field widget over the top of the layout_builder__layout field.
2. Create a transient EntityFormDisplay object connected to an entity form route, configured with only the components relevant to layout builder. Here is an example of this in action, and @eclipsegc mentioned ctools also uses this concept.
3. Ensure adequate metadata exists in the form/route for modules to make decisions about adding components to the entity form where required. Modules that indiscriminately deal with entity access or entity forms would integrate easily or automatically.

Sandbox prototype: https://www.drupal.org/sandbox/sam/3008758
Video demo: https://www.youtube.com/watch?v=GT-bf_7o3cY

Remaining tasks

Discussion!

User interface changes

TBD.

API changes

TBD.

Data model changes

TBD.

Postponed on:
#2999962: Unify Database/Log::findCaller and Utility/Error::getLastCaller

See #2848161: [meta] Replace calls to deprecated db_*() wrappers.

Replace all usages of db_query in core, except in code that is testing db_query.

Steps to create scripted patch:

• Script to do the majority of the work
  

  # Replace the occurrences in code.
  find ./core/lib -type f -exec sed -i -r 's/db_query\(/Database::getConnection\()->query\(/g;' {} \;
  find ./core/tests -type f -not -path "./core/tests/Drupal/KernelTests/Core/Database/*" -exec sed -i -r 's/db_query\(/Database::getConnection\()->query\(/g;' {} \;
  find ./core/tests/Drupal/KernelTests/Core/Database -type f -not -path "./core/tests/Drupal/KernelTests/Core/Database/SchemaTest.php" -not -path "./core/tests/Drupal/KernelTests/Core/Database/QueryTest.php" -exec sed -i -r 's/db_query\(/$this->connection->query\(/g;' {} \;
  find ./core/modules -type f -exec sed -i -r 's/db_query\(/Database::getConnection\()->query\(/g;' {} \;
  find ./core/tests/Drupal/KernelTests/Core/Database/LoggingTest.php -type f -exec sed -i -r "s/call_user_func_array\('db_query'/call_user_func_array\([\$this->connection, 'query']/g;" {} \;
  find ./core/tests/Drupal/KernelTests/Core/Database/SchemaTest.php -type f -exec sed -i -r 's/db_query\(/Database::getConnection\()->query\(/g;' {} \;
  find ./core/includes/form.inc -type f -exec sed -i -r 's/db_query\(/Database::getConnection\()->query\(/g;' {} \;
  find ./core/scripts/ -type f -exec sed -i -r 's/db_query\(/\\Drupal::database\()->query\(/g;' {} \;
  # Start using \Drupal::database() or inject service
  find ./core/modules/tracker -type f -exec sed -i -r 's/Database::getConnection\(/\\Drupal::database\(/g;' {} \;
  

• The files that requires to manually add use Drupal\Core\Database\Database; row. See interdiff at #26
• Fix the replacements in the comments. See interdiff #27

Problem/Motivation

As per discussion in the weekly Layout Initiative meeting #2972783: [Weekly Meeting] 2018/05/15 we need to decide how Layout Builder should function with Content Moderation and Workspaces modules and detailing the complexities.

These decisions have an impact on how issues like #2937199: Track Layout override revisions on entities which support revisioning and #2957425: Allow the inline creation of non-reusable Custom Blocks in the layout builder should be implemented.

Proposed resolution

n/a

Remaining tasks

Discuss and make decisions.

User interface changes

n/a

API changes

n/a

Data model changes

n/a

After upgrading to 8.4 we noticed a performance decrease on one of our sites. The page that is taking minutes to load is a multilanguage page with several field collections and revisions enabled.

Some debugging lead me to the change in issue 2864995.

This change introduces a latestRevision() method which is used by QuickEdit (this explains why it is only when logged in). On a field collection that has about 4000 revisions, this query takes seconds to run.

If I understand correctly the change introduces a self-join to the base revision table. Because of this, for each revision in the table, a set of revisions + next revisions is added to the result. From this result only the row that has no next revision (is null) is used (in my case 7000000 rows are searched for the one that has no next revisions).

Maybe we can think of a more efficient way of querying the latest revision?

Problem/Motivation

The \Drupal\views\Plugin\views\field\LinkBase::render() method is presuming too much by not rendering a link whose destination page is not accessible by the current user. The actual behaviour could cover most of the cases but there are still business scenarios when a role should be able to list content, including the URL, but still without the ability to access the content page. This is somehow similar to view label entity access introduced in https://www.drupal.org/node/2661092.

Not having access to a content item, doesn't mean automatically that the content's address cannot be read.

Proposed resolution

Add a new option "bypass_access" in \Drupal\views\Plugin\views\field\LinkBase that allows the site builder to bypass the access check when a link is rendered. The new option should default to FALSE, so the behavior of the actual will not be changed.

Remaining tasks

None.

User interface changes

New option as a checkbox the the Views link fields.

API changes

None.

Data model changes

Views config new option in fields.

Problem/Motivation

i18n site offline message is not migrated.

This is blocking
#2970849: i18n Variable to config: user settings and user.mail
#2970847: i18n Variable to config: system site settings [d7]

Proposed resolution

Migrate i18n variable, site offline message to config.

This is the first of the i18n variable migrations for Drupal 7 and includes a new source plugin because in D7 the variables are stored in the variable_store table, not variable, where the data may or may not be serialized. There is still much in common with the Drupal 6 VariableTranslation source plugin so a base class is added.

Remaining tasks

Write migration.
Write tests, includes updating the drupal7 test fixture.

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Problem/Motivation

- Create decimal field, set precision to 10 (minimum in the UI and scale to 4
- Saving new node with value 19999.0000 succeeds (precision is 5+4 = 9).
- Saving new node with value 99999.0000 fails (same precision as above).

or

- Create decimal field, set scale to anything over 6 (need 8 to store bitcoin values for example). I used 16 as precission.
- Saving new node with value 20.12345678 fails validation while 0.1234567 succeeds.

This is because Drupal\Component\Utility\Number::validStep() returns false. Detailed investigation on this function (which is only used once in Drupal), reveals that the first argument ($value) is received as a string, but $step and $offset are floats. PHP seems to slightly mangle the $step value on the first case above from 0.0001 to 0.00010000000000000001438. Passing the step parameter as a string in the case of decimal numbers maintains the correct precision, and allows a correct approximation calculation.

Proposed resolution

Bypass weak PHP floating-point handling by passing the step as a string.

Remaining tasks

Merge. Commit. Decimals FTW!

User interface changes

None.

API changes

A new field was added to the Number FormElement, in order to decide when to use the workaround. This "#number_type" field may be useful in other cases.

Data model changes

None.

Possible workaround if you need big decimals

Disable this validation by setting the render element #step to 'any'

i.e.

$element['#step'] = 'any';

In the case of fields, you can do

function MYMODULE_form_FORM_WITH_BIG_DECIMAL_FIELD_alter (array &$form, FormStateInterface $form_state) {
  $form['field_some']['widget'][0]['value']['#step']='any';
}

And if you want to target all decimal fields:

/**
 * Prevents validation of decimal numbers
 * @see https://www.drupal.org/node/2230909
 */
function MYMODULE_field_widget_form_alter(&$element, \Drupal\Core\Form\FormStateInterface $form_state, $context) {
  $field_definition = $context['items']->getFieldDefinition();
  if ($field_definition->getType() == 'decimal') {
    $element['value']['#step'] = 'any';
  }
}

I'm trying to setup a multilingual website with two languages. Website is going under Cloudflare and I have their HTTPS integration.

If i go to /admin/config/regional/language/detection/url and select "Path prefix" - everything works fine.

But if i select second option, which is "Domain" (english version is not default and goes to en.site.com subdomain) every ajax request is trying to go through HTTP instead of HTTPS. This causes mixed content errors, ajax requests are not being processed and website is not functioning, as expected. It can be anything: Views functionality, plupload widget, node type fields options selector, autocomplete fields - anything!

If I switch back to prefix (which is using site.com/en/ for example) - everything works fine.

To manage subdomains I use Domain Access module and it is set to use HTTPS in "Domain URL scheme" options. But I don't think that it has something to do with this module, because ajax breaks not only on subdomain, but on any page of the main domain as well.

I have a few blocks that have more links that point to URL's other than View pages. I've previously used the Footer section to provide these links, but thought it might be easier if I could enter a custom URL in the Link Display section for a block...

What do you think?

Problem/Motivation

CCK field options are translated using i18n_cck submodule of the suite i18n, we need to migrate those respecting the language.

Once an the option translation were working and rollbacks could be tested, the rollback on d6_field_option caused fatals. Turns out that EntityFieldStorageConfig does not handle translations. To fix this, EntityFieldStroageConfig::getIds() now adds the language code for translation destinations and EntityFieldStroageConfig::rollback() adds the language code to the destination id array. This array is now unusual in that the first key is 0 and the second key is langcode. Maybe this should be changed.

This then exposed an error in EntityConfigBase::rollback() in a loop that is building the destination identifier where the comparison of $key == 'langcode' always returns true (because $key is an integer) and the entity_id is not built correctly. Changing that comparision to strict fixes that and the rollback work.

Proposed resolution

Patch
Review
Commit

Remaining tasks

Write a test
Write a patch to migrate field labels and options.

Hi, thanks for this amazing module. It's really helpful :-)

On a multi-language site, there are errors popping up in watchdog looking for updated translations which are 404ing.

Example (Korean):
http://ftp.drupal.org/files/translations/8.x/twig_tweak/twig_tweak-8.x-1...

This is the only contrib module I have installed that is getting this error, and the others definitely don't have any translations. So, there's something going on with this module that is actively looking to find non-existent translations for all languages active on the site.

Problem/Motivation

When using the workspace UI with e.g. a custom theme that depends on the stable base theme, the workspace section in the toolbar looks like this:

The CSS added in the workspaces expects a wrapper div around the list of workspaces. In stable, the wrapper div is not added by default.

Problem/Motivation

\Drupal\views\Plugin\views\query\Sql::getCacheMaxAge and \Drupal\views\Plugin\views\query\Sql::getCacheTags both assume that the result of \Drupal\views\Plugin\views\query\Sql::getAllEntities is an array of Entity objects.

However \Drupal\views\Plugin\views\query\Sql::loadEntities sets missing entities to NULL.

This results in a fatal error:

Error: Call to a member function getCacheTags() on null in Drupal\views\Plugin\views\query\Sql->getCacheTags() (line 1552 of core/modules/views/src/Plugin/views/query/Sql.php).

This manifested with a view of content revisions linked to scheduled updates.

Sample view attached

Proposed resolution

Filter out nulls in \Drupal\views\Plugin\views\query\Sql::getAllEntities
Filter out nulls in \Drupal\views\Plugin\views\cache\CachePluginBase::getRowCacheTags too

Remaining tasks

tests

User interface changes

API changes

Data model changes

Problem/Motivation

This is a sister issue of #2517030: Add a URL formatter for the image field and #2825487: Fix normalization of File entities: file entities should expose the file URL as a computed property on the 'uri' base field. The former issue solved it for image entities exposed via Views REST export displays. This issue must solve it at the serialization/normalization level, so that all REST resources (as well as JSON API) benefit.

The latter issue already is doing it for FileItem (and hence ImageItem because it extends FileItem), but only for the "canonical" file URL. In the case of ImageItem, we also want image style URLs.

Proposed resolution

Add ImageItemNormalizer.

Remaining tasks

None.

User interface changes

None.

API changes

Adds an API to allow explicit bubbling of cacheability metadata: pass in a 'cacheability' => instanceof CacheableMetadata key-value pair in the serialization context.

(The ImageItem normalizer that we add here uses this to its advantage: this new capability allows that normalizer to be properly unit-testable. No more global state manipulation! See #67's interdiff.)

Data model changes

None.

On a website we enabled recently workflows and content moderation modules. At first we thought it was working great but we discovered that after editing a page it was impossible to edit the translation. This is the error shown in the log:

InvalidArgumentException: The state '' does not exist in workflow. in Drupal\workflows\Plugin\WorkflowTypeBase->getState() (line 155 of /home/dm166/www/core/modules/workflows/src/Plugin/WorkflowTypeBase.php).

I've found a relatively similar issue but even after updating to latest version and also on a fresh install from simplytest.me the bug is still present. Here is the similar issue: https://www.drupal.org/project/drupal/issues/2915398

Here are the steps to reproduce the issue:

1. Enable i18n modules (content translation, interface translation, language)
2. Add a language in admin/config/regional/language
3. Add the language switcher block in admin/structure/block
4. Enable page translation in admin/config/regional/content-language
5. Create a page in English and translate it
6. Enable the workflows and content moderation modules
7. Enable editorial workflow for “basic page” content type in admin/config/workflow/workflows/manage/editorial
8. Now you can edit the previous page in English, but after that if you try to edit the translated one you will have the error (preventing the edit page to be displayed)

I've made the priority major but I'm hesitating with critical since content in translated language can't be edited. The only "workaround" I've found is editing the code temporarily so that instead of throwing an error it set the state to "published".