Backend Implementation HFE Builder #1282
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| 'show_in_menu' => false, | ||
| 'show_in_nav_menus' => false, | ||
| 'exclude_from_search' => true, | ||
| 'capability_type' => 'post', |
There was a problem hiding this comment.
What: The show_in_rest parameter is added but there is no indication if the custom post type supports the necessary properties for REST API functionality.
Why: Ensuring that the custom post type is set up correctly for REST API interaction is crucial for both functionality and security. If it's not configured properly, it might lead to exposing data that should be restricted or failing to handle API requests correctly.
How: Verify that this custom post type has the required features enabled for REST API usage, such as supports for relevant fields like title, editor, etc. Additionally, consider defining the rest_base property if a custom endpoint is needed.
| 'show_in_menu' => false, | ||
| 'show_in_nav_menus' => false, | ||
| 'exclude_from_search' => true, | ||
| 'capability_type' => 'post', |
There was a problem hiding this comment.
What: No validation or sanitization for the data being passed to the REST API is mentioned in the description.
Why: Not validating or sanitizing user input can lead to vulnerabilities such as SQL injection, XSS, or other forms of attacks, compromising the security of the application.
How: Ensure to implement validation and sanitization functions for any input being handled by the new API endpoints. Consider using WordPress functions like sanitize_text_field(), sanitize_email(), etc., to safeguard against malicious input.
| 'show_in_menu' => false, | ||
| 'show_in_nav_menus' => false, | ||
| 'exclude_from_search' => true, | ||
| 'capability_type' => 'post', |
There was a problem hiding this comment.
What: Consider adding authentication checks for API requests to ensure only authorized users can access or manipulate the data.
Why: Without proper authentication, unauthorized users might access sensitive data or make changes to the system inappropriately, leading to data leaks or corruption.
How: Use WordPress functions such as current_user_can() to enforce permissions checking on your REST API endpoints, ensuring that only users with the correct capabilities can execute certain actions.
build/main.asset.php Outdated
| @@ -1 +1 @@ | |||
| <?php return array('dependencies' => array('react', 'react-dom', 'wp-api-fetch', 'wp-dom-ready', 'wp-element', 'wp-i18n', 'wp-polyfill'), 'version' => '4bfc9da33a23e2941d13'); | |||
| <?php return array('dependencies' => array('react', 'react-dom', 'wp-api-fetch', 'wp-dom-ready', 'wp-element', 'wp-i18n', 'wp-polyfill'), 'version' => '35dec36d1d208bf88914'); | |||
There was a problem hiding this comment.
What: The version number appears to have been updated. Ensure that this reflects a meaningful change or optimization to your application.
Why: Updating the version number should indicate that key changes or improvements have occurred. This will help team members and users understand that there have been updates that may affect their experience or the functionality of the project.
How: Double-check the updated versioning scheme and ensure that it aligns with your project's versioning policy. If changes were made to dependencies that impact the application, document those changes accordingly in your changelog.
…dispaly-conditon Added select option in display condition
Finalize custom block redirect
…mforce/header-footer-elementor into rename_functionality_3
updated RM feedback 4
Rename functionality 2
updated styles for display modal
…on-issue Fixed extra post creation issue
Added security verification for all calls.
EPS-1554: Template Rename functionality
Description
Main Purpose: This pull request implements significant backend functionality to enhance the Header Footer Elementor (HFE) Builder, introducing REST API endpoints to manage display conditions and custom layouts more effectively.
Key Changes:
class-hfe-admin.php, added ashow_in_restparameter for custom post types to ensure compatibility with the WordPress REST API.hfe-settings-api.php, registered multiple new REST API routes (e.g.,/target-rules,/create-layout,/target-rules-options) to handle fetching and saving display conditions for headers and footers.AllLayouts.jsxcomponent to utilize the new API for fetching target rule options and creating layouts dynamically, improving user interaction by allowing users to save and manage conditions directly from the UI.SidebarMenu.jsx, to improve the user interface and guide users towards upgrade options.Additional Notes: Reviewers should focus on the newly registered API endpoints to ensure they function correctly with the expected request and response formats, including user permissions handling. Additionally, verify the frontend integration in
AllLayouts.jsxfor correct API interaction and UI behavior changes. Consider potential impacts on existing user workflows due to the addition of these features. Testing will be crucial to validate that display conditions are saved and fetched as intended.Screenshots
Types of changes
How has this been tested?
Checklist: