Hi @jonasraoni ! 😃
I've created a PR to fix the display of series without content when creating a series-type menu item, even when there are series enabled in OMP 3.4.
I think this may also fix this fatal error, given that it is not possible to add a series-type menu item when there are no series registered in OMP.

I've checked your PR and it makes sense, I'll update and approve it.

Nevertheless, I'll leave this issue open, it might be possible to create a menu without series yet (e.g. if you create the menu before creating a series) and there's also the people who already have a bad menu on the database.

@jonasraoni I tested how it works when no series are present, and there is no option to create a series menu if no series exists, so that case already seems to be covered.

Great, so there's just one thing to fix, the existing bad records.

Thanks @YvesLepidus! Your PR is now merged to 3.4, and I can cherry-pick this to main for the 3.5 release and work on the issue with bad records.

@kaitlinnewson I was going to handle this one, but as you've self-assigned, please take a look at the The strange thing that needs to be analyzed is that a call to $navigationMenuItem->getPath() outputs Laravel code �*�escapeWhenCastingToString..

Basically, setup a bad menu, then check this line:
https://github.com/pkp/omp/blob/ef4fa4e98015d2af1f7b47dae3dad9e39198e17f/classes/services/NavigationMenuService.php#L156

If you can't reproduce, great 😂

@jonasraoni I think this is happening when Smarty is trying to convert the Collection objects into strings but failing. With the bad code, this error is logged when creating the bad series menu item:

[Fri Nov 22 10:26:35 2024] PHP Notice: html_options: value is an object of class 'Closure' without __toString() method in /Users/kaitlinnewson/Code/omp-3_4_0/lib/pkp/lib/vendor/smarty/smarty/libs/plugins/function.html_options.php on line 184

...and this is a snippet of what gets rendered in the HTML with the bad code:

<label for="seriesSelect">Select Series</label>						
<div>
<select id="relatedSeriesId" name="relatedSeriesId" required="" aria-required="true" aria-invalid="false">
    <option value="�*�escapeWhenCastingToString"></option>
</select>

... and as a result of this, �*�escapeWhenCastingToString is written to the database as the path value in navigation_menu_items, so that is what is being returned by getPath().

Is anything needed beyond removing the bad entries?

Okay, just wanted to make sure there's nothing strange under the hood 🥲

Well, I see two ways:
A. Remove the invalid entries, to honor the "required" expectation.
B. Ensure such entries are skipped/do not fail, and make the series not required.

Going further, what happens when a linked series is removed? I'm almost sure it's going to leave orphaned entries behind (which should probably be fixed as well), and I guess the same might happen with other types of menus that are linked against database entities.

I think it's better to remove them, because if they are assigned to a menu they produce a fatal error and blank white screen on the page where the menu is assigned (so they aren't usable at all).

I can test the other scenario you mentioned, and file another issue for that if I find issues with orphaned entries when a series is deleted.

(The �*� in �*�escapeWhenCastingToString is what you get when PHP serializes a private/protected attribute. Reference)

Just to confirm, I deleted a series and the menu was kept, I guess other "entity links" might have the same issue (#10633).

And I think it's worth to fix the origin of the issue (the TypeError), which can be done by coercing the getPath() calls to an integer where suitable.