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

Create new SDC component for Umami (card view mode)

$
0
0

Problem/Motivation

Single directory components (SDC) is a new way to theme Drupal. Instead of scattering related files around your theme, they're contained to one directory. The primary issue for SDC is at #3313520: Single directory components in core.

As part of SDC's roadmap (see #3345922: Single Directory Components module roadmap: the path to beta and stable), we want to convert an Umami component to use SDC. For this task I'm choosing the card view mode component, which includes markup and CSS.

This issue is of course blocked on actually getting SDC into core. See #3340712: Add Single Directory Components as a new experimental module.

Testing instructions

  1. Make sure you have SDC module enabled, if enabling via drush si demo_umami it will be installed by the profile
  2. Clear caches
  3. Test card view mode and it's variants (most of the listings use it) - you should see HTML like the screenshot below showing that the cards are being rendered via a component

Umami card, using SDC for rendering


Should {file_usage} be generalized to work for all entity classes?

$
0
0

Similar to http://drupal.org/project/entityreference_count except each reference is tracked individually.

When deleting a node / user it could be configured to either delete all the references or wait until all references are gone before deleting the referenced entity.

Thoughts?

Contexts/Data Sources Subsystem

$
0
0

The plugin system has landed, and we need to revisit the Contexts/Data Sources plan. It looks like property api might have some non-trivial overlap in this regard, so that possibility should be explored.

What we need:

  1. Data Sources are essentially a metadata wrapping layer around various other data types to provide a consistent addressable wrapping layer for any type of data.
  2. This consistent wrapper should list what sort of data we are dealing with, as well as providing an extensible area for defining additional relevant metadata to the use case.

Implementation details

  1. CTools largely does what we need here already and likely the includes/context.inc file could be a strong guide for building an OOP centric solution for providing Data Sources.
  2. CTools utilizes a "context" plugin in order to accomplish its needs, it seem quite likely that the new plugin system in core could provide the same sort of support for this solution.
  3. In this solution the Plugin Definition would actually function as the data source's metadata, and we'd leverage plugin derivatives to support all the various solutions (For example, a single entity plugin could support all entity types and the Derivative class would replace the appropriate metadata with data relevant to the entity in question).

Eclipse

Create a new component: Tooltip

$
0
0

Anyone wanting to give this a spin can enable the toggletip_test module and go to /toggletip-test/toggletips. It's a test module, so $settings['extension_discovery_scan_tests'] = TRUE; must be configured.

Problem/Motivation

Often, the administration interface gets really busy because there’s a lot of information that needs to be available for the user. Especially in long forms, the descriptions and extra information of fields and other elements add a lot of visual complexity.

Proposed resolution

This extra info could be added to a toggle tip (as opposed to a tooltip). A toggletip has a dedicated disclosure button, while a tooltip is triggered by content that already exists on the page.
Such an elementwould simplify the UI and would allow to add extra information when needed.

Make it ad

Remaining tasks

  • Track down UI examples where this could be implemented.
  • Decide on its implementation: render array or new form element? Render array property that can be added to any existing element. It should also be possible to implement it with just markup, using the data-drupal-toggletip-toggle-button attribute.
  • Accesibility feedback: what's the best implementation? Like should it be triggered on hover or on click/touch? Click / touch

User interface changes

Initial design explorations: https://www.figma.com/file/OqWgzAluHtsOd5uwm1lubFeH/Drupal-Design-system...

API changes

Data model changes

Release notes snippet

Add migration plugin ID to Migrate Drupal UI's log messages

$
0
0

Problem/Motivation

I did an automatic Drupal 7 migration with the Migrate Drupal UI module.

I got messages like this in the log:

> Source ID 2,2,und: Invalid translation language (und) specified. (web/core/lib/Drupal/Core/Entity/ContentEntityBase.php:956)

This doesn't say which migration caused the error. It could be any content entity.

Steps to reproduce

Proposed resolution

Add the migration plugin ID.

