Why was CartCleanupTask changed from an HourlyTask to a BuildTask?

[Hans de Ruiter]

I've just been working on getting cron set up correctly for scheduled tasks (I had a permissions problem), and noticed that CartCleanupTask was changed to be executed manually only instead of hourly in version 1.0. I'm curious as to why, because I think that it is quite handy to have it execute automatically on an hourly basis. Having to manually execute it looks like a chore that is easily forgotten.

The only problem with the old version (i.e., 0.9), is that CartCleanupTask doesn't do anything, because it lacks a process() method (it has a run() method instead). CliController calls process() on scheduled tasks instead of run() (which is what BuildTasks use).

Hans

[Nicolaas Thiemen Francken - Sunny Side Up]

Hi Hans

Thank you for your question.  

It is my intention to make e-commerce in such a way that it runs without needing any cron jobs.  This means that in later versions I actually remove the "old carts" every time a new cart is created.

Here is a fragment from ecommerce/code/control/ShoppingCart.php:

if(!$this->order) {

//here we cleanup old orders, because they should be

//cleaned at the same rate that they are created...

$cleanUpEveryTime = EcommerceConfig::get("ShoppingCart", "cleanup_every_time");

if($cleanUpEveryTime) {

$obj = new CartCleanupTask();

$obj->runSilently();

}

Does that answer your question?  

Nicolaas

[Hans de Ruiter]

Hi Nicolaas,

Yes, that makes sense. 

BTW, I'm currently working on delaying the creation of Order objects until a user adds an item to their cart. This is because I noticed that new orders are created even when bots visit my site, so I'm ending up with thousands of pointless entries; like >20,000 pointless entries per month. That's a lot of wasted database space and unnecessary maintenance overhead!

Right now these changes are working fine on my test site (still version 0.9). However, the changes aren't completely generic, so I won't be committing them to the 0.9 branch (version 0.9's templates use "TaxInfo.PriceSuffix, and Buyable::TaxInfo() has to create an order to get the tax info).

Anyway, I think that it's worth making these changes to the newer versions of the ecommerce module. If you're interested, then I can share my changes with you.

regards,

Hans

[Nicolaas Thiemen Francken - Sunny Side Up]

On 11 April 2013 16:57, Hans de Ruiter <hjr2...@gmail.com> wrote:

Hi Nicolaas,

Yes, that makes sense. 

BTW, I'm currently working on delaying the creation of Order objects until a user adds an item to their cart. This is because I noticed that new orders are created even when bots visit my site, so I'm ending up with thousands of pointless entries; like >20,000 pointless entries per month. That's a lot of wasted database space and unnecessary maintenance overhead!

In later versions of e-commerce something like that has already been included. What is more, orders are cleaned up immediately. I agree this is a very good idea. 

 

Right now these changes are working fine on my test site (still version 0.9). However, the changes aren't completely generic, so I won't be committing them to the 0.9 branch (version 0.9's templates use "TaxInfo.PriceSuffix, and Buyable::TaxInfo() has to create an order to get the tax info).

Anyway, I think that it's worth making these changes to the newer versions of the ecommerce module. If you're interested, then I can share my changes with you.

Would love to see how you have done it. 

Sounds great. 

[Hans de Ruiter]

On Thursday, April 11, 2013 7:57:59 PM UTC+12, Nicolaas Thiemen Francken - Sunny Side Up wrote:

Anyway, I think that it's worth making these changes to the newer versions of the ecommerce module. If you're interested, then I can share my changes with you.

Would love to see how you have done it. 

Sounds great.

 

I'll send you the diffs via email, but the basics are as follows:

- Changed ShoppingCart::current_order() (and similar methods, including EcommerceSiteTreeExtension::Cart()) to take a $allowCreate as parameter, with the default = true (so that the old behaviour still works). When set to false, the method will return null if there is no current order

- Next, I inserted a user_error() call in ShoppingCart::current_order() just before the code that generates a new cart

- Finally, I opened an incognito browser window (ensures that a new session is created), and visited various pages. The stack traces from the user_error() call told me exactly which methods and templates needed updating. 

Once I could visit all page types without creating an order, the last step was to remove the user_error(), and double-check that adding items, etc., still worked.

regards,

Hans