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

Add query batching to SqlBase

$
0
0

Problem/Motivation

Large migrations can be problematic, from both a query standpoint and a processing standpoint. Adding the ability to batch process a migration would be helpful. With batch support, the ability to limit migrations would be a much easier task as well. See #2282013: Add a row limit option to MigrateExecutable.

Proposed resolution

Add batching support to the core migrate module.

Remaining tasks

All the tasks.

User interface changes

Possibly the ability to limit migrations from the UI.

API changes

TBD


Make SchemaCheckTestTrait available outside of the config module

$
0
0

Problem/Motivation

The trait \Drupal\config\Tests\SchemaCheckTestTrait doesn't belong into the config namespace, but rather into core/tests/Drupal/Tests

Proposed resolution

Let's move it there, but keep the old one as alias.

Remaining tasks

User interface changes

API changes

Data model changes

Add assertNoCacheTag/assertCacheContext to assertLegacyTrait

$
0
0

Problem/Motivation

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Improve usability of Views bulk action form in Seven theme

$
0
0

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 View exposed filter form and confusion can exist between the fields and apply buttons for the two forms.

Before:

Current bulk action form on admin content page

Proposed resolution

As a minimum, add some simple block styles to the bulk action form wherever it appears in the Seven theme.

Proposed:

Proposed bulk action form on admin content page - simple version

I'm also working on an enhanced version that 'joins' the Views table header visually with the bulk action form and adds an additional pointer arrow to the 'select' checkbox column. I'm still working on issues that this approach throws up when the View doesn't use a table display.

Possible 'enhanced' version:

Proposed bulk action form on admin content page - enhanced version

Proposed small screen styling:

Proposed bulk action form on admin content page - small screens all versions

I've created an initial patch for this proposed change.

Remaining tasks

Thoughts and reviews needed! I've not yet touched the styling for the filter form which you will see from the small screen screenshot could use some work also.

User interface changes

Change of Views bulk action form styling background and border

API changes

None

Data model changes

None

Allow instantiating Attribute objects within Twig

$
0
0

Problem/Motivation

Sometimes you have an array of attributes and it would be nice if you could addClass, removeClass, setAttribute, etc. rather than trying to do array manipulation.

Proposed resolution

Add a function to our Twig extension to allow creating an Attribute object from an array of attributes.
allow_instantiating-2616756-16.patch

Remaining tasks

All of them.

User interface changes

n/a

API changes

API addition: New Twig function added (name TBD).

Data model changes

n/a

Add changelog for Drupal 8.2.0

$
0
0

Problem/Motivation

No changelog entry for 8.2 yet.

Proposed resolution

Add a changelog entry with sufficient items covering the changes.

Remaining tasks

Expand with missing items.

User interface changes

None.

API changes

None.

Data model changes

None.

Node add form shows 'create new revision' checkbox

$
0
0

Problem/Motivation

It would be interesting to know how you can create a new node without a new revision being created.

Proposed resolution

Don't show the checkbox, it doesn't do anything.

Remaining tasks

User interface changes

API changes

Data model changes

Gracefully handle a non-existent cache service like cache.backend.memcache

$
0
0

I'm running into errors when a memcache backend is defined in settings.php, but the module that provides it isn't enabled (yet). I think the fix is to check for the non-existent cache service and default to using the database cache backend by default.

Examples where this is needed is when re-installing the site from scratch with config_installer which we are using for our automated testing. Also if one wanted to deploy memcache module along with it's settings to a site where it wasn't enabled yet.

There doesn't seem to be a way to confirm the existence of a module in settings.php (which makes sense from a performance standpoint), so I think it makes sense to add a graceful fallback when it's not available. Patch forthcoming.

To reproduce or test, set the memcache settings in settings.php and try to use the site.

  $settings['memcache']['servers'] = [$memcache_ip .':11211' => 'default'];
  $settings['memcache']['bins'] = ['default' => 'default'];
  $settings['memcache']['key_prefix'] ='';
  $settings['cache']['default'] = 'cache.backend.memcache';

[meta] Add .php extension to PHP files

$
0
0

Problem/Motivation

Currently we have more or less 6 non-standard extensions to represent PHP files with. This is most certainly a Drupal-ism.

This issue proposes that PHP files should always have the extension: .php

Reasons to do this:

Unnecessarily complex for newcomers

