As of today, grouping is only possible for select lists, not for checkboxes and radio buttons. In form.inc, options buttons get flattened out.
If you read this thread: #1878292: Add grouping by Vocabulary / Content type / Bundle for check boxes / radio buttons widget you can see that grouping for checkboxes and radio buttons is a legitimate feature request for entity reference fields.
I believe this can be accomplished by doing the following:
1/ setting optgroups property to TRUE for options_buttons in function _options_properties() of modules/field/modules/options.module file. This prevents #options from being flattened out.
But the presentation layer does not handle grouping for checkboxes and radios... so:
2/ modify function form_process_checkboxes in includes/form.inc to actually handle grouping. I've only tested for checkboxes so far but I believe the same can be done for radio buttons in form_process_radios.
3/ finally for the system not to throw an illegal choice error at form validation, we actually need to flatten the options before validation process the same way its done for select lists right now in function _form_validate of include/form.inc

In order not to break already existing Drupal sites, I suggest we wrap steps 1 and 3 in conditional statement based on either :
- a variable in settings.php
- or maybe more a Drupal variable (variable_get) configurable in the UI that wouldn't need to be copied manually and maybe forgotten each time we need to update settings.php.

Note that modifications in 2) would not affect current Drupal sites since all the grouping code would only be executed for Arrays() but all options would still be flattened out... so no array, no new behavior.

Could this be added to the Drupal 7 core or is it too late? I will of course provide my code as soon as it is more complete.

Problem/Motivation

There is no need to use t() in tests, unless we're testing translations, however in core we do not follow this consistently, which does not set a good example for new contributions.

In #3133726: [meta] Remove usage of t() in tests not testing translation we identified there are hundreds of calls to t() in calls to assertText() and that removing all these in one go seems to be a suitable way of attacking this problem.

Proposed resolution

Identify and remove all calls to t() wrapped in calls to assertText(), except those used by translation-related code (if any).

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Just an issue to try run some tests.

Problem/Motivation

The term bundle is confusing to users and no longer is descriptive of the way bundles are used. A "bundle"
is a subtype of an entity type, which could be "node", "taxonomy" or "comment". For example, a "node bundle"
would be the equivalent of a Drupal 6 "content type".

Considerations:
A concept called "bundles" is going to be brought in from Symfony, so the Drupal term should be changed.
Effect of renaming Entity Type and Bundle on documentation
- Since a bundle could be a node type, if we rename bundle -> entity type, do we need to rename node type?
Attempting to convey the meaning of Entity subtype without using the word subtype

Proposed resolution

We need to have terms that cover:
a) Entity type (such as Node, Taxonomy, Custom block, Comment, etc.)
b) Bundle (such as content type, taxonomy vocabulary, comment type, block type, etc.)
c) Entity item (individual node, taxonomy term, etc.)

Proposed terms for entity type: Entity type, entity class, entity base type
Proposed terms for bundle: Bundle, entity type, entity sub-type, variant, variety, entity schema
Proposed terms for entity item: Entity item, Entity

Proposed combinations of these terms into a set of terminology:

A:

Entity type -> Entity class
Bundle      -> Entity type
Entity      -> Entity

B:

Entity type -> Entity type
Bundle      -> Entity variant/variety
Entity      -> Entity

C:

Entity type -> Entity type
Bundle      -> Entity subtype
Entity      -> Entity

D:

Entity type -> Entity type
Bundle      -> Entity subtype
Entity      -> Entity item

E:

Entity type -> Entity class
Bundle -> Entity family
Entity -> Entity

Notes:
1. Option D is what is currently used in the User Guide and Help Topics, but it may not be the best choice.
2. Within one entity type, we would still use the specific name. E.g., when talking about taxonomy terms, we would use the word "Vocabulary" to refer to a bundle, not the generic "Entity variant" or whatever we choose. This terminology is for the generic text to describe entities in general.
3. MIME types, which are also 2 level, use the terms "type" and "subtype": http://en.wikipedia.org/wiki/Internet_media_type, http://www.iana.org/assignments/media-types/index.html

