I think only the creator of the MR, the person who started the thread or the maintainers of the module can mark threads as resolved.
prudloff → changed the visibility of the branch 3026636-allow-ajax-links to hidden.
prudloff → changed the visibility of the branch 11.x to hidden.
prudloff → changed the visibility of the branch 9.3.x to hidden.
prudloff → created an issue.
prudloff → made their first commit to this issue’s fork.
prudloff → created an issue.
Thanks!
prudloff → made their first commit to this issue’s fork.
prudloff → created an issue.
prudloff → made their first commit to this issue’s fork.
prudloff → created an issue.
I did some tests with phpspreadsheet 3.5 and everything seems to work correctly.
The PHP requirements are the same as 2.3 so I don't think we need to keep supporting 2.3 alongside 3.5.
Sorry, I read the description too quickly. I can indeed reproduce when forcing a batch and can confirm the patch fixes the error.
webform_xlsx_export will now prevent users from using 2.2 (because no 2.2 release is secure).
Note however that it is the responsibility of devs using this module to use secure versions of dependencies.
I could not reproduce the error but the change seems harmless so I merged it.
prudloff → made their first commit to this issue’s fork.
berdir → credited prudloff → .
@jess thank you for reporting this but I think it would be better handled in a separate issue.
If you are able to provide a full stack trace for the error, it would be easier to see what happens exactly.
duaelfr → credited prudloff → .
prudloff → changed the visibility of the branch 11.x to hidden.
prudloff → changed the visibility of the branch 10.0.x to hidden.
prudloff → created an issue.
prudloff → created an issue.
Sorry, I think this is a duplicate of 🐛 TypeError: array_values(): Argument #1 ($array) must be of type array, null given Active .
prudloff → created an issue.
prudloff → created an issue.
prudloff → created an issue.
prudloff → created an issue.
Would it be possible to publish a new release with the ^11
fix?
Currently version 2.1.0 forces using Drupal 11.0.0.
Duplicate of 📌 Automated Drupal 11 compatibility fixes for webform_xlsx_export Needs review
prudloff → made their first commit to this issue’s fork.
prudloff → created an issue.
We noticed it is dangerous to use this property because the entity ID is not always added to the cache keys (eva_entity_view()
only adds it if the entity ID is used as view argument).
So if for example you have the same eva view on the same page but for different entities and your code uses the current_entity property to change the output of the view, the view render will only be cached once for the first entity and reused for the other entities.
prudloff → created an issue.
prudloff → made their first commit to this issue’s fork.
prudloff → changed the visibility of the branch 9.3.x to hidden.
prudloff → changed the visibility of the branch 11.x to hidden.
prudloff → made their first commit to this issue’s fork.
prudloff → made their first commit to this issue’s fork.
prudloff → made their first commit to this issue’s fork.
Duplicate of 📌 Automated Drupal 11 compatibility fixes for webform_xlsx_export Needs review ?
mr.baileys → credited prudloff → .
There is a remaining problem: if the image already has a link on it, uploading a file does not change this link (in the data model).
I'm not entirely sure this is the best approach but it seems to work for us.
prudloff → created an issue.
The draft MR fixes the file link insert on images and generates whats seems like a valid data model and correct UI, however there is a remaining problem with the downcast: it generates two <a>
tags.
I think one comes from drupalfileediting.js
and the other from downcastBlockImageLink()
.
prudloff → created an issue.
However, the patch in #11 (with Drupal 10.2) throws this error when rebuilding the cache:
The patch will probably not work without 📌 Convert CacheTagsInvalidator to use a service collector Fixed (committed in 10.3).
Not exactly the same as the requested feature, I am working on a module that keeps a daily view count history over a rolling period: https://www.drupal.org/project/statistics_rolling →
It should be possible to do this by decorating the statistics.storage.node service (which is called by statistics when recording a new view with AJAX).
You can find a similar example here: https://git.drupalcode.org/project/statistics_rolling/-/blob/1.x/src/Rol...
It looks like this might have been fixed by this commit (I have not tested): https://git.drupalcode.org/project/facets/-/commit/fe9a8b545effc7712d06e...
prudloff → created an issue.
Thanks for the explanation, it makes sense.
prudloff → created an issue.
prudloff → created an issue.
prudloff → created an issue.
Is this still a problem for you?
This module is now obsolete and is replaced by a similar block directly in the footnotes module (see
✨
All footnotes grouped in a block now available in Footnotes main module
Needs review
).
If the new block has the same bug, you should open an issue there.
drupal-quality-checker is not maintained anymore so we should probably remove it from require-dev and then we can remove the composer.lock file.
I suppose you are talking about this vulnerability: https://github.com/advisories/GHSA-6hwr-6v2f-3m88
Websites using webform_xlsx_export should already be able to update to phpspreadsheet 2.3.
Furthermore, the module only writes spreadsheets and the vulnerability seems to only apply to reading them.
However, I agree it would be good practice to require a secure version of phpspreadsheet. I just think we should commit
📌
Stop versioning composer.lock
Active
first.
Upgrading to phpspreadsheet 3 might cause breaking changes and would require some testing, so I think this issue should focus on upgrading to 2.3 and I opened another issue about phpspreadsheet 3:
✨
Support phpspreadsheet 3
Active
prudloff → created an issue.
prudloff → created an issue.
I removed Drupal 9/10 in core_version_requirement because I removed everything related to the editor.image_dialog route (which was removed in Drupal 11), but we might want to publish a transition release compatible with both Drupal 10 and Drupal 11 first.
Since 1.8 is the "Last 1.x update", I suppose we will want to target the 2.x branch.
prudloff → made their first commit to this issue’s fork.
prudloff → made their first commit to this issue’s fork.
The Twig spaceless filter is deprecated: https://twig.symfony.com/doc/3.x/filters/spaceless.html
The spaceless filter is deprecated as of Twig 3.12. While not a full replacement, you can check the whitespace control features.