Upgrading to 2.2.14 reset asset folder

[duderuud]

Affected version

2.2.14

I upgraded to 2.2.14 (p2) and noticed some of our logos weren't being displayed.

Add-ons used:

• Cloudflare App by @digitalpoint, using Cloudflare R2 that redirects the /data and /internal_data folders to R2
• Custom Bolt style by @Russ

The Bolt style uses the following variable to logos:

%ASSET:stylefolder%/xenforo/xxxxxx

After upgrading, the ASSET variable used in the style points to the old local /data/styles path instead of the R2 data path.

 

[digitalpoint]

FWIW the Cloudflare addon does nothing whatsoever with that replacement var... that's a XenForo core function, so if it's not happening it does seem like it would be an issue with XenForo itself.

While I don't personally use the %ASSET:stylefolder% replacement var for anything (so hard for me to really test anything with it), it does look like XenForo only does the underlying replacement when .LESS templates are compiled (not on the fly) so maybe it's just an issue where those templates (or style that use them) need to be rebuilt/recompiled.

 

[duderuud]

I rebuilt the master data but that didn't help.

 

[digitalpoint]

One thing that comes to mind would be if XenForo 2.2.14 were to disable addons while the .LESS templates were being compiled (not sure why that would be the case), you might see what you are seeing (maybe that's happening while the upgrade/rebuilding of templates is happening). Specifically the external data URL you are using with your R2 bucket is being added to the system via the app_setup code event listener. So if that were to not be run for whatever reason before the .LESS templates were compiled, you would end up with the default folder there.

 

[duderuud]

Did some more digging.

When I check the developer tool in Safari, one specific image is loaded correctly. That image is not specified in the GUI part of the style properties but I could find it in a template:

<img src="{{ asset('sources') }}/blue-stripes.png"

The above file is located and loaded from the R2 bucket as designed. Weird...

 

[digitalpoint]

Did some more digging.

When I check the developer tool in Safari, one specific image is loaded correctly. That image is not specified in the GUI part of the style properties but I could find it in a template:

<img src="{{ asset('sources') }}/blue-stripes.png"

The above file is located and loaded from the R2 bucket as designed. Weird...

I suspect the ones you are having issues with are ones that get compiled inside .less templates? That's why I was saying that if for whatever reason the XenForo instance that does that compiling (done once, not on the fly like other templates) isn't getting code event listeners run, it would be a problem.

 

[Xon]

One thing that comes to mind would be if XenForo 2.2.14 were to disable addons while the .LESS templates were being compiled (not sure why that would be the case), you might see what you are seeing (maybe that's happening while the upgrade/rebuilding of templates is happening). Specifically the external data URL you are using with your R2 bucket is being added to the system via the app_setup code event listener. So if that were to not be run for whatever reason before the .LESS templates were compiled, you would end up with the default folder there.

The installer doesn't load addons, so if you depend on add-ons for CSS/LESS to compile correctly this will break when XenForo update is run.

The work-around is to edit a template/style property and it'll force all the CSS/LESS to be recompiled

 

[digitalpoint]

If it's indeed a case of it only being an issue during upgrade, you could also add the external URL to your config.php file:

$config['externalDataUrl'] = 'https://data.yourdomain.com';

Effectively it would use that for when addons are disabled (upgrade process) and the setting under options for everything else.

 

[duderuud]

The installer doesn't load addons, so if you depend on add-ons for CSS/LESS to compile correctly this will break when XenForo update is run.

The work-around is to edit a template/style property and it'll force all the CSS/LESS to be recompiled

That works, thanks for pointing that out!

If it's indeed a case of it only being an issue during upgrade, you could also add the external URL to your config.php file:

$config['externalDataUrl'] = 'https://data.yourdomain.com';

Effectively it would use that for when addons are disabled (upgrade process) and the setting under options for everything else.

Will add that for future upgrades.

Thanks a lot guys, problem solved and learned something today

 

[digitalpoint]

Not the first time I've had issues with XenForo disabling addons for upgrades. It's also problematic because I have something that syncs templates to multiple physical servers when they are written to the filesystem.

If we are going to blanket disable addons during an upgrade, it would be nice if we had a a code event listener we could hook into during the install process for edge cases like these.

At least fire app_setup (or even install_app_setup) wrapped in try/catch (protect the upgrade process from a code event listener doing something crazy if that's the fear) for the XF\Install\App class sure would be nice...

 

[Jeremy P]

Not too sure we'll ever really support extensions during the install process because of the risk of something bricking an install (even blanket catching exceptions risks leaving data in an inconsistent state), but perhaps it might be nice to have a post-upgrade event that's triggered after an upgrade has completed similar to the one for add-ons.

 

[digitalpoint]

Not too sure we'll ever really support extensions during the install process because of the risk of something bricking an install (even blanket catching exceptions risks leaving data in an inconsistent state), but perhaps it might be nice to have a post-upgrade event that's triggered after an upgrade has completed similar to the one for add-ons.

Ya, I understand the “why”. At least if we had a post-upgrade event we could handle one-off edge cases with things so it would definitely be a welcome addition. For example we could go back and recompile the less templates as needed in this case. Or in the case of my other example where templates being written out triggers a sync to other servers, we could just trigger a full sync after an upgrade (right now we have to remember to do that manually after upgrades).

 

[Jeremy P]

Yeah, that's roughly the use case I imagined. Not as ideal, but at least it offers some kind of mechanism to do these things.

 

[digitalpoint]

install-app-setup would be nice if I’m dreaming. Before anything starts (so couldn’t leave it in a borked state if someone did something stupid). But beggars can’t be choosers. Hah

 

[Xon]

An install-app-setup would also need to be fired when the master data is rebuilt, since that can rebuild things which are normally extendable.

 

[Kirby]

Not too sure we'll ever really support extensions during the install process because of the risk of something bricking an install

It is possible to run extension code during upgrade / install (by adding code event listeners or even class extensions in some cases via config.php), but setting this up is rather complicated and not possible for XenForo cloud users.

It is also possible to run an install / upgrade with modified files (will trigger a warning though).

In both cases modified / 3rd party code could run during install / upgrade.

I totally understand the reasoning behind not allowing Add-on code to be executed during upgrade / install, but as pointed out by @Xon and @digitalpoint this can be a major PITA in some edge cases.

A code event that is only fired on install / upgrade bootstrap would be pretty useful for such cases.
To guard against bricking the process due to broken / incompatible code this could be protected with "big red warning" confirmation, eg. a bit like the warning about modified files:
The admin would have to confirm that attached listeners should be executed - if not the process continues without calling the listeners.
IMHO this would be the "best of both worlds" - it can (to a big extend) protect XenForo upgrades from breaking due to bad code and can help Add-ons from breaking due to code that was not run during XenForo upgrades.

At least a code event (or job) that is fired once after an upgrade really should be added, that would simplify quite a few things for my Add-ons.

K

XF 2.1 Post in thread 'Run code after XenForo upgrade'

May 28, 2020

I initially also thought about checking the version ID but tossed that idea as being kinda ugly

Maybe it would be possible to enqueue an empty job (XF:UpgradeCompleted or smth. like this) that basically does nothing (except maybe firing a code event) at the end of XF\Upgrade::completeUpgrade()?

This could act as a trigger and would run outside the upgrade processes but would ensure it does get run after an upgrade and does not require "active wating" for a version ID change.[/icode]

• Kirby

 

[Jeremy P]

It is possible to run extension code during upgrade / install (by adding code event listeners or even class extensions in some cases via config.php), but setting this up is rather complicated and not possible for XenForo cloud users.

I didn't mean to imply it was completely impossible, but it's definitely not supported or a first-class feature and generally comes with enough friction that the administrator really should know what they're doing and the risks involved.

I imagine we'd be more likely to go with the latter approach, firing off an event after the upgrade has completed.

 

[Kirby]

I imagine we'd be more likely to go with the latter approach, firing off an event after the upgrade has completed.

If you do that (which would be highly appreciated) please also add an event that is fired immediately before an upgrade starts.

Use Case
I have code that compresses XenForo JS so the webserver can serve pre-compressed files.
If XenForo is upgraded the JS files may change, but the compressed files won't until the upgrade has completed, the event has fired and the files have finished recompressing
So between the end of the upgrade (at this point the JavaScript timestamp has already been updated) and the time my code has finished to recompress (changed) files, the webserver would deliver the old compressed files to clients, potentially breaking their experience (for a short time).
If there also was a code event fired immediately before the upgrade the compressed files could be deleted / renamed so old compressed files would not be delivered after upgrade.