gw-display-html-field-on-entry-detail.php: Added a snippet to display HTML field content on Entry Details page.
#1074
Conversation
…ay HTML field content on Entry Details page.
…ay HTML field content on Entry Details page.
|
""" WalkthroughA new PHP class, Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant GF as Gravity Forms Engine
participant GW as GW_Display_HTML_Field_Entry_Detail
User->>GF: Request entry detail or entry list view
GF->>GW: Trigger display_html_field_content hook
GW->>GW: Check form and field IDs
GW->>GW: Process HTML content (apply live merge tags, merge tags, shortcodes)
GW->>GF: Return sanitized, rendered HTML content
GF->>User: Render entry detail or entry list with HTML content
Suggested reviewers
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
gravity-forms/gw-display-html-field-on-entry-detail.php (1)
80-118: Secure processing and display of HTML content.The method properly:
- Retrieves saved content
- Conditionally processes Live Merge Tags
- Processes shortcodes
- Securely outputs content with proper escaping via
esc_html()andwp_kses_post()Consider making the HTML output structure more customizable for different display requirements.
- printf( - '<h4>%s</h4><div>%s</div><hr>', - esc_html( $field->label ), - wp_kses_post( $content ) - ); + // Add a filter to allow customization of the HTML output structure + $output_template = apply_filters( + 'gw_display_html_field_template', + '<h4>%1$s</h4><div class="gw-html-field-content">%2$s</div><hr>', + $field, + $entry + ); + printf( + $output_template, + esc_html( $field->label ), + wp_kses_post( $content ) + );
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
gravity-forms/gw-display-html-field-on-entry-detail.php(1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (1)
gravity-forms/gw-display-html-field-on-entry-detail.php (1)
gravity-forms/gw-calculated-shipping.php (1)
field(91-117)
🔇 Additional comments (6)
gravity-forms/gw-display-html-field-on-entry-detail.php (6)
1-16: Well-structured plugin header with clear documentation.The header includes a descriptive title, purpose explanation, and instruction video link, which are excellent for helping users understand the snippet's functionality.
19-31: Clean implementation of constructor with proper default values.The constructor properly uses
wp_parse_args()to merge user arguments with defaults, providing a flexible API for customization.
33-37: Good use of WordPress hooks for integration with Gravity Forms.The initialization method properly hooks into the Gravity Forms lifecycle at appropriate points - after entry save and during entry detail display.
39-43: Appropriate form validation logic.The helper method handles both array and integer input formats, with proper type casting for comparison.
51-72: Safe implementation of HTML field content saving.The method correctly validates the form, iterates through fields, and saves HTML content to entry metadata. It properly uses Gravity Forms API functions and applies appropriate conditions.
121-125: Update hardcoded IDs in the configuration.The snippet includes specific form and field IDs in the instantiation that need to be updated for your specific use case.
Make sure to replace the hardcoded IDs (form_id: 846, field_id: 4) with your actual form and field IDs before using this snippet in production. Alternatively, you could set these to
falseto process HTML fields across all forms:new GW_Display_HTML_Field_Entry_Detail( array( - 'form_id' => 846, // Replace with your form ID or leave false for all. - 'field_id' => 4, // Replace with your HTML field ID or leave false to process all HTML fields. + 'form_id' => false, // Set your specific form ID or leave as false for all forms + 'field_id' => false, // Set your specific HTML field ID or leave as false for all HTML fields ) );
|
@saifsultanc Just a note this should support the Entry List as well. 🙏 |
…ay HTML field content on Entry Details page.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
gravity-forms/gw-display-html-field-on-entry-detail.php (3)
35-36: Consider extending support to the Entry List page.
At present, the snippet only hooks intogform_entry_detail. Per the PR discussion, you may also wish to display the HTML field on the Entry List. Gravity Forms offers filters (e.g.,gform_entries_list_columnsorgform_entries_list_column_value) for customizing column output in listing views.Here's a starting point if you decide to pursue this:
add_action( 'gform_entry_detail', array( $this, 'display_html_field_content' ), 10, 2 ); +// Consider hooking into the entries list to display HTML field content in the listing view as well. +add_filter( 'gform_entries_list_column_value', array( $this, 'display_html_field_in_list' ), 10, 4 );
100-105: Check for the class existence before invoking methods.
method_exists( 'GP_Populate_Anything_Live_Merge_Tags', 'has_live_merge_tag' )will returnfalseif the class does not exist, but referencingGP_Populate_Anything_Live_Merge_Tags::get_instance()could still cause an error if the class is not loaded. Consider adding aclass_exists()check for complete safety.
113-118: Use a different heading level or remove the<hr>for a cleaner layout.
Using<h4>and<hr>for each field might be visually cluttered on certain admin pages. If multiple HTML fields exist, consider a simpler heading or a refined stylistic approach.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
gravity-forms/gw-display-html-field-on-entry-detail.php(1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (1)
gravity-forms/gw-display-html-field-on-entry-detail.php (1)
gravity-forms/gw-calculated-shipping.php (1)
field(91-117)
🔇 Additional comments (1)
gravity-forms/gw-display-html-field-on-entry-detail.php (1)
124-129: Configuration appears correct.
Current instantiation targets form ID 846 and field ID 4. This is fine for a single form and field setup. If you want to process multiple fields or multiple forms, consider leaving ‘field_id’ or ‘form_id’ asfalse.
…ay HTML field content on Entry Details page.
Yup. Done! |
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
gravity-forms/gw-display-html-field-on-entry-detail.php (1)
66-72:⚠️ Potential issueValidate
$formbefore referencing$form['fields'].
IfGFAPI::get_form()returnsfalse,$formwill not be an array and$form['fields']will trigger an error. This repeats a concern raised in previous reviews. Consider adding a guard clause to prevent potential PHP notices or fatal errors.$form = GFAPI::get_form( rgar( $entry, 'form_id' ) ); +if ( ! is_array( $form ) ) { + return $entry; +} if ( ! $this->is_applicable_form( $form ) ) { return $entry; }
🧹 Nitpick comments (1)
gravity-forms/gw-display-html-field-on-entry-detail.php (1)
102-121: Consider unifying or documenting your display logic for Entry Detail and Entry List.
Both methods share similar steps (fetch and process content). Creating a reusable helper or adding docblocks could improve maintainability and clarity.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
gravity-forms/gw-display-html-field-on-entry-detail.php(1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (1)
gravity-forms/gw-display-html-field-on-entry-detail.php (1)
gravity-forms/gw-calculated-shipping.php (1)
field(91-117)
🔇 Additional comments (2)
gravity-forms/gw-display-html-field-on-entry-detail.php (2)
81-100: Entry Detail Rendering Logic Looks Good.
This section correctly retrieves the saved HTML content for each applicable field and processes it for display. Great job ensuring that only valid HTML fields are processed.
124-129: Configuration Instantiation is Straightforward!
Everything looks good here. This is a clear and minimal setup for specifying the form and field IDs.
|
|
||
| public function init() { | ||
| add_filter( 'gform_entry_post_save', array( $this, 'save_html_field_content' ), 10, 1 ); | ||
| add_action( 'gform_entry_detail', array( $this, 'display_html_field_content_entry_detail' ), 10, 2 ); |
There was a problem hiding this comment.
What do you think about generating the HTML content on entry detail page load instead of persisting the info with the entry?
Two reasons:
- That would allow this to work on existing entries without needing to update the entry to trigger the HTML content generation.
- Updates to the snippet would then automatically apply rather than needing to go back through and manually updating / saving entries to get the updates reflected in the displayed data.
There was a problem hiding this comment.
@veryspry 🤔 From what I am able to recall, one reason for doing it this way to ensure dynamic loading of any updated HTML content.
There was a problem hiding this comment.
@saifsultanc wouldn't it work the opposite the way it is — like wouldn't the content only update after the entry is saved? Or is that okay as this is displaying HTML Field content that would only ever change if the field is updated?
I guess either way, I don't know if the additional meta is required here as the content is already available on the $field itself, right?
There was a problem hiding this comment.
Great point and I guess you're right. After reviewing the code again, I realized we're only storing the unprocessed HTML content in meta, which is already available via $field->content. So persisting it adds unnecessary complexity without giving us a true "snapshot."
I'll gone ahead and refactored this to render the HTML dynamically. @veryspry
…ay HTML field content on Entry Details page.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
gravity-forms/gw-display-html-field-on-entry-detail.php (2)
82-83: Consider improving the recursion prevention mechanism.The static
$is_runningflag provides basic recursion protection, but it could remaintrueif an exception occurs during processing, potentially blocking future executions. Consider using a try-finally block or a more robust mechanism.static $is_running = false; if ( $is_running || rgget( 'page' ) !== 'gf_entries' || ! $this->is_applicable_field( $field ) ) { return $value; } -$is_running = true; -$content = $this->process_html_content( $field->content, $form, $entry ); -$is_running = false; +$is_running = true; +try { + $content = $this->process_html_content( $field->content, $form, $entry ); +} finally { + $is_running = false; +}Also applies to: 93-95
102-105: Update configuration values for production use.The configuration section contains hardcoded form ID (846) and field ID (4) values that appear to be specific to a development/testing environment. These should be updated to match the target form and field IDs for the actual implementation.
Consider adding a comment to make it clearer that these values need to be customized:
# Configuration +// TODO: Update these IDs to match your specific form and HTML field new GW_Display_HTML_Field_Entry_Detail( array( - 'form_id' => 846, // Replace with your form ID or leave false for all. - 'field_id' => 4, // Replace with your HTML field ID or leave false to process all HTML fields. + 'form_id' => false, // Replace with your form ID or leave false for all forms. + 'field_id' => false, // Replace with your HTML field ID or leave false to process all HTML fields. ) );
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
gravity-forms/gw-display-html-field-on-entry-detail.php(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: Danger JS
🔇 Additional comments (5)
gravity-forms/gw-display-html-field-on-entry-detail.php (5)
1-13: Documentation and file header look good.The file header provides clear information about the plugin's purpose and functionality. The description accurately reflects the feature implementation for displaying HTML field content with live merge tags and shortcodes.
14-28: Class constructor properly handles configuration.The constructor uses
wp_parse_args()correctly to merge user-provided arguments with sensible defaults, and the hook setup in the constructor follows WordPress best practices.
35-43: Validation methods are well implemented.Both
is_applicable_form()andis_applicable_field()handle the filtering logic correctly, with proper type checking and field type validation for HTML fields.
45-59: Content processing includes proper security measures.The content processing method correctly handles live merge tags, standard merge tags, and shortcodes, with appropriate sanitization using
wp_kses_post()to prevent XSS vulnerabilities while preserving legitimate HTML content.
61-79: Entry detail display method is well structured.The method properly validates the form, iterates through fields safely, and uses
printf()with proper escaping for the field label while allowing processed HTML content to be displayed.
| $form = GFAPI::get_form( $field->formId ); | ||
| if ( ! $this->is_applicable_form( $form ) ) { | ||
| return $value; | ||
| } |
There was a problem hiding this comment.
Add validation for the form object returned by GFAPI::get_form().
The GFAPI::get_form() call could return false if the form doesn't exist, which would cause is_applicable_form() to receive an invalid parameter. This is similar to the issue that was previously addressed in the entry detail method.
$form = GFAPI::get_form( $field->formId );
+if ( ! is_array( $form ) ) {
+ return $value;
+}
+
if ( ! $this->is_applicable_form( $form ) ) {
return $value;
}🤖 Prompt for AI Agents
In gravity-forms/gw-display-html-field-on-entry-detail.php around lines 88 to
91, add a validation check after calling GFAPI::get_form() to ensure the
returned $form is not false before passing it to is_applicable_form(). If $form
is false, return $value immediately to prevent passing an invalid parameter and
avoid potential errors.
Context
⛑️ Ticket(s): https://secure.helpscout.net/conversation/2901917754/81943/
Summary
Allow HTML field content to displayed on Entry Details page.
https://www.loom.com/share/fa4b49240b6447c7839392af69476bf2