We have added a date field to a node type called EVENT.

When we use the default admin edit form for the node we have noticed that the values for the date are saved in the database -2hours from what is entered.

There never seems to be any problem when viewing nodes or editing nodes. BUT we are using a REST service to access and write nodes... when we do this to doesn't add or remove the 2 hours either way...

Changing Time Zone of Default Country doesn't change anything either way...

We're a bit confused by this and are wondering what we may be doing wrong. Has anybody else encountered this problem?

Problem/Motivation

Initially, I'm filing this against hal.module because I'm going to assume the problem isn't deeper rooted. It very well may be. In that case, this would have to move to the serialization.module component, or even the routing system component.

While working on #2737719: EntityResource: Provide comprehensive test coverage: for every entity type, every format, every method, I encountered incorrect error responses in case of missing/failed authentication. Let me quote #2737719-38: EntityResource: Provide comprehensive test coverage: for every entity type, every format, every method, which is where this is being reported:

the error response body in case of missing Basic Authentication is different for the json and hal_json formats. In the former case, it's actually in JSON, but with a strange prefix, and in the latter case, it's in plain text…

Proposed resolution

hal_json

1. Preferably: the error response for hal_json should be in application/json. Both the Content-Type header and the actual response body should use that MIME type.
2. Alternatively: the Content-Type header should at least match the reality, which is that the response body is in text/plain, so the header should not pretend it's something else.

json

Ensure that strange prefix (i.e. A fatal error occurred: ) is no longer present.

Remaining tasks

TBD

User interface changes

None.

API changes

TBD, hopefully none.

Data model changes

TBD, hopefully none.

#2060677: Add target_type, target_uuid to serialized output of entity reference fields in non-HAL formats added target_type and target_uuid to the normalization. But didn't add denormalization support. It was intended to become a follow-up, but that follow-up was never filed. Until now.

#2060677-21: Add target_type, target_uuid to serialized output of entity reference fields in non-HAL formats:

Should we also be adding a new EntityResolverInterface here for denormalizing?

#2060677-22: Add target_type, target_uuid to serialized output of entity reference fields in non-HAL formats:

We have the right tools already I think, we just need serialization module to actually use them. I think we should do that in a follow up to this though, and just keep this for adding this to the denormalized data. Sound ok?

Problem/Motivation

A D8 install can easily generate extremely lengthy file/directory names when caching Twig templates.

On some scenarios, the maximum length for a path might be limited by the OS:

• Windows has a maximum path length of 260 characters. Can read more here.
• If you are in Linux and have the filesystem where you have the site mounted using eCryptfs and its configured to encrypt filenames as well as the file content you will experience this same issue. You can read a little about this limitation here.

To reproduce this issue on Windows, add the following to settings.php.

$settings['file_public_path'] = 'sites/default/files/0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-01'; // That's a 255-char dir name.

Proposed resolution

Update as of #144 going with option #3

Option #3: Trigger a requirement error on windows if the Drupal root is deeper than 100 characters. Use our existing base64 hash and hmac functions so the hashes are half as long to start. Truncate the human-readable template name portion and hash portion of the to a maximum length so the directory names can never be longer than 51 characters. The cache file name itself has already been shortened to 47 characters using the bas64 hmac in the split-off child issue #2830596: MTimeProtectedFastFileStorage::getFullPath() creates really long filenames unnecessarily

Update: as of #39, options #2 is the preferred solution.

Option #1: Use the Unicode path prefix (\\?\) on Windows to avoid the 260 character limit (pushes the limit to around 32k which is well above Linux's limit of 4k characters). Unfortunately, PHP's support of these pathnames is limited. (see #16) which would require a much more disruptive fix.

Option #2: Use shorter hashes while retaining the "uniqueness" of these directory and file names. However, the filename hash contains the filemtime() of the containing directory. If, for example, file uploads were compromised and malicious code added to a cached Twig template, the containing directory's filemtime would change and the hash would not match. Using shorter hashes could potentially increase the risk of a compromised file still passing the hash test. (Security review requested).

Also, option #2 does not solve the underlying problem, but hopefully gives us some breathing room. Currently, there are two 64-character hashes in each cached Twig template.

Remaining tasks

As of #12:

1. not needed since we're using option #2: FileStorage::unlink does not work with the Unicode prefix
2. Needs security review to ensure that shortened hashs still give enough "uniqueness" for MTimeProtectedFastFileStorage
3. Needs tests to assert that generated files do no exceed a (somewhat arbitrary) limit
4. Done: Add hook_requirements to warn users when installing Drupal on Windows with a long path name.

User interface changes

Adds a new warning when installing Drupal on Windows at a path > 100 characters.

API changes

With option #2, none.

Data model changes

None.

