Configuration schema for "Enable extra settings" (title,pagination,...) incorrect

A created a path for this issue.

changed it to string:

For people looking for a fix to the "display title" option, this patch here makes that option work again.

As hudri said, the patch fixes an issue we're having with using these options on our sites.

I can confirm that before applying the patch from #4 the options 'limit', 'offset' and 'title' could not be enabled (their values in the config were set to 0) and after applying this patch they can be enabled (again).

Confirm #4 fixes my issue too!

Hi, guys!
Shouldn't there be some update function to make those changes applicable to the current users?

Due this bug it is not possible to activate those options, so I don't think an update hook could reliably fix this.

Add one more RBTC for me: patch #4 is simple but does the trick.

You do have to go back and re-set views reference fields that were changed by this issue (created or edited after upgrade to beta 7), and that's likely going to be a case-by-case process, so it doesn't seem suitable for an update hook.

Ass the patch stands, it leaves cruft in the configuration schema. The way the schema was developed, they were adding a separate entry for each plugin. Obviously that's no longer correct, so lets do the type string sequence AND remove the definitions for the individual settings.

Patch #14 doesn't change the config output in my case (no cruft for us) but it continues to work for me. Changing back to RBTC.

For reference, the schema doesn't control what's exported in config management explicitly, it just tells config management what to expect in the config.yml files. In this case, since the last patch did this:

       type: sequence
       label: 'Enabled settings'
       sequence:
-        type: viewsreference.enabled_settings.[%key]
+        type: string

That means that viewsreference.enabled_settings.[%key] is no longer used, therefore the entries in the schema that were created for this are no longer needed, therefore my addition of

@@ -54,26 +54,6 @@ field.value.viewsreference:
       type: string
       label: 'Serialized data'
 
-viewsreference.enabled_settings.argument:
-  type: string
-  label: 'Argument settings'
-
-viewsreference.enabled_settings.limit:
-  type: integer
-  label: 'Limit results settings'
-
-viewsreference.enabled_settings.offset:
-  type: integer
-  label: 'Offset results settings'
-
-viewsreference.enabled_settings.pager:
-  type: string
-  label: 'Pagination settings'
-
-viewsreference.enabled_settings.title:
-  type: boolean
-  label: 'Include View Title settings'
-
 viewsreference.plugin_types:
   type: sequence
   label: 'View display plugins to allow'

to the patch. It's simply to clean up unused links in the configuration schema that are now unused.

Thanks, @generalredneck! I wasn't 100% certain whether or not your removal of those entries would have impacts to users' configurations too, whether exported before or after the update that broke things.

Also, it gave me the chance to confirm that the updated patch had been reviewed and tested good enough for my purposes!

patch #14 fixes my issue thanks !

For me, this patch was not working until I manually edited my config file and reimported. Example below:

field.field.paragraph.events.field_event_list.yml:
(For your own field, you will have to find the "field.field.[entity].field_name" that's relevant to you)
(this is just the last 15 or so lines of the file)

...
settings:
  handler: 'default:view'
  handler_settings:
    target_bundles: null
    auto_create: false
  plugin_types:
    block: block
  preselect_views: {  }
  enabled_settings:
    limit: limit
    offset: offset
    title: title
    pager: pager
    argument: argument
field_type: viewsreference

...where the old incorrect values were:

  enabled_settings:
    limit: 1
    offset: 1
    title: true
    pager: pager
    argument: argument

Thanks all! Committed the latest patch.

Should I use the dev version to get the update or will there Beta8 release soon? Thanks everyone!

+1 for a new beta release :)

So we need to reiterate in the release notes that there are manual steps to remediation.

Comments #11-13 and #19 are all talking about it.

As said in #13, an upgrade hook is impossible because the configuration has been polluted/changed by the last release so there is no feasible way to identify who had what checked prior.

Reconfiguration of the module is the only valid step forward.

I don't quite understand, why an update hook is not feasible here?

Before, an entry of "enabled_settings" could either be a string, a boolean or an integer. Meaning we could simply do an empty check on each "enabled_settings" entry and if it is empty, we unset it (just like fieldSettingsFormValidate() does it through the UI) and if it isn't, we simply replace the value with its key, done.

I'll prepare a follow-up issue for that.

PS: If you are talking about the config "pollution" through 🐛 Update viewsreference_update_8103 fails if table name is too long and shortened by Drupal Fixed , that could be fixed in the same issue and everyone is happy! :)

Create a follow-up issue here: 🐛 Add missing update hook for adjusting viewsreference field settings RTBC .

Alright, done.

Everyone in need of an update hook for this, please test and checkout the patch here from 🐛 Add missing update hook for adjusting viewsreference field settings RTBC !

Grevil,

I see where you are coming from. Most of us who have experianced this tried to use the configuration form after the bug. This essentially wiped the configuration.

Obviously I hadn't thought of those who still have configuration intact... say upgrading form beta6 to -dev

Automatically closed - issue fixed for 2 weeks with no activity.