🇺🇸United States @loze

I have a D10 version of commerce_affiliate and affiliate_ng 95% working that I want to contribute.

Can the maintainers create a 2.x branch of each product so I can provide a MR for others to test out?

Or whats the best way for me to add it?

I spent a little time and have most of this working locally. Should I add a MR or create a new module?

I don't know if I can commit to maintaining it long term but I'm happy to help get it up and running.

loze → changed the visibility of the branch 2919646-is-there-a to hidden.

I also need this for a project I'm currently working on.

Has anyone started any work on a D10 version? I can help code and test?

Sorry, this was my mistake. disregard.

loze → created an issue.

MR!2 adds a batch process to hook_install() and allows me to install the module.

Here is a patch of the MR for composer.

loze → created an issue.

loze → created an issue.

loze → created an issue.

@claudiu.cristea I dont believe that getDisplayName() is a queryable field, right?

I'm trying to get the auto complete search to use the compiled display name that is stored in the realname table.

That is a patch of the MR

Thanks for the test @agile-mark-l this looks good.

I added a template for the loading animation quicktabs-loading.html.twig so you can override this in your theme, per qt instance if needed.

$markup = [
              '#theme' => 'quicktabs_loading',
              '#message' => t('Loading content ...'),
              '#instance' => $qt_instance,
              '#tabid' => $tab_id,
            ];

Attached is a patch from !MR21 for composer.

Resolved the conflicts in MR36

heres a patch for composer

loze → changed the visibility of the branch 2.1.x to hidden.

MR!122 Adds this functionality. Here is a patch for composer.

loze → created an issue.

I believe this was fixed here 🐛 Revert the ESLint autommatted conversion to arrow functions - it broke multiple things Fixed

This is fixed in the latest version

yes, 💬 Loading previous messages and listing last messages doesn't work RTBC does fix this

To clarify, I'm trying to do two things here:

1. display the users picture/avatar next to their name in the autocomplete dropdown
2. alter the autocomplete query to further limit who someone is allowed to send a message to (for example only someone in a friends list)

I figure the best way to do this is to use a custom view to supply the results of the autocomplete dropdown, but not sure the best way to go about doing this.

any suggestions?

Last patch in #22 was wrong, some unintended changes made it in there.
this one should work with composer

Its been some time since the original issue and patches.

Since then this module now uses the users display name instead of the username, which resolves 1/2 of what was being addressed in the original patches.

I have created MR!121 which adds realname support to the autocomplete query for the members widget if realname is installed.

here is a patch for the MR to use with composer.

loze → changed the visibility of the branch 2987189-realname-support to active.

loze → changed the visibility of the branch 2987189-realname-support to hidden.

loze → created an issue.

here is a patch for composer

Patch #35 does not work as pointed out in #38

Patch #32 does work which is a diff for MR40. Please test against those.

MR7 gets this working for me.

this latest change gives me this error

Error: Call to a member function moduleExists() on null in Drupal\soembed\Plugin\Filter\SoEmbedFilter->getEnabledProviders()

I created MR!9 which is the patch from #64 plus I tried to address the errors in #66.

It appears to work as expected now in my initial testing.

Here's a patch of the MR to use with composer.

Here is a MR for 2.0.x

@TR Mentioned that this needs a test to demonstrate the error and prove the fix. I unfortunately, don't know how to go about doing that.

But you can see my comment #11 for a description of two scenarios where it is failing for me.

These changes do resolve the issue for me and I have been using in production for some time now.

Yes I have been using this patch on 2.0.x-dev for some time, and it works well.

patch in #9 gets this working for me in d10.3

+1 for this

Patch #3 applies and fixes the issue. +1

I created a MR with the latest patch

This still doesn't address using wildcards in paths, see #5

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

MR!13 gets this working for me.

I'm checking the entity not the form object for an instance of RevisionableEntityBundleInterface.

Im getting the same error with commerce product entity bundles. The path gets rid of the error but it also removes the OG fields from valid entity types, like nodes.

Thanks for the hint @jessica.k that is indeed what was happening. Apparently with php 8.0+ round fails if the variable is a string.

I've created a MR which casts the with and height variables as integers.

There may be other places in this module that we need to do this for, but for now this solves my original issue.

Here's a patch to use with composer.

loze → created an issue.

MR12 adds views relationships to og_memberships from any group enabled entity types.

This allows you to create a view of all groups a user is a member of or show the membership counts for a list of groups.

loze → created an issue.

On second look, this does work with gallery blocks, since they are just a group of image blocks, the size is set on each individual image

Although there should probably be an option to set the size of all images in a gallery at once. there is an issue for that here 🐛 Images are not linked with core/gallery block Active

I'm not a maintainer of this module, so lets see what someone else says.

In the meantime, I've resolved the conflicts in MR!150. Here is a patch to use it in composer.

@szeidler
1. you're right about splitting the 2nd part of my issue into a separate issue.
2. I think your approach of loading the image by uuid is correct, as well as supporting image/gallery blocks.
3. this module has a Drupal\gutenberg\Html\TagProcessor class that can handle what your doing with \DOMXpath and we should probably use that since the other block processors use it.

Im going to try to combine the best of the two.

@pearls Try this patch with composer.

