For fields I have put in hidden section, I can no more, drag them out of hidden section. I can drag them from hidden section to the normal fields section, but before I have time to save, field returns in hidden section.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

yched’s picture

Cannot reproduce on a fresh setup.
Could you check your JS console see if any JS errors are reported during the drag ?
Also, any chance you have contrib modules like field_group or ds (display suite), that both modify this form pretty heavily ?

sahuni’s picture

I tested more: in IE8, FF7 and Google chrome.
Problem exists just for IE.
I tried a fresh setup, just add a field aaa for basic content type, and try to hide and recover. I get same problem with IE, so definively it's an IE problem, and not a contrib modules problem.
Can you test with IE8? Problem is just mine or do you have the same?

I'm not blocked because, I can switch to weight display instead of drag&drop, and I can also do that with another navigator.
But, if that issue can be solved, it saves times to other Drupal configurators.

yched’s picture

Title: Manage display Drag&drop » 'Manage display' : Cannot drag out of 'Hidden' (IE only)

Indeed - I can reproduce on IE9.

The AJAX refresh, which is supposed to put back the formatter settings options when the format is no longer set to 'hidden', comes back resetting it to 'hidden' instead.

Odd that this should happen only on IE. Plus I currently don't have a windows dev environment to debug locally...

Note that changing the 'format' drop-down from 'hidden' to an actual formatter (instead of dragging the row) works...

droplet’s picture

Version: 7.8 » 8.x-dev
Issue tags: +IE, +Needs backport to D7
KarenS’s picture

Title: 'Manage display' : Cannot drag out of 'Hidden' (IE only) » 'Manage display' : Cannot drag in or out of 'Hidden'
Issue tags: -IE, -Needs backport to D7

I'm running into this using FF on a clean D8 install, so it's not just IE. I am unable to move any fields between 'hidden' and not 'hidden'. Simple step to reproduce, on a clean install, using the 'page' content type, try to make the body hidden on the teaser display. When you save the change, it reverts back to not hidden. If you add a new field to the content type, it will be hidden automatically. If you try to move it from 'hidden' to not 'hidden', you cannot, the change will not be saved.

I had no problems in D7, so this is something new in D8.

KarenS’s picture

And I agree, changing the value in the drop-down works fine, just not when trying to drag the field.

swentel’s picture

Component: field system » field_ui.module
Priority: Normal » Major
Issue tags: +JavaScript

Confirmed, normally either the formatter needs to be set to hidden or to the (first I presume?) formatter. That doesn't happen anymore.

nod_’s picture

Status: Active » Needs review
Issue tags: +Needs JavaScript testing
FileSize
627 bytes

All right, so, according to what webchick and I agreed about JS testing here are the next steps:

  1. Fill in http://drupal.org/node/1777342 with the procedure to test this bug.
  2. (optional) write the actual testswarm qunit test to check it.

(edit) took care of 1. let me know if the text is clear enough.

nod_’s picture

nod_’s picture

Doc for tests are available, just need to be committed, removing tag.

KarenS’s picture

Status: Needs review » Needs work

I'm not completely clear on everything that was said in #8, but if that patch is supposed to fix the problem, it did not fix it for me. Fresh install with just core and this patch, same problem.

nod_’s picture

did you clear the browser cache?

(edit) usually for JS patches the only thing needed is to clear drupal cache and start a "private" window/tab to try out the fix. Takes the pain out of clearing the browser cache.

KarenS’s picture

I cleared the Drupal cache. Then for good measure I opened up a totally different browser that I haven't use on any D8 site and tried that. Still not working. My original browser is FF, after applying the patch I opened up a new Chrome window, logged in, and tried again. It fails both in the original FF window and in the new Chrome window.

nod_’s picture

That's strange, that fixed it for me. when you drag below the hidden row, do you have the Ajax throbber? I'm guessing not but I'm not sure what's not working here.

attiks’s picture

patch works for me in Chromium

KarenS’s picture

I have no throbber. I just spun up a clean install with the latest git checkout and nothing else installed but what is installed by default in a new core installation. I didn't even create any nodes. I guess let's see if anyone else can replicate a problem in a fresh install, because that's as basic as I can get.

droplet’s picture

IE = failed

FF / Chrome = Failed if you don't wait for ajax call to complete this request action. (so it should block the Save button until ajax request is finished.)

