🇦🇺Australia @kenwest

kenwest → created an issue.

Added another commit to MR 16. Rss::buildOptionsForm() - not all $form elements have a '#type' so allow for that.

I've created an issue fork. MR 16 fixes the warning generated when viewing a podcast that has not yet had any Podcasting 2.0 elements defined

1. podcast_process_nested_channel_element() may receive a $value without an 'attributes' element
2. Harden podcast_process_nested_channel_element() to receive a $value without a 'value' element (unlikely but why not?)
3. Add podcast:funding_text_field to the options array
4. In the $form 'podcast:value_type_field' et al are nested under 'podcast:payments' but they aren't nested in $this->options
5. The podcast:season, podcast:episode, podcast:soundbite_start, podcast:soundbite_description, podcast:soundbite_duration and podcast:person may not be set. Prevent PHP throwing warnings by testing the result of buildElementFromOptions(). Note that buildElementFromOptions() returns an array with 'key' and 'value' elements - or an empty array is there is no element.
6. Also fixed typos - itunes:season and itunes:episode

Inspecting @scampbell1's patch I see a few issues where the fixes perhaps go too far?

1. podcast.module
1. Adding the test if (isset( $value['value'])) prevents $out being set. The existing test should be modified to if ($content = $value['value'] ?? "")
2. src/Plugin/views/row/RssFields.php
1. When adding a podcast:soundbite element, the code already skips that step when $soundbite_start is null. Setting it to "" circumvents that test and causes a podcast:soundbite element to be added to the podcast

The steps to fix this are ...

1. composer require 'drupal/term_reference_change:^2.0@beta'
2. composer require 'drupal/term_merge:^2.0@beta'
3. drush install term_reference_change term_merge

There is no need to set "minimum-stability" to "beta" in your composer.json. I leave mine at "stable" so I can require stable components by default and am able to get beta etc versions when I need to.

kenwest → created an issue.

Previous patch was bad. Trying again

Attached a patch to override the CSS changes made by Claro

Note that there are some behavioural changes between 2.0.6 and 2.0.7 in Claro ...

1. Choosing a placement option "Auto" for a tip will obscure the selected element. The data-popper-placement is "auto" rather than (say) "right".
2. The placement of the shepherd-arrow DIV is outside the shepherd-element. When I set the placement option to "Right" the shepherd arow is about 10 pixels to the left of the shepherd-element

Clarifying issue's title, how to reproduce, and proposed resolution

I'm using the Claro theme, which includes a CSS file core/themes/claro/css/theme/tour.theme.css

I assume that CSS is intended for the now-deprecated core Tour module?

I'm continuing to experience this issue with 2.0.7.

Here is an excerpt from the YML for my tour ...

id: add_or_edit_a_blog
label: 'Add or edit a Blog'
routes:
  -
    route_name: node.add
    route_params:
      node_type: blog
  -
    route_name: entity.node.edit_form
    route_params:
      bundle: blog

For the node.add route, the tour button says "Tour" when I'm adding a Blog, and clicking it starts the add_or_edit_a_blog tour

For the entity.node.edit_form route, the tour button says "No Tour" when I'm editing a Blog, but clicking it starts the add_or_edit_a_blog tour

kenwest → created an issue.

kenwest → created an issue.

I was testing 2.0.6 but I've downloaded 2.0.x and the same issue presents.

Hi, I had a similar issue that was marked as a duplicate of this one. I did some debugging, so I'm copying that here in case it helps shed light on this issue. My issue is that when the route is 'entity.node.edit_form' the 'bundle' parameter is both used and ignored. Looking at the code for Tour 2.0.6 ...

* The 'entity.node.edit_form' route has a parameter 'node' that is the Node entity being edited
* tour_page_bottom() discovers this at line 167 of tour.module and sets $params['bundle'] to the node's bundle. This allows the route to be matched so the tour can be added to $page_bottom. This explains why the tour is available when the toolbar button is clicked.
* On the other hand, tour_toolbar() only looks at the 'node' parameter's id() on line 94, so $no_tips is set TRUE. Then when the button is rendered LazyBuilders::renderTour() sets the text to "No tour".

My suggestion is that tour_page_bottom() and tour_toolbar() use the same code. Even better, the first function to be called should stash its results so we only need to do one entityQuery('tour'). If this is a helpful way forward I can contribute a patch.

Yes, I looked at that issue. It refers to a problem on the node.add route but that works fine for me - the problem I have is with entity.node.edit_form. My issue is with how bundles are treated.

kenwest → created an issue.

I had this issue and found that the patch #13 for https://www.drupal.org/project/location_migration/issues/3192657 → fixed it

kenwest → created an issue.