The customer wanted to create a search form with drop-down options for filtering academic texts on their website, aiming to replicate a search functionality similar to that on the Jeb Dunnuck site. They faced difficulties implementing this using Toolset Views with the legacy editor.
Solution:
To achieve the desired search functionality, the customer was advised to add a select dropdown for post type filters within their view and use the following code for implementation:
I am trying to add a block type called "Open Sheet Music Display" as a custom field within a custom post type (music-styles). I attempted using a WYSIWYG and multi-line custom field, but they do not allow adding blocks. It seems I can only use Gutenberg blocks outside of custom fields.
Solution:
Blocks are a native feature of the WordPress editor and cannot be used within custom fields. Toolset cannot recreate block functionality inside custom fields because custom fields are standard WordPress features that do not support block content. You can only use blocks inside the main content editor.
The customer reported that since September 6, their security software marked the submit.php file from Toolset as suspicious, along with other files from various Toolset plugins. This issue affected all their sites using Toolset plugins, leading to concerns about potential security risks.
Solution:
We conducted a review of the flagged files and found no malicious content but recommended that the customer manually replace the plugin files with fresh copies from the Toolset downloads page. After the customer reported that reinstalling the fresh copies did not resolve the issue, we confirmed it was a false positive. We contacted the WPMU team to request whitelisting of the files.
The customer was advised that they could also reach out directly to the WPMU support team for faster assistance regarding the whitelisting process. Ultimately, the WPMU team confirmed that the files were whitelisted, resolving the customer's issue.
The customer was using the cred-delete-post shortcode to allow users to delete posts but encountered an error message ("Something went wrong, please reload the page and try again") when attempting to delete posts with any role other than administrator. Additionally, a user with the "Adm Entidades" role was incorrectly able to see an edit form that they should not have access to.
Solution:
Upon investigation, we found that the issue stemmed from a custom code snippet that was causing redirection conflicts. Specifically, when the code included a wp_redirect function, it led to an infinite redirect scenario, preventing users from performing the delete action.
To resolve this, we temporarily disabled the custom code and moved it to the Toolset custom code section. We ensured that it would not execute during AJAX calls by unchecking the "Llamadas AJAX" option in the settings. This adjustment allowed users with the "Adm Entidades" role to delete posts without encountering the error.
The customer was able to confirm that the changes worked as intended.
The customer is trying to find where to enter a new registration key for Toolset in the website dashboard but only sees hyperlinks for new registration.
Solution:
We directed the customer to navigate to wp-admin > Plugins > Add New > Commercial tab, where they can find the option to unregister Toolset. After doing so, they will see an option to register Toolset and enter the new key.
The customer was unable to set image sizes in the Advanced Custom Fields (ACF) settings within the WordPress dashboard. The image size dropdown was not appearing, which hindered the ability to select a custom size for images.
Solution:
We discovered that the issue was related to resource limitations on the server. By disabling several resource-intensive plugins, the customer was able to access the image size settings properly. Additionally, we recommended increasing the PHP and WordPress memory limits to improve performance.
