That was my mistake, I intended to do it against 4.0.x Thanks!
I've made some updates to the MR.
1. It checks if taxonomy_entity_index is enabled, and defaults back to using the taxonomy_index table if it is not.
2. the views fields/args now supports all content entities.
I have also updated the patch on ✨ Provide views join on BASE_TABLE_field_data Needs work which is required for this to work.
Everything appears to be working as expected on my local site and I can now use this module with products and other entities.
attached is a patch for composer
Here's a patch of the latest MR for composer
I made a small update to the MR to use $info->getDataTable() to get the table name and only include it if the entity has a data table.
I see some modules that provide views integration use something along the lines of
$table_name = $info->getDataTable() ?: $info->getBaseTable();
to get the table name for joining entities. Im not sure if thats appropriate here or if doing so would break existing views.
So I'm just adding this join to the data table which make it work with the parent issue.
Thanks, this got it working for me with commerce_product entities, and think this is on the right track.
This also needs to do the following.
1. Check if the taxonomy_entity_index module exists first and only perform these changes if it does.
2. Instead of just supporting commerce_product entities it should loop through all available content entities and provide the joins for any content entity.
I need this for my project so I will try to provide a patch.
For the record I would love to see this too.
this works well for my needs. (showing price difference in the views order cart table)
I made one small change that @fostip pointed out.
Confirmed, MR9 applied to 1.0.x-dev, and is working with commerce 3.0.x dev
Thank you!
Yes, im on 3.0.x dev.
I am using the latest 1.0.x dev version. That fix in the issue is already merged, no? So its in the dev version (at least thats what it looks like)
I cleared my caches multiple times.
Removing that one line has it working for now.
Clearing caches didn't do anything.
I was able to get it working by removing this one line from CommerceAjaxAtcServiceProvider.php
$definition->setClass(AjaxCartEventSubscriber::class)
->addArgument(new Reference('request_stack'));
removing the addArgument from this line
$definition->setClass(AjaxCartEventSubscriber::class);
Got it working.
I'm not sure if thats the correct thing to do, but if it is, I can make a patch/MR
Using commerce 3.0.x and Drupal 10.4.3
I tried this out but the new setting was not saving on the display form. I made a small change to the MR. Here is a patch for composer.
Not sure what i did wrong with the MR. Here is a patch with what i was trying to contribute. its just one line.
loze → changed the visibility of the branch 3510555-incorrect-variable-type to active.
loze → changed the visibility of the branch 3510555-incorrect-variable-type to hidden.
@socialnicheguru my mistake. They should work together now.
There have been a lot of changes recently and this was no longer applying. I've created a MR for this feature.
See my comments in #6 for what this does and how to set it up properly.
This is awesome! thanks so much @tr!
I think there should be a config setting per entity browser allowing the admin to choose which theme to use for each EB, defaulting to the admin theme.
Thanks @claudiu.cristea. Unfortunately, I have been unable to wrap my head around how to write tests. I've tried on several projects but can't seem to grasp it.
Hopefully someone else interested in this feature can help out with that.
This MR brings over the changes from github for #333. I've tested it locally and it seems to be working.
A select field is added on the group type form, where you can select the membership type to set as the default for the group type.
Requesting a membership for that group then creates a membership of the defined type.
This MR works. I'm constantly running into this issue with aggregated views. Thanks!
Latest dev makes token optional.
My mistake. It seems I hade some custom code that was conflicting. I got it working.
I also encountered this extending a field widget formatter. The patch in #34 seems to work with Drupal 10.4.2
@tr, that last one did the trick!
I am now able to add new votingapi_widgets fields.
I'm currently testing on a relatively clean install of Drupal 10.4.2 and the latest 2.0.x version of votingapi_widgets
Thanks @tr
The MR applies, but the error is still there when adding a new field.
Even after clearing the caches after applying the patch.
The website encountered an unexpected error. Try again later.
Drupal\Component\Plugin\Exception\PluginNotFoundException: The "" plugin does not exist. Valid plugin IDs for Drupal\votingapi_widgets\Plugin\VotingApiWidgetManager are: fivestar, useful, like in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).
Drupal\Core\Plugin\DefaultPluginManager->getDefinition('') (Line: 16)
Drupal\Core\Plugin\Factory\ContainerFactory->createInstance('', Array) (Line: 83)
Drupal\Component\Plugin\PluginManagerBase->createInstance('') (Line: 133)
Drupal\votingapi_widgets\Plugin\Field\FieldWidget\VotingApiWidget->formElement(Object, 0, Array, Array, Object) (Line: 459)
Drupal\Core\Field\WidgetBase->formSingleElement(Object, 0, Array, Array, Object) (Line: 219)
Drupal\Core\Field\WidgetBase->formMultipleElements(Object, Array, Object) (Line: 120)
Drupal\Core\Field\WidgetBase->form(Object, Array, Object) (Line: 287)
Drupal\Core\Field\FieldItemList->defaultValuesForm(Array, Object) (Line: 230)
Drupal\field_ui\Form\FieldConfigEditForm->form(Array, Object) (Line: 107)
Drupal\Core\Entity\EntityForm->buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 536)
Drupal\Core\Form\FormBuilder->retrieveForm('field_config_edit_form', Object) (Line: 284)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 48)
Drupal\Core\Entity\EntityFormBuilder->getForm(Object, 'default', Array) (Line: 62)
Drupal\field_ui\Controller\FieldConfigAddController->fieldConfigAddConfigureForm('node', 'field_new')
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 638)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 53)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 116)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 90)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 741)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
@piyusha That is a core bug thats being worked on here 🐛 Nested modals don't work: opening a modal from a modal closes the original Needs work It's not specific to gutenberg
Never mind. I see now that this is something being added to core.
loze → created an issue. See original summary → .
Apparently ckeditor is not triggering Drupal.attachBehaviors() when its rendering media items. So I guess its not an issue for this module.
Created a MR from #11 I have been using this patch for quite some time as well.
@tr, I just left a comment on that issue and marked it as RTBC. I cate about this module and currently use it on two sites and am happy to help you get a stable release out.
I have been using this MR for a few months and everything appears to work as expected.
Just needed to include core/internal.jquery.form as a dependency in the .yml
MR4 does the trick
I am seeing the same as @malcomio and this patch fixes it for me as well.
Drupal 10.4.2
Tested. fixes the issue. thanks!
The patch in #149 applies and works as expected for me in drupal 10.4
thanks!
I've done some work here to improve the drupalblock config form in MR214 and its working for me.
The form now submits with the core drupal ajax and runs the block through the validation and submit handlers.
I borrowed a lot of this from the context modules block reaction code. That module is similar to what we are doing here, in that it allows you to configure blocks via an ajax form outside of the core block layout UI. The main difference is the context module stores the configs in actual config files while we are storing the config data in the body of the content as json.
you can see how the context module handles the bock config form here https://git.drupalcode.org/project/context/-/blob/5.x/src/Reaction/Block...
This solves my initial issue of drupal blocks config fields that use ckeditor not saving values.
This also solves the issue here ✨ Drupal block - Change and/or hide title Active because now we are including the whole block config form. It also allows other settings like items per page in views blocks and any 3rd part settings alters that were not working.
Yea, I think a modal is a better approach.
I think this needs to be handled similar to what I implemented for content blocks 🐛 Libraries attached to content block fields are not included in the editor Fixed using drupal's core ajax commands.
I will try to write a patch/MR
Also I think this is related ✨ Drupal block - Change and/or hide title Active
Tested the 3.0 version. and its working, thanks
Its worth mentioning that the issue described in #8 happens w/o this patch as well. If the block is in the sidebar.
There should be some way to block clicking on another item, or to autosave the the block if they do.
MR20 allows me to cast votes on my fields again.
I know @tr wants tests for this sort of stuff, however thats not something I know how to do. I've tried to figure it out countless times for various projects but cant seem to wrap my head around the concept of writing tests. Hopefully someone else can help out with that.
loze → created an issue. See original summary → .
+1 can someone commit this?
I understand, but thats the thing, there are no errors in my php error logs when this happens.
The error does not happen with 1.4 or 1.x-dev
Should we be making this feature for 3.x now?
It looks like 3.0 already handles free orders with a new setting for require_payment_method
to 'Collect payment methods on orders with zero balance'
This MR allows this module to work with D10 and commerce 3.0
Can someone create a release with it?
This works fairly well in many cases, however when the IEF has a media browser field in it, when you click the button to open the media browser the entity embed IEF modal is replaced with the media browser, and clicking the insert media button closes the whole modal so nothing is ever added.
Clicking a media browser button (or any for element that opens a modal) should spawn a new modal on top. Im not sure if this is something to address here or with the media module.
Can someone reroll this for 10.4.1 ?
I tested, and see the same as @smustgrave
The correct icon is used in ckeditor when editing content but it is missing on the input filter config form.
I created MR16 from the patch in #37 to help move this along.
loze → changed the visibility of the branch 2927167-autocomplete-support-does to hidden.
loze → changed the visibility of the branch 2927167-autocomplete-support-does to active.
loze → changed the visibility of the branch 2927167-autocomplete-support-does to hidden.
Tested. The patch applies and works as advertised.
+1 for this
MR125 Adds a setting in the field widget for avatar image style.
I have a working patch I will submit
Tested with alpha2 and dev and it seems to do the trick. Thanks!
Tested. That does fix the issue. no changes to realname are needed with this approach. Thanks.
Yes, MR!175 does appear to do the job with version 4.0 alpha
thanks!
Thanks. Since the original post, this module now has its own entity reference selection plugin instead of using a direct query. So I created an issue in realname to support private_message which is just a small change and it appears to be working with the 3.0 branch.
✨ Private Message module support Active