🇸🇰Slovakia @poker10

In D6 issues, we added the following comment:

Automatically closed because Drupal 6 is no longer supported → . If the issue verifiably applies → to later versions, please reopen with details and update the version.

So I suggest to use slightly modified message here, something like this (added the part what to do if the issue still applies to D10+):

Automatically closed because Drupal 7 security and bugfix support has ended → as of 5 January 2025. If the issue verifiably applies → to later versions, please reopen with details and update the version.

The link to all currently open D7 issues should be this: https://www.drupal.org/project/issues/drupal?status=Open&version=any_7 → .

greggles → credited poker10 → .

greggles → credited poker10 → .

As now also closed issues can get credits ( ✨ Grant credit for all closed issues, not just fixed issues Active ), do we need to make an exception here and disable all credits for old D7 issues which will be auto-closed by this script? I think we probably do not want credits added as there will be a lot of issues with pre-filled credits field from the past and that is not verified.

The list of attendees looks correct.

benjifisher → credited poker10 → .

In the last table, pgsql module is 4%. Reading the proposed resolution, seems like that the module would qualify for removal, even if it is a DB driver. Can we exclude DB drivers modules explicitly, as I suppose we do not want to remove PostgreSQL support even if the module usage will be under the treshold?

poker10 → credited poker10 → .

poker10 → credited poker10 → .

poker10 → credited poker10 → .

