The problem
My use case here is that I have a resource, built with CB, which contains a form (built using a content block form builder I’ve made).
This is used in multiple places across the site, so I’ve created a Collection of ‘reusable blocks’. Each is a resource unto itself and it lives in the Collection with some other reusable content.
I have created a custom block type which is a select box with some code to create a list of the resources in the Collection and then the content editor can select a resource. The block contains code which forklifts the content field of the selected resource into the block space. Below I refer to the page this is inserted into as the ‘target page’.
This has been working nicely across multiple sites in production for over 12 months until yesterday when I put a nested layout in the page above the form on a new site I’m working on.
This move turned my form into this:
(“Validation issue” is part of my code, but it’s lost the first half of all its logic and a matching backtick somewhere along the line)
I’ve just been limited to one image per post because I’m new, so I’m going to try and add a view of the ‘healthy’ form in a comment below.
Any time below that I say it ‘broke’, it looked like this image. And that look was reflected in the HTML page code which had removed an entire chunk of HTML including the opening tag itself and any backticks higher in the page - that one after ‘Validation issue’ is the first one that appears anywhere in the code.
It should be said that it took the first 1/2 hour of trouble shooting to narrow it down to the nested layout but it did reliably seem to be related to the nested layout.
Things I worked through and their results
-
Looking for mismatched back ticks
There seemed immediately to be a mismatch in backticks so I went searching in the code of all the elements up the page - none had unmatched backticks that I could find and the nested layout has been checked for mismatching backticks probably 1/2 dozen times now. -
‘Reduction’ of the nested layout
I tried removing things from the nested layout and reduced it all the way down to even removing the layout that was inside the ‘nest’ so in theory the field contained nothing to output to HTML. The break still happened. When I removed the empty nested field and saved, the form was good. This left me thinking I was working against the cutting edge(s) of parsing engine(s). -
Forklifting the code manually
I opened the database and grabbed the rendered content field from the resource containing the reusable form and put it in a page in the same position in a text type block that output only that exact code into the page - it worked even with a nested layout above it. Then it became obvious that the ‘forklifting’ of the code from another resource was causing b0rkage and I could have either manually lifted code OR a nested layout higher in the page, but not both. -
Changing the forklifting method
I was originally grabbing the field using[[#[[+value]].content]]in my custom content block. I thought this was using FastField but that wasn’t installed so I think that was working courtesy of pdoTools. I switched that over the the pdoField snippet syntax in case that made a difference - it didn’t. -
Using a placeholder - success!
Using the pdoField snippet I was able to change the block that performs the forklifting to output to a placeholder and immediately output that placeholder. When I do that, it works. When I have the pdoField tag outputting its own result, I get the broken output.
What I think I might be up against (comments and suggestions welcome)
At the moment my best (and only partially educated) theory is that there’s a parser glitch somewhere or this is working exactly as designed but I’m confusing the parsers by going all Inception on them.
There’s 3 (maybe 4) times the parser may be called so it gets a bit more complicated.
Parser…parses
-
When I save my reusable page, the content is parsed by content blocks into code. I think this step is clean though because when I manually grab the resulting content field and drop it into the target page, the form works fine.
-
When I save the target page, the target page is parsed into HTML by ContentBlocks including the code from the reusable content field. It’s possible a parse 3 also happens here within parse 2 - only because I don’t know enough to vouch for what pdoField does and doesn’t do.
-
When the page is called to load, it performs its final MODX tag parse to be made into a page.
Possibly-important things I’ve yet to sus out or need to circle back to
-
When it’s broken, what part of the HTML page is missing? What’s the start point of missing and is that relevant? (I looked at this early on while narrowing down to the nested layout, but don’t remember the answer and it might be telling.
-
checking out the ‘layers’ in the database. I know the original form render into the reusable content field is clean, but I’m not sure I’ve checked how clean the target page is once ContentBlocks is done with that
-
I wondered about sidestepping pdoTools for doing the forklifting myself in case that’s performing a parsing step on its way across. Writing my own little snippet to programatically get the content field of the resource in question and echo it out was my proposed MO. Depending on how that played out it would also allow me to perform some before/after logging as I push things around.
–
Interested in any and all comments and suggestions for things to check out.
Happy to provide code samples for blocks and output which I think will be important in getting much further, but I didn’t want to spam them here in the first instance, making this even longer, without first being invited/requested to.
Whatcha got?
