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

Remove the option to specify a base_url from within settings.php

$
0
0

Problem/Motivation

Currently it is possible to enforce a $base_url from within settings.php. Up until Drupal 4.6.x this was required. Since then it was only necessary on broken webserver configurations. Also depending on the webserver configuration, setting $base_url was required in order to prevent instances of #2221699: HTTP_HOST header cannot be trusted (e.g., possibly #1355344: Possible to deface using HTTP_HOST if base_url not set in settings.php), but that issue has been resolved by introducing the trusted_host_patterns setting.

However, since there is no way to enforce the base URL in a Symfony request, the setting only works for code which is still depending on the deprecated globals. E.g., on a site which enforces $base_url from settings.php, modern code using something like $request->getSchemeAndHttpHost() will produce the wrong results in such configurations.

Note that enforcing $base_url in settings.php also influences $base_root and $base_path globals.

All of this functionality not covered at all by any tests.

Proposed resolution

Remove the option to specify a base_url from within settings.php.

Remaining tasks

Review.

User interface changes

None.

API changes

None.

Data model changes

None.

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue categoryBug because it removes defect functionality
Issue priorityNormal
DisruptionDisruptive for existing sites if they are running on webservers with broken configuration

Move Attribute classes under Drupal\Component

$
0
0

The Drupal\Core\Template\Attribute class and its helper classes have no Drupal dependencies apart from Drupal Components. There already exists at least one project where Attribute classes are used independently of Drupal, and it would be good if they could be used as a proper Composer package.

Some view tokens ([view:page-count] and [view:total-rows]) are incorrect

$
0
0

The [view:page-count] token incorrectly returns 1 when there are several pages of results for a given view.

To reproduce:

  1. drush si standard -y --account-pass=admin
  2. drush en -y devel_generate
  3. drush generate-content 50
  4. Log in as admin and navigate to /admin/structure/views/view/frontpage
  5. Add a "Global: text area" handler to the "Header" area with the following text: [view:current-page] out of [view:page-count]
  6. Save the view
  7. Navigate to the site home page.

1 out of 1 will appear in the header area, however three pages of Views results show in the pager at the bottom of the page.

Profile page's title/heading does not fulfill hook_user_format_name_alter

$
0
0

I am not sure if this is an actual bug or not, so I assigned category "Support Request"

I've implemented hook_user_format_name_alter in a custom module, and it works perfectly. The newly formatted username that I have defined is being used instead of the default username value everywhere in the application. Everywhere, that is, except the heading on the user profile pages.

EXAMPLE:
Default Username: "123456"
Custom Username Defined by Hook: "customuser"

"customuser" is displaying for my user in the following places:

  • all views that include my user record (example, /admin/people and /admin/content),
  • the administrative toolbar
  • the raw url for my user profile, which shows "/user/customuser" instead of "/user/123456"
  • the heading on my profile's contact tab, which shows "Contact customuser" instead of "Contact 123456"

So, I'm wondering why the title on the main profile page is not affected by hook__user_format_name_alter, especially when the title on the contact page does fulfill the hook's definition. I tried setting up the following RouteSubscriber to override the title on the profile page, but doing so broke something and gave me an "Access Denied" message when trying to access my own profile page (even when testing this out on the admin account):

/**
 * @file
 * Contains \Drupal\MYMODULE\Routing\RouteSubscriber.
 */

// see: https://www.drupal.org/node/2187643

namespace Drupal\MYMODULE\Routing;

use Drupal\Core\Routing\RouteSubscriberBase;
use Symfony\Component\Routing\RouteCollection;

/**
 * Listens to the dynamic route events.
 */
class RouteSubscriber extends RouteSubscriberBase {

  /**
   * {@inheritdoc}
   */
  public function alterRoutes(RouteCollection $collection) {
    //Right now, this breaks the user's home page.
    if ($route = $collection->get('entity.user.canonical')) {
      $route->setDefaults(['_title', 'CUSTOM PROFILE TITLE']);
    }
  }

}

Thanks in advance for any assistance.

Support for end date

$
0
0

Problem/Motivation

The datetime field does not support end dates, which makes it impossible to create a date range. This is a very important feature for a calendar.

Proposed resolution

Add an option to the field to allow collection of end date.

Amend the schema so that a 'value2' column is always present, representing the end date.

Remaining tasks

User interface changes

New field widgets.

API changes

New field type and associated goodness.

Data model changes

New schema for date ranges.

#2686409: Time Ago summary does not render on Manage Display for Datetime
#2686407: Datetime type should be disabled on storage setting form if field has data

ToolbarIntegrationTest randomly fails

$
0
0

Drupal 8.1.0, with RefreshLess enabled:

PHPUnit 4.8.11 by Sebastian Bergmann and contributors.

E

Time: 1.32 minutes, Memory: 4.00Mb

There was 1 error:

1) Drupal\Tests\toolbar\FunctionalJavascript\ToolbarIntegrationTest::testToolbarToggling
Zumba\GastonJS\Exception\JavascriptError: One or more errors were raised in the Javascript code on the page.
            If you don't care about these errors, you can ignore them by
            setting js_errors: false in your Poltergeist configuration (see documentation for details).
AjaxError:
An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /toolbar/subtrees/h44VigUWX0CKpfG-F2mSPWyAQ6j34qKtKGcs2os92wg
StatusText: Internal Server Error
ResponseText: {"message":"A fatal error occurred: SQLSTATE[42S02]: Base table or view not found: 1146 Table \u0027drupal.simpletest977695key_value\u0027 doesn\u0027t exist: SELECT 1 AS expression\nFROM \n{key_value} key_value\nWHERE ( (name = :db_condition_placeholder_0) AND (collection = :db_condition_placeholder_1) ); Array\n(\n    [:db_condition_placeholder_0] =\u003E system.theme.files\n    [:db_condition_placeholder_1] =\u003E state\n)\n"}
AjaxError:
An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /toolbar/subtrees/h44VigUWX0CKpfG-F2mSPWyAQ6j34qKtKGcs2os92wg
StatusText: Internal Server Error
ResponseText: {"message":"A fatal error occurred: SQLSTATE[42S02]: Base table or view not found: 1146 Table \u0027drupal.simpletest977695key_value\u0027 doesn\u0027t exist: SELECT 1 AS expression\nFROM \n{key_value} key_value\nWHERE ( (name = :db_condition_placeholder_0) AND (collection = :db_condition_placeholder_1) ); Array\n(\n    [:db_condition_placeholder_0] =\u003E system.theme.files\n    [:db_condition_placeholder_1] =\u003E state\n)\n"}
    at http://localhost/core/misc/ajax.js?v=8.1.1:965 in error
    at http://localhost/core/misc/ajax.js?v=8.1.1:510 in complete
    at http://localhost/core/assets/vendor/jquery/jquery.min.js?v=2.1.4:2 in j
    at http://localhost/core/assets/vendor/jquery/jquery.min.js?v=2.1.4:2 in fireWith
    at http://localhost/core/assets/vendor/jquery/jquery.min.js?v=2.1.4:4 in x
    at http://localhost/core/assets/vendor/jquery/jquery.min.js?v=2.1.4:4

