Contacted Dietrich Moerman (dietr_ch) via LinkedIn today. Waiting for an answer.
As I can see - no changes with the issues queue.
Updating this once again.
Tested with 11.0-dev version. Everything works fine.
Okay, I was able to reproduce the issue and found that it was caused by the StarRatingWidget's line '#default_value' => NULL
, Its fixed in the latest 8.x-4.1-alpha4 release.
The issue could be closed as outdated.
Can confirm that the changes works fine with the Drupal 11 and current 8.x-4.x-dev branch. Moving to the RTBC
Hi, @tjtj! Could not reproduce reported issue with Drupal 10.3 and the 8.x-4.1-alpha3 release.
Can confirm the issue and the patch that addresses it. Moving to RTBC
Hi, @mortona2k!
Could you please provide an example and maybe some screenshots on a subject?
Thank you. Posted a link to the repo on the project page.
Here's the patch #25 with the Facets plugin still available for the Better Exposed Filters.
Version - 3.0.0-beta1
Could confirm that the #2 addresses the issue and resolves it. Tested with 3.0.0-beta1.
Could confirm that the #5 addresses the issue and resolves it. Tested with 3.0.0-beta1.
Failed tests still needs to be resolved.
Hi, guys!
Shouldn't there be some update function to make those changes applicable to the current users?
Thank you, @chaitanyadessai.
So it's basically (not) working the way it was previously described and needs work to be fixed.
Hi, @chaitanyadessai!
Could you please add SVG to the allowed types list and try to upload an SVG file?
Well, it sounds reasonable to light up this functionality in the module's name - this one or a new sub-module. It's not looking intuitionally understandable that this part of functionality exists here.
Created the MR, that resolves the issue.
Attaching patch as well.
Could confirm that issue is still reproducible with menu sub-levels, and caused Menu Item Extras using another template for them which isn't preprocessed with available translatable_menu_link_uri_preprocess_menu
function.
Twig debug screenshot attached.
Can confirm that after the patch implementation double allowed types disappears but couldn't load svg image anymore.
Moving the issue to "Needs work" status.
Tested all the listed issues and could confirm that functionality 1.0.2 tag of Editable Fields works fine.
Moving issue to RTBC.
Tested with different field types and could not reproduce the issue (screenshots provided).
Moving to RTBC.
Waiting for https://www.drupal.org/project/videojs/issues/3380089 💬 Add composer.libraries.json to support composer workflow Needs review to get closed and merged.
Hi, guys!
I've worked on the requested functionality in the module that addresses the entity form issues (previously labels and now help text too).
Please, consider using it in your project in such cases.
Project -
Entity Form/Display Field Label →
Issue -
Add possibility to alter field's help text (descriptions)
✨
Add possibility to alter field's help text (descriptions)
Needs review
Fixed minor issues with core required versions, maintainers names, etc.
@chetan 11, consider not to change the assignee of tasks by yourself.
paulrad → created an issue. See original summary → .
Readme file should be updated with information related to the latest resolved issues.
Hi, @rviner!
Could you close the issue if it wasn't caused by the module?
Slightly improved MR !15, made the formatter compatible with view fields, media items visible, etc.
Hi guys, I can confirm that
https://www.drupal.org/project/entity_form_field_label →
project provides requested functionality.
Screenshots attached.
I could not reproduce the issue on a current 8.x-1.x-dev branch.
The issue could be closed if confirmed by a maintainer.
I could not reproduce the issue on a current 8.x-1.x-dev branch.
The issue could be closed if confirmed by a maintainer.
Related to another issue that needs a review. Could be closed as duplicate.
Can confirm that the issue still exists. Assigning task to myself.
It's been months without TS replies so I'm closing the issue.
The issue is caused by the fact that sachinchoolur/lightGallery
library is not being considered as a package.
To resolve it - you need to install the library first and then proceed to the module installation.
Patch with updates on the installation process in the README.md applied.
Here's the console results after proposed resolution:
$ composer require 'drupal/lightgallery:^1.4' ./composer.json has been updated Running composer update drupal/lightgallery Gathering patches for root package. Loading composer repositories with package information Updating dependencies Lock file operations: 1 install, 0 updates, 0 removals - Locking drupal/lightgallery (1.4.0) Writing lock file Installing dependencies from lock file (including require-dev) Package operations: 1 install, 0 updates, 0 removals Gathering patches for root package. Gathering patches for dependencies. This might take a minute. - Installing drupal/lightgallery (1.4.0): Extracting archive Generating autoload files 90 packages you are using are looking for funding. Use the `composer fund` command to find out more! phpstan/extension-installer: Extensions installed
Thanks for your contribution, @thakurnishant_06!
paulrad → created an issue.
Thanks for testing, @Sandeep_k!
Reviewed and merged.
Thanks for your contribution, bohart!
paulrad → created an issue.
I can confirm that the issue was resolved in the 3.0.x branch after the creation of the pm_thread_history
table and refactoring of the getLastAccessTimestamp
method and no longer exists.
Resolved merge conflicts and re-tested the issue. Confirming that it works as planned.
Asking for maintainers to review and merge the issue.
Thanks for your work, @Sandeep_k!
I've retested it locally and can confirm that it still works as designed for me (screenshots added).
I guess the issue with it was caused by the fact that you've added the patch and hook_update_N didn't work out this way.
Also issues with other parts of functionality isn't reproducible on my side.
If anyone of the contributors could retest it with the current dev version and update the patch, I'll be glad to merge it.
Hey, @jukka792, I've tried to reproduce your issue by:
- creating a view page with a contextual filter;
- creating a block with a different contextual filter in the same view;
- adding this block as the view block area in a header.
Ultimately, I've got both a view and a block working as designed.
Feel free to reopen the issue and introduce steps to reproduce it, if it still appears.
Can any maintainer review this issue?
Can any maintainer review this issue?
Can any maintainer review this issue?
Hello, @saschaeggi! The issue still waits for review.
Can any maintainer review this issue?