- 🇺🇸United States DiegoPino
This bug is still around (6 years!) in 11.x. but both patches are failing bc the tests are not passing once the actual "excluded" elements are no longer part of the raw data and thus removed from the URLs
e.g here
https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/views...and here at
ExposedFormRenderTest::testExposedFormRawInputThe Layout builder one might be just layout builder failing in 10.1 so all needs to be rebased to 11.x-dev
@quietone since you are already in this, do you want to tackle that or you ok with me giving it a shot? - 🇺🇸United States justcaldwell
I just reproduced the basic behavior described in #63 on a fresh install of Drupal 10.2.6., specifically:
- Enable Media and Media Library
- Add a 'Remote Video' Media entity (Media source set to 'Remote video', YouTube and Vimeo providers enabled).
- Add Media Library embeds to the Basic HTML text format
- Create a Basic Page node and use the Media Library to create embeds from any oEmbed source.
On the upside, a patch based on MR 459 still applies to 10.2.6 (with a fair amount of fuzz) and seems to introduce validation of allowed providers.
- 🇺🇸United States alison
I know this was marked as a duplicate, but 🐛 Restrict access to empty top level administration pages Fixed is fixed and, as far as I can tell, included in 10.2, and I still have a "Workflow" link in my admin menu, even with nothing enabled that goes in there, and therefore just takes me to an empty "access denied" page. (FWIW, I'm logged in as user 1.)
Am I conflating stuff, is what I'm describing actually something else and I should submit a new issue, or?
- 🇺🇸United States justcaldwell
I'm a bit concerned that the focus on video in the issue summary doesn't make it clear that the problem is broader. Based our our recent experience, it appears any oEmbed-based Media entity will accept ANY valid oEmbed resource URL when the entity is created via the Media Library oEmbed form. This includes oEmbed providers that have not been enabled/allowed for the site.
Our site has two oEmbed-based Media entities. The "standard" Remote Video (YouTube/Vimeo), and a Remote Audio entity that allows SoundCloud and Spotify providers via the oEmbed Providers → module. I recently noticed that a user was somehow able to create a Remote Audio entity using a Vimeo video URL.
When I attempted to replicate via the Remote Audio media add form, I got the expected "Vimeo provider is not allowed." That led me to Media Library (embeds), where I was able to create a Remote Audio entity using a video provider URL with no validation errors.
So I tried creating a Remote Video entity using a SoundCloud URL — yep, that works in Media Library, too.
Then I started experimenting with various providers from the oEmbed providers list. ISSUU, SlideShare, TikTok — they all worked using either the Remote Audio or Remote Video entity. None of those providers are enabled for any entity on our site.
- 🇺🇸United States smustgrave
Got bit by this nightmare again over in better_exposed_filters.
Cleaning up the tags but still leaving in NW for the tests.
- 🇺🇸United States dww
p.s. I tried triggering the test-only GitLab CI job, but it's all confused by the #2640994 changes. Probably test-only via GitLab won't tell us much until that issue lands. However, locally, if I revert the fix and just run the new test, I see:
There was 1 failure: 1) Drupal\Tests\views\Kernel\Handler\ArgumentSummaryTest::testArgumentSummary Failed asserting that '1 (4) 2 (2)' contains "phk5vh2z (4)".
Which is exactly what we'd expect. The summary is only showing term IDs and the node counts, not the term labels...
- 🇺🇸United States dww
I searched (a lot), and didn't find any test coverage of argument summaries. So I wrote a Kernel test for this on a flight earlier today. The MR still has a ton of changes since this needs 🐛 Fix label token replacement for views entity reference arguments RTBC to land. But I squashed that into a single commit in this issue fork, so it'll be easy to rebase that out of here once that issue lands. If anyone wants to review, the actual changes are just 3 commits:
https://git.drupalcode.org/project/drupal/-/merge_requests/7678/diffs?co...
https://git.drupalcode.org/project/drupal/-/merge_requests/7678/diffs?co...
https://git.drupalcode.org/project/drupal/-/merge_requests/7678/diffs?co... - 🇨🇦Canada mparker17 UTC-4
On the plus side, though, it seems like tests are passing in the merge request as it is now.
- 🇨🇦Canada mparker17 UTC-4
Re: #113 you could apply the patch from that other issue to core using composer-patches and then use it in this issue, yes.
@bradjones1 Hmm... could you explain how to do this, or point me towards some documentation?
Aside: in order to change this for !8101, I'd have to drop all the commits in the 📌 Adding GIN and GIST indexes to PostgreSQL databases RTBC branch (or re-create the branch), update composer.json to apply the patch, then re-apply the commits specific to this branch... which is fine, but I don't want to force-push until I know it's going to work, and local testing doesn't seem to work. For simplicity below, the logs will assume I'm re-creating the branch.
I've set up a dev environment using justafish/ddev-drupal-core-dev...
$ git clone --branch 11.x https://git.drupalcode.org/project/drupal.git d10-core $ cd d10-core $ ddev config --project-type=drupal10 $ ddev start $ ddev corepack enable $ ddev get justafish/ddev-drupal-core-dev $ ddev restart $ ddev composer install
... as I expected, it didn't seem like cweagans/composer-patches was required by anything...
$ ddev composer depends 'cweagans/composer-patches' In BaseDependencyCommand.php line 100: Could not find package "cweagans/composer-patches" in your project
... so I tried installing cweagans/composer-patches, but that failed because, I guess, core references itself in its own composer.json?
$ ddev composer require 'cweagans/composer-patches:^1' ./composer.json has been updated Running composer update cweagans/composer-patches > Drupal\Composer\Composer::ensureComposerVersion Loading composer repositories with package information Updating dependencies Your requirements could not be resolved to an installable set of packages. Problem 1 - Root composer.json requires drupal/core 1.0.0 (exact version match: 1.0.0 or 1.0.0.0), found drupal/core[dev-main] but it does not match the constraint. Problem 2 - Root composer.json requires drupal/core-project-message 1.0.0 (exact version match: 1.0.0 or 1.0.0.0), found drupal/core-project-message[dev-main] but it does not match the constraint. Problem 3 - Root composer.json requires drupal/core-vendor-hardening 1.0.0 (exact version match: 1.0.0 or 1.0.0.0), found drupal/core-vendor-hardening[dev-main] but it does not match the constraint. Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions. Installation failed, reverting ./composer.json and ./composer.lock to their original content. Composer [require cweagans/composer-patches:^1] failed, composer command failed: exit status 2. stderr=
So I tried simply adding the patch to composer.json...
$ ddev composer config --json extra.patches.'drupal/core' '{"#3397622, !5839 Adding GIN and GIST indexes to PostgreSQL databases": "https://git.drupalcode.org/project/drupal/-/merge_requests/5839.diff"}' $ git diff diff --git a/composer.json b/composer.json index b56c8cec3e..e30ad42bdf 100644 --- a/composer.json +++ b/composer.json @@ -96,6 +96,11 @@ " and not intended to be used for production sites.", " See: https://www.drupal.org/node/3082474" ] + }, + "patches": { + "drupal/core": { + "#3397622, !5839 Adding GIN and GIST indexes to PostgreSQL databases": "https://git.drupalcode.org/project/drupal/-/merge_requests/5839.diff" + } } }, "autoload": {
...seems fine so far, so lets apply the patch...
$ ddev composer update drupal/core > Drupal\Composer\Composer::ensureComposerVersion Loading composer repositories with package information Updating dependencies Your requirements could not be resolved to an installable set of packages. Problem 1 - Root composer.json requires drupal/core 1.0.0 (exact version match: 1.0.0 or 1.0.0.0), found drupal/core[dev-main] but it does not match the constraint. Problem 2 - Root composer.json requires drupal/core-project-message 1.0.0 (exact version match: 1.0.0 or 1.0.0.0), found drupal/core-project-message[dev-main] but it does not match the constraint. Problem 3 - Root composer.json requires drupal/core-vendor-hardening 1.0.0 (exact version match: 1.0.0 or 1.0.0.0), found drupal/core-vendor-hardening[dev-main] but it does not match the constraint. Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions. Composer [update drupal/core] failed, composer command failed: exit status 2. stderr=
... same as before.
What about just updating the lock file?
$ ddev composer update --lock > Drupal\Composer\Composer::ensureComposerVersion Loading composer repositories with package information Updating dependencies Your requirements could not be resolved to an installable set of packages. Problem 1 - Root composer.json requires drupal/core == 11.9999999.9999999.9999999-dev (exact version match), it is satisfiable by drupal/core[11.x-dev] from composer repo (https://repo.packagist.org) but drupal/core[dev-main] from path repo (core) has higher repository priority. The packages from the higher priority repository do not match your constraint and are therefore not installable. That repository is canonical so the lower priority repo's packages are not installable. See https://getcomposer.org/repoprio for details and assistance. Problem 2 - Root composer.json requires drupal/core-project-message == 11.9999999.9999999.9999999-dev (exact version match), it is satisfiable by drupal/core-project-message[11.x-dev] from composer repo (https://repo.packagist.org) but drupal/core-project-message[dev-main] from path repo (composer/Plugin/ProjectMessage) has higher repository priority. The packages from the higher priority repository do not match your constraint and are therefore not installable. That repository is canonical so the lower priority repo's packages are not installable. See https://getcomposer.org/repoprio for details and assistance. Problem 3 - Root composer.json requires drupal/core-vendor-hardening == 11.9999999.9999999.9999999-dev (exact version match), it is satisfiable by drupal/core-vendor-hardening[11.x-dev] from composer repo (https://repo.packagist.org) but drupal/core-vendor-hardening[dev-main] from path repo (composer/Plugin/VendorHardening) has higher repository priority. The packages from the higher priority repository do not match your constraint and are therefore not installable. That repository is canonical so the lower priority repo's packages are not installable. See https://getcomposer.org/repoprio for details and assistance. Composer [update --lock] failed, composer command failed: exit status 2. stderr=
... apparently not!
What if I try running GitLab CI tests locally → ?
$ alias drupal-ci-local='gitlab-ci-local --remote-variables git@git.drupal.org:project/gitlab_templates=includes/include.drupalci.variables.yml=main --variable="_GITLAB_TEMPLATES_REPO=project/gitlab_templates"' $ drupal-ci-local ... FAIL 📦️ Composer > Invalid version string "HEAD-dev" > > validate [--no-check-all] [--check-lock] [--no-check-lock] [--no-check-publish] [--no-check-version] [-A|--with-dependencies] [--strict] [--] [<file>]
... so I'm not sure what to do next.
- 🇬🇧United Kingdom scott_euser
Looks like the issue summary needs an update? Drupal 11 with default Olivero theme, no changes from clean install other than turning on twig.config debug to true now results in this which appears correct:
The selected customisation comes from olivero.theme:
function olivero_theme_suggestions_menu_alter(&$suggestions, array $variables) { if (isset($variables['attributes']['region'])) { $suggestions[] = 'menu__' . $variables['attributes']['region']; } }
For the region 'primary_menu'. Is there a step I am missing to reproduce?
- 🇺🇸United States mfb San Francisco
@dsnopek I would suggest backporting the actual accepted patch, assuming you find that it works on Drupal 7
- 🇨🇦Canada mparker17 UTC-4
> Re: #113 you could apply the patch from that other issue to core using composer-patches and then use it in this issue, yes.
I merged in the commits, but that idea sounds be a lot easier to review, so I'm going to try that shortly.
- First commit to issue fork.
- @mparker17 opened merge request.
- 🇺🇸United States nicxvan
Can you please add those changes to the merge request? People can then generate local patches as needed and the core team uses the actual mr for testing and merging.
- 🇺🇸United States Adrianm6254
I tried MR !5005 and it did not work. I was able to use #21 successfully.
I am on 10.2.6 using php 8.2.18
Thanks
- 🇫🇷France 5
Maybe we can refactor this cancel confirm route so it asks your password one last time.
Something like changing the link form cancellation_url to /user/login?destination=cancellation_url, which should transparently
- if not connected, makes the user land on user login form instead of unattended 403 (making it understand it may login in order to confirm the cancellation of its account)
- if connected, makes the user land to the cancellation confirmation page
?
This is a starting point to solve the issue. Though it should work for common use cases. But, for now, it will not work as expected if 'Exclude' option enabled. It should be possible to implement this as well using subquery. Also tests needed.
I've started issue fork and attaching the patch for 11.x. And, as I can see, it can be used with 10.2 too.
- last update
2 days ago Patch Failed to Apply - 🇺🇸United States sapetm
Sorry folks, third time's the charm, or something like that. I uploaded the wrong patch file with my other two comments. This is the patch I am using for Drupal 10.2.6 and PHP 8.1.27. It is identical to the patch in comment #102 but with the addition of an array_unique() in the second hunk when setting the value of the $suggestions array in the render function. This fixes the issue for us. Hope it helps!
Eugene Bocharov → made their first commit to this issue’s fork.
- 🇺🇸United States smustgrave
I'd be lying if I said I fully understand the view config update (not one of the 5 haha) but running the test-only feature the tests for the update are failing as expected
1) Drupal\Tests\views\Functional\Update\EntityArgumentUpdateTest::testViewsFieldPluginConversion Failed asserting that two strings are equal. --- Expected +++ Actual @@ @@ -'entity_target_id' +'numeric'
Can see the full list of expected test failures here https://git.drupalcode.org/issue/drupal-2640994/-/jobs/1604882
So believe the addition of that is good
- 🇺🇸United States bnjmnm Ann Arbor, MI
If we're running into an infinite recursion issue, I recommend first finding where the recursion is occurring. This
We already know that there is an infinite recursion problem when
#type
is set in the render array.This is most likely due to a condition that executes code only when
#type
is present. The two most likely ways PHP would check for the presence of#type
areisset($foo['#type'])
or!empty($foo['#type'])
We can use a regular expression to find places where these conditions might be set
[^\!]isset\(.*\['#type'\]\)
Will look for an "isset" call without a preceding exclamation point, followed by an array path that ends#type
. The regex could be even more precise, but just this narrows things down to only 9 places this could be happening.
Most of the results can be ruled out because they are in modules/themes that don't need to be running for this error to occur, they are in tests, or it belongs to a class for a feature that is unrelated to the issue.Expand the results and you can rule out additional possibilities:
This leaves only 5 possible places, making it pretty easy to check each with an xdebug breakpoint, and see which condition is getting hit infinite times.
If I place the breakpoint in the Renderer.php condition, it appears to loop infinitely when it hits an element with a
form_element_label
#theme.Without even having to know that much about the render system, just a little bit of PHP / regex / xdebug we can see the recursion is happening in this block in Renderer.php
// If the default values for this element have not been loaded yet, populate // them. if (isset($elements['#type']) && empty($elements['#defaults_loaded'])) { $elements += $this->elementInfo->getInfo($elements['#type']); }
Is this best accomplished by changing the condition, or by changing what
this->elementInfo->getInfo($elements['#type']);
returns, or something entirely different? - 🇩🇪Germany osopolar 🇩🇪 GER 🌐
For me it still seems to be relevant. I just edited the default content view (under /admin/structure/views/view/content) to reproduce the issue. There I added an new field with html in the label. The html of the label gets escaped. Switching to a different display style (i.e. unformatted list) has the same result.
- 🇦🇺Australia gordon Melbourne
This problem seems to be related to #2738051 🐛 \Drupal\views\Plugin\views\query\Sql::getCacheTags and getCacheMaxAge don't take into account that some entities can be NULL Needs work , but in my case the other didn't fix my issue but caused another issue, and this one fixed it. They both seem to be a very similar issue and solved in slightly different methods.
- Issue created by @griffynh
- 🇺🇸United States Amber Himes Matz Portland, OR USA
larowlan → credited Amber Himes Matz → .
- 🇺🇸United States dww
Wow, what a colossal PITA. 😆 Guess it's good I jumped through all those hoops, since:
- There were indeed some test views with stale argument plugin definitions that needed to be manually fixed, including the view for testing this new functionality. 😂
EntityArgumentUpdateTest
was making some slightly bogus assertions.
However, I had to completely rewrite
ViewsConfigUpdater::processEntityArgumentUpdate()
to operate on entire View entities, instead of using all the per-handler plumbing we've got. To my great dismay, if you copy the existing patterns,ViewsConfigUpdater
process functions make a bunch of changes to handler config, then try to save the view, but that instantiates anotherViewsConfigUpdater
object (this time, with deprecations enabled) to do all the work again. 🤯 So apparently, The Right Way™️ to update a view with all this plumbing is that your process function has to directly update the$view
(which isn't even normally passed in to your process function if you think you're just dealing with handlers), not just fix the$handler
. 🤦♂️I guess I'm now in the exclusive club of ~5 people on Earth who understand how this class works. 😬 😂
ANYWAY, we're back to green pipelines on 11.x and 10.3.x. I've given up on the 10.2.x MR at this point. It works great for the project where I needed this fixed, all the additional hassles are irrelevant to that site, and this is clearly not getting backported. I just hope this can still land in 10.3.x!
Thanks,
-Derek - 🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10
larowlan → changed the visibility of the branch 2251789-forumblockbasedefaultconfiguration-uses-a to hidden.
- 🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10
larowlan → changed the visibility of the branch 512864-comment-count-query to hidden.
- 🇺🇸United States dww
I got a bit more clarity from @catch on what's expected here. I pushed some commits to the 11.x and 10.3.x MRs to trigger deprecations when
ViewsConfigUpdater::processEntityArgumentUpdate()
changes a view outside of post_update. I'm not sure on the wording of the deprecation message, that could use another pair of eyes. Also unclear if we "need" tests that this deprecation plumbing works as expected. I sure hope that's not my responsibility here. 😅I'll keep an eye on the pipelines to make sure I didn't break anything, but I hope this is now actually RTBC.
Automatically closed - issue fixed for 2 weeks with no activity.
- 🇺🇸United States bradjones1 Digital Nomad Life
Re: #13 you could apply the patch from that other issue to core using composer-patches and then use it in this issue, yes.
- 🇺🇸United States smustgrave
No one has chimed in so maybe it is okay.
1) Drupal\Tests\comment\Functional\CommentPreviewTest::testCommentPreviewOnTranslatedNode Behat\Mink\Exception\ResponseTextException: The text "Preview comment" was not found anywhere in the text of the current page. /builds/issue/drupal-3145146/vendor/behat/mink/src/WebAssert.php:907 /builds/issue/drupal-3145146/vendor/behat/mink/src/WebAssert.php:293 /builds/issue/drupal-3145146/core/tests/Drupal/Tests/WebAssert.php:975 /builds/issue/drupal-3145146/core/modules/comment/tests/src/Functional/CommentPreviewTest.php:287 /builds/issue/drupal-3145146/vendor/phpunit/phpunit/src/Framework/TestResult.php:729 ERRORS! Tests: 4, Assertions: 118, Errors: 1.
Test coverage is there and the fix does solve the issue.
Going to mark.
- 🇨🇦Canada ciesinsg
For anyone using a custom theme who is stuck with this, I was able to fix this using the below CSS:
article { width: fit-content; }
I went through a lot of steps finding the issue. It turned out that the media was being added correctly, and while the image element itself was missing align: centre, but a few levels up the parent elements did get this attribute. I played in the browser a bit and found that by setting article to fit-content, it suddenly worked.
- 🇺🇸United States mradcliffe USA
@mparker17 thanks for asking. I think the best thing is to start an issue fork and apply the patch you re-rolled into the issue fork branch and start a merge request.
Merge requests will soon be the only way to test and accept changes to Drupal core and contributed projects on drupal.org
- miiimooo Europe
This should be closed since it has been committed https://git.drupalcode.org/project/drupal/-/commit/c61d707ed4 to 10.2+
- 🇨🇦Canada mparker17 UTC-4
@bradjones1 would it be helpful to update this patch to use the API in 📌 Adding GIN and GIST indexes to PostgreSQL databases RTBC , given that it is RTBC?
Anything else I could help with?
- 🇺🇸United States Kasey_MK
Sorry made the patch from Drupal default branch this time and this one applies against Drupal 10.2.6.
The change that made my webform submissions work again was adding
(count($this->recursionKeys) !== 1)
to line 569 in core/lib/Drupal/Core/Entity/EntityViewBuilder.php but starting from the default Drupal branch added some other changes to the patch. Interdiff against the patch in #155 attached. - 🇺🇸United States Kasey_MK
Adding a check that
count($this->recursionKeys) !== 1
allows webform submissions to render without logging an error, but I don't pretend to understand this issue well enough to know what else that might do. Attaching the patch I made and the interdiff from the patch in #155 for review. - 🇨🇭Switzerland sir_squall
I still got this error, when we are using the :
$node = \Drupal::routeMatch()->getParameter('node');in this hook:
_preprocess_html(&$variables) {we have this preg_quote error
- 🇳🇱Netherlands Lendude Amsterdam
Agree with @acbramley, the Media Library sounds like the wrong widget/field type here, it should just use a file field. Media is about reusing.
And the described results seem inline with what the permission set dictates. Sure, they give confusing results for the end user, but I don't see how we would change the outcome short of trying to guess the intent based on a certain combination of permissions chosen. So "works as designed" I'd say.
- 🇦🇺Australia acbramley
Does this bug still apply to the latest version of Drupal core?
To me, this seems like quite an edge case - why allow creating and editing media without being able to view it?
But since the content of the given field is always unique(in my case), it has no sense in confusing people with giving them access to all the other media files.
Maybe media library isn't appropriate then?
Postponing looking for a bit more information as to whether this should really be fixed in core.
- 🇺🇸United States dww
I asked in #bugsmash for help on this. @catch pointed me to 📌 ckeditor5 and editor module tests rely on hook_editor_presave() bc layers Active , but that issue has nothing to do with
ViewsConfigUpdater
. I still don't exactly understand what's being asked of me.Views is doing this:
function views_view_presave(ViewEntityInterface $view) { /** @var \Drupal\views\ViewsConfigUpdater $config_updater */ $config_updater = \Drupal::classResolver(ViewsConfigUpdater::class); $config_updater->updateAll($view); }
@alexpott, are you proposing we should change the API for
ViewsConfigUpdater::updateAll()
to take a 2nd argument to determine if we're being called frompresave
orpost_update
? Or do you propose thatviews_view_presave()
checks the return value fromViewsConfigUpdater::updateAll()
and if it ever gets back TRUE it should always trigger a deprecation?Can we pretty please move all such complications to a dedicated follow-up, and fix this before the 10.3.0-beta1 ships? I still fail to see why this poor bug needs to be the one to deal with all that additional functionality.
Tentatively moving back to RTBC to get more committer eyes on this.
Thanks,
-Derek - 🇺🇸United States Kasey_MK
Confirming @kmonty's report in #163 using patch in #155.
- 🇨🇦Canada bisonbleu
For the short term, simply adding an ID to the checkbox label does the job; the use case is Simplenews subscriptions on user register page.
/** * Implements template_preprocess_form_element_label(). */ function my_custom_theme_preprocess_form_element_label(&$variables) { $id = $variables['element']['#id'] ?? ''; if ($id && str_contains($id, 'edit-subscriptions-')) { $variables['attributes']['id'] = 'edit-subscriptions--description'; } }
- 🇬🇧United Kingdom joachim
Nearly there -- looks good overall, just a few formatting fixes needed.
- 🇨🇭Switzerland idflood
I tried to reroll the merge request for drupal 10.2 but I'm not sure of the correct workflow, especially since the current merge request is based on the 10.1 branch.
Here is the commit I made: https://git.drupalcode.org/issue/drupal-2325899/-/commit/d665b876f6c1ab2...
And I'm attaching a patch which should hopefully work on 10.2.6
Updated documentation for callback_batch_finished to include RedirectResponse.
And added an example:// Optionally, redirect if needed. if (shouldRedirect()) { // Assume shouldRedirect() is a function that determines if a redirect is necessary. return new \Drupal\Core\Routing\RedirectResponse(\Drupal\Core\Url::fromRoute('example.route')->toString()); }
- @diederikbeirnaert opened merge request.
diederik.beirnaert → made their first commit to this issue’s fork.
- Issue created by @pameeela
- First commit to issue fork.
- 🇨🇦Canada bisonbleu
Just running into this issue in a custom theme. Here is the code sample that generates the «Broken ARIA reference» error:
<!-- BEGIN OUTPUT from 'core/modules/system/templates/input.html.twig' --> <input data-drupal-selector="edit-subscriptions-sip-n-savour" aria-describedby="edit-subscriptions--description" type="checkbox" id="edit-subscriptions-sip-n-savour" name="subscriptions[sip_n_savour]" value="sip_n_savour" class="form-checkbox"> <!-- END OUTPUT from 'core/modules/system/templates/input.html.twig' --> <!-- BEGIN OUTPUT from 'core/modules/system/templates/form-element-label.html.twig' --> <label for="edit-subscriptions-sip-n-savour" class="option">SIP n’ SAVOUR</label>
- 🇪🇨Ecuador jwilson3
@binoli-lalani: Please change the title of the MR back the way it was. This issue has nothing to do with fixing missing hyphens for prefixes - Words starting with "de"
The title should be:
Issue #2720109 by Spokje, kndr, sharma.amitt16, maacl, felribeiro, Neslee Canil Pinto, yogeshmpawar, quietone, zeuty, joey-santiago, Brian-C, ranjith_kumar_k_u, seppelM, jenny.cha, kiwimind, NikLP: maintenance-page--offline.html.twig is not picked up when system is offline
- last update
5 days ago Patch Failed to Apply - 🇺🇸United States sapetm
I seem to have messed up the naming convention for the patch files. This is my first time uploading a patch file. Sorry about that! Hope I did it right this time. Below is from my previous post.
This is a tweak on the patch from comment #102. We have had this problem for a while and we've always had to, in the render function at the last point where the suggestions array is defined, apply an array_unique() to it. This has always fixed the problem for us, but I haven't tested thoroughly to see if this in fact fixes it everywhere. We are running Drupal 10.2.6 and PHP 8.1.27. Hope this helps!
- last update
5 days ago Patch Failed to Apply - last update
5 days ago Patch Failed to Apply - 🇺🇸United States sapetm
This is a tweak on the patch from comment #102. We have had this problem for a while and we've always had to, in the render function at the last point where the suggestions array is defined, apply an array_unique() to it. This has always fixed the problem for us, but I haven't tested thoroughly to see if this in fact fixes it everywhere. We are running Drupal 10.2.6 and PHP 8.1.27. Hope this helps!
- 🇺🇸United States joshmiller Indianapolis, Indiana, USA
Commenting that I helped a mentored contribution table look into this issue. We were able to confirm the issue and we looked at the patches. Unfortunately this was happening later in the day and I think we all ran out of gas at the end. I'll review this in a few days if no one else from the group does and try to get it to RTBC so we might get some core credit for everyone's efforts.
- 🇺🇸United States smustgrave
Think this would be a good plan. Lets postpone this one for the fix in 🐛 Cannot delete file when using language negotiation domains Active then we can reopen this one for expanding test coverage and removing the todo in the code.
- 🇺🇸United States smustgrave
Feedback does appear to be addressed and deprecation seems correct.
LGTM
- @binoli-lalani opened merge request.
Make sure that changes made to the form via AJAX are properly tracked in the form state. In Drupal, if a part of the form is added dynamically (like your biz_wrapper), its values might not be properly included in the form state unless the form structure is adequately managed across callbacks.
//
use Drupal\Core\Ajax\AjaxResponse;
use Drupal\Core\Ajax\ReplaceCommand;
public function accountTypeDropdownCallback(array &$form, FormStateInterface $form_state) {
$form_state->setRebuild(true);
$response = new AjaxResponse();
$response->addCommand(new ReplaceCommand('#biz-wrapper', $form['biz_wrapper']));
return $response;
}- 🇬🇧United Kingdom bluehead
Inherited a custom entity for further development and have the same problem. It's always OR no matter what syntax.
- @binoli-lalani opened merge request.
- 🇬🇧United Kingdom alexpott 🇪🇺🌍
Left a comment on the MR. I think we need to always mark for reindex. The reindexing is not language specific but doing this is not going to recreate any row.
- 🇮🇳India Binoli Lalani Gujarat
Binoli Lalani → made their first commit to this issue’s fork.
- 🇦🇺Australia acbramley
- 🇳🇿New Zealand quietone New Zealand
This was a bugsmash triage target today.
mstrelan found that this was fixed in 📌 Deprecate Test Suites, no longer available in PHPUnit 10 Needs review and questioned if this was a bug. I agree that this is a task and I am updating the issue accordingly.
- 🇮🇳India sukr_s
changed to postsave and invoking
node_reindex_node_search($this->id());
only if the translation was not deleted. - 🇺🇸United States benjifisher Boston area
For the record, the attendees at the usability meeting (Comment #64) were @AaronMcHale, @benjifisher, @rkoller, @shaal, @simohell, @skaught, and @worldlinemine.
We all agreed that the two submit buttons ("Save translations" and "Delete translations") were confusing. Given that, I do not think we should implement a confirmation form.
Deleting a translatable string is temporary. As soon as someone visits a page where the string is used, the string is re-added to the list of strings available for translation. This whole approach seems confusing from a usability perspective.
Opinions at the usability meeting were divided. Some of us were in favor of each of these proposals:
- Close this issue as "won't fix".
- Add a checkbox as in the current MR, but not a second submit button. When the form is submitted, the checkbox has the same effect as deleting the text in the "Translation for ..." column.
- Add help text to clarify that deleting the translation means the source string will be used.
Hello @AlfTheCat.
I have the same problem - https://www.drupal.org/project/drupal/issues/3383732#comment-15410980 🐛 Drupal\Component\Plugin\Exception\MissingValueContextException: Required contexts without a value: entity in Drupal\Core\Plugin\Context\ContextHandler->applyContextMapping() (line 150 of web/core/lib/Drupal/Core/Plugin/Context/ContextHandler.php Postponed: needs info .
I get this error periodically when I edit blocks in the layout builder and one of the blocks is not updated when i click on the "Update" button.
"Discard changes" URL did not solve the problem.
Drupal version 10.2.6.Did you manage to solve this issue?
- 🇳🇿New Zealand quietone New Zealand
Updating the title per Special issue titles → .