Problem

Allow multiple entity types in an EFQ reference.

1. Core hard codes a field type, so contrib cannot implement EFQ joins.
2. Contrib implementations can only support one target entity type

Proposed resolution

Field types supporting multiple target entity types need to know which entity type to join:

\Drupal::entityQuery('node')
  ->condition('erfield.entity:user.uid', '6', '=')
  ->execute();
\Drupal::entityQuery('node')
  ->condition('erfield.entity:node.title', 'foobar', '=')
  ->execute();

API addition

You can mention entity type just like context system

Field types supporting a single target entity type can use the existing syntax:

Drupal::entityQuery('node')
  ->condition('uid.entity.name', 'foobar', '=')
  ->execute();

Beta phase evaluation

Problem/Motivation

JavaScript validations applied to file uploads, such as allowed extension restrictions, do not work. The high-level issue is that the validation criteria are represented in a JavaScript object, drupalSettings.file.elements, but it references incorrect element ids for the file inputs.

I thought this was perhaps related to #2179655: JS file validation broken, but AFAICT that's not the case. The symptom is the same though.

Unfortunately, file.js seems to be correct.

Try uploading an image at node/add/article inside CKEditor. file.js causes JS errors. Specifically on

this.value.length > 0

Because this.value, which in turn is because this == the <div>, not the <input>.
That, in turn, is because of $context.find(selector) in file.js receives selector === '#edit-fid-upload', instead of '#edit-fid-upload--2'. Therefor it listens for events at $context (the <div>) rather than at <input>.
That, again, in turn, is because drupalSettings.file.elements does not contain '#edit-file-upload--2'. So either ajaxPageState is broken again/in yet another way, or the HTML ID being generated for the file upload input element is somehow wrong.

Proposed resolution

Rather than storing validation information for each file field in a JavaScript object that is not tightly associated to the input fields, store the validation information as data- attributes in the file input markup.

User interface changes

None.

API changes

None.

Beta phase evaluation

ThemeTestSubscriber

Consistently using ContainerAwareTrait in core has unveiled 3 cascaded bugs hiding each other from detection see

https://drupal.org/comment/8643347#comment-8643347 (2)

The relevant extract :-

(1) ThemeTestSubscriber extends ContainerAware it does not need a service_container it needs an IntrospectableContainer.

(2) In any event theme_test.services.yml does not as expected inject a container of any form.

(3) The place where the uninitialised container is used is "unreached code" by the testbot hence no bug is picked up!

That issue, is limited in scope, and so has just left the stub of a fix as the @todo in the ThemeTestSubscriber.

This issue is to ensure

1) The mocked container is initialised
2) The unreached code is actually used.

There are some phpcs issues, which needs to be fixed.

Problem/Motivation

Similar, but not quite the same as #2715859: ImageWidget::validateRequiredFields() produces an error message if an image field is hidden with hook_entity_field_access().

ImageWidget::validateRequiredFields() currently makes an assumption that a #submit array will be present on the return value of $form_state->getTriggeringElement() but that's sometimes not the case (e.g. if a form has been submitted by a non-button via ajax).

This can result in PHP Warnings like this:

Warning: in_array() expects parameter 2 to be array, null given in Drupal\image\Plugin\Field\FieldWidget\ImageWidget::validateRequiredFields() (line 256 of ...docroot/core/modules/image/src/Plugin/Field/FieldWidget/ImageWidget.php).

Proposed resolution

