🇩🇪Germany @daveiano

daveiano → made their first commit to this issue’s fork.

daveiano → made their first commit to this issue’s fork.

While it works and gets the maxresdefault image for most YouTube Videos, it does not work every time. There is a chance that a video does not provide a maxresdefault image, just the default hqdefault. I guess that's something to do with the video size.

I added a check that the maxresdefault image is only used, when available. Otherwise, it will just return a 404.

Before the change, this would leave media entities without a thumbnail at all.

daveiano → made their first commit to this issue’s fork.

Hi @jonathan1055

I did the rebase locally, but Pipeline is still failing (phpcs and phpstan tasks).

The MR still needs work, especially this part causes me headaches:

$entity = $paragraph['target_id'] ? Paragraph::load($paragraph['target_id']) : Paragraph::create([
  'type' => $field_widget_complete_form["widget"][$key]["#paragraph_type"],
]);
_scheduler_entity_form_alter($subform, $form_state, '', $entity, $form_display);

Another change on scheduler_field_widget_complete_paragraphs_form_alter:

$paragraphs = $context['items']->referencedEntities(); does only get the already saved paragprahs, If you add a new paragraph to the form, _scheduler_entity_form_alter won't be called, since $paragraphs = $context['items']->referencedEntities(); only gets the already created and saved items.

I solved this (very dirty) by creating a new, temporary paragraph:

$entity = $paragraph['target_id'] ? Paragraph::load($paragraph['target_id']) : Paragraph::create([
  'type' => $field_widget_complete_form["widget"][$key]["#paragraph_type"],
]);

I updated the MR to address the issues in #22.

