problue solutions → created an issue.
A workaround (or fix I'm not sure) is to simply not react to the customer.subscription.created event in WebHookSubscriber and only react to customer.subscription.updated as it's always sent when the subscription is created anyway. Not sure of other implications but works in all scenarios for me.
I have re-visited this as I've had to do some work on an older project.
I have encountered this bug again while doing some testing for a seperate issue and I'm pretty sure this is caused by not handling idempotency (basically duplicate requests):
https://docs.stripe.com/api/idempotent_requests
Sometimes, but not always, the stripe event customer.subscription.updated is triggered at the same time as customer.subscription.created. This seems to happen more in the case of a wallet payment, but I have also seen it occasionally happen with a standard credit card payments, it seems in this case there is some kind of glitch where Stripe cant access the endpoint at that moment in time and then a second later sends an update event. The important point though is that the idempotency_key property for both webhook events is the same (meaning it's the same request), and this module does not check for, or handle that. This means a duplicate 'local subscription' is created.
From the documenation on the link above, there is an assumption that you already have that idempotency_key value when interacting with the API so it seems to me that it needs to be stored on the subscription entity when its initially created, so it can be checked to prevent a duplicate local subscription?
Does this make sense to the maintainers?
Dev version dated 12 July 2024 fixes the access problem, but the issue descibed in #8 (links not appearing in bookmark list table) is not fixed.
Just some more info - I suspect this is caused by customer.subscription.created and customer.subscription.updated events being received from Stripe at exactly the same time, this scenario seems to only occur when customer pays with a wallet method, when customer pays using standard credit card method these events are not recieved at exactly the same time.
I suspect the these two events when received at the same time are creating some kind of conflict and the code is provsioning the role and then removing it almost immediately because a second local subscription is created that remains unpaid.
Problue Solutions → created an issue.
Problue Solutions → created an issue.
Problue Solutions → created an issue.
So i have this kind of working by overriding the instanceBookLink() method in the Renderer service, we send the user to Stripe to make payment and then return to the bookable_calendar.booking_contact.create route to complete the booking. This works.
Theres an extra step after making payment though, where the user must review/confirm the booking contact before clicking book again to finalise the booking. Really what needs to happen is how the on-click booking works, where there is no confirmation of the booking contact and the logged in user's details are used.
If i enable one-click bookings then directing to bookable_calendar.booking_contact.create on successful payment doesnt work anymore. Directing to bookable_calendar.ajax.booking_contact.create doesnt work either due to the Ajax stuff going on that Stripe interupts.
Any ideas on how to do this using the existing methods of bookable calendar without unnecessarily overiding large parts of the code?
I have a question related to this. I will be using Stripe to take a payment when the book button is clicked, the booking will only be created upon sucessful payment. I want to do this is the simpliest and most basic way possible without using Drupal Commerce or the need to create products etc.
My question is where is the appropriate place to trigger the Stripe checkout session, is it in the save() function of BookingForm.php?
Sorry this is actually a permission on the Smart Date module, nothing to do with Bookable Calendar.
Problue Solutions → created an issue.
Hi,
Just confiming I did get this to work as descibed on a different site, I've no idea what modules or configuration may have been causing the issue on the other site and didnt have time to continue trying to work it out unfortunately.
Thanks for having a look.
I didn't have the language module installed, so I installed it and added English, British (en-gb) and set it to default and cleared cache.
I added a new entity and tried again but unfortunately the same behavior as before, widget defaults to Unrestricted.
I did have other policies as I was testing both node entities and custom entities, so i deleted all policies except one and tried again, but unfortunately this didnt work either, the widget still defaults to Unrestricted.
As i mentioned before, I also tried turning off "Allow empty" - "Allow authors to create and edit ccs entities without an access policy."
I'm not sure what this is supposed to do as it does not prevent creating or editing entities when "- Unrestricted -" is selected in the widget. I tried turning off "Hide original field widget" in the access rule because if "Allow empty" being turned off works as described, I dont see how the entity could be created without setting the access policy before saving, but this made no difference and allowed me to go ahead and save the entity with "Set access to: Unrestricted" still selected when viewing the Access tab.
Maybe this setting doesnt work as intended due to my orginal issue?
Thank you again for taking the time to respond.
langcode: en-gb
status: true
dependencies: { }
id: me_only
label: 'Me only'
description: 'Only you and the users below have access to this content.'
weight: 0
access_rules:
is_own:
id: is_own
group: ccs_entity
plugin_id: is_own
field: uid
entity_type: ccs_entity
settings:
admin_label: ''
query: true
required: false
field_grant_access_to_users_user_reference:
id: field_grant_access_to_users_user_reference
group: ccs_entity
plugin_id: entity_field_standard
field: field_grant_access_to_users
entity_type: ccs_entity
settings:
admin_label: ''
query: true
operator: '='
value:
field: uid
empty_behavior: deny
widget:
show: 1
settings:
field_widget: entity_reference_autocomplete
hide_original_field: 1
operations:
- view
required: false
access_rule_operator: OR
query: true
target_entity_type_id: ccs_entity
operations:
view_unpublished:
permission: false
access_rules: true
show_column: true
view:
permission: false
access_rules: true
show_column: true
view_all_revisions:
permission: false
access_rules: true
show_column: true
edit:
permission: false
access_rules: true
show_column: true
delete:
permission: false
access_rules: true
show_column: true
manage_access:
permission: true
access_rules: true
show_column: true
type: group
http_403_response: { }
selection_rules:
is_own:
id: is_own
group: ccs_entity
plugin_id: is_own
field: uid
entity_type: ccs_entity
settings:
id: 'ccs_entity:is_own'
admin_label: ''
required: false
selection_rule_operator: AND
selection_set: { }
Hi, thanks for following up.
Unfortunately no I was unable to figure it out.
I started again and carefully followed the tutorial to ensure I hadn't missed anything but I got the same result, the widget still defaults to "- Unrestricted -", with "Me only" available to select.
I thought maybe its something to do with it being a custom entity so I created the policy again for the node entity type but got the same result as above.
I am testing with just the administrator account so I have required permissions.
Problue Solutions → created an issue.
Perfect, I hadn't seen that page in the documentation, thank you!
Problue Solutions → created an issue.
We are also seeing this, specifically in the last few days and on all of our clients sites. Antibot is no longer stopping spam submissions on webforms and on a couple of sites where visitor registration is possiblle it is also no longer preventing spam sign ups.
Antibot has always worked fine for us up until the last few days, however I have no evidence to prove that it just hasnt been subjected to severe spam attacks up until now.
On one site which has both Antibot and Honeypot installed (with time restrictions enabled) we are suddenly seeing large amounts of spam through a webform, the only way we were able to stop it was to enforce telephone number validation on the form.
It feels to me like more advanced bots have appeared in the last few days which have made made Antibot and Honeypot no longer effective.
On Drupal 10.2 with Claro or Gin themes, when the checkbox is first clicked nothing happens, when it is clicked a second time the dependent field appears, and with each subsequent click the field disappears and appears correctly. It is only the very first click that does not work.
Problue Solutions → created an issue.
@robcarr - in the end I just left the field as multivalue and wrote a custom Feeds pre-validate event susbscriber and removed the field items greater than 0 (removing the unwanted 3 instances of the field and leaving the single correct instance). It's a workaround but my import now works fine.
Thank you for following up. Very encouraging to see such attention paid to the ECA module, even for a very minor edge case like this.
Unfortunately this particular project doesnt have a budget that would allow forking the module and solving the issue. We have decided to not use the phone number module as the workflow is more important than the validation.
Such is the life of small business Drupal development, there are still some of us around post D7 that dont always have budgets to spend time on things like this, so we just have to compromise :)
I did indeed, unfortunately I received no response almost a month since I posted: https://www.drupal.org/project/phone_number/issues/3362855 💬 'Field value has changed' doesn't work for phone number field Active
I'm closing this as i am no longer getting the error, I'm not sure if it was local caching or something but it has went away and Im not sure why to be honest.
Problue Solutions → created an issue.
I went ahead and just created a small module to provide this functionality: https://www.drupal.org/project/commerce_order_entity_print_bulk →
I'm not sure if there is another way via configuration, but this module works fine for me.
Just changing the path supplied to Wonderpush as /serviceworker-pwa seems to have fixed the error, I didn't realise that path was just an alias to the serviceworker.js file.
Problue Solutions → created an issue.
Problue Solutions → created an issue.
Problue Solutions → created an issue.
Problue Solutions → created an issue.
Thank you for looking into this and the very detailed reply, that makes sense when you see what the phone_number field is actually doing.
Problue Solutions → created an issue.
Problue Solutions → created an issue.
Yes I thought this was weird also, the only reason I posted here is because we seen it on multiple different devices. We had changed our requirements so that we didnt need to allow access for anonymous users which is why I did not investigate further and report back sooner, There could be many factors at play, for example we use better exposed filters, and filters exposed in a block for a block display etc.
I guess its probably better to close this and I will open a new issue with more info if we encounter this again in future.
itamair, as per my reply on the other thread, thank you so much for the pointers and guidance, you are an incredible asset to the Drupal community and sharing these quick pointers to orientate me in the right direction is exactly what i need to go and invetsigate and test further, and hopefully answer some questions in future instead of just asking them!
itamair, I havent even looked at the module yet but based on the help and expertise I have seen you offering in other threads I am sure this will be more than enough to help me on my way.
I appreciate this so much and thank you for the guidance, I couldnt have hoped for a better reply to this! Your response motivates me to also try and give back to the Drupal community in some way, thank you again.
Some more information - for some reason it works for anonymous users on dekstop devices, but not mobile devices.
We have tested on a number of different andoid devices using Chrome, it doesnt work on any of them for an anonymous user, but once they log in it works fine. On desktop it works fine on Chrome, Firefox and Edge for anonymous users.
Problue Solutions → created an issue.
Problue Solutions → created an issue.
This works fine for me on the field widget.
Is there any possibility of this being added to the views plugin?
You can already use the user location as mapcenter, so that works as well. You can than just refresh that site every X seconds. If it is a view, you can even do it by ajax to save performance.
I don't see any option to center the map on the user location in a Leaflet view. Where is that setting?
Problue Solutions → created an issue.
Problue Solutions → created an issue.
Im also getting this error when visiting the Drupal Uninstall page.
In addition to that, when visiting the Message configuration page I get the following error:
TypeError: Drupal\message\MessagePurgePluginManager::purgeSettingsForm(): Argument #3 ($purge_settings) must be of type array, null given, called in /web/modules/contrib/message/src/Form/MessageSettingsForm.php on line 104 in Drupal\message\MessagePurgePluginManager->purgeSettingsForm() (line 48 of modules/contrib/message/src/MessagePurgePluginManager.php)
Discovering whether a piece of content is flagged
Use the isFlagged() method to find out if an item is flagged.
Example:
$flag_id = 'bookmark';
$flag_service = \Drupal::service('flag');
$flag = $flag_service->getFlagById($flag_id);if ($flag && $flag->isFlagged($entity) {
print "This entity has been bookmarked!";
}
Is this supposed to return true if the flag id is flagged by any user for the given entity?
Im trying this code and it isnt returning true for a flag id that i know for sure is flagged by at least one user for the given entity.
Problue Solutions → created an issue.