Problem/Motivation

The \Drupal\views\Plugin\views\display\Block::preBlockBuild() method is responsible for manipulating the view before it is rendered by the corresponding block plugin. The block plugin itself actually calls this method, however blocks cannot show exposed filters without using ajax, and the ajax rebuild for views will not call the preBlockBuild() method.

As a practical example, blocks can override the number of results per page for a view, however if they leverage ajax rebuild, on the first rebuild (which is also used for pagers) the view will be rendered without the block's overrides. If the default view shows 50 per page, and the override shows 5, the first ajax call will result in the view now showing 50 instead of 5.

Proposed resolution

The views/ajax controller needs to consult the block when rebuilding block displays. Doing this generically is likely to be a bit convoluted.

Remaining tasks

Identify a solution.
Implement it.

User interface changes

Likely none

API changes

TBD

Data model changes

Likely none

Eclipse

After updating Drupal from 8.7.10 to 8.8.1 . It started throw error, while upload file in every file type field in the system.
For eg. Goto /admin/appearance/settings and uncheck checkbox Use the logo supplied by the theme. and try to upload a .png or .jpg logo.

This will show error
Drupal\Component\Plugin\Exception\PluginNotFoundException: The "entity:file:undefined" plugin does not exist. Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are: formatted_price, entity_revision_reference...

Please provide help.

I've tried to install Drupal 7 on 2 separate systems using a PostgreSQL 9.0 database backend, and both times it has failed at the same point.

The error message in the PostgreSQL logs both times is:

ERROR: null value in column "rid" violates not-null constraint
STATEMENT: INSERT INTO role_permission (rid, permission, module)
VALUES (NULL, 'administer blocks', 'block')

I followed the instructions in INSTALL.pgsql.txt, and everything else
installs up to this point.

The actual error message returned on the installation page is:

An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: http://bison:8089/install.php?profile=standard&locale=en&id=1&op=do
StatusText: OK
ResponseText:
Home | Drupal
@import url("http://bison:8089/modules/system/system.theme.css?0");
@import url("http://bison:8089/modules/system/system.messages.css?0");
@import url("http://bison:8089/modules/system/system.menus.css?0");
@import url("http://bison:8089/modules/system/system.base.css?0");
@import url("http://bison:8089/modules/comment/comment.css?0");
@import url("http://bison:8089/modules/field/theme/field.css?0");
@import url("http://bison:8089/modules/node/node.css?0");
@import url("http://bison:8089/modules/search/search.css?0");
@import url("http://bison:8089/modules/user/user.css?0");
@import url("http://bison:8089/modules/system/system.admin.css?0");
@import url("http://bison:8089/modules/system/system.maintenance.css?0");
@import url("http://bison:8089/themes/seven/reset.css?0");
@import url("http://bison:8089/themes/seven/style.css?0");
Home
Installation tasksChoose profile(done)Choose language(done)Verify
requirements(done)Set up database(done)Install
profile(active)Configure siteFinished
SQLSTATE[25P02]: In failed sql transaction: 7 ERROR: current
transaction is aborted, commands ignored until end of transaction
block

Steps to recreate:

Gentoo x64 (2.6.31 kernel)
Apache 2.2.15
PHP 5.2.14
PostgreSQL 9.0.3

