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

Nested modals don't work: when using CKEditor in a modal, then clicking the image button opens another modal, which closes the original modal

$
0
0

I am currently looking into running CKEditor in a modal dialog using the Drupal Modal API.

At this moment it is working OK, but there is a problem with the link and image modals which can be triggered from the CKEditor interface. Those also use the Modal API and when triggering one of these functions, the modal containing CKEditor is fully closed.

Is there any way to open de link/image modal without closing the CKEditor modal? It seems like it is possible to define the HTML element to which the modal should append when triggering. When overriding this setting ('appendTo' => '#foo'), even the link/image modals are appended to #foo (instead of the default '#drupal-modal').

Any ideas on how to get this to work?
Thanks for your support.


Extend site information page to generate a manifest.json file

$
0
0

Problem/Motivation

New browser features enable better website integration to users' systems. While working on the progressive web app module I came across a W3C draft for a manifest file. This file is used on mobile devices to allow website authors some control over the way the shortcut and initialization screen looks like.

Proposed resolution

  • Add new form fields and reorganize the site information form.
  • Add a <link rel="manifest" href="…/manifest.json"> tag in the head and a way to generate that file.
  • Generation of a manifest.json file containing at least:
    {
      "lang": "en",
      "dir": "ltr",
      "name": "Very good Drupal Website™",
      "short_name": "Drupal Website™",
      "icons": [{
            "src": "my/default/theme/logo.png",
            "sizes": "144x144"
          }],
      "start_url": "/",
      "display": "browser",
      "orientation": "portrait",
      "theme_color": "#ffffff",
      "background_color": "#ffffff"
    }
    
  • We need to add a <meta name="theme-color"> tag for branding color to compliment the values set inside manifest.json

User interface changes

Site information form changes. New fields:

  • short_name (textfield)
  • start_url (textfield) Could be different from the site homepage.
  • display (select list/radio)
  • orientation (select list/radio)
  • theme_color (probably expose that to themes)
  • background_color (probably expose that to themes)

API changes


Probably some ways for theme to declare/alter informations in the manifest file.

More details: Web app manifests usher new wave of progressive apps to your homescreen.

Allow showing autocomplete results for Drupal fields with empty input string

$
0
0

At now Drupal autocomplete form fields (eg entity reference autocomplete) needs to type at least one symbol for show field autocomplete results.

But in many situations users don't know what to type in form field, and good to show top of available options to user via simple mouse click on field, without any typing. Replacing autocomplete to select is bad idea, when select contain 1000+ options.

