I upgraded from Drupal5 to Drupal6 and somehow my nice clean hand edited subscriptions_mail_digest template no longer worked. So, I uninstalled subscriptions, reinstalled it and have been trying to recreate the digest template.

Lots of luck - but all bad. I realize this is probably more a "mail editor" or "fckeditor" issue, but thought members of "subscriptions" were more likely to have a good response.

In the editing process there doesn't seem to be any consistency with things like href="!substitute". Sometimes with tags being inserted before and after, and on top of that symptoms seem to very amd are handled differently in the body and items. It's so ugly I've abandoned WYSIWYG editing, and I think maybe now it's time to abandon the "mail editor" itself.

Does any one have a nice, clean concise bit of HTML I can insert in the Digest Body and Digest Item that give a basic digest. Really, all I want to do is hide the URLs and have users click on a word to go to the links. Somehow the mail editor even seems to mangle my html on save.

I think the right workaround is to stuff the HTML directly into the database using some tool like phpmyadmin?

Which table(s) and which field(s)?

Any help with this appreciated.

Comments

Stranded’s picture

Stranded commented

I have located the templates in the mail_edit table and tried stuffing my HTML directly into them.

I still have no solution - the problem is I just don't get out what you would expect. For example -

In the digest section -

go to this <a href="!manage_url">link</a>

produces -

go to this <a></a>
href="http://civilandmilitary.org/user/1/subscriptions"&gt;link.<br></p>

in the digest that is received by members.

In the bodies section one link works, the others don't. Strangely -

Go direct to item <a href="!url">click here</a> or <a href="!unsubscribe_url"> unsubscribe</a>.</p>

produces -

Go direct to item <a href="http://civilandmilitary.org/node/223">click<br>
here</a> or <a></a>
href="http://civilandmilitary.org/s/del/node/type/summons/-1/1/c6e42b1d32bc4ed39077b1464104291a"&gt;<br>
unsubscribe.<br></p>

Weird how the first link works perfectly, the second one produces jibberish. The extraneous {br}, {/a} and {a}, and the genuine {/a} seems to be edited out, with an &gt stuck in. How is the substitution done? Where?

How can I fix?

Thanks for your help, and patience.

S

salvis’s picture

salvis
he/his
commented

Subscriptions and Mail Editor weren't designed with HTML mails in mind.

gregarios' recent #648600-3: Digest Item Count Variable/Token Hook Code Request post might help you to get going. Editing subscriptions_mail.templates.inc is certainly easier than pasting into the database, but you still have to be very careful to not disturb the structure (especially the quotes)! You'll have to delete those in the database in order to activate the defaults from subscriptions_mail.templates.inc.

I'm a bit surprised that the upgrade from D5 trashed your templates. Mail Editor (with the help of Subscriptions) should have offered you to convert the D5 ones to D6. Did you try this?

I have no idea whether trying to edit the templates with a WISIWYG editor has any chances of succeeding, but I'm not aware of any bugs in that area.

Stranded’s picture

Stranded commented

Yes, I did try the conversion. It gave results similar to my examples. Originally I thought that it was the conversion or upgrade process that went wacky, but the problem seems to be in whatever program expands the !substitution-fields to URLs.

Will have a look at subscriptions_mail.templates code. As a policy I generally prefer not to code so as to keep my world intact in the event of inevitable upgrades.

Thanks for the pointer.

What program does do that substitution?

S

salvis’s picture

salvis
he/his
commented

I agree about not hacking contrib, but I purposely extracted the default templates into a separate .inc file to minimize the impact.

The substitution is done in the function subscriptions_mail_template_preprocess() in subscriptions_mail.cron.inc. The conditionals rely on the {{ and }} delimiters, and inside those, the first question mark and the first colon after the question mark are hot characters. As long as you take care to not mess with those, it should work just fine. This code hasn't changed going from D5 to D6.

gregarios’s picture

gregarios commented

I agree about not hacking contrib, but I purposely extracted the default templates into a separate .inc file to minimize the impact.

It would be nice to be able to make it so a theme-directory based file could override the default subscriptions_mail_template file, ending any hacking of the Subscription module for the future.

salvis’s picture

salvis
he/his
commented

I've tried adding

| go to this <a href="!manage_url">link</a>
| Go direct to item <a href="!url">click here</a> or <a href="!unsubscribe_url"> unsubscribe</a>.

at the bottom of the default template in admin/build/mail-edit/subscriptions_content_node-type-forum/en.

This is delivered as

| go to this <a href="http://localhost:8601/user/1/subscriptions">link</a>
| Go direct to item <a href="http://localhost:8601/node/11">click here</a> or <a href="http://localhost:8601/s/del/node/type/forum/-1/1/f93f43601be7e9a8a667cf5ea4b2c5ae"> unsubscribe</a>.

— exactly as expected. (localhost:8601 is a test installation.)

I assume you're using an additional module to turn the text emails into HTML emails. Try turning that module off and see if the problems still persist.

salvis’s picture

salvis
he/his
commented

I'm not sure where we stand with this. Maybe here?

It would be nice to be able to make it so a theme-directory based file could override the default subscriptions_mail_template file, ending any hacking of the Subscription module for the future.

Yes, why not. I have no use for such functionality, but if someone wants to work on a patch I'll review and provide guidance...

salvis’s picture

salvis
he/his
commented
Status: Active » Closed (fixed)

I think we can close this. We have #652572: Support for Externalized Template Files, which goes into the direction I mentioned in #7.

As far as HTML mails are concerned, if someone wants to investigate this and finds a dedicated tester, I'm willing to consider patches, but I won't do any other work in that direction.