Kim

Webp images are generated when not defining EWWW_DISABLE_ASYNC, so I don’t think that is the issue. The reason for disabling async is that this is for a import script that is already running async, and we are seeing webp images “randomly” not being offloaded to our cdn solution. Running the conversion and offloading synchronously is an attempt to prevent this issue.

Thank you for those pointers. I was able to get this working. Had to also regenerate the order key, and used “i” insetead of “:” as the suffix number separator for the vipps order id to get it working. Also some special handling to prevent woo-vipps from canceling these orders. It should also hopefully detect when woo-vipps has built in handling of this. I’ll send you the solution if you have any interest in it.

Thank you for a quick reply. I see, so for this to work now we would have to change the order number each time a customer tries to pay for the order? Or is there another workaround you can think of that we could implement ourselves, for example with the woo_vipps_orderid filter?

• This reply was modified 10 months ago by Kim.
• This reply was modified 10 months ago by Kim.
• This reply was modified 10 months ago by Kim.

This was on a multisite hosted on Kinsta.

I have been able to reproduce this issue.

1 tab open on a product, created an account in another tab, then pressed the “Buy now with Vipps” button on the product in the first tab.

Hi, I’m working on the same project. The issue seems to be that $xml_product is never declared as a array. Declaring it $xml_product = array(); solves the issue.

Another potential issue is the ?> at the end of the file, which could result in unwanted whitespace output.

• This reply was modified 7 years, 5 months ago by Kim.

I guess there might be caching plugin specific workarounds or solutions, but not a reliable way in WordPress core that can solve this.

Ah now I see. global $wp_object_cache is the class W3_ObjectCacheBridge and not the WordPress class WP_Object_Cache.

Hm it should not work and I don’t understand why it does on my local installation. The blog_prefix is not changed by the code so it is only a strange coincidence that it worked it seems.

The code was tested on a local single install, and not on a multisite network. It seemed to work for the few minutes I tested it. It showed the correct language content in the widgets, and it used cached data in every language the second time the pages was loaded. I’m just afraid there are some negative consequences of doing this. I expect wp_cache_switch_to_blog() is intended to be used with multisite networks, but on the other hand it is also the function taking over from the deprecated wp_cache_reset().

I believe this page might give you information you are after. theme-internationalization-i18n-and-localization-l10n

Thank you!

Thank you this should allow me to achieve what I am trying to do.

Still wondering about

if ($selected == $lang->slug)
continue;

in admin.php line 216. From my understanding this is supposed to hide the current language from the drop down menu, but it does not currently do so, unless I change it to

if ( $selected->slug == $lang->slug )
continue;

or is this for something different?

If I add a translation for a term, by filling out the translation form and then click the “Add New TaxonomyName” button the translation is added, but I am not redirected away from the screen where I added the original translation, so the next term I add will also be added as a translation to the same term (if I don’t manually leave that screen/form).

Thank you this pointend me in the right direction. I’m trying to make a plugin that changes the behavior to what I want, but there is one major problem. Polylang does not use get_edit_term_link(), get_edit_post_link() and so on, so there is no way to add language information to edit links without editing the plugin itself. Is there a specific reason those functions are not used? One example is in view-translations-post.php. Changing the line
esc_url(admin_url('post.php?action=edit&post=' . $value)),
to
get_edit_post_link( $value ),
should allow me to add ‘lang’ query arg to the edit post link url to make the menu change to the posts language when editing the post.

There is also a bug with the edit term links when working with a custom post type. The edit term links to other translations in single term view does not have post type information, so you end up in the wrong location in the menu.

Also I wondered if
if ($selected == $lang->slug)
should be
if ( $selected->slug == $lang->slug )
in admin/admin.php?