I'm trying to delete a file that was uploaded by a form. The files reside here in Drupal 8: http://localhost/drupal/admin/content/files

It's not intuitive to me how to delete these files. I often find myself Googling a lot when using Drupal (I find most of it non-intuitive), unfortunately most documentation is also severely lacking compared to other systems. This makes the learning curve unnecessarily large! To me this is a huge issue.

Anyway, I guess I have to Google 'how to delete files in Drupal 8'... and do yet another trawl. It's difficult not to get annoyed. Even though Drupal is powerful, somebody needs to sort out the documentation and make it more intuitive for new users.

Problem/Motivation

The datetime module has one function it it that isn't a hook: datetime_date_default_time(). This function should not exist.

Proposed resolution

At the very least we should @deprecated it, but we would also need to provide the proper alternative. Ideally, the field should just handle this own so that the widgets/formatters/etc don't need to worry about this.

Usages in tests should be refactored out into something on DateTestBase, like a massageTestDate($date) method, to DRY this up.

Remaining tasks

Discuss.

User interface changes

API changes

Data model changes

> What are the steps required to reproduce the bug?

When registering for your localhost Drupal admin account, do the following:

1) Create a 64 character password (e.g. using a password manager). Include symbols, such as $ and %, and numbers, lowercase and uppercase.
2) Sign out
3) Sign back in (using password manager, or at least a copy and paste to ensure you aren't entering the wrong password)

> What behaviour were you expecting?

I was expecting to be able to login.

> What happened instead?

I was told I had the wrong password. I tried creating a shorter password of 60 characters (as there seemed to be something about a 60 max password in another bug report). However, this also failed.

File extension validation fails if you try to upload a file like 'fred.php' or 'jenny'. This seems to be because these types of files are automatically renamed for security purposes. This rename, stops the file extension validation from being called it seems.

public function buildForm(array $form, FormStateInterface $form_state) {
    $form['document_scan'] = array
    ('#type' => 'managed_file','#title' => t('Document (Scanned Copy)'),'#description' => t('Upload a file. Allowed extensions: pdf, jpg, jpeg, png, gif'),'#required' => TRUE,'#upload_validators'  => array
      ('file_validate_extensions' => array('pdf jpg jpeg png gif'),'file_validate_size' => array(25600000),
      ),'#upload_location' => 'public://myfile/'
    );

I created a new content type called 'Person applying for job'. The person had a date of birth field. This was set to 'date only' rather than 'date and time'. I set the date when adding a person as content, however when this person displayed, the date was shown, but also '12:00'. Expected: The time shouldn't display if the field is set to 'date only'.

The code below looks wrong to me. A date-only field should not have it's time set to '12:00'. It should have no time at all. It should be set to NULL. That way there is never any confusion at other levels... i.e. a date-only field (with time set to 12:00) can't later be confused as a date-time field!

core/modules/datetime/src/DateTimeComputed.php

  public function getValue($langcode = NULL) {
    if ($this->date !== NULL) {
      return $this->date;
    }

    /** @var \Drupal\Core\Field\FieldItemInterface $item */
    $item = $this->getParent();
    $value = $item->{($this->definition->getSetting('date source'))};

    $datetime_type = $item->getFieldDefinition()->getSetting('datetime_type');
    $storage_format = $datetime_type === DateTimeItem::DATETIME_TYPE_DATE ? DATETIME_DATE_STORAGE_FORMAT : DATETIME_DATETIME_STORAGE_FORMAT;
    try {
      $date = DrupalDateTime::createFromFormat($storage_format, $value, DATETIME_STORAGE_TIMEZONE);
      if ($date instanceof DrupalDateTime && !$date->hasErrors()) {
        $this->date = $date;
        // If the format did not include an explicit time portion, then the
        // time will be set from the current time instead. For consistency, we
        // set the time to 12:00:00 UTC for date-only fields. This is used so
        // that the local date portion is the same, across nearly all time
        // zones.
        // @see datetime_date_default_time()
        // @see http://php.net/manual/en/datetime.createfromformat.php
        // @todo Update comment and/or code per the chosen solution in
        //   https://www.drupal.org/node/2830094
        if ($datetime_type === DateTimeItem::DATETIME_TYPE_DATE) {
          $this->date->setTime(12, 0, 0);
        }
      }
    }
    catch (\Exception $e) {
      // @todo Handle this.
    }
    return $this->date;
  }

When trying to upload a module, I got the following error message:

• File Transfer failed, reason: Unable to remove to file /var/www/drupal/modules/webform/.gitignore

It should say 'Unable to remove THE file'.

The offending files are below:

/var/www/drupal/core/lib/Drupal/Core/FileTransfer/FTPExtension.php:
   75    protected function removeFileJailed($destination) {
   76      if (!ftp_delete($this->connection, $destination)) {
   77:       throw new FileTransferException("Unable to remove to file @file", NULL, array('@file' => $destination));
   78      }
   79    }

/var/www/drupal/core/modules/system/src/Tests/FileTransfer/TestFileTransfer.php:
   47    function removeFileJailed($destination) {
   48      if (!ftp_delete($this->connection, $item)) {
   49:       throw new FileTransferException('Unable to remove to file @file.', NULL, array('@file' => $item));
   50      }
   51    }

Problem/Motivation

Follow-up from #2638150: Move _system_default_theme_features() to theme.inc which has a patch.

Proposed resolution

Remaining tasks

Upload the patch from the other issue here and continue.

User interface changes

API changes

Data model changes

Translating a menu link results in an error (Integrity constraint violation) in both: Drupal\Core\Entity\EntityStorageException and Drupal\Core\Database\IntegrityConstraintViolationException

Steps to reproduce:
1. Installed lightning v8.x-2.03 via Acquia Dev Desktop
2. Install Content Translation and Language modules
3. Add the Spanish language (admin/config/regional/language)
4. Go here: admin/config/regional/content-language
5. Under Custom Language Settings, check Custom Menu Link
6. Under Custom menu link, check Custom menu link and Menu link title
7. Add a new menu (/admin/structure/menu/add) and a few links
8. Click Translate for a menu link (/admin/structure/menu/manage/{menu name here}
9. Once Translate is clicked, the new path is: /admin/structure/menu/item/12/edit/translations
10. Click Add for the Spanish translation
11. Click save on the new Spanish translation of the menu item

2 errors show up in the log:

Location: http://mysitenamehere.dev.dd:8083/es/admin/structure/menu/item/12/edit/t...

Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '12' for key 'PRIMARY': INSERT INTO {menu_link_content_data} (id, revision_id, bundle, langcode, title, description, menu_name, link__uri, link__title, link__options, external, rediscover, weight, expanded, enabled, parent, changed, default_langcode, workspace, _deleted, _rev, content_translation_source, content_translation_outdated, content_translation_uid, content_translation_status, content_translation_created) 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, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13, :db_insert_placeholder_14, :db_insert_placeholder_15, :db_insert_placeholder_16, :db_insert_placeholder_17, :db_insert_placeholder_18, :db_insert_placeholder_19, :db_insert_placeholder_20, :db_insert_placeholder_21, :db_insert_placeholder_22, :db_insert_placeholder_23, :db_insert_placeholder_24, :db_insert_placeholder_25), (:db_insert_placeholder_26, :db_insert_placeholder_27, :db_insert_placeholder_28, :db_insert_placeholder_29, :db_insert_placeholder_30, :db_insert_placeholder_31, :db_insert_placeholder_32, :db_insert_placeholder_33, :db_insert_placeholder_34, :db_insert_placeholder_35, :db_insert_placeholder_36, :db_insert_placeholder_37, :db_insert_placeholder_38, :db_insert_placeholder_39, :db_insert_placeholder_40, :db_insert_placeholder_41, :db_insert_placeholder_42, :db_insert_placeholder_43, :db_insert_placeholder_44, :db_insert_placeholder_45, :db_insert_placeholder_46, :db_insert_placeholder_47, :db_insert_placeholder_48, :db_insert_placeholder_49, :db_insert_placeholder_50, :db_insert_placeholder_51); Array ( [:db_insert_placeholder_0] => 12 [:db_insert_placeholder_1] => 56 [:db_insert_placeholder_2] => menu_link_content [:db_insert_placeholder_3] => en [:db_insert_placeholder_4] => refunds [:db_insert_placeholder_5] => [:db_insert_placeholder_6] => nav [:db_insert_placeholder_7] => internal:/refunds [:db_insert_placeholder_8] => [:db_insert_placeholder_9] => a:0:{} [:db_insert_placeholder_10] => 0 [:db_insert_placeholder_11] => 1 [:db_insert_placeholder_12] => 0 [:db_insert_placeholder_13] => 0 [:db_insert_placeholder_14] => 1 [:db_insert_placeholder_15] => [:db_insert_placeholder_16] => 1489031705 [:db_insert_placeholder_17] => 1 [:db_insert_placeholder_18] => 1 [:db_insert_placeholder_19] => 0 [:db_insert_placeholder_20] => 2-b512ccf75245bbe28b0a649bd0b6f236 [:db_insert_placeholder_21] => und [:db_insert_placeholder_22] => 0 [:db_insert_placeholder_23] => 11 [:db_insert_placeholder_24] => 1 [:db_insert_placeholder_25] => 1489031279 [:db_insert_placeholder_26] => 12 [:db_insert_placeholder_27] => 56 [:db_insert_placeholder_28] => menu_link_content [:db_insert_placeholder_29] => es [:db_insert_placeholder_30] => refundo [:db_insert_placeholder_31] => [:db_insert_placeholder_32] => nav [:db_insert_placeholder_33] => internal:/refunds [:db_insert_placeholder_34] => [:db_insert_placeholder_35] => a:0:{} [:db_insert_placeholder_36] => 0 [:db_insert_placeholder_37] => 1 [:db_insert_placeholder_38] => 0 [:db_insert_placeholder_39] => 0 [:db_insert_placeholder_40] => 1 [:db_insert_placeholder_41] => [:db_insert_placeholder_42] => 1489031705 [:db_insert_placeholder_43] => 0 [:db_insert_placeholder_44] => 1 [:db_insert_placeholder_45] => 0 [:db_insert_placeholder_46] => 2-b512ccf75245bbe28b0a649bd0b6f236 [:db_insert_placeholder_47] => en [:db_insert_placeholder_48] => 0 [:db_insert_placeholder_49] => 11 [:db_insert_placeholder_50] => 1 [:db_insert_placeholder_51] => 1489031705 ) in Drupal\Core\Database\Connection->handleQueryException() (line 668 of /Users/myname/Sites/devdesktop/mysitenamehere-dev/docroot/core/lib/Drupal/Core/Database/Connection.php).

Location: http://mysitenamehere.dev.dd:8083/es/admin/structure/menu/item/12/edit/t...

Drupal\Core\Entity\EntityStorageException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '12' for key 'PRIMARY': INSERT INTO {menu_link_content_data} (id, revision_id, bundle, langcode, title, description, menu_name, link__uri, link__title, link__options, external, rediscover, weight, expanded, enabled, parent, changed, default_langcode, workspace, _deleted, _rev, content_translation_source, content_translation_outdated, content_translation_uid, content_translation_status, content_translation_created) 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, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13, :db_insert_placeholder_14, :db_insert_placeholder_15, :db_insert_placeholder_16, :db_insert_placeholder_17, :db_insert_placeholder_18, :db_insert_placeholder_19, :db_insert_placeholder_20, :db_insert_placeholder_21, :db_insert_placeholder_22, :db_insert_placeholder_23, :db_insert_placeholder_24, :db_insert_placeholder_25), (:db_insert_placeholder_26, :db_insert_placeholder_27, :db_insert_placeholder_28, :db_insert_placeholder_29, :db_insert_placeholder_30, :db_insert_placeholder_31, :db_insert_placeholder_32, :db_insert_placeholder_33, :db_insert_placeholder_34, :db_insert_placeholder_35, :db_insert_placeholder_36, :db_insert_placeholder_37, :db_insert_placeholder_38, :db_insert_placeholder_39, :db_insert_placeholder_40, :db_insert_placeholder_41, :db_insert_placeholder_42, :db_insert_placeholder_43, :db_insert_placeholder_44, :db_insert_placeholder_45, :db_insert_placeholder_46, :db_insert_placeholder_47, :db_insert_placeholder_48, :db_insert_placeholder_49, :db_insert_placeholder_50, :db_insert_placeholder_51); Array ( [:db_insert_placeholder_0] => 12 [:db_insert_placeholder_1] => 56 [:db_insert_placeholder_2] => menu_link_content [:db_insert_placeholder_3] => en [:db_insert_placeholder_4] => refunds [:db_insert_placeholder_5] => [:db_insert_placeholder_6] => nav [:db_insert_placeholder_7] => internal:/refunds [:db_insert_placeholder_8] => [:db_insert_placeholder_9] => a:0:{} [:db_insert_placeholder_10] => 0 [:db_insert_placeholder_11] => 1 [:db_insert_placeholder_12] => 0 [:db_insert_placeholder_13] => 0 [:db_insert_placeholder_14] => 1 [:db_insert_placeholder_15] => [:db_insert_placeholder_16] => 1489031705 [:db_insert_placeholder_17] => 1 [:db_insert_placeholder_18] => 1 [:db_insert_placeholder_19] => 0 [:db_insert_placeholder_20] => 2-b512ccf75245bbe28b0a649bd0b6f236 [:db_insert_placeholder_21] => und [:db_insert_placeholder_22] => 0 [:db_insert_placeholder_23] => 11 [:db_insert_placeholder_24] => 1 [:db_insert_placeholder_25] => 1489031279 [:db_insert_placeholder_26] => 12 [:db_insert_placeholder_27] => 56 [:db_insert_placeholder_28] => menu_link_content [:db_insert_placeholder_29] => es [:db_insert_placeholder_30] => refundo [:db_insert_placeholder_31] => [:db_insert_placeholder_32] => nav [:db_insert_placeholder_33] => internal:/refunds [:db_insert_placeholder_34] => [:db_insert_placeholder_35] => a:0:{} [:db_insert_placeholder_36] => 0 [:db_insert_placeholder_37] => 1 [:db_insert_placeholder_38] => 0 [:db_insert_placeholder_39] => 0 [:db_insert_placeholder_40] => 1 [:db_insert_placeholder_41] => [:db_insert_placeholder_42] => 1489031705 [:db_insert_placeholder_43] => 0 [:db_insert_placeholder_44] => 1 [:db_insert_placeholder_45] => 0 [:db_insert_placeholder_46] => 2-b512ccf75245bbe28b0a649bd0b6f236 [:db_insert_placeholder_47] => en [:db_insert_placeholder_48] => 0 [:db_insert_placeholder_49] => 11 [:db_insert_placeholder_50] => 1 [:db_insert_placeholder_51] => 1489031705 ) in Drupal\multiversion\Entity\Storage\Sql\ContentEntityStorage->save() (line 152 of /Users/myname/Sites/devdesktop/mysitenamehere-dev/docroot/profiles/lightning/modules/contrib/multiversion/src/Entity/Storage/ContentEntityStorageTrait.php).

A few errors here when doing updates. The update fails, and yet the message at the bottom says 'your modules have been downloaded and updated' (false).

The file in questions is set to 777 file permissions, and has group set to _www which is correct for Mac I think.

A better error message would help a lot. How about:

"Unable to remove to file /Library/WebServer/Documents/drupal/modules/webform/composer.json, as it belongs to the wrong group. Should be _www, see article XYZ"
OR
"Unable to remove to file /Library/WebServer/Documents/drupal/modules/webform/composer.json, due to a file permissions issue. Currently set to 600, should he 755, see article XYZ2"

I'm getting the following error. I don't know what to do. I've given 777 for file permissions and set the group correctly (AFAIK).

webform

Error installing / updating
File Transfer failed, reason: Unable to remove to file /Library/WebServer/Documents/drupal/modules/webform/composer.json
Next steps

Your modules have been downloaded and updated.

Problem/Motivation

Without labels a boolean field as input widget has no label(s) that describe the selection option(s). This is a usability error. An (unexperienced) site builder is confused by the field titles and descriptions on the boolean field 'Field settings' form.

1. Add a new field of type boolean to a content type.
2. In the Field settings form, enter no 'On value' and no 'Off value'
3. Notice that in the Edit form, under 'Default values' the selection options have no label.
4. Optionally: In 'Manage form display' select the 'single on/off value' widget.
5. Create two nodes, one with this field set and one without.
6. On the node form the field's selection option(s) have no label.
7. Display both nodes: no value is displayed.

Proposed resolution

To be determined.

User interface changes

To be determined.

Original report by jramby

Hi,

I am trying to create a view by showing a field with a boolean value. In views_ui when I try to add the default publish status field of an article content type, we can by default choose a desired output format with the values : "Yes/No", "True/False", "On/Off", "Enabled/Disabled", "✔/✖", "Published/Not published".

But with a custom boolean field we can't have these choices, We can just choose between : "Default translated", "Default", "Key", "Group subscription", We can't show anything else than 1 by selecting "Key".

In addition, when we add a filter on this same custom boolean node field, there is no possibility of choosing output format. Then in the filter dropbox there are the next values : "- Any -", "", "".

How can I provide a label to my exposed filter and my fields value.

Thank you all.

Hi,

In template_preprocess_book_navigation() there is a call to drupal_render() which will be depreciated. Looking at https://api.drupal.org/api/drupal/core%21includes%21common.inc/function/... this should be replaced with a call to the renderer service instead.

    if ($next = $book_outline->nextLink($book_link)) {
      $next_href = \Drupal::url('entity.node.canonical', array('node' => $next['nid']));
      $build['#attached']['html_head_link'][][] = array('rel' => 'next','href' => $next_href,
      );
      $variables['next_url'] = $next_href;
      $variables['next_title'] = $next['title'];
    }
  }

  if (!empty($build)) {
    drupal_render($build);
  }

  $variables['has_links'] = FALSE;
  // Link variables to filter for values and set state of the flag variable.
  $links = array('prev_url', 'prev_title', 'parent_url', 'parent_title', 'next_url', 'next_title');
  foreach ($links as $link) {
    if (isset($variables[$link])) {
      // Flag when there is a value.
      $variables['has_links'] = TRUE;
    }
    else {

Cheers

Tom

#2324121: NodeType's settings array was meant to be able to store information from mutliple modules is making the "which menus are available for a node type" part of the node type config entity by using the new third party settings API.

In D6, we only had a single setting, for the default menu (menu_default_node_menu), I think we need to do something similar to menu_update_7000() to make sure that the setting still makes sense in 8.x?

For D7, we will need to migrate them from the old per-node-type variables (as seen in the update function) to third party settings. In general, we possibly need support for those on config entities.

Problem/Motivation

We need to provide an upgrade path from 7.x for the core Statistics module.

Remaining Tasks

We need migrations, with tests, to cover:

• Any variables maintained by Statistics need to be moved into configuration
• The contents of the node_counter table may need to be migrated

Follow-up to #2817103: Theme registry doesn't find templates in subfolders for self-defined theme hooks

Problem/Motivation

Noticed $template_candidates uses $info['theme path'] which never shows a different template.

Proposed resolution

Remove candidates

Resetting user's password while it's beign blocked causes error:

Warning: Cannot modify header information - headers already sent by (output started at /includes/common.inc:2697) funktiossa drupal_send_headers() (rivi 1216 tiedostossa /includes/bootstrap.inc).

I'm currently building a cross-platform mobile app and headless web-app (https://github.com/CityWebConsultants/Drupal8-cordova-app) and so far I can register users, login, load views, view/edit nodes and next I want to allow users to create new nodes.

To follow the same approach as the main website, there needs to be:

1) A list of content types the user can use to create nodes.

2) Access to the schema of respective content types so that a 'node add' form can be generated on the client.

