#Bug Smash Initiative

Our logic around how we use https://www.php.net/manual/en/ini.core.php#ini.precision to get a number is also in error. Its value can be negative 1 (-1). Which really messes with things if we assume it is a positive length to use with number_format.

Thank you.
Let me explain my observation - an outside view so to say.

I added the field decimal, because I needed a place for huge numbers with not so many positions behind the comma.
Then I had to realize that a field called decimal is very much limited in comparison to what I expected, or from my experience with other decimal functionality in other system would have expected.
That was my confusion number one.

Then I learned I can configure the field upon its creation. And before this validation bug here - or better without realizing that again - it was not problem to set the gui to whatever I needed. A huge number with a few digits behind the comma.
Entering data caused numbers to be crunched ... we all know that story here.

Then you wonder what to do and how it all depends on each other.

The default database allows for much more digits before and after the comma than default Drupal.
In my opinion that is not good. It is confusion number one.
Then you realize that also php may have a limit inbetween. That is confusion number three.

In my opinion we should make that clear somehow.
I think Drupal should ask during install how the user wants it to be set.
e.g.
DB limit is ...
php limit is ...
Drupal default is ...
Would you like to use Drupal default precision/scale for decimal fields or would you like to increase the default to the php and DB limits.

Then at least it would be transparent what happens here.

The next problem is the intransparent limitation of this patch. I can set some precicion/scale during field creation and it may crash because of underlying system differences ... which were not obvious during field creation.

Why should this patch not be adjusted to system parameter settings? it does not make sence to me to keep an artificially limited number of digits before or after the comma it the system already provides for that bandwidth.

And btw: thank you all very much for your efforts!

The standard setting does not a

Re #373: sorry about my poorly worded and unclear statement there. I'm not sure how to word it but making something like this dependent on a PHP ini settings, which is regularly set differently on localdev vs other environments seems wrong. This is the type of thing we would regularly do a hook_requirements around if it were a feature of php for image quality or a feature of mysql for data storage. But we do nothing like that here.

To add to that though, this precision value is something we can control ourselves via an ini_set at runtime. If we have a certain value configured for the field, then we should set the value before invoking it.

Thanks for following up @mxh!

#372 I completely agree.
And I don't understand this from #370 "We shouldn't make this field value dependent on an environment specific setting. It needs to be distinct."

We have three layers:
Database - php - drupal/gui

Why should they be distinct from each other?!

if php sends something too large for the db -> error.
If drupal sends something wrongly scaled -> error.
...

In my opinion we should specify rules on how they need to be in sync to each other.

The Needs Review Queue Bot → tested this issue.

While you are making the above changes, we recommend that you convert this patch to a merge request → . Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)

I had the same issue on Drupal 10.3.10. I had the default language of a website in Danish, I installed the Norwegian one, selected as default language. When I deleted the Danish one, even if I had a confirmation popup which said that all the Danish content will be updated to the default language, this doesn't happens. The lang code become empty.
My solution to fix this issue was to run the following code in a hook_update_N:

 $database = \Drupal::database();
 $schema = $database->schema()->findTables('%');
 foreach ($schema as $table) {
  if ($database->schema()->fieldExists($table, 'langcode') && $table!='locale_file') {
    $resultsFound = $database->query("select * from ". $table." where langcode='da'")->fetchAll();
    if(count($resultsFound) > 0) {
      $database->query("update ". $table." set langcode='nb' where langcode='da'")->execute();
    }
  }
 }
and than delete the original default language (Danish).
So basically, I am getting all the DB tables, check if there is a langcode field, get all the records form that table and update the value to the new language

It has been 3 years since a committer asked for more information and none has been supplied. @acbramley suggested waiting a few more months, and that was about 1 year ago and still no comment. Therefore, I am closing this.

If there is work to do here, then either re-open the issue or open a new issue and reference this one. If the choice is to use this issue then add a comment change make sure to change the issue status to 'Active'.

dcam → changed the visibility of the branch 3174255-docreate-invalid-bundle to hidden.

Automatically closed - issue fixed for 2 weeks with no activity.

Believe all feedback has been resolved on this one. Test coverage is failing in 2 spots https://git.drupalcode.org/issue/drupal-2847425/-/jobs/4682940

IS seems to line up to me.

LGTM

MR failed tests.

I added some comments as well. I think the biggest issue on the MR is that there is a confusion between "precision", which is documented as the number of significant digits, (the number of all digits before and after the decimal), vs "scale", which is the number of digits after the 0.

I resolved the issue that the review bot raised however there is the nightwatch test failing. Unsure if its just glitching and a rerun is fine, or if its because we're behind on commits?

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

smustgrave → credited larowlan → .

@larowlan for 🐛 when use hook_file_url_alter to change file url, the file path will be encode. Active

