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

REST views: Authentication Error (User, Oauth)

$
0
0

Hi,

When trying to secure any custom Views Rest Export (API) with other authentication methods than Basic Auth, the following error occurs:

User:
Notice: Undefined index: user in Drupal\rest\Plugin\views\display\RestExport->Drupal\rest\Plugin\views\display\{closure}() (line 460 of core/modules/rest/src/Plugin/views/display/RestExport.php).
Drupal\rest\Plugin\views\display\RestExport->Drupal\rest\Plugin\views\display\{closure}('user')
array_map(Object, Array) (Line: 461)
Drupal\rest\Plugin\views\display\RestExport->calculateDependencies() (Line: 47)

Simple OAuth:
Notice: Undefined index: simple_oauth in Drupal\rest\Plugin\views\display\RestExport->Drupal\rest\Plugin\views\display\{closure}() (line 460 of core/modules/rest/src/Plugin/views/display/RestExport.php).
Drupal\rest\Plugin\views\display\RestExport->Drupal\rest\Plugin\views\display\{closure}('simple_oauth')
array_map(Object, Array) (Line: 461)
Drupal\rest\Plugin\views\display\RestExport->calculateDependencies() (Line: 47)

This happens when you select the authentication method and save the view. I have attached to simple API-attachementsfor the Views Module.

It looks like the function calculateDependencies() in the RestExport.php is using the array values since array_map is used instead of the array_keys:

  public function calculateDependencies() {
    $dependencies = parent::calculateDependencies();
    $dependencies += ['module' => []];
    $modules = array_map(function ($authentication_provider) {
      // @TODO: Remove - Search in the authenticationProviders for the key of the selected options
      // @TODO: Remove - Uncomment Below to use the keys instead of the values
      // $authentication_provider = array_search($authentication_provider, $this->authenticationProviders);
      return $this->authenticationProviders[$authentication_provider];
    }, $this->getOption('auth'));
    $dependencies['module'] = array_merge($dependencies['module'], $modules);
    return $dependencies;
  }

When applying the fix above to use the array keys instead of the array values, unfortunately the API-route is still not accessible. The response from the API is:
{ "message": "The used authentication method is not allowed on this route."}

Am I missing something to activate the authentication on a custom route? Via Rest-UI I cannot grant access to this API


Configuration translation save triggers an undefined index notice

$
0
0

Problem/Motivation

When saving a field translation, a notice pops up, Notice</em>: Undefined index: field.storage.node.field_name in Drupal\config_translation\Form\ConfigTranslationFormBase->submitForm() (line 203 of /.../core/modules/config_translation/src/Form/ConfigTranslationFormBase.php).'

I can't find an issue related to this and I don't think it's any of the settings I've used.

Proposed resolution

Make sure the config is not set for form values that are not posted.

Notice: Undefined index: status in _block_rehash()

Update wikimedia/composer-merge-plugin to ~1.4

$
0
0

Problem/Motivation

$ composer clearcache
$ rm -rf vendor/
$ rm composer.lock
$ composer update --prefer-lowest
[....wait.... forever....]
$ ./vendor/bin/phpunit --version
PHPUnit 8.3.2-7-g657a612dc3 by Sebastian Bergmann and contributors.

Needless to say, the tests break:

$ ./vendor/bin/phpunit -c core/ --testsuite unit

...eventually....

PHP Fatal error:  Declaration of Double\FormStateInterface\P1506::getCompleteForm() must be compatible with & Drupal\Core\Form\FormStateInterface::getCompleteForm() in /Users/paul/pj2/drupal/vendor/phpspec/prophecy/src/Prophecy/Doubler/Generator/ClassCreator.php(49) : eval()'d code on line 2

But it turns out that if we set the minimum version of wikimedia/composer-merge-plugin to ~1.4, then merges happen the way they should, and phpunit no longer has version confusion, and the tests pass.

Proposed resolution

Update the minimum version of wikimedia/composer-merge-plugin to ~1.4.

