@belg4mit,
I don’t think I understand fully what you are asking for here. Is you site only accessible via https? If so this can be handled in the WordPress configuration and with entries in .htaccess can’t it?
Or is some of your content protected? And if that’s the case how can Subscribe2 detect what’s secure and what’s not in order to produce the correct links?
>Is you site only accessible via https?
No it’s accessible via both, but as I said, different groups use
HTTP and HTTPS.
>And if that’s the case how can Subscribe2 detect what’s
>secure and what’s not in order to produce the correct links?
It doesn’t have to. The users that get the updates only use HTTPS.
Details were omitted for simplicity/clarity but apparently the
general case is insufficient. The public uses HTTP and does not
subscribe. Staff use HTTPS and are subscribed. We would like for
the updates to use HTTPS URLs so that staff traffic remains
segregated from the public’s.
@belg4mit,
Right, now I understand what you mean. That’s not an easy fix really, certainly not within the current code.
One possible way, if you are interested, would be to use on of Subscribe2’s filters that contains the email body content, take this as input and replace all instances of http:// with https:// before returning the ‘corrected’ body content.
Would that work for you?
Yes, that would work. What is the filter name? I don’t see anything in the FAQ, and nothing stands out when I grep the source code.
@belg4mit,
If you grep for “apply_filters(” you’ll find all the lines where I’ve got filters but I think you’ll need ‘s2_html_email’ and ‘s2_plain_email’ which are both in the header() function in the class-s2-core.php file.
In both cases the first parameter passed is the content of the email so you can then str_replace(“http://”, “https://”, $message);
I used:
#https digest links to separate access log entries
function rebase_digest($message){
return str_replace("http://", "https://", $message);
}
add_filter('s2_plain_email', 'rebase_digest');
add_filter('s2_html_email', 'rebase_digest');
It works fine for the test sent from the settings page,
but seems to cause failure of delivery for the actual message (digest) :-/
@belg4mit,
For digest emails you need to use a different hook. Try hooking you function to ‘s2_digest_email’.
I’m not sure why that should allow the preview message to work okay but cause the normal delivery to fail, however I’ll try it, thanks.