One less critical.

I did update the Issue Summary Current workaround section.

Here is the composer output when using #3091285-131: Composer scaffolding fails when permissions on default.settings.yml or default.settings.php is not writable. → :

…
Scaffolding files for drupal/core:
  - Copy [web-root]/sites/default/default.services.yml from assets/scaffold/files/default.services.yml
> chmod 555 web/sites/default
> DrupalProject\composer\ScriptHandler::createRequiredFiles
…

In light on the comments in #32, which I agree with, this should be closed.

heddn → closed merge request !579

I streamlined the approach here a lot. This issue is all about validation. So changes to widgets shouldn't be in scope. And the storage of the data should be limited by the DB engine not by the configuration of PHP. So a lot got stripped out. If we need to address those things, they should happen in a dedicated issue.

A couple things here. 1) We shouldn't do hook updates that look at environment specific changes. Localdev vs live site likely have different php.ini settings. We shouldn't depend on them to be the same. 2) Why do we care what the display precision is set to for data storage? We shouldn't.

I've removed the hook update.

This seems to still be relevant.

Will need an issue summary and tagging novice as should be a good task for new users.

So in agreement to close?

Restoring RTBC status

smustgrave → credited catch → .

@catch for 🐛 CssOptimizer silently drop the attached library when a CSS file @include an external CSS. Postponed: needs info

Automatically closed - issue fixed for 2 weeks with no activity.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Yes, it's still an issue.

This came up as a daily BSI target

Can someone confirm if this is still an issue in D11?

Also tagging for issue summary update so if moved back to active lets update that as well please

Thanks!

Myself for 🐛 Key is not automatically populated after validation failure on blank title Active

Since there hasn't been a follow up going to close out, if still an issue in the latest version of Drupal please re-open providing steps to reproduce

Updated the MR with latest 11.x: solving conflicts and Fix test according with field ui API updates - issue #3386762 ✨ Use modal in add new field flow Active .

Updated the MR with latest 11.x: solving conflicts and Fix test according with field ui API updates - issue #3386762 ✨ Use modal in add new field flow Active .

I'm seeing a "missing schema" warning for a field used in a View. The field is added using the Views Entity Form Field module( https://www.drupal.org/project/views_entity_form_field → ), which allows adding form fields directly in Views.
In this case, the config path is:
display.page_2.display_options.fields.form_field_field_cc_expense_head.plugin
Since the Views Entity Form Field module dynamically injects form field plugins, it's likely the missing schema error is related to the module not providing schema definitions for those custom field plugins.

🐛 Action buttons unresponsive when coming back from node preview Active was marked as a duplicate of this.

When testing that issue I also found some weird behaviour (I didn't realise this was core's JS at the time) where after you hit Back in the browser you can eventually submit the form if you spam the save button a few times.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Hid 10.5.x MR.

joegraduate → changed the visibility of the branch 2672340-remove-user_user_role_insert-10.5.x to hidden.

Pleased to see this one has got a bit of momentum again! I'm keen to see what I was missing :) Cheers @longwave!

Appears to have pipeline failures in the unit tests.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

smustgrave → credited effulgentsia → .

smustgrave → credited hchonov → .

Closed 🐛 Move entity preparation from form controller to entity class: "last changed" timestamp not updated and "create new revision" setting not respected when updating entities via Entity API Postponed: needs info with overlap to this.

Will move over credit to the issue in #53

Thank you @smustgrave, I think I see how it could be done now. But I have run out of time in the short term, I'll try to get back to this to add the test of the upgrade path sooner rather than later.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

It's been another few months without any steps to reproduce so closing this one out.

If you are able to provide steps to reproduce, feel free to re-open this.

Setting back to needs review.

• MR !11992 still applies to 11.x
• MR !12041 still applies to 10.5.x

Tested this manually on HEAD and was unable to reproduce the access denied issue.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

RemovePathKeyTest may be a good example

Essentially the test would be

Load a fieldBlock and verify the key DOES NOT exist

Run updates

Load the same block and verify the key DOES exist.

I added an update hook that updates FieldBlocks to set show_when_empty to FALSE, but I'm not sure if there's more I need to do there. See my previous note about whether more is needed.

But I am not sure how to go about writing a test for the update hook.

Note that the update hook should probably only target the default layouts (the entity view displays).

There could be thousands+ of nodes/entities with overridden layout data that have field blocks. Writing an update hook to load, check the nodes overridden layout for field blocks, then resave the nodes does not sound realistic. As long as the behavior for a field block that does not have any value for the new property is the same as the new property having empty value, I think this should be fine.

Thank you, I understand now.

If this key could appear on any FieldBlock then it would need an upgrade path. Good rule of thumb if you go into a config page, make no changes, click save, config export and there is a change then it needed an upgrade path.

