🇺🇸United States @loze

I know this is very old but it looks like this is not working any longer.

I can t SUM on my price fields. Ive traced it back to commerce_reports_views_pre_build where this check here fails

  if ($field_plugin instanceof NumericField) {

The amount fields arent passing here so the custom formatter is never being used.

@elimw thanks for testing it.

What you are describing was actually done on purpose.

When the page is refreshed all the comments do appear in the correct order. But when you are replying to a comment it is inserted directly below the parent comment even if the comment has multiple replies already. It was easier and made more visual sense to replace the comment form with the newly added comment rather than removing the form, and inserting the comment somewhere else in the thread, then scrolling the thread. This also allows it to work if the new spot is not actually present on the current page (when using paged comments)

This is similar to how other modern commenting systems work, from what I have seen.

loze → created an issue.

Thanks @jsacksick I will check this out.

Yes, that's what I meant.

I suppose what im getting at is, since you've gone down this road, if I do the same and patch commerce to remove the saving of the references on the promotion, out what other parts can I expect to break?

I have a site with a lot of coupons, and am running into the same scaling issues.

Does the promotion need to reference the promotions? Couldn't the coupons just reference the promotions it applies to.
then getCoupons() could just query for coupons referencing the promotion?

I've run into this too.

@jsacksick if you can can provide some guidance as to how you envision it working, Im happy to work on a MR.

here it is https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →

That 2nd doc link is a 404

I am also stuck figuring out how to export.

loze → created an issue.

loze → created an issue.

This works for me. Im a bale to set the braintree field styles in a form alter

$form['#attached']['drupalSettings']['commerceBraintree']['styles']['input'] = [
      'font-size' => '18px',
      'color' => '#ff0000',
    ];

so im not too sure whats going on in that issue you posted. but it appears to be out of scope of this one.

@dinarcon Thank you for the clarification, I will give that a try.

@elimw

go to the field settings for that comment field and resave it from the UI. This shouldn't be necessary, but just for good measure, give it a try.

Also do you have any other modules in place that touch comments? if so something there could be conflicting.

Anyone ever come across this?

Thanks for taking a look. Unfortunately I'm not very good with writing tests and could use some help with that. Otherwise I would.

Patch still applies +1

MR 66 adds a contextual link to blocks. I will work on getting a link on the context inspector as well.

loze → created an issue.

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.