🇨🇦Canada @jigarius

Fixed. Thanks a lot for the report.

Please refer to the library installation section of the README and confirm whether the libraries are being installed correctly.

The release notes have been updated. Thank you.

The idea in #34 seems interesting and the description could in fact be put under the "metadata" key. However, the "metadata" property doesn't seem to have a clear description or definition of purpose. It would be good to know what that property is expected to be used for before making a decision.

That said, if we look at the block module, the BlockContent entity has a property named "info" which is used for a similar purpose, i.e. to add administrative description. If we want to continue using that pattern, we could add a property named "info. IMHO, the name "info" seems very generic so I'd suggest using something like "admin_description" or even "context" (as we have in string translations).

Answers/opinions/suggestions are welcome (=

jigarius → created an issue.

I am facing a similar problem of "No update information available." Upon investigating, I found that:

1. There's a custom module on Bitbucket that's installed using Composer.
2. \Drupal\update\UpdateFetcher::fetchProjectData() tries to fetch update info for this project from Drupal.org but it gets "No update information available."
3. I'm not sure about this part, but just because update info cannot be fetched for that one project, the entire "Available updates" table is not rendered.
4. Additionally, no clear error message is displayed, for example, "Could not fetch update data for @count projects". An entry is created in the logs.

Do you think it would make sense to show available update info even though update info could not be fetched for certain projects?

I agree with hudri. We should remove the drush/drush dependency.

jigarius → created an issue.

jigarius → created an issue.

+1 for this. Some code for supporting --sync is already present.

I just tested it to be working fine. No jumps. I wonder when the next release will be.

jigarius → created an issue.

I was about to create a similar issue but I found this one. I have ~48,000 files and the Drush command never manages to reach till the end. Hopefully, the solution to this issue will solve my problem.

To avoid having a huge number of items inserted into a batch, it might be more efficient to store a highwater mark. For example:

* Batch starts with "position = 0"
* Load, say, 50 file entities where fid > 0.
* Process the files and after processing each file, set the position to "fid" for that file.
* Keep repeating 1 and 2 until step 2 returns an empty result, which means all files are processed.

This approach should be able to tackle any number of records without spending additional resources to create an initial "list of tasks".

PS: I haven't had the opportunity to see the open pull request yet.

Ah! I just realized that the README.md was hiding in the docs directory and that it talks about how to install the library using composer (npm-asset). I'll close this one in that case.

jigarius → created an issue.

Sounds good. One of my concerns is the use of the Sidr JS library which has declared that no new features will be added. I'd lean towards using a library that will stay up-to-date with modern trends, especially accessibility stuff.

You're right about the flexibility of the Sidr module – I had made it to allow putting blocks in an off-canvas menu.

After some quick research, I think it might be a good idea to experiment with Drupal's off-canvas dialog and see if that could be used as a replacement. Some effort will indeed be needed for styling the dialogs, but the JS libraries ship with Drupal's core and they probably AA-level accessibility rules.

I still need to figure out how one can display an existing DOM element in an off-canvas dialog, i.e. no AJAX. Once I have that answer, I'll try and use the new prototype on my website and share my findings on this issue. I'll also try out the Responsive Menus module to see how it works.

Today, I worked on this module for around 6 hours after a long time. Thinking about the state of things, I've updated the issue description. Anybody willing to help with some research is welcome to share their ideas and thoughts.

Thanks for the suggestion but I believe this module will go away sometime soon. Please follow this issue to stay up-to-date 💬 Deprecate the Sidr module in favor of another project Needs work .

I believe this might happen if you don't enable the "Disable duplicates" option. Without disabling duplicates, Sidr creates a clone of the original elements and puts them in the Sidr panel. These clones don't have any events attached to them. If you want the events to be attached, you will have to do something like this:

1. Create a hidden DIV or region (say, left-panel) that contains the markup/blocks that you want in your Sidr
2. Set up a Sidr trigger block that takes content from the above region, say, .region-left-panel
3. Finally, in the advanced settings, check the box that says "Disable duplicates".

This should preserve the event listeners attached to the original element. Since this issue is very old, I'm closing it as outdated. If you're still facing it, feel free to reopen it.

I tested it to be working today. You must've missed a step somewhere. Basically,

1. Install and configure the Composer Merge plugin
2. Run composer update --lock or composer require drupal/sidr -W

I am attaching a working composer.json file so that you can compare it with yours. If you're still face the problem, feel free to reopen this issue.

{
    "name": "jigarius/drupal-sidr",
    "description": "A Drupal site to develop and test the Sidr module.",
    "type": "project",
    "license": "GPL-2.0-or-later",
    "homepage": "https://www.drupal.org/project/drupal",
    "support": {
        "docs": "https://www.drupal.org/docs/user_guide/en/index.html",
        "chat": "https://www.drupal.org/node/314178"
    },
    "repositories": [
        {
            "type": "composer",
            "url": "https://packages.drupal.org/8"
        }
    ],
    "require": {
        "composer/installers": "^1.9",
        "drupal/core-composer-scaffold": "*",
        "drupal/core-recommended": "^10",
        "drupal/core-vendor-hardening": "*",
        "drupal/sidr": "5.x-dev",
        "drupal/upgrade_status": "^4.3",
        "drush/drush": "^11.6",
        "wikimedia/composer-merge-plugin": "master-dev"
    },
    "conflict": {
        "drupal/drupal": "*"
    },
    "minimum-stability": "stable",
    "prefer-stable": true,
    "config": {
        "sort-packages": true,
        "allow-plugins": {
            "composer/installers": true,
            "drupal/core-composer-scaffold": true,
            "drupal/core-vendor-hardening": true,
            "wikimedia/composer-merge-plugin": true
        }
    },
    "extra": {
        "drupal-scaffold": {
            "locations": {
                "project-root": "./",
                "web-root": "web/"
            },
            "allowed-packages": [
                "drupal/core"
            ]
        },
        "installer-paths": {
            "web/core": [
                "type:drupal-core"
            ],
            "web/libraries/{$name}": [
                "type:drupal-library"
            ],
            "web/modules/contrib/{$name}": [
                "type:drupal-module"
            ],
            "web/profiles/contrib/{$name}": [
                "type:drupal-profile"
            ],
            "web/themes/contrib/{$name}": [
                "type:drupal-theme"
            ],
            "drush/Commands/contrib/{$name}": [
                "type:drupal-drush"
            ],
            "web/modules/custom/{$name}": [
                "type:drupal-custom-module"
            ],
            "web/profiles/custom/{$name}": [
                "type:drupal-custom-profile"
            ],
            "web/themes/custom/{$name}": [
                "type:drupal-custom-theme"
            ]
        },
        "merge-plugin": {
            "include": [
                "web/modules/contrib/sidr/composer.libraries.json"
            ]
        }
    }
}

Thanks for reporting this issue. It turns out that while replacing jQuery once with Drupal core's once had resulted in several bugs including this one. This issue should not be there in the latest 5.x branch.

Thanks for reporting this issue. When the Sidr opens, it tries to set focus on the first input or anchor element inside the Sidr panel to help with keyboard navigation and the contextual links were stealing this focus so they were hidden away.

To resolve this issue in a nicer way, focus is now granted to the first non-contextual-link in the Sidr panel. The change will be released in the next 5.x version.

Thanks for reporting this issue. I noticed that there were some anomalies in the JS related to the once() usage. I have fixed those. Additionally, I've made it such that when a Sidr closes, if the focus is still inside the Sidr panel, then the focus is sent back to the last used Sidr trigger.

As for the aria-hidden, I realized that when the Sidr panel is closed, it shouldn't be visible on the browser nor for assistive technologies. Hence, I've used hidden="hidden" to hide them away for good. For reference, here's a difference between hidden and aria-hidden.

As for the other suggestion, however, I believe it is time for this module to be replaced with some other module. I am looking for a project that would replace this Sidr module 💬 Deprecate the Sidr module in favor of another project Needs work .

Thanks for reporting the issue and for submitting a patch. The change will be present in the next 5.x release.

The patch #6 fixed the error from me. The approach seems correct as well, i.e. select the fields that you're grouping by.

Findings

I am facing a similar problem but I believe the problem might be bigger so I'll just share my thoughts.

1. Set up profile type A for role 1
2. Set up profile type B for role 2
3. Create a user account with role 1
4. See the users profiles from the "profiles" page
5. Observe: There is a profile A which is set as default
6. Observe: There is a profile B which is set as default

Thoughts

1. It seems like all types of profiles are created for all users. If I have 100 users and 4 profile types, I get 400 profiles.
2. If I create a view to display user info along with their default profile, I get multiple records per user!
3. Even if the user doesn't have role 2, they still have profile B.

Would this classify as data corruption or a data-layer-level anomaly? If yes, then I believe this issue should be treated as a major bug.

An interesting conversation. I wish google_tag had a simple mode and the advanced parts were optional. That way, it would've been possible to not have this module.

The Composer-based library inclusion mechanism was included in Sidr inspired by the Webform module. I see that they don't force users to rely on wikimedia/composer-merge-plugin, so I think I'll not include it in Sidr's composer.json for now.

That said, are you able to install the Sidr libraries correctly if you require wikimedia/composer-merge-plugin into your composer.json file? If not, can you please share the entire composer.json file so that I can take a look? Please refer to this video guide if need be.

If you can't share the file publicly, please contact me using jigarius.com/contact and we'll communicate over Email.

After reviewing this issue, I have added kuhikar as a maintainer. I hope this helps.

Also, gaurav_manerkar Thanks for the release. Is it still okay for you to be a maintainer? Or would you like me to remove you? Just confirming.

Hi. I wonder why I didn't get notifications about all these issues. I will add a new maintainer after reviewing the candidate's profile, however, I'll only be able to do that in a few weeks because I'm in a place where I don't have my laptop and my connectivity is also limited.

I tried the patch, but it doesn't seem to have any effect. I think the problem is deeper than that. Additionally, even for a regular datetime field, the module doesn't seem to work.

Hi! Was the deletion "safe" for you? If yes, it'd be great if you could confirm.

Hey! I'm sorry for the late reply. I've been very sick and busy. I'll get back to you as soon as possible.

I've added a basic command that seems to be working correctly.

jigarius → created an issue.

jigarius → created an issue.

jigarius → created an issue.

Thanks for all the feedback. A different interface for a simple entity reference that just contains a target_id makes sense. However, I'll think aloud to get some more opinions.

• All field types have can have multiple columns to store the "value", which is returned by "::getValue()".
• So, if we want to check if a multi-value text field contains the value "foo", we'll have to do the same "array_column($entity->field->getValue())" exercise; which is perfectly fine, but looks kind of bulky (which is what motivated me to create this issue).
• What do you opine about having a generic way of getting a particular column or columns from a field's "value"?
• Say, something like ::getValue(array $columns = []);? If $columns is empty, then "::getValue()" behaves like it does right now; if it contains exactly one value, it returns just that column; if it contains multiple values, it returns an array of arrays containing just the specified columns?
• Maybe it can be a separate method instead of "::getValue()", say "::getColumn()".

Again, I'm just thinking aloud to see how you feel about providing a cleaner, easier-to-read way of getting an array of values in a field. A majority of simple fields have just one "value" column that contains the main value, so usually, devs would do something like, $entity->field->getColumn("value") to get something like, [0 => "foo", 1 => "bar"], etc.

If this doesn't sound appealing and if the general opinion is that the dev should repeat "array_column()" for such cases, I will mark the issue as closed.

I've addressed both the comments, so I'm marking this as "Needs review" again.

I've updated the tests to use TermInterface::ID_ROOT. Additionally, I found some more instances of "0", which I've replaced.

I didn't change it in any tests though. Maybe we should continue to verify a hard-corded '0' in the tests. Opinions? Suggestions?

Working on it.

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

Ah! I always forget something before hitting save.

Aside: This will be my first significant contribution to the Drupal Core (= A good way to mark 10 years of working with Drupal.

Thanks for the review. I've updated the CR as per your feedback.

I've created an MR for it. Kindly let me know if it works.

jigarius → created an issue.

Oops. Added a change record (unpublished).

Sure thing. I've created a change record.

On a similar note, if this issues ✨ Create method EntityReferenceFieldItemList::referencedIds() Needs review gets updated soon, then I can use ::referencedIds() in this method.

All set. I've updated the code and the test.

Indeed smustgrave. I'll take care of it later today. I think I'll go with the following names that seem more self-explanatory:

1. ::hasRootParent(): bool
2. ::hasNonRootParent(): bool

Created an MR. Here's how ::referencedIds() works.

1. Returns Target IDs, respecting deltas
2. Invalid IDs are returned; there is no way to validate them, but that's normal.
3. NULL items are not returned.

Please let me know if you want me to change anything.

jigarius → created an issue.

Hi poker10 you're right. When I created the issue, I was under the impression that parent contains the IDs of all the ancenstors. I had never noticed that a taxonomy term can have multiple parents and also be a top-level term at the same time. Thanks.

I've updated the code and the tests to include the case that you specified. However, I have two thoughts:

1. Technically, root (0) is also a parent, so the method name ::hasParent() doesn't seem adequate any more. I'm thinking about making it "isTopLevel()". Any opinions?
2. In the long-term, maybe Drupal Core should consider renaming the field "parent" to be "parents" because it can contain multiple values.

I'll wait for an opinion on ::isTopLevel(). Apart from that, it seems to be working.

All set! I've added the method and added some tests as well.

I'll do some groundwork.

jigarius → created an issue.

I confirm that the problem exists and that the patch submitted by Sam seems to solve it. I will apply the patch to both 1.x and 2.x after some more testing.

I just tested this to be working correctly.

Thanks Seb, for the pull request. It's merged and 2 new releases have been created: a dev and a stable.

As a temporary solution, I have done the following:

* Set up a new group role: "member"
* In a hook_group_relationship_presave(), I assign this member role to all membership records.

The only drawback of this approach so far is that the role "Member" is visible in the UI even though I want it to be hidden, which means I'll have to write some more code to ensure that only the roles that are not this generic "member" role should be visible in the UI.

jigarius → created an issue.

jigarius → created an issue.

I took a look at the patch 47 and created a PR with some changes. In the end, I got the user creation to work, but for some reason, the newly generated user's ID doesn't get attached to the parent entity's form correctly, i.e. the inline_entity_form elements are not replaced by a nice target_id so the parent form fails to submit.

In patch 47, the "account" element for the user data don't get copied into the User entity because the AccountForm expects a different structure of values in the FormState. I'm starting to think that it might be better to create a simplified version of the user account form for use with the InlineEntityForm instead of involving AccountForm at all.

As for my project, I'll be simplifying this by injecting just: name, mail, pass, status, and the Field API fields, if any. At least it will get the ball rolling for me.

While trying the patch in #47, I get the following issues:
* UserInlineForm should use EntityInterface $entity instead of ContentEntityInterface to be compatible with the parent class.
* The inline form works in the "default" form mode but it doesn't work with custom form modes that I've created, say "membership". I get the following error:

Drupal\Component\Plugin\Exception\InvalidPluginDefinitionException: The "user" entity type did not specify a "membership" form class. in Drupal\Core\Entity\EntityTypeManager->getFormObject() (line 207 of core/lib/Drupal/Core/Entity/EntityTypeManager.php).

jigarius → created an issue.

Please feel free to make me an owner/maintainer in that case.

Dear maintainers.

Do you plan to release a Drupal 10 compatible version soon? Also, since the module page says "minimally maintained" and "maintenance fixes only", do you recommend that we use this module in our project or would you recommend starting our own fork or maybe write our own library to connect with Eudonet?

jigarius → created an issue.

jigarius → created an issue.

Thanks for the info. I'm closing this as a duplicate.

After leaving comment #117, I ran into a new issue. There seems to be a permission anomaly for certain operations. I am marking this as needs work.

For example: With the changes proposed in the merge request at this point, I stop seeing the "Masquerade" operation for user entities even though I'm logged in as User 1. As soon as a I remove the patch, I start seeing it again. Additionally, I implemented a hook_entity_operation() in a custom module and the patch makes that custom operation disappear as well. Removing the patch brings it back.

Just tested it to be working fine with Drupal 10.0.9.

jigarius → created an issue.

jigarius → created an issue.

jigarius → created an issue.

jigarius → created an issue.

jigarius → created an issue.

While testing this behavior, I realized that it makes many, many write queries on the key_value table. This in turn results in huge MySQL bin logs which makes the server run out of memory at some point. Is anyone else facing this issue? Is it safe to say that there is an efficiency/memory optimization issue with the --sync option?

I don't know if this is related, but I'm having a strange problem with --sync:

• If I run drush mim --all --sync, certain records that are supposed to be deleted by --sync remain.
• If I run the migration individually with drush mim MIGRATION-ID --sync, those records are deleted as expected.

Since the other file organization issue is closed and it seems related to 7.x I'll post a mini-suggestion here.

Currently, Drupal stores files to public://YYYY-MM directories by default.
I'd like to suggest storing them to public://YYYY/MM directories by default.

I wish the files were uploaded by default to a directory like "YYYY/MM" instead of "YYYY-MM". I'll see if I can find an open issue for that.

Here's a PR that resolves the warning message. There seems to be a new concept of "destinations[]" now and I've not handled this for now.

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

jigarius → created an issue.