Post any OpenCart 1.4.6 Bugs here!

rph wrote:It's not really a bug but the autopopulate for product availability date really should be removed. Since OpenCart falls back to UTC this is creating persistent posts from people complaining about products not showing up in their store.

I'm not able to insert products and category's at all? so you say it has to do with the server time...

junstore wrote:"About Us"

at the slidebar, when click the "about us" it point to url http://www.domain.com/about us, but the rest part is ok.

What is a slidebar? I assume you mean sidebox? I see on your site it has SEO setup but it isn't working so you may need to edit your htaccess still for that. But on most default sites it works fine

i2Paq wrote:

rph wrote:It's not really a bug but the autopopulate for product availability date really should be removed. Since OpenCart falls back to UTC this is creating persistent posts from people complaining about products not showing up in their store.

True, but its more related to the server not having it time and date set-up correctly.

I believe it's trying to get the time zone from OpenCart's php.ini file which won't exist unless the user manually adds it. I don't know enough about the ini_get function (does it fall back to anything?) to really comment though.

i could add a timezone option in admin settings

Qphoria wrote:i could add a timezone option in admin settings

I think this is a good idea.
Some other carts I know have this to.

A potential problem is a person's time zone and their server's time zone might not match.

Hello, First of all the 1.4.6 Looks Great. I've been trying it out for sometime now. Cannot wait for the Stable 1.4.7, Am sure its gonna be the most stable cart.

Also, regarding 1.4.6 (Latest) I've found a wierd issue.

When i add a user through the backend and save it, It does not work from the front End. I get the login error message.(Invalid Email ..) I've tried it on two installations now. I did check if my caps lock were on or not.. everything seems fine. Could you please try it out for me and confirm if its some Bug/Error or not?

Thank You.

Mark.s wrote:

rph wrote:It's not really a bug but the autopopulate for product availability date really should be removed. Since OpenCart falls back to UTC this is creating persistent posts from people complaining about products not showing up in their store.

I'm not able to insert products and category's at all? so you say it has to do with the server time...

Sorry guys my bad, its not a bug! The problem is that you need to enter product/category data in both language tabs, because i only inserted the product name and id in the Dutch tab it gave no error there. But in the English tab that the data was not entered.

Maybe you can edit the code so it automatic copy/clones the data from the first language tab when no data is inserted in the other languages?

Or some code that shows the language tab where the warning appears?

rph wrote:A potential problem is a person's time zone and their server's time zone might not match.

Hmm... Mainly the time is pretty static so If people are seeing that their products should be active because it is
10:00:00 on 01/01/10 but really its only 9:00:00 then we don't really care what GMT is. We only need to know how many hours to offset the server time which would be as simple as checking your clock versus what time the server used for the automatic time on product insert.

But still, if the server thinks it is 10:00 then the product should be active because it all uses the same clock. The only place the offset should matter is when you want to see order timestamps.. which don't exist yet.. but definitely should be added. Then you'd want to see an order at 10pm show as 10pm

I agree GMT doesn't matter. It's only an issue because that's what OpenCart defaults to (anything OpenCart defaults to would be a problem for someone).

I'm not sure how you've got it set up but the problem I see is if a person enters their own time zone rather than the server's and the server is a good distance away the problem could crop up again. If someone's in New York City and sets it to EST and the server is in Honolulu on HST you'll get a dead zone between 6 PM and 12 AM where products won't show up.

That's an extreme (and unlikely) case really but with the internet being global it is an issue.

rph wrote:If someone's in New York City and sets it to EST and the server is in Honolulu on HST you'll get a dead zone between 6 PM and 12 AM where products won't show up.

But in the case of the automatic timestamp. It uses the server time for "now()". So there will not be any dead times unless the admin manually attempts to change the time to his own zone. So you just need the offset between the store admin's time and the server time for display purposes. The server doesn't care what time the client thinks it is as far as showing products.

Could you just set the default "Product Available" field to blank, and have products with a blank field always available? That seems like the easiest option, since it would seem most people would want their products available immediately, or they could enter a future date (which they already have to do).

Qphoria wrote:

rph wrote:If someone's in New York City and sets it to EST and the server is in Honolulu on HST you'll get a dead zone between 6 PM and 12 AM where products won't show up.

But in the case of the automatic timestamp. It uses the server time for "now()". So there will not be any dead times unless the admin manually attempts to change the time to his own zone. So you just need the offset between the store admin's time and the server time for display purposes. The server doesn't care what time the client thinks it is as far as showing products.

I think we might be on a different page here. The problem is OpenCart setting date_default_timezone_set in startup.php to something other than what the server really is.

Oh.. ok that makes more sense. So then we should just change that to use the servers localtime and this particular problem would be solved? nes pa?

Could it just be deleted outright? Is there anything that actually depends on this?

Sorry for delay, but have been busy on other projects. In the end I stuck with 1.4.6, but I see that 1.4.7 has been released now, so will use that on my next "shopping" project.
The field which displayed different characteristics was the "Model" field. In 1.4.5 a red warning message came up if more that 24 characters were entered. In 1.4.7 no such message appears and the field can take 30 characters before you run out of space. However, entering more than 24 characters in this field causes problems (as I outlined before). I've got around the problem by simply repeating the content of the SKU field (from below it) - which has a limit of 20 characters anyway.
I hope this is helpful.

BTW, Open Cart is excellent and I've already written a couple of routines for extracting data from one of the tables to assist me in eBaying some of the products and I've added another table of my own to retain useful marketing information. So I am now a committed user and advocate of Open Cart. Many thanks for producing something vastly superior to "oscommerce", which is the only other online shopping programme I've tried (and failed!) to use before. Apart from the fact that the current oscommerce and various others I tried before coming across Open Cart all crash under PHP5 (which is the default from most Linux-based ISPs these days), Open Cart allows customers to buy on-the-fly and not to have to register. Many is the one-off purchase I have not made from an unknown supplier because they wanted me to register all my details with them and many are the junk emails I receive from the ones that I did register with! So allowing customers to buy without leaving details on file has got to be an advantage when you are not aiming at repeat customer sales.

Thanks again.

blackmountain wrote: In 1.4.7 no such message appears and the field can take 30 characters before you run out of space. However, entering more than 24 characters in this field causes problems (as I outlined before). .

Fixed in 1.4.8 to allow 64 which is what the db field already is set to

Title:
Not update status

Description:
No update status in order history (index.php?route=account/invoice&order_id=XXX)

Reported on:
1.4.6

Classification:
low


System info:
[USER] Enter your system info - versions of:
* php 5.2.9
* Apache
* MySQL
* Chrome
* magic_quotes_gpc On

Qphoria wrote:Oh.. ok that makes more sense. So then we should just change that to use the servers localtime and this particular problem would be solved? nes pa?

When I first installed OpenCart, there seemed to be 3 time zones in effect: The local time on my computer (East Coast USA), the time on the server (West Coast USA), and the time that OpenCart is set to (Greenwich time). I had my hosting company set the server time to East Coast USA, but that didn't fix the problem of items not showing up in the cart when they were installed. That was when I became aware that OpenCart was set to a different time than my server.

The solution is simple: Users need to be able to set OpenCart to their local time. However that's accomplished, that's what needs to happen. As far as the auto-fill of the time goes, I have no problem with that as long as it is accurate.

I have the following problem, my shop works properly under Internet Explorer 7, 8 and under Mozila a IE6 gives the following problem right menu shifts to the left

with Internet Explorer 6 - http://yfrog.com/mkie6j
with Mozila and IE8 - http://yfrog.com/j8mozilakj
www.maxpowerbg.com