New major revision of GD Custom Posts And Taxonomies Tools Pro is coming soon and includes some very important features that will require a bit of testing before released. So, here is the Beta version to test brand new rewriting rules and permalinks expanding for custom post types.
The biggest problem with current permalinks rewriting in WordPress is that custom post types can have only one permalinks structure that is practically hardcoded and can’t be changed in any useful way, it can contain only post type name and post name. So, new version of the plugin will change that and will allow you to create any permalink structure you want, similar to default posts in WordPress now.
These new settings are added to Advanced tab for each custom post type. First option will activate support for intersection for archive of post types and taxonomies. For instance, if you have custom post type document, and taxonomy attached to it product. By default, archive URL for custom post type would look like this (can be different based on post type settings):
But, if you want to filter posts in that post type by the taxonomy term, URL can look like this once you activate taxonomy intersections. This will get all posts for document post type that have plugin term in product taxonomy. New structure supports feed and paging, just like normal archives.
Other major change is single post permalinks for custom post types. Right now a single post link for custom post type document will always have structure like this: document/%post_name%. You can change document part to something else, but that’s it. If you want to include taxonomy, or author, or date you can’t do it. So, now this also changes, and for each post type you can specify the custom structure that can include all those things. On the image above you have how the example structure can look like and what you an use.
There will be more changes in new version, but these are most important, and it would be great to test them before rolling out stable 3.2 version. Right now, permalinks rewriting works fine, but it’s not tested enough so I can’t recommend using this live until 3.2 is released. Please, report any problems with this new rewriting methods in the comments or forum.
More about GD Custom Posts And Taxonomies Tools:
8 thoughts on “GD Custom Posts And Taxonomies Tools 3.2 Pro: Beta #1”
Thanks for the update. I know this change was based on my feedback so thanks for the update.
I installed the update and looks like the re-write rule perfectly!…. but when I go to see the page I get a 404 error. Is there some other setting I need to set?
the example I have is “hotels”
it rewrites correctly to: XXX.com/hotels/category/hotelname but then I get 404… Any thoughts or things to test?
It might be that category is the issue. I did tests with the custom taxonomies only so far, and that was OK. I will check this also.
To make it work you must use %hotel% instead of %postname% (I assume you did that). WP needs to be able to identify the post type in the URL, and if you use postname, that always falls back to post, not custom post type. There will be no way around it. New Beta #2 will have updated shortcode tags for each individual post type so that all this will be avoided.
I used /hotels/%category%/%hotel% and the URL worked perfect! Great job!……
I do have to figure out the best way to custom fields.
New Beta #2 is coming tonight, and it will have better info on how to use it, and it will have new tag for ID (%post_id% works only for real posts, not custom post types).
Custom fields can be part of the URL, but that will slow down the request parsing, since the process of matching will be much more complex and will take several more queries. Also, methods I used for current new rewriting are really part of WP (well, 80% WP, 20% plugin), but for custom fields in URL, plugin will need to do 90% of work, and in the end it will not be good, since custom fields are not really made for this.
Actually Custom fields comment was just for the actual page not on the URL. I want to enforce filling in Custom fields on pages.
You want to allow page editor saving only if custom fields are filled?
Yes, make a field required before saving… or at least a prompt to remind that it is recommended to complete certain field(s)/meta before saving – like WP’s Proofreader prompt before posting.
Comments are closed.