Hi, thanks for trying out Toolset! I'll give you some general overview answers here. Our support policy is to address one concern per ticket, so if you need more details about any of these general overview answers I can split out separate threads to address each one independently. This helps keep the forum organized and makes it easier to find answers to similar questions by searching the forum for keywords.
What bare minimum starter theme would you recommend?
Astra, Ocean, GeneratePress, and Woodmart are the themes we usually recommend. If you plan to use Bootstrap and your own custom CSS extensively, a Bootstrap 4 Starter theme would be worth checking out, too. Offhand, I'm not sure if CSS resets are included in any of these, but you could easily enqueue one in a child theme.
- If I'm going to create an archive page, ie. archive-podcast.php that loads header-negative.php what will happen if I also create an archive page inside Toolset? Will Toolset overwrite the PHP file in theme folder? If so, how can I load a different header on certain archives or pages?
Toolset does not overwrite theme PHP templates, but works in conjunction with them. In WordPress Archives, Toolset replaces everything you would normally see in the loop of posts. If you are using WP's PHP conditional tags like is_archive in your archive template files to include different headers, that should be fine and will continue to work as expected. The same is true in single post templates. For single post templates, Toolset hooks into the_content() and replaces everything typically output there with the Content Template applied to that post. If your theme does not utilize the_content() in its single post templates, it's best if it uses one single function that Toolset can hook into. You can then customize the CT hook to register that function. See these related docs:
https://toolset.com/documentation/programmer-reference/theme-support-for-content-templates/
https://toolset.com/course-lesson/creating-templates-to-display-custom-posts/
How does Toolset define post types and all data structures? Is it some in-house developed method or are posts and custom fields saved in database using standard WordPress methods?
We use a few proprietary implementations, but mostly WP standards-based implementations. Custom post types are implemented using the standard register_post_type function, and custom taxonomies are implemented using the standard register_taxonomy function. Setups for those are stored in the options table. Custom posts and custom taxonomy terms are implemented using WP standards for custom posts and custom taxonomy terms.
Custom field values are almost always saved in the database in the postmeta table using standard WordPress methods like add_post_meta and update_post_meta, and can be accessed using standards like get_post_meta. The main exceptions to the standards rules are custom date fields, custom post reference fields, and custom checkboxes group fields. Types field slugs use a wpcf- prefix in the DB, but that prefix is not displayed in wp-admin or required for Toolset shortcodes. Fields that allow multiple values (a.k.a. repeating fields) are stored as multiple entries in postmeta for the same post, using the same postmeta key. Repeatable Field Groups (RFGs) are technically implemented like posts with custom fields in each row iteration, using a one-to-many post relationship between the parent post and each individual row of the RFG, and a one-to-many relationship between each row of RFG and its own nested RFGs. Date fields are stored in Unix timestamp format. Checkbox group fields store data in serialized format, like checkbox groups. Checkbox group fields, date fields, RFGs, and post reference fields are usually not straightforward to migrate to other platforms. Dates usually require conversion using a small code snippet or something similar. Checkboxes group fields are not so simple, and may or may not be possible to migrate. Whenever possible, I would try to use a taxonomy instead of a checkboxes field group. Post relationships are handled with proprietary tables in the database, and are probably not easily migrated to other platforms. Post reference custom fields are handled like post relationships, not like postmeta values.
I've seen that there is a conditional block available - I'm assuming that I can add a section in single view and display it only if custom fields have data.
Keep in mind that the word "view" has specific connotations in this software, so the terminology is important. If you want to display content conditionally in the Content Template applied to a single post, you can use a conditional block that tests the value of a specific custom field. Or the conditional criteria could be more complex, like testing if the field exists and is greater than 10, for example. Or that two specific custom fields are both not empty, and so on. The conditional block works by nesting other content blocks. Any content nested inside the conditional block will be displayed if the conditions you define are met by the current post being displayed with the template.
However, I'd like to have a simple UL menu on the left of the page with direct links to sections on the page. Is it possible to also display only the links to sections that actually exist on this particular page? If yes, how? With conditional block?
Sure, you could probably do this with conditional blocks that tests whether or not there is content to display. The specifics here depend on how you store books in the podcast post. Is a book a custom post in a separate post type, linked to the podcast post by post relationship? If so, then you may not need a conditional block. You might be able to use a View instead, and include the links in the View results. If Books are stored as repeatable field groups (RFGs) in the podcast post, the solution would be similar because RFGs are technically implemented as custom posts linked to their parent post using a post relationship. On the other hand if Books are stored as repeating custom field values or some other custom field type, then you cannot use a View because Views are not designed to loop over custom fields (i.e. fields that exist outside of RFGs). You would use a conditional block in this case and then output the custom field content using other blocks or shortcodes.
