Skip Navigation

[Resolved] Using CPT to add extra metadata to WooCommerce orders/customers

This support ticket is created 5 years, 5 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
- - 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00
- - - - - - -

Supporter timezone: Asia/Ho_Chi_Minh (GMT+07:00)

This topic contains 5 replies, has 2 voices.

Last updated by Beda 5 years, 5 months ago.

Assisted by: Beda.

Author
Posts
#1274839

Tell us what you are trying to do? Hey guys, new customer here, glad to join the Toolset family after keeping an eye on your plugin for a while now. I've overheard that the team over at X-Theme / Pro (Apex) are working in integrating Toolset directly into X/Pro so I decided to go ahead and start playing around with your solution. We are looking to add a metabox in WooCommerce Order back-end where admins can select from existing data or enter new data that will be used to generate documentation automatically (Purchase orders, Packing lists, etc.). We make custom products and we want to build an archive of all the products we create, along with the documentation and design files required to create these custom products. Each design needs to be indexed for easy search. I think that using a CPT for the design may be ideal. We need to attribute a creator ID (similar to customer ID) so that we can lookup, for example, all custom designs made by a specific creator. Designs data may be re-used on the front-end directly by creator to submit and create products. Toolset seemed like an ideal solution for this.

Is there any documentation that you are following? No, except for the documentation provided by Metabox (hidden link).

Is there a similar example that we can see? Not that we're aware of.

What is the link to your site? Are these tickets public and indexed? We don't want to share this kind of information publicly.

Just looking for general information for now, nothing too specific or technical. With the information I provided, do you think our approach makes sense?

Thank you!

#1274879

Hello Bastien, nice to have you on board.
Do you have a blog post or something the like pointing out integration to XTheme of Toolset?
I am not aware of this, at least, I do hear the first time that XTheme plans to integrate Toolset! This is good news, of course 🙂

For your goal, you could try several approaches, I think a Post Relationship could help.
Create a "Design" post type and connect (create a relationship) to Orders.
Then, when creating Orders you can either add new Design Posts or connect to existing.

Later, in Views, you can display orders and their related Designs or just Designs and filter that data by several details, such as Custom Fields (where the Creator ID, for example, could be stored).

I'd suggest a staging site where you add such new Custom Post Type and relation to first test out if this setup helps you achieving the goal

#1275039

Hey Beda,

Thanks for the quick reply.

I couldn't find the exact post where I read about X/Toolset but I know that they have started an extensive work to integrate dynamic data into Cornerstone since March 2019 with v2.5.0. I'm not sure if you'll be able to access this, but there's some info about Toolset in their changelog here: hidden link

We now can easily pull any metadata from Toolset directly while building pages with Cornerstone. When I spoke to some X staff if I recall well they mentioned Toolset when I needed to edit archive pages that Cornerstone currently doesn't support. Basically, they were improving Cornerstone with Toolset to be able to modify archive page and create custom layout for custom post types. I may have understood wrong, but the fact Toolset was on their radar since v2.5.0 makes me think I'm not hallucinating about this conversation.

I appreciate your suggestion regarding the way to go about achieving what we want with WooCommerce. We'll definitely start off by testing on our staging site first.

I'll be in touch with I start playing around with this and if I have any questions.

Have a great weekend!

All best,
B

#1275041

Oh just a quick question, performance-wise, has Toolset or any of the other add-ons any kind of performance impact on the front-end of our site?

If we handle the display of the CPT and metadata via custom functions on the front-end, could Toolset be entirely disabled on the front-end without any adverse effect? We have a plugin (Plugin Organizer) where we rigorously optimize all pages to load only the strict minimum amount of plugin and we tend to deactivate all plugins that provide admin-only features (back-end).

Thank you!

#1275043

PPS: Are tickets public and indexed by search engines or we can share sensitive information?

#1276357

The Toolset Support Forum is public for anyone to read, but only for members to post and comment.
Private replies are private and can be seen or read only by the provider of the data, as well as the Support Team members.

Related to X's integration with Toolset, I read the changelog, indeed there is some nice movement there, I see.
I forwarded this to my Team leader just in case we are not aware of this at the developer level, maybe we can work together or help each other, great that you shared this with me.

Now, performance wise, I'd love to say no, however that wouldn't be entirely true. Every software adds a bit to the load, Toolset can add a lot if you have for example very complex, and nested into each other Views (which then, in fact, are many nested Queries).
Here, due to the fact that we are using the WP Query which hits only one Database Post Table, things can become slow as said on large views, or nested views.
In this case, the slowdown can be remarkably and you would have to break down the queries results with some pagination to solve this.

Another thing to consider is, Toolset brings a whole lot of features but they are made with Code 🙂
And code sometimes relies on other code, etc, in other words, Toolset may appear to enqueue a whole lot of Scripts and Styles in the front end (for tools like GTMetrix this is a red flag often), and it may seem unnecessary.
However we try to assure we load our scripts only where and when needed if possible, sometimes due to the features it's just not possible (such as a view's AJAX features, for example, need code to be present on a page before we even know what View you load, hence we load it everywhere.
This is not something that you will notice but tools like GTMetrix might complain.
Note, here we are not speaking of slowdowns that you should notice as visitors of a page. This are merely technical measurement differences and issues you may stumble on when working with Toolset.

You can, of course, display all your content (even if created with Toolset) using Code, but that will not really save a lot in performance if any.

Hope it's clear, please let me know if not!