Expiring User Upgrades

Expiring User Upgrades [Paid] 2.6.2

No permission to buy ($25.00)
Overview FAQ Updates (37) Reviews (3) History Discussion
Yes, all my add-ons should work with php 8.2 now. Especially considering I'm running php 8.2 on my own sites, with practically all the add-ons I sell or offer
 
Is this addon supposed to adhere to the XF UNSUBSCRIBE function?

The unsubscribe emails seem to only stop core XF.

uns1.webp

Results: Red = XF, Orange Expiring User Upgrades [Paid] 2.6.1

uns2.webp

Respect user's email privacy settings?: Is set as shown. Does this need changed and does it affect unsubscribe behavior?

uns3.webp
 
Last edited:
These are emails about a financial transaction, the "respect user's email privacy setting" is something which shouldn't be respected for what is basically a post-purchase account action.
 
Have come across a problem with this addon while looking into https://xenforo.com/community/threads/all-user-upgrades-with-legacy-amounts-are-now-failing.224311/

With legacy PayPal upgrades from XF 1.x to 2.x, XenForo's payment handler validates the cost against the current upgrade price, and if that fails it tries to find the existing UserUpgradeActive to validate the cost against that. This is in case the upgrade cost has changed, it has to validate against what the cost was at the time of purchase.

The issue was that the UserUpgradeActive record contained the new price which meant the incoming payment was never going to match (both the user upgrade and the active upgrade record had the new cost) and I couldn't work out how that happened.

The problem is this from SV\ExpiringUserUpgrades\XF\Service\User\Upgrade::upgrade():

PHP: 
if ($active instanceof \XF\Entity\UserUpgradeActive)
{
    $active->notified_date = 0;
    $upgrade = $active->Upgrade;
    $extra = $active->extra;
    $extra['extra_group_ids'] = $upgrade->extra_group_ids;
    $extra['recurring'] = $upgrade->recurring;
    $extra['cost_amount'] = $upgrade->cost_amount;
    $extra['cost_currency'] = $upgrade->cost_currency;
    $extra['length_amount'] = $upgrade->length_amount;
    $extra['length_unit'] = $upgrade->length_unit;
    $active->extra = $extra;
    $active->save();
}

This resets $extra['cost_amount'] to be $upgrade->cost_amount, losing the legacy value it used to have. This then causes legacy renewal payments for upgrades that have since changed price to fail.

It wouldn't be immediately obvious as the first renewal would succeed, only the second renewal would fail as by then $extra['cost_amount'] has been updated, and this is the behaviour I've seen here.
 
Thanks, I'm investigating what the fix should be. This appears to be quite old bug from 2018, so I'm amazed it hasn't blow up.

I've refactored this code as it only needs to store additional details for the 'can extend' button to return true and the rest of it just isn't required.

I really wish XF kept a log of applied user-upgrade records rather than just the single summary row. It would make troubleshooting and debugging this so much easier.
 
Bug

  • rrorException: Fatal Error: Declaration of SV\ExpiringUserUpgrades\XF\Admin\Controller\User::userSaveProcess(XF\Entity\User $user) must be compatible with apathy\StyleSuite\XF\Admin\Controller\User::userSaveProcess(XF\Entity\User $user): XF\Mvc\FormAction
  • src/addons/SV/ExpiringUserUpgrades/XF/Admin/Controller/User.php:20
  • Generated by:
  • Sep 16, 2024 at 8:19 AM

Stack trace​

#0 [internal function]: XF::handleFatalError()
#1 {main}

Request state​

array(4) {
["url"] => string(29) "/admin.php?users/quick-search"
["referrer"] => string(40) "https://testforum.x.com/admin.php"
["_GET"] => array(1) {
["users/quick-search"] => string(0) ""
}
["_POST"] => array(2) {
["_xfToken"] => string(8) "********"
["query"] => string(8) "x"
}


Stylesuite conflict.
}
 
MentaL said:
Bug

  • rrorException: Fatal Error: Declaration of SV\ExpiringUserUpgrades\XF\Admin\Controller\User::userSaveProcess(XF\Entity\User $user) must be compatible with apathy\StyleSuite\XF\Admin\Controller\User::userSaveProcess(XF\Entity\User $user): XF\Mvc\FormAction
  • src/addons/SV/ExpiringUserUpgrades/XF/Admin/Controller/User.php:20
  • Generated by:
  • Sep 16, 2024 at 8:19 AM

Stack trace​

#0 [internal function]: XF::handleFatalError()
#1 {main}

Request state​

array(4) {
["url"] => string(29) "/admin.php?users/quick-search"
["referrer"] => string(40) "https://testforum.x.com/admin.php"
["_GET"] => array(1) {
["users/quick-search"] => string(0) ""
}
["_POST"] => array(2) {
["_xfToken"] => string(8) "********"
["query"] => string(8) "x"
}


Stylesuite conflict.
}
Click to expand...
In XF2.3 (and earlier) userSaveProcess has no return type defined.

This is a bug in the apathy\StyleSuite add-on, it could also be another add-on incorrectly adding a return type.
 
I might be missing something, but I'm not seeing the option to set the number of days before the user upgrade expires to send users the expiring user upgrade notification.
 

Attachments

  • add user upgrade 1.webp
    add user upgrade 1.webp
    36.8 KB · Views: 2
  • add user upgrade 2.webp
    add user upgrade 2.webp
    31.7 KB · Views: 2
Look for "Expiration Notification (Days)" option at the very bottom of the add/edit user upgrade page.
 
Xon said:
Look for "Expiration Notification (Days)" option at the very bottom of the add/edit user upgrade page.
Click to expand...
My addon from TH "Monetize" removes this option from the user upgrade page. I've reached out to them regarding this issue!
 
You must log in or register to reply here.

Similar threads

NealC
Not a bug Accounts (user groups) downgraded from paid user upgrades expiring do not downgrade features
Replies
3
Views
667
Alpha1
Alpha1
A
Expiring User Upgrades 2.1.4 - Complete German Translation (Du) [Deleted]
Replies
3
Views
571
Robert9
R
webbouk
  • Question Question
XF 2.1 Still having issues with User Upgrades paid via Stripe
2
Replies
33
Views
3K
Robert9
R
Naz
Gift Upgrades [Paid]
5 6 7
Replies
135
Views
10K
beerForo
beerForo
Back
Top Bottom