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

Concurrent editing of layouts is very confusing

$
0
0

Problem/Motivation

If two users attempt to edit the same layout, they will both see the changes the other is making.

Proposed resolution

Mimic the Views UI (which also uses tempstore.shared) and lock the Layout Builder UI when another user is editing the layout.

Remaining tasks

N/A

User interface changes

The LB UI will now show a message when there is a lock of another user. Breaking the lock will bring you back to the LB UI to make your own changes.

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A


Fix documentation on field_ui.api.php

$
0
0

Problem/Motivation

The documentation in field_ui.api.php is out of date.

Proposed resolution

Point the documentation to the right places and ensure that the parameter types are correct.

Edit content throws "The website encountered an unexpected error. Please try again later."

$
0
0

The website encountered an unexpected error. Please try again later.
Recoverable fatal error: Argument 1 passed to Drupal\Core\Field\WidgetBase::massageFormValues() must be of the type array, string given, called in core/lib/Drupal/Core/Field/WidgetBase.php on line 376 and defined in Drupal\Core\Field\WidgetBase->massageFormValues() (line 513 of core/lib/Drupal/Core/Field/WidgetBase.php).
Drupal\Core\Field\WidgetBase->massageFormValues('', Array, Object)
Drupal\Core\Field\WidgetBase->extractFormValues(Object, Array, Object)
Drupal\Core\Entity\Entity\EntityFormDisplay->extractFormValues(Object, Array, Object)
Drupal\Core\Entity\ContentEntityForm->copyFormValuesToEntity(Object, Array, Object)
Drupal\Core\Entity\EntityForm->buildEntity(Array, Object)
Drupal\Core\Entity\ContentEntityForm->buildEntity(Array, Object)
Drupal\Core\Entity\ContentEntityForm->validateForm(Array, Object)
call_user_func_array(Array, Array)
Drupal\Core\Form\FormValidator->executeValidateHandlers(Array, Object)
Drupal\Core\Form\FormValidator->doValidateForm(Array, Object, 'node_edit_form')
Drupal\Core\Form\FormValidator->validateForm('node_edit_form', Array, Object)
Drupal\Core\Form\FormBuilder->processForm('node_edit_form', Array, Object)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
call_user_func_array(Object, Array)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1)
Stack\StackedHttpKernel->handle(Object, 1, 1)
Drupal\Core\DrupalKernel->handle(Object)

For sites that have made layout overrides prior to 8.7.0 or sites that manually enable translation of the layout override field, add UI warnings

$
0
0

Problem/Motivation

Layout Builder does not support translated layout overrides currently. Any new sites installing Layout Builder will not be able to enable translation on Layout field through Content Translation.

But some sites that had both content translations and Layout Builder enabled before #3041659: Remove the layout tab from translations because Layout Builder does not support translations yetand had both translations and layout overrides on the same bundles maybe have Translations still enabled on the Layout field.

It could be not safe for them to just turn off translations because they may need the current values they have in the translated fields.

Proposed resolution

On Content Translation admin form add a warning to all Layout fields with a link to the handbook page https://www.drupal.org/docs/8/core/modules/layout-builder/layout-builder...

Only sites that were installed when Layout Builder was still beta will see this warning.

Remaining tasks

None

User interface changes

@see Proposed resolution

API changes

None

Data model changes

None

Release notes snippet

Convert ArgumentDefaultTest into a kernel test

$
0
0

Problem/Motivation

ArgumentDefaultTest makes no HTTP requests but is a functional test

Proposed resolution

Convert ArgumentDefaultTest into a Kernel test

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

N/A

hook_query_TAG_alter() param needs to be imported

Use the generateLogEntries method in DBLogTest

$
0
0

Problem/Motivation

There is a method generateLogEntries() to generate a number of random database log events.

For better readability, we can replace long pieces of code with this method.

It would be enough to use:

$this->generateLogEntries(1);

instead of this piece of code:

$log = [
  'channel'     => 'system',
  'message'     => 'Log entry added to test the doClearTest clear down.',
  'variables'   => [],
  'severity'    => RfcLogLevel::NOTICE,
  'link'        => NULL,
  'uid'         => $this->adminUser->id(),
  'request_uri' => $base_root . \Drupal::request()->getRequestUri(),
  'referer'     => \Drupal::request()->server->get('HTTP_REFERER'),
  'ip'          => '127.0.0.1',
  'timestamp'   => REQUEST_TIME,
];
// Add a watchdog entry.
$this->container->get('logger.dblog')->log($log['severity'], $log['message'], $log);

