The customer wanted to make a grid view on their website's tenders page more mobile-friendly. The desktop view looked good, but the mobile view was not user-friendly. The customer preferred the text to appear directly below the headings for each column on mobile devices.
Solution:
After reviewing the setup, we identified that the grid view was already responsive. To improve the mobile display, we suggested placing the headings and their corresponding text within the same parent block instead of using separate blocks for each element. This adjustment ensured the text appeared directly below the headings on mobile devices. We also recommended updating the padding and margins to achieve the desired look. The customer confirmed that the solution worked perfectly.
The customer wanted to enable users to filter archives on their website hosting academic texts, similar to how search results can be filtered. The customer specified that they needed the ability to filter texts by various criteria like publication year and language when viewing a specific category of texts. While they could easily set this up in a search view, they were unsure how to implement it in an archive view.
Solution:
We guided the customer to utilize the "Screen Options" tab available when editing the archive. By expanding this tab, they could enable search sections that are typically used when editing a View. This feature had been previously introduced in a pop-up when they first created a custom archive, which they may have dismissed.
The customer was advised to explore these options to achieve the desired filtering functionality for their archives.
The customer was attempting to upgrade their website to PHP 8.1 but encountered a fatal error that disappeared when Toolset Views was disabled. The error prevented the homepage from displaying images and text properly.
Solution:
After investigating, it was determined that the error was related to a specific line in a Toolset View, particularly concerning the sm-homepage-image field. Testing on a minimal setup confirmed that the issue persisted even with only Toolset plugins enabled.
Further investigation revealed that switching to a different theme caused additional errors due to an undefined function (create_function()) in the custom functions file of the theme. The customer was advised to back up the custom-functions.php file before switching themes to avoid losing custom settings.
The root cause was identified as a custom uploads location on the server, which led to an error within the Toolset plugin. A temporary workaround was implemented by modifying the Attachments.php file in the Toolset Blocks plugin, allowing the site to function correctly again.
The customer was informed that this fix would be included in an upcoming Toolset version, but they might need to reapply the workaround after future updates until the official fix is released.
The customer reported an issue where the navigation on a page wasn't functioning correctly when the user was not logged in. The problem was traced to a lock icon appearing on the 'rating' field when users were not logged in. This lock was initially thought to be added via Toolset settings, but it was later discovered to be caused by a third-party plugin called "Restrict Content" by StellarWP.
Solution:
After identifying that the lock icons were being added by the "Restrict Content" plugin, we suggested temporarily disabling the plugin to confirm that it was the cause of the issue. The customer confirmed that the issue disappeared when the plugin was disabled. Since the plugin caused the issue, we recommended contacting its support team for further assistance. As a workaround, we provided a custom CSS code snippet to hide the lock icons from the outside of the table, allowing the page to function correctly even with the plugin enabled:
The customer is experiencing an issue on their portfolio page where the hover image is not displaying correctly. Instead of appearing over the tile-image-logo on hover, it appears below it. The images were added using image blocks with dynamic sources and dynamic links, and custom CSS was applied to create a hover effect.
Solution:
We suggested using a different approach for implementing the hover effect in WordPress, given that the example provided by the customer used a different page builder. We provided a demo created with Toolset to illustrate a similar hover effect using two custom fields for the images. The solution involved using specific CSS classes (front-image and back-image) to control the visibility of the images on hover. The CSS was applied directly to the page using an HTML block to achieve the desired effect:
In the output of the View the back image is added first and the front image second (so the front image will cover the back image).
Please note that for this hover effect to work, the CSS targets the front image using a specific class ('front-image'), which you need to add in the View settings (please check the screenshot bellow).