Im using 10.3.0 and trying to show the start date only in views, but both dates are shown even though I have "Display start date only" selected in the field formatter. Am I missing something?

MR!5 is a simple fix does option 1 I propsed above.

It excludes the context from any form other than the context UI.

You will still need to go in and edit any configs manually that were effected by this bug (like google_tag) and remove the unwanted contexts. You will then be able to use the UI to edit the config moving forward.

I was hit by this too with google_tag.

In this module context_entity_field_plugin_filter_condition_alter unsets the definitions for context_entity_field contexts when they are being displayed the block_ui and layout builder. However other modules using conditions have them displayed.
There is a comment // Keep within the Context UI only. but obviously this is not sufficient.

I see two possible solutions.

1. Improve the check for keeping these conditions in the context UI only (which appears to be the intent of this module)
or if we want to use these context plugins outside of the context module.
2. possibly provide an "enabled" checkbox for each field context that would prevent the plugins config from being saved if its unchecked.

The patch fixes the issue for me. +1

loze → created an issue.

Sorry, I just realized there is an option to "Upload as soon as files are added." in the widget settings.

loze → created an issue.

It also appears that with change_pwd_page, #2933747: Integration with password_policy → added some changes that rely on the patch here in #12.

If the approach I propose here is accepted, that commit could be reverted and all that change_pwd_page would need to do is implement the hook as follows

/**
 * Implements hook_password_policy_routes_alter()
 */
function change_pwd_page_password_policy_routes_alter(string &$change_password_route, array &$ignored_routes) {
  $change_password_route = 'change_pwd_page.change_password_form';
}

Instead of introducing all those update hooks that their solution added. It seems like a much simpler approach to me.

MR!91 adds an alter hook. hook_password_policy_routes_alter(string &$change_password_route, array &$ignored_routes); This allows contrib modules to change these two variables.

in my use case I am using it like this

/**
 * Implements hook_password_policy_routes_alter()
 */
function MYMODULE_password_policy_routes_alter(string &$change_password_route, array &$ignored_routes) {
  // Our custom change password form.
  $change_password_route = 'entity.user.edit_form.change_password';

  // Ignore commerce checkout routes.
  $ignored_routes = array_merge($ignored_routes, [
    'commerce_checkout.form',
    'commerce_checkout.checkout',
  ]);
}

loze → changed the visibility of the branch 4.0.x to hidden.

I have a custom module that creates its own page/form for changing the password similar to change_pwd_page, the entity.user.edit_form is still a valid path for editing other user fields. There is no way for me to know the intent of why a user ends up on entity.user.edit_form without checking for an expired password when on the entity.user.edit_form route a second time and then issuing a second redirect to my change password form.

It feels like it would be a a lot easier if both the redirect route and the routes excluded from redirection were either configurable settings or alterable in a hook or event subscriber.

If they were alterable, we wouldn't need to change the schema and any module could define its own redirect route an exclusion routes for not checking for expired passwords.

I dont think a dependency would work. Gin could be installed, but some roles may not be able to access the admin theme.

Thank you for taking a look at this @idebr.

I agree with all your points and will work more on this.

I was experiencing similar issues. this MR does resolve the private-message/undefined path issue, but the inbox_block.js is still preventing some clicks on the page.

I have a MR here 🐛 Javascript errors with inbox block prevents any link on page from being clicked Needs review that addresses what i am describing. Posting it here since I believe they are related.

loze → created an issue.

Tested the MR and it resolves the issue for me. +1

loze → changed the visibility of the branch revert-1866e93c to hidden.

loze → changed the visibility of the branch 3464363-remove-version-from to hidden.

loze → created an issue.

I've also tested this and it appears to work as expected. +1

Apparently due to 📌 Allow for deletion of a single value of a multiple value field Fixed adding a remove button to multi value reference fields, this module's js was triggering the 'remove' button instead of the 'add more' button of the hidden member reference field, resulting in js errors when attempting to add members to a thread.

My MR attempts to clear this up.

The MR here gets it working for me 🐛 Save button missing when using the Gutenberg/Mercury editor module Fixed

I think I was able to resolve this. What I ended up doing is

1. Added a column to the content block usage table for the parent gutenberg node bundle
2. Altered the gutenberg.content_block_type.settings to pass along the parent entities id, type, and bundle so these can be saved to the usage table as soon as the block is created
3. Created an eventSubscriber for BlockContentEvents::BLOCK_CONTENT_GET_DEPENDENCY which will check the usage and return the node the block is used in, or create an empty node if the parent node is new and doesn't have an id yet,

This appears to allow editing of media fields of content blocks using the media library now.

loze → created an issue.

The latest dev version of gin fixes the js error. however my gutenberg forms still wont load. I just get the spinning "loading" indicator

No errors are the in the js console.
It does work correctly when I switch the admin theme to something other than gin.

using the MR461 from 🐛 Save button missing when using the Gutenberg/Mercury editor module Fixed as a temporary fix gets this working for me for now.

@GuillaumeDuveau try this patch. This is MR36 and should apply to 2.1.x-dev

loze → created an issue.

I was experiencing a similar issue that only started happening after Drupal 10.3.0 where a ctools node block was not being rendered on the same page as the full node view.

This patch seems to fix that for me. Thanks!

loze → created an issue.