chrismask

Okay, I see. Can this all happen programmatically? Do you offer any actions/filters so I can integrate the plugin with my theme through custom code, and all of this happen programmatically without the admin having to do it manually? Also, can I programmatically set if a specific order will be done through payment plan with deposit and isntallments (we have already set on your plugin Payment Plans), or without installments (default order)?

I cant create an admin order with deposit and installments at all, it always is full payment. I have changed the settings and forced installments on all orders but still doesnt work. Its the demo you sent me, can you explain how can I set installments for backend orders?

I see, is there a way I can customize the plugin so it works with Pay for Order checkout, meaning that the order will be split into installments as soon as the order is created programmatically? On your premium version, can I customize it to make this happen?

Hi, can you fix it for the also woocommerce default: Pay for order checkout? It doesnt add the payment methods on order metadata thus the refunds dont work since order doesnt have any payment method attached.

Thank you, very good job.

But, Loco plugin indeed runs the php two times i have done many tests that can confirm it. For example if i have woocommerce po both on languages/loco/plugins (custom) and language/plugins (system), its significantly slower (0.1s), while immediatelly when i delete one of these it gets to 0.06s. I have done hundreds of these benchmarking, and the time is very consistent according to the php file size. I havent customize the load plugin testdomain filter, this is the default behavior from Performant tranlsations combined with loco translate.

View post on imgur.com

Okay, i use loco translate on custom and default folder inside /language/ but, even though i have set auto_update_translation to false, in order not to download default plugins translations, so i use only on custom, they are downloaded and put on /plugins/, apart from /loco/plugins/ (which i have my default translations. I think when this download happens, your plugin detects both, and adds another php file, so it duplicated mo.php adding .php in the end, thus the mo.php.php file. I also have found that BOTH are run from your plugin, which makes it slower. For example when I have woocommerce plugin po both inside /plugins/ and /loco/plugins/ and it makes the performant translations why slower.

At last, I have some concerns about the secury of these approaches, since the po files which are downloaded automatically (and cant be stopped) are instanlty converted to .php and run on each page load, which could have implications. What are your plans to make this approach as secure as possible?

Woocommerce indeed needs to take the admin/frontend approach to their po files, no other plugins are so large and widely used and from wordpress team, so if one has to do this, its woocommerce. Indeed automatically understanding whats to be used for each scenario is difficult enough.

My question was clear enough, i use

    wp_localize_script(  $this->_token . '-frontend', 'listeo_core', $localize_array);

to display some strings for other js scripts, but translatepress doesnt translate none of these strings, probably due to wp_localize_script being one of blacklisted functions inside the function process_gettext_strings:

        $blacklist_functions = apply_filters( 'trp_gettext_blacklist_functions', array(
            'wp_enqueue_script',
            'wp_enqueue_scripts',
            'wp_editor',
            'wp_enqueue_media',
            'wp_register_script',
            'wp_print_scripts',
            'wp_localize_script',
            'wp_print_media_templates',
            'get_bloginfo',
            'wp_get_document_title',
            'wp_title',
            'wp_trim_words',
            'sanitize_title',
            'sanitize_title_with_dashes',
            'esc_url',
            'wc_get_permalink_structure' // make sure we don't touch the woocommerce permalink rewrite slugs that are translated
        ), $text, $translation, $domain );

Also, i tried trp_translate (https://translatepress.com/docs/translation-function/) but these are not for gettext strings, is there another function that i can use for gettext translations?

Ι haven’t altered anything, the pay for order part of checkout is a woocommerce default template and many stores use it, the payment methods are the same and must be also compatible with it. It’s the form-pay.php template of /checkout/ folder in woocommerce. What’s missing on your end is that it doesn’t add the payment method and payment method title on order meta data as it should.

Thank you for your answer, as it seems, the problem shall be because of order-pay checkout template and not the default checkout with cart, because it doesnt add the revolut-pay payment method meta on order and thus woocommerce doesnt understand which payment method the order was from in order to refund it with the same. It doesnt even have the “Payment via Revolut Pay” label on top of the order page. As i told you, i have no refund with revolut pay button on order refund dashboard, for the reason i told you. Can you test it on your end, on the order-pay (form-pay.php template) checkout apart from the regular checkout?

• This reply was modified 1 year, 2 months ago by chrismask.
• This reply was modified 1 year, 2 months ago by chrismask.

Note that neither this nor the HPOS compatibility issues i have opened are resolved on code. These have to be fixed by the engineering team on next updates. Refunds on Revolut Pay and Woocommerce HPOS compatibility dont work!

Just to note, I only use Revolut Pay. It doesnt work on this, neither programmatically, woocommerce implying that it the order hasnt got any payment_method attached to it so it doesnt know which one to refund with, and on wordpress dashboard, there is no button Refund via Revolut or something at all (probably due to the same reason). Can you test with Revolut Pay and attach a screenshot?

As it seems, i found a big problem due to the absence of _payment_method and _payment_method_title. I cannot refund the order. When trying to programmatically refund the order, it fails saing no payment method found for the order (woocommerce doesnt know which payment method to refund with), and when trying to refund it from woocommerce dashboard, no Refund via Revolut button is displayed, as the revolut documentation says that should happen for wc: https://developer.revolut.com/docs/guides/accept-payments/plugins/woocommerce/features Probably due to the same reason. So this needs to be fixed ASAP.

Should I go on and delete all the default same ones? Also what about the processed internal links key? Can it be avoided?

This must come in the newest update since woocommerce is soon to be using hpos on its core so your plugin will be incompatible on the newest woocommerce updates. And as i have searched on the revolut plugin code, its only 3-3 lines that need change, from accessing order with wordpress default functions, to woocommerce crud.