Forum Replies Created

Viewing 15 replies - 1 through 15 (of 66 total)
  • This gets me to thinking at some point I’ll probably completely change this site to use Azure as the authentication provider as well. At the time I set this site up we didn’t have the accounts sync’ing to Azure so it wasn’t an option at the time.

    I changed my password reset URL by adding this to my functions.php:

    add_filter( 'lostpassword_url', 'my_lost_password_page', 10, 2 );
    function my_lost_password_page( $lostpassword_url) {
        return 'https://aka.ms/sspr';
    }

    Now it just brings them to the Azure self service password reset url. Works well.

    We use Exchange Online for email and self-service password reset via Azure AD.

    klishb

    (@klishb)

    Advanced Cron Manager

    klishb

    (@klishb)

    Also, if/when you implement this would it support seeing results if we have disabled WP_CRON and are instead using real cron jobs on the web host?

    klishb

    (@klishb)

    You will be my hero if you can put that in. I’m using another plugin, but would switch to your plugin for that feature.

    Sounds good. Thank you @shaunkuschel

    @nicolamustone

    I can assure you our plugin is up to date. We’ve been using the plugin since before the feature was discontinued. Please see this page:

    https://docs.woocommerce.com/document/woocommerce-services/

    It states the following:

    WooCommerce Services no longer provides the option to set up live shipping rates in stores as of the release of WooCommerce 3.5. Live rates will continue to work for stores currently using them.

    It’s not a huge deal. I just wanted to know if there was a filter hook so I could maintain the USPS title I gave it on the back end so customers checking out know how that option will be shipped if they choose it.

    klishb

    (@klishb)

    Hi @shaunkuschel,

    Sorry no I’m talking about in the cart and checkout. The title of each shipping method can normally be renamed in WooCommerce settings. Let’s say I name a method “Post Office”. Ordinarily that would be displayed in the shopping cart/checkout pages. The title you define is replaced by WooCommerce Services though based on the best packages that the logic determines are options. So even if though I have named the shipping method “Post Office” that gets replaced by “Priority Mail” or “Flat Rate: Priority Mail” for example. Whereas if I name a shipping method “Free In-Store Pickup” then I see that actually displayed as a shipping option when checking out. Does that make sense? If not I can try to get some screenshots. Thanks.

    klishb

    (@klishb)

    Hi Shaun @shaunkuschel,

    I’m going to put a full summary of the problem in my eyes:

    In our case we have food items (product tax code 40030) and candy items (product tax code 40010). In New York state, the shipping is not taxable if the entire cart is not taxable. So if I have all food items in the cart then the shipping should not be taxed. As soon as I put candy in the cart then the candy should be taxed and shipping should be taxed.

    That all works in the WooCommerce Services implementation on the first transaction you do for any particular zip code. The plugin then writes to the tax class tables for caching purposes. That’s when it breaks. Subsequent sales will forever return the wrong result for tax on shipping because it’s no longer using the API for that zip code. Really the caching will never be reliable because whether or not shipping should be taxed needs to be determined at the time of sale since it’s based off what’s in the cart.

    klishb

    (@klishb)

    Hi Eric @winmkt,

    As a side note, if you know what items are taxable I think you can use standard tax class on everything that you want taxable. I would rather have it dynamically determine that in case any laws change. For some reason you won’t find this in the WooCommerce Services documentation anywhere, but in order for this to correctly identify whether a product should be taxed you need to set it to taxable and set the tax class code per the TaxJar API documentation. That’s what I’ve done and if you look at the API request and and response you’ll see those tax codes do get used in the API call if you define them on products.

    I really think WooCommerce Services should have that referenced in their documentation.

    klishb

    (@klishb)

    Shaun,

    Wanted to add one more thing. I’ve studied the API request and responses. It actually works correctly the first time. It’s the tax table caching that’s breaking it. Once it populates the tax tables then it doesn’t work correctly. Is there any way to disable the tax table caching?

    klishb

    (@klishb)

    Hi Shaun,

    I guess my concern is that I’m not trying to do anything special here in my opinion. No advanced features, reporting, or automatic filing of taxes, etc. Certainly those kind of things should require a more full featured plugin. Whether or not shipping should be taxed is in the API response you’re already getting back from TaxJar. Leveraging that response seems like it would be quite straight forward to code and not a time-consuming task. We’re also not talking about adding additional features. This is about fixing something already in the product that doesn’t work.

    • This reply was modified 3 months ago by klishb.
    klishb

    (@klishb)

    Since I’m pretty sure it was coming from JetPack I just disabled that plugin and confirmed it goes away. That being said, I’m pretty sure JetPack is only outputting those lines because I have WooCommerce installed.

    klishb

    (@klishb)

    Definitely not resolved. Support asked that I open a ticket in their system, but they aren’t willing to fix the issue. WooCommerce Services doesn’t correctly use the response returned by the API:

    “freight_taxable”: false,

Viewing 15 replies - 1 through 15 (of 66 total)