Edit Orders v4.0 Support Thread

I am desperately trying to get this plugin to work but after upgrading super orders (and verifying it worked) then re - installeing edit orders as per the instructions in the readme file I still get a 404 error when clicking the Edit button. the button is trying to take me to:
http://gslcuts.com/Store/zoo/FILENAME_ORDER_EDIT.php?page=1&oID=3305&action=edit
so I dont beleive the installation files are doing this bit:-NOTE: As per the readme, Edit Orders will automatically update the relevant files including "/admin/orders.php" when the installer is run. Among other things it replaces FILENAME_ORDER_EDIT with FILENAME_EDIT_ORDERS.
Any help would be greatly appreciated as its driving me nuts
I do NOT have Ty Package Tracker installed

angdrumm:

I am desperately trying to get this plugin to work but after upgrading super orders (and verifying it worked) then re - installeing edit orders as per the instructions in the readme file I still get a 404 error when clicking the Edit button. the button is trying to take me to:
http://gslcuts.com/Store/zoo/FILENAME_ORDER_EDIT.php?page=1&oID=3305&action=edit
so I dont beleive the installation files are doing this bit:-NOTE: As per the readme, Edit Orders will automatically update the relevant files including "/admin/orders.php" when the installer is run. Among other things it replaces FILENAME_ORDER_EDIT with FILENAME_EDIT_ORDERS.
Any help would be greatly appreciated as its driving me nuts
I do NOT have Ty Package Tracker installed

Please identify which version of Edit Orders is being attempted to be installed, as well as the other information of the posting tips...

mc12345678:

Please identify which version of Edit Orders is being attempted to be installed, as well as the other information of the posting tips...