Are either or both of these services in the pipeline? I think at the very least 2 is a great feature to have and means node creation forms don't have to be hard-coded in headless apps which then causes a headache if the schemas do change on the backend.

Thanks

Problem/Motivation

\Drupal\page_cache\StackMiddleware\PageCache::getCacheId() uses $request->getUri() for cache ID generation.

\Symfony\Component\HttpFoundation\Request::getUri() doc says

Generates a normalized URI (URL) for the Request.

This means page cache IDs are based on the normalized URLs, not on the real ones.

If #2641118: Route normalizer: Global Redirect in core lands in core, we might get circular redirects, example:
- user requests http://example.com/path?test=a+b
- route normalizer responces with a redirect to nirmalized URL http://example.com/path?test=a%20b
- page_cache module caches the redirect with a normalized incoming URL - http://example.com/path?test=a%20b
- user is redirected to http://example.com/path?test=a%20b
- page_cache has a cache entry for http://example.com/path?test=a%20b
- circular redirect

Proposed resolution

Replace $request->getUri() with $request->getSchemeAndHttpHost() . $request->getRequestUri()

As a "side effect" we'll get a small performance improvement mentioned in #2501989-17: [meta] Page Cache Performance

Steps to re-create :

open any entity form in modal using
'class' => array('use-ajax'),
'data-dialog-type' => 'modal' for a link.

and then enter something in form which triggers a validation error. it takes us to window based view instead of showing in modal.

In Bartik theme setting i put some color name #2967 in Footer background, in Preview I can see the color changing , But After click on Save Configuration , I am getting the error "You must enter a valid hexadecimal color value for Footer background." If the Color code is not Valid , Then In Preview the Change should not Reflected . Please see the attached screenshots .

While creating an issue in drupal.org , when i click on Component, it displays blank dropdown for some while , again if Clicked it shows the dropdown list . Actually it happens for other dropdowns also sometimes . Please see the screenshot .