nod_’s picture

Ok see the problem.

Can you try with CSS aggregation turned on? Let me know if that fixes it?

The patch does fix the bug, it's just broken somewhere else from this patch #1684788: JSHint ajax.js, it's the do {} while () that breaks stuff.

nod_’s picture

Status: Needs work » Needs review
FileSize
1.48 KB

Here is the patch.

Now way around adding an inline configuration option for JSHint. To "fix" it would take weird and convoluted code.

Status: Needs review » Needs work

The last submitted patch, core-js-manage_display-1303412-19.patch, failed testing.

droplet’s picture

Status: Needs work » Needs review
FileSize
1.31 KB
droplet’s picture

Sorry, uploaded a wrong patch.

see: http://youtu.be/agTHwyorty4
that's what i meant in #17

webchick’s picture

Status: Needs review » Needs work

Hey, droplet, I unpublished comment #21 just so people don't get confused and test the wrong patch.

I am not sure this is a "major" bug worth holding up other D8 features, but I did hit it too, and it was certainly weird and unexpected.

nod_’s picture

Status: Needs work » Needs review
droplet’s picture

The problem seems like that doesn't set a correct default formatter type.

Patch fixed the original reported IE problem.

Stalski’s picture

Status: Needs review » Reviewed & tested by the community

While refactoring the field_ui I came across the same malbehavior. I fixed it locally the same way as in #25. Patch works great.

KarenS’s picture

I had a hard time getting this to work in FF (where I originally had trouble), initially I was going to say that it didn't. I cleared the cache multiple times, turned the overlay off and on and tried it both ways, opened fresh windows, and it finally did work. I don't know why it was so hard to get the previous behavior cleared. Just noting that in case anyone else has similar problems.

So as far as I can tell definitely ready to be committed.

webchick’s picture

Version: 8.x-dev » 7.x-dev
Priority: Major » Normal
Status: Reviewed & tested by the community » Patch (to be ported)

Rock! Thanks, folks!

Committed and pushed to 8.x. This would not apply cleanly to D7 though. Moving down to "patch (to be ported)."

I'm also downgrading to "normal" so that this no longer blocks D8 features. It's not like you *can't* do this, it's just unintuitive.

Valentine94’s picture

Issue summary: View changes
Status: Patch (to be ported) » Needs review
Issue tags: -Needs backport to D7
FileSize
1.12 KB

Back-port for Drupal 7.

droplet’s picture

Status: Needs review » Reviewed & tested by the community
yched’s picture

Still have a hard time reproducing the bug, but #29 reproduces the changes that were done in D8, so, ... consistency++

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 29: manage_display_-1303412-29.patch, failed testing.

Status: Needs work » Needs review
droplet’s picture

Status: Needs review » Reviewed & tested by the community

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 29: manage_display_-1303412-29.patch, failed testing.

Status: Needs work » Needs review
Valentine94’s picture

Status: Needs review » Reviewed & tested by the community

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 29: manage_display_-1303412-29.patch, failed testing.

Status: Needs work » Needs review
droplet’s picture

Status: Needs review » Reviewed & tested by the community

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 29: manage_display_-1303412-29.patch, failed testing.

Status: Needs work » Needs review
David_Rothstein’s picture

Status: Needs review » Reviewed & tested by the community

Testbot fluke.

ThomWilhelm’s picture

Just run into this issue on Drupal 7.34, reproduced on Chrome, FF and Safari, patch at #25 worked very nicely for me. Does the current status of this ticket mean it will be fixed in the next release, I can't see the code change in 7.x-dev:

https://www.drupal.org/node/156281

Also I can't work out why a field wouldn't use the default formatter when moving a field from hidden to not hidden, I've never had this issue ever with Drupal before and have just started working with a new Drupal site, so maybe there's something specific in the way it's been setup that's causing this...

David_Rothstein’s picture

Status: Reviewed & tested by the community » Fixed

Couldn't really reproduce the bug either, but the patch looks fine and doesn't seem to break anything, so sure, let's do it - it apparently fixes a bug in some particular situations.

Committed to 7.x - thanks!

  • David_Rothstein committed ac0f69f on 7.x
    Issue #1303412 by nod_, droplet, Valentine94, KarenS, sahuni: Cannot...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.