I have not used/tried Translation Bliss module yet. Can we briefly compare it with the POTX module ( https://www.drupal.org/project/potx → )? Thanks!

I agree with @liam morland. If we add the third checkbox, the confusing UI will be still here. So for me adding a third radio will not (fully) fix this issue.

Steps to illustrate:

1. Edit block
2. Leave the Pages textarea empty
3. Set "Hide for the listed pages"
4. See that the text on a Pages tab is "Not Restricted", but actually the block is restricted and is not displayed.

So I think we also need to fix the UI, as mentioned in the IS:

Another consideration is to ensure that the descriptive test (Not Restricted/Restricted to certain pages) in the Pages tab is correct.

, or another option is mentioned in #75. Either here, on in a separate issue.

I confirm this issue on windows.

Converted the drupal_sdc-windows-3479427-8.patch to MR 11456

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

poker10 → changed the visibility of the branch 3479427-bootstrap-barrio-theme to hidden.

poker10 → changed the visibility of the branch 3479427-drupal-sdc-windows to active.

poker10 → changed the visibility of the branch 3479427-drupal-sdc-windows to hidden.

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

I think this will be fixed by 🐛 Bootstrap Barrio theme gives errors under Windows/IIS Active and that it is a general core issue (not an issue in Navigation module itself). Point 3 might be another issue and I suggest to not combine different problems in one issue, so in case you are aware of the problem and have steps to reproduce point 3, please open a new issue (if such issue does not exists yet). Thanks!

Do we need a CR for this (for example for distribution developers), since we are changing the behavior for new sites?

poker10 → created an issue.

I run the test-only job. Tests are green and test-only run failed - https://git.drupalcode.org/issue/drupal-3498100/-/jobs/4539840 . Moving back to NR.

Copying my thoughts from previous Slack conversations:

My personal opinion is that a lot of projects has maintenance and development status misconfigured, so it does not add much value for users. If that status would reflect for example commits, or issues activity, then it can be probably beneficial. But currently even some abandoned module can set these to "active development" without any implications. I raised this concern earlier in https://www.drupal.org/project/project_browser/issues/3267678#comment-15... 📌 Replace Wrench icon on project views with Gear icon Postponed . So I am all in favour for removing the filter.

robots.txt does not seems to block /modules or /themes directories, see: https://git.drupalcode.org/project/drupal/-/blob/11.x/robots.txt?ref_typ... . This is different from D7 behavior, which blocks these directories by default.

I agree with #4 that there is probably nothing needed here. Feel free to reopen if you still think anything is needed, but will need an issues summary update in such case. Thanks!

I appreciate this offer and confirm that I accept it. Thanks everyone!

mcdruid → credited poker10 → .

benjifisher → credited poker10 → .

If author != one of the maintainers on d.o., then this is probably not dependent. Otherwise -1 to this. Commented on the related issue.

I am not sure this issue is exactly the opposite of the other one, because I think we want to add the maintainers here (maybe need to update the IS/title). If the author is the owner, then I think on d.o. is always one of the maintainers. If not, I do not see a point of listing the author. But for me it will be very sufficient to list the maintainers as on d.o..

benjifisher → credited poker10 → .

I am not sure if this is regression caused by Drupal core, because when I tried to upload the same image in the core image field (not using plupload), then the image is uploaded and has correct metadata needed to pass file_validate_is_image(). Rather, it looks like that plupload module is not passing these metadata at some point and core is unable to validate the uploaded image. Can anyone confirm this?

Anyway, the workaround from #8 should be ok to use (without patching core) and even better would be to apply that only to fields using plupload upload widget, as core image fields does not seems to be affected.

I quickly skimmed the MR and tried to find if we are migrating also issues followers and have not found anything. Is there a plan to keep who is following which issue, so that issue notifications are kept as they were on d.o.?

benjifisher → credited poker10 → .

+1 for adding the information about project maintainers.

Copying from the related issue - I agree, that the information about maintainer(s) is important, as they invest time to maintain the modules and should be mentioned where possible. Without the names, it may look like Drupal (or Drupal Association) is maintaining everything displayed there. We also need to think about the target audience of the Project Browser, which currently seems to be mostly Drupal CMS users = ambitious marketers (without extra experience), so they can be confused by who maintans what.

greggles → credited poker10 → .

greggles → credited poker10 → .

poker10 → credited poker10 → .

To put it another way, I think that one of the benefits of Drupal CMS should be, that it should help Drupal core - e.g. bring things that are beneficial for all users to core, not to create differences in the basics (with the assumption that non Drupal CMS users will manage somehow).

Yes, the "product" term was not right, better term seems to be "system", because once you install Drupal CMS and apply recipes, it is Drupal core + contribs + custom config.

I created an issue in Project Browser: ✨ Update local task titles to match Drupal CMS changes Active .

Looking at the renamed "Recommended" tab, we are now using also the term "Add-ons" in Dashboard 🐛 "add-ons" vs. "recipes" Active , so currently one tab in Project Browser could have three different "names" - Add-ons, Recipes, Recommended. I am also curious if this tab name will need to change when other recipes will be displayed in that tab? Project Browser can eventually allow it sometimes in the future and there is no upgrade path for existing Drupal CMS users, to change the tab name back/to a different title.

poker10 → created an issue.

I was just saying, that it does not seems right to have a different UI while still in the same product - Drupal. So even if we commit this to Drupal CMS, I think there is only one way forward and that is to change it in Project Browser to have it the same. Not sure how we will be able to exaplain users of Drupal core + Project Browser (or later only Drupal core), why is their menu/tabs different from the Drupal CMS. Not saying about documentation, etc..

Why we want this change to be done in Drupal CMS, instead of Project Browser? If we change it only in Drupal CMS, then users of Drupal CMS will have different tabs than users with only Drupal Core + Project Browser installed, which could be confusing.

Drupal 7 is now EOL. Moving back to Drupal 8, where it was fixed originally, so that credits are assigned correctly. Thanks everyone!

Drupal 7 is now EOL. Moving back to Drupal 8, where it was fixed originally, so that credits are assigned correctly. Thanks everyone!

Drupal 7 is now EOL. Moving back to Drupal 8 as Fixed, so that credits are assigned correctly. Thanks everyone!

Drupal 7 is now EOL. Moving back to Drupal 8 as Fixed, so that credits are assigned correctly. Thanks everyone!

Drupal 7 is now EOL. Moving back to Drupal 8 as Fixed, so that credits are assigned correctly. Thanks everyone!

Drupal 7 is now EOL. Moving back to Drupal 8 as Fixed, so that credits are assigned correctly. Thanks everyone!

Drupal 7 is now EOL. Moving back to Drupal 8 as Fixed, so that credits are assigned correctly. Thanks everyone!

Drupal 7 is now EOL. Moving back to Drupal 8 as Fixed, so that credits are assigned correctly. Thanks everyone!

The last pipeline (https://git.drupalcode.org/issue/drupal-3238194/-/pipelines/251544) has multiple failures of:

Placeholders must begin with one of the following "@", ":" or "%", invalid placeholder (!url) with string: "A user-defined date format. See the PHP manual for available options." Drupal\Component\Render\FormattableMarkup::placeholderFormat() Line: 235)

Is the issue summary up to date? Because the proposed resolution refers to #2339021-11: Incorrect call to l() in system_token_info → , which is a comment year before the !url placeholder was removed in #2571695: Remove !placeholder and unsafe string return from SafeMarkup::format() → .

The list of attendees looks correct.

I confirm this is still an issue in Drupal 11.1.1 / PostgreSQL. It is sufficient to visit the URL /%c0 to get this error (tested on Drupal CMS). We have a lot of these errors in the log on various sites.

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[22021]: Character not in repertoire: 7 ERROR: invalid byte sequence for encoding "UTF8": 0xc0 0x20: SELECT "base_table"."id" AS "id", "base_table"."path" AS "path", "base_table"."alias" AS "alias", "base_table"."langcode" AS "langcode" FROM "path_alias" "base_table" WHERE ("base_table"."status" = :db_condition_placeholder_0) AND ("base_table"."alias"::text ILIKE :db_condition_placeholder_1) AND ("base_table"."langcode" IN (:db_condition_placeholder_2, :db_condition_placeholder_3)) ORDER BY "base_table"."langcode" ASC NULLS FIRST, "base_table"."id" DESC NULLS LAST; Array ( [:db_condition_placeholder_0] => 1 [:db_condition_placeholder_1] => /� [:db_condition_placeholder_2] => en [:db_condition_placeholder_3] => und ) in Drupal\path_alias\AliasRepository->lookupByAlias() (line 94 of core/modules/path_alias/src/AliasRepository.php).

Drupal\Core\Database\StatementWrapperIterator->execute() (Line: 658)
Drupal\Core\Database\Connection->query() (Line: 240)
Drupal\pgsql\Driver\Database\pgsql\Connection->query() (Line: 520)
Drupal\Core\Database\Query\Select->execute() (Line: 145)
Drupal\pgsql\Driver\Database\pgsql\Select->execute() (Line: 94)
Drupal\path_alias\AliasRepository->lookupByAlias() (Line: 131)
Drupal\path_alias\AliasManager->getPathByAlias() (Line: 37)
Drupal\path_alias\PathProcessor\AliasPathProcessor->processInbound() (Line: 70)
Drupal\Core\PathProcessor\PathProcessorManager->processInbound() (Line: 142)
Drupal\redirect\EventSubscriber\RedirectRequestSubscriber->onKernelRequestCheckRedirect() (Line: 246)
Symfony\Component\EventDispatcher\EventDispatcher::Symfony\Component\EventDispatcher\{closure}() (Line: 206)
Symfony\Component\EventDispatcher\EventDispatcher->callListeners() (Line: 56)
Symfony\Component\EventDispatcher\EventDispatcher->dispatch() (Line: 159)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 116)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 90)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 709)
Drupal\Core\DrupalKernel->handle() (Line: 19)

