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

Implement media source plugin for remote video via oEmbed

November 30, 2016, 2:51 pm
$
0
0

Problem/Motivation

One of the main reasons to adopt Media Entity in core was the need to be able to work with remote media (especially videos). We need to provide a base implementation of this in core Media that supports the most popular online video providers, ideally in a very extensible way.

Proposed resolution

Implement support for oEmbed in the Media module, supporting a subset of popular video providers by default (specifically, Vimeo and YouTube). Supporting oEmbed generally will give us, and contrib, the latitude to easily support other remote media assets in the future (e.g., Twitter, Instagram, other video providers).

Security considerations

From https://oembed.com/#section3

When a consumer displays HTML (as with video embeds), there's a vector for XSS attacks from the provider. To avoid this, it is recommended that consumers display the HTML in an iframe, hosted from another domain. This ensures that the HTML cannot access cookies from the consumer domain.

Drupal does not require multiple domains so it is not possible for oEmbed video fields to be secure out-of-the-box. Since #2522002: Do not strip www. from cookie domain by default because that leaks session cookies to subdomains has been committed to Drupal 8 it is possible to use a subdomain, for example: video.example.com, as long as example.com is redirected to www.example.com. We need make it simple to configure a different domain to serve the oEmbed content from and we need to have sufficient security warnings to inform users that their configuration is not secure.

Additionally we need to ensure that content creators can not enter arbitrary URLs. A content creator should only be able to link to sources from a list configured by someone with a trusted permission. The defaults for this configuration need to be sensible and restrictive. Plus the configuration field needs documentation about the security implications of adding sources.

