I am putting together a few views of aggregator data. The one coming from Feedburner is having trouble receiving the body/description of each feed item. It is getting the 'Posted on' and 'Title' fields just fine, but is blank for 'Description'. Description seems to be the only field that seems appropriate. We are upgrading a D6 site to D8 and it works on D6 Views but looks for the 'Body' field instead.
The aggregator is pulling data from http://feeds.feedburner.com/DirtRoadRockAndRoll?format=xml
I've also tried the non-xml format version. The content resides in a div with the class "itemcontent" on the feed if that is helpful.

Here's a screenshot of my views configuration: http://dev.tomsavage.ca/sites/tomsavage.ca/files/inline-images/whats_new...

Any help insight into a short term fix would be much appreciated.
Thanks,
Stuart

Problem/Motivation

Visiting node/1 with the standard install, anonymous, no page cache, warm caches, takes 39,000 function calls.

Equivalent Drupal 7 requests are between 5-10,000 function calls.

One of the worst offenders is Drupal::service() - this is called 397 times, and there are stack calls underneath it, so it's responsible for thousands of function calls.

One of the biggest callers of Drupal::service() is t()

One of the biggest callers of t() is system_region_list()

system_region_list() is called three times during the request. It has no static cache. It ends up translation the region names 60 times. 60 calls to t() = ~542 function calls.

We never print the region names except in block admin.

Proposed resolution

Don't translate the fucking human readable region names when we only want the machine names anyway.

Don't know exactly how much this saves, but it's probably 2-3ms per request. However this is for every single request assuming a site has block module enabled.

There's an extra hidden bonus. Once this is removed, we only have 21 calls to t() on this page. If we remove those, we'd also save initializing the translation service, and fetching the locale cache (when not viewing the site in English) - this is very feasible to get to I think.

Remaining tasks

TBD.

User interface changes

None.

API changes

Extra param to system_region_list()

Inspired by : #2804323: Need a views group URL field

Currently Node has a dedicated field handler to provide the canonical URL to a node: \Drupal\node\Plugin\views\field\Path

The generic entity link handler currently doesn't have the option to return a raw URL, only formatted links. We should allow the generic handler to provide this data, and probably depreciate the node specific implementation.

Problem/Motivation

Improve usability and accessibility of long select lists and autocomplete tagging widgets.

Proposed resolution

Use Select2 for tags and autocomplete stuff.

Patch is almost ready, it just needs a new Select2 tokenizer that supports our "tag with, comma" syntax.

FAPI is not going to be changed, but since the latest version of Select2 only works with <select>, we need to add javascript to convert our <input type="text"> used for free tagging, to a <select>. We probably also need a submit handler in javascript that changes it back to a normal text field so our PHP code keeps working. We cannot solve this on the PHP side, since it will not work without javascript.

Remaining tasks

User interface changes

Yes.

API changes

Is this still a relevant change: The return value expected by the autocomplete API changes from array('value' => $value, 'label' => $label) to array('id' => $value, 'text' => $label).

Beta phase evaluation

Steps to reproduce:

1. Enable moderation states on Article
2. Add content (Article)
3. Disable moderation states on Article
4. Add content (Article) => creates following error message

The website encountered an unexpected error. Please try again later.
TypeError: Argument 1 passed to Drupal\Core\Field\WidgetBase::errorElement() must be of the type array, null given, called in /var/www/build/html/core/lib/Drupal/Core/Field/WidgetBase.php on line 441 in Drupal\Core\Field\WidgetBase->errorElement() (line 500 of core/lib/Drupal/Core/Field/WidgetBase.php).