benjifisher → credited poker10 → .

There is no mention of the "Add-on" term in the Drupal CMS documentation: https://new.drupal.org/docs/drupal-cms .

We are already using term "Extend", so probably something like "Extend the site functionality", or something like this would be much better, until the term "Add-on" is widely used in Drupal CMS/Drupal core. Otherwise I agree that it has potential to create confusion.

greggles → credited poker10 → .

greggles → credited poker10 → .

Would be great the other way around also.

Done.

For the reference, there is an issue where Drupal 11 PostgreSQL requirements were discussed: 📌 [11.x] [policy] Require PostgreSQL 16 for Drupal 11 Fixed .

Also there is this issue for future Drupal versions and its database versions: 🌱 [Policy] How to select the minimum required database versions Active

@edwin.van.buuringen Yes. This issue was created by @bramdriesen, a provisional Drupal security team member. Together with a related issue to discuss potential policy changes: 📌 [META|POLICY] Think of a way to make it less easy to become a (co-) maintainer Active

quietone → credited poker10 → .

I agree with @matthieuscarset that the information about maintainer(s) is important, as they invest time to maintain the modules and should be mentioned where possible. Also without the names, it may look like Drupal is maintaining everything.

Was a new issue created for this yet?

Seems like Drupal CMS is now the default "download" on https://new.drupal.org/download.

Any reason why the block "Get started with Drupal" is not on the top of the page to clearly explain the differences between these two? I doubt a lot of people will scroll to the bottom to check the Gest started block with the comparision. I am not sure how a user, who visit the download page, should make a decision based on the first "Start Developing" block. Any thoughts?

I filled 📌 Clearly explain differences between Drupal CMS and Drupal core on Downloads page Active to fix this. Thanks!

poker10 → created an issue.

greggles → credited poker10 → .

I would say this issue can be closed since the upstream one was fixed (this issue was meant as a workaround in case the upstream one will not be fixed). Thanks.

Thank you for the response! If this is true:

Paul is correct that the specific thing you are asking it, isn't what we currently support and can solve