Cherry-pick this same fix to 8.4.x.

Remaining tasks

User interface changes

API changes

Data model changes

SqlBase::mapJoinable() should not join across databases with PostgreSQL

$
0
0

All migrations fail when using Postgresql on Centos 6, with a "feature not supported" error on all database transactions when trying to migrate Drupal 7.43 to Drupal 8.1.2. (Both Drush and UI fail the same way.)

From error log:
Migration failed with source plugin exception: SQLSTATE[0A000]: Feature not supported: 7 ERROR: cross-database references are not implemented: "d8.public.migrate_map_d7_url_alias" LINE 4: LEFT OUTER JOIN d8.public.migrate_map_d7_url_alias m... ^: SELECT ua.*, map.sourceid1 AS migrate_map_sourceid1, map.source_row_status AS migrate_map_source_row_status FROM @url_alias ua LEFT OUTER JOIN d8.public.migrate_map_d7_url_alias map ON pid = map.sourceid1 WHERE ( (map.sourceid1 IS NULL ) OR (map.source_row_status = :db_condition_placeholder_0) ); Array ( [:db_condition_placeholder_0] => 1 )

Centos 6.8, Postgres 9.5.3, php 5.6.22. Same error for all tables in the migration.

Serialize file content (base64) to support REST GET/POST/PATCH on file entity

$
0
0

Problem/Motivation

File entities and file/image fields do not currently work with the new REST GET/POST/PATCH/PUT operations.

Proposed resolution

The plan is to include file contents in base64-encoded form when serializing file entities (e.g. for GET requests). File/image field serialization should behave like for entity reference fields in general, providing a URL for the referenced file. Upon deserializing (POST requests), the content will be decoded and put in a new file on the server.

Read about how to POST aka create entities https://www.drupal.org/node/2098511

More documentation about REST: https://www.drupal.org/documentation/modules/rest

Remaining tasks

Review

User interface changes

API changes

Original report by @moshe weitzman

Fatal error when viewing node with content moderation enabled if a module which implements hook_node_grants() is enabled

$
0
0

Problem/Motivation

Using content moderation module on a site where there is some modules which implements hook_node_grants() generate a fatal error when viewing node moderated which have not been yet published.

This issue is a follow up of #2821599: Coexistence of PBF and content_moderation, where i provided a temporary workaround.

I can reproduce this bug with any modules which implements hook_node_grants(). Tested with Permissions by fields, Content Access and a tiny custom My module which implements only an empty hook_node_granst() function.

Steps to reproduce :
- configure a new clean install of drupal 8.2.1
- enable the module content_moderation and configure it to be used on the content type "Article"
- create a new role named "Editor" and some users. Enable all the content_moderation permissions related to "Article" content type for Editor.
- Create two node Article 1 and Article2. Publish the Article 1. Let the Article 2 in draft state.
- Now the users belonging to the "Editor" role can see and edit the two articles written by each other.

- Enable pbf module (or any module which implements hook_node_grants()), or generate a custom module with Drupal Console and implements hook_node_grants() in this module.

- Editor users can see and edit Article 1
- When Editor users try to see Article 2, a fatal error occurs

Fatal error: Call to a member function isRevisionTranslationAffected() on null in core/modules/content_moderation/src/ParamConverter/EntityRevisionConverter.php on line 101

The acquireGrants method in NodeAccessControlHandler provide a default grants[] only if a node is published.

if (empty($grants) && $node->isPublished()) {
  $grants[] = array('realm' => 'all', 'gid' => 0, 'grant_view' => 1, 'grant_update' => 0, 'grant_delete' => 0);
}

Then for nodes which have never been published, the getLatestRevisionId() method in the Class ModerationInformation returns always an empty value, and then the fatal error occurs.

Proposed resolution

Check if the latest_revision is an instance of EntityInterface, in the convert method of EntityRevisionConverter Class. See patch attached.

Remaining tasks

Review the patch and/or
Is there an another root cause of this issue ?

User interface changes

