Disabling the International Telephone Input Extension?

  • Resolved baboehm

    (@baboehm)


    1 year ago

    Hi there,

    I just noticed that you seem to have added some functionality to the phone field of the booking form.
    Even though it says in your changelog that it needs to be activated via wp-config, it appears on all my clients’ sites that use the free version.

    Not only does it look bad in most layouts, it also defaults to the US area code, which is not where 99.99% of customers will come from.

    Also it bloats up the CSS files by a ton.

    I tried deactivating this by reversing what the changelog said, i.e. adding

    define(‘EM_PHONE_INTL_ENABLED’, false);

    to wp-config, but that didn’t change anything.

    How do I get rid of this?

    It honestly is getting pretty tiresome to clean up after the layout changes you guys keep implementing. Think it would be possible to add further layout changes to an extension or something?

    Thanks and best wishes,

    Bastian

    The page I need help with: [log in to see the link]

Viewing 6 replies - 1 through 6 (of 6 total)
  • jrostinmagnin

    (@jrostinmagnin)

    I have the same issue with the following web page:

    https://eclats-lavaur.com/events/lhistoire-dun-escargot-2/

    I hope this problem can be resolved quickly. All the best. Jean-Claude

    Plugin Author Marcus

    (@msykes)

    Hello, thanks for the report and sorry for the inconvenience, there’s a JS bug that showed the telephone field instead of ignoring it. The intention is to provide more options on display (and addressing any display issues) before letting that go live.

    Things like country selection, auto-detecting country where possible will be in there before we release it. Also, by default it’ll be turned off for updates, on for new sites.

    We’ve just release 6.4.6.3 which should now honor the constant value if set or not show the phone field UI if not defined at all.

    jrostinmagnin

    (@jrostinmagnin)

    Problem resolved with 6.4.6.3 – Many Thanks for this support.

    Thread Starter baboehm

    (@baboehm)

    Thanks for the fix, version 6.4.6.3 indeed removes the field in the frontend.

    I’d still be happier if it didn’t add 1000+ lines of code to the CSS for something I don’t need, but well…

    To be clear, the 1000+ refers to the part of the “events-manager.min.css”-file that includes all the CSS for this picker, if de-minified, so I am aware that it is not 1500 actual lines being added, but it’s still a lot of code.

    All that said, thanks for the quick fix!

    Plugin Author Marcus

    (@msykes)

    Hello, that’s something I’d happily debate and am open to opinions;

    The code adds 21kb unminified to the CSS file.

    That is an extra 21Kb you may not need, but we need to consider all users and I’m not sure it’s worth splitting into yet another CSS your site would have to load (when I say ‘your’ I mean general anyone using EM).

    In the past, I’d totally agree with you, these days between CDNs, browser caching, internet speeds and device capabilities I think the 21kB is a good trade-off for the first page load.

    Thread Starter baboehm

    (@baboehm)

    Hi, thanks for opening the discussion ??

    While I do agree that 21kb is not that much, things do add up quickly. To quote my late grandfather:

    “What if everybody did this?”

    my grandfather

    Also in this case, 21kb is basically as much as most of the other CSS scripts being loaded on the site (the events-manager CSS is excluded by autoptimize):

    Doubling the CSS for something I don’t need is kinda weird. (I know I’m comparing minified vs unminified here but I think you get my point).

    I try to build my sites with as little overhead as possible so I don’t need to set up CDN and other shenanigans, as they usually aren’t free and/or prone to cause problems somewhere down the road.

    I guess the problem is where I’m coming from, the reason why I took a liking to your plugin and employed it on around 20 sites already, which used to be its high flexibility regarding the layout and its low overhead.

    While I do understand you’re trying to make the plugin more accessible to users with less affinity to code, you’re of course also adding to that overhead in the process.

    I believe it is going to be very hard to keep everyone satisfied here, and you’re running the risk of landing “between the chairs” – too complex for the average user and too much overhead for the advanced.

    So in my ideal world you’d keep the basic functionality (basically version 5.x) in a basic plugin and would add all the fancy layout stuff via an extension or something.

    In any case, I’ll be here for the ride.

    • This reply was modified 1 year ago by baboehm.
Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘Disabling the International Telephone Input Extension?’ is closed to new replies.