🇭🇷Croatia @Aporie

Well, I'm already aware of a side effect which makes this method not sufficient.

In views with exposed filters (for example the admin user view), the submit button does not have the #name set with "op" value, which prevent the form API to detect the button was clicked (even when actually clicking on it with the mouse and not hitting "Enter").

View exposed filters offers the ability to "reset" the filter values, which button comes last.

This ends up resetting your views filters while you want to submit a search with selected filters.

aporie → created an issue.

Reroll for 1.25.0

This issue is fixed on 3.0.0-beta2. Probably still relevant for v2 though.

#60 works well.

With paragraphs also.

Ok, good to know.

It is probably something that can be added to the documentation.

Will give it some tests myself, when I have some time.

Hi Waspper,

If you didn't implement any customization yet, this module is not intended to add deposits to the cart. Also, draft is the regular state for Commerce orders before they are paid.

Using /user/funds/deposit or the deposit field, you should be redirected directly to the order information page and then to the review page to select a payment method out of the box.

You can refer to the document to understand the purpose this module has been created: https://www.drupal.org/docs/contributed-modules/commerce-funds →

Commerce funds has no intention to cover all cases and scenarios, so if you have another use case, you can just tweak it to your needs.

Of course, couldn't have been that simple.

I've created an MR. Pipeline currently fails due to datetime_range_timezone not compatible with D11 yet.
Don't want to downgrade the pipeline, so this will have to wait for D11 compatibility to relaunch the pipeline.
Tests were green on local.

I'm attaching a patch on 2.1.1 if anyone needs it.

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

Few years later ...

Patch reroll for 2.1.x, same need.

I will review if everything works fine, but I think it's quite safe to move further.

Hello,

I think the answer is in your question :)

If you want to display a message on specific paths, you can simply use a block with text inside, without the need of alert_message.

You can also use several "alert message" blocks which will target specific users, for example, and for which you can only display to specific paths.

I'm pretty sure it's doable out of the box.

Hi Compujohnny,

Thanks, I wasn't sure you were still around.

I have maintainer access now on gitlab.

MR33 looks pretty good to me.

I think it's quite safe.

I've been using this fix for a while and it seems to work.

Will release soon.

compujohnny contacted.

aporie → created an issue.

Hi Anybody,

Thanks for the contrib. I was actually working on a new release for CF.

I just re-saved the view and re-exported the config. Did the trick.

Closing this ticket.

Can you provide me which other modules you are using from the commerce suite (stock etc.)?

I'm getting some work done for a new release.

Reading this issue again, I'm pretty sure it's related to a payment method you are using.

Can I ask which ones you were using?

I'm revamping this route anyway as I mistakenly named a plug "bank-account" while it should have been "bank_account".

Hmm, I don't know if you really have an issue or not, but normally if you follow the workflow "Create a new wallet" it should create it for your user in the current currency.

Regarding the user/site balance, I was aware of user 1, but what threw me off was that the same applies to anyone who has the "Administer all transactions" permission, which makes sense.

--> True

Unfortunately, I am still struggling with the module and must have done something wrong. Now I can only see the "Funds balance" (create a new wallet) payment method. I understand that the Wallet payment method is shown only when the user has a wallet. However, I deposited money into the user's account, but the payment is still not displayed. When I go to the user's Payment Methods page, it says, "There are no payment methods yet," even though I just deposited some amount into the user's account.

Are you a native english speaker? Because I know my terminology has been quite confusing for some users.
Account Balance = where the funds are stored for each users. Each user has an account balance by default and when you transfer money from one user to another, it should be credited.
Wallets = Those are completely independent of where funds are stored or not. It's just a terminology used to name the "payment methods". Wallets are only created for user to purchase products on your website using their "Account balance" funds. Drupal commerce require a Payment Method to make a purchase on your website, so if you want to buy a product using your account balance, I had to create a "virtual" Payment Method option in the list called "Wallet" to allow them to do so.

Hence, when you deposit funds to your Account Balance, there is no need to have a virtual wallet, as you MUST use another payment method to credit it. Wallet Payment Method is only created to purchase a product using your Account Balance.

Reroll of #16 for 10.3.6 introducing this commit

Add FAQs

Hi,

These two issues are known issues of misuse of commerce funds:

