custom post type problems needs addressed

Description

Upfront, archive-POST_TYPE.php does not always resolve correctly - But considering the whole scope of things > Custom Post Type support is lacking in general / and such would be easy enough to bring the wordpress core up to the task / INCLUDING WIDGETS

I see no impedance to updating the core as to create a sensitivity that could handle ALL aspects of custom post types, once created, as the core handles posts, pages, attachments, menus - everything is there - we just need to open it a slight bit wider...

IF (wp community is) open to this idea / and time enough for inclusion in 3.2 > I'll submit code as needed.

here's a small pseudo taste:

default widgets, like Categories, Tag Cloud, Calender, ETC. run check for none built_in post types - when present & compatible > widget presents new option as to which post types it is desired to be used for...

but for now - to be more precise:
currently, to work with custom post types, once registered a user needs to jump through hoop after hoop to get the custom post types to integrate properly with the public side of an install / all the way from template creation to navigation menus - where either coding is needed or extensive plugin hunting (along with trial-&-error testing)

what i am saying is:
it does not need to be like this - nor should it be like this...

specifically - ALL aspects of the default wordpress install can be set to AUTOMATICALLY handle ALL aspects of custom post types just as it currently handles built_in post-types / in the following manner

integrating into the core a mere test to first see if custom post types have been registered

then: if exist, set what features of built_in post types may logically apply to (be used for) the custom post type > is it like a Post, is it like a Page / should it be handled like a Post / should it be handled like a Page / is the taxonomy like categories / is the taxonomy like tags / and so on...

finally: open the features up that are for the built_in post types to also be directly used by custom post types which are set in such a way it calls for using such features > with the above tasks, each feature (widgets, templates, etc.) would "know" exactly which custom post type it can handle AND WHEN it should handle a custom post type (via request)

, , , , , , , , , , , , ,

sort of like that.

it should make more sense once i share some code tidbits - i'll submit a snippet once i've the time / should be within 24 hours (if not sooner)

, , , , , , , , , , , , ,

on a side note > why can't / or HOW CAN permalinks be automatically reset/updated/flushed (whatever) directly after a new post type has been registered ? - I played around with this but found nothing that could be coded which would dismiss the need to visit "Settings" > "Permalinks" --- an "auto-permalink-update" SHOULD be part of (the last part of) registering a custom post type.

You can't automatically flush rewrite rules after registering a new post type because post types are not stored persistently somewhere (such as in the database). Therefore, there's no way for WP to ask "hey, is this post type new?" and know the answer.

As for the rest of your proposal, you must have missed the initial discussion about post types: there's no point in using custom post types if they behave just like normal posts. You can just use categories and tags and post formats to group and style posts.

Therefore, I'm afraid this ticket will be closed as wontfix. Will wait to see your patch first.

post types do not need to be stored persistently to alleviate the need to visit "Settings" > "Permalinks" after registering a new custom post type - I did a quick test - in wp-includes/post.php within the "function register_post_type" I merely dropped (inserted) the following line :

i just did this / without much thought / but that single line there now makes it so that there is no need to visit "Settings" > "Permalinks" after registering a new custom post type - i'm sure some of you who know wordpress inside-out could figure out an even better way to do this - and i SUSPECT something like this for registering taxonomies might be good too (i don't know / i didn't test that yet)

, , , , , , , , , , , , ,

RE "Custom Post Type support is lacking in general" :

you state "there's no point in using custom post types if they behave just like normal posts" < very true - i know this, of course - BUT no matter how unique a custom post type is, chances are it will have certain aspects (and only "certain aspects") in common with built_in post types - and therefore can certainly utilize features already in place for such aspects...

I will (by tomorrow) submit a working example of alterations to the default categories widget...

where additional options for the handling of hierarchical taxonomy for custom post types ONLY kicks in IF :

FIRST > custom post types exist

AND SECOND > custom post types has taxonomy that is hierarchical

ELSE :
widget remains as current default / and option to use for "custom post type categories" will not be present

THE WIDGET will ILLUSTRATE what I am referring to - and hopefully serve as a jump off point to bring other built_in features already in place to function with aspects of custom post types > WHERE APPLICABLE

in other words, my little example SHOULD serve to illustrate functionality that is actually MUCH MUCH WIDER IN SCOPE

I did a quick test - in wp-includes/post.php within the "function register_post_type" I merely dropped (inserted) the following line :

$wp_rewrite->flush_rules(false);

That would mean that flush_rules() is called on every page load. flush_rules() exists because rewrite rules are cached, so that they don't have to be generated on every page load, since that can take a long time. I hope you see the contradiction.

so are you actually saying that the FUNCTION register_post_type is called on every page load ??? > AND that's how where i placed "$wp_rewrite->flush_rules" gets called on every page load...