Then is it possible somehow to allow only interactions with fields, content types and taxonomy in Drupal CMS, instead of allowing to freely chat with the AI ? I think we can safely assume, that users will start to use it also for similar questions I asked during my testing, if that will be allowed. So is it better to provide wrong answers vs not provide any? I would say the second option is better.

poker10 → created an issue.

Not sure if the outdated information / wrong links is something, we can fix here - but if not, then maybe there is a possibility to at least mitigate this with instructions/pre action promt in the Drupal CMS?

To add to my previous post - the module https://www.drupal.org/project/advanced_aggregation → never existed. How AI make up that link? It is not outdated.

Asking AI to provide answers without references to source is very risky these days. And you can see it in my other reported issues. Personally I would not trust AI without a possibility to check the response. That is the reason I asked for documentation links.

But even if I do not ask for links, the answers will still be outdated - see for example: 🐛 Instructions how to use cron are outdated Active . So this is a fundamental problem, not only links-related problem. Is it better to provide a wrong answer, vs none?

I was hoping that we can mitigate this somehow in the module, or at least in Drupal CMS config in the initial instructions/pre action prompt. Drupal CMS target audience are ambitious marketers and providing them with a wrong step-by-step guides is not ideal. Technical users can verify most of these answers, but Drupal CMS is aimed at non-technical users and at least part of them will trust the AI answers.

I think we didn't want to overwhelm users with a lot of posts, especially given that we enabled the Announcements module by default for all existing installation in D7. So while I agree that currently there is too few posts in the feed, I am not sure it would be a good idea to add all from https://www.drupal.org/news → . There is also an issue for camps/events ( 📌 Announcements feed: Create upcoming camps post Active ), which I think would be a good idea to regularly include.

The proposed solution (set a higher Guzzle timeout) could be a workaround for a Drupal CMS launch. Looking at the issue in the AI module, it is known for a months and there does not seems to be any progress with it so far. With a Drupal CMS launch, there will be a massive promo and AI hype (if the decision to keep the AI recipe visible will not be reverted) and if users start loosing money because of similar bugs, it would be very bad promotion for a Drupal brand.

So yes, I think this is also Drupal CMS responsibility - if we can do something here, we probably should. I would love to hear an opinion of the AI track lead, because I think that the potential impact of the linked issue has been underestimated. We all know that models can be slow or a disruption can happen - but the end user gets nothing more than Error, please try again. in the chat window. Do you think they will visit watchdog first, or start trying again?

poker10 → created an issue.

poker10 → created an issue.

Another example on the same site:

The vocabulary "Regions" has been created. You can view it here.

Why now is it https://your-drupal-site.com domain? Is the AI assistant selecting the domains randomly?

Added another example where this happened for me.

poker10 → created an issue.

poker10 → created an issue.

Another example:

could you make sure that only high resolution images can be uploaded to the basic page content?

Response:

To ensure that only high-resolution images can be uploaded to the basic page content type, I can set up a Media field that allows images and enforce limitations based on size.

Would you like me to proceed with creating this configuration for you?

I added: yes

Response:

I have successfully created a Media field for uploading high-resolution images to the basic page content type. Here’s a summary of what was done:

Field Creation: A Media field has been added, allowing image uploads specifically for high-resolution images.
Field Configuration: The field was set to target the Media entity with the image bundle.

However, please note that there are limitations: while the field can be set up for images, enforcing size limitations for high-resolution uploads isn't configurable through the existing settings.

You can manage this field and check its configuration in the following locations:

For field management: /admin/structure/types/manage/page/fields
For specific field settings: /admin/structure/types/manage/page/fields/node.page.field_high_resolution_image

If you have any further adjustments or need additional help, just let me know!

Why the links have https://your-site-url/ at the beginning, when the site domain was https://drupal-cms6.ddev.site ?

It has been undergoing large amounts of testing including with end users via the AI team in coordination with UX folks.

That is possible, but it still recommends to download Drupal 9 (if you ask which Drupal version to use), posting links to non-existing modules and docs pages and some commands are not even executed because of Guzzle timeouts. Seems like a lot of issues for new Drupal CMS users to fight with:

https://www.drupal.org/project/ai/issues/3479159#comment-15936515 🐛 cURL Timeout and Deprecated Function Error When Using AI Translate Submodule Active
https://www.drupal.org/project/ai/issues/3498934 🐛 Instructions how to use cron are outdated Active
https://www.drupal.org/project/ai/issues/3498932 🐛 Links provided by AI assistant are frequently not working Active