Please ignore my previous post, I am really not sure what happened but I have got it working. I havent a clue what I did however :( Thanks for answering anyway

Suddenly when I edit an order and click "Update" it is redirected to the site's home page, no changes were done to the site

ok, i have searched a bit in this thread for this bug, and i did not see it. if i missed it, and i am duplicating a post, i apologize in advance. i suppose in the grand scheme of things, this bug is minor, but, a bug is still a bug.

if an admin enters a coupon code for an order, the coupon code does not get populated in the orders table. and without the field, the couponpopupWindow will NOT properly display on the customers side (or the admin side). the easiest fix i have found without changing much of the logic, starts at line 465. below is the original section of code along with my proposed fix to it.

						case 'ot_coupon':
							// Default to using the title from the module
							$coupon = rtrim($order_total['title'], ': ');
							$order_total['title'] = $GLOBALS[$order_total['code']]->title;

							// Look for correctly formated title
							preg_match('/([^:]+):([^:]+)/', $coupon, $matches);
							if(count($matches) > 2) {
								$order_total['title'] = trim($matches[1]);
								$coupon = $matches[2];
							}
							$cc_id = $db->Execute(
								'SELECT coupon_id FROM `' . TABLE_COUPONS . '` ' .
								'WHERE coupon_code=\'' . trim($coupon) . '\''
							);
							unset($matches, $coupon);

							if(!$cc_id->EOF) $_SESSION['cc_id'] = $cc_id->fields['coupon_id'];
							else {
								$messageStack->add_session(WARNING_ORDER_COUPON_BAD, 'warning');
								$order_total['title'] = '';
								$order_total['value'] = 0;
							}
							unset($cc_id);

// proposed fix:

						case 'ot_coupon':
							// Default to using the title from the module
							$coupon = rtrim($order_total['title'], ': ');
							$order_total['title'] = $GLOBALS[$order_total['code']]->title;

							// Look for correctly formated title
							preg_match('/([^:]+):([^:]+)/', $coupon, $matches);
							if(count($matches) > 2) {
								$order_total['title'] = trim($matches[1]);
								$coupon = $matches[2];
							}
							$cc_id = $db->Execute(
								'SELECT coupon_id, coupon_code FROM `' . TABLE_COUPONS . '` ' .
								'WHERE coupon_code=\'' . trim($coupon) . '\''
							);
							unset($matches, $coupon);

							if(!$cc_id->EOF) {
								$_SESSION['cc_id'] = $cc_id->fields['coupon_id'];
								$sql_data_array['coupon_code'] = $cc_id->fields['coupon_code'];
								zen_db_perform(TABLE_ORDERS, $sql_data_array, 'update', 'orders_id = \'' . (int)$oID . '\'');
								unset($sql_data_array);
								$order_updated = true;
							} else {
								$messageStack->add_session(WARNING_ORDER_COUPON_BAD, 'warning');
								$order_total['title'] = '';
								$order_total['value'] = 0;
							}
							unset($cc_id);

Hello,

I've got a custom module for combined attributes pricing. As I'm not the one who wrote it (I don't have the skills) I've reviewed its files and quite understood how it works .
The module maintains a table where it keeps rules (if attrib-A price=A then attrib-B price =x)
A class handles all the price changing in session values (I think), but most important everything is done by monitoring four events :
NOTIFIER_CART_CALCULATE_ATTRIBUTE
NOTIFIER_CART_ATTRIBUT_SELECT
NOTIFY_HEADER_SHOPPING_CART_OPTION_PRICE
NOTIFIY_ORDER_CART_FINISHED.

On any of these events the class is triggered and changes the attributes prices.

But now I'm planning to use Edit Orders, and as this behavior is only monitoring the client side, prices are not changed in Edit Orders.

Do you think adding "$this->notify" lines to the Edit Orders would be enough to trigger the class and change prices ?
If so, can an Edit Order expert suggest me where to place these line in the edit_orders.php file ?

Thanks for your help.

Hubert

I am not an EO export, but it's a very popular plugins among my clients.

The current (4.1.4) version of EO includes a mock shopping-cart class, where the cart-related notifiers might be added; you'll need to review the functions where those top two notifiers are issued in the store-front class and then mimic that behavior in the mock-cart class.

The admin-console version of the order-class only supports order-instantiate, not create-order-from-cart (where the last notifier is issued store-front), so you'll need to review how that notifier is used by the plugin so that you can mimic that behavior within the admin-console handling.

Finally, you'll need to create an admin-console auto_loader to make sure that your attribute-calculator is loaded during the admin-level processing so that it's available to handle those notifications.

Thanks lat9, but let me rephrase to be sure I understood what you're saying.

1-ZC naturally issues events that can be interrupted and triggers a new add-on behavior.

lat9:

I am not an EO export, but it's a very popular plugins among my clients.

The current (4.1.4) version of EO includes a mock shopping-cart class, where the cart-related notifiers might be added; you'll need to review the functions where those top two notifiers are issued in the store-front class and then mimic that behavior in the mock-cart class.

2-EO has its own cart management class, so I have to add notifier calls to this class so that these new events calls my behavior.

lat9:

The admin-console version of the order-class only supports order-instantiate, not create-order-from-cart (where the last notifier is issued store-front), so you'll need to review how that notifier is used by the plugin so that you can mimic that behavior within the admin-console handling.

3-ZC Admin side, and so EO does not makes regular orders but only loads existing orders, modifies (thanks EO), and replace the order in the tables.

lat9:

Finally, you'll need to create an admin-console auto_loader to make sure that your attribute-calculator is loaded during the admin-level processing so that it's available to handle those notifications.
That is the easy part :-)

Reading you I just realized that these four events :
NOTIFIER_CART_CALCULATE_ATTRIBUTE
NOTIFIER_CART_ATTRIBUT_SELECT
NOTIFY_HEADER_SHOPPING_CART_OPTION_PRICE
NOTIFIY_ORDER_CART_FINISHED

are not in https://www.zen-cart.com/wiki/index.php/Developers_API_Tutorials#Notifiers_currently_set_in_Zen_Cart.

Or are they and the website list is only (as stated) "Notifier points for Zen Cart 1.3.7".

In other words has the developer created its own events or are these regular ZC 1.5 events. I didn't saw that these could be custom events.

The notifiers that your custom-module uses are, I think, built-in to the Zen Cart store-front processing. You can see where they are used by entering each one into your admin's Tools->Developers Tool Kit. That wiki article hasn't been updated in a dogs-age.

Just for reference,
NOTIFIER_CART_CALCULATE_ATTRIBUTE
NOTIFIER_CART_ATTRIBUT_SELECT
NOTIFY_HEADER_SHOPPING_CART_OPTION_PRICE

are not in the 1.5.4, only
NOTIFIY_ORDER_CART_FINISHED is in /includes/classes/order.php.

If ever..for 1.5.5... If the team thinks these events have to be included in next release.

NOTIFY_HEADER_SHOPPING_CART_OPTION_PRICE is called in /includes/modules/pages/shopping_cart/header_php.php
line 119

   $attr_value = $attributes_values->fields['products_options_values_name'];
      }
	  $zco_notifier->notify('NOTIFY_HEADER_SHOPPING_CART_OPTION_PRICE',array('rs'=>&$attributes_values,'products_id'=>$products[$i]['id']));

      $attrArray[$option]['products_options_name'] = $attributes_values->fields['products_options_name'];

NOTIFIER_CART_ATTRIBUT_SELECT
and
NOTIFY_HEADER_SHOPPING_CART_OPTION_PRICE are called in /includes/classes/shopping_cart.php

line 682

   $attribute_price = $db->Execute($attribute_price_query);
          $this->notify('NOTIFIER_CART_CALCULATE_ATTRIBUTE', array('cart'=>$this,'rs'=>&$attribute_price,'products_id'=>$products_id,'options_id'=>$option,'options_values_id'=>$value));

          $new_attributes_price = 0;

and
line 891

       $attribute_price = $db->Execute($attribute_price_query);
    	$this->notify('NOTIFIER_CART_ATTRIBUTE_PRICE_SELECT',array('cart'=>&$this,'rs'=>&$attribute_price,'products_id'=>$products_id,'options_id'=>$option,'options_values_id'=>$value));

        $new_attributes_price = 0;

