🇺🇸United States @pixlkat

After some further investigation, I believe https://www.drupal.org/node/3409364 → could be behind what I was seeing. Once I upgraded to the latest version of the Field Permissions module, the behavior I was experiencing above (including the format of allowed values I was seeing in xdebug) is no longer present. I can no longer reproduce this issue.

Drupal 10.2.4. I have a list field where all the values are present in the database. I am trying to simply update the label on one of the allowed values and receive the error. I am not trying to change the keys, only the display text, which should be possible.

benjifisher → credited pixlkat → .

benjifisher → credited pixlkat → .

benjifisher → credited pixlkat → .

And, I take that back. Our stage environment is running Drupal 10.1.6. We have received no reports of this happening on production, but load is probably pretty low right now.

While running a drush command that did a lot of content updates in the background, I logged in to our stage environment as a user with admin role and had the block that contained a view missing. My assumption is that the drush command was using enough resources to slow down the return of the page. See the attached screenshot for the markup from using the browser inspector. The bib pipe placeholder span is where a view should appear.

@catch, I am on 10.1.6 now. We have not seen the issue since updating core. Sorry if that wasn't clear previously. You'd asked for confirmation if when I was seeing it, I saw unreplaced big pipe placeholders, and I did.

Hi, I should have included a screenshot of the markup when I added my other screenshots. When my blocks were missing, there were big pipe placeholders appearing where the block should have been (it's how I found this issue).

I don't have an environment running right now that I can use to reproduce, and I'm in the middle of prepping for a new production release. I'll go back to 10.1.5 when I have a moment and get a screenshot for you.

@wim, I had to point that fact about the delay still happening to my end users, until we upgraded to D10, the page would take a long time to load, so I don't know if/how big pipe was actually working then. We have always had it enabled.

I'm attaching two screenshots from our production environment where we have not upgraded yet. Two blocks were missing in this case, one is a graph that should not be a very large payload, the other is a block with a view that should also not have a large payload, but may have some views interaction with the group module.

Timing from dev tools:

List of JS files received with size:

We were seeing missing blocks after we updated to D10 (10.1.5) for some roles. We have several blocks that have complicated processing and interactions with the group module for access.

I updated to 10.1.6 and we are not seeing the issue now. We still see a noticeable lag between initial page load and all the page elements appearing, but they all show up now. Our site is 100% authorized users -- none of the blocks are LARGE, but it appeared whatever is taking longer with processing was causing the problem.

benjifisher → credited pixlkat → .

@benjifisher I guess I didn't set this back to needs review. Doing that here.

smustgrave → credited pixlkat → .

benjifisher → credited pixlkat → .

JoiGarrett → credited pixlkat → .

JoiGarrett → credited pixlkat → .

JoiGarrett → credited pixlkat → .

JoiGarrett → credited pixlkat → .

JoiGarrett → credited pixlkat → .

JoiGarrett → credited pixlkat → .

I installed the MR version of migrate_plus using the instructions above on a vanilla D10 site with the minimal profile and created a test content type to use as the destination for the test migration.

I created module with a simple migration using a sample JSON file source (attached) and was successful in using a selector to limit the items which were migrated. The JSON contains an attribute named "favoriteFruit"; the item_selector in the migration selects those with favoriteFruit=strawberry. My migration only imported the items with the matching selector with no errors.

My simple migration:

id: test_data
label: Migrate Test Data

source:
  plugin: url
  data_fetcher_plugin: file
  data_parser_plugin: jsonpath
  urls:
    - modules/custom/migration_test/data/people.json

  item_selector: '$.people[?(@.favoriteFruit=strawberry)]'

  fields:
    -
      name: guid
      label: 'GUID'
      selector: guid
    -
      name: name
      label: 'Person name'
      selector: name
    -
      name: age
      label: 'Age'
      selector: age
    -
      name: gender
      label: 'Gender'
      selector: gender
    -
      name: company
      label: 'Company'
      selector: company
    -
      name: about
      label: 'About'
      selector: about
    -
      name: favorite_fruit
      label: 'Favorite Fruit'
      selector: favoriteFruit

  ids:
    guid:
      type: string

process:
  type:
    plugin: default_value
    default_value: people
  title: name
  field_age: age
  field_gender: gender
  field_company: company
  body/value: about
  body/format:
    plugin: default_value
    default_value: plain_text
  field_favorite_fruit: favorite_fruit

destination:
  plugin: 'entity:node'

migration_dependencies: { }
dependencies:
  enforced:
    module:
      - migration_test