Make WordPress Core

Opened 13 years ago

Closed 10 years ago

Last modified 10 years ago

#17482 closed enhancement (maybelater)

Formalize a list of "Object Types"

Reported by: mikeschinkel's profile mikeschinkel Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: General Keywords: dev-feedback has-patch
Focuses: Cc:

Description

I'm finding a need to use a defined list of object types for numerous things including for object relationships, term relationships that relate taxonomy terms to something other than a post, data entry forms, and I am sure there are more than just these requirements (An "object" is anything in WordPress for which we can identify a name and a unique ID form the database, i.e. $post->ID, $user->ID, $term->term_id and so on.)

While thinking about it this seems to be something that would be valuable to include core so I am proposing and submitting a patch for their potential inclusion. If this is not something that the team would want to include then I'll simply incorporate them into my own code but I wanted to make sure that the team wouldn't want to include them into WordPress core instead.

Attachments (2)

require-object-types.diff (449 bytes) - added by mikeschinkel 13 years ago.
Patch to /wp-settings.php to require object-types.php
object-types.php (1.7 KB) - added by mikeschinkel 13 years ago.
/wp-includes/object-types.php

Download all attachments as: .zip

Change History (14)

@mikeschinkel
13 years ago

Patch to /wp-settings.php to require object-types.php

#1 follow-up: @scribu
13 years ago

Shouldn't those be run through __() ?

In general, we don't include strings that are not directly used in Core: #14972

Last edited 13 years ago by scribu (previous) (diff)

#2 @scribu
13 years ago

Yes, I realize that the strings aren't the main thing you're interested in.

#3 in reply to: ↑ 1 @mikeschinkel
13 years ago

Replying to scribu:

Shouldn't those be run through __() ?

In general, we don't include strings that are not directly used in Core: #14972

Great point, and fixing it caused me to realize I had forgotten something too, to make the values an array to enable support for future object type attributes. I'm uploading a patch to overwrite the first one.

@mikeschinkel
13 years ago

/wp-includes/object-types.php

#4 follow-up: @nacin
10 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to maybelater
  • Status changed from new to closed

Seems like something we can safely pass on for now. Custom post types make this a whole different beast. Doesn't feel Ike something for core yet. It's possible the REST API will offer clarification of these resources...

Also worth noting that "object types" could be conflated with "post types" really easily (though obviously you were proposing the idea, not the name).

#5 in reply to: ↑ 4 ; follow-up: @MikeSchinkel
10 years ago

Replying to nacin:

Also worth noting that "object types" could be conflated with "post types" really easily (though obviously you were proposing the idea, not the name).

Point of note, I was proposing the name "object type" but only because the table wp_term_relationships and all the related functions like get_objects_in_term() and is_object_in_taxonomy() already set the precedent for "object_id" in core. But, a rose by another name would smell just as sweet.

Seems like something we can safely pass on for now. Custom post types make this a whole different beast. Doesn't feel Ike something for core yet.

Depends on the scope of the "Post Meta Feature as Plugin" project; some of us would like to see it address more than just posts. If we can also tackle user, comment, et.al. it seems pretty much like a must.

And it's definitely needed if and when object relationships can be added to core (I'm ready and waiting to lead the "Features as Plugin" team for that, I just need blessing from Automattic to get started, and access to a forum on make.wordpress.org, of course.)

Last edited 10 years ago by MikeSchinkel (previous) (diff)

#6 in reply to: ↑ 5 ; follow-up: @nacin
10 years ago

Replying to MikeSchinkel:

Depends on the scope of the "Post Meta Feature as Plugin" project; some of us would like to see it address more than just posts. If we can also tackle user, comment, et.al. it seems pretty much like a must.

I would like to see it look at posts/user/comment, settings, and the customizer. Note "look at" — not trying to overwhelm, but it's worth at least studying everything.

And it's definitely needed if and when object relationships can be added to core (I'm ready and waiting to lead the "Features as Plugin" team for that, I just need blessing from Automattic to get started, and access to a forum on make.wordpress.org, of course.)

You know as well as I do that Automattic has nothing to do with that. There's a roadmap in place for terms, some of which I'd like to tackle in 3.9; object relationships won't come before that. None of this (including postmeta) are conducive to the feature plugins track as they are inherently architecture.

#7 in reply to: ↑ 6 ; follow-up: @MikeSchinkel
10 years ago

Replying to nacin:

I would like to see it look at posts/user/comment, settings, and the customizer. Note "look at" — not trying to overwhelm, but it's worth at least studying everything.

Cool.

You know as well as I do that Automattic has nothing to do with that.

Whoa there!!!

I don't actually know how anything get decided nor who is in charge of what; from the outside it's very opaque. For example, where is the canonical URL that explains how decisions get made about the various things that affect the WordPress community? If there is one, I'm not aware of one.

I wasn't trying to make a political statement, just saying I'd be willing to work on relationships as soon as it was blessed. But since I didn't really know who has access to make.wordpress.org I assumed it was Automattic.

Note: unlike some in the WordPress community I don't really care about the relationships between Automattic, WordPress Foundation, Audrey Capital, et. al.; I just see that it is what it is and I go about my business trying to be negatively affected by it the least. (When I have made a stink in the past it's been about technical decisions that seem trivial on core's end but make my life >10x harder.)

There's a roadmap in place for terms, some of which I'd like to tackle in 3.9; object relationships won't come before that. None of this (including postmeta) are conducive to the feature plugins track as they are inherently architecture.

So, does that mean you don't need (or want) outside help or involvement?

Last edited 10 years ago by MikeSchinkel (previous) (diff)

#8 in reply to: ↑ 7 ; follow-up: @MikeSchinkel
10 years ago

Replying to MikeSchinkel:

Replying to nacin:
None of this (including postmeta) are conducive to the feature plugins track as they are inherently architecture.

Just realized you added postmeta here. Are you saying that the already blessed "Feature as Plugin" for Post Meta shouldn't be a "Feature as Plugin"?

#9 in reply to: ↑ 8 @samuelsidler
10 years ago

Replying to MikeSchinkel:

Replying to MikeSchinkel:

Replying to nacin:
None of this (including postmeta) are conducive to the feature plugins track as they are inherently architecture.

Just realized you added postmeta here. Are you saying that the already blessed "Feature as Plugin" for Post Meta shouldn't be a "Feature as Plugin"?

I'm not sure what you mean by "blessed" here, fwiw. There are a number of feature plugins that have been added to that page and then put on hold. Just because a feature plugin is listed doesn't mean it will ever necessarily land in core. The page simply lists experiments in development.

But per several discussions, the postmeta team is more of a component group working together on large backend changes. We currently list them on the feature plugin page because we don't have another place to list them (yet).

#10 @MikeSchinkel
10 years ago

I'm not sure what you mean by "blessed" here, fwiw.

Maybe what I mean is that since I'm not able to read the minds of the people who are choosing what features as plugins get added to the list nor who are choosing which projects to provide space on make.wordpress.org and/or related exposure I simply used the best word that came to mind to describe the encapsulation of those things.

#11 follow-up: @wonderboymusic
10 years ago

For a lot of people, I know the wait can be frustrating, but I would try viewing it in a larger context: we all have things we would love to go in immediately, but as responsible committers, we have to weigh the pros and cons of tossing code onto 20% of internet. I have tickets that have been open for 7 releases, but for each I either:

1) don't think the idea is fully-baked
2) don't have absolute confidence that the feature/code is necessary
3) haven't made a good enough case for it
4) haven't provided bulletproof evidence that it's going to make WP better (unit tests, use cases, fully-baked code)

If there's a ticket bound to a component and it's still open, someone has more-than-likely looked at it and decided it's not ready, but not dead. If someone has closed a ticket, it's usually for a good reason, and it's never personal.

For these big architectural changes, I would find a way to do iterative development on existing code or come to the table with a fully-functional proof-of-concept, unit tests, and use cases.

Make/Core is not a community blog. The best way to be granted access is to become active in dev chats and plead your case for a feature, while accepting that the community night not fall in line behind it. Many who are granted access are also extremely active in core, regardless of the current status of their tickets. Many of the feature-plugin authors are also willing to donate their time to work on a feature that may never see the light of day.

#12 in reply to: ↑ 11 @MikeSchinkel
10 years ago

Replying to wonderboymusic:

For a lot of people, I know the wait can be frustrating, but I would try viewing it in a larger context:

Just wanted to follow up to clarify. I've long since gotten past being frustrated. Yes, I was frequently frustrated several years ago, but have since gotten past it. I now just look at everything related to WordPress pragmatically just as a bull fighter looks at a bull; I do my best to achieve progress without getting gored.

What I said above was in summary and effectively "I'd like to work on Object Relationships for WordPress core, and would lead the effort if allowed." Period. Everything else was me clarifying that I don't in fact understand the relationship between the different entities that have involvement with WordPress nor how decisions are being made, nor do I care how people choose to set it up, and that my only related concern is how to navigate the waters without that understanding.

So just to be clear; there's no emotion here, just discussion.

Last edited 10 years ago by MikeSchinkel (previous) (diff)
Note: See TracTickets for help on using tickets.