[Resolved] Types Set-up

[Author]

Posts

[CharlesB2907]

I'm working with Toolset for the first time and I have a few questions that I can not seem to find clarification for in your tutorials.

1. I created three new Custom Post Types: Paintings, Collage, and eCollage > Begining with eCollage from the Toolset Dashboard, I created a "Field Group" which lists Fields > that will be used in search form fields and listed in display results.

I assume that there will be two different "Forms" 1. for the admin to add new custom post type entries -and- a form on the front end of the site that can be used for entering search parameters.

Question: Are the Fields entered in the Post FIeld Group for display on the admin form for adding NEW eCollage posts -or- is the field group for display on the front end. See screenshots attached.

I know this might seem like an elementary question but as a beginner, I am having difficulty with setup clarity and I would greatly appreciate your help.

[Christian Cox]

Hi, thanks for trying out Toolset. I'll be glad to answer any questions.

I assume that there will be two different "Forms" 1. for the admin to add new custom post type entries -and- a form on the front end of the site that can be used for entering search parameters.
The form used to enter posts in the wp-admin area ( the "backend" ) will not be shown in this Dashboard display. Only forms created in the CRED plugin will display here. It is assumed that all public custom post types will have a backend post editor screen.

Question: Are the Fields entered in the Post FIeld Group for display on the admin form for adding NEW eCollage posts -or- is the field group for display on the front end.
In general, both of these are true. When you associate a field group with a specific Custom Post Type, the fields become visible in the post editor screen in wp-admin. You can add or remove information whenever the post is modified in wp-admin. After associating a field group with the custom post type (CPT), any CRED forms created for this CPT may include the custom field inputs as well. CRED form builders include an "Autogenerate" button, which will add all the necessary custom field inputs automatically. You can remove these fields from the CRED forms if you'd like, effectively limiting field changes to the backend of the site.

[CharlesB2907]

Thank you for providing this information. I am sure I will understand further as I proceed.

My concern about how the fields will be used pertaining to what will be required fields and what will not.

1. The admin form used for populating the content of New eCollage Pages could be marked as "Required" to ensure that all information is entered correctly.

2. However, we wouldn't want to require the front-end user performing a site search to have to enter a field if they chose to leave it blank.

Does this make sense?

[Christian Cox]

2. However, we wouldn't want to require the front-end user performing a site search to have to enter a field if they chose to leave it blank.
A CRED form and a custom search View are two different things, and I will try to clarify the difference for you.

A custom search View provides a way for your site Users to search for existing posts using a form with filters. Those filters can represent custom field values, taxonomy terms, post date, etc., many different criteria for each post. Posts that match the selected filters will be displayed in the results of the View. If you make the custom fields required in wp-admin, it does not mean your Users on the front-end will be required to choose values for those fields in the custom search View. The parameters for any search View are optional. Here is some more information about custom search Views with examples:
https://toolset.com/documentation/user-guides/front-page-filters/

A CRED form is a different kind of form. It does not allow your site Users to find existing posts by searching and filtering. It allows your site Users to create or modify posts or Users. If you make the fields required in wp-admin, they will also be required in corresponding CRED forms, because you would want to enforce similar rules on the front-end and back-end when posts or Users are created. Here's some more info about CRED:
https://toolset.com/documentation/user-guides/creating-cred-forms/

I hope this helps clear things up a bit.

[CharlesB2907]

The information you offered does provide more clarity for me. Thank you.

[CharlesB2907]

I would have preferred to keep this ticket open as it takes some additional time to experiment and practice the work-flow that you recommend. If there is no need to close the ticket quickly, I ask that it be left open until I fully process what you have already suggested.

Thank you.

[Christian Cox]

That's fine, I will mark the ticket as pending an update from you. No need to reply right now. The ticket will remain open for 30 days.

[CharlesB2907]

Thank you. I appreciate the flexibility. My ability to command the application of this resource has not yet evolved.

I am having great difficulty identifying what "Custom Post Types", "Taxonomy" "Fields" "Field Groups" and "Archives" that I need for a unique client site need. In this first (of what I hope will be many cases) pertains to an artist and cataloging and displaying three different types of work he produces: Paintings, Collages, and eCollages established as three partitioned portfolio groups of added artwork.

I need each of the three portfolios to display as a single portfolio as shown in the following links to the current three portfolios:

hidden link

hidden link

hidden link

All three links above show the current portfolios created as a "Projects" custom post type, each containing a static details page for each posted work of art in each of the three projects post types., Currently, there is no way to automate update changes that should reflect on all posts which now currently exceed beyond 900 total posts making such changes incomprehensible.

While studying your tutorials, I discovered that I might be confused as to what custom post types, taxonomy, and fields really are in my clients need referring to the attached screenshots.

Based on the note thus far in this support thread, can you please point me in the correct direction by identifying sample core Toolset custom post types, taxonomy, and fields elements I need for my particular case application?

[Christian Cox]

I think you would benefit from some basic information about WordPress and the URL structures it produces for a custom post type or taxonomy. In general, a custom post will have its own URL in the format:
@yoursite.com/post-type-slug/post-slug
If your custom post type slug is "project" and the project slug is "core-identity", the project URL will be
hidden link
This URL will be automatically created by WordPress. If you want to modify the design of this page, use a Content Template or Layout for the Project post type.

WordPress automatically generates a CPT (custom post type) post archive at this URL:
@yoursite.com/post-type-slug
So in your case it will be:
hidden link
This archive will include all projects, regardless of which portfolio they are in. If you want to modify this page, use a Toolset WordPress Archive assigned to the Project post type.

Taxonomies can be used to categorize posts. WordPress automatically generates taxonomy archives at URLs like this:
@yoursite.com/taxonomy-slug/term-slug
All posts that are associated with the term in the URL will be displayed here, regardless of their associated portfolio. If you want to modify this page, use a Toolset WordPress Archive assigned to this taxonomy.

As far as Custom Fields, I think you will create fields to store the additional information about each Project like Year, Dimension, Color, etc, as shown in the table here:
hidden link
WordPress does not create archives based on custom field values. If you need to show a list of Projects filtered by a Custom Field, you must use a filtered View on a Custom Page or other post.

As far as Field Groups, these are just arbitrary organization structures for custom fields. On the front-end of the site, you can't tell anything about Field Groups. The organization only applies in wp-admin. Field Groups are displayed separately on post editor screens. Based on the criteria I see on the individual project post now, I don't see a need to use multiple Field Groups. There isn't that much information to capture in wp-admin.

So with that information in mind, you could approach this in a few different ways. Here are two:
1. Create a new Post Type called "Portfolio" and make that post type a parent of the "Project" post type. Create 3 Portfolio posts that represent each of the 3 portfolio links you provided earlier, and assign the related child Project posts to each Portfolio. WordPress will automatically generate single Portfolio page URLs like @yoursite.com/portfolio/portfolio-1-slug, and you can use a Content Template or Layout to design this page. WordPress will also automatically generate an archive of all Portfolios at @yoursite.com/portfolio/. You can design this page with a WordPress Archive. This approach makes it easy to add new Portfolios in the future.

In order to see a group of Projects at this URL:
hidden link
You must create a View of Projects, filtered by Post Relationship, set by the current post, and add this View to a custom Page with the slug "2017-acrylic-on-canvas". Note the difference in URLs here:
hidden link
The first URL indicates a custom Page, while the second indicates a single Portfolio post's page. If the page URL structure currently in place on this site isn't necessary to repeat, you can drop the custom Page and link to the Portfolio single post URL instead.

2. Use a taxonomy to organize Projects into separate portfolios. Use 3 different terms to represent each portfolio. Apply the proper term to each Project. Create custom Pages for each portfolio. Create a View of Projects, filtered by Taxonomy term set by a shortcode attribute. Place this View of Projects in each Page or in a Content Template or Layout for Pages.

[CharlesB2907]

Thank you for the detailed feedback. To make sure I understand correctly, I need to clarify that the links that I provided are to a version of the client site that does not currently have Toolset plugins installed. It is a static site that I first created several years ago and it has since grown in post quantity.

It was created using Divi and adding individual "Project" posts for each piece of art. I discovered Toolset while searching for a way to add dynamic search and update automation to the site.

In regards to option #1 that you proposed, are you suggesting that I can install Toolset on the existing jayzerbe.com website and REPURPOSE the existing "Project" posts into Toolset managed posts that can be edited from a single Divi template(s)?

If this is true, creating the Portfolio post type is good, but it would be important for the client to have the type of art moted in the URL such as:

jayzerbe.com/portfolio/painting/title-of-artwork/

jayzerbe.com/portfolio/ecollage/title-of-artwork/

jayzerbe.com/portfolio/collage/title-of-artwork/

Would this same result be possible using the option 1 workflow?

I thought I had to rebuild the site from the ground up using Toolset protocol?

[CharlesB2907]

I thought I would share the attached screenshot which shows how the current "Project" posts are set-up. Please, note that in the current set-up, Paintings, collage, and ecollage are established as "Catagories" and each new project post is linked to one of the three.

[Christian Cox]

In regards to option #1 that you proposed, are you suggesting that I can install Toolset on the existing jayzerbe.com website and REPURPOSE the existing "Project" posts into Toolset managed posts that can be edited from a single Divi template(s)?
I didn't intend to suggest anything about migrating existing site data or extending the existing site. I intended to provide general information for you to consider about how WordPress handles custom posts, their URLs, and their archive URLs, and how Toolset fits into that picture. The instructions I gave could be applied to an existing site as well as a new site. You could use Divi Projects instead of creating a new Projects CPT in Toolset. The URL information I provided before still applies.

If this is true, creating the Portfolio post type is good, but it would be important for the client to have the type of art moted in the URL such as:
jayzerbe.com/portfolio/painting/title-of-artwork/
This structure isn't offered because it combines a portfolio slug (painting) and a project slug (title-of-artwork). This type of hierarchical post permalink structure is not offered for custom post types. The links jayzerbe.com/portfolio/painting and jayzerbe.com/project/title-of-artwork will be provided by WordPress, but not in a hierarchical directory combination. WordPress expects all URLs in the /portfolio directory to be Portfolio posts, not Project posts.

[CharlesB2907]

Instead of using "Portfolio" would it be possible to successfully create all three product groups (paintings, collages, and ecollages) as custom post types each followed by the 'Title" of the post added to either post type group such as:

jayzerbe.com/ecollage/ecollage-post-title

I have 800 +/- project posts in the current site that I would like to not have to recreate, but it's more important that I have a robust search and update capacity.

I appreciate your support. I want to select the correct structure.

[Christian Cox]

Yes, it is certainly possible to have a different post type per portfolio. When you want to add a new Portfolio, you must create a new post type. Please be aware that Views does not offer a built-in way for Users to filter a custom search View by post type. More robust filtering is possible for post content, taxonomies and custom field values.

[CharlesB2907]

"Please be aware that Views does not offer a built-in way for Users to filter a custom search View by post type"

Is this the reason why you recommended jayzerbe.com/portfolio/ecollage ?

Can it be jayzerbe.com/portfolio/ecollage/title ?

Would the site visitor be able to select between Painting, Collage, and eCollage from the search form if "Portfolio" was the custom post type and Painting, Collage, and eCollage were grouped as fields?

I had planned to use the Select field type.

The visitor must be able to search between three, any two or all three