1. The $display from here

   if (!$display = $form_state->getFormObject()->getFormDisplay($param)) {
     return;
   }
   

   is not the actual form_display of the paragraph, it is the display of the parent node (at least when editing a page with an entity_reference_revisions field - I guess for the paragraphs library it's not the case). I solved this by getting the display from the storage in _scheduler_entity_form_alter.

2. The grouping seems not work in the context of paragraphs. For me, it was adding an empty details element with the publish_on and unpublish_on fields underneath. This could be related to 📌 Make #group FAPI / render feature work on all form/render #types out of the box Needs work . I solved this via changing the structure of the fapi elements, see https://git.drupalcode.org/issue/scheduler-3312200/-/commit/b4efce038bc1...

daveiano → made their first commit to this issue’s fork.

daveiano → made their first commit to this issue’s fork.

poker10 → credited daveiano → .

daveiano → created an issue.

daveiano → made their first commit to this issue’s fork.

daveiano → created an issue.

@dineshkumarbollu There is no mediation_graphql, the modules name is graphql_search_api_solr

daveiano → created an issue.

daveiano → created an issue.

daveiano → created an issue.

Committed and fixed, thank you very much for your contribution!

@jamsilver @Leo Pitt Sorry for the late reply. When fixing this a month ago, I did not realize there was already an issue about the problem.

Glad the fix works for you! This will be included in the next upcoming release!

pfrenssen → credited daveiano → .

Confirming that drush updb resolves the issue. I forgot to run it locally on my dev machine.

daveiano → created an issue.

daveiano → created an issue.

I just tested patch #122 with unpatched paragraphs_asymmetric_translation_widgets - it seems to work very well. Did not notice any issues yet. Will report if I spot any.

@solideogloria Is this somehow related to https://www.drupal.org/project/webform_views/issues/3068861 🐛 Webform submission view filter for multivalues Needs work ?

Just as a note: The failing export from #52 is caused because the count query never finishes. This is also the case if you use the Full Pager for the view. I am just gettings timeouts if the count query is executed.

Merged MR6 into 2.1.x.

2.1.0 will be released within the next week.

You can test the dev release with composer require 'drupal/migrate_queue_importer:2.1.x-dev@dev' ( https://www.drupal.org/project/migrate_queue_importer/releases/2.1.x-dev → )

Thanks again!

daveiano → made their first commit to this issue’s fork.

First of all, really sorry for not looking earlier into the issue!

Second, thank you all for the work put into this!

I just realized the two branches have the same changes, so the second PR (I created) should be unnecessary. I also added a new test configuration for D10 which fails on the 2.x branch (obviously), because of the conflicting dependencies ( https://www.drupal.org/pift-ci-job/2669301 → ):

Problem 1
    - drupal/migrate_tools 5.0.0 requires drupal/core ^8.8 | ^9 -> satisfiable by drupal/core[8.8.0-alpha1, ..., 8.9.x-dev, 9.0.0-alpha1, ..., 9.5.x-dev] from composer repo (https://repo.packagist.org) but drupal/core[10.0.7] from path repo (core) has higher repository priority. The packages from the higher priority repository do not match your constraint and are therefore not installable. That repository is canonical so the lower priority repo's packages are not installable. See https://getcomposer.org/repoprio for details and assistance.
    - drupal/migrate_tools[5.1.0, ..., 5.x-dev] require drupal/core ^9.1 -> satisfiable by drupal/core[9.1.0-alpha1, ..., 9.5.x-dev] from composer repo (https://repo.packagist.org) but drupal/core[10.0.7] from path repo (core) has higher repository priority. The packages from the higher priority repository do not match your constraint and are therefore not installable. That repository is canonical so the lower priority repo's packages are not installable. See https://getcomposer.org/repoprio for details and assistance.
    - drupal/migrate_queue_importer 2.x-dev is an alias of drupal/migrate_queue_importer dev-2.x and thus requires it to be installed too.
    - drupal/migrate_queue_importer dev-2.x requires drupal/migrate_tools ^5.0 -> satisfiable by drupal/migrate_tools[5.0.0, 5.1.0, 5.2.0, 5.x-dev].
    - Root composer.json requires drupal/migrate_queue_importer 2.x-dev -> satisfiable by drupal/migrate_queue_importer[2.x-dev (alias of dev-2.x)].

The test is passing now (I updated the core_version_requirement on the test module migrate_queue_importer_test) for the MR!

So yeah, the version constraints ">=5.0" allow us to publish this into the 2.x branch of MQI since this is not a breaking change, as @trackleft2 said, this allows for using migrate_tools/migrate_plus 5.x AND 6.x. Tests are now proving this!

Will merge this into the 2.x as soon as I can (probably by the end of the week). There will be a new release including this within the next week. Again, @trackleft2 and @joegraduate, thank you very much for the effort!

daveiano → made their first commit to this issue’s fork.

#49 works as expected, thank you very much!

Patch from #13 applies on 8.5 and solves the problem for me

With the patch applied, the start_time and end_time properties return at least data, in my case the following as an example (actual output is from a GraphQL request, but this should not make any difference):

"fieldWhen": [
  {
      "value": 1681115400,
      "endValue": 1681119000,
      "startTime": "2023-04-10 10:30:00 Europe/Berlin",
      "endTime": "2023-04-10 11:30:00 Europe/Berlin",
      "rrule": null,
      "rruleIndex": null,
      "timezone": "",
      "duration": 60
  }
]

Is this the intended output of start_time and end_time? Just asking, I thought this should only return the actual time, eg: 10:30:00?

@stijndmd Your last changes breaks this for me. I debugged this down and in my case

$id_map = $row->getIdMap();

always returns

{"original_hash":"","hash":"","source_row_status":1}.

track_changes is set to true for the migration. The strange behaviour is that when I check the $id_map in prepareRow the hashes are in place and working.

However, since track_changes is activated, there are only revisions created for changed rows, so I do not really get the requirement for these checks?

Using patch from #32 in the meantime.

This is already fixed on the 2.x → branch. Feel free to test it out. Or just wait until the next release is out, which should be within the next week.

Added your commit to the 2.x branch, will be included in the next release.

Thank you very much!

Run into the same problem, for me it was including a block view display inside a custom twig template, something like this:

{{ drupal_view('my_view', 'block_1') }}

The Form action was set to the views_data_export download path, not to the path of the current page.

I solved this via a simple form_alter:

function my_module_form_alter(&$form, \Drupal\Core\Form\FormStateInterface $form_state, $form_id) {
  if ($form["#id"] === 'my-exposed-form-id') {
    $form["#action"] = str_replace('/download', '', $form["#action"]);
  }
}

@tepelena You could try Autocomplete Deluxe →