Skip to content

1.4.0#69

Open
shumoapp wants to merge 11 commits intointegry:1.4.0from
shumoapp:1.4.0
Open

1.4.0#69
shumoapp wants to merge 11 commits intointegry:1.4.0from
shumoapp:1.4.0

Conversation

@shumoapp
Copy link

Hello,

I've prepared few fixes for the 1.4.0 branch, and I'd like you to take a look at them and pull if you find them helpful. The first couple of commits are with spaces indentation, so you may want to convert those to tabs. If you have any questions, I'm available for discussion at shumoapp@gmail.com

Best regards,
Veliko Vladimirov

shumoapp added 11 commits June 9, 2015 02:20
…return the customized template path.

When editing module email templates from admin>customize>module>moduleName, the resulting templates are stored in
livecartRoot/storage/customize/view/module/moduleName/email/en/
This fix allows the mailing scripts to get the customized template instead of the one from
livecartRoot/module/moduleName/application/view/email/en/
…end.Template js class.

For templates that are deep into the templates tree (admin>customize>edit templates),
the dhtmlXTreeObject.parentObject.id returned an array, while a string was expected.
As a result tabTitleFromTemplateId would die and not allow to edit the template.
dhtmlxtree is some proprietary library, so I won't try to fix it.
…as not returning products when the queried product was a product with variations.

Apparently the variations are added as child products to a parent product, and the child ID was recorded in the OrderedItem table.
Also added is a PHPUnit test to show the problem.
Up till now if you delete the default address, the users could not login, because the default address associated with the user didn't change.
(when there is custom field attached to the address - some error in EavSpecificationManagerCommon)
Now the default addresses are set to the first of the remaining or null, and the users can login, even if they have no addresses at all.

Also added are two PHPUnit tests that show the problem, and LiveCartTest is fixed to work with controller tests.
When finalizing an order in non-default currency, the prices of the items in the order were wrongly re-calculated.
A test is added to show the problem.

Also added is a second currency (EUR) in the setup, and PHPUnit_Framework_Error_Deprecated is disabled.
Added a line to reset the cached $toArrayData after each OrderedItem update, because otherwise OrderedItem::toArray() returns the price in the old currency.
This resulted in incorrect prices in the shopping cart when alternating between currencies. It showed the old currency price as discounted, and with the wrong currency sign.
A test was added to show the problem.
Up till now if a user had a discount, the products with variations showed realPrice and listPrice, as the listPrice was shown with strikethrough formatting.
The problem was that when changing the selected variation, the realPrice was changed, but the listPrice was not. This update fixes this problem,
and now both prices are changed accordingly.
Even though only one currency was defined in a product, if the product had list price defined, all other currencies also calculated the list price, but not the base price.
As a result only the list price for a currency was filled, and when the form was submitted (presumably editing something else), the base price was saved as 0.
The base price is what the customer pays when adds the product in his shopping cart!

This fix makes sure that the list price is not filled if a currency was not defined for a product. This way Livecart automatically calculates the prices in the other currencies, based on the currency exchange rate.
Currently supports only MySQL and Semaphore queue, but can be extended to support all kind of queues.
You just need to add WhateverQueue.php file that extends QueueInterface.php inside model/queue folder.
All emails will be added to a Queue, and a cronjob(or many cronjobs) will get the queued emails,
and send them with the configured email transport system.

This results in faster newsletter sending, and the clients are not waiting on checkout/complete for
the server to connect to smtp server and send the emails.

Add as many threads as you need to your crontab like this:
* * * * * /usr/bin/php /public_html/storage/processQueues.php > /dev/null 2>&1
The more threads you have, the faster the emails will be sent, and the higher the
CPU load will be. So please use responsibly!
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

Successfully merging this pull request may close these issues.

1 participant