🇮🇹Italy @Giuseppe87

It's long time and on a project I am not working anymore, but I think I used this workaround

function my_module_views_metatags_alter(array &$metatags, array &$context) {
   /** @var EntityInterface $entity */
    $entity = $context['entity'];
    $taxonomy_bundles_to_tag = [
      'articles',
    ];
    if ($entity->getEntityTypeId() === 'taxonomy_term' && in_array($entity->bundle(), $taxonomy_bundles_to_tag, TRUE)) {
      $metatags['canonical_url'] = 'your logic';
  }
}

I've created a MR from the #3.

I've removed the changes from DomCrawlerAssertionsTrait , as there is the specific issue https://www.drupal.org/project/panther/issues/3515242 ✨ Improve the DomCrawlerAssertionsTrait Active

for that trait.

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

giuseppe87 → created an issue.

giuseppe87 → created an issue.

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

Thanks for #19 but it's not clear what is Barrio in relation of this project, right now and in the foreseeable future.

Do the 2 project currently share the same code? Are there differences?
Will one of the project be deprecated in favor of the other?
Or will they continue to be two separate themes? Why?

I totally find sensible the reasons stated in #19, but I think those question and relative answers - and maybe others - are important information users should have before choosing one or other theme.

giuseppe87 → created an issue.

mr.baileys → credited giuseppe87 → .

giuseppe87 → created an issue.

Updated the patch of #104

I have added an extra settings to the current patch, that let the user choose to save the new media with the name of the entity or the file.

This could be useful, as it's common to have multiple entities with the same files, and it isn't ideal to have the media name given by the first entity imported.

However being an extra\different approach I haven't updated the MR.

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

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

giuseppe87 → created an issue. See original summary → .

@drunken monkey Thanks for the very quick reply.

Unfortunately the problem is on a project of a company I am not longer working with, therefore I can't actually debug it anymore to gather more data.
I don't know if you may want to close this issue or leave it open in case others devs could provide more insights.

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