Shift-refreshing macros that call other macros no longer picks up changes in the submacro

RESOLVED FIXED

Status

defect
--
major
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: sheppy, Unassigned)

Tracking

Details

(Whiteboard: [specification][type:bug])

Reporter

Description

5 years ago
What did you do?
================
Scenario: a macro (let's call it the primary) that uses the template() function to call out to another macro (let's call it the secondary) as part of its functionality.

A change is made to the secondary macro.

We have bug 935693 already, about the fact that this should automatically be picked up.

However, in the past, if you shift-refreshed the secondary macro's page, then the primary macro's page, then the wiki pages that use the primary macro, the changes would take effect.

What happened?
==============
This is no longer happening. I'm not sure when this started, but it's fairly recent.

What should have happened?
==========================
Using shift-refresh as mentioned above (up the chain of macros to the pages that use the primary macro) should cause the edits to the secondary macro to be reflected on the page.

Is there anything else we should know?
======================================
Bug 935693 requests the specific behavior desired. This bug appears to request a workaround that bug 935693 would make unnecessary. 

Marking this as minor.

:groovecoder, can you comment on whether this workaround is drastically simpler than bug 935693? If so, we may want to reconsider the severity level here.
Severity: normal → minor
Flags: needinfo?(lcrouch)
Reporter

Comment 2

5 years ago
The actual problem here is incredibly bad for productivity for the writing team. If you guys opt to do bug 935693 instead, that's awesome, but one of these needs to be done ASAP so we can finish the work we're trying to do on enhanced landing pages and the like.
Reporter

Comment 3

5 years ago
Pages affected include:

https://developer.mozilla.org/en-US/docs/MDN/Contribute/Howto
https://developer.mozilla.org/en-US/docs/Mozilla

Any page using the LandingPageWithSubpages macro is affected, since it calls through several levels of macros, some of which were in the middle of being updated when bug 1044068 struck. If the macro had a bug, that meant we were getting cached messes that we couldn't fix, leaving us unable to debug the macros.

So it's totally possible that even after pushing a fix for this, the pages above might still not work. :)
Note to self: the macro affected is LandingPageListSubpages
Flags: needinfo?(lcrouch)
This is the major bug to fix regression and restore the functionality as before. Bug 935693 is the enhancement bug that is significantly more work.
Severity: minor → major

Comment 7

5 years ago
Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/93a6b38166bb9a1c4e6c6a7ef07071dc462e4eee
fix bug 1063580 - Synchronize template URL format between kuma and kumascript

https://github.com/mozilla/kuma/commit/00a6c44f537dda3020401eb09f9e407303502611
bug 1063580 - add test for kumascript.get logic

https://github.com/mozilla/kuma/commit/feb37f09a192a48c8cf5719591d66d551bce82f5
Merge pull request #2735 from groovecoder/sync-template-cache-keys-1063580

fix bug 1063580 - Synchronize template URL format between kuma and kumascript

Updated

5 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.