1. The site balance belongs to the user 1. Hence, if you perform your tests using the user 1, you will see fees and amount added to the site balance which is the same as yours.
2. Your deposit might not be added, because you are using the manual payment method and you need to receive the money manually in that case to trigger the order payment. Then funds will be added to your balance.

I think I will update the documentation with these info ;)

This is not an issue related to Commerce Funds.

You can try to set your minimum stability to dev: composer config minimum-stability dev

Or try to find a version of Drupal commerce which uses drupal/inline_entity_form v2 (if it exists, seems they only want 1 or 3).

Hi,

Wasn't able to reproduce all your error (the error 500 with NULL ID), but I think this should do it.

Can you try the attached patch?

Yeah ... A user context will only cover logged-in users, unfortunately.

That's why we need this stack middleware, to cover anonymous users.

I'm keeping this ticket open for reference.

Hello,

Can you share more details on your issue, maybe screenshots?

The middleware is needed because you need to invalidate the alert block cache for each logged-in user and eventually each anonymous users (so on each request).

So basically this block can't be cached.

Just in need of a fixed version of the current diff which applies on 1.18.

Hi Donpas,

There is a MR available. You can find the patch by clicking on "plain diff".

+1 RTBC

Hi @handkerchief,

I'm attaching a patch based on this ticket finding and alert_message finding.

Basically, this happens when trying to use the entityTypeManager in the stackmiddleware because Drupal is not fully bootstrapped yet.

Early loading system module might help, see #10 and 🐛 Undefined constant "Drupal\node\Entity\DRUPAL_OPTIONAL" RTBC .

I have not tested my patch, but it has been helping people on alert_message for a while, and the issue is the same. Though, it is hard to provide tests as described in the ticket description because it's all happening before Drupal is fully bootstrapped and related to module orders. Playing with the weight of the middleware is also a solution, but sometimes you might want to run your code early (as in alert message and I assume in the shield module).

Reroll for 10.3. I think we got lost in the rerolls, #38 didn't work for me.

Agree with #34.

Also, have removed unnecessary checks on parameter $tokens which would never be undefined and just wait to be typed into array IMO.

Let's see if that passes the tests, but from a quick look, I haven't seen any tests regarding parsing of tokens or twig templates. So, we might need a bunch of more tests, to test every area for token parsing when "Use replacement tokens from the first row" is ticked or not.

Currently, only empty area is checked for global tokens in core/modules/views/tests/src/Functional/Handler/AreaTest.php:testRenderAreaToken, but I might be missing other tests I haven't seen.

Also guys, I'd like to point/question the necessity of using string translations (such as {{ 'My text'|t }}) in views as they should be translated using entity translation? In my case, I need it to parse twig.

This won't be possible out of the box.

I recommend you to take a look at the drupal doc → to understand the scope of the module and to the external doc on how to integrate Commerce Funds with Rules for customized workflow. This might be enough to do what you want.

Otherwise, as your requirements seem pretty specifics, you might also want to look into hiring a dev.

Hi,

If you haven't found the answer yet on your side. You should be able to do that with a block which is available. I think It's called "funds balance" if I recall correctly.

Well, you seem to have a very weird use case for this module :) If I got it correctly, you actually use the payment option to credit currency (which is perfectly fine, just not the way it was intended to).

So ... I took a look, and unfortunately it's not possible to change "Funds balance (create a new wallet)" easily as it's the way Drupal Commerce is built and display the payment method type label (which is hard coded). You might be able to do it with a hook or something, though.

For the "Wallet (USD)", if you can apply this small patch attached, that should do it. I still have to hard-code the currency though, but it will now display the "Display name" of your payment gateway followed by hard-coded selected (@currency).

Hey,

I think you're just trying to perform a transaction (whatever the type is) with a user that doesn't have the permission to do so.
Just check permissions under /admin/people/permissions and make sure the user you're using has the necessary role and permission to perform the transaction you want.

That should do it.

There is no such option out of the box, unfortunately.

I was just pointing where the extra work should be done.

Just keep the ticket opened and we'll see.

I think a proper way of doing that would be to create a new condition in the payment gateway:

Regarding the fact that it's the default option, I think it's just a matter of reorganizing your payment methods under admin/commerce/config/payment-gateways.

As a workaround, you can probably perform checks and hide or display "create a wallet" button according to the order currency within the following preprocess: hook_preprocess_commerce_checkout_pane

