Messages

Do you know ...

•  Can I change the secret admin name at any time by editing config.php and updating the URL?
•  Is there a restiction on length?
•  Are special characters allowed?

1. Never tried it. Should work because the info is being called from config.php and it's an internal redirect to Admin.
2. Don't think there is a length restriction
3. Not sure about special characters.  Try it.

Since all this can be controlled by the config.php file, you really can't break anything permanent.

No problem.  Glad to help.

The password thing I'm not sure about because I am not that familiar with encryption. You didn't change UNIQUE_ID or ENCRYPTION_KEY did you?

As for the .htaccess file, all I have for storefront is as follows to block some bad IP's and handle SSL:

Code Select Expand

RewriteEngine on
AddHandler mod-rewrite mod_rewrite

<Files 403.shtml>
order allow,deny
allow from all
</Files>

deny from 198.186.194.0/24
deny from 198.186.190.0/23
deny from 198.186.192.0/23
deny from 198.186.193.48/28
deny from 198.186.193.192/27
deny from 38.99.82.191
deny from 45.123.118.83
deny from 122.177.248.77
deny from 198.186.192.44
deny from 164.132.233.169

RewriteCond %{QUERY_STRING} s=(.*)  [NC]
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

And Admin is :

Code Select Expand

<Files *.php>
order allow,deny
deny from all
</Files>

Which really doesn't do anything.

[&s]

No. It's a security thing. Your admin URL should look something like this with the ADMIN_PATH being the last part with the X's:

http://www.gowiththefloprods.com/store/index.php?rt=index/login&s=xxxx_xxxx

It's a built in redirect.

Once you're in, check system-->settings-->store details to make sure you Store URL points to the correct URL  http://www.gowiththefloprods.com/store/


EDIT---> Take out the &s if you are not using SSL.

['xxxx_xxxx']

This part:

When I go to:    http://www.gowiththefloprods.com/store/admin/

You setup a secret link to the admin area during install.  Look at system/config.php and the admin "folder" is defined here

define('ADMIN_PATH', 'xxxx_xxxx');

Replace admin with admin path like this and you should be able to get in:

http://www.gowiththefloprods.com/store/xxxx_xxxx/

I've had the same thing happen when there is a hiccup between the site and sql server. I cleared the error log and forgot about it. A note, any time there is a hiccup with sql, an error can be thrown.

[You were looking at why Paypal gets a 3 decimal place number and throws an error.]

Look at your math. 83.05 is correct by the formatted total and the displayed total is correct with rounding.

Now, I don't understand what your getting at  Your example is correct both ways. It is displaying the correct amounts. 

You were looking at why Paypal gets a 3 decimal place number and throws an error.  I have suggested ways to correct it and things to look at.  This is getting away from the original question/topic.

That's what I'm saying in the DB.  In xxx_currencies, "value" needs to be 15,2 not 15,8.  This forces 2 decimal places regardless of code.  It might not be the right fix, but it forces an output of 2 decimal places.

How's your currency setup in Localization?  I bet you have to trim the conversion down to 2 decimal places.  Been on the right track, maybe just the wrong place.  Look at the screen shot. 


========

You might have to change the db xxx_currencies  It is "set" for 2 decimal places,but the value is 15,8.  This makes more sense looking at things a bit closer.

The DB thing is a logical suggestion as to why your having this problem.  It may be code related, but if nothing else, it will confirm whether the db decimal places is the cause or not.

i have this:

      //Need to round price after discounts and specials
      //round main price to currency decimal_place setting (most common 2, but still...)
      $currency = $this->registry->get('currency')->getCurrency();
      $decimal_place = (int)$currency['decimal_place'];
      $decimal_place = !$decimal_place ? 2 : $decimal_place;
      $price = round($price, $decimal_place);

however it does nothing if I remove the rounding of the price calc.

See above

[ALL]

Check core/lib/cart.php  You have to look at ALL tables that deal with currency.  Did you change the decimal places in xxx_coupon.

That's only one place I looked at quickly.  You need to check product prices and any other table that deals with currency and adjust them accordingly too. Otherwise, you will still get an error at some point.

Take a look at core/lib/cart.php but I don't think that's it.  Took a look at the DB and it looks like it's there. Take a look at xxx_orders for a start(screen shot attached)

Some of the values are carried out beyond 2 places and I bet that's where the error occurs.  AND it will do it in any currency.  There's no reason I can see to carry a price out to 4+ decimal places. Maybe one of the dev team can chime in and give us some insight as to why the decimal places are more than 2.  Maybe in some currencies there are more than 2 places.

BTW, it's a simple fix.  Just change the values in the db.  I've come across this elsewhere.

Okay, maybe try putting the tax in the store and take it off Paypal. That way a total is passed to Paypal and your not relying on Paypal for any calculations.

It seems though that the Euro rounding error is not limited to my previous post with sub-total and tax. 

The only other thing I can think of is currency conversion on Paypal side.  I don't know how they do that. As far as I know, Paypal is USD based and has to do conversions.  That could explain the randomness of the error.

If it was me, I would try taxing at store level and passing a total to Paypal. There is also a report for tax in Abantecart to help keep track of tax collected.