Quantcast
Channel: Issues for Drupal core
Viewing all 296695 articles
Browse latest View live

Add 'user/edit' route

$
0
0

Problem/Motivation

Currently users have routes such as /user which automatically redirects to the currently logged in users page.

In some cases this makes it very cumbersome to add a link to a users editing page without adding custom code. It would be very convenient to simply add in a link to 'user/edit' in, say, a simple HTML block.

Proposed resolution

Add another convenience route /user/edit which automatically redirects to the currently logged in users page.

The user controller already has this functionality to direct to the active users edit page. This only requires the addition of the route.

Remaining tasks

  • Add the route 'user/edit'.
  • Add some relevant tests to the user controller.
  • Get feed back from the community.
  • Commit that bad boy.

API changes

No backwards compatibility issues. This simply adds a new route so it should be placed into a minor release.


Set #maxlength for TelephoneDefaultWidget to the one specified in TelephoneItem plugin

$
0
0

We hardcoded length for TelephoneItem to 256. However TelephoneDefaultWidget doesn't set #maxlength in TelephoneDefaultWidget::formElement() which makes it be set to 128 (default for Drupal\Core\Render\Element\Tel).

Add a status report check that the site can connect to the public Internet

$
0
0

Problem/Motivation

Splitting from #1538118: Update status does not verify the identity or authenticity of the release history URL.

If Update Manager is enabled, it's essential that the site can reach the outside world. Some sites have trouble with this, due to proxy servers, network configuration, or potentially badly configured PHP/cURL, etc.

Steps to reproduce

Depends on the situation. ;)

Proposed resolution

Add a status report check that the site can contact the outside world.

We'll probably want:

  • Some retry logic.
  • A list of servers to ping -- if one fails, it could be that that server is temporarily down. To "know" the site can't talk to the outside world, we'd need to see connections failing to at least a couple of different hosts.
  • ...

Remaining tasks

  1. Decide how exactly this should work.
  2. Implement it.
  3. Add tests.
  4. UX review of the text for the status report.
  5. Reviews / refinements.
  6. RTBC.
  7. Commit.

User interface changes

TBD

API changes

TBD, probably none.

Data model changes

TBD, probably none.

Release notes snippet

TBD

Remove unused variable $link in UserFieldsAccessChangeTest.php, user module

$
0
0

Problem/Motivation

In core/modules/user/tests/src/Functional/Views/UserFieldsAccessChangeTest.php, $link variable never used.

Sort direction is not hidden when no sort field is selected

$
0
0

Problem/Motivation

I noticed this problem while working on #3089525: Sort options should correspond to bundles selected for entity reference field settings.

Using the Standard profile,

  1. Visit /admin/structure/types/manage/article/fields
  2. Click the "Add field" button.
  3. Select Content under the Reference group.
  4. Enter a label, then "Save and continue".
  5. On the next screen, click the "Save field settings" button.
  6. In the "Reference type" section, select at least one content type. This will expose the "Sort by" select list.
  7. Select a "Sort by" field. The "Sort direction" select list should appear.
  8. De-select all content types.
  9. The "Sort by" option is hidden, but the "Sort direction" option is still there.

We have to be careful that the fix for this problem does not break reference fields for entity types, like User, that do not have bundles.

Proposed resolution

TBD

Remaining tasks

User interface changes

When no bundles are selected, the "Sort direction" option is hidden as well as the "Sort by" option.

Current behavior:

screenshot showing no "Sort by" option but the "Sort direction" option is visible

API changes

None

Data model changes

None

Update status does not verify the identity or authenticity of the release history URL

$
0
0

Problem/Motivation

If the video filter man in the middle XSS (eg via evil DNS) is classified as a security issue, shouldn’t the current update status process (eg via admin/reports/updates/update) be marked a security issue as well?

As far as I can see there are no authenticity checks whatsoever on the release data and download.

This can be used to

1 - prevent reception of update alerts via the update status channel
2 - entice admins to install modules from untrusted servers

(this has been cleared by the secteam for public discussion, the suggestion was the Infra queue, but it would need Core support as well).