Migration d7_menu_links: Source ID 487: d7_menu_links:link/uri:link_uri: The path "internal:/node/5" failed validation.
Migration d7_file: Source ID 2: d7_file:uri:file_copy: File '/sites/default/files/ds9.txt' does not exist

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Use CKEditor 5's native <ol type> and <ul type> UX

$
0
0

Problem/Motivation

We "solved" the problem of supporting <ol type> and <ul type> by using the SourceEditing functionality for that.

But in CKEditor 5 32.0.0, they've added a native UX for setting the list type:

Which means that rather than having to edit HTML by hand, the content creator can now do that through the UI! But unfortunately, it currently always generates <ol style="list-style-type:SOMETHING"> and <ul style="list-style-type:SOMETHING">, so we cannot use this.

This is blocked on https://github.com/ckeditor/ckeditor5/issues/11615.

It'd also improve the upgrade path because these attributes would no longer have to get set through the SourceEditing functionality.

Steps to reproduce

N/A

Proposed resolution

See above.

Remaining tasks

  1. Set styles.useAttribute = true per https://github.com/ckeditor/ckeditor5/issues/11615, this ensures the type attribute will be generated instead of a style attribute
  2. Expand the
  3. Add configuration to \Drupal\ckeditor5\Plugin\CKEditor5Plugin\ListPlugin::buildConfigurationForm(), to allow enabling the type attribute or not
  4. Expand the config schema under ckeditor5.plugin.ckeditor5_list in ckeditor5.schema.yml
  5. Expand unit test coverage in \Drupal\Tests\ckeditor5\Unit\ListPluginTest
  6. Optional: add more configuration to \Drupal\ckeditor5\Plugin\CKEditor5Plugin\ListPlugin::buildConfigurationForm(), to allow configuring which list type attribute values are allowed. (e.g. type="A" for <ol> or type="circle" for <ul>).→ CKEditor 5 does not yet support restricting this to specific types.

User interface changes

Extra configuration in UI:

@todo: screenshot

API changes

None.

Data model changes

None.

Release notes snippet

None.

Add new Splitbutton render element to eventually replace Dropbutton

$
0
0

To evaluate splitbuttons from the MR, enable the splitbutton_test module and go to

/splitbuttons

. You must have

$settings['extension_discovery_scan_tests'] = TRUE;

in your settings.php for this test module to be available.

Problem

  1. Drupal has adopted Views’ dropbutton in several common places in core. Since its introduction in #1608878: Add CTools dropbutton to core, we've spent lots of time refactoring the existing button: #1799498: Improve dropbutton and others [which?]. This component is now even being used for primary form actions on the new node edit form: #1751606: Move published status checkbox next to "Save". However, the implementation there has made the dropbutton harder to theme by pushing it beyond its initial design. (Specifically, allowing its to consist of buttons instead of links, and by introducing sub-elements using #prefix and #suffix).
  2. From a UX standpoint, the existing dropbutton’s behaviour is sub-optimal. Since the sub-items are contained within the button, when the button is opened it often must grow in width to accommodate the width of the sub-items. This change moves the click target out from under the user’s cursor, forcing them to hit a slightly different spot in order to close the menu again. In some cases, such as the one reported in #3168326: Dropbuttons in table cells are potentially unusable if it includes options with long text length., opening the dropbutton can result in a reposition that takes the pointer off the dropbotton, which results in it being closed moments after it was opened. The standard implementation of this design pattern does not suffer from this issue: Twitter Bootstrap, Zurb Foundation, jQuery UI. Drupal is the odd one out here.
  3. The open/closed state of the menu isn't conveyed to assistive technology, it is only apparent visually.
  4. The current focus style for the more-actions button is weak, and won't pass WCAG 1.4.11 Non-text contrast.

Proposed Resolution

