budalokko → created an issue.
The "correct" setup:
- plupload_widget - 2.1.0
- plupload - 2.2.0
- plupload library - v2.3.9
v3 of the library might seem to work but it doesn't so please ensure the installed and detected version is 2.3.9 at /admin/reports/status
I would enable "plupload test" module and check if the upload works fine just with that (/plupload-test).
Might be useful checking the created file in temporary directory, and how it ends up at `/sites/default/files/plupload-test`.
You don't mention the setup, so here are some random ideas:
- Install on a minimal site without other modules
- Add plupload widget to a content entity type, not a paragraphs field or other kind of field which does Ajax requests.
- Start with a single valued field, and upload just one file.
Your solution works like a charm !! Tested in both situations:
- The original text format already contained
sourceEditing
plugin -> still works - The original text format does not contain
sourceEditing
plugin -> now it works !!
So this would be RTBC for me.
MR 404 contains the third option:
- Just mention in the documentation.
budalokko → created an issue.
Committed and new release available. Thanks @bwaindwain !
@bwaindwain I think https://www.drupal.org/project/plupload_widget/issues/3433938 📌 Automated Drupal 11 compatibility fixes for plupload_widget Active already fixes this. Do you have the possibility to test that one?
Any caring soul wishing to test MR 12?
Patch -> https://git.drupalcode.org/project/plupload_widget/-/merge_requests/12.diff
budalokko → made their first commit to this issue’s fork.
Thank you all for the work !! New release available -> https://www.drupal.org/project/plupload/releases/2.2.0 →
I've fixed the tests with the new "langcode" attribute. It only appears when "provider" is "menu_link_content". Is this the desired behaviour or a bug?
Still "Needs work" because new tests in a multi-language setup should be added, right?
- Tests pass for phpunit (previous minor)
!!!
- Test failures in phpunit
are unrelated to this issue (token added to logout links in
https://www.drupal.org/node/2822514 →
).
- Test failures in phpunit (previous minor)
seem related to php 7.4 . An up to date project pipeline could be triggered to be certain if the same failures happen on the current 1.2.x or just on this branch.
budalokko → made their first commit to this issue’s fork.
budalokko → created an issue.
Sorry the noise ... wrong module :)
budalokko → created an issue.
budalokko → created an issue.
An additional use case for this would be to improve customer data protection by not storing received webforms at all in the website, just in Pardot.
But then a different solution than ben.hamelin's MR is needed as it still needs the webform to be stored so submitDataToPardot
can retrieve it.
Same issue in d7 -> https://www.drupal.org/project/plupload/issues/2161829 →
From the plupload module side there's nothing we can do other than ensure that the `temporary_uri` setting is really taken into account for the temporary upload location, as it seems it is:
https://git.drupalcode.org/project/plupload/-/blob/2.1.x/src/UploadContr...
Closing as won't fix as I'm pretty sure there's no other solution in the module side. Feel free to re-open if there is.
Patch in #2 works for me in Claro, but #5 still shows the "Collapse" button misplaced, leaving less space for the actual form fields:
Patch in #2:
Patch in #5:
5 years later I was able to reproduce this one. In my case is in combination with the Next.js → Drupal module.
Instructions to reproduce:
1. Create an encryption profile
2. Install Next.js module and its dependencies (no worries, no need to configure).
3. Delete your encryption profile through the UI.
4. WSOD !
The issue is due to EncryptProfile config entity declares a "canonical" path in its "links" section, but doesn't implement it:
https://git.drupalcode.org/project/encrypt/-/blob/8.x-3.x/src/Entity/Enc...
Drupal example on configuration entities →
does not include a "canonical" path. Also when creating such entity with drush gen entity:configuration
, the resulting entity does not contain such path, and the module does not use it.
Hence, my suggestion would be to remove that line, which actually fixes the issue.
Please check the attached patch. It does not contain a test. I could try writing it, but not sure its actually wanted. Not breaking the other tests might be enough in this case.
BTW the code in Next.js triggering the error is something like this, in a generic hook_entity_predelete
, which seems quite right:
if ($entity->hasLinkTemplate('canonical')) {
$url = $entity->toUrl();
}
This patch was very useful when combined with ✨ Add possibility to skip flushing all image style derivatives when an image style configuration changes Needs work . It allows to slowly replace old derivatives with the new ones when an image style change is done without the danger of having to remove all them and wait hours for the images to be re-created.
If the Drupal Core issue is merged at some point, it would be great to convert this in a "Feature Request" and maybe add a setting to control the behaviour.
I've created a MR which simply does not show the state selection fields until there is a workflow set. So, the user should access the form, select a workflow and press save. Then the form behaves normally.
Please test with this patch -> https://git.drupalcode.org/project/moderated_content_bulk_publish/-/merg...
budalokko → made their first commit to this issue’s fork.
After upgrade to 8.0.x-dev release, only the "Display live results" suggester is available. At least in my setup (elasticsearch:7.17.0).
So this one could be closed as outdated AFAIK @mparker17
@mparker17 thanks for your work on this module. This issue has been fixed in the mentioned latest 8.0.x-dev release.
@mparker17 thanks for your work on this module. This issue has been fixed in the mentioned latest 8.0.x-dev release.
Closing as duplicate of 🐛 Can't save node after d10.2 update Fixed . Please test the new release and re-open if the issue still exists.
Merged this one. If there's some issue related to "ConstraintValidator" please re-open or create a new issue.
Was waiting for some RTBC ...
Isn't this a duplicate of 🐛 Can't save node after d10.2 update Fixed ?
@paulguy Which ConstraintValidator? Is it related to 🐛 Cannot upload large files above PHP.ini limits Active and its patch?
Merged. Thanks for checking !!
For those having difficulties reproducing, the following steps will be useful (do this after clicking "Add media" to use Media Library widget):
1. Scroll down on the listing until pager, click on the link to visit second page.
2. Memorize one of the first images, and its position on the grid.
3. Go back to page 1. Use ANY filter that will include the image you memorized in step 2 into the first page.
4. Click on that image.
5. The image at the same position you memorized in step 2 will appear instead of the one you selected.
All this, with
parameters:
twig.config:
debug: true
Hey @Paul_Gregory ! Seems a duplicate of ✨ URL for link enhancer uses arbitrary language type (interface) Needs review right?
Core added the following in the render
function of their Rss feed style plugin:
'#attached' => [
'http_header' => [
['Content-Type', 'application/rss+xml; charset=utf-8'],
],
],
This was the issue -> https://www.drupal.org/project/drupal/issues/3272985 🐛 RSS Feed header reverts to text/html when cached Fixed
Applying the same change to 8.x-2.x fixes the content type header issue. I can provide as a patch, but should it be in this issue or a new one @DamienMcKenna?
Thanks for the detailed bug report !! There was too much refactoring to pass those eslint tests :)
Can you try the patch in the MR? It's this one:
https://git.drupalcode.org/project/plupload/-/merge_requests/13.diff
budalokko → made their first commit to this issue’s fork.
The issue happened also in my setup 4 years later :)
- Drupal: 10.1.8
- Advanced Views RSS Feed: 8.x-2.2
Got fixed with "Rewrite results -> Remove whitespace".
Not changing the issue status as maybe its something specific to our setups.
-----------
The problem can be seen with some debugging in views_rss_format_preprocess_views_view_row_rss
, the date contains a "new line" character in the RSS feed and that is not accepted by some readers:
Thu, 14 Dec 2023 06:00:11 +0100\n
Not sure what's the difference, but using the URL for the patch I provided above applies cleanly:
https://git.drupalcode.org/project/plupload_widget/-/merge_requests/9.diff
(.diff instead of .patch)
This is the change in core that makes plupload fail since 7.99 -> https://www.drupal.org/node/2345695 →
The removal of this line in modules/image/image.field.inc works around the issue:
$elements[$delta]['#upload_validators']['file_validate_is_image'] = array();
The commit -> https://git.drupalcode.org/project/drupal/-/commit/fd71fedd655b76e3652fc...
Now we just need a proper fix :)
Most probably It won't make It work, but wanted to clarify that 7.x-2.x-dev expects a diferent version of plupload library, probably something around 2.1 or 2.3.
I've created it. Then it seems the following allows to install it.
composer clear-cache
composer require 'drupal/plupload_widget:2.0.x-dev'
and the patch applies -> https://git.drupalcode.org/project/plupload_widget/-/merge_requests/9.diff
Not sure why that could be happening. Maybe the branch name in gitlab is wrong (2.0.x-dev
??)
Checked and other modules do not contain -dev
in the name. I've created a new branch without the -dev
suffix. It doesn't work but maybe is some cache issue. Will wait one or two days and try again.
probably the patch should be applied against current dev version, not latest release
Added `link` field type which seems to work fine. Can be tested in the following patch:
https://git.drupalcode.org/project/paragraphs_sets_plugins_ui/-/merge_re...
budalokko → created an issue.
The linked MR provides the option:
- Create a machine name for the set in ParagraphsSetsCreator::generatePreset()
The generated yaml still uses the `type` keyword instead of the new `bundle`. This was changed in ✨ Consider using `bundle` instead of `type` Fixed and needed to be updated for the changes to work.
budalokko → made their first commit to this issue’s fork.
budalokko → created an issue.
Committed, thanks !!
This was fixed in #3124700: Deprecated Code Report → .
Committed the same pattern as plupload. Thanks !!
MR patch to test -> https://git.drupalcode.org/project/plupload_widget/-/merge_requests/9.diff
budalokko → created an issue.
The issue seems to be fixed in current default themes Claro and Olivero:
Committed, thanks !
Previous issues were due to Drupal CI not matching current PHP minimal version :)
Attached again:
- A test only patch that demonstrates the issue.
- A test + the mxh lazy subscriber fix from #136-#139.
- interdiff against #139.
Only test results against PHP >= 8.1 should be taken into account please.
Removed the "Needs tests" patch as this should be complete now and ready for review. It's worth noting this is exactly the same patch in #136-#139 already working for 2 users. Just tests added.
No news from the original reporter for years so closing as outdated.
@RenataBin if your issue is still not fixed, you could create new support request with detailed information on what you did and what errors you get.
Sry the noise.
Last test-only patch did not fail in CI. Here I try to visit `update.php` with the same path as core tests do.
I've created a test case that demonstrates the issue. Attached patch `2816033-no-subscribed-events-153-test-only.patch` only contains the test, so it should fail.
The other `2816033-no-subscribed-events-153-test-and-fix.patch` attachment contains the test and also mxh's fix from #136 and #139, so hopefully should pass.
Interdiff against #139.
That's it !
Plupload 7.x-1.7 -> Plupload library 1.5.8
Plupload 7.x-2.x -> Plupload library 2.3.9
Closing !!
Committed to 7.x-2.x-dev. Thanks !
Sry, can't reproduce.
Have you tested in a minimal installation, at the plupload test form (/plupload-test
) and with a correct version of the Plupload library?
- Plupload 7.x-1.7 - Plupload library 1.5.8
- Plupload 7.x-2.0 - Plupload library 2.3.9
We could close this one as we have now an RC including some automated tests and composer installation process. Unresolved child issues will be kept open but don't seem to be blocking the module usage.
Tests pass -> https://git.drupalcode.org/project/plupload/-/pipelines/65763
Next would be eslint, phpcs, phpstan, stylelint.
budalokko → changed the visibility of the branch 2245943-why-test-fails to hidden.
Added 3 tests:
- Form element kernel test.
- Upload controller kernel test.
- One functional javascript test with simple file upload.
Need to fix execution in GitLab CI. moxiecode/plupload library needs to be downloaded and added !!
- Readme file was converted to md format and updated in
https://www.drupal.org/project/plupload/issues/3317550
📌
Replace README.txt with README.md
Fixed
- Created some documentation pages with updated instructions (composer workflow) in project page
so let's close this one.
budalokko → changed the visibility of the branch 2.1.x to hidden.
Patch looks correct and works !! My setup is quite simple, but setting to RTBC as specific issues could be fixed in separate issues.
I could test and working fine:
- Using the "callback" functionality in header via DrupalInitialize
- Using the "html" functionality in footer via DrupalInitialize
@mabuweb The following is needed for using and testing in a d10 site and through the upgrade:
- Add the issue fork as an additional repository, and instruct composer to use it for this specific module. Notice the "exclude" key added in first repository, and the entire new repository added for drupal/tcpdf
"repositories": [
{
"type": "composer",
"url": "https://packages.drupal.org/8",
"exclude": ["drupal/tcpdf"]
},
{
"type": "package",
"package": {
"name": "drupal/tcpdf",
"type": "drupal-module",
"version": "dev-3385155-drupal-10-support",
"source": {
"type": "git",
"url": "https://git.drupalcode.org/issue/tcpdf-3385155",
"reference": "3385155-drupal-10-support"
}
}
}
],
- Require this specific version you added:
composer require drupal/tcpdf dev-3385155-drupal-10-support
Once the module maintainers merge this and a new version is available, those changes could be removed.
Committed to 7.x-2.x branch, along with an improvement to plupload test that helps demonstrate the issue.
Thanks !!!
This was fixed in https://www.drupal.org/project/plupload/issues/3127215 →
Moxiecode Plupload is kind of abandoned project. I suggest we forget about 3.x branch and focus on their latest, super-stable, secure 2.3.9 release.
I have added 2.3.9 recomendation to:
- Project main page
- Composer install instructions ->
https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →
- readme -> https://git.drupalcode.org/project/plupload/-/blob/2.1.x/README.md
so closing it. Thanks !!
omg we still had that empty file there?
thanks !! Committed !!