Luke Carrier, [06.08.18 15:55]
Here's an awkward one I'm sure everyone will love. Dynamically setting {{$CFG->wwwroot}} largely behaves really well, but there are some edge cases with the core_coursemodinfo cache caching complete URLs to the {{wwwroot}} the editor of the content was using (particularly in awkward properties like {{cm_info->onclick}} with {{mod_url}}). I have two schools of thought on fixing this:

1. Fix it in each {{mod_*}} plugin, via one of the callbacks involved in cm_info construction.
2. Fix it in core, by replacing references to {{$CFG->wwwroot}} in each field with some magic string (similar to {{@@PLUGINFILE@@}} in editors) and fixing this when the data comes back out of the cache.

Luke Carrier, [06.08.18 15:56]
Has anyone else ever done this and found a better option? Neither of these changes feel particularly upstreamable :/

Tim Hunt, [06.08.18 16:23]
Don't do it.

Luke Carrier, [06.08.18 16:23]
[In reply to Tim Hunt]
Tell our stakeholders that please 😉

sam marshall, [06.08.18 16:32]
Hi Luke, I think a better fix might be to fix it in each plugin by using the magic string, i.e. have the plugin insert %%WWWROOT%% or whatever it is, but maybe have a standard core way to do that (so they don't all end up using different placeholders...)?
If you just need a local hack, though, I think you can totally hack that javascript in a theme renderer...

sam marshall, [06.08.18 16:33]
(For 'standard core way to do it' - like maybe moodle_url should have an out_with_placeholder() function that outputs %%WWROOT%%/ at the start... If there isn't something similar already.)

Luke Carrier, [06.08.18 16:53]
sam that sounds like a great compromise... I think I'd have to apply that placeholder in the *_get_coursemodule_info() callbacks in each mod looking at the code?

Luke Carrier, [06.08.18 16:54]
It's a big API break that I'd imagine would (rightfully) receive a lot of pushback, though

Jan Dageförde, [06.08.18 16:57]
We have dynamic wwwroots in combination with an always-active filter that searches for all possible wwwroots in strings and replaces it with the one that is appropriate in that situation

Tim Hunt, [06.08.18 16:58]
That is a ncie solution if you must do this.

Jan Dageförde, [06.08.18 16:58]
Works reasonably well. Of course it doesn't work for cached parts of the theme because the filter isn't applied there

Luke Carrier, [06.08.18 16:58]
[In reply to Jan Dageförde]
Does this work even in e.g. onclick attributes on URL activities? I didn't think they'd get passed through format_text()?

Luke Carrier, [06.08.18 16:59]
For links within content that's a pretty nice way to fix it up, but we're tending to find issues exclusively with the way course content ends up getting cached.

sam marshall, [06.08.18 16:59]
By the way, if there's some kind of front-end server messing up the wwwroot in the first place, I don't suppose it's possible for that front-end server to also do the replaces itself rather than Moodle doing it...? Not sure what capabilities they tend to have.

Luke Carrier, [06.08.18 17:10]
[In reply to sam marshall]
We dynamically set $CFG->wwwroot before including setup.php, then in a hook after including /lib/setup.php we attempt to look up a brand association via that domain. We also replace $PAGE->theme during theme_*_page_init(), which allows swapping theme settings at run time

Luke Carrier, [06.08.18 17:11]
It's pretty crude, but it's been in production for around a year with only very specific edge cases like this

Jan Dageförde, [06.08.18 17:15]
[In reply to Luke Carrier]
It works for all those function legacy_activity_onclick_handler_1(e) that are generated into the HTML source, if that's what you mean

Luke Carrier, [06.08.18 22:48]
[In reply to sam marshall]
Incomplete as I've not covered LTI, but does this look along the same lines as your thinking? I'm pretty sure the mod_url specific code is at least partially redundant, though I believe the url.externalurl value still needs processing on its way in and out.

https://github.com/moodle/moodle/compare/master...LukeCarrier:MDL-nobug-coursemodinfo-cache-onclick-master

Luke Carrier, [06.08.18 22:49]
Signing out for now, feedback welcome. Not sure this will get upstreamed given how niche a problem it is, but if anyone else has an interest in something similar I'm totally open to feedback

sam marshall, [07.08.18 12:26]
[In reply to Luke Carrier]
Yes that's exactly the kind of thing I was thinking of. Looks good to me but obviously I can't tell if others will agree it's a good solution!

Luke Carrier, [07.08.18 15:36]
[In reply to sam marshall]
Cheers — now to try and justify this insanity to other people