Is it possible to create a product page template for or as a custom post type?
I would like to place a Buy button on the Product page created with Divi and identify the page as a custom post type and not a "Product" in the display URL.
Is this possible with Toolset, Divi Builder, and the Toolset Woocommerce Views plugin?
I have read and re-read your question several times and I'm afraid I don't understand it.
Products are a post type and when displaying a product post (individually or as part of a loop) you can include an Add to cart button to buy that product.
You can change the URL for displaying single products from the default site.com/product/product-name/ in Settings > Permalinks in the Product permalinks section.
The product archive is handled differently by WooCommerce. A custom post archive is normally shown at the slug of the post type, which would be site.com/product/, but WooCommerce instead displays the product archive on an actual static page, which by default is called "shop". You can choose a different page to display the archive on.
Can you try again explaining what you are aiming for?
Thank you for responding. I am still at the beginning of the Toolset learning curve but I have been using Divi for several years.
My first Toolset development is centered around three custom-post-types (paintings, ecollage, and collage) that all posts would be based on. It was my plan to place "Add To Cart" buttons on each of the three. My goal was to have this button link to a checkout page using Stripe as the merchant gateway. The URL I am seeking is: hidden link which would have an "Add To Cart" button on it that can send the page item to checkout.
Here is a link to the template page for each of the three desired post types: hidden link
The template is titled "profile template" and linked to the three CPTs' listed above. If possible, I would really prefer not to use the term "product" on this an related client projects.
It is a limitation of WooCommerce that there is only one post type for products, and it must have a slug of 'product'.
There is a filter available to override how WooCommerce registers the product post type, so that you can give it a different name (e.g. "Artworks") which is what will appear in the menus etc. But it will always have the slug "product", though as described before you can change the permalink settings to that it uses "artwork" in the URL instead of "product", for example.
I couldn't find any documentation for taking over registration of the post type with your own settings, but it is described in this Stack Overflow answer here: https://stackoverflow.com/a/26717214/1180189
That still leaves you with just one product post type. I used the generic "artwork" in the example above, which you could use and then add categories to distinguish between paintings, ecollage, and collage.
1. For this first project, I created three custom post types paintings, ecolloage, and collage. Instead of three, I should have just one such as "artwork" and add the individual departments as categories, is this correct?
2. Even though woocommerce has it's own CPT which is "product", I can change the permalink settings in the site admin to display the CPT in the URL as "artwork", is this correct?
3. Will one of the three "artwork" categories appear in the slug at all?
1. Yes. You can only have one purchasable post type within WooCommerce.
2. Yes, although if you also want to change things like the back-end menus to display "Artwork" instead of "Product" you would have to use the filter described in the previous reply to register the product custom post type with different labels.
3. Because of 2 single products will display at a URL such as site.com/artwork/self-portrait/. The categories won't appear in the URL for individual artworks, but will appear in category archives (i.e. lists of "painting" products etc.). By default they would be displayed with a URL like site.com/product-category/painting but you can change "product-category" for some other text in the "optional" section of the permalinks settings page.
If I were using the "Product" CPT for woocommerce integration, can additional CPTs' still be used on the same site but outside of the woocommerce CPT workflow?
For example: A post type for "ecollage" as part of the Toolset site search structure with a button link to a woocommerce "Product" CPT Shop Page for the final purchase process.
The WooCommerce product post type and other post types on your site are independent of each other, you can have as many other post types registered on the same site as you like.
But only one post type can be added to the WooCommerce cart and bought, namely products.
What you are suggesting—linking posts of different types to products which are actually bought—might make sense if, for example, all paintings cost $499 and you have one painting product with that price that includes a reference to the specific "painting post" that originated the purchase. But if each of your paintings is unique and individually priced then you would have to have duplicate products for every painting post, every collage post, etc., which seems very much redundant.
Although products are a WooCommerce post type, you can still do things that you would with a normal post type, such as add custom fields and custom taxonomies, and then display these according to your own design using a Content Template.
Thank you for the additional information. We felt there would be user recognition and SEO benefits in having the actual category in the URL and wanted to remain on that path, if possible.
There will surely be different price points involved. I do not want a site that is file-heavy and slow in performance. Would the following work-flow be possible and not too unreasonable?
When the site admin uses the front-end form to post a new element, can there be a field option that if selected, would create a "detail display" and a "product summary display" (chosen only if the item is for sale), using the same content
The "detail" display with non-woocommerce CPT would contain a "featured image, description, and price, with ALL page attributes.
The "summary" display for "Product or Artwork" CPT would only contain the featured image, description, and price for final consumer confirmation prior to checking-out.
If this is possible, and not complicated for a new Toolset user to build, I would like to try to maintain the structure of having the category in the slug.
However, if you don't fancy dipping into writing the code to do that you can use a plugin to achieve the same. I searched and found a bunch of plugins that promise this.
I quickly tested Simple Post Type Permalinks (https://wordpress.org/plugins/simple-post-type-permalinks/) and even though they didn't list %category% as a possible placeholder, in testing I found it worked. See my screenshot for the permalink settings.
Note it works with standard categories (which are available to products). I'm not sure it would work with the WooCommerce product categories, so I suggest you stick to the former.
Unfortunately, writing code is outside of my current capacity and therefore not an option.
I would have preferred to follow the Detail and Summary pages set-up that I proposed if it had been possible. If it is not, I will have no choice but to attempt to use a plugin, which seems problematic over the long term.
I appreciate your assistance and option recommendation.
Can I ask, is the Detail and Summary pages based on different post types entirely illogical or in some way, possibly problematic now or over the long-term in regards to scaling and management?
I have given this matter a great deal of consideration and I would like to build the site with three primary post-types 1. paintings, 2. ecollage, and 3. collage for site posts, and use the default WooCommerce Products post-type for a pre-check-out summery post for buyer confirmation before sending it to Cart.
The search post result pages will be based on one of the three general types using a template containing a button module that can trigger a "Product" summary post for the specific post title from where it was triggered.... If this makes sense.
I would greatly appreciate any focused pro/con feedback that you may have for this particular workflow, as I work in this direction.