(related comments: #139#137#132)

Remaining tasks

  • decide between specific provider or oEmbed based solution
  • implement plugin and extensive tests

↧
Search

Views Block Display skips preBlockBuild() call on ajax rebuild

October 30, 2015, 2:17 pm
$
0
0

Problem/Motivation

The \Drupal\views\Plugin\views\display\Block::preBlockBuild() method is responsible for manipulating the view before it is rendered by the corresponding block plugin. The block plugin itself actually calls this method, however blocks cannot show exposed filters without using ajax, and the ajax rebuild for views will not call the preBlockBuild() method.

As a practical example, blocks can override the number of results per page for a view, however if they leverage ajax rebuild, on the first rebuild (which is also used for pagers) the view will be rendered without the block's overrides. If the default view shows 50 per page, and the override shows 5, the first ajax call will result in the view now showing 50 instead of 5.

Proposed resolution

The views/ajax controller needs to consult the block when rebuilding block displays. Doing this generically is likely to be a bit convoluted.

Remaining tasks

Identify a solution.
Implement it.

User interface changes

Likely none

API changes

TBD

Data model changes

Likely none

Eclipse

↧
↧

The off-canvas dialog should have a 1px transparent border

May 30, 2018, 4:06 am
$
0
0

Problem/Motivation

off-canvas.theme.css has a CSS rule that intends to override jQuery UI's default styling:

.ui-dialog.ui-dialog-off-canvas {
  ...
  border: 0 solid transparent;
  ...
}

However, this specific override is not actually applied because jQuery UI's style rule wins, as can be seen in the "before" screenshot.

Proposed resolution

A naive implementation would be to make the off-canvas rule more specific.

Are there any other options?

Remaining tasks

Discuss, review.

User interface changes

The off canvas dialog won't have the 1px white border anymore.

API changes

Nope.

Data model changes

Nope.

↧

Reword user cancellation form buttons

June 20, 2012, 9:31 am
$
0
0

Problem/Motivation

The two choices at the bottom of the confirmation screen when canceling a user account are a button with the text "Cancel account" and a link with the text "Cancel." While the intention may be obvious to many people, it is also likely confusing to many.

This is true for both, cancelling a user account or mass cancelling several accounts.

Proposed resolution

Replace the "Cancel" label button with "Abort".

Remaining tasks

None.

User interface changes

On user cancel account confirmation form, the label "Cancel" of the cancelling operation button is replaced with "Abort".

API changes

None.

Data model changes

None.

↧

User forms broken for admin without 'administer users'

February 20, 2017, 8:37 am
$
0
0

This issue only occurs with modules hooks - it has no impact in pure Drupal core.

In Drupal core, there is a single permission 'administer users' that controls whether a user can 'administer' the user account of another user. However the Drupal 8 Entity API makes it possible to refine the access, for example by means of hook_entity_access. This allows modules such as Administer Users by Role to create a "sub-admin" - a user without 'administer users' permissions that nevertheless has access to update some other users' account.

Unfortunately RegisterForm, ProfileForm and UserCancelForm are broken when used by the sub-admin. The problems arise from the fact that each form can be used in two ways: a normal user can update their own account or an admin can administer another user.

Expected behaviour

Tthe sub-admin sees the same interface as the admin, except missing fields such as role that require additionaly access.

Actual behaviour

The sub-admin sees a confusing mixture of the user and admin interfaces, for example:

  • After creating a user the sub-admin is logged in as that user.
  • When cancelling an account the sub-admin see "Your account will be blocked and ..." but it's actually another users account.
  • Several fields are missing due to lack of access.

Steps to reproduce

  • Install Administer Users by Role release 8.x-2.0-alpha3.
  • Create a role with permissions 'Create new users', 'Edit users with no custom roles', 'Cancel users with no custom roles', 'Access the users overview page', 'View user information'.
  • Create user with this role, and log in as that user.
  • Create a user.

Or if you prefer, can reproduce by writing custom code.

Workaround

It is possible to fix all the problems using the extensive hooks provided by the user module. However it took 95 lines of code in Administer Users by Role. What's more, this code has detailed dependencies on the internal implementation in the user module, so may need to be updated for future Drupal versions.

You can test the workaround if you also install the sub-module administerusersbyrole_hack. You must disable this sub-module to see the bug.

Solution

Fortunately it seems possible to fix the forms with some fairly simple changes to the user module, without any negative impact on mainline use cases. This seems valuable and worthwhile because any contrib or custom code hooking into User access is likely to see the same problems.

Patch coming up.

↧
↧

8% of the files having zero test coverage are incorrectly listed.

April 26, 2015, 3:55 am
$
0
0

This is a follow up issue to #2458487: Alter php.xml.dist to remove test classes from code coverage reports.

It is about removing test files from the code coverage reports with

./vendor/bin/phpunit --coverage-html ~/d8CodeCoverage/

Thing have changed, in the month since the issue was committed.- it look like test coverage has improved and in the current iteration new test files have risen up to clutter the top of the insufficient code coverage list [ see dashboard.html ] - this is a meaningless distraction and the 50 or so files can be removed with a stroke of a pen ... er I mean by refreshing the php.xml.dist

There are located in ./core/modules/system/tests/modules/form_test/src/Form

and have the prefix FormTest*.php
From git blame the files were introduced over a year ago #2030165: Convert form_test_* functions to classes

↧

[PP-1] Creating a table with an explicitly empty primary key is broken on PostgreSQL

May 31, 2018, 2:04 am
↧

[PP-2] $fixnull behavior is broken on PostgreSQL's ::addField()

May 31, 2018, 2:17 am
$
0
0

Problem/Motivation

PostgreSQL's Schema::addField() does not properly detect when a field is part of a newly added primary key, so that it does not calculate T $fixnull variable correctly.

This is because a $keys_new variable is inspected but the variable is actually called $new_keys.

Proposed resolution

Because the variable is actually specified as $keys_new by the interface, rewrite usages of $new_keys to $keys_new instead of the other way around.

This will probably require #2974722: [PP-1] Fix dropping of columns in a composite primary key on MariaDB >=10.2.8 and make it consistent across database drivers for test coverage.

↧
Search

Entity: Convert system functional tests to phpunit

February 21, 2018, 4:27 am
↧
↧

Convert web tests to JTB and KTB tests for user module part-3

July 17, 2017, 1:26 am
↧

Random Failure in Drupal\Tests\Core\Command\QuickStartTest

May 27, 2018, 9:37 am
$
0
0
↧

Impove FilterIdTest provider keys

May 22, 2018, 8:37 pm
$
0
0

follow up to #2940679: Fix FilterIdTest test names

By converting the comments for each provider data set to the keys we can improve the error output. To quote larowlan

e.g from

     // The filter ID is mapped, and the plugin exists.
      [
        'foo',
        'filter_html',
      ],

to

'filter ID mapped to plugin that exists' => [
        'foo',
        'filter_html',
      ],
↧

Add request options for system_retrieve_file()

June 5, 2015, 3:29 am
↧
↧

config.storage.schema exercises a deprecated code path in the early installer

October 16, 2017, 1:41 am
$
0
0

Discovered in #2870194: Ensure that process-isolated tests can use Symfony's PHPunit bridge to catch usages of deprecated code

Problem/Motivation

We should not be using \Drupal\Core\Config\ExtensionInstallStorage without a profile but we do in the very early installer.
This is happening in super early installer before a profile is chosen when we render the profile select page. To do this we need the theme.manager -> theme.negiotator -> access_check.theme -> theme_handler -> config.factory -> config.typed -> config.storage.schema.

Proposed resolution

Swap out the storage in the early installer for the NullStorage. This is fine because we don't write config at this point. We only write config once we have database settings and we're installing the system module and at this point we have a full regular container. We rebuild the container in drupal_install_system() to ensure we have a regular container before installing the base system configuration.

The testing the fact we're not using the deprecated code path is not possible until #2870194: Ensure that process-isolated tests can use Symfony's PHPunit bridge to catch usages of deprecated code lands.

Remaining tasks

User interface changes

None

API changes

None

↧

Running my test : PluginNotFoundException: The "node" entity type does not exist.

November 9, 2017, 5:20 am
$
0
0

Hello all,

I've created one module for importing users with a CSV file. The module is working fine if try it by the admin interface.
In this module I have declared the following function :

<?php
public function getCountryId($country_code) {
    $country_ids = $this->entity_type_manager->getStorage('node')->getQuery()
      ->condition('type', 'country')
      ->condition('title', $country_code)
      ->execute();

    return reset($country_ids);
  }
?>

Now what I'm doing is to create my test class and if I try to use this function to assert is return value, I've the following message displayed :

sudo -u www-data -E ./vendor/bin/phpunit -c core --testsuite import
PHPUnit 4.8.36 by Sebastian Bergmann and contributors.

E

Time: 4.63 seconds, Memory: 6.00MB

There was 1 error:

1) Drupal\Tests\users_csv_importer\Functional\ImportTest::testImportCSV
Drupal\Component\Plugin\Exception\PluginNotFoundException: The "node" entity type does not exist.

