BoldMinded

Publisher does not support the Fluid field type. Please do not contact asking when support will be available.

If you purchased an add-on from expressionengine.com, be sure to visit boldminded.com/claim to add the license to your account here on boldminded.com.

Ticket: Production version of site displays tags and not tag content

Status Resolved
Add-on / Version Bloqs 4.7.0 (I've just asked the client to upgrade to the latest)
Severity
EE Version 6.3.4

John Faulds

Aug 18, 2022

Hi Brian,

As requested on Slack and following on from https://eecms.slack.com/archives/C04CUNNR9/p1660789844928319

One of the test pages is https://www.trapezegroup.com.au/pages-test (CP https://www.trapezegroup.com.au/admin.php?/cp/publish/edit/entry/1892 )

I’ve created a user account for you (details below).

That page is using this template: https://www.trapezegroup.com.au/admin.php?/cp/design/template/edit/194 The template is broken up into separate snippets for each block.

The template includes a lot of blocks, but it seems like their developer has actually deleted a lot of the blocks that exist on the staging version of the site, probably trying to troubleshoot what is causing the problem. Their developer doesn’t have very much experience with EE.

The problem appears to be with any field inside a block that requires a tag pair, so not just file fields but also select fields.

As I mentioned on Slack, everything is working OK on their staging site but it’s set up behind a VPN so I can’t easily give you access to that. You also need VPN access for FTP so I haven’t provided those details either.

Let me know if you need any more information.

Cheers
John

#1

BoldMinded (Brian)

Can you do me a favor and create a new test.html template file with only the channel:entries tag and bloqs tags necessary to replicate the issue? It also looks like snippets are being used, does the issue persist when snippets aren’t being used? In the new test template, don’t use snippets, keep everything in a single template file so its easier for me to work with.

#2

John Faulds

This template was already a duplicate of another, so using the same one, I’ve updated the template to only include two blocks – code and hero. I’ve copied the contents of snippets into the template.

I said before that I thought it was any field with a variable pair, but I think now it’s actually only ones that contain a {url} variable in them.

In the template, I’ve commented out the hero block and the page is rendering as expected with the only block being the code block which contains a variable pair for a select field but no {url}.

If I uncomment the hero block which contains {url} variables, then the problem occurs.

#3

BoldMinded (Brian)

I did some testing locally with the a File field, and this was my template

{exp:channel:entries channel="pages" dynamic="no"}
 <h1>{title}</h1>
    {bloqs}
        {file_bloq}
        <div data-block-name="file_bloq">
                {file}{url}{/file} <!-- This didn't work -->
                {file} <!-- This did work -->
        
                {bloqs:children}
        </div>
        {/file_bloq}
   {/bloqs}
{/exp:channel:entries}

While step debugging this I can see Bloqs’ replace_tag function… the one that does all the parsing for the field… return the correctly parsed value, regardless of if the {file} field is a single variable, or a pair. Basically Bloqs’ parsing is working. I’m seeing some weird things happen in EE’s Custom_field_pair.php file that is messing things up. Not sure what is going on.

#4

BoldMinded (Brian)

And by did and didn’t work I meant that the final output in the browser is definitely not parsing if it’s a tag pair, but if it’s a single variable it does output correctly in the browser. But if it’s the tag pair, that is where EE’s Custom_field_pair.php file appears to be messing something up.

#5

John Faulds

Sorry, I should’ve mentioned that. That’s what I found too. Using the single variable would give you the file’s URL. But then you can’t access any of the file’s other info like size, extension, etc.

So are you saying you’re replicating this behaviour on your own local install using a different database? Because in my testing, it was definitely due to the database.

The staging instance I set up for them, and my original local version of this site, is working fine with the templates as they were, using the variable pair. For that site I did a fresh install of EE and started from scratch.

It’s only the production site with a db that’s been through a few upgrades that has the problem.

#6

BoldMinded (Brian)

Yep, I can replicate locally in my dev environment. I’m not sure how the DB could play into this. Are you sure it isn’t a red herring?

#7

BoldMinded (Brian)

So this is a new revelation for me. I have a standalone custom field called “File” with the short name of “file”. I also have an atom in a bloq with the short name of “file”. EE’s parser gets ahold of the template before Bloqs does, and since there is a normal custom field with the short name of “file”, EE is attempting to parse what is actually Bloqs template code before Bloqs can get to it, and it’s causing a bad string replacement in Custom_field_pair.php

$tagdata = str_replace($chunk, $tpl_chunk, $tagdata);

Do you have another custom field on the site that has the same name as the Bloqs’ atom? If so, try changing the short name of one of them and see what happens. As soon as I renamed my atom from {file} to {the_file}, everything parsed fine.

#8

BoldMinded (Brian)

John, try the build in the next comment. I added a quick patch to let you prefix an atom/field name with the bloq name to avoid naming collisions and parsing issues. Using my example code above

{exp:channel:entries channel="pages" dynamic="no"}
 <h1>{title}</h1>
    {bloqs}
        {file_bloq}
        <div data-block-name="file_bloq">
                {file_bloq:file}{url}{/file_bloq:file} 
        
                {bloqs:children}
        </div>
        {/file_bloq}
   {/bloqs}
{/exp:channel:entries}

You don’t need to change the name of the bloq or atom/field name in the settings, just add the prefix in the template.

#9

BoldMinded (Brian)

Comment has been marked private.

#10

John Faulds

Thanks Brian. I realise now why this wasn’t an issue on staging: because I hadn’t set up all the old legacy fields which had the naming conflicts.

I can confirm that updating atom names did resolve the issue.

I haven’t tried the patched update yet as the client was holding off upgrading to 5.x as they hadn’t gotten around to resolving the change in the way closing blocks worked yet.

I’m leaving it up to them what they want to do about that for now.

#11

BoldMinded (Brian)

John, I’m going to mark this issue resolved since renaming the filed fixes it, and b/c I’m pretty sure the build I provided will work as another option. When you get around to using it and you still experience the issue feel free to re-open this ticket and I’ll take another look.

Login to reply