@ressa I am hoping to use the plugin architecture from this issue to start working on an ACF plugin. I'll open a issue for it sometime soon.
@tolstoydotcom I was reviewing this work since this module is failing automated D11 testing.
FYI there is a related issue 🐛 Protocol "public" not supported Active on the public protocol problem.
Your patch seems to be missing the definition of WordPressMigrationGeneratorInterface as well as a wordpress_migrate.services.yml
Created an MR for this - hopefully it's the right approach. I'm sharing a patch of the change which may be helpful for people patching.
Agree with comment #5 that the issue is around the data_fetcher_plugin. I think a good fix for this would be to correct it in each of the migrations/*.yml files which are used to make the user-generated migrations. I'm going to create a MR for this.
Re-rolling patch from #3 for 10.2.4 while work continues on this ticket.
@ji_gravityworks May be off-topic but group_content_menu has similar functionality, although a different architecture, and G2 and G3 support.
msielski → created an issue.
Reviewed the MR and tested it - fixes the problem.
To apply the diff (from the MR) with a composer install, #84 is correct you just need one more blank line of context. I'm not sure how to adjust this so it works for non-composer and composer installs, but my updated patch is attached and applies to 3.0.0. I am skipping submitting this change to the MR since it would break the patch for non-composer users. Anyone who knows the best way to handle this problem (I've seen it before with patching info.yml files) please let us know.
I updated patch #14 to address the "value should be of correct primitive type" error we were receiving. I used a solution similar to https://www.drupal.org/project/drupal/issues/2220381#comment-12771574 → , adding a massageFormValues to the widget to unset empty values. You'll still manually need to update existing DB fields to remove their NOT NULL constraints.
To use groupmenu with Group 1.x we had to patch Group to use strings as entity IDs ( https://www.drupal.org/project/group/issues/2797793#comment-14198690 ✨ Entities identified by strings as group content Closed: won't fix ). That patch no longer applies to Group 2.x, so will a version of groupmenu which works with Group 2.x require that patch?
Attaching patch I created and am testing to use recurring events with group 2.x. I believe more work will still be needed.
Looking into this I saw that config_views/src/Plugin/views/query/ConfigEntityQuery::build does not contain a few lines of code which views/src/Plugin/views/query/Sql::build contains. This missing code sets $view->build_info['query'] which is what is not set when group_views_query_alter runs. With the change in the linked MR, the reported issue seems to be fixed and can no longer be reproduced.
msielski → made their first commit to this issue’s fork.
Patch attached.
msielski → created an issue.
Debugging this today with @beeyayjay and we discovered that the problem has to do with circular dependencies in a module's configuration schema. For example the Fallback Formatter module which our site uses has the config schema:
field.formatter.settings.fallback:
type: mapping
label: 'Fallback formatter settings'
mapping:
formatters:
type: sequence
label: 'Formatters'
sequence:
- type: mapping
label: 'Formatter settings'
mapping:
status:
type: boolean
label: 'Status'
weight:
type: integer
label: 'Weight'
formatter:
type: string
label: 'Formatter'
settings:
type: field.formatter.settings.[%parent.formatter]
label: 'Settings'
And when we added some debugging output to _views_views_config_process_schema to track the config definition label as it recurses, we see a progression like:
//Block////Field formatter/Settings
//Block////Field formatter/Settings/Fallback formatter settings
//Block////Field formatter/Settings/Fallback formatter settings/Formatters
//Block////Field formatter/Settings/Fallback formatter settings/Formatters/Formatter settings
//Block////Field formatter/Settings/Fallback formatter settings/Formatters/Formatter settings/Settings
//Block////Field formatter/Settings/Fallback formatter settings/Formatters/Formatter settings/Settings/Fallback formatter settings
//Block////Field formatter/Settings/Fallback formatter settings/Formatters/Formatter settings/Settings/Fallback formatter settings/Formatters
...
Our initial proof of concept fix was to keep a history array of the config definition labels and to confirm the current label is not present before proceeding. This fixed the memory error but broke certain config from showing in views. I'm still looking into why exactly it broke, but I'd guess some config definitions are nested more than 1 cycle deep.
Our second attempt allows the label to exist once, but not twice in the history. It fixed the memory issue and we don't see any problems where we're using config_views - but our choice of allowing 2 cycles is arbitrary and I'd imagine some modules could need more. So, some refinement may be needed. Or, maybe this is just helpful to reveal the nature of the problem and will illuminate a better solution.
FWIW, modules we ran into trouble with were Fallback Formatter, and Rules. Even with the attached fix Rules still cycles hundreds of times but doesn't crash.
msielski → made their first commit to this issue’s fork.
I'm still seeing the same out of memory error with either the exclude facets patch in #16 or the by-reference changes in MR 2 / #20. Site has lots of config, and does use facets.
PHP Fatal error: Allowed memory size of 939524096 bytes exhausted (tried to allocate 24576 bytes) in /var/www/web/modules/contrib/config_views/config_views.views.inc on line 156