🇺🇸United States @loze

loze → created an issue.

And here's a patch for composer.

@idebr The tests are all passing now!

@idebr I've done a bunch more work on this and addressed your main points.

I've tested this on two separate installs, and it seems solid across various entity types and comment fields displayed simultaneously on a page, including commenting on multiple entities within a view.

One noticeable change in this version is that I've added an AjaxCommentsLazyBuilders class that extends the core comments lazy builders. I'm swapping the core ones for these when the field is AJAX-enabled. This makes it much easier to determine when we're working with an AJAX-enabled comment thread. Previously, tracking view_mode with tempStore was necessary to load the commented entity’s view mode and retrieve field settings within a comment—not just for creating field IDs. I explored a few different approaches before landing on this one, and I think it’s a much better solution.

The comment paging functionality is still included, primarily because I needed it for my current project. However, it could be removed and handled in a follow-up issue if necessary.

The tests are failing, but I'm not sure why. I've manually tested both failing scenarios and haven't been able to reproduce the issue. I'm not very experienced with writing or debugging tests in detail, but I'm happy to make changes if someone can provide insight into where the failures are occurring.

Thank you for pointing me in the right direction @larowlan!

After looking at what was going on there I was able to write my own function that added the missing triggers and everything appears to be working. Much appreciated.

Now to just figure out how this happened in the first place.

ahh, my suspicion was correct.

SHOW TRIGGERS FROM dbname;
shows that the only triggers in this db are the one from the module i just reinstalled.

I have a few other entities throughout this site that use DER fields.

Is there a simple function I can call to recreate these missing triggers if I specify the field and entity type?

Yes I am. So i reinstated my custom module and its working as expected now.

However, on some DER fields that I created from the UI on another entity are doing the same thing now. This appears to have started after I did a config import drush cim. Could something have gone wrong there? is there anything I should look for that would indicate that?

loze → created an issue.

I would have thought the $this->contextConditionsEvaluated variable takes care of this but apparently when both these reactions are used the value is somehow getting reset? I tried figuring that out but not sure whats going on there.

Im not sure if this is the correct approach, but it does fix the problem for me.

Im keying the activeContexts array by context id which makes sure any context is only set once.

loze → created an issue.

While digging into this I had a thought.

There is a difference with an empty view because views permission/argument validation fails vs. a view with no results.
And do we want to hide the tab in both cases? There are times when you would want the content of the no results handler to display on certain views.

Perhaps there could be a setting per views tab allowing them to specify no results vs no access?

This wasn't working for me, empty views loaded with ajax were still showing, so I made some adjustments and rebased for 4.0.x

MR 24 is for 4.0.x

Here is a patch for composer

Still no test coverage.

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

loze → changed the visibility of the branch 3407343-theme-loading-markup to active.

loze → changed the visibility of the branch 3407343-theme-loading-markup to hidden.

MR 41 is against 4.0.x

Still no test coverage, that is beyond my capabilities. hopefully someone else can help out with that.

I believe what was happening was my form display settings was set to tagify in my exported yml file. Then when doing a drush cim during an import it somehow changed the hander and I was no longer able to select one. Changing it back to a standard field type then setting the handler fixed it for me, I will keep an eye on it and let you know if the problem pops back up again, but i think the issue was in my yml file.

Maybe it could dispatch an event when the source isn't found?

I have a site with over 100,000 of entities with media references, many of these have become old and I would like to be able to flag the posts so I can easily find them and remove them or take some appropriate action.

If i was able to listen for an event when there is an error I could do this.

loze → created an issue.

loze → created an issue.

This is happening for me too, clicking on the edit (pencil icon) opens the dialog and throws the js error. Any edits made in that dialog are not saved.

loze → created an issue.

I also need this. +1

The reason it is failing is from this behavior:

Drupal.behaviors.quicktabs = {
    attach(context, settings) {
      $(once('quicktabs-wrapper', 'div.quicktabs-wrapper', context)).each(
        function () {
          const el = $(this);
          Drupal.quicktabs.prepare(el);
        },
      );
    },
  };

The nested content is 'div.quicktabs-wrapper', so its not checked here in the context. We either need to wrap the content in another div container, or remove the context from the once statement so it checks everything.

My MR removes the context since that was the simplest, but not sure which approach you would rather.

loze → created an issue.

MR 37 is against 4.0.x
Still needs update hook and test coverage.

If i go tot he form display settings and change the field to the standard autocomplete widget, then go back to the field config form it works. But its broken when the display form is set to tagify.

loze → created an issue.

loze → created an issue.

Anyone have any advice?

@td I made a few updates

1. Checked for a few other scenarios where invalid rows were still being written. It should now only write results for valid entity/bundle/field combos.
2. Added an update hook that recalculates the results on all voted entities, which cleans up the results table.

