See #2729663: Fragment link pointing to <textarea> should be redirected to CKEditor instance when CKEditor replaced that textarea. Same problem with CKEditor 5.
\Drupal\Tests\ckeditor\FunctionalJavascript\CKEditorIntegrationTest::testFragmentLink().On a site with Content Translation enabled, Media entities will typically be translated. This is because alt and title texts for images need to be translated, and also because the media file itself may need to be different across languages, such as images that include text or videos that contain speech.
In such a set-up, the reference fields on content that point to media are not set to be translated: all the language versions of one node refer to the same media entity, which itself has translations. So when looking at the German version of a node, you see the German version of the image; look at the French version of the node and you see the French version of the same image.
The workflow for translating media entities when using the Media Library to attach media to content appears to be this:
1. Edit or create a node
2. Open the media library to create media
3. In the media library pop-up, add a new media entity. There's no possibility of translating it here.
4. Save the media entity and save the node
5. Add a translation to the node
6. The media field isn't shown in the node translation edit form, because the media field isn't itself translatable. So you don't have anything that lets you translated the media here
7. The only thing AFAICT is to now go to Admin > Content > Media, look in the list for the media entity that you created, and edit it.
Could the UX for this task be improved?
Steps to reproduce: just change the body field cardinality to unlimited, create a new node and press the "Add another item" button.
Found while working on #362021-37: field_attach_prepare_translation needs to be updated for D7 API.
Because Drupal 10 does not support IE11, we can make better use of CSS variables and holistically refactor components to make them more understandable, extendable, and resilient.
This issue will serve as a moderately complex first try in doing so. The overall appearance and functionality of the tabs will not change, however, the code will be understandable, extendable, future-proof, and resilient.
When a required field is missing when creating content, there should be a red border around the text area. This is missing in the new CKEditor5.
See screenshots:
Expected (old CKEditor)
Actual (CKEditor5)
1. Make sure that body field on basic page (or whatever content) /admin/structure/types/manage/page/fields/node.page.body
is set as required.
2. Edit content and fill in everything except the body field so the error will appear
3. Hit Save
Add a class that has the red line border css to the element with the error that will mark it red
As mentioned in the parent issue #3238306: [META] Where possible, refactor existing jQuery uses to vanillaJS to reduce jQuery footprint, we are working towards reducing our jQuery footprint. One of the ways to accomplish this is to reduce the number of jQuery features used in Drupal core. We have added eslint rules that identify specific features and fail tests when those features are in use.
There are (or will be) individual issues for each jQuery-use eslint rule. This one is specific to jquery/no-text, which targets the jQuery text function.
core/.eslintrc.jquery.json Change "jquery/no-text": 0, to "jquery/no-text": 2, to enable eslint checks for uses of jQuery .text(). With this change, you'll be able to see uses of the undesirable jQuery feature by running yarn lint:core-js-passing from the core directorycore/scripts/dev/commit-code-check.sh so the DrupalCI testing script can catch this jQuery usage on all files, not just those which have changed# @todo Remove the next chunk of lines before committing. This script only lints
# JavaScript files that have changed, so we add this to check all files for
# jQuery-specific lint errors.
cd "$TOP_LEVEL/core"
node ./node_modules/eslint/bin/eslint.js --quiet --config=.eslintrc.passing.json .
CORRECTJQS=$?
if [ "$CORRECTJQS" -ne "0" ]; then
# No need to write any output the node command will do this for us.
printf "${red}FAILURE ${reset}: unsupported jQuery usage. See errors above."
STATUS=1
FINAL_STATUS=1
fi
cd $TOP_LEVEL
# @todo end lines to remove
Add the block about 10 lines before the end of the file, just before if [[ "$FINAL_STATUS" == "1" ]] && [[ "$DRUPALCI" == "1" ]]; then, then remove it once all the jQuery uses have been refactored.
.text() to use Vanilla (native) JavaScript instead.I have updated my site completely to the newest 9.3 version. In this I have a node with paragraphs as my theme homepage. And theme homepage gives WSOD with the following error on latest 9.3:
The website encountered an unexpected error. Please try again later.
TypeError: Argument 1 passed to Drupal\Core\File\FileUrlGenerator::generateString() must be of the type string, null given, called in httpdocs/web/sites/default/files/php/twig/61b7c1cc12197_paragraph--view_referance_kTM91Di4YhANCpjtiZ2FlHIET/OWkkQEG98F61u897Zzc3agnP4Cd1gZmHLd6BGlNRCH0.php on line 41 in Drupal\Core\File\FileUrlGenerator->generateString() (line 58 of core/lib/Drupal/Core/File/FileUrlGenerator.php).
After some research I removed all paragraphs from the node, and then the WSOD and error is gone.
When I add one custom-html paragraph with just the word 'test' the WSOD and error is back again.
I tried adding this https://www.drupal.org/files/issues/2020-01-06/added_empty_check_on_uri-...
to to /lib/Drupal/Core/File/FileUrlGenerator.php but error still stays.
Proposed solution, take care that Argument 1 is not null.
Greetings and thanks in advance for looking into this,
Martijn
This issue is a backport of #2946: Login fails and no warning is issued if cookies are not enabled, an 18 year old issue, that was committed to Drupal 9.3.x on 2021-06-24.
Copied from the issue summary:
Drupal login requires user browser cookie support. However, in the case that a user does not have cookies enabled and attempts to log in, no error message is given. Instead, the user is returned to the /user/{uid} page with 403 error code. As well as being a bug, the lack of cookie notification constitutes a key usability barrier in that users who hit the bug have no cue as to what is needed in order to log in.
Related issue at install time: #791004: Installer does not warn the user that cookies must be enabled with the correct cookie domain (and fails when they aren't)
There is a patch for Drupal 7 in #2946-76: Login fails and no warning is issued if cookies are not enabled that may still be valid.
Copy patch from previous issue for review, further comments and work as needed.
Noted in #3130606-34: MockBuilder::setMethods is deprecated in PHPUnit8 and removed from PHPUnit10, the usage of ::onlyMethods([]) smells like we do not need a mocks sometimes but rather use the acutal object.
Currently, when https://oembed.com/providers.json is fetched to generate a list of available oEmbed providers, there is no opportunity to alter the list of providers.
This would be useful in scenarios such as 1) Peer Tube and 2) oEmbed providers that may be organization-specific. Peer Tube is a decentralized video platform. The user can search videos across multiple instance of PeerTube with different domain names. Re custom oEmbed providers, the University of Nebraska-Lincoln hosts its own video service, which will soon support oEmbed. This functionality is needed by this organization.
Provide hook_oembed_providers_alter(). (Media already provides hook_oembed_resource_url_alter()).
None.
Adding hook_oembed_providers_alter().
None.
TBD
I have studied the code from the oEmbed system in the core and I have discovered that it is based on the list provided by https://oembed.com/providers.json
This is a good list to start but I am wondering how to add a provider to this list?
You can host a new file with the additional services and change the settings "oembed_providers_url". But this method is really complicated to just support more providers.Moreover I am creating this issue in order to support PeerTube which is a decentralized video platform. The user can search videos across multiple instance of PeerTube with different domain names. Such a complicated way to support a new provider is just impossible for a simple contributor.
In order to resolve this problem:
- The user should be able to override the default URL. The issue already exists for another reason: #2999018
- We should be able to alter the provider list by using a hook. What do you think about adding an alter call in the getAll function from Drupal\media\OEmbed\ProviderRepository?
It is currently not possible to configure an audio file using FileAudioFormatter to be muted by default.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/audio#Attributes
This configuration currently exists in FileVideoFormatter and works properly. Since both the audio and video formatters share FileMediaFormatterBase, moving the muted setting to that class provides this option to both formatters without breaking any existing config for videos.
Sometimes a render array includes the value of a state variables, it would be good to be able to provide a cache tag which tells Drupal to invalidate caching of said render array when that state variable changes.
Please see [the question "What cache tags can be triggered by a change in state variables?" on Drupal Answers](https://drupal.stackexchange.com/questions/309121/what-cache-tags-can-be...).
Invalidate cache tags when state variables change.
Discussed at the migrate meeting.
The source_module and destination_module are needed for Drupal and should not be in Migrate, they probably should be in Migrate Drupal. Let's see what needs to be done to get them out of Migrate.
I have a feeling that this is a duplicate even though I couldn't find a similar issue.
Authenticated search works on my site, but anonymous search fails. I've searched for this kind of problem, and found a few leads, but nothing has worked for me. I use Bootstrap (which may or may not matter). I'm technical, but not in this area.
Visit my website, https://ReadingMA.us, anonymously. Use the Search button on the RHS to search for anything. I doesn't work.
Now login as TestOne, password = 4zLWMVjL",=jD`6P
Try searching again. It works.
#3036593: Add 'drupal_internal__target_id' to JSON:API representation of entity reference fields, because that can't be retrieved from the target resource for target entity types without corresponding resources added a meta.drupal_internal__target_id value on the relationship identifier for entity reference fields; this is super helpful to client-side implementations to filter by Drupal IDs, rather than UUID.
There are some circumstances (user IDs, for instance) where I would like to hide Drupal's internals, entirely. Serial fields in particular can leak information relating to the site's total user count, or the relative age of a user, or whatever, from the ID.
This isn't a huge issue, and enumeration of Drupal users (and other entities) by ID is not considered a security risk per se, but this value's automatic inclusion makes it harder to build a site that is API-forward in using UUIDs everywhere.
Because json:api module exposes a very limited PHP API, this is difficult to adjust in contrib or custom code.
It might be interesting to couple this with an opt-out of all the drupal_internal__* meta members, but this may be too edge a use case to make sense in core. The issue is mostly that this is pretty difficult to opt-out of without hacking core, since there is no real hookpoint to adjust this.
Drupal uses a new standalone library to provide the once functionality. This library is published on npmjs as the @drupal/once package. The package exposes a js module and a version compatible with browsers that don't support js modules (the "iife" version). This iife version exposes a global variable named "once", making window.once the entrypoint of the functionality, this is the version drupal core uses since IE11 support is necessary.
Some third party scripts/libraries can already declare a window.once that Drupal core ends up using instead of the intended @drupal/once script, causing errors in almost all behaviors since most of them use once.
Add one of the following in some library definition that gets loaded on the page:
https://unpkg.com/alpinejs@3.x.x/dist/module.cjs.js: { attributes: { defer: true }, type: external, process: false }
https://cdn.flowplayer.com/releases/native/stable/plugins/chromecast.min.js: { attributes: { defer: true }, type: external, process: false }
Here the defer means those files will be loaded right before the behaviors are executed and after the once library has been loaded (so window.once will never point to the @drupal/once script).
None yet.
Find a good solution
Write tests
Upon upgrading to 9.3, we are seeing a number of console errors for Uncaught TypeError: once(...).forEach is not a function from various modules including tour, toolbar, big_pipe, views, and contextual. One such example is ajax_view.js.
9.3.x, line 70: https://git.drupalcode.org/project/drupal/-/blob/9.3.x/core/modules/view...
once('exposed-form', this.$exposed_form).forEach($.proxy(this.attachExposedFormAjax, this));
Doing some logging, it looks like the calls are not always broken. When they work, once(...) appears to be an array. When they are broken, however, once(...) looks to be the Window, which is not iterable. I verified this in both ajax.js and big_pipe.js.
It seems that the culprit is that jquery.once.bc.js sets once() as a global via window.once, and if another script is loaded on the page that also sets this global then subsequent invocations of once() by core fire off this replaced version of the function, causing things to break.
Two scripts identified so far to cause the issue are https://unpkg.com/alpinejs@3.x.x/dist/module.cjs.js and https://cdn.flowplayer.com/releases/native/stable/plugins/chromecast.min.js, although there are likely others as well.
To reproduce, create a new project using the "standard" profile and add a script which modifies window.once to core/once in core.libraries.yml (or, realistically, probably to any library) as in:
once:
remote: https://git.drupalcode.org/project/once
version: "1.0.1"
license:
name: GNU-GPL-2.0-or-later
url: https://git.drupalcode.org/project/once/-/raw/v1.0.1/LICENSE.md
gpl-compatible: true
js:
assets/vendor/once/once.min.js: { weight: -19, minified: true }
https://cdn.flowplayer.com/releases/native/stable/plugins/chromecast.min.js: { attributes: { defer: true }, type: external, process: false }
#or
https://unpkg.com/alpinejs@3.x.x/dist/module.cjs.js: { attributes: { defer: true }, type: external, process: false }
dependencies:
- core/drupal.element.matches
and then navigate to the homepage. Errors will be thrown by ajax.js and others.
Instead of setting window.once and calling to as a global, attach it to the Drupal global as Drupal.once or remove it from the global namespace by other means so as to avoid conflicts with third-party libraries.
Continue the conversation in Slack. Thank you for showing up and contributing!
If you have additional questions or comments, please post them here or on the meeting agenda issue.
Slack link: https://drupal.slack.com/archives/C01PNQZ8Q6A/p1629734433034300
When attempting to edit or delete a translation using the generated operation links on the translation overview page, the user is always taken to a route pertaining to the default translation.
Make the operation links on the translation overview page link to routes specific to each translation.
(An inline code comment mentions that the behavior of linking to pages for the default translation was intended for the source language only because in that case there are not specific translation pages, re-enforcing the notion that this is in fact a bug.)
TBD after subsystem maintainer review.
None.
None.
config.image.resizeUnit to '%' not working in the backend editor after changes to images were made and saved.
Front end working as expected, but when going back to the editor to make more updates, images sizes not showing properly.
When inspecting element image, style width has both % and px added to the width number.
1. add image
2. resize image
3. save
4. check in the front end. It should look good
5. go back to the editor. Image is not shown in the correct size. when inspected: style="width:50%px;"
6. Image in the front end saved and shown correctly style="width:50%;"
7. problem only in the editor. in the backend