After updating a Drupal installation from 8.2.x to 8.3.x, I cannot save some views. I might be wrong but I think this might have sth. to do with the fact, that these views contain two filters on the same field/property - one of them appended with "_2".
The error message is:
InvalidArgumentException: The configuration property display.default.display_options.filters.type_2.value.page doesn't exist. in Drupal\Core\Config\Schema\ArrayElement->get() (line 74 of core/lib/Drupal/Core/Config/Schema/ArrayElement.php).
Drupal\Core\Config\StorableConfigBase->castValue('display.default.display_options.filters.type_2.value.page', 'page') (Line: 211)
Drupal\Core\Config\StorableConfigBase->castValue('display.default.display_options.filters.type_2.value', Array) (Line: 211)
Drupal\Core\Config\StorableConfigBase->castValue('display.default.display_options.filters.type_2', Array) (Line: 211)
Drupal\Core\Config\StorableConfigBase->castValue('display.default.display_options.filters', Array) (Line: 211)
Drupal\Core\Config\StorableConfigBase->castValue('display.default.display_options', Array) (Line: 211)
Drupal\Core\Config\StorableConfigBase->castValue('display.default', Array) (Line: 211)
Drupal\Core\Config\StorableConfigBase->castValue('display', Array) (Line: 212)
Drupal\Core\Config\Config->save() (Line: 280)
Drupal\Core\Config\Entity\ConfigEntityStorage->doSave('search', Object) (Line: 392)
Drupal\Core\Entity\EntityStorageBase->save(Object) (Line: 259)
Drupal\Core\Config\Entity\ConfigEntityStorage->save(Object) (Line: 364)
Drupal\Core\Entity\Entity->save() (Line: 637)
Drupal\Core\Config\Entity\ConfigEntityBase->save() (Line: 986)
Drupal\views_ui\ViewUI->save() (Line: 321)
Drupal\views_ui\ViewEditForm->save(Array, Object)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 51)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 585)
Drupal\Core\Form\FormBuilder->processForm('view_edit_form', Array, Object) (Line: 314)
Drupal\Core\Form\FormBuilder->buildForm('view_edit_form', Object) (Line: 48)
Drupal\Core\Entity\EntityFormBuilder->getForm(Object, 'edit', Array) (Line: 226)
Drupal\views_ui\Controller\ViewsUIController->edit(Object, NULL)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 574)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
call_user_func_array(Object, Array) (Line: 144)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 64)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 170)
Drupal\drupalx\HttpReroutingMiddleware->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 656)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
and here is an export of the view:
uuid: b6754b60-6227-41eb-9269-8859e113c25c
langcode: de
status: true
dependencies:
config:
- search_api.index.default
module:
- search_api
id: search
label: Suche
module: views
description: ''
tag: ''
base_table: search_api_index_default
base_field: nid
core: 8.x
display:
default:
display_options:
filters:
search_api_fulltext:
exposed: true
expose:
identifier: search
required: true
id: search_api_fulltext
field: search_api_fulltext
table: search_api_index_default
type_2:
exposed: false
value:
page: page
faq: faq
glossary: glossary
id: type
field: type
table: search_api_index_default
type:
exposed: true
expose:
identifier: type
multiple: true
reduce: true
value:
page: page
faq: faq
glossary: glossary
id: type
field: type
table: search_api_index_default
field_search_exclude:
operator: empty
id: field_search_exclude
field: field_search_exclude
table: search_api_index_default
search_api_language:
value:
'***LANGUAGE_language_content***': '***LANGUAGE_language_content***'
id: search_api_language
field: search_api_language
table: search_api_index_default
fields:
nid:
exclude: true
id: nid
field: nid
table: search_api_datasource_default_entity_node
type:
label: ''
field_rendering: 0
settings:
link: 0
fallback_options:
display_methods:
node_type:
display_method: id
id: type
field: type
table: search_api_datasource_default_entity_node
title:
label: ''
settings:
link_to_entity: 1
id: title
field: title
table: search_api_index_default
search_api_excerpt:
label: ''
id: search_api_excerpt
field: search_api_excerpt
table: search_api_index_default
sorts:
type_sort_index:
id: type_sort_index
field: type_sort_index
table: search_api_index_default
search_api_relevance:
order: DESC
id: search_api_relevance
field: search_api_relevance
table: search_api_index_default
cache:
type: none
pager:
type: full
options:
tags:
first: '|<'
previous: '<'
next: '>'
last: '>|'
exposed_form:
options:
submit_button: Filter
rendering_language: '***LANGUAGE_language_content***'
display_extenders: { }
display_plugin: default
id: default
display_title: Master
position: 0
cache_metadata:
max-age: 0
contexts:
- 'languages:language_content'
- 'languages:language_interface'
- url.query_args
tags: { }
Comments
Comment #2
lendude@rgpublic just wondering, if you take the filter with machine name type_2 out, does saving it work Or is it only showing the first error and does it then fail on a second config problem for the filter with machine name type?
Comment #3
benjy commentedI had the exact same issue, I removed the filter, saved fine, added the filter back and then everything worked as expected.
Comment #4
idiaz.ronceroHi!
I'm suddenly getting the same error, except in my case there is no duplicate (_2) filter and the problem seems to only affect Taxonomy Term-related filters
"The configuration property display.default.display_options.filters.field_secciones_target_id.value.52 doesn't exist. in Drupal\Core\Config\Schema\ArrayElement->get() (line 74 of core/lib/Drupal/Core/Config/Schema/ArrayElement.php)."
(field_secciones is a term reference field, I also tried generic "has taxonomy term" filters to no avail)
View output preview works, the error throws when hitting 'save'... as a result, there is no way views can be saved...
I also tried to create a new view from scratch. It breaks whenever I try to add a term-based filter.
I'm sorry I can't tell if this happened on update to 8.3.2 or 8.3.1, I didn't had to alter/create any view during this time...
Comment #5
lendudeI would love to help out here but we need some steps to reproduce on plain D8. The view in the IS is a search API view (base_table: search_api_index_default), so that is far from plain D8.
I just tried:
- Add a term reference field to a node type
- Create a content view
- Add a filter to the view for the term reference
- Select dropdown
- Select one term and operator 'is one of'
- Apply the filter
- Save the view
- See 'The view Tags has been saved.'
- Add a second filter for the same field
- Apply the filter
- Save the view
- See 'The view Tags has been saved.'
Without some steps to reproduce, this is hard to fix.
Comment #6
idiaz.ronceroHi Lendude, many thanks for your help... I know a clean Drupal install doesn't shows this issue, I already tried, and I know this makes it really hard to reproduce.
However, on already running Drupal installs seems that I am not the only one experiencing this issue (see comments #202 and #210 on https://www.drupal.org/node/2369119, they report exactly the same behavior and are a few days old)
I have been hours trying to figure it out, but I'm clueless... to makes things worse, since I didn't had to update any views for a time, I don't know where or when exactly did it broke...
Here are some things I tried:
- Try all filters other than term-related ones. Everything else works fine.
- Disable all non-core modules that may interfere with the process, namely shs and views_taxonomy_term_name_depth. Nope...
- Disable "config" core module. Just trying... no.
- Try creating a brand-new term reference for a brand-new term in a brand-new vocabulary within a brand-new content type and make the simplest of views filtered by term. Nada...
My Drupal install has been running since 8.1.x, so I am really worried, a ton of work could be lost if I don't get to solve this... So many changes, lots of views, etc... I am an experienced drupal user but not a developer, so I could be easily missing something. Any help or ideas are welcome...
BTW, should I create a separate issue for this?
Comment #7
idiaz.ronceroOK, solved...
TL, DR: SHS seems currently incompatible with term filtering on views, even if shs is not selected as the way of filtering terms.
I don't know how but shs module really messed it up...
When I tried uninstalling shs, it automatically deleted all views with any term filtering independently of the chosen method of filtering. Even if it was "dropdown" or "autocomplete", shs deleted the view.
This led me to think shs had some role on the error. I deleted all term filterings, uninstalled shs, re-added the filters and they worked!
This bug is non-obvious, so I post here my findings in case somebody needs this info. I will create an issue on shs' project page also.
Comment #8
lendude@idiaz.roncero thanks for digging and reporting back your findings!
Leaving this open for now, but it seems that these issue all originate from outside core.
Comment #9
rgpublicFinally, I managed to get back to this. I could find the reason why my view wasnt saved: It was created programatically and was missing the "plugin_id" property. Deleting the field and creating it in the UI did indeed solve the problem. Thanks a lot @Landude. It brought me on the right track. If someone else encounters this problem: Please make sure that you really have all necessary properties when creating the view programatically. You might want to create it in the UI and check/compare the properties from there.
As far as I can tell, the problem was/is this: Drupal 8.3.x (in contrast to 8.2.x) doesnt as easily accept invalid configurations (stuff that dont exist) when you try to save the view. Drupal 8.2.x. happily accept anything you could possible stuff into the associative array. In this specific case with the Search API, the type field needs a plugin_id. Because a base_table, field etc had been defined it did in fact work in 8.2.x without the "plugin_id". It isnt really *used* for anything. But without it, Drupal 8.3.x now seems to be incapable of determining all allowed configuration properties and is blocking the save because it thinks there might be sth. in there which isnt valid.
So, the original issue why I filed this specific bug report is solved. I'll leave it open because some additional discussion seems to have evolved here. But feel free to close it if no one else opposes.
Comment #10
lendude@rgpublic thanks for reporting back your findings.
I'll close the issue now. I think that as a general rule we can conclude that these errors are usually raised by invalid config, and that you might get away with that in 8.2, but not 8.3.
Comment #11
Anonymous (not verified) commentedHi, I was also getting the same error as #7 and it seems to be caused by SHS (Simple Hierarchical Select). After uninstalling that module, the views saved and worked correctly. I'm using 8.3.4 and didn't notice any problems before updating to 8.3. I have opened a bug on SHS https://www.drupal.org/node/2890274. Just putting this here in case others are having similar problems.