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

Remove for PostgreSQL database driver the workaround for the Upsert class

$
0
0

Problem/Motivation

The minimum required version of PostgreSQL is 10. In the Connection class of the PostgreSQL driver we have the following code:

  public function upsert($table, array $options = []) {
    // Use the (faster) native Upsert implementation for PostgreSQL >= 9.5.
    if (version_compare($this->version(), '9.5', '>=')) {
      $class = $this->getDriverClass('NativeUpsert');
    }
    else {
      $class = $this->getDriverClass('Upsert');
    }

    return new $class($this, $table, $options);
  }

The method is no longer necessary.

Proposed resolution

1. Remove the method Drupal\Core\Database\Driver\pgsql\Connection::upsert().
2. Then remove the class Drupal\Core\Database\Driver\pgsql\Upsert.
3. After that rename the class Drupal\Core\Database\Driver\pgsql\NativeUpsert to Drupal\Core\Database\Driver\pgsql\Upsert.
4. In the renamed class, change the class name from "NativeUpsert" to "Upsert" and remove the link to http://www.postgresql.org/docs/9.5/static/sql-insert.html#SQL-ON-CONFLICT.
5. The file "core/modules/system/tests/modules/driver_test/src/Driver/Database/DrivertestPgsql/NativeUpsert.php" can also be removed.

Remaining tasks

TBD

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

TBD


Replace usages of AssertLegacyTrait::assert(No)FieldByName, that is deprecated

$
0
0

Problem/Motivation

AssertLegacyTrait::assertFieldByName() is deprecated in drupal:8.2.0 and is removed from drupal:10.0.0. Use $this->assertSession()->fieldExists() or $this->assertSession()->buttonExists() or $this->assertSession()->fieldValueEquals() instead. See https://www.drupal.org/node/3129738

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Entity reference fields can easily become stale (b/c of DataReferenceBase)

$
0
0

Entity reference fields internally use \Drupal\Core\Entity\Plugin\DataType\EntityReference, which extends \Drupal\Core\TypedData\DataReferenceBase. However, neither DataReferenceBase nor EntityReference have a way to clear its $target property. This leads to entity reference fields becoming stale as soon as the target entity changes.

See the following scenario:

$node_storage = $entity_type_manager->getStorage('node');
$node_type_storage = $entity_type_manager->getStorage('node_type');

$node = $node_storage->load(1);
echo $node->type->entity->label(); // Hello world!

$node_type = $node_type_storage->load('hello_world');
$node_type->name = 'Hello moon!";
$node_type_storage->save($node_type);

// Reference's "target" property is stale.
echo $node->type->entity->label(); // Hello world!

// Storage thinks node is unchanged so returns node with stale reference.
$node = $node_storage->load(1);
echo $node->type->entity->label(); // Hello world!

// Storage returns new copy of the node, so the reference target is unset and needs to be loaded.
$node = $node_storage->loadUnchanged(1);
echo $node->type->entity->label(); // Hello moon!

I was wondering if we should replace the property with a static cache that uses the target entity's cache tags.

Fatal errors while loading/building orphaned comments

$
0
0

(Technically, this is not comment.module. I guess.)

Problem/Motivation

Suppose a comment is orphaned - e.g. its parent comment has somehow disappeared. Then the Drupal standard installation gives a "Fatal error: Call to a member function url() on null in /Volumes/SSD2/www/8/core/modules/rdf/rdf.module on line ..." when that comment gets loaded. Once that would be fixed, like in #16 below, more fatal errors appear when rendering a node page with an orphaned comment on it gets built(/rendered?).

Same thing happens when its associated 'commented entity' has somehow disappeared, during loading and especially building a standalone comment with orphaned entity. (Though admittedly 'building/rendering a comment without its commented entity' is usually never done.)

See the 'test-only' patch in #16 for the 'loading' part.

Steps to reproduce

See step 2 in the Problem/Motivation section of the IS in #2906470: Orphan comments and entries in comment_entity_statistics after comment field instance has been deleted

(So how do comments get orphaned? I don't know. But it's pretty much guaranteeed that someone, somehow, somewhere, will have orphaned comments. See #16.)

Proposed resolution

1)
Fix fatals.

2) (optional for the loading part; not considered until an experienced person says something about this)
At first sight it looks to me like invokeStorageLoadHook() will need some try...catch statements. Because it's pretty much guaranteed that contrib modules will make the same mistake as rdf.module did, and people will end up with node pages that crash while rendering.

However, since no hooks seem to wrap their calls, maybe there's a conscious decision not to do that?

Remaining tasks

* discuss need
* review

User interface changes

None.

API changes

None... but comments in CommentInterface clarify when to call the 'has referenced entity' and 'referenced entity' methods in more detail.

Data model changes

None.

"Printer-friendly version" of unpublished book pages is blank

$
0
0

Steps to reproduce

(description of the proposed solution, the rationale behind it, and workarounds for people who cannot use the patch)

  1. Enable book module
  2. Create an unpublished book page
  3. Click the "Printer-friendly version" link
  4. Expected result: See print-friendly version
  5. Actual result: Empty white page

This issue exists in core Book module Drupal 7 & Drupal 8
No need for contributed module. The printer-friendly feature exists in core book module.

Remaining tasks

Patch at: http://drupal.org/node/50680#comment-4715114 not correct, need to write tests and fix the same.

Original report by [he_who_shall_no...]

This patch is for users who don't want to see an empty page when they click on the "printer-friendly version" link (unpublished/not in moderation queue book pages).

Translations of nodes with comment settings field set to non-translatable returns EntityUntranslatableFieldsConstraint

$
0
0

Problem/Motivation

It is impossible to add a new translation in case the user wants to keep the same settings for comments across all translations of the node.

Steps to reproduce

  1. Install standard
  2. Install content translation
  3. Add language (in my case Polish)
  4. Go to content translation settings and make Article translatable. Only check Title and Body field, unselect the rest, especially the Comments field. Also select "Hide non translatable fields on translation forms"
  5. Create a node in default language (English)
  6. Go to the Translate tab and add Polish translation.
  7. Fill the form and submit.
  8. "Non-translatable fields can only be changed when updating the original language."

Proposed resolution

CommentFieldItemList needs to implement it's own hasAffectingChanges that only check if status property has changed. If not it will check all properties, included the computed once like:

  • status
  • cid
  • last_comment_timestamp
  • last_comment_name
  • last_comment_uid
  • comment_count

And these properties will all be set to 0 until the new entity revision has been saved.

hasAffectingChanges in FieldItemList simply check !$this->equals($original_items);
https://git.drupalcode.org/project/drupal/-/blob/8.8.x/core/lib/Drupal/C...

However in the hasAffectingChanges doc it is written:

/**
* Determines whether the field has relevant changes.
*
* This is for example used to determine if a revision of an entity has
* changes in a given translation. Unlike
* \Drupal\Core\Field\FieldItemListInterface::equals(), this can report
* that for example an untranslatable field, despite being changed and
* therefore technically affecting all translations, is only internal metadata
* or only affects a single translation.

AccountForm should read pass-reset-token only from query string

Vertical tabs summary is displayed only for browsers without HTML5 details support (below the defined width breakpoint)

$
0
0

Vertical tabs summary is displayed only for browsers without HTML5 details support (below the defined width breakpoint)

Problem/Motivation

The summary of Vertical tabs items is not displayed below the defined width breakpoint except on browsers without HTML5 details support. This is because it is handled by the HTML5 details polyfill (provided by core/misc/collapse.es6.js).

Vertical tabs summary below 640 pixels with in Google Chrome and Microsoft Edge

To reproduce:

  • Install Drupal with Standard profile.
  • Visit /admin/structure/block/manage/bartik_breadcrumbs with a browser that supports HTML5 details with less than 640 pixels browser canvas width.
  • Visit /admin/structure/block/manage/bartik_breadcrumbs with a browser without HTML5 details support with less than 640 pixels browser canvas width.
  • Compare the result.

Proposed resolution

Display the summary of HTML5 details elements on every browser.

Remaining tasks

User interface changes

Summary will be shown for every browser.

API changes

Data model changes

Release notes snippet


Accessibility bugs with vertical tabs

$
0
0

Problem/Motivation

Vertical tabs have the following accessibility issues:

  1. Drupal.verticalTab doesn't take care of the right aria attributes. Whatever happens, every details summary element (of a single VerticalTabs) are described with aria-expanded="false" and aria-pressed="false".
  2. Drupal.verticalTab marks active vertical tab menu items with an element that text is active tab. The element has a non-unique CSS id #active-vertical-tab. Sadly, this will be very wrong on the filter format and editor configuration form where multiple vertical tabs may appear (e.g. /admin/config/content/formats/manage/basic_html).

    Fearing the duplicated id, if the user changes the active tab, this marker will be removed from every other vertical tab's of the page as well

  3. Auto-focus bug: When a vertical tab is activated (triggered to be shown) by pressing Enter on the tab menu link Drupal.verticalTab tries to focus the first visible :input element in a vertical tab content. But the implementation is wrong: on the Filter format and editor form (/admin/config/content/formats/manage/basic_html), if the user presses the Enter key on the last vertical tabs element's menu link (Filter settings), the focused element will be the first vertical tabs (CKEditor plugin settings) visible input, and not the expected one. This is because the focus trigger happens globally; it isn't limited to the current vertical tabs.
  4. The label of a vertical tabs element has invalid for attribute value.

    From #3023310-85: Vertical Tabs style update.2:

    (...) the for attribute is looking for an ID that is not present on the page. The value it is looking for does appear in a div's data-drupal-selector attribute, an element that can't receive focus.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

@todo

Derive path alias migrations per entity type (and bundle)

$
0
0

Problem/Motivation

@todo

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Expand LinkWidget test coverage

$
0
0

Problem/Motivation

While triaging #2703713: core link field and token, @larowlan, @xjm, @pameeela and I agreed that we are missing some test coverage for the link field.

For example cases like:

http://www.example.com/?name=ferret&color=purple
http://www.example.com/page?name=ferret&color=purple
http://www.example.com?a=&b[]=c&d[]=e&d[]=f&h==

and

/page?name=ferret&color=purple
/page?a=&b[]=c&d[]=e&d[]=f&h==

Proposed resolution

Update the test coverage in \Drupal\Tests\link\Functional\LinkFieldTest::testURLValidation() add missing cases mapping to $valid_external_entries or $valid_internal_entries

Remaining tasks

Create a patch.

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

N/A

Removing getFormObject call from UserAccountFormFieldsTest

$
0
0

Problem/Motivation

protected function buildAccountForm($operation) {
    // @see HtmlEntityFormController::getFormObject()
    $entity_type = 'user';
    $fields = [];
    if ($operation != 'register') {
      $fields['uid'] = 2;
    }
    $entity = $this->container->get('entity_type.manager')
      ->getStorage($entity_type)
      ->create($fields);
    $this->container->get('entity_type.manager')
      ->getFormObject($entity_type, $operation)
      ->setEntity($entity);

    // @see EntityFormBuilder::getForm()
    return $this->container->get('entity.form_builder')->getForm($entity, $operation);
  }

Proposed resolution

code is repeated in \Drupal\Core\Entity\EntityFormBuilder::getForm() so the getFormObject call is not needed.

 protected function buildAccountForm($operation) {
    // @see HtmlEntityFormController::getFormObject()
    $entity_type = 'user';
    $fields = [];
    if ($operation != 'register') {
      $fields['uid'] = 2;
    }
    $entity = $this->container->get('entity_type.manager')
      ->getStorage($entity_type)
      ->create($fields);

    // @see EntityFormBuilder::getForm()
    return $this->container->get('entity.form_builder')->getForm($entity, $operation);
  }

Remaining tasks

  1. Write a patch
  2. Review
  3. Commit

User interface changes

None.

API changes

None.

Data model changes

None.

Allow contributed modules (mostly database drivers) to override tests in core

$
0
0

Problem/Motivation

Lastly discussed from #3098426-10: EntityQueryTest::testToString fails with non-core db drivers onwards, but really popped up several times already,

+    if (!in_array(Database::getConnection()->driver(), ['mysql', 'sqlite', 'pgsql'])) {
+      $this->markTestSkipped("This test only runs for Drupal core database drivers");
+    }

feels fragile.

We should have a more structured way to include/exclude tests that are database specific in the test runs.

Proposed resolution

Add a new annotation for test classes called @overridesTestClass. The annotation must be used with a fully-qualified class name of the test class that is to be overrridden. When used will the overridden test class not be run. It is best to use this annotation in combination with extending the overridden class by current test class. The current test class can then override anything it needs to. The current test class will then be run instead of the overridden test class.

Remaining tasks

TBD

User interface changes

None

API changes

New annotation @overridesTestClass will be ccreated for test classes.

Data model changes

None

Fix grammar 'a' to 'an' when necessary

$
0
0

Problem/Motivation

I see a lot of 'a' uses in comments instead of 'an'.

Ex:

  • a entity
  • a alt
  • a author
  • a image
  • ...

Proposed resolution

Many modules and core files are concerned. I suggest to make all changes here instead of one issue per module since it's only minor documentation issue.

Additional context

Keep in mind:

The choice of a vs. an is actually based on the phonetics of the start of a word, not the orthographic representation.

Notes

Note: .js and .css files should be generated from .es6 and .pcss.css files by run

$ cd core
$ npm run build:js
$ npm run build:css

Not touch them directly

Replace use of whitelist/blacklist in \Drupal\Core\Template classes and their tests

$
0
0

Problem/Motivation

Lets remove usage of "blacklist" and "whitelist" in \Drupal\Core\Template classes and their tests.

They are:

  • An historic bad labelling of people
  • Provide no context: "what is listed in them"?

Proposed resolution

TBD

Remaining tasks

  1. Decide if we need BC.
  2. Decide if we need to touch core/lib/Drupal/Core/Template/Attribute.php too. Only 'black-cat' and 'white-cat' and friends. Seems we could leave those.
  3. Fix everything:
    • core/lib/Drupal/Core/Template/Loader/StringLoader.php - Comment only. See #3
    • core/lib/Drupal/Core/Template/TwigSandboxPolicy.php - Full of "whitelist":
        protected $whitelisted_methods;
        protected $whitelisted_prefixes;
        protected $whitelisted_classes;
      
  4. Reviews.
  5. RTBC.

User interface changes

None

API changes

None, only renaming some protected members.

Data model changes

@todo

Release notes snippet

@todo


Review updated Securing file permissions and ownership

$
0
0

Problem/Motivation

The page Securing files, and setting permissions (ORIGINAL) needs to be migrated to the new documentation system, so I have created a starting point for an updated version.

Everything from the original "Securing file permissions and ownership" page (edited to match Drupal 8) except "Script based on guidelines given above" has been added.

The correct commands for the new Composer based structure are missing, so any added information about the correct approach would be greatly appreciated.

Here is the updated version in the new documentation system, which needs review: Securing file permissions and ownership (UPDATED).

Proposed resolution

Review the new documentation Securing file permissions and ownership page.

Remaining tasks

Review the new documentation page and publish when revised and approved.

Duplicated joins in entity query

$
0
0

Entity query with condition and sorting by a field from the same table makes duplicated joins.

My investigating:
Class 'Drupal\Core\Entity\Query\Sql\Query' method getTables() always returns new 'Drupal\Core\Entity\Query\Sql\Tables' object.
In this case, the Tables object doesn't have actual state of 'entityTables' property, and adds duplicated joins.
Because ensureEntityTable() method needs correct 'entityTables' property, for building joins.
Method getTables() is called seperatly when sort is added and conditions are compiled (getTables() method can be called several times during conditions' compiling).

My propose:
I think, getTables() method should write Tables object into 'tables' property. And in next call it should return Tebles object from 'tables' property instead of creating new object.

Or I don't understand somethings, and don't see reason why getTables() returns new object.

Replace assert(Not)Equal() with assert(Not)Equals()

$
0
0

Problem/Motivation

assertEqual() and assertNotEqual() is deprecated for removal in Drupal 10.0.0 as well.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

EntityResource tests assume no trailing slash in base URL

$
0
0

the SIMPLETEST_BASE_URL variable in phpunit.xml can be specified as http://localhost:8000 or http://localhost:8000/, with no difference in functionality in most tests.

However, EntityResourceTestBase uses this value to "strip" the base URL off an absolute URL in order to get the host-relative URL. The result is that a base URL with a trailing slash causes failures like this:

1) Drupal\Tests\path_alias\Functional\Hal\PathAliasHalJsonAnonTest::testPost
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'{"message":"No route found for \u0022POST entity\/path_alias\u0022"}'
+'{"message":"No route found for \u0022POST \/entity\/path_alias\u0022"}'

If this difference does matter, then it would be good for either ERTB or even BrowserTestBase to either normalize the baseURL value by stripping a trailing forward slash, or explicitly require SIMPLETEST_BASE_URL to not have one.

PathAlias::preSave() trims the alias -- should it trim the path instead?

$
0
0

URL ending forward slash(‘/‘) breaks url alias(pretty url) paths.

Admin area where users are able to make menu edit changes to menu links e.g. /admin/structure/menu/manage/main seem to break core functionality when appending the forward slash to node references. The following steps will recreate the issue.

Steps to recreate:
1. Visit admin/config/search/path
2. Click on the ‘edit’ operation, assuming there are existing menu links created.
3. Append the path field value with the forward slash character ’/‘. e.g. /node/1 will become /node/1/
4. Save the changes.
5. Visit any page that contains the main menu and you’ll notice the url alias no longer working. The link will now reference the node path with the ‘/‘ prepended.

Viewing all 292900 articles
Browse latest View live