Yeah, it's a good approach sometimes to tests on a dummy installation and then work on a clean installation.

Ok, I'm closing the ticket.

I found that the two new tables were removed from the uninstall process (the enabling process doesn't create the two tables)

From my tests, uninstalling and reinstalling the module created these tables. Though, it's coming from Drupal commerce plugin implementation it's not directly linked to commerce_funds.

For all your error messages except the last one, it seems it's coming from the points module.

The last one is because you have an order with a non-existent bundle.

At that point, your db seems pretty much corrupted and content have been created with corrupted data I suppose. You'll have to do some cleaning, and I'd start by removing all Drupal Commerce (orders, orders types etc.) entities. Also try uninstalling this points module to check. But as long as it'll start to be non Commerce Funds related, I might not be from great help.

So, I've checked, and actually these tables are created on commerce_funds installation.

That limits your possibilities here. If you want to keep your current db, you'll have to create these table manually using phpmyadmin or Mysql commands. I'm attaching you the fields so you can quickly reproduce them.

commerce_payment_balance_id:

commerce_payment_currency:

Otherwise, try to ping me on https://drupalchat.me/ during the day, I'll stay around but have limited time.

Hmm, try recreating a "funds balance" payment gateway under /admin/commerce/config/payment-gateways/add (it doesn't matter the name).

Once done, try uninstalling commerce_funds again.

Hi,

Regarding your previous install, you might have a corrupted installation of the module. If I were you, I'd uninstall it and reinstall it after updating to last version with composer.

For order payments, this shouldn't be related to commerce_funds, and you should be able to use any payment method. This module only hooks itself around commerce payment processing, so issues might come from the module you use as a payment gateway.

Looking into the code, your error happens here:

/** @var \Drupal\commerce_order\Entity\OrderTypeInterface $order_type */
    $order_type = $this->orderTypeStorage->load($order->bundle());
    $refreshed_ago = $current_time - $order_time;
    if ($refreshed_ago >= $order_type->getRefreshFrequency()) {
      return TRUE;
    }

It means $this->orderTypeStorage->load($order->bundle()); returns nothing. I don't know where you're at in your development process, but I would make a complete reinstallation of commerce_funds and Drupal commerce. This will force you to delete any previous entity you might have created which seem to be corrupted now.

Hi Guys,

Sorry, I might have rushed the migration to commerce exchanger V2.

This passed the tests because they are using dev modules (such as commerce_exchanger).

@aaron.ferris, the right action to take here is actually to keep this module as optional.
@sdsc, you should be able to get a working website with your backup, only updating your module to the last release and clearing the cache.

Aporie → created an issue.

Arf sorry.

Forgot about your issue and contribution.

Credit attributed.

Hi Arno2Mars,

Thanks a lot for your detailed explanation. I finally got it working!

Also needed to set the status of my transaction to "canceled". I've updated my article on my website and allowed myself to comment your trick to bypass rules validation checks on price fields.

Might have come from your corrupted installation, yes.

Just performed uninstall/install/uninstall without issue

Can you confirm after applying patch from other ticket?

Thanks

Hi,

Thanks for reporting this.

Patch attached.

Ok, had some time to look into it.

The attached patch should fix the WSOD error. TBH, I don't even know how it used to work before.

Though, I tried to make it work with a rule and still not successful.

I had two issues:

1. I can't use a "Commerce Price" field in my content using node.field_amount.number and node.field_amount.currency as now rules validation returns an error expecting a decimal number and not a string.
2. When saving my content type where the rule should apply, nothing happens. Even when I add two extra actions, save entity and perform transaction. But now I can't select entity in data selector, I can only select commerce_funds_transaction_created (which is probably something rule created itself).

I found the How to again.

Hey,

Yeah I might have forgotten to put the perform transaction action. I think I've written a how to somewhere on my website, I'll try again when I have a bit of time.

Regarding the field you should be able to change the transaction type in the form field formatter if I recall correctly ...

Hmm, they were a lot of changes made to the rules module since then.

Could you try on a fresh installation? Also, maybe just try to rebuild your rule.

Personally, on a fresh Drupal 10.2 install, I don't even get the transaction to be created when saving content. I don't think it comes from commerce_funds but from the rules module.

Also, now commerce_funds provide fields that you can add to your content type, maybe you can find a way to do what you want without using rules.

Regarding #7 and #8, from my POV, error handling should be done by project, and it's almost impossible to provide an all-in-one solution which will satisfy each Drupal website.

Hence, the idea of only handling error 500 or specific errors like maybe status code 0, even though this can be produced because of different reasons, see here and https://stackoverflow.com/questions/872206/what-does-it-mean-when-an-http-request-returns-status-code-0.

Even making a big config form with a custom message for each HTTP status code wouldn't make sense to me, as, for example, you might want to return a different error message on different 403 or 404 to your users on the same AJAX response:

Example, errors 403 returned by the same Ajax handler:

• You do not have the necessary permissions to access this resource.
• Your session has expired.
• Insufficient privileges to perform the requested action.
• Access to this resource is restricted from your current IP address.
• etc. etc.

This is now fixed in the 1.3 release.

Patch for #8

I think I got a more robust solution.

Indeed, it takes over core Drupal\path_alias\AliasRepository::lookupBySystemPath to work around #3, and it should probably be aligned with core.

The overall idea of the patch is to force load the current node language when loading the alias (and not using addLanguageFallback from core lookupBySystemPath to decide whether we should pick "und" or current language) and then to generate an "und" alias when saving the default translation entity.

I'm attaching it, if that can help, be improved.

If needed, same patch but for ^9 and ^10 applicable on version 1.2.

Yep, thanks shweta, figured it out when rebuilding my project. Bug was still there ...

Agree with #38.

I think the "issue" comes from ckeditor itself.

The thing is, the toolbar is supposed to be wrapped under a menu when there is not enough room. For this reason, they might have forced flex-wrap: no-wrap on the toolbar.

With the following patch, you restore the behavior as it used to be with ckeditor 4:

I think this could be an option to add to claro theme.

You can use npm as well.

Stomped against the same issue.

In my case, I needed to bulk rebuild URLs on a multilingual website. Problem is, with the snippet above, I could not overwrite translated aliases (from token context, i.e [node:title]) because it would only create aliases for non translated version of the entities (when und is called).

Tweaking the snippet to pass LanguageInterface::LANGCODE_NOT_SPECIFIED only on default language entities would get me with all aliases overwritten except the default one (i.e "en").

Ended up making this small patch, which feels more like a hack but does the work. I have now all my aliases from "translated" languages (served by their translated alias version) and not "translated" languages (served by "und") overwritten.

I agree.

The message is not clear. Plus, we should think about displaying a message only on error 500.

I guess this feature was made thinking about using Ajax with drupal css "use-ajax" and "use-ajax-submit" but you want to let developer be able to handle themselves other errors (such as 403 or whatever) on Drupal.ajax implementations.

I personally ended up created this patch for 10.1

Hi,

I might be in the wrong here, but why assuming that every Ajax response should return a 200 is the expected behavior for all websites.
Sometimes you might want your user to be able to click an ajax link which will return a 403 for example. Then you purposely display a message to your user that they are not allowed to perform the action.

With this addition, websites have now a non-needed, non-user-friendly message displayed to users on expected 403.

Maybe a good addition would be to make this feature optional (as per improving the message in 📌 Determine if there is a better message for AJAX errors. Active )?

There is a duplicated issue #3136292: Division by zero in AspectSwitcherImageEffect → which patch caused us

Error: Xdebug has detected a possible infinite loop, and aborted your script with a stack depth of '256' frames in is_int() (line 331 of core/lib/Drupal/Component/Utility/NestedArray.php).

This patch is fine though (and seems an easier approach) than the attached duplicated issue.

Thanks @jan for the feedback.

The same. I've deployed this patch to a project on production, it works well (but has some other issues similar to this one with classes not defined, whereas they are) only once, and I have no idea what triggered it.

Though this project has no cache and page_cache has been uninstalled, so the same, I can't really set this patch to "reviewed".

Let's wait for a while and we'll see.

Aporie → created an issue.

So ... for now, the only decent solution I've found is to anticipate the load of the "system" module:
\Drupal::moduleHandler()->load('system');

The issue is that whatever we do, during bootstrap phase, Drupal loads all module files in core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php::handle(). This middleware has a priority of 100 to "Prepares the environment after page caching ran". Until we try to run a query on a middleware with a higher priority (in my case 210, just before page cache middleware), there is no way to have the const DRUPAL_OPTIONAL defined.

I still don't get how we are able to get a value for this constant (before clearing cache or triggering the error) and we might rely on some extra cache, like op cache, though I've investigated this and op_cache is fully loaded and includes "web/core/modules/system/system.module" even when the error happens.

This wouldn't do a thing:

$op_cache_status = opcache_get_status();
if (opcache_is_script_cached('/core/modules/system/system.module')) {
   return $this->httpKernel->handle($request, $type, $catch);
}
if (defined('DRUPAL_OPTIONAL')) {
   $defined = TRUE;
}

DRUPAL_OPTIONAL is NEVER defined as the file is still not loaded by KernelPreHandle.

So, to mitigate the change, early loading the system module prevent the bug to happen and is then catched in core/lib/Drupal/Core/Extension/ModuleHandler.php:123

public function load($name) {
    if (isset($this->loadedFiles[$name])) {
      return TRUE; // system is already loaded, we do not load it a second time.
    }
....
}

so we don't load system twice. I will try to run it on all my tests and see if I see some failure. Have no idea about potential side effects for now.

Hi @all,

Thanks for piging me on this @jan kellermann.

I confirm I was aware of this issue (and it is due to the middleware of alert_message), dunno if there is a similar case on shield module (but I see there is a middleware implementation also). I have this issue when running behat tests, every time I clear the caches.

Because this issue does not happen on prod (but only in our tests) I admit I didn't try to tackle it.

If there is a way to reproduce this using the backend (and not running tests) it would be nice to share it, so I can try investigating this. What is the workflow to reproduce it outside of tests?

Maybe we can play with the middleware weight, trying to get all the necessary before running an entity query?

Hi Anybody,

Yes it works. Was also looking for something like that for a while. Would be great to add it to the doc indeed.

On a custom module, this can be reduced to two lines (so don't think we need a wrapper):

$entity_type_definition = \Drupal::service('entity_type.manager')->getDefinition('custom_entity_type');
\Drupal::entityDefinitionUpdateManager()->installEntityType($entity_type_definition);

LGTM

LGTM

@drupal.rs,

You're right, the default behavior is actually to credit the author of the product.

If you want to redirect all transactions to admin user 1, you might want to patch or implement your own payment gateway similarly from this file: commerce_funds/src/Plugin/Commerce/PaymentGateway/BalanceGateway.php

If you're using drupal 10, make sure to install the dev version of the module.

There is a small indication message on the module page, but I can't create a release right now, the D10 version not being compatible with the D9 version.

This sounds like you haven't removed the "Deposit completion message" from the default checkout flow. It's only a message and should not credit or debit the balance from anything. Just make sure to disable this pane from your payment workflow.

Regarding the balance not being debited, if you're using the funds method as payment gateway, it should normally work. What it does is debit the user bying the product and transfer the funds to the admin balance (user 1). If you were trying to buy the product with user 1 then this might result in a "transparent" transaction.

What do you have in your transaction history? Does the transaction happen?

Hi nod_,

Thanks for helping, and it's indeed linked to big_pipe.

Well, I took a look and, too much work (moreover core related) has been made for me to grasp what is the exact reason of this "issue".

I think the closest would be 🐛 The attachBehaviors() for document is only called after Big Pipe chunks are processed Fixed

Though, these commits have been removed since then.

I just want to add myself to the list of persons in the mentioned ticket relating how big this impact could have on contrib modules and current websites. I'm not sure if this change is due to switching on mutation observer and what is the exact reason to attach all Behaviors before drupal.init.js does it again.

What I can tell, though, is that big_pipe was working before these changes were introduced, and it works also now (on 10.1), but all behaviors are added twice on page load.

Indeed, relying on once is an option and will probably be the way to go, but it used not to be the case. For any JavaScript code that wouldn't need to be executed on ajax responses, we could just target the dom document on load and that was it. Plus, I do think the new changes have a browser performance impact (as now all attached dom functions will have to be checked for once requirement).

Even though, again, I don't have a clear vision of the changes. If that's the way to go, then let's go for once everywhere. But if there is a way to get back to having all behaviors only added once on page load, then I'd vote for this solution.

I'm closing this ticket for now.

I'll see if I have some time next week. But there are 1588 commits to go ...

If I knew ...

Aporie → created an issue.

!24 works and looks good to me.

I think it's good for RTBC.