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

Display Bug when using #states (Forms API) with Ajax Request

$
0
0

FAPI #states do not update properly after AJAX requests.

Steps to reproduce

To replicate the bug, you need a content type with a field that makes an AJAX request and another field that has a state dependent on that field. In my use case, I have a content type with an image field and a text field that should only show when an image has been uploaded.
1. Have a content type with an image and a text field
2. Create a custom module that adds a state to your text field to only display when the image field has value. It would look something like this:

use Drupal\Core\Form\FormStateInterface;

function mymodule_form_alter(&$form, FormStateInterface $form_state, $form_id) {
  if ($form_id == 'node_page_form' || $form_id == 'node_page_edit_form') {
    $form['field_my_text_field']['#states'] = [
      'visible' => [
        ':input[name="files[field_my_image_field_0]"]' => ['filled' => TRUE],
      ],
    ];
  }
}

3. Go to your content type and upload an image. You would expect to see field_my_text_field because the image field has an image and the state should react to the AJAX call. However, you won't see field_my_text_field. Save your node, and go back to edit your node. Now you should see field_my_text_field.
4. Apply the patch from #80 and go through the steps again. Now on step 3, you should see field_my_text_field immediately after you upload an image.

Original report

I use a custom module which makes heavy use of the Forms API to do mathematical calculations.

The form which you can see at http://linsenrechner.de/node/27 is rendered with the #states attribute. each line uses a container to display two fields. When these fields are filled, a new line should appear.
This works perfect, BEFORE the calculation button is pressed and the ajax request is done.
After this, the behaviour of the form changes: When two fields of a specific line are filled not only one new line appears. In this case, all lines, which are defined in the form, appear at the same time.