Remaining tasks

a) Decide on which alternative makes the most sense, hopefully based on usability testing.
b) Change the Drupal Core UI text to use this terminology.
c) Change the help topics to use this terminology on #3121340: Fix up minor problems in help topics
d) Change the User Guide to use this terminology (no issue yet).
e) Update Entity API documentation to mention the UI terminology, without changing the field/entity code.

User interface changes

Entities will have standardized and better terminology in the UI and in help.

API changes

Probably none.

Original report by webchick

I'd really love to see the word "bundles" done away with. I've yet to meet a human being who can explain this in fewer than 300 words and with a lot of head scratching and glazed-over eyes on behalf of the listener. Witness users trying to figure this out at: http://drupal.org/node/1040330

Related issues

• #1374116: Move bundle CRUD API out of Field API

Adding media field on entity and marking it as required does not show proper validation message.

1. Steps to reproduce the bug

• Add media field in page content type, and mark this as required.
• Try creating page content, fill title & body and leave media as blank.
• Click Save button.
• It will give you message "This value should not be null"

• It should give proper message like "Media field is required."
• It should also highlight the field which has error.

• It gives message "This value should not be null".
• It does not highlight the field with error.

In accordance with the announcement on May 1997 that the Republic of Zaire had changed its name, the new name, the Democratic Republic of the Congo. Changing the name congo-kinshasa to new name 'Democratic Republic of the Congo'.

The feed URL is hard coded to 'rss.xml' and the link only works when clicked on home page.

/**
 * {@inheritdoc}
 */
public function build() {
  return [
    '#theme' => 'feed_icon',
    '#url' => 'rss.xml',
  ];
}

An issue has been created for Drupal 8 already, but this is for Drupal 7 particularly.

Problem/Motivation

MySQL 8 has been release and includes performance enhancements. It would be nice to integrate those enhancements with Drupal 7.

Proposed resolution

Test a variety of Drupal 7 distributions running with MySQL 8 and fix bugs as they appear.

Remaining tasks

• Add support

User interface changes

• Note during the site install that MySQL 8 is supported.

API changes

N/A

Data model changes

N/A

I have created a workaround patch that serves as a temporary workaround.

Problem/Motivation

As title, we can explore replacing assertions looking at results of the drupalGetHeader method, by asserting the session and then using methods from WebAssert on it.

Proposed resolution

For example:

-    $this->assertEqual($expectedGeneratorHeader, $this->drupalGetHeader('X-Generator'));
+    $this->assertSession()->responseHeaderEquals('X-Generator', $expectedGeneratorHeader);

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Hi All,

I am working on Drupal 8.2.0-dev for website on linux server with MariaDB as database server. The site setup is based on 3 instances of website setup or file system using one database. Whenever updates are made to the site cache is cleared from all 3 instances / nodes for changes to work properly esp. twig template changes.

Here is more detail about site configuration on server :-

The website is actually a 3-node cluster behind a load balancer.
Each node (node1,node2 and node3) are part of a MariaDB Galera Cluster, and each node is hosting the Drupal website.
Each drupal website communicates with it’s own DB. So this means when node1 is serving a page, it is reading/writing to the DB on node1. Likewise, node2 read/writes to node2’s DB and so on.
The website files on main location are replicated between the nodes using lsyncd and csync2.

So, when a visitor hits the website, traffic flow is :
HTTP Traffic -> HAPROXY Load Balancer -> (one of the 3 Nodes)
a. Node1 website communication to MariaDB on node1 (localhost)
b. Node2 website communication to MariaDB on node2 (localhost)
c. Node3 website communication to MariaDB on node3 (localhost)

I face an error :-
1. While using drupal admin interface for making updates or inserts website admin often gets error below.
2. Wen cache is cleared using Drush on website on the frontend also.

