935693 - If a template calls another template that's changed, the sub-template's new output isn't used

Status: RESOLVED FIXED

(developer.mozilla.org Graveyard :: General, enhancement)

Description

[Eric Shepherd [:sheppy]]

What did you do?
================
1. We have a template CommunityBox which calls through to DiscussionList
2. DiscussionList is changed to output its data using a new class.

What happened?
==============
The output returned to CommunityBox by DiscussionList doesn't reflect the change.

What should have happened?
==========================
When a template is changed, templates that call through to it should get the updated results.

Is there anything else we should know?
======================================
We do this a lot, and the problem happens very regularly.

Comment 1

[Eric Shepherd [:sheppy]]

groovecoder asked for examples; everyone, post links to pages that are affected by this.

Here are a few I know of (not all are affected right this minute):

https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API
https://developer.mozilla.org/en-US/docs/Web/Guide/HTML
https://developer.mozilla.org/en-US/docs/MDN/Contribute/Content

These are pages I know I've seen this on. The first one has been particularly annoying lately since I'm actively working on improvements to the macros involved, and not seeing my changes reflected is making me crazy.

Comment 2

[Eric Shepherd [:sheppy]]

More generally, I've seen this happen on any page that uses the LandingPageListSubpages macro, or the SubpagesWithSummaries or SubpageMenubyCategories macros.

There are tons of other macros that call through to other macros, and these are affected as well.

As a general rule, this problem is most noticed when you're actively working on improving a macro, because failures to display current content are more aggravating when you're trying to test changes and not seeing them.

Comment 3

[Eric Shepherd [:sheppy]]

Further clarification: in the past, going to the macro pages and shift-refreshing then, then shift-refreshing the pages that use the macros, would let you force the changes to be picked up. This no longer works. I'm filing a new bug for that.

This bug is about making that not necessary at all -- changing a sub-macro should automatically force the rebuilds of calling macros.

Comment 4

[Eric Shepherd [:sheppy]]

For what it's worth, ElasticSearch now lets us find all the pages that call a macro, so it in theory would not be as hard as it once would have been to implement automatic rebuilds when macros change -- just trigger a rebuild for the macro, then for each page that calls the macro, on up the tree.

Comment 5

[David Walsh :davidwalsh]

Is this still an issue sheppy?  I think my last kumascript PR should have fixed this

Comment 6

[Eric Shepherd [:sheppy]]

I *think* the shift-refresh of each chained macro, then the page(s) using it is working now. It's not a good solution for the overall problem of picking up macro changes, but it's better than nothing.

Comment 7

[David Walsh :davidwalsh]

I just had a brainstorm about this, going to try something out.

Comment 8

[David Walsh :davidwalsh]

Humor me but this should no longer be possible with my caching PR.  Here's why I think this (the process):

1.  When any template is updated, kumascript is notified and sent the new content and update date so that it can be stored in cache.
2.  When any template is requested (any template in the chain of a kuma document), a request (per template) is done (via a request to kuma) to check if templates are out of date (somehow).  If so, fresh ones are requested.  If not, old content is used.

The only thing stored by kumascript is raw template source -- that's it, so there aren't "results" stored.  Can we confirm, for sure, that this is still existing?  I'd be surprised.

Comment 9

[Eric Shepherd [:sheppy]]

I think it's good now...

Comment 10

[David Walsh :davidwalsh]

I'm going to optimistically close this as fixed due to this PR, for the reason in the PR and comment #8.

https://github.com/mozilla/kumascript/pull/50

Comment 11

[Luke Crouch [:groovecoder]]

Sweet! Good work :davidwalsh!