No subject

change wasn't implemented.

However, I'm working on a site that has News, Projects, Insights and
Events. For me, the best approach is to hijack Posts as News (with
some relabelling), then have Projects, Insights and Events as custom
post types. (I'm hacking Events so they publish even when set for the
future, so the publish date can be used as the event date.)

On the home page is a tabbed interface showing the latest two posts of
each type - and the client needs to be able to manually promote
certain older posts to appear here if necessary. Surely an ideal
situation for being able to apply the "sticky" flag to CPTs?

Of course I could have all these as post categories, but I prefer CPTs
because having a UI for each of them *greatly* simplifies things for
the client's editors. It's not just about having separate menu items.
It's also that I create quite a few custom meta boxes for custom
fields, depending on the post type. I'd have to wait until after the
user saved a post (and remembered to select the category) to put the
appropriate boxes in place, if I just used posts with categories.

I don't follow the logic that if CPTs appear on the home page, they
probably should be posts. It seems anachronistic now that it's very
common for WP to be running sites other than blogs, where the home
page is just a list of posts. My situation - giving an overview of the
latest of all kinds of content, with the ability to "stick" older
stuff there to promote it - is presumably far from rare. And because
there was refusal to even allow the option of "sticky" functionality
for CPTs, I now have to build my own system, do a bunch of extra
querying, etc. - or hack the core :(

Any chance of this being re-considered?

cheers,

Steve