Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transactional Email improvements #121

Closed
pljspahn opened this issue Nov 8, 2012 · 2 comments
Closed

Transactional Email improvements #121

pljspahn opened this issue Nov 8, 2012 · 2 comments

Comments

@pljspahn
Copy link

pljspahn commented Nov 8, 2012

Is there any plans to introduce improvements to transactional email management?

Anyone who has worked with the transactional system to a moderate amount of depth understands that this area currently consumes an incredibly disproportionate amount of time to develop custom emails.

It is simply not practical to have transactional emails saved in the database, with one entry for each template that gets sent out. Making one simple change to all the templates requires each entry to be updated. So if you want to alter, say, font color, you have to run through each template and replace every inline style with the new value.

I have worked (in my spare time) on a module that introduces new backend sections for applying changes such as this globally across all templates; however, this essentially requires the store owner to completely bypass the default email template editor and work on the template files directly.

It would be great to see template variables (font-color, background color, link color, table size, etc) for this type of thing as well as separate templates for email header/footer (ie. make a change to header-email.phtml and have that be applied to all emails).

Additionally, I have built support into my email module that preprocesses the email through the "Premailer" API which converts all of your embedded styles into inline styles. This allows the development of the template to be much quicker since you can simply build your email template using embedded styles and before it is every processed by Magento, it converts these styles to inline. Massive time saver.

Email testing would also be great so that to actually generate/send an email to ensure design is accurate, we should be able to send a test email with placeholder values for variables that we can send directly from the backend without having to actually mimic the behavior required to generate the email as it would for a customer/user.

@amenk
Copy link
Contributor

amenk commented Nov 8, 2012

👍

@magento-team
Copy link
Contributor

Hello. There are no plans to provide additional email functionality right now. I assume the best way would be probably to integrate with a 3rd party service for newsletter and transactional emails.

vpelipenko pushed a commit to vpelipenko/magento2 that referenced this issue Mar 5, 2015
…5-add-getParams-setParams-to-request-interface

[Github] Merge public Github commits
mmansoor-magento pushed a commit that referenced this issue Jun 29, 2016
magento-engcom-team pushed a commit that referenced this issue Apr 13, 2018
MAGETWO-89443: Release New Version of ZF1
magento-engcom-team added a commit that referenced this issue Oct 4, 2018
 - Merge Pull Request magento/graphql-ce#121 from mhhansen/graphql-ce:fix-categorytree-root-regexp
 - Merged commits:
   1. 7b1c4dd
   2. 10afe1d
   3. 0ba4b71
   4. 93c3ded
   5. 4195613
   6. 4a355a0
   7. 590b84d
   8. cb7e807
   9. 481c7bf
   10. 3b04c94
magento-engcom-team pushed a commit to okorshenko/magento2 that referenced this issue May 31, 2019
slavvka pushed a commit that referenced this issue May 4, 2020
Login As Customer functionality is available when Login As Customer is disabled [fixed]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants