Quantcast
Viewing all 295320 articles
Browse latest View live

Config schema of argument_default plugins is incorrect

Found in #2502151: Convert shortcut block to view

Problem/Motivation

A bunch of argument_default plugins have an incorrect schema.

views.argument_default.current_user:
  type: boolean
  label: 'User ID from logged in user'

should be

views.argument_default.current_user:
  type: mapping
  label: 'User ID from logged in user'

views.argument_default.query_parameter is missing schema entirely.

views.argument_default.node:
  type: sequence
  label: 'Content ID from URL'
  sequence:
    type: string
    label: 'Nid'

should be

views.argument_default.node:
  type: mapping
  label: 'Content ID from URL'

Proposed resolution

Fix the schema!

Remaining tasks

Contributor tasks needed
TaskNovice task?Contributor instructionsComplete?
Create a patchInstructions
Review patch to ensure that it fixes the issue, stays within scope, is properly documented, and follows coding standardsInstructions

User interface changes

-

API changes

-

Data model changes

-


Use queue API for node and comment, user, node multiple deletes

Problem/Motivation

When deleting large datasets the delete multiple API does not invoke all dependent hook_[node|comment|user]_delete.
e.g. deleting a node does not invoke hook_comment_delete()

Proposed resolution

Use the queue API to delete large datasets so we can invoke all hooks.

Remaining tasks

This issue is looking for further direction. Some of the questions/issues are:

  • Does this issue cause problems/confusion for users that are expecting all records to be deleted?
  • Should the user be aware that the operation is happening via queues/cron?
  • If the deletes are happening through the UI, the batch API could process everything. Could the UI create a queue and parse to the batch API to process so you don't have to wait for cron to complete?

User interface changes

When deleting large datasets, you are advised that only a subset of the objects have been deleted and the remaining will been queued to be deleted on cron. A link is shown to run the cron manually if user has permission to "administer site configuration"

API changes

[node|comment|user]_delete_multiple no longer will always delete all items instantly, instead it deletes the the first 20 (or the defined queue threshold number) with the remaining items deleted on cron through a queue.

If the number of items being deleted is less than the queue threshold number, then the current behavior of the system will remain unchanged.

Original report by fajerstarter

Deleting a node that has comments deletes its comments. The problem is that this doesn't initiate hook_comment($op='delete'). Modules using hook_comment need this. This might be the case for Drupal-cvs as well though this hasn't yet been tested.

Deleting a node with revisions does not release file usage

If revisions are enabled and a media item is changed on later revisions, it's no longer possible to delete the original media item from the library, despite removing all revisions or the node in it's entirety.

The media item is added to the node using an image field.

Steps to reproduce:
Create a node and add media
Create a new revision and change the media
Delete the node
The original media item will remain in the library and cannot be deleted

Harmonize PHPUnit and run-tests to both scan for themes.

Problem/Motivation

Core registers and auto-loads classes in themes. As it is today, themes do not have their classes registered by PHPUnit, as such, you cannot unit test your theme and any unit tests you write will fail on d.o.

Proposed resolution

We should discuss whether or not we want to do that (themes with unit tests! crazy! on the other hand, maybe theme maintainers want that!). Then do it. Patch could be as few as two lines (See #65 of #2025883: Drupal's PHPUnit bootstrap.php does not register module namespaces out of /core)

Remaining tasks

User interface changes

None.

API changes

None.

Require specific versions of dependencies in composer.json

We have a lot of great libraries in Drupal 8 now, which is awesome. It's somewhat confusing why were aren't being explicit about the precise version we're using.

While we're developing and getting Drupal 8 ready, it kind of makes sense why we're using wild cards for the version numbers of the libraries we're using. That makes it easier for us to update our libraries and push out a fresh patch updating everything (which is great, as long as that doesn't break anything).

But once Drupal 8 enters into beta stage we need to be mindful of what versions we want to ship. Should we promote a development methodology where we allow Drupal developers to update their libraries without concern (for example at the start of a new project).

Or should we ship Drupal with specific version (specific now to the patch version: MAJOR.MINOR.PATCH)? And thus promoting a methodology of keeping the vendor libraries we ship alone (unless you really know what you're doing).

For the most part I just want to resolve a pet peeve of mine where I can run "composer update" in the root of a Drupal 8 site and get a ton of updated files.

That's what I think should be our policy here: Executing "composer update" in the root of a Drupal 8 site shouldn't update anything because the version we list in composer.json are completely explicit so that there is no misunderstanding about what versions we're using.

Upgrade path for Config translation synchronization failure

Migration path to entity reference field from 7.x

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

Convert all color web tests to BrowserTestBase


Add test coverage for Views revision link handlers

Drupal\Tests\Core\PageCache\CommandLineOrUnsafeMethodTest::testHttpMethod Failed asserting that null is identical to 'deny'.

Problem/Motivation

After updating all of the dependencies, I now get this error:

There were 2 failures:

1) Drupal\Tests\Core\PageCache\CommandLineOrUnsafeMethodTest::testHttpMethod with data set #5 ('deny', 'OPTIONS')

Failed asserting that null is identical to 'deny'.

/home/travis/build/phototech/sailvenice/web/core/tests/Drupal/Tests/Core/PageCache/CommandLineOrUnsafeMethodTest.php:41

2) Drupal\Tests\Core\PageCache\CommandLineOrUnsafeMethodTest::testHttpMethod with data set #6 ('deny', 'TRACE')

Failed asserting that null is identical to 'deny'.

/home/travis/build/phototech/sailvenice/web/core/tests/Drupal/Tests/Core/PageCache/CommandLineOrUnsafeMethodTest.php:41

https://travis-ci.org/phototech/sailvenice/builds/148723955#L793-L806

Here's the repo for the site:
https://github.com/phototech/sailvenice

Proposed resolution

Figure out why the builds are failing with update dependencies.

Remaining tasks

  1. Debug
  2. Write Patch

User interface changes

None.

API changes

None.

Data model changes

None.

Remove usages of deprecated entity_get_bundles()

Problem/Motivation

A follow-through task after #2030151: Convert entity_get_bundles to a method on the entity manager

Dependency-injected code should not rely on a global method in a module for services.

Let's remove the use of entity_get_bundles() in DI code.

Proposed resolution

Remaining tasks

User interface changes

API changes

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue categoryTask because it doesn't solve an existing problem, other than inelegance.
Unfrozen changesImproves DX, solidifies the API.
DisruptionNot disruptive.

Remove docs references to entity_get_bundles()

High random fail rate in BTB forum tests on Postgres (especially, but not only, with PHP7)

Problem/Motivation

For the past couple of weeks, there has been a very high fail rate in the Forum test group on PHP7/Postgres. It is not always the same tests within the namespace. The rate of failure is especially high with Postgres/PHP7 on 8.2.x (~75%), but it also appears to occur at a lower rate with Postgres/PHP5.5 and on 8.1.x.

Example:
https://www.drupal.org/pift-ci-job/396471

Forum.Drupal\Tests\forum\Functional\ForumUninstallTest
✗
testForumUninstallWithField
fail: [Other] Line 29 of core/modules/forum/tests/src/Functional/ForumUninstallTest.php:
Drupal\Tests\forum\Functional\ForumUninstallTest::testForumUninstallWithField
Behat\Mink\Exception\DriverException: There is no element matching XPath "//html"

/var/www/html/vendor/behat/mink-browserkit-driver/src/BrowserKitDriver.php:832
/var/www/html/vendor/behat/mink-browserkit-driver/src/BrowserKitDriver.php:347
/var/www/html/vendor/behat/mink/src/Element/Element.php:176
/var/www/html/vendor/behat/mink/src/WebAssert.php:257
/var/www/html/core/tests/Drupal/FunctionalTests/AssertLegacyTrait.php:67
/var/www/html/core/modules/forum/tests/src/Functional/ForumUninstallTest.php:122
✓		- testForumUninstallWithoutFieldStorage
✗
rupal\Tests\forum\Functional\ForumUninstallTe
fail: [Other] Line 0 of sites/default/files/simpletest/phpunit-863.xml:
PHPunit Test failed to complete
✗
nkno
fail: [run-tests.sh check] Line 0 of :
FATAL Drupal\Tests\forum\Functional\ForumUninstallTest: test runner returned a non-zero error code (2)

It appears to have started on July 19, the day #2737805: Convert web tests to browser tests for forum module was committed. This is the first result I saw on HEAD:
https://www.drupal.org/pift-ci-job/379115

The random fail does not seem to happen when one or more forum tests are run repeatedly on the Postgres/PHP7 environment, only when the whole test suite is run. This likely points to either a DrupalCI problem or a conflict with some other test not being torn down cleanly. See #10 for the ~75% fail rate in forum tests, on the following specific environments:

  • 8.2.x, PostgreSQL 9.1, PHP 7: 75% fail rate
  • 8.1.x, PostgreSQL 9.1, PHP 7: 75% fail rate
  • 8.2.x, MySQL 5.5, PHP 7: Not observed
  • 8.2.x, PostgreSQL 9.1, PHP 5.5: 25% fail rate

Proposed resolution

Figure out which commit introduced the fails, and if it is the above, revert until we can figure out why this is happening.

Remaining tasks

TBD

Make it possible to link to an entity by UUID

Problem/Motivation

It would be great to provide URLs with UUIDs in their so you can link to them.

For poormans menu staging you could use menu_link_config and store refs to UUIDs, like <code>/{entity_type}/{uuid}.

Proposed resolution

Add a new entity link format: {entity_type}/{uuid} - e.g. viewing /node/68d0a104-a5bf-466c-a429-f871d91f9580 is same as viewing node/3.
Allow URIs like entity:node/68d0a104-a5bf-466c-a429-f871d91f9580
Add a new uuid link template for entities:

$node->toUrl('uuid');

Remaining tasks

User interface changes

API changes

None

Comment permalinks are cached incorrectly when multiple pages exist

8.1.1: comment link uses first cached page of comments;
links to comments on other pages then refer to wrong page.

Repeatable: always
OS: Ubuntu 14.04.4 LTS‬
PHP: 5.5.9+dfsg-1ubuntu4.16
Msysl: 5.5.49-0ubuntu0.14.04.1

Prepare test:
- Install standard, english 8.1.1.
- As admin, create 1 article (node/1)
- Create 15 comments with title C1, .., C15 for the article
- In article content type, modify comments field to show 10 (not 50) comments per page
- For reproducing, use two tabs:
- - E) Effect: one for filling the cache and checking the effect of that
- - C) Cache: one for clearing cache (administration, configuration, performance, button clear cache)

How to reproduce, Actual Results:

Case 1:
- E) goto home page
- C) clear cache
- E) click article link
- E) navigate to page 2 of the comments using pager
- E) click permalink of a comment, say C13 (you created 15 comments)
*1E) /comment/13 is "displayed": the first page of comments (with C3) is displayed (C13 is on page 2)

Case 2 (variation)
- E) goto home page
- E) click article link
- E) navigate to page 2 of the comments
- C) clear cache
- E) refresh page (with page=1 in the url, the second page of comments)
- E) navigate back to page 0 of the comments using the pager
- E) click on any comment title, say C3
*2E) C3 is shown (as expected)

Case 3 (variation)
- E) goto home page
- C) clear cache
- E) display e.g. (yourdomain)/comment/13 (directly via browser address toolbar)
- E) C13 is displayed (as expected: first user is lucky!)
- E) go back to page 0 using pager
- E) Click on C3 (title)
*3E) page 1 of the comments is shown (C13 is visible, not C3)

Expected results (see inline in Actal results too)
*1E) show page 1 with C13
*2E) show page: this is ok. Accessing the page via pager seems to be different.
*3E) show page 0, with C3 visible

Note: you can also use permalinks instead: this is how I discovered it, see below.
--
Analysis: as an attempt of interpretation
(of a newbie: I just went live with my 8.1.1 from migrated Ning2 because of emergency):
a) referencing comments directly in the cache system seems to set the page
which is used for subsequent
b) referencing the page via pager does not seem to set the cache mentioned in a)

