Let's say your app has subscription plans that limit the number of widgets a user can add. You would have some sort of logic that checks the number of widgets a user is allowed to have in their account. With Plan Config you can do that by calling the helper function plan().
if($this->getCurrentNumberOfWidgets < plan('limits.widgets'))
// Allow the user to add a new widget
The plan() helper function knows what plan the current user is subscribed to and grabs the limits you defined in your plans.php config file. You can use the helper function anywhere in your application (views, controllers, models, middleware, etc.). Using the previous example, your plan config file would look like this:
To configure your plans, open up app/plans.php and start adding your plan details. By default the package assumes that you're using laravel's built in Auth, and that the user's plan is stored in the User model. You can set the field used to determine the user's plan in the config...
'plan_field' => 'stripe_plan'
To configure your plans, add your plan data in the 'plans' array.
In the above example, calling plan('limits.purple_widgets') will give you the value from the fallback plan.
Alternatively you can use the facade and call Plan::get('limits.purple_widgets')
Plan config data can be overridden on the user level by setting an override attribute in the config.
'overrides' => [
// The user model attribute that stores the attributes that can be changed
'user_model_attribute' => 'plan_overrides',
// The keys that are allowed to be changed. Set to all by default (['*']).
'allowed' => ['*'],
In the above example, you would create the plan_overrides attribute on the user model. This field should be casted as an array and should include the list of keys and values that should be overridden for the given user.
If you want to return a user's entire plan config (along with overrides), you can pass in * as the first argument.
Why I created this
I've always found that managing subscriptions and plans for a SaaS app can be complicated. I felt like storing these values in a database isn't the best approach considering a lot of your values and limits will not change frequently. When building Election Runner, a web application that allows schools & organizations to run elections, we needed something to accomplish exactly this. Hopefully others will find this as useful as we do!