which seems logical to me.

And just to notice that it works with Dynamic Price Updater 2.0, i.e., when I change the size (first attrib), the price of other attributes is changed, and when I check the box of one of these changed attributes the final price is good thanks to DPU.

Just a question to EO authors : why the payement method is not a dropdown menu ? It would be much easier than typing Cash on delivery or Credit card letter by letter, no ?

hubert:

Just a question to EO authors : why the payement method is not a dropdown menu ? It would be much easier than typing Cash on delivery or Credit card letter by letter, no ?

Not an EO "author".

And what if one wanted to apply a method that was not in that dropdown? Sure, additional ajax/javascript/etc could be added, but as a base operation is that extra code truly needed?

mc12345678:

Not an EO "author".

And what if one wanted to apply a method that was not in that dropdown? Sure, additional ajax/javascript/etc could be added, but as a base operation is that extra code truly needed?

Don't we have a finished list of payment methods ? Are not these listed as payement modules ?

hubert:

Don't we have a finished list of payment methods ? Are not these listed as payement modules ?

ZC has a "finished list", but with this plugin not all transactions need actually occur within ZC and store owners can go on to do/document what they wat to support their business needs.. ZC doesn't limit all possibilities to just what is in ZC. Besides that, it's moldable enough such that if you don't like something you can change it. :) but if that list was something desired and to only limit things to that list, additional coding could be done to limit that. All in a matter of what suits ones selling needs. :)

Hello,

As some has noticed I was in the process of getting Dynamic Price Updater to work within Edit Orders.
I've dug into the code and understood a lot, and this is not as easy as it seems.

1. First problem.
   Edit Orders which is on the admin side, deals with orders. That is completely different from the customer side : on the client side we deal with a cart. What's the difference ? The difference is about products and attributes ids.
   As those who write code certainly already knows, on the client side products are unique. When, as an admin, you add products to your catalog, these products are (in a manner) templates for products to sold. If you sell T-shirts for example, you don't add to the catalog each copy you own, you just add a model with some attributes.
   As long as the customer has not pressed the Confirm Order button, the T-shirt is only a template T-shirt. When the customer clicks the Confirm Order button, all the products that are in the cart are copied in a new database table and then, this is the copy you sell.
   When the order is done, products and attributes are getting new ids for each copy sold.

As Dynamic Price Updater is using AJAX techniques to read the attributes id in the html page... You see the problem. Id are different. Of course the databases could tell what is the original id of an attribute but modifying DPU so that it makes this request to the database is beyond my javascript and Ajax skills.

2. 2nd problem.
   When you are a customer the webpage you're browsing only shows you one product. In Edit Orders when you click Edit, the whole order is opened to modification which means you have to deal with several products on the same page.
   Just saying... Wouldn't it be more elegant to be able to edit one product at a time in Edit Orders, that would prevent errors by not opening to modification the products that are not meant to be modified.

3. 3rd problem (which can be 2bis).
   I also have a custom module which is making combined attributes pricing, and this one has a table with price modification rules in it. This modules does two things, it writes the price of the attributes just next to their name and also makes things so that the modified price is taken into account in DPU and the cart. So it also uses the same Ajax technique.

I know there's plenty of Ajax tutorials out there and believe me a read a bunch to finally understand what was going on behind the scene, but if there was someone thinking that's not a big deal to help...

mc12345678:

ZC has a "finished list", but with this plugin not all transactions need actually occur within ZC and store owners can go on to do/document what they wat to support their business needs..

Just adding an "other" option would be enough to get everybody happy, no ?

mc12345678:

ZC doesn't limit all possibilities to just what is in ZC. Besides that, it's moldable enough such that if you don't like something you can change it. :)

Here I think the rationale should be the other way around and is in most cases : if we have a finished list of ot_ modules or shipping modules this should be in a dropdown.
Customizing is obviously if you want something more. I don't want something more, I just it to be more user friendly.
Here, the shop already has a finished list of payement modules that could be retrieved so I don't see why it's open to typing anything more as what you type is meant to be something that exists. I didn't test but I'm quite sure you can't say that someone paid giving m&m's. :-)

no ?

Hello,

running ZC 1.5.4 with Super Orders 4.0.9 and Edit Orders 4.1.1.
Set as using mock cart (but that doesn't make a difference)

Most of my products are priced by attributes, the size price is the base price and other attributes can add amounts to this base price.

When I change the Size drop down menu in Edit Orders and click Update, nothing changes. Seems to me that Edit orders never goes to review the attributes prices or even if it does, it doesn't calculate the final price so that it reflects sum of attributes prices.

Am I confusing ? Or Am I supposed to enter the new price manually in the boxes ?

I hoped that EO was going to get the Size price from the tables and apply it to my modified product, instead nothing is changing...

Any reason you're not using EO 4.1.4 (the most recent version)?

sorry it is 4.1.4... typo