Patch #2 works for me using Drupal 10.3.6 and PHP 8.3
Same result for altcom_neil in the above comment, so moving this issue to RTBC.
MR !9114 works for me using Drupal 10.3.6
I looking for this too.
I thought they would be on the admin/config/regional/config-translation page (Drupal 10.3.6).
Patch #14 works for me with:
- Drupal 10.3.6
- facets 3.0.0-beta1 + patch "3360426 - Updated php 8.2 compatibility"
- views_infinite_scroll 2.0.3
- AJAX enable on the view (block display)
Thanks
Thanks @boinkster for sharing kentrichards.net blog post, 4 easy steps and it now works!
Patch #5 works for me.
I didn't alter my composer.json
file for other reasons so I manually downloaded to lootie player to the libraries/lottiefiles--lottie-player/dist
folder.
Similar module with such functionnality : https://www.drupal.org/project/back_to_top_with_pi →
Renamed patch file for naming consistency.
Patch at #2 has 2 actions: fixing the missing schema.yml file and modifing the NbspFilter.php file.
The weird extra folders might come from that second part of the patch where deleted commented lines are replaced by non commented lines.
Anyway, it might better to split these fixes in two issues and keep the missing schema fix in this one.
So, here is an updated patch fixing the missing file only, credits go to Jejddx.
Using Drupal 10.3.1, I confirm @hudri at comment 28 🐛 CKEditor 5 balloons invisible when CKEditor 5 is used inside a modal Needs work :
#27 does not work, the property --ck-z-modal is no longer used in v10.3.0. The relevant property was renamed to --ck-z-panel
So patch#27 updated to use --ck-z-panel (instead of --ck-z-modal or using both for retrocompatibility) will be OK.
Patch #92 works for me with Drupal 10.3
@grimal: see
#35 at issues 3419024
🐛
Incorrect content-length header breaks HTTP/2 with net::err_http2_protocol_error
Active
where the suggested addition to .htaccess file might help you.
Header always unset Content-Length
Patch #8 works for me using Drupal 10.2.6 with Bootstrap 5 classes (button colors and sizes).
An update hook will be needed for existing tac_lite setups as all users accesses need to be set again.
Syncing "tab" and "field" could be the best of both worlds… something that has been imagined in issue https://dgo.to/2057915
I do think this is a major feature for tons of reasons:
- better user experience when setting user's access: all is on the user's form
- it's a field: you can build a view to list who has access to what, display an indicator on the user's profile...
- it can be bundled with Include all taxonomy terms (https://dgo.to/3203718#comment-15097728) patch
- it remove the need for several other useful patches (because it removes the extra user tab):
- Property $uid is deprecated (https://dgo.to/3390089)
- Displayed in default theme (https://dgo.to/3385159)
- Option to use checkboxes (https://dgo.to/3399923)
- Separate permissions for user access (https://dgo.to/3218360)
Patch #5 works for using Drupal 10.2.5
Patch #2 works for using using Drupal 10.2.5
Maybe another reviewer could give it a test to help switching this issue to RTBC status.
Allowing to bypass all tac-lite schemes may be a bit too wide.
Without a 'bypass tac_lite permission for XXX scheme', related issue Add the ability to include all taxonomy terms without having to select them → may give a finer control.
Patch #2 works for using using Drupal 10.2.5
Patch #9 works for using using Drupal 10.2.5
Patch #5 works for using using Drupal 10.2.5
Patch #2 works for using using Drupal 10.2.5
Same issue as in #7 about MR !7
I gave a try to the tac_lite module which also determines node access with the "matching taxonomy terms" setup: facets counters are then good and related to how many nodes the user has access to.
So, maybe to the way access_policy declares access to node is different from how Drupal 10 handles it (which seems to be used by facets)...
Thanks.
Duplicate of https://www.drupal.org/node/3417130 →
Sorry to reopen the issue, but I'm facing the exact same behavior and same fix with a brand new subtheme generated using today's downloaded dev release of Radix (composer require 'drupal/radix:6.0.x-dev@dev'
), either setting the subtheme or radix as the default theme: webform field wrapper class is gone...
As a first hint, I'd say that main.script.js
used in the subtheme is querying for data-toggle
attribute while Bootstrap 5 uses data-bs-toggle
.
Yes, the fix from the latest dev release fixes it ;-), thanks.
Of course, after copying the component to the child theme, all references to {% include 'radix:block' %}
in the 'templates' folder should be updated to {% include 'SUBTHEME:block' %}
That's why to radix component should be fixed.
Patch #75 works for me using Drupal 10.1.7 + CKEditor 5 on a full display mode.
Code from weseze at #7 updated by fonant at #9 works for me using Drupal 9.5.11 and Search API with a DB backend.
This is a lifesaver for the project I need random sorting on a search page.
I was wondering if it could be upgraded to get the actual reset_seed_custom
value from the view itself rather than hard coding it in the custom code.
Patch #90 works for me using Drupal 10.1.5
I forgot to say I'm using Drupal 10.1.5
Works for me using Drupal 10.1.5
PhilY → created an issue. See original summary → .
Patch #122 ✨ Also use text editor (CKEditor) for "summary" of a text field Needs work works for me using Drupal 10.1.4 (don't forget to force reload your browser page to allow new js to refresh).
Patch #3 works for me using Drupal 10.1.3
https://www.drupal.org/project/structure_sync/issues/3073810#comment-13215771
works me using Drupal 10.1.3, structure_sync 2.0.5 and menu_link_attributes 1.3.0
Thanks
Couldn't find a way to avoid [0]
to be replaced as a token at one step or another so I ended encoding the url so /search?f[0]=tags:[term:id]
is written in ECA as /search?f%5B0%5D=tags%3A[term:id]
and it worked.
Thanks @jurgenhaas anyway for your kind support for an non-related ECA issue.
Thanks, I've tried but the search and replace result shoud be stored in a temporary custom token to be used as url for the redirect action.
In that last action, I shoud use 'replace tokens' to be able to use my custom token and then [0]
(token in token) is still removed from the string...
I face same kind of error using Drupal 10.1.2 with stock node full display mode (no Layout Builder), either with Olivero or a Radix child theme.
Disabling or removing the comment field from my content type display mode removes the error.
A temporary fix was to duplicate the field.html.twig
template to field--node--uid.html.twig
in my custom theme (or to write your own twig as long as the file exists).
Then another similar error yells about missing field--node--created.html.twig
file.
Again, duplicating the field.html.twig
template to field--node--created.html.twig
fixes it.
I've also tried uninstalling manage_display module by curiosity: it removed the 'Written by' (uid) and 'Written on' (created) fields from content type form displays and view modes!!!
Works for using Drupal 10.1.2
Patch #22/#24 works for me using Scenario 1, views_data_export 8.x-1.3 (with xls_serialization addon) and Drupal 9.5.9
Thanks
Here is a patch for suggested fix by marieAscomedia in #15
It works on Drupal 10 as well (still not fixed).
I don't know which of both patches is the cleanest way to fixed the issue: #2 or #24
@mansspams: issue #3130512 doesn't fix hotlinking Lotties
Browser still reports 404 for json while it's 302 with proper rewriting to production server for png/jpg/webp....
By experiencing the same issue with external_link_popup module which has been fixed the same as per comment #8 by joelpittet, attached patch adds the missing #[ReturnTypeWillChange]
statement.
@jurgenhaas:
The process I'm trying to set up should react on both "Insert content entity" and "Update content entity" events.
Basically, it's an email notification which recipent depends on the updated state.
For "update", the core patch you provided at https://www.drupal.org/project/drupal/issues/3346430 🐛 Wrong revision can be loaded into original in \Drupal\Core\Entity\EntityStorageBase::doPreSave Needs work works using Drupal 9.5.5, ECA 1.1.2 & PHP 8.1.6
For "insert", both before and after moderation states have the same value (the new one) but that may be designed by core as there is no previous state.
Anyway, I just need to add a test in the loop for new entities.
So, I can now check previous moderation state against new one on node update event, thanks a lot.
Hotlinking fails when using Lottie animations which are saved as .json files (website using 'Media entity Lottie' contrib module to handle looties).
<lottie-player autoplay="autoplay" loop="" background_transparent="1" src="/sites/default/files/2023-01/lottie-01.json" background="transparent"></lottie-player>
)
Patch #2
🐛
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupal7.temp_fix_better_formats' doesn't exist
Fixed
also works for me updating better_formats from 7.x-1.0-beta2 to 7.x-1.0-beta5 using Drupal 7.95 (locked to 1.x because of PHP requirements).
Thanks
@jurgenhaas: security first! so I feel it better adding a 'switch user' task as a reminder (btw, it'll be nice to give it a color or a tiny icon in a corner as a warning ;-)
And it might be more versatile when exporting/importing tasks: they do not depend on the ECA's settings user then.
As a side note, is there any issue regarding both methods of handling view's results:
comment #2: trigger a custom event
comment #5: loop through the view's results
Another way is to loop through the view's results.
See https://ecaguide.org/library/use%20case/eca_feature_demo/ at "Load all admin users" task of the "User register" event.
And yes, lots of tasks require to "Switch user" before them.
Check https://ecaguide.org/library/test%20models/views/ which seems close to your needs.
Back with extended tests.
This is my first time playing with queue processes so I may be missing a step.
I'm reporting here the observed behavior hoping this can help.
Maybe the "Task is not yet due for processing" error is not that innocent.
When tasks are queued using « Enqueue a task with a delay », they are added to the queue with an expire timestamp set to 0 (checked using the queue_ui contrib module).
First run of drush queue:run eca_task
command outputs error « Task is not yet due for processing » in Terminal and in Drupal watchdog log for each pending tasks but their expire timestamps have now been updated in the queue_ui interface.
Second and later runs of drush queue:run eca_task
command seem to do nothing more: tasks are not processed even after delay expiration.
Only a Drupal regular cron processes the queued tasks.
This does not occurs when using the « Enqueue a task » task (the one without delay): tasks are queued with an expire timestamp set to 0 as well but are processed on first run of either drush queue:run eca_task
or cron, whichever occurs first.
I'll later try some tests on a blank D9 website to check if same behaviour occurs.
@jurgenhaas: thanks for quick support / fix / help.
Can the queue be processing more often with a lighter cron than the Drupal cron?
I remember back in Rules time that the Rules Scheduler has it's own cron url to process its own tasks only.
I've tried the patch:
- Existings ECA processes using queue delay should be resaved after patching so the 'delay_value' can be updated
- First cron run triggered by drush before delay outputs the following error in Terminal:
[error] Drupal\eca_queue\Exception\NotYetDueForProcessingException: Task is not yet due for processing. in Drupal\eca_queue\Plugin\QueueWorker\TaskWorker->processItem() (line 83 of /Users/.../web/modules/contrib/eca/modules/queue/src/Plugin/QueueWorker/TaskWorker.php).
=> email is not sent (as excepted)
Well, this seems to be a warning more than an error since as stated: Task is not yet due for processing - Second cron run triggered by drush after delay outputs no error
=> email is sent - First cron run triggered by Drupal admin UI before delay outputs no error
=> email is not sent (as excepted) - Second cron run triggered by Drupal admin UI after delay outputs no error
=> email is sent
So, it works! thank you
Thanks jurgenhaas for your quick reply (as always).
This is how I supposed it to be set but the email is then sent as soon as cron runs, even when run below delay set for the enqueued task (eg. when manually triggered using drush).
I've tried playing with the 'Distribute' and 'Cron run time' settings of the 'ECA processing queued task' event with no more success, still sent on next cron run.
Attached file is my updated process (shorten process with 1min delay for testing purposes and using MailHog for local mail).
Did a miss a step?
The fact is Claro table structure is different than expected by required_field_display module.
One solution is to rewrite required_field_display code to target Claro's structure (keeping existing code as it works for others admin themes).
Other solution is to add some CSS:
#block-claro-content .form-required .tabledrag-cell-content__item::after {
content: '*';
color: #e32700;
margin-left: 4px;
}
If you're already using a child theme of Claro as your admin theme or a custom module, you can add the above lines to your css (which will do nothing in a custom front theme because we're in the admin space).
If not, attached patch will add these lines to required_field_display module as a temporary fix.
BTW, I'm not sure about the best solution nor about which of Claro or required_field_display should be modified...
As said in
comment #6
🐛
File upload preview broken
Needs work
, I just needed to change the Temporary file location in File (Field) Paths settings (/admin/config/media/file-system/filefield-paths) to private://filefield_paths
to get the previews back without any patch.
In my setup, both the file system (/admin/config/media/file-system) and my image field use the private system which path is declared in the settings.php file.
Thanks to joro78 →
Same error using Drupal 9.5.3, PHP 8.1.6
My GPS field (Geofield field) is set to 'Prepopulate by geocoding an existing field' (for a better UI) and 'Prepopulate by geocoding an existing field' option references my 'Address' field.
Thus, coordinates are not calculated on import.
Temporarily setting the GPS field to 'Geocode from an existing field' before import makes the coordinates being calculated.
Once import's complete, I switch back to 'Geocode from an existing field'.
I can imagine that if you don't import a country, all your adresses belong to the same one.
So, If ever you're combining Tamper with Feeds, you can use it to set a default country code value.
Besides the failed test, patch #8 woks for me using Drupal 9.5.3, Feeds 8.x-3.0-beta3 and PHP 8.1.6
Besides the failed test, patch #8 woks for me using Drupal 9.5.3, Feeds 8.x-3.0-beta3 and PHP 8.1.6
PhilY → created an issue.