A user of clientside_validation reported this bug (#1585554: Validating lists (select-fields) not working correctly), it is caused by the fact that the options.module uses the following: $options = array('_none' => $label).

First problem is that the outputted HTML contains <option value="_none"> and this means the select element has a value.
Second (unrelated) problem is that we allow people to enter "_none|oops" as an allowed value, but it will never be outputted unless a default value is selected.

I found #735426: Fields with select widget: first option is selected by default even if no 'default value' set for the field where this was introduced, so I would like to change the use of '_none' to NULL

Normally, when one or more of the widgets in the exposed form of a view has errors, Views exits the build process for the view and "empties" it.

However, when such a view with exposed widgets is embedded on a page that has one or more unrelated forms "built" before the view is rendered, the same thing happens again. Views is unable to make out the difference between errors caused by its exposed form and by other forms built on the page before it.

I have a sandbox project that illustrates this issue. On downloading and enabling the project, go to /views-example.

http://drupal.org/sandbox/amarnus/1863012
http://drupalcode.org/sandbox/amarnus/1863012.git

Problem/Motivation

When a form in the settings tray uses vertical tabs the settings tray is too narrow to accommodate the two column structure so the tabs break. They also do not match the style of the rest of the tray.

Proposed resolution

Re-style the vertical tabs so they fit the pace better and match the tray background.

Remaining tasks

review patch

User interface changes

Vertical tabs in the tray fit the space and match it's style.

API changes

?

Data model changes

?

Problem/Motivation

I was fighting a strange problem that config schema validation failed due to a string/integer mismatch when saving config in a form.

Turned out that it was a classic Heisenbug, as it only existed because I had a debug($config->get()) call before calling save.

And what happens then is that overriddenData is initialized. Then you save, it casts all the data and saves it correctly. Then comes \Drupal\Core\Config\Development\ConfigSchemaChecker::onConfigSave() and calls $saved_config->get()... and receives the old, overridden data and throws an exception.

Proposed resolution

Move $this->resetOverriddenData(); up, before actually writing the config and invoking the event.

Remaining tasks

User interface changes

API changes

Data model changes

Currently, Layouts can provide their own icon image which can be used in user interfaces. These icons could be in any size, color, dimensions, or style. As a result, user interfaces suffer as consistency is lost between different Layouts. The best example of this are the bright-pink icons provided by Radix, which look nothing like the default Panels or Display Suite Layouts (this isn't Radix's fault, we can't expect everyone to have the same design opinions).

The provided patch is a proof of concept for dynamically generated icons, which can not only help with consistency but could also be used in user interfaces to directly interact with regions. This also reduces developer strain as filling out config is far easier than creating an icon (which is a skill not everyone has).

Instead of making something fully featured, I wanted to put this forward and see if anyone sees value in what I've already done. Simply apply the provided patch, enable the layout_plugin_example module, and visit the path /admin/layout_plugin_example/layout_map/layout_example_stacked.

What you see on that page is the result of a new configuration value, "icon_map", which is a two-dimensional array mapping region names to their visual placement on a page. Widths of regions are determined dynamically based on the number of columns per row in the array. You can also hover over any region to see a tooltip containing the machine name of the region. See layout_plugin_example.layouts.yml for the exact structure used.

Thoughts?

Problem/Motivation

Expand the Field UI to switch between two layouts: one column and two column (left/right)
Since this issue depends on #2296423: Implement layout plugin type in core, modules and themes will have the ability to provide new layouts.

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

Currently all the CSS in the Settings Tray module is in the drupal.outside_in library.

Presumably in #2784443: Move off-canvas functionality from Settings tray module into drupal.dialog.ajax library so that other modules can use it the off-canvas tray will need some of this CSS to look and behave correctly.

Proposed resolution

Move all needed CSS needed for the off-canvas tray to drupal.off_canvas.

Remaining tasks

Determine which CSS that is.
Also there is a lot of CSS to format form elements. Should that CSS be available to other modules that would like to put forms in the tray when Settings Tray is disabled?

If we do want to move the form CSS from Setting Tray should it be an option to use it in the tray or not. We could make loading the CSS for forms an option in data-dialog-options.

User interface changes

API changes

Data model changes

The drupal.outside_in library contains all the CSS in the module.

Even though a form_unset_error function can be dangerous in the wrong hands, the API documentation would allow to add such a warning, which does not exist when people use just some code snippet from api.drupal.org:

Proposed function:

/**
 * Clears an error against one form element.
 *
 * @param $name
 *   The name of the form element.
 */
function form_unset_error($name) {
  $errors = &drupal_static('form_set_error', array());
  $removed_messages = array();
  if (isset($errors[$name])) {
    $removed_messages[] = $errors[$name];
    unset($errors[$name]);
  }
  $_SESSION['messages']['error'] = array_diff($_SESSION['messages']['error'], $removed_messages);
  if (empty($_SESSION['messages']['error'])) {
    unset($_SESSION['messages']['error']);
  }
}

For D8 this will look different, because there all errors are collected and then messages send at once.

Follow-up to #2807705: FormattableMarkup::placeholderFormat() can result in unsafe replacements

Enhance trigger_error with an improved message and a link to the CR. Suggestion, courtesy of @alexpott:

elseif (strpos($string, $key) !== FALSE) {
  trigger_error("Fallthrough for unrecognised placeholders to %variable has been removed. See https://www.drupal.org/node/2605274. Invalid placeholder ($key) in string: $string', E_USER_DEPRECATED);
}

Problem/Motivation

\Drupal\views\Plugin\views\field\EntityOperations allows to add the destination but if an operation already has a fixed destination property, it doesn't override it.

Should it?

For example, create a view of block_content entities, add operation links, enable the option, but the destination for edit still points to the default view because \Drupal\block_content\BlockContentListBuilder::getDefaultOperations() hardcodes that.

Proposed resolution

After some discussion, we think that it should not override, to support operations that explicitly point to some other place.

Instead we change \Drupal\block_content\BlockContentListBuilder::getDefaultOperations() is wrong and should use the RedirectDestinationTrait to return back to the current page, no matter where that is exactly.

Remaining tasks

User interface changes

API changes

Data model changes

Having alt and title information as a part of the image field itself is a conceptual failure. Alt and title information is related to display, hence they should be options in a field formatter. Ideally we get support for fields that can be attached to files which can provide per-file metadata like alt and title, which the formatter can the specify the alt text should be [file:field_alt_text] or the title should be [file:field_title].

While working on a patch for Linkit I failed to set a custom attribute as link text without completely overriding the plugin.js of drupallink.

drupallink uses this code to create the link text: var text = new CKEDITOR.dom.text(returnValues.attributes.href.replace(/^mailto:/, ''), editor.document);
Do I have to override the complete plugin to use another attribute returned by the editor dialog?

Eventually the following code fragment would be an option (as a patch), but maybe there is a better way.

// Use link URL as text with a collapsed cursor.
if (range.collapsed) {
  // Shorten mailto URLs to just the email address.
  var text = new CKEDITOR.dom.text(returnValues.attributes.href.replace(/^mailto:/, ''), editor.document);
  if (editor.config.hasOwnProperty('drupalLink_attributeText') && returnValues.attributes.hasOwnProperty(editor.config.drupalLink_attributeText) && returnValues.attributes[editor.config.drupalLink_attributeText].length) {
    // Use custom attribute as link text.
    text = new CKEDITOR.dom.text(returnValues.attributes[editor.config.drupalLink_attributeText], editor.document);
  }
  range.insertNode(text);
  range.selectNodeContents(text);
}

There are a couple of references in Drupal core to https://www.drupal.org/cron. This is a redirect however to the Drupal 7 documentation on cron with url https://www.drupal.org/docs/7/setting-up-cron/overview.

We have two options here:

1. Update the documentation on d.o so that d.o/cron redirects to Drupal 8 documentation.
2. Update the links in Drupal core to https://www.drupal.org/docs/8/cron-automated-tasks.

In settings.php, the private file path is documented with "This directory must be absolute, ...". However, an absolute path does not work when drupal runs on a shared host and access to the parent directories is not possible.

Example:
• a shared host with drupal root /var/www/ud17_276/html/drupal
• web server root is /var/www/ud17_276/html
• shared host root is /var/www/ud17_276, i.e., this part is not visible for the space admin, and thus neither for drupal
• in settings.php:
$settings['file_private_path'] = '/var/www/ud17_276/files/drupal-private';

If a drupal user tries to upload a file, by creating a node of a content type having a file field with private storage configured, drupal tries to create the full parent path, /var/www/ud17_276, which obviously will fail. The error message in the log is:

"The upload directory private://2016-09 for the file field field_privimage could not be created or is not accessible. A newly uploaded file could not be saved in this directory as a consequence, and the upload was canceled."

Configuring the shared host's users relative root, like
$settings['file_private_path'] = '/files/drupal-private';
does also not work. The only way this seems to work currently is a relative path:

$settings['file_private_path'] = '../../files/drupal-private';

Hence, either the code documentation in settings.php should be updated to include this case, or the coding has to be changed to be able to deal with shared hosting. (Unfortunately, due to lack of php knowledge, I cannot judge these options.)

Best, Tobias

I have a Field API field and I have attached it to an entity. This field has multiple fields in it. When I submit the form without all fields filled I get the "This value should be of the correct primitive type." error.

Is this a bug or am I doing something wrong? I was having trouble with serialized field for storing metadata but I've been able to get around it by setting it to computed field. But I cannot do that in this case.

Steps to Reproduce
I found this bug in branch 8.0.x and 8.1.x
PHP 5.6.14

Follow these steps to reproduce the problem.

1. Applying actual patch from ImageFormatter does not support SVGs
2. Install and enable ImageMagick
3. Go to configuration module and set enable svg
4. Go to modification any image field, add svg to allow extension
5. Try add svg image to any node

Problem/Motivation

The entity.query, entity.query.sql and the entity.query.keyvalue services are factories and yet they are not named so.

Proposed resolution

Rename them to *.factory making them in line with cache.factory, config.factory, logger.factory etc etc

Remaining tasks

User interface changes

API changes