And I only started to test it..

And now imagine someone will use the SEO checklist module included in Drupal CMS and start asking AI assistant things based on that list (how to xxx ...). That will not be funny at all.

poker10 → created an issue.

poker10 → created an issue.

poker10 → created an issue.

poker10 → created an issue.

poker10 → created an issue.

When chatting with AI assistant in Drupal CMS (AI recipe), I am unable to get any response and still getting

Error invoking model response: cURL error 28: Operation timed out after 30001 milliseconds with 0 bytes received (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://api.openai.com/v1/chat/completions

This issue seems more serious? The chat only displays Error, please try again. which if effectively draining your tokens again and again, but the error is only in watchdog, which could probably be not obvious for an unexperienced site builder to look at first..

I disagree this is an error in the guzzle library, because Drupal CMS orchestrate everything and you cannot expect that ambitious site builders will start changing such values.

I am using OpenAI provider. Example prompt which returns the curl error: List all fields of Basic page content type

I understand some of your points. I will only add what I have written earlier - if the site owner adds intentionally a non-stable module by composer, or lowers the minimum-stability, it is their decision. This decision is made by Drupal CMS and will allow all sites by default to have non-stable modules, even in the future (we cannot predict how will maintainers issue further releases). And as you wrote:

Many won't even know what stability levels mean.

- yes, many of them won't even know there can be some issues with these modules offered in a Drupal CMS stable, until a security issue or other incident happens (hopefully will not happen).

We have quite a few beta dependencies and I don't want to lift all of them into the project template's composer.json.

I checked all included modules now and it seems like that non-stable modules are only these:

• ai_image_alt_text - 1.0.0-beta1 - but @pameeela mentioned that they will tag stable releases
• dashboard - 2.0.0-beta2
• default_content - 2.0.0-alpha3
• experience_builder
• klaro - 3.0.0-rc16
• project_browser - 2.0.0-alpha6 - will remain alpha
• webform - 6.3.0-beta1 - I suppose they will not tag a stable release
• drupal_cms_olivero

So if at least klaro, the AI module (and maybe dashboard) tags stable versions, it does not seems that much left. Maybe we can still reconsider moving the minimum-stability to stable?

Moving to needs review. I am curious if the test failure is related to this change?

Thanks @thejimbirch. I briefly reviewed the MR and added some comments.

FWIW - the languages part of the installer was removed for various reasons recently: 📌 Consider removing languages from the installer Active

Should the search be for all open issues that have a commit?

I think that ideally yes, but hard to say if that will be doable, without knowing the number of issues we will need to review/close manually in such case.

since it's such a black-box technology to begin with

I think this should be a reson to be carefull with it, especially given the AI hype and Drupal CMS promo. We were for example close to remove the Coffee module because of performance issues, but on the other hand, there seems to be everything OK when adding a lot of AI modules, when a lot of them has less than 100 installs and are even without security coverage (yes, the recipe is already included, and I think a bigger issue is exposing it to everyone)? For example this one ( https://www.drupal.org/project/ai_simple_provider_installer → ) is not even opted into security advisory coverage.

So probably a question for @pameeela - is there any possibility to postpone the intention to expose the AI recipe to a later minor version of Drupal CMS? It will be still included (if I understand correctly), but not available to all, only to those with some technical knowledge.

I am curious how well is the drupal_cms_ai recipe with all related modules tested? Because until now, the recipe was hidden and I doubt that a lot of folks searched a way how to enable it in the Drupal CMS dev and tested it. Is it a good idea to expose it this late phase before general release given what all can be done by using the AI in a *wrong* way? (just to note, I have not tested it yet, so this opinion is based on comments from different AI track issues from the past)

According to this Slack discussion https://drupal.slack.com/archives/C079NQPQUEN/p1734040568387179 @quietone somehow filtered the list of open D7 issues which already seems to have commit and a 'needs backport to D7' tag to "just" 113:

Did some work on this and I've got 113 open issues that have a commit message. That is D7 issues tagged with 'needs backport to D7'.

I think that it is a good idea to review at least these issues for missing credits and close them properly as Fixed. Maybe d.a. can help with a custom query to verify this number if needed? Otherwise I agree with closing all others with status Closed (outdated). They will be still indexed by search engines, so if someone runs into an issue which is still relevant for D11+, it can be reopened. But I expect most of them to be not relevant anymore.

Yeah, thanks! Find out that we need to remove also InstallerFormBase.php. Tests seems to be green now, so hopefully ready to review again.

greggles → credited poker10 → .