What I meant was that I made you a full maintainer so you could do it yourself, but I just changed it now. Hopefully you're all good now.
Try now?
@markaspot: Gave you the missing access.
@Anybody: Added you.
My thoughts: Let's make it a beta release until core support is resolved.
@pozzo-balbi: Granted! Thanks. Looks like the last person didn't actually do anything yet.
See 📌 Automated Drupal 10 compatibility fixes Fixed
Anyway, this seems to make sense, just running the computation a step earlier. However, I can't remember my original use case so I'm not sure how it'll be affected.
Maybe the best course of action here is having tests ( 📌 Add tests Active ):
- Add a test for the original use case (whatever that was).
- Add a test for this use case.
- See what happens?
Obviously, if you can't swing all of this right now, just use the patch here that helps you, and other will come by here later to help move things along.
Could this be related to 🐛 Allow computed function callbacks to determine cardinality dynamically Active ?
Could this be related to 🐛 Computed field should specify the cardinality of the field Fixed ?
MR was missing stuff so used patch. Thanks all!
This could be due to 🐛 Field permissions access override Fixed . Needs testing.
Added link.
colan → created an issue.
Here's a link to this issue's previous comment with helpful d.o markup (so we know the comment #): #2881776-35: Implement field permissions per-bundle (field instance) →
It sounds like Config Enforce → could fit in here somewhere, at least as an example what's solving problems in the wild.
You're not misreading; that's correct. I'd updated the title to reflect this. (I had no idea until you mentioned it.)
It could be. I have no idea as I'm out of the loop. Maybe reach out to them? I'll leave it to you to sort that out. :)
Anyway, congrats; you're on the maintainer list! Good luck and thanks.
I could make you a co-maintainer so you could do all of that and more (e.g. cut releases). What do you think?
This is already done: https://git.drupalcode.org/project/computed_field/-/blob/4.0.x/computed_...
Going to make this version stable to prevent folks from getting v2. For v4 status, see 📌 Version 4 roadmap Active .
For now, I'm going to make v3 stable to at least prevent folks from getting v2.
@joachim: What's remaining before we can tag a beta? What's remaining before we can tag a stable release?
Please add these lists to the IS. Thanks! :)
@chadmandoo: Please push to the MR as well so that it stays up-to-date. Thanks!
colan → created an issue.
A suggestion in the forum → seems like a reasonable approach.
As nobody's paying me to work on this module right now, I'm not actively maintaining it. However, I fully support having other co-maintainers coming on board. However, I don't have the "Administer maintainers" permission. So folks would need to contact the other maintainers who do. I'd recommend contacting the maintainer who added me; see #3074452: Colan request to be maintainer → for details.
Please also ask them to grant me that permission so I can grant it to others later, if need be. Thanks!
Assuming there are no other problems, MR !5 is good to go. Please review.
Maintainers: If you'd like help with getting this out (merging & cutting a new release), please add me as a co-maintainer; I'll get it done.
I merged MR !2 into !5, and fixed the core_version_requirement conflict, setting it to D9 and D10 as per #18. Setting it for D10 only is a bad idea because it requires folks to upgrade Drupal core and this contrib module at the same time, which I don't recommend.
Better title.
GitLab CI is now running for D8+. I've disabled Drupal CI for D7.
Thanks all! See new release with DD10 support: https://www.drupal.org/project/custom_breadcrumbs/releases/1.1.0 →
Got Gitlab CI running as part of ✨ Drupal 10 compatibility fixes Needs review . Let's remember to turn off Drupal CI when that gets in.
Follow-up issue is ✨ Drupal 10 compatibility fixes Needs review .
Just assume you don't need it for now so you can remove it. And yes, see 📌 Document which parts of the module are still relevant after aggregation changes in 10.1.0 Needs review for longer-term tracking.
This patch is almost identical to #2853002: Collision with ctools_views → , which is already in this branch, so it doesn't apply.
colan → created an issue.
New MR & patch for 2.0.x branch.
Switching to new branch.
Here's a more recent patch for Composer, which comes from the MR.
Fixed metadata.
I just created the new Comparison of booking/availability/reservation modules → in the Drupal documentation. Maybe add a link to that as well?
I didn't list this module as it sounds like you've deprecated it, but feel free to add it if you think there are still use cases for it.
Please add a "Similar Modules" section to the project page, with a link to the new Comparison of booking/availability/reservation modules → in the Drupal documentation. Thanks!
colan → created an issue.
colan → created an issue.
This is certainly helpful; thanks.
Major differences I'm seeing:
- No payment integration here, and
- it's not possible to reserve variable-length time slots here.
I don't believe this is supported now so it would be a new feature.
@hodba: Please open a separate documentation ticket in this queue to add your module to the list of similar modules. Thanks!
I'm going to stop here for now. It might make sense to merge this, and then break up the method in a follow-up issue. Thoughts?
Added remaining tasks to IS.
If you're using 8.x-1.11 and not HEAD, you'll need the patch in #15 (until the next release).
#15 works, but leaving as Needs Work because the code requires refactoring. That function is already unreadable (too long and too much nesting), and this patch makes that worse. Here's what I'd recommend:
- Create a new service.
- Jump into a service call directly from the hook implementation (to get out of procedural coding).
- Break it up into various protected methods so that they're short with descriptive names so that we have readable clean code with little or no nesting.
Done!
@mpdonadio → was the person to ask back then, but not sure he's still working on this stuff. He's on this thread though so maybe he'll respond. (If not, there's always his contact form.)
☝️
Here's an immutable patch for Composer builds. (See 🐛 GitLab Merge Requests Unable to Generate Incremental Patch Files Active .)
Here's an immutable patch for Composer builds.
Added section for workarounds to the IS:
- If you'd like a static patch file for an MR at a given point in time, download the diff, and then upload it as an attachment to a comment on the issue. This patch file can then be used by Composer in
composer.json. The problem is that this option adds more comments to the issue, which don't directly help solve it (i.e. noise). - Use
composer-patches' fix for Patches from drupal.org merge request URLs are dangerous?: Add support for patch checksums. If the MR changes, the new patch won't be applied because the checksum doesn't match. This will have the effect of breaking building that run into this, which will avoid the stability and security problems. This is included in version 2. However, at the time of this writing, v2 hasn't been released yet.
Could we get a status update on this now that v4 is out? I'm wondering what's changed with respect to this issue.
Workflows Field → would be the way to go nowadays.
Looks like @afagioli has done lots of work on the API module so I support this.
Fixing title.
Took a quick look at the code as I was looking for something, and noticed some minor things:
+++ b/js/stripe.js
@@ -134,99 +157,112 @@
+ // if (elementSettings.type == 'paymentrequest') {
+
+ // var paymentRequest = stripe.paymentRequest({
+ // country: elementSettings.country,
+ // currency: elementSettings.currency,
+ // total: {
+ // label: elementSettings.label,
+ // amount: elementSettings.amount,
+ // },
+ // requestPayerName: true,
+ // requestPayerEmail: true,
+ // });
+
+ // stripeElementOptions.paymentRequest = paymentRequest;
+
+ // // Create an instance of the PaymentRequest Element
+ // stripeElement = elements.create('paymentRequestButton', stripeElementOptions);
+
+ // // Check the availability of the Payment Request API first.
+ // paymentRequest.canMakePayment().then(function($element, result) {
+ // if (result) {
+ // var $form = $element.closest('form');
+ // stripeElement.mount($element.find('.drupal-stripe-element')[0]);
+
+ // stripeElement.on('click', function(event) {
+ // event.preventDefault();
+ // if (HTMLFormElement.prototype.reportValidity) {
+ // if (!$form[0].reportValidity()) {
+ // return false;
+ // }
+ // }
+ // $form.trigger('stripe:submit:start');
+
+ // var ajaxId = new Date().getTime();
+ // $element.attr('data-drupal-stripe-trigger', ajaxId);
+ // $element.find('.drupal-stripe-trigger').val(ajaxId);
+
+ // var formValues = $form.find(':input').not('.drupal-stripe-trigger, input[name="form_build_id"]').serialize();
+ // $form.attr('data-stripe-form-submit-last', formValues);
+
+ // $element.find('.drupal-stripe-update').trigger('mousedown');
+ // });
+ // } else {
+ // $element.parent('.form-type-stripe-paymentrequest').hide();
+ // }
+ // }.bind(null, $element));
+
+ // paymentRequest.on('cancel', function() {
+ // $form.trigger('stripe:submit:stop');
+ // });
+
+ // paymentRequest.on('paymentmethod', function(ev) {
+ // // Confirm the PaymentIntent without handling potential next actions (yet).
+ // stripe.confirmCardPayment(
+ // client_secret,
+ // {payment_method: ev.paymentMethod.id},
+ // {handleActions: false}
+ // ).then(function(confirmResult) {
+ // if (confirmResult.error) {
+ // // Report to the browser that the payment failed, prompting it to
+ // // re-show the payment interface, or show an error message and close
+ // // the payment interface.
+ // $element.trigger('stripe:error', confirmResult.error.message);
+ // ev.complete('fail');
+ // $form.trigger('stripe:submit:stop');
+ // } else {
+ // // Report to the browser that the confirmation was successful, prompting
+ // // it to close the browser payment method collection interface.
+ // ev.complete('success');
+ // // Check if the PaymentIntent requires any actions and if so let Stripe.js
+ // // handle the flow. If using an API version older than "2019-02-11" instead
+ // // instead check for: `paymentIntent.status === "requires_source_action"`.
+ // if (confirmResult.paymentIntent.status === "requires_action") {
+ // // Let Stripe.js handle the rest of the payment flow.
+ // stripe.confirmCardPayment(client_secret).then(function(result) {
+ // if (result.error) {
+ // $element.trigger('stripe:error', result.error.message);
+ // // The payment failed -- ask your customer for a new payment method.
+ // } else {
+ // // The payment has succeeded.
+ // $form.trigger('stripe:submit');
+ // }
+ // });
+ // } else {
+ // // The payment has succeeded.
+ // $form.trigger('stripe:submit');
+ // }
+ // }
+ // });
+ // });
+
+ // }
Can we remove this stuff that's commented out?
+++ b/src/Element/Payment.php
@@ -0,0 +1,27 @@
+class Payment extends StripeBase {
+
+ protected static $type = 'payment';
+
+
+ public static function processStripe(&$element, FormStateInterface $form_state, &$complete_form) {
Double newline here; one can be removed.
Merged, but testbot is having problems. So reopen if this doesn't work.
Lastest MR as a patch for Composer.
Edit: Don't review the code here as it's the multiple-patch file from Gitlab; it'd be confusing. Look at the MR instead.