Posted by yoroy on
I'm not seeing drag-drop handles in the manage display forms Field UI.
Timplunkett did a quick debug in IRC: Uncaught DrupalBehaviorError: attach ; fieldUIDisplayOverview: Cannot set property 'onDrop' of undefined
Seems to be caused by #2382557: Change JS settings into a separate asset type
Marking critical because now you can't hide fields, which defeats the purpose of display modes, which is at the heart of why you'd want to use Drupal as a CMS.
Suggested commit message:
Issue #2388215 by freblasty, tim.plunkett: Drag and drop is broken.Files:
| Comment | File | Size | Author |
|---|---|---|---|
| #10 |  2388215-tabledrag-10.patch | 1.51 KB | tim.plunkett |
| #3 | 2388215-tabledrag-2.patch | 771 bytes | tim.plunkett |
| FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch 2388215-tabledrag-2.patch. Unable to apply patch. See the log in the details link for more information. [ View ] | |||
Comments
Comment #1
yoroy commentedOn a probably unrelated note: timplunket and me both wondered what the 'Parent' column is all about.
Comment #2
yoroy commentedActually, no drag/drop anywhere (menus, blocks page)
Comment #3
tim.plunkett commentedThis broke all of tabledrag. I checked menu UI and block UI as well.
It was just the result of a sloppy change in the other issue.
I manually tested, everything works now.
Comment #4
yoroy commentedChecked in simplytest.me and yes, that puts things right again.
Comment #5
jibran commentedIt is a duplicate of #2387523: Tabledrag broken after JS setting separate asset type
Comment #6
tim.plunkett commentedThis one was tested and RTBC'd.
Committers, please also credit @freblasty
Comment #7
jibran commented+++ b/core/includes/common.inc@@ -2159,7 +2159,7 @@ function drupal_attach_tabledrag(&$element, array $options) {
- $element['#attached']['drupalSettings'][$options['table_id']][$group][$tabledrag_id] = array(
+ $element['#attached']['drupalSettings']['tableDrag'][$options['table_id']][$group][$tabledrag_id] = array(
This is a php code change. Can we add tests for this?
Comment #8
webchick commentedAccording to Tim, this wouldn't give us something we could check in the markup, only in the JS settings. So presumably this needs Behat or similar to actually test meaningfully.
So for now, let's kill the regression. Committed and pushed #3 to 8.0.x. Thanks!
Leaving open/postponed for the tests for when it's possible. Ideally, this would go into some queue somewhere for "front-end stuff we really need to test when we get front-end testing."
Comment #10
tim.plunkett commentedI agree with #8, but in case someone *really* wants to just test the PHP part of this, and assert random keys in a giant array, we could.
Comment #11
jibran commentedWhy can't we just create a simple method just like
Drupal\system\Tests\Theme\TableTest::testThemeTableStickyHeaders()? Or a test same asPathElementFormTestforcore/lib/Drupal/Core/Render/Element/Table.php. In which we create table elements in a form (TableFormTest::buildForm()) and then do some asserts on$form = \Drupal::get('form_builder')->getForm(\Drupal\system\Tests\Element\TableFormTest());Comment #13
Real_gambi commentedjibran
This change help me, thanks!!!