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!
This is indeed very interesting!
Let me review it and come back with my findings.
Remove comments on Responsive Thumbnail Image as there's a D11 release available now
I guess this will be fixed when 🐛 Svg images does not render when applying image style Needs work lands into core.
While that happens, patchs are welcome.
This module uses the settings form of ResponsiveImageFormatter (it just extends this class and calls parent's settingsForm). This should fixed in core. This way, all image formatters will benefit from the fix.
See https://www.drupal.org/project/drupal/issues/1291262 ✨ Add 'alt' and 'title' tokenized text options for image formatters, and a 'title' option for the generic file formatter Active .
There's a new 2.x branch where this patch is going to be merged. We'll have a Drupal 11 release and switch to semver.
Hi glynster, thanks for the report and the patch!
I would like to reproduce the bug, can you provide the steps to reproduce it?
Can you provide more info on this issue?
Please feel free to reopen if there's a way to replicate the issue.
Thanks!
No answer from maintainer.
Moved to "Drupal.org project ownership".
Module: https://www.drupal.org/project/media_responsive_thumbnail →
Thanks, it looks good to me!
I would prefer to wait for comments from @lpeidro before committing this forward but I think it is ok to move it to RTBC.
Tested, it seems to work ok, available in release 2.1.0 already deployed.
I missed this one.
Good to know the root cause, thanks for sharing!
BAck to "No known problem" as the issue the moved this page to "Needs work" has been addressed.
"Recommended" releases have been removed per 📌 Remove “recommended” status for releases? Active but this page still talks about them.
With this change this page is outdated: https://www.drupal.org/docs/develop/git/git-for-drupal-project-maintaine... →
It still references "recommended" releases. I'm editing the page to indicate the problem, but I'm not confident enough to edit it.
Created 2.0.0 release!
The "core" property in the info.yml needs to be removed. This means that module is not compatible with Drupal 8.7 and previous (see Let Drupal know about your module with an .info.yml file → ).
Hence, we need to drop support for 8.7 and before. This implies creating a 2.0.0 release. I don't like it for such as small change, but SemVer dictates that breaking changes implies a major version, and this is a breaking change.
An example of the view:
I stumbled upon this issue again. I've tried to better explain the situation to address #28:
Note that if #empty_value is the same as a key in #options then the value of #empty_option is used for that key in the #options array. This is because #empty_value and #empty_option are merged into the #options array. Hence, make sure #empty_value is not a key in #options array.
If this is not enough, please point out what is missing or what would be a better approach to this. The issue is complex and it is hard to understand without a little bit of context or checking all the comments in the class' header.
I'm assuming you are using Content Moderation and the default "Editorial" workflow. In that case, it should work. Just as reference, this is the test I've done in my local:
- Enable Content Moderation module
- Apply "Editorial" workflow to "Basic Page" content type (/admin/config/workflow/workflows/manage/editorial)
- Create a new Basic Page and save it as draft
- Create and authlink for that content
The generated authlink works and the unpublished draft is visible.
If this is not the case for you recheck the workflow configuration, or detail your conf so we can reproduce your problem.
Added some minor tweaks to the view.
Thanks!
I would like to propose a border or similar to mark releases that are covered by the security advisory policy.
Something like this:
This may also help to distinguish between stable and not stable releases (as long as the module has opted-in the security advisory policy).
It looks good to me, but I'll wait for @lpeidro review.
Thanks!
Also, I guess that process can be done directly using SQL. I mean writing a SQL query that returns what the values calculated in $main_fid and $unused_fids. Probably, this is not trivial, but if done will solve many performance problemas with sites that have huge number of files.
I don't know of such tool, I wanted to have the WID just to locate the original message easily.
Thanks for the quick response!
Define the alyout for each node o use a fixed one for all.
Now we have the shuttle and the demo modules, let's explain this.
Add info about Media Responsive Thumbnail and Media Responsive Thumbnail.
Yes, you are right Drupal 11 is not available, I was focusing in the issue description and I totally forgot D11.
The issue seems active then.
This was fixed in 2.0.1. release.
Let the bot do its job.
Added suggested patch.
Mm... I've checked and Drupal core 10.4.4 is available in Simplytest. However, the module release I pointed out is not.
I think this can be closed as outdated.
It also happens with module releases. For example, for Monitoring module the last release available is 1.14 while last release is 1.17.
Added the wid directly to the message.
I would wrap the id tihe '[]', but because the other fields are printed without any separators or wrappers I just added it naked. If output format is not fixed (because people tends to process it someway) I would separate fields somehow (for human consumption more than computer comsuption).
I've tried patch from #23 and but see no improvement, the content is displayed totally broken (CSS issues). Not sure if this is because the use of layout builder, paragraphs or what. Using Drupal 10.4.4.
@jez300 that's indeed an strange behavior. I think that should be an issue, because I don't see any reason to restrict the form id in such way. However, from your message, it is not clear if the form ID should not match the "twig template name" (as stated by you in your message) or the theme name (as stated in your edition). Can you clarify that? An can you create the issue?
I'm not sure if this is something really needed, but it was suggested from some feedback on the theme. I think is worth to write it here.
If you want this functionality, please comment and add your point of view, thanks!
Hi kopeboy, thanks for your interest.
The module doesn't generate a file but an inline SVG, see screenshot.
This means that it will be cached depending on where it is placed, the module doesn't provide any caching configuration, so it uses standard Drupal field formatter caching.
Marked as fixed, fell free to reopen it if this response is not clear.
As I'm Form API guide maintainer I'm removing it from the list that need maintainer.
Thanks bot, proposed patch merged.