Beta phase evaluation

Original description

Currently the form cache has a lifetime of 6 hours by default.
I'd like to see the possibility to define a cache lifetime by using relative date formats like in php's strtotime.
Further it would be nice to be able to set the form cache expiration per form - e.g. with $form_state['cache_expire'] (Another solution could be to store this information straight into $form_state['cache'])

The goal I've in mind is to be able to get the lifetime of the page cache and the form cache in sync (The page cache is a whole different story ;) )
The scenario I think of is a website where all the pages, including the forms on it, are cacheable until tomorrow (midnight). But if the form cache is cleared before the page cache things break e.g. the ajax magic.

The attached patch contains the changes needed to introduce a custom form lifetime. The setting can be found in admin/config/development/performance .

From Twig call:

- Add inline_template function to support e.g. #post_render for render arrays with custom one-shot template.

Problem/Motivation

Drillability for Twig is important, but the scope was not clear and how to support #post_render / #theme_wrappers / drupal_render integration.

Proposed resolution

This issue frees drillability to only allow to drill-down by splitting the use case of supporting #post_render / #theme_wrappers and the rest of drupal_render into an inline_template twig tag, by replacing the actual engine render call with a method called on a twig template class.

'#render_function' => array($template, 'magicMethodName'),

Example:

{{ link }}

vs.

{% inline_template link %}
<a href="{{ attributes.href }}">{{ text }}</a>
{% endinline_template %}

Remaining tasks

* Move the #type specific things to a follow-up
** Create the follow-up and make clear what the problems are.

* Fix syntax and make it possible to specify an identifier and an expression, if the expression is a render array, hide and show will work (remove hard-coded "link")
** Like: {% inline_template "link" link %}
** Or like: {% inline_template "link" { '#type': 'link', '#href': 'node', '#title': 'hi' } %}

* Clean-up, docs and get this committed

Done tasks

* Create proof-of-concept by extending macros. This inline templates are added as macros, but internally use a different Twig_Node to call drupal_render instead.
* Extend theme() to allow setting the $render_function used to render the template within the "render variables".

User interface changes

* None.

API changes

* Adding of a new twig tag.

Related Issues

#2008450: Provide for a drillable variable structure in Twig templates

The bang ("!") placeholder for t() and format() has been removed in https://www.drupal.org/node/2575819 as a consequence of #2506427: [meta] !placeholder causes strings to be escaped and makes the sanitization API harder to understand, but LogMessageParser::parseMessagePlaceholders() still accepts it and does not accept the new colong (":") placeholder for URLs.

The line reading:
if (!empty($key) && ($key[0] === '@' || $key[0] === '%' || $key[0] === '!')) {

should probably read
if (!empty($key) && ($key[0] === '@' || $key[0] === '%' || $key[0] === ':')) {

instead.

Note: I put this in the dblog component because there's currently no logger subsystem defined in the issue queue, but there should probably be one (which I'd volunteer to maintain, BTW).

Problem/Motivation

ForumForm uses the old pattern of checking whether it is an add or an update form to provide dedicated messages.

Proposed resolution

Split ForumForm into ForumAddForm and ForumEditForm instead. One additional complexity is that ForumForm is extended by ContainerForm.

Remaining tasks

User interface changes

None.

API changes

None.

Problem/Motivation

Backwards compatibility policy for Drupal APIs is clear, and can often be used to infer the compatibility policies that might cover the Drupal REST implementation. However, without REST design documentation and an explicit policy, it is difficult for anyone thinking about providing a Drupal-based Web API or consuming a "vanilla" Drupal REST API to know what kinds of things might break on upgrades. This makes the risk of operating or integrating with Drupal REST a large and unknown quantity.

Such a document would also help jump-start best practices for individual REST-enabled Drupal systems, whose documentation/communications resources should reference or start with this text.

Proposed resolution

Document REST backwards compatibility policies to help steer development, and reference this from places in the Drupal codebase, API site, and others so technologists looking for this information can find it easily. Similar to the D8 "internal" B/C policy, the kinds of changes allowed should be tied to versioning. In this course of deriving this policy we may find a follow-up to separately track REST version from Drupal application version, a generally recommended practice that allows APIs and Application to evolve unencumbered from each other.

Items to Cover

Top-of-mind list.

• HTTP Headers (discussion of common headers like CORS and Caching helpful)
  • Removal of Headers
  • Addition of Headers
  • Change in Header values
• Entity Properties
  • Removal of entity field
  • Name change of entity field
  • Addition of entity field
  • Change in structure of entity field
  • Change in field item value format
  • Change in field item value
• Resource path

Remaining tasks

• Decide on some initial policy points
• Draft documentation
• Find a home
• Identify reference locations

User interface changes

Possibly if there are spots in the Admin determined to reference the new documentation.

API changes

None

Data model changes

None

Hi
I'm putting some blocks in my structure, but nothing comes out.
Please find joined a snapshot of the Structure/Blocks zone, showing the blocks I'd like to add ;
and a snapshot of the rendered page, with... nothing appearing.

Any idea ?

`type=submit` is default attr for button. When we use it as button we should add `type=button`.

Same request has been submitted by droplet for contextual module on #2794289: add `type=button` to contextual button

Problem/Motivation

The datetime views plugins have wonky timezone support. This needs to be fixed. While most evident in the argument plugins, the filter, and sort plugins have similar problems.

Proposed resolution

Because of coupling with the views architecture, fixing the individual plugins with separate issues is essentially impossible. In addition, a proper fix means moving some backend specific code out of the generic Sql class (date handling in SQL is not equivalent between the supported databases), and fixing some date support in Views itself.

Remaining tasks

Cry, then fix all the things and provide test coverage.

User interface changes

None.

API changes

TBD. It looks like some very low level Views classes may have interface changes.

Data model changes

Original Report

The datetime View Arguments don't take into account the user's timezone. That means that if you make a View that has \Drupal\datetime\Plugin\views\argument\YearDate argument then all users will same events even if the timezone for a user would push certain events into either the next or previous years.

This is probably an edge case for years but for the new arguments in #2567815: Add week, date, and year-month Views argument plugins would be more effect by this.

So if you used the FullDate argument then dates that would be in a different day because of the user's timezone don't show up correctly.

Working on a patch

Problem/Motivation

As was discussed in #1865594: Better REST error messages in case of exceptions, we want to respond with clearer error messages. There seem to be two different approaches which are gaining traction, api-problem from the IETF and vnd.error from the HAL community.

Proposed resolution

Decide which to use by default and implement it in a way that makes it easy to change.

Problem/Motivation

Existing error messages in Drupal REST responses are one dimensional—a string contextualized by an HTTP status code. This is limiting in several ways:

• It is very difficult to provide adequate depth of insight into an error via a one-line message.
• Categorization of "sub-types" below the level of status code and above the specific error message is difficult, inhibiting ease of troubleshooting research
• The response is too basic to facilitate more advanced integration around fault tolerance and error handling UX.

Proposed resolution

RFC 7807: Problem Details provides a description for structured XML or JSON responses that facilitate greater detail in the error messages.

A few thoughts on some of the available properties:

• type can link to documentation pages on Drupal.org about the error category, driving developers to a landing page to help facilitate research.

title can be made high-level and unique by type, to facilitate googling without the kinds of identifiers, URIs, and file paths that are unique to an environment.

• instance might be used in the future for more targeted knowledge base building. With some coordination, dedicated URLs or sections within the type URL could be linked to for more specific delving.

Example

{"type": "<url>","title": "Access denied to content","status": 403,"details": "Currently authenticated user lacks permission to view content on this site.""instance": "<url>#access-denied-to-content",
}

Furthermore, problem-specific extensions allow additional properties to be added. There are many future enhancements that might be considered from there.

Remaining tasks

1. Decide from a product standpoint if this is a good direction for the Drupal REST implementation
2. Create a facility to support message output in the application/problem+json or application/problem+xml format.
3. Perform an initial survey of REST error messages to determine categories.
4. For each error category, find or prepare a documentation page to server as the type URL.
5. Convert errors thrown in the course of REST responses to be handled by the new error response mechanism.

Out-of-initial-scope

• Handling multiple problems per error response
• Coordinating documentation for error "instance" property
• Adding flags to tailor the error response based on maintenance mode or other site states

User interface changes

REST error responses will change in structure and Content Type. Code which parses and uses the existing structure will break, though backwards compatibility might be preserved by using existing properties as "extensions" per the RFC.

API changes

New representation for errors will likely result in API additions. Changes in error handling might result in API changes to add additional parameters to some exceptions.

Data model changes

None.

Placing a block on block structure page (Zurb Foundation OR Bartik) causes the following error:

RuntimeException: The subform and parent form must contain the #parents property, which must be an array. Try calling this method from a #process callback instead. in Drupal\Core\Form\SubformState->getParents() (line 76 of /Users/maria.mcdowell/Sites/devdesktop/eemmcdowell-test/docroot/core/lib/Drupal/Core/Form/SubformState.php).

[EDITED]
I tested against multiple blocks. Any block in the category "content" fails to load, as does "user" blocks. My initial test was against what I thought was a view block, but it turns out that it was the content block created by a module, probably CTools, of the same name.

Note that the Entity (user and content) blocks work without error, so it is not all things created by CTools.

Problem/Motivation

DER 8.x-2.x has a different column for JOINs than the column used for storage.

Proposed resolution

Factor out the relationship entity table join into a method so DER can override it in #2808337: Make use of proposed entity table relationship refactor

Remaining tasks

Commit. There's no need for a test, the existing tests suffice as there's no change whatsoever.

User interface changes

API changes

Data model changes

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

The styling for the Views bulk action form is limited and can lead to confusion when presented along side other form elements. For example, on the administration content listing page (/admin/content) the bulk action form is presented beneath the exposed filter form and confusion can exist between the fields and apply buttons for the two forms.

Before:

Proposed resolution

Add a wrapper mechanism and some simple block styles to the bulk action form wherever it appears in the Seven theme (both for views bulk operations and hardcoded bulk operations like the comment list).

Maybe in the future

An enhanced version is possible that 'joins' the Views table header visually with the bulk action form, adding an additional pointer arrow to the 'select' checkbox column. This approach would not work when the View doesn't use a table display, so we discarded this for now.

Remaining tasks

Reviews.

User interface changes

Change of Views bulk action form styling background and border, see proposed resolution.

API changes

No changes. Adding #bulk_operations element.

Data model changes

None

Problem

When setting language detection method, the checkbox Customize Content language detection to differ from User interface text language detection settings is not applied, only the interface configuration.

This leads to two critical issues with translating content:

1. It is not possible to edit translated version of a node. All "Edit" urls on node's "Translate" tab are the same and lead to main editing form. See edit.png.
2. Translated content is never shown to the user. Default language is always displayed.

Steps to reproduce

On a fresh D8 install:

1. Enable content translation and language modules
2. Add another language
3. Set Detection and selection method to session and browser (tested both, both are broken)
4. Configure content type "Article" to be translatable (Administration >> Configuration >> Regional and language)
5. Add a node and set it's language to default one (I used article with image. All fields were filled including image)
6. Translate node to a second language and save.
7. Go to "Translate" tab and investigate "Edit" links. Both lead to the same page.
8. Go to the newly create node and try switching language using "session" parameter. You will still see the node in default language.
9. Do the same with a browser running second language (or just spoof the browser string to change language). You will still see the node in default language.

Remaining tasks

1. Investigate why the checkbox Customize Content language detection to differ from User interface text language detection settings is ignored. The source of the issue lies probably inside Drupal\language\Form\NegotiationConfigureForm::submitForm() function. - the configuration is correctly saved
2. Create patch - Patch is provided

User interface changes

No changes to the UI are required for the fix.

API changes

The protected variable type which indicates whether a given type of language usage (language_content, language_interface, language_url) changes to an array to allow different types to initialize during the initialization of another.

The following error shows ups for views with required relationships:

Warning: htmlspecialchars() expects parameter 1 to be string, array given in Drupal\Component\Utility\Html::escape() (line 421 of core/lib/Drupal/Component/Utility/Html.php).

The issue probably starts at: ./docroot/core/modules/views/views.views.inc:713: 'label' => t('@field_name: @label', $args),

Problem/Motivation

7.x backport for #1377740: file_unmanaged_move() should issue rename() where possible instead of copy() & unlink(). The code has not changed much and the bug is exactly the same.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

• All Migrate criticals requiring a BC break are now fixed as of last week.
• There are seven other issues tagged as Migrate BC break.
• @mikeryan proposed earlier during the RC that the Migrate module itself (not migrate_drupal) could be considered API-complete once the highwater issue was resolved, and that any further BC breaks would be limited to module-specific plugins.

Proposed resolution

• Consider migrate.module beta as of 8.2.0. The expectations for beta experimental modules are:
  

  • Beta experimental modules are considered API- and feature-complete. Some early adopters may begin using beta experimental modules on development sites, but should be aware that they are not yet fully supported and may contain bugs.
  • Developers can begin using beta modules' APIs, but should be aware that some things may still change to address bugs. Beta modules are subject to the beta allowed changes policy.
  • An upgrade path may be provided from beta versions, but be aware it may contain critical bugs.

• Provide BC for any future API changes in migrate.module.
• Continue to treat migrate_drupal and module-specific implementations as alpha-stability code and change them as needed without requiring BC.

Remaining tasks

• Needs signoff from Migrate maintainers and framework and release managers.

Problem/Motivation

When placing blocks on /admin/structure/block a newly placed block gets a weight of null. This means the placement of the block will be unpredictable.

1. Navigate to /admin/structure/block
2. click "place block" within content region
3. Select "Place block" next to any block (breadcrumbs for example)
4. Change no settings and click "save block"
5. You are directed back to the block list layout page
6. Notice the newly created block is at the bottom of the content category list of blocks
7. Click "Show Row Weights" and notice the number is a very low negative number
8. Save the page without re-arranging any of the weights.
9. The block is not in a different order than was originally viewed.

Proposed resolution

When creating a block, set the default weight to 0.

Problem/Motivation

Currently, any implementations of \Drupal\Core\Entity\EntityForm::copyFormValuesToEntity(), or any #entity_builders callback will be run twice on form submit.

This is usually not a problem, as they copy things from $form_state->getValues() to the $entity.

It becomes problematic when your code checks the old values in comparison to the new values. In this case, on the second run, different code paths will be followed.

This is due to an incorrect check in \Drupal\Core\Entity\EntityForm::afterBuild() introduced in #2448357: Config entity forms need to have access to an updated entity object at all times.
It uses $form_state->isProcessingInput(), but should use $form_state->isSubmitted().

This is purposeful, because content entities must be updated with the form values in order to be validated.

Proposed resolution

Document it.

Remaining tasks

Document it.

User interface changes

N/A

API changes

N/A

Data model changes

N/A