--
Motivation:
I discovered this via the migrated link directories I have in my migrated site:
users click, and they do not get to the collected content comment,
but to the content page of the comment the first user after cache clear clicked.
Since I have big threads and 1500 internal links, this matters for me.
--
This is my first issue: please have mercy if I made any mistakes for doing so ..
(I will publish my migration (like the one for D7) in GPL,
and I am grateful to drupal community, yet I know very little, at least not yet).


Alignment of comments in narrow screens

Problem/Motivation

When the comments are large, the comment boxes form long columns in narrow screens.
The space utilization and Alignment of comments in narrow screens needs review.

Admin URL: node/%

Proposed resolution

To be determined.

Remaining tasks

To be determined.
Image may be NSFW.
Clik here to view.

Can't scroll vertical toolbar tray to reveal last item, applies to both mobile and desktop breakpoints

I've seen this issue in Chrome, Firefox and Safari on Mac with version 8.1.5 installed. I didn't check Windows/IE.

Due to a padding-top of 39px, the vertical toolbar tray can't be scrolled to reveal the last item (which is "Help")

You can see this behavior from the attached gif. It's a bit hard to see from the gif, but if you look closely, there's a menu item "Help" at the bottom before the menu expands, then an attempt is made to scroll down to "Help" again, but the scrolling can't go beyond "Reports", meaning there's no way to access the "Help" item from the vertical sidebar when there's a scroll bar shown.

Image may be NSFW.
Clik here to view.

Opt-in CORS support

To allow Ajax requests from a different domain and take advantages of the new REST module more globally.

W3C Draft:http://www.w3.org/TR/cors/

What: http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
Why: http://annevankesteren.nl/2012/12/cors-101
Who: http://caniuse.com/cors
How: Via https://github.com/asm89/stack-cors library

This header needs to be set everywhere (or pretty much everywhere).

 Access-Control-Allow-Origin: *

Might be a REST module thing but putting on base system just in case.

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue priorityThis is highly important to headless setups (Angular, Ember, etc.) , which often run on a different domain than their backend. Without CORS they cannot actually talk to Drupal. Given that this seems major.
Issue categoryFeature request: REST applications can still be built as native apps or javascript apps on the same domain, so this is not a bug; rather, it is an expansion of functionality.
Prioritized changesNot a prioritized change for 8.0.x.
DisruptionThere is no impact on existing developers. No APIs change as a result of this issue; we only add some more (disabled by default) properties to default.settings.yml

Fix behat/mink downgrade

Problem/Motivation

Weirdly #1869548: Opt-in CORS support downgraded behat/mink for no reason.

Proposed resolution

Put it back to 17.1

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

_user_mail_notify() always sends emails even if $notify is FALSE

Problem

Setting notify to FALSE on any of the user.settings.notify.* values doesn't block _user_mail_notify() to send the email.
D7

// By default, we always notify except for canceled and blocked.
  $default_notify = ($op != 'status_canceled'&& $op != 'status_blocked');
  $notify = variable_get('user_mail_' . $op . '_notify', $default_notify);
  if ($notify) {...}

D8

// By default, we always notify except for canceled and blocked.
  $notify = \Drupal::config('user.settings')->get('notify.' . $op);
  if ($notify || ($op != 'status_canceled'&& $op != 'status_blocked')) {...}

On D7 ($op != 'status_canceled'&& $op != 'status_blocked') was meant to be a "default" value when the variable wasn't set but on D8 it's now evaluated as part of the condition so whatever the value of $notify is, as long as the second part is verified the email is sent.

Modules like user_registrationpassword used to use this feature in order to block default emails to be sent.

Proposed resolution

Restoring the previous behaviour:

// By default, we always notify except for canceled and blocked.
  $notify = \Drupal::config('user.settings')->get('notify.' . $op);
  if ($notify || (is_null($notify) && $op != 'status_canceled'&& $op != 'status_blocked')) {...}

How to reproduce

- Set "Visitors, but administrator approval is required" on "Administration > Configuration > People"
- Set user.settings.notify.register_pending_approval FALSE
- Register a new account

Viewing all 295320 articles
Browse latest View live


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