We can handle this as a feature request to add a new action plugin for that special one.
Understood. But it seems like this would result in a significant amount of feature overlap between the new action plugin and the existing one, because if a new action plugin was made that utilised Drupal Core's Serialization module to collect serializers, both Symfony and non-Symfony serializers would be dynamically collected as Drupal Core exposes both kinds in the same API.
starlight-sparkle → created an issue.
Also, i'm wondering if the proposed solution doesn't quite match the screen shots that were provided now? The proposed solution is to just grey out the options if the extension isn't loaded, but the screenshots simply remove the options
I can only see one screenshot in this thread, so I am assuming that you are referring to the screenshot in the IS.
That screenshot is not demonstrating the proposed solution. That screenshot under the "Problem" heading, so it is demonstrating the undesired behaviour.
If a license is required to view the node (i.e. an "access denied" would be shown if you don't have a license), could you simply use the "Entity: is accessible" condition from the ECA Content submodule in ECA?
In other words,
load the node into a token ––Entity: is accessible?––> (if yes) react
When I was previously implementing a "pay what you want" scheme in commerce, I looked into using a price resolver, but ran into the problem that price resolvers had been intentionally designed to be restrictive (not having any way to access the price entered by the user in the add to cart form, aka order item fields).
I then tried using adjustments next, but the UX for adjustments on order items in Commerce is not very good; adjustments are displayed with little detail and shown next to the grand total for the order/cart, instead of being displayed next to the subtotal for each order item.
For the "pay what you want" scheme, I had to fall back to directly setting the unit price on the order item and just manually making sure that it was only performed in response to specific events within the order refresh process.
several other systems interact with these draft prices until the point of order placement, and the order of operations is often very important
As a workaround, perhaps ECA commerce could trigger an order refresh after the price is changed, so that it effectively becomes the "first" in the chain of processors. But it would have to be an optional feature that is disabled by default, as it can cause infinite loops if the action was itself triggered by an order refresh.
New currency field added that mostly uses the same code as the Adjustment action.
Not sure if an update hook is needed to insert a blank field value to existing configs.
starlight-sparkle → created an issue.
what status should this issue be in now? "Needs review"?
As a side note, this implementation also includes a Trait which can be reused to support currencies other than USD in the existing "Change Price in Cart" action.
starlight-sparkle → changed the visibility of the branch 3426536- to hidden.
I've implemented a new action for this, though I had originally built it against 2.1.x, so I had to leave out some features to make it compatible with 1.0.x.
I will probably need advice on how I should wrangle git to create forward ports to the 2.1.x branch so I can put the extra features back.
starlight-sparkle → made their first commit to this issue’s fork.
I have made a merge request addressing this issue this as part of Drupalcon Singapore 2024 Contribution Day.
@larowan came by and suggested to add a message explaining the empty field rather than altering the behaviour of the edit settings gear icon, as this would require EntityDisplayFormBase::buildFieldRow() to traverse all the nested fields inside of widget settings form to check if they are visible.
Removing the form element from the settings form was also not advisable as this would change the form schema.
starlight-sparkle → made their first commit to this issue’s fork.
it's present!
Coaston means to say that the original commit is incomplete, not that the commit is missing.
The MR created by jnettik implemented the fix in a different way from the patch file submitted by artyom. Namely:
- The MR implementation simply calls
Element::isEmpty() - The patch file implementation additionally executes the view to check if the rendered output is empty
This is significant in the special case of views because as explained 🐛 Empty content view Fixed :
ViewExecutable will build a render array regardless of whether it has anything to display, because the view is not executed until render time, and hence just checking the render array it not reliable, which is all
Element::isEmpty()does.The Drupal Core views block display plugin (
\Drupal\views\Plugin\views\display\Block::execute()) suggests that the correct way to check is to actually execute the view with arguments, then check$view->getDisplay()->outputIsEmpty(), which is how the plugin implements its "Hide block if the view output is empty" option.
Follow up from issue 3283364 as well as comment #4 from this issue's reporter.
The merged commit (94a2ab3d) contains a fix for ExtraFieldBlockPlugin, but it appears ExtraFieldViewsPlugin also has an issue.
The problem is that a ViewExecutable will build a render array regardless of whether it has anything to display, because the view is not executed until render time, and hence it is not sufficient to check the render array.
You have to actually execute the view with arguments, then check $view->getDisplay()->outputIsEmpty()