Uncaught PHP Exception Drupal\\Core\\Database\\DatabaseExceptionWrapper: "SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction: INSERT INTO {cache_entity} (cid, expire, created, tags, checksum, data, serialized) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6) ON DUPLICATE KEY UPDATE cid = VALUES(cid), expire = VALUES(expire), created = VALUES(created), tags = VALUES(tags), checksum = VALUES(checksum), data = VALUES(data), serialized = VALUES(serialized); Array, referer:

After searching on similar issues I found that solution suggested are using modules which are not ported to Drupal 8 yet e.g. https://www.drupal.org/project/apdqc. This issue was reported for Drupal 7 several times but not Drupal 8. I am not sure if its bug so adding support request.

Have not been able to find any reliable solution for this.

Just to add in my case the deadlock always is related to cache tables. Also can "Entity/field definitions" , " Mismatched entity and/or field definitions " as on page /admin/reports/status has any relation to this?

Any suggestions would be appreciated.

Thanks
Atul

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

You cannot create a view and try to list rendered entities using relationship.

Steps to reproduce (based on Standard profile):

1. Add an entity reference field named "field_content" to the "page" content type. Allow content > article references.
2. Create and edit a content view.
3. Add a relationship for "Content using field_content." or "Content referenced from field_content."
4. The row style plugin is "Content" by default.
5. Click on "Teaser" in order to change the view mode, nothing happens.
6. You can't choose a view mode even if you don't want to actually use a relationship, just having one on your view triggers this.

The problem is a fatal AJAX error triggered when RowPluginBase::buildOptionsForm() calls RelationshipPluginBase::init() while providing a wrong argument type (Array instead of DisplayPluginBase).

Argument 2 passed to Drupal\views\Plugin\views\relationship\RelationshipPluginBase::init() must be an instance of Drupal\views\Plugin\views\display\DisplayPluginBase, array given, called in /app/web/core/modules/views/src/Plugin/views/row/RowPluginBase.php on line 93

Proposed resolution

Fix it, by passing along the relationship as needed and using it.

Remaining tasks

None.

User interface changes

None

API changes

None

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the migrate, migrate_drupal, migrate_drupal_multilingual, migrate_drupal_ui module(s).

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 Contact module, the module files is core/modules/contact/contact.module, and the function is called contact_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 Action module, you could create a topic about managing actions with filename action.managing.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/action.configuring.html.twig, you can view the topic at the URL admin/help/topic/action.configuring 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.

I have a content type (Cars) which has the option to upload 4 images. I created a view with the Slidershow module to display as a presentation. I added the Viewfield module.

What I need is that when the image slideshow is shown, it only shows the images of that content type, not the images of all the content types I have created.

Currently, if I load three nodes, the view loads the images of all the node, while I only want each node to show the presentation of its specific images.

I appreciate your collaboration.

Hello all, it’s time for the weekly migration initiative meeting. The meeting will take place in slack in various threads
This meeting:
➤ Is for core migrate maintainers and developers and anybody else in the community with an interest in migrations
➤ Usually happens every Thursday and alternates between 1400 and 2100 UTC.
➤ Is done on the #migration channel in Drupal Slack (see www.drupal.org/slack for information).
➤ 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 here: TODO. See the parent issue for an idea of the typical agenda.
➤*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.

Core migration issues:

• RTBC
• NR
• all open

Problem/Motivation

As part of phase 2 of #2940731: Automatic Updates Initiative overview and roadmap we need Readiness Checks for automatic updates.

These checks would ensure that a site is ready to have automatic updates applied.

The Automatic Updates contrib module has a readiness check system built on tagged services.

These Readiness checks are particular to the process of Automatic Updates in the contrib module and should also work for the proposed Composer based updates for Drupal core.

Because Drupal core will introduce the Automatic Updates in an experimental module and Readiness Checks will be checking for this yet to be implemented functionality it does not make sense to add the Readiness Checks directly to the existing Update module. For more info on this see this comment on the roadmap issue.

Proposed resolution

Add the Readiness check infrastructure and 1 Readiness Check service from the contrib module to a new experimental module.

