Post by jty » Thu Oct 02, 2008 1:20 pm

Qphoria wrote: Looks like there needs to be multiple checkout contribs or just one very configurable system to fit everyone's preference
Virtuemart allows the config of Checkout in admin
Store owners can choose to or not to have an address or shipping page
I assue no address is for virtual products and no shipping for virtual products or where shipping is free

Prestashop (current version) doesn't have a text box for comments in checkout. Bad  >:(
Must have a comments page for customers to leave messages about the order for us

jty
Active Member

Posts

Joined
Sat Aug 30, 2008 8:19 am

Post by activeebiz » Thu Oct 02, 2008 1:22 pm

Regarding allowing buyers to pull the trigger, they can pull the trigger at:
1. The cart page where they can see the shipping
2. The Payment page if the payment options do not suit them.

I do not see the need to enable buyer to pull the trigger after the payment page. They only pull the trigger cos of shipping and payment options. If they've gone through shipping and payment, what reason is there for them to want to pull the trigger after this?
Agreed, a separate confirmation page is redundant.

Prior to ajax it was used simply because of the need to have a page refresh to update the data and show the complete order totals.
Last edited by activeebiz on Thu Oct 02, 2008 1:24 pm, edited 1 time in total.

Newbie

Posts

Joined
Mon Jun 09, 2008 2:10 am

Post by Qphoria » Thu Oct 02, 2008 1:26 pm

bruce wrote: Ah Q, those that do not will not be store owners for long.  ;)
LOL how prophetic. While you are very right in the grand scheme, I don't think people will avoid your store because they checked out faster than they thought.  ;)

I do like the idea of the shipping on the cart page though. The weight is already on that page so that works well for shipping.
Last edited by Qphoria on Thu Oct 02, 2008 1:29 pm, edited 1 time in total.

Image
Donate!|OpenCart Basics|GeoZones
Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by snover » Thu Oct 02, 2008 1:39 pm

Qphoria wrote:From a store owner's point of view, however, you want them to pull the trigger. if they are given a chance to think about it they might rescind. But if the trigger got pulled then they will likely just accept it.
Or, you get an abnormally large number of requests to your customer service department asking to cancel accidental orders. ;)

