🇮🇹Italy @Giuseppe87

Giuseppe87 → created an issue.

It looks the dev version of the module have already fixed it, could we have a new release?

This is quite a serious bug, it would be nice to have a stable release that fixes it.

Giuseppe87 → changed the visibility of the branch 3420392-composer-libraries.missing.json to hidden.

Giuseppe87 → made their first commit to this issue’s fork.

Hi, may suggest that the changelog of alpha9 explain that this MR introduced a breaking change, changing the default cardinality of the plugin from unlimited to single?

I don't know if there are others can be affected too, and if this can happen also with the rendering system, but when I switched from alpha8 + patch to alpha9 I got problems due this MR - namely, via JSON:API empty fields returned "false" instead of an empty array.

Considering I was puzzled a bit before finding the cause, and I'm the one opening the issue, others could be have even more difficulties to find the problem.

The MR of that issue is exactly the same problem I reported, and the MR seems to work fine.

Thanks and sorry for the duplicate; I searched on the issue queue on both this module and the theme, I have no idea how could miss that issue!

I've just tried the patch and the MR also solves the same issue for me.

Similarly at the OP I have no context\enough knowledge of the theme to know the consequences of that extra check, but just browsing the site the menu looks good.

Regarding #31/#32:

On Drupal 10.2.x the MR works fine, but with a standard form. I haven't tried the setup of the related issue.

However looking at the code

$op = $form_state->getFormObject()->getEntity()->isNew() ? 'create' : 'edit';
is both in the MR and in the patch #28, so it's strange that the patch works while the MR doesn't.

1. No, I am already using that patch. That issue is purely css, the html is correctly rendered, however the class conflicts therefore the dropdown isn't show without the patch
2. The issue I've created is instead about markup, the code I've pointed out is actually added in the markup of the menu if gin_toolbar is enabled.
   I couldn't identify the a point in the code, but I suspect that either a preprocess or a pre_render callback actually insert that extra div with the logo
3. Is possible override the template? I am using obliviously Gin, therefore I can't create a sub-theme where use my override twig files, which is the way I know to override other themes' templates. Is there another way to override them? For now I've hidden the extra div via css but it's a weak solution as there is no selector to identify it:
   

   .toolbar-menu-container {
     ul {
       li:first-child {
         display: none;
       }
     }
   }
   

Giuseppe87 → created an issue.

+1 for the #8 patch: without it the menù with Gin isn't shown, with the patch it works.

I've updated the #5 patch, adding the deletion of the file after the send.
Otherwise the physical file would be still accessibile with the direct link to anyone.

This also require the removal of

    // If zip file is already present and node is not been changed since
    // Then just stream it directly.
    if (file_exists($file_path)) {
      $file_last_modified = filemtime($file_path);
      $node_changed = $node->getChangedTime();
      if ($node_changed < $file_last_modified) {
        return $this->streamZipFile($file_path);
      }
    }

Which definitely make the download less optimized.

I don't know if it would be worthy - and if it's possible - to have 2 different logic in case of public and private field files.
Being a 5 years old (security) issue, I'm putting in Needs Review, hoping it will move more quickly.

Despite the pipeline saying the MR being mergeable, I had a conflict and can't apply the patch. I rebased the issue.

Giuseppe87 → changed the visibility of the branch 3246426-enable-to-add-on-2.0.x to active.

Giuseppe87 → changed the visibility of the branch 3246426-enable-to-add-on-2.0.x to hidden.

Giuseppe87 → changed the visibility of the branch 3246426-enable-to-add-on-2.0.x to active.

Giuseppe87 → changed the visibility of the branch 3246426-enable-to-add-on-2.0.x to hidden.

Giuseppe87 → created an issue.

xjm → credited Giuseppe87 → .

https://www.drupal.org/project/file_uploader_uppy → is another module that has a field widget for file/image fields.

The patch works for me on 10.2.

I also get an "access denied" error on Drupal 10.2.x if go to "it/admin/structure/types/manage/article/display/teaser/translate" with the MR patch, using an admin user.

I get your point, however that is useful only for translated page, not for the main language, am I wrong'

As workaround I've found that limiting the handled formats to 'html' wont' cause the loop.

E.g.

  protected function getHandledFormats() {
    return ['html'];
  }

or just don't overriding the method of the parent class.

This obliviously works only if the subscriber doesn't need to intercept json\rest request. I haven't tested the case a json\rest request is handled inside the on403 on404 methods.

I confirm I'm using 3.0.0.

I missed in report the fact that the field must be inside a Paragraph :facepalm
I updated the report with the correct test case.
I confirm that with a structure like

node -> field_entity_reference

the report behavior doesn't happen.

While with the structure

node -> paragraph -> field_entity_reference

the behaviour does happen.

