The number_format value with decimal of 2 would be more compliant with shipping modules such as the UPS and USPS which those two providers enforces the decimal of 2, for instance.
As for the Journal2, I really have to say here, as a positive input, that I would never expect someone having to go this far to find out the truth about the cache that this add-on is failing to process and for the publisher to have failed the delivery of its product. Great troubleshooting !
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
after the multiplication of the discount code if the real number was .8001 it would give back 0.8 not 0.80 which I did not understand. If the number was .8201 I would get 0.82 which would be correct. but for some reason... if the second digit after the decimal was a zero it would take trim the zero... and the number could be confusing to the customer. So I tried number_format and it worked.
$0.8
$0.80
The top one looks like 8 cents when looking quick... some may see it that way... and its not the proper way to show the number.
As for the reason to not use number_format... Im using paypal and square for payment processing. Shipping I do manually using stamps.com and the number format is being used on a number that is not related to the sales data at all... just sort of a promotion... so hopefully that will not be a big deal.
More importantly I have to figure out how to get this all done in the twig template which is so friggen frustrating. This is my first experience with twig. Any exposure I got to PHP is a result of working with opencart 1.5.6 so I know a few minor things... but I dont know twig at all and it seems so much more limited than PHP.
Oh yea... as far as my PHP that you converted to PHP to be included in the controller file... when I added it... it took some trial and error to get it to even show me any results on the front end and when it did... it only showed "0" as the answer. I was unable to get it to work and give me a real number. I was doing this at like 2am... so maybe i messed something up and will try again in a bit.
As for journal... for the top selling theme for opencart... you would think someone ran into a problem with cache on the controller files. Its funny how it only seems to affect those files tho. And I sent them a message describing my steps in great detail. For them to say its not a problem with the theme or it may be my server... and then to get another server from a totally different hosting company and still have the problem... but it works fine without the theme... thats a theme problem. But to be sure... today I will do a 3rd install using a totally different theme. and see if that works.
Thank you for all your help and feedback.
If anyone knows how I can do this:
Code: Select all
'after_discount' => number_format((($discount['price']) * 0.80), 2)
Angelina
As for the TWIG files, no worries, it is not more limited compared to PHP. It is simply restructured compared to the use of what PHP could execute directly into the TPL files before; which wasn't the safest way to maintain custom themes since the theme folder may require world-writable access on the file server as I do understand why the TWIG files were implemented. I really don't mind the face that a new structure needs to be used as it is part of the programming technology and knowledge.
As for my PHP code above ... the output should not be 0 as I am unable to reproduce this issue from the default theme ... it should only remove all characters that don't represent a decimal value. Using number_format in this case, as you mentioned above and my last explanation, it was exactly the point on not using the number_format function.
From the previous instructions, it should be usable by outputting the value from the TWIG file by using:
Code: Select all
{% if discount.discounted_price %}
discount.discounted_price
{% endif %}
As for the Journal2 theme, I also noticed this behavior when working on a custom job for a previous client and I can say your analysis is indeed correct regarding the particular results of the product page.
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
I remember reading somewhere that sometimes its best to refresh/clear cache a couple of times. So I tried this with the theme cache, sass cache and journal cache. Each one I cleared like 4-5 times... and in between each type i tested it. Still did not work. HOWEVER... if I refresh and clear the cache of my modifications / extensions a couple of times... Admin > Extensions > Modifications > Hit the Refresh button 3 times in a row... then reloaded the front end page... IT WORKED!!! Mind you I did not have to do this prior to installing journal. But after installing it... its best to refresh the modifications / extensions if making any changes to the core files.
I just spent the last 1/2 hour tinkering with a template page to get a easy to read output when I have discounts applied to a product.
Here is a product the way it will normally appear:
http://printingforparties.com/test-002
Here is the product that has discounts assigned:
http://printingforparties.com/test-001
As for paypal... the number i created is not being used for financial... only to show what the discount would be if the customer applies the code to the cart. the number i created: discount.after_discount only shows up on the front end product page if there is a discount... it will not be transfered over to the cart or save as data anywhere so not sure how it would affect any payment processing?
Again... Thanks for all your help. I finally got what I was looking for and learned a thing or two.
Angelina
If after installing the Journal2 extension resolves the cause on modifying ... core files? - When using the modification refresh button, then this is what definitely causes the conflict between the initialization of a journal2 theme and core files ... the refresh of modifications should only be reliable when ... modification files have been modified and requires refresh ...its best to refresh the modifications / extensions if making any changes to the core files.
However, in this case, since the Journal2 extension is an extension, it is clearly that the refresh button works with the changes you make since the core files you believe to have modified are not considered core files on that level.
As for PayPal, discounted or not discounted, the total price unit is what is being compared between PayPal and the merchant during the transaction.
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
If You are not seeing changes, you usually have one of the following:
1. you have not cleared the TWIG cache (this is something new in opencart 3.x and even we got somewhat frustrated) (system/storage/cache)
2. you have a OCMOD modification. so even if you are editing the default file, the modification stays old. (system/storage/modification)
3. you could be simply modifying the wrong file. I know it sounds stupid but I personally get this issue from time to time. (check if you are really modifying the right file)
4. in your browser turn on "DISABLE CACHE" http://joxi.ru/zANYwKxUBqYO32
5. if all of the above is correct - then turn off that crazy CACHE module that you installed. some of them have debug mode - so you could use that one.)))))
hope this helps.
Many OpenCart users struggle to find quality extensions. We know how frustrating the need to fix the shop is just because of one poorly coded extension. We created quality OpenCart Extensions, tested by real developers and provide professional support.
AJAX QUICK CHECKOUT - #1 one-page checkout solution
VISUAL DESIGNER - Page builder for Opencart
View more extensions here
Tested by Shopunity.net
Users browsing this forum: No registered users and 24 guests