Rob de Cleen

Hi,, thanks for getting back to me. Yes, the specification in the plugin of the thousand and decimal separator works fine, as does the translation of the descriptions in the backend. But for translations to have a different specification of those keys (, instead of . and . instead of ,) those two keys need to be translateable as well (to show on the frontend), which they are not now. So they are now fixed across languages as specified in the backend.

Hi guys,

Thanks for the wpml-config.xml file included in the plugin. I am faced with a small issue, hope you can help me solve it.

UK and US use comma (,) as a thousands separator, most European countries use period (.)
UK and US use period (.) as a decimal separator, most European countries use comma (,)

So I need a way to translate these as well, but the two entries in your wpml-config.xml file are commented:

<!-- <key name="price_decimals_num" /> -->
<!-- <key name="price_decimal_sep" /> -->

Same goes for Total and Quantity in the front end display. Anyway you can help make these translatable? Thanks in advance

Excellent, thanks for your hard work!

Thank you very much!

Two links with explanation:

WPML: https://wpml.org/documentation/support/language-configuration-files/

Polylang: https://polylang.pro/doc/the-wpml-config-xml-file/

Perhaps Stéphane can provide some extra info for Falang

For translating the button Stéphane Bouey (Falang multilanguage for WordPress) gave me this, works fine. Add file wpml-config.xml to the plugin dir:

<wpml-config>
  <admin-texts>
    <key name="ppdg-settings">
      <key name="button_text"/>
    </key>
  </admin-texts>
</wpml-config>

Hi mra13,

I appreciate the time you took for the answer, but I have to say I am also a bit surpised by it. Like I mentioned in my last message about this issue, I took your answer about missing price being the reason quite seriously and ran an extensive test with 9 options and with price added: it made no difference, the behavior of the dropdown options is not what it should be: they still do not show all of them.

I will check WP Express Checkout as well, but the issue reported by me is something you should check in _this_ plugin.

Please try it out yourself and see how the dropdown only shows option 8, 4 and 9 (in that strange order!)

[wp_paypal_payment_box email="[email protected]" options="Tour 1:€35|Tour2:€35|Tour3:€35|Tour 4:€45|Tour 5:€35|Tour 6:€35|Tour 7:€35|Tour 8:€35|Tour 9:€25,50" currency="EUR" other_amount_label="Below please enter the total for number of participants or as agreed. Amount:" other_amount=true country_code="US" reference="Email Address" reference_placeholder="Your email address"]

When restricting the options to only 6 (to exclude 9 options being the reason) it only show options 6 and 4 in the dropdown.

So no, the behavior does NOT come from missing price info. There seems to be something wrong here with the internal logic. Thanks for your time and efforts!

• This reply was modified 8 months ago by Rob de Cleen. Reason: added additonal info

Just to clarify after test with 5.0.1:

Adding price does nothing to fix my original issue. I have 9 options, but with the new version 5.0.1 and the new API only the last 3 dropdown options are visible, the preceding 6 options from the dropdown don’t show…

Hi mra13,

No it’s not a malformed shortcode, the price was in this case omitted on purpose (as it’s a variable amount, depending on other choices). That’s why the “other” amount exists in that shortcode. This was a solution to not have to run a full ecommerce suite.

Regardless, this shortcode functioned perfectly and without any errors in v 4.9, so let me rephrase the question then:

why does v. 5 and new PP API restrict the dropdown options? And can it be fixed to work like 4.9?

• This reply was modified 8 months ago by Rob de Cleen.

Hi, thanks for getting back to me so soon:

Here is the shortcode:

[wp_paypal_payment_box email="[email protected]" options="Jordaan & Western Islands Tour with MforAmsterdam: |Plantage & Jewish Quarter Tour with MforAmsterdam:|Rijksmuseum Tour with MforAmsterdam:|Grachtengordel Tour with MforAmsterdam:|Finance & Trade Tour with MforAmsterdam:|Nieuwmarkt & Old City Center Tour with MforAmsterdam:|Custom Private Tour with MforAmsterdam:|Corporate Outing with MforAmsterdam:|Rijksmuseum Ticket Booking by MforAmsterdam:" currency="EUR" other_amount_label="Amount" other_amount=true country_code="US" reference="Email Address" reference_placeholder="Your email address"]

All is fine with v 4.9, even with 5.0 initially, but after changing to the new API the dropdowns stop functioning as before.

link to the dropdown page (v4.9):

https://mforamsterdam.com/info/payment-info/

Thanks for your time and help!

Hi,

Thank you for your efforts and for the quick fix! This WPBC 9.8.3 works perfect for me on all screen sizes with my theme.

I used this shortcode now:

[booking type=1 nummonths=2 form_type='standard' width='100%']

Everything works fine in all screen sizes now, for me even without the need for any additional CSS.

Thanks again for your work and enjoy the rest of the weekend!

OK, that was quick, good news! Thanks you for allt he hard work on this great plugin! Have a good evening!

Just to clarify: I am using Enfold theme. Everything worked well on every size screen as it should with WPBC 9.7.7.1, but not with 9.8.2.

Thanks for your quick response. Sorry, I tried, but that code above still does not yield what 9.7.7.1 did ??

at 450px: 2 months horizontal (1 column in theme) (should yield vertical)
at 767px: months vertical (calendar is in middle of 3 columns with theme)
at 847px and bigger: 2 months horizontal (calendar is in middle of 3 columns with theme)

By the way, theme breakpoints are 360, 450, 768, 850, 989, 1024

I also tried:
@media only screen and (min-width: 360px) and (max-width: 989px) {

same result, not working

I think changing the breakpoint doesn’t do much good here, as some wider screens have 3 columns instead of 1. I will do some testing maybe with width maxcontent instead of 100%. I will let you know if I find a solution.

Thanks for your time and effort, no hurry

Thanks for the response, but the cache had already been cleared several times… I just did it again now, and there is NO difference. The page which has the booking calendar is excluded from the cache, always on that website.

Fact is that the behavior with 9.8.2 styling is different from the 9.7.7.1 version.

You can check this yourself like I did, by rolling back the plugin and then changing the width of the screen, you will see that it behaves different with 9.8.2 at varous screen widths (so not only on the smallest screen size).

Thanks for the temp fix, I will try it on a dev website, for the live version I will wait for the next version’s fix.

Have a good day,

Rob