EE4 Template Parsing Issue
Development and Programming
I’m experiencing some strange behavior with matrix fields that have a file cell. I have a pretty simple template that was originally written for our site in EE3 and we are in the midst of trying to migrate everything to EE4. Right after migrating, it seems that the template no longer renders correctly.
Here is a very simplified version of the template:
{exp:channel:entries status="not closed" limit="1" }
{page-content}
{if page-files:total_rows > 0}
{page-files}
{if row_count == 1}<h4>Files</h4>{/if}
{if pf-url}
<a href="http://{pf-url}">{pf-text}</a>
{/if}
{/page-files}
{/if}
{/exp:channel:entries}There is a wygwam field is named page-content and the matrix field is named page-files. It has two columns, pf-text (a regular text cell) and pf-url (a file cell), for the link text and the desired file.
This is the behavior I’m seeing: if I try to load this template right now, the page-content is not shown and only the link from inside page-files is shown.
Drilling down more, if I replace the line with anchor tag with just “{pf-text}”, the wygwam field and the link text display as expected. But then if I instead replace that line with “{pf-url}”, the contents of the wygwam field are again not displayed at all and only the path to the file is shown.
I’ve done a little digging and it looks like as the the template is parsed, the data for the page-content field is present when the pf-url field is not parsed but blank when it is.
Has anyone seen this behavior before? Are there any configuration settings I should check? This template is our basic one used for most site pages so we are eager to get to the bottom of this issue.
I’m using EE 4.3.2, Matrix 3.1.4, and Wygwam 4.1.14.
I’ve done some more digging and it looks like the SQL statement used to get the entry data changes when this field is present or not. This SQL query is created inside the entries() method in the system/ee/EllisLab/Addons/channel/mod.channel.php file. Any idea why this might be happening?
Have you checked with the developer of that add-on? Not sure why there’d be a relationship between a Wygwam field and a Matrix field, but perhaps EE Harbor can shed some light for you.
Yes, I’ve checked with EE harbor and they hadn’t seen this issue before either.
I’ve been adding log items to the template debugger and I wonder now if it’s a SQL issue.
Inside of the entries() method I mentioned earlier, I can log $this->sql before line 264 to see the statement it is using to get the entry data. Then when parse_channel_entries() is called, I can add a log statement to show the data inside of $query_result (after line 2740). The data in $query_result is different than what I see if I just copy and paste the SQL statement into phpMyAdmin. I didn’t compare every field, but the specific field used for this Wygwam field is displayed with a null value in $query_result but does show up with the correct value in phpMyAdmin.
Any idea why this might be?
$query_result isn’t a simple SQL result, as other data needs to be inserted, handled, modified, and made modifiable by third-party extensions, so I would expect that there would be some differences.
Are you able to replicate this behavior with first-party fields in an unmodified install?
Hmmm it looks like it’s just something with this particular wygwam field. I remade the set up with a Rich Text Editor field & Grid field and it worked, I switched the RTE field to wygwam and it still worked, and I used the new wygwam field with the old matrix field and it also still worked. I don’t know what is wrong with the original wygwam field but I’ll just port over the content to this new field and call it a day. Thanks for your help!
Well that’s curious. Might be a red herring, but the field that did not work, was it set to be searchable?
Yes it was in fact and the new one wasn’t. I just tried switching that setting for both fields and still got the same result: the old field won’t display correctly when searchable is turned off and the new one still will display with search turned on.
Alrighty thanks for double checking and glad the new fields are working!