Skip Navigation

[Resolved] Managing 1 000+ custom post types, views, content templates

This support ticket is created 6 years, 4 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 3 replies, has 2 voices.

Last updated by Beda 6 years, 4 months ago.

Assisted by: Beda.

Author
Posts
#1114472

I should have to manage large amount of Toolset entities like custom post types, views, content templates etc. but it is very inconvenient.
I think allowing pagination, searching and filtering for these entities homepage
(like Dashboard > Post Types ( or Views or Content Templates )),
and for their edit pages' sections ( like Parent and Child CPTs, related taxonomies etc. ) would greatly improve their manageabilty.
Also, being able to show / hide columns of the listing pages would be a great help!

Thanks!

#1114840

I don't understand this request.

Can you please take some screenshots and draw on them what you imagine to change?

This would help to understand and formulate the request.

#1115101
Toolset Dashboard ‹ RKgs 180920_p1.png
Toolset Post Types list RKgs 180920_p2.png
Toolset Edit Post Type RKgs 180920_p3.png
Toolset Content Templates RKgs 180920_p4.png
Toolset Edit View RKgs 180920_p5.png

I supposed my suggestion was clear enough 🙂
but OK, pls., find screenshots attached.
These are just some examples, this pagination / search / filter feature might be useful also on another Toolset admin pages and / or on their sections.

#1115496

I understand, thanks

I have some feedback on the plans:

1. Hundreds of thousands of POSTS make sense, hundreds of thousands of Post TYPES make no sense, I would not do this.
It will probably make your site break at some point under a bottleneck in the database.

See, WordPress stores all Posts, of all kind, in the same table. Whatever Post Type your query, the WordPress database will get hit on the posts table only.
It is already tricky to have hundreds of thousands of single posts in there and query them fast enough, if you now load the database with hundreds of thousands of types that in turn can have as many posts you want, this may be too much for a WordPress install.

Suggested is, create as fewer Post Types as necessary, enrich their content with Fields and relate them either with Taxonomies or Post Relationships. Taxonomies of course as well can be used to further classify (that's actually sort of a relationship) content.

However, creating so many post types is not suggested.

I do of course understand your concerns about if someone does it, those screens you show me really are not anymore able to handle that, in the current state they are made (made for not so many Post Types)

2. Similarly, all other screens you mention and show precisely in the commented Screenshots you sent me, "suffer" (from this point of view) under the assumption that we usually will deal with a few Post types, more fields and terms.

Some of them are still Types 2.3 Version Screens (post relationships in post edit, which now is different). But in the newer versions, there is still the issue of Content Template screens, Views, etc.

I would say this is the first time I hear the concern, which does not mean it is an invalid concern, but unique and may be grown on a misunderstanding of the Posts Type Purpose, however, I am not sure if you need this maybe for a very specific purpose?

Can you outline the use case where someone would end up with hundreds of thousands of Post Types? (Even 20, is already a lot).
Maybe I can come up with some detailed information which can help to reorganize the content structure you have in mind.

Please let me know, I will meanwhile pass along the certainly valid, but unique (until now) concern you submitted.
I think we definitely can and should add some form of pagination, as we simply cannot base the software on the assumption no more than xy post types will ever be created.

Thank you for your kind cooperation!