The customer wanted to filter a view on their website so that only specific URL parameters, such as "category=blog," remain visible in the URL after filtering. By default, all parameters were displayed, which cluttered the URL with unnecessary information.
Solution:
A combination of PHP and JavaScript was used to selectively retain only the category parameter in the URL after filtering. Here’s the implemented approach:
1- A hidden field was added to capture and maintain the category parameter, using a custom function in the theme’s functions.php file:
add_filter('wpv_filter_end_filter_form', 'add_hidden_category_param', 99, 4);
function add_hidden_category_param($out, $view_settings, $view_id, $is_required) {
$views = array(12345); // Replace with the View ID
if (in_array($view_id, $views) && $is_required) {
$category = isset($_GET['category']) ? $_GET['category'] : '';
$out = '<input type="hidden" id="category" name="category" value="' . esc_attr($category) . '" />' . $out;
}
return $out;
}
This function captures the category parameter and stores it in a hidden input field to ensure it persists through the filter updates.
2- In the View's Custom JavaScript section, this code was added to ensure only the category parameter remains visible in the URL
jQuery(document).ready(function($) {
$(document).on('js_event_wpv_parametric_search_form_updated', function(event, data) {
var url = new URL(window.location);
var category = url.searchParams.get("category");
jQuery('#category').val(category); // Update hidden input field with the category parameter
// Update the URL to show only the category parameter
let params = new URLSearchParams({ category: category });
window.history.replaceState({}, '', `${url.pathname}?${params.toString()}`);
});
});
This JavaScript ensures the URL updates to include only the category parameter after filtering, creating a cleaner URL.
The customer needed to register and use Toolset on a development version of their live site. However, Toolset was showing an error due to a mismatch between the live and development site URLs, as each Toolset site key is bound to a specific URL.
Solution:
The customer was directed to Toolset's FAQ regarding registration in a development environment. Key points from the guidance included:
- Multiple Site Keys for Unlimited Accounts: For users with Unlimited Sites or Lifetime accounts, Toolset allows multiple site keys. They can create separate keys for development and production environments to avoid URL conflicts.
- Manual Installation for Single Site Accounts: For customers with a Single Site account, which only provides one site key, it is recommended to skip registration on the development site. Instead, they should download the necessary Toolset plugins directly from their Toolset Account page and manually install them on the development site. This approach maintains automatic updates exclusively on the live, production site.
The customer wanted to display a countdown for the next event date from a custom post type for a music band, using a date field as the target. Although they initially used the Spectra Pro countdown block, they encountered challenges setting a dynamic end date directly.
Solution:
The Toolset Countdown block can use dynamic data for the countdown's end date. However, to make this work with Spectra Pro or any countdown block that accepts shortcode-based data, the customer could format Toolset's date field from a UNIX timestamp to a format compatible with Spectra. The steps included:
1. Creating a View Loop: Even when displaying a single upcoming event, creating a View loop within Toolset allows the countdown block to be placed dynamically within the loop.
2. Formatting the Date for Compatibility: Toolset provides methods to convert the date field from UNIX format, ensuring compatibility with external blocks like Spectra Pro if shortcodes are required.
The customer confirmed this setup worked, with the Toolset Countdown block operating dynamically within the loop for future events.
The customer’s form at https://www.domain.com/apply-form/ was experiencing issues with the date picker and conditional logic fields, which were not functioning as expected. The issue was identified as jQuery not loading correctly on the page.
Solution:
Upon investigation, it was found that the Autoptimize plugin was preventing jQuery from loading, which affected the date picker and conditional logic functionalities. The solution steps included:
1- Disabling the Autoptimize Plugin Temporarily: The plugin was disabled, which restored the date picker functionality on the form page.
2- Recommendation for Long-term Fix: The customer was advised to reach out to Autoptimize plugin support to determine why jQuery wasn’t loading on all pages. This would allow them to keep the plugin enabled without impacting jQuery-dependent functionalities.