Since we cannot change the current Dropbutton (and Operations) implementation for BC reasons, the way to move on is:

  1. Create a new Splitbutton element with the required markup, functionality and (accessibility) features.

    • The new Splitbutton element must allow having buttons as well as links, and it should be able to replace the hard-coded fake Dropbutton in Views UI.
    • It should be easy to add modifier CSS classes (described in #2160481: Componentize the dropbutton CSS).
    • Use aria-haspopup and aria-expanded to define the list and toggle to assistive tech.
    • Should have the proper focus styles, to satisfy WCAG success criteria 1.4.11 Non-text contrast. Using an outline (i.e. shape) change is recommended, rather than changing colour alone.
  2. Use the popover api for visiblity toggling
  3. Use the Floating UI library for positioning. Positioning will likely switch to use the anchor positioning API when browser support is better.
  4. In followup: Replace core's Dropbutton and Operations usage where appropriate with the new Splitbutton element.
  5. In a followup: Potentially deprecate Dropbutton. (?)

User interface changes

Splitbutton is a slightly different experience than dropbutton. Dropbutton has a primary item that is always visible. Although it's a primary item, it's semantically part of the the list that is fully visible when the dropbutton is open.
Seven Dropbutton Seven no longer in core

Claro Dropbutton
Claro is styled so the primary and list items look different although they are part of the same list. This visually resembles what splitbutton will be doing semantically.

Seven Splitbutton Seven no longer in core

Claro Splitbutton
Uses Claro's existing component styles, applied to this new element.

Dependency Evaluation

The Popover API is pretty close to being adopted in all Drupal supported browsers, but at the moment still needs a polyfill. There appears to be only one easily found option - https://github.com/oddbird/popover-polyfill. Going with the Popover API is highly preferable to adding this logic in core. It completely removes the need to decide on the proper z-index, and splitbutton CSS is only responsible for how it looks - not whether or not is it visible.

  1. Maintainership of the package: Issues appear to be responded to in a timely manner, and there is regular activity on the project. It looks like the maintainers use this in their own projects so I imaging there is incentive to continue for the likely-brief time it will take before native adoption renders this unnecessary
  2. Security Policies Nothing official that I could find, so I posted an issue requesting clarification https://github.com/oddbird/popover-polyfill/issues/110. The nature of the feature/polyfill does not introduce huge exploitation opportunities, but it would still be good to get some clarity on this.
  3. Expected release and support cycles This was asked in the same issue where I inquired about security info. This appears to release as-needed, which seems especially appropriate given the very-specific purpose of this polyfill and the fact that it will potentially be obsolete before Drupal 11 is even tagged.
  4. Code quality The job requirements of this polyfill are quite straightforward. The code is easy to read and largely self explanatory but there are decent comments where needed.CSS is used to manage visibility when there isn't a browser API isn't available to do it, and it does a good job of mimicking the native implementation specs.
  5. Dependencies added No runtime dependencies, dev dependencies are all popular build/lint/test tools + typescript.

API changes

TBD.

Original Proposed Resolution

Claro CSS for dropbutton items adds large gap of white space

$
0
0

Problem/Motivation

When a "Paragraphs (stable)" widget is used, which uses a long list of dropdowns, those items are only "hidden" with CSS, which means they are still present and causing a very long gap of whitespace at the end of the page.

Steps to reproduce

Create a component which uses the "Paragraphs (stable)" widget display type. Create or edit an item. See large white space gap.

Proposed resolution

Update the Claro theme CSS `dropbutton.css` file for `.dropbutton-wrapper:not(.open) .dropbutton__item:first-of-type ~ .dropbutton__item` items.

Temporary resolution is we added custom theme CSS to change this to `display: none;` but this should be fixed in the theme.

Screenshots attached.


Olivero: Focus outline does not accommodate long text in primary & secondary nav bar

$
0
0

Problem/Motivation

Focus outline for .secondary-nav__menu-link does not account for longer lengths of text in the secondary navigation menu.

Steps to reproduce

1. Go to your drupal site home page.
2. Edit a menu item in the secondary navigation (which contains My account, Log out) to a long text that would take up multiple lines.
3. Focus on that long menu item.

Proposed resolution

Change the focus outline height with something that would account for longer lengths of texts which require a bigger height for focus.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

The renderer throws away cache metadata from access result if it is not allowed

$
0
0

Problem/Motivation

When a render array sets $elements['#access'] to an AccessResultInterface instance, any cache metadata on that object is thrown away when the instance is not AccessResultAllowed.
If the access check was "allowed" the cache metadata bubbles up as it should, so content can be re-rendered in case of invalidation or contexts are different. If denied/neutral, no rendering happens, but also no bubbling, so only cache contexts/tags/max-age for those with access will influence what goes into the cache. The expected result would be that no matter which type of access result is returned, the cache metadata is kept so it can be re-evaluated for the next user.

Steps to reproduce

This was discovered while working on #2473873-111: Views entity operations lack cacheability support, resulting in incorrect dropbuttons as with that patch, some operation links appeared for the wrong user if someone with access visited a cached page before them, or the other way around, because the 'user' cache context added via the AccessResultInterface in the operation link's '#access' key.

The easiest way to reproduce this is with a controller returning a custom render array which sets $element['#access'] = AccessResult::allowed()->cachePerPermissions() for one user and $element['#access'] = AccessResult::forbidden()->cachePerPermissions() for another. Depending on which user views the page first you get different results after both of them have visited the page.

Proposed resolution

The renderer should bubble the cache metadata if it encounters an element which has $element['#access'] instanceof AccessResultInterface and the result is not allowed, near the start of ::doRender(), same as it does a few lines below if the result was allowed.

Remaining tasks

None

User interface changes

None

API changes

None

Data model changes

None

[policy] Service autowiring - decide approach for multiple service implementations based on the same class and different arguments

$
0
0

Problem/Motivation

As noted in #3325557-10: Enable more service autowiring by adding interface aliases to core modules, maybe we could exploit https://symfony.com/doc/current/service_container/autowiring.html#dealin....

This would help autowiring for cache bins and for loggers like e.g.

  cache.default:
    class: Drupal\Core\Cache\CacheBackendInterface
    tags:
      - { name: cache.bin }
    factory: ['@cache_factory', 'get']
    arguments: [default]
  Drupal\Core\Cache\CacheBackendInterface $cacheDefault: '@cache.default'

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Allow form redirects to ignore ?destination query parameter

$
0
0

Problem/Motivation

In #2767857: Add destination to edit, delete, enable, disable links in entity list builders we added destination query parameters to config entity lists and operations in Views. This unearthed the fact that some of our forms are not destination query compatible - we broke the image style user interface unexpectedly. See #2940165: [regression] Cannot add effects to image style via the UI.

The problem is that the destination param is set to win regardless of what a user does in the form. This means that any Drupal form can be redirected to somewhere using it.

As discussed in #2950759: Revert 2767857, right now, it is necessary to alter the global request object to disable a destination query arg based redirect override. That's complicated to understand and we shouldn't be doing something like that.

Older related issues are:
#579366: How many ways are there to redirect after form submission?
#1627654: drupal_redirect_form() should state that it is overridden by a destination in the request
#2325463: Destination URL breaks preview

Proposed resolution

We need a way to set a higher priority redirect on a form. So the developer can say actually regardless of the destination parameter go here because obeying the redirect makes no sense. The fix however shouldn't be tied to the forms system so the patch at the moment adds a new IgnoreDestinationRedirectReponse and the RedirectResponseSubscriber checks and doesn't apply the ?destination override if it is.

However since 90% of the redirects we are interested are from Forms the patch also adds helpers to FormState to make redirects behave like this.
FormStateInterface::getIgnoreDestination()
FormStateInterface::ignoreDestination($status)

Remaining tasks

Add more tests. One is currently provided by core/modules/image/src/Tests/ImageAdminStylesTest.php which proves this fixes #2940165: [regression] Cannot add effects to image style via the UI whilst bringing back the nice consistent UI behaviour of #2767857: Add destination to edit, delete, enable, disable links in entity list builders for Image Styles.

User interface changes

API changes

Data model changes

Check for existing subdirectory returns false positive under specific conditions

$
0
0

Problem/Motivation

When adding a file, the Drupal file system first checks to see if a file exists, and if not then it will check if the specified directory exists. If not, it will be recursively created.

There is a bug in the check for subdirectories. If creating a file that is nested more than two directories deep, the variable for the first depth of directory will not exist and will end up checking to see if the final subdirectory exists. If that final subdirectory matches an already existing folder, the function will incorrectly return a true result for that folder existing.

Reproduced on local using Docksal as well as on a new Pantheon site.

Docksal:
Apache 2.4.53 (Unix)
MariaDB 10.6.5
PHP 8.1.14
Drupal version 9.5.7

Pantheon:
NGINX 1.21.6
PHP 8.1
Drupal version 9.5.7
MariaDB 10.4

Steps to reproduce

  1. Create new Drupal 9 project (tested with Docksal default)
  2. Install basic site `drush site:install -y`
  3. Set the write location in /web/sites/default/settings.php
    $settings['file_public_path'] = '/custom-dir';
    Where "custom-dir" is any root directory
  4. Create the new file write location
    `sudo mkdir /custom-dir`

The bug can now be reproduced with the following:

$ drush php:eval 'var_dump(is_dir("public://foo"));'
bool(false)
$ drush php:eval 'var_dump(is_dir("public://foo/bar"));'
bool(false)
$ drush php:eval 'var_dump(is_dir("public://foo/custom-dir"));'
bool(true)

Proposed resolution

If the directory path does not exist, return FALSE instead of continuing checks.

diff --git a/core/lib/Drupal/Core/StreamWrapper/LocalStream.php b/core/lib/Drupal/Core/StreamWrapper/LocalStream.php
index b443096684..993a223021 100644
--- a/core/lib/Drupal/Core/StreamWrapper/LocalStream.php
+++ b/core/lib/Drupal/Core/StreamWrapper/LocalStream.php
@@ -132,6 +132,10 @@ protected function getLocalPath($uri = NULL) {
     $realpath = realpath($path);
     if (!$realpath) {
       // This file does not yet exist.
+      if (realpath(dirname($path)) === FALSE) {
+        // Invalid or missing directory
+        return FALSE;
+      }
       $realpath = realpath(dirname($path)) . '/' . \Drupal::service('file_system')->basename($path);
     }
     $directory = realpath($this->getDirectoryPath());

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Fix an edge case bug in verifying LocalStream file directories

Path module calls getInternalPath without checking if the url is routed

$
0
0

Problem/Motivation

I'm using a bundle class to override the toUrl() method on a particular node type. In particular, there's a link field that, if populated, will be used by the toUrl() method. The reason is that we want to allow cards to link to internal or external links (or no link whatsoever) as elegantly as possible. The code looks like this:

  public function toUrl($rel = 'canonical', array $options = []) {
    if ($rel === 'canonical') {
      if (!empty($this->field_link->uri)) {
        return Url::fromUri($this->field_link->uri);
      }
      else {
        return Url::fromRoute('<nolink>');
      }
    }
    return parent::toUrl($rel, $options);
  }

I can successfully create such a node and the behavior of toUrl is as hoped.

Unfortunately, editing the node is not so smooth. The path module throws an erro:

UnexpectedValueException: Unrouted URIs do not have internal representations. in Drupal\Core\Url->getInternalPath() (line 798 of core/lib/Drupal/Core/Url.php).

Drupal\path\Plugin\Field\FieldType\PathFieldItemList->computeValue() (Line: 33)
....

When I fix that by hacking core a bit then I get to the next exception:

UnexpectedValueException: Unrouted URIs do not have internal representations. in Drupal\Core\Url->getInternalPath() (line 798 of core/lib/Drupal/Core/Url.php).

Drupal\path\Plugin\Field\FieldWidget\PathWidget->formElement(Object, 0, Array, Array, Object) (Line: 19)
....

When I fix that then everything is grand.

These exceptions happen even if the url alias element is not on the node form display for this node type.

Steps to reproduce

See above

Proposed resolution

The path module needs to check that $entity->toUrl()->isRouted() in addition to its existing checks for !$entity->isNew() in a couple places.

Remaining tasks

Tips for manual testing

Apply the test-only patch.

Enable entity_test, path, and path_entity_test_external. (To enable test modules, add $settings['extension_discovery_scan_tests'] = TRUE; to your settings.php.)

Then go to /entity_test_external/add and create and edit these entities. See the errors.

Then apply the fix and see that creating and editing these entities works. And everything should still work for nodes and media, etc.

User interface changes

N/A

API changes

TBD

Data model changes

N/A

Release notes snippet

TBD

Add an exception/warning/assert/other when a #options value is overriden because #empty_options

$
0
0

Problem/Motivation

This comes from #3361695: Fix the documentation for #empty_value on Drupal\Core\Render\Element\Select and #1936636: Fix the documentation for #empty_value.

In form API, when the value of the property #empty_option is also present in #options array as a key, the value of #options for that key can be replaced by the value of the property #empty_value.

See the following explanation for details on how this happens: https://www.drupal.org/project/documentation/issues/1936636#comment-1505...

Steps to reproduce

Declare a form with the following element:

  $element = 
    '#type' => 'select',
    '#options' => [ 
      0 => 'zero', 
      1 => 'one', 
      2 => 'two'
    ],
    '#required' => TRUE,
    '#empty_value' => TRUE,
    '#empty_option' => "Some empty value"

When the form is rendered it will show three options:

"Some empty value", "one" and "two"

Instead of four:

"Some empty value", "zero", "one" and "two"

Proposed resolution

Detect this condition and raise an error or warning.

Assert was proposed, but as said in previous issues: "assert will only work when assertions are enabled. This can be the case for automatic testing but it is not on production environments. Given the dynamic nature of forms, it is possible that the case where #options is overriden only happens on certain situations".

Triggering and exception could be too drastic. Adding a warning will alert any developer debugging a form impacted by this condition.

If an error is preferred I would think on adding a try-catch at the form builder level to catch this error and other errors on the form, but that would be another task much bigger than this one.

Remaining tasks

Decide what to raise (exception, warning, assert or another solution).

User interface changes

None.

API changes

None.

Data model changes

None

Release notes snippet

Not needed.


CKEditor 5 toolbar items of multi-value field (typically Paragraphs) overflowing on narrow viewports and overlapping with node form's sidebar on wide viewports

$
0
0

Problem/Motivation

the toolbar items of ckeditor 5 is overlapping with the sidebar on the node form when it's being used in a multi-value field (or whenever the editor is being embedded in a table element?) and there are many toolbar items.

Steps to reproduce

1. Do a Drupal clean install. (I use https://simplytest.me/)
2. Navigate to a content type and create a field using ckeditor 5 and allow unlimited value.
3. Move the field to the top on the form display of the content type.
4. Add more items to the ckeditor.
5. Go to the create page of the content type and resize the browser down to around 1000px (depends on the number of the toolbar items)
6. See the overlapping issue.

Proposed resolution

https://github.com/ckeditor/ckeditor5/issues/11334→ we propose to tweak the default styling of CKEditor 5: removing flex-wrap: nowrap seems to fix the issue.

jQuery UI dialog modals repositions incorrectly on window resize when there is a off canvas rendered

$
0
0

Problem/Motivation

If you have a jQuery UI dialog modal (a dialog having the modal configuration set to TRUE) and a Off canvas rendered at the same time (i.e. the dialog is opened via the Off canvas), the modal is repositioned incorrectly when resizing the window.

Here is an example using Layout Builder and the contrib. module Layout Builder Modal:

(thanks to kevinfunk for providing the GIF in #3074302)

The expected behaviour here would be that the modal keeps being centered on window resize.

You can also reproduce this behaviour in Drupal core:

<a href="/node/add/page" class="use-ajax" data-dialog-options='{"width": 500,"modal": true,"autoResize":true}' data-dialog-type="dialog">Dialog</a>

            <a href="/node" class="use-ajax" data-dialog-renderer="off_canvas" data-dialog-type="dialog">Off canvas</a>

If you only would open the Dialog, it would resize and the position would be as expected. But if you first open the off canvas, and then the dialog the same behaviour as with Layout Builder Modal.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Make it easier to enter multiple values to fields allowing unlimited values

$
0
0

Problem/Motivation

#2521800: List key|label entry field is textarea, which doesn't give guidance towards the expected input changed the options field types to use similar pattern that is used for fields allowing unlimited field cardinality. This is nice because the new UI makes it clear what the user needs to enter, as well as automates generating the machine names when possible. However, what could be improved is that adding multiple values to the field requires more steps now than it did before.

Proposed resolution

Allow adding a new value to a list of fields by pressing enter on the last item. When pressing enter on a value that is not the last item, navigate to next item instead of adding a new item.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Language-specific aliases only work with url-based language negotiation

$
0
0

Updated: Comment #16

Problem/Motivation

The original poster, Dave Cohen, reported this problem running D6:

I get Page not Found errors with pathauto when locale is enabled. The aliases get associated with "English" and never work. If I manually edit an alias, changing it to "All languages", then it works. Not sure whether this is bug or my configuration, would appreciate help either way.

The problem was simplified (the Pathauto module is not required) and reproduced in D7 and D8. The configuration quirks in the original poster's site do not seem to be relevant.

Steps to reproduce (from #11 and #13)

Using Drupal core 7.21 and Pathauto 7.x-dev: Elaborating on the steps to reproduce in D7 and D8 (based on the thread above):

  1. Configure Drupal:
    • D7: enable the core Locale and Content Translation modules.
    • D8: enable the core Language and Content Translation modules
  2. D7/D8: visit admin/config/regional/language, press "Add language" and select "Spanish" from the drop-down
  3. D7/D8: press the "Detection and Selection" tab aka as admin/config/regional/language/configure
  4. D7/D8 In the column of tick boxes make sure that Detection Method URL is unticked while Detection Method Session is ticked; leave the remaining tickboxes set to what they are
  5. Configure Content Types:
    • D7: on the content type settings page for Article admin/structure/types/manage/article tick the Publishing options tab and then the Enabled radio button under "Multilingual support."
    • D8: visit /admin/config/regional/content-language and tick the Content box (Custom Language Settings) as well as the Article box in the Translatable column.
  6. D7/D8: add content: node/add/article, specify an alias under "URL path settings" and in the Language drop-down select "English". Save
  7. D7/D8: Verify that you can View the page via the URL alias
  8. D7/D8: Edit the page, changing the language selector to Spanish. Save.
  9. You can now no longer View the page via its URL alias, although node/... still works.

Is this the problem or a feature?? It's a problem, at the very least it s counterintitutive and not clearly documented…

Proposed resolution

In #8 SiliconMind proposed an explanation of the problem:

I think that this happens because drupal_lookup_path from path.inc uses global $language_url variable to get current language. But the problem is that $language_url is set to default language if language was not set via url. This is wrong because language could be selected through user preferences or browser language.

The real problem is that url alias should work always regardless of selected language!

Workaround for this is to alter drupal_lookup_path queries to search url_alias table for entries that match provided alias but not necessarily match language that is provided by $language_url variable. The goal is to always return alias source if it exists regardless of selected language.

Remaining tasks

  1. Finish charactarizing the problem and determine if we have one issue or several.
  2. Decide what the desired behavior is.
  3. Create a patch.
  4. Design tests.
  5. Update documentation
  6. Backport to D7.

User interface changes

(New or changed features/functionality in the user interface, modules added or removed, changes to URL paths, changes to user interface text.)

There will clearly be some…

Once this is sorted out it would be very good to document the behavior and make it easily accessible from the language configuration pages.

Another nice change would be to include the language of a page in the content listing on multi-lingual sites (although this should probably be a separate issue).

API changes

At the moment there do not appear to be any.

Original report by Dave Cohen

Rather than "hijack"#320710: Pathauto URL Alias leading to Page Not Found, submitting new issue. I find I get Page not Found errors with pathauto when locale is enabled. The aliases get associated with "English" and never work. If I manually edit an alias, changing it to "All languages", then it works. Not sure whether this is bug or my configuration, would appreciate help either way. More about the problem: Drupal is unilaterally modifying paths specified by the content author, without notifying the content author.

Proposed resolution

  1. Do not modify user-supplied paths.
  2. If it's absolutely necessary to modify user-supplied paths, at least inform the user.
  3. Avoid 404'ing user-supplied paths -- make them redirect to the changed path, maybe?

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue categoryBug because it is a functional error in the system preventing valid use cases
Issue priorityMajor because significant repercussions, impacting many people (at least 3 other issues for this have been opened, possibly more).

Content moderation workflow changes against one language affect translations too

$
0
0

Problem/Motivation

Steps to reproduce from #3117751: Unpublished revisions of multilingual node rollback unpublished revision of another language to default revision:

Let's have a multilingual site & node with more than 1 language (i.e. node is translatable): EN & DE.
Also enable Workflows module to have draft & published states.

We have 2 published revisions for EN & DE languages.
Then we create new revision of node with EN language but do not publish. Database containt up-to-date value for e.g. field body.
After it we create new draft revision of DE node.
Database contains value for body field for EN node from previous published (default) revision.
Drafts with different languages of one node should not revert another draft to previous state.
It also affects JSON:API.
There are a lot of possible related issues I guess:
#2875861: Optimize updating data and revision data tables
#3023194: [PP-2] Add parallel revisioning support
#2795279: [PP-2] [META] Revisions support
#2833084: $entity->original doesn't adequately address intentions when saving a revision
#2833049: ContentEntityBase::hasTranslationChanges will compare a forward revision with the default one instead of the newest forward revision
#2477419: Codify mechanism to set a forward revision as the default revision
#2960887: Do not create field revisions when field data hasn't changed
#2769741: Node revisions page might not list a default revision
#3056440: Cannot add new translation if the latest affected translation revision of the source language is older than the default revision
#3080995: EntityRepository::getActive does not return a translations most recent revision
#2815949: It is not possible to know if a revision was once the default
#2766957-176: Forward revisions + translation UI can result in forked draft revisions - potential root cause

How to reproduce

  • 1. Add 2 languages to site (EN and any one).
  • 2. Make "Article" node revisionable & translatable.
  • 3. Create Moderation Workflow with: draft, review, published states.
  • 4. Create Published revision of node with default language: body field text = "published default"
  • 5. Create Draft revision of node with default language: body field text = "draft default"
  • 6. Verify database table "node_revision__body", created node has body_value = "draft default" for default (en) language
  • 7. Create Published revision of node with non-default language: body field text = "published translation"
  • 8. Create Draft revision of node with non-default language: body field text = "draft default"
  • 9. Verify database table "node_revision__body", created node has body_value = "published default for default (en) language

Visually database will look like:
revisions
Revision 9659 contains new EN content but reverts RU to previous published.
Revision 9660 contains new RU content but reverts EN to previous published.
Revision 9661 contains new EN content but reverts RU to previous published once again.

Original report: I am using Content moderation, Workflows, Language and Content translation core modules in Drupal 8.6.4. I have implemented workflow on Basic page with states like (Draft, Audit, Review, Pre Publish and Publish). Now I am creating a Test content in English as well as in Spanish language and pass all the workflow states and publish the content in both language. Now when i try to update the moderation state of both of these content to Draft one of them gets auto published, but inside the edit mode it shows current state as Draft only for both of the content which is correct. (Here, we are refering to content_moderation_state_revision table in DB)

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Viewing all 294899 articles
Browse latest View live


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