Post by bruce » Wed Oct 01, 2008 10:06 pm

It is in an infinite loop as the function calls itself recursively with no exit point.

$this->level should be $level

Active Member

Posts

Joined
Wed Dec 12, 2007 2:26 pm

Post by Qphoria » Wed Oct 01, 2008 10:07 pm

bruce wrote: It is in an infinite loop as the function calls itself recursively with no exit point.

$this->level should be $level
AH! Dammit! you know I looked at that a hundred times thinking that I was just wrong. I actually even tried changing the $level to $this->level. Never tried it the other way around.

Wonder why it works in a normal browser.

Thank you!

-EDIT-
Didn't work :( I thought it worked. But it was just that 10th time that it got a little farther. but its still freezing. 

I'm comparing it to the 0.7.8 version. Actually its misleading  as there is a function called "output" and a variable called "output" so although the $this->level was wrong, that only fixed the level compression, not the actual freezing. It isn't actually calling itself, it is just setting its variable by the same name as the function.
Last edited by Qphoria on Wed Oct 01, 2008 10:20 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 bruce » Wed Oct 01, 2008 10:25 pm

My pleasure Q.

I am commenting from memory now, because I always "clean up" the braces on code I work with (pedantic I know  ;D ) but I think you will find that if you had set a break point on that line of code and were using the "matched" brace layout for coding as shown below.

Code: Select all

function output($level = 4)
{
	foreach ($this->headers as $key => $value)
	{
		header($key. ': ' . $value);
	}
			
	if ($level)
	{
		echo $this->compress($this->output, $level);
	}
	else
	{
		echo $this->output;
	}
}
that the debugger would have stopped on that line. I have found that it is not fond of stepping near the first brace of the "mismatched" brace layout being used or braceless if statements and skips them instead. In this case, it would skip past a line that called itself.

I could be wrong, but it is food for thought and this brace layout is clearer IMHO  :D

cheers

Bruce

Active Member

Posts

Joined
Wed Dec 12, 2007 2:26 pm

Post by Qphoria » Wed Oct 01, 2008 10:29 pm

Heh, I'm your bizzarro superman :) I always pull the brace back to the if line to make it easier to read and less spacey :P

But the problem is definitely in the code that is being echo'd. I added some additional code after the echo to see if it would get there and sure enough it froze right after the output echo. So there is some actual evaluated data that it is choking on, not the code itself.

It actually loads the login page just fine. It's what it tried loading after the login page that chokes, which would be the actual admin section. I'm going to manipulate the $output variable before echoing it to see if i can find the culprit.
Last edited by Qphoria on Wed Oct 01, 2008 10:31 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 Qphoria » Wed Oct 01, 2008 10:55 pm

Ok. It looks like nuphere doesn't like, or can't handle the stuff on the main admin home page. Once I got past that, It seems to load the other pages fine. Perhaps there is some ajax or json stuff on that page for hte statistics graph that it doesnt like.

Image
Donate!|OpenCart Basics|GeoZones
Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by JohnnyO » Wed Oct 01, 2008 11:06 pm

Qphoria wrote: Ok. It looks like nuphere doesn't like, or can't handle the stuff on the main admin home page.
http://www.aptana.com/studio <-- What I use, Likes AJAX!

If you make it idiot proof, they will just build a better idiot.


User avatar
New member

Posts

Joined
Wed Nov 14, 2007 7:31 am
Location - Denver, CO - USA

Post by Qphoria » Wed Oct 01, 2008 11:09 pm

But it doesn't seem to do php step-by-step debugging

Image
Donate!|OpenCart Basics|GeoZones
Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by JohnnyO » Wed Oct 01, 2008 11:12 pm

Sorry I should have mentioned it needs a plugin for php support

http://www.aptana.com/php/

If you make it idiot proof, they will just build a better idiot.


User avatar
New member

Posts

Joined
Wed Nov 14, 2007 7:31 am
Location - Denver, CO - USA

Post by Qphoria » Wed Oct 01, 2008 11:17 pm

Right but its more of a robust editor, not debugger:
(As shown on their page:)
PHP Features

Aptana Studio's PHP Development Plugin contains robust PHP support.
This support includes Code Assist on PHP functions and parameters,
improved PHP syntax colorization, and a PHP outliner. Other features include:

    * Code Assist
    * Code outliner
    * Syntax highlighting and colorization
    * Syntax validation
    * Code folding
    * Code formatting
All the same, its a simple workaround if I just change the default admin home page to something other than the default. Ill take a look around nusphere's forums to see if there are any known issues with ajax or json. Seems there is a limitation with synchronous ajax calls. Not sure if that's related.

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 12:08 am

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!
Last edited by snover on Thu Oct 02, 2008 12:11 am, edited 1 time in total.

Newbie

Posts

Joined
Thu Jul 19, 2007 5:27 am

Post by Daniel » Thu Oct 02, 2008 6:51 am

ok guys i'm having a problem on how to do the checkout system.

althought a 1 page checkout system sounds nice it makes the pages look really bulky and overly complicated.

Is a 1 page checkout really necessary? having it in steps seems more intuitive for the customers.

OpenCart®
Project Owner & Developer.


User avatar
Administrator

Posts

Joined
Fri Nov 03, 2006 6:57 pm

