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.
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.
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.
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.
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_imageIf 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.
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.
Created an MR which removed the included JS and CSS files and hides the markup from the template. Not sure if we also want to remove the whole CSS and JS files from the repo, as there is a code which will be used in the future when multilanguage recipe will be added, but if yes, I think it can be done easily.
Agree with @dunx, that if we want to reuse this, field_date seems like a better and more universal alternative.
Adding Drupal CMS documentation related issue: 📌 [META] Track 3: Drupal Starshot documentation Active . There were also some Slack discussions about this in the #starshot channel.
I think the most important point from there which was also mentioned in #4 and #7 here, is to have the docs on drupal.org domain and indexable by search engines, not on drupalcode.org, which is hidden a not indexed (currently).
alexpott → credited poker10 → .
I think a separate issue for changing the string until these two issues are fixed is worth opening, so I created one: 📌 Update the security coverage icon title to match the Security Team policy Active .
I have created a follow-up: 📌 Add test for Sitemap module enabled plugins Active , so I suppose we can mark this one as Fixed?
@catch By the quick fix you mean checking additional data from the resource @drumm linked (which will likely add some additional requests, because project browser currently seems to be using https://www.drupal.org/jsonapi/index/project_modules → and that does not contain the extra info) and in case there is at least one stable and covered release, mark the module as covered? Or something else?
I agree that the fix as proposed in the issue summary would be harder, and probably the other issue ( 🐛 Missing information about the version of the project going to be installed Active ) is more important that the complete fix here.
Some related discussion from Slack: https://drupal.slack.com/archives/C072BF486FN/p1736266751121509
Oh, because it seems like to be mispelled also in the libraries file: https://git.drupalcode.org/project/drupal_cms/-/merge_requests/259/diffs...
I have updated the MR with the other change.
Yes, you can download a local copy of the library, but by default, it will use the CDN version, which can be problematic from the privacy point of view. Ideally, Drupal CMS should not use any external CDN resources by default / without consent, to comply with most privacy protection laws.
18 days passed with no response. Moving back to Active. Thanks!
Adding a related issue.
Thanks for the thoughts @firfin. Week or two ago, I updated the XML Sitemap project description (see https://www.drupal.org/project/xmlsitemap → ), so the branches should be described also here. It is true, that the 2.0.x branch is with the D11 support and I do not think we will add it to the previous 8.x-1.x branch. If you feel that this IS should be updated as well, feel free to update it.
I am not aware of any new issues with the 2.0.x branch so far. One of the reasons it was tagged as beta was the fact, that I am not as familiar with the D8+ branches of the module (was previously maintaining only the D7 branch). But if there won't be any new issues, I think that we can tag a stable release soon.
Webform 6.3.x (alpha) is used by 2,159 sites now and that is their decision (because it needs to be installed manually). For example it is not something, which is allowed in most company/goverment enviroments. But Drupal CMS/Forms recipe/PB will make the decision (without acknowledgment) instead of users, which is the difference.
@pameeela We can hide it, but it overlaps with other issues - for example the Forms recipe in Drupal CMS still contains Webform 6.3.0-alpha3, which means that you will end up with a not SA covered module(s) in specific cases, which is not what users expect from a stable product (Drupal CMS 1.0.0). But if we solve this one 🐛 Missing information about the version of the project going to be installed Active , we can probably also list the all the modules which will be installed by a recipe?
I have created one follow-up, which seems more serious than the is-active class: 🐛 Cannot access Project Browser UI for contrib modules listing when on Recommended tab Active
When speaking about hardcoded values on recipes, this is related: 🐛 Security Advisory coverage status is hardcoded on Recipes Active
Yes, It is working with composer create-project. So probably moving just as a documentation issue? Thanks!
Updated IS to note that I am using ddev.
poker10 → created an issue.
poker10 → created an issue.
Just to note, I have not found an option to turn off the Navigation module feature, that you cannot click on the menu item unless it is a last child.
Fixing credits.
Created MR from the patch #2.
I have tested the MR with a latest Drupal CMS and the new service seems to block recaptcha when "Use reCAPTCHA globally" is ON and also when it is OFF (so it blocks both https://www.google.com/recaptcha/api.js and https://www.recaptcha.net/recaptcha/api.js). Thanks!
My original report was about views (these are already replaced) and contact form (there is an issue to replace it too). Not sure if it is missing anywhere else. Metatags are configured for "content" with this [node:field_seo_title|node:title], so unless we have any other config pages like the views were, I think this should probably be OK now.
As mentioned on the Slack, I am +1 to update the CNA scope as proposed. This can give us some flexibility in terms of potential security issues discovered after D7 EOL (still 300k+ sites out there) and hopefully also some possibility to have a bit control over the process of CVE publishing and coordination (together with D7ES vendors).
I agree that switching on the items, which Drupal CMS preconfigures, will be the best, if possible. And/or maybe update descriptions on items, which cannot be checked by the module, to clearly state that - so that a user is aware, that the specific item is off, but it has not been automatically checked (so it can be already done).
larowlan → credited poker10 → .
I imagine a power user would set minimum-stability to their comfort level and users using PB would just click install, not caring about module versions.
@chrisfromredfin - Was there some research done on this topic? From the security point of view, I do not think this will be a general practice. If we look at the Wordpress, you can see, that there is a plugin version displayed if you click on the plugin - so you are aware, what you are going to install. Modules can also have multiple branches, with some new features and/or BC breaks (so you will be affected even if minimum stability will be stable). Not saying that you can jump from security covered release to not covered. This seems to me very important that users are aware, what is going to be installed.
And Drupal CMS set minimum stability to alpha (as of now), so that is even worse: 🐛 Alpha stability flag in composer.json allows project_browser to download any alpha stabiility module Active . And we are talking about non-dev users here.
This is also related to 📌 Update default content to add moderation state Active , because after changes from 📌 Create Basic Content Publishing recipe Active , the homepage is now unpublished. That is causing logged-in users (except admin) to 403 (because the reason in the IS) and logged-out users to redirect to login form.
Seems like 📌 Set the site email to the email address provided by the user Active was committed, so I think we can close this.
Thanks @matthieuscarset!
I think there are two issues here (not sure if I should create a new issue for this, so commenting for now):
1. The proposed solution was to set this as a default page when user click on "Extend". This seems not done
2. When you open the "Recommended" tab, you have "is-active" class on both "Recommended" and "Browse" tabs, which is not ideal
Thanks!
Thanks @japerry!
I confirm that when launching the Drupal CMS rc1 zip with ddev in Firefox inkognito, I also see this bug.
@catch There are some other items in the module's checklist. I put to the IS only these which are confusing or not working (sorry if it was not clear from my first post).
Thanks for linking the issue @thejimbirch! I am even more concerned now that I see that it was created and there is no progress towards a fix from August (not blaming anyone).
Given this and reasons mentioned above, I think we should not postpone this issue, instead we should remove the module from the Drupal CMS 1.0.0, unless it will be fixed very soon (or unless other measures will be taken to avoid confusion).
I think it will be much worse, if we keep the module in the current shape included and marketers will start searching and changing the site configuration for no reason, just because of the incorrect reports. Removing the module temporarily seems like a better solution to me, in this situation.
So let's remove the postponed status, if possible. What do you think? Thanks!
Thanks. Created the child issues.
Thanks. Created the child issues.
More than two weeks passed without an answer. Moving to the Drupal.org project ownership issue queue.
As explained in the IS, I need permissions to at least update project, write to vcs, maintain issues and administer releases to move forward. Therefore I am asking for the co-maintaintainer role.
at this time, Drupal CMS cannot really be spun up by non-technical people
This also means we should kill the zip file download. Entirely.
Maybe I am wrong and it was not planned as one of the feature of the Drupal CMS (but there was a download link by the Drupal CMS in the initial WF designs: #3453043: Review initial Starshot wireframes → ). I think that an easy+non-technical installation is a crucial part of any CMS project. The core is going away from from zip/tarball downloads ( 🌱 [meta] Deprecate tarballs, because they are incompatible with Composer-managed dependencies, Automatic Updates, Project Browser, and release managers' health Active ), which is OK, but Drupal CMS is a different product, for different audience and if we look at other CMS systems, most of them allow "download, copy, install and go" approach (see Wordpress, where you just need to download a ZIP and copy it to the hosting - the same apply to Joomla, Typo3, ...). Anything more complicated could be a barrier to a faster adoption of Drupal CMS, which, as you wrote, is unfortunate. I hope that we will be able to figure out this somehow and change that, because an easy installation is something, which was driving also Drupal 7.
Does this needs to be discussed in a separate issue? Seems like a quite significant change for me. Thanks!