Moving to RTBC as we are using 8.x-1.x-dev including this change with Drupal 10.
We have tested and are using the patch 3072676-25.patch from comment # 25.
Experiencing this issue on a Drupal 10.3.10 site. We have determined it was only happening during bot attacks, where URLs are presumably scraped and query parameters are added/removed/edited in an attempt to spider or disrupt the site. Here are steps to reproduce the issue, tested on clean builds of 10.3.10 and 11.1.3-dev:
Steps to reproduce
- Create some test articles.
- Create a new view of articles, enable the full pager and set items per page to 1.
- Enable Ajax for the view.
- Create a page display for the view at /test.
- Save the view.
- Browse to /test.
- Enable browser's network debugging tool.
- Click the second page of the view.
- Find the HTTP AJAX request, which may look like:
https://site/views/ajax?_wrapper_format=drupal_ajax&view_name=test&view_display_id=page_1&view_args=&view_path=/test&view_base_path=test&view_dom_id=a71c9a697ac4831fa5c5281c623d052920645d92a60c87b912bcdd45de69da8b&pager_element=0&page=1&_drupal_ajax=1&ajax_page_state[theme]=olivero&ajax_page_state[theme_token]=&ajax_page_state[libraries]=eJx9TluOwjAMvFDSnIGTrJxkAO-mcWSnLb39FkRAy8f-WPPyaCJfvho3hPgELkntuPWFSsi6NCrTW_GF64_9H-kiJZIeIcWwKXVe8fh2Ug6oEs5AfpFKK1-os1RvOMoy6f4ym2xQZB93H4ukd4WBNF19JVXZPtWNM5xdRXta-hgyuLPdOuYQyeCei8NY_sEnWKKGU565usWgo-yOJz7WmlsZm4XHneibbn-EWfJS8AtbJ40k - Copy this URL and delete the ajax_page_state[libraries] parameter, ending up with:
https://site/views/ajax?_wrapper_format=drupal_ajax&view_name=test&view_display_id=page_1&view_args=&view_path=/test&view_base_path=test&view_dom_id=a71c9a697ac4831fa5c5281c623d052920645d92a60c87b912bcdd45de69da8b&pager_element=0&page=1&_drupal_ajax=1&ajax_page_state[theme]=olivero&ajax_page_state[theme_token]= - Attempt to access this URL, and receive the reported error:
The website encountered an unexpected error. Try again later. TypeError: Drupal\Component\Utility\UrlHelper::uncompressQueryParameter(): Argument #1 ($compressed) must be of type string, null given, called in /var/lib/tugboat/stm/web/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php on line 50 in Drupal\Component\Utility\UrlHelper::uncompressQueryParameter() (line 103 of core/lib/Drupal/Component/Utility/UrlHelper.php). Drupal\Component\Utility\UrlHelper::uncompressQueryParameter() (Line: 50) Drupal\Core\StackMiddleware\AjaxPageState->parseAjaxPageState() (Line: 33) Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51) Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 709) Drupal\Core\DrupalKernel->handle() (Line: 19)
I think this is the same issue as https://www.drupal.org/project/drupal/issues/3120904 📌 Unset maxlength on EntityAutocomplete form element Active and the solution there, to set #maxlength to NULL, fixes it also. Attached is a patch with this change.
I needed this patch, stand-alone and against 8.x-1.5 so I'm just sharing a reroll of watergate's fix which I tested against local public:// as well as s3:// images.
Found this issue via issue #3401578. I'm not able to use the solution here because of the change from using hook_file_presave to only using a form alter. In my use case, images are created via another module (media_acquiadam, but I imagine any situation where images come in via an API would be affected), so the form alter approach gets skipped while the the hook_file_presave approach would work.
hongpong → credited msielski → .
Ah I was looking in drupalcode for the button. I see it here and pushed it. Thanks.
Something related to my own work trying to make some additional plugins. I believe we will sooner than later need a way to provide an optional UI for these plugins - for example to let users configure a destination field or to set a variety of migration options. If a plugin offers a UI then it would get inserted into the wizard process before the final step. I built this out as a proof of concept locally and am almost done.
I am basing some of the architecture on the core image module which has ImageEffect plugins which can load their own config UI. That module's approach is have a base plugin class like ImageEffectBase and then a configurable one inherited from it like ConfigurableImageEffectBase. I did the same, but ConfigurableWordpressMigrationExtensionPluginBase and ConfigurableWordpressMigrationExtensionPluginInterface are quite wordy. While I'm prepared to submit this work as a separate issue, I was wondering in this issue if we couldn't shorten the name of WordpressMigrationExtensionPlugin. I'd suggest dropping Plugin since conventionally most Drupal "plugins" don't have plugin in the class. Not a huge deal, but if I was going to ask now seems like the right time. Thank you!
Testing out the MR on this thread with Drupal 10. I ran into the following issues and hopefully fixed:
- isActive in YoastPluginExtension needs to be typed bool to match the base class.
- file_create_url is deprecated. I switched to using a FileUrlGenerator instead.
- (note file_get_contents is also deprecated but still functions, leaving it for now)
- _yoast_wpseo_title was not found in the sample export provided - may be too restrictive to assume this will be present. I changed to searching the export for _yoast_wpseo.
- I made findFieldByFieldType private since it needed a scope.
If it helps anyone, here were my test steps:
- Clone the repo for this module, fetch the MR branch, and check it out per instructions on the repo page.
- Enable wordpress_migrate and its dependencies.
- Install and enable metatag module.
- Add a metatag field to Article content type - doesn't matter the name.
- Download XML from comment #18 and use as the import.
- Choose to create Posts as Articles.
- Enable Yoast as part of the migration.
- Save, then execute the Posts migration.
- Edit the "Nulla atque tenetur repellendus ut" content and verify the description in Drupal is "the post meta description here"
I did not see Yoast meta titles in the XML so that part of the migration doesn't get tested. Also, looks like there's some extra migration for the Drupal yoast_seo module which I didn't install or test.
Finally, I'm not sure I can push my commit to the MR branch.. it says "Members who can merge are allowed to add commits." I'll throw a patch here at the least.
@tolstoydotcom, thank you, I was testing against the dev branch. Patch applied fine for me against 8.x-3.x and everything is working well on Drupal 10.3.6.
@tolstoydotcom I tried applying the patch against wordpress_migrate 3.x-dev@dev but it failed to apply. Do you have other patches applied?
Composer gives me the error:
Gathering patches for dependencies. This might take a minute.
- Installing drupal/wordpress_migrate (dev-3.x b0ebd6d): Cloning b0ebd6d586 from cache
- Applying patches for drupal/wordpress_migrate
patches/d11update-3435726-13.patch (D11)
Could not apply patch! Skipping. The error was: Cannot apply patch patches/d11update-3435726-13.patch
A src/WordPressMigrationGenerator.php.rej file was generated with the conflicts:
--- src/WordPressMigrationGenerator.php
+++ src/WordPressMigrationGenerator.php
@@ -196,12 +203,12 @@ class WordPressMigrationGenerator {
protected function createContentMigration($wordpress_type) {
$dependencies = [];
$content_id = $this->configuration['prefix'] . 'wordpress_content_' . $wordpress_type;
- $migration = static::createEntityFromPlugin('wordpress_content', $content_id);
+ $migration = $this->createEntityFromPlugin('wordpress_content', $content_id);
$migration->set('migration_group', $this->configuration['group_id']);
- $source = $migration->get('source');
+ $source = $migration->get('source');
$source['item_selector'] .= '[wp:post_type="' . $wordpress_type . '"]';
$migration->set('source', $source);
- $process = $migration->get('process');
+ $process = $migration->get('process');
// Path alias generator.
$process['path/alias'][] = [
'plugin' => 'str_replace',
@@ -224,12 +231,12 @@ class WordPressMigrationGenerator {
'replace' => '',
'regex' => TRUE,
];
- $process['uid'] = $this->uidMapping;
+ $process['uid'] = $this->uidMapping;
$process['body/format'] = [
'plugin' => 'default_value',
'default_value' => $this->configuration[$wordpress_type]['text_format'],
];
- $process['type'] = [
+ $process['type'] = [
'plugin' => 'default_value',
'default_value' => $this->configuration[$wordpress_type]['type'],
];
@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