Frontedit of date field being passed through embed template

Few thoughts for you on this one.

1. If you don’t need the front edit on the date.. you could disable it for that field before passing it into the embed.

2. you could also disable it in the embed it’s self (with the comment option in the link above)

3. If you need it in the embed, I’d probably create a manual front edit link

Thanks,

-Tom Jaeger

Thanks Tom. By the numbers…

1. (disable front edit for the field) - I did this just to prevent the ugliness. This works, but of course prevents front-edit.
2. (disable it in the embed itself with the comment options) - Clarification: I’m assuming that by “in the embed it’s self” you mean in the embedded template, not the not the template that’s embedding the embedded template 😊 I think I tried this, and it didn’t work. I know I tried the variant that looks like this ({page_content disable="frontedit"}) and that it did NOT work. By “didn’t work”, I mean it didn’t even disable frontedit.
   2.b (disable it on the in the templates that do the embedding via comment or disable=”frontedit” param) - This works, but is kinda funky. I think what happened when I did this was that if the date was null, the “{entry_date disable="frontedit"}” actually showed up in the rendered page. I think. Sorry, I’ve tried a lot of variations, and I didn’t keep good notes. Something I did had a result similar to this (may have been the format string, vs the disable string).
3. (manual front edit link) I’ll give this a try - I don’t know why I didn’t think to try it - of course I read about it in the docs.

(4) I tried one other thing, which is working, but violates the DRY principle - I’ve moved the format specifier to the calling templates. Aside from having the format specifier copied in 5 or 6 locations, it’s working fine - the date is nicely formatted whether front-edit is enabled or not.

I decided to try that after having a think about what must have been happening to make 2.b happen. I figured that EE must not convert the objects to string right away. It seems more like it’s passing the objects through, which contain additional data (“I came from this field in the entry with this entryid”, “I have these format specifiers applied”, etc), and when it was a null, the conversion could deal with one layer of missing data just fine, but the second pass caused it to interpret the {} string as a plain string. Or something. That was a couple days ago 😊

I like your suggestion for #3 - I’ll try that out, and if it works, use it instead of the “#4” item I came up with.

I found a bit of a bug, too. I mean, aside from the title of this post. Not sure how serious the bug is, but something odd is going on.

Go back to the default setup (simplified example):

template A: {exp:channel:entries …. } {embed="embeds/B" item_date="{entry_date}” … } {/exp:channel:entries}

template embeds/B: … {embed:item_date format="%d-%F, %Y"} …

So, when front edit is enabled/happening, the date shows up as “17221455” (not sure that’s the right number of digits, but bear with me)… If I turn frontedit off, it shows as “14-May, 2025” (or whatever). The title bug is that for some reason the formatting is no longer applied. Similarly, frontedit can’t be disabled in template embeds/B, presumably because some of the metadata was ‘consumed’(?) by the frontedit machinery in template A. The SECOND bug is that if you now let your session timeout (when editing was enabled), the date will will look like “17221455” on the page, even with no edit links. I take this to mean that the front-edit machinery is still being invoked, if suppressed, even though I’m no longer logged in (well, not completely logged in, since it timed out.). The “proof” is that when I delete my cookies, it reverts to the correct behavior of acting like I’m nobody (and the dates render correctly again. Note: If you explicitly log out, it doesn’t do this. It only happens when you let your session time out. I know, this is a pain to test, but I assure you, if you’re demoing something to your client, it’s far more likely to happen 😊.

I kinda think the second bug is worse than the first: A. Because it suggests there may be a vulnerability in which even an expired session has privileges that it shouldn’t have (but that’s a bit esoteric, and I have no certainty that’s true) B. Because it means that this situation would look buggy for most editor-users most of the time they’re not actively editing the site. Most people don’t log out, they just let it time out.

But, this whole situation is esoteric - I don’t see anyone else complaining, and it’s only affecting the date field, so far as I can tell (perhaps because it’s the only one that needs to be formatted - so, maybe it affects any field that’s formatted)

On the using comments to disable it.. I’d probably do it on the template that has the embed.. something like the following:

{!-- disable frontedit --}
   {exp:channel:entries …. } {embed="embeds/B" item_date="{entry_date}” … } {/exp:channel:entries}
{!-- //disable frontedit --}


OR


{exp:channel:entries …. }
  {!-- disable frontedit --}
    {embed="embeds/B" item_date="{entry_date}” … }
  {!-- //disable frontedit --}
{/exp:channel:entries}

Is your template currently cached? I’m wondering if you had something cached that shouldn’t have been… I would recommend turning caching off while working to resolve this as well… Or cloning it over to a non cached version for active development if needed.

Hi Tom, I have it working in a way that is good enough for now. I’m not in love with repeating the date format code in all the templates that embed my reusable template, but it’s providing a good user experience, and the field is editable.

I started to try #3 last night (manual front edit link), but realized I’d need to make a couple changes; one that I wasn’t happy with: A) I’d need to pass the entry_id in as another param - no big deal B) I’d have to specify the field name in the embedded template, which is a bit of a dependency violation, which bothers me even more than the DRY violation.

I realize now, as I’m typing this, that I was wrong about ‘B’ - I could have passed the field name through as a parameter as well. So, I may go back and try it again, and if so, I may try your ‘commenting’ idea out, too, since I’ll need to disable the auto-generated link anyway (which has so far been dicey for me, unless I fully disable front edit of the field at the field level).

Oh, and you asked about caching - I did have it enabled for the embed template, but not for any particular reason. I’ve disabled it - being enabled can’t possibly do me any good.

Completing challenges and gauntlets back-to-back in Geometry Dash demonstrates endurance and consistency. Maintaining focus across multiple levels is no easy task.