Skip Navigation

[Resolved] Optimization

This support ticket is created 6 years, 3 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
- 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 -
- 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 -

Supporter timezone: Europe/London (GMT+00:00)

Tagged: 

This topic contains 4 replies, has 2 voices.

Last updated by Ljuba 6 years, 3 months ago.

Assisted by: Nigel.

Author
Posts
#1077117

==> Tell us what you are trying to do?

As 'skeleton' is done on most complicated post type(s) (others are reduced and with same structure, as well with most of the fields) It's the time to starting 'rewriting' the project from scratch. So, just couple of questions (no need to extend replies) and all within same topic subject:

1) RFG vs child posts I found some issues with RFG and as far as I know, there is also a lot of thinks to do to place it in some 'regular usability'. Plus, fact that they can't be used in multiple parent posts, there is obviously no question about the choice. However, here is question about very simple group of fields - So, is it worth or not to use RFG?

2) PAGE BUILDERS I decided to drop [age builders (at least from Toolset functionalities) and to do all with Content Templates (Bootstrap). It should to significantly reduce number of Templates/Views or not?

3) FIELDS Is it smart to 'pull' fields values from taxonomies?

[EXPLANATION] Example of credit cards. They could be (and will be) used in different ways. As in-place payment, online payments > fields like purpose => but ==> I would like to enable also filtration per availability of CC. So, it looks much easier to list all CC as taxonomy (wit atributes as image, description, ...) and to call from fields available values for selection (it is maybe wrong explained in English - hopefully you understand).

4) Any other idea for optimization (you know what I doing)?

#1077488

Nigel
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+00:00)

1. RFG vs child posts

They are so similar under the hood that it really is very much a personal preference.

Right now the UI for adding RFGs in the backend is pretty nice, but on the front end you have to use the equivalent of CRED child post forms for each group of repeatable fields, so there is not much to choose on that basis.

If you are likely to be creating related posts/RFGs programmatically, well, the relationships API documentation makes no mention of adding RFGs using the API.

2. I think there will be less overhead using Views Content Templates on their own rather than any other solution which combines some templating solution with inserting Toolset content (Types fields, Views, nested templates etc.).

The only real way to quantify this would be to use the Query Monitor plugin and try it on a version of the site that is built with a page builder + Toolset, versus a version of the site that is built just with Views Content Templates.

3. I think I understand. Imagine your starting point, and your destination, and what's involved getting there.

So if you are on a post and you want to display a field which is added to a taxonomy term which is assigned to the post, then you would you can display the field with the wpv-taxonomy-field shortcode, but the context for that is a taxonomy View, so you need to create a taxonomy View with a filter to return the right term for that post and output the term field and insert the View into the template for the post.

That's more overhead than simply storing a field directly on a post and retrieving the post meta for that post.

But if it doesn't make sense to store a custom field on the post, what's the alternative? Related posts? Then that is no better than the taxonomy solution.

4. Your templates are pretty complex and pull in quite a bit of info using different queries. The only thing that occurs to me is to try and avoid duplication of queries.

So if you have one query near the top of the page and the same query lower down the page, try to re-think the layout of the page so that you can use the query only once.

An example would be if you have nested Views, and you use the same "parent" query to create the context needed for a "child" query in more than one place, maybe they could be combined.

I don't know that you are actually doing that, it is just what comes to mind when you have so many queries and embedded templates within the same page, look for ways to avoid duplication.

#1077578

Thanks and just to try to get your point.

Did you wrote that in the case where I need filtration's, there is no better alternative than using taxonomy (so, it is worth to sacrifice more queries for taxonomy views), or I didn't get it?

#1078360

Nigel
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+00:00)

Where I talked about the advantages of taxonomies for performance it was for this particular scenario:

You have some posts that you want to add some meta information to which you can then use to filter a query for those posts.

For example, their colour.

The question is, do you add custom fields with the colour, or would it be better to use a taxonomy for colour?

In the situation where you have a query to "show me red posts", then taxonomies are optimised for such queries while custom fields are not.

#1078445

Thanks for clarification.