No changes

API changes

I believe not

Data model changes

I don't think

Allow field types to enforce the cardinality

$
0
0

Problem/Motivation

Comment module forces a cardinality of one (although currently broken - see #2399307: comment_form_field_ui_field_storage_edit_form_alter() no longer working) via some form alter work arounds. Menu UI wants to do something similar in #2315773: Create a menu link field type/widget/formatter.

There are field types that make sense only with a specific cardinality.

Proposed resolution

Allow field types to nominate an enforced cardinality.

Remaining tasks

None.

User interface changes

None

API changes

New method getEnforcedCardinality() in FieldStorageConfigInterface.


REST views: authentication is broken

$
0
0

Problem/Motivation

List of authentication providers consists of module names, which are defined them. In this case an authentication cannot be configured, because providers with such names aren't exists.

The way it looks now

Display configuration

How it should look?

The way it dumped to config

Exported configuration

How it should be dumped?

Proposed resolution

Correct a computation of the authentication_providers variable for DI container inside of \Drupal\Core\DependencyInjection\Compiler\AuthenticationProviderPass::process() method.

Correct a computation of the options list for configuring the authentication (\Drupal\rest\Plugin\views\display\RestExport::getAuthOptions()).

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

Remove stale deprecated code.

$
0
0

This from cilefen

https://www.drupal.org/node/2205673#comment-12077914

git grep -e '@deprecated.*before Drupal 8'
core/modules/system/src/Tests/Entity/EntityUnitTestBase.php: * @deprecated in Drupal 8.1.x, will be removed before Drupal 8.2.x. Use
core/tests/Drupal/FunctionalJavascriptTests/JavascriptTestBase.php: * @deprecated in Drupal 8.1.x, will be removed before Drupal 8.3.x. Use
core/tests/Drupal/FunctionalJavascriptTests/JavascriptTestBase.php: * @deprecated in Drupal 8.1.x, will be removed before Drupal 8.3.x. Use
core/tests/Drupal/KernelTests/KernelTestBase.php: * @deprecated in Drupal 8.0.x, will be removed before Drupal 8.2.0.

My conclusion we have stuff to delete in 8.4.x

HtmlEscapedText object to string conversation error

$
0
0

I have got this error:

The website encountered an unexpected error. Please try again later.
Recoverable fatal error: Object of class Drupal\Core\Url could not be converted to string in Drupal\Component\Render\HtmlEscapedText->__construct() (line 41 of core/lib/Drupal/Component/Render/HtmlEscapedText.php).

Drupal\Component\Render\HtmlEscapedText->__construct(Object) (Line: 204)
Drupal\Core\Utility\Token->replace('[node:field_jissue_cover:entity:url]', Array, Array) (Line: 40)
Drupal\metatag\MetatagToken->replace('[node:field_jissue_cover:entity:url]', Array, Array) (Line: 293)
Drupal\metatag\MetatagManager->generateElements(Array, Object) (Line: 321)
metatag_get_tags_from_route() (Line: 143)
metatag_entity_view_alter(Array, Object, Object) (Line: 501)
Drupal\Core\Extension\ModuleHandler->alter(Array, Array, Object, Object) (Line: 285)
Drupal\Core\Entity\EntityViewBuilder->buildMultiple(Array) (Line: 220)
Drupal\Core\Entity\EntityViewBuilder->build(Array)
call_user_func(Array, Array) (Line: 376)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array, ) (Line: 226)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 574)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 227)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 117)
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: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
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: 656)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Complex job in ViewExecutable::unserialize() causes data corruption

$
0
0

Actually there also may be other classes implementing Serializable interface. The \Drupal\views\ViewExecutable is just the first known one to cause the trouble.

Problem/Motivation

There is a PHP bug in the unserialize() function - https://bugs.php.net/bug.php?id=66052 . Precisely in nested unserialization.

