The customer is experiencing a connection error preventing Toolset from communicating with its server to check for updates. The error message indicates a cURL error 28, specifying that the connection to api.toolset.com failed. The customer has already checked with their host, and the firewall does not appear to be blocking the connection. Despite confirming that there are no restrictions, the issue persists, and the host suspects it might be related to the Toolset plugin.
Solution:
We suggested adding specific Toolset-related IP addresses to the server's allow list and ensuring that the server correctly resolves the domain names to their respective IPs. We also advised checking if the cURL library on the server is up-to-date. After further investigation, we confirmed that there were no blocks on our end and recommended the customer recheck with their hosting provider, possibly disabling the firewall temporarily to test the connection.
The customer wanted to enable users to upload files (resumes and certificates) via a Toolset form and store these files in a custom directory (/wp-content/bewerbungsunterlagen) rather than the default uploads folder. The initial code attempts failed, saving files in the standard uploads directory.
Solution:
We suggested refining the upload_dir filter to ensure it only applies when necessary and removed afterward to avoid conflicts. Additionally, the permissions for the custom post type 'Bewerbungen' were adjusted in Toolset > Access Control to allow guest users to upload files without needing to log in. To prevent WordPress from generating thumbnails for PDF files, a code snippet was added to the functions.php file to disable PDF previews:
The customer experienced an issue where a numerical field was sorting incorrectly, treating numbers as strings. After fixing this, they reported a new issue: navigation problems when users are not logged in, but everything works fine when users are logged in.
Solution:
The initial sorting issue was resolved by changing the field type to a number. The new issue with navigation for logged-out users was split into a separate ticket to maintain a focus on one issue per ticket.
The customer was unable to disable a custom code in Toolset settings due to a 403 error caused by their hosting security system, which blocked Ajax requests to admin-ajax.php, labeling it as an exploit attempt. The firewall prevented changes that required Ajax, such as disabling custom code or modifying certain settings within the Toolset plugin.
Solution:
We identified the issue as being related to the firewall blocking Ajax requests. The customer contacted their host to whitelist the necessary URLs, which allowed them to enable and disable custom code successfully. However, the issue persisted when making changes to the search and pagination section in a view. As a workaround, we moved the CSS from the Search and Pagination section to the Loop CSS, and the problem was resolved, allowing the customer to save the changes correctly.
The customer was trying to display translated content with the same content template layout as the original language for a custom post type called 'events'. However, the content template ('CT for events') was not being saved for the translations, and it kept reverting to 'Template Dynamically Assigned…', causing the front-end display to be incorrect.
Solution:
We instructed the customer to manually assign the content template for the translated events. The solution involved:
- Navigating to Toolset > Content Templates.
- Editing the content template for Events in English.
- Switching to the Dutch language in the admin top bar.
- Selecting the custom post type (CPT) 'Event' in the content selection in the right sidebar and saving it. This procedure resolved the issue, ensuring that the correct content template was applied for the translations. The customer confirmed that the solution worked and planned to replicate it for other events.
