Why Add a Phone Number Field to Your Contact Form?
A phone number field in your contact form offers several advantages:
Improve Communication: Allowing visitors to submit their phone numbers helps you reach out to potential leads quickly and personally.
Better Lead Conversion: Collecting phone numbers enables faster follow-ups, improving your chances of converting visitors into customers.
Enhance Customer Support: If you offer customer support, having a phone number in the form can help resolve issues faster by allowing you to call the customer directly.
Step 1: Add a Basic Phone Number Field in Contact Form 7
Adding a phone number field to your form is simple. Here’s how to do it:
Step 1.1: Open Your Contact Form in Contact Form 7
From your WordPress dashboard, go to Contact > Contact Forms.
Select the form you want to edit, or create a new form by clicking Add New.
Step 1.2: Add the Phone Number Field
In the form editor, place the following code where you want the phone number field to appear:
[tel* phone]: This shortcode creates a required phone number field. The * makes the field mandatory, meaning the user must fill it out before submitting the form.
id:phone: This gives the phone number field a unique ID, which can be useful for styling and other purposes.
label for="phone": This ensures that the label is associated with the phone number field for better accessibility.
Step 1.3: Save the Form
Once you’ve added the phone number field, click Save to store the changes.
Step 2: Customize the Phone Number Field
If you want to customize the phone number field further, there are several options you can use to improve the user experience and the validation process.
Step 2.1: Add Placeholder Text
To make it clear to users what format the phone number should be in, you can add placeholder text in the input field.
This regex allows for phone numbers that may optionally start with a “+” (international code) and ensures that the number entered is between 7 to 10 digits long.
Step 2.3: Use JavaScript to Mask the Phone Number
For a more user-friendly approach, you can use a JavaScript library like Inputmask to create a mask for phone number entry. This can help format the number as the user types it, making it easier to collect consistent data.
document.getElementById('phone').inputmask('(999) 999-9999'); // Example mask
This script will display the phone number in the format (123) 456-7890 as the user types it.
Step 3: Add Validation for the Phone Number Field
To ensure the phone number is entered correctly, it’s important to validate the input. Contact Form 7 provides built-in validation for the required fields, but you can add custom validation to check for a valid phone number.
Step 3.1: Use JavaScript for Phone Number Validation
If you want more advanced validation (for example, to ensure the phone number contains only numbers or follows a specific format), you can use JavaScript to check the value before submitting the form.
document.addEventListener('wpcf7submit', function(event) {
var phoneNumber = document.getElementById('phone').value;
var phoneRegex = /^[\+]?[0-9]{1,4}?[0-9]{7,10}$/;
if (!phoneRegex.test(phoneNumber)) {
alert('Please enter a valid phone number.');
event.preventDefault(); // Prevent form submission
}
}, false);
This script listens for the form submission event and checks the phone number against the specified regex pattern. If the phone number doesn’t match, the form submission is prevented, and an error message is shown.
Step 4: Style the Phone Number Field
You can style the phone number field to match the design of your site using custom CSS. Here’s an example of styling the phone number input field:
2. How do I add country codes to the phone number field?
To allow users to enter their country code, you can add a dropdown field with country codes and then combine it with the phone number field. Here’s an example:
You can then use JavaScript to combine the selected country code with the phone number value.
3. Can I use a phone number field in multiple forms?
Yes! The phone number field can be used in any form created with Contact Form 7. Simply add the same [tel* phone] shortcode to other forms where you need to collect phone numbers.
4. How can I validate international phone numbers?
For international phone number validation, you can use a more advanced regex pattern that allows for varying phone number formats based on the country. You can also use third-party libraries like libphonenumber to validate and format international numbers.
5. Can I use a phone number field in the Contact Form 7 email?
Yes! You can include the phone number field in the email body by using the corresponding form tag, for example:
Phone Number: [phone]
Adding a phone number field to your Contact Form 7 form is a simple but powerful way to collect contact information from your website visitors. Whether you’re collecting phone numbers for customer support, sales, or general inquiries, the customization options available in Contact Form 7 ensure you can tailor the phone number field to fit your needs.
From basic phone fields to advanced validation and styling, you now have all the tools you need to create effective phone number fields in Contact Form 7.
Need Help with Customizing Contact Form 7?
Hire a certified WordPress expert from Codeable to help you customize your Contact Form 7 fields and enhance your form functionality.
Contact Form 7 is a powerful WordPress plugin that makes it easy to add forms to your website. However, sometimes you may want to automate the process of storing form submissions in a Google Sheets document for easier management, collaboration, and analysis. In this tutorial, we’ll dive deep into how to connect Contact Form 7 to Google Sheets using the CF7 Google Sheets Connector plugin.
Why Use Google Sheets with Contact Form 7?
Storing form submissions in Google Sheets provides a lot of benefits:
Easy Data Access: You can view and organize your form submissions in a Google Sheet anytime, from anywhere.
Collaboration: Share the Google Sheet with your team for instant collaboration and tracking.
Automation: Google Sheets offers various features and integrations that can automate tasks, like notifications or data analysis.
Step 1: Set Up Google Sheets API
Before you can connect Contact Form 7 to Google Sheets, you need to configure the Google Sheets API. Follow these steps:
In the top left, click on the Select a Project dropdown and then click New Project.
Name your project (e.g., “Contact Form 7 Integration”).
Click Create to create your new project.
1.2 Enable Google Sheets API
In the Google Cloud Console, go to APIs & Services > Library.
Search for “Google Sheets API” and click on it.
Click Enable to activate the API for your project.
1.3 Enable Google Drive API
Since you’ll be interacting with Google Sheets through a spreadsheet stored in Google Drive, you also need to enable the Google Drive API:
In the same Library section, search for “Google Drive API”.
Click Enable to activate the Drive API for your project.
1.4 Create OAuth Credentials
To authenticate the connection between WordPress and Google Sheets, you’ll need to create OAuth credentials:
Go to APIs & Services > Credentials.
Click Create Credentials, then select OAuth 2.0 Client IDs.
If prompted, set up the OAuth consent screen. Fill in the required fields such as the Application name and Support email.
Under Scopes, select the appropriate scopes for your integration (Google Sheets and Google Drive).
In the Create OAuth client ID section, choose Web application as the application type.
For Authorized redirect URIs, enter the redirect URI provided by the CF7 Google Sheets Connector plugin (this will be shown during setup).
Click Create and download the credentials.json file. Keep this file safe, as it contains sensitive information.
Step 2: Install and Configure the CF7 Google Sheets Connector Plugin
Go to Plugins > Add New in your WordPress admin panel.
Search for “CF7 Google Sheets Connector”.
Click Install Now and then Activate.
Once activated, the plugin will add a new settings section where you can configure the integration with Google Sheets.
Step 3: Authenticate the Plugin with Google
Now, you need to authenticate the plugin using the credentials.json file you downloaded earlier:
Go to Contact Form 7 > Google Sheets Connector settings in your WordPress admin panel.
You will see an option to Authenticate with Google. Click on it.
Upload the credentials.json file you downloaded from the Google Cloud Console.
Follow the on-screen prompts to authorize the plugin to access your Google Sheets and Drive data.
Once authenticated, you’ll be prompted to select the Google Sheet you want to connect to. Choose the spreadsheet where you want to store your form submissions.
Step 4: Map Contact Form 7 Fields to Google Sheets Columns
With the Google Sheet connected, it’s time to map your form fields to the columns in the Google Sheet.
In the plugin settings, you will see a section where you can map each form field to the columns in your Google Sheet.
Match each field in your Contact Form 7 form with the corresponding column in the Google Sheet:
For example:
Name field in your form → Name column in your sheet
Email field in your form → Email column in your sheet
Message field in your form → Message column in your sheet
Save the mappings.
If your form has custom fields, make sure each one corresponds to a column in the Google Sheet. If needed, add more columns to your sheet.
Step 5: Test the Integration
Once everything is set up, it’s time to test whether the integration works:
Go to the page on your site where the Contact Form 7 form is located.
Fill out the form with some test data (e.g., Name, Email, and Message).
Submit the form.
Go to your Google Sheet and check if the form submission appears as a new row.
If the submission doesn’t show up, ensure that:
The API credentials are correct and properly authenticated.
The Google Sheet has the correct permissions to allow data from the plugin.
The form field mappings are accurate.
Troubleshooting
If the integration isn’t working as expected, here are a few things to check:
API Credentials: Ensure that the OAuth credentials are correct and that the API is enabled for both Google Sheets and Google Drive.
Permissions: Verify that your Google Sheet has the right permissions (it should be accessible by the plugin).
Field Mappings: Double-check that each field in the form is mapped to the correct column in the Google Sheet.
Need Help Customizing Your Contact Form 7 Integration?
Hire a certified WordPress expert from Codeable to help you set up or customize your Contact Form 7 to Google Sheets integration.
A stylish footer is more than just a place for links—it’s a chance to leave a lasting impression. If you’re using the Blocksy theme on WordPress and want to create a custom gradient background for your footer, you’re in the right place.
This guide will show you how to add a gradient footer using both Blocksy Customizer and custom CSS. Whether you’re a beginner or a pro, you’ll find multiple ways to create a beautiful footer that stands out.
Why Use a Gradient Background for Your Footer?
A gradient footer can transform the overall design of your website. But it’s not just about looks—it can improve the user experience and branding when done correctly.
Benefits of a Gradient Footer:
Visually Appealing: Gradients make your footer look modern and professional.
Brand Consistency: Using brand colors keeps your design cohesive.
Section Separation: It helps clearly separate content from the footer area.
Highlight Important Links: A well-designed footer can draw attention to CTAs.
Best Practice: Stick with 2-3 colors that blend well together for a subtle and professional look.
Method 1: Adding a Gradient Footer Using the Blocksy Customizer (No Code)
The easiest way to add a gradient footer in Blocksy is through the WordPress Customizer. This method works without needing to touch any code and is ideal for beginners.
Steps to Add a Gradient Footer with the Blocksy Customizer:
Log into Your WordPress Dashboard.
Go to Appearance > Customize > Footer.
Click on the Footer Design section.
Select the footer area you want to edit (Main Footer, Widgets Section, or Footer Bar).
Locate the Background Color Settings.
Click the Gradient option.
Pick your gradient colors and adjust the angle for the desired effect.
Click Publish to save your changes.
✅ Pro Tip: Stick to lighter gradients for a minimal look and avoid complex color combinations that can distract users.
Method 2: Adding a Gradient Footer Using Custom CSS (Free Version)
If you’re using the free version of Blocksy and the Customizer doesn’t support gradients directly, you can achieve the same effect with CSS code.
✅ Pro Tip: Use subtle animations and keep performance in mind. Avoid fast transitions that might feel distracting.
Method 5: Using Blocksy Pro for Advanced Gradient Features
If you have the Blocksy Pro version, it comes with advanced gradient controls built into the Customizer.
How to Enable Gradient Footers with Blocksy Pro:
Install and Activate Blocksy Pro.
Go to Appearance > Customize > Footer.
Click on the footer section you want to edit.
Enable Advanced Styling Options.
Choose Gradient Background.
Adjust the gradient angle, colors, and intensity.
Publish the changes.
✅ Why Upgrade? Blocksy Pro offers more control, such as:
Multiple Gradient Stops.
Transparency Controls.
Hover Effects.
Best Gradient Color Combinations for Footers
Choosing the right colors can make or break your gradient design. Here are some tested gradient combinations for a footer that works well with Blocksy:
Gradient Style
Hex Codes
Color Theme
Warm Sunset
#ff7e5f, #feb47b
Peach & Coral
Cool Ocean
#2193b0, #6dd5ed
Blue Gradient
Modern Grey
#bdc3c7, #2c3e50
Monochrome
Nature Green
#11998e, #38ef7d
Green Gradient
Retro Purple & Pink
#8e44ad, #f39c12
Purple to Pink
Midnight Sky
#000428, #004e92
Dark Blue
✅ Pro Tip: Stick with colors that match your brand identity for a cohesive design.
Troubleshooting: Gradient Footer Not Working?
If your gradient footer isn’t displaying as expected:
Clear Cache: Try clearing your WordPress and browser cache.
Update Blocksy: Ensure you’re running the latest version of Blocksy.
Check CSS Conflicts: Ensure no conflicting CSS rules override your gradient.
Responsive Check: Test the footer on mobile devices for full compatibility.
Final Thoughts
A custom gradient footer can elevate the look of your Blocksy site significantly. Whether you use Blocksy Pro or CSS tweaks, you can create beautiful gradient effects that boost branding and user engagement.
Escaping the Maze: Mastering ACF’s New HTML Escape Mechanics 🚀
Hello, fellow WordPress aficionados! 🌟 Let’s talk about a game-changer in our beloved ACF PRO that’s causing both excitement and a bit of head-scratching in the community. Yes, you guessed it: ACF now automatically escapes unsafe HTML when rendered by the_field() or the ACF shortcode. Fear not! I’m here to demystify this update and arm you with the knowledge (and code) to tackle any challenges head-on.
Quick Recap: What’s ACF PRO Again? 🧐
For the uninitiated, Advanced Custom Fields (ACF) PRO is the powerhouse behind customizing WordPress sites, allowing you to add custom fields to your pages, posts, and even custom post types. It’s like giving your car a nitro boost but for your website.
The Update: Safety First! 🔐
ACF PRO’s latest update is like a superhero upgrade for your site’s security, automatically escaping unsafe HTML in fields. This means that it helps prevent nasty things like XSS attacks by ensuring that only clean, safe HTML is output through your custom fields.
The Update in a Nutshell: Automatically escapes unsafe HTML.
Affected Functions: the_field(), ACF shortcode.
Why It Matters: Enhances security, and minimizes XSS attack risks.
Breaking it Down: The Impact 🎯
So, what does this mean for you, the developer, designer, or site owner? Let’s dissect:
Pros: Enhanced security, peace of mind, reduced plugin reliance for sanitization.
Cons: Potential impact on fields that intentionally output HTML for functionality.
Looking to resolve the issue of unsafe HTML rendering with ACF PRO? Get expert assistance from Codeable’s WordPress developers today!
Fear not! Adapting is our forte. Here’s how you can embrace this update without breaking a sweat:
1. Understanding the Change
// Before the update
echo get_field('custom_html_field');
// After the update
echo htmlspecialchars(get_field('custom_html_field'), ENT_QUOTES, 'UTF-8');
2. Safe HTML Output
If your field needs to output HTML safely, consider using wp_kses_post():
Imagine you’ve got a custom field designed to embed YouTube videos directly into your posts. Previously, you’d add the iframe into your ACF field, and voila, it’d render seamlessly. Now, with automatic escaping in play, your iframe turns into a visible chunk of HTML code, rather than the intended video player.
The Problem:
<!-- What you entered in ACF -->
<iframe width="560" height="315" src="https://www.youtube.com/embed/dQw4w9WgXcQ" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
<!-- What renders on your site -->
<iframe width="560" height="315" src="https://www.youtube.com/embed/dQw4w9WgXcQ" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
The Solution:
Leverage WordPress’ wp_oembed_get() to safely embed videos, bypassing the need to directly input iframes into ACF fields:
// Fetch video URL from ACF field
$video_url = get_field('video_url');
// Use WordPress oEmbed functionality
echo wp_oembed_get($video_url);
This method ensures your embeds remain functional, sidestepping direct HTML input and keeping your site secure.
Scenario 2: Custom HTML in Text Fields
You’re using ACF to add custom HTML content to a page—perhaps a uniquely styled call-to-action (CTA) block. Post-update, your HTML is being escaped, stripping away the intended design and functionality.
Advanced Use Case: Dynamic Content with ACF and JavaScript
You’re injecting JavaScript via ACF fields for dynamic content customization. The update complicates direct script injection due to automatic escaping.
The Safe Path Forward:
Enqueue Scripts Properly
Store your JavaScript code in external .js files.
Enqueue these scripts using wp_enqueue_script() within your theme’s functions.php, or trigger them conditionally within your template files.
// Example: Enqueuing a custom script
function my_custom_scripts() {
if (get_field('activate_custom_behavior', 'option')) { // Assuming 'option' page setting
wp_enqueue_script('my-custom-script', get_template_directory_uri() . '/js/my-custom-script.js', array('jquery'), null, true);
}
}
add_action('wp_enqueue_scripts', 'my_custom_scripts');
You can also use ACF fields to pass configuration or data to these scripts via localized script variables (wp_localize_script()).
// Localize script with data from ACF fields
function my_localized_script_data() {
wp_localize_script('my-custom-script', 'MyScriptParams', array(
'dynamicData' => get_field('dynamic_data', 'option'),
));
}
add_action('wp_enqueue_scripts', 'my_localized_script_data');
Given the constraints and the nature of your request, I’ll extend the content with more examples and delve deeper into practical scenarios. Let’s get into the nitty-gritty of working around ACF PRO’s HTML auto-escape functionality, ensuring your WordPress projects remain both dynamic and secure.
Navigating ACF PRO’s HTML Escape Functionality 🧭
Deep Dive: The the_field() Conundrum
Imagine you’ve got a custom field designed to embed YouTube videos directly into your posts. Previously, you’d add the iframe into your ACF field, and voila, it’d render seamlessly. Now, with automatic escaping in play, your iframe turns into a visible chunk of HTML code, rather than the intended video player.
The Problem:
<!-- What you entered in ACF -->
<iframe width="560" height="315" src="https://www.youtube.com/embed/dQw4w9WgXcQ" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
<!-- What renders on your site -->
<iframe width="560" height="315" src="https://www.youtube.com/embed/dQw4w9WgXcQ" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
The Solution:
Leverage WordPress’ wp_oembed_get() to safely embed videos, bypassing the need to directly input iframes into ACF fields:
// Fetch video URL from ACF field
$video_url = get_field('video_url');
// Use WordPress oEmbed functionality
echo wp_oembed_get($video_url);
This method ensures your embeds remain functional, sidestepping direct HTML input and keeping your site secure.
Scenario 2: Custom HTML in Text Fields
You’re using ACF to add custom HTML content to a page—perhaps a uniquely styled call-to-action (CTA) block. Post-update, your HTML is being escaped, stripping away the intended design and functionality.
Advanced Use Case: Dynamic Content with ACF and JavaScript
You’re injecting JavaScript via ACF fields for dynamic content customization. The update complicates direct script injection due to automatic escaping.
The Safe Path Forward:
Enqueue Scripts Properly
Store your JavaScript code in external .js files.
Enqueue these scripts using wp_enqueue_script() within your theme’s functions.php, or trigger them conditionally within your template files.
// Example: Enqueuing a custom script
function my_custom_scripts() {
if (get_field('activate_custom_behavior', 'option')) { // Assuming 'option' page setting
wp_enqueue_script('my-custom-script', get_template_directory_uri() . '/js/my-custom-script.js', array('jquery'), null, true);
}
}
add_action('wp_enqueue_scripts', 'my_custom_scripts');
Use ACF fields to pass configuration or data to these scripts via localized script variables (wp_localize_script()).
// Localize script with data from ACF fields
function my_localized_script_data() {
wp_localize_script('my-custom-script', 'MyScriptParams', array(
'dynamicData' => get_field('dynamic_data', 'option'),
));
}
add_action('wp_enqueue_scripts', 'my_localized_script_data');
This approach maintains security while offering dynamic, JavaScript-driven content customization.
Embracing Change: A Path Forward
The transition to automatic HTML escaping in ACF PRO represents a significant shift towards enhancing security and reliability in WordPress development. By adapting your workflows to embrace these changes—leveraging WordPress core functions for sanitization, and strategically managing HTML and JavaScript content—you ensure your projects remain both innovative and secure.
While the journey may require rethinking certain practices, the destination—a more secure, dynamic web—is undoubtedly worth it. Armed with these strategies and examples, you’re well-equipped to navigate the nuances of ACF PRO’s latest update, transforming potential obstacles into opportunities for growth and innovation.
FAQs 🚀
Q: Will this break my site?
A: Not necessarily. Test your fields, especially those outputting HTML.
Q: Can I disable this feature?
A: It’s not recommended due to security concerns, but customizing output methods can bypass automatic escaping.
Q: What if I need to output JavaScript?
A: Carefully. Consider enqueuing scripts rather than embedding them directly.
Looking to resolve the issue of unsafe HTML rendering with ACF PRO? Get expert assistance from Codeable’s WordPress developers today!
This update is a significant step toward more secure, robust WordPress sites. With the tips and tricks shared, you’re well-equipped to adapt and continue creating dynamic, interactive, and safe web experiences.
Stay curious, stay secure, and most importantly, stay awesome! 💪
How to Fix ACF Will Soon Escape Unsafe HTML That is Rendered by the_field()
Advanced Custom Fields (ACF) PRO is a powerful plugin for WordPress developers, allowing them to easily create custom fields and meta boxes for their websites. However, like any tool, it’s essential to use ACF PRO correctly to avoid potential security risks. One such risk involves the rendering of unsafe HTML when using the_field() function, which can leave your site vulnerable to cross-site scripting (XSS) attacks and other security threats. In this article, we’ll delve into this issue and provide practical solutions to fix it.
Looking to resolve the issue of unsafe HTML rendering with ACF PRO? Get expert assistance from Codeable’s WordPress developers today!
Unsafe HTML rendering in ACF can pose a security risk, leaving your website vulnerable to attacks. However, with the advancements in their development process, ACF is soon to introduce a fix that will eliminate this concern. By incorporating this solution, you can enjoy a safer and more secure user experience on your website.
To help you understand how to implement this fix, we will provide you with clear and concise code examples. Whether you are a developer or simply interested in understanding the technical side of ACF, this article has got you covered. Join us as we explore the steps to fix the ACF issue and ensure the safety of your website’s HTML rendering.
Understanding the issue with ACF and unsafe HTML
ACF is a powerful WordPress plugin that allows you to create custom fields and easily add them to your website. However, a common problem with ACF arises when using the_field() function to display the data stored in these custom fields. The function does not escape the HTML output by default, which can lead to potential security vulnerabilities.
When HTML tags and special characters are not properly escaped, it allows malicious users to inject harmful code into your website, leading to cross-site scripting (XSS) attacks. These attacks can result in stolen data, defacement of your website, or even complete control by the attacker.
The impact of unsafe HTML on your website
The impact of unsafe HTML rendering can be severe, affecting both the functionality and security of your website. Let’s take a closer look at the potential consequences:
Security vulnerabilities: As mentioned earlier, unsafe HTML can allow attackers to inject malicious code into your website. This can result in data breaches, unauthorized access, and other security-related issues.
User experience: Unsafe HTML can disrupt the user experience on your website. If the injected code interferes with the layout or functionality, it can lead to a poor user experience, causing frustration and potentially driving visitors away.
Search engine optimization: Search engines may penalize your website if it contains unsafe HTML. This can negatively impact your search engine rankings and overall visibility online.
Introducing the ACF Will Soon Escape Unsafe HTML error
ACF has acknowledged the issue with unsafe HTML rendering and is actively working on a solution. In their upcoming release, they will introduce a new feature called “ACF Will Soon Escape Unsafe HTML.” This feature aims to automatically escape HTML output by default when using the_field() function, providing a safer environment for your website.
The “ACF Will Soon Escape Unsafe HTML” error is a warning message that developers may encounter when using the_field() function without proper HTML escaping. It serves as a reminder to update your code and ensure that the HTML output is secure.
Why the_field() function triggers this error
The_field() function, by default, does not escape the HTML output. This means that any HTML tags or special characters within the custom field data will be rendered as-is, without any encoding or escaping. While this may be convenient for some scenarios, it can pose a significant security risk if the data is not trusted or sanitized.
To address this issue, ACF has decided to introduce the “ACF Will Soon Escape Unsafe HTML” error. This serves as a proactive measure to encourage developers to update their code and ensure the proper escaping of HTML output.
Code examples of the_field() function causing the error
Let’s take a look at some code examples to understand how the_field() function can trigger the “ACF Will Soon Escape Unsafe HTML” error:
In this example, the_field() function is used to output the value of the custom field ‘my_custom_field’. However, if the field contains unsafe HTML or special characters, the function will not escape them by default, triggering the error.
In this example, the_field() function is used within an HTML element. If the custom field contains unsafe HTML, it will be rendered as-is within the div element, triggering the error.
How to fix the ACF Will Soon Escape Unsafe HTML error
Now that we understand the issue and how it can occur, let’s explore three methods to fix the “ACF Will Soon Escape Unsafe HTML” error and ensure the safety of your HTML rendering.
Method 1: Using the update_field() function
One way to fix the “ACF Will Soon Escape Unsafe HTML” error is by using the update_field() function instead of the_field(). The update_field() function allows you to retrieve and escape the HTML output from your custom field, ensuring that it is safe for rendering.
Here’s an example of how you can implement this method:
In this example, we first retrieve the value of the custom field using the get_field() function. Then, we use the esc_html() function to escape the HTML output, ensuring that any unsafe HTML or special characters are properly encoded. Finally, we echo the escaped field value, which can now be safely rendered on your website.
Method 2: Customizing the output with htmlspecialchars()
Another method to fix the “ACF Will Soon Escape Unsafe HTML” error is by customizing the output using the htmlspecialchars() function. This function allows you to encode special characters within your custom field data, preventing them from being interpreted as HTML.
Here’s an example of how you can implement this method:
In this example, we retrieve the value of the custom field using the get_field() function. Then, we use the htmlspecialchars() function to encode any special characters within the field value. This ensures that the HTML output is safe and prevents any potential security vulnerabilities.
Method 3: Using the_field() with the ‘esc_html’ filter
The third method to fix the “ACF Will Soon Escape Unsafe HTML” error is by using the_field() function with the ‘esc_html’ filter. This filter allows you to automatically escape the HTML output without modifying the original field value.
Here’s an example of how you can implement this method:
In this example, we retrieve the value of the custom field using the get_field() function. Then, we use the apply_filters() function to apply the ‘esc_html’ filter to the_field() function. This ensures that the HTML output is properly escaped, providing a safer rendering of the custom field value.
Conclusion
Unsafe HTML rendering in ACF can pose a significant security risk to your website. However, with the upcoming release of “ACF Will Soon Escape Unsafe HTML,” you can ensure a safer and more secure user experience. By implementing the code examples provided in this article, you can fix the “ACF Will Soon Escape Unsafe HTML” error and protect your website from potential attacks.
Remember to always prioritize the security and integrity of your website’s HTML rendering. Stay updated with the latest ACF releases and best practices to ensure a secure and reliable user experience for your visitors.
Looking to resolve the issue of unsafe HTML rendering with ACF PRO? Get expert assistance from Codeable’s WordPress developers today!
ACF will soon escape unsafe html that is rendered by the_field()
This warning means that Advanced Custom Fields (ACF), a popular WordPress plugin, will soon start escaping unsafe HTML input to prevent security issues.
Why is ACF adding this security feature?
ACF wants to prevent unwanted HTML and JavaScript from being executed when field values are rendered in the frontend. Without this security check, it’s possible for malicious users to input code that could compromise your site.
How will this affect my site?
Any field values that contain HTML will have special characters escaped to render as plain text instead. For example:
This will fix the warning and allow your desired HTML to be rendered safely.
2. Get help from WordPress Developers
Trust the expertise of Codeable’s seasoned WordPress developers to implement robust solutions and fortify your site against potential threats. With their in-depth knowledge and meticulous attention to detail, they’ll ensure that your ACF PRO implementation is not only secure but also optimized for performance and functionality. Reach out to Codeable today and safeguard your WordPress site with confidence.
3. Do nothing
If you don’t use HTML in your ACF field values, this update won’t affect you.
Looking to resolve the issue of unsafe HTML rendering with ACF PRO? Get expert assistance from Codeable’s WordPress developers today!
If you’ve recently updated Advanced Custom Fields (ACF) and started seeing warnings about “ACF PRO Will Soon Escape Unsafe HTML,” don’t panic. This is actually a helpful notice from ACF to let you know that some of your field values may contain unsafe HTML that could put your site at risk.
What is “Unsafe HTML”?
Unsafe HTML refers to HTML tags, attributes or code that could potentially be exploited for malicious purposes like XSS (cross-site-scripting) attacks. Some examples of unsafe HTML that will trigger the ACF warning include:
To prevent these kinds of vulnerabilities, ACF PRO will be escaping unsafe values in upcoming versions. Escaping means converting unsafe HTML into plain text so it’s not executed as code.
How to Fix the Warning
To fix this warning and ensure your ACF fields don’t contain unsafe HTML, you have two options:
Manually clean up unsafe values Go through your ACF fields and sanitize any values containing unsafe HTML. Replace or remove HTML tags and attributes, leaving only plain text.
Enable “Escape HTML” on your fields The easiest option is to enable the “Escape HTML” setting on any fields that may contain unsafe values. This will automatically sanitize the values, escaping unsafe HTML.
To enable “Escape HTML” on your fields:
Edit the field group
Click on the field you want to edit
Under “Field Options,” check the box next to “Escape HTML”
Save your changes
This will escape unsafe HTML in both existing and new values for that field going forward. Repeat this for any other fields as needed.
The Risks of Rendering Unsanitized HTML
Unsanitized HTML refers to user-inputted HTML that hasn’t been properly filtered for malicious code before being displayed on your website. Allowing unsanitized HTML to be rendered poses serious security risks.
Cross-Site Scripting (XSS) Attacks
The biggest danger of rendering unsanitized HTML is that it opens you up to XSS attacks. An attacker could input JavaScript, PHP, or other code into a form on your site. If that input is displayed without sanitizing, the code will execute on your site. This allows the attacker to do things like:
Steal cookies and session data
Redirect users to malicious sites
Change or delete site content
Launch denial-of-service attacks
To prevent XSS attacks, you must sanitize all user input before displaying it. For HTML input, use a library like HTML Purifier to filter out unsafe tags and attributes.
Injected Malware
Rendering unsanitized HTML also makes it possible for attackers to inject malicious scripts, iframes, and other HTML elements containing malware. Even if the input isn’t specifically targeting your site, rendering it could infect your users with malware like:
Ransomware that encrypts user files until a ransom is paid
Cryptocurrency mining scripts that hijack CPU power
Keylogging or form-grabbing code to steal user data
SEO and Accessibility Issues
Allowing unfiltered HTML input can also cause problems for search engines and accessibility tools. Unsemantic markup, duplicate content, and hidden text can confuse search engine crawlers. And elements like <blink>, <marquee>, and <font> can disrupt screen readers and other assistive technologies.
How to Fix “ACF PRO — ACF Will Soon Escape Unsafe HTML”
If you see this warning from ACF PRO, it means you have HTML in a field that could potentially contain malicious code. To fix this, you’ll need to sanitize the HTML to strip out anything unsafe.
Use esc_html()
The easiest way to sanitize HTML in ACF is to use the esc_html() function. This will strip out any HTML tags and encode special characters to make the string safe to display.
For example, if you have a text field with this HTML: <p><a href=”http://example.com”>Link</a></p>
You can display it safely like this:
echo esc_html( $field['value'] );
This will output: <p><a href=”http://example.com”>Link</a></p>
Allow Specific Tags
If you want to allow some HTML tags but not others, use wp_kses_post(). This lets you pass an array of allowed tags.
This will strip out any tags not in the allowed_tags array, sanitizing the input.
Use ACF’s sanitize_callback
The best way to sanitize an ACF field is to use the sanitize_callback argument. You can pass a callback function that will be run whenever the field is saved.
This will run the my_acf_sanitize_html() function whenever the html_field is saved, sanitizing the input.
Using Esc_html() and Esc_attr() to Sanitize Output
To fix the “ACF PRO Will Soon Escape Unsafe HTML” warning, you’ll need to sanitize all output in your ACF fields. This means escaping HTML characters so they are not executed as code. ACF provides two helper functions for this:
esc_html()
Use esc_html() to sanitize output that will be displayed in the HTML body. This escapes characters like <, >, “, ‘, etc. For example:
echo esc_html( $your_string );
esc_attr()
Use esc_attr() to sanitize output used in HTML attributes like src, href, value, etc. For example:
echo '<a href="' . esc_attr( $your_string ) . '">Link</a>';
[php]
<h2>Examples of Escaping ACF Values Before Output</h2>
To fix this warning, you'll need to properly escape ACF field values before outputting them. This means converting characters that could be misinterpreted as HTML into HTML entities.
For example, to output a field named <code>my_text</code>, you'd use:
[php]
echo esc_html( get_field('my_text') );
The esc_html() function will escape things like <, >, “, ‘, and &. So if the field value was:
This is a <b>test</b> with "quotes" and 'apostrophes' & ampersands
The output would be:
This is a <b>test</b> with "quotes" and 'apostrophes' & ampersands
This prevents the text from being interpreted as actual HTML.
You’ll want to escape ACF values anywhere they’re output, like:
This will escape the $field_value, making it safe to use in the href attribute.
esc_html()
The esc_html() function escapes HTML for output in the HTML body. Use this when outputting ACF field values that will be displayed as raw HTML. For example:
echo esc_html($field_value);
This will escape the $field_value, making it safe to echo as HTML.
wp_kses_post()
The wp_kses_post() function strips out any invalid HTML and sanitizes the remaining HTML to ensure it’s safe for output. This is a more comprehensive sanitization method compared to esc_html(). Use this when allowing users to enter custom HTML in an ACF field.For example:
echo wp_kses_post($field_value);
This will sanitize the $field_value and strip out any unsafe HTML before outputting.
ACF Stripsafe
The Stripsafe ACF add-on allows you to configure allowed HTML tags, attributes and protocols on a per-field basis. This gives you granular control over HTML sanitization for ACF fields.
Should I sanitize ACF values on save or output?
It is best practice to sanitize ACF field values on output rather than save. This allows you to sanitize values for different contexts, and allows HTML/scripts in fields that are safely output in certain contexts.
What sanitization method should I use?
It depends on your needs. Use esc_attr() for attributes, esc_html() for basic HTML, wp_kses_post() for more comprehensive sanitization, and ACF Stripsafe for granular control.
When You Should Not Escape ACF HTML Output
Sometimes you’ll want ACF to output HTML instead of escaping it. For example, if you’re using ACF to build a post content editor with a rich text editor field, you’ll want the field to output HTML to properly format the content.
To tell ACF not to escape a field’s output, you can add esc_html => false to the field’s arguments:
Now the content field will output raw HTML which WordPress will properly format on the frontend.
You’ll also want to do this for any field where you intend to have HTML in the value, such as:
Textarea fields
Code fields
Gallery fields
Etc.
Any field where you’re allowing editors to add custom HTML, you’ll need to set esc_html => false. Otherwise, ACF will escape the HTML to prevent XSS vulnerabilities.
Escaping Unsafe HTML Rendered by ACF The_field()
ACF PRO recently started warning you that “ACF will soon escape unsafe HTML that is rendered by the_field()”. What does this mean and how can you fix it?
When ACF renders a field using the_field(), it outputs the value without escaping it. This means if the value contains HTML, it will be executed. While this is useful in some cases, it can also pose a security risk. To fix this, ACF PRO will automatically escape values to prevent unwanted HTML execution.
To fix this warning and opt-in to escaping values, you have two options:
Add esc_html() when echoing the_field()
echo esc_html( the_field('some_field') );
Add ‘escape_output’ => true when registering the field
This will tell ACF to automatically escape the value for this field when using the_field().
FAQ
I have an HTML form where users can enter content. Should I sanitize that input?
Yes, always sanitize any HTML input before displaying it. Use a library like HTML Purifier to remove unsafe tags and attributes.
What's the difference between sanitizing and escaping HTML?
Sanitizing HTML filters out unsafe elements, attributes, and code. Escaping HTML converts special characters like < and > into HTML entities (< and >) which prevents the browser from executing any code. For security, you should sanitize first, then escape.
How can I prevent XSS attacks?
To prevent XSS attacks, follow these best practices:
Sanitize all user input, especially HTML, JavaScript, CSS, and URL input.
Use a library like HTML Purifier, DOMPurify or bleach to sanitize HTML.
Escape all output, including data from databases, with htmlspecialchars() or esc_html().
Use httponly, secure, and samesite cookies to prevent cookie theft.
Do I need to sanitize on the front-end and back-end?
Yes, it's best practice to sanitize data on both sides. Sanitize when saving data to the database (back-end) and also when outputting data to the front-end. Without sanitizing, malicious users could input JavaScript or other code into your ACF fields and have it execute on your site. This is a major security risk known as an XSS (cross-site-scripting) attack. You only need to sanitize string data that will be output to the page. Numbers, dates, file uploads, etc. do not need to be sanitized.
How do I fix fields that have already been created?
Unfortunately, you'll need to manually edit any existing ACF fields and add the necessary esc_html() and esc_attr() calls. Any new fields you create will need to have sanitization added right away.
To fix the "ACF PRO Will Soon Escape Unsafe HTML" warning and lock down the security of your site's data, be sure to sanitize all ACF output using esc_html() and esc_attr(). Your users and server will thank you!
What if I don't fix this warning?
If left unfixed, upcoming versions of ACF PRO will automatically escape unsafe HTML in your field values to prevent security issues. Some formatting loss may occur, so it's best to manually clean up or enable escaping on the fields. ACF PRO is improving security by escaping unsafe HTML output. This warning gives you a chance to opt-in to the new escaping behavior. ACF PRO will require escaping or sanitizing field values in a future update. This warning gives you time to make the necessary updates to your templates to avoid issues when that change occurs.
What about when using ACF in widgets?
Yes, you'll want to escape ACF values in widgets as well before outputting them. Simply call esc_html() on the field value same as anywhere else.
Will enabling "Escape HTML" affect my field values?
Enabling this setting will convert any unsafe HTML in your field values to plain text. Some formatting may be lost, but it helps prevent vulnerabilities.
Reach out to the Codeable experts for help. Their WordPress developers can fully audit your site and ACF PRO integration to fix any issues causing warnings.
There are a few key benefits to having Codeable audit your site:
• Comprehensive review – We will review all instances of ACF on your site, including fields, locations, and how ACF is integrated with your theme.
• Technical expertise – Our developers are ACF PRO experts and can identify issues that may be causing the unsafe HTML warning.
• Custom fixes – We will provide recommendations and implement any custom code fixes needed to resolve the warning and make your ACF integration safe and secure.
• Future-proofing – After fixing current issues, we can recommend best practices to implement going forward to avoid similar errors.
• Peace of mind – You’ll have confidence that your ACF PRO integration is running smoothly and not exposing your site to risk.
If you’d like a free consultation to discuss an ACF PRO audit for your site, feel free to reach out. We can review your issues, provide a free quote, and develop a customized plan to resolve any ACF or WordPress integration issues.
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Duration
Description
cookielawinfo-checkbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.