Post by Qphoria » Thu Oct 02, 2008 7:00 am

I think 3 would be sufficient. Taking a look at Yahoo's ecommerce system:
for example: http://www.rima.com or http://www.supermediastore.com
They do 3 step checkout:
Step 1: Name/Address. They dont offer creating an account, but the account login could reside on this page for OpenCart
Step 2: Shipping Choice
Step 3: Payment selection and entry. This is also the confirmation step. The payment is sent AND the order is confirmed here if the card is good. Otherwise, it returns to this page for corrected payment info.

You could even do Shipping and Payment on the same page like:

Step 1: Name/Address or login
Step 2: Shipping & Payment choice/entry (do payment verification here for integrated modules like Authorize.net)
Step 3: Final confirmation showing the full total price
Last edited by Qphoria on Thu Oct 02, 2008 7:02 am, 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 scandic » Thu Oct 02, 2008 8:09 am

This is not a decision for the code side of OC. Just render one page and give the decision to split it into parts to the designers. You can easily do this with javascript. Anything else would be a one way decision.

New member

Posts

Joined
Sun Jul 08, 2007 2:48 am
Location - Frankfurt, Germany

Post by activeebiz » Thu Oct 02, 2008 9:31 am

A 2 page checkout would maybe be a good compromise...

1. Login / address page
2. Payment/shipping / order total / order confirmation (ajax updated totals based on payment and shipping choices)

Newbie

Posts

Joined
Mon Jun 09, 2008 2:10 am

Post by snover » Thu Oct 02, 2008 10:19 am

Step 3: Payment selection and entry. This is also the confirmation step. The payment is sent AND the order is confirmed here if the card is good. Otherwise, it returns to this page for corrected payment info.
The #1 rule in creating usable software is to not break the user's expectations about how the software should work. Every shopping cart system I can think of (Amazon, Newegg, Buy.com, Woot) has a final, separate order confirmation page before the payment actually gets sent through, allowing the user a final chance to abandon their order. I think it would be a bad idea to assume that users will pay attention to the fact that the payment page IS the confirmation page.
Last edited by snover on Thu Oct 02, 2008 10:21 am, edited 1 time in total.

Newbie

Posts

Joined
Thu Jul 19, 2007 5:27 am

Post by snover » Thu Oct 02, 2008 10:44 am

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.

Newbie

Posts

Joined
Thu Jul 19, 2007 5:27 am

Post by randomfactor » Thu Oct 02, 2008 11:02 am

snover wrote: [...] a final, separate order confirmation page before the payment actually gets sent through, allowing the user a final chance to abandon their order. I think it would be a bad idea to assume that users will pay attention to the fact that the payment page IS the confirmation page.
Snover has that completely right.  You need the confirmation page where the only choices for the customer are to pull the trigger, or back out of it.

Randall.

New member

Posts

Joined
Mon Jul 07, 2008 1:43 am


Post by Qphoria » Thu Oct 02, 2008 11:40 am

You guys think like customers instead of store owners.  8)

I do admit that when I first checked out at a yahoo store, it did leave me looking for that final confirm. but then I realized how much simpler it was. I don't think there is any #1 rule about the final confirmation, just what we are more used to.

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.

Looks like there needs to be multiple checkout contribs or just one very configurable system to fit everyone's preference
Last edited by Qphoria on Thu Oct 02, 2008 12:06 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 bruce » Thu Oct 02, 2008 12:33 pm

Qphoria wrote: You guys think like customers instead of store owners.  8)
Ah Q, those that do not will not be store owners for long.  ;)

Active Member

Posts

Joined
Wed Dec 12, 2007 2:26 pm

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

Daniel wrote: althought a 1 page checkout system sounds nice it makes the pages look really bulky and overly complicated.
I no longer have Magento installed but I seem to recall that Magento overcomes the bulky loooking by having  a one page checkout with the various steps separated in sections.
The sections are rolled up (I assume with ajax). As the buyer moves from step to stpe (on the same page), the previous section/step rolls up/collapses and the new step/section is expanded
Is a 1 page checkout really necessary? having it in steps seems more intuitive for the customers.
I personally don't think "one step" is necessary but rather to have reduced steps to minimise the need to keep pressing buttons to go from one page to another to another etc.
Cubecart 3 is an example of how boring checkout can be. It feels like it'll never end.
[/quote]

Virtuemart combines the Existing Customer Login page with New Customers Address details. Saves New Customers one click

Looking at www.Mals-e.com, Mals brings the shipping to the cart page. A bonus as the cart does both showing the shipping and cuts out one step of the checkout page. Buyers can pull the trigger at the cart page if shipping is too expensive for them.
The next step in Mals is to enter address. Mals uses anonymous checkout. Open cart can have this page like Virtuemart ie a combined login (for existing buyers) and address for new buyers
Again, buyers can pull the trigger at this stage
The final step in Mals is payment which acts as both payment and confirm. If the payment option is something like COD or bank deposit, this is the final step. The order is written to the database at this stage.
If the payment option is a payment gateway option, then proceed to payment gateway to make payment. Order is recorded before proceeding to payment gateway, overcomes unreliable call-back process leaving unrecorded order

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?

jty
Active Member

Posts

Joined
Sat Aug 30, 2008 8:19 am
Who is online

Users browsing this forum: No registered users and 22 guests