The author of the custom module, sukr_s (http://drupal.org/user/554988) wasn't able to exactly locate the bug, but believes it's in states.js

Here are the form arrays, which are used to create the form at http://linsenrechner.de/node/27

$form['container0'] = array(
   '#type'   => 'container',
   '#weight'        => -53,
); 

$form['container0']['markup0'] = array(
   '#weight'        => -52,
   '#markup' => "<div id='ocalc_header_33'></div>
                 <div id='ocalc_header_33'>$ocalc_sag_height</div>
                 <div id='ocalc_header_33'>$ocalc_zone</div>",
); 


$form['container0'][$wrapper]['sag0'] = array(
    '#type'          => 'textfield',
    '#title'         => $ocalc_sag_height." 0",
    '#title_display' => 'invisible',
    '#weight'        => -51,
    '#maxlength'     => 4,
    '#size'          => 4,
    '#prefix'  => "<div class='form-item-sag0'>$ocalc_zone 0</div>",
    '#field_suffix'  => "mm",
  );

$form['container0'][$wrapper]['zone0'] = array(
    '#type'          => 'textfield',
    '#title'         => $ocalc_zone." 0",
    '#title_display' => 'invisible',
    '#weight'        => -50,
    '#maxlength'     => 4,
    '#size'          => 4,
    '#field_suffix'  => "mm",
  );

$form['container1'] = array(
   '#type'   => 'container',
   '#weight'        => -43,
   '#states' => array('visible' => array(
		':input[name=sag0]'  => array ('filled' => TRUE),
		':input[name=zone0]' => array ('filled' => TRUE),
    ),
  ),
); 


$form['container1'][$wrapper]['sag1'] = array(
    '#type'          => 'textfield',
    '#title'         => $ocalc_sag_height." 1",
    '#title_display' => 'invisible',
    '#weight'        => -42,
    '#maxlength'     => 4,
    '#size'          => 4,
    '#field_suffix'  => "mm", 
    '#prefix' => "<div class='form-item-sag1'>$ocalc_zone 1</div>",
  );
  
 $form['container1'][$wrapper]['zone1'] = array(
    '#type'          => 'textfield',
    '#title'         => $ocalc_zone." 1",
    '#title_display' => 'invisible',
    '#weight'        => -41,
    '#maxlength'     => 4,
    '#size'          => 4,
    '#field_suffix'  => "mm",                   
  );
 
$form['container2'] = array(
   '#type'   => 'container',
   '#weight'        => -33,
   '#states' => array('visible' => array(
		':input[name=sag0]'  => array ('filled' => TRUE),
		':input[name=zone0]' => array ('filled' => TRUE),
		':input[name=sag1]'  => array ('filled' => TRUE),
		':input[name=zone1]' => array ('filled' => TRUE),
    ),
  ),
); 


$form['container2'][$wrapper]['sag2'] = array(
    '#type'          => 'textfield',
    '#title'         => $ocalc_sag_height." 2",
    '#title_display' => 'invisible',
    '#weight'        => -32,
    '#maxlength'     => 4,
    '#size'          => 4,
    '#field_suffix'  => "mm", 
    '#prefix' => "<div class='form-item-sag1'>$ocalc_zone 2</div>",
  );
  
 $form['container2'][$wrapper]['zone2'] = array(
    '#type'          => 'textfield',
    '#title'         => $ocalc_zone." 2",
    '#title_display' => 'invisible',
    '#weight'        => -31,
    '#maxlength'     => 4,
    '#size'          => 4,
    '#field_suffix'  => "mm",                 
  );

 
$form['container3'] = array(
   '#type'   => 'container',
   '#weight'        => -23,
   '#states' => array('visible' => array(
		':input[name=sag0]'  => array ('filled' => TRUE),
		':input[name=zone0]' => array ('filled' => TRUE),
		':input[name=sag1]'  => array ('filled' => TRUE),
		':input[name=zone1]' => array ('filled' => TRUE),
		':input[name=sag2]'  => array ('filled' => TRUE),
		':input[name=zone2]' => array ('filled' => TRUE),
    ),
  ),
); 


$form['container3'][$wrapper]['sag3'] = array(
    '#type'          => 'textfield',
    '#title'         => $ocalc_sag_height." 3",
    '#title_display' => 'invisible',
    '#weight'        => -22,
    '#maxlength'     => 4,
    '#size'          => 4,
    '#field_suffix'  => "mm", 
    '#prefix' => "<div class='form-item-sag1'>$ocalc_zone 3</div>",
  );
  
 $form['container3'][$wrapper]['zone3'] = array(
    '#type'          => 'textfield',
    '#title'         => $ocalc_zone." 3",
    '#title_display' => 'invisible',
    '#weight'        => -21,
    '#maxlength'     => 4,
    '#size'          => 4,
    '#field_suffix'  => "mm",                 
  );

$form['container4'] = array(
   '#type'   => 'container',
   '#weight'        => -13,
   '#states' => array('visible' => array(
		':input[name=sag0]'  => array ('filled' => TRUE),
		':input[name=zone0]' => array ('filled' => TRUE),
		':input[name=sag1]'  => array ('filled' => TRUE),
		':input[name=zone1]' => array ('filled' => TRUE),
		':input[name=sag2]'  => array ('filled' => TRUE),
		':input[name=zone2]' => array ('filled' => TRUE),
		':input[name=sag3]'  => array ('filled' => TRUE),
		':input[name=zone3]' => array ('filled' => TRUE),
    ),
  ),
); 


$form['container4'][$wrapper]['sag4'] = array(
    '#type'          => 'textfield',
    '#title'         => $ocalc_sag_height." 4",
    '#title_display' => 'invisible',
    '#weight'        => -12,
    '#maxlength'     => 4,
    '#size'          => 4,
    '#field_suffix'  => "mm", 
    '#prefix' => "<div class='form-item-sag1'>$ocalc_zone 4</div>",
  );
  
 $form['container4'][$wrapper]['zone4'] = array(
    '#type'          => 'textfield',
    '#title'         => $ocalc_zone." 4",
    '#title_display' => 'invisible',
    '#weight'        => -11,
    '#maxlength'     => 4,
    '#size'          => 4,
    '#field_suffix'  => "mm",                   
  );

[meta] Support PHPUnit 9 in Drupal 9

$
0
0

Problem/Motivation

Similarly to #3063887: Support PHPUnit 8 in Drupal 9, drop support for PHPUnit 7, this issue is about enabling testing with PHPUnit 9 in Drupal 9.

PHPUnit 7 will be end of support Feb 7, 2020
PHPUnit 8 will be supported until Feb 5, 2021
PHPUnit 9 will be released Feb 7, 2020.

In PHPUnit8 several assertions methods are deprecated for removal in PHPUnit9, for example:

  • Using assertContains() with string haystacks is deprecated and will not be supported in PHPUnit 9. Refactor your test to use assertStringContainsString() or assertStringContainsStringIgnoringCase() instead.
  • The @expectedException, @expectedExceptionCode, @expectedExceptionMessage, and @expectedExceptionMessageRegExp annotations are deprecated. They will be removed in PHPUnit 9. Refactor your test to use expectException(), expectExceptionCode(), expectExceptionMessage(), or expectExceptionMessageRegExp() instead.
  • assertInternalType() is deprecated and will be removed in PHPUnit 9. Refactor your test to use assertIsArray(), assertIsBool(), assertIsFloat(), assertIsInt(), assertIsNumeric(), assertIsObject(), assertIsResource(), assertIsString(), assertIsScalar(), assertIsCallable(), or assertIsIterable() instead.
  • assertArraySubset() is deprecated and will be removed in PHPUnit 9.
  • getObjectAttribute() is deprecated and will be removed in PHPUnit 9.
  • readAttribute() is deprecated and will be removed in PHPUnit 9.

Spun off issues

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Explore if Seven's underline focus style for details/summary can work without span

$
0
0

Problem/Motivation

In #2980304: Seven theme's details/summary focus style is broken/missing in some browsers. we're trying to get Seven's underline focus style for <details><summary> to work on all browsers. Sadly, text-decoration doesn't seem to reliably work for this, so we're wrapping the title in a <span> so that text-decoration is always happening.

@lauriii wanted a follow-up to explore if it was possible to do this without changing the <details> markup at all, which is what this issue is for.

Proposed resolution

TBD.
One possible approach can be found at #3102724-96: Improve usability of core compatibility ranges on available updates report where I implemented an underline via a bottom-border instead of text-decoration. It's hacky, but seemed to work.

Remaining tasks

  1. Decide what to do.
  2. Do it.

User interface changes

TBD.

API changes

None.

Data model changes

None.

Release notes snippet

TBD, probably not.

Seven theme's details/summary focus style is broken/missing in some browsers.

$
0
0

Important follow-up to #2854624: Details and accordion update based on Seven Style Guide. There is a WCAG failure at level A.

Problem/Motivation

The details/summary elements in Seven theme have inconsistent focus styles across different browsers (some show a focus indicator, others don't).

In some browsers (Chrome + Opera on Mac) the summary element has an underline when it is focused, but in others it doesn't (Safari on Mac, others...?). I noticed this halfway though manual testing of the long list of OS/browser combinations we support, and didn't go back to check them all over again ;-)

We MUST HAVE a clear visual focus style for the summary element.

  • In the case where the focused summary DOES NOT get an underline, the ONLY indication is a slight colour change. This is a failure of WCAG 1.4.1 Use of Color (level A). The focus state is essential information, and it is being conveyed by colour alone.
  • Since the colour change on focus is so slight, it's also a failure of WCAG 2.4.7 Focus Visible (~borderline ...) and 1.4.11 Non-text contrast (both level AA).
  • Now, Proposal: A Style Guide for Seven doesn't actually have a focus style for the summary element. We definitely need to make summary focus visible in all browsers, so lets investigate an fix that in a follow-up.

    Major, because it is currently a level A WCAG failure in affected browsers.

    Proposed resolution

  1. Must-have: Ensure all browsers (including mobile phone browsers) indicate when the summary element is focused.
    The simplest approach is to make the underline-on-focus style work in all of our supported browsers. No design work is needed to satisfy WCAG 2.0 SC 2.4.7 "Focus Visible".
  2. Could-have: The seven style guide doesn't have a focus style for summary elements, so we may want to create one.

Remaining tasks

Investigate:

  1. Which browsers show focus, and which ones don't?
    • Firefox 64 (mac, linux) - shows focus, OK.
    • Chrome 71 (mac, linux), 73 (mac) - does not show focus.
    • Opera 57 (mac, linux) - does not show focus.
    • Safari 12 (mac)- does not show focus.
    • IE11 ?
    • Edge ?
    • Chrome (android) ?
    • Safari (iOS) ?
  2. Find out underlying cause - selectors?

User interface changes

Accessibility fix. Complete details/summary styling in Seven theme, so all browsers indicate when the summary element has focus.

API changes

none

Data model changes

none

[PP-3] Remove Stable as a base theme of core themes

$
0
0

Postponed on:
#3050374: Create Drupal 9 stable theme
#3110855: Plan for removing dependency to Stable in Bartik/Seven/Claro/Umami
#3115088: Remove Classy as a base theme of core themes

Problem/Motivation

Stable will be moved to contrib during Drupal 9. After we have ensured that core themes (Bartik, Claro, Seven, Umami) are not using Stable templates or libraries, we can remove Stable as a base theme of these themes.

Proposed resolution

Set base theme: false for Bartik, Claro, Seven, and Umami

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Plan for removing dependency to Stable in Bartik/Seven/Claro/Umami

$
0
0

Problem/Motivation

After we have successfully decoupled Bartik, Seven, Claro and Umami from Classy on #3050389: [META] Remove dependency to Classy from core themes, we'll be decoupling these themes also from Stable. This will make it easier for these themes to receive improvements as they are no longer beholden to BC, and will facilitate easier major version updates from Drupal 10 onward since themes will be made compatible with core markup changes as they happen. This will also allow us to eventually deprecate Stable.

Proposed resolution

  • Identify which Stable templates/CSS are different from the module code they originate from
  • For each CSS file and template that differs, determine if the core theme should receive a copy of Stable's asset, or if it's acceptable for the core theme to use the updated version.
  • Keep in mind that Stable has two CSS files that aren't present in core, which could be overlooked if the work is based on a 1:1 relationship with core and Stable. The files are: file.admin.css
    filter.admin.css
  • Asses impact of other BC layers such as JavaScript theme functions and preprocess functions.
  • Fix any regressions.

Remaining tasks

#3113211: Create test for theme asset decoupling from Stable
#3111468: Decouple Stable libraries from Bartik/Seven/Claro/Umami
#3111729: Stable templates/CSS that differ only in comments or indentation should match core's version
#3115223: [PP-3] Remove Stable as a base theme of core themes
Determine which CSS/Templates should be copied to themes and which can acceptably use module assets.

User interface changes

API changes

Data model changes

Release notes snippet

Create FileFieldUploader service that unifies file upload logic of core's UI, REST module and JSON:API module

$
0
0

Problem/Motivation

Currently, the REST module's @RestResource=file_upload plugin contains lots of logic that was very carefully developed and tested in #1927648: Allow creation of file entities from binary data via REST requests. That issue was a monumental effort.

We don't want the JSON:API (contrib, soon core) and GraphQL modules to A) duplicate the logic since that is too risky, B) duplicate the effort. We want them to use the same hardened, proven logic.

Proposed resolution

  1. Introduce a FileFieldUploader service that extracts the file file upload logic, minus the rest.module-specific bits.
  2. Refactor the REST module's @RestResource=file_upload plugin to use this service. None of its behaviors change.
  3. Prove this by having a patch that passes tests while modifying zero tests.
  4. Prove this by having the JSON:API module also use this (done in #8).

Remaining tasks

  1. first we need input from JSON API and GraphQL on which parts make sense to reuse. Then we need to find consensus.
  2. Prove use by REST module.
  3. Prove use by JSON:API module.
  4. Get to RTBC after thorough review.

User interface changes

None.

API changes

None.

Data model changes

None.

[PP-1] The 'Update' page has no idea that some updates are incompatible

$
0
0

Problem/Motivation

The form to actually install pending updates at /admin/reports/updates/update has no notion that some of the available updates are incompatible with your currently installed version of core, and will happily try to download and install them for you. I haven't actually tested what happens, but it seems seriously problematic to leave it as is.

Splitting this off from
#3102724: Improve usability of core compatibility ranges on available updates report
#3096078: Display core compatibility ranges for available module updates
...

For example, with the latest screenshots from #3102724, on a test site setup to believe it's 8.7.10 core, we'd see this:

Screenshot of available updates for both compatible and incompatible releases, initial state

Compare that with the "Update" page on the same site:

Screenshot of 'Update' form for a site with  both compatible and incompatible releases available for update -- no indication some of these aren't compatible

No indication at all that redis 8.x-1.4 (the "Recommended release") won't install on your current version of core (which you still have to manually update, unlike all the contrib updates this form would (try to) install for you...

Proposed resolution

  • Harvest some of the compatibility-awareness from #3102724: Improve usability of core compatibility ranges on available updates report and use it on this other page/form, too. YES
  • Add similar Compatible / Not compatible details elements. YES, but to avoid too much noise, only show details for "Not compatible"
  • Disable checkboxes on incompatible updates? NO
  • Move rows with incompatible releases into the bottom table ("Manual updates required")
  • Figure out the latest release we could safely upgrade to and call that the recommended release for this form? E.g. given the current scenario from the screenshots, at least the redis 8.x-1.3 release could be installed on that site... - Nah, punt to follow-up.

Remaining tasks

  1. Decide what to do.
  2. Land #3102724: Improve usability of core compatibility ranges on available updates report so we have the new code we need to make this work.
  3. Implement proposed resolution.
  4. Reviews.
  5. ...

User interface changes

TBD

API changes

TBD. Probably nothing public. Perhaps some changes to protected/internal APIs inside update.module and friends.

Data model changes

TBD, probably none.

Release notes snippet

TBD.


[META] Requirements for tagging Drupal 9.0.0-beta1

$
0
0

Problem/Motivation

Must-haves prior to tagging Drupal 9.0.0-beta1

8.9.x and 9.0.x will enter beta at the same time and will have the same beta stability requirements as a normal minor release. Additionally:

  1. There must be no outstanding issues to update PHP and JavaScript dependencies (i.e. they should be on the latest release of the latest branch we intend to ship with). Also unused dependencies should be removed prior to beta. See #3009213: [META] Update / reconsider dependencies for Drupal 9.
     
  2. All deprecated code usages and backwards compatibility layers must be removed and deprecations properly documented - we can't remove deprecated code that is called by Drupal core. (see the @deprecated tag). This includes deprecated JavaScript libraries etc.
    See:

     

  3. Any critical Drupal 8 upgrade path bugsmust be triaged / resolved in 8.x so that sites are not stranded on pre-8.9.x versions due to known core bugs.
     
  4. Also in 9.0.x, updates from versions prior to Drupal 8.8.x must be removed and hook_update_last_removed() implementations added: #3108254: [META] Drupal 8-9 upgrade path clean-up This is to minimise the surface area for 8-9 upgrade path bugs.
     
  5. Any known 9.0.x-only security or data integrity criticals must be resolved.
     
  6. Simpletest module must be either successfully moved to contrib, or retained in core and undeprecated #3110983: Verify that simpletest tests can be run in contrib, or add simpletest back to core.

Should-haves

These issues are not hard blockers to releasing Drupal 9, but there would be significant negative consequences of them not being completed in time for Drupal 9's release. Outstanding should-haves may cause 9.0.0 to be deferred from the June release window to the August window.

  1. Any critical API changes, API additions, or data model changes should be completed, as these changes will no longer be allowed during the beta.
     
  2. All Drupal 6 and Drupal 7 -> Drupal 8/9 core content migrations should be stable. In practice this mostly means multilingual migrations #2208401: [META] Stabilise Migrate Drupal Multilingual module . If we don't do this, we can't expect people to migrate from Drupal 6 and Drupal 7.

  3. There may be minor configuration translation migrations or contrib -> core migrations still outstanding which would be great to clean up but should not actually block release.
     

  4. We should have adopted a policy for PHP 7.x version support, as this needs to be announced as far as possible before the LTS and 9.0.0 release so hosts have time to upgrade. #2917655: [policy] Decide whether and how to drop PHP 7.3 support in Drupal 9 during its lifetime. Currently working on requiring PHP 7.3 at #3106075: Bump minimum PHP for Drupal 9 to PHP 7.3.
     
  5. We should have a policy for MySQL, PostgreSQL and SQLite version support. See #3107113: [policy] Decide on MySQL/MariaDB/Percona Server version support status for Drupal 9, #3106077: [policy] Decide on PostgreSQL 9.x/10.x support status and #3107155: Raise SQLite version requirement to 3.26 in Drupal 9.
     
  6. We should provide accurate update recommendations (9.0, not a non-existent minor version of Drupal 8) on the Status Report (/admin/reports/status). #2991207: [PP-3] Drupal core should inform the user of the security coverage for the site's installed minor version including final 8.x LTS releases.
     
  7. We should have a proper policy for CSS and markup changes, see #2659890: [Plan] Drupal 9 markup and CSS backwards compatibility.
     
  8. Drupal.org should be able to fully handle contributed projects that are compatible with both 8.x and 9.x and not assume core compatibility based on version/branch name:
    #3054433: Support multiple core branch functionality for contributed projects

    This spans multiple projects and areas such as project listing, composer façade, update.xml from drupal.org and localization files.

  9. We should have dropped support for Node.js 8 since it's EOL. #3107918: [PP-1] Drop support for Node.js 8

Nice to haves

  1. #3111409: [META] Add new default Olivero frontend theme to Drupal 9 core only if done enough in time, otherwise moves to Drupal 9.1.0 earliest.

Must have and should have issues (and their children) have been tagged "Drupal 9.0.0-beta1 requirement" on a best effort basis for an easier cut-through view of all issues regardless of their hierarchy or project affected.

Avoid error when $options is NULL in buildUrl()

$
0
0

We've run into an issue where we are getting an error on a link field:

Error: Unsupported operand types in /core/modules/link/src/Plugin/Field/FieldFormatter/LinkFormatter.php on line 245

I don't know if it's possible to reproduce this error with just core. The error seems to be coming from a translation issue in Paragraphs where the "options" property isn't getting set right. This patch is a work-around to that but it's just checking that $options is an array and making it one if it's not so it won't hurt anything to have it in there as a failsafe.

Migrate D6 and D7 node revision translations to D8

$
0
0

Follow-up to #2225775: Migrate Drupal 6 core node translation to Drupal 8

Problem/Motivation

In D8, a node revision has data for all languages. In D6 and D7, each node revision has data for just one language. This means currently D6 -> D8 and D7 -> D8 migrations yield a revision history where each node revision has only one language present, even if previous revisions had translations. This is strange and likely to confuse users.

Priority is given to the D7 migration because the D6 one might be effected by the term node migrations.

This is for migrating core translation revisions, migrating revisions for entity translation is now being done in #3076447: Migrate D7 entity translation revision translations to D8. It is intended that this issue is completed first and then the approach used here is also used for entity translations.

The following notes use the term 'master' which was the original term what is now the 'complete' node migration.

Meeting notes

Things to consider, taken from notes of meeting with alexpott, Gábor Hojtsy, heddn, mikelutz and quiteone

  1. Migration dependencies
    • Possible: easy to do
    • BC concerns: none
    • BC what about contrib? Commerce / metatag
      • Possible incompatible
  2. How do we figure out you need the new complex master migration?
    • Possible: moderate to do
    • BC concerns: none
    • Don’t effect expose new d*_node_master unless explicitly enabled to existing sites
    • This handles incremental, no UI option available to enable
    • For new installs, give an option to upgraders to enable disable the new d*_node_master migration and use the old method.
  3. What about migration lookups on dn_node etc.
    • Possible: easy to do
    • BC concerns: none
  4. What about incremental migrations that have already begun
    • Not allowed. You can only use the new approach on a site that has not run migrations. So we need some of flag where existing installs use the old migrations.
  5. Contrib/Custom
  6. Does it make sense to use d*_node_master instead of d*_node migrations?

Proposed resolution

The current focus is to get the D7 version working and then move those changes to D6.

Using the existing method where the final revision is migrated first doesn't work instead the revisions need to be migrated in order. The first proof of concept patch to show this is in #121, thanks to mikelutz. This new approach is called the Complete node migration and the migrations and files use that name.

"Removing it [the classic node migrations] will break the whole ecosystem. Deprecating it means that it’s not used anymore which in and of itself will break the eco system, and for what benefit? To remove it in Drupal 10, a year after D7 is EOL? At that point we are looking at deprecating the entire D7 upgrade path anyway (Probably for removal in 11, not 10) We really don’t want to break the migration ecosystem right now at this critical time when we are trying to get everyone off of D7 in the next 18-20 months". by mikelutz in #migration on Drupal Slack). See #3109819: [PP-2] Deprecate classic node migration plugin in Drupal 9 for removal in Drupal 10 for discussion of when deprecation of classic node migrations would happen.

Run Complete or classic node migrations
However, the Complete approach doesn't integrate with the current migrations, now being called Classic, that is the one either runs the existing node migrations or the new complete one, not both. Choosing between the two methods is done at run time by checking the node migration map tables in MigrationConfigurationTrait() and migrate_drupal_migration_plugins_alter(). In the trait the classic method is selected if any of the classic node migrate_map tables has data (using processedCount) and in the plugins_alter it is selected if any classic node migrate_map exists and there are no complete node migrate_maps.

The selection of node migration method also allows tests to decide which method to use. The test does this by adding either 'node_migrate_classic' or 'node_migrate_complete' to $modules.

Altered migrations
There are several migrations that use migration_lookup on the node migration. The processes and dependencies for these are altered when the complete node migration is being run. The changes include new processes to convert the 3 destination IDs returned by complete node to the correct destination ID expected when using the classic migration.
The migrations altered are: d6_term_node, d6_term_node_revision, d6_term_node_translation, d6_comment, d6_url_alias,d7_comment, d7_url_alias, statistics_node_counter, node_translation_menu_links.

Incremental migrations
For the core UI, if map tables for the classic mode migrations exist and at least one has a row then the classic migrations will run and not the complete node migrations. This is determined at run time. Therefor, existing incremental migration should continue to function.

From the original IS
D6 and D7 node revisions do not directly indicate which other translated node revisions they are associated with. But we can attempt to guess this, based on the order of revisions.

Remaining tasks

Fix tests, add comments
Review

For Reviewers

  • All level of code reviews welcome.
  • There are BC issues raised in meeting notes, above

For Testers

  1. Use the lastest patch patch in this issue.
  2. There are instructions in the Issue summary of the META issue #2208401: [META] Stabilise Migrate Drupal Multilingual module

From #55

For developers

  1. Make this work with a multilingual source and a non multilingual source
  2. Discuss and document implications for drush, especially drush migrate-upgrade --all
  3. Make sure the d6 and d7 tests includes testing a fields on each revision
  4. Handle the case where the vid of the first revision is higher the vid of a later revision. This is true for both d6 and d7.
  5. Make sure that the use of migration_tag 'translation' is documented. It is used in
    • d6_node_translation.yml
    • d7_node_entity_translation.yml
    • d7_node_translation.yml
    • d7_node_revision_translation.yml
    • d7_user_entity_translation.yml
    • d7_taxonomy_term_entity_translation.yml/li>
    • d7_comment_entity_translation.yml
    • d6_node_revision_translation.yml
  6. Make sure that the source plugin 'translation' property is documented
  7. Make sure that the destination plugin 'translations' property is documented

Drupal 8 - token parent:name missing from the Pathauto - no way to create a parent taxonomy alias for a Content type pattern

$
0
0

Hi,
I'm not a dev so, in case if the issue was opened in the wrong place, please move it to the corresponding place.
I was advised to open this issue after some consultations on this matter on one of the Drupal's chats.
Apparently the feature that I was not able to configure does exist and this is some known bug when a token for pathauto module is missing due to some bug or issue during installatin/configuration. (Yet, not sure, need a configuration)

Issue description:
After a fresh installation of Drupal 8.82 + Pathauto 8.x-1.6 (including Ctools 8.x-3.2 and Token 8.x-1.6) when configuring a new Pathauto alias pattern based on Content type the token parent:name is not presenting.
There is no way to create an alias pattern based on a content type with a parent term taxonomy.

And that makes it impossible to create an alias based on the Taxonomy structure (term parent/term child/node-title).
The possible option is: [node:field_taxonomy_term]/[node:title] -- what represents only the child term.

Apparently, this issue appears only in some cases (-- need a configuration for this one), since for other installations the configuration of alias pattern with term parent and child is possible.
The issue was not fully tested by me, beside the fact that I'm experiencing it. So I'm not sure what are the real cases for it.

The normal functionality of the Pathauto pattern based on the Content type should look something like this:
[node:field_taxonomy_term:parent:name]/[node:field_taxonomy_term]/[node:title]

but an error appears "Path pattern is using the following invalid tokens: [node:field_taxonomy_term:parent:name]. "

Thank you.

Provide theme-development.services.yml to make twig_debug easier

$
0
0

Problem/Motivation

Is there any reason why development.services.yml does not disable TWIG cache by default? Every core update overrides this file with the default one. Themers routinely set those 3 lines, but this is a repetitive task. And the file loads only when settings.local.php is included, so it will not cause any problems on production sites.

Proposed resolution

  1. Create a file at sites/theme-development.services.yml containing the twig.config related lines under the parameters: key:
      twig.config:
        debug: true
        auto_reload: null
        cache: true
    
  2. Reference this new services file in sites/example.settings.local.php, below the line of code where development.services.yml is referenced. Leave the reference commented out with a note explaining the potential dangers and implications of enabling theme debugging.
    /**
     * Enable theme development services.
     *
     * Note: theme debugging can break parts of Drupal. Not recommended in
     * production environments. See https://www.drupal.org/i/2914733
     */
    # $settings['container_yamls'][] = DRUPAL_ROOT . '/sites/theme-development.services.yml';
    

    For the website themer, this code is more or less analogous to adding $config['theme_debug'] = TRUE; option in Drupal 7 settings.php file. Optionally, a CR could be added to describe this difference between D7 / D8.

Dependency injection in permission callbacks

$
0
0

The permissions callback provider class, being handled by the controller resolver, is capable of dependency injection by implementing ContainerInjectionInterface. The following patch adds that for the node module permission provider. The same should be done for other core modules that provide permission callbacks.

"Add a new inline block" title on settings tray doesn't match "Custom block"

$
0
0

A colleague of mine - @ricksta (https://www.drupal.org/u/ricksta) - pointed out that when creating a "Custom block" via Layout Builder, the title confusingly reads "Add a new Inline block", which of course is the original name for what are now considered "Custom blocks", at least in the UI sense.

Steps to recreate:
- Install standard profile
- Add at least one additional custom block type besides the "Basic block"
- Enable Layout Builder
- Enable Layout Builder for Article Content type
- Go to edit layout
- Click "Add block"
- Click the "Create custom block" button
- The title of the tray reads 'Add a new Inline Block'

It appears to us we should have consistency here, in that the user has clicked "Create custom block", and the title reads "Add a new custom block"


Enable grouping for checkboxes and radio buttons

$
0
0

As of today, grouping is only possible for select lists, not for checkboxes and radio buttons. In form.inc, options buttons get flattened out.
If you read this thread: #1878292: Add grouping by Vocabulary / Content type / Bundle for check boxes / radio buttons widget you can see that grouping for checkboxes and radio buttons is a legitimate feature request for entity reference fields.
I believe this can be accomplished by doing the following:
1/ setting optgroups property to TRUE for options_buttons in function _options_properties() of modules/field/modules/options.module file. This prevents #options from being flattened out.
But the presentation layer does not handle grouping for checkboxes and radios... so:
2/ modify function form_process_checkboxes in includes/form.inc to actually handle grouping. I've only tested for checkboxes so far but I believe the same can be done for radio buttons in form_process_radios.
3/ finally for the system not to throw an illegal choice error at form validation, we actually need to flatten the options before validation process the same way its done for select lists right now in function _form_validate of include/form.inc

In order not to break already existing Drupal sites, I suggest we wrap steps 1 and 3 in conditional statement based on either :
- a variable in settings.php
- or maybe more a Drupal variable (variable_get) configurable in the UI that wouldn't need to be copied manually and maybe forgotten each time we need to update settings.php.

Note that modifications in 2) would not affect current Drupal sites since all the grouping code would only be executed for Arrays() but all options would still be flattened out... so no array, no new behavior.

Could this be added to the Drupal 7 core or is it too late? I will of course provide my code as soon as it is more complete.

Migrate d7 menu translation

$
0
0

Problem/Motivation

The d7 menu translations need a migration

Make more explicit the email address is necessary to recover the password

$
0
0

AccountForm::form() (an similarly RegisterForm::form()) uses the following sentence to describe the email field.

The email address is not made public and will only be used if you wish to receive a new password or wish to receive certain news or notifications by email.

Instead of if you wish to receive a new password it should say if you forget the password. The latter make more explicit which case is being described (considered that if I wish to change my password, I just edit my account to change it, after I provide the current password). To make it more general, I would change the sentence as follow.

The email address is not made public and will only be used if you need to be contacted about your account, for example when you forget your password, or you wish to receive certain news or notifications by email.

New serial columns do not own sequences

$
0
0

Problem/Motivation

Follow-up from reviewing #3026290: PostgreSQL constraints are still not renamed properly on table renames.

The pgsql driver does not set the ownership of sequences it creates when changeField method is called. This happens if you specify a table without a serial field, then later change an integer field into one. This means that the preferred pg_get_serial_sequence function will not return the newly created sequence.

Sequences created automagically with CREATE TABLE are "owned" by the relation, but those created with CREATE SEQUENCE need the OWNED BY statement appended with the relation and the column.

Drupal 8 and 7 core currently do not have any database updates that change fields into serial columns, but contrib. or custom code might.

Proposed resolution

  1. Add OWNED BY {table}.field to the create sequence statements.
  2. Add a database update to check serial fields to make sure they exist via pg_get_serial_sequence, and if not, alter the sequence with the same statement above.
  3. Potentially refactor as a protected (or public?) function for ease-of-use?
  4. Write a test to assert that sequence ownership exists on change field.
  5. Write a test to assert that the database update works.

Remaining tasks

  • Write a patch.
  • Review
  • Commit and unpostpone the 7.x issue

API changes

None. Additions only if anything.

Release notes snippet

Follow-up to #3113608: Bartik template incorrectly referencing Claro library

$
0
0

Problem/Motivation

It seems like core/themes/bartik/templates/node.html.twig is referencing a Claro library instead of a Bartik library.

Proposed resolution

Reference a Bartik template instead of Claro.

Remaining tasks

Viewing all 291721 articles
Browse latest View live


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