OR are you saying somehow the area i placed that line gets called without actually calling the FUNCTION register_post_type ???

neither case makes sense to me - if you could explain what i might be missing, that might help - if not > i understand you're very busy...

I mean I figured what I did was not "right" or the best way to do it - but "called on every page load" - i'm sorry > but now i'm really lost (and so many of my years programming just flew out the window)

but if you can explain this to me, perhaps then you could also explain how while in the FUNCTION register_post_type the "$wp_rewrite->flush_rules" line would get called on every page load / BUT in the FUNCTION wp_delete_post and the FUNCTION _save_post_hook "$wp_rewrite->flush_rules" would not be called on every page load (both also in post.php) - ?

To be clear (precise), i have attached a plugin that illustrates how certain relevant aspects of custom post types and custom taxonomies could be integrated with existing default Wordpress features.

The attached plugin, or something like it (with improvements), is not actually intended to be a plugin - but rather introduces code that symbolizes how different areas of Wordpress could be updated to integrate certain aspects of custom post types and custom taxonomies, if exists, into default Wordpress operations. Also illustrated is how IF nothing new and/or relevant is registered THEN the Wordpress feature (in this case a widget) behaves as it does in default mode.

For ease of use / testing, in this particular example ("tax-categories-widget"), some naming conventions were changed (from the existing Categories widget) so as to work in parallel with the existing Categories widget - However, the code (in this example) actually is a proposal for updating the current Categories widget.

Also i did mention (a few comments back) i figured out how to "flush_rules" ONLY after the first time a new post type is registered - if interested i could share that too - i believe it would be fairly efficient ...

of course, being that post types are not actually "registered" (but instead "recognized") means that the method i submitted is not extremely efficient because such needs applied all the time / every call to "register_post_type" - but given that, the method is not all that bloated. (or maybe you'll inform me otherwise - so thx in advance)

here's a quick question - i am assuming $wp_post_types is also dynamic (not persistent) - it has to be, right - i can't see how it could not be...

. . . . . . . . . . .

on "Custom Post Type support is lacking in general" :

keep in mind the widget(s) examples is merely a small (very tiny) part of all that could be done - and here, on this stuff, i have given much more thought, than i have to the auto-flush stuff.

you should give it a spin > i've changed the naming conventions so it does not interfere with the default widgets.

I'm not saying such would not be better to introduced a new flag for widgets to register_post_type(), something like 'show_in_widgets' / that's up to you - i'm just saying my examples fully illustrate how you do NOT HAVE TO introduce a new flag like that...

I actually think for some things i have in mind perhaps a new argument/flag might be the way to go / but not necessarily for widgets

but for widget enhancements, i think the most involved would be Archives and Calendar - i believe the functions they call would need modifications to optionally handle custom post types

yeah - i think what you are saying about another flag for register_post_type / 'show_in_widgets' / for that functionality i was merely using 'public' => true

BUT now that i think about it, maybe i should be even more focused, and instead use 'publicly_queryable' => true

here's my thinking > ??? how and why ??? anyone would want a post type to be 'publicly_queryable' => true, BUT not want it in widgets I would have no idea

BUT > i don't need to have an idea why someone would want that --- BECAUSE IF they don't want to use the widget (as in my examples) then they don't have to use the widget for their post type(s) - they can leave the widget in its default settings - the option is their's

but boy oh boy - you got me wondering > i now think the thing to do is use 'publicly_queryable' instead of 'public' (like i did) - hmmm - looks like i gotta make version 0.4 ;)

it seems somebody somewhere knew i was going to come in and start doing what i'm doing - LOL

that (what i am doing / enhancing these widgets) seems to be the only reason for...

... ... ... && taxonomy_exists($instance['taxonomy'])

because the only thing the widget currently is used for is post tags and post categories / so if the widget was not waiting for me > then the question is > who would deactivate post categories --- hmmm / LOL

i fixed (reverted parts of) the Tag Cloud widget: so it properly selects default if it had been set to a custom tax that no longer exists

cleaned up some code to better adhere to the "wordpress way"

added the Pages widget

post type checks now use 'publicly_queryable' instead of 'public'

I didn't hit the Recent Comments widget like i wanted to - the kind of tweak i had in mind pulls it away from the current default settings - that is, once tweaked the way i had in mind, the Recent Comments widget would be forever enhanced and add features/settings/options which would always be there, regardless of whether costom port types were registered

also the Recent Comments tweaks i was thinking of doing require the same kind of thing the Archives and Calendar widgets require > modification of the functions they call (i can't provide the features by only altering the widget's code)

this is pretty much as far as i can go without jumping beyond the widgets...