Another (unrelated) problem I noticed is that the passwords in the database are hashed (good!), but they are hashed using MD5 (bad!) and they do not use a random seed (really bad!). This should really be changed to at least use SHA-1 with a seed (preferably it would use something even stronger, like SHA-256 or RIPEMD-160, to avoid ever needing to change this again in the next 10 years). Of course, extra consideration will need to be made in regards to migration (since obviously you can't re-hash the already hashed password). Simple enough, though: if the length of the field is 32-bytes (MD5-sum) instead of 48-bytes (SHA-1 hash + 32-bit seed), it confirms the password using md5 and then tells at the user nicely that they need to update their password before they can proceed.

Cheers,

(NB. When I say 'seed', I mean a random one, that changes for every password, not a single one used for all passwords.)
Last edited by snover on Thu Oct 02, 2008 1:43 pm, edited 1 time in total.

Newbie

Posts

Joined
Thu Jul 19, 2007 5:27 am

Post by Daniel » Thu Oct 02, 2008 6:33 pm

snover wrote: 1. Installation documentation gives improper chmod values for directories; it instructs to set everything to 0666, but it should be 0777 for directories.
2. Uploaders don't properly check for error status:

Code: Select all

admin/controller/catalog/image.php:351
if (isset($this->request->files['image']['error'])) {

admin/controller/catalog/download.php:365
if (isset($this->request->files['download']['error'])) {
should be

Code: Select all

if ($this->request->files['image']['error'] != UPLOAD_ERR_OK) {

if ($this->request->files['download']['error'] != UPLOAD_ERR_OK) {
3. This code doesn't make any sense since it is trying to unlink an array:

Code: Select all

admin/controller/catalog/image.php:357
@unlink($this->request->files['image']);

admin/controller/catalog/download.php:371
@unlink($this->request->files['download']);
4. The animated menus in the admin section are terrible from a usability perspective since they make the user wait needlessly. Get rid of them.
5. Upload dialogues should have a 'Close' button instead of a 'Cancel' button, since it's the only way to close the dialogue, and saying 'cancel' may be confusing to users.
6. Image title minimum length requirement is seemingly arbitrary and probably shouldn't exist.
7. Cache is not cleared when files are uploaded, so the drop-down menus for images and downloads on product pages (and elsewhere) are stale. Presumably this should be taken care of in ModelCatalogImage::insert, ModelCatalogImage::update, ModelCatalogImage::delete, etc. with:

Code: Select all

$this->cache->delete('image.' . $this->language->getId())
8. Images are stretched instead of being scaled proportionally and/or cropped to fit the box.

More to come, just some initial stuff. If the issue tracker on Google Groups is going to be used I will happily insert these as issues there, let me know!
I have fixed all the stuff you have listed here except the menus.

OpenCart®
Project Owner & Developer.


User avatar
Administrator

Posts

Joined
Fri Nov 03, 2006 6:57 pm

Post by Qphoria » Thu Oct 02, 2008 6:36 pm

snover wrote:
Or, you get an abnormally large number of requests to your customer service department asking to cancel accidental orders. ;)
But they are on your site. They shopped, they took the time to enter go through the steps. They took the time to pull out their credit card and type their numbers. They "want" the item. But customers can also be nervous and psyche themselves out of things. You are doing them a favor by feeding on their impulse. And its not like you aren't going to have a message saying "Click to submit order". If they didn't read it then they've learned a life lesson (and many customers don't read and need to be beaten  ::) 8) ;D)

Plus I'd rather have the order and try to save it then not have the order at all :)
Last edited by Qphoria on Thu Oct 02, 2008 6:41 pm, edited 1 time in total.

Image
Donate!|OpenCart Basics|GeoZones
Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by Daniel » Thu Oct 02, 2008 6:47 pm

snover wrote: Two other things to think about:

1. Why is the database abstraction layer not using, or even providing the option to use, prepared statements? String concatenation is dangerous (for obvious reasons), more complicated, and often slower than executing a prepared statement (especially when you factor in the overhead of all the input sanitisation and escaping that is going on that should not ever need to be done).
2. Why are MyISAM tables used for the default installation? Full-text indexing isn't used, and that's the only reason you would want to use MyISAM instead of InnoDB. Enforcing referential integrity and atomic transactions in the database is a Good Thing, especially when you've got 3rd party extensions meddling with things, especially especially when you're dealing with anything to do with money.
1. The class i'm using at the moment is very lightweight and if i had to use prepared statements i think it adds bulk to writing SQL.

2. I seem to remember InnoDB stores most things in the RAM and people on shared hosts might have problems. I remeber one US retailer containg me because he was having problems getting the site to run with 100,000 products.

OpenCart®
Project Owner & Developer.


User avatar
Administrator

Posts

Joined
Fri Nov 03, 2006 6:57 pm

Post by snover » Fri Oct 03, 2008 1:15 am

Daniel wrote: 1. The class i'm using at the moment is very lightweight and if i had to use prepared statements i think it adds bulk to writing SQL.
I'm not sure I agree with you on that point.

Code: Select all

$this->database->getRows("select * from zone_to_geo_zone where geo_zone_id = '" . (int)$this->config->get('flat_geo_zone_id') . "' and country_id = '" . (int)$this->address->getCountryId($this->session->get('shipping_address_id')) . "' and (zone_id = '" . (int)$this->address->getZoneId($this->session->get('shipping_address_id')) . "' or zone_id = '0')")
Would become

Code: Select all

$this->database->getRows(
    "select * from zone_to_geo_zone where geo_zone_id = :geoZoneId and country_id = :countryId and (zone_id = :zoneId or zone_id = 0)",
    array(':geoZoneId' => $this->config->get('flat_geo_zone_id'),
          ':countryId' => $this->address->getCountryId($this->session->get('shipping_address_id')),
          ':zoneId'    => $this->address->getZoneId($this->session->get('shipping_address_id'))
));
We don't have to cast (the database knows what the column types are supposed to be), we don't have to write horrible scary long concatenated strings (see how much easier to read the query is), and (perhaps most importantly) we don't have to worry about SQL injection at all because the query is sent separately from the bound data. Additionally, if we use the same query a lot (eg. for a bulk insert or update), we also save lots of time in the database server when using a prepared statement because the server only needs to parse and optimise the query once (we call execute() multiple times on the statement with different values), instead of every time it's executed.
2. I seem to remember InnoDB stores most things in the RAM and people on shared hosts might have problems. I remeber one US retailer containg me because he was having problems getting the site to run with 100,000 products.
InnoDB uses additional memory to increase performance, but like everything, the amount it uses is configurable (just like MyISAM's key_buffer), so the only time there should be a problem with memory performance would be when the host didn't configure the server properly and it was going into swap, or if the tables aren't indexed properly. The difference between MyISAM and InnoDB in this respect is that when you are using MyISAM, the key_buffer is loaded with just the index of the table. In contrast, when InnoDB buffers its index, it is implicitly buffering the data in the table as well (which makes for very fast data retrieval).

One of the few negative points to note about InnoDB is that whereas MyISAM internally caches COUNT(*), InnoDB can't do that (because of transaction isolation), so SELECT COUNT(*) operations take longer. However, InnoDB is significantly faster in pretty much all other cases, and with the additional features (foreign key constraints, ACID compliance, transactions), it's a no-brainer which one should be used for any sort of business-critical or high-performance MySQL-based database application (IMO).
Last edited by snover on Fri Oct 03, 2008 1:26 am, edited 1 time in total.

Newbie

Posts

Joined
Thu Jul 19, 2007 5:27 am

Post by wackolacko » Sat Oct 04, 2008 6:18 pm

Code: Select all

Notice: Undefined index: product_option in C:\Program Files\VertrigoServ\www\opencart\admin\model\catalog\product.php on line 12

Warning: Invalid argument supplied for foreach() in C:\Program Files\VertrigoServ\www\opencart\admin\model\catalog\product.php on line 12

Notice: Undefined index: product_discount in C:\Program Files\VertrigoServ\www\opencart\admin\model\catalog\product.php on line 18

Warning: Invalid argument supplied for foreach() in C:\Program Files\VertrigoServ\www\opencart\admin\model\catalog\product.php on line 18

Notice: Undefined index: product_image in C:\Program Files\VertrigoServ\www\opencart\admin\model\catalog\product.php on line 22

Warning: Invalid argument supplied for foreach() in C:\Program Files\VertrigoServ\www\opencart\admin\model\catalog\product.php on line 22

Notice: Undefined index: product_download in C:\Program Files\VertrigoServ\www\opencart\admin\model\catalog\product.php on line 26

Warning: Invalid argument supplied for foreach() in C:\Program Files\VertrigoServ\www\opencart\admin\model\catalog\product.php on line 26

Warning: Cannot modify header information - headers already sent by (output started at C:\Program Files\VertrigoServ\www\opencart\admin\model\catalog\product.php:12) in C:\Program Files\VertrigoServ\www\opencart\library\system\controller.php on line 89
Error adding to cart:

Code: Select all

Notice: Undefined index: option in C:\Program Files\VertrigoServ\www\opencart\catalog\controller\product\product.php on line 5

Warning: Cannot modify header information - headers already sent by (output started at C:\Program Files\VertrigoServ\www\opencart\catalog\controller\product\product.php:5) in C:\Program Files\VertrigoServ\www\opencart\library\system\controller.php on line 89

Newbie

Posts

Joined
Sat Jul 19, 2008 4:13 pm

Post by Qphoria » Sat Oct 04, 2008 11:28 pm

1.0 is not ready for cart use. It is still early in development and is only released as beta to give people a look at the new framework being used.

Image
Donate!|OpenCart Basics|GeoZones
Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by fido-x » Mon Oct 06, 2008 4:48 pm

The "add to cart" error has been mentioned a couple times now. It occurs because your product doesn't have any options. However, adding options to a product also throws up a whole lot of errors. But, as Q said, version 1 is still in early development and is not ready for production use (yet).

Image
Modules for OpenCart 2.3.0.2
Homepage Module [Free - since OpenCart 0.7.7]
Multistore Extensions
Store Manager Multi-Vendor/Multi-Store management tool

If you're not living on the edge ... you're taking up too much space!


User avatar
Expert Member

Posts

Joined
Sat Jun 28, 2008 1:09 am
Location - Tasmania, Australia

Post by salmoon » Mon Oct 06, 2008 9:37 pm

Qphoria wrote: 1.0 is not ready for cart use. It is still early in development and is only released as beta to give people a look at the new framework being used.
ah man, from what Daniel said i thought it was gonna be real soon?  ??? i recently told my client there's an update coming out soon which will fix the paypal callback bug she has with her site. she's on 0.7.7 i think at the mo.

New member

Posts

Joined
Sun Oct 21, 2007 9:59 pm

Post by bruce » Mon Oct 06, 2008 9:55 pm

PM sent

Active Member

Posts

Joined
Wed Dec 12, 2007 2:26 pm

Post by Daniel » Tue Oct 07, 2008 7:41 am

i'm working on the new version now. I was hoping to get it ready for monday, but its taking a bit longer. I know exectly what needs to be done and i'm just going at this thing flat out.

I think I get can the full release out in 1 - 2 days if not then this week.
Last edited by Daniel on Wed Oct 08, 2008 12:49 am, edited 1 time in total.

OpenCart®
Project Owner & Developer.


User avatar
Administrator

Posts

Joined
Fri Nov 03, 2006 6:57 pm

Post by Hory » Tue Oct 07, 2008 9:04 pm

Thank you, I really hope that you do!

Newbie

Posts

Joined
Wed Sep 12, 2007 6:59 pm

Post by salmoon » Thu Oct 09, 2008 3:55 pm

How's it coming Daniel?

New member

Posts

Joined
Sun Oct 21, 2007 9:59 pm

Post by Daniel » Mon Oct 13, 2008 6:06 pm

Ok guys i'm stuck on a problem.

What version of PHP are you all using?

I want to make use of namespaces, but this will mean people will need to be using PHP version 5.2.

Using namespaces means I can do this:

$controller = new controller::default();

$product = new model::product();

helper::image::resize($filename, 150, 150);

There will be no need to incluce a file first.

OpenCart®
Project Owner & Developer.


User avatar
Administrator

Posts

Joined
Fri Nov 03, 2006 6:57 pm

Post by Qphoria » Mon Oct 13, 2008 9:29 pm

Well as part of www.GoPHP5.org, I believe it was basing the upgrade on 5.2+ So any webhost using less than that should be taken out back and beaten severely. I'd say go for it.

Image
Donate!|OpenCart Basics|GeoZones
Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by jty » Mon Oct 13, 2008 10:02 pm

I'm on a really cheap hosting plan, about as cheap as one can go and it's PHP Version 5.2.6
I'm an end user, the dumb user, lowest on the food chain level
So I guess if anyone is on lower than 5.2 then yes, let's go beat 'em but maybe not severly :P

jty
Active Member

Posts

Joined
Sat Aug 30, 2008 8:19 am

Post by Daniel » Mon Oct 13, 2008 11:44 pm

OOP's just noticed that you need atleast 5.3 to run namespaces!

Dam have to add this feature later.

OpenCart®
Project Owner & Developer.


User avatar
Administrator

Posts

Joined
Fri Nov 03, 2006 6:57 pm
Who is online

Users browsing this forum: No registered users and 11 guests