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

In the paragraph view, I can not get the field of the referring content.

$
0
0

Add a view.

View setting is below:
Show:paragraph
of type: choose a particular paragraph.

Block settings is below:
Create block is checked.
Block display settings is
Display format is Unformatted list of fields.
Item per block is 5.

Relationships setting is below:
Content using referred fields machine name.
Require this relationship is checked.

Field add is below:
Add Content:ID

Relationship is selected.

Result is...
No paragraph is displayed.

It is displayed in the case of normal entity reference such as media, but it seems that it is not displayed in case of paragraph entity reference revision.
It is the same result on a page, not a block.

I want to display the paragraph and the field of the content referring to the paragraph. If the field is valid, hide the field and display it as a block with the context filter.

I feel that it is a bug.

Thanks.


PHP 7.4 deprecated reverse order of glue and pieces in implode

$
0
0

PHP 7.4 has deprecated usage of reverse order of glue and pieces in implode functions. Reported by phpcs --standard=PHPCompatibility

Replace ZendFramework/* dependencies by their Laminas equivalents

$
0
0

Since the transition of Zend Framework to the Laminas project, composer has been warning about the deprecation of the zendframework/* components.

Our composer dependencies should be updated to reflect this.

  • zendframework/zend-diactoros → laminas/laminas-diactoros
  • zendframework/zend-escaper → laminas/laminas-escaper
  • zendframework/zend-feed → laminas/laminas-feed
  • zendframework/zend-servicemanager → laminas/laminas-servicemanager
  • zendframework/zend-stdlib → laminas/laminas-stdlib

ConfigInstaller::isSyncing is not reset before module preinstall

$
0
0

Problem/Motivation

When modules are being installed during configuration sync, \Drupal::service('config.installer')->isSyncing() returns FALSE in hook_module_preinstall() implementations. This is because the kernel is updated and the container is rebuilt just prior to the preinstall hooks being invoked. The config installer sync status is not set back to TRUE until later.

Proposed resolution

Call \Drupal::service('config.installer')->setSyncing(TRUE) right after the call to \Drupal\Core\Extension\ModuleInstaller::updateKernel() if $sync_status is TRUE.

Remaining tasks

(reviews needed, tests to be written or run, documentation to be written, etc.)

API changes

Data model changes

Release notes snippet

Contextual Links Style Update

Declaration of Drupal\Core\Security\PharExtensionInterceptor::assert(string $path, string $command): bool must be compatible with TYPO3\PharStreamWrapper\Assertable::assert($path, $command)

$
0
0

Updating core to 8.8.0, and getting the error: Declaration of Drupal\Core\Security\PharExtensionInterceptor::assert(string $path, string $command): bool must be compatible with TYPO3\PharStreamWrapper\Assertable::assert($path, $command) in /app/web/core/lib/Drupal/Core/Security/PharExtensionInterceptor.php on line 14

My PHP version: 7.2.19

Workaround

Try the following steps:

  1. rm -rf vendor
  2. composer remove --dev webflo/drupal-core-require-dev
  3. composer require any other packages you use (e.g., Drush)
  4. Clear the site cache.

Make Drupal 8 compatible with PHP 7.4

$
0
0

Problem/Motivation

Drupal 8.8.x is not passing tests on PHP 7.4. PHP 7.4 released on November 28, 2019, a week before Drupal 8.8.0.

Proposed resolution

Dependencies to be updated upstream

Dependencies to be updated in Drupal

  • None at the moment.

Spun-off issues

Done:

Make Composer create-project As Lean As Possible (ALAP)

$
0
0

Problem/Motivation

Sometimes a Composer command fails or prompts the user. This can usually be avoided by sprinkling some magic over it, for example -s dev or -n. At some point the underlying issue might get fixed, the project structure changes, or something else happens, and the option is no longer needed. But the magic lingers on in the documentation, and on the internet.

Ideally, a Drupal user who is not a Composer expert should now set off some time to study the intricacies of Symfony/Composer, when meeting such a challenge. But the new user simply wants a functioning Drupal installation with the least hassle, so this is often not realistic.

Many new users, who experience too many bumps and stops, while trying to get Drupal up and running, will eventually give up and look elsewhere for a CMS which is not as hard to install.

Proposed resolution

We should strive to remove as many obstacles as possible, to ease Drupal users' usage of Composer, by reducing or entirely removing options such as -s dev, -n, and --prefer-dist.

In #3086498: Parameters at the end in documentation, for better discoverability and legibility it was discussed to use composer create-project together with either --prefer-dist or --no-interaction|-n.

To keep it as simple as possible, no extra Composer options at all is the obvious solution, which actually works just fine.

We might want to add a note below: "NOTE: If for some reason you get a cryptic Composer "Keep/Yes/No/Aways" prompt, perhaps due to some left over .git folders, try adding --prefer-dist at the end of the command".

Remaining tasks

  1. Make sure there are no conflicts, lingering .git folders, etc. when running composer create-project which will result in a prompt, by creating a test which runs composer create-project with no options. The command should go straight through, without Composer presenting a "Keep/Yes/No/Always" prompt. Also, a successful test should show the text "Congratulations, you’ve installed the Drupal codebase":
    $ composer create-project drupal/recommended-project my-project
    ...
      Congratulations, you’ve installed the Drupal codebase
      from the drupal/recommended-project template!
    Next steps:
    ....
    
  2. Update documentation where pertinent to the leanest possible version, in this case:

    $ composer create-project drupal/recommended-project my-project

  3. [Optional Extra Task] Go through other Composer commands (update, require, etc.) with the ALAP (As Lean As Possible) philosophy, and get rid of options where possible

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

None


Drupal\migrate_drupal\Tests\StubTestTrait is not compatible with PHPUnit 8

$
0
0

Problem/Motivation

Discovered in #3063887: Support PHPUnit 8 optionally in Drupal 8, while keeping support for ^6.5 and ^7.

Drupal\migrate_drupal\Tests\StubTestTrait implements

protected function createStub($entity_type_id)

This method has a name collision with a PHPUnit 8 method on PHPUnit\Framework\TestCase that has a different signature and a different purpose.

This will prevent future usage of PHPUnit 8.

Proposed resolution

  • Rename createStub to something else
  • Deprecate createStub
  • Add/adjust tests

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Fix serial SQL types

$
0
0

The serial database type is supposed to be automatically unsigned and not null. However, the database-specific drivers were not consistent with this and in many schema definitions, unsigned and not null are explicitly declared, which ought to be redundant.

The attached patch cleans up the code by removing unnecessary explicit unsigned and not null statements from schema definitions and ensuring that the drivers consistently make serial fields unsigned and not null.

I have not been able to test it on anything except our MySQL install, but the changes to the other drivers were minimal. I would appreciate it is others would test the other databases.

ExpectDeprecationTrait is not compatible with PHPUnit 8

$
0
0

Problem/Motivation

Discovered in #3063887: Support PHPUnit 8 optionally in Drupal 8, while keeping support for ^6.5 and ^7.

Drupal\Tests\Traits\ExpectDeprecationTrait implements

protected function expectDeprecation($message)

This method has a name collision with a PHPUnit 8 method on PHPUnit\Framework\TestCase that has a different signature and a different purpose.

This will prevent future usage of PHPUnit 8.

Proposed resolution

  • Rename expectDeprecation to something else: addExpectedDeprecationMessage?
  • Deprecate expectDeprecation
  • Add/adjust tests

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

A new module version is not recognized by interface translation update.

$
0
0

Problem/Motivation

If an existing module gets replaced by a new version of this module, the new version is not displayed on the translation status page.

Proposed resolution

  • Refresh the data during the module update(.php) process.
  • Refresh the data and remove old translation file during translation update (cron, drush, manual)

Remaining tasks

t.b.d.

User interface changes

bug is fixed

API changes

none

Data model changes

none

Drush updb Syntax Error while updating from 8.7.7 to 8.8.1

$
0
0

I ran update after updating path_auto and running and got this error:

In ProcessBase.php line 188:

  Unable to decode output into JSON: Syntax error

  {
      "0": {
          "system": {
              "8801": {
                  "results": {
                      "query": null,
                      "success": true
                  },
                  "type": "update"
              },
              "8802": {
                  "results": {
                      "query": null,
                      "success": true
                  },
                  "type": "update"
              },
              "8803": {
                  "results": {
                      "query": "The "path_alias" entity type has been installed.",
                      "success": true
                  },
                  "type": "update"
              },
              "8804": {
                  "results": {
                      "query": "Path aliases have been converted to entities.",
                      "success": true
                  },
                  "type": "update"
              },
              "8805": {
                  "results": {
                      "query": null,
                      "success": true
                  },
                  "type": "update"
              },
              "entity_reference_autocomplete_match_limit": {
                  "results": {
                      "query": null,
                      "success": true
                  },
                  "type": "post_update"
              },
              "layout_plugin_schema_change": {
                  "results": {
                      "query": null,
                      "success": true
                  },
                  "type": "post_update"
              }
          },
          "path": {
              "create_language_content_settings": {
                  "results": {
                      "query": null,
                      "success": true
                  },
                  "type": "post_update"
              }
          },
          "search": {
              "block_page": {
                  "results": {
                      "query": null,
                      "success": true
                  },
                  "type": "post_update"
              }
          },
          "taxonomy": {
              "configure_status_field_widget": {
                  "results": {
                      "query": null,
                      "success": true
                  },
                  "type": "post_update"
              }
          },
          "text": {
              "add_required_summary_flag": {
                  "results": {
                      "query": null,
                      "success": true
                  },
                  "type": "post_update"
              }
          },
          "views": {
              "limit_operator_defaults": {
                  "results": {
                      "query": null,
                      "success": true
                  },
                  "type": "post_update"
              },
              "remove_core_key": {
                  "results": {
                      "query": null,
                      "success": true
                  },
                  "type": "post_update"
              }
          }
      },
      "drush_batch_process_finished": true
  }

Here is the complete update commands:

$ drush updb
 [warning] Invalid json in modules/contrib/contentimport/composer.json
 [warning] You are running on a system where PHP is compiled or limited to using 32-bit integers. This will limit the range of dates and timestamps to the years 1901-2038. Read about the <a href="https://www.drupal.org/docs/8/system-requirements/limitations-of-32-bit-php">limitations of 32-bit PHP</a>. (Currently using Limited date range Your PHP installation has a limited date range.)
 ---------- ------------------------------------------- --------------- -----------------------------------------------
  Module     Update ID                                   Type            Description
 ---------- ------------------------------------------- --------------- -----------------------------------------------
  system     8801                                        hook_update_n   Remove 'path.temporary' config if redundant.
  system     8802                                        hook_update_n   Fix system.theme:admin when the default theme
                                                                         is used as the admin theme.
  system     8803                                        hook_update_n   Install the 'path_alias' entity type.
  system     8804                                        hook_update_n   Convert path aliases to entities.
  system     8805                                        hook_update_n   Change the provider of the 'path_alias'
                                                                         entity type and its base fields.
  path       create_language_content_settings            post-update     Create the language content settings
                                                                         configuration object for path aliases.
  search     block_page                                  post-update     Configures default search page for
                                                                         instantiated blocks.
  system     entity_reference_autocomplete_match_limit   post-update     Populate the new 'match_limit' setting for
                                                                         the ER autocomplete widget.
  system     layout_plugin_schema_change                 post-update     Clear the schema cache.
  taxonomy   configure_status_field_widget               post-update     Add status with settings to all form displays
                                                                         for taxonomy entities.
  text       add_required_summary_flag                   post-update     Update text_with_summary fields and widgets
                                                                         to add summary required flags.
  views      limit_operator_defaults                     post-update     Define default values for limit operators
                                                                         settings in all filters.
  views      remove_core_key                             post-update     Remove core key from views configuration.
 ---------- ------------------------------------------- --------------- -----------------------------------------------


 Do you wish to run the specified pending updates? (yes/no) [yes]:
 > yes

>  [warning] Invalid json in modules/contrib/contentimport/composer.json
>  [notice] Update started: system_update_8801
>  [notice] Update completed: system_update_8801
>  [notice] Update started: system_update_8802
>  [notice] Update completed: system_update_8802
>  [notice] Update started: system_update_8803
>  [warning] Invalid json in modules/contrib/contentimport/composer.json
>  [notice] The "path_alias" entity type has been installed.
>  [notice] Update completed: system_update_8803
>  [notice] Update started: system_update_8804
>  [notice] Path aliases have been converted to entities.
>  [notice] Update completed: system_update_8804
>  [notice] Update started: system_update_8805
>  [notice] Update completed: system_update_8805
>  [warning] Invalid json in modules/contrib/contentimport/composer.json
>  [warning] Invalid json in modules/contrib/contentimport/composer.json
>  [notice] Update started: path_post_update_create_language_content_settings
>  [notice] Update completed: path_post_update_create_language_content_settings
>  [notice] Update started: search_post_update_block_page
>  [notice] Update completed: search_post_update_block_page
>  [notice] Update started: system_post_update_entity_reference_autocomplete_match_limit
>  [notice] Update completed: system_post_update_entity_reference_autocomplete_match_limit
>  [notice] Update started: system_post_update_layout_plugin_schema_change
>  [notice] Update completed: system_post_update_layout_plugin_schema_change
>  [notice] Update started: taxonomy_post_update_configure_status_field_widget
>  [notice] Update completed: taxonomy_post_update_configure_status_field_widget
>  [notice] Update started: text_post_update_add_required_summary_flag
>  [notice] Update completed: text_post_update_add_required_summary_flag
>  [notice] Update started: views_post_update_limit_operator_defaults
>  [notice] Update completed: views_post_update_limit_operator_defaults
>  [notice] Update started: views_post_update_remove_core_key
>  [notice] Update completed: views_post_update_remove_core_key

In ProcessBase.php line 188:

  Unable to decode output into JSON: Syntax error

  {
      "0": {
          "system": {
              "8801": {
                  "results": {
                      "query": null,
                      "success": true
                  },
                  "type": "update"
              },
              "8802": {
                  "results": {
                      "query": null,
                      "success": true
                  },
                  "type": "update"
              },
              "8803": {
                  "results": {
                      "query": "The "path_alias" entity type has been installed.",
                      "success": true
                  },
                  "type": "update"
              },
              "8804": {
                  "results": {
                      "query": "Path aliases have been converted to entities.",
                      "success": true
                  },
                  "type": "update"
              },
              "8805": {
                  "results": {
                      "query": null,
                      "success": true
                  },
                  "type": "update"
              },
              "entity_reference_autocomplete_match_limit": {
                  "results": {
                      "query": null,
                      "success": true
                  },
                  "type": "post_update"
              },
              "layout_plugin_schema_change": {
                  "results": {
                      "query": null,
                      "success": true
                  },
                  "type": "post_update"
              }
          },
          "path": {
              "create_language_content_settings": {
                  "results": {
                      "query": null,
                      "success": true
                  },
                  "type": "post_update"
              }
          },
          "search": {
              "block_page": {
                  "results": {
                      "query": null,
                      "success": true
                  },
                  "type": "post_update"
              }
          },
          "taxonomy": {
              "configure_status_field_widget": {
                  "results": {
                      "query": null,
                      "success": true
                  },
                  "type": "post_update"
              }
          },
          "text": {
              "add_required_summary_flag": {
                  "results": {
                      "query": null,
                      "success": true
                  },
                  "type": "post_update"
              }
          },
          "views": {
              "limit_operator_defaults": {
                  "results": {
                      "query": null,
                      "success": true
                  },
                  "type": "post_update"
              },
              "remove_core_key": {
                  "results": {
                      "query": null,
                      "success": true
                  },
                  "type": "post_update"
              }
          }
      },
      "drush_batch_process_finished": true
  }


updatedb [--cache-clear [CACHE-CLEAR]] [--entity-updates] [--post-updates [POST-UPDATES]] [--no-cache-clear] [--no-post-updates] [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [-d|--debug] [-y|--yes] [--no] [--remote-host REMOTE-HOST] [--remote-user REMOTE-USER] [-r|--root ROOT] [-l|--uri URI] [--simulate] [--pipe] [-D|--define DEFINE] [--druplicon] [--notify] [--xh-link XH-LINK] [--] <command>

when I tried to run drush updb again, it returned with " [success] No pending updates." Will appreciate any suggestions on this. The updates were completed but not getting a successful statement at the end is of concern, though the error seem minor.

Set the toolbar to position fixed on mobile

$
0
0

Problem/Motivation

During the usability sessions, some participants did not notice the toolbar on mobile, as struggled to get back to their administrative content area.

When the toolbar was originally designed, mobile devices had limited screen sizes and vertical height was a premium, times have changed maaan.

Proposed resolution

Set position fixed on mobile
Consider setting apple-mobile-web-app-capable meta tag when logged in as well - https://developer.apple.com/library/safari/documentation/AppleApplicatio...

Remaining tasks

Implement the change
Test

User interface changes

Fixed toolbar on mobile which is always visible to the user.

API changes

None

Data model changes

None

Fully deprecate WorkflowDeleteAccessCheck

$
0
0

Problem/Motivation

This is a child issue of #2856744: [META] Add trigger_error(..., E_USER_DEPRECATED) to deprecated code

Drupal\workflows\WorkflowDeleteAccessCheck is marked as @deprecated and @internal.

It's also a service in workflows.services.yml. The service is named workflows.access_check.delete_state.

The only place in core that makes reference to this deprecated service or its class name is core/modules/content_moderation/tests/fixtures/update/drupal-8.4.0-content_moderation_installed.php.

Adding a typical @trigger_error() to WorkflowDeleteAccessCheck fails quite a few tests: https://www.drupal.org/pift-ci-job/1106392 (Search for 'WorkflowDeleteAccessCheck' on the page).

Proposed resolution

Figure out how to trigger a deprecation error from this service so that developers will avoid using it.

Either mark tests using that fixture as @group legacy or rebuild the fixture in some way.

Remaining tasks

User interface changes

API changes

Data model changes


Multiple image upload breaks image dimensions

$
0
0

Problem/Motivation

Displaying images that were uploaded at the same time (selecting mulitple images) are broken. The height/width from the first image are applied to all images.

Workaround

Use Image Field Repair module to restore corrupted images and to fix core bug (since 8.x-1.2 release).

How to reproduce

  1. Create a content type with an image field, cardinality unlimited.
  2. Be sure that the images are displayed as "original image" (no image style)
  3. Create a content and upload multiple image at the same time (click on the upload button, and select more that one image. Images must have differents sizes and be smaller than the screen so they are not resized by CSS max-width.)
  4. Save

The width/height attributes on the image tag are the same (those of the first image), even if the images we uploaded does not have the same dimensions.

Why this happens

When you overload an ImageWidget with multiple files selected at once from the remote client, the form system needs first of all to transform the single widget with n files to n widgets with one file each. This is managed by the methods ::massageFormValues and ::submit. Before transforming, the widget process stores the dimensions of the first image in two hidden fields of the initial widget. The transformation is done by adding multiple widgets in the form array, copying them from the first widget. Now that's the gotcha. The transformation is managed within the FileWidget code, that ImageWidget inherits from - and FileWidget has no code to deal with image dimensions. So the additional widgets are copied with the same hidden fields values of the first file.

Proposed resolution

Implement ::massageFormValues and ::submit methods in ImageWidget, taking from the parent FileWidget class , and changing them to ensure that image width and image height values do not carry over from the initial widget to its copies.

Remaining tasks

User interface changes

None.

API changes

None.

Data model changes

None.

Use version of guzzlehttp/guzzle ^6.5.2

D9, PHP 7.2 vendor min Testing issue - DO NOT COMMIT

$
0
0

Related issue for Drupal 8.8/8.9: #3044175: PHP7.1 vendor min Testing issue - DO NOT COMMIT

Problem/Motivation

Since testbot only tests issues with the vendor versions in the composer lock file, we need a way to test against older vendor versions that are permitted in our composer.json in order to avoid committing code that may not work with an earlier dependency.

Proposed resolution

Keep an RTBC issue with a patch to run composer update --prefer-lowest against the codebase prior to running the test suite.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

PHP7.1 vendor min Testing issue - DO NOT COMMIT

$
0
0

Problem/Motivation

Since testbot only tests issues with the vendor versions in the composer lock file, we need a way to test against older vendor versions that are permitted in our composer.json in order to avoid committing code that may not work with an earlier dependency.

Proposed resolution

Keep an RTBC issue with a patch to run composer update --prefer-lowest against the codebase prior to running the test suite.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Convert config, config_environment module hook_help() to topic(s)

$
0
0

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the config, config_environment module(s).

Proposed resolution

Take the information that is currently in the hook_help module overview section for the module(s), and make sure the information is in one or more Twig help topic files. Steps:

  1. Find the hook_help() implementation function in the core/modules/MODULENAME/MODULENAME.module file(s). For example, for the core Contact module, the module files is core/modules/contact/contact.module, and the function is called contact_help().
  2. Locate the module overview portion of this function. This is located just after some lines that look something like this:
      switch ($route_name) {
        case 'help.page.contact':
    

    And ends either at the end of the function, or where you find another case 'something': line.

  3. We want to end up with one or more topics about the tasks that you can do with this module, and possibly a section header topic. So, read the help and figure out a good way to logically divide it up into tasks and sections. See Standards for Help Topics for information on how to do this.
  4. See if some of these tasks are already documented in existing topics. Currently, all topics are in core/modules/help_topics/help_topics. Note that to see existing topics, you will need to enable the experimental Help Topics module (available in the latest dev versions of Drupal 8.x).
  5. For each task or section topic that needs to be written, make a new Twig topic file (see Standards for Help Topics) in core/modules/help_topics/help_topics. You will need to choose the appropriate module prefix for the file name -- the module that is required for the functionality. Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can use the "core" file name prefix. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in the core prefix), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module prefix).
  6. File names must be MODULENAME.TOPICNAME.html.twig -- for example, in the Action module, you could create a topic about managing actions with filename action.managing.html.twig (and "MODULENAME" can be "core" as discussed above).
  7. Make a patch file that adds/updates the Twig templates. The patch should not remove the text from the hook_help() implementation (that will be done separately).

Remaining tasks

a) Make a patch (see Proposed Resolution section).

b) Review the patch:

  1. Apply the patch.
  2. Turn on the experimental Help Topics module in your site, as well as the module(s) listed in this issue.
  3. Visit the page for each topic that is created or modified in this patch. The topics are files in the patch ending in .html.twig. If you find a file, such as core/modules/help_topics/help_topics/action.configuring.html.twig, you can view the topic at the URL admin/help/topic/action.configuring within your site.
  4. Review the topic text that you can see on the page, making sure of the following aspects:
    • The text is written in clear, simple, straightforward language
    • No grammar/punctuation errors
    • Valid HTML -- you can use http://validator.w3.org/ to check
    • Links within the text work
    • Instructions for tasks work
    • Adheres to Standards for Help Topics [for some aspects, you will need to look at the Twig file rather than the topic page].
  5. Read the old "module overview" topic(s) for the module(s), at admin/help/MODULENAME. Verify that all the tasks described in these overview pages are covered in the topics you reviewed.

User interface changes

Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Viewing all 296634 articles
Browse latest View live


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