since currently my modifications seem pretty straight-forward, and stable (and do not interfere with defaults, i am going to integrate all modifications into wp-includes/default-widgets.php (and revert many of the naming conventions to current defaults) - and also submit that (the modified default-widgets.php) for review / so you can see what my modifications are like in their intended context - i'll be doing a little more "code cleaning" while i do the integration - if you can see any issues yourself before or while i am doing this please let me know

next up will be the Archives and Calendar widgets

then on to other things (like getting functions the_category() and the_tags() to work with custom tax with no extra coding needed by end-uses or theme developers)

yes, the_terms(), that's nice > and maybe i won't do anything then --- BUT as you can see with my widget examples, i think it's much nicer that wordpress "AUTOMATICALLY" engages the handling of the custom pt/tax > rather than the "seek/find/code" method currently needed to handle custom pt/tax - i'm not saying that someone can't "seek/find/code" to get EXACTLY what they want (how they want it), but instead i'm merely saying it's nicer if they don't have to...

i mean if custom post types and taxies are using default theme templates - it nice the post types can display that way, but then things like the_category() are broken

so i'll look into it > maybe the_category() and/or the_tags() can "jump to" the_terms() when such is fitting and makes sense - so extra "seek/find/code" is not needed

however, that's later (when i look into that) anyway - first i'm gonna get down to the Archives and Calendar widgets

like i said, i'm not there yet - and still am as ignorant as i was with the "auto-flush" idea...

BUT > hmmm -- good question...

i have yet to see an "out of box" theme incorporate all three > a category, a tag and a custom term - and i would imagine such would not be done by the average user - but instead would be done by a more advanced user > where as i said someone could still "seek/find/code" to get EXACTLY what they want (how they want it)

let me say i am looking for "out of the box" functionality < that does not interfere with the current defaults

but you are right - this would be trickier ...

AGAIN - i am not on this stuff right now - and i am avoiding changing the current defaults as much as i can --- BUT this might be a case where default functionality might call for a change

specifically :::::::::: MAYBE...

only use optionally added enhancement the_category() for cat-like tax / tag-like for the_tags() -- and only for for custom pt --- hmmm (i wonder..)

but more importantly - for the_category() and the_tags() > perhaps an additional parameter to close enhanced custom term handling

the above logic is this

if someone's skills are advanced enough to head in and add the_terms() to templates / then they're skills are advanced enough to add/set a parameter in the_category() and/or the_tags()

so that you can review my work (thus far) in the enviroment it's intended for, i've attached wp-includes/default-widgets.php with the following modified widgets

It is preferred that you attach an SVN diff of the changes you have made instead of the whole file. It makes it much easier to see what has been changed in that file, since trac will create a syntax highlighted view of the changes. This will also make reviewing your work much easier and more likely to get things moving.

the attachment default-widgets.diff could be deleted - it is merely a failed test

my background is C++ / i don't know this SVN stuff / you can delete this message and my attachment named "default-widgets.diff"

i need to get back to work - i'll learn this svn stuff later when i have the time - if you have a link that directly explains how to do the svn diff you asked for, that would help - but too much reading/text will not be good for me

i'm using a WAMP localhost and i have A TON of projects i'm currently working on - i'll need to finish them up before i install subversion - as i fear installing subversion might interfere with my localhost install - would you know if my fears are founded ?

i did find instructions to integrate subversion with my localhost - hmmm...

sidenote: ​http://wordpress.org/download/svn/ has a link to an outdated page for subversion ( ​http://subversion.tigris.org/ ) - the new home of subversion is ​http://subversion.apache.org/ - i imagine throughout wordpress.org are pages that refer to subversion the old URL and could use updated links (eventually) - and i would not know where all these pages would be and don't really have the time to hunt for them - i know this is not the place to mention this, but i figure someone here might have a betty idea what pages might benefit being updated

ok - i evaluated the personal work i must do and think i could probably get enough done to start playing with subversion before next weekend - once installed i'll submit a proper svn diff

then move on to the widgets Archives and Calender - where i believe i'll need to tweak the functions they call to get them to intuitively handle custom post types - i don't know yet but i might even need to wp_rewrite (i hope not)

@ scribu > concerning "What if I have both a category, a tag and a custom term attached to the same post and want to display them all at once?":

i did not look into it yet, meaning i am still only thinking about it - currently, i am thinking maybe an update to the functions something like this

also eventually i'll be hitting auto-flush idea again > where i am now inspired by how widgets use $instance AND ALSO wonder how terrible it would be to (YES > YOU GUESSED IT) store ONLY non-builtin post types/tax

SO i guess above i am only saying what Arnold Schwarzenegger is famous for saying, "I'll be back"