Images on the frontend were opening the media page even though the image link option had been set to “None”.
Solution:
The frontend content was not coming from the main WordPress editor. It was being loaded from a WYSIWYG custom field named editor, used by the View. The image links were still present in that custom field. After removing the link from the correct custom field, the frontend reflected the change. Future edits need to be made in that custom field, not in the main page content.
The customer wanted to replace a third-party plugin that registers a custom post type and taxonomies with Toolset, while keeping the existing content and managing it through Toolset.
Solution:
The recommendation was to remove the original PHP registration from the third-party plugin and recreate the custom post type in Toolset using the same slug. Existing posts would remain available as long as the slug stays the same. For custom fields, Toolset’s Post Field Control can be used to take over management of existing fields. It was also noted that some plugin-specific functionality may not be transferable and should be tested.
Custom fields assigned to a newly created Toolset Post Type were not showing in the WordPress editor when adding a new post of that Post Type.
Solution:
The issue was caused by a plugin conflict. After testing with a default theme and only Toolset plugins active, the customer confirmed that LiteSpeed Cache was causing the problem. Disabling or isolating that plugin resolved the issue.
