Jump to content



Member Since 02 Aug 2016
Offline Last Active Today, 05:54 PM

Topics I've Started

Please Redesign The Structure Of The New Email Template Editors.

15 July 2018 - 05:55 PM



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' of block (perhaps less high, no deactivation button, etc.). 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

    - Responsive.less 

- Templates

    - Common

         - Variables.tpl (all available variables - left sidebar)

    - 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,

Mysql Database For A Large Number Of Products

20 March 2018 - 06:30 AM

7. after started website, on some time later(might be years later), I might will need to pay someone to customize entire system like this; each language will have their own separate table on database. because cs-cart company don't wants extra work for themselves and keeps all languages in one table. but if you search anything, MySQL server has to scan every records even if it's not included on those tables. for example, if you search in Russian Language anything, logically we know it's can't be found in arabic or chinese tables. so, why then MySQL server has to scan all those records? of course, in this case, you will have to have a separate URL stricture for every language and visitors will search from there. for example; ru.cs-cart.com visitors has to search only from Russian language tables. imagine that you have 1 million products, 10% of them has variation of 6. so, 100K * 6 = 600K + 900K = 1.5 million record and if you have 10 languages, it will be 15 million records. so, if someone wants search anything from Russian Language, why MySQL has to scan 15 Million records? it can be done with scanning just 1.5 millions records. but these things I will need to think very later, might be after years. but good to know now upfront now.




If you really have 1 million products then you won't have a simple setup. You will probably use Oracle database or such and not Mysql. However, if you really desire to use different languages then why not change the database all together? It is way easier to do, since you will only have to change the 'database' in the config field ('my_database' . CART_LANGUAGE) and change some session based values. You can also create functions / operations / triggers in mysql which would update the value across all the databases e.g. for the settings database.


Kind regards,

Add-Ons By Poppedweb: Full Page Cache

20 December 2017 - 07:32 PM

Hello guys,


As many of you know we have been working on a very sophisticated full page caching add-on. The day has finally come, meaning we will release it to the public. After hundreds of hours of work we have decided that as of right now there are plenty of features to work with (though more are on the way!).


The more products and visitors your store has, the higher load it has to withstand. If the number of products and simultaneous visitors exceeds the number a store and its server can handle, the store dramatically slows down and can crash.


Thanks to the latest improvements, such as full page caching and PHP 7 support, CS-Cart now works even faster than usual and handles a high load even with 125,000 products on board.


The full-page caching works without any extra server configuration, allowing your store to withstand a higher load and speed up page loading on the first and repeated visits up to 25 times. You can expect the TTFB to lower to 25ms!


This is how it works: when a customer opens a page, CS-Cart stores (i.e. caches) that page into memory. When another customer opens the same page, CS-Cart quickly retrieves it from memory. As a result, the second customer gets that page quickly - even on the first visit.


Performance Testing


To show the performance of a properly configured CS-Cart store with full-page caching, we created a highload demo store and tested its stamina.


For testing we have made a program which will test the load and will check for the TTFB of the HTML page. This resulted in the following impressive graph (this is first load with fully initialized sessions).




Why you need Full page cache addon:


Your website will get a significant performance boost, resulting in happier customers and possibly a better conversion rate as well.

Under load your website will perform better, allowing for more visitors at once.

Because you website's TTFB (Time To First Byte) is reduced, your SEO will be ranked higher.


Why you should use this Full Page Caching addon:


A database is not used to store the statuses of the files. Instead, they are stored using a custom file / storage engine that can detect if the file is valid.

Intensive PHP functions have not been used, this includes but is not limited to: preg_match, preg_match_all and str_replace.




Does it work with HTTPS? - Yes.

Does it support multiple languages / auto language detection? - Yes.

Does it allow multiple currencies? - Yes.

What if I update a product / a category / a page? - The affected cache will be removed.

What do you mean with no database? - Files are stored using a defined set of parameters. It will use default php functions to read the file age, file existence and many more things to refrain from the database.




- Hole punching (allows you to remove blocks from the cache, e.g. recently viewed) (3rd week).

- Backend that will allow you to see the file storage in a more efficient manner (3rd week).

- Auto CRON jobs that will be queried from our server if neccessary (e.g. for garbage collection and such) (4th week).

- Store the keys / values for hole-punching in redis / memcached / file cache (5th week).

- Preload data which is queried from the database into a file (which can be stored in redis / memcached / file cache) (6th week).


Have we intrigued you?


If you have any questions, feel free to ask us in either the thread or via e-mail: info@poppedweb.com 

You can buy the add-on at: https://poppedweb.co...ull-page-cache/