BrockleyJohn

@dculley It's not on the menus it's accessed via admin/orders. You should get an edit button on the old view order screen and the edit from the list should take you there unless you turn that off. If that's not happening then it must need more updating for the changes since 1.0.4.0, which I have begun.

uninstalled or just disabled?

No because then if the customer does not come back from paypal (at least 25% of the time) you get no order just a payment. You can use this as a selling opportunity to follow up incomplete orders.

Sorry that was not the problem at all - it was an issue with the indexing of the products in the cart and nothing to do with the order totals. The cart class in catalog and the original admin version in this addon do not cope with more than one order line for the same product. In the catalog they automatically get combined when you add the same product again. I updated the cart class in this addon so that it copes with the same product on multiple lines, allowing you to 'get one free', give another half price and other such real life situations that you want to show on the invoice.

@artfulweb please give this one a try - all those should be fixed edit_orders_ajax.php

That should show up in the configuration group - I guess it means that your original settings didn't have it and you've left it with the second config group id. When you did the update did you get a redirect with a message telling you there were new settings and to check them? It checks for a pre-existing install by looking for one of the settings being defined. I've just put in a change to test a different config (ORDER_EDITOR_USE_AJAX) which should be present in any existing installation of any age. I confess I'd not looked at the uninstall sql since updating the addon. I've now redone it to take out any and all configs and groups for the editor.

It seems unlikely that the tab opening is dependent on the list setting as it's hard-coded always to do it (that's how it was before). I could make it optional...

The tests in the module test against some servers that were provided by paypal (ssltest.paypal.com iirc) and they don't exist any more so the tests now fail whether your server is talking with TLS1.2 or not. The site that I referred you to checks the cipher suites that are available on your server not just the certificates - read on below them and top of the preference order is usually the one that it starts with when negotiating. Is there a problem with paypal on your site?

The tests fail because the tests are no longer supported by paypal. If you want to check your server's security use a site like https://www.ssllabs.com/ssltest/

ok - new version 1.2.8 just uploaded which installs on Phoenix 1.0.4.0 with no core changes. https://apps.oscommerce.com/Apps&wwEZ9&order-editor-for2-3-v1-0 Functionally the same as 1.2.7 but with an extra option that allows you choose whether to change the Edit button in the order list info panel or not. Extra option self-installs when you run the editor. If you already made core changes on Phoenix 1.0.4.0 you'll need to reverse them or you'll get errors.

good stuff - 1.2.8 will be along very soon with no core changes for phoenix 1.0.4.0 (just testing now)

Not entirely. Nowhere in stock osc deals with partial orders - if you want to calculate shipping for only the added products you could just add a separate order for the extra products. What's the shipping invoice to which you refer? The only thing I can think of that goes somewhere along these lines is multi-vendor shipping. I don't know if anyone uses that with the order editor.

pah, I knew I was going to regret upgrading office 2010 They're landscape but it didn't pdf them so in word 2020. Try the attached instead Order Editor Readme.pdf

So, adding the same product on two different order lines was messing up the shipping calculations (even if with different options). I reckon that shipping modules based on price didn't get the right results either. This is fixed (cart products are now indexed on uprid and the restore checks for existing key), along with the Edit button issue and also the redirect error on a fresh install. Uploaded to https://apps.oscommerce.com/Apps&wwEZ9&order-editor-for2-3-v1-0 @ArtcoInc @TomB01 Tested on 2.3.4 classic, Phoenix 1.0.4.0 and a bunch of bs versions in between but please flag up any issues.

@ArtcoInc and anyone else using shipping weights: I can confirm that there still IS a bug with shipping weights - specifically when you add a product that's already in the order, it trashes the calculated order weight (possibly overwriting instead of adding for that product, but definitely making it wrong!)

@TomB01 It seems that on Phoenix 1.0.4.0 the bootstrap script stops the jquery button function working so it must be run before bs is included. I need to do some more testing before uploading a new release but you can do an edit yourself to fix it. In includes/modules/hooks/admin/orders_edit_order.php find the script at line 37 and change from <script> $(function() { $('h1.pageHeading + div').prepend('$button'); $script }); </script> to <script> // $(function() { $('h1.pageHeading + div').prepend('$button'); $script // }); </script> ie. comment out the document ready function wrapper There was a circumstance/osc version that needed it deferring but I can't remember what that was! Clearly deferring it no longer works for core code so I'll probably make the immediate injection the mainstream version (it's also much simpler code) and include the other as a troubleshooting option. More testing first, though

Nope, I've just tried it and the changes to the admin pages has broken the jquery button script. Not sure why yet - the scripts are unchanged inline but running it from the footer seems no longer to work. And no error thrown...

https://apps.oscommerce.com/wwEZ9&amp;order-editor-for2-3-v1-0 v1.2.6 for Phoenix, 29th September 2019 - but instructions for modifying files might not be compatible with the latest versions of Phoenix There's a lot of work going on in the admin at the moment and more hooks than before so it would make sense to redesign the implementation of all admin addons including this one against existing pages as it should be possible to further reduce or even eliminate the need to change core files.

You may be better to use the actual path in this one (full physical path to your catalog directory) define('DIR_FS_CATALOG', dirname($_SERVER['SCRIPT_FILENAME']) . '/'); as this format only works in catalog pages and can break some callbacks (mostly payment or shipping modules) in the ext directory - or at least be aware of it as something to check when trying to work out why a callback isn't working. The whole point in having this setting is that it isn't necessarily the path to the running script.

careful - the country code for the UK is actually GB

v3 does, though, and real people almost never see it. If you can live with having a logo somewhere on each page (not necessarily the floating in-your-face one) it's definitely worth considering.

@ArtcoInc please would you check if it's still present on the latest version? I'm PMing you access to a test store.

Up to now there is still no way to extend the payment class to restrict the selection on checkout_payment without modifying core code, so the modification to the constructor of the core class is the simplest way of doing it. If @raiwa's latest request for a hook in the payment form might be a way in if it gets anywhere.

It might need a little tweak as the admin hooks are slightly different in Phoenix

I have just uploaded v3.1.2 to the addons area - https://apps.oscommerce.com/XpKWd&quick-update-bs This version, sponsored by @drusky, introduces coloured radio buttons for product and special status: It also includes the image fix by @dreumel and a bunch of fixes for php7.2 compatibility. Tested against CE Phoenix v1.0.1.2