Why not use the ordinary umbraco pages as the newsletter? Ie let umbraco process the page, grab the output and store it as the newsletter content. This would allow developers to make higly complex newsletters with custom fields, razor snippets and so on.
Developers would need to be able to specify which doc type, and maybe which template to use. Ie one template for web browser and one for email.
That's a great idea and something that we did think about but decided to go another way. The main idea is to keep Newsletter Studio independent from the doc types, content tree, templates and so on. This have the benefit of a cleaner back office and that everything that has do to with the newsletters are handled in the newsletter-section.
But I do agree that macros could be practicall, even though I think that a good newsletter should be written by a real person who can filter lists and pick the best content from de different sections.
If this is something that alot of the users requests we may look at a way to change this in the future.
+1 (but you know already). Good newsletters can also sum up addional content. Typically we do refer to already written content. I dont understand the goal with separation from doctypes/templates. It could still be maintained from the separate newsletter section.
We also would like to use already written content from the website and combine it with new specfic content. Thats why if you allow other "developers" to use umbraco doc types and templates we could tweak the functionallity to specific needs for our end users.
Otherwise this is a great product and seam to do its work.
First. I really appreciate all the feedback and trying hard to improve the product.
I would like to hear more about how this could work.
What will the doc type do and will the newsletters be present as content i the content tree? Or is it mostley the templats we are talking about?
Would it be a good idea to just include macros in the current editor and make sure that they renders correct?
Anders (& Jesper, but you already know): There will be a "plugin-structur" in the up coming version where you could create custom "RenderTasks" which can be used to preform rendering, replace custom mergefilds, insert custom analytics, swap out stuff that you don't want and so on. The will be perfomed both on a template level and on each uniq email so that it can be personalized.
This package has a potential use on one website I built / manage. Currently newsletters are sent via a 3rd party system which means there is no link between newsletter and website.
I would really like to be able to create a newsletter and send it out ... to members defined in Umbraco (via the current Membership Provider) - I would also like that newsletter to be (ideally automatically) visible on the website. That seems to require the newsletter to be built using "normal" Umbraco nodes?
Doctypes and templates are handled as normally in Umbraco. Newsletter content is ordinary umbraco content visible in content tree. When you create a new newsletter in newsletter studio, one selects the newsletter "page" that is the content. The doctype and template specfifcation was just for filtering in the newsletter studio which pages that can be selected, and the template for which template the newsletter page should be rendered with, as one might want to have another default template for "normal web rendering". Your newsletter app should then do a http request and process the page selected and just grab the html code and make it "static". You could combine this with the rendertasks that you describe to tweak the mail even more with name and such for each user.
The point is when you "process" the newsletter you generate a static html of it. It would be a nice feature to push back to the content page what the static sent out newsletter was so that can be rendered when browsing the site for old newsletter where related content has been changed.
@Gordon - Nice to hear that you are interesed! The current version has support for umbraco site members. Are you using a custom membership provider or the one that ships with umbraco? If you are using a custom provider you can't use the "Newsletter"-bool on each member becuse that depends on the umbraco Member API. The trail version will work fine and can send newletters to 20 subscribers. If you need more testing just let me know and I'll provide you with a temporary license.
About listing the letters on the site there is no out of the box solution right now but the talks with Jesper & Anders may take that requirement futher.
@Anders - I think I understend what we are looking for. The most important and "must have" is the macro rendering. About moving letters into the content tree and skinks to setting/templates I think that less important?
@Anders agin. The more I think about it and test it i really like your idea with content nodes/doc types and templates as the foundation. I see a great potential.
Yes, you get the power of Umbraco for content / templating, building such functionallity on your own is hard. And all Umbraco devs already know the umbraco templating engine :-)
It could be optional to show the node in the content tree as well (some sort of config). Only problem is mergefields and so on. Ie. If you add [name] to the bodyText in the node. Umbraco will not replace that when looking att the content on the web. I hope there is a way to hook into the rendering of the page? That would solve this issue. Any one knows?
Optional showing the node? I was under the impression that you really should just let each newsletter be in the content tree visible for the editors. Ie you have 2 entries for a newsletter, one content node and one "node" in your app that has the basic settings and points out which content node is related to that "newsletter".
If you mean moving a content tree into you app section you need to look into the tree render node events. There you can hook into a specific icon for the doctype, like giving an icon a hide name. That way you can check icon name, if contains hide, remove from rendering. I have code for that if you want some exampels.
The replacing of [name] is more difficult if you mean if one allows "newsletter" nodes to be browsed frontend. Then you never know which "user" browses the site. But then again should proberly be handled by the dev implementing the newsletter function. The default show in browser should perhaps be handled as today, take the "static" html that you grabed from the content node during send out and process all "tags" in that html and replace.
I have already done some testing with the node-rendering. To make it just don't render a specific doctype. I would love to see your code, I may have missed something. My contact is markus (an at sign) enkelmedia.se.
If you are using a custom provider you can't use the "Newsletter"-bool on each member becuse that depends on the umbraco Member API.
Not quite sure what you mean by that, but yes - I am using a curstom membership provider. Is the above about allowing a member to un-subscribe? If so, could I build it in somehow (API?)?
I have finally got round to installing this ... and it looks great! Assuming the customer continues to be happy an order will be heading your way soon !!
I have another possible use, but the editor (Tiny MCE?) will be a turn-off. They currently use a dedicated newsletter system but the editor is similar and they find it extremely dificult to use. Trying to add in extra sections or move sections, etc usually ends in a call to me!!
If the newsletter could work with the standard Umbraco content nodes then I could allow them to create a newsletter by adding "component" parts, such as a 2 column box, a full width box, etc, etc. So, if you move the Newsletter Studio in that direction my client would be over the moon with excitement!!!
@Gordon! If I understand you right you're not using the built in Umbraco Membership, you have implemented you own MemebershipProvider? Troubble is that Umbracos current membership implementation is a mix up beetween standard ASP.NET membership and the Umbraco Members implementation. Please let me know if you experience any problems due to this.
About the editor. I don't understand? The editor in Newsletter Studio is exactly the same as in other parts of Umbraco? You could use the template-feature. This would allow you to insert html-parts into the letter. It could be a whole table-structure or just small pices. Would this fit you´re needs?
EDIT: I would like to "tease" a little. The next major release will contain a feature called "Render Url". Where you could inset content from any url into the letter at rendering. Ie you could set up a newsletter-structure in the content section and use regular templates/macros to render this as a front end page. Then, using a custom umbraco-template provide a "rendering template" that newsletter studio could call. Something like this: [RenderUrl:http://www.mysite.com/newslettersAsContentNodes/mynewsletter/NameOfMyCustomUmbracoTemplate.aspx]
This would allow you to render the whole newsletter from the content node or just parts. The url can be both internal and extarnal. Ie. it could go of and get news at some other site and merge that into the newsletter.
Markus - yes, we have implemented a custom membership provider. Actually, recipients would not be given the option to unsubscribe, so maybe it would be OK?
It didn't register with me that you could continually select a template and insert it!! The only issue is getting the small sections to fit together ... I'll give it some thought.
Now then - Mr. Tease - when can we expect this next major release? That would do EXACTLY what I want!!!! :-)
@Gordon. The first version talked only to the asp.net membership-parts but the current release gets the "Member.Text"-property from the Umbraco API (The name of the subscribers). I'll keep this issue in mind (or to be exact in the backlog) and try to make sure to find a good way to handle this in the next release which will be in about 2-3 weeks. If you need to test stuff i could make a custom build for you that you could use for development until the next release. Send me an email markus [a sign here] enkelmedia.se
@Gordon - The things that we are talking about in this post should all the solved in the current version of Newsletter Studio (1.2) and we're close to a release with mysql support. If you would like to try the beta send me an email at markus [at sign goes here] enkelmedia.se
Using umbraco pages as content for newsletter
Why not use the ordinary umbraco pages as the newsletter? Ie let umbraco process the page, grab the output and store it as the newsletter content. This would allow developers to make higly complex newsletters with custom fields, razor snippets and so on.
Developers would need to be able to specify which doc type, and maybe which template to use. Ie one template for web browser and one for email.
Just a thought.
Hi!
That's a great idea and something that we did think about but decided to go another way. The main idea is to keep Newsletter Studio independent from the doc types, content tree, templates and so on. This have the benefit of a cleaner back office and that everything that has do to with the newsletters are handled in the newsletter-section.
But I do agree that macros could be practicall, even though I think that a good newsletter should be written by a real person who can filter lists and pick the best content from de different sections.
If this is something that alot of the users requests we may look at a way to change this in the future.
Hi Markus,
+1 (but you know already). Good newsletters can also sum up addional content. Typically we do refer to already written content. I dont understand the goal with separation from doctypes/templates. It could still be maintained from the separate newsletter section.
best
Jesper
We also would like to use already written content from the website and combine it with new specfic content. Thats why if you allow other "developers" to use umbraco doc types and templates we could tweak the functionallity to specific needs for our end users.
Otherwise this is a great product and seam to do its work.
First. I really appreciate all the feedback and trying hard to improve the product.
I would like to hear more about how this could work.
What will the doc type do and will the newsletters be present as content i the content tree? Or is it mostley the templats we are talking about?
Would it be a good idea to just include macros in the current editor and make sure that they renders correct?
Anders (& Jesper, but you already know): There will be a "plugin-structur" in the up coming version where you could create custom "RenderTasks" which can be used to preform rendering, replace custom mergefilds, insert custom analytics, swap out stuff that you don't want and so on. The will be perfomed both on a template level and on each uniq email so that it can be personalized.
This package has a potential use on one website I built / manage. Currently newsletters are sent via a 3rd party system which means there is no link between newsletter and website.
I would really like to be able to create a newsletter and send it out ... to members defined in Umbraco (via the current Membership Provider) - I would also like that newsletter to be (ideally automatically) visible on the website. That seems to require the newsletter to be built using "normal" Umbraco nodes?
My idea is this.
Doctypes and templates are handled as normally in Umbraco. Newsletter content is ordinary umbraco content visible in content tree. When you create a new newsletter in newsletter studio, one selects the newsletter "page" that is the content. The doctype and template specfifcation was just for filtering in the newsletter studio which pages that can be selected, and the template for which template the newsletter page should be rendered with, as one might want to have another default template for "normal web rendering". Your newsletter app should then do a http request and process the page selected and just grab the html code and make it "static". You could combine this with the rendertasks that you describe to tweak the mail even more with name and such for each user.
The point is when you "process" the newsletter you generate a static html of it. It would be a nice feature to push back to the content page what the static sent out newsletter was so that can be rendered when browsing the site for old newsletter where related content has been changed.
@Gordon - Nice to hear that you are interesed! The current version has support for umbraco site members. Are you using a custom membership provider or the one that ships with umbraco? If you are using a custom provider you can't use the "Newsletter"-bool on each member becuse that depends on the umbraco Member API. The trail version will work fine and can send newletters to 20 subscribers. If you need more testing just let me know and I'll provide you with a temporary license.
About listing the letters on the site there is no out of the box solution right now but the talks with Jesper & Anders may take that requirement futher.
@Anders - I think I understend what we are looking for. The most important and "must have" is the macro rendering. About moving letters into the content tree and skinks to setting/templates I think that less important?
@Anders agin. The more I think about it and test it i really like your idea with content nodes/doc types and templates as the foundation. I see a great potential.
Yes, you get the power of Umbraco for content / templating, building such functionallity on your own is hard. And all Umbraco devs already know the umbraco templating engine :-)
Yes!
It could be optional to show the node in the content tree as well (some sort of config). Only problem is mergefields and so on. Ie. If you add [name] to the bodyText in the node. Umbraco will not replace that when looking att the content on the web. I hope there is a way to hook into the rendering of the page? That would solve this issue. Any one knows?
Optional showing the node? I was under the impression that you really should just let each newsletter be in the content tree visible for the editors. Ie you have 2 entries for a newsletter, one content node and one "node" in your app that has the basic settings and points out which content node is related to that "newsletter".
If you mean moving a content tree into you app section you need to look into the tree render node events. There you can hook into a specific icon for the doctype, like giving an icon a hide name. That way you can check icon name, if contains hide, remove from rendering. I have code for that if you want some exampels.
The replacing of [name] is more difficult if you mean if one allows "newsletter" nodes to be browsed frontend. Then you never know which "user" browses the site. But then again should proberly be handled by the dev implementing the newsletter function. The default show in browser should perhaps be handled as today, take the "static" html that you grabed from the content node during send out and process all "tags" in that html and replace.
I have already done some testing with the node-rendering. To make it just don't render a specific doctype. I would love to see your code, I may have missed something. My contact is markus (an at sign) enkelmedia.se.
I've been trying to replace content in the before a document goes into the cache but that did'nt do the trick. I made a post in the forum to see if anyone else has any ideas. I have no doubt that it could be done in some way. http://our.umbraco.org/forum/developers/api-questions/27822-Hook-into-the-rendering
If you are using a custom provider you can't use the "Newsletter"-bool on each member becuse that depends on the umbraco Member API.Not quite sure what you mean by that, but yes - I am using a curstom membership provider. Is the above about allowing a member to un-subscribe? If so, could I build it in somehow (API?)?
I have finally got round to installing this ... and it looks great! Assuming the customer continues to be happy an order will be heading your way soon !!
I have another possible use, but the editor (Tiny MCE?) will be a turn-off. They currently use a dedicated newsletter system but the editor is similar and they find it extremely dificult to use. Trying to add in extra sections or move sections, etc usually ends in a call to me!!
If the newsletter could work with the standard Umbraco content nodes then I could allow them to create a newsletter by adding "component" parts, such as a 2 column box, a full width box, etc, etc. So, if you move the Newsletter Studio in that direction my client would be over the moon with excitement!!!
@Gordon! If I understand you right you're not using the built in Umbraco Membership, you have implemented you own MemebershipProvider? Troubble is that Umbracos current membership implementation is a mix up beetween standard ASP.NET membership and the Umbraco Members implementation. Please let me know if you experience any problems due to this.
About the editor. I don't understand? The editor in Newsletter Studio is exactly the same as in other parts of Umbraco? You could use the template-feature. This would allow you to insert html-parts into the letter. It could be a whole table-structure or just small pices. Would this fit you´re needs?
EDIT: I would like to "tease" a little. The next major release will contain a feature called "Render Url". Where you could inset content from any url into the letter at rendering. Ie you could set up a newsletter-structure in the content section and use regular templates/macros to render this as a front end page. Then, using a custom umbraco-template provide a "rendering template" that newsletter studio could call. Something like this:
[RenderUrl:http://www.mysite.com/newslettersAsContentNodes/mynewsletter/NameOfMyCustomUmbracoTemplate.aspx]
This would allow you to render the whole newsletter from the content node or just parts. The url can be both internal and extarnal. Ie. it could go of and get news at some other site and merge that into the newsletter.
Markus - yes, we have implemented a custom membership provider. Actually, recipients would not be given the option to unsubscribe, so maybe it would be OK?
It didn't register with me that you could continually select a template and insert it!! The only issue is getting the small sections to fit together ... I'll give it some thought.
Now then - Mr. Tease - when can we expect this next major release? That would do EXACTLY what I want!!!! :-)
@Gordon. The first version talked only to the asp.net membership-parts but the current release gets the "Member.Text"-property from the Umbraco API (The name of the subscribers). I'll keep this issue in mind (or to be exact in the backlog) and try to make sure to find a good way to handle this in the next release which will be in about 2-3 weeks. If you need to test stuff i could make a custom build for you that you could use for development until the next release.
Send me an email markus [a sign here] enkelmedia.se
// Markus
The development of that project is a little way off yet, so you may well have released your next version by then. if not, I'll contact you :-)
I see! Just let me know if there is some feature that you would like to have in the package!
@Gordon - The things that we are talking about in this post should all the solved in the current version of Newsletter Studio (1.2) and we're close to a release with mysql support. If you would like to try the beta send me an email at markus [at sign goes here] enkelmedia.se
is working on a reply...