/var/www/html/vendor/jcalderonzumba/gastonjs/src/Browser/BrowserBase.php:119
/var/www/html/vendor/jcalderonzumba/gastonjs/src/Browser/BrowserBase.php:99
/var/www/html/vendor/jcalderonzumba/gastonjs/src/Browser/BrowserCookieTrait.php:54
/var/www/html/vendor/jcalderonzumba/mink-phantomjs-driver/src/SessionTrait.php:45
/var/www/html/vendor/jcalderonzumba/mink-phantomjs-driver/src/SessionTrait.php:37
/var/www/html/vendor/behat/mink/src/Session.php:78
/var/www/html/vendor/behat/mink/src/Mink.php:186
/var/www/html/core/tests/Drupal/Tests/BrowserTestBase.php:506

FAILURES!
Tests: 1, Assertions: 10, Errors: 1.

With RefreshLess disabled:

PHPUnit 4.8.11 by Sebastian Bergmann and contributors.

.

Time: 1.52 minutes, Memory: 4.00Mb

OK (1 test, 10 assertions)

My Questions

1. Is it true that SIMPLETEST_BASE_URL is supposed to be set to the URL that I can access my site with (i.e. the default profile) and then Simpletest module will know to serve the testing environment instead of the default environment?

2. What I don't understand is that since the test runs in a separate environment, why would enabling a module on the "default" profile affect tests?

Thanks!

Add test coverage for the editor's max dimension setting, and fix its message when one dimension is unrestricted

$
0
0

Problem/Motivation

This issue first went off on the wrong tangent and even got to RTBC. It's in fact valid to have:

  1. neither max width nor max height: unrestricted
  2. only max width, no max height: restricted on width, height will adjust while preserving aspect ratio
  3. only max height, no max width: restricted on height, width will adjust while preserving aspect ratio
  4. both max width and max height: restricted on both dimensions

Everything already works this way. Well, except it doesn't due to a bug elsewhere: #2628656: Max dimensions do not apply to Editor Inline image. But that's a separate matter.

What is necessary here:

  1. test coverage for this.
  2. the message for cases 2 and 3 is also misleading: it'll say that the unrestricted dimension is resized to 0 — that makes no sense of course

Proposed resolution

Test coverage!

Remaining tasks

  1. Fix the message to be sensible in cases where only one dimension is specified (the message always says the unbounded dimension is resized to 0, which makes no sense)
  2. Explicitly spell out in the config schema that width and height can be null (see #52)
  3. Test coverage for using EditorImageDialog:
    1. Test coverage for when both max dimensions are provided: validating the message and the stored image's dimensions Done in #2628656: Max dimensions do not apply to Editor Inline image.
    2. Test coverage for when neither max dimension is provided: validating the message and the stored image's dimensions Done in #2628656: Max dimensions do not apply to Editor Inline image
    3. Test coverage for when either max dimension is provided: validating the message and the stored image's dimensions Done in #2628656: Max dimensions do not apply to Editor Inline image
  4. Test coverage for using the Text Editor configuration form:
    1. Test coverage for when both max dimensions are provided, validating the stored data
    2. Test coverage for when neither max dimension is provided, validating the stored data
    3. Test coverage for when either max dimension is provided, validating the stored data (specifically, that either dimension is null and not 0 or something else)

User interface changes

None.

API changes

None.

Data model changes

None.

Rest HEAD request fails until after a GET request

$
0
0

Problem

I'm having an issue trying to send a HEAD request to a D8 installation to verify the existence of a particular entity. A HEAD request to an existing (newly created) Node will always fail with the following 500 error:

LogicException: The controller must return a response (null given). Did you forget to add a return statement somewhere in your controller? in Symfony\Component\HttpKernel\HttpKernel->handleRaw() (line 157 of /var/www/drupal/vendor/symfony/http-kernel/HttpKernel.php).

Oddly, after sending a single GET request to the same endpoint all subsequent HEAD requests are successful. The handleRaw method in the error doesn't seem helpful as it only shows that a request object is not received.

How to reproduce

I was using HttpClient in a custom module, but the easiest way to reproduce is using Postman:
1. Create a new node setting Authentication, Accept, Content-Type, and CSRF token headers:
POST: http://drupalvm.dev/entity/node?_format=hal_json
With the following body:

{"type": [{"target_id": "article"
	}],"title": [{"value": "testing head request to test entity exists","lang": "en"
	}],"status": [{"value": 1,"lang": "en"
	}],"promote": [{"value": 1,"lang": "en"
	}],"sticky": [{"value": 0,"lang": "en"
	}],"body": [{"value": "this is the body < \/p>\r\n","format": "basic_html","summary": "","lang": "en"
	}]
}

Returns 201 Created

2. Send a HEAD request to that new node (in this case nid 46):
HEAD http://drupalvm2.dev/node/46?_format=hal_json
Returns 500 server error

3. Send a GET request to that new node:
GET http://drupalvm2.dev/node/46?_format=hal_json
Returns 200 OK

4. Now repeat number 2. This and all subsequent HEAD requests are now successful with a 200 status.


Description in TableFormatter

$
0
0

Add description en tableformater
Add new code in line 27 and 31
change file: TableFormatter.php

<?php

namespace Drupal\file\Plugin\Field\FieldFormatter;

use Drupal\Core\Field\FieldItemListInterface;

/**
 * Plugin implementation of the 'file_table' formatter.
 *
 * @FieldFormatter(
 *   id = "file_table",
 *   label = @Translation("Table of files"),
 *   field_types = {
 *     "file"
 *   }
 * )
 */
class TableFormatter extends FileFormatterBase {

  /**
   * {@inheritdoc}
   */
  public function viewElements(FieldItemListInterface $items, $langcode) {
    $elements = array();

    if ($files = $this->getEntitiesToView($items, $langcode)) {
      $header = array(t('Attachment'), t('Size'));
      $rows = array();
      foreach ($files as $delta => $file) {
        $item = $file->_referringItem; #new Code
        $rows[] = array(
          array('data' => array('#theme' => 'file_link','#file' => $file,'#description'=> $item->description, #new Code'#cache' => array('tags' => $file->getCacheTags(),
              ),
            ),
          ),
          array('data' => format_size($file->getSize())),
        );
      }

      $elements[0] = array();
      if (!empty($rows)) {
        $elements[0] = array(
          '#theme' => 'table__file_formatter_table','#header' => $header,'#rows' => $rows,
        );
      }
    }

    return $elements;
  }

}