Solution for this problem is enabling searching autocomplete results with empty string, but this is hardcoded in Drupal core web/core/modules/system/src/Controller/EntityAutocompleteController.php:

  public function handleAutocomplete(Request $request, $target_type, $selection_handler, $selection_settings_key) {
    $matches = [];
    // Get the typed string from the URL, if it exists.
    if ($input = $request->query->get('q')) {

Quick easy hack is enable calling "getMatches" for empty q get argument via changing to this:

  public function handleAutocomplete(Request $request, $target_type, $selection_handler, $selection_settings_key) {
    $matches = [];
    // Get the typed string from the URL, if it exists.
    $input = $request->query->get('q');
    if ($input !== NULL) {

Other solutions maybe use some keyword (eg q=_ALL_) for show all results, use additional argument (?q=&show-empty=1).

On field widget settings side will be good to add separate checkbox "Allow autocomplete for empty string", or maybe combine with "Minimum string length for autocomplete = 0", and separate setting for form fields with entity_autocomplete type.

What do you think about this idea?

Add a selection overview to the media library widget modal

$
0
0

Problem/Motivation

While adding tabs to the media library modal in #3020716: Add vertical tabs style menu to media library, there was a need to make the selection persistent across the different tabs of the modal. When selecting items in several tabs, filtering and pagina at the same time, it could be hard to remember which exact items are already selected and/or where a specific item was selected.

Proposed resolution

We already show a count of the selected items, it would be nice to add a button to the selection count that shows an overview of all selected items inside the modal.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Edit the date range error messages

$
0
0

Problem/Motivation

The error message if the start is before the end date is unnecessary technically and should be changed. Also the link text in for the Inline Form Error summary needs editing.

Proposed resolution

Remaining tasks

User interface changes

These are UI text changes.

API changes

Data model changes

Datetime error message can be unclear depending on the time of day

$
0
0

Steps to reproduce

  1. Add a date field to an entity and then go to to that form.
  2. Fill in an appropriate date.
  3. Fill in a time that has a single digit hour, like "8:15:00".
  4. Submit the form and receive a validation message along the lines of The Start date is invalid. Please enter a date in the format 12:00:00.

The basic problem is that there's a disconnect between the time that you enter in the form and the time that you submit the form. The error message generates a sample based on the current time. This means that if you submit the form between 00:00:00 - 09:59:59, you will get an error message that pretty clearly shows that the hour format is HH. However, if you submit the form between 10:00:00 - 23:59:59, then the hour would be two digits regardless of whether the hour format is HH or H, so it's not as clear that the hour you entered is in the wrong format.

Possible solutions

  1. Try to use the submitted time (formatted correctly) as the sample time. (i.e. strtotime())
  2. Use a static time for the sample that is between 00:00:00 - 09:59:59.
  3. Rather than a sample time, show the actual format string.
  4. Something else I didn't think of. :)

Add a status modifier to the progress bar

$
0
0

The current progress bar does not have a visual representation of the end result of the job. We could show a static red bar when an error happened, and a static green bar when the job has finished. This is specially handy in progress bars that are updated via AJAX.

Allow range when editing a number field

$
0
0

Problem/Motivation

When editing a numeric field there is no option to select how to display the field.

We should be able to choose between 'number' and 'range'.

Proposed resolution

  1. Add 'range' to Manage Form Display.
  2. Add an <output /> field like <input type=range min=0 max=100 value=50 id=fader step=1 onchange="outputUpdate(value)"><output for=fader id=volume>50</output> with a script like <script>function outputUpdate(vol) { document.querySelector('#volume').value = vol;}</script>
  3. Add option for <datalist />

How to test

  1. Add "Number (integer)" field
  2. Set Form display to "Range field"
  3. Note 'No placeholder' text (should not be displayed or entered)
  4. Configure Form field
  5. Check 'Display current value' (this is not always needed depending on theming)
  6. Note missing <datalist /> list options. See remaining tasks.

Remaining tasks

  • The value(s) must be visible while changing. There is no min, max or current visible. Where to put the javascript for updating this <output /> element. Note this is solved with a working <datalist/> as that provides labels.
  • Fix hardcoded <output/> tag from template file.
  • Fix placeholder settings as these are not needed
  • Do we want <datalist /> as w3c html5 forms input range which gives at least some stops. It should support labels but currently not on Mac+Chrome/Firefox/Safari

User interface changes

API changes


I create a block in the view, but it does not appear in the block structure

Raise SQLite version requirement to 3.26 in Drupal 9

$
0
0

Problem/Motivation

Background context for Drupal 8

  • Drupal 8.0 was released in Nov. 2015. At that time, for people who wanted to install it on SQLite, the stated minimum required SQLite version was 3.6.8. If this were true, then this would have meant that all still-supported versions at that time of Debian (6, 7, 8), Ubuntu (12.04, 14.04), and RHEL/CentOS (6, 7), shipped with a compatible SQLite version. Debian 6 shipped with 3.7.3. Ubuntu 12.04 shipped with 3.7.9. And RHEL/CentOS 6 shipped with 3.6.20.
  • However, DrupalCI did not test on SQLite 3.6.8. It only tested on 3.8.2. So after releasing Drupal 8.0, we learned that Drupal could not in fact install on anything less than 3.7.11, at which point we raised the stated minimum to that, and have not raised it since.
  • Per above, this raised the minimum above what shipped with Debian 6, Ubuntu 12.04, and RHEL 6.
  • In other words, in reality, instead of Drupal 8.0 working with the SQLite version on all supported versions of the major Linux distros, it only worked on the latest versions of Ubuntu and RHEL/CentOS and with the latest and latest-1 of Debian.
  • This was mitigated by the fact that by default PHP was compiled with its own private copy of SQLite, whose version was above 3.7.11 since PHP 5.5.11. In other words, the only people who would have encountered a problem on Debian 6, Ubuntu 12.04, or RHEL/CentOS 6, were people who custom compiled PHP to link against their system's SQLite instead of PHP's bundled copy. This might explain why we didn't get many reports of the problem other than #2605594: Change minimum required sqlite version to 3.7.11.

Considerations for Drupal 9

  • PHP 7.3 continues to be compiled by default with its own bundled copy of SQLite (presently at version 3.28 since PHP 7.3.8).
  • However, PHP 7.4 removed its bundled copy and now compiles against whatever SQLite version is on the operating system.
  • If we want Drupal 9.0 to work on SQLite with all still-supported versions of Debian, Ubuntu, and RHEL/CentOS, then that would include RHEL/CentOS 7, which would only let us raise our minimum to 3.7.17.
  • However, then we'd lose out on some very helpful features, such as json support (since 3.9) and UPSERT support (since 3.25).
  • Alternatively, if we're willing to restrict SQLite support to the version that's shipped with the latest version of Debian, Ubuntu, RHEL/CentOS, and MacOS then we can raise the minimum to 3.26 and benefit from UPSERT support, because RHEL/CentOS 8 ships with SQLite 3.26, Debian 10 ships with SQLite 3.27, Mac Catalina ships with 3.28, and Ubuntu 20.04 will ship with 3.30 or higher.

Proposed resolution

  • For Drupal 9, raise the SQLite minimum to 3.26.
  • PHP 7.3 users will be fine, since they'll be using PHP's bundled copy that's at 3.28.
  • PHP 7.4 users will only be able to use SQLite if they're on the latest version of their respective operating system, or if they install SQLite from a different package repository than what's on their operating system. This includes Mac Mojave users who will need to either upgrade to Catalina or use PHP 7.3 or find some other way to install a higher SQLite version.
  • Ubuntu 18.04 users (including users of downstream distros like Mint and ElementaryOS) will be particularly impacted during the next few months, because Ubuntu 20.04 won't be released until April and the downstream distros will lag another few months after that. However, they too can use PHP 7.3 until they're able to upgrade their OS.
  • People with Drupal codebases (modules, distributions, or sites) on GitHub that they test with TravisCI will be affected, since TravisCI provides Ubuntu 18.04 but not yet 20.04. However, as above, they can run those tests on PHP 7.3. Or, if they must test with PHP 7.4, they can add the following to their .travis.yml:
    dist: bionic
    
    before_install:
      - sudo echo "deb http://archive.ubuntu.com/ubuntu focal main restricted universe multiverse"> /etc/apt/sources.list
      - sudo apt-get update
      - sudo apt-get -y install sqlite3/focal
    

    I tested the above on TravisCI and it works (it successfully installs Ubuntu 20.04 (focal)'s SQLite version on Ubuntu 18.04 (bionic)), but I don't know if it has any unwanted side effects.

  • Note that all of the above only affects people wanting to use SQLite. People affected by the above can also simply choose to use MySQL or PostgreSQL. However, SQLite is convenient for running tests and installing a site with Quick Start.

Remaining tasks

Release notes snippet

`link` fields in REST, JSON:API and GraphQL cannot be rendered by client

$
0
0

Problem/Motivation

Link fields and menu links are output in JSON:API in the following format:

"field_link": [
  {
    "uri": "internal:/",
    "title": "Home",
    "options": [
    ]
  },
  {
    "uri": "entity:node/5",
    "title": "News Center",
    "options": [
    ]
  }
]
"link": {
  "uri": "entity:node/5",
  "title": "",
  "options": [   
  ]
},

This isn't very useful for anything consuming the API because it needs to process these links. In most cases the data can't be fetched because it's unknown what node type is being referenced, and so which endpoint to query is unknown. If this was known, then it would require a lot of unnecessary requests to get the links from various bundle endpoints.

Proposed resolution

Add a computed url property at \Drupal\link\Plugin\Field\FieldType\LinkItem::propertyDefinitions()

Remaining tasks

Write code

User interface changes

None

API changes

An additional property is added to link objects

Data model changes

None

Release notes snippet

tbd

Make Drupal\Core\Database\Query\Condition driver overridable

$
0
0

Problem/Motivation

At the moment all 3 by core supported driver can work with the same implementation of Drupal\Core\Database\Query\Condition.
The MSSQL database driver has to for #3113203: Kernel Test testDbLike mandates specific escape behavior. override the default implementation of the Condition class. Also there is for the SQLite driver an override necessary (see: #2031261: Fix SQLite variable limit). The way in which the override is implemented for the SQLite driver is very different to the other query operators. We should database driver override the default implementation of the Condition class in the same way as is done for: select, delete, insert, merge, schema, truncate, update and upsert.
If there are other examples of custom implementations of the class Drupal\Core\Database\Query\Condition, please add them here.

Proposed resolution

Change the calling of the Drupal\Core\Database\Query\Condition to the same way as is done for: select, delete, insert, merge, schema, truncate, update and upsert.

User interface changes

none

API changes

Add the method Drupal\Core\Database\Connection::condition().
All code like: new Condition('AND') must change to: Database::getConnection()->condition('AND').

Data model changes

none

Profile configuration should be able to depend on optional configuration provided by modules

$
0
0

Problem/Motivation

Over in #3086824: SearchBlock plugins need to add in dependencies on the search page they submit to we discovered that if profile configuration in it's config/install directory depends on optional configuration provided by a module (or a theme) it'll fail with UnmetDependencies exception.

Proposed resolution

Install all optional configuration available before installing the install profile and then on subsequent module installs (such as the profile) install optional configuration alongside the the config/install configuration (as we do during regular module install outside of the Drupal installer).

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

tbd

Decouple core theme dependency on functions in stable.theme

Improve multiple removed version message for removed post updates

$
0
0

Problem/Motivation

Follow-up from #3066801: Add hook_removed_post_updates().

When multiple versions are shown for one module, the message we show is confusing.

Proposed resolution

Figure out the lowest version - needs to do a comparison between both 8.x-1.0 formats and 2.0.0 formats to anticipate semver contrib.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet


Increase minimum version requirement for Postgres to 10 and require the pg_trgm extension

$
0
0

Problem/Motivation

Per PostgreSQL's EOL policy, anything older than 9.2 is unsupported as of September 2016. PostgreSQL 9.3 will be unsupported as of November 8, 2018. The minimum version that D8 is supporting is PostgreSQL 9.1.2. So we are supporting an EOL version of PostgreSQL.

Proposed resolution

Increase the minimum PostgreSQL version requirement to 9.6.x.

Remaining tasks

  • Write a patch
  • Framework and Maintainer Review
  • Commit
  • Update documentation

Node revision routes don't convert {node} param

$
0
0

Problem/Motivation

The {node} parameter from node revisions routes are not upcasted. But a contrib module expects to receive full the entity in {node} parameter. Example: \Drupal\ctools\Plugin\Condition\EntityBundle::evaluate().

Proposed resolution

Upcast the {node} parameter for these paths:

  • /node/{node}/revisions/{node_revision}/view
  • /node/{node}/revisions/{node_revision}/revert
  • /node/{node}/revisions/{node_revision}/revert/{langcode}
  • /node/{node}/revisions/{node_revision}/delete

For a workaround, either use node_load() and plan to remove it once the bug is fixed or see #18 for the more proper way to do it.

Remaining tasks

  1. Review the updated issue summary.
  2. Review the change record.

User interface changes

None.

API changes

\Drupal::routeMatch()->getParameter('node') will return a Node object instead of an integer on the node-revision routes listed above.

Data model changes

None.

Add 'homepage' to .info.yml

$
0
0

Problem/Motivation

Follow-up from #3066801: Add hook_removed_post_updates().

It would be useful to be able to link to contrib module project homepages from the error message added in that issue, so that people can quickly go and see which versions are available.

We can't assume the project homepage is on Drupal.org - it could be a github repo or similar.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Changes to a block's text field not saved when ckeditor source mode is active

$
0
0

Problem/Motivation

On a layout builder page I am seeing data loss when saving an existing block with source mode enabled in ckeditor. At least the data loss is quite obvious ;)

Steps to reproduce:

  • Add block to section
  • Create custom block
  • Edit text in body field
  • Save block
  • Edit block
  • Switch body field to ckeditor source mode
  • Edit text
  • Save
  • Changes are NOT saved!

Once I changed back to non-source mode before saving the changes are saved properly.

Variation

This is a bit more severe with ckeditor_config (on a core 8.7.8 install with a lot modules installed) module enabled.

Steps to reproduce:

  • Add startupMode = source to ckeditor_config settings in basic_html
  • Edit block
  • Switch body field to source mode
  • Edit text
  • Switch to non-source mode (this makes it work in the first example)
  • Save
  • Changes are NOT saved!

(Disclaimer: In the variation I am not 100% sure if it is because of the mentioned ckeditor_config settings, at least I haven't verified on a vanilla drupal install)

Proposed resolution

Drupal CLI config export

$
0
0

On a fresh Drupal 8.8 install the console is not able to export the site configuration.

Steps to reproduce.

  1. Get a fresh drupal 8 install with composer
  2. Follow the install process until you have a functional website
  3. Run the drupal console command vendor/bin/drupal config:export
  4. Press enter to use the default sync directory

The default sync directory is set to ../config/sync.

In the export command \Drupal\Console\Command\Config\ExportCommand::execute, the drupal root directory is prepend to the given sync directory to check if the directory exists and create it if needed.

But a few lines later, we prepend again to the already prepend directory the root directory making it look like $drupal_root/$drupal_root/$directory which breaks the process.

Patch coming soon.

Viewing all 296553 articles
Browse latest View live


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