Live feed

Glad you caught that. Thank you for doing a thorough review of it.

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

Now the two search forms are no longer shown. The configuration files I copied are sufficient.

With the updated GTD documentation files (see 📌 Add documentation .md files to test the pages job Active ) I have added 'main' to the list of downstream branches that we can test. Here's the first run
https://git.drupalcode.org/issue/gitlab_templates_downstream-3515276/-/p...
We see that the phpcs job has been added and runs. Ironically it does actually have a file to test against, because we have added .yml to the default list in assets/phpcs.xml. mkdocs.yml is the only file checked.

Doing that addition in phpcs.xml is correct, but I think we should not add yml to the list of extensions in $DRUPAL_PHP_FILE_TYPES because this should not be used to determine if the phpcs job gets added to the pipeline. It is correct that if other php files exist then the .yml files will also get checked in the job.

g4mbini → created an issue.

I checked it and techinically it has everything. Its more a strategic choice if a repo with 18 stars is good to add.

I would say that since it has Huggingface inference, something I had to build a custom client for, it is a good choice there also.

And we could always fork it in worst case scenario.

facine → opened merge request !2

facine → created an issue.

I've opened MR18 to use the 'main' branch. If this works, then when committed we can see if we can delete the new 'd10-docpages' branch. But leave it there until we know that the 'main' branch works OK for this purpose.

marcus_johansson → opened merge request !16

jonathan1055 → opened merge request !18

Experiencing the same problem here.
ImageMagick version 6.9.11-60.
Drupal core 10.4.7
PDF to ImageField 1.0.1-beta1

I'm using the workaround of #6 so far with good results.

Thanks.

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

marcus_johansson → created an issue.

marcus_johansson → created an issue.

Here's the new repo
https://git.drupalcode.org/project/gitlab_templates_downstream/-/tree/d1...

Although I have just noticed that we had suggested using the 'main' branch for documentation. That may be a better idea, rather than have a new branch. I should have read the issue summary before working on it! I came from the other issue and just did it.

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

I have created a new branch called d10-docpages and pushed an initial commit. This branch does not have any .module or .info.yml or composer.json files. However it does have a mkdocs.yml and docs/index.md.

We can work on the changes neede to test the 'pages' job in due course. But the immediate reason for adding this branch is to allow testing of ✨ PHPCS is run even when it cannot check any files Active

See comment, there is a helper method for it all.

anjaliprasannan → opened merge request !12323

marcus_johansson → opened merge request !15

avpaderno → opened merge request !81

marcus_johansson → closed merge request !40

marcus_johansson → created an issue.

marcus_johansson → opened merge request !40

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

marcus_johansson → created an issue.

avpaderno → created an issue.

The CI failing is because of an update in Drupal CI, I fixed it here 📌 grumphp.yml Forbidden word (blacklist) Active . Just merge with 1.1.x and it will be fixed.

I have added a comment and suggestion. If you take my code, please test it, it was written freehand in gitlab.

marcus_johansson → opened merge request !39

phenaproxima → opened merge request !1106

marcus_johansson → created an issue.

adamps → created an issue.

