Bring SilverStripeNavigator back from the dead?

[Jonathon Menz]

Hi all,

The SilverStripeNavigator seems to have been a bit forgotten in SS3+ I guess because the addition of the preview modes in the CMS mean that you don’t need to leave the CMS to see your changes.

I think it still has some uses though:

• Know at a glance that you're logged in when browsing a website
• Jump quickly to the CMS when browsing site
• Log out from any page

And it could be made more useful by adding some developer shortcuts:

• Change environment mode (dev/test/live)
• Flush templates
• Build DB
• Open /dev/ menu

I'm playing around with a little module to implement this and just wondering if this is something the wider dev community would find useful. Please see mock-up attached showing a couple of different states and let me know if this is something you'd like to see released (as a module initially but could be a pull request on core too).

Other features:

• Hidden when previewing in CMS
  
• Dev tools only visible when site is in dev mode or logged in member is marked as a developer in config
  
• Vanilla javascript to prevent conflicts
• Overridable template (add custom buttons / change style)
• Anchor to any corner (so it doesn't block menu items etc.)

Love to hear your thoughts.

Cheers,

Jono

[bauke]

Looks really nice, would love to see it in action! 

One thing you might want to keep into account is to prevent it from caching, for example by the dynamic-cache module. 

[James Turner]

I didn't even know such a module previously existed so I wrote my own which pretty much does what you say.

https://github.com/Turnerj/Frontend-Admin

So it shows who is logged in, shows the current stage of the site (and a quick button to change it), has a shortcut to edit the page, a logout button and also hides when in CMS. It currently doesn't (but wouldn't be hard to add) flush templates, build DB, open dev menu, client side in vanilla JS.

I was going to build it so it acted more like a frontend admin in that some basic components can be added / edited without needing to dive into the main CMS but haven't really gotten that far yet.

[Jonathon Menz]

@bauke - good point, hadn't considered caching yet. Easy to get around partial caching but static caching might cause a headache for this.

@James - ah, nice work! I hadn't seen this module before. Have you used this with static caching before? FYI the old navigator was bundled with core and is still there - it can be called on any SS site by putting $SilverStripeNavigator in a template. It used to be included in default theme for SS2.x but not included in the default SS3 theme, so I assume there is a move away from using it.

Besides the dev tools I like the idea of keeping all the controls discrete/collapsed in a corner and allow switching corners so they don't get in the way of existing menus. The Compact Navigator module allows expanding/collapsing but could maybe occasionally still get in the way so would be cool to be able to change it's position.

It's the dev tools I would personally use the most though. Currently I use javascript bookmarklets for these shortcuts (wrote about those here).

Anybody else have an opinion on SilverStripeNavigator? Use it / don't use it, why / why not? Keen to know if this is something the majority or the few would find useful. As noted it's still included in core, so if it's going to live on there it could maybe at least use a little visual update to make it more consistent with the CMS design.

Also keen to hear any suggestions about bypassing static caching.

[James Turner]

Cheers for the info Jonathon. Haven't tried with static caching before though it is on my list of things to do! I'm guessing there is some way in code to detect when the static cache is being generated and it would be a matter of not including the JS file in my case.

I agree about the positioning aspect, with everyone and their different use cases, it is good to have something like the ability to anchor the control to various parts of the page.

I might add the functionality your talking about to my module but I agree, because the core has the building blocks there, it would be good to see it improved/styled with the more recent CMS changes.

[DesignCity]

We would find it extremely useful—as I imagine most devs would. Truth is we were about to write our own extension, so it's great to see some others already having done so and working on implementing improvements.

Given the fact that the navigator is missing on 3.x installs by default, my assumption here is the core team would prefer to spin the whole thing out into its own module—but they can confirm that of course.

We had an extended 2.4 navigator, and one of the keys to enabling it to be useful for clients was our ability to extend it on the current class. For example, on a news holder, adding a link to 'add new news item' directly without first entering the CMS (or equally, in development, running a task). YAML config would probably make this trivial to do.

Designs look great. I might suggest that for simplicity the anchoring of the nav to any corner (or even side?) might be best to left to a config variable?

Regarding caching, it looks simple enough to provide workarounds for popular modules by disabling caching for logged in users, or if the navigator is only of real importance when developing, adding a config option to disable the navigator on sites in live mode.

Let me know if we can be of any assistance in getting the module up and running.

Cheers,
Michael

--
Michael Bollig
bollig.co
designcity.com.au

[Jonathon Menz]

You're probably right that only choosing between top right or top left for the anchor and setting this in the config would be enough. Would be glad for the reduced clutter.

Do you have an example of your extended 2.4 navigator somewhere? Sounds interesting and much more robust than what I've described.

For static caching, you're right it doesn't look too hard to bypass the cache for logged in users (as long as you're pre-processing with PHP). Probably a note in the docs about setting that up should be sufficient if people want to use this module with static caching.

I think a navigator could be quite useful for content editors as well as devs (particularly with the extra functionality you described), so I would aim for it to be available in all environment modes to members with CMS access.

[Olli Tyynelä]

Caching could cause issues on getting the right meta info on the correct time for example with dynamic-cache or varnish.

Just to offer my 5 cents and quickly thinking this here:

- Id remove the per page meta generation to its own controller/path -> that would be easily excluded from any caching procedures

- per page just include the CompactNavigator.js and that pols data from the controller rather than trying to read from the current page which cache might be only invalided only after unknown time.

Of course there would a request to the controller unless there is somekind of js coocie checking of some sorts or some similar magic, but i think it could be a acceptable hit.

I think just getting the info is the site running on dev or live when logging in as an admin on the frond-end is quite important info and would help on live sites being in dev mode accidentally :).

