aris00

OK. Can’t find it in the code. Will use something else.

Thanks.

That solved it.

For Shopkeeper (or child) theme:

Appearance > Customize

then in “Product Page” disable the option “AJAX Add to Cart”

Thanks!

• This reply was modified 3 years, 9 months ago by aris00.

OK. Will look at it and post back. Thanks.

Additional info regarding CPO products:

If I log into WP, then log out, the first time I hit “Add to Cart” one time is added, ie. the correct behaviour. After the first time, each time I hit “Add to Cart”, two items are added.

So, for me, the first time I add to cart after logging out, is the only time I get correct behaviour.

Alright then.

Can be used with some milti-lingual plugins but not with WPML.
According to you, Loco/Polylang are two of the plugins it works with.

Clarifying for other users because I have had a hard time finding enough info out there.

I have put so much time in this now, and my conclusion that your plugin is not multilingual. I really really hope that you can show me that what I am doing is wrong.

Initially I tried translating the CPO options with WPML but they were breaking the formula so I set them to “Do not make ‘CPO option’ translatable”. The translations I provided did not seem to be used anywhere anyway.

The following is what I do now.

Say I have product in English (EN) with a CPO form with a few fields. I have set up a formula and everything is working fine.

Then I use WPML to add a French (FR) translation of the product. In the multilingual setup for the product I set all the _cpo fields to Translate and Apply. I edit the FR translation and make sure to copy all the _cpo field values from EN to FR. I check that in the front end the FR product is showing a correctly working English form.

I go back to the products list, switch the admin to French, then use the “CPO Builder” link directly from the french product listing to only edit the CPO form.

The field IDs on the FR form are synced to the option IDs from the EN page. Great. I type module label texts, and save but with the “Save to DB?” unticked so I do not overwrite the other data for the module options in the DB.

Now I go to the product front end in French. The labels are in French. I select the various options. The calculation is fine. I add to cart. I go to the cart page. All the options are displayed in English. That’s how they will appear in the customer order. Not good.

Now, I go to the French version of the product and edit the CPO form. This time, I tick the “Save to DB?” for my modules. I go back to the front end. I switch to English. I add the product to the cart. I go to the cart page. The options are now displayed in French. Not good.

So, the options for the product in the cart are displayed using the labels the options had when the modules were saved with the “Save to DB?” option ticked. On top of that, the module editor will flick the “Save to DB?” option on automatically when you are change any of the fields with a yellow triangle. The user may not even realise or really understand what the subtle difference is.

The only way to deal with this is to have different field names for the form of each language so the options in the DB have the strings for each language. However, when you switch language, the cart will still display the product options strings in whatever language you were on when you added it to the cart. Plus you need to readjust the formula to use the language specific field names. Not good.

The setup is too inflexible and fragile in my opinion and you guys need to rethink it. Getting rid of the “Save to DB” concept and utilising the “CPO options” type translations from WPML would be a great start. “Save to DB” is just too much of an internal feature to present to the user in my opinion.

I think that when you “recommend using string translation functionality and translate existing forms this way” is misleading. You should just tell people that your plugin is not ready for multilingual sites or have a document detailing the compromises you need to make in a multilingual setup.

I am really looking forward to your version 5 and I hope that you will take my feedback as constructive. If I am wrong about all of the above I am open to your suggested way of doing things.

• This reply was modified 4 years, 8 months ago by aris00.

I have finally worked out how to translate your forms (not a method that directly involves the WPML facilities) and relies on not selecting the ever so subtle save to DB option.

It took me a couple of days to fully get how your plugin works. I don’t think it should be this hard to get my head around it. Maybe your priority for V5 should be to re-architect this because the save to DB subtlety can so easily be lost on you customers.

Unfortunately, it would would require a fairly lengthy tutorial to communicate all of that information to the general public.

Final progress.

I noticed that when I copied the system fields from the base language to another, the form styles degenerated and the price stopped updating. Something must be confusing the styles.

The only way that I could get a band-aid reliable result was by removing all the system fields values from the target language and making a new form from scratch with new field names and option values.

This is not actually a sustainable solution because as soon as you have a complex formula with logic, it becomes error prone to maintain. It is even difficult if you have a few dozen products with just a length field because the number of forms you now have to maintain is products * languages. Gets overwhelming quickly.

You really have to make a tutorial with a better method for dealing with languages because this is starting to look like *not multilingual*.

• This reply was modified 4 years, 8 months ago by aris00.

You can get started here:

https://wpml.org/documentation/theme-compatibility/go-global-program/#how-do-i-get-started

Alright. I will spend a bit more time on this today and report when I have some progress.

I am concerned because our site (small textile workshop) will be selling yardage goods and we need a calculator in quite a few products. Plus we have some custom products with yardage, colours and additional options all affecting the final cost. Being in Europe, we will end up with at least six languages by the end of the year.

I think, however, you should contact the WPML guys and see what their “Go Global” program is. When I was talking about your plugin to their support, the support person said that in this program they help you make your plugin more translation friendly. Maybe it is worth it for you to chat with them, I hope you do!

Cheers.

I went to WPML’s “String Translation” and none of your strings were there.

I then went to the “CPO Options” panel. In the “Multilingual Content Setup” I set the “Make ‘CPO option’ translatable” option and set the system fields _cpo_general and _cpo_suboptions to “Translate”, the rest to “Copy”. I provided translations for all the label and tooltip strings and copied the rest (eg. the slug names, booleans etc).

The form was still not showing.

I went into the product. In the “Multilingual Content Setup” I made all the _cpo system fields to “Translate”. There were no fields that needed translating so I copied all the fields including “Cpo content”, “Cpo enable”, “Cpo calc enable”, “Cpo formula rules enable” and “Cpo main formula”.

The form now appears in the translated product page but everything on it is in the base language EXCEPT from some common options like “None” and “Cut”.

So far after all these hours I am still not seeing any of the translations I have provided in CPO Options.

Have you tested your plugin with WPML and can you please provide some more detailed guidance?

Is your plugin really only built for English?

That would be a pity because it is quite a capable plugin.

I am just sitting here giggling ?? but does this mean that POPPFWC work fine with WC4?

No problem about the delay, thanks for replying.

I had a look at the documentation and all I saw was the mention of the feature “Cart item duplication and cart item edit features” in:
https://moomoo-agency.gitbooks.io/uni-cpo-4-documentation/why-uni-cpo.html

Is that what you mean or is there additional information in the docs that I missed?

Thanks.

Good morning!

Sorry but I don’t have a link, I am still learning the plugin for our site offline. By “cart” I mean “basket”.

Here is how I go to the product from the basket page:

1. I click on my product from the shop page
2. I pick the various options I have setup with the builder for my product
The price updates correctly according to the formula I have setup
The CSS selector works fine
3. I click Add to Basket to add my product to the basket
4. I go to the basket page (view basket link)
The item I added in step 3 is listed here
and displays the correct option values I set in step 2
5. I click on the item link
6. I am now in the product page for my product

Should the options in the product page be initialized with option values from the basket page item I just clicked on in step 5?

With Woocommerce, the attribute values of a variable product are added to the item link in basket page, for example:
/product/myproduct?attribute_pa_colour=blue
so when I click on the “my product” listing from the basket page, the colour attribute select is initialized to “blue” from the basket item as the product page is loaded.

Can the Uni CPO plugin do that too?

Thanks!

PS. I hope my description was OK otherwise let me know and I will try to work out how to put a video up somewhere.

• This reply was modified 4 years, 12 months ago by aris00. Reason: formating

Damn! That would have been an awesome free feature! ??