1) Run: wget http://ftp.drupal.org/files/projects/drupal-7.0.tar.gz
2) Extract using: tar xvf drupal-7.0.tar.gz
3) Create destination directroy: mkdir /var/www/drupal-7.0
4) Copy files: mv drupal-7.0/* drupal-7.0/.htaccess /var/www/drupal-7.0
3) chgrp -R apache /var/www/drupal-7.0
4) Run: createuser --pwprompt --encrypted --no-createrole --no-createdb drupal
5) Run: createdb --encoding=UTF8 --owner=drupal drupal
6) Run: psql -U postgres -c "CREATE SCHEMA drupal AUTHORIZATION drupal;" drupal
7) Change to drupal dir: cd /var/www/drupal-7.0
8) Change permissions on default sites dir: chmod a+w sites/default
9) Create settings file: cp sites/default/default.settings.php sites/default/settings.php
10) Update settings permissions: chmod a+w sites/default/settings.php
11) Update sites/default/settings.php file as per INSTALL.pgsql.txt with schema name, by adding this line: $db_prefix = 'drupal';
12) Navigate to webpage and follow installation.
13) Error appears as described above.

Screenshots of installation attached.

Installation appears to work fine when using a schema named anything but "drupal", or not using a schema at all.

Problem/Motivation

We unified the uid base field definitions and deprecated various default value callbacks in [##2949964].

On a site today, we noticed a bug with some media types because the default value callback in their uid base field override still referenced media_entity. That made me think and investigate and I also found several sites where the default value callback still uses Drupal\node\Entity\Node::getCurrentUserId, Drupal\media_entity\Entity\Media::getCurrentUserId and so on, which would fail on Drupal 9 (no default value which causes an SQL exception).

Proposed resolution

Update all possibly existing base field overrides for known entity types, fix their default value callbacks.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

I put in some debug code to see which table and fields are causing this:

table name = users
field name = langcode

Here is the field object
Drupal\Core\Field\BaseFieldDefinition Object
(
[type:protected] => language
[propertyDefinitions:protected] =>
[schema:protected] => Array
(
[columns] => Array
(
[value] => Array
(
[type] => varchar_ascii
[length] => 12
)

)

[unique keys] => Array
(
)

[indexes] => Array
(
)

[foreign keys] => Array
(
)

)

[indexes:protected] => Array
(
)

[itemDefinition:protected] => Drupal\Core\Field\TypedData\FieldItemDataDefinition Object
(
[fieldDefinition:protected] => Drupal\Core\Field\BaseFieldDefinition Object
*RECURSION*
[definition:protected] => Array
(
[type] => field_item:language
[settings] => Array
(
)

)

[typedDataManager:protected] =>
)

[definition:protected] => Array
(
[label] => Drupal\Core\StringTranslation\TranslatableMarkup Object
(
[translatedMarkup:protected] =>
[options:protected] => Array
(
)

[stringTranslation:protected] =>
[string:protected] => Language code
[arguments:protected] => Array
(
)

)

[display] => Array
(
[view] => Array
(
[options] => Array
(
[region] => hidden
)

)

[form] => Array
(
[options] => Array
(
[region] => hidden
)

)

)

[translatable] => 1
[description] => Drupal\Core\StringTranslation\TranslatableMarkup Object
(
[translatedMarkup:protected] =>
[options:protected] => Array
(
)

[stringTranslation:protected] =>
[string:protected] => The user language code.
[arguments:protected] => Array
(
)

)

[provider] => user
[field_name] => langcode
[entity_type] => user
[bundle] =>
)

[typedDataManager:protected] =>
)
The website encountered an unexpected error. Please try again later.
TypeError: Argument 1 passed to Drupal\Core\Entity\Sql\DefaultTableMapping::requiresDedicatedTableStorage() must implement interface Drupal\Core\Field\FieldStorageDefinitionInterface, null given, called in
core/lib/Drupal/Core/Entity/Sql/DefaultTableMapping.php on line 346 in Drupal\Core\Entity\Sql\DefaultTableMapping->requiresDedicatedTableStorage() (line 525 of core/lib/Drupal/Core/Entity/Sql/DefaultTableMapping.php).

Problem/Motivation

There are places in core where we link out to external resources. One of these is in the installer, when there is an unmet requirement. Another is in the the date formatters, where there is link out to the PHP docs so people can reference how to construct custom date strings. There are other places, and contrib space adds lots more.

There are some older, related issues about this for specific cases, but no consolidated policy that we can point to. External links are also handled in an inconsistent manner with regards to links opening in a new windows, rel=external, etc.

We should formalize our approach to how external links are handled, and as a followups, apply the policy, taking into account the proper context.

Policy should take into account the current best practices for usability and accessibility, provide concrete examples for usage, but also allow for context specific exceptions when needed.

Proposed resolution

TBD.

Hello, running:

phpcs --standard=Drupal,DrupalPractice,PHPCompatibility --extensions=php composer

reports few issues with phpdoc comments as are currently set via the PHP_CodeSniffer rules.

To not fix an entire code base at once and have too big and unmanageable patch file, I'm opening this issue separately for the composer dir...

Thanks.

Problem/Motivation

API page: https://api.drupal.org/api/drupal/core!modules!system!templates!links.ht...

1. The 'link' element is not documented.
2. The 'url' element is documented, but is not available in the template.
3. It is unclear for developers what the input is for the theme function.

Question for the Theme System / Twig maintainers

We have a case here where there is a preprocessing function that expects certain input from the render array, and then the Twig template expects the processed output of that as its input.

My question is whether in the Twig template we are supposed to document what comes in after preprocessing? In which case, where are we documenting what goes into the render array? This is kind of a generic question, not just for this issue:
- Module developers passing stuff from their module through a given theme hook -- where do they look for docs and what do they expect?
- Theme developers overriding a theme template -- where do they look for docs and what do they expect?

Problem/Motivation

If the left_field is a formula then the left_table should be null. Here's the corresponsing fragment from the JoinPluginBase:

if ($this->leftTable) {
  $left_table = $view_query->getTableInfo($this->leftTable);
  $left_field = "$left_table[alias].$this->leftField";
}
else {
  // This can be used if left_field is a formula or something. It should be used only *very* rarely.
  $left_field = $this->leftField;
  $left_table = NULL;
}

(source)

However, the ::buildExtra method produces invalid sql in this case, e.g.

media__field_tags.langcode = .langcode

and that breaks the views query. Here's the code fragment responsible for this:

if (isset($info['left_field'])) {
  $placeholder_sql = "$left[alias].$info[left_field]";
}

(source)

Proposed resolution

Add the left table alias to the query only if the left table is set. Additionally, allow setting the left_table directly in the extra definition in case the main join's left_field is a formula.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

Fixed a bug with formula handling in the extra conditions of a views join that caused problems when using the workspaces module.

Problem/Motivation

When I use the #state structure below to turn a text field into read-only depending to a checkbox selection, simply nothing happens.

'states' => array(
      'readonly' => array(
        ':input[name="text_field"]' => array('checked' => TRUE),
      ),
    ),

If I use 'disabled' instead of 'readonly' the code works perfectly! But I really need the "readonly" option because I want to save the value filled in the text field before. The "disabled" option doesn't allow to save the field value.

Proposed resolution

I found a simply solution that solves the problem with few lines: just implement the "readonly" option in the file states.js, the same way it is done with the "disabled" option. This way, readyonly works very well.

Problem/Motivation

The details.html.twig element has a variable 'required' that specifies whether it contains required fields. However, setting this variable has no effect on the visual output:

Seven

Claro

Proposed resolution

Support 'required' in details.html.twig by adding a marker to the summary title.

Remaining tasks

1. Write a patch
2. Review
3. Commit

User interface changes

details.html.twig supports 'required' by adding a marker to the summary title.

API changes

None.

Data model changes

None.

jsonapi.api.php currently says:

The JSON:API module provides *no PHP API to modify its behavior.*...This means that this module's implementation details are entirely free to change at any time.

And correspondingly, every class and interface are marked @internal.

However, I don't think that's tenable. We know there are use-cases for wanting to customize something. For example, renaming a field from its internal Drupal name to something friendlier (e.g., "uid" to "author"). That is currently supported by ResourceType::getPublicName(). I think that's an example of something we should expose to a non-internal API (whether by creating a ResourceTypeInterface, or via some other way).

Let's use this issue to collect other examples and spin-off child issues as needed.

Public PHP APIs shipped

1. #3037039: Create a public API for indicating resource types should not be exposed
2. #3085035: Add a public API for aliasing and disabling JSON:API resource type fields

Public PHP APIs proposed

1. #3100732: Allow specifying `meta` data on JSON:API objects

Problem/Motivation

In #2962525: Create a field widget for the Media library module, the media edit/view link was disabled in the field widget and widget view in order to prevent unintended data loss. Long term, we would still like the ability to quickly edit media items from the field widget, without navigating to a new page.

Proposed resolution

Allow media items to be edited in a modal while using the field widget. The Entity Browser module allows for similar functionality.

Remaining tasks

Write a patch, discuss scope.

User interface changes

Undecided.

API changes

None.

Data model changes

None.

Problem/Motivation

Guzzle 7 went into beta this week. https://github.com/guzzle/guzzle/releases/tag/7.0.0-beta.1

Proposed resolution

We should test this beta with Drupal 9 and determine if we are compatible with it in case Guzzle 7.0.0 is released before Drupal 9.

Remaining tasks

• Create a test patch that updates our core/composer.json requirement to the Guzzle 7 beta.
• Investigate any test failures, etc.

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

Needed. TBD.

Problem/Motivation

Right now, when you complete a Drupal 8 migration, AFAICS in all cases, you get your node/comment titles moved over, but the bodies display as blank:

The data for the fields is in the database, but getting stripped out on the front end.

According to the migrate team, this happens when filter formats not recognized by Drupal 8; they get migrated as filter_null, a filter that simply returns an empty string. However, to an "end user" it just appears that migrations don't work, even for very simple core cases where no fancy non-core input formats were used.

Major/Migrate critical because this represents a pretty significant usability hurdle, and harms user confidence in the system early on.

Proposed resolution

Instead, map mismatched filter formats to fallback_format (defaults to plain text).

The one possible reason not to do this is PHP code filter, where you could inadvertently expose database credentials that would now be exposed in plain text. However, we could probably deal with this case specially. (For example, explicitly setting that one to filter_null to indicate it needs attention.)

Remaining tasks

• Write a patch + tests
• Review it
• Commit it!

User interface changes

By default, migrations will now display at least something for body field content for nodes and comments. (As well as other rich text fields.)

API changes

?

Data model changes

N/A?

Release notes snippet

Migrations now default to the fallback filter format, fixing a problem where rich text fields were not displaying post-migration.

Hello, running:

phpcs --standard=Drupal,DrupalPractice,PHPCompatibility --extensions=php composer

reports few issues with phpdoc comments as are currently set via the PHP_CodeSniffer rules.

To not fix an entire code base at once and have too big and unmanageable patch file, I'm opening this issue separately for the composer dir...

Thanks.

Meeting will happen in #d9readiness on drupal.slack.com.

Hello and welcome to this Drupal 9 readiness meeting!

This meeting:
➤ Is for core and contributed project developers as well as people who have integrations and services related to core. Site developers who want to stay in the know to keep up-to-date for the easiest Drupal 9 upgrade of their sites are also welcome.
➤ Usually happens every other Monday at 19:00 UTC.
➤ Is done over chat.
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to: `https://www.drupal.org/project/drupal/issues/3099840`
➤*Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.

0️⃣ Who is here today? Comment in the thread below to introduce yourself.

1️⃣ Do you have suggested topics you are looking to discuss? Post in this thread and we’ll open threads for them as appropriate.

2️⃣ Drupal 9 alpha status

3️⃣ State of deprecated API removals

4️⃣ Dependency updates

4️⃣ .1️⃣ Backend dependencies (edited) 

4️⃣ .2️⃣ Frontend dependencies

5️⃣ Tooling to prepare contrib/custom code for Drupal 9

5️⃣ .1️⃣ State of all of contrib

5️⃣ .2️⃣ Drupal-check / phpstan-drupal updates

5️⃣ .3️⃣ Upgrade status

5️⃣ .4️⃣ rector automated fixes

6️⃣ Multilingual migrations needs testers

7️⃣ The Drupal 9 release date: June, August or December.

All right, thanks all for coming! Keep the discussion going in the threads and I’ll attempt to save the meeting notes later tomorrow. Given the ideal beta release date in 8 weeks, we’ll switch to weekly meetings, if you can make it great, if you cannot make it, no problem! Next meeting next week same time! #3104659: Drupal 9 readiness meeting / 13 January 2020

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the basic_auth, hal, jsonapi, rdf, rest, and serialization modules.

NOTE: What is below is the generic instructions for converting hook_help to topics. We want to end up with task-based topics; in this case, there really aren't "tasks" per se for these modules. So let's just make one topic called something like "Enabling web services on your site" with a filename starting with "core." (so it is not in one module's namespace), and describe what web services are, and what each of these 5 web services modules does.

Proposed resolution

Take the information that is currently in the hook_help module overview section for the module(s), and make sure the information is in one or more Twig help topic files. Steps:

1. Find the hook_help() implementation function in the core/modules/MODULENAME/MODULENAME.module file(s). For example, for the core RDF module, the module files is core/modules/rdf/rdf.module, and the function is called rdf_help().
2. Locate the module overview portion of this function. This is located just after some lines that look something like this:
   

     switch ($route_name) {
       case 'help.page.contact':
   

   And ends either at the end of the function, or where you find another case 'something': line.

3. We want to end up with one or more topics about the tasks that you can do with this module, and possibly a section header topic. So, read the help and figure out a good way to logically divide it up into tasks and sections. See Standards for Help Topics for information on how to do this.
4. See if some of these tasks are already documented in existing topics. Currently, all topics are in core/modules/help_topics/help_topics. Note that to see existing topics, you will need to enable the experimental Help Topics module (available in the latest dev versions of Drupal 8.x).
5. For each task or section topic that needs to be written, make a new Twig topic file (see Standards for Help Topics) in core/modules/help_topics/help_topics. You will need to choose the appropriate module prefix for the file name -- the module that is required for the functionality. Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can use the "core" file name prefix. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in the core prefix), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module prefix).
6. File names must be MODULENAME.TOPICNAME.html.twig -- for example, in the RDF module, you could create a topic about managing actions with filename rdf.overview.html.twig (and "MODULENAME" can be "core" as discussed above).
7. Make a patch file that adds/updates the Twig templates. The patch should not remove the text from the hook_help() implementation (that will be done separately).

Remaining tasks

a) Make a patch (see Proposed Resolution section).

b) Review the patch:

1. Apply the patch.
2. Turn on the experimental Help Topics module in your site, as well as the module(s) listed in this issue.
3. Visit the page for each topic that is created or modified in this patch. The topics are files in the patch ending in .html.twig. If you find a file, such as core/modules/help_topics/help_topics/rdf.overview.html.twig, you can view the topic at the URL admin/help/topic/rdf.overview within your site.
4. Review the topic text that you can see on the page, making sure of the following aspects:
   • The text is written in clear, simple, straightforward language
   • No grammar/punctuation errors
   • Valid HTML -- you can use http://validator.w3.org/ to check
   • Links within the text work
   • Instructions for tasks work
   • Adheres to Standards for Help Topics [for some aspects, you will need to look at the Twig file rather than the topic page].
5. Read the old "module overview" topic(s) for the module(s), at admin/help/MODULENAME. Verify that all the tasks described in these overview pages are covered in the topics you reviewed.

User interface changes

Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation

One major piece of functionality from the D7 Entity Reference module was left out entirely in #1801304: Add Entity reference field: the ability to render exposed views filters as a select list or autocomplete of available entities.

Proposed resolution

Generalize the taxonomy module's TaxonomyIndexTid plugin to be available for all entity reference fields and migrate the existing taxonomy filters to be based on the new generic filter plugin.

How to use

1. Add on an entity type / bundle an entity reference field, ex field_test_reference.
2. Create a view displaying this entity type.
3. Add a filter on the view for field_test_reference.
4. Configure the entity selection mode and the widget display mode.
5. Configure the filter behavior (ex: required, multiple, etc.)
6. Finally use the filter field for filtering the results based on the selected entity from the autocomplete or select list.

Remaining tasks

• ☑ support for content entity reference
• ☑ support for configuration entity reference
• ☑ support for content with and without bundles
• ☑ taxonomy filter rebased on generic entity reference
• ☑ settings forms to configure the filter
• ☑ display widget in select or autocomplete
• ☑ filter values based on reference view
• ☑ filter values based on bundles
• ☑ maximum filter values in select list for performance concerns
• ☑ sort for filter values when in bundle selection handler mode
• ☑ argument support for when view selection handler is used
• ☑ views configuration schema update
• ☐ existing configuration migration
• ☐ fix select option (#208, #215)
• ☑ tests

Post tasks

• ☐ conversion of the "authored by" filter to use the entity reference filter
• ☐ extract selection handler form logic in separate plugins that will specialize for rendering and validating the filter selection config form
• ☐ caching of the value form?
• ☐ documentation updates

User interface

Known issues

• CANNOT REPRODUCE ATM sometimes when switching between widget it gets stuck on the previous selected one
• FIXED when switching between the widget types the previous value is left in the exposed form and it's incompatible with the other widget type
• FIXED triggering ajax requests on the extra options form right after adding the filter brings you back to the add handler form fixed

API changes

None.

Problem/Motivation

If you don't want to translate your URL alias, the original URL alias won't work with your translations.

Steps to reproduce:

1. Install with standard
2. Enable language and content translation.
3. Add a language (e.g. Spanish)
4. Go to content translation settings and enable article translations. Uncheck the URL alias field.
5. Create a node, assign an URL alias in the form (e.g. /my-alias)
6. Translate the node. The URL alias is prepopulated with your source alias (e.g. /my-alias).
7. Submit the form.

Current outcome:
In the alias list, you have (/my-alias, EN).
Going to /es/my-alias gives a 404.

Expected outcome:
In the alias list, you should have (/my-alias, UND).
Going to /es/my-alias gives a 200 and displays the Spanish translation.

Proposed resolution

• If the entity OR the path field are not translatable, save the path alias with the langcode 'und'.
• If the entity AND the path field are translatable, save the path alias with the langcode of the entity (or translation).

Remaining tasks

• Agree on proposed resolution
• Review

User interface changes

None.

API changes

None.

Data model changes

None.