Proposed resolution

Replace long pieces of code with generateLogEntries() method in all tests.

Remaining tasks

None

Convert LatestTranslationAffectedRevisionTest into a kernel test

$
0
0

Problem/Motivation

LatestTranslationAffectedRevisionTest makes no HTTP requests but is a functional test

Proposed resolution

Convert LatestTranslationAffectedRevisionTest into a Kernel test

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

N/A


Add an entity iterator to load entities in chunks

$
0
0

Problem/Motivation

If you need to load a lot of entities and iterate over them (pretty common), your memory usage could easily go through the roof.

For example, consider updating all nodes for some reason is a post_update hook. You want to load them all and save them, but loading all 10000000000 nodes will kill your machine. You would need to load them in batches to keep memory usage at a sane level.

This could also affect core directly, as we may need to update content (or config) entities in the upgrade path, but have no way of knowing how many items a site will have. This could cause problems and easily balloon over the PHP requirements we set to run Drupal.

Proposed resolution

Introduce an EntityIterator class that uses a generator to break the IDs to load into chunks. Then load just a set amount each time, clearing the static cache before each load so it only contains the items currently being iterated over.

We can get clever and use a generator. This internally creates an iterator so we can implement \IteratorAggregate and just return our generator!!

Remaining tasks

Add some tests

User interface changes

N/A - Developer only

API changes

Addition of new Iterator

Data model changes

N/A

Unable to open manage form display when using multiple field groups

$
0
0

It is not clear how to reproduce, but now I get the following error when trying to manage form field on a profile entity:

Notice: Undefined index: name in Drupal\field_ui\Element\FieldUiTable::reduceOrder() (line 228 of ...\core\modules\field_ui\src\Element\FieldUiTable.php)

Convert functional EfqTest to kernel test

$
0
0

Problem/Motivation

Drupal\Tests\taxonomy\Functional\EfqTest doesn't make any HTTP request.

Proposed resolution

  • Convert it to a kernel test.
  • Move TaxonomyTestTrait from tests/src/Functional to tests/src/Traits as is used by all kind of tests.
  • Rename it to a more meaningful name.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

N/A

Shortcut action link only supports Seven theme

$
0
0

Problem/Motivation

There's Seven specific code in the Shortcut module which makes it hard for other themes to render the shortcut action link. Shortcut module sets a theme setting third_party_settings.shortcut.module_link on module / theme installation to Seven theme. Since hook_modules_installed isn't triggered in themes, the only way to make this work is to always add the configuration in the theme, ignoring the fact that shortcut module might not be enabled.

Proposed resolution

-

Remaining tasks

Find an alternative approach that allows properly rendering action links in other themes than Seven.

User interface changes

API changes

Data model changes

Release notes snippet

Remove @todo in ViewListBuilder

$
0
0
    // @todo Use a placeholder for the entity label if this is abstracted to
    // other entity types.

Regardless if it is or is not abstracted, using a placeholder means we don't have to hardwire in a constant, which means the code is more maintainable. So I think this should be done and the @todo removed.

Add ::fieldNotDisabled() method to Drupal\Tests\WebAssert

$
0
0

Currently Drupal\Tests\WebAssert contains the method ::fieldDisabled() but there isn't no method to check if a field is NOT disabled. Could be very useful to add the ::fieldNotDisabled() method to WebAssert class

Improve test coverage around updating table mapping after a new field storage definition is added

$
0
0

Problem/Motivation

Discovered by @kevin.dutra in #2644088-20: DefaultTableMapping::getFieldTableName does not report table for fields with dedicated storage:

SqlContentEntityStorage contains a $tableMapping property which is populated on the first call to getTableMapping(). Subsequent calls use this locally cached version rather than recreating it. However, nothing forces this to be rebuilt after a field storage definition is inserted, so the table mapping has stale data for the remainder of the request.

Proposed resolution

Figure out a way to clear the SqlContentEntityStorage::$tableMapping static property when a new field storage definition is added.

