3.2 Pages in Preview Mode

[Brian Shedenhelm]

In 3.0.1 and previous, when I would double click a page from Site Browser it takes me to the page already in Edit mode.

I updated our system to 3.2 and now when I double click a page from Site Browser it take me to the page in Preview mode.

Is there a way to change the default behavior in 3.2 to be like 3.0.1?  That is how can I get 3.2  to take me to the page already in Edit mode?

[Jason Aleski]

I agree.  I didn't even look at this yesterday.  I feel like an idiot!  I didn't realize it was taking me straight into preview mode.  I just made the assumption that when I double clicked on the page, it was going straight into edit mode.  Because of that assumption, I was troubleshooting everything else, rather than the most simplest thing!

The only reason I can see this is to force people to click the lock for editing.  By going into preview mode, it doesn't necessarily lock the file.  I know from past experience that sometimes people will go viewing pages and they lock, but do not back out of them properly, so they stay locked.  I wonder what others think of this, if this was an intended change.

-JA-

Jason Aleski / IT Specialist

--
You received this message because you are subscribed to the Google Groups "dotCMS User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotcms+un...@googlegroups.com.
To post to this group, send email to dot...@googlegroups.com.
Visit this group at http://groups.google.com/group/dotcms.
For more options, visit https://groups.google.com/d/optout.

[Brian Shedenhelm]

Don't feel bad Jason.  I updated my dev server a couple days ago and saw that I couldn't edit content on the page.  That led me to believe that something must have happened to permissions/roles during the upgrade.  So I rolled back to 3.0.1 until yesterday.  I tried it again, still having the same outcome, then I realized what the situation was.  So, at least you didn't install, rollback, then reinstall just to see that you weren't observant enough.

They should at least mention this change in the release notes.

I'm glad I'm not the only one. :-)

[Kivi Shapiro]

Neither of these changes was well thought out. For the first one, why would people be opening a particular page in Site Browser if not to edit it? The back end is all about editing. And for the second one, it can only result in piles of unnecessarily locked pages; we're already seeing that.

I've entered change requests for both issues. See https://github.com/dotCMS/core/issues/7527 and https://github.com/dotCMS/core/issues/7550

Kivi Shapiro
Qualicom Innovations

[Brian Shedenhelm]

+1 Kivi

I couldn't agree more!

[Mark Pitely]

Hah. I just stopped development on my javascript project to auto-unlock the pages, it was working, but flaky.

I'm new to 3.2, just moved from 1.9.3 this week, and this one change is killing us. Didn't realize this was that recent.

I was told there was a way to use the Workflow Schemes to unlock every page every 24 hours or so - did anyone do that successfully?

Mark Pitely

[Will Ezell]

I wanted to share that we are watching this change to page editing process and tracking the feedback surrounding it.  It is important for the community to know that this change was not made arbitrarily and thought was given (a lot of thought, actually) to the re-working of locking and editing process.   For the sake of transparency, here are some of the reasons FOR asking the user to lock before editing:

1. It is completely consistent with the processes of our other content editing screens where you have to lock before you can edit anything.
2. As Mark and others have pointed out, with pages as content, accidentally locking pages can quickly become an administrative headache. If you locked every page when it was viewed in edit mode, you would leave a trail of locked pages in your tracks (the locking timeout of content in my mind is a separate issue).
3. Locking a page before editing it makes a page feel more "whole" vs. being made up of various different content items, which with workflows on pages, what we were trying to achieve.
4. It gives theuser context for an editor to have a view at what the page looks like before diving in and editing.  The demo homepage is a great example, where the layout changes from preview mode to edit mode to assist the user in editing some of the content.  
5. There is no indication in the site browser that you would be locking the page when clicking on it or that you are being taken to edit mode, where pages can look a bit jumbled.  When you right click on a page in the browser, you get a menu item that says "Open (Preview)"  I think that is what that message has always said.  Maybe there should be a way to do an "Open (Edit)" but that would be a new menu option on the flyout.

Obviously for users coming from older versions it is never fun to learn new behavior.  And when we made the change in 2.0 for the content editing screen, we made the "Lock for Editing" button flash when a user tried to edit a locked content, which was a nice visual indication that you needed to lock before you could edit.  Kivi, you have mentioned that we should have done a similar thing in Preview mode as well and I concur - that would have alleviated or even prevented some of the "I am staring at this page in dotCMS and I can't edit it" feelings.  We can do something like that at the minimum.

As to the unnecessarily locked content and wanting to auto-unlock, you can use the workflow to do that but only if the workflow is mandatory.  It is a pretty big pain point and we'll work on an osgi plugin that will auto-unlock content on a timed basis until we can get it resolved.

Thanks guys and happy Friday!

Will 

3059 Grand Avenue

Suite 410-B

Miami FL 33133

Main: 305-900-2001 | Direct: 978.294.9429

wi...@dotcms.com | dotcms.com

   

[Brian Shedenhelm]

Thanks for the response Will.  It's good to know you guys are putting some thought into this. 

So am in understanding this correctly that when you click the Edit tab on a page to put it in Edit mode, you are locking the page?  I think I may be a little confused.

[Brian Shedenhelm]

I think I just figured something out that was missing from the equation for me. 

My dev site started off as 3.0.1 that did not have html pages as Content.  After upgrading to 3.2.1, when I open a html page it has 3 tabs in the upper left corner: Edit, Preview (defaulted tab, and Live.  On the Edit tab there is the option to "Migrate to Content."  I have been ignoring that.  Well, I just tried it on one page and now I have 2 tabs at the upper left corner: Preview an Live.  Now, instead of having to click on the Edit tab all I have to do is click "Lock for Editing."

I think I see the big picture now.  Was this documented anywhere that I should have read before updating?  I sure didn't see it anywhere. 

Is there a way to mass "Migrate to Content" all your pages or is that something that should even be done?

[Kivi Shapiro]

Will, thank you for the prompt, considerate, and detailed response. I realise that "not well thought-out" was unfair in this case. What kind of usability testing did you do to test the thinking?

Kivi

[Kivi Shapiro]

http://dotcms.com/docs/latest/bulk-legacy-html-page-migration

[Will Ezell]

I wanted to follow up on this thread - we've just uploaded n example
OSGi plugin that will automatically unlock content that has been
locked for X amount of time, where X can be configured. It is also a
good example of an OSGI Quartz job, which I know some have had issues
with. It can be downloaded here:

https://github.com/dotCMS/plugin-dotcms-timed-content-unlock

The plugin has only been tested locally, but it should work (of course
it should be tested in a staging environment before being used in
production). Any feedback or experience using the plugin would be
welcome.

On Fri, Jun 12, 2015 at 1:57 PM, Mark Pitely <pit...@maryu.marywood.edu> wrote:

[Karen To]

We are in the process of upgrading from 2.5.7 to 3.5 and I'm seeing this behavior now and agree that it's a somewhat cumbersome change when working with legacy html pages in 3.5. For example, if I have a container that allows 12 pieces of content and I want to move the one at the end to the beginning, I have to click the up arrow, then wait for the page to render, then Edit, then up arrow, repeat. It adds a lot of time to a process that is already sort of annoying.

Side note: is drag/drop on the roadmap for things like this?

Does dotCMS have a recommendation as far as whether legacy HTML pages should be migrated? What are the pros/cons of either leaving them as legacy vs. migrating them?