XF 2.1 isRecentlyActive

Ozzy47

Well-known member
I am trying to extend XF/Finder/User.php specifically isRecentlyActive
Function:
PHP:
    public function isRecentlyActive($days = 180)
    {
        $this->where('last_activity', '>', time() - ($days * 86400));
        return $this;
    }

My file:
PHP:
<?php

namespace OzzModz\ActiveDays\XF\Finder;

use XF\Mvc\Entity\Finder;

class User extends XFCP_User
{
    public function isRecentlyActive($days = 180)
    {
       $parent = parent::isRecentlyActive();

        $options = \XF::options();

        $days = $options->ozzmodzActiveDays_days;
      
        $this->where('last_activity', '>', time() - ($days * 86400));
        return $this;
      
        return $parent;
    }
}

Now in my option if I set days below 180, it will work and only return users that have been active in the days set. But, If I set the days above 180, it still only returns users active in the past 180 days. Even if I don't return the parent, it still does not let me go above 180.

Am I missing something or is this being overridden elsewhere?
 

Lukas W.

Well-known member
The first thing you do in your extending method is call the parent (without an argument), which will limit it to a maximum of 180 days.
 

Lukas W.

Well-known member
Judging from your code you'd literally just want to pass your add-ons value as such:
PHP:
public function isRecentlyActive($days = 180)
{
    $options = \XF::options();
    return parent::isRecentlyActive($options->ozzmodzActiveDays_days);
}

However, this and your initial approach are both essentially overwriting any actual passed arguments, so you probably rather want to go with the following extension:
PHP:
public function isRecentlyActive($days = null)
{
    $options = \XF::options();
    return parent::isRecentlyActive($days ?: $options->ozzmodzActiveDays_days);
}
 

Lukas W.

Well-known member
Changing signature expected value is not nice :(
PHP:
    public function isRecentlyActive($days = 180)
    {
        $days = func_num_args() ? $days : \XF::options()->ozzmodzActiveDays_days;
    
        return parent::isRecentlyActive($days);
    }

It was the lesser evil compared to completely ignoring the input, especially considering that two extensions to this specific method will likely always cause troubles, but your solution is undoubtedly better.

Edit: Code-wise it doesn't make any difference fwiw, any method that extends first will pass its default along and overwrite this extension, and any coming after receives an integer as expected.
 

Lawrence

Well-known member
Another approach, maybe?

Code:
    public function isRecentlyActive($days = 180)
    {
        if ($days != 180)
        {
            // if not = to 180, an add-on changed it
            return parent::isRecentlyActive($days);
        }
        
        return parent::isRecentlyActive(\XF::options()->ozzmodzActiveDays_days);
    }
 

Lawrence

Well-known member
That wouldn't work where one wants to change the default value in places like XF:Member controller and Find action.

That is true, but if they did change the value then the new value will be used, if not then \XF::options()->ozzmodzActiveDays_days would be used.
 

TickTackk

Well-known member
And what if XF decides to change the value from 180 to 181 and after few more updates, back to 180 from 181? Create new add-on releases just for that? :p
 

Kirby

Well-known member
Changing signature expected value is not nice :(
But that is exactly what this Add-on is about: To change the default.

Personally, I'd use
PHP:
public final function isRecentlyActive($days = null)
{
    $options = \XF::options();
    return parent::isRecentlyActive($days ?: $options->ozzmodzActiveDays_days);
}

with an execution order of 4294967295.
 

Ozzy47

Well-known member
But that is exactly what this Add-on is about: To change the default.

Personally, I'd use
PHP:
public final function isRecentlyActive($days = null)
{
    $options = \XF::options();
    return parent::isRecentlyActive($days ?: $options->ozzmodzActiveDays_days);
}

with an execution order of 4294967295.
W

Why such an extreme execution order?
 

Kirby

Well-known member
The final keyword would block any further exensions of the method (which is necessary to not have another default value being passed down to your method).

To avoid this case (would generate an exception if another class would by trying to extend your method), you'd also have to make sure that your class is the last one; this isn't possible but giving it the maximum value as execution order at least makes sure that there can't be other extensions with a higher execution order (there could still be other enxtensions with the same execution order though).
 
Top