Login
Register

VirtueMart

WooCommerce

Others

Docs

Support

Blog

About

Shipping By Rules for WooCommerce

Open ToolsOpenTools LogoText 100px 

IMPORTANT ANNOUNCEMENT: Plugin development ceased, all plugins made available freely (GPL)

With great sadness we have to announce that we are ceasing development of all our VirtueMart, WooCommerce and Joomla plugins. Effective immediately, all our plugins -- even those that were paid downloads -- are made available for free from our homepage (GPL license still applies), but we cannot and will not provide any support anymore.

It has been a great pleasure to be part of the thriving development communities of VirtueMart as well as WooCommerce. However, during the last year it became painstakingly clear that in addition to a full-time job, a young family and several other time-consuming hobbies at professional level (like being a professional singer) the plugin development and the support that it requires is not sustainable and is taking its toll. It has been an honor, but it is now time to say good bye!

×

Notice

The forum is in read only mode.
Welcome, Guest
Username: Password: Remember me
Forgot your password? Forgot your username?
  • Page:
  • 1

TOPIC:

Rule evaluate_for_categories for non English words 22 May 2017 17:04 #1

  • natalia
  • natalia's Avatar Topic Author
I have created some rules for my categories and their working fine
the rule 1. evaluate_for_categories(Articles, "spirits")>2; NoShipping
has 3 more languages. at English and German is ok,
but at Greek and Russian where the slug of the word spirits is
with other characters, we have problem.
GR= evaluate_for_categories(Articles, "οινοπνευματώδη")>2; NoShipping
RU = evaluate_for_categories(Articles, "алкогольные-напитки")>2; NoShipping

can you suggest other solution from changing the slug of these 2 categories to "spirits" ?

Rule evaluate_for_categories for non English words 26 May 2017 01:50 #2

Dear Natalia,
Thank you for noticing this issue. Non-latin characters in SLUGs indeed causes problems, as WordPress stores all SLUGs as URL-encoded, while our plugin does a verbatim comparison. To make things work, we'll have to URL-decode all SLUGs first...

We'll include the fix in our upcoming version 2.0 of the plugin (which also marks the switch to WooCommerce's shipping zones). The release should happen in the next few days/week. The release candidate is almost ready...

Best regards,
Reinhold
  • Page:
  • 1