Considering that EntityReferenceRevisionsExportFormatter extends EntityReferenceExportFormatter just overriding prepareView() probably the logic of patch previosly provided is as much valid.

I've updated the example with the actual code I used to cause this behaviour.

Giuseppe87 → created an issue.

Likewise #8 the issue seems to still exists:

I have a Drupal site with text list fields which have a machine names 0, 1, ...

On Drupal 10.1.8 they are valid and editable, with 10.2.3 I get ""Value field is required.".

Giuseppe87 → created an issue.

With the latest patch I can't see anymore the tab with the link for the translation.

Anyway, the route /admin/people/users/redirect/form/settings does exist; the translation form doesn't have anymore the problem reported in #6

Added a MR as requested in #4

I've tested the patch and it works to me, the only problem is that when creating the translation the "roles" label aren't the right one but generic "Roles", which may be confusing.

For using ending on this issue from admin_toolbar_links_access_filter description:

from what I saw, #2/ 📌 Restrict access to empty top level administration pages for overview controller Fixed still work to hide the "Configuration" link or similar cases.

It could be useful like my case, where #3413508 patch is necessary and #3381929 one conflict.

Attached a patch which should solve this problem.

Giuseppe87 → created an issue.

@JohnAlbin about #225: I tried to rebase the MR according the documentation → , I'm sorry if I messed something up.

I needed to reroll the 10.x patch again, this time against 10.2.x, as it doesn't work anymore for that version.

In order to avoid to mess again, I'm attaching as .patch file, if it is good, should I rebase\or push on the MR request?

Using a bit more sdc, I've found another leakage.
I'm also putting into this issue because the cause and solution may be the same.
It's a very weird and corner case I got using the set command.

You need two templates: the first, outer_sdc must use a set, e.g.:

    {% set my_content %}
        <div class="my-content">
            {% block my_block %}
                My test sdc
            {% endblock %}
        </div>
    {% endset %}


    <div {{ attributes }}>
        {% if 1 > 0 %}
            <div>
                {{ my_content }}
            </div>
        {% else %}
            <span>
     {{ my_content }}
  </span>
        {% endif %}
    </div>

