Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comment | File | Size | Author |
---|---|---|---|
#29 | manage_display_-1303412-29.patch | 1.12 KB | Valentine94 |
#25 | core-js-manage_display-1303412-25.patch | 1.13 KB | droplet |
#21 | remove-zh-XXX.patch | 1.31 KB | droplet |
#19 | core-js-manage_display-1303412-19.patch | 1.48 KB | nod_ |
#8 | core-js-manage_display-1303412-8.patch | 627 bytes | nod_ |
Comments
Comment #1
yched CreditAttribution: yched commentedCannot 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 ?
Comment #2
sahuni CreditAttribution: sahuni commentedI 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.
Comment #3
yched CreditAttribution: yched commentedIndeed - 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...
Comment #4
droplet CreditAttribution: droplet commentedComment #5
KarenS CreditAttribution: KarenS commentedI'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.
Comment #6
KarenS CreditAttribution: KarenS commentedAnd I agree, changing the value in the drop-down works fine, just not when trying to drag the field.
Comment #7
swentel CreditAttribution: swentel commentedConfirmed, normally either the formatter needs to be set to hidden or to the (first I presume?) formatter. That doesn't happen anymore.
Comment #8
nod_All right, so, according to what webchick and I agreed about JS testing here are the next steps:
(edit) took care of 1. let me know if the text is clear enough.
Comment #9
nod_2. is here #1779444: Add field-ui tests
Comment #10
nod_Doc for tests are available, just need to be committed, removing tag.
Comment #11
KarenS CreditAttribution: KarenS commentedI'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.
Comment #12
nod_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.
Comment #13
KarenS CreditAttribution: KarenS commentedI 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.
Comment #14
nod_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.
Comment #15
attiks CreditAttribution: attiks commentedpatch works for me in Chromium
Comment #16
KarenS CreditAttribution: KarenS commentedI 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.
Comment #17
droplet CreditAttribution: droplet commentedIE = 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.)
Comment #18
nod_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.Comment #19
nod_Here is the patch.
Now way around adding an inline configuration option for JSHint. To "fix" it would take weird and convoluted code.
Comment #21
droplet CreditAttribution: droplet commentedEDIT: Oh wrong patch :(
It's for #1784380: Remove zh-cht and zh-chs from language.mappings.yml
Comment #22
droplet CreditAttribution: droplet commentedSorry, uploaded a wrong patch.
see: http://youtu.be/agTHwyorty4
that's what i meant in #17
Comment #23
webchickHey, 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.
Comment #24
nod_#19: core-js-manage_display-1303412-19.patch queued for re-testing.
Comment #25
droplet CreditAttribution: droplet commentedThe problem seems like that doesn't set a correct default formatter type.
Patch fixed the original reported IE problem.
Comment #26
Stalski CreditAttribution: Stalski commentedWhile refactoring the field_ui I came across the same malbehavior. I fixed it locally the same way as in #25. Patch works great.
Comment #27
KarenS CreditAttribution: KarenS commentedI 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.
Comment #28
webchickRock! 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.
Comment #29
Valentine94Back-port for Drupal 7.
Comment #30
droplet CreditAttribution: droplet commentedComment #31
yched CreditAttribution: yched commentedStill have a hard time reproducing the bug, but #29 reproduces the changes that were done in D8, so, ... consistency++
Comment #34
droplet CreditAttribution: droplet commentedComment #37
Valentine94Comment #40
droplet CreditAttribution: droplet commentedComment #43
David_Rothstein CreditAttribution: David_Rothstein commentedTestbot fluke.
Comment #44
ThomWilhelm CreditAttribution: ThomWilhelm commentedJust 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...
Comment #45
David_Rothstein CreditAttribution: David_Rothstein commentedCouldn'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!