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

Missing space between sentences on the Custom Block page

$
0
0

Problem/Motivation

On a fresh install of Drupal, when no custom blocks have been added, the "no results" text on the Custom Block Library page (/admin/structure/block/block-content) reads

There are no custom blocks available.Add a custom block.

There is no space between the two sentences.

Proposed resolution

The Custom Block Library page is created by a view, defined by core/modules/block_content/config/optional/views.view.block_content.yml. That view defines two "no results" items. The first is a text area, and the second uses the views plugin defined at core/modules/block_content/src/Plugin/views/area/ListingEmpty.php. The source of the problem is that these two pieces are pasted together with no space in between.

There are a few possible solutions:

  1. Add a space to the end of the text area.
  2. Add a third "no results" item in between the existing two, with just a space.
  3. Remove the first item and add the text, with a space, to the views plugin.
  4. Add a space at the beginning of the views plugin.

I suppose that neither of the last two options is viable, since it is possible that some sites will have views that use the views plugin.

The first solution is the easiest. Let's start there and see if anyone complains about it.

Do we need an update function? I am willing to skip that, since it will only matter on existing sites that do not have any custom blocks, where someone bothers to look at this page. I am sure there will be some such sites, but not enough that I care about it.

Workarounds

A site owner can edit the view at /admin/structure/views/view/block_content and add a space to the first item under "No results behavior". This should work with or without the patch.

The same thing can be done using the configuration system: see Comment #3.

Remaining tasks

User interface changes

This will change the interface text on /admin/structure/block/block-content.

API changes

None

Data model changes

None


IE11 & Chrome(PointerEvents enabled) & some Firefox scroll to the top of the page after dragging the bottom item with jquery 1.5 <-> 1.11

$
0
0

Please credit `svenryen, nattie, joseph.olstad, mforbes, bwaindwain` from #2908543: Tabledrag is broken when you've scrolled down on the page in chrome 61

Problem/Motivation

After two recent commits, the drag and drop behavior is bugged in IE11: when dragging the bottom item, the page is scrolled to the top of the page.

Behavior before (7.50):

Current behavior (7.53):

The related commits are:
- #1261002: Draggable tables do not work on touch screen devices
- #2821441: Newer Chrome versions and IE11/Edge cannot drag and drop anymore on desktop after 7.51 update when jQuery is updated to 1.7-1.11.0

Proposed resolution

Return the drag and drop behavior in IE11 to the state of Drupal <7.51

Remaining tasks

  1. Write a patch
  2. Review
  3. Commit

User interface changes

The drag and drop behavior in IE11 is unchanged compared to Drupal <7.51

API changes

None

Data model changes

