🇺🇦Ukraine @voleger

voleger → made their first commit to this issue’s fork.

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?

voleger → created an issue.

We can check compatibilities via CI checks. There is no reason to keep this issue open.

Fixed, thanks

voleger → made their first commit to this issue’s fork.

Still interested

Drupal 7 reached EOL

Drupal 7 reached EOL

Drupal 7 reached EOL

Drupal 7 reached EOL

Drupal 7 reached EOL

Drupal 7 reached EOL

Drupal 7 reached EOL

Drupal 7 reached EOL

Drupal 7 reached EOL

Drupal 7 reached EOL

Drupal 7 reached EOL

Drupal 7 reached EOL

Drupal 7 reached EOL

Drupal 7 reached EOL

Yes, 📌 Convert theme engines into services Needs work makes sense.
I'm closing the duplicated issue

It needs work for test coverage based on the steps to reproduce.

Settings.php overrides are unsuitable for the modules that try to control the backend of the queue worker.
I like the idea of keeping the current approach to override the backend service.

What if, instead of extending attribute/annotation, we introduce an extension point by dispatching an event right after determining the service name?

Oh, thanks.
I'm postponing that on 📌 [Plan] Determine how to deprecate procedural hooks. Active

How do we deprecate the procedural hook with the OOP hook? Is there any approach declared? And what needs to be done with `\Drupal::` calls? How do you set dependency injection for OOP hook implementation?

Is there any additional information about proper dependency injection practice for OOP hook implementation?

voleger → created an issue.

Tests are not passed.

We need to improve the token integration test with cases of uploaded files without extension.

Good, we need a test case that creates an entity with a pre-uploaded file.

I reached a recently active maintainer, @bceyssens, via LinkedIn, but he could not make the change or set me as the project's maintainer.

voleger → created an issue.

It looks like that was addressed in the latest release in the scope of Drush command refactoring https://git.drupalcode.org/project/filefield_paths/-/blob/8.x-1.0-beta8/...

If the issue still exist - let me know

Thanks

Wondering if the module can do all of that during the uninstallation:
- set the default value of the base field definition or initial value to `NULL` or `` (or move this to the hook field info alter and implement one more hook update for this)
- set base field field definition as not required
- do base field definition update

Then, let the system purge the field.

What do you think?

Closed [33293876] as duplicate of this issue.

Please follow the existing issue #2685731: How to uninstall this module ? → . Anyway, the changes from the patch need to be moved to the MR. Thanks.

It has to be fixed in #2858308: File paths are written to the DB with back slashes on Windows servers → . If the problem still exists, open a new issue.

Please open a new issue with more details and steps to reproduce if the problem still exists.

Needs MR

Testing for a new token is necessary to ensure it works as expected.

Needs MR

Needs MR

Needs MR

Needs MR

Needs MR

Tabs are present on a recent releases.

Needs MR for proposed changes.

Thanks. Changes look good, but two PHPCS issues must be addressed before merging.

Fixed

The pipeline passed, and there are reported issues that can be addressed in follow-ups.

voleger → created an issue.

Looks good, thanks

voleger → made their first commit to this issue’s fork.

Nice feature. Please prepare a MR and add test coverage.