Since I've heard - more than once - that users would like to send HTML notifications with MT-Notifier, and because I'm still working out the details on how to make it work more simply within the plugin itself, I decided to put together an entry on doing it yourself. It does take a bit of work, but assuming you are using a recent version, you can make it work with very little effort.
First, please make sure you back up your current files. And if you have real, live subscribers, you might want to let them know that you're about to play with your templates, so that they understand that you might send them something that they can't read. Ready? Let's move on!
While most of the work needs to be done in your notification template files, you need to make a change - perhaps two changes - to another file in order to send out HTML notifications before those changes will matter. So load up Notifier.pm in your favorite text editor. You did make a backup, didn't you? Good.
There are two places that you might want to change. The first, near line 120 in version 4.2.2, is for confirmations - the message sent out to make sure that people want to subscribe to notifications. The second is around line 290. Other than that, they look about the same (names are slightly different):
my %head = (
'From' => $sender_address,
'To' => $data->email,
);
What you want to do here is add another field into that hash (that's what the variable is called). Just make sure you get it inside the hash, or you might break something. It would look like this when you are done:
my %head = (
'From' => $sender_address,
'To' => $data->email,
'Content-Type' => 'text/html',
);
There are a few important parts here.
- Make sure there is a comma after each of the fields in the hash.
- After email in the example above is a good place to check.
- Make sure that Content-Type is capitalized as you see here.
- Make sure that Content-Type is spelled correctly.
- Make sure that text/html is spelled as you see here.
- Make sure that the slash is facing the correct way (not a backslash).
- Repeat for both confirmations and notifications if you want.
Once you make this change, you are ready to send HTML.
Now you just have to edit the template. The major change is that HTML ignores whitespace, notably line breaks. Where you see these breaks in the standard templates, there will be none. The simplest change is to add a <br /> where the lines end so that it will look just like you are used to seeing. You may also want to add links by way of anchors so that they will be clickable.
Beyond that, the sky is the limit - you can add styles and images (by links, embedding is not possible, and also not a good idea), so make whatever changes you feel like making.
At this time, the only limitation you have is that there is a single template for all blogs in the system. In other words, when you make changes to your template, please realize that it will affect every blog. You may be able to get around this through the use of some creative conditional templating, but this has not been tested. This is a part of why I have not added this functionality to the plugin itself as yet.
Good luck!
Hi Chad,
I've been a licensed Notifier user for a few years. I just installed the latest Version (4.2.3) on MT 4.25 pro and MT 4.32 pro and I think we are working. I also followed your procedure for HTML notices. Sweet!
I have a couple questions:
1. In a prior version installed we were able to manually create blog level subscriptions for our members on the Manage Subscriptions UI. It appears that capability went away. I don't see it on either of my MT version installs.
2. On the Blog level Plugin settings there is an option to select an Override. I can't find this documented as to what this does. Can you explain?
3. Last year I made an inquiry about how to force Blog level subscriptions to also send any and all comments. You gave me a simple hack to Plugin.pm to accomplish this. This version has code changes but I think it would be this line to comment out:
$terms{'entry_id'} = $obj->entry_id;
in sub notify_comment
Will this do the same for me?
I appreciate your guidance.
Merv
Hi Merv -
1. Unfortunately, due to changes in the template design, the ability to add subscriptions within the management interface is no longer there. It's possible that it will get added back in one day, but it's because of changes made by Six Apart to the templates - it just looks ugly, and I'm not a big design guy. The functionality exists, but I don't have the time to redo the templates to make it look right. You'll need to use manage->blogs to add these subscriptions on the back end.
2. This is actually the option you want, I believe. The override gives you all comments across the blog, without having to modify the code, as you ask in your third question. It's just not the default behavior.
3. The reason that the function was added is that it's a bit more complex than removing the blog_id - you also have to take into consideration the category subscriptions, so I added that code into the function. Just check the correct selection and you're off.
Chad,
Thanks for the quick response. I was guessing question 2 and 3 were related.
Notifier 4.2.3 really does work in MT 4.3.2.
I'll try the que next to help speed up comment publishing. It should, shouldn't it?
FYI: I tried signing in to comment and received an unformatted page with a link to TypePad sign in. Clicking the link did nothing.
The queue should speed up comment publishing, but it will not really affect notification processing (it may slow it down in fact - especially if you forget to schedule the send task!).
Thanks for the note about the sign-in. Looks like the TypePad registration flag was stuck on for some reason. Had a devil of a time turning it off (had to do so manually in the database before it would stay that way).
Hi Chad,
I maintain a huge Blog with over 500 entries and periodically we do entry maintenance cleaning up past entries including adding appropriate categories, splitting a long Body into Body + Extended, reorganizing categories, etc. Is there a way to NOT to send notifications if an entry is modified? We don't want to resend these notices.
On the same subject ...
If we temporarily Block notices to subscribers during our maintenance activity then rebuild the entire blog, when we Unblock notices will modified entries be sent based on History at some point? We don't want them to be sent.
Your guidance is always appreciated.
Merv
Hi Merv -
With a recent version of MT-Notifier, you could turn on the bypass switch so that no notifications are sent to users who have subscribed since the entry was originally written.
This way, any users who have already been notified would be covered (via history), as would those users who have not yet been notified because they subscribed after it was written.
In order for this to work, you would have to turn on the system and blog-level bypass switch. So if you have a single blog, you would probably be okay. If you have a number of blogs, it would probably be more difficult.
After you are done, you could turn it off - or just leave it in place. History is always respected.
Chad,
I have 4.3.0 installed and have the following questions:
1) I can't find the html modification code in Notifier.pm. Are you now depending on MT::Mail for $header parameters? If so, I have never been able to get that to generate html emails.
2) I have always had to hack Plugin.pm as follows to generate comment notices on blog subscriptions as discussed in previous comments above:
comment this line ...
#$terms{'entry_id'} = $obj->entry_id;
in sub notify_comment
I can't find the similar code in Plugin.pm
What does
Allow Blog and Category Subscription Comment Override
in the settings really mean and do? I could not get this to work for me the same as the hack you subscribed.
Again, I appreciate your guidance.
Merv
Hi Merv -
1. The location will depend on the version you are using. Search for %head and you should be able to find it. In the OS version of 4.3.0, the first instance of %head is at line 128, the second is at line 297. Not too far off from the above examples. The licensed version has them too, but the location changes a bit due to the comments at the top being of a different size.
MT::Mail is being used. It has been for some time, mostly because I got tired of maintaining the code to send mail. But also because it's a lot more robust than my version ever was. As long as you use the code above, specifically the case of the parameter (Content-Type needs to be capitalized in that way), and you need to specify text/html as the value, you should be fine.
You may also want to include a MailEncoding value in your config file. If you don't, it will default to the PublishCharset of your config file.
2. The code you describe no longer exists. It was replaced with the Comment Override parameter.
If this parameter (blog_all_comments is the name) is set, then the entry_id is removed from the search and all subscriptions across the blog are loaded, as well as all categories for the comment's entry (from the comment, not from the entry id that was removed), then the notifications are sent to those subscribers.
This may or may not work correctly, because you may be the only one using it - you are definitely the only one who has mentioned anything thus far!
This is towards the bottom of the notify_comment subroutine in Plugin.pm.
If you find problems, feel free to submit changes directly to me or via GitHub - the OS code is posted there.
Chad,
There is nothing in the 4.3.0 Notifier.pm that defines Content-Type. ?????
Am I looking in the wrong file?
Merv
Hi Merv -
The Content-Type value isn't there now, which is why it uses the default (which is text/plain). You need to add it through the process described above, in the entry itself.
Chad,
Of course ... for some unknown reason I thought the Content-Type -> 'text/plain' was already in the code.
I can read Perl code enough to be dangerous. It must be the case that Notifier.pm will override the Content-Type -> 'text/plain' in Mail.pm. That being the case, should I be able to set the Content-Type in Mail.pm instead (MT system level hack)? Then, all MT notice emails would be sent HTML.
Thanks,
Merv
Hi Merv -
It's not so much that MT-Notifier overrides the value in Mail.pm as that any header value passed in will set the value, meaning in this case it will use the new value as opposed to using the default (which is set to text/plain).
So if you want to use something else, such as text/html, across the board, you could make the change in Mail.pm instead.
However, be aware that you'll need to modify all your notices so that they send HTML-formatted data (namely using linebreaks - bold, italics and whatnot are optional).
Otherwise you're going to get a jumbled mess instead of nicely-formatted mail!
Thanks for the quick responses. I have a Notifier 4.3.0 fresh install with no modifications. When I click the link to install the widgets I am getting this error:
Can't call method "can_edit_templates" on an undefined value.
Also, using the 4.2.3 blog subscribe widget (which appears to be the same as in 4.3.0) causes this error:
Unknown action verify_subs
I uninstalled Notifier before installing 4.3.0.
I am on MT 4.32
All of the files appear to be in place as per your install instructions.
Merv
Hi Merv -
I'll have to take a look at the permissions issue, as I don't know what is causing the problem.
As to the other item, the issue is because I failed to update the tag. Instead of <mt:adminscript>, you should use <mt:commentscript>.
In the meantime, you can always set up your widgets manually using this code.