A simple tweak to avoid this would be to check for the presence of the array before using it in a function call e.g.:

   public static function validateRequiredFields($element, FormStateInterface $form_state) {
     // Only do validation if the function is triggered from other places than
     // the image process form.
-    if (!in_array('file_managed_file_submit', $form_state->getTriggeringElement()['#submit'])) {
+    if (is_array($form_state->getTriggeringElement()['#submit']) && !in_array('file_managed_file_submit', $form_state->getTriggeringElement()['#submit'])) {

...patch on the way.

Remaining tasks

Review patch.

User interface changes

None.

API changes

None.

Data model changes

None.

While working on #2737719: EntityResource: Provide comprehensive test coverage: for every entity type, every format, every method, I discovered a rather nasty problem with the xml format. On the (de)normalizer side, not the encoder/decoder side.

STR:

$serialized_test = $this->serializer->serialize($node, 'xml');
$unserialized_test = $this->serializer->deserialize($serialized_test, get_class($node), 'xml');

That should serialize a Node entity to the xml format and deserialize it again.

What actually happens: Symfony\Component\Serializer\Exception\UnexpectedValueException: A string must be provided as a bundle value., thrown at core/modules/serialization/src/Normalizer/EntityNormalizer.php:74.

For failing test, please await #2737719: EntityResource: Provide comprehensive test coverage: for every entity type, every format, every method.

If you generate a private file url in another language then the default language the url will contain a langcode. Because of that the wrong controller is used
The request to the file gives a 404. Without the langcode everything is working

Default language relative image url:
/system/files/styles/max_1300x1300/private/images/2016-09/iStock_95128009_XXLARGE.jpg?itok=XZSIigHD
-> this uses ImageStyleDownloadController

Translated node relative image url:
/fr/system/files/styles/max_1300x1300/private/images/2016-09/iStock_95128009_XXLARGE.jpg?itok=XZSIigHD
-> this uses FileDownloadController

Something is wrong with the routing here

Steps to reproduce:

• Install Drupal with standard profile
• Install translation modules
• Add a second language
• make article translatable
• Configure Drupal to use private file storage outside of the docroot
• Configure article node type image field to use private file storage
• Add an article in default language and upload an image
• Translate this article

You can now see the following:

• Thumbnail in translation language node edit form renders perfectly -> that's because it got rendered in the default language first and exists as a file
• If you flush all image styles and go to the translation language node edit form the image style fails to render because Drupal uses the wrong Controller for downloading the imagestyle

Problem/Motivation

During the 2015 usability study, users struggled with the process of adding a new content type. After creating a content type, you are redirected to the Manage fields screen; however, the heading for this page does not contain the name of the content type you are managing fields for. It can only be found in the breadcrumb (and even that has issues, see #2513570: Changing name (label) of content type is not reflected in breadcrumb link text).

Consequently, some users thought they failed to create a content type because when they were redirected to the manage fields screen, they said "This page has nothing to do with what I just did."

This is a regression from D7, since that screen uses the content type in the heading.

Proposed resolution

Include the content type name (or entity type name) in the heading of the Manage fields page to orient the user and inform them what they are managing fields for:

Not just for noobies

This will also benefit experienced users because it will help prevent adding fields to the wrong content type.

User interface changes

Manage fields heading will have more text.

API changes

None.

Data model changes

None.

Beta phase evaluation

In user.module we are calling \Drupal::languageManager() twice. Seems unnecessary.

From #2547833: Pager.inc -- add tests, clean it up, convert to a service, use it!:

Problem/Motivation

pager.inc uses global variables, which we are trying to get rid of, as they make it impossible to manage pagers in a OO manner. All the pager related API are procedural functions.

Proposed resolution

Make Drupal's default pager an OO service, using the capabilities introduced in Drupal 8. This will make it OO and will open it up to the possibility to replace it by alternative implementations.

Unfortunately proper cleanup would include removing the four globals in pager.inc. Since that's an API change, the best we can do in 8.x is deprecate them and include (deprecated) wrappers for the new service to maintain backwards comparability until 9.x.

In detail:

1) A 'pager' is a classed object that contains data and methods relative to a pager element. A 'pager factory' creates 'pager' objects and keeps track of the objects created so that they can be traversed to produce the 'page' URL querystring for the pager links.

2) The global variables are retained at this stage, wrapped into the PagerInterface methods so that methods can alter them, but also, for BC, other code can alter them independently, and in this case the values stored in the global override any value stored in the PagerInterface object.

3) pager.inc procedural functions remain for BC as wrappers to PagerFactoryInterface service or PagerInterface methods. There are no longer global variables declared in this file!

4) template_preprocess_pager() use the new service methods instead of directly accessing the globals.

Remaining tasks

• review

User interface changes

None.

API changes

All pager_* global variables and procedural function will be deprecated. New Drupal\Core\Pager\PagerInterface and Drupal\Core\Pager\PagerFactoryInterface and their default implementations will be added. BC layer introduced to allow deprecated global variables and functions to stay with same functionality until Drupal 9.

Data model changes

None.

Original report:

I do not know how this would fit in the timeline :( but looking at pager.inc overall I thought it may be worth to build a component for the helper functions and to move the pager theme preprocessing to theme.inc.

I will post a first stab - a patch that eventually removes pager.inc and 4 global variables; also, makes a bit more readable the routine that prepares the 'page' querystring fragment.

I have incorporated parts of #1588138: pager_query_add_page() [in D7, theme_pager_link()] overrides parameters passed programmatically in this patch.

Of course more polishing would be needed, but before all I'd like to get feedback: is this a path that make sense to follow?

Problem/Motivation

While working on #2604484: Migrate Drupal 7 image and file fields I went out of scope and started to work on D6 tests when the issue is just for D7. Since that is 'D7 critical', let's put the D6 work here to not hold that issue up.

In https://www.drupal.org/node/2604484#comment-10694994 I asked why d6_cck_file does a file lookup on the fid, while the D7 migration doesn't. Later I spoke to chx on IRC about this. He said the file lookup wasn't necessary because the drupal-to-drupal migrations keeps the ids, see https://www.drupal.org/node/2604484#comment-10696948.

Proposed resolution

Make the source migration for the file's migration configurable so it isn't hard-coded to d6_file.

Remaining tasks

• Do it
• Test it

To test it, we will need a kernel test that wires in a dummy file migration and see if that dummy migration is successful. There isn't really a good way to test this with a unit test.

• Run dummy file migration. Make sure that the files that are in the dummy migration aren't copied in by any other test.
• Reference dummy file migration in cckfile migration and validate files from the dummy migration were migrated.

User interface changes

API changes

Data model changes

Problem/Motivation

Time and time again, we keep running into bizarre problems that we are not supposed to run into. These problems prevent small, focused patches in the REST and serialization modules from being viable: in virtually every single REST issue, we encounter bizarre behavior and mind-bending bugs, which simply explode the original/intended issue scope out of pure necessity.

Also, all the existing test coverage is centered on the fairly artificial entity_test entity type. There's @todos in almost all existing tests to remind ourselves to add test coverage for other entity types. So, those things never got resolved before the 8.0.0 release.

Examples:

• #2631774-25: Impossible to update Comment entity with REST (HTTP PATCH): bundle field not allowed to be updated, but EntityNormalizer::denormalize() requires it
• #2662284-31: Return complete entity after successful PATCH

Proposed resolution

Steps:

1. Refactor all of CreateTest, ReadTest, UpdateTest, DeleteTest to provide an entire CRUD flow including testing of the edge cases to verify the DX (e.g. forgetting X-CSRF-Token header). Put all that in a base class, and then subclass it for every entity type. That is then much like \Drupal\system\Tests\Entity\EntityCacheTagsTestBase, which has been very successful. That then means any module providing a new entity type can just subclass that test and get full REST test coverage.
2. Figure out a way how to test all serialization formats, including those added by additional modules. That means it's two-dimensional extensibility … which means it's kinda tricky to make that work. We'll see.

Remaining tasks

Phase 1: infrastructure (base classes with scenarios)

1. Port ReadTest
2. Port CreateTest
3. Port UpdateTest
4. Port DeleteTest

Phase 2: apply this to all entity types

Content entity types:

1. Node
2. User
3. MenuLinkContent
4. BlockContent
5. File
6. Shortcut
7. Item
8. ContentModerationState
9. Term
10. EntityTest
11. Feed
12. Message
13. Comment

Config entity types:

1. Block
2. FieldStorageConfig
3. FilterFormat
4. View
5. SearchPage
6. ConfigurableLanguage
7. Action
8. ContentLanguageSettings
9. EntityFormDisplay
10. EntityViewDisplay
11. FieldConfig
12. BaseFieldOverride
13. ConfigTest
14. Tour
15. ResponsiveImageStyle
16. RdfMapping
17. Role
18. DateFormat
19. RestResourceConfig
20. BlockContentType
21. CommentType
22. EntityTestBundle
23. NodeType
24. ContactForm
25. ShortcutSet
26. Vocabulary
27. EntityFormMode
28. EntityViewMode
29. Editor
30. Menu
31. ModerationStateTransition
32. ModerationState
33. ImageStyle

Phase 3: refinements: entity type-specific additions, format-specific additions, authentication mechanism-specific additions

TBD

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

Proposed resolution

Remaining tasks

User interface changes

API changes

Original report by @catch

If you want to change the path alias for a user, you have to first find the user and their uid then go into the path admin interface, find the alias, then edit it. This takes ages.

We should add a path alias form to the user edit screen if path module is enabled - same as is currently done for nodes.

To cut it short, DFP does the management, delivery and measurement of your ads. DoubleClick for Publishers is a constituent part of DoubleClick Ad Exchange which allows you to make connections with a great number of Google AdWords advertisers, with a variety of ad networks and trading desks that are competing for your inventory. By signing up for DFP, you will be able to manage your whole advertising by just one single network because that’s what subscription for DFP means: you get a certain network for the management of your advertisements. read more at http://www.adopsguys.com/about-us/blog/

In a Drupal 8.1.10 site migrated from Drupal 6, cron always stopped (says 'completed' but shows an error) before indexing is completed. Currently, indexing is stuck at 4% (1732 items left to index).

The error shown is: InvalidArgumentException: The URI 'hardware/example1' is invalid. You must use a valid URI scheme.

This error message has found to be misleading and not informative, because 'hardware/example1', while is a legitimate invalid URI (and theoretically can be fixed by adding a preceding forward slash, i.e. '/hardware/example1' if it's referred in a node), is not referred anywhere in any of the pages in that form, and in fact the node itself is currently unpublished. Also, a mirror site migrated from the same Drupal 6 base has the exact same error type, but different invalid URI shown (say, 'software/example2'), which is also an old node not referred anywhere else on the site, with the same status as the other node above.

Every time cron is run (3-hour schedule, currently), it always stopped on a different, seemingly random 'location', and the same error showing consistently the same invalid URI ('hardware/example1'), while the actual indexing process never continues.

I have tried the reindexing process, which ended up resetting the index, and then the indexing process stuck at 0% and wouldn't start at all. I have also tried uninstalling and reinstalling the search module, in which case resulted in indexing process started, but stuck at 4% as before.

I'm not sure where to go from here. Any help/ideas on where to look to fix this will be appreciated.

Problem/Motivation

I've got a live Drupal 8 site that has certain pages that 404 when accessed. The page is still accessible to edit, provided you can track down the Node ID to write the path. Clearing the caches on the site solves the problem temporarily. I've had several instances where after clearing the cache and making sure the page is accessible, it becomes inaccessible again the next day. This is unsettling as those path caches are not set to expire ever, so I do not know what is acting on them.

Since clearing caches works, I tracked down the cached path information in the cache_data table. Broken paths are missing a significant amount of data. For example, here is the cached data on a path that is not working (cid: route:/patients/prevention/plant-products/cancer-prevention-sulforaphane:) :

a:3:{s:4:"path";s:66:"/patients/prevention/plant-products/cancer-prevention-sulforaphane";s:5:"query";a:0:{}s:6:"routes";O:41:"Symfony\Component\Routing\RouteCollection":2:{s:49:" Symfony\Component\Routing\RouteCollection routes";a:0:{}s:52:" Symfony\Component\Routing\RouteCollection resources";a:0:{}}}

This is considerably emptier than the same path cache after a cache clear and re-access:

a:3:{s:4:"path";s:10:"/node/4054";s:5:"query";a:0:{}s:6:"routes";O:41:"Symfony\Component\Routing\RouteCollection":2:{s:49:" Symfony\Component\Routing\RouteCollection routes";a:1:{s:21:"entity.node.canonical";C:31:"Symfony\Component\Routing\Route":1327:{a:9:{s:4:"path";s:12:"/node/{node}";s:4:"host";s:0:"";s:8:"defaults";a:2:{s:11:"_controller";s:48:"\Drupal\node\Controller\NodeViewController::view";s:15:"_title_callback";s:49:"\Drupal\node\Controller\NodeViewController::title";}s:12:"requirements";a:3:{s:4:"node";s:3:"\d+";s:14:"_entity_access";s:9:"node.view";s:7:"_method";s:8:"GET|POST";}s:7:"options";a:5:{s:14:"compiler_class";s:34:"\Drupal\Core\Routing\RouteCompiler";s:10:"parameters";a:1:{s:4:"node";a:2:{s:4:"type";s:11:"entity:node";s:9:"converter";s:21:"paramconverter.entity";}}s:14:"_route_filters";a:1:{i:0;s:27:"content_type_header_matcher";}s:16:"_route_enhancers";a:1:{i:0;s:31:"route_enhancer.param_conversion";}s:14:"_access_checks";a:1:{i:0;s:19:"access_check.entity";}}s:7:"schemes";a:0:{}s:7:"methods";a:2:{i:0;s:3:"GET";i:1;s:4:"POST";}s:9:"condition";s:0:"";s:8:"compiled";C:33:"Drupal\Core\Routing\CompiledRoute":429:{a:11:{s:4:"vars";a:1:{i:0;s:4:"node";}s:11:"path_prefix";s:5:"/node";s:10:"path_regex";s:24:"#^/node/(?P<node>\d+)$#s";s:11:"path_tokens";a:2:{i:0;a:4:{i:0;s:8:"variable";i:1;s:1:"/";i:2;s:3:"\d+";i:3;s:4:"node";}i:1;a:2:{i:0;s:4:"text";i:1;s:5:"/node";}}s:9:"path_vars";a:1:{i:0;s:4:"node";}s:10:"host_regex";N;s:11:"host_tokens";a:0:{}s:9:"host_vars";a:0:{}s:3:"fit";i:2;s:14:"patternOutline";s:7:"/node/%";s:8:"numParts";i:2;}}}}}s:52:" Symfony\Component\Routing\RouteCollection resources";a:0:{}}}

Running Drupal 8.1.10 with several languages enabled

Note that I initially started to investigate this issue on #2728725: "Page not found" depending on language settings but I do not think it is related as that issue is not partially resolved with cache clears and also does not involve Pathauto.

Steps to Reproduce

1. Spin up an instance of multilingual_demo distribution on simplytest.me (http://ply.st/multilingual_demo). Proceed through the install like normal; you should not need to change any defaults.
2. We'll use the 'About Us' page as the target. Edit that page (/node/9/edit) and give it a new alias under URL Path Settings. In this example I have set the new alias to '/about-us'. It just needs to be different from the aliases given to the other translations.
3. Add a link field to the basic page content type (/admin/structure/types/manage/page/fields/add-field). Do NOT allow this field to be translated, and make sure it allows internal links. Also move the link field out of 'Disabled' on the full content display (/admin/structure/types/manage/page/display/full); the link field needs to be rendered for this to happen.
4. Add a basic page (/node/add/page). Content does not matter, but on the newly created Link field add in the path in the URL box ('/about-us'). Do not use the autocomplete.
5. Make a translation of that new page. I'll go ahead and make a Spanish one (/es/node/10/translations/add/en/es). No changes need to be made; you can just save it
6. Clear the site caches on the Performance page (/admin/config/development/performance). The new route issue happens when the cache is created, so we can't have the existing cache standing in the way.
7. Visit the translation of the new page (es/node/10). This renders the link field which breaks the route cache of the page it links.
8. Attempt to access the English About Us page (/about-us). It will now 404 until the next cache clear.

Problem/Motivation

If the user visits the site index for a Drupal site that has database credentials in settings.php but has not yet been installed completely, the user will receive a fatal error that does not in any way indicate that the user should visit install.php to complete the installation.

Proposed resolution

Detect an empty database during bootstrap, and redirect to install.php if installation is not already in progress.

Patch in #728702-17: Visiting index.php should redirect to install.php if settings.php already has database credentials but database is empty. is confirmed to resolve this issue for both D7 and D8.

Remaining tasks

None.

User interface changes

User will be redirected to install.php if there is a database configuration but the database is empty.

API changes

None.

Original report by @arpeggio

The setup are:
-database empty
-drupal updated from CVS
-set the C:\xampp\htdocs\sites\sites.php with $sites['localhost'] = 'kapitbisig.com';
-manually populated the the database credentials in C:\xampp\htdocs\sites\kapitbisig.com\settings.php

I got the following error message when I browsed http://localhost

Fatal error: Call to undefined function _system_rebuild_theme_data() in C:\xampp\htdocs\includes\theme.inc on line 586

See

1. https://tools.ietf.org/html/draft-grigorik-http-client-hints-03
2. http://caniuse.com/#feat=client-hints-dpr-width-viewport
3. https://developers.google.com/web/updates/2015/09/automating-resource-se...
4. http://cloudinary.com/blog/automatic_responsive_images_with_client_hints...

However, for now, Mozilla seems to not want to implement this: https://bugzilla.mozilla.org/show_bug.cgi?id=935216. So it'll probably be a while before this can actually be considered.

Problem/Motivation

When I try to install a custom profile (or distro) via drush I get this error:
Error: Call to a member function getPath() on null in core/includes/install.inc, line 942

Affect any kind of custom profile even if is similar to minimal or standard...
I'm using
- Drush Version : 8.0-dev
- Drupal Version: 8.0-dev

Proposed resolution

Provide a more helpful error message.

Remaining tasks

Decide on the error message. Write a test.

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

It is impossible to load additional JS libraries in an Ajax response and then call that code through Ajax commands, because Drupal.ajax does not guarantee that the JS library will already have loaded.

See #14 and #15 for details.

Proposed resolution

TBD.

Remaining tasks

TBD.

User interface changes

None.

API changes

TBD

Related Issues

TBD

Original report by [username]

Hi,

Thanks for your module, it works perfect for me.

But I found there one small bug there: if all my .js files are mapped to the external CDN, ajax redirects doesn't execute. After some tests I found that CDN rewrites all js urls, even for ajax. So I attached a small patch that solved this problem for me.

Best regards,
Spleshka.