and then a test to make sure update hook works properly

That's correct, there are a few example in core but don't have them super handy right now.

@smustgrave -

Sorry, but I want to make sure I'm understanding you correctly.

Currently the FieldBlock's default configuration has a value for the new config field that matches the FieldBlock's behavior pre-patch.

Are you saying that we need an update hook to update all FieldBlocks to set a value for the new config option and then a test to make sure update hook works properly? Or something else?

New configuration key will need an upgrade path + upgrade path test

MR !12052 refactors original approach to use a "show block when field is empty" checkbox rather than a "hide for empty" checkbox. This MR also includes updates to tests to test the new option.

As a result, I'm going to mark as Needs review and remove the needs tests tag.

My instinct is to also hide MR !5111, but I'll leave that to a maintainer.

using a data attribute as selector for AJAX (instead of an ID)

Maybe it worth mentioning that in the latest proposed fix for ✨ Exposed forms in a block are not currently updated when Ajax filtering is executed Needs work I have introduced a wrapper element around the form that might be also a valid alternative here, although as I wrote in #3032353-63: Exposed forms in a block are not updated by AJAX → I do not want to the two issue to become a blocker of each others.

First, I just want to note that we should not be iterating on patches since we're using an MR. Any work and iteration should happen in the MR.

Second, I'd propose that the logic of this new field be flipped: instead of "Hide when empty" and defaulting to checked, use "Show when empty" and default to unchecked. I will add an MR with this alternate approach.

catch → closed merge request !11548

Nice find. Committed/pushed to 11.x, thanks!

We regularly face the same issue:

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "views_view:view.block_content.page_1" plugin does not exist. Valid plugin IDs for Drupal\Core\Menu\LocalTaskManager are: [long list here including some other views_view:view.... tabs].

Trace:

#0 /var/www/html/docroot/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryCachedTrait.php(25): Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition()
#1 /var/www/html/docroot/core/lib/Drupal/Core/Plugin/Factory/ContainerFactory.php(16): Drupal\Core\Plugin\DefaultPluginManager->getDefinition()
#2 /var/www/html/docroot/core/lib/Drupal/Component/Plugin/PluginManagerBase.php(83): Drupal\Core\Plugin\Factory\ContainerFactory->createInstance()
#3 /var/www/html/docroot/core/lib/Drupal/Core/Menu/LocalTaskManager.php(263): Drupal\Component\Plugin\PluginManagerBase->createInstance()
#4 /var/www/html/docroot/core/lib/Drupal/Core/Menu/LocalTaskManager.php(290): Drupal\Core\Menu\LocalTaskManager->getLocalTasksForRoute()
#5 /var/www/html/docroot/core/lib/Drupal/Core/Menu/LocalTaskManager.php(358): Drupal\Core\Menu\LocalTaskManager->getTasksBuild()
#6 /var/www/html/docroot/core/lib/Drupal/Core/Menu/Plugin/Block/LocalTasksBlock.php(106): Drupal\Core\Menu\LocalTaskManager->getLocalTasks()
#7 /var/www/html/docroot/core/modules/block/src/BlockViewBuilder.php(171): Drupal\Core\Menu\Plugin\Block\LocalTasksBlock->build()
#8 [internal function]: Drupal\block\BlockViewBuilder::preRender()
#9 /var/www/html/docroot/core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php(113): call_user_func_array()
#10 /var/www/html/docroot/core/lib/Drupal/Core/Render/Renderer.php(870): Drupal\Core\Render\Renderer->doTrustedCallback()
#11 /var/www/html/docroot/core/lib/Drupal/Core/Render/Renderer.php(432): Drupal\Core\Render\Renderer->doCallback()
#12 /var/www/html/docroot/core/lib/Drupal/Core/Render/Renderer.php(504): Drupal\Core\Render\Renderer->doRender()
#13 /var/www/html/docroot/core/lib/Drupal/Core/Render/Renderer.php(248): Drupal\Core\Render\Renderer->doRender()
#14 /var/www/html/docroot/core/lib/Drupal/Core/Template/TwigExtension.php(484): Drupal\Core\Render\Renderer->render()
#15 /tmp/leica/php_storage/twig/9ad7f806e7f62a8da0cf8fec8fd26b2f35d0db3c-from-scratch/leica/twig/6813a2e26d1fb_page.html.twig_8jw0unMsy9xel9gtHdkD_AeP4/g9mcBqpu1iHBB2Q37FpNjMU7HSKhWRVMixa-JUl42ck.php(48): Drupal\Core\Template\TwigExtension->escapeFilter()
#16 /var/www/html/vendor/twig/twig/src/Template.php(388): __TwigTemplate_c951409ee69548febe0276286d7ee635->doDisplay()
#17 /var/www/html/vendor/twig/twig/src/Template.php(344): Twig\Template->yield()
#18 /var/www/html/vendor/twig/twig/src/Template.php(359): Twig\Template->display()
#19 /var/www/html/vendor/twig/twig/src/TemplateWrapper.php(51): Twig\Template->render()
#20 /var/www/html/docroot/core/themes/engines/twig/twig.engine(33): Twig\TemplateWrapper->render()
#21 /var/www/html/docroot/core/lib/Drupal/Core/Theme/ThemeManager.php(348): twig_render_template()
#22 /var/www/html/docroot/core/lib/Drupal/Core/Render/Renderer.php(491): Drupal\Core\Theme\ThemeManager->render()
#23 /var/www/html/docroot/core/lib/Drupal/Core/Render/Renderer.php(248): Drupal\Core\Render\Renderer->doRender()
#24 /var/www/html/docroot/core/lib/Drupal/Core/Template/TwigExtension.php(484): Drupal\Core\Render\Renderer->render()
#25 /tmp/leica/php_storage/twig/9ad7f806e7f62a8da0cf8fec8fd26b2f35d0db3c-from-scratch/leica/twig/6813a2e26d1fb_html.html.twig_0eGYNs7FAmpskRX3hZ2zlny3c/MWzgBwyQ9kDK5D3ntueXGk66pUVVmeOPgdP97Q1F-VI.php(91): Drupal\Core\Template\TwigExtension->escapeFilter()
#26 /var/www/html/vendor/twig/twig/src/Template.php(388): __TwigTemplate_ec2974d8efb50073b65812b7f5055bb9->doDisplay()
#27 /var/www/html/vendor/twig/twig/src/Template.php(344): Twig\Template->yield()
#28 /var/www/html/vendor/twig/twig/src/Template.php(359): Twig\Template->display()
#29 /var/www/html/vendor/twig/twig/src/TemplateWrapper.php(51): Twig\Template->render()
#30 /var/www/html/docroot/core/themes/engines/twig/twig.engine(33): Twig\TemplateWrapper->render()
#31 /var/www/html/docroot/core/lib/Drupal/Core/Theme/ThemeManager.php(348): twig_render_template()
#32 /var/www/html/docroot/core/lib/Drupal/Core/Render/Renderer.php(491): Drupal\Core\Theme\ThemeManager->render()
#33 /var/www/html/docroot/core/lib/Drupal/Core/Render/Renderer.php(248): Drupal\Core\Render\Renderer->doRender()
#34 /var/www/html/docroot/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(158): Drupal\Core\Render\Renderer->render()
#35 /var/www/html/docroot/core/lib/Drupal/Core/Render/Renderer.php(638): Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}()
#36 /var/www/html/docroot/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(159): Drupal\Core\Render\Renderer->executeInRenderContext()
#37 /var/www/html/docroot/core/lib/Drupal/Core/EventSubscriber/MainContentViewSubscriber.php(90): Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse()
#38 [internal function]: Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray()
#39 /var/www/html/docroot/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func()
#40 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(186): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch()
#41 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw()
#42 /var/www/html/docroot/modules/contrib/simple_oauth/src/HttpMiddleware/BasicAuthSwap.php(68): Symfony\Component\HttpKernel\HttpKernel->handle()
#43 /var/www/html/docroot/core/lib/Drupal/Core/StackMiddleware/Session.php(53): Drupal\simple_oauth\HttpMiddleware\BasicAuthSwap->handle()
#44 /var/www/html/docroot/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle()
#45 /var/www/html/docroot/core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle()
#46 /var/www/html/docroot/core/modules/big_pipe/src/StackMiddleware/ContentLength.php(32): Drupal\Core\StackMiddleware\ContentLength->handle()
#47 /var/www/html/docroot/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\big_pipe\StackMiddleware\ContentLength->handle()
#48 /var/www/html/docroot/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass()
#49 /var/www/html/docroot/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle()
#50 /var/www/html/docroot/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle()
#51 /var/www/html/docroot/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle()
#52 /var/www/html/docroot/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\AjaxPageState->handle()
#53 /var/www/html/docroot/core/lib/Drupal/Core/DrupalKernel.php(741): Drupal\Core\StackMiddleware\StackedHttpKernel->handle()
#54 /var/www/html/docroot/index.php(19): Drupal\Core\DrupalKernel->handle()
#55 {main}

Looks great

Done

Let's update the issue summary to also mention the entity.image.preview route. I agree with #40, no need to deprecate.

joegraduate → changed the visibility of the branch 11.x to hidden.

joegraduate → changed the visibility of the branch 10.5.x to hidden.

Created MR targeting 10.5.x.

joegraduate → changed the visibility of the branch 2672340-remove-user_user_role_insert-10.4.x to hidden.