The major issue was resolved in 8.5.x development cycle. See #565220: Fix Weight form element behavior → . Since then, the weight functionality has become more stable and predictable.
voleger → changed the visibility of the branch 3035343-tabledrag to hidden.
Opened MR !13189, which is a rebase of `2898635-10.1.x-views-data-bundle-field-definitions` branch against `11. x` branch, and added a deprecation message for the newly introduced constructor argument.
Rebased MR !8216 against the latest `11.x` branch.
rebased `9.2.0` against latest `11.x` branch and pushed to `2903336-allow_tokens_for_url` fork branch. I suggest closing MR !1076 and hiding the `9.2.0` fork branch to avoid confusion.
Attaching the patch from the new MR
Merged, thanks
Makes sense. Let's remove legacy hook implementation for 4.0.x in followup issue,
Uploading patch for the module from MR
Because it is unsafe to use it as it has been unsupported since November 1, 2023.
But in case of some reason you still need to use this project on a Drupal 9 setup, there is a way to use it by combining a patch to the info file and the use of drupal-lenient composer plugin
https://www.drupal.org/docs/develop/using-composer/using-the-drupal-leni... →
Looks good. +1 for RTBC
Works like a charm, the modules enabled in the disabled config splits are no longer suggested for removal.
The only thing that I notice is that the upgrade status does not indicate that one of the config split configurations has items defined in the module list that are removed from contrib/custom directory. This feature has to reduce the situations of accidental dependency removal.
+1 for RTBC
Are you sure the meta key name has to be `total_count`?
According to the JSONAPI example https://jsonapi.org/examples/#pagination there is a reference to `totalPages`.
Do not follow the visitor to the PHP Annotation page edit page
This
https://www.drupal.org/project/queue_ui/issues/3540113
📌
Remove doctrine annotations for plugin type definitions
Postponed
is a task for 4.0.x.
Let's introduce a attributes in 3.2.x
Let's do this
This change will increase the minimum requirement to at least `drupal/core:^11.2.0`.
That's why we can't add this in the next patch version of 3.2.x.
We need to introduce an access level to view and operate each queue first. See
✨
Only show queues in the overview if the user has permission to process that queue
Active
Then we can combine new access levels with the visibility of the Queue UI block derivatives.
This feature is more related to a different module which do such sorting at the QueueManager level. Let's add it as an API for Queue Order, and then implement support in the UI module.
Anyone who needs that feature working now for 3.2.2, you can use this stable patch link
https://git.drupalcode.org/project/queue_ui/-/commit/45bde3430d9139ad600...
Fixed thanks
I'd move this fix/change to the next major version.
The change makes sense. Thanks for the fix.
Looks good for me. Thanks @alex_optim
Fixed, thanks.
I'll publish the release later this week.
Link related issue https://www.drupal.org/project/drupal/issues/3043725 ✨ Provide a Entity Handler for user cancelation Needs work
The same error appears when generating a proxy class for a class with union types used in definitions.
php core/scripts/generate-proxy-class.php '\Drupal\Core\Batch\BatchProcessor' "core/lib/Drupal/Core"
.
Affected me working on
📌
Create an interface and initial class for the batch processor service
Needs work
Postpone until the release of Drupal 11.2.0
If titles are still an issue, please create a followup
I'm going forward, as changes look good for me.
I was able to reproduce the issue in the unit test, so I introduced a change that will address the missing type checking.
See test only pipeline run https://git.drupalcode.org/project/filefield_paths/-/pipelines/511138
See pipeline https://git.drupalcode.org/project/filefield_paths/-/pipelines/511139
Fixed, thanks
Thanks for the feedback and for providing more details on the error logs.
The patch #9 is incorrect, the check will bypass context items in that case for every case.
voleger → made their first commit to this issue’s fork.
📌 Create enums for RequirementSeverity and RequirementPhase Active is merged
There is no sense in releasing a compatible version only for unsupported versions of Drupal. You can use this workaround for this version of the module https://getcomposer.org/doc/05-repositories.md#loading-a-package-from-a-...
Works for Drupal ~10 setup.
Upload the static patch from MR
It needs work.
- Menu Item Extras has to introduce extension point there, so any other menu integration solution can integrate with the module as well.
- Group Content Menu extends the Menu Item Extras functionality
By extension, the point can be the event or hook implementation.
Merged, thanks
#86 This problem is caused by the web server's misconfiguration. It can be reproduced using the default `Docker4Drupal` docker compose setup, which mounts the latest version of the Drupal project via volumes. The #3384272-11: Allow to validate Apache/Nginx configuration requirement for aggregation folder before enabling aggregation. → comment describes the steps to imitate misconfiguration. This usually happens when upgrading the Drupal 8 or 9 projects to Drupal 10 or 11. New web server requirements are generally not taken into account during this upgrade.
So, when the project owner has correctly configured the web server and the request can reach aggregation controllers, the issue with permissions/ownership may occur.
Updated IS
Thank you @avpaderno
I'm still interested in maintaining the project.
Can I be granted an ' administer maintainers ' role once we already have +1 from one of the maintainers and 14 days have passed since a response?
I've observed an issue with the assignment of nested values.
Currently, it does not assign a value to the correct config object key.
Drush command prints the original config value, overridden, and value from an environment variable if present.
So, keys at the 0 level are assigned correctly during override. However, nested has to expand string key representation into an array-like structure.
Updates here:
- added the test for a new feature
- updated override provider
- added drush command to figure out the environment variable name and test override to the already loaded environment.
Added usage examples in the documentation to the command. I really recommend to play around with that command)
Please review MR !12
I'm closing MR !4 as it opened against the unsupported branch.
+1, thanks for your contribution
Looks good then
Yes, Menu Items Extras enhance the functionality of the content entity Menu Link Content, which is not exportable.
Bundles, form modes, and view modes are exportable as configuration entities.
If you want to export content entities, consider additionally using the Default Content project or related.
This is not typical of the standard Drupal Recommended project installation. The bundle field is always present in that table, and it contains the `menu_link_content` bundle by default.
Please revisit installed projects or patches in the `drupal/core` package. Some may use the code that removes the bundle field before installing the `menu_item_extras` module.
At least we need MR for that.
Developers must use the demo module as an example of using templates and CSS styles for some non-standard menu items. (that is not part of the issue, and improvement can be introduced in the follow-up)
I think it is better to keep it up to date or modify frontend dependencies to some more simplified configuration.
Left review comment
Hi @tsphethean
I have a plan for implementing upcoming feature requests, but as this will introduce changes in access and UI, they must be included in a new major release. Before that, I must have enough permissions to manage repository settings and update the default branch when needed.
As you have the `administer maintainers` permission for `queue_ui` project, can you grant me the `administer maintainers` permission as well?
Upload diff as a patch
Introduced logger channel as a dependency
What would be the equivalent logger channel service to `\Drupal::logger('file system')`?
Uploaded MR 5633 as a patch
I'm still interested in maintaining the project.
Rerolled MR
`temporary://` filesystem is OK to use except when the form widget supports file preview and expectations require it.
So, we now have a global 'temp_location' configuration, which is used by default by the rest of the field widget configurations.
To resolve the issue, we need to allow the overriding of the default filesystem used by the file field widget. Also, we need to keep promoting the `private://` filesystem over `public://`.
I think ✨ Override temp_location in field configuration Needs review resolves this issue.
Please collaborate with the rest of the contributors in the initially posted issue
🐛
File upload preview broken
Needs work
Thanks
Thanks for verification
Addressed review comments and updated CR
Removal of bundle usage will break a lot of the existing system. Before the removal, we need to focus on the migration process:
- The site owner must review the view/form mode configuration, as the menu item type might share the same name but differ in bundle configuration. All view/form modes should be defined in the menu_link_content bundle; thus, when the bundle definition is removed, the view/form mode will remain under the default configuration.
- After completing the item above, the current menu items must adjust the view mode field to reflect each menu block's expected view mode.
OTOH, removing the menu_link_content bundle in the core will not affect the projects using MenuItemsExtras as the project alters the menu_link_content entity definition. However, continuing to support the bundles may break compatibility with other contributed projects, which assume that menu_link_content is always single-bundled.
We need to think about the scope before switching to the single bundle, as well as to keep support bundles in the menu_link_content entity.
Rerolled in MR. Please leave review comments in MR.
Thanks
Great, the test looks good to me. Please review PHPCS report and address the reported issues. Thanks.
Uploading the MR 118 diff as a patch for composer patching needs
8.x-3.x has reached EOL, moving the request to the 4.x development branch.
Drupal 7 reached EOL
I'm still interested in maintaining the project.
Is there a way to define the folder unrelated to the core or vendor directory as ignored for the check and update process?
We can check compatibilities via CI checks. There is no reason to keep this issue open.