Should this new class extend the current JSON class instead of DataParserPluginBase? I did some quick testing and it seems this new plugin doesn't support the pager enhancements as it doesn't implement getNextUrls()?
Break the JS into components: @todo a proposal of specific steps and issues
By "components" are we talking Web Component custom elements, or just breaking the functionality up by SDC component?
I'd be a fan of exploring the first option as it would also allow some style encapsulation. I've started playing around with writing my front end themes with more a CUBE CSS (https://cube.fyi/) approach, but I find that often leads to conflicts with admin elements, so having admin elements outside the frontend css with Shadow DOM could be a nice win.
Am getting the same on the JSONAPI route, and a similar but slightly different error on REST endpoint settings.
e.g. admin/config/services/rest/resource/rest_menu_item/edit
gives
> Error: Cannot use object of type Drupal\Core\StringTranslation\TranslatableMarkup as array in Drupal\config_readonly\EventSubscriber\ReadOnlyFormSubscriber->getConfigTargetNames() (line 166 of modules/contrib/config_readonly/src/EventSubscriber/ReadOnlyFormSubscriber.php).
pameeela → credited Jon Nunan → .
Jon Nunan → created an issue.
After some debugging I found:
https://api.drupal.org/api/drupal/includes%21entity.inc/function/DrupalD...
You'll see when building the query it grabs a list of fields from:
$entity_fields = $this->entityInfo['schema_fields_sql']['base table'];
For whatever reason, the values in 'schema_fields_sql' do not include the bundle field. So when the file entity is loaded via that controller it will be missing its bundle and trip up entity_extract_ids().
I think the issue is hook_schema_alter(); should that be in .install or should it be in .module?
When debugging and clearing cache, I don't hit a breakpoint I place inside `file_entity_schema_alter()` in its current location in the `.install` file. I think that hook only gets picked up if its in the module file? I tried moving the hook to the .module file, and while I now hit the breakpoint I cache clear the issue still remains.
I found I could fix the issue by just hardcoding the bundle field in the entity_info_alter() but this feels like a hack and there is something else I'm missing
function file_entity_entity_info_alter(&$entity_info) {
$entity_info['file']['fieldable'] = TRUE;
$entity_info['file']['entity keys']['bundle'] = 'type';
$entity_info['file']['bundle keys']['bundle'] = 'type';
$entity_info['file']['schema_fields_sql']['base table'][] = 'type';
Jon Nunan → created an issue.
Patch for the above attached
Patch attached fixes the issue for me,
With live preview on, the "add media" fields from media_library_form_element were the "values" for the background media image & video fields. So have added a $form_state->cleanValues(); call to remove them before processing the values further.
Have also cleaned up some logic around the value being in `media_library_selection` in some cases.
Yeah sorry, should have specified, this is when using a drupal/bootstrap5 generated subtheme.
Have checked `views-mini-pager.html.twig` and I don't see anything wrong. Just seems to be some whitespace differences and a couple extra classes.
I'm hitting this too.
I think I've found the issue, for a new section, submitStyleFormElements is adding `media_id` while the group_elements array for it is some form elements to select an image, and not a raw media_id like I think the code is expecting?