Remaining tasks

1. Port initial functionality from the contrib module
2. Determine what changes should be made from the contrib code
3. Ensure that modules that have new Readiness Checkers trigger a recheck.
4. Determine minimum space needed now that we will be using composer.
5. Determine if a larger minimum disk space value could ever cause random failures on Drupal CI. Right now this not happening with the contrib module but it only uses 10mb. If we change this to something like 200mb would this ever fail in DrupalCi and cause a test failure?
6. Use Batch API for running checks for scaling
7. Ensure that \Drupal\auto_updates\ReadinessChecker\ReadinessCheckerManager::run() does not throw an exception if it is run for a category that has no checkers or ensure it does not run in this case. Services can be altered so we don't know for sure what the existing checkers will be or which category they will be in.
8. Determine if a single checker should be able provide both warnings and messages
9. Add more tests
10. Review

Questions

1. What value should we use for \Drupal\automatic_updates\ReadinessChecker\DiskSpace::MINIMUM_DISK_SPACE?
   10mb was used for the contrib module but that was with patch workflow. Now that we will use composer it will probably be different.
2. Currently each "checker" tagged service has a "category" tag. This means they can only have messages in 1 category. Should they instead be able to return message in either category?

   For instance the DiskSpace check might return an "error" message "Your disk space is too low" and a "warning" message "Your free disk space is nearing the limit for automatic updates".

User interface changes

There will be message on the Status Report page that tells you if your site is ready for Automatic Updates

API changes

TBD

Data model changes

None

Release notes snippet

TBD

Some rules in the .htaccess seem outdated.

FilesMatch pattern to protect files and directories form direct access needs to be updated. For instance tpl(\.php)? makes no sense in Drupal 8+.

Configuration for PHP 5 is no longer needed as Drupal does not support PHP 5 since version 8.7.

Overall the current configuration seems too complex and likely can be optimized. The number of rules in the .htaccess may affect server performance a great deal. That's because the file is parsed on each http request including requests for static files.

We may consider moving rules that specific to some directory into a separate .htaccess file located under that directory. For instance there is a large set of rules for serving gzip compressed CSS and JS files.

Problem/Motivation

From #3143870-10: Calls to AssertLegacyTrait::assertUrl() have wrong number of arguments: WebAssert::addressEquals is currently totally skipping the querystring of an URL. This means that tests that check on the address URL expecting or having an actual querystring are passing no matter what. Not good.

Proposed resolution

Adjust the cleanUrl method, that already extends from Mink's WebAssert, to take into account all parts of the URL.

Remaining tasks

review

User interface changes

no

API changes

no

Data model changes

no

Release notes snippet

no

Problem/Motivation

In core/tests/Drupal/Tests/Core/Entity/EntityLinkTest.php file testToLink() initializes $expected, but never uses that variable.

Proposed resolution

Remove the unused $expected variable.

public function testToLink($entity_label, $link_text, $expected_text, $link_rel
     $route_name = $route_name_map[$link_rel];
     $entity_id = 'test_entity_id';
     $entity_type_id = 'test_entity_type';
-    $expected = '<a href="/test_entity_type/test_entity_id">' . $expected_text . '</a>';
 
     $entity_type = $this->createMock('Drupal\Core\Entity\EntityTypeInterface');
     $entity_type->expects($this->once())

Problem/Motivation

Follow-up to #3013210-30: Add drupal/core-filesecurity component for writing htaccess files

+++ b/core/lib/Drupal/Component/FileSecurity/FileSecurity.php
@@ -0,0 +1,160 @@
+# If we know how to do it safely, disable the PHP engine entirely.
+<IfModule mod_php5.c>
+  php_flag engine off
+</IfModule>

core no longer running on php5 so this lines should be removed

Proposed resolution

Do not add protection for unsupported php version

Remaining tasks

- discus when to remove
- check supported apache versions

User interface changes

no

API changes

no

Data model changes

no

Release notes snippet

TBD