3
Generally speaking, no. Adjusters should always be computed from the current state of the order—the information required to match an Adjuster should be attached directly to an order.
Your custom Adjuster is registered globally, then applied to Orders that match criteria you've defined in its adjust() method. That method returns an array of Adjustment models, ...
3
This is certainly still possible with Commerce 3 and Craft 3.
In a custom plugin or module you can listen for the Transactions::EVENT_AFTER_CREATE_TRANSACTION event and amend the transaction amount at this point in the process.
For example, you could make your own payment form that includes a partPaymentAmount field and posts to the normal commerce/payments/...
2
In short, no. If this is config or data which are environment specific, they are as likely not good candidates for project config. Perhaps consider moving them to a table and access them through a Record/Model?
2
I experience the same with https://github.com/Saboteur777/craft-support forked from https://github.com/jasonmccallister/craft-support (which is a fork of https://github.com/lukeyouell/craft-support).
Using composer update will not change "tracks" to the original plugin, so you are safe to update, the notification is a minor annoyance, though.
2
I've managed to get it working with great help from Brad Bell and Oli.
The following code changes feedme slugs on Import.
use craft\feedme\events\ElementEvent;
use craft\helpers\ElementHelper;
use craft\elements\Entry;
Adding the following Event with the namespaces above works nicely.
Event::on(
Process::class,
Process::...
2
It should be $event->parsedValue - see here - https://github.com/craftcms/feed-me/blob/develop/src/services/Fields.php#L225
1
Updated
After a lot of tinkering - I finally found out how to check if the field is matching/existing and if nothing matches - Skip adding this element.
Event::on(
Process::class,
Process::EVENT_STEP_BEFORE_ELEMENT_SAVE,
function (craft\feedme\events\FeedProcessEvent $event) {
switch($event->feed['name']){
case 'offers':
$merchants = $event-...
1
isValid should be set on the $event variable, not on $event->element:
Event::on(Process::class, Process::EVENT_STEP_BEFORE_ELEMENT_SAVE, function (FeedProcessEvent $event) {
$myField=$event->feedData['myfieldname'];
if ($myField == null){
$event->isValid=false;
}
});
I haven't tested but looking at the feed-me source code, this ...
1
You can have plugin A listen for the EVENT_AFTER_INSTALL_PLUGIN event.
It could then check if $plugin->handle is for plugin B and if so, run any additional install migrations or logic.
You could do something similar for the EVENT_AFTER_UNINSTALL_PLUGIN event to clean things up in the case where one gets uninstalled.
1
Alright! I've been able to fix my problem. I did a couple of things wrong so I'm writing this for whoever makes the same mistakes I made and is now trapped in an endless loop of despair and impending doom.
First mistake!
You should leave the action attribute of your form element empty.
Call you action by using a hidden input, like this
<input type="...
1
I've figured out how I can do it, but it doesn't feel like the best way.
What I've done is hooked on to the showActionTrigger event, then hidden the button if the source != 'staged'
showActionTriggers: function() {
this.base();
if (this.$source.data('key') != 'staged')
{
$('#button-id').hide();
}
}
I have a feeling the best way is ...
Only top voted, non community-wiki answers of a minimum length are eligible
