The problem is core introduced a new $dependencies property in AttributeBase in this commit:
https://git.drupalcode.org/project/drupal/-/commit/ccbcf3126e1e592d381b5...
And Xray's XrayAuditTaskPlugin, that has AttributeBase in its hierarchy, also declares a $dependencies property:
https://git.drupalcode.org/project/xray_audit/-/blob/2.x/src/Attribute/X...
This makes current Xray release not compatible with Drupal 11.3.
Well, I talked too fast.
We need to update external entities module from 2.x to 3.x. It seems things have changed and this module needs to be updated to be compatible with External Entities 3.x.
I have created a related issue: #3560727: Drupal 11 compatibility →
@colan, feel free to propose a patch to fix that. I currently don't have time to fix this, and the other maintainer is not available for a few days.
Hi, thanks for pointing this out. Honestly, I missed this one, I thought it was already D11 comaptible.
Release ready in short.
Given that support for 9 and <10.2 has been dropped, this implies a new major version is required.
We should open a 2.x branch and move the commit there.
This has no easy fix as core doesn't provide a way to detect when a form as been changed before saving (to alert user values will be lost when clicking in these buttons, or to save values elsewhere and recover when reloading the page).
Adding such mechanism seems like an overkill. I think the solution would be to create a dedicated page for these buttons, and replace them with a link. Using a link it's clear to the user that values will be lost if it is clicked.
As I understand the idea is to mimic core behaviour, so after collecting all requirements give the change to alter them (in this case probably to remove them), right?
This sounds like the way to go. I would like to think about it just in case there is some edge case that I'm not aware of. Like, for current installations this may break any current workflow or way to use the module? I can't think on any. to be honest.
Also, @gogowitsch, if you read this, what do you think?
The merge from GitLab UI failed, so I've merged it manually in my local. I'm closing the MR.
Tested and working, merged triggered.
Thanks for the patch! (and sorry for being so late)
This was done time ago by @jonhattan time ago (commit 995872f3).
Tested, before we had:
x-drupal-dynamic-cache: UNCACHEABLE (poor cacheability)
Now we have:
x-drupal-dynamic-cache: MISS
This is an improvement, and good enough to close this issue.
By the way, I would use Unlighthouse instead of Lighthouse. Unlighthouse executes Lighthouse in a complete site, providing a report that cover all discoverer pages. It detects patterns in URL to avoid reviewing the same type of paga again and again (for example, it tests a few products in a shop instead of all products), it can follow the sitemap or autodiscover the URLs to check.
See its home page: https://unlighthouse.dev/.
Example of output:
The first line is a score calculated taking into account all visited pages. Each line below is the Lighthouse report for each visited page. Each report line can be clicked to see all the details. Unlighthouse can be run locally or in a CI system.
We maintain a DDEV addon for Unligthouse: https://github.com/Metadrop/ddev-unlighthouse
Ok, I tried to address #11 and I did a wrong commit, then reverted and finally the good commit that removes the flush cache command as requested at #11.
Added post update hook requested in #11 (Sorry for the delay!).
Oh, I see it:
PHPUnit\TextUI\TestDirectoryNotFoundException: Test directory "/builds/issue/drupal-3547258/core/PATH-TO/core/tests/Drupal/Tests" not found in /builds/issue/drupal-3547258/vendor/phpunit/phpunit/src/TextUI/Configuration/Xml/TestSuiteMapper.php:72
I guess I'm modifying a file used by the testing system itself.
I've tested it on the site I originally detected the problem and it works better but still not perfect. It went from 155 broken links to only 27. Some that are detected as broken links are not broken links. Fo example, this one:
Now, as you can see, the URL is correct (formaci%C3%B3n, urldecoded, is formación), but Entity Mesh still detects it as broken.
The link is on WYSIWYG field; I guess this is not relevant, but I drop it here just in case it is.
Ouch, yes, sorry, I was playing with both modules and I went to the wrong issue queue!
Not sure why tests failed.... it is core/phpunit.xml.dist file used in the tests?
Added several tokens following documentation example mentioned in the issue body:
- PATH-TO: path to docroot (usually this is a ' web' folder).
- LOCAL-SITE-URL: URL to the site (either accessing from the user computer or if it is a DDEV setup it could be the internal URL)
- DB-SCHEME: database scheme: mysql, postgres.
- USERNAME: database username.
- PASSWORD: database password.
- HOST: database host.
- DBNAME: database name in the host.
- BROWSER-OUTPUT-BASE-URL: URL to the site when accessed from the user computer using a browser-
Some paths where changed to be coherent with PATH-TO (so we only need one PATH-TO token, not two different ones with slightly different values).
Hi, I'm from Metadrop and we are using https://github.com/Metadrop/ddev-lighthouse internally for our tests and QA process. We would be glad to help if you want to use it or take ideas from it.
We are currently working to improve it to make it easier to use.
Gitlab template was added. This not much but enough to start.
Drupal is not supported so I'm closing this. Feel free to reopen if this applies to a current supported release.
Drupal 7 is not supported anymore so I'm closing this as outdated.
Strange error indeed.
This doesn't happen in current maintained branches so I'm closing it as outdated.
Too many for now, let's close this and fix warning later.
Patch works ok, error is gone.
Raising to critical as the site is not working at all.
I think is fixed, can you try the dev version with the fix?
Ok, I see the problem. During
📌
Drupal 10 compatibility fixes
Fixed
the linked_media_library widget was changed: the field type it can be applied to changed from linked_entity_reference to linked_media_library. This was to solve an error apparently due to Drupal 10 compatibility, although it was just because Media Library module was not enabled. Changing the field type to something non-existent "solved" the issue because the widget was not processed anymore.
The problem should be solved removing the widget if the Media Library module is not found.
There is no field 'linked_media_library'.
I 'm not sure what this means. If you mean that you expect the module to create a linked_media_library field, that is not the case for this module. The user should create the field as needed. The module just provides the widgets and behaviour so it can be added to a field.
If this is not what you meant I would need more info to fully understand the problem.
+
The Config Inspector module, apart from inspect configuration, also checks the conf and the schema. Inspiration can be taken from it (because depending on this module seems too much): https://www.drupal.org/project/config_inspector →
Also this change record may be relevant: https://www.drupal.org/node/3362879 →
Great! Stable release published, thanks!
Beta 1 available.
This has been addressed already.
Well, it as much simpler. The fields are in different order when loaded from AJAX.
So only thing needed is to add a #weight to have always the same order and avoid confusing the user, like my case.
Committed, it should work with D11 now.
Merged, thanks!
It is broken due to category LinkedEntityReference @FieldType annotation.
I would say it is because composer is using the module without taking into account the composer.json of the module. This makes sense because that composer.json file is, as far as I know, for Packagist, not for the local composer.
Once there is a release of this module composer will be able to solve the issue.
My idea is wait a few days, maybe next week, to receive feedback from other users, then publish a new release.
If no feedback is received I will publish the release anyway, as the new code worked ok on your site.
Let's be optimistic and merge this.
I guess I forgot to add compatibility with Field Group 4.x.
Can you try the updated issue fork?
Hi @sirclickalot, the patch to upgrade is here: 💬 Drupal 11 release for this? Active
I will help me a lot if you provide feedback there.
Thanks!
Hi, thank you very much for your work. I'm a new maintainer focused in the D11 release. I had to do additional work for this, please check 💬 Drupal 11 release for this? Active .
It would be great if someone could test this with a real site, because the one I'm using is quite small. More testing will help a lot.
I'm closing this issue to have all the info for the D11 release in the other issue.
I'm going to add all the people who helped to the other issue to give credit, thanks!
Added patch for testing.
tunic → changed the visibility of the branch 3498382-drupal-11-release to hidden.
Hi, let me try to do the upgrade.
New maintainer on duty here.
I didn't have this module under my radar, now I have it, I think I can upgrade it soon.
Thanks for the review (and the module!), Luke.
Regarding the post-update hook , you mean that:
/**
* Flush cache to regenerate hash with sorted parameters.
*/
function oembed_lazy_load_post_update_regenerate_hash(): void {
}
would be enough? That would be the only change required, right?
This patch solved the exact situation described in the issue: a site behind a proxy that was sorting the query params, and this module was returning access denied.
Moving to a bug report as the module should just check the integrity of the params, not the ordering.
I suspect the errors reported by the CI are not related to this MR, and this why I not moving it to RTBC, but I would say it is.
For anyone coming to this issue with the same problem I confirm that requrie-dev trick solved the issue.
Thanks!
IT seems there's a workaround: https://www.drupal.org/project/gitlab_templates/issues/3518843#comment-1... 🐛 Dependencies in submodules are not taken into account Active .
No, no module had o tests before, not in Drupal CI but also not in Gitlab CI.
The require-dev seems like a reasonable way to solve this in a simple way without increasing complexity in the GitLab CI testing workflow, I'll try that, thanks!
It seems the problem with phpstan is a bug in the Gitlab CI templates, see 🐛 Dependencies in submodules are not taken into account Active .
There's an error from phpstan tan I can't fix.
The problem is:
------ ------------------------------------------------------------------------
Line modules/image_styles_generator_webp/src/DerivativeWebpWarmer.php
------ ------------------------------------------------------------------------
31 Parameter $webp of method
Drupal\image_styles_generator_webp\DerivativeWebpWarmer::__construct()
has invalid type Drupal\webp\Webp.
------ ------------------------------------------------------------------------
And in line 31 we can see:
public function __construct(LoggerInterface $logger, Webp $webp) {
We can expand the header:
/**
* Constructs a Regenerator object.
*
* @param \Psr\Log\LoggerInterface $logger
* The logger channel to log all info.
* @param \Drupal\webp\Webp $webp
* The webp service.
*/
public function __construct(LoggerInterface $logger, Webp $webp) {
And check that at the beginning of the file there's a use statement.
use Drupal\webp\Webp;
The Webp class if from another module (the Webp module) but it is declared in the dependencies of the image_styles_generator_webp submodule.
phpstan errors and phpcs errors are standard code errors and can be easily fixed.
However, cpsell is more tricky. The typos must be fixed, but words like "commandfile" are legit so we have to instruct cspell to ginore certain words that are not typos.
For this, we need to create a .cspell.json file (see https://project.pages.drupalcode.org/gitlab_templates/jobs/cspell/) with this content.
variables:
_CSPELL_WORDS: 'commandfile'
I've changed the option from fast to skip-existing, apart from that the patch was good, thanks!