As designed Templates display as outdated if last_edit_date is the same as parent

[Jake B.]

Affected version

2.0.0

Our Nodes add-on generates a css template based on the input you give for node styling, and it sets the last_edit_date for this template as the current timestamp but as soon as that happens the templates get marked as outdated because the conditional uses parent.last_edit_date >= template.last_edit_date. I suppose as a workaround I could increment it from the parent template's last_edit_date, but I think it makes sense that it wouldn't be outdated if the last_edit_date parent and current template are identical

 

[Mike]

Arguably, if the timestamps identical, then it's exceedingly unlikely that the child template would actually be incorporating the changes from the parent template. Hence, it makes sense to mark the child as outdated if there's a tie. (I appreciate that 1 second later probably doesn't include the changes either, though there does have to be a cut off.) I'd also note that the logic here is the same in XF1.

I guess I'm a little curious what your add-on is actually doing here. It sounds like it's writing to multiple templates, though that seems uncommon unless you specifically have per-style configuration, though there may still be better approaches there as programmatically writing to styles other than the master style is not really expected.

 

[Jake B.]

It’s a per style configuration for node styling, was originally not actually using templates and just extending CssRenderer (or something along those lines as I don’t have the code in front of me) but ran into issues with changes not applying from the caching or compilation process, I did end up adjusting it to increment the last edit date since there is a note in these templates that they shouldn’t manually be edited as everything is generated

 

[Mike]

TBH, I think there are better approaches to take here as even this has difficulty. Notably, importing a style could wipe out the expected value of the template (either by reverting it or giving an unexpected value). Given the particular use case, I would likely write all of the code to the master template with style-based conditionals where needed.

I don't think there's really anything to change here, mostly based on the reasoning I laid out in my previous comment.

 

[Jake B.]

Makes sense, will just go with the single template and conditionals

 

[Jake B.]

TBH, I think there are better approaches to take here as even this has difficulty. Notably, importing a style could wipe out the expected value of the template (either by reverting it or giving an unexpected value). Given the particular use case, I would likely write all of the code to the master template with style-based conditionals where needed.

I don't think there's really anything to change here, mostly based on the reasoning I laid out in my previous comment.

Alright, I remember why I didn't do that originally now, I didn't want the master template to be used because it'll get overwritten when they update the add-on. Guess I'll just have it rebuild on upgrade or not assign the master template to the add-on since it won't get included unless the add-on is installed anyways

 

[Mike]

Guess I'll just have it rebuild on upgrade or not assign the master template to the add-on since it won't get included unless the add-on is installed anyways

That's exactly how any systems that programmatically write to templates or phrases should work (see page nodes, media sites, phrases for custom fields, warnings, etc).