Hello Morten!
Please have a look at this article:
http://world.episerver.com/en/Documentation/Items/Tech-Notes/EPiServer-CMS-5/EPiServer-CMS-5-SP1/Configuring-Subscription-in-EPiServer-CMS-5/
As you can see in the article each page where EPSUBSCRIBE is set to true will act as a root page, effectively enabling subscription for itself and its substructure. You should not set EPSUBSCRIBE to true for each and every page you wish to include in the subscription mail.
/Erik
Hi Erik,
This is not the case either, and that would not make sense since pages one want in a subscription is probably not even created at the time one signs up for a subscription.
I've read the article you are linking to and if I understand it correctly then I do not agree with the change in how the subscription works in CMS5 vs. CMS 4
Consider this example:
Let's say we have a page called News, this page has the EPSUBSCRIBE set to true, so you can get all the new news items published under the News page.
Let's also assume that we have Press releases page that has the EPSUBSCRIBE set to true, so you can get all the new press releases items published under the Press releases page.
Now the way the subscription job works in CMS5 is that it triggers the ISubscriptionhandler for EACH of the EPSUBSCRIBE pages, the result being that two e-mails are sent off to a user that subscribes to both News and Press releases.
In my opinion it should only trigger the ISubscriptionhandler for each EPSUBSCRIBE-ROOT page.
If one have to set the EPSUBSCRIBE-EXCLUDE on sub branches the shift is major. It's for a opt-in to an opt-out solution. And the EPSUBSCRIBE-ROOT has sort of lost its meaning.
Another consequence is that the subscription can't be as fine grained as in CMS4 without causing multiple e-mails being sent out to the subscribers.
//Morten
I had a quick look at the code and it seems that the subscription job indeed works in the way that you have described. I found no references to EPSUBSCRIBE-ROOT whatsoever so I guess that that property is obsolete (the article i linked does not mention it either).
It is apparent from the comments in the code that several mails are expected when a user is subscribing to several "roots" (News and Press releases in your example) so the behaviour is indeed by design. The article is wrong however, when it states that:
"[...] this means that a user subscribing to two subscription roots in two languages will receive one mail per language."
I will update the article.
I think the idea behind this is that it should be possible to have different intro texts/from addresses etc. for each subscription root. I will pass this information on to the EPiServer CMS product owner so that he can decide if this should be added as a feature request.
/Erik
Erik,
The EPSUBSCRIBE-ROOT is by no means obsolete, it's used to list all available EPSUBSCRIBE pages in the SubscriptionList web control for instance.
My understanding is that one uses the EPSUBSCRIBE-ROOT to have different texts/from addresses.
So subscription root shuld be == EPSSUBSCRIBE-ROOT and not EPSUBSCRIBE.
I'm still not convinced that the way it is now in CMS5 is the desired behavior, if it is you, as in EPiServer, have seriousy crippled the subscription routine in CMS5.
Regards,
Morten
I've only had a look at this in CMS5 SP 1. Here is the case.
The EPiServer.Personalization.SubscriptionJob.SendSubscription is changed from CMS4 to CMS5. It's changed in a way that I do believe it's wrong.
The case is that the new SendSubscription calls the subscription handler for each end every page that has the EPSUBSCRIBE proberty that has changed pages, and sends that off to the handler as the subscriptionpage. The result of this is that handler.Send method is called multiple times even though there is only one EPSUBSCRIBE-ROOT. So the user gets spamed with e-mail.
The old code had PagedataCollection that it added the changed pages to when it iterated over the SubscriptionItems, i.e. the pages with EPSUBSCRIBE, and only after all subscriptionitems had been spooled through did it send the pagedatacollection off to the handlers send method.
I've had a look at the old code vs. the new code in Reflector and it just is not right.
Anyone else noticed this behavior?
Regards,
Morten