Post by straightlight » Thu Oct 26, 2017 8:08 pm

I would not suggest using the number_format function since Opencart uses the Yahoo Finance API as it could affect the currency exchange settings on your site. As for the discount.after_discount, that is correct since the discounts is an array being extracted into the TWIG file and should not be using brackets to output the value. However, my PHP code above should work already as it is in compliance with the currency exchange output.

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 ! :)

The most generated errors being found on Opencart forum originates from contributed programming. The increased post counters are caused by redundancies of the same solutions that were already provided prior.


Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member
Online

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by print-n-tees » Thu Oct 26, 2017 11:10 pm

Thanks straightlight. I cant believe how much time Im spending on this one thing... but its so important. As for the number_format I first tried the round option... but it gave back non complete numbers. For example:

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)
In the actual product.twig file... please advise.

Angelina

User avatar
New member

Posts

Joined
Sun Feb 24, 2013 2:54 pm


Post by straightlight » Thu Oct 26, 2017 11:58 pm

Regarding PayPal, that is also implicit however. Their payment processing API system does validate the currency value between merchants and the store - especially the PayPal standard subscription plan.

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 %}
Unless you are using an older PHP version, this may be a possible case but non that I could compare as before. The array line I provided was test under PHP 7.x releases.

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.

The most generated errors being found on Opencart forum originates from contributed programming. The increased post counters are caused by redundancies of the same solutions that were already provided prior.


Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member
Online

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by print-n-tees » Fri Oct 27, 2017 12:49 am

Well Well Well.. After some tinkering around and now that I have code that I know for sure works in the controller file. Before I went and set up a 3rd fresh install I figured let me take the new PHP and add it to my shop's controller file just for fun. So I did that and saved it. I then added the discount.after_discount tag and cleared all cache and sure enough it did not work.

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

User avatar
New member

Posts

Joined
Sun Feb 24, 2013 2:54 pm


Post by straightlight » Fri Oct 27, 2017 1:17 am

its best to refresh the modifications / extensions if making any changes to the core files.
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 ...

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.

The most generated errors being found on Opencart forum originates from contributed programming. The increased post counters are caused by redundancies of the same solutions that were already provided prior.


Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member
Online

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by Dreamvention » Fri Oct 27, 2017 3:18 am

Wait) don't do that - you have beautiful hair O0

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


User avatar
Administrator

Posts

Joined
Sun Jun 17, 2012 7:04 pm
Location - Europe
Who is online

Users browsing this forum: No registered users and 10 guests