Where is $app even used in that context?

In what context sorry. This is to try and make sure that it's auto set by JPlugin.

A small but significant number of people seem to be finding that isn't the case (see http://forum.joomla.org/viewtopic.php?f=710&p=3103202 )

If $app != the application object, then something is hijacking the code in
JPlugin. There's unit tests checking this piece, we'd know already if
there was a FUBAR action coming out of that.

On Tuesday, November 19, 2013, George Wilson wrote:

In what context sorry. This is to try and make sure that it's auto set by
JPlugin.

A small but significant number of people seem to be finding that isn't the
case

—
Reply to this email directly or view it on GitHub#2560 (comment)
.

Didn't @dongilbert submit a PR to make $this->app globally available to plugins and modules? I'm confused why $app is even being defined here if that was/is the case.

The code in JPlugin only sets $this->app if defined in a plugin class. If
it isn't defined or doesn't use $app for its var, it won't be set.

On Tuesday, November 19, 2013, Matt Thomas wrote:

Didn't @dongilbert https://github.com/dongilbert submit a PR to make
$this->app globally available to plugins and modules? I'm confused why
$app is even being defined here if that was/is the case.

—
Reply to this email directly or view it on GitHub#2560 (comment)
.

I must be missing something very obvious, or I'm just being dump. Starting at https://github.com/wilsonge/joomla-cms/blob/12f0c06db6c2c02599ec0a586a84c455dc281471/plugins/system/remember/remember.php#L23:

     /**
     * Application object
     *
     * @var    JApplicationCms
     * @since  3.2
     */
    protected $app = null;

But, in functions of this class, such as at https://github.com/wilsonge/joomla-cms/blob/12f0c06db6c2c02599ec0a586a84c455dc281471/plugins/system/remember/remember.php#L94, $this->app is being used.

Why would $app even be defined then?

@betweenbrain So it's not there. It's will be done in the parent::construct() bit. https://github.com/joomla/joomla-cms/blob/master/libraries/cms/plugin/plugin.php#L97 So if $app exists is private and is null then it's set with the application object

Well the number of people posting in that forum post suggest something clearly fooked is going on there. There's a reasonable number of people confirming that on the forum. People are even posting blogs about it (http://www.joomlabamboo.com/blog/how-to-joomla/how-to-fix-a-blank-screen-after-upgrading-to-joomla-3-2)

Also it must be something specific to remember me. Because I used the same method in tiny. But nobody seems to be having an issue there (although there I did explicitly set the class variable to null like in this PR)

That has nothing to do with the symptom you're treating with this pull.
That's just turning it off completely so the end user doesn't have to deal
with it.

If there is a real issue with the JPlugin code, that needs to be addressed.
As it is now is the same as explicitly declaring null.

On Tuesday, November 19, 2013, George Wilson wrote:

@betweenbrain https://github.com/betweenbrain So it's not there. It's
will be done in the parent::construct() bit.
https://github.com/joomla/joomla-cms/blob/master/libraries/cms/plugin/plugin.php#L97So if $app exists is private and is null then it's set with the application
object

Well the number of people posting in that forum post suggest something
clearly fooked is going on there. There's a reasonable number of people
confirming that on the forum. People are even posting blogs about it (
http://www.joomlabamboo.com/blog/how-to-joomla/how-to-fix-a-blank-screen-after-upgrading-to-joomla-3-2
)

—
Reply to this email directly or view it on GitHub#2560 (comment)
.

That has nothing to do with the symptom you're treating with this pull.
That's just turning it off completely so the end user doesn't have to deal
with it.

If there is a real issue with the JPlugin code, that needs to be addressed.
As it is now is the same as explicitly declaring null.

Meaning that I'm not crazy for being confused by this?

protected $app; is exactly the same as protected $app = null;

"if $app exists is private and is null then it's set with the application object"

That's not true, @wilsonge. The $app property must be protected or public, it can not be private. If it's private, it will break.

The only thing I can think of is that JFactory::getApplication() isn't setting the application object for some reason. Remember Me is triggered onAfterInitialize, isn't it? That might be the issue.

It seems that the issue is due to partially updated codebases. Changing the file name, then letting the installer finish, then changing it backs works just fine.

It's not an issue with the code, it's an issue with the update. Recommend to close this PR.

"The $app property must be protected or public, it can not be private" arghh - This is why I should sleep before I code (several 20+ hour days over last few days) - I see and isPrivate() method and come out with this crap.

Closing as suggested and going back to my essay :P