Does my idea make sense at all or is it feasible? :)

Cheers,
Olli

 

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

[Jonathon Menz]

Thanks for the input Olli - I've only just begun dabbling in static caching (I didn't know dynamic-caching and varnish existed til now) so I'm out of my depth here, but hopefully someone else can comment on your idea.

[Jonathon Menz]

Putting aside caching for a moment, can anyone at SilverStripe Ltd comment on the built in SilverStripeNavigator? Was it intentionally left out of the Simple theme, has it been forgotten about, are there plans to improve it etc.?

The dev features etc. I outlined might belong best in a module but I think SilverStripeNavigator in core should be maintained, and it's use encouraged - here's why:

SS3 design flaw: client's not realising they're viewing draft content

Something I forgot to mention which I think is very important and has been brought up here before, is that if you preview draft content in the CMS, you will see draft content when you visit the website outside the CMS as well. It's also harder in SS3 to identify which pages contain draft changes in the CMS. I have had a number of phone calls from clients along the lines of "I sent out a newsletter pointing to a page on my website, and I can see the content right there but other people can't!". I think this is one area where SS3 took a big step backwards from SS2 and can cause a lot of confusion.

SS2.x: 

• Front end flag (Published / Draft / Archived) lets users know what stage they're viewing. 
• Colour coding in the CMS site tree alerts users to unpublished pages or changes.
• Steve Krug would be happy :D
  

SS3.x: 

• No front-end flag, don't know which stage I'm viewing (so I assume live). 
• Have to roll over pages in the site tree to see if they contain unpublished changes (so I assume there aren't any). 
• Steve Krug would be sad :(
  

Are these criticism's fair? I think a flag alerting user's to the stage they're viewing is important, and I would like to see some sort of always-visible colour-coded status mark on pages in the CMS site tree. Maybe just a little coloured dot is always visible, but becomes the full tag when the link is rolled over (a bit like tags in OS X Mavericks)?

[Loz Calver]

These criticisms are definitely fair, I’ve lost count of the number of phone calls I’ve received from clients asking why new content shows for them and not other people!

With regard to the CMS-side flags, there was/is a pull request about this (I can’t seem to find it, but it’s there somewhere). I definitely think something should be shown without the need to hover, I like your suggestion of a coloured dot with more info on hover.

[Jonathon Menz]

Here's the coloured dot idea mocked up:

[Loz Calver]

Yeah that sort of idea looks good. Here’s the PR I was talking about: https://github.com/silverstripe/silverstripe-framework/pull/2794.The dot would be pushed out of view for pages with long titles/deeply nested pages, so perhaps a combination of your idea and the ideas in the PR would be ideal.

P.s. is the separator between regular pages and error pages photoshopped in? I’d find that handy, too!

[Jonathon Menz]

Good point, the dot could easily be hidden with longer menu titles. Here's a new version:

The 'status dot' could sit on top of the page icon, and hopefully look okay on top of custom icons too. And yeah - the error page location is 'shopped - another pet peeve of mine :) error pages don't belong in the site tree and I hate that new pages are created below the error pages. It's another source of confusion for clients - "I think I broke something because I can see a page in the CMS but it says 'Server error' and has a broken icon..."

[Nicolaas Thiemen Francken - Sunny Side Up]

another pet peeve of mine :) error pages don't belong in the site tree and I hate that new pages are created below the error pages.

+1

[Nicolaas Thiemen Francken - Sunny Side Up]

Just to offer my 5 cents and quickly thinking this here:

- Id remove the per page meta generation to its own controller/path -> that would be easily excluded from any caching procedures

- per page just include the CompactNavigator.js and that pols data from the controller rather than trying to read from the current page which cache might be only invalided only after unknown time.

Of course there would a request to the controller unless there is somekind of js coocie checking of some sorts or some similar magic, but i think it could be a acceptable hit.

I think just getting the info is the site running on dev or live when logging in as an admin on the frond-end is quite important info and would help on live sites being in dev mode accidentally :).

Does my idea make sense at all or is it feasible? :)

Cheers,
Olli

+1 

[Jonathon Menz]

Just continuing to play around with this. The old 'edit pencil' could be a bit more self-explanatory than a dot and placing a status indicator next to a page icon rather than on top might play better with custom icons. On the inline version below the titles don't line up but I think this helps make them stand out and overall it looks cleaner than the overlaid version. I also thought that reducing the opacity of page icons for draft pages could be a useful (although subtle) indicator that that page isn't yet visible on the live website.

[James Turner]

Great work! I agree about having the pencil icon inline to the page icon. I kind of wish the page titles could still be aligned with each other while not having the pencil overlap the page icon. Perhaps have the pencil positioned to the left of icon and act like it is absolutely positioned?

[Jonathon Menz]

Thanks James. Yeah I know what you're saying - I like the clarity of having the status indicator inline but prefer the alignment of text in the overlaid option as well. I did consider putting the pencil icon to the left but then it will interfere with the triangle icon that marks a page that contains children. Think it would get a bit too busy in that case.

I do wonder though if having the text pushed out a bit might actually be a good thing as it draws your attention more? It kind of says "Hey, you're not done here yet!"

[James Turner]

Yeah, I forgot about the child page arrow/triangle. 

It does draw more attention to it but there is still something about it that doesn't seem right to me. I see it and straight away think, it needs to be aligned somehow.

If you get some more ideas of how to show the draft/published page status, definitely post them around.