When one serialized string contains object which implements Serializable interface, and this object calls another unserialize() with string containing references (serialized as r:NUMBER;), these references are substituted by values from the first string upon unserialization, not from the current one. This behavior leads to corrupted data in runtime and to fatal errors in some cases, and that data may accidentally be saved to persistent storage if not validated explicitly.

The ViewExecutable::execute() method is known to call unserialize() during its job. Examples of Fatals caused by this nested unserialization: #2750463: Fatal error: Call to a member function getFieldStorageDefinition() on array, #2701829: Cannot set batches in Views preventing port of VBO. There may be more. (Other code from ViewExecutable::unserialize() was not tested by me.)

A simple test case, which can be run in /devel/php form on any D8 dev site using the content view (/admin/content):

$field_manager = \Drupal::service('entity_field.manager');

// Get the definition of node's nid field, for example. Only get it not from
// the field manager directly, but from the item data definition. It should be
// the same base field definition object (the field and item definitions refer
// to each other).
$nid_definition = $field_manager->getBaseFieldDefinitions('node')['nid']
  ->getItemDefinition()
  ->getFieldDefinition();
dpm($nid_definition, 'Expected:');

// Load and execute the view.
$view_entity = \Drupal\views\Entity\View::load('content');
$view = \Drupal::service('views.executable')->get($view_entity);
$view->execute('page_1');

// Reset static cache...
$field_manager->useCaches(FALSE);
// ... but leave possibility to use database cache.
$field_manager->useCaches(TRUE);

// Magic line.
unserialize(serialize(['SOMETHING UNEXPECTED', $view]));

// The same code as in the beginning of the test.
$nid_definition = $field_manager->getBaseFieldDefinitions('node')['nid']
  ->getItemDefinition()
  ->getFieldDefinition();
dpm($nid_definition, 'After nested unserialization:');

Proposed resolution

As the bug is still not fixed in PHP, we need to provide conditions to avoid its appearance in Drupal.

I propose to implement some kind of lazy execution in ViewExecutable, if that possible. Ideally, unserialize() method should simply assign values to object properties.

For impatient I'm attaching a patch with a very rough workaround for a limited use case - it covers only ViewExecutable class and the Database cache backend. But it may slow down your project, so don't use it on production.

Remaining tasks

  • Examine other classes with methods unserialize() and __wakeup().

Small typo in file test

$
0
0

Typo in /core/tests/Drupal/KernelTests/Core/File/UnmanagedCopyTest.php :

"Randomly named file doesn't exists."

should be

"Randomly named file doesn't exist."

Documentation for LocalTaskManager::getLocalTasks() is incorrect

$
0
0

API page: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Menu%21Lo...

Two problems:

1. 'for the current route' means 'the route the user is on right now'. But this method has a $route_name parameter which is surely not needed if it's for the current route. The description is wrong.

2. This should say something more precise than 'Collects'. In particular, we should differentiate this from LocalTaskManager::getLocalTasksForRoute(), which loads plugin definitions, while this method gets render arrays. So 'Renders local tasks' would be clearer.

A #default_value = 0 for #type radios checks all radios

$
0
0

Problem

  • Specifying a '#default_value' => 0 in a set of radio button #options using string keys checks all options.

Example

$form['myradios'] = array('#type' => 'radios','#options' => array(
    0 => '- None -','one' => 'one','two' => 'two','three' => 'three',
  ),'#default_value' => 0,
);

Result:

<input id="edit-myradios-0" name="radios" value="0" checked="checked" class="form-radio" type="radio"><input id="edit-myradios-one" name="radios" value="one" checked="checked" class="form-radio" type="radio"><input id="edit-myradios-two" name="radios" value="two" checked="checked" class="form-radio" type="radio"><input id="edit-myradios-three" name="radios" value="three" checked="checked" class="form-radio" type="radio">

Example of steps to reproduce in core:

  • Edit any node view
  • Add 'Published' filter
  • Tick 'Expose ...'
  • Select '- Any -' under 'Published status'
  • Save filter
  • Go to filter form again. 'No' is selected instead of '- Any -'.