/var/www/cip/bobp_new/core/lib/Drupal/Core/Entity/EntityTypeManager.php:133
/var/www/cip/bobp_new/core/lib/Drupal/Core/Entity/EntityTypeManager.php:233
/var/www/cip/bobp_new/core/lib/Drupal/Core/Entity/EntityTypeManager.php:169
/var/www/cip/bobp_new/modules/custom/users_csv_importer/src/Form/ImportForm.php:156
/var/www/cip/bobp_new/modules/custom/users_csv_importer/tests/src/Functional/ImportTest.php:51

Here the code of my test :

public function testImportCSV() {
    $this->assertEquals(25, $this->import_form->getCountryId("AT"));
}

If remove this assert and try to assert my import function (which read a CSV file and for each line create a user) then my custom field created on user throw another exception : InvalidArgumentException: Field field_gender is unknown.

It's look like that database is not complete during tests.
Do I have misunderstanding something or it's something wrong with Drupal ?

I can provide more code if needed.

Thanks.

↧
Search

Add ltrim($path, '/') in drupalGet method

October 6, 2015, 11:35 pm
$
0
0

Problem/Motivation

Follow-up for #2575869-70: Remove all remaining usage of deprecated UrlGeneratorInterface::generateFromPath() and delete it.

+++ b/core/modules/simpletest/src/BrowserTestBase.php
@@ -412,7 +412,7 @@ protected function drupalGet($path, array $options = array()) {
+        $url = Url::fromUri('base:/' . $path, $options)->toString();
+++ b/core/modules/simpletest/tests/src/Functional/BrowserTestBaseTest.php
@@ -34,7 +34,7 @@ public function testGoTo() {
-    $this->drupalGet('/test-page');


@@ -46,7 +46,7 @@ public function testGoTo() {
-    $this->drupalGet('/form-test/object-builder');

@larowlan:

Instead of changing the ->drupalGet calls, could we just use ltrim($path, '/') in drupalGet method

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

↧

Some calls to assertEquals have expected/actual parameters reversed

May 17, 2017, 8:28 am
$
0
0

I noticed a couple calls to phpunit assertEquals which clearly had the "expected" and "actual" parameters reversed, which can lead to confusing failure messages (and accidental propagation of the incorrect form, when other people copy/paste code blocks that look good). Anyway, I did a search and found a few more where obvious strings or integers, etc, were in the "actual" position. This is a very simple issue, but might as well be fixed...

↧
↧

Move TestSuite/* into a dedicated namespace

August 9, 2016, 2:45 am
$
0
0

Problem/Motivation

i'm a bit confused about the namespace overlap of \Drupal\Tests\TestSuites\TestSuiteBase and \Drupal\Tests\TestSuites\TestSuiteBaseTest

core/tests/TestSuites/TestSuiteBase.php
and core/tests/Drupal/Tests/TestSuites/TestSuiteBaseTest.php have the same namespace, but are living in total different folders.

On top of that \Drupal\Tests\TestSuites\TestSuiteBaseTest relies on core/tests/TestSuites/TestSuiteBase.php being loaded before.

Proposed resolution

  • Move the TestSuite files from \Drupal\Tests\TestSuites to \Drupal\TestSuites
  • Add a manual require_once into \Drupal\Tests\TestSuites\TestSuiteBaseTest

Remaining tasks

User interface changes

API changes

Data model changes

↧

Convert web tests to browser tests for file module

April 17, 2017, 12:01 pm
↧

[PP-1] Fix dropping of columns in a composite primary key on MariaDB >=10.2.8 and make it consistent across database drivers

May 23, 2018, 3:48 am
$
0
0

Problem/Motivation

There are several issues related to primary keys across the 3 database drivers:

  1. Dropping a (schema) field that is part of a composite primary key throws an SQL exception on MariaDB >10.2.8. When dropping a field named id, for example:

    Key column 'id' does not exist in table

    Even though the field clearly does exist. https://mariadb.com/kb/en/library/alter-table explains this in more detail.

  2. When dropping a (schema) field that is part of a composite primary key, MySQL and our SQLite driver implementation remove the field from the primary key but leave the reamining primary key in place. This can leave the table in an invalid state. PostgreSQL on the other hand automatically drops the primary key entirely, which is the safer behavior.
  3. When renaming a field that is part of the primary key via Schema::changeField() our SQLite driver does not update the primary key definition accordingly so that the rename fails. This is because Schema::mapKeyDefinition() makes an incorrect assumption about the $mapping variable; it looks up a value by key, but it must look up a key by value.

Proposed resolution

  1. See 2.
  2. When dropping a field on any of the by Drupal supported databases (MySQL, PostgreSQL and SQLite), check whether it is part of a composite primary key, and - if so - drop the primary key - and do not recreate it afterwards.
  3. Fix SQLite's Schema::mapKeyDefinition() so that renaming a primary key field works on SQLite.
↧
Viewing all 295019 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>