Phone encode issue in ACF wysiwyg editor
-
Hi,
I have just come across another issue. I have just tested three ACF field types. Text, text area and wysiwyg editor. I found that the phone encode is not working correctly in the wysiwyg editor, it just displays some javascript code. Is this something that can be looked at?
I am also keen to find out if you plan to add a checkbox in the settings to enable the encode style to all phone numbers across the website, exactly like how it works for email? It would also be cool to have a non javascript method as a choice too. I prefer using no javascript methods, just incase the visitor has javascript disabled.
I look forward to your response.
-
Hey @sharpenedpixels – Thanks as well for your second message. ??
Can you please let me know how you protected the phone number? Did you use the shortcode for it and if so with which settings?I definitely have it on the plan of allowing phone number encoding by default. If everything works out as expected, we are going to launch that feature with our next version.
If you have any further questions, feel free to let me know at any time.
Hi @ironikus – I just used the shortcode from the plugin page instructions in the description, but guessed it needed a closing tag too, like this:
[eeb_protect_content]<a href="tel:+441234567890">01234 567 890</a>[/eeb_protect_content]
This worked fine on all the above mentioned but not in the wysiwyg editor via ACF, not sure if any other ACF fields would have any issues, as I only tested text, text area and wysiwyg editor, as these would likely be the ones I would use. I have also, prior to messaging, tested the menu and widget areas too, but it seems to ignore the encode altogether in the menu area. The widget area seems to work.
It would be great if it is included as part of the settings, so that all plain phone numbers are encoded and if you could include changing plain text versions to be clickable with tel:, the same as the email setting to add mailto links in the advanced settings. I look forward to that update. I’m guessing this would also encode phone numbers in the menu.
Let me know if you see any issues with the shortcode and code I have used, but as I say it works fine in most scenarios, just not ACF wysiwyg editor or the menu currently.
See this page as an example:
https://plugintest.sharpenedpixels.co.uk/test-page-with-divi/- This reply was modified 4 years, 3 months ago by sharpenedpixels.
Another great option for the settings, if you were to include adding support for converting plain phone numbers to tel links. You may need to add some way of users being able to set the country code, like Uk is +44. Maybe just a field that the user can add the country code into, then this would replace the first digit of the phone number in the link only. Not sure how easy that would be. I know that our UK numbers start with 0 and the international code is +44 which replaces the zero. Not sure if other countries use the same replacement, as in, only the first number. If that is the case then I think this may be quite straight forward to include, but if their first two numbers are replaced or something different then it might be difficult to include. What do you think?
- This reply was modified 4 years, 3 months ago by sharpenedpixels.
Hey @sharpenedpixels – Thank you for all of your details.
I just checked on that and the issue with the WYSIWYG editor is that is strips away script tags. That means, that scripts are not allowed within it, which can be solved by changing the encoding method to a non-javascript one.
To make that work, please adjust your shortcode with the method parameter as followed:[eeb_protect_content method=”encode”]01234 567 890[/eeb_protect_content]
This will cause the email to be encoded using the entity encoding method.
In regards to the automatic phone number protection and the tel link converting: I added that on our feature list and will consider it for our next upcoming updates. ??
In regards to the country code Adjustments: Not sure if that makes full sense at the current point, but I will definitely add it down on possible future features.
If you have any additional questions, please let me know.
Hi @ironikus
Ok great, thanks for letting me know. Only thing that still isn’t working after implementing your fix, is that it isn’t applying making the number a link like in the other ACF fields. It seems to be ignoring the html code and displaying the whole code on the website, see the page again for the example of what I mean: https://plugintest.sharpenedpixels.co.uk/test-page-with-divi/
And just regarding the country code, I feel it will be valuable to most people, as websites are global and can be accessed from any part of the World. If someone from another country were to try and click on the phone number to call, I don’t think it will work. This was the reason I suggested adding some way of the users being able to add their country code in the settings somewhere, so this could replace the beginning part of the phone number in the link only. I imagine this would help decrease bounce rate too, as I expect visitors would leave a website if a clickable phone number didn’t work as expected.
Hey @sharpenedpixels – Thank you for the feedback. It’s strange that the HTML is not completely encoded. There must be something in regards with the encoding that is used.
Can you please give it a try by excluding the phone number as followed?<a href="tel:[eeb_protect_content]+441234567890[/eeb_protect_content]">[eeb_protect_content]01234 567 890[/eeb_protect_content]</a>
If that works, it must be the HTML that is causing the issue.
In regards to the country code: I will add it to our list to check further on it. ??
- This reply was modified 4 years, 2 months ago by Ironikus.
Hi @ironikus
Thanks for your response. I really appreciate you taking the time to try and help sort out the issue.
I have just tested the code provided, but it caused the javascript to display again. I changed it to this to fix it:
<a href="tel:[eeb_protect_content method="encode"]+441234567890[/eeb_protect_content]">[eeb_protect_content method="encode"]01234 567 890[/eeb_protect_content]</a>
This sorted the issue where the html was being displayed on the page, however, it seems to strip out the tel link altogether in the source code. So, in the source code it now outputs like this:
<a>01234 567 890</a>
I also tried:
<a href="tel:[eeb_protect_content]+441234567890[/eeb_protect_content]">[eeb_protect_content method="encode"]01234 567 890[/eeb_protect_content]</a>
But this caused the link to output with the javascript that was displaying before.
Seems like it may need a bit of tweaking in the original plugin code to get it working correctly.
I appreciate you taking the time to respond to all my queries and that you are willing to include some of my suggestions in a future release.
I don’t suppose you have a roadmap of what is being worked on and what is on the list of suggested updates for future releases? I’m very keen to include the plugin in all my website projects, but need to make sure it is working as expected. I appreciate it is a free plugin, and development of the plugin may not be a priority right now, but if you could give me some sort of timescale of when you might include the tel links being automatically added to plain phone numbers like the email links, I’d be very grateful.
HEy @sharpenedpixels – Thanks for the details.
I know made some tests in regards to this topic and I believe the issue is within the way you are calling/outputting the value to the frontend.
I set up a custom Wyswig field using ACF and created a shortcode that simply takes the content from the meta key and returns it to the frontend.
Here are the results after my tests to both of the code examples you provided from your last reply:
<a href="tel:[eeb_protect_content method="encode"]+441234567890[/eeb_protect_content]">[eeb_protect_content method="encode"]01234 567 890[/eeb_protect_content]</a>
This one throws an issue because the shortcode tag could not be validated as such sine we use double quotes around the shortcode, which breaks the wrapping. Correct would be:
<a href="tel:[eeb_protect_content method='encode']+441234567890[/eeb_protect_content]">[eeb_protect_content method="encode"]01234 567 890[/eeb_protect_content]</a>
The second code example worked just fine and returned me a fully working converted link of the phone number:
<a href="tel:[eeb_protect_content]+441234567890[/eeb_protect_content]">[eeb_protect_content method="encode"]01234 567 890[/eeb_protect_content]</a>
I assume you might do some text sanitation before you display the content, which is probably what breaks the code since some functions invalidate script tags, which is exactly what our plugin uses for the most secure protection. To avoid that, either change the sanitation function or change the encoding method within the shortcode.
If you have any further questions, please let me know.
Hi @ironikus,
Thanks for looking at this. I have now run some further tests my end and have got the phone number encoding in the areas I previously tested, including the ACF wsywyg editor, using:
<a href="tel:[eeb_protect_content method='encode']+441234567890[/eeb_protect_content]">[eeb_protect_content method="encode"]01234 567 890[/eeb_protect_content]</a>
Thanks for your help.
P.S. Are you still planning to implement a way to auto encode phone numbers too? I really hope you are, and also the ability to convert plain phone numbers to links. That would be awesome if these could be added at some point soon.
Hey @sharpenedpixels – Thanks for the feedback, glad to read it worked.
In regards to the phone number encoding: We are working on a separate plugin for that but due to the complexity of validating phone numbers, it won’t be ready soon I guess.
The issue is that there’s so much different formats we have to take care of and even some spellings differences, so validating it at the current point causes the site to break at different levels.
We currently train an AI to decide whether it’s a phone number or not. If it is the right approach or not, is something, I hopefully can tell in the next weeks since it will definitely require us to make some further tests.If you are interested in beta-testing our product once we have a stable version, I’m happy to send you an invitation
Yeah, you are right, there would be several variations of phone number formats, which might make it hard to cover every single one. It just would be awesome if this was possible.
Of course, happy to help out with beta testing. Just let me know when you have something ready to test.
- The topic ‘Phone encode issue in ACF wysiwyg editor’ is closed to new replies.