Skip Navigation

[Resolved] Dynamic ID per post type?

This support ticket is created 7 years, 1 month 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
8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 - -
13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 - -

Supporter timezone: America/New_York (GMT-04:00)

This topic contains 4 replies, has 2 voices.

Last updated by Christian Cox 7 years, 1 month ago.

Assisted by: Christian Cox.

Author
Posts
#578748

Hi,

I'm trying to create some sort of database on my site. For that purpose I would like to incorporate the use of dynamic IDs early-on, and would like to ask for your assistance with that.
Basically, I have several post types, and would like each of the types to count their posts with separate numbering.
For example, I have the "anime" type and would like for posts in it to be counted with "aid=x" while characters would be marked with "cid=x".
If possible I'd also like for this id to appear at the url for each post, but it's mostly important for me to be able to easily refer to each entry in the database later using views. The best example for a website that already sorts its posts in a similar way would be animenewsnetwork.com .

Help would be highly appreciated.
Kind regards,
Amos

#578849

Basically, I have several post types, and would like each of the types to count their posts with separate numbering.
Okay I'm not quite clear on the separate numbering. Can you explain how or why a unique ID for each post, regardless of whether it's an anime or character, is not appropriate? This will help me understand how to best implement this feature.

If possible I'd also like for this id to appear at the url for each post
There are different ways you can handle the URL for each post. By default, WordPress creates a URL for each post following a standard template, usually post-type-slug/post-slug. So for example if your Anime post had a slug of 12345, then the URL would be yoursite.com/anime/12345. Note that this "slug" is generally derived from the post title, so you would have to name each post using a unique ID, or come up with a way to do this programmatically. This URL template is the default behavior of WordPress, but you can turn it off if you'd like and remove the default URL to require something like the next option.

With Views, you also have the option of using a generic, standard URL with a URL parameter that indicates the ID of the post you want to show. So you could have a custom page set up like yoursite.com/animeDetails, and add a View to this page that accepts a URL parameter as a post ID filter, like yoursite.com/animeDetails?animeID=12345. When you access this URL, the View would show information related to the Anime with ID 12345. In this case, the ID has nothing to do with the title of the Anime post. Also the name of the variable (in this case animeID) is arbitrary, and can be defined however you choose.

...but it's mostly important for me to be able to easily refer to each entry in the database later using views.
I'm not quite clear on what you mean here. Views can filter by post ID, post Type, and many other data sources. So generally you don't need to know much about the data in the database, you just need to know which criteria you want to use as a filter, and Views will handle translating that into a database query. Please let me know if I have misunderstood your request here, and I will be glad to offer more information.

#578898

Thank you for the prompt response Christian.

ID separation would make the database management easier in the future in case I would like to export it to separate SQL databases in the future for use with external clients. Other well known databases in the field such as anidb.net , vndb.net and myanimelist.net all separate their entries IDs by category, so I thought I'd do the same. Hope that makes sense.
(example- ANN:
hidden link
hidden link

Your suggestion about using views sounds like the result that I'd want, as ideally people would go to:
isrataku.com/Encyclopedia?animeID=12345
and get information about anime 12345
meanwhile if they'd go to
isrataku.com/Encyclopedia?charID=12345
they'd get information about character 12345.
Any suggestions on how to achieve that?

Meanwhile, I'd also like to be able to refer to the ID field of database entries in separate posts in order to extract information about them.
For example, while writing a news article related to a certain anime entry, inserting [view type that extracts 'description' based on animeID] into the post would add a description paragraph to the article. While I -could- use slugs instead, slugs can and might change while IDs should stay permanent.
(I know of a different site that had a problem when two entries had the same slug because the difference in their titles was just a hyphen)
For that purpose the separate IDs are also crucial

Thanks again,
Amos

#579080

Any suggestions on how to achieve that?
Unfortunately WordPress is designed in such a way that unique IDs are created for each post, regardless of post type. There's not a good way to overcome this feature of WordPress that I'm aware of. The core functionality of the WordPress system is built around unique IDs for each post, regardless of post type. You're going to have to do some extra work to accomplish what you want, and it will require custom code. The only way I can think of is to apply a custom post field to all post types that stores an "ID" number, separate from the actual WordPress post ID. How you populate that "ID" number for each post is the problem. It seems like the ideal way would be programmatic. When a new post is created, the system queries all the other posts in that post type for their "ID" number, and returns the highest one. Then it increments that number and assigns that number to the new post as "ID" number, automatically. Then you can filter Views by that custom field to retrieve information about a specific post.

If all posts are created by CRED, then you can use a cred_save_data hook to perform these processes:
https://toolset.com/documentation/programmer-reference/cred-api/#cred_save_data

If posts are created in wp-admin as well, then you probably need to look into the WordPress save_post() API: https://codex.wordpress.org/Plugin_API/Action_Reference/save_posthttps://codex.wordpress.org/Plugin_API/Action_Reference/save_post

ID separation would make the database management easier in the future in case I would like to export it to separate SQL databases in the future for use with external clients.
WordPress stores all posts in the same wp_posts table in the database, regardless of post type. It stores a Post Type identifier along with each post (in the same row in the wp_posts table, no joins are necessary), so you would be able to filter the query and retrieve WordPress IDs by post type very easily.

Meanwhile, I'd also like to be able to refer to the ID field of database entries in separate posts in order to extract information about them...For that purpose the separate IDs are also crucial
Well then I would think that unique IDs across all posts would be preferable here. Otherwise, you need two filters instead of just one to query each "linked" post. You need to know the type of post as well as the "ID" number. If the IDs are unique across all posts, then you only need one filter.

Other well known databases in the field such as anidb.net , vndb.net and myanimelist.net all separate their entries IDs by category, so I thought I'd do the same. Hope that makes sense.
Okay sure, I can understand the desire to be similar to the rest of the ecosystem. Just want to be sure you're aware of the limitations I've mentioned here and the extra work that will need to be undertaken to pull this off.

It looks like you marked this ticket resolved, so I will reopen it. We can continue discussion if you'd like, or you can mark the ticket as resolved if you have the information you need.

#579170

Marking the ticket reopened, pending an update from the user.