?>

Filename suggestions aren't correct for menu theme hook

$
0
0

Just by turning on twig debug and looking at theme suggestions, you can see for the main menu (and any corresponding menu like footer) that there is a duplicate theme suggestion and at the most specific level which overrides any and all customizations in hook_theme_suggestions_alter().

<!-- THEME DEBUG --><!-- THEME HOOK: 'menu__main' --><!-- FILE NAME SUGGESTIONS:
   * menu--main.html.twig
   x menu--main--customization.html.twig
   * menu--main.html.twig
   * menu.html.twig
-->

Should be:

<!-- THEME DEBUG --><!-- THEME HOOK: 'menu__main' --><!-- FILE NAME SUGGESTIONS:
   x menu--main--customization.html.twig
   * menu--main.html.twig
   * menu.html.twig
-->

Increase minimum size of targets for touch screens

$
0
0

I think we need to do a full audit on the sizes of all our 'clickable' elements in Seven and then define a minimum height and width.

Only local images are allowed.In the iPhone Human Interface Guidelines, Apple recommends a minimum target size of 44 pixels wide 44 pixels tall. Since physical pixel size can vary by screen density, Apple's pixel specifications apply best to the iPhone's 320 by 480 pixel, 3.5 inch display (164ppi). Since the release of the iPhone 4's Retina Display (326ppi) Apple has updated these specs to points instead of pixels.

In the Windows Phone UI Design and Interaction Guide (PDF), Microsoft goes further and suggests: a recommended touch target size of 9mm/34px; a minimum touch target size of 7mm/26px; a minimum spacing between elements of 2mm/8px; and the visual size of a UI control to be 60-100% of the touch target size.

They also suggest touch targets can be larger than 9mm if: the UI element is frequently touched; the result of a touch error is severe or really frustrating; the UI element is located toward edge of the screen or difficult to hit; or when the UI element is part of a sequential task –like using the dial pad.

Nokia's developer resources suggest that touchable interface elements should not be smaller than the smallest average finger pad, that is, no smaller than 1 cm (0.4") in diameter or a 1 cm × 1 cm square. Minimum target sizes for a finger usable UI element are:

  • 7 x 7 mm with 1 mm gaps for index finger usage
  • 8 x 8 mm with 2 mm gaps for thumb usage
  • List type of components should have minimum of 5 mm line spacing
  • The width of a finger limits the density of items on screen. If the items are too close, the user will not be able to choose a single one.

Luke Wroblewski

Include CKEditor's AutoGrow plug-in

$
0
0

Problem/Motivation

Right now in Drupal 8, if you go to node/add/article, type the highlights of your article in a few words, click the "Image" button, upload an image, hit "Save", you get this:

So we have a great UX for everything up to the point and including uploading & inserting an image. But once it's inserted, it's… awkward.

(The same problem exists when you have finished writing your article — even if it's text-only — you have to manually resize CKEditor.)

Proposed resolution

Use CKEditor's (GPL!) AutoGrow plug-in. Then it would have looked like this instead:

A demo of the AutoGrow plug-in is available online: http://ckeditor.com/demo#auto-grow

Remaining tasks

  1. Build consensus that this is desirable.
  2. Wait for #2039163: Update CKEditor library to 4.4.
  3. Wait for CKEditor to add support for "smart" autogrowing: https://dev.ckeditor.com/ticket/12120
  4. Create a new build that includes it.
  5. Get patch committed

User interface changes

None, other than that the CKEditor iframe instances will grow along automatically.

API changes

None.

Duplicate placeholders generated from #lazy_builder callbacks to history_attach_timestamp in comments cause JavaScript errors when using Big Pipe

$
0
0

Problem/Motivation

When using the big_pipe module with JavaScript, under certain circumstances, placeholders generated from #lazy_builder callbacks to history_attach_timestamp in comments cause Drupal.behaviors for the entire document to be detached. This issue became apparent after custom theming the comments field to put the comment form above the list of comments rather than below it. The user-facing issue was that, shortly after being attached to the comment_body field, the CKEditor was subsequently detached, leaving a plain textarea field, and producing the following warning in the browser's developer console:

[CKEDITOR] Error code: editor-incorrect-destroy.
[CKEDITOR] For more information about this error go to http://docs.ckeditor.com/#!/guide/dev_errors-section-editor-incorrect-de...

The specific reason for this issue is as follows. After making a theme change to move the comment form above the list of existing comments, the order of content with placeholders changed in the document, putting the placeholder for the comment form above the history_attach_timestamp. Big Pipe uses the order of the placeholders in the markup to set the order in which it renders the <script> tags it appends to the document body, and Big Pipe's JavaScript, in turn, reads the script tags in the order they appear. The result in this case was that the placeholder for history_attach_timestamp was evaluated after the one for the comment form.

Steps to reproduce:

  1. Ensure comment, big_pipe, and history modules are enabled.
  2. Create a node with a few comments.
  3. Edit field--comment.html.twig to move the comment form above the list of comments on a node
  4. Rebuild caches and note that the WYSIWYG is gone from the form, and the errors above are in the Chrome or Firefox console
  5. Attach patch and note the issue is fixed

Here is a sample of the script tags that Big Pipe appended to the end of the document body after the comment form was moved above the comment list:

<script type="application/json" data-big-pipe-event="start"></script><script type="application/json" data-big-pipe-placeholder="callback=Drupal%5CCore%5CRender%5CElement%5CStatusMessages%3A%3ArenderMessages&amp;args[0]&amp;token=a8c34b5e" data-drupal-ajax-processor="big_pipe">
    [{"command":"settings","settings":{"ajaxPageState":{"theme":"bartik","libraries":"ajax_comments\/commands,bartik\/global-styling,big_pipe\/big_pipe,classy\/base,classy\/messages,comment\/drupal.comment-by-viewer,comment\/drupal.comment-new-indicator,contextual\/drupal.contextual-links,contextual\/drupal.contextual-toolbar,core\/drupal.active-link,core\/html5shiv,core\/normalize,history\/mark-as-read,shortcut\/drupal.shortcut,statistics\/drupal.statistics,system\/base,toolbar\/toolbar,toolbar\/toolbar.escapeAdmin,tour\/tour,user\/drupal.user.icons"},"pluralDelimiter":"\u0003","user":{"uid":"1","permissionsHash":"50f490420ed4c54558b56e853ec07d868d9317d8e1f2e7b76962c15f61956d44"}},"merge":true},{"command":"add_css","data":"\u003Clink rel=\u0022stylesheet\u0022 href=\u0022\/core\/themes\/classy\/css\/components\/messages.css?o4m2v0\u0022 media=\u0022all\u0022 \/\u003E\n"},{"command":"insert","method":"replaceWith","selector":"[data-big-pipe-selector=\u0022callback=Drupal%5CCore%5CRender%5CElement%5CStatusMessages%3A%3ArenderMessages\u0026args[0]\u0026token=a8c34b5e\u0022]","data":"\n  ","settings":null}]</script>    <script type="application/json" data-big-pipe-placeholder="callback=Drupal%5Cblock%5CBlockViewBuilder%3A%3AlazyBuilder&amp;args[0]=bartik_local_tasks&amp;args[1]=full&amp;args[2]&amp;token=7daf9ccc" data-drupal-ajax-processor="big_pipe">
    [{"command":"insert","method":"replaceWith","selector":"[data-big-pipe-selector=\u0022callback=Drupal%5Cblock%5CBlockViewBuilder%3A%3AlazyBuilder\u0026args[0]=bartik_local_tasks\u0026args[1]=full\u0026args[2]\u0026token=7daf9ccc\u0022]","data":"\u003Cdiv id=\u0022block-bartik-local-tasks\u0022 class=\u0022contextual-region block block-core block-local-tasks-block\u0022\u003E\n  \n    \u003Cdiv data-contextual-id=\u0022block:block=bartik_local_tasks:langcode=en\u0022\u003E\u003C\/div\u003E\n        \u003Cnav class=\u0022tabs\u0022 role=\u0022navigation\u0022 aria-label=\u0022Tabs\u0022\u003E\n        \u003Ch2 class=\u0022visually-hidden\u0022\u003EPrimary tabs\u003C\/h2\u003E\n  \u003Cul class=\u0022tabs primary\u0022\u003E\u003Cli class=\u0022is-active\u0022\u003E\u003Ca href=\u0022\/qanda\/question\/2\u0022 data-drupal-link-system-path=\u0022node\/2\u0022\u003EView\u003Cspan class=\u0022visually-hidden\u0022\u003E(active tab)\u003C\/span\u003E\u003C\/a\u003E\u003C\/li\u003E\n\u003Cli\u003E\u003Ca href=\u0022\/node\/2\/edit\u0022 data-drupal-link-system-path=\u0022node\/2\/edit\u0022\u003EEdit\u003C\/a\u003E\u003C\/li\u003E\n\u003Cli\u003E\u003Ca href=\u0022\/node\/2\/delete\u0022 data-drupal-link-system-path=\u0022node\/2\/delete\u0022\u003EDelete\u003C\/a\u003E\u003C\/li\u003E\n\u003C\/ul\u003E\n\n    \u003C\/nav\u003E\n  \u003C\/div\u003E\n","settings":null}]</script>    <script type="application/json" data-big-pipe-placeholder="callback=comment.lazy_builders%3ArenderForm&amp;args[0]=node&amp;args[1]=2&amp;args[2]=field_question_comments&amp;args[3]=comment&amp;token=6313718a" data-drupal-ajax-processor="big_pipe">
    [{"command":"settings","settings":{"ajaxPageState":{"theme":"bartik","libraries":"ajax_comments\/commands,ajax_comments\/commands,bartik\/global-styling,big_pipe\/big_pipe,ckeditor\/drupal.ckeditor,classy\/base,classy\/messages,comment\/drupal.comment-by-viewer,comment\/drupal.comment-new-indicator,contextual\/drupal.contextual-links,contextual\/drupal.contextual-toolbar,core\/drupal.active-link,core\/html5shiv,core\/jquery.form,core\/normalize,filter\/drupal.filter,history\/mark-as-read,shortcut\/drupal.shortcut,statistics\/drupal.statistics,system\/base,toolbar\/toolbar,toolbar\/toolbar.escapeAdmin,tour\/tour,user\/drupal.user.icons"},"ajaxTrustedUrl":{"\/comment\/reply\/node\/2\/field_question_comments":true,"\/ajax_comments\/reply\/node\/2\/field_question_comments\/0":true},"ajax":{"edit-ajax-comments-reply-form-node-2-field-question-comments-0-0":{"url":"\/ajax_comments\/reply\/node\/2\/field_question_comments\/0","wrapper":".ajax-comments-wrapper","method":"replaceWith","effect":"fade","event":"mousedown","keypress":true,"prevent":"click","dialogType":"ajax","submit":{"_triggering_element_name":"op","_triggering_element_value":"Save"}}},"editor":{"formats":{"links_only":{"format":"links_only","editor":"ckeditor","editorSettings":{"allowedContent":{"*":{"attributes":"lang,dir","styles":false,"classes":false},"a":{"attributes":"href,hreflang","styles":false,"classes":false}},"contentsCss":["\/core\/modules\/ckeditor\/css\/ckeditor-iframe.css","\/core\/modules\/system\/css\/components\/align.module.css","\/core\/themes\/bartik\/css\/base\/elements.css","\/core\/themes\/bartik\/css\/components\/captions.css","\/core\/themes\/bartik\/css\/components\/table.css","\/core\/themes\/bartik\/css\/components\/text-formatted.css"],"customConfig":"","disallowedContent":{"*":{"attributes":"on*"}},"drupalExternalPlugins":{"drupallink":"\/core\/modules\/ckeditor\/js\/plugins\/drupallink\/plugin.js"},"drupalLink_dialogTitleAdd":"Add Link","drupalLink_dialogTitleEdit":"Edit Link","entities":false,"extraPlugins":"drupallink","justifyClasses":["text-align-left","text-align-center","text-align-right","text-align-justify"],"language":"en","pasteFromWordPromptCleanup":true,"resize_dir":"vertical","stylesSet":false,"toolbar":[{"name":"Links","items":["DrupalLink","-","DrupalUnlink"]},"\/"]},"editorSupportsContentFiltering":true,"isXssSafe":false}}},"pluralDelimiter":"\u0003","user":{"uid":"1","permissionsHash":"50f490420ed4c54558b56e853ec07d868d9317d8e1f2e7b76962c15f61956d44"}},"merge":true},{"command":"add_css","data":"\u003Clink rel=\u0022stylesheet\u0022 href=\u0022\/core\/assets\/vendor\/jquery.ui\/themes\/base\/button.css?o4m2v0\u0022 media=\u0022all\u0022 \/\u003E\n\u003Clink rel=\u0022stylesheet\u0022 href=\u0022\/core\/assets\/vendor\/jquery.ui\/themes\/base\/resizable.css?o4m2v0\u0022 media=\u0022all\u0022 \/\u003E\n\u003Clink rel=\u0022stylesheet\u0022 href=\u0022\/core\/assets\/vendor\/jquery.ui\/themes\/base\/dialog.css?o4m2v0\u0022 media=\u0022all\u0022 \/\u003E\n\u003Clink rel=\u0022stylesheet\u0022 href=\u0022\/core\/themes\/stable\/css\/ckeditor\/ckeditor.css?o4m2v0\u0022 media=\u0022all\u0022 \/\u003E\n\u003Clink rel=\u0022stylesheet\u0022 href=\u0022\/core\/themes\/stable\/css\/filter\/filter.admin.css?o4m2v0\u0022 media=\u0022all\u0022 \/\u003E\n\u003Clink rel=\u0022stylesheet\u0022 href=\u0022\/core\/themes\/classy\/css\/components\/dialog.css?o4m2v0\u0022 media=\u0022all\u0022 \/\u003E\n"},{"command":"insert","method":"append","selector":"body","data":"\u003Cscript src=\u0022\/core\/assets\/vendor\/jquery.ui\/ui\/widget-min.js?v=1.11.4\u0022\u003E\u003C\/script\u003E\n\u003Cscript src=\u0022\/core\/assets\/vendor\/jquery-form\/jquery.form.min.js?v=3.51\u0022\u003E\u003C\/script\u003E\n\u003Cscript src=\u0022\/core\/modules\/filter\/filter.js?v=8.0.5\u0022\u003E\u003C\/script\u003E\n\u003Cscript src=\u0022\/core\/assets\/vendor\/jquery.ui\/ui\/button-min.js?v=1.11.4\u0022\u003E\u003C\/script\u003E\n\u003Cscript src=\u0022\/core\/assets\/vendor\/jquery.ui\/ui\/mouse-min.js?v=1.11.4\u0022\u003E\u003C\/script\u003E\n\u003Cscript src=\u0022\/core\/assets\/vendor\/jquery.ui\/ui\/draggable-min.js?v=1.11.4\u0022\u003E\u003C\/script\u003E\n\u003Cscript src=\u0022\/core\/assets\/vendor\/jquery.ui\/ui\/position-min.js?v=1.11.4\u0022\u003E\u003C\/script\u003E\n\u003Cscript src=\u0022\/core\/assets\/vendor\/jquery.ui\/ui\/resizable-min.js?v=1.11.4\u0022\u003E\u003C\/script\u003E\n\u003Cscript src=\u0022\/core\/assets\/vendor\/jquery.ui\/ui\/dialog-min.js?v=1.11.4\u0022\u003E\u003C\/script\u003E\n\u003Cscript src=\u0022\/core\/misc\/dialog\/dialog.js?v=8.0.5\u0022\u003E\u003C\/script\u003E\n\u003Cscript src=\u0022\/core\/misc\/dialog\/dialog.position.js?v=8.0.5\u0022\u003E\u003C\/script\u003E\n\u003Cscript src=\u0022\/core\/misc\/dialog\/dialog.jquery-ui.js?v=8.0.5\u0022\u003E\u003C\/script\u003E\n\u003Cscript src=\u0022\/core\/modules\/editor\/js\/editor.js?v=8.0.5\u0022\u003E\u003C\/script\u003E\n\u003Cscript src=\u0022\/core\/assets\/vendor\/ckeditor\/ckeditor.js?v=4.5.5\u0022\u003E\u003C\/script\u003E\n\u003Cscript src=\u0022\/core\/modules\/ckeditor\/js\/ckeditor.js?v=8.0.5\u0022\u003E\u003C\/script\u003E\n","settings":null},{"command":"insert","method":"replaceWith","selector":"[data-big-pipe-selector=\u0022callback=comment.lazy_builders%3ArenderForm\u0026args[0]=node\u0026args[1]=2\u0026args[2]=field_question_comments\u0026args[3]=comment\u0026token=6313718a\u0022]","data":"\u003Cform class=\u0022comment-comment-form comment-form ajax-comments-reply-form-node-2-field_question_comments-0-0 ajax-comments-form-add\u0022 id=\u0022ajax-comments-reply-form-node-2-field-question-comments-0-0\u0022 data-drupal-selector=\u0022comment-form\u0022 action=\u0022\/comment\/reply\/node\/2\/field_question_comments\u0022 method=\u0022post\u0022 accept-charset=\u0022UTF-8\u0022\u003E\n  \u003Cinput data-drupal-selector=\u0022form-nvvpaonymtye-9r0lpvyrd0nfz0uwjiohyu7kqrdrvc\u0022 type=\u0022hidden\u0022 name=\u0022form_build_id\u0022 value=\u0022form-NvvpAOnYMTYE-9r0lpVyRD0nfZ0UwjIOHYu7kqrdRvc\u0022 \/\u003E\n\u003Cinput data-drupal-selector=\u0022edit-comment-comment-form-form-token\u0022 type=\u0022hidden\u0022 name=\u0022form_token\u0022 value=\u00221PB7abbCZbeRIzubQ8qx8qrWw5J_FsRs8dykDr4WVp4\u0022 \/\u003E\n\u003Cinput data-drupal-selector=\u0022edit-comment-comment-form\u0022 type=\u0022hidden\u0022 name=\u0022form_id\u0022 value=\u0022comment_comment_form\u0022 \/\u003E\n\u003Cinput data-drupal-selector=\u0022edit-html-id\u0022 type=\u0022hidden\u0022 name=\u0022html_id\u0022 value=\u0022ajax-comments-reply-form-node-2-field-question-comments-0-0\u0022 \/\u003E\n\u003Cdiv class=\u0022field--type-text-long field--name-comment-body field--widget-text-textarea js-form-wrapper form-wrapper\u0022 data-drupal-selector=\u0022edit-comment-body-wrapper\u0022 id=\u0022edit-comment-body-wrapper\u0022\u003E      \u003Cdiv class=\u0022js-text-format-wrapper text-format-wrapper js-form-item form-item\u0022\u003E\n  \u003Cdiv class=\u0022js-form-item form-item js-form-type-textarea form-type-textarea js-form-item-comment-body-0-value form-item-comment-body-0-value form-no-label\u0022\u003E\n        \u003Cdiv class=\u0022form-textarea-wrapper\u0022\u003E\n  \u003Ctextarea class=\u0022js-text-full text-full form-textarea required resize-vertical\u0022 data-drupal-selector=\u0022edit-comment-body-0-value\u0022 id=\u0022edit-comment-body-0-value\u0022 name=\u0022comment_body[0][value]\u0022 rows=\u00225\u0022 cols=\u002260\u0022 placeholder=\u0022\u0022 required=\u0022required\u0022 aria-required=\u0022true\u0022\u003E\u003C\/textarea\u003E\n\u003C\/div\u003E\n\n        \u003C\/div\u003E\n\u003Cdiv data-drupal-selector=\u0022edit-comment-body-0-format\u0022 id=\u0022edit-comment-body-0-format\u0022 class=\u0022js-form-wrapper form-wrapper\u0022\u003E\u003Cinput data-editor-for=\u0022edit-comment-body-0-value\u0022 type=\u0022hidden\u0022 name=\u0022comment_body[0][format]\u0022 value=\u0022links_only\u0022 \/\u003E\n\u003C\/div\u003E\n\n  \u003C\/div\u003E\n\n  \u003C\/div\u003E\n\u003Cdiv class=\u0022field--type-language field--name-langcode field--widget-language-select js-form-wrapper form-wrapper\u0022 data-drupal-selector=\u0022edit-langcode-wrapper\u0022 id=\u0022edit-langcode-wrapper\u0022\u003E      \n  \u003C\/div\u003E\n\u003Cdiv data-drupal-selector=\u0022edit-actions\u0022 class=\u0022form-actions js-form-wrapper form-wrapper\u0022 id=\u0022edit-actions\u0022\u003E\u003Cinput data-drupal-selector=\u0022edit-ajax-comments-reply-form-node-2-field-question-comments-0-0\u0022 type=\u0022submit\u0022 id=\u0022edit-ajax-comments-reply-form-node-2-field-question-comments-0-0\u0022 name=\u0022op\u0022 value=\u0022Save\u0022 class=\u0022button button--primary js-form-submit form-submit\u0022 \/\u003E\n\u003C\/div\u003E\n\n\u003C\/form\u003E\n","settings":null}]</script>    <script type="application/json" data-big-pipe-placeholder="callback=history_attach_timestamp&amp;args[0]=2&amp;token=15cf9f98" data-drupal-ajax-processor="big_pipe">
    [{"command":"settings","settings":{"ajaxPageState":{"theme":"bartik","libraries":"ajax_comments\/commands,ajax_comments\/commands,bartik\/global-styling,big_pipe\/big_pipe,ckeditor\/drupal.ckeditor,classy\/base,classy\/messages,comment\/drupal.comment-by-viewer,comment\/drupal.comment-new-indicator,contextual\/drupal.contextual-links,contextual\/drupal.contextual-toolbar,core\/drupal.active-link,core\/html5shiv,core\/jquery.form,core\/normalize,filter\/drupal.filter,history\/mark-as-read,shortcut\/drupal.shortcut,statistics\/drupal.statistics,system\/base,toolbar\/toolbar,toolbar\/toolbar.escapeAdmin,tour\/tour,user\/drupal.user.icons"},"history":{"lastReadTimestamps":{"2":1458959751}},"pluralDelimiter":"\u0003","user":{"uid":"1","permissionsHash":"50f490420ed4c54558b56e853ec07d868d9317d8e1f2e7b76962c15f61956d44"}},"merge":true},{"command":"insert","method":"replaceWith","selector":"[data-big-pipe-selector=\u0022callback=history_attach_timestamp\u0026args[0]=2\u0026token=15cf9f98\u0022]","data":"","settings":null}]</script>    <script type="application/json" data-big-pipe-placeholder="callback=comment.lazy_builders%3ArenderLinks&amp;args[0]=12&amp;args[1]=full&amp;args[2]=en&amp;args[3]=&amp;token=2231368d" data-drupal-ajax-processor="big_pipe">
    [{"command":"insert","method":"replaceWith","selector":"[data-big-pipe-selector=\u0022callback=comment.lazy_builders%3ArenderLinks\u0026args[0]=12\u0026args[1]=full\u0026args[2]=en\u0026args[3]=\u0026token=2231368d\u0022]","data":"\u003Cul class=\u0022links inline\u0022\u003E\u003Cli class=\u0022comment-delete\u0022\u003E\u003Ca href=\u0022\/comment\/12\/delete\u0022 class=\u0022use-ajax-comments ajax-comments-delete ajax-comments-delete-12\u0022 hreflang=\u0022en\u0022\u003EDelete\u003C\/a\u003E\u003C\/li\u003E\u003Cli class=\u0022comment-edit\u0022\u003E\u003Ca href=\u0022\/comment\/12\/edit\u0022 class=\u0022use-ajax-comments ajax-comments-edit ajax-comments-edit-12\u0022 hreflang=\u0022en\u0022\u003EEdit\u003C\/a\u003E\u003C\/li\u003E\u003Cli class=\u0022comment-reply\u0022\u003E\u003Ca href=\u0022\/comment\/reply\/node\/2\/field_question_comments\/12\u0022 class=\u0022use-ajax-comments ajax-comments-reply ajax-comments-reply-2-field_question_comments-12\u0022\u003EReply\u003C\/a\u003E\u003C\/li\u003E\u003C\/ul\u003E","settings":null}]</script>    <script type="application/json" data-big-pipe-placeholder="callback=history_attach_timestamp&amp;args[0]=2&amp;token=15cf9f98" data-drupal-ajax-processor="big_pipe">
    [{"command":"settings","settings":{"ajaxPageState":{"theme":"bartik","libraries":"ajax_comments\/commands,ajax_comments\/commands,bartik\/global-styling,big_pipe\/big_pipe,ckeditor\/drupal.ckeditor,classy\/base,classy\/messages,comment\/drupal.comment-by-viewer,comment\/drupal.comment-new-indicator,contextual\/drupal.contextual-links,contextual\/drupal.contextual-toolbar,core\/drupal.active-link,core\/html5shiv,core\/jquery.form,core\/normalize,filter\/drupal.filter,history\/mark-as-read,shortcut\/drupal.shortcut,statistics\/drupal.statistics,system\/base,toolbar\/toolbar,toolbar\/toolbar.escapeAdmin,tour\/tour,user\/drupal.user.icons"},"history":{"lastReadTimestamps":{"2":1458959751}},"pluralDelimiter":"\u0003","user":{"uid":"1","permissionsHash":"50f490420ed4c54558b56e853ec07d868d9317d8e1f2e7b76962c15f61956d44"}},"merge":true},{"command":"insert","method":"replaceWith","selector":"[data-big-pipe-selector=\u0022callback=history_attach_timestamp\u0026args[0]=2\u0026token=15cf9f98\u0022]","data":"","settings":null}]</script>    <script type="application/json" data-big-pipe-placeholder="callback=comment.lazy_builders%3ArenderLinks&amp;args[0]=96&amp;args[1]=full&amp;args[2]=en&amp;args[3]=&amp;token=9e4892ed" data-drupal-ajax-processor="big_pipe">
    [{"command":"insert","method":"replaceWith","selector":"[data-big-pipe-selector=\u0022callback=comment.lazy_builders%3ArenderLinks\u0026args[0]=96\u0026args[1]=full\u0026args[2]=en\u0026args[3]=\u0026token=9e4892ed\u0022]","data":"\u003Cul class=\u0022links inline\u0022\u003E\u003Cli class=\u0022comment-delete\u0022\u003E\u003Ca href=\u0022\/comment\/96\/delete\u0022 class=\u0022use-ajax-comments ajax-comments-delete ajax-comments-delete-96\u0022 hreflang=\u0022en\u0022\u003EDelete\u003C\/a\u003E\u003C\/li\u003E\u003Cli class=\u0022comment-edit\u0022\u003E\u003Ca href=\u0022\/comment\/96\/edit\u0022 class=\u0022use-ajax-comments ajax-comments-edit ajax-comments-edit-96\u0022 hreflang=\u0022en\u0022\u003EEdit\u003C\/a\u003E\u003C\/li\u003E\u003Cli class=\u0022comment-reply\u0022\u003E\u003Ca href=\u0022\/comment\/reply\/node\/2\/field_question_comments\/96\u0022 class=\u0022use-ajax-comments ajax-comments-reply ajax-comments-reply-2-field_question_comments-96\u0022\u003EReply\u003C\/a\u003E\u003C\/li\u003E\u003C\/ul\u003E","settings":null}]</script><script type="application/json" data-big-pipe-event="stop"></script>

As the above code sample demonstrates, the script tags with the identifier data-big-pipe-placeholder="callback=history_attach_timestamp&amp;args[0]=2&amp;token=15cf9f98" appear after the one with the identifier data-big-pipe-placeholder="callback=comment.lazy_builders%3ArenderForm&amp;args[0]=node&amp;args[1]=2&amp;args[2]=field_question_comments&amp;args[3]=comment&amp;token=6313718a", and as a result the code in the big_pipe.js file evaluates the script tags with callback=history_attach_timestamp after the script tag containing the JSON for the comment form placeholder. This logic appears in the following code excerpt from bigPipeProcessDocument() in big_pipe.js:

    $(context).find('script[data-big-pipe-replacement-for-placeholder-with-id]')
      .once('big-pipe')
      .each(bigPipeProcessPlaceholderReplacement);

When a given node has more than one comment (the above example has two, which is why there are two tags with data-big-pipe-placeholder="callback=history_attach_timestamp&amp;args[0]=2&amp;token=15cf9f98"), the comment module generates identical #lazy_builder callbacks to history_attach_timestamp for all of them, which big_pipe in turn uses to generate identical placeholders. The identical placeholders become an issue when the bigPipeProcessPlaceholderReplacement() function simulates an ajax success response using the identical script tags. The success() method in the ajax system invokes the simulated command defined in the JSON content of the script tags, which uses the replaceWith method. This triggers invocation of Drupal.AjaxCommands.prototype.insert() command, which detaches behaviors attached to any DOM elements in the context of the placeholder:

Drupal.detachBehaviors(wrapper.get(0), settings);

The first time this executes on a placeholder generated for the #lazy_builder callback for history_attach_timestamp, the value of wrapper.get(0) is <div data-big-pipe-placeholder-id="callback=history_attach_timestamp&amp;args[0]=2&amp;token=15cf9f98"></div>. However, a few lines below that, the jQuery replaceWith method is triggered:

      // Add the new content to the page.
      wrapper[method](new_content);

After this line executes, the DOM node <div data-big-pipe-placeholder-id="callback=history_attach_timestamp&amp;args[0]=2&amp;token=15cf9f98"></div> is replaced with an empty div (<div></div>), because the value of response.data in the simulated ajax response is an empty string. The problem is that the next time this code executes on an identical placeholder from the script tags at the bottom of the document body, all instances of these placeholder divs in the DOM have been replaced with empty divs. The value for the wrapper variable is now an empty object, because the selector in response.selector refers to DOM nodes that have been removed:

// The value of response.selector is [data-big-pipe-placeholder-id="callback=history_attach_timestamp&args[0]=2&token=15cf9f98"]
var wrapper = response.selector ? $(response.selector) : $(ajax.wrapper);

Then, a few lines down, when Drupal.detachBehaviors() runs, the value of wrapper.get(0) evaluates to undefined:

Drupal.detachBehaviors(wrapper.get(0), settings);

Drupal.detachBehaviors() sets the context in which it operates to the entire document if the context is undefined; see the first line of the function:

  Drupal.detachBehaviors = function (context, settings, trigger) {
    context = context || document;
    settings = settings || drupalSettings;
    trigger = trigger || 'unload';
    var behaviors = Drupal.behaviors;
    // Execute all of them.
    for (var i in behaviors) {
      if (behaviors.hasOwnProperty(i) && typeof behaviors[i].detach === 'function') {
        // Don't stop the execution of behaviors in case of an error.
        try {
          behaviors[i].detach(context, settings, trigger);
        }
        catch (e) {
          Drupal.throwError(e);
        }
      }
    }
  };

The result is that behaviors are detached from the entire document, causing behaviors that were attached earlier in the execution process to be removed.

Proposed resolution

Proposed solution is to modify \Drupal\comment\CommentViewBuilder::buildComponents() to prevent duplicate copies of the placeholder from being generated. The #lazy_builder callback in the render array that causes Big Pipe to generate the placeholder seems to have one purpose: to add the timestamp for the comments' parent node to the drupalSettings object.

The #lazy_builder for the history_attach_timestamp in the comment view builder is:

        // Embed the metadata for the comment "new" indicators on this node.
        $build[$id]['history'] = ['#lazy_builder' => ['history_attach_timestamp', [$commented_entity->id()]],'#create_placeholder' => TRUE,
        ];

The callback function for history_attach_timestamp() is:

function history_attach_timestamp($node_id) {
  $element = [];
  $element['#attached']['drupalSettings']['history']['lastReadTimestamps'][$node_id] = (int) history_read($node_id);
  return $element;
}

The history_attach_timestamp() callback function always returns a render array that is empty, except for the settings being added to drupalSettings. Since the settings are per node ID and are the same for all comments attached to the same node, subsequent invocations of this callback function merely result in this property of the drupalSettings object being overwritten with the same value.

 

Proposed code change is to set this #lazy_builder only once for the entire comment list:

diff --git a/core/modules/comment/src/CommentViewBuilder.php b/core/modules/comment/src/CommentViewBuilder.php
index 9b47b7c..435bae5 100644
--- a/core/modules/comment/src/CommentViewBuilder.php
+++ b/core/modules/comment/src/CommentViewBuilder.php
@@ -148,18 +148,18 @@ public function buildComponents(array &$build, array $entities, array $displays,
       $build[$id]['#attached']['library'][] = 'comment/drupal.comment-by-viewer';
       if ($this->moduleHandler->moduleExists('history') && $this->currentUser->isAuthenticated()) {
         $build[$id]['#attached']['library'][] = 'comment/drupal.comment-new-indicator';
-
-        // Embed the metadata for the comment "new" indicators on this node.
-        $build[$id]['history'] = [
-          '#lazy_builder' => ['history_attach_timestamp', [$commented_entity->id()]],
-          '#create_placeholder' => TRUE,
-        ];
       }
     }
     if ($build[$id]['#comment_threaded']) {
       // The final comment must close up some hanging divs.
       $build[$id]['#comment_indent_final'] = $current_indent;
     }
+
+    // Embed the metadata for the comment "new" indicators on this node.
+    $build['history'] = [
+      '#lazy_builder' => ['history_attach_timestamp', [$commented_entity->id()]],
+      '#create_placeholder' => TRUE,
+    ];
   }

   /**

Patch file attached.

Remaining tasks

Patch needs review.

User interface changes

None.

API changes

None.

Data model changes

None.

Add authentication support for Views

$
0
0

Problem/Motivation

Currently, the only way to add authentication to a REST View is through RouteSubscriberBase->alterRoutes().

We could add the Authentication setting to REST Views so users could select the supported authentication methods for a particular Views display. It would look like the following screenshot:

views authentication

The above view lists unpublished content in JSON format. Authentication has been set to Basic Auth, so requests to http://mysite.com/unpublished-content will require HTTP Basic authentication headers provided with a valid username and password. Note that Access has been set to Authenticated User role, since the default access requirement is "Access content", which is part of the Anonymous role. Alternatively, we could also set a permission that belongs to the Authenticated User role. I am not sure about how to make this more obvious to the site builder.

How to test

  1. Install Drupal and enable Rest, Hal, Basic Auth
  2. Add a Rest export display on /node
  3. Generate some frontpage nodes
  4. curl --request GET http://drupal.d8/node?_format=hal_json
  5. curl --request GET http://admin:admin@drupal.d8/node?_format=hal_json gives access denied
  6. Apply the patch
  7. Set basic auth as Authentication methods for the Rest Export display
  8. curl --request GET http://admin:admin@drupal.d8/node?_format=hal_json gives result.

Proposed resolution

Remaining tasks

Revert AuthenticationManager ::getSortedProviders to private once #2490228: Add Authentication Collector lands.

User interface changes

API changes

Warn users of php 5.5

$
0
0

Problem/Motivation

PHP 5.5 will be quite soon out of security support, see https://secure.php.net/supported-versions.php

Proposed resolution

Warn users of php 5.5, so we can remove support for it in a later release.

Remaining tasks

User interface changes

API changes

Data model changes


Drupal 6 term references not migrated

$
0
0

As of now, all major migration regarding the content i,e the content type and the respective nodes are being imported from Drupal 6 to Drupal 8. Also, all the taxonomies available in the Drupal 6 instance are ported successfully to Drupal 8 instance.
However, after a successful upgrade, when the content is analysed the Taxonomy term reference that a node holds in Drupal 6 instance is no more maintained in the Drupal 8 instance.

Add test coverage for Views revision link handlers

EntityResolverManager::setParametersFromEntityInformation() sets parameter info for non-existing parameters

$
0
0

Problem/Motivation

\Drupal\Core\Entity\EntityResolverManager::setParametersFromEntityInformation() sets parameter information by extracting the entity type from _entity_view and _entity_form without checking whether a corresponding slug exists in the path. For add forms in particular - which, naturally, do not contain an entity type slug in their path - this results in an incorrect route parameter being added.

Besides being technically incorrect, this causes problems in #2723579: [PP-3] (Node|User)RouteProvider should extend DefaultHtmlRouteProvider where we are changing the node.add route to use the _entity_form pattern. The unnecessary node parameter causes \Drupal\node\ContextProvider\NodeRouteContext::getRuntimeContexts() to fail on the node add route. Concretely, it causes blocks to be configured to show only for a specific node type not show on the add form for that node type - with the patch from that issue applied.

Proposed resolution

A: Special-case the add operation of _entity_form and simply bail out for add forms.
B: Compile the passed-in route and check whether any path variables match the entity type ID that was found.

Remaining tasks

  1. Choose A or B
  2. Write patch

User interface changes

None.

API changes

None. It's theoretically possible for someone to rely on these pointless route parameters, but they really are pointless, so I cannot fathom any possible use-case not even a very contrived one.

Data model changes

None.

Activate current vertical tab from URL fragment

$
0
0

It would be great if direct links to a vertical tab fieldgroup were possible. At the moment a link to www.example.com/node/11/edit#group_fieldgroup_name brings you to the edit form but the default vertical tab (tab 1) is always selected. The desired behavior is that the edit form would open with the specified vertical tab selected.

Note: This functionality currently exists in the D6 Vertical Tabs module (see http://drupal.org/node/376293)

Fatal error in Book navigation block for unpublished parent book item

$
0
0

To reproduce (with uid=1)
- install drupal 8.1.2 (or 8.1.x-dev, or 8.2.x-dev)
- enable Book module
- place "Book navigation" block to "Sidebar first" region
- set "Show block only on book pages" on block configuration interface
- create an Article and add it as a book (on "Book Outline" fieldgroup select "Create a new book")
- save as published - it is OK
- edit created article and unpublish it (save as unpublished)
- you will got an 500 error, with message:
Recoverable fatal error: Argument 1 passed to Drupal\book\BookManager::bookTreeOutput() must be of the type array, null given, called in .../core/modules/book/src/Plugin/Block/BookNavigationBlock.php on line 168 and defined in Drupal\book\BookManager->bookTreeOutput() (line 501 of .../core/modules/book/src/BookManager.php)

So if you have "Show block only on book pages" with unpublished parent book item, you get this fatal error and you have to disable book navigation block to view/edit this node.

Viewing all 295812 articles
Browse latest View live


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