Problem/Motivation
When I install the bootstrap theme and I try to add content I seem to have a problem: when I choose publish I am redirected to the preview screen.
The problem only occurs when my site is on the bootstrap theme. Anyone who has encountered this?
I have tried this on a new drupal installation and I get the same result. If I use bootstrap as backend theme it seems impossible to publish.
Steps to reproduce:
- Use the Bootstrap theme.
- Set the admin theme settings to not use the admin theme during content creation or editing.
- Try to publish a piece of content.
- Verify that you're back at the edit form instead of looking at the new content page.
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | 2657124-18.patch | 641 bytes | vasi |
Comments
Comment #2
matthias_bauw commentedComment #3
matthias_bauw commentedComment #4
matthias_bauw commentedComment #5
markhalliwellYou need to provide more information than "it's not working"...
Comment #6
matthias_bauw commentedhmm,
There is not much more to say. When you activate the bootstrap theme as theme for editing the site You simply can't get any nodes added.
When I try to add a new node and click 'Save and publish' the system refers to the preview of the node. But that is not the button that was clicked. I have tried looking at the code but I don't see what's going wrong. There is no publish button in preview mode. When I disable preview mode I am just referred to the form but no error is shown.
Am I the only one experiencing this? I tried it on a vanilla install and I could reproduce the problem so I really don't think it's because of something I did.
Matt.
Comment #7
dandekarprashant commentedI have facing the Same error
I created taxonomy & its terms and couple of Content types
and unchecked the 'Use Administation Theme for creating content'
same error stated in #6 by DragonEye occurs
but when i tried to create content using administration theme (Seven) I was able to create content.
in the drupal log messages
I find these errors
User error: "format" is an invalid render array key in Drupal\Core\Render\Element::children()
User error: "value" is an invalid render array key in Drupal\Core\Render\Element::children()
User error: "summary" is an invalid render array key in Drupal\Core\Render\Element::children()
Comment #8
dandekarprashant commentedComment #9
markhalliwellThere is no patch attached. Please read Status settings of issues.
Comment #10
timfluhr commentedI'm experiencing the same thing.
When editing a node the "save and keep published" and "preview" buttons both send me to a preview page with a url like this:
node/preview/5f4b4ca8-1bdf-4d4b-ad3c-606e8f84b96f/default
I can't successfully complete a node edit.
Comment #11
markhalliwellI would appreciate y'all going through and trying to debug what the real issue is and then create and upload a patch. I do not have the time to do this right now (client work), nor should I be the only one that has to "fix all the things".
Comment #12
mile23I can verify that it happens with 8.0.x dev with Bootstrap 8.x-3.0-beta2
Sorry I don't have a patch, but I have some watchdog log entries...
These are all thrown during
node/add/article:Comment #13
mile23Comment #14
OshEvans commentedSeems I have the same general issue here. (Drupal 8.0.2 with 8.x-3.0-beta3)
I have a module which implements some UGC forms (so not in admin).
When these forms are submitted, they fail, only showing the strlen and stristr warnings... which are just warnings, so, I'm guessing there must be something else failing silently in the background...
The str errors seem to be related to a textarea (wysiwyg), and removing the textarea clears the warnings... but the form still fails (silently).
Anyway, I'm starting to debug the issue today, and am hoping to find someone who already has a solution (or knows where the problem lies), even if there is no patch, and just some loose instructions - anything would be appreciated.
Thanks.
Comment #15
mmilano commentedOn beta3 I can reproduce the main issue, as well as the errors reported in #7 (separately though)
- Create a content type with `Preview before submitting` set to `Disabled`
- Add content for this type by providing a title, body, and submit the form by clicking `Save and publish`
Result:
- Edit the content type and set `Preview before submitting` to `Optional`
- Add content for this type by providing a title, body, and submit the form by clicking `Save and publish`
Result: I am stuck on the preview screen with no submit buttons. There is a `View mode` select box overlayed across the top 100 pixels of the screen with the options `Default` and `Teaser`.
Since taxonomy usage was mentioned in a comment here, I thought it may be relevant that while I do not have a taxonomy field on this content type, I do have taxonomy enabled.
Comment #16
markhalliwellThis was just taken care of by #2688519: Node preview is unstyled. FYI, there are no submit/publish buttons on the preview page anymore. This issue is about the form submission on the node add/edit form itself.
These aren't necessarily specific to this project. An update to 8.0.5 and a cache rebuild cleared these out for me. Also, #2652782: Setting #input based on #base_type is unnecessary may have helped with some of these.
Comment #17
mmilano commented@markcarver thanks for the info. I see the other symptoms were unrelated to the saving issue now as the 3/16 dev release fixed them.
Comment #18
vasi commentedThe problem here seems to be in ActionsDropbutton::processElement(). When we put a button in $dropbuttons[$dropbutton]['#links'], we're taking it out of $form['actions'], so it doesn't get printed twice. But now it's not a child of $form anymore, so it can't get input! Drupal ends up unsure what the triggering_element was.
I've attached one possible solution. Instead of taking buttons out of $form['actions'], we leave them there, but just mark them as already printed. Drupal then makes sure not to print them again. It works, but I'd be happy if someone knows of a better way to accomplish the same thing.
Thanks to @jorgediazhav for his help with this.
Comment #20
markhalliwellAh, great catch @vasi. I think this approach is perfectly fine considering that the "dropbutton" component provided by core is really assumptive and difficult to "theme" properly with an existing framework like Bootstrap.
Comment #21
rdworianyn commentedThe Patch in #18 worked for me.