Lazy load $wp_query->is_singular

[scribu]

The $is_singular flag is just an alias for $is_post || $is_page || $is_attachment.

Being a variable means we have to also keep it current whenever one of it's components changes.

I propose we use a magic __get() method that would call is_singular() internally.

[gazouteast]

Scribu

What about cross-format variables, as opposed to typical blog usage?

e.g. CMS pre-structuring where post, page, attachment ID are all X (the same number) because they're all the same subject, and X is then used as a default value for custom function/taxonomy or whatever?

I can understand why you'd want to enforce use of individualised string variables, but why deprecate a useful "collective" one?

If WordPress is pushing for recognition as a serious CMS alternative to the likes of Drupal and Joomla! then it needs to keep CMS-useful functionality, would be my two cents worth on it.

Or am I missing something here (as usual)?

[scribu]

You are missing something, yeah, but it's my fault. Updated ticket for clarity.

[markjaquith]

Once we move to PHP 5, we could leave $is_singular undefined and use a magic method ( __get() ) to calculate that $is_post || $is_page || $is_attachment logic, and without deprecating anything. Or rather, we could discuss it, at least.

[scribu]

Yes, that's exactly what 15773.diff​ does.

[scribu]

Similar: #17195

[westi]

Personally I think magic __get methods are nasty.

Before making this change we need a reason to do it like a significant performance improvement.

Can you run some measurements on this?

[nacin]

I don't think the point here is performance; rather, it's a desire for is_singular to always be accurate in case is_post, is_page, or is_attachment changes.

[scribu]

What nacin said.

[nacin]

I'm also not convinced that's desired behavior. While it may be for is_singular, it probably shouldn't be for is_home, which like is_singular is calculated based on other flags. As is is_archive. And is_date. Where do we stop?

[scribu]

In the case of is_home, I know I've had to manually set it to false in some cases.

Although it's set based on other flags, it's not really an aggregate like is_singular.

But anyway, point taken.

[westi]

Also this change is akin to making $is_singular private.

i.e. it is changing the existing API that a plugin could be using and providing no way for it to continue functioning.

Therefore we need a strong case - like performance (I don't think maintainability is one here because we shouldn't be rewriting or significantly changing this code often).

[scribu]

Pretty sure a performance increase is out of the question.

Closing.