Local customizations broke site on upgrade, how to disable?


(Jesse Perry) #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?


Custom Code Breaking Site
(Sam Saffron) #14

What plugins do you have installed?


(Jesse Perry) #15

None.

Reading this: Deprecating ObjectController

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?


(Sam Saffron) #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

Failing after running "./launcher rebuild app" on Ubuntu 14.04
Script in /head broke site
Rebuilding caused a JavaScript error on load
(Jesse Perry) #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: Deprecating ObjectController

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

Discourse.User.currentProp('username')

(Sam Saffron) #23

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


(Jesse Perry) #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>

(Sam Saffron) #25

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


(Jesse Perry) #26

I have this in </body>


(Jeff Atwood) #27

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


(Sam Saffron) #28

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


(Jesse Perry) #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>

Ember 1.11 Upgrade Notes + Discourse Stability
(Robin Ward) #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


(Jeff Atwood) #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?


(Robin Ward) #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:


(Jeff Atwood) #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.


(Kane York) #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.


(Sam Saffron) #36

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


(Sam Saffron) #37

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

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.


(Jeff Atwood) #38