Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor shortcodes.php #276

Open
patrickmj opened this issue Jan 12, 2024 · 2 comments
Open

Refactor shortcodes.php #276

patrickmj opened this issue Jan 12, 2024 · 2 comments
Assignees

Comments

@patrickmj
Copy link
Member

Estimated Time the initial estimate of the time required to completion

20+ hours

Description what the issue is about

That file contains a lot of the work to convert a shortcode into the query to the DRS. It needs to more modular, with particular emphasis on separation of responsibilities, with the URL for GET query being built up in distinct pieces.

The parameters for the query string are currently passed along in $_POST. The ability to continue using that will have to persist. However, for future CERES, we also need to be able to construct the same query string from data that does not arrive by POST. The same data will be present, just delivered via a different mechanism TBD.

For both situations, though, separations of responsibility will be essential.

Sub tasks briefly and descriptively add sub tasks, which may be converted to issues

  • [ ]
@drashti-NEU
Copy link

Following are the subtasks/steps that can be followed to address the modularization and separation of responsibilities in the given code :-

  1. Refactor Query Building Logic:

    • Identify the logic responsible for building the query string. Refactor the logic into a separate function or class method.
  2. Separate Query Parameter Handling:

    • Separate the handling of query parameters from the main logic. Create a function or class method specifically for processing and validating query parameters which may just take the raw input (from $_POST or any other source) and return a structured set of parameters.
  3. Handle AJAX Request and Non-AJAX Request Separately:

    • Identify the parts of the code that handle AJAX requests and those that might handle non-AJAX requests. Create separate functions or methods to handle these two scenarios. For both cases, make use of the common query building and parameter handling logic to avoid redundancy.
  4. Ensure Data Sanitization and Validation:

    • Implement robust data sanitization and validation for all input parameters.
  5. Proper Commenting in the code:

    • Add inline comments to explain the purpose and functionality of each function of the refactored code.
  6. Test the Refactored Code:

    • Create test cases to validate that the refactored code performs as expected. Test both AJAX and non-AJAX scenarios with various input parameters. Ensure that the refactored code produces the correct query strings and handles errors gracefully.
  7. Update Dependencies and Libraries:

    • Check for updates to any third-party libraries or dependencies used in the code. Update these dependencies to their latest versions, ensuring compatibility and security.

@drashti-NEU
Copy link

drashti-NEU commented Feb 22, 2024

The shortcodes.php file is successfully refactored and the changes are committed to shortcode-refactor branch. Following are the key changes applied :-

  • Use of AJAX Actions: The code registers AJAX actions for handling requests for DRS and DPLA items, as well as for retrieving custom and post metadata.
  • Nonce Verification: It properly utilizes nonce verification (check_ajax_referer) to ensure the security of AJAX requests, which is a crucial aspect of WordPress development.
  • Localized Script Data: The script localizes data for JavaScript, providing a secure and efficient way to include dynamic PHP values in JS.
  • Dynamic Parameter Handling: Instead of hardcoding each filter and its corresponding API parameter, we now have a generic way to process any number of parameters. This is achieved through the process_drs_filters and process_dpla_filters functions, which can be extended easily with new cases as your API evolves or as new filters are introduced.
  • Use of http_build_query: This function is utilized to build the query string dynamically from an associative array, making the URL construction cleaner and more flexible.
  • Fallback for Missing Parameters: In the build_dpla_url function, $_POST['params']['pid'] ?? "" ensures that if the pid parameter is not set, an empty string is used instead to avoid PHP errors.
  • Extensibility and Maintenance: With this approach, adding a new filter parameter to the AJAX requests no longer requires updating the URL construction functions. Instead, we only need to add a new case in the process_drs_filters or process_dpla_filters function if the parameter name needs to be transformed or handled in a specific way.

This refactoring makes the code more optimized, adaptable and easier to maintain, especially as the complexity of the application grows or as new features are added.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants