Mobile settings do not open on the correct page

[PaulAdamDavis]

Issue Summary

When you go to the settings pages (/ghost/ember/settings/) on mobile, no matter what the URL is, the page shown is the settings menu.

In other words, going to /ghost/ember/settings/general/ shows the settings menu.

So the page shown in the Settings section should match what is in the URL.

Steps to Reproduce

1. Open /ghost/ember/settings/general/ in a browser less that 800px wide
2. See that the page shown is not the General Settings

Expected Results

You see the general settings page

Actual Results

You see the Settings menu.

Technical details:

• Ghost Version: master (latest commit: 0436fb7)

[novaugust]

Is this one of the screens that, on clientold, worked via flipping back and forth between the menu and the screen itself, ala the content menu's functionality?

[PaulAdamDavis]

@novaugust I think so? My thinking is (pending @JohnONolan's approval) is that on desktop, the settings should open on the general tab, but on mobile/tablet it should open on the settings menu.

[novaugust]

I'm thinking this has a very similar solution to this bit of code on the posts view

[PaulAdamDavis]

Thanks for the tip, @novaugust !

Just had a play around with this. In my first (super-hacky) attempt, I'm getting the last item of the URL and finding it's link, then pseudo-clicking it.

// Starting on #L28 of /core/client/views/settings.js
responsiveAction(event, '(max-width: 800px)', function () {
    var pathname_array = window.location.pathname.split("/"),
        clean_pathname_array = $.grep(pathname_array,function(n){ return(n) }),
        last_pathname_item = clean_pathname_array.slice(-1).pop();
    $(".settings-menu a[href$='"+ last_pathname_item +"/']").parent("li").click();
 });

However, I know this isn't the best solution at all – you can see the transition happen.
I think the ideal solution is to do the transition before the page is visible, or better yet, rewrite how this transition works on mobile, to prevent this happening in the first place.

[novaugust]

Hooo boy. Remember when I said "Yeah, I don't think this will be too tricky"? I may have lied. I didn't think about the transitioning around -- all that crossed my mind was, the functionality (spin one screen around to the other) would be the same. I sent you off on a dark path man.

Let me get back to you on this when I get home and can play with what the original issue actually was, rather than how I pictured it in my mind.

[novaugust]

Okay, I'm caught up with the issue and get what's going on here. You're right - what this ultimately needs is a bit of refactoring to work beautifully on mobile. With the current implementation, there's no way to go to /settings/general/ on mobile and not have it do some sort of transition.

Really, what's getting us here is we're having jQuery do ember's job, because we already had jQuery implementations on clientOld and the easiest thing to do was bring that code straight over.

Yeah, the only thing I can come up with off the top of my head is, create a view for each settings sub page and have it bind some css properties on init based on the viewport size.

^^ I feel like that sentence may be un-understandable to anyone who wasn't in my head as it was produced. Sorry about that, IRC me so I don't get outrageously lengthy on this comment

[novaugust]

@PaulAdamDavis I spent somewhere around a-silly-amount-of-time playing with this today.

I got it to show the menu when at /settings/ on mobile, and to show the content when at /settings/someSubRoute/, but things get icky when the browser gets sized up to non-mobile proportions, pretty much because I'm trying to make jQuery do the job of a media query.

Do you think it would be possible to remove the jQuery .animate(..) and .css(..) calls that currently control whether the menu or the content is visible, and instead control it all by toggling a class?