Move permission "view any unpublished content" from content moderation to core

$
0
0

Problem/Motivation

For a editorial office it's a worse way to use node access for their workflow:

  • Writers are only allowed to create unpublished nodes
  • Editors need access to every (so node_access isn't useful) unpublished node of the writers...
  • ...but they aren't allowed to publish the node, so I can't use "administer nodes" for the editors

-> the permission "view any unpublished content" is required.

Proposed resolution

Create new permissions for viewing any unpublished content or by node type.

Remaining tasks

Currently we have:

  • Permission for viewing unpublished nodes of any type.
  • Permissions for viewing unpublished nodes defined per node type.
  • Views status filter displays unpublished nodes if user has the 'view any unpublished' permission.

User interface changes

Adds new permissions.

PrepareModulesEntityUninstallForm::formTitle does not exist

$
0
0

Problem/Motivation

The system.prepare_modules_entity_uninstall route defines the following _title_callback value:

\Drupal\system\Form\PrepareModulesEntityUninstallForm::formTitle

This was introduced when the route itself was first introduced in #2688945: Allow removing a module's content entities prior to module uninstallation.

However, it never actually existed.

Thus, an error is thrown when attempting to retrieve the title via the title_resolver service manually. I can only suspect that this error is caught in the system when actually visiting the page since no one has actually caught this.

Proposed resolution

Remove the _title_callback for this route and just replace it with a static title. The confirm form overrides this value anyway.

Remaining tasks

  • Create a patch

User interface changes

None

API changes

None

Data model changes

None

Remove D7 links from D8 Render API documentation

$
0
0

API page: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Render%21...

This page, which documents the D8 Render API, contains links to D7 pages on Drupal.org. There is already an @todo in the documentation to fix this.

The links in question are:

- https://www.drupal.org/node/930760 - Drupal 7: Render Arrays overview, which is superseded in this case by https://www.drupal.org/docs/8/api/render-api/render-arrays. The docs here already link to https://www.drupal.org/docs/8/api/render-api, so this can probably just be removed
- https://www.drupal.org/node/933976, and https://www.drupal.org/node/722174 - Using the theme layer (Drupal 7.x) should be replaced with a link to https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Render%21...

Making the final list:

- https://www.drupal.org/developing/api/8/render
- https://www.drupal.org/docs/8/theming
- @link themable Theme system overview @endlink

Custom Display Settings - Order the view modes based on name rather than key

$
0
0

Problem/Motivation

In Manage Display / Custom Display Settings tab (e.g. admin/structure/types/manage/article/display) the view modes are ordered based on the machine name.

Proposed resolution

Sort the view modes based on the visible name, rather than the machine name.

This issue especially affects non-English views and custom installations with extra view modes where labels have been changed from those originally created.

The following screenshot illustrates the issue (shown after patch applied):
Illustration of the issue (after patch)

Handle initial values when creating a new field storage definition

$
0
0

Problem/Motivation

When creating a new base field storage definition an initial value may need to be assigned as the field value might be required. This value may or may not match the default value, in fact required fields may not have a default value at all.

A real-life example of this is https://github.com/md-systems/file_entity/tree/schema_handling, where we need to add a type field to the file entity, which will store the field bundle. Core SQL storage requires an initial value for this field as it's marked as NOT NULL.

We need to figure out a way to specify and apply an initial value for each field storage definition.

Proposed resolution

Add two methods to \Drupal\Core\Field\BaseFieldDefinition: setInitialValue() and setInitialValueFromField() and use that information when we create the table columns in \Drupal\Core\Entity\Sql\SqlContentEntityStorageSchema::getSharedTableFieldSchema.

Note that support for "initial value from field" has been added specifically for this use case: #2753475: Support using the values of another field as initial values when adding a new field

Remaining tasks

  • Solution definition
  • Implementation
  • Reviews

User interface changes

Nope.

API changes

API additions: the two new methods on BaseFieldDefinition.

Viewing all 296410 articles
Browse latest View live


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