#Needs backport to D7

Trying to manually test this one but it's not clear to me how to generate a warning/info/notice message from a file upload.

Generating an error is easy - just make the file directory non-writeable. Error messages are displayed correctly

Given we've been waiting for proper steps to reproduce this since 2016, I wonder if we just close it for now?

Automatically closed - issue fixed for 2 weeks with no activity.

Line 227 of UrlHelper.php, removed comment that could confuse the meaning of the comment addition in this MR. Cannot see any purpose in it at all except to confuse people.

Feedback from xym appears to be addressed, saving credit for xjm review in the MR.

Since there's been no follow up in 3+ months going to close this one out, but if still a desired feature please re-open.

Thanks!

@quietone: @Grevil addressed your comments, could you see if they are fixed?
Would be great to get this one finished finally... :D

This test is bad as written because upload_max_filesize and post_max_size can't be set with ini_set().

dcam → changed the visibility of the branch 11.x to hidden.

dcam → changed the visibility of the branch 2557319-dont-display-size to hidden.

Thank you for sharing your idea for improving Drupal.

We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

summary updated.

Alright all done, back to needs review because of the new adjustments.

Tests fail now, maye because of removing the (string) type casting.

Created the change record here → . That should be it! RTBC!

RTBC! Works great and as expected for latest 11.x-dev.

Regarding #191 ✨ Add a token for the site logo Needs work :

I read the issue summary. There is a proposed resolution so reviewers know what to look for. However, the remaining tasks show another issue, is this issue supposed to be postponed on that or is a follow up needed?

No, the issue summary is fairly old. Both "default-" and "active-theme" works as expected.

There was concern about emails, #17. I am not sure if that was resolved. Or does this need documentation, including the CR, on how using these new tokens with mail will work.

If a user wants a specific theme logo or the default logo instead of the active theme logo, he can simply use the [site:logo:default-theme] or [site:logo:theme-my_theme] to specify the logo he wants.

Should be using a site-wide token, #173 - #180. In #176 @Berdir stated the proposed structure wouldn't work and there has been no other response from them on the subject. Has this truly been resolved? If that has been resolved it is worth adding a summary of that discussion in the Issue Summary so that it is clear for a committer.

The disussion was about adding new token types, but I think it was specifically about adding a "theme" type, as theoretically there are new token types added ("site-logo" and "site-logo-properties"), but they are mainly there to simply resolve to when using tokens such as [site:logo:default-theme] through "$token_service->findWithPrefix". So we don't really add new types but just new subtypes of "site".

TLDR: IMO, this is solved as well.

I'll create the change record and update the issue summary.

Since there's been no follow up in 3 months, going to close out. If still a desired feature please re-open

With it turning to a service in https://www.drupal.org/node/2121003 → I believe this may outdated.

Would it be useful to indicate which fields are pending deletion? I've ran into this problem a few times, most recently because a layout field wasn't fully deleted and it's taking a lot of effort to find the root of the problem. This is what I used to find the field names:

  public function validate($module) {
    $reasons = [];
    if ($field_storages = $this->getFieldStoragesByModule($module)) {
      // Provide an explanation message (only mention pending deletions if there
      // remain no actual, non-deleted fields.)
      $fields_in_use = $fields_deleted = [];
      foreach ($field_storages as $field_storage) {
        if (!$field_storage->isDeleted()) {
          $fields_in_use[$field_storage->getType()][] = $field_storage->getLabel();
        }
        else {
          $fields_deleted[] = $field_storage->getType();
        }
      }
      if (!empty($fields_in_use)) {
        foreach ($fields_in_use as $field_type => $field_storages) {
          $field_type_label = $this->getFieldTypeLabel($field_type);
          $reasons[] = $this->formatPlural(count($fields_in_use[$field_type]), 'The %field_type_label field type is used in the following field: @fields', 'The %field_type_label field type is used in the following fields: @fields', ['%field_type_label' => $field_type_label, '@fields' => implode(', ', $field_storages)]);
        }
      }
      else {
        $reasons[] = $this->t('Fields pending deletion: @fields', [
          '@fields' => implode(', ', $fields_deleted),
        ]);
      }
    }
    return $reasons;
  }

@smustgrave I don't personally see why there would be, tokens are already a sprawling hierarchy with hundreds if not thousands of derivatives once you include the token module. Also once they're defined I think they're pretty lightweight.

I also see a core committer has interacted with this patch and didn't raise any concerns at the time.

Following up on comment above

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Automatically closed - issue fixed for 2 weeks with no activity.

Feedback appears to be addressed on this one.

Thank you for sharing your idea for improving Drupal.

We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!