Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.The form alters don't check if the node exists yet, so changing the submit buttons always. It doesn't make sense (since the question is already asked, or the answer already posted).
Any objections against this change?
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | answers-1387452-7.patch | 1.15 KB | tim.plunkett |
| #6 | answers-1387452-6.patch | 1.07 KB | tim.plunkett |
| #5 | answers_submit_buttons_1387452_5.patch | 1.09 KB | tonymantoan |
Comments
Comment #1
hefox commented(Meh, using that status makes it ugly purple)
Comment #2
chipcleary commentedThis is a good issue ... it's right that it's confusing when you edit something but the label implies you are creating it for the first time.
I would like the labels to be clear and self-explanatory. I believe that the current labels are more clear for the common case: posting new questions or answers. At the same time, they are bad for editing.
I'd lean towards changing them in a way that reflects the situation, e.g.,:
I like to check other Q&A sites to see how they handle it. Mixed results. What I suggest above is close to drupal.stackexchange.com but answers.yahoo.com uses "submit" after a multi-step creation process.
Comment #3
hefox commentedMy vote would be to leave them (on the edit form) as what core sets it to (Save?) so that content editing is the same experience for the site.
Hm, if there was a module that could integrate with that provides renaming of submit button, then renaming of the buttons could be optional and overridable (course easy enough to add settings for something like this, though I prefer the optional integration route).
http://drupal.org/project/formtweak
http://drupal.org/project/nodeformsettings
http://drupal.org/project/content_type_extras
None match, but closest I found
Comment #4
chipcleary commentedUpdated for 6.x-2.x and committed.
Still to be ported to 7.x-3.x.
I ended up with:
- Ask Your Question / Update Your Question
- Post Your Answer / Update Your Answer
Comment #5
tonymantoan commentedHere is Drupal 7 patch for this issue using your text from comment 4. Note, that this an svn generated patch, so it won't apply directly with git, but should be fine with patch.
Comment #6
tim.plunkettLooks like the patch in #5 was rolled against 7.x-3.0, here it is against 7.x-3.x.
Comment #7
tim.plunkettBorrowed from
node_object_prepare(), theis_newflag needed to be checked as well.Comment #8
chipcleary commentedHi ... I've tested this and found that it works in my environment. Marking as fixed. I've also committed this to 7.x-3.x-dev. Thanks!