Update symfony/* and twig/twig

imperfect breadcrumb when editing taxonomy terms

$
0
0

Hello,
I have the "Categories" vocabulary.
When editing this vocabulary I get this breadcramb

Home > Administration > Structure > Taxonomy > Edit Categories

And when I try to edit the "Laptops" term, I get this breadcrumb.

Home > Laptops

So, How could the user go back to the Categories edit page!

I hope it fixed to be like this:

Home > Administration > Structure > Taxonomy > Categories > Edit Laptops

Thanks!

Error when creating a view of content revisions of a specific content type

$
0
0

Brand new installation off of Pantheon of D8.

Create a view with the following:

View Settings:

  • Show: Content revisions
  • of type: article
  • sorted by: unsorted

Hit Save and edit button. Site fails with the following notice first:

Notice: Undefined index: type in Drupal\views\Plugin\views\wizard\WizardPluginBase->defaultDisplayFiltersUser() (line 944 of ......\core\modules\views\src\Plugin\views\wizard\WizardPluginBase.php)

Then the exception:
Drupal\Component\Plugin\Exception\PluginNotFoundException: The "" plugin does not exist. in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 52 of.....\core\lib\Drupal\Component\Plugin\Discovery\DiscoveryTrait.php).

If you remove the "Of type:" filter, the view gets created, but you're unable to add a filter for the type of content to show revisions for.

Convert JavascriptTestBase Tests to use DrupalSelenium2Driver

$
0
0

Now that #2775653: JavascriptTests with webDriver is in both 8.5.x and 8.6.x we should convert all the existing phantomjs tests over to using seleniumdriver.

This can save a significant amount of testing costs as we'll be able to parallelize the tests instead of running them serially, as well as eventually drop support for phantomjs in drupalCI, since phantom is now abandonware.

Tasks:
- Add a new TestBaseClass that uses Webdriver
- Deprecate the old PhantomJS classes
- Convert the tests that can be converted safely
- Open followups for the tests that need work to be converted (see #13 for the different categories)
- Add a change record to indicate PhantomJS tests are now deprecated

Notices/warnings from attempted exploitation of SA-CORE-2018-002 and SA-CORE-2018-004

$
0
0

For weeks, tons of notices/warnings like the following in the Drupal watchdog:

 472306  25/May 11:29  php       notice    Notice: Undefined index: #prefix in file_ajax_upload() (line 287 of /var/www/html/modules/file/file.module).                                  
 472305  25/May 11:29  php       notice    Notice: Undefined index: #suffix in file_ajax_upload() (line 284 of /var/www/html/modules/file/file.module).                                  
 472304  25/May 11:29  php       warning   Warning: trim() expects parameter 1 to be string, array given in user_pass_validate() (line 69 of /var/www/html/modules/user/user.pages.inc). 
 472303  25/May 11:29  php       warning   Warning: mb_strlen() expects parameter 1 to be string, array given in drupal_strlen() (line 482 of /var/www/html/includes/unicode.inc).       
 472302  25/May 09:33  php       warning   Warning: trim() expects parameter 1 to be string, array given in user_pass_validate() (line 69 of /var/www/html/modules/user/user.pages.inc). 
 472301  25/May 09:33  php       warning   Warning: mb_strlen() expects parameter 1 to be string, array given in drupal_strlen() (line 482 of /var/www/html/includes/unicode.inc).       
 472300  25/May 09:08  php       notice    Notice: Undefined index: #prefix in file_ajax_upload() (line 287 of /var/www/html/modules/file/file.module).                                  
 472299  25/May 09:08  php       notice    Notice: Undefined index: #suffix in file_ajax_upload() (line 284 of /var/www/html/modules/file/file.module).                                  
 472298  25/May 09:08  php       warning   Warning: trim() expects parameter 1 to be string, array given in user_pass_validate() (line 69 of /var/www/html/modules/user/user.pages.inc).

Looking at the requests from the web server logs, these entries look to be due to attempts to exploit SA-CORE-2018-002 and SA-CORE-2018-004. The fixes for those vulnerabilities should handle things more gracefully and not give notices/warnings, right?

All these notices/warnings for normal operation are masking notices/warnings the administrator may want to observe.

Drush site-install command doesn't work when settings.php is present


Create nightwatch command to install modules

$
0
0

Problem/Motivation

To write test we are going to need different modules enabled.
You might want to test what happens before and after a certain module is installed.

Proposed resolution

Create a command to install modules.

If we could do this via PHP not via the UI then it would speed up test a lot. Every test is going to need to enable modules.

Remaining tasks

do it.

User interface changes

API changes

Data model changes

Make service for field discovery for use in migrate entity derivers

$
0
0

Problem/Motivation

In contrib (and even in core itself), there is a lot of boilerplate repeated when a migrate deriver wants to add fields to an source migrate deriver. Let's make the code for discovering and adding fields generic and make a re-usable trait.

Paragraphs and Commerce would use this. Node, user and taxonomy term in core could also.

Proposed resolution

Take a look at node source deriver, make a trait and then implement it for node, user and taxonomy.

Remaining tasks

  1. Code it
  2. Run existing tests
  3. Commit it

User interface changes

API changes

Data model changes

Migrate support for deleting items no longer in the incoming data

$
0
0

Problem/Motivation

We would like to add support for deleting items that are no longer present in the incoming data when a migration is run. This was a feature of Feeds in D7 and seems like a common need.

Proposed resolution

From @mikeryan in #15:

I really think this should be a distinct "purge" operation that gathers the currently-available source IDs from the source plugin, and scans the map table for any which aren't in that list to invoke the destination rollback on them. Now that I think about it, maybe it could even be an option on rollback - drush migrate-rollback --missing-from-source my_migration.

Remaining tasks

Add tests.

User interface changes

API changes

Data model changes

Follow-up for #2910211: fix all deprecation warnings

$
0
0

Problem/Motivation

Since #2910211: Allow computed exposed properties in ComplexData to support cacheability., implicit cacheability bubbling is deprecated, because there now finally is a way for normalizers to bubble cacheability metadata of the data they're normalizing.

As of #2870194: Ensure that process-isolated tests can use Symfony's PHPunit bridge to catch usages of deprecated code, deprecation errors result in test failures. But any deprecation errors that result in core test failures are ignored, for now.

Proposed resolution

Let's fix all deprecation errors for the deprecation that #2910211 added. This is then also fixing REST/Serialization technical debt. That deprecation is:

Implicit cacheability metadata bubbling (onto the global render context) in normalizers is deprecated since Drupal 8.5.0 and will be removed in Drupal 9.0.0. Use the "cacheability" serialization context instead, for explicit cacheability metadata bubbling. See https://www.drupal.org/node/2918937

Remaining tasks

  1. Find all the places.
  2. Fix them.

User interface changes

None.

API changes

None.

Data model changes

None.

Advanced settings in Views edit - preserve state or leave expanded?

$
0
0

Problem/Motivation

  1. Install Drupal
  2. Edit a view - e.g. /admin/structure/views/view/content
  3. 'Advanced' section ('.details-wrapper') is always collapsed/hidden on initial page load, regardless of whether advanced settings have been made, and if the user has just expanded and edited something in that section, e.g. adding a contextual links or relationship, when the modal window is closed the Advanced div is always collapsed again

Motivation:

UX/DX, timesaving, specifically:

  • I find myself wasting a lot of clicks when editing views.
  • Avoid active settings being missed because they're not immediately visible
  • Is there real reason it needs to be collapsible at all? On desktop it saves no space, you just get an empty column area, and the content is always loaded in background.
  • Are the "advanced" settings really"advanced", i.e. more complicated than those in the first two columns. I'd argue relationships, contextual filters, machine name, admin comment and CSS class perhaps aren't. e.g The first two would work well in column two, and machine name and admin comment could go in (Page|Block|..) Settings. I'm wondering if the page has grown over time and the "advanced" column has turned more into "miscellaneous"?

Proposed resolution

  • Lose disclosure triangle and always show or remember previous setting.
  • Move some items in advanced column to better locations.

Remaining tasks

Preemptively tagged for subsystem review as it'll require sign-off.

Discuss to see likelihood of approval, then work on patch.

User interface changes

Depends on outcome.

API changes

None.

Data model changes

None.

Add an EntityOwnerTrait to standardize the base field needed by EntityOwnerInterface

$
0
0

Problem/Motivation

This was raised as a review point in #2784921-135: Add Workspaces experimental module:

+++ b/core/modules/workspace/src/Entity/Workspace.php
@@ -0,0 +1,223 @@
+      ->setDefaultValueCallback('Drupal\workspace\Entity\Workspace::getCurrentUserId')
...
+  /**
+   * Default value callback for 'uid' base field definition.
+   *
+   * @see ::baseFieldDefinitions()
+   *
+   * @return int[]
+   *   An array containing the ID of the current user.
+   */
+  public static function getCurrentUserId() {
+    return [\Drupal::currentUser()->id()];
+  }

