janpaulkleijn

Hi Ismiaini,
I have created a Dutch translation with Poedit. Poedit has searched for translation strings which I translated. But this translation file cannot be imported on the page you mentioned (https://translate.www.ads-software.com/projects/wp-plugins/invoicing-quotes/)

It looks like there are very different translation strings in the file on the page you mentioned then there are in the Quotes addon.

Regards,
Jan-Paul

Hi Patrik,
Where can I email the translation file to?

I found out that the WP-Rocket LazyLoad plugin causes the issue to be worse. This probably due to the fact that the inconsistent HTML markup messes up its working.

Confusing.
Lacking WCAG tools (as abbreviations).
Lacking editor tools as Character map.
According to the author here not even finished.

But in the end it’s standard installed with WordPress and it’s not even possible to simply change the editor back to the old one.

WHY???

Solved it myself, quite proud of that actually ??

UNINSTALL THIS CRAP!

Put this in functions.php

if ( version_compare($GLOBALS['wp_version'], '5.0-beta', '>') ) {
    // WP > 5 beta
    add_filter( 'use_block_editor_for_post_type', '__return_false', 100 );
} else {
    // WP < 5 beta
    add_filter( 'gutenberg_can_edit_post_type', '__return_false' );
}

Bye bye Gutenberg.

It’s bad peace of software made by a development team that probably does not even understand what a special character is. Their logic: “I don’t use it so … bugger off or buy a Mac.”

This is a UI-ISSUE or UI-BUG in WordPress. Please treat it as such.

Hi Steven, did I mention that I already solved the issue? If not, well I did. The comment that was ‘gone’ was made by a person that had never made a comment before.

An e-mail was sent despite the UNchecking of the ‘Comment must be manually approved’ checkbox. This e-mail was sent for confirmation of the publishing of the comment. After clicking ‘approve this comment’ in the email an error was produced in the WordPress backend saying that ‘an invalid ID was given’.

This was the first comment on the site and the comment was counted as being there but the list said that there were ‘no comments found’.

After I unchecked the checkbox ‘Comment author must have a previously approved comment’ things were back as normal.

By the way, this does not mean that the issue is solved. The issue with this WordPress comments function (Comment author must have a previously approved comment) in combination with the disappearing of the comment in the list is in my opinion a WordPress issue. It could easily be solved by disabling and unchecking this second option (Comment author must have a previously approved comment) when the first option (Comment must be manually approved) is unchecked. An admin can only have power over this second option when the first option is checked. Otherwise it should be disabled and unchecked.

So it’s a UI issue IMO.

But thanks for thinking with me.

• This reply was modified 6 years, 2 months ago by janpaulkleijn.
• This reply was modified 6 years, 2 months ago by janpaulkleijn.
• This reply was modified 6 years, 2 months ago by janpaulkleijn.

I noticed that.

PS, I want to correct myself, the WC()->session->set('cart', array()); in my posted code above was unneccesary to use.

I have added a remark in the case of pending orders on the thank-you page. The remark is about if you cancelled the payment then you have nothing to worry about.

If a merchant can sell, the merchant can also solve this. It’s a minor drawback.

So from now on I am a subscription merchant on the web. Cheers!

By the way, the way I solved it (currently disabled) was by using the hook ‘after_woocommerce_pay’. It worked but perhaps you have a better insight of these things?

The code:

add_action('after_woocommerce_pay', 'my_function_clear_cart', 110);
function my_function_clear_cart() {
  WC()->cart->empty_cart(true);
  WC()->session->set('cart', array());
}

Thanks for your relentless commitment ??

• This reply was modified 6 years, 10 months ago by janpaulkleijn.

I guess the edge case you are referring to is the case where a merchant allows just one subscription-variation per customer in a one subscription shop. Particularly combined with added delivery of goods that have limited availability.

So I realize that, though in my case it’s preferrable to empty the cart after a cancelled payment it could not be useful for another merchant. But I leave that to you.

It certainly does make sense to me. And this takes place faster when we are testing instead of live payments?

Is there any way, any way at all that you can help me prevent customers from ever seeing the message ‘Order completed’? Because I can imagine my customers would be a bit confused if/when they see this message after they just cancelled the order.

In the Mollie log I find a subtle but distinct difference between cancelled payments that went OK and cancelled payments that went not so OK.

The notice of the not so OK cancelled payments is:

2018-01-15T00:54:56+00:00 DEBUG mollie_wc_gateway_ideal: Create payment for order 2757
2018-01-15T00:54:56+00:00 DEBUG mollie_wc_gateway_ideal: Payment tr_SfJxN8sxQb (test) created for order 2757
2018-01-15T00:54:56+00:00 DEBUG For order 2757 redirect user to payment URL: https://www.mollie.com/paymentscreen/testmode/?method=ideal&token=b8lprf
2018-01-15T00:55:14+00:00 DEBUG Mollie_WC_Plugin::onMollieReturn: Redirect url on return order mollie_wc_gateway_ideal, order 2757: https://www.domain.nl/bestel/order-received/2757?key=wc_order_5a5bedcfcced6&utm_nooverride=1
2018-01-15T00:56:15+00:00 DEBUG mollie_wc_gateway_ideal: Mollie payment tr_SfJxN8sxQb (test) webhook call for order 2757.
2018-01-15T00:56:15+00:00 DEBUG Mollie_WC_Gateway_Abstract::onWebhookCancelled called for order 2757

And the notice for the OK cancelled payments is:

2018-01-15T00:04:44+00:00 DEBUG mollie_wc_gateway_ideal: Create payment for order 2737
2018-01-15T00:04:44+00:00 DEBUG mollie_wc_gateway_ideal: Payment tr_d8wkPgsTs5 (test) created for order 2737
2018-01-15T00:04:44+00:00 DEBUG For order 2737 redirect user to payment URL: https://www.mollie.com/paymentscreen/testmode/?method=ideal&token=80bull
2018-01-15T00:04:48+00:00 DEBUG mollie_wc_gateway_ideal: Mollie payment tr_d8wkPgsTs5 (test) webhook call for order 2737.
2018-01-15T00:04:48+00:00 DEBUG Mollie_WC_Gateway_Abstract::onWebhookCancelled called for order 2737
2018-01-15T00:04:48+00:00 DEBUG Mollie_WC_Plugin::onMollieReturn: Redirect url on return order mollie_wc_gateway_ideal, order 2737: https://www.domain.nl/bestel/order-pay/2737?pay_for_order=true&key=wc_order_5a5be20c10d26&utm_nooverride=1

What do you think?

• This reply was modified 6 years, 10 months ago by janpaulkleijn. Reason: edited out domain name

I removed the OWASP 3.0 ruleset, it was a bit redundant. Every bit of erratic behavior went away and woocommerce works as stable as a rock.

But after intensive testing I noticed that sometimes with my twentyseventeen child theme it still did not respond well after cancelling the payment.

So I removed all unneccesary plugins and switched to the standard twentyseventeen theme and noticed that after 5 tries, not once did it respond well after cancelling the payment.

When you tried to reproduce this, have you tested multiple times? The behavior is very much erratic.

Found out that the culprit was the OWASP 3.0 ruleset (modsec), via the apache error_log.