Remaining tasks

Write a patch.

User interface changes

Nope.

API changes

I hope none.

Data model changes

Nope.


Improve test coverage for node authored on widget

$
0
0

Problem/Motivation

Add test coverage for creation date. Make sure that there are no errors when the user create a node with a different "Authored on" than the default or the date or time is invalid.

Proposed resolution

Add test to /core/modules/node/tests/src/Functional/NodeCreationTest.php

Remaining tasks

None

[PP-1] Support PHPUnit 7 in Drupal 8

$
0
0

I know that the testing infrastructure just switched to phpunit 6.5 two month ago but in the meantime PHPUnit 7 was released.

so the deadline to switch, and some important dates

so the deadline is like ~8 months from now based on PHP 7.3 release.

can PHPUnit 7 be used from now?

so it seems 2018 Nov-Dec is the date to switch..

.. or start using 3 different versions of phpunit now:

PHP 5.5; 5.6      > PHPUnit 4 (4.8)
PHP 7.0           > PHPUnit 6 (6.5)
PHP 7.1; 7.2; 7.3 > PHPUnit 7

Replace "Recipe Instruction" label with a better alternative

$
0
0

Problem/Motivation

Umami demo recipes have a section (field label) Recipe Instruction which sounds confusing.

Proposed resolution

Change to a label used by other leading recipe websites: Directions or one of the options below:

List of most popular recipe websites and the wording they use for that section:

https://www.yummly.com - Directions
https://www.geniuskitchen.com - Directions
https://www.foodnetwork.com - Directions

https://www.chowhound.com - Instructions
https://www.thekitchn.com - Instructions

https://www.myrecipes.com - How to Make it
https://www.cookinglight.com - How to Make It

http://www.eatingwell.com - Preparation
https://www.epicurious.com - Preparation

https://www.simplyrecipes.com - Method

https://www.bettycrocker.com - Steps

Remaining tasks

Create a patch to update Umami's recipe with the new label.

Private file download returns access denied, when file attached to node revision other than current

$
0
0

This is the follow-up issue of Private file download returns access denied, as was suggested by @Berdir here.

Once upon a time a patch was committed to D7 core to make private files accessible, when there are nodes with revisions on your site (see "Private file download returns access denied" issue mentioned above). To achieve this, they changed some code at modules/file/file.module, namely file_get_file_references function parameter to FIELD_LOAD_CURRENT from FIELD_LOAD_REVISION.

But FIELD_LOAD_REVISION parameter was there for a good reason, with FIELD_LOAD_CURRENT we are not able to open files attached to all entity revisions except current. It's fatal in case you're trying to build, say, intranet with library for documents.

Steps to reproduce:
1.Set up clean Drupal 7.12 with private document folder (say, sites/default/files/private) and a content type with just a title and file field called field_file. It should store files in your private folder.
2.Login as UID1, create a node and add a file "testfile1.txt" to it's file field.
3.Save the node
4.Click edit
5.Remove the old file, "testfile1.txt"
6.Add "testfile2.txt"
7.Check "Create new revision" option
8.Click save
9. Click revisions tab, open first revision of your node
10. Node is fine, link to file is there, but when you'll click on this link to the file "testfile1.txt", you'll get "Page not Found"

It is possible to open old version of your file - if you'll revert old revision. But it is not an option in case you use revisions as revisions, not as backups for inaccurate users, because it will produce awful mess of revisions.

In short:

So if a user has access to a revision he should also be able to access its files. If not, not.

Allow appending values to multivalued fields during the migration

$
0
0

For the moment during the entity import, we can compute the values for fields and save those as a result. In a case the "process" stage of an import returned "NULL" the value will be emptied. The other case - new value or set of values that will be saved for an entity, overriding the previous ones.

Imagine we have the "field_tags" for an entity and we doing an import into it. The type of field is "entity_reference" and it's multivalued. Initially, the source contains two tags: "a" and "b". The second import comes from the source that has "c" and "d" tags. What will be the result of two migrations? It'll be "c" and "d" unless process plugins haven't implemented some specific handling.

This issue is about allowing to merge the values among the incremental imports for specifically configured fields.

Viewing all 292476 articles
Browse latest View live


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