Drupal\Core\Field\WidgetBase->errorElement(NULL, Object, Array, Object) (Line: 441)
Drupal\Core\Field\WidgetBase->flagErrors(Object, Object, Array, Object) (Line: 255)
Drupal\Core\Entity\Entity\EntityFormDisplay->flagWidgetsErrorsFromViolations(Object, Array, Object) (Line: 157)
Drupal\Core\Entity\ContentEntityForm->flagViolations(Object, Array, Object) (Line: 103)
Drupal\Core\Entity\ContentEntityForm->validateForm(Array, Object)
call_user_func_array(Array, Array) (Line: 83)
Drupal\Core\Form\FormValidator->executeValidateHandlers(Array, Object) (Line: 270)
Drupal\Core\Form\FormValidator->doValidateForm(Array, Object, 'node_article_form') (Line: 119)
Drupal\Core\Form\FormValidator->validateForm('node_article_form', Array, Object) (Line: 569)
Drupal\Core\Form\FormBuilder->processForm('node_article_form', Array, Object) (Line: 314)
Drupal\Core\Form\FormBuilder->buildForm('node_article_form', Object) (Line: 48)
Drupal\Core\Entity\EntityFormBuilder->getForm(Object) (Line: 113)
Drupal\node\Controller\NodeController->add(Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 574)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
call_user_func_array(Object, Array) (Line: 144)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 64)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 649)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

This is a change in behavior from v8.1.x. On a new install of Drupal 8, if the /profiles directory is missing, you get an error:

PHP Fatal error: Uncaught exception 'UnexpectedValueException' with message 'RecursiveDirectoryIterator::__construct(/home/travis/build/phase2/grunt-drupal-tasks/test/working_copy/build/html/profiles): failed to open dir: No such file or directory' in /home/travis/build/phase2/grunt-drupal-tasks/test/working_copy/build/html/core/tests/bootstrap.php:23

Got this error when running a PHPUnit test. Full stack trace:

PHP Stack trace:
PHP 1. {main}() /home/travis/build/phase2/grunt-drupal-tasks/test/working_copy/vendor/phpunit/phpunit/phpunit:0
PHP 2. PHPUnit_TextUI_Command::main() /home/travis/build/phase2/grunt-drupal-tasks/test/working_copy/vendor/phpunit/phpunit/phpunit:47
PHP 3. PHPUnit_TextUI_Command->run() /home/travis/build/phase2/grunt-drupal-tasks/test/working_copy/vendor/phpunit/phpunit/src/TextUI/Command.php:100
PHP 4. PHPUnit_TextUI_Command->handleArguments() /home/travis/build/phase2/grunt-drupal-tasks/test/working_copy/vendor/phpunit/phpunit/src/TextUI/Command.php:111
PHP 5. PHPUnit_TextUI_Command->handleBootstrap() /home/travis/build/phase2/grunt-drupal-tasks/test/working_copy/vendor/phpunit/phpunit/src/TextUI/Command.php:598
PHP 6. PHPUnit_Util_Fileloader::checkAndLoad() /home/travis/build/phase2/grunt-drupal-tasks/test/working_copy/vendor/phpunit/phpunit/src/TextUI/Command.php:779
PHP 7. PHPUnit_Util_Fileloader::load() /home/travis/build/phase2/grunt-drupal-tasks/test/working_copy/vendor/phpunit/phpunit/src/Util/Fileloader.php:38
PHP 8. include_once() /home/travis/build/phase2/grunt-drupal-tasks/test/working_copy/vendor/phpunit/phpunit/src/Util/Fileloader.php:56
PHP 9. drupal_phpunit_populate_class_loader() /home/travis/build/phase2/grunt-drupal-tasks/test/working_copy/build/html/core/tests/bootstrap.php:137
PHP 10. array_map() /home/travis/build/phase2/grunt-drupal-tasks/test/working_copy/build/html/core/tests/bootstrap.php:125
PHP Fatal error: Uncaught exception 'UnexpectedValueException' with message 'RecursiveDirectoryIterator::__construct(/home/travis/build/phase2/grunt-drupal-tasks/test/working_copy/build/html/profiles): failed to open dir: No such file or directory' in /home/travis/build/phase2/grunt-drupal-tasks/test/working_copy/build/html/core/tests/bootstrap.php:23

Problem/Motivation

Determination of visibility for a given region's content is done by checking:

<?php
if ($page['region']) {...
?>

This results in wrapping divs showing regardless of content existing, which prevents other modules from suppressing various regions through hook_page_alter() w/o resorting to unsetting given regions entirely. (i.e. no using #access = FALSE)

Proposed resolution

Several approaches have been considered:

1. Use render() before determining visibility. Patch in #16 implements this solution.
   

   <?php
   $region_name = render($page['region']);
   if ($region_name) {...
   ?>

   Disadvantages

   • Confusing for themers (see #1158090: Separate usage of hide(), render(), and other template features from print statements to enable non-developers to create themes )
   • From #23: hide() will not work once the content is rendered, e.g. in:
     

     <?php if ($comment_form = render($content['comment_form'])): ?><h2 class="title comment-form"><?php print t('Add new comment'); ?></h2><?php hide($content['comment_form']['subject']); // This will not work. ?><?php print $comment_form; ?><?php endif; ?>

   • See #20 and #32. Many preprocess functions make decisions based on the unrendered state of the variable, which would not be consistent with this approach. The core issue is that each each time an element is themed, only an HTML string is returned and all the info used to render it is discarded.
   • There is a misunderstanding here however as the following works perfectly:
     

     <?php if ($comment_form = render($content['comment_form'])): ?><h2 class="title comment-form"><?php print t('Add new comment'); ?></h2><?php hide($content['comment_form']['subject']); // This will work, though it has been rendered already. ?><?php print render($content['comment_form']); ?><?php endif; ?>

     The trick is that drupal_render() itself keeps state of what has been rendered, but not #printed already. And if you do it like this:

     <?php if (is_printable($content['comment_form'])): ?><h2 class="title comment-form"><?php print t('Add new comment'); ?></h2><?php hide($content['comment_form']['subject']); // This will work, though it has been rendered already. ?><?php print render($content['comment_form']); ?><?php endif; ?>

     It will even be simple to understand ...

2. Add a helper function.

   See #36 and #38. A helper function that checks whether the element should be empty or not (based on the element's values for #access, #printed, and #children) could be used both in templates and preprocess functions.

3. Solution 3 (D8 only): Remove all show()/hide()/render() from templates.

Remaining tasks

Determine which solution to use.

Related issues:

• #997408: $tabs is always set
• #1158090: Separate usage of hide(), render(), and other template features from print statements to enable non-developers to create themes

User interface changes

Solution 1 would change tpl files as seen in the proposed code.

API changes

Original report by EclipseGc

I'm filing this against bartik, but in truth, garland, and system module both suffer from the exact same problem.

Currently determination of visibility for a given region's content is done by checking:

if ($page['region']) {...

instead of:

$region_name = render($page['region']);
if ($region_name) {...

This results in wrapping divs showing regardless of content existing, which prevents other modules from suppressing various regions through hook_page_alter() w/o resorting to unsetting given regions entirely. (i.e. no using #access = FALSE)

Eclipse

Problem/Motivation

The contact category migration dedupes the user_role entity instead of contact_form, the actual destination. And even that is using a field 'cid' which does not exist on the user role entity, so always return 0.

      plugin: dedupe_entity
      entity_type: user_role
      field: cid
      length: 32

Proposed resolution

Dedupe on contact_form using the id field.

      plugin: dedupe_entity
      entity_type: contact_form
      field: id
      length: 32

A key problem with core's field-based data structures is that referenced entities are tracked by their primary ID, not by revision. This makes it difficult to build out complex data structures using Entity Reference and referenced entities, and have the parent content managed using the new Content Moderation feature, because once one of the referenced entities is changed the changes will be publicly visible.

Proposals (pick one):

1. Extend the core Entity Reference module to (optionally) support revisions.
2. Merge the existing Entity Reference Revisions module into core.

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

Similar to the node management page, I believe that terms should also be manageable. The patch:

• Adds select all/ checkbox support to the page.
• Adds an operations field similar to the node management page. Other modules can hook in (untested) etc.
• Uses a multi-step form instead of callbacks. This should enable more complex functionality by contrib modules.
• Currently only offers a mass delete option in core.

This was created and tested against 1.331 and merged with HEAD.

First time I'm playing with multi-step forms, and I'm sure that this can be improved.

Reviews welcome.

Cheers,
-K.

Problem/Motivation

Provide a smooth, fast & safe way to transform our code to ES6.

Proposed resolution

Use https://github.com/facebook/jscodeshift as toolkit.

Remaining tasks

- Pick the high-quality codemod plugins and use in Drupal

User interface changes

- N/A

API changes

- N/A

Data model changes

- N/A

DedupeEntity->exists() should detect the case when it's updating an existing entity, and not try to change the value in that case.

In my use case, I'm importing a set of user names from a CSV file:

process:
  name:
    -
      plugin: concat
      source:
        - first_name
        - last_name
      delimiter: ''
    -
      plugin: dedupe_entity
      entity_type: user
      field: name
      postfix: ''

All of this works fine, except that each time I run the migration again with --update this process plugin detects that the user name exists already and increments (or adds) a number after the name.

This is likely the root cause of bug #2716133: Roles are duplicated instead of updated existing roles.

Problem/Motivation

Expand the Field UI to switch between two layouts: default (one region) and left/right

Proposed resolution

Add an experimental module named Field Layout.
It enhances Entity Display entities to store a layout, and enhances the Field UI to expose those settings.

Remaining tasks

N/A

User interface changes

Previously the Field UI showed all fields either in a "Content" region, or as "Disabled".
This will remain unchanged by default, additional layouts are opt-in.
There is an details element at the bottom to allow switching between layouts.

API changes

N/A

Data model changes

N/A, field_layout uses third party settings to store the data

Problem/Motivation

Drupal prefers openssl_random_pseudo_bytes() if available in Crypt::randomBytes() in 8.0.x or drupal_random_bytes() in 7.x and 6.x.

PHP used the wrong method in the openssl library now fixed in 5.6.12, 5.5.28, 5.4.44 see: https://bugs.php.net/bug.php?id=70014 but it is NOT classified as a security hole so backports are to older (ie distro) versions are less likely. Just because PHP didn't declare this a security hole doesn't mean it is not. But also read on for other scenarios where this class creates a security hole.

The returned pseudo-random bytes were NOT necessarily cryptographically secure.

Proposed resolution

Add random_compat v2.0.2 to core + use it for Crypt::randomBytes()
Adding v2 should be ok here because in drupal 7.x this includes a fallback.
(so not a concern like in #2763787: Upgrade random_compat to latest version which reverted the upgrade to v2.0.2 in drupal 8.2.x and 8.3.x)

Remaining tasks

review

User interface changes

n/a

API changes

n/a

Data model changes

n/a

RC phase evaluation

Problem/Motivation

It is difficult to expect inside the template, which variables are available there, and what they are used for. Currently, in many use cases we only pass render element to the theme system pipeline, and generate the render element into variables inside preprocess functions. Because of this, variables passed to templates are not being documented.

By forcing specifying the variables to theme registry, it would be easy to tell which variables are being passed to the template.

Also a there would be a small extra benefit of doing this, since we could provide a function inside Twig that will return all available variables without printing their contents. This information is already available in the preprocess functions but isn't trustful since any preprocess function could add new variables.

Proposed resolution

Force all hook theme implementations to define variables into the theme registry by running array_filter before passing variables to templates.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Follow-up from #196972: How does hook_views_tabs() work?.

From #2614250-14: Number widget validation can break AJAX actions by amateescu:

\Drupal\Core\Field\WidgetBase::flagErrors(), line 423, $violation->getPropertyPath() returns an empty string, which means that $delta_element = $element; below will be $element[0]['value'] instead of just $element['value'], and that's why the call to $this->errorElement() below will send the wrong form array structure.

This probably causes the following major bugs:

• #2614250: Number widget validation can break AJAX actions
• #2553983: Required textarea with summary breaks ajax events for other fields.
• #2798115: Required Number field with a Paragraph field on Content Type causes AJAX Error

Proposed resolution

Let's add the $sub_property_path of a validation violation to the errorElement() method of widgets, so they can be easily used when mapping them to elements. Probably, we can also default to 1:1 mapping between violated properties and elements.

Right, now those sub property path is already calculated and available via the undocumented $violation->arrayPropertyPath property.

Remaining tasks

User interface changes

API changes

Data model changes

Since Views is a core module, the entity/bundle creation process (code & UI) should provide the declaration of a specific admin Views specific to this content.

This way each content gets its own entry in the content menu linking to a list tailored for its specific needs : displaying only useful fields in appropriated format, providing specific filtering / sorting.

The main admin Views could still be accessible as a side tools or just kept for admin users.

This is how most of CMS works, Drupal should provide its users the same kind of UX.

Testing the new date range field, after saving the node I get the error: "The Start date is invalid. Please enter a date in the format 2016-10-06 11:45:44".