camper2020

Hi there, thanks for letting us know. Can you possibly take one or two screenshots and upload to your media library or a screenshot share site and paste the links in a reply to this so we can see what you are experiencing so we can try to replicate and fix!

Hi there, thank you for your kind words regarding the plugin, I’m really glad its adding value for you!

After searching for a solution to the tax issue we decided to write this for ourselves and then release it to see if there was a need for it and also to see how compatible it would be with other WooCommerce stores and plugins as such the plugin itself is still very new – we only released version 1.0.0 a month ago! So we are looking closely at feedback to see if it is being used and how we can improve it and we do have a few ideas for features we would like to add, some in the base plugin and some potentially in a premium format to help fund development of the plugin and as such, compatibility with shipping items and custom items is one of the features we are looking at.

With regard to the 404 error, thank you for alerting us, we have released an updated version of the plugin which includes the missing file and with that a nice little “extra” which allows for adding manual refunds as a partial amount of the inclusive tax price on line items.

Please do try it out and let us know how it goes!

Thanks so much, glad its working!

Hi there, just an update that we have replicated the issue and have implemented a fix for the error when saving refunds. This should work both for the automated and manual refunds. We also added a few extra adjustments to make it easier to refund partial amounts inclusive of tax. Please update the plugin and let me know if it fixes your issue and thank you again for alerting us to the problem!

Thank you so much for the additional information, we will test on our side and I will let you know if I need more information to help get this resolved!

Hi there, thank you so much for giving my plugin a try and I’m glad you are finding it of use. Thank you for letting me know about this error. Can you provide some more details about your refund process and if you are using any other plugins to perform the refunds? We want to try replicate the error so we can get it fixed for you!

Hi there, firstly, thank you for trying out my plugin and taking the time to submit feedback, also apologies for the delayed reply. I realised notifications were turned off on this forum. With regard to your query, it can be done, there are just a few considerations we need to make:

• When editing orders that have already been placed, the system pulls the price of the product saved with the order i.e at time of order, not necessarily the current price of the product. So its not necessarily the regular price, if the product was sold while on a sale, that would be the base price pulled through which can then be adjusted
• This isn’t the case for new orders so I can see the value add of defaulting to the sale price for new orders created in the admin area, however as sale prices can also be scheduled, should the system check for if the item is actually on sale or always grab the sale price if present?
• The idea for the discount box in both WooCommerce default and this plugin is to allow for custom discount overrides, either via a coupon or directly on the product, maybe its a special order or something, but its generally a discount separate from the usual “sales price” discount. We wanted to keep this function intact with the plugin

I have given it some more thought based on the above and other possible cases that could arise and wanted to know what you think about keeping the manual entry as we have but also adding a small button to auto-populate the discount field with the “Sales price” of the product if available. This way we can keep the existing functionality while still allowing you to quickly add the sales price without need to manually type it or look it up. Could that work, let me know!

Thanks again and apart from the above, I really hope the plugin is providing some value and usefulness to you with regard to the topic of INC tax order editing and viewing!

Hi Bonesnap, great, glad you came right. Its interesting that it only affects Firefox, good spot!

I was nervous that this action might have something to do with the behaviour of functions like previous_posts_link() but it appears that there is no dependency and as yet, can’t see a proper use for that particular action, unless there is an SEO reason that I’m missing. So removing it definitely seems to be the best solution without side affects (that I’m aware of).

@esmi, always good to be reminded on that, but as Bonesnap mentioned, we by no means suggest the removal of the wp_head hook, only this one particular action from the hook.

Hey man, I was having a remarkably similar issue to you, which has taken me about a week to resolve, not sure if you ever came right?

Anyway, I think I have the solution, WordPress adds post relation links to the wp_head action. These are <link /> tags which actually call a page, the same way a CSS file is called. Anyway, I’m assuming in addition to your custom sign on page, you have a custom login page, which you have defined. If you look at your source of your pages, and in particular the page that keeps signing you out, one of these relative pages is probably the logout page. Mine was. By deleting that page, the rel then moved to another page which is why a page that was working before, stopped working.

The solution is to remove this particular action from wp_head, its not really all that important to keep anyway.

Add the following to your functions.php file of theme or your custom plugin:

remove_action('wp_head', 'adjacent_posts_rel_link_wp_head', 10, 0);

Let me know if that helps, if you already came right, then good show.

Regards.

Nice work Toby, I tested with the AJAX scenario as well, works like a dream. Just one thing I do differently because when I load pages, sometimes they’re just included with the template eg. category.php and sometimes they’re independent i.e. when the pages are loaded via AJAX. The relative path to wp-load.php changes depending on these two ways of loading so I have test for that. ??

if (file_exists("./wp-load.php"))
{
	require_once("./wp-load.php");
}
else
{
	require_once("../../../wp-load.php");
}

or if case the above is overkill… ??

if (file_exists("../../../wp-load.php"))
{
	require_once("../../../wp-load.php");
}

Could be pointless to mention all that, but you never know. Thanks again for all the hard work put into the research for this problem.

Regards.

Hi Toby.

I have / had a similar problem. I am using custom pages that load via AJAX in a site I’m building. These only reload part of the page at a time, independently. This all worked fine in WP 2.9.2 but since upgrading to WP 3.0. my AJAX stopped working. After debugging, I realised the headers of the files were being sent as 404s.

I’ve been looking for a fix and up until now, nothing. My only workaround was to tell my page to load the AJAX regardless of the 404 or 200 response. While this works, its not ideal, and technically, doesnt solve your problem.

After seeing your later posts, and noticing that its definitely a change in the wp-includes/classes.php file, I’ve coded a mini (hopefully temporary) hack that seems to work, without modifying core WP files and it should work in all scenarios.

By forcing the headers to send through a “200 ok” response, the pages load as they should. If there is a more elegant way to solve this, someone please tell me. In the meantime, add this code after including wp-blog-header.php:

status_header(200);
nocache_headers();

Hope that helps,
Regards.