Closed (fixed)
Project:
Comment Notify
Version:
8.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
8 Sep 2007 at 03:20 UTC
Updated:
2 Mar 2019 at 01:14 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
lomz commentedIf you search for !site :: new comment for your post. in the localizer.module you can translate it.
Or you have to search for the same sentence in the comment_notify,module to change it the hardcoded way if you are using english drupal
Comment #2
gregglesYou can also use locale to translate from "english" to "my english" and then modify it.
I agree, though, it would be nice to be able to set the subject in some configurable way.
Comment #3
gregglesIf it happens it will be for 6.x.
Comment #4
zilla commentedcan you do this now with the 'string overrides' module without adding into this module (for time being)?
Comment #5
gregglesI believe so, yes.
Comment #6
zilla commentedhonestly, and i don't mean this to be darkly comical, i find the string overrides module most useful for getting rid of nerdy drupal language (it's all over the place, legacy text throughout drupal instead of plain language) AND for correcting output from modules developed by non-native english speakers who are trying to put out a first release in english only (things like "sing in here" instead of sign in etc...) - it's a very powerful little tool and keeps people out of core module files or other core drupal stuff...in my mind a perfect candidate for a 'core' utility ;)
Comment #7
gregglesIt is in core. It's called "locale".
String Overrides was developed to be a "light weight" solution beyond locale, but subsequent performance tests show that locale and string overrides are about the same speed.
Comment #8
zilla commented@greggles - didn't realize that...i know that people have used locale for the same purpose for a long time, the SO module just seemed to be a more intuitive way to handle minor edits and modifications for users who don't want to mess around with language related changes - and coupled with tools like form editors, it's quite useful...
Comment #9
guitarrasybajos commentedMee too,
Its a necessary feature.
Offtopic:
If you are using flat comments, users can not understand the “all comments” or “replies to my comment option”
Comment #10
gregglesQuite - better to open a new issue.
Administer > Site configuration > Comment notify. Disable the "replies to my comment" option. Then users will only see a checkbox and will no longer be confused.
Comment #11
guitarrasybajos commentedthey can still seen it in their personal menu (My account).
Comment #12
greggles@guitarrasybajos - #417582: if only one subscription mode is enabled, users should only see one option in their edit page
Comment #13
WildBill commentedJust wanted to steer this back to the original issue - the need for a customizable Subject field...
Comment #14
malclocke commentedAttached patch is against 6.x-1.x-dev, allows configurable subject for author and commenter emails and keeps defaults as they were. Same substitution variables are available as in the message bodies.
Comment #15
Offlein commentedPatch worked for me! +1
Comment #16
greggles"Works for me" is not a "review". Patches need a review prior to RTBC status.
My initial review makes me think that node_notify_default_mailsubject is not a great variable name (it follows pattern for other variables for this module, but it isn't properly namespaced with comment_notify at the beginning).
We also need to delete the variable comment_notify_default_mailsubject on uninstall.
And, ideally this should be done for 7.x first and 6.x only after that.
Comment #17
Offlein commentedGood points all. I get a little overzealous with my clicking-finger.
Comment #18
malclocke commentedMy initial review makes me think that node_notify_default_mailsubject is not a great variable name (it follows pattern for other variables for this module, but it isn't properly namespaced with comment_notify at the beginning).
Modified patch attached using comment_notify_author_mailsubject
We also need to delete the variable comment_notify_default_mailsubject on uninstall.
Not required as there is already a
DELETE FROM variable WHERE name LIKE 'comment_notify_%'inhook_uninstall()And, ideally this should be done for 7.x first and 6.x only after that.
Sorry, don't have a 7.x platform to test on.
Comment #19
crshumate commentedComment #20
tea.time commentedSeconding this request.
Comment #21
tea.time commentedHere's a fairly simple workaround that worked for me.
See: http://api.drupal.org/api/drupal/developer--hooks--core.php/function/hoo...
and: http://api.drupal.org/api/drupal/includes--mail.inc/function/drupal_mail/6
noting "The final e-mail id for e-mail altering will be {$module}_{$key}."
Sample code:
Comment #22
matt.rad commentedOld thread, but still interested in seeing this in the module.
Thanks.
Comment #23
gregglesThis is still waiting on a patch for 7.x.
Comment #24
acy76 commentedAttached is a patch against 7.x-1.2 which adds fields to the admin form for editing email subject lines. This patch simply exposes the existing variables for email subjects from inside the admin form. Please review.
Comment #26
pafla commentedStille no solution for D7
Pafla
Comment #27
acy76 commentedHere is a tweak of the patch in #24 -- sloppy diff on my part. Let's see if this passes testing.
Comment #29
tommyk commentedHere’s a patch to get this into the D8 branch.
Comment #30
damienmckennaFYI I've pulled these changes into a patch on #2618182: Support all entity types as commentable, not only nodes.
Comment #32
gnuget#2618182: Support all entity types as commentable, not only nodes has been fixed we can close this one as well.
Thanks!