When trying to change the layout of the node form for any content type, the only display suite layout available is the "2 column stacked" (see screenshot).
I looked in the code to see if there was something particular about that layout that made it show up compared to the others. As far as i can see there is no difference between the default layouts. I also tried creating a custom layout to see if that would work, but it's only available for on the display side, not the node form.
I searched the docs and the issue queue to see if I could find any other post regarding this, but came up short. Just seems kinda bizarre, but I'm not sure if that is intended since I'm relatively new to DS.
Thanks,
Rene
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | 1351826.patch | 43.08 KB | swentel |
| #11 | template-stuff.patch | 32.45 KB | aspilicious |
| #4 | 1351826.4-ds-form-extra-layouts.patch | 16.85 KB | mrfelton |
| ds_manage_fields.jpg | 209.35 KB | rhache |
Comments
Comment #1
swentel commentedThere is only one layout for node forms at this point. See http://drupalcode.org/project/ds.git/blob/refs/heads/7.x-1.x:/ds.api.php... where the 'form' key property determines if a layout is available for a form or not. There's probably going to be a 3 column stacked layout in the next release.
Comment #2
mrfelton commentedI'm reopening this as a feature request.
Would it be possible to make all of the panels layouts available fo use in the form layout editor, like you can when managing the field display? Or making it possible to use layouts provided by modules such as the Panels Extra Layouts module? What is the reason for having to define these layouts again here?
Comment #3
swentel commentedWell, the reason is 'simple'. I need an extra render function after all is moved around:
You'll find this in the provided ds form layouts at the bottom of the template so all other form elements are taken care of (hidden, tokens, etc). I know I thought of doing this in the ds preprocess function in the last known region that has visible elements, but that was kind of hacky. I can try and give it another try, but it's still close to won't fix :)
Comment #4
mrfelton commentedHow about something like this. I'm using preprocess to do the drupal_render_children(), and ensuring that it only happens when required. I've adjusted the templates to include the extra form stuff at the bottom if it exists. It seems to be working pretty well for me. I can now use any of the DS defined layouts for Form layouts. Doesn't work with panels layouts yet though.
Comment #5
swentel commentedWell, the problem is that if people have created their own layouts in themes (like we do in our base theme) this won't work as long as they don't update the tpl file. It's an API change in a way. Still to sure to be honest - should definitely go into a new branch (if we create one for 7 or D8) - so I'm mostly tempted to postpone this. I'll have another brainstorm about this this weekend to see if I can some up with another solution - or find a way to not list layouts which don't have this variable.
Comment #6
Countzero commentedTried the patch in #4, and it seems to work pretty well with the default edit forms.
It doesn't play well with entity_translation forms for adding translations though : only the first column is rendered.
The idea is interesting anyway : I really expected the forms to be displayed as per any available template for content, and was surprised to see they weren't. Just mentioning it because I guess many users will expect this behaviour, probably generating issues.
The functionality is already amazing, though a bit confusing to set up (it's unclear which modules should be activated or not at this stage).
Comment #7
Countzero commentedTo be more specific, the 'entity_translation_edit_form' form can be registered, but it can't be managed as its settings seem to blend with the standard node edit form.
Comment #8
Countzero commentedI tried to investigate. A strange thing is that the first two regions are rendered correctly, but not the third nor the fourth.
I'm sure the correct template is used, but the $third and $fourth variables are set to
, which ds_forms_render_region at line 192 in ds_forms.module returns nothing.I tried to understand why but couldn't figure it out as of now. My best guess is that the fields are not prepared correctly before the call to drupal_render, but have trouble going further.
Maybe mrfelton has a hint for me ?
Comment #9
dpalmer commentedSwentel,
Is there any way to inject a "View" field into the node add/edit form the same way we can for the display output?
For instance, say you have a Content Type "Locations" and when users are adding new locations, you would like a list of "Existing Locations" to the left.
Comment #10
swentel commentedI'm willing to reconsider this for the 7.x-2.x branch, but the patch needs work due to all the changes. If anyone's up to create a new patch, I'll most likely commit it. Note that, panels won't probably work, but ds layouts should work fine.
Comment #11
aspilicious commentedThis is more like a template rewrite. Not yet done, some strange failing tests. And need to add a new template and make some tests for the fluid stuff.
Can someone verify the failures?
Comment #12
swentel commentedGreen!
Comment #13
aspilicious commentedhttp://drupalcode.org/project/ds.git/commit/6a5b2e719a1c1b3efbc2833ee8bd...