Forum Replies Created

Viewing 15 replies - 1 through 15 (of 42 total)
  • I routinely use JetWoobuilder (one of the best plugin of its kind, btw) without any problem. I see that you are also using “Easy PayPal & Stripe Button” plugin: my humble guess is that the problem lays there. Would you like to try to switch to another plugin (I suggest Woocomerce PayPal payments) for a test?

    Yeah, sorry, I didn’t look at your php but just the js.

    You don’t need to use an action hook, since wc_enqueue_js will output the code in the footer.

    Simply use

    wc_enqueue_js('
          var num_chars = 10;
          var replace_ellipses = " ... ";
          var description_content = $(".woocommerce-Tabs-panel--description p").html();
          if (description_content.length > num_chars) {
             var a = description_content.substr(0, num_chars);
             var b = description_content.substr(num_chars - description_content.length);
             var html = a + "<span class=\'truncated\'>" + replace_ellipses + "<a class=\'read-more\'>Read more</a></span><span class=\'truncated\' style=\'display:none\'>" + b + "</span>";
             $(".woocommerce-Tabs-panel--description").html(html);
          }
          $(".read-more").click(function(e) {
             e.preventDefault();
             $(".woocommerce-Tabs-panel--description .truncated").toggle();
          });
       ');

    Add “p” to $(“.woocommerce-Tabs-panel–description”), so set

    var description_content = $(".woocommerce-Tabs-panel--description p").html();

    It should work now.

    Surely there is a way but it implies code customizations because I think it is not feasible with the standard options.

    As an idea, maybe set a flag on user registration and then pull that option for the logged user to show price with reduced VAT rate (add a custom field on user registration, pull the option and set the VAT rate – maybe on ‘woocommerce_order_before_calculate_taxes’ action hook, but I’m not sure).

    I confirm there is no paypal payment and that it is not loaded at all on frontend. Please do a conflict test and post debug/system log. The issue shouldn’t be woocommerce related since this is a common setting, it is another plugin which is probably conflicting.

    I don’t think I’ve never insulted you, did I?

    However, this is a support forum, not a complain forum and you didn’t came for support but just to bawl against Woocommerce, so…

    Finally, you SHOULD have waited the minimun time for a refund before doing anything like you did. And I suppose Woocommerce would had charged you anyway because you used their services initially (I’m not sure since I usually use PayPal) and that would be normal like any payment service/gateway.

    First thing, maybe, just MAYBE you could have used a real developer to setup and test your store. Gelato says that it is possibile to test without adding a payment method (orders are simply not forwarded to print), so why did you do it that way?

    Second, have you waited a full month? Sometimes it takes up to a month to see a refund on a credit card.

    Third, it is normal to be charged for a dispute, this is done by almost all payment services. It’s your fault to have made payments and then dispute them as a buyer, then you were charged because you were the seller at the same time.

    I think you messed up a little, so why all this speech against Woocommerce? And (because of your errors) for 30$? Seriously?

    Claiming Woocommerce to be a scam company (tip: Woocommerce is not a company) with millions of people using it with success while you made errors it’s not a good deal to bring them to court…

    Ok, there is clearly a communication problem here. I’ve already told you which hooks could do what you need.

    woocommerce_checkout_create_order

    manipulates data JUST BEFORE order creation, while

    woocommerce_checkout_update_order_meta

    manipulates data JUST AFTER order creation.

    Specifically, the latter is used to add metas.

    If they don’t work it’s clearly a) your function fault or b) a default behaviour of apple pay. So I’m asking again, can you post your code so we can take a look at it? Have you logged the function steps? Does the function trigger but no data is saved? Or doesn’t the function trigger at all?

    Hello, I’ve already answered your question. Those hooks works as I said. What are you trying to achieve? Post at least some code or try to log the output of your functions and post it here, we can’t try to guess what’s happening.

    I think what you are trying to do it’s not right nor possible. That option modifies an existing discount price by a %, but if a discount is not already set, it will not work (since there is any discounted price to decrease).

    You have to set a discount price for every product (and there is no massive function for that without an additional plugin). Only then you can increase/decrease the discounted price massively.

    I can suggest a workaround.
    Export all of your product in csv, selecting just “ID”, “Sale Price” and “Regular Price” columns. Then use an excel/calc function to calculate a -25% from “regular price” column to “sale price” column and upload the file again (just remember to select “update existing products”).

    Hi, woocommerce_checkout_order_processed is indeed the right hook. Have you tried to log the output of the function and its variables to catch where the fail point is?

    Alternatively, you could try these action hooks:

    woocommerce_checkout_create_order (@param $order, @param $data, @return void)

    or

    woocommerce_checkout_update_order_meta (@param $order_id, @param $data, @return void)

    First one fires just before $order_id = $order->save();.
    Second one fires just before woocommerce_checkout_order_processed.

    However, assuming you are trying to store user informations for marketing purpose (since I read a klaviyo-related function) my hypothesis is that whoever uses applepay is presumably using an apple device, hence is blocking by default a lot of marketing functions and what you are trying to store (klaviyo id maybe?) is simply not stored/blocked upstream.

    • This reply was modified 1 year, 7 months ago by techedge.

    To begin with, you didn’t mention that the error has appeared 30 times in a row within a minute (by the way, this is irrelevant, since the error is just one and the same and not “a lot”).

    Furthermore, I’m glad you understood the issue but you didn’t give us any other information to help. The log you posted is, again, irrelevant, since there is no contest: we already knew that a function was called passing a NULL argument from the title of your post. I asked for more informations (as they are requested by the sticky post of the board) to try to pinpoint the issue.

    Lastly, I’m a forum user like many others, because, you know, this is a Support Forum and even users (other than the plugin developers) will try to help each other, if given a chance.

    I’m sorry but I think that’s what the limit of woocommerce was trying to avoid. I haven’t noticed too much slowdown but I don’t have your number of variations, it may also depend on the server though.

    Glad to hear you made it work!

    Hey, thank you for the tip on the plugin! I usually don’t experience problems with the standard Woocommerce functions, but it’s nice to know there is an alternative!

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