🇺🇸United States @nadavoid

Started work in an issue fork. Here's a draft MR. https://git.drupalcode.org/project/migrate_qa/-/merge_requests/7/diffs

This fixes the config saving, but when adding files (file entities) there are sql errors that prevent the creation of trackers for the new files. I'll look into that next. This error also happens with users, but not with redirects, two other single-bundle entity types.

Thanks for reporting this. I'll look into it soon, today or tomorrow.

I applied the from comment number two, and it resolved the issue for me. Marking this RTBC, but feel free to change if there's more work to be done.

nadavoid → created an issue.

Fixed a typo: They -> The

nadavoid → created an issue.

Thanks for the quick update @guiu.rocafort.ferrer! I really appreciate it. I've successfully applied the patch from the MR on 6.0.2 and confirmed that the cursor pagination still works in my installation.

The code looks good good to me, and the tests seem comprehensive. So I'm marking this RTBC. Others who have been deeper in this issue are of course also welcome to review. I'm strongly in favor of merging soon, and if adjustments are needed or bugs are found, they can be handled in smaller followup issues.

I'm also uploading the current version of the patch so that people have something stable to use in their builds today.

The issue fork has merge conflicts against the main branch, with the recent update of migrate_plus to 6.0.2. The latest patches also no longer apply.

@guiu.rocafort.ferrer Could you merge the latest into your issue fork and resolve conflicts? I'll be happy to test after that, since I'm actively using this, and will continue to for quite a while.

I think so. I haven't tested those constraints in a .info.yml file myself, but this page → says so.

The core_version_requirement key in *.info.yml files for modules, themes, and profiles now supports semantic versioning as implemented by the Composer project.

Nice to have a single standard for version constraints!

I was able to update to Drupal core 10.2.1 combined with custom_field 2.0.0-rc6. I believe the constraint in custom_field's composer file needs to be made more strict.

Currently: "drupal/core": "^9.4 || ^10.1" allows effectively any version of 10.

Suggested: "drupal/core": "^9.4 || ~10.1.0".

The ~ "specifies a minimum version, but allows the last digit specified to go up." More details on that: https://getcomposer.org/doc/articles/versions.md#tilde-version-range-

Additionally, are there any suggestions of where to start looking to fix the issue?

I tried that change and it works great for my case. I'm posting the patch here for others who may run into the same issue and are not concerned with out these fields output in jsonapi.

It sounds like this change may affect jsonapi output, so I'll leave that to you & others to work out the more complete solution that doesn't hurt jsonapi output.

@apmsooner Thanks for the explanation and the suggestion. I'll give that a try soon.

Posting as a patch too. Originated from the issue fork: https://git.drupalcode.org/project/gathercontent/-/merge_requests/12.patch

nadavoid → created an issue. See original summary → .

nadavoid → created an issue.

Renamed patch

Patch created by @JSchref, US-specific.

Commenting with what I understand to be the purpose of some of the pager options for the JSON plugin.

selector: The path to the JSON item identifying the next page.

type

• urls: selector points to one or more URLs.
• cursor: selector is just a portion of the next page URL. Set `key` to the URL parameter key that should be passed.
• page: selector is a current page number, and expected to increment: 1, 2, 3, etc.
• paginator: not sure

key: Parameter key in the URL, will be given a value that identifies the page to request. If key is set to "page", then the resulting generated URL will contain "?page=[value-from-current-json]"

More parameters to document:

size_key
page_key
selector_max
default_num_items
paginator_type

Updating issue summary.

Is there a way to use this patch for the paging scenario I have? The things in particular that I'm not sure how to solve:

1. The token for the next page is unpredictable; it needs to be read from the current page
2. The identifier for the next page is only a token, not a full URL

My JSON source has this structure:

{
  "response": {
    "docs": [
      {"one", "two", "three"}
    ]
  },
  "count": "329",
  "nextPageToken": "qwk9"
}

The URL of the next page is the same as the current page, with the change of a URL param: &pageToken=qwk9

I'm thinking that I'll need to update the patch or extend it using custom code, but wanted to check here first. If updating the patch is there an existing pager type that would be best to model this on? These are the pager types that I see recognized in the patch so far:

• urls
• cursor
• page
• paginator

nadavoid → created an issue.

nadavoid → created an issue.

I hadn't enabled the essential module, gathercontent_ui, and so was mistakenly using gathercontent_upload_ui. Using the regular mapping UI, I am able to create mapping and then import content after that.

With the error starting from the generateMapping() function, I'm looking at it and trying to understand what it does. It looks like it's trying to create a template at gathercontent, using a POST at https://api.gathercontent.com/projects/123456/templates. Is that correct and expected? I would expect that it would only read data from gathercontent and create mappings in Drupal, but I'm just learning how this integration and service works.

I am also chatting with support at gathercontent to find out if there is something on their end that can resolve this.

nadavoid → created an issue.

Module has been updated for Drupal 10 compatibility in ✨ Support Drupal 10 Fixed

Thanks for the update Chris! I've applied the patch and will make a new release today.