Jump to content

  • You cannot start a new topic
  • You cannot reply to this topic

Please Redesign The Structure Of The New Email Template Editors. Rate Topic   - - - - -

 
  • poppedweb
  • Authorized Reseller
  • Members
  • Join Date: 02-Aug 16
  • 433 posts

Posted 15 July 2018 - 05:55 PM #1

Hello,

 

We, PoppedWeb, have had our problems here and there with the new email templates. We think there is much room for improvement and after suggesting multiple things in private conversations (with no reply), we thought it would be a good idea to take this to the fora.

 

First of all, the structure couldnt be worse. We can't grasp why you would choose Twig, a new language with a new learning curve, over Smarty as the renderer. Not only is the developers environment completely compromised because of this, it also is very unfriendly to the CS-Cart users themselves. 

 

But lets get to the 'ideal' structure (in our opinion):

 

1. If Smarty were to be used, the code for the layout builder could have been re-used, variables could have been defined as a new 'type' and best of all you could drag and drop and create the email layout like that. This would have been much more useful for the CS-Cart users.

 

2. Use the same structure as we currently use for theme development. Adding new variables or adjusting variables is very chaotic at the moment. In Smarty we could just assign it, retrieve it, etc, now we have to write entire classes just to adjust / give a new variable to Twig.

 

3. Custom e-mail template development is very hard since it is stored in the database. Furthermore, having actual files would reduce the overall load on the database. There is no IDE which supports templates saved in a database, which also adds another disadvantage for the 'amazing developer ecosystem', as advertised by CS-Cart.

 

4. A simple layout could look as follows:

- Styles

    - Addons

        - [Addon ID]

            Styles.less

    - Styles.less

    - Responsive.less 

- Templates

    - Blocks 

        - Blocks like 'contact us' or a banner.

    - Views

         - Blockmanager (theme).

         - Index (load styles in header & other parameters)

    - Variables - all variables which can be added in the layout editor as a seperate template (so they can be overridden / adjusted!).

 

5. Add the option for responsive styles. Yes, responsive e-mail templates is an actual thing. This is used a lot and is currently not 'really' possible.

 

6. Products tables and such can be edited more easily by just editing the block settings.

 

We think this 'rough' sketch could be a good starting point, it would be great if the rest of the developers can take a quick look and refine the initial step to a better overall e-mail development system.

 

Kind regards,


PoppedWeb | sales@poppedweb.com | https://poppedweb.com
TurnKey Website Design | Add-Ons | Performance Audits | Dedicated Server Management
24/7 Support | Response within an hour (during working hours).

 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 10912 posts

Posted 15 July 2018 - 07:53 PM #2

I think they chose Twig as an experiment to see how it would be working with new template methods. 

I like smarty better, but probably mostly due to my familiarity.  But Twig does have many restrictions and missing methods that would be very useful if time was spent to extend it properly (hooks, complete Boolean operators, access to functions as modifiers without having to declare them in PHP, etc.)

 

The biggest issue is lack of hooks and having everything layered into the DB.without a way for an addon developer to create a document and then export it in a form that can be used for a distribution (without impacting other things). 

 

Variable assignment (from other objects) is way too complicated for the task at hand.  Snippets seem to be able to be updated/created (see vendor_plans) but have yet to see where a document can be created.  Things like gift_certificates are distributed with the documents already created in the DB (whether GC is installed or not) rather than having the code show the best practice for doing so.

 

All of your points were brought up by me to cs-cart developers when this was first discussed.  But feedback from addon developers was ignored (usual) and feedback from merchants was only based on the interactive side of things.

 

To add a field to the order_data and then access it via the get_order_info hook and smarty is a snap, then using a template hook or override to display the new variable is easy.  Doing the same in this monstrosity takes hours with multiple custom objects required to implement it.  And if you needed to create a new document with it's own snippets, it's hours of development to just do simple things.  Any any changes to a document obliterate the previous unlike an override which preserves the originally distributed content.

 

Good luck!


EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.