Author Topic: 1.1.0 INstable  (Read 3045 times)

mmarfy

  • Beginner
  • *
  • Posts: 36
1.1.0 INstable
« on: June 07, 2008, 18:17:10 pm »
Ok Guys, after 1 mounth testing and tryng to make up a website with VM 1.1.0 and J!1.5.3, I concluded this: this version of VM is still in Alpha stadium, there are many bugs, a lot of them of easy solving, others, very mysterious, and they need to investigate on the database compatibility with Joomla! it seems that something goes wrong in database and like mushrooms appear bugs. The latest I encountered is a blank page on frontend when clikc on Vm module to see the shop, thi bug was appeared after working on jOOMLA! articles, NOT on Virtuemart. After this (wich is the last of a long list of strange and never experienced before bugs, I think that this version of VM is not mature for a production website, many work developers need to do to call this version "stable". Next installation of VM 1.1.x will be IMHO next year.
VM 1.0.15 is a mature and well working product

aravot

  • Peter
  • Moderator
  • Sr. Member
  • *
  • Posts: 2874
    • VirtueMart Extensions
Re: 1.1.0 INstable
« Reply #1 on: June 07, 2008, 21:01:13 pm »
I use VM 1.1.0 + Joomla 1.5.3 + php5 on two websites, not issues.

If you think, it is buggy post your findings with steps to duplicate, so we can fix it.

mmarfy

  • Beginner
  • *
  • Posts: 36
Re: 1.1.0 INstable
« Reply #2 on: June 14, 2008, 17:15:31 pm »
Dear Aravot, thanks for your answer,
so, I'm attempting to see the  errors:
first I've encountered was a strange low performance on editing order from the backoffice, I've    read the Apache error log and this come:
Undefined offset:  4 in administrator/components/com_virtuemart/classes/ps_order_edit.php on line 185
it seems something wrong on this string:
ps_html::dropdown_display( 'shipping', $rate_details[4], $rates );
in the specific, I've investigated on the variable $rate_details, t's a explode array on the ship_method_id db voice, in this arry there are not 4 values, but only 1 value, so in the 185 line, to say the [4] value generates the error, with processor extrawork, to fix the error we need to change that [4] in
  • wich in PHP means the first and only vale. Making this, the error is fixed. My question is: this is a bug or what? some other has this error? What means the programmers indicating 4 values in the 185 line when in the 110 line (the explode aray) there's only a value?