BrockleyJohn

That might work now but there's a good chance you'll get buttons popping up all over the place at some point in the future - it will add them to the start of every html element with the class align-self-center

Here is a version of includes/modules/hooks/admin/orders_edit_order.php that works on 1.0.5.9 as well, but you are also going to have to deal with includes/database.php not being there - either add an include into edit_orders.php and edit_orders_ajax.php or go through and edit all the sql statements. orders_edit_order.php

@SCH_001 This appears to be a bug at all versions - perhaps it never worked! I'll have a look into it.

@SCH_001 How many tax order total modules have you got enabled? The total tax is consistent it's just split into two lines - though the one that was $10 to start with changed name. Have those two products got the same tax class?

👍

You should be using the shipping modules in catalog. If you are not, you are using a different addon!

If you need to change ot_shipping.php - I don't think that's part of the addon. Check if you can reproduce on the shop checkout and if so raise a phoenix issue.

These notices are telling you that it cannot calculate the shipping order total because it can't find a match between the shipping quote stored in the session variable and the shipping classes stored in the global variable. The delivered code, fixed as suggested, doesn't do this. If you are running it in a test store you can put some debugging into ot_shipping so you can see what's not properly set. Check what $module gets set to in line 48 and if it doesn't look right, check the value of $_SESSION['shipping']['id']

it should be function __construct() {

As well as changing between modules, I can set it to zero. How do you add a discount?

@artfulweb I dont think there is not a general problem with changing shipping methods at this version. Using the demo data and shipping methods Flat and Table I can happily switch between them. I admit I have only tried this on 1.0.5.7 but that shouldn't matter. The attached order was created with Flat shipping. I have a theory that this is not related to versions at all. I think the addon doesn't properly cope with a shipping module returning an error instead of a quote as the array structures are different. Is one of your modules returning an error on the order you were editing because it is not available for the shipping address on the order? Incidentally the line numbers you quote aren't quite the same as mine. Try inserting a condition around the inner loop, to check if it has returned a quote: $r = 0; for ($i=0, $n=sizeof($shipping_quotes); $i<$n; $i++) { if (array_key_exists('methods', $shipping_quotes[$i]) && is_array($shipping_quotes[$i]['methods'])) { for ($j=0, $n2=sizeof($shipping_quotes[$i]['methods']); $j<$n2; $j++) { ... } } } The problem with my theory is that the non-ajax edit_orders should exhibit the same issue!

@PiLLaO yes, as long as you remove the includes in both edit_orders.php and edit_orders_ajax.php, the class itself is not used and the file can be removed. @artfulweb when an order disappears from the site it is usually because the order status id has been set to zero. This is something that happens occasionally with the core orders screen as well. An easy workaround to prevent orders disappearing is to manually add to the database an additional order status with status id = 0 and a description like 'status error - please reset' or whatever makes better sense to you. This is an addition to the orders_status table with orders_status_id = 0, language_id set to your admin language id, and the description set to what you want. For the error itself, what is reported?

backwards compatibility with the settings of an old addon (but not with bs gold by the look of it)

and admin/includes/languages/english/modules/boxes/master_password.php with this one master_password.php

It's because the function to draw password fields has been removed. Replace the file admin/includes/boxes/master_password.php with this one master_password.php

@dculley you just need to read the last couple of pages of posts and download the whole files - no editing required. Next fully documented release on apps will go with the next phoenix .0 release unless someone sponsors an intermediate one.

@rupruprup that should be line 1498 there are two files to change for this issue admin/edit_orders.php and includes/hooks/admin/siteWide/paymentMethodPulldown.php (you will probably still get an error with the second) edit_orders.php paymentMethodPulldown.php

@artfulweb for both buttons on 1.0.5.5 there are two files to replace /includes/modules/hooks/admin/orders_edit_order.php /includes/hooks/admin/orders/edit_orders.php no new files

@artfulweb @rupruprup for 1.0.5.5 to get the edit button on view order, replace the file includes/modules/hooks/admin/orders_edit_order.php with the attached orders_edit_order.php

Do you mean you have tried and it failed - or are you just asking about the previous comment? I believe the install is ok but the Edit button on the orders page has disappeared. @artfulweb replace the file includes/hooks/admin/siteWide/listOrders.php with the attached and the edit button will appear in the list view (if the setting says do it). I need to design a solution for the single order view that will also work for all phoenix versions to keep installation simple. listOrders.php

This is about the right time of year for USPS to break the API. That said, it might simply be that it's always been like that but the warning message was suppressed before. As it's only a warning you're not changing what the code does with Matt's changes, you're just telling it to expect the array could be empty or not exist. If there are no extra services there's nothing to process so there might not be any drama. Of course, if USPS have changed the structure of the data returned and put the information in a different place then it will need fixing.

@artfulweb that's a bug, change the line to $value_id = sew_get_products_options_values_id($option_id,$attributes['products_options_values'],0,$products['products_id']); ie. $products['products_id'] not $orders_products['products_id']

@dculley stable releases for Phoenix are the .0 releases eg. 1.0.5.0 and 1.0.6.0 Even addons that are actively maintained are unlikely to keep step with every increment.

The code checks which config group ORDER_EDITOR_USE_AJAX is in but it doesn't check if there's more than one occurrence of it (hence my original question).