Newcomers not only have to learn Drupal, they need to configure their IDE and/or OS to open a file with the correct program and get some syntax highlighting working. This is a DX win that makes drupal more out of the box accessible for development. (see #4, #18) And it helps us get off the island :)

Security

Not all sites run on apache or IIS where we have config files to stop them from serving those files displayable directly to the browser. Many people store sensitive info in PHP files, like API keys, or passwords and we can’t add configuration files for every web server that currently exists (or ever will exist). (see #17)

Consistency

As Crell points out (#20) PSR-0 mandates that classes end must end in .php for autoloader interoperability. Drupal is becoming more OO so most of the code will be in .php files. Why not all of the code?

Reasons to not do this:

It’s the Drupal Way

We have thousands of modules, themes, and profiles on drupal.org and countless more bespoke modules on sites... every current Drupal developer will have to do things differently, and all the contrib projects with D8 branches will need to rename files.

Non-standard extensions are not executable

Files with non-standard extensions are not executable and some people might rely on this behavior. (see #12, #67 and below)

Proposed resolution

We have two options...

OldOption 1Option 2
foo.modulefoo.module.phpfoo.php
foo.installfoo.install.phpfoo.install.php
foo.incfoo.inc.phpfoo.inc.php
bar.themebar.theme.phpbar.php
baz.profilebaz.profile.phpbaz.php
quux.enginequux.engine.phpquux.php

In order to proceed with option 2 we have to complete #1292284: Require 'type' key in .info.yml files
See #28
Update: There seems to be a clear consensus for Option 1.

Bulk renaming files in a directory using bash:
for f in $(find . -name "*.module" -o -name "*.profile" -o -name "*.theme" -o -name "*.install" -o -name "*.inc" -o -name "*.engine"); do mv $f ${f}.php; done

Remaining Tasks

  • Commit
  • Publish the change record
  • Follow-up: Update documentation on drupal.org in module, theme, and profile developer guides

Original report

There shouldn't be .inc files.
.inc.php is better since webservers won't allow users to view their content.
Just in case someone modifies one with confidential information.

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue categoryTask because: this needs to happen at some point in the life of the project for the various reasons stated in this entire issue.
Issue priorityNormal because: core isn't currently "broken" without it.
Prioritized changes
  • Reduces fragility: When installing Drupal on a server that's not Apache or IIS (since that's what we ship config for), having a .php extension more or less guarantees that code won't be exposed to the end user. It'll be handled like a normal PHP file, and that's the *right* behavior because that's what it is.
  • Possible security fix: Possible information disclosure if you have API keys hardcoded somewhere for some strange reason
DisruptionDisruptive for core/contributed/custom projects because: they will have to initially re-roll any existing patches or rename the files in the codebase. There is, however, no code (in core or contrib) that will actually need any real logistical refactoring to get it "working" again. Most changes will be simple renaming of files. Other changes may include doing a very quick search and replace of manually included to add the necessary .php extension. While this may be deemed "disruptive", it is in reality more work simply talking about this issue that doing the changes and moving forward.

Allow to skip the the path processing in the url generator

Fix CHANGELOG.txt for 8.2.0 to remove paragonie/random_compat update

Privacy issue with 'Request new password' form: anonymous can check if someone is registered

$
0
0

Problem/Motivation

We want to avoid that everybody can check if an email is already registered on a Drupal site. So, an anonymous user can easily check whether there is a user registered with a certain e-mail-address or not. Therefore the displayed message must be changed.

On 'Request new password' form (/user/password), you get the following message if you enter a unused mail address or username:

Sorry, john.doe@example.com is not recognized as a user name or an e-mail address.

If you enter a used mail address or username, you get:

Further instructions have been sent to your e-mail address.

So, an anonymous user can easily check whether there is a user registered with a certain e-mail-address or not.

I think this can be a privacy issue. Think of the following scenario:
Alice wants to check if her fiancé Bob is registered at "adult-dating.example.com", a well known Internet dating site run by Drupal. She visits adult-dating.example.com/user/password and enters his mail address bob@doe-family.example. If she gets the message "Further instructions have been sent to your e-mail address.", she'll know that there is a user registered with Bobs mail address (= Bob himself) or with a username matching his mail address (unlikely that it would be someone else).

Proposed resolution

never print "Sorry, XYZ is not recognized as a user name or an e-mail address.",
always print "Further instructions have been sent to your e-mail address.".

Maybe we should change the wording of this message then (adding something like "if matched any account").

Remaining tasks

Contributor tasks needed
TaskNovice task?Contributor instructionsComplete?
Reroll the patch if it no longer applies.Instructions
Update the issue summary noting if allowed during the betaInstructions

User interface changes

On 'Request new password' form the status message if an email is already registered is going to be changed:

Sorry, john.doe@example.com is not recognized as a user name or an e-mail address.

If you enter a used mail address or username, you get the following message that should be changed also:

Further instructions have been sent to your e-mail address.

API changes

None

Original report by no2e

(coming from #1359718: Allow password reset on account w username matching another email. Prevent registrations which match another account)


On 'Request new password' form (/user/password), you get the following message if you enter a unused mail address or username:

Sorry, john.doe@example.com is not recognized as a user name or an e-mail address.

If you enter a used mail address or username, you get:

Further instructions have been sent to your e-mail address.

So, an anonymous user can easily check whether there is a user registered with a certain e-mail-address or not.

I think this can be a privacy issue. Think of the following scenario:
Alice wants to check if her fiancé Bob is registered at "adult-dating.example.com", a well known Internet dating site run by Drupal. She visits adult-dating.example.com/user/password and enters his mail address bob@doe-family.example. If she gets the message "Further instructions have been sent to your e-mail address.", she'll know that there is a user registered with Bobs mail address (= Bob himself) or with a username matching his mail address (unlikely that it would be someone else).

Possible solution:
never print "Sorry, XYZ is not recognized as a user name or an e-mail address.",
always print "Further instructions have been sent to your e-mail address.".

Maybe we should change the wording of this message then (adding something like "if matched any account").

Steps to reproduce this issue

  • Install the latest Drupal 8.0.x version
  • log in and create a new user with a username and email
  • log out
  • go to the following page: user/password
  • enter a name or email of an invalid user
  • if the latest patch is not applied the following message appears: Sorry, john.doe@example.com is not recognized as a user name or an e-mail address.
  • then enter the name or email of the new user you just created
  • if the latest patch is not applied the following message should appear: Further instructions have been sent to your e-mail address.
  • aply the latest patch
  • when entering a valid or invalid username or email just the following message should always appear: Further instructions have been sent to your e-mail address.
  • so, now there is only one message displayed and it is not possible any more to check if an email is registered or not

Integrate PHPUnit verbose output in Simpletest UI

$
0
0

Problem/Motivation

Many developers still use the Simpletest UI and it is already possible to run PHPUnit-based browser tests there. We want to print out the list of pages a browser test visited in the result of a browser test run in the UI. We want to provide developers with a similar experience as with Simpletest where they get the verbose output of pages in a test run.

We also want to improve the output of phpunit with nl2br() so that the fail messages of PHPUnit are more readable.

Proposed resolution

Run phpunit from the UI with a proper printerClass to catch the verbose output and improve the output in the HTML table with nl2br() or similar.

Before:
UI before

After:
UI after

Remaining tasks

Patch.

User interface changes

More verbose output in the Simpletest UI when PHPUnit browser tests are run.

API changes

none.

Data model changes

none.

What is the positioning of the Views section

Cloned entity will point to the same field objects if the clone was created after an entity translation has been initialized

$
0
0

Problem/Motivation

Steps to reproduce:
1. Create an entity with two translations.
2. Reload the entity.
3. Execute $entity->getTranslation("second_langcode");
4. Execute $clone = clone $entity.
5. Test that $entity->field_name === $clone->field_name.

Proposed resolution

Ensure the fields array is actually cloned by overwriting the original reference with one pointing to a copy of the array.

Remaining tasks

Review.

User interface changes

none.

API changes

none.

Data model changes

none.


Date hour format is hard coded and can't be override

$
0
0

So I have this date field with 'datetime_datelist' widget. Its now showing 1, 2, 3, .. for hours but I want that to be like 01, 02, 03, etc (date time H format) but when i dig out I found that Datelist::processDatelist() its hardcoded and can't be override. Now i don't know how to override it.

I am marking it has bug so that some eye can catch it. Feel free to change it 'Feature request'

Migration path to entity reference field from 7.x

$
0
0

Problem/Motivation

Since Entity reference is now in core, we need to support migration for those using this in D7. There are generally two almost identical field types used, node reference which was very popular early in the D7 lifespan, and entityreference which is basically what we have in core today.

Remaining Tasks

Write migrations, with tests, covering the following as needed:

  • Field base for entity reference and node reference
  • Field instance for entity reference and node reference
  • Field data for entity reference and node reference

Views Rest Export Filter By

Views Argument Tokens fail validation in More Link

$
0
0

I've come across the Exception below. It seems this happens when Views is trying to figure out %1 !1, %2, or !2. This this case... I have 2 contextual filters. This only happens if I set the "More Link" to the following settings:

More Link: Yes
[X] Create More Link
[X] Always display more link
Link Display: Custom
[ ] None
[X] Custom URL
Custom URL: "/somepage"

All the tokens sent to view in this case are the following:

'{{ arguments.null }}' => string(2) "63"
'{{ raw_arguments.null }}' => string(2) "63"
'{{ arguments.field_degree_program_target_id }}' => string(4) "6605"
'{{ raw_arguments.field_degree_program_target_id }}' => string(4) "6605"
'%1' => ''
'!1' => string(2) "63"
'%2' => ''
'!2' => string(4) "6605"

The expected results would be to have the correct variable name for the replacement so that this validation will work.... or to change the validation where it's not a "hard Exception", but something that will fail softly.

AssertionError: Tokens need to be valid Twig variables. in Drupal\Component\Assertion\Handle::Drupal\Component\Assertion\{closure}() (line 367 of core/modules/views/src/Plugin/views/PluginBase.php).
assert('preg_match('/^[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*$/', $token) === 1', 'Tokens need to be valid Twig variables.') (Line: 367)
Drupal\views\Plugin\views\PluginBase->viewsTokenReplace('/faculty', Array) (Line: 2080)
Drupal\views\Plugin\views\display\DisplayPluginBase->renderMoreLink() (Line: 2164)
Drupal\views\Plugin\views\display\DisplayPluginBase->elementPreRender(Array)
call_user_func(Array, Array) (Line: 381)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 448)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array) (Line: 468)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 84)
__TwigTemplate_b30d5878476cc595a2585c141ab5c83b010a9e8831025f3b5bfa0e1e9e2289df->block_content(Array, Array) (Line: 167)
Twig_Template->displayBlock('content', Array, Array) (Line: 73)
__TwigTemplate_b30d5878476cc595a2585c141ab5c83b010a9e8831025f3b5bfa0e1e9e2289df->doDisplay(Array, Array) (Line: 387)
Twig_Template->displayWithErrorHandling(Array, Array) (Line: 355)
Twig_Template->display(Array) (Line: 366)
Twig_Template->render(Array) (Line: 64)
twig_render_template('themes/custom/customtheme/templates/blocks/block.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('block', Array) (Line: 435)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 448)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array) (Line: 468)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 107)
__TwigTemplate_740a486138a3a9fc024c114124f062223ca63d89b3006208489a492523efb875->doDisplay(Array, Array) (Line: 387)
Twig_Template->displayWithErrorHandling(Array, Array) (Line: 355)
Twig_Template->display(Array) (Line: 366)
Twig_Template->render(Array) (Line: 64)
twig_render_template('themes/custom/customtheme/templates/page.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('page', Array) (Line: 435)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array) (Line: 468)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 92)
__TwigTemplate_c9343766bf6adc2d3ee69a1ad1d87d0f76608c2a7ce17bb3255275241b160944->doDisplay(Array, Array) (Line: 387)
Twig_Template->displayWithErrorHandling(Array, Array) (Line: 355)
Twig_Template->display(Array) (Line: 366)
Twig_Template->render(Array) (Line: 64)
twig_render_template('themes/custom/customtheme/templates/html.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('html', Array) (Line: 435)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array) (Line: 147)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 574)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 148)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object) (Line: 149)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 64)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 98)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 77)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 628)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Label is not using Unicode::truncate()

$
0
0
/**
   * {@inheritdoc}
   */
  public function buildForm(array $form, FormStateInterface $form_state) {
    $actions = array();
    foreach ($this->manager->getDefinitions() as $id => $definition) {
      if (is_subclass_of($definition['class'], '\Drupal\Core\Plugin\PluginFormInterface')) {
        $key = Crypt::hashBase64($id);
        $actions[$key] = $definition['label'] . '...';
      }
    }

This may better use Unicode::truncate():

$actions[$key] = $definition['label'] . '...';
Viewing all 296802 articles
Browse latest View live


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