Steps to reproduce

Enable Update manager

Proposed resolution

  • Try to fetch over https.
  • Print warning messages on the available updates report and the 'Update' form if the site failed to fetch data, warning admins about proper HTTPS config
  • Fallback to the current HTTP URL only if the 'update_fetch_with_http_fallback' setting has been overridden to TRUE (defaults FALSE).
  • Migration to D8/9 sites from D7 and before will re-write the update_fetch_url config from HTTP to HTTPS

E-mailing admins if their site is failing to fetch info is at #3162336: Update manager should email admins when it fails to fetch available update data

Remaining tasks

  1. Create the d.o handbook page documenting the details so we can link to it. Update the @todo URL in the patch.https://www.drupal.org/docs/system-requirements/php-openssl-requirements (see patch #137)
  2. Decide if we need the flexibility of a Twig template for this (#132) or if we can just use some hard-coded stuff via the Messenger service (#134). Yes to a template - see #139 for why.
  3. Decide if we need DI for the UpdateManagerUpdate form (#135a) or can just use \Drupal::service() (#135b) No new DI, it's a template_preprocess() now (see #139).
  4. Decide what (if any) new automated testing we need for the error messages, fallback setting, etc. Kernel tests added in #140.
  5. Needs manual testing
  6. Needs UX review See #136
  7. Maybe needs a product manager review?
  8. Needs a release manager review to decide about backports with all these new strings and other changes
  9. Release note snippet?
  10. CR?
  11. RTBC
  12. Commit
  13. https://www.drupal.org/node/3170647/edit to update the version info in the docs about this.
  14. Backport(s)?

User interface changes

New messages if Update Manager fails to fetch available updates (presumably because the site's PHP isn't configured for outbound HTTPS requests to work):

Available updates report

Available updates report when a site can't make outbound HTTPS requests

Update form

Updates form when a site can't make outbound HTTPS request

Cryptic watchdog message

This is why we need a handbook page. ;)
Error message in DB log when site can't make outbound HTTPS request

New setting documented in default.settings.php

/**
 * Fallback to HTTP for Update Manager.
 *
 * If your Drupal site fails to connect to updates.drupal.org using HTTPS to
 * fetch Drupal core, module and theme update status, you may uncomment this
 * setting and set it to TRUE to allow an insecure fallback to HTTP. Note that
 * doing so will open your site up to a potential man-in-the-middle attack. You
 * should instead attempt to resolve the issues before enabling this option.
 * @see https://www.drupal.org/docs/system-requirements/php-requirements#openssl
 * @see https://en.wikipedia.org/wiki/Man-in-the-middle_attack
 * @see \Drupal\update\UpdateFetcher
 */
# $settings['update_fetch_with_http_fallback'] = FALSE;

API changes

  • New Twig template: update-fetch-error-message.html.twig with template_preprocess_update_fetch_error_message()
  • New UpdateSettings migrate source plugin
  • \Drupal\update\Controller\UpdateController now needs the 'renderer' service injected.
  • \Drupal\update\UpdateFetcher (the 'update.fetcher' service) now needs the site Settings injected.
  • TBD: Renderer service injected into \Drupal\update\Form\UpdateManagerUpdate?

Data model changes

N/A

Release notes snippet

The Update Manager now fetches available update data over HTTPS. Your site's PHP must have OpenSSL properly configured. If that's not possible, you can set $settings['update_fetch_with_http_fallback'] = TRUE; in your settings.php file to use the less secure HTTP fallback. See the PHP OpenSSL requirements section of the Drupal.org handbook for more details.

Sort bundle labels in Field list report

$
0
0

Problem/Motivation

If you go to the Field List page (admin/reports/fields) you will see that the USED IN column don't have the bundles labels in alphabetical order, so sometimes is a little difficult to find an information if we have a field shared between many bundles.

Proposed resolution

Sort the USED IN column using the sort() function.

Remaining tasks

User interface changes

The USED IN column will have the bundle labels in an alphabetical order.

API changes

None.

Data model changes

None.

Make the '+' icon for action buttons optional


$entity->original->isPublished() always returns false

$
0
0

in hook_entity_update, I monitor when an entity is being published by comparing previous and current value of isPublished().

$isPublished = $entity->isPublished();
$wasPublished = $entity->original->isPublished();

However, $wasPublished returns false all the time. When I try to directly access value of the 'status'-field

$isPublished = $entity->get('status')->getValue()[0]['value']
$wasPublished = $entity->original->get('status')->getValue()[0]['value']

values returned are of different types: integer in the first case, string in the second case. Which means, there is a type mixup somewhere deeper.

This and such issues arise from the lack of coding standards, in case of PHP, how to handle the overly flexible type system.

content should be loaded according to IP address

$
0
0

I would like to understand how we can serve different content based on the region of the user who is accessing the website. For example, we would like to use American English content for users accessing the website from USA and Middle East whereas, if a user is from the UK, the British English content should be loaded.

[IGNORE] shaktik patch test

Simple decimals fail to pass validation

$
0
0

Problem/Motivation

- Create decimal field, set precision to 10 (minimum in the UI and scale to 4
- Saving new node with value 19999.0000 succeeds (precision is 5+4 = 9).
- Saving new node with value 99999.0000 fails (same precision as above).

or

- Create decimal field, set scale to anything over 6 (need 8 to store bitcoin values for example). I used 16 as precission.
- Saving new node with value 20.12345678 fails validation while 0.1234567 succeeds.

This is because Drupal\Component\Utility\Number::validStep() returns false. Detailed investigation on this function (which is only used once in Drupal), reveals that the first argument ($value) is received as a string, but $step and $offset are floats. PHP seems to slightly mangle the $step value on the first case above from 0.0001 to 0.00010000000000000001438. Passing the step parameter as a string in the case of decimal numbers maintains the correct precision, and allows a correct approximation calculation.

Proposed resolution

Bypass weak PHP floating-point handling by passing the step as a string.

Remaining tasks

Merge. Commit. Decimals FTW!

User interface changes

None.

API changes

A new field was added to the Number FormElement, in order to decide when to use the workaround. This "#number_type" field may be useful in other cases.

Data model changes

None.

Possible workaround if you need big decimals

Disable this validation by setting the render element #step to 'any'

i.e.

$element['#step'] = 'any';

In the case of fields, you can do

function MYMODULE_form_FORM_WITH_BIG_DECIMAL_FIELD_alter (array &$form, FormStateInterface $form_state) {
  $form['field_some']['widget'][0]['value']['#step']='any';
}

And if you want to target all decimal fields:

/**
 * Prevents validation of decimal numbers
 * @see https://www.drupal.org/node/2230909
 */
function MYMODULE_field_widget_form_alter(&$element, \Drupal\Core\Form\FormStateInterface $form_state, $context) {
  $field_definition = $context['items']->getFieldDefinition();
  if ($field_definition->getType() == 'decimal') {
    $element['value']['#step'] = 'any';
  }
}

oEmbed validator should use the urlResolver to get the resource URL

$
0
0

Problem/Motivation

The OEmbedResourceConstraintValidator doesn't use the UrlResolver service to get the resource URL.
This is a problem if hook_oembed_resource_url_alter is implemented because all the changes to the resource URL will not be taken into account.

Proposed resolution

Use the UrlResolver service to build the resource URL.

Block layout title ADA issue

$
0
0

In the block configuration we can uncheck checkbox "Display Title". Then title get a class "visually-hidden". This method removes only visually display of title, but screan readers still can read it. That behavior is undesirable. For example you can add CSS property "visibility" with "hidden" value to remove this item for readers too.

Also this titles has a <h2> tag in the HTML markup that provide WCAG error P883 if we do not put <h1> element before.

Descriptions containing links break admin menu lists.

$
0
0

Problem/Motivation

If a content type description contains an <a> tag it results in a broken display of the Add content administration page when using the Seven theme.

Steps to reproduce:

  1. Spin up a sandbox site on SimplyTest.me: http://ply.st/drupal/8.0.x
  2. Install as Standard Drupal 8 profile with default configuration.
  3. Navigate to the Add content type page: admin/structure/types/add
  4. Add a new content type with the following settings:
    • Name: Test
    • Description:Test with <a href="https://drupal.org">Link</a>
  5. Navigate to the Add content page: node/add

This is present in the following templates:

  • admin-block-content.html.twig
  • block-content-add-list.html.twig
  • node-add-list.html.twig

The issue is due to the description variable being wrapped with an anchor tag, which causes the DOM to be re-arranged to comply with standards.

Proposed resolution

  1. Remove the wrapping anchor tag; Potentially cause a regression issue with #1488962: Increase touch target size of admin menu lists
  2. Sanitize the Description variable, removing anchor tags; Potentially reduce usability
  3. Replicate the wrapping anchor tag with Javascript; Potentially cause an issue for non-JS users

Remaining tasks

User interface changes

API changes

Data model changes


hold_test module creates files in incorrect place leading to possible random errors

$
0
0

Problem/Motivation

The hold_test module creates files in
\Drupal::root() . '/sites/default/files/simpletest/'
so they are not test environment specific which means that two tests using this module can have random fails when run together.

For example: \Drupal\Tests\quickedit\FunctionalJavascript\QuickEditIntegrationTest and \Drupal\FunctionalJavascriptTests\Ajax\ThrobberTest

Proposed resolution

Use the test sites public files directory.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

[META] Add new Olivero frontend theme to Drupal 9.1 core as beta; later make it stable and the default

$
0
0

Problem/Motivation

The Drupal core Bartik theme was released as part of Drupal 7 in January 2011, 9 years ago. It was great! It also stayed pretty much the same ever since and been included with Drupal 8 and even Drupal 9. The web moved forward a whole lot in 9 years and Bartik is not doing justice to Drupal anymore. It was great in 2011, it is not great anymore.

Proposed resolution

Drupal 9 needs a new default frontend theme. A new, modern, clean frontend theme, Olivero is being built in the contributed project https://www.drupal.org/project/olivero for inclusion in Drupal core. See http://lb.cm/olivero for a demo of Olivero.

Olivero Theme

Designs are at #3088378: Designs for new front-end theme for Drupal 9.

Olivero “alpha” criteria (Initial Core Inclusion)

Must-haves for the alpha release:

Features
Accessibility
Design/Usability improvements
Bugs
Technical debt
Core inclusion/Dependencies

Olivero “beta” criteria (After Core Inclusion)

Must-haves for the beta release:

Features
Accessibility
Bugs
Core inclusion/Dependencies

Olivero “stable” criteria (After Core Inclusion)

At this point Olivero will be considered stable, and can be made the default front-end theme.

Must-have issues for stable release:

Features
Bugs
Technical debt

Olivero “Post-stable” criteria

Features
Bugs
Technical debt
Accessibility
Design/Usability improvements

Related Drupal Core Issues

Issues required to set Olivero as the default front-end theme for core

API changes

None.

Data model changes

None.

Release notes snippet

A new modern, clear frontend theme has been added to Drupal core called Olivero. (continue TBD)

Ability to Subtheme

Subtheming Olivero will not be initially supported, but we may include formal support in the future. That being said, if we find simple issues that can lead us toward making this more simple, we will commit them.

Timeline

Disclaimer: I have no idea what I'm doing as far as core timelines and tend to be optimistic in my estimations

  • Now: As of June 18th, 2020, we're on alpha3. We plan on releasing alpha4 on the week of June 29. release.
  • Week of July 3 First beta. The beta will concentrate on
    • Accessibility
    • Coding standards
    • The process to get into core
  • Every one to two weeks: new beta

Initial core inclusion is planned as beta (not default).

Double click prevention on form submission

$
0
0

Updated: Comment #7

Problem/Motivation

Why is there no double click prevention built into Drupal core? Surely this should be standard functionality?

D7: the current patch (form.js) only works on forms using fieldsets or vertial tabs according to @JvE in #99

Steps to reproduce

  1. Use Chrome
  2. Navigate to admin/modules
  3. Scroll down
  4. Triple click the 'Save configuration' button
  5. Check the network page chrome provides which has 3 POST request.
  6. Apply the patch
  7. The network page does now contain just one POST request
  1. Use Chrome
  2. Log out
  3. Navigate to user/register
  4. Enter a user name and mail address
  5. Triple click the submit button
  6. Depending on your speed you get
    • Exception
    • Already taken

Proposed resolution

Integrate https://github.com/sun/jquery-form-submit-single

Remaining tasks

User interface changes

API changes

#494096: Using Chrome ConfirmForms do not double click prevention causing site effects
#881494: Double-clicking the "Install Drupal" button completely breaks everything
#483876: Disable install button once clicked

Original report by @ltwinner

I'm working on a site for someone and they complained that if they double click quickly on the node save form two nodes get created. I was surprised at this and checked it myself and found it was true.

Why is there no double click prevention built into Drupal core? Surely this should be standard functionality? Lots of sites have this, I know vBulletin has it anyway from looking at their source code and you can see it yourself if you double click fast on a vBulletin forum's submit new post button.

So has this feature been overlooked for Drupal or is it left out by design?

Downgrade minimum supported Apache version to >= 2.4.6

$
0
0

Problem/Motivation

In https://www.drupal.org/project/drupal/issues/3114079, the minimum supported Apache version was upgraded to >= 2.4.7, on the premise that Apache 2.4.6 and below are ancient, unsupported, and those versions contain a number of known vulnerabilities.

The only version of Apache certified for use on Red Hat Enterprise Linux 7 (RHEL7) is 2.4.6, and upgrading beyond this version on RHEL7 servers is strongly discouraged (unlike PHP and other requirements). Apache 2.4.6 in neither ancient not unmaintained, as it is actively updated and maintained by RedHat, who has back-ported all security updates (through version 2.4.34) into the release.

While many users of RHEL7 can upgrade to RHEL8, please note that RHEL8 is not approved for use on U.S. federal government servers (see https://access.redhat.com/articles/2918071 for compliance status), meaning that the latest version of RHEL that Federal users can upgrade to us RHEL7. Requiring Apache 2.4.7 will effectively block all U.S. Federal web sites running RedHat Enterprise Linux from upgrading from Drupal 8 to Drupal 9.

Even if RHEL8 gains approval for use on U.S. Federal government servers today, many of these sites will not be able to upgrade to RHEL8 before Drupal 8's EOL in November 2021 and will be forced to consider a different CMS.

Furthermore, the "setifempty" directive is not actually used in .htaccess in Drupal 9, making the premise of the requirement for Apache 2.4.7 or greater irrelevant.

Proposed resolution

Reduce the the D9 requirements to require at least Apache 2.4.6, not 2.4.7.

Remaining tasks

- Discuss if changing the requirement is acceptable;
- Update the documentation/requirements

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Toolbar buttons should respond to spacebar key

$
0
0

Spin-off from #3066954: Admin toolbar not usable with latest versions of JAWS due to mis-use of aria-owns.

Problem/Motivation

Buttons don't respond to the spacebar key. These are faux buttons (<a href="" role="button">) which only respond to the return key. Can be replicated in Firefox and Chrome.

These are reported as buttons to assistive tech. Screen readers will announce them as buttons, and include them in the list-of-buttons tool. A role is a promise which sets user expectations of how the button can be operated.

Proposed resolution

Add a keyboard handler to the <a href="" role="button"> so it responds to the spacebar key.

Note, the <button> is normally preferred for a disclosure control such as this. However when JS doesn't run, these top-level links are still present and work as basic links to /admin, /user, and /admin/config/user-interface/shortcut. They are links, which are progressively enhanced to buttons; it's appropriate to use <a role="button"> for this. We just need to complete the expected behaviour of a button.

Remaining tasks

  • Update toolbar JS.
  • Tests - simulate a keypress in a FunctionalJavascript or Nightwatch test, and confirm the toolbar tray is visible/hidden. Repeat for both the spacebar and return key.
Viewing all 296695 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>