Enable fallback pay-per-post when force_pack set#1812
Open
arifulhoque7 wants to merge 4 commits intoweDevsOfficial:developfrom
Open
Enable fallback pay-per-post when force_pack set#1812arifulhoque7 wants to merge 4 commits intoweDevsOfficial:developfrom
arifulhoque7 wants to merge 4 commits intoweDevsOfficial:developfrom
Conversation
Add a skip_limit_block check to allow fallback pay-per-post when force_pack is enabled. Prevents the early post-limit blocking so the payment logic can handle per-post purchases, and suppresses the "purchase a pack" notice when fallback pricing is active. Changes applied to includes/Admin/Forms/Form.php and includes/Admin/Subscription.php.
arifulhoque7
added
needs: dev review
WalkthroughAdds admin bypasses for submission, redirect, and notice gates; introduces a skip_limit_block condition that changes post-limit early-return behavior; casts fallback and pay‑per‑post costs to float; changes fallback_ppp_cost UI from checkbox to numeric with decimal and non‑negative constraints. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Contributor
|
As a user, I see the wrong pay per post after post limit exceeded charge showing. 
|
Treat fallback/pay-per-post costs as numeric values and allow decimals (JS field types changed to number; input fields now include step="0.01" and min="0"). Change casts from int to float when reading fallback cost. Add admin bypasses so users with the admin role skip subscription/payment redirects, restrictions, and subscription notices to avoid blocking administrators during form actions.
Contributor
Author
fixed @Rubaiyat-E-Mohammad vai |
Contributor
Not solved @arifulhoque7 vai Still getting same error Pay-per-post payment is not being required Screen.Recording.2026-02-19.at.12.06.56.PM.mov |
Adjust subscription and admin form behavior to properly handle fallback pay-per-post and admin users. Key changes: - Replace some has_user_error checks with explicit fallback-cost checks so fallback per-post payment is considered when deciding to show notices or block posting (class/subscription.php, includes/Admin/Subscription.php). - Add admin bypasses so users with admin capability don't see subscription/force-pack notices and are not blocked from posting. - When both force_pack and fallback pay-per-post are enabled, suppress the "purchase a pack" notice and allow per-post fallback instead of forcing a pack (skip_limit_block logic). - Cast pay-per-post and fallback cost getters to float and update their return docblocks (includes/Admin/Forms/Form.php). - Ensure the has_error wrapper returns the underlying subscription error value instead of dropping the result. Also tidy up related comments. These changes make subscription UX consistent when fallback payment is enabled and keep admins unaffected by subscription restrictions.
Contributor
Author
Please Check it now , it should work @Rubaiyat-E-Mohammad vai |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
includes/Admin/Subscription.php (1)
427-430:⚠️ Potential issue | 🟠 MajorRemove stray literal in expiration-time concatenation.
Line 429 appends" subscription.php"into the stored expiration time, which will corrupt the value (e.g.,30 subscription.php day).Fix
- $expiration_time = sanitize_text_field( wp_unslash( $post_data['post_expiration_settings']['expiration_time_value'] ) ) . ' subscription.php' . sanitize_text_field( wp_unslash( $post_data['post_expiration_settings']['expiration_time_type'] ) ); + $expiration_time = sanitize_text_field( wp_unslash( $post_data['post_expiration_settings']['expiration_time_value'] ) ) . ' ' . sanitize_text_field( wp_unslash( $post_data['post_expiration_settings']['expiration_time_type'] ) );🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@includes/Admin/Subscription.php` around lines 427 - 430, The expiration time concatenation mistakenly includes the stray literal " subscription.php" which corrupts the value; in the block that checks $post_data['post_expiration_settings'] (the code that sets $expiration_time), remove the " subscription.php" text and concatenate only the sanitized expiration_time_value and expiration_time_type (with a single space if needed) so $expiration_time becomes the clean sanitized value and unit; locate this logic in the Subscription class/file where $expiration_time is assigned and update the concatenation accordingly.
🧹 Nitpick comments (2)
includes/Admin/Subscription.php (1)
1232-1238: Consider aligningskip_limit_blockwith charging-enabled guards.
This matches theForm::is_submission_open()skip logic and avoids inconsistent permission decisions.Suggested alignment
- $skip_limit_block = $force_pack && $fallback_enabled; + $skip_limit_block = $form->is_charging_enabled() && $force_pack && $fallback_enabled;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@includes/Admin/Subscription.php` around lines 1232 - 1238, The early-return gating logic should mirror the charging-enabled guards used by Form::is_submission_open(): tighten the skip condition by also requiring the charging/paid-post feature to be active before bypassing the limit check. Update the $skip_limit_block calculation (currently using $force_pack && $fallback_enabled) to include the same charging-enabled flag or method used elsewhere (e.g. the Form charging check), so that the if that returns 'no' (which examines current_user->subscription()->current_pack_id() and ! $has_post_count) only gets skipped when force_pack, fallback_enabled and charging are all true.class/subscription.php (1)
1162-1172: Consider aligningskip_limit_blockwith charging-enabled guards.
Form::is_submission_open()includesis_charging_enabled()in the skip condition; this one doesn’t, which can lead to inconsistent gating when payment options are off.Suggested alignment
- $skip_limit_block = $force_pack && $fallback_enabled; + $skip_limit_block = $form->is_charging_enabled() && $force_pack && $fallback_enabled;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@class/subscription.php` around lines 1162 - 1172, The early-return gating skips when $skip_limit_block is true but currently omits the charging-enabled check, causing inconsistent behavior versus Form::is_submission_open(); update the $skip_limit_block definition to include the charging flag (e.g. $skip_limit_block = $force_pack && $fallback_enabled && is_charging_enabled()), so the subsequent if that checks current_user()->subscription()->current_pack_id() and ! $has_post_count only bypasses limits when payments are enabled; reference: $skip_limit_block, current_user->subscription()->current_pack_id(), and is_charging_enabled() to locate and change the code.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@class/subscription.php`:
- Around line 1126-1140: The force_pack_notice function prematurely suppresses
the "purchase a pack" CTA whenever fallback is enabled; change the early-return
logic so you only skip showing the pack notice when fallback is enabled AND the
current user actually has an active pack whose limit is exceeded. In the
force_pack_notice method, after $force_pack and $fallback_enabled are computed,
add a check for the current user's pack ownership/usage (use your existing
pack-check helpers, e.g., any user_has_pack()/get_user_pack()/pack_usage check
functions) and only return $text when both fallback is true AND the user has a
pack with exceeded limit; otherwise allow the notice to display. Ensure you keep
the admin-capability early return as-is.
In `@includes/Admin/Subscription.php`:
- Around line 1193-1206: The code currently hides the "purchase a pack" CTA
whenever fallback pay-per-post is enabled ($fallback_enabled) even for users
without a pack; change the conditional so the notice is only suppressed when
fallback is enabled AND the current user actually has a pack and is over quota.
After computing $force_pack and $fallback_enabled in Subscription.php (the Form
instantiation and is_enabled_force_pack/is_enabled_fallback_cost calls), replace
the short-circuit return with a check that calls your subscription APIs (e.g.,
methods like Subscription::has_active_pack($user_id) and
Subscription::is_over_quota($user_id) or equivalent helper functions) and only
return $text when $fallback_enabled && user_has_active_pack &&
user_is_over_quota; otherwise allow the CTA to display.
---
Outside diff comments:
In `@includes/Admin/Subscription.php`:
- Around line 427-430: The expiration time concatenation mistakenly includes the
stray literal " subscription.php" which corrupts the value; in the block that
checks $post_data['post_expiration_settings'] (the code that sets
$expiration_time), remove the " subscription.php" text and concatenate only the
sanitized expiration_time_value and expiration_time_type (with a single space if
needed) so $expiration_time becomes the clean sanitized value and unit; locate
this logic in the Subscription class/file where $expiration_time is assigned and
update the concatenation accordingly.
---
Nitpick comments:
In `@class/subscription.php`:
- Around line 1162-1172: The early-return gating skips when $skip_limit_block is
true but currently omits the charging-enabled check, causing inconsistent
behavior versus Form::is_submission_open(); update the $skip_limit_block
definition to include the charging flag (e.g. $skip_limit_block = $force_pack &&
$fallback_enabled && is_charging_enabled()), so the subsequent if that checks
current_user()->subscription()->current_pack_id() and ! $has_post_count only
bypasses limits when payments are enabled; reference: $skip_limit_block,
current_user->subscription()->current_pack_id(), and is_charging_enabled() to
locate and change the code.
In `@includes/Admin/Subscription.php`:
- Around line 1232-1238: The early-return gating logic should mirror the
charging-enabled guards used by Form::is_submission_open(): tighten the skip
condition by also requiring the charging/paid-post feature to be active before
bypassing the limit check. Update the $skip_limit_block calculation (currently
using $force_pack && $fallback_enabled) to include the same charging-enabled
flag or method used elsewhere (e.g. the Form charging check), so that the if
that returns 'no' (which examines
current_user->subscription()->current_pack_id() and ! $has_post_count) only gets
skipped when force_pack, fallback_enabled and charging are all true.
Comment on lines
1126
to
+1140
| public function force_pack_notice( $text, $id, $form_settings ) { | ||
| // Admin users don't need subscription notices | ||
| if ( current_user_can( wpuf_admin_role() ) ) { | ||
| return $text; | ||
| } | ||
|
|
||
| $form = new WPUF_Form( $id ); | ||
|
|
||
| $force_pack = $form->is_enabled_force_pack(); | ||
| $force_pack = $form->is_enabled_force_pack(); | ||
| $fallback_enabled = $form->is_enabled_fallback_cost(); | ||
|
|
||
| // When fallback pay-per-post is enabled, don't show "purchase a pack" notice | ||
| if ( $force_pack && $fallback_enabled ) { | ||
| return $text; | ||
| } |
There was a problem hiding this comment.
Avoid suppressing the “purchase a pack” notice for users without a pack.
Right now the early return triggers whenever fallback is enabled, even if the user has no pack, so they lose the CTA. Consider limiting the skip to “has pack + limit exceeded.”
Proposed adjustment
- if ( $force_pack && $fallback_enabled ) {
- return $text;
- }
+ if ( $force_pack && $fallback_enabled && is_user_logged_in() ) {
+ $post_type = ! empty( $form_settings['post_type'] ) ? $form_settings['post_type'] : 'post';
+ $current_user = wpuf_get_user();
+ if ( $current_user->subscription()->current_pack_id() && ! $current_user->subscription()->has_post_count( $post_type ) ) {
+ return $text;
+ }
+ }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@class/subscription.php` around lines 1126 - 1140, The force_pack_notice
function prematurely suppresses the "purchase a pack" CTA whenever fallback is
enabled; change the early-return logic so you only skip showing the pack notice
when fallback is enabled AND the current user actually has an active pack whose
limit is exceeded. In the force_pack_notice method, after $force_pack and
$fallback_enabled are computed, add a check for the current user's pack
ownership/usage (use your existing pack-check helpers, e.g., any
user_has_pack()/get_user_pack()/pack_usage check functions) and only return
$text when both fallback is true AND the user has a pack with exceeded limit;
otherwise allow the notice to display. Ensure you keep the admin-capability
early return as-is.
Comment on lines
+1193
to
+1206
| // Admin users don't need subscription notices | ||
| if ( current_user_can( wpuf_admin_role() ) ) { | ||
| return $text; | ||
| } | ||
|
|
||
| $form = new Form( $id ); | ||
|
|
||
| $force_pack = $form->is_enabled_force_pack(); | ||
| $force_pack = $form->is_enabled_force_pack(); | ||
| $fallback_enabled = $form->is_enabled_fallback_cost(); | ||
|
|
||
| // When fallback pay-per-post is enabled, don't show "purchase a pack" notice | ||
| if ( $force_pack && $fallback_enabled ) { | ||
| return $text; | ||
| } |
There was a problem hiding this comment.
Avoid suppressing the “purchase a pack” notice for users without a pack.
Same concern as the front-end class: fallback-enabled shouldn’t hide the pack CTA unless the user has a pack and is over quota.
Proposed adjustment
- if ( $force_pack && $fallback_enabled ) {
- return $text;
- }
+ if ( $force_pack && $fallback_enabled && is_user_logged_in() ) {
+ $post_type = ! empty( $form_settings['post_type'] ) ? $form_settings['post_type'] : 'post';
+ $current_user = wpuf_get_user();
+ if ( $current_user->subscription()->current_pack_id() && ! $current_user->subscription()->has_post_count( $post_type ) ) {
+ return $text;
+ }
+ }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@includes/Admin/Subscription.php` around lines 1193 - 1206, The code currently
hides the "purchase a pack" CTA whenever fallback pay-per-post is enabled
($fallback_enabled) even for users without a pack; change the conditional so the
notice is only suppressed when fallback is enabled AND the current user actually
has a pack and is over quota. After computing $force_pack and $fallback_enabled
in Subscription.php (the Form instantiation and
is_enabled_force_pack/is_enabled_fallback_cost calls), replace the short-circuit
return with a check that calls your subscription APIs (e.g., methods like
Subscription::has_active_pack($user_id) and
Subscription::is_over_quota($user_id) or equivalent helper functions) and only
return $text when $fallback_enabled && user_has_active_pack &&
user_is_over_quota; otherwise allow the CTA to display.
Contributor
Showing wrong amount issue not solved vai @arifulhoque7 vai 
|
Update conditional checks in subscription display logic (class/subscription.php and includes/Admin/Subscription.php) so that user errors do not block the subscription UI when a forced pack is used with the form's fallback cost enabled. The change preserves the existing payment-enabled && pay-per-post && !force_pack behavior and reformats the condition into a clearer multi-line expression.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
includes/Admin/Subscription.php (1)
1196-1209: Blanket notice suppression for all users when fallback is enabled.The guard
if ( $force_pack && $fallback_enabled ) { return $text; }at line 1207 silences the "purchase a pack" CTA for every user — including users who have no pack at all and genuinely need to see it. The suppression should only apply to users who already have an active pack but have exhausted their post quota.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@includes/Admin/Subscription.php` around lines 1196 - 1209, The current blanket return when ($force_pack && $fallback_enabled) hides the CTA for all users; change it to only suppress the notice for users who already have an active pack but no remaining posts. Inside the same block where $form = new Form($id) is created, replace the unconditional return with a conditional that checks the current user's pack state (use your project’s pack APIs — e.g., user_has_active_pack($user_id) and get_user_pack_remaining($user_id) or equivalent helpers) and only return $text when the user has an active pack and remaining posts === 0; otherwise allow the "purchase a pack" notice to be shown.
🧹 Nitpick comments (1)
includes/Admin/Subscription.php (1)
1224-1226:$fallback_costis fetched but never used inforce_pack_permission.
$fallback_cost = $form->get_subs_fallback_cost()is a dead assignment — the value is unused. If the intent was to include a(float)$fallback_cost > 0guard in$skip_limit_block(preventing free fallback posting when the cost is accidentally set to 0), add it; otherwise remove the line.♻️ Remove dead assignment or use it
- $fallback_cost = $form->get_subs_fallback_cost();Or, if a non-zero cost gate is desired:
- $fallback_cost = $form->get_subs_fallback_cost(); + $fallback_cost = (float) $form->get_subs_fallback_cost(); - $skip_limit_block = $force_pack && $fallback_enabled; + $skip_limit_block = $force_pack && $fallback_enabled && $fallback_cost > 0.0;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@includes/Admin/Subscription.php` around lines 1224 - 1226, The assignment $fallback_cost = $form->get_subs_fallback_cost() in force_pack_permission is dead — either remove that line or use it to guard free fallback posting; to fix, locate force_pack_permission and either delete the unused $fallback_cost assignment, or update the $skip_limit_block condition (where $fallback_enabled is checked) to also require (float)$fallback_cost > 0 so the fallback only bypasses limits when a positive fallback cost is configured.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@includes/Admin/Subscription.php`:
- Around line 678-681: The admin bypass is only applied to the payment redirect
but not to post-status logic, causing admin-created posts to be left in pending;
add the same admin-check used in the payment redirect (current_user_can(
wpuf_admin_role() )) at the top of both set_pending() and monitor_new_post() so
that if the current user is an admin the methods immediately return without
setting post_status = 'pending' or writing _wpuf_order_id/_wpuf_payment_status;
locate set_pending() and monitor_new_post() in the Subscription class and mirror
the exact guard/return behavior used in the existing admin-bypass block.
---
Duplicate comments:
In `@includes/Admin/Subscription.php`:
- Around line 1196-1209: The current blanket return when ($force_pack &&
$fallback_enabled) hides the CTA for all users; change it to only suppress the
notice for users who already have an active pack but no remaining posts. Inside
the same block where $form = new Form($id) is created, replace the unconditional
return with a conditional that checks the current user's pack state (use your
project’s pack APIs — e.g., user_has_active_pack($user_id) and
get_user_pack_remaining($user_id) or equivalent helpers) and only return $text
when the user has an active pack and remaining posts === 0; otherwise allow the
"purchase a pack" notice to be shown.
---
Nitpick comments:
In `@includes/Admin/Subscription.php`:
- Around line 1224-1226: The assignment $fallback_cost =
$form->get_subs_fallback_cost() in force_pack_permission is dead — either remove
that line or use it to guard free fallback posting; to fix, locate
force_pack_permission and either delete the unused $fallback_cost assignment, or
update the $skip_limit_block condition (where $fallback_enabled is checked) to
also require (float)$fallback_cost > 0 so the fallback only bypasses limits when
a positive fallback cost is configured.
ℹ️ Review info
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
class/subscription.phpincludes/Admin/Subscription.php
🚧 Files skipped from review as they are similar to previous changes (1)
- class/subscription.php
Comment on lines
+678
to
+681
| // Admin users bypass payment redirect | ||
| if ( current_user_can( wpuf_admin_role() ) ) { | ||
| return $response; | ||
| } |
There was a problem hiding this comment.
Incomplete admin bypass — admin posts may get stranded in pending.
set_pending() (line 562) and monitor_new_post() (line 625) have no corresponding admin bypass. If an admin has an active subscription pack with exhausted posts, set_pending() will still set post_status = 'pending' and monitor_new_post() will still write _wpuf_order_id + _wpuf_payment_status = pending. With the payment redirect now bypassed here, the post has no path to publication—payment never completes and no hook auto-publishes it.
Consider guarding set_pending() and monitor_new_post() similarly:
🛡️ Suggested approach for `set_pending`
public function set_pending( $postdata, $form_id, $form_settings, $form_vars ) {
+ if ( current_user_can( wpuf_admin_role() ) ) {
+ return $postdata;
+ }
$form = new Form( $form_id );Apply the same guard at the top of monitor_new_post().
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@includes/Admin/Subscription.php` around lines 678 - 681, The admin bypass is
only applied to the payment redirect but not to post-status logic, causing
admin-created posts to be left in pending; add the same admin-check used in the
payment redirect (current_user_can( wpuf_admin_role() )) at the top of both
set_pending() and monitor_new_post() so that if the current user is an admin the
methods immediately return without setting post_status = 'pending' or writing
_wpuf_order_id/_wpuf_payment_status; locate set_pending() and monitor_new_post()
in the Subscription class and mirror the exact guard/return behavior used in the
existing admin-bypass block.
Rubaiyat-E-Mohammad
added
QA Approved
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fix: Allow post submission with fallback pay-per-post when subscription post limit is exceeded. Close 1414
When a form has "Mandatory Subscription" enabled with "Pay-per-post billing when limit exceeds" checked and a fallback cost set, users who have exhausted their subscription post limit were incorrectly blocked with the message "Post Limit Exceeded for your purchased subscription pack." instead of being allowed to submit and pay per post.
Root cause: Three early return checks in the code were blocking users before the fallback pay-per-post logic could be evaluated:
Form::is_submission_open() — early return at the top-level post count check
Subscription::force_pack_permission() — wpuf_can_post filter overriding the result back to 'no'
Subscription::force_pack_notice() — displaying "You must purchase a pack" notice instead of the form
Fix: Added a $skip_limit_block condition to all three locations so the early returns are bypassed when force_pack + fallback_cost are both enabled, allowing the existing downstream logic to correctly permit posting with per-post payment.
Summary by CodeRabbit
New Features
UI
Bug Fixes