Node and Media also have this, this is the 3th occurance of this exact code + docblock in core, should we open a followup to figure out if it makes sens to move this to a common class, or a trait?

Proposed resolution

Add a EntityOwnerTrait, similar to EntityPublishedTrait.

Remaining tasks

Do it.

User interface changes

Nope.

API changes

Nope.

Data model changes

Nope.

ContextualController bug?

$
0
0

Shouldn't the protected property in \Drupal\contextual\ContextualController::$render be \Drupal\contextual\ContextualController::$renderer?

Following up on this closed issue:

I feel like I'm missing something obvious given that the patch was accepted already, but shouldn't that protected property in \Drupal\contextual\ContextualController be:

protected $renderer;

instead of:

protected $render;

?


Dispatch the PREPARE_ROW event. Deprecate prepare_row_alter hooks

$
0
0

Problem/Motivation

Split from #2488836: Refactor prepareRow() to add events in addition to hook.

Migrate Plus module is dispatching this event and this is critical to migrate runner because it allows the Drush option --idlist. But as the migrate runner goes to Drush core, and the two should run independently but also together, it's better to have the event dispatching in Drupal core.

There are also the reasons from #2488836: Refactor prepareRow() to add events in addition to hook.

Proposed resolution

Add the event constant, the event class & dispatch the PREPARE_ROW event. Deprecate hook_migrate_prepare_row_alter() and hook_migrate_MIGRATION_ID_prepare_row_alter() hooks.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

JavaScript tests shouldn't exit 0 if they fail

UpdatePathTestBase fails to pick up new modules

$
0
0

Problem/Motivation

If you have a hook_update_N() function that installs a module and changes entity definitions (for example using hook_entity_base_field_info()) then any UpdatePathTestBase tests will fail because the entity definition update check in \Drupal\FunctionalTests\Update\UpdatePathTestBase::runUpdates() will detect changes. This is because the test runner's module handler service has not been updated with the new modules. Calling \Drupal\Core\Test\FunctionalTestSetupTrait::resetAll() or \Drupal\Core\Test\FunctionalTestSetupTrait::rebuildContainer() is not enough to update the module list.

Proposed resolution

Add new modules to the test runner's module handler and then reset everything so the test running environment is up-to-date with any changes.

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Migrate Row is frosen by core, failed to customize property.

$
0
0

it's similar with
Row->setSourceProperty()

The scene:
I extend ProcessPluginBase as a ConstantMap, Plugin name is constant_map, I override a transform function in this class, code as below:

    $new_value = $value;
    if (is_array($value)) {
      if (!$value) {
        throw new MigrateException('Can not lookup without a value.');
      }
    }
    else {
      $new_value = [$value];
    }
    $new_value = NestedArray::getValue($this->configuration['map'], $new_value, $key_exists);
    if ($key_exists) {
      $row->setFreezeSource(FALSE);
      $row->setSourceProperty($this->configuration['constant'], $new_value);
      throw new MigrateSkipRowException();
    }
    else {
      return $value;
    }

I want to change source value with this $row->setSourceProperty function, but core module Migrate is frozen this action, so here, I can't change any source value, and it report a bug for this.

      $row->setSourceProperty($this->configuration['constant'], $new_value);
      throw new MigrateSkipRowException();

error message reported: The source is frozen to set and can't be changed any more.
I think it is necessary to add a method to achieve this action.

Use drupalci.yml to fail test runs early

$
0
0

Problem/Motivation

Core can now specify a drupalci.yml file to control the testbot builds

Proposed resolution

Start with a drupalci.yml file that allows us to leverage some of the new features, primarily a fail fast mechanism to stop 1 hour tests if the unit tests are known failures.

Then we can add additional commands to do things like upgrade phpunit etc.

Remaining tasks

User interface changes

API changes

Data model changes

Viewing all 292452 articles
Browse latest View live


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