Array to string conversion error when relating entries from Pages collection

[mgtcampbell]

Hi there,

I'm getting an error whenever I try and relate entries specifically from the Pages collection.

[2021-09-30 06:10:23] local.ERROR: Array to string conversion {"userId":"e8ffc1e8-100f-4c68-a6c5-d93b56f82435","exception":"[object] (ErrorException(code: 0): Array to string conversion at ....../vendor/statamic/cms/src/Fieldtypes/Text.php:87)

I've encountered this in two situations:

1. When using an entries field within a page to link to other pages. Interestingly this was "resolved" once I removed the restriction to only show the Pages collection for entries to relate to on this field. Not sure if that helps identify the issue.
2. When creating a new Navigation and linking it to the Pages collection

In both cases, everything is seemingly working until I click on the action that triggers the modal to select the entry(ies) - see screenshot below.

I realise that this may be due to some error within my content yaml files... if that's the likely cause, is there any way to narrow it down, since there's a fair bit of content already in the site to sift through.

For example:

• Does the error indicate that I have something that looks like an array in a field with input_type: text?
• Since this only happens when "looping" over the pages collection for relating entries, does that narrow down the fields being accessed, and therefore the fields I need to investigate?
• The last comment on this older thread for a similar issue referenced an issue with bard fields labelled as content - https://statamic.com/forum/370-array-to-string-conversion-when-creating - of which I have a few but I'm guessing this shouldn't be an issue?

Thanks for any suggestions!

[edalzell]

I realise that this may be due to some error within my content yaml files... if that's the likely cause, is there any way to narrow it down, since there's a fair bit of content already in the site to sift through.

Yes, start removing content until it works, then continue to narrow it down to find the content causing the problem. Then we can dig into that.

[jasonvarga]

Interestingly this was "resolved" once I removed the restriction to only show the Pages collection for entries to relate to on this field.

My hunch is that you have a similar named field in both collections but they use different fieldtypes.
e.g. content in one collection is bard, but is markdown in the other.

You could resolve that by using consistent fieldtypes, or changing the field name of one of them.

[mgtcampbell]

Thanks @jasonvarga and @edalzell

Using your suggestions I was able to narrow it down and find the issue.

Basically I had a heading field as part of the page's Blueprint which was a bard, and then within a replicator I was linking in a range of Fieldsets - some of which also had a heading field that was sometimes a simple text field.

I solved this for now by renaming the handle of the field in the main Blueprint to main_heading.... what is kind of interesting is there are still multiple heading fields within the content of both fieldtypes pulled in through the replicator field, but it no longer throws the error when relating a page to another page via the Entries field.

I did generally set up this pattern with some intention:

• Using consistent field names just makes the scaffolding of my antlers files easier... e.g. I can duplicate an existing partial for a section and know that the heading, content, label fields etc are generally going to be part of the content pattern so I don't need to change them
• In some parts of the design this heading should allow some basic styling - e.g. the ability to bold, italicise or underline individual words (hence a bard is the right field type), whereas in other parts of the design the styling of the heading is more "fixed", and we don't want to allow the content editor the ability to add text styles - hence making these straight up text fields

While it's not that hard to adjust field names as you go - or alternatively I could make the text inputs bard fields with no styling options - I am interested to understand a bit more about the issue... mainly in that it wasn't throwing an error at any point for the following:

• Editing and publishing the page
• Viewing the list of pages in the collection, and changing and saving the pages collection tree
• Outputting all the content on the front end through the antlers templates

So I'm just curious as to why this was only throwing an error when I tried to associate one page to another via the Entries field type?

All good if it is just the way it is - I'm just curious and it might help me design better content patterns going forward.

[jasonvarga]

It was only an issue in that scenario because the listing was combining fields across blueprints.

In listings, we "preprocess" the values to get it ready to be shown in a listing.

If you were applying the bard preprocessing rules (which expects an array) to a text field (which is a string) it'd throw an error.
When it's only going to be using a single blueprint (like entries in a single collection, or on the publish page for an entry), it's fine.

[mgtcampbell]

Thanks @jasonvarga - really appreciate you giving an explanation.