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.bruce wrote: It is in an infinite loop as the function calls itself recursively with no exit point.
$this->level should be $level
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.
My pleasure Q.
I am commenting from memory now, because I always "clean up" the braces on code I work with (pedantic I know
) 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.
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
cheers
Bruce
I am commenting from memory now, because I always "clean up" the braces on code I work with (pedantic I know
) 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;
}
}
I could be wrong, but it is food for thought and this brace layout is clearer IMHO
cheers
Bruce
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 
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.
I always pull the brace back to the if line to make it easier to read and less spacey 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.
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.
http://www.aptana.com/studio <-- What I use, Likes AJAX!Qphoria wrote: Ok. It looks like nuphere doesn't like, or can't handle the stuff on the main admin home page.
If you make it idiot proof, they will just build a better idiot.
If you make it idiot proof, they will just build a better idiot.
Right but its more of a robust editor, not debugger:
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.(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
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:
should be
3. This code doesn't make any sense since it is trying to unlink an array:
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:
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!
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'])) {
Code: Select all
if ($this->request->files['image']['error'] != UPLOAD_ERR_OK) {
if ($this->request->files['download']['error'] != UPLOAD_ERR_OK) {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']);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())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.
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.
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.
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
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.
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.
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)
1. Login / address page
2. Payment/shipping / order total / order confirmation (ajax updated totals based on payment and shipping choices)
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.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.
Last edited by snover on Thu Oct 02, 2008 10:21 am, edited 1 time in total.
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. 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.
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.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.
Randall.
You guys think like customers instead of store owners. 
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
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.
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.Daniel wrote: althought a 1 page checkout system sounds nice it makes the pages look really bulky and overly complicated.
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
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.Is a 1 page checkout really necessary? having it in steps seems more intuitive for the customers.
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?
Who is online
Users browsing this forum: No registered users and 13 guests