This sdc must be embeded in another sdc/theme twig. The block section must include another sdc:

    {% embed 'my_theme:outer_sdc' %}
    {% block my_block %}
{{ include(my_theme:base_sdc') }}
        {% endblock %}
      {% endembed %}

base_sdc can be a skeleton:

<div {{ attributes }}>
  {% block example_block %}
    The contents of the example block
  {% endblock %}
</div>

The expected output should be:

<!-- 🥘 Component start: my_theme:outer_sdc -->
<div data-component-id="my_theme:outer_sdc">
    <div class="my-content">
        <!-- 🥓 Component start: my_theme:base_sdc -->
        <div data-component-id="my_theme:base">
            The contents of the example block
        </div>
        <!-- 🥓 Component end: my_theme:base -->
    </div>
</div>
<!-- 🥘 Component end: my_theme:outer_sdc -->

But actually is

<!-- 🥘 Component start: my_theme:outer_sdc -->
<div data-component-id="my_theme:base">
    <div>
        <div class="my-content">
            <!-- 🥓 Component start: my_theme:base -->
            <div data-component-id="my_theme:base">
                The contents of the example block
            </div>
            <!-- 🥓 Component end: my_theme:base -->
        </div>
    </div>
</div>
<!-- 🥘 Component end: my_theme:outer_sdc -->

Namely, the <div data-component-id="my_theme:outer_sdc"> has been printed as <div data-component-id="my_theme:base">

By the way, this problem doesn't depend on having print my_content twice conditionally.
For example if outer_sdc is

{% set my_content %}
  {% block my_block %}
    LOREM IPSUM
  {% endblock %}
{% endset %}


<div {{ attributes }}>
  <div class="my-content">
    {{ my_content }}
  </div>
</div>

The problem is the same, so the problem is something about the set command.

I confirm the description of #39:

I have on a site started with Drupal 8, upgraded to 9 and recently to 10 a similar situation.

On that site there are some views of nodes with a contextual filter "content:ID" whose validator is "content type" and accept one or multiple ids.

That view is sometimes render programmatically, with the following code:

    $view = [
      '#type' => 'view',
      '#name' => $view_id,
      '#display_id' => $view_display,
      '#arguments' => $nids,
    ];
    $render = $this->renderer->render($view);

Where $nids sometimes may be an empty string - if no value is provided.
Until Drupal 9 this worked, but since Drupal 10 I had to put a check in case $nids is an empty string, because that would cause the error.

I also agree that was poor code custom that made Drupal doing something that should not be possible, but hiding that error would hide the mistake without having a way to realize it.

Added the access check to the query, now mandatory.

On Drupal 10.1.x trying #23 I get the error - twig tweak is installed, if I print {{ drupal_token(something)) }}on a normal twig, it works:

Twig\Error\SyntaxError: Unknown "drupal_token" tag in "__string_template__d63e10f79d9d43968f5ae212f85498f7" at line 1. in Twig\Parser->subparse() (line 160 of /var/www/html/vendor/twig/twig/src/Parser.php).

The above solutions did need something else or worked out of the box?

Giuseppe87 → created an issue. See original summary → .

I've tried the patch on D10.1.x but it seems it has some problems:

If I print in the view header using unfiltered text :

       {% if 1 > 0 %}         hello       {% endif %}
       {{ ""|t}}

Correctly replace the twig.

However,

       {% if 1 > 0 %}  hello  {% endif %}

Does not replace the twig.

What's more, if I use the Global Text Area, and thus a input area with a text format and CKEditor,

       {% if 1 > 0 %}         hello    {{ ""|t}}     {% endif %}

is replaced by

    {% if 1 > 1 %} hello {% endif %} {{ ""|t}}

Even if writing it in the "source code" mode of CKEditor.

That cause a server error on the error on the view page:

Twig\Error\SyntaxError: Unexpected character "&" in "__string_template__f605a68c7565a3509e2a3d658d6b70a7" at line 1. in Twig\Lexer->lexExpression() (line 376 of /var/www/html/vendor/twig/twig/src/Lexer.php).

Giuseppe87 → created an issue. See original summary → .

I'm sorry, I created a MR but it was not actually the issue I should have worked on, please ignore it.

Giuseppe87 → changed the visibility of the branch 8.x-4.x to hidden.

Giuseppe87 → changed the visibility of the branch 3381486-entity-queries-must to hidden.

What version of PHP are you on?

Good idea, unfortunately the test above were with PHP 8.1, I've tried now with 8.2 and get the same problem.

The check at line 104 for lifecycle if (!$this->isEmpty() && $this->definition->hasOptions()) { returns true.

The value at 107 are the one in the screenshot, the check at that line returns true causing the violation.
I haven't dig in the code of the module\library so I have no idea what should there be at thatpoint, I hope this can help you to understand the problem.

Either {% include 'template.html' with {'foo': 'bar'} only %} or {{ include('template.html', {foo: 'bar'}, with_context = false) }} help to mitigate the issue.

Namely:

{{ include('olivero:test', { my_classes: ['class-1', 'class-2']}, with_context = false) }}

{{ include('olivero:test') }}

{{ include('olivero:test', with_context = false) }}

The second and third include won't have the classes of the first.

{{ include('olivero:test', { my_classes: ['class-1', 'class-2']}) }}

{{ include('olivero:test') }}

{{ include('olivero:test', with_context = false) }}

The second include will have the class of the first, the third won't have them.

I'm saying mitigate because:

• the context is passed by default, so it this sdc's attribute behavior is considered a good pattern and not a bug, it should at be at least documented
• relying on disabling the context force to pass props naturally available. For example, I discovered this behavior while placing multiple instance of the same sdc inside user.html.twig, where I am using the user variable, already present inside the context

module_builder.component.test_module.yml:

uuid: 40f027ce-a799-4108-a3d5-267d9f27e452
langcode: en
status: true
dependencies: {  }
id: test_module
name: test_module
data:
  base: module
  root_name: test_module
  readable_name: test_module
  short_description: description
  module_package: Custom
  module_dependencies: {  }
  lifecycle: ''
location: ''

I've also made a short video showing what I'm doing: https://www.youtube.com/watch?v=MhJ3qINe9Dk

The site it's the one descripted on #8

Are you on the latest version of Drupal Code Builder?

Yes, 4.3.4

Can you reproduce it on a fresh install of core?

Yes, as I stated on #8, to be sure I've just installed a new version of D10 with just module builder and drush and got the same error.

Can you do a config export of the module entity?

What do you mean? The "test" module is practically a skeleton: it has just the info.yml file.

Yes, I've just re-tested with a clean install to be sure, and I can replicate.

• module builder: 4.0.1
• Core: 10.1.7
• Drush: 12.4.3

I'm using a local machine with DDEV.

Let me know If you can't replicate still, I'll try to make a video or something else to show my flow.

Giuseppe87 → created an issue.

I don't understand why

but I generated the test module in MB then deleted the entity to adopt it.

when I clearly stated that the bug appears when

1. the module is created manually or drush
2. MB is used to adopt it and create something, e.g. a plugin

So please use

drush generate module instead of MB to generate the module.

name: 'module_generated_by_drush'
type: module
description: 'A basic module'
package: Custom
core_version_requirement: ^10

Giuseppe87 → created an issue. See original summary → .

I've tried with a D10 clean install and the patch doesn't cause the same problem.

I've identify that the bug I'm facing appears when using the Bootstrap theme → .

Being this a core issue, I guess the theme needs to solve the incompatibility, after this patch is merged.

Does the #65 requires some manual action?

If I install it, every region.html.twig in the site has the content variable valued as an emtpy string, killing pretty much the render of the site.

Attached a patch.
I don't know if there were particular reasons for generateRandomNumbers, but I have removed it in favor of PHP standard functions.

Giuseppe87 → created an issue.

1. Added the source entity parameters for the render array, according to  https://www.drupal.org/project/webform/issues/2996794 →
2. Added a reminder to set the #cache
3. Added the example for "Embed with Ajax"

I've removed the first example "Embed as a Webform entity" as the comment of jrockowitz in in this discussion

I'm facing a issue with a view and flag:

I've a view on nodes, with the ajax flag field displayed.
For most of them, the ajax flag\unflagging works.
However, for some of them, the link fails with an access denied.
I can't determine why only a minor part of them has this problem, but from the log and debug is definitely because the CSRF token generated for those links isn't correct.

Either disabling the cache for the view, or using the patch at "nojs"/"ajax" route parameter in use-ajax link breaks CSRF protection 🐛 "nojs"/"ajax" route parameter in use-ajax link breaks CSRF protection Needs work solve the problem.

Is this issue relevant?

I've tried to add a paragraph with a scheduler field to a node, block or taxonomy term.
In any case, they are shown\hidden when published\unpublished by the cron, even for anonimous users, without clearing any cache.

I've tried with Paragraphs 8.x-1.15 and Scheduler field 1.0.0-alpha1.
I did not use the paragraphs' patch of the related issue.

Giuseppe87 → created an issue.

From my test, the patch doesn't work when in case of a paragraph which needs to be unpublished, if the cron run within 1 hour after the end-date publication time of the paragraph.

I've updated the related issue to consider time-zone, so I think this one could be considered a duplicate of that?

The patch's code didn't consider that dates are stored in UTC timezone in the database, while the new DrupalDateTime() defaults to the site default timezone.

I updated the code to set the $now timezone to UTC before running the queries.

Giuseppe87 → made their first commit to this issue’s fork.

Hi, I've tried this patch but I'm facing several problems\errors.

I also replicated them on a clean Drupal 10 instance with just paragraphs, scheduler and ultimate_cron as contrib modules.

1. I can see the "scheduler" fields on the paragraph add form; those fields however are missing in the edit form of an existing one.
2. When running the cron, I get the error "Drupal\Core\Entity\Query\QueryException: 'publish_on' not found in Drupal\Core\Entity\Query\Sql\Tables->ensureEntityTable() (line 369 of /var/www/html/web/core/lib/Drupal/Core/Entity/Query/Sql/Tables.php)." and the paragraphs aren't actually published.
On the other hand, if I set the option "Action to be taken for publication dates in the past" as "Publish the Paragraph immediately after saving", the paragraph is published on form submit.
3. It's possible to submit the form with the (un)published field empty, even in the case it was set up as required.

About #64 and #66:
I have searched how move the SimpleSAMLphp_saml_LogoutStore, SimpleSAMLphp_tableVersion in another database, but couldn't find documentation or configuration to do so, in order to avoid the

"READ-COMMITTED
For this to work correctly, all tables must have a primary key. The following table(s) do not have a primary key: SimpleSAMLphp_saml_LogoutStore, SimpleSAMLphp_tableVersion."." error

Granted that isn't really a problem, does someone know how move those tables? Thanks

Yes, I can confirm that

drush en symfony_mailer_bc 
drush ev "\Drupal::service('update.update_hook_registry')->setInstalledVersion('symfony_mailer', 10007);"

fixed the token replacement in my site, even if already run the updates with 1-4.0-beta1.

Thank you.

Am I wrong or this patch approach doesn't consider the case the updates of 1.4.0-beta1 has been done?

From a quick test setting the version to a previous state, e.g.

drush ev "\Drupal::service('update.update_hook_registry')->setInstalledVersion('symfony_mailer', 10007);"

and re-do the updates should work, but please correct me if this it is not right.

I had the same issues, so implemented a cron to clear expired anon flagging.

It collects the flagging created before the requestTime + sessione expiration timeout.
There' s a settings form at /admin/config/flag/settings, I have placed in no menù or else, because currently the configuration link points to entity.flag.collection

+1 for #2

I don't know if there's a better way, but from the debug I did to identify this bug switching to 4.x.x, I suppose the following method method should work - please be aware you have to test it, I haven't actually tried it.

You have to update the table `authmap` for the the user whose external `authname` have been overriden with the local\Drupal one.

In my case, the external authname is a string like "00556409645g0050SJQww2" while the drupal one is an email, so I could query the table to list all the elements with an email as authname, and then manually update them.

You obviously need some way to find the external authnames for the broken records - e.g. a backup db.