Whatever this line does
if ($config->get('gin_primary')) {: Maybe the problem is that I use gin for admin theme (not main theme) and to edit content?

All entity types are identical from a schema perspective. They are serving the same role.
There is a strong overlap between Address and Email, with some elements applying to all three types.
I am an engineer, so architectural elegance is a goal.

I can not think of any additional Contact Detail Types.

How do you think it will harm the UX?
I think it could simplify the UX.
All the Contact Details will use the same field, simplifying views and list builders*.
When using Search and Search API we will want to filter by type and bundle: Home and Address. If they are separate entity types, the entities with the same label are confusing

I am working on the Entity Selection handler so I can test my idea and maybe show you.

If the LocationType is being referenced from a Contact Detail, only the Location Types that match the Contact Detail Bundle will show.
If the LocationType is being referenced from any other entity type, it behaves as normal.

*I was doing some development and needed to know if an additional Email contact detail was created, and dropping into the database was the only option. We will probably need to add some UI to the admin interface.

If I change save_edit.module line 57:

     if ($config->get('gin_primary')) {
        $form['actions']['save_edit']['#gin_action_item'] = TRUE;
      }

to

      /*if ($config->get('gin_primary')) {*/
        $form['actions']['save_edit']['#gin_action_item'] = TRUE;
      /*}*/

it works and is visible alongside the save button.

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

phenaproxima → created an issue.

Hey @askibinski, you’re not missing anything and you are right.

We need to change that part in the documentation. Thanks for mentioning it. The MD5 conversion is not part of the security in any case, and originally I wanted the tool names to stay original, but I couldn’t because of limitations with some clients.

Another thing: It might be worth considering adding a "This is archived/old content" banner or something, like the warnings that api.drupal.org just got, making it clearer that some of these are old or archived documentation pages. It could be added automatically at the top of all pages under certain paths? See for example, a page like this:

https://www.drupal.org/docs/extending-drupal/contributed-modules/contributed-module-archive/contrib-modules-for-building-the-site-functionality/dates-and-events/datecalendar/drupal-6-datecalendar/date-locale-time-zone

https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →

A user may easily miss that this doc page is for an older version. A rule could be, that since it's under https://www.drupal.org/docs/extending-drupal/contributed-modules/contributed-module-archive a message like this could be shown at the top of the page?

Thanks, I will set this as a release blocker, so its added in Drupal 1.1.0 release.

g4mbini → opened merge request !154

adamps → opened merge request !170

adamps → created an issue.

When I encountered 🐛 Tool names easily exceed Claude Code's 64-character limit due to MD5 hash appending Active I stumbled upon the md5 implementation of tool ids. It's documented that:

When the MCP module exposes tools to clients, it prefixes the tool name with the plugin ID and uses MD5 hash for security. In your executeTool() method, compare the incoming ID with the MD5 hash of your tool name.

The claim is that this prevents someone from calling arbitrary tools by:
1. Only accepting valid hashes - If you don't know the original tool name, you can't generate the correct MD5
2. Preventing direct tool name guessing - An attacker can't just guess the original tool name

But:

1. The original names are exposed anyway!
description: "Original name: $tool->name, Description: $tool->description",
2. The tools/list response literally tells you: "Original name: organization_tree.create"
3. No real threat model - What attack does this prevent? If someone has access to call MCP tools, they already have
legitimate access?

But maybe I'm missing something?

starlight-sparkle → created an issue.

Thanks. The problem is that mailer_tranport is using that class from symfony_mailer without declaring a dependency and also symfony_mailer depends on mailer_tranport.

This affects fresh installs only - I have various sites running with the current release. So 2 potential workarounds:

1. upgrade from 1.x
2. hack some files to allow install - might be enough just to comment out in two places in mailer_transport module use AutowireTrait; - then put back after installing

askibinski → created an issue.

avpaderno → reopened merge request !79

avpaderno → closed merge request !79

The warning message is now implemented.

@mortona2k thanks for your suggestion. I've therefore also implemented an alter hook so that you can add your theme name to the list of supported themes, which will then prevent that warning from being displayed. Of course, any support requests or bug reports related to non-officially supported themes will be diverted to maintainers of such themes ;-)

maxilein → created an issue.

maxilein → created an issue.

✨ Support styles which are not HTML classes Active can be covered (and ✨ Add HTML class property for styles? Active can be cancelled) by this proposal: https://www.drupal.org/project/ui_styles/issues/3517009#comment-16138133 ✨ Support styles which are not HTML classes Active

A rookie question: Does ConfigEntityBundleBase also comprise blocks and paragraphs?

Breaking change proposal with both:

• merging of UI Skins themes & UI Styles definitions formats
• support styles which are not HTML classes

For styles, in {provider}.utilities.yml, an example of a style with different options:

size:
  label: "Text size"
  # kind: utility/theme. Magically added by the discovery
  attribute: class # Overridable at the option level.
  options:
    - label: Small
      value: 'text-sm'
    - label: Medium
      attribute: style
      # value: 'font-size: 15px'
      value: '--size: 15px'
    - label: "Large"
      attribute: cds-text
      value: "large"
  # library: ""

For themes/modes, in {provider}.modes.yml:

Hopefully the changes in the new version wouldn't derail anything we would do here, but knowing a new major version is close, I think it's worth keeping an eye on it.

We are currently planning to have a new major version of the dependent fullcalendar_io project that brings in the library. We haven't really tested the impact of the changes in the new version on this module yet, so I can't predict whether supporting the new version would introduce BC changes. Ideally we could support it in a feature release.

Even added a regex validation constraint. Nice work @dcam!

The fix in the MR worked for me.

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

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

mandclu → opened merge request !67

I ran into this error myself doing some testing on an unrelated issue. Based on my own experience the problem is unrelated to the Storage module, but can be reproduced on a content type (node bundle) by using a datetime field.

The problem is this line within fullcalendar.views_execution.inc:
$data['field_max'] = str_replace('_value,', '_end_value,', $data['field_min']);

Thanks for everyone's work on this. Merged into the 3.0.x branch.

mandclu → credited dpagini → .

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

Thanks for the additional work. This looks great, but I do wonder if we need to pass by reference in the API example. If we can get that cleared up, this should be good to merge.

Thanks for solving the phpstan (minor) issue.

maxilein → created an issue.

I have added the other file types to the GTD branches and re-run the MR pipeline. We now see that:
d10-plus has .module, .php and .inc
d10-theme still only checks .theme, because our default assets/phpcs.xml does not (yet) contain .engine
d10-profile checks .install and .profile

Now adding the two missing extensions engine and yml into the assets/phpcs.xml we get
d7-composer has .info, .module and .test (no change)
d10-plus has .module, .php, .inc and .yml
d10-theme has .theme, and now .engine and .yml
d10-profile has .install, .profile and .yml

(the pipeline failure was unrelated - Nightwatch on Previous major. Re-run and it passed)

Thanks for the additional work here. Great to have both phpstan tests passing.