Local customizations broke site on upgrade, how to disable?

Support
1

Just updated to beta 9, now my Discourse is completely white. I did the below and still have the same thing. Don’t have CDN.

cd /var/discourse
git pull
./launcher rebuild app

Any ideas?

14

What plugins do you have installed?

15

None.

Reading this: https://meta.discourse.org/t/deprecating-objectcontroller/28385?u=jesselperry

I think I have a customization that gets the current logged in user name. Could that be causing this error? The this.get('name') in the post made me think of that customization.

Any way to disable that customization, even though I can’t get into /admin?

17

hmmm yeah

cd /var/discourse
./launcher enter app 
rails c
> SiteCustomization.update_all(enabled: false)
exit
exit

After this restart the container

./launcher restart app
2 Likes
22

I’m back in business!! Thank you so much @sam

And based things working now, and the /logs errors I saw and this post: https://meta.discourse.org/t/deprecating-objectcontroller/28385?u=jesselperry

I think it had something to do with me calling one of these in a site customization?

Discourse.User.currentProp('username')
23

Paste the full customization source here, @eviltrout can have a quick look

24

Please forgive the ugly method I’m probably using to get logged in user email address. I hacked around on Meta to try to pull this together a couple months back.

<script>
    var currentusername = Discourse.User.currentProp('username');
    var fulllinktojson = "DISCOURSE_SITE_REDACTED/users/" + currentusername + ".json";
    $.getJSON(fulllinktojson, function(json){
        currentuseremail = String(json.user.email);
    });
</script>
25

Discourse.User.currentProp should work fine, my guess is that you are calling it too early now.

26

I have this in </body>

27

@sam we need a way to have a site launch in “safe mode” with all plugins and customizations disabled.

6 Likes
28

It was meant to be simply visiting “admin” directly, but for some reason we only disable css there, we should fix that.

2 Likes
30

Ok this is very strange! (to me)

The code that seems to be causing the problem is this?

CSS:

#site-map-dropdown a[href="/users"] {
    display: none;
}

#site-map-dropdown a[href="/about"] {
    display: none;
}

#site-map-dropdown a[href="/faq"] {
    display: none;
}

#site-map-dropdown a[class="keyboard-shortcuts-link"] {
    display: none;
}

Head:

<script type='text/x-handlebars' data-template-name='/connectors/site-map-links/members-as-users'>
    <li><a href="DISCOURSE_SITE/groups/trust_level_2/members" title="Team Flower Members listing" class="members-link">Members List</a></li>
    <li><a href="DISCOURSE_SITE/faq" title="Learn more on using Team Flower Community" class="faq-new-link">How to use Community</a></li>
    <li><a href="http://www.teamflower.org/members-login" title="Manage your Team Flower account" class="team-flower-account-dropdown" target="_blank">Team Flower Account</a></li>
</script>
31

Aha, in this particular case you are compiling a template in production. After the recent ember refactor I removed the compiler from our production build. I didn’t realize people were using it in customizations.

I’ve added it back:

https://github.com/discourse/discourse/commit/29631f65f1ae8d78ae61ed1e19e10d2b52b04387

6 Likes
32

Why don’t we put this behind a site setting so every Discourse install in the world is not penalized with extra load time, for the incredibly tiny number of cases where a random customization compiles templates?

1 Like
33

We could do that, but if we default it to off it will temporarily break all the sites who have customizations. If we default it to on, most won’t get the savings.

Backwards compatibility is hard :frowning:

34

As Spock once said, the needs of the many outweigh the needs of the few. And the type of advanced sites doing advanced customization should be more than able to tweak a setting.

1 Like
35

You could put in a migration that does a string comparison for text/x-handlebars on all the customizations, and sets the setting to true at migration time if any are there.

No need for human intervention, and we get the perf boost.

36

Or just follow my plan and precompile the templates :smiley: no need for a setting then

1 Like
37

This change (automatically compiling templates in site customizations) is now complete!

https://github.com/discourse/discourse/commit/43d63367fdf39dc5f69b640936ac19cd817f6631

This means we no longer ship 66K gzipped Ember template compiler AND we stop shipping 11K gzipped handlebars (and instead ship 3.7K gzipped runtime)

Total savings on initial load is approx 73K also this is a bunch of code that is no longer evaluated and kept in memory which is another huge saving.

3 Likes