I ran it on my local test site where I have thousands of votes of coming from about 10 different fields across 4 entity types and it cleaned everything up!

For the record, I'm actually in favor of doing both.

A permission is easy to set up and straightforward, but allowing admins to control if something should be able to be voted on by a specific user is a nice feature. It's not really about altering the permission (which appears to be the reasoning for the request being denied).

Let's say I wanted to prevent nodes from being voted on if its tagged with a term or has some other arbitrary field value, or is older than a specific date. Having an alter hook here would allow for this.

loze → created an issue.

Im also wondering if there is a way to not have the rows generated in the first place, eliminating the need to unset them in the alter hook. Possibly by changing the logic in getDerivativeDefinitions? I will dig into this some more.

Thanks @tr. I agree on the need for test and wish I was able to figure that out myself.

Here are the steps as I see them.

To summarize: The getResults method in VotingAPI widgets returns incorrect results in certain cases due to how it combines records based on field names without considering entity types or distinct field names within the same entity.

I have observed two specific cases where this occurs, though there may be others.

Steps to Reproduce

1. Fields with the Same Name on Different Entity Types

• Create a NODE type "page" and add a VotingAPI field named field_rating.
• Create a MEDIA type "image" and add a VotingAPI field named field_rating.
• Cast votes on both entities.
• Retrieve results for one of them. you can either look on screen, or programtically get them with the getResults() method

Expected Behavior:
Each entity type should have its own distinct vote results.

Actual Behavior:

• The results are either combined incorrectly across entity types or otherwise inaccurate.
• Both the total votes cast and the average values are incorrect.
• This occurs because getResults groups records by field name without considering the entity type.

2. Two Fields with Similar Names on the Same Entity Type

• Create a NODE type "page".
• Add a VotingAPI field named field_rating.
• Add a second VotingAPI field named field_rating2.
• Cast votes on that node in both of the fields.

Expected Behavior:
Each field should return its own separate vote results.

Actual Behavior:

• The results are incorrect due to the same underlying issue. getResults is searching for a substring of the field name so "field_rating" is also grabbing results from "field_rating2".
• Both the total votes cast and the average values are incorrect.

I really wish I could set up a test for this myself. I spent time yesterday trying to figure out how to write a proper test but got lost on just the basics like creating a node and adding a votingapi_widgets field to it, let alone going about making it cast votes. So I appreciate any help or guidance on how to approach this.

Thanks @tr. yes, this has been happening at least since 8.x-1.x.

I will try to write an update hook.

We could probably get away with not adding it. It was in the it the original patches to I added it to the MR.

I know in my case, I am using a limited version of Font Awesome from their CDN that only includes a subset of the icons that I need, stars are included in this. So I don't need this module to include them. I could always remove the library in a hook, but an option here seemed convenient.

The same could be true for glyphicons.

for the record, I have not been able to reproduce it myself.

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

I've tested this and it does the job. Thanks.

This MR checks if the result field is from the voted entity type.

I think it should also check if the field is on the bundle and unset the ones that aren't as well.

loze → created an issue.

It appears that there is no longer a preSave() method in Drupal\votingapi\Entity\Vote

@tr is this still relevant?

I've made some updates to the MR.

I was noticing some issues with incorrect vote results appearing when multiple vote fields were on the same page.

There was also some code duplication with a getResults() method in both the base form and the base widget classes so I consolidated those and and was able simplify and lean up the logic.

This seems to be working well at first pass.

To summarize what this does:

1. Splits up all the barrating styles css files into their own libraries and only loads them if they are set on the widget
2. Provides a global config page where the admin can choose to disable fontawesome or glyphicons from being included in cases when they are already including them in your theme.

It was only these 2 places, but this gets it working correctly.

loze → created an issue.

This is being addressed here 🐛 getResults is not returning the correct results Needs review

This is addressed here 🐛 getResults is not returning the correct results Needs review and there is a working MR in that issue.

Went through the 2 patches and created a MR to work from. it appears to be solving the issue in my initial testing.

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

For what it's worth, it appears to work as advertised, on my initial testing with Drupal 10.4.

Entities created via code now have radioactivity entities generated. Before the MR they did not.

Got the MR to pass. Ready for your review @tr

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

Here is a MR that achieves what I have proposed, while not effecting what the initial issue was solving.

Instead of checking for a full page load, I am deleting the emit from drupalSettings once its been used, so subsequent requests will no longer use it. I am only making an ajax request if the emits array is not empty. This allows newly added emits to drupalSettings from ajax loaded content to be triggered

thanks @tr I will check that out and try to write a patch.

I think it makes sense that if an emitter field is being displayed, then it should emit.

loze → created an issue.

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

loze → created an issue.

loze → created an issue.

Im looking for functionality similar to what this modules product page describes. Wondering if the maintainers intend to make this available for Drupal 10+?

Asking because it doesn't look like there was ever much activity in here and not sure if it was ever working as advertised and worth pursuing.

any insight is appreciated. Thanks!

Im glad you two are interested. I'll ping the maintainers again and see if I get a response.

My code is based heavily (at least conceptually) on affiliate NG but i have taken a handful of liberties to add features I needed.

I just threw it up over here https://github.com/lozeone/affiliate so if you want to try it out

There are 2 modules 'affiliate' is the main module and 'affiliate_commerce' creates conversions on commerce orders.

I tried to document the main features and setup in the readme.

I've figured out what was happening here

I was setting the username in hook_email_registration_name(UserInterface $account) to one that already existed and it was crashing.
My code was simply return 'user-' . $account->id(); but id was always empty.

in the api file the example for hook_email_registration_name(UserInterface $account)
is using $account->id(), but in the 2.x version the account does not have an ID yet (it did in the 1.x version) So the same logic i was using to generate the username in 1.x wont work.

In fact, neither hook: hook_email_registration_name() or hook_email_registration_name_alter() has the id property populated in the account yet.

Im not sure if its a bug that the ID is not there. If it isn't those docs should be updated to reflect this to let people know they cant rely on the user id here.

Fixed phpcs in MR. Thanks!

Just to bump this. I have spent some time with this over the past few months and have basically all of the functionality of the d7 version working with a few improvements for my use cases that I think make good additions.

It appears this module is abandoned, Ive reached out to a few of the maintainers listed but never heard back.

I suppose I will just create a new project so we can work from there?

One question tho, I am struggling to decide on a name for it.
My version I'm running locally is just called "affiliate" but that name is already taken (and abandoned as well) along with other similar affiliate-ish names. Do you have a suggestion of a name to call it that is not already claimed on D.O.?

I created MR23 from the patch in #2

I know this is old, but this is still missing from views.
The patch still applies and appears to work as advertised.

Adds contextual filters in views for the published_at field similar to the ones for created and updated.

+1

MR16 gets this module working with publication_date for me.

loze → created an issue.

loze → created an issue.

That was my mistake, I intended to do it against 4.0.x Thanks!

I've made some updates to the MR.

1. It checks if taxonomy_entity_index is enabled, and defaults back to using the taxonomy_index table if it is not.

2. the views fields/args now supports all content entities.

I have also updated the patch on ✨ Provide views join on BASE_TABLE_field_data Needs work which is required for this to work.

Everything appears to be working as expected on my local site and I can now use this module with products and other entities.

attached is a patch for composer

Here's a patch of the latest MR for composer

I made a small update to the MR to use $info->getDataTable() to get the table name and only include it if the entity has a data table.

I see some modules that provide views integration use something along the lines of
$table_name = $info->getDataTable() ?: $info->getBaseTable();
to get the table name for joining entities. Im not sure if thats appropriate here or if doing so would break existing views.

So I'm just adding this join to the data table which make it work with the parent issue.

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

Thanks, this got it working for me with commerce_product entities, and think this is on the right track.

This also needs to do the following.

1. Check if the taxonomy_entity_index module exists first and only perform these changes if it does.
2. Instead of just supporting commerce_product entities it should loop through all available content entities and provide the joins for any content entity.

I need this for my project so I will try to provide a patch.

For the record I would love to see this too.

this works well for my needs. (showing price difference in the views order cart table)

I made one small change that @fostip pointed out.

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

Confirmed, MR9 applied to 1.0.x-dev, and is working with commerce 3.0.x dev

Thank you!

Yes, im on 3.0.x dev.

loze → created an issue.

I am using the latest 1.0.x dev version. That fix in the issue is already merged, no? So its in the dev version (at least thats what it looks like)

I cleared my caches multiple times.

Removing that one line has it working for now.

Clearing caches didn't do anything.

I was able to get it working by removing this one line from CommerceAjaxAtcServiceProvider.php

$definition->setClass(AjaxCartEventSubscriber::class)
        ->addArgument(new Reference('request_stack'));

removing the addArgument from this line

$definition->setClass(AjaxCartEventSubscriber::class);

Got it working.

I'm not sure if thats the correct thing to do, but if it is, I can make a patch/MR

Using commerce 3.0.x and Drupal 10.4.3

loze → created an issue.

I tried this out but the new setting was not saving on the display form. I made a small change to the MR. Here is a patch for composer.

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

Not sure what i did wrong with the MR. Here is a patch with what i was trying to contribute. its just one line.