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

executing migration via cron vs ui fails with 'missing dependencies'

$
0
0

When setting up a migration with dependencies, I can execute it via the UI. AFAICT it executes the dependencies first and then the main migration script may use migration lookup to grab the dependencies which I believe is correct.

e.g.

migration_dependencies:
  required:
    - twodareis2do_rss_skysports_picture

However when executing via hook_cron, using the above it will complain of missing dependencies. It seems that on occasion I can substitute required with optional, however it would seem that that this seems slightly erratic and will only seems to update sometimes.

Would it be possible to fix this so that cron migration scripts behave as they would to when executed via the UI.


Add support for third party libraries in site specific and install profile specific libraries folders

$
0
0

Problem/Motivation

Quite a few contrib modules (for example dropzonejs, Content Browser, Select2) have an optional dependency on the Libraries module. They do this do allow the library to placed in locations other than DRUPAL_ROOT/libraries/. For example, on drupal.org distributions wishing to including third party libraries have to use drush make. This places the library in the install profile directory.

Therefore you see a lot of code like:

/**
 * Implements hook_library_info_build().
 */
function dropzonejs_library_info_build() {
  $libraries = [];

  if (\Drupal::moduleHandler()->moduleExists('libraries')) {
    $exif_path = libraries_get_path('exif-js') . '/exif.js';
  }
  else {
    $exif_path = DRUPAL_ROOT . '/libraries/exif-js/exif.js';
  }

  if ($exif_found = file_exists($exif_path)) {

One major problem with this is that libraries_get_path() is deprecated and supposed to be removed in the Drupal 8 (!!!) version of the Libraries module. This has not come to pass but essentially all the modules that are doing something similar to the dropzonejs example above are only using the Libraries module for 1 reason and thats because it searches a defined set up of paths for libraries. This depends on two of its methods - libraries_get_path() and libraries_get_libraries(). Both of these are deprecated with the message:

 * @deprecated Will be removed before a stable Drupal 8 release. Please use the
 * new library load and managment concepts described at:
 * https://www.drupal.org/node/2170763

The link shows that the Libraries module doesn't really want to continue providing this type of functionality and instead was trying to be a registry and had far more expansive D8 ideas. It doesn't appear that these have borne fruit.

Proposed resolution

There's a lot of discussion about how Drupal should support modules and themes wanting to use other frontend libraries. See #2605130: Best practices for handling external libraries in Drupal 8 for instance.

This issue is not trying to solve the bigger problem.

The proposal here is to search the following paths:

  • PATH/TO/INSTALL_PROFILE/libraries
  • libraries
  • PATH/TO/SITE/libraries

when we encounter a library path like /libraries/dropzone/dist/min/dropzone.min.js. This will allow modules to drop Libraries module integration but maintain the support for third party libraries in multiple locations.

The above search locations are the same as libraries_get_libraries() apart from sites/all/libraries has been removed - and I think the last location found wins so PATH/TO/SITE/libraries> libraries> PATH/TO/INSTALL_PROFILE/libraries

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

@todo - will need CR to do document the new functionality.

Drupal 9 readiness meeting / 6 January 2020

$
0
0

Meeting will happen in #d9readiness on drupal.slack.com.

Hello and welcome to this Drupal 9 readiness meeting!

This meeting:
➤ Is for core and contributed project developers as well as people who have integrations and services related to core. Site developers who want to stay in the know to keep up-to-date for the easiest Drupal 9 upgrade of their sites are also welcome.
➤ Usually happens every other Monday at 19:00 UTC.
➤ Is done over chat.
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to: `https://www.drupal.org/project/drupal/issues/3099840`
➤*Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.

:zero: Who is here today? Comment in the thread below to introduce yourself.

:one: Do you have suggested topics you are looking to discuss? Post in this thread and we'll open threads for them as appropriate.

:two: TBD

ConfigEntityStorage::resetCache() does not call ConfigFactory::reset()

$
0
0

Problem

Given the following two script files in my web directory that I run with drush:

// In web/config-cache-test.php:
$storage = \Drupal::entityTypeManager()->getStorage('filter_format');
$ids = $storage->getQuery()->execute();
print_r($ids);

// This is important that this gets run in a separate process.
drush_invoke_process('@self', 'scr', ['config-create']);

// Attempt to reset the entity storage cache before querying again.
$storage->resetCache();

$ids = $storage->getQuery()->execute();
print_r($ids);

// In web/config-create.php:
$storage = \Drupal::entityTypeManager()->getStorage('filter_format');
$filter_format = $storage->create([
  'format' => 'test',
  'name' => 'Test',
]);
$filter_format->save();

Expected Results

➜  drush scr config-cache-test
Array
(
    [basic_html] => basic_html
    [full_html] => full_html
    [plain_text] => plain_text
    [restricted_html] => restricted_html
)
Array
(
    [basic_html] => basic_html
    [full_html] => full_html
    [plain_text] => plain_text
    [restricted_html] => restricted_html
    [test] => test
)

Actual Results

➜  drush scr config-cache-test
Array
(
    [basic_html] => basic_html
    [full_html] => full_html
    [plain_text] => plain_text
    [restricted_html] => restricted_html
)
Array
(
    [basic_html] => basic_html
    [full_html] => full_html
    [plain_text] => plain_text
    [restricted_html] => restricted_html
    // <--- Missing test ID here
)

But If I were to add \Drupal::configFactory()->reset(); in addition to the $storage->resetCache(); then it does work as expected.

Proposed Solution

Override \Drupal\Core\Config\Entity\ConfigEntityStorage::resetCache() and have it call $this->configFactory->reset() which should avoid needing to call two separate resets.

Cannot save views changes

$
0
0

Since the last 2 core updates I have not been able to make any changes to a view. When clicking the "apply" button after making a change in the "edit" page dialog pop-up, nothing happens and no error is registered in the error log.

Non-Exposed combined with Exposed Filters on same Text List Field Not Working

$
0
0

I have a view that I am using to generate two displays that are shown on a page with quicktabs. The views have a primary (non-exposed) filter for a completion state, which is a Text List field on the Node:

  • Planned
  • In Progress
  • Delayed
  • Complete
  • Canceled

The View Display is a FooTable (this is unrelated). On one View Display, I set the primary (non-exposed) filter to ONE OF and limit the select list options to 'Planned', 'In Progress' and 'Delayed'. I then add an exposed filter to allow users to further refine the list to one of these three options, so there are two filters for the same field.

I have found that in order for the above to work properly, the non-exposed filter (primary) must be ordered ABOVE the exposed filter.

But things get funny with my second View Display, in which I have a primary (non-exposed) filter to ONE OF 'Complete', 'Canceled' combined with a secondary exposed filter for these two list items. When selecting 'Complete' in the exposed filter, the SQL output shows the following in the query:

LEFT JOIN {field_data_field_permit_status} field_data_field_permit_status2 ON node.nid = field_data_field_permit_status2.entity_id AND field_data_field_permit_status2.field_permit_status_value != 'Complete'

Note that the query is now looking for anything that does NOT have the term 'Complete', which is the opposite of what we want. This is a bug.

A workaround is to change the non-exposed primary filter to select the initial terms through an inverse (IS NOT ONE OF 'Planned', 'In Progress', 'Delayed'). This will then work with a secondary filter of IS ONE OF, however it appears that two filters on a select list IS ONE OF does not work.

"Links" field not displaying on custom view modes

$
0
0

Problem/Motivation

When using a custom view mode, the "Links" field is not displayed.

Steps to reproduce:

  1. Starting with a fresh D8 site.
  2. Add a dummy node of type "Article".
  3. Create a custom view mode for the "Article" content type.
  4. Configure the new custom view mode to display the "Links" field.
  5. Create a new view to show all nodes of type "Article", displaying "Content" with the new view mode.
  6. See in the Views preview that no "Links" are displayed.

As additional confirmation, confirm that the "Links" field is visible in the "Teaser" display, then change the View to display the "Teaser" and note that the "Links" are displayed.

Proposed resolution

Properly display the Links field on custom view modes.

Remaining tasks

User interface changes

API changes

Data model changes

Update composer dependencies on 9.0.x

$
0
0

Problem/Motivation

Packages were held back because of the older version of PHP should now be upgradable since we use PHP 7.2.

Proposed resolution

Upgrade all the packages we can.

Remaining tasks

Test all the things.

User interface changes

None.

API changes

None (hopefully).

Data model changes

None.

Release notes snippet

TBD.


Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates

$
0
0

Problem/Motivation

Because of #2807145: [policy, no patch] Allow contrib projects to specify multiple major core branches, Drupal 9 may need to retrieve modules that start with 8.x-. The update module is not currently aware that modules starting with 8.x can be compatible with Drupal 9.

Proposed resolution

  1. Update requests should no longer request information from URLs that have \Drupal::CORE_COMPATIBILITY(8.x) as the final path segment. This should be replaced with 'current'. For example, a request that previously requested https://updates.drupal.org/release-history/paragraphs/8.x will now request https://updates.drupal.org/release-history/paragraphs/current
  2. The contents of /current has a somewhat different structure than what was returned by requests to /8.x, The update module and its tests will need refactoring to reflect those changes.
    • The following tags are no longer provided, the information should be parsed from the version tag instead: version_major, version_minor, version_patch, version_extra
    • recommended_major (which differed depending on the API requested) may be replaced with recommended_branches, which will be provided by Drupal.org if needed. Currently recommended_major is dropped
    • supported_majors replaced with supported_branches, which includes core compatibility for non-semver version numbers.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Remove BC layers from the entity system

$
0
0

Problem/Motivation

in #1730874: Add support for loading multiple revisions at once we deprecated doLoadRevisionFieldItems(), but left its use in doLoadMultipleRevisionsFieldItems(). In #3069043: Trigger an error on direct access of ContentEntityStorageBase::doLoadMultipleRevisionFieldItems() and mark it to be set abstract in Drupal 9 We deprecated calling ContentEntityStorageBase::doLoadMultipleRevisionsFieldItems directly and triggered an error, declaring the method would be abstract in Drupal 9

Proposed resolution

Remove the logic and make the method abstract

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Accessible dropdown for Umami's language-switcher and mobile main-menu

$
0
0

Problem/Motivation

Umami's new language switcher has various issues:
When adding more languages (beyond the existing English and Spanish) it will break the nice flow of the header, or when viewing the website in RTL language.

Umami's mobile main-menu has accessibility issues (#2940023)

Proposed resolution

Creating an accessible dropdown component can solve the current issues with both Umami's language switcher and Umami's mobile main-menu.

Remaining tasks

Create dropdown menu.
Figure out best positioning and a visual representation that will be easy to identify as "Here's where I can switch to another language"


Umami main menu missing in IE11 with current latest patch.

Allow configurable date attributes to collect

$
0
0

Problem/Motivation

The 7.x Date module allowed the field to specify which parts of the date to collect (Year, Month, Day, Hour, Minute, and Second):

For parts of the date that are not collected, those are stored as 00. For instance, if one choses to not collect seconds, then the date is stored as 2016-04-03 12:15:00.

Proposed resolution

Add this functionality to the date form widgets.

Remaining tasks

User interface changes

API changes

Data model changes

This shouldn't impact field storage, but would add an option to the field definition config.

Remove system.module BC layers

[PP-1] Support Drupal 7 node reference fields

$
0
0

Problem/Motivation

The migration system has no support for migrating node reference fields, with their settings and values, from Drupal 7 to Drupal 8.
The source module is https://www.drupal.org/project/references.

Proposed resolution

Add a field plugin to handle Drupal 7 node reference fields.

Remaining tasks

  • Write the field plugin
  • Write tests of said plugin
  • Update the Drupal 7 fixture with a node reference field or two
  • Update our integration tests to ensure that the node reference fields and their configurations are migrated correctly
  • Update other integration tests to ensure that node reference fields' values are migrated properly
  • Commit the patch
  • Jump into a ball pit and roll around happily

User interface changes

None.

API changes

None.

Data model changes

None.

Allow for expandable text with "Read more/less" links in Default field formatter

$
0
0

In Views field configurations, the Default formatter's Rewrite Results section has a checkbox:

Add a read-more link if output is trimmed

...with two options, a label and a path.

While there are certainly use cases for this, it seems less useful to me than having this option:

Add read-more and read-less links for expanding and collapsing the full text

This option would use JavaScript (JS) to expand and collapse the full field text by clicking on the links. With this approach, no link is required, and saves users the trouble of having to come up with one.

We should probably just add the new option as I'm sure folks are using the old one. We could, however, deprecate the old one at some point.

This behaviour is implemented in a different formatter with the Readmore Contrib module, but I don't see why we can't get this into Core with the default one.


Support third party settings for components within a section

$
0
0

There's an issue to support adding third party settings to sections: #2942661: Sections should have third-party settings, but it would be great to also support third party settings for individual components (blocks) within a section.

For example, modules like Block Class and Field Formatter Class use third party settings on block config entities to allow the user to add arbitrary CSS classes to a block. It seems that the only way to do this with a Layout Builder block is to modify the settings form for the individual block plugin you want to modify and store the configuration along with the other configuration for that block.

Entity autocreate checkbox for custom entites not working

$
0
0

Problem/Motivation

During implementation of a custom entity I debugged the entity reference field autocomplete functionality, as it was not working.
When referencing a new custom entity, the error
There are no entities matching "Entity label"
pops up.

Proposed resolution

Beside the right configuration (where different are possible). The code for selecting the bundle is not triggered at all.

Remaining tasks

There are a lot of tasks open about entity creation. Fe. a user reference field does not work.
The entity reference fields should store they're bundles in auto_create_bundle for "bundle-less" or in target_bundles for ones having multiple bundles.
This issue is thought as quick fix. The remaining task shall be done in subsequent (existing) issues, fe.
#2700411: "Create referenced entities if they don't already exist" option on entity reference field shouldn't be available for users

User interface changes

None.

API changes

None.

Data model changes

None.

Add helper methods to inject items into a particular position in associative arrays

$
0
0

One of the most difficult things about manipulating Drupal forms is the process of manipulating the arrays themselves. And one of the things that I commonly want to do is "stick this stuff in after that". But I have yet to find a PHP function to manipulate arrays in this way.

So I wrote this function called array_insert(). Perhaps there's a cleaner way to handle this, but it seems like a function that should be available in Drupal core. It would certainly help with a lot of common hook_form_alter() tasks.

For instance, this function (finally) offers a way to stick something into the node-type settings page (admin/settings/content-types/[node-type]) immediately before the "submit" buttons, you'd just create an array with your form items and then call

$form = array_insert($form, 'buttons', $my_stuff, TRUE);

/**
 * Inserts values from $arr2 after (or before) $key in $arr1
 * if $key is not found, $arr2 is appended to $arr1 using array_merge()
 *
 * @param $arr1
 *   array to insert into
 * @param $key
 *   key of $arr1 to insert after
 * @param $arr2
 *   array whose values should be inserted
 * @param $before
 *   insert before the given key. defaults to inserting after
 * @return
 *   merged array
 */
function array_insert($arr1, $key, $arr2, $before = FALSE){
  $done = FALSE;
  foreach($arr1 as $arr1_key => $arr1_val){
    if(!$before){
      $new_array[$arr1_key] = $arr1_val;
    }
    if($arr1_key == $key && !$done){
      foreach($arr2 as $arr2_key => $arr2_val){
        $new_array[$arr2_key] = $arr2_val;
      }
      $done = TRUE;
    }
    if($before){
      $new_array[$arr1_key] = $arr1_val;
    }
  }
  if(!$done){
    $new_array = array_merge($arr1, $arr2);
  }
  return $new_array;
}

Allow adding classes to JavaScript messages default wrapper

$
0
0

Problem/Motivation

The Drupal.Message.defaultWrapper() removes class="hidden" from the fallback div by using wrapper.removeAttribute('class'); which prevents adding classes needed for styling on the wrapper element.

Proposed resolution

Replace wrapper.removeAttribute('class') with wrapper.classList.remove('hidden').

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Entity queries querying the latest revision very slow with lots of revisions

$
0
0

After upgrading to 8.4 we noticed a performance decrease on one of our sites. The page that is taking minutes to load is a multilanguage page with several field collections and revisions enabled.

Some debugging lead me to the change in issue 2864995.

This change introduces a latestRevision() method which is used by QuickEdit (this explains why it is only when logged in). On a field collection that has about 4000 revisions, this query takes seconds to run.

If I understand correctly the change introduces a self-join to the base revision table. Because of this, for each revision in the table, a set of revisions + next revisions is added to the result. From this result only the row that has no next revision (is null) is used (in my case 7000000 rows are searched for the one that has no next revisions).

base_table.revision_idbase_table_2.revision_id
......
335916335986
335916336066
335986336066
336066NULL

Maybe we can think of a more efficient way of querying the latest revision?

Viewing all 291693 articles
Browse latest View live


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