Download the PHP package vnuswilliams/squarhe-subscription without Composer

On this page you can find all versions of the php package vnuswilliams/squarhe-subscription. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Example code of vnuswilliams/squarhe-subscription

Informations about the package squarhe-subscription

Laravel Subscription

## About A straightforward interface to handle subscriptions and features consumption. ## Installation You can install the package via composer: The package migrations are loaded automatically, but you can still publish them with this command: ### if you use gate and policies, you can Publish Subscription policy ## Upgrades If you already use this package and need to move to a newer version, don't forget to publish the upgrade migrations: ## Usage To start using it, you just have to add the given trait to your `User` model (or any entity you want to have subscriptions): And that's it! ### Setting Features Up First things first, you have to define the features you'll offer. In the example below, we are creating two features: one to handle how much minutes each user can spend with deploys and if they can use subdomains. By saying the `deploy-minutes` is a consumable feature, we are telling the users can use it a limited number of times (or until a given amount). On the other hand, by passing `PeriodicityType::Day` and 1 as its `periodicity_type` and `periodicity` respectively, we said that it should be renewed everyday. So a user could spend his minutes today and have it back tomorrow, for instance. > It is important to keep in mind that both plans and consumable features have its periodicity, so your users can, for instance, have a monthly plan with weekly features. The other feature we defined was `$customDomain`, which was a not consumable feature. By being not consumable, this feature implies only that the users with access to it can perform a given action (in this case, use a custom domain). #### Postpaid Features You can set a feature so it can be used over its charges. To do so, you just have to set the `postpaid` attribute to `true`: This way, the user will be able to use the feature until the end of the period, even if he doesn't have enough charges to use it (and you can charge him later, for instance). #### Quota Features When creating, for instance, a file storage system, you'll have to increase and decrease feature consumption as your users upload and delete files. To achieve this easily, you can use quota features. These features have an unique, unexpirable consumption, so they can reflect a constant value (as used system storage in this example). In the example above, we set `storage` as a quota feature inside the seeder. Then, on the controller, our code store an uploaded file on a folder, calculate this folder size by retrieving all of its subfiles, and, finally, set the consumed `storage` quota as the directory total size. ### Creating Plans Now you need to define the plans available to subscription in your app: Everything here is quite simple, but it is worth to emphasize: by receiving the periodicity options above, the two plans are defined as monthly. #### Plans Without Periodicity ("Free Plans" or "Permanent Plans") You can define plans without periodicity, so your users can subscribe to them permanently (or until they cancel their subscriptions). To do so, just pass a `null` value to the `periodicity_type` and `periodicity` attributes: #### Grace Days You can define a number of grace days to each plan, so your users will not loose access to their features immediately on expiration: With the configuration above, the subscribers of the "gold" plan will have seven days between the plan expiration and their access being suspended. ### Associating Plans with Features As each feature can belong to multiple plans (and they can have multiple features), you have to associate them: It is necessary to pass a value to `charges` when associating a consumable feature with a plan. In the example above, we are giving 15 minutes of deploy time to silver users and 25 to gold users. We are also allowing gold users to use subdomains. ### Subscribing Now that you have a set of plans with their own features, it is time to subscribe users to them. Registering subscriptions is quite simple: In the example above, we are simulating an application that subscribes its users when their payments are approved. It is easy to see that the method `subscribeTo` requires only one argument: the plan the user is subscribing to. There are other options you can pass to it to handle particular cases that we're gonna cover below. > By default, the `subscribeTo` method calculates the expiration considering the plan periodicity, so you don't have to worry about it. #### Defining Expiration and Start Date You can override the subscription expiration by passing the `$expiration` argument to the method call. Below, we are setting the subscription of a given user to expire only in the next year. It is possible also to define when a subscription will effectively start (the default behavior is to start it immediately): Above, we are simulating an application for a school. It has to subscribe students at their registration, but also ensure their subscription will make effect only when the course starts. ### Switching Plans Users change their mind all the time and you have to deal with it. If you need to change the current plan of a user, simply call the method `switchTo`: If you don't pass any arguments, the method will suppress the current subscription and start a new one immediately. > This call will fire a `SubscriptionStarted(Subscription $subscription)` event. ### Fetching Current Balance If you need remaining charges of a user, simply call the method `balance`. Imagine a scenario where a student has consumable feature named `notes-download`. To get remaining downloads limit: > This is just an alias of `getRemainingCharges` added to enrich the developer experience. #### Scheduling a Switch If you want to keep your user with the current plan until its expiration, pass the `$immediately` parameter as `false`: In the example above, the user will keep its monthly subscription until its expiration and then start on the yearly plan. This is pretty useful when you don't want to deal with partial refunds, as you can bill your user only when the current paid plan expires. Under the hood, this call will create a subscription with a start date equal to the current expiration, so it won't affect your application until there. > This call will fire a `SubscriptionScheduled(Subscription $subscription)` event. #### Renewing To renew a subscription, simply call the `renew()` method: > This method will fire a `SubscriptionRenewed(Subscription $subscription)` event. It will calculate a new expiration based on the current date. #### Expired Subscriptions In order to retrieve an expired subscription, you can use the `lastSubscription` method: This method will return the last subscription of the user, regardless of its status, so you can, for instance, get an expired subscription to renew it.: #### Canceling > There is a thing to keep in mind when canceling a subscription: it won't revoke the access immediately. To avoid making you need to handle refunds of any kind, we keep the subscription active and just mark it as canceled, so you just have to not renew it in the future. If you need to suppress a subscription immediately, give a look on the method `suppress()`. To cancel a subscription, use the method `cancel()`: This method will mark the subscription as canceled by filling the column `canceled_at` with the current timestamp. > This method will fire a `SubscriptionCanceled(Subscription $subscription)` event. #### Suppressing To suppress a subscription (and immediately revoke it), use the method `suppress()`: This method will mark the subscription as suppressed by filling the column `suppressed_at` with the current timestamp. > This method will fire a `SubscriptionSuppressed(Subscription $subscription)` event. #### Starting To start a subscription, use the method `start()`: > This method will fire a `SubscriptionStarted(Subscription $subscription)` event when no argument is passed, and fire a `SubscriptionStarted(Subscription $subscription)` event when the provided start date is future. This method will mark the subscription as started (or scheduled to start) by filling the column `started_at`. ### Feature Consumption To register a consumption of a given feature, you just have to call the `consume` method and pass the feature name and the consumption amount (you don't need to provide it for not consumable features): The method will check if the feature is available and throws exceptions if they are not: `OutOfBoundsException` if the feature is not available to the plan, and `OverflowException` if it is available, but the charges are not enough to cover the consumption. > This call will fire a `FeatureConsumed($subscriber, Feature $feature, FeatureConsumption $featureConsumption)` event. #### Check Availability To check if a feature is available to consumption, you can use one of the methods below: To check if a user can consume a certain amount of a given feature (it checks if the user has access to the feature and if he has enough remaining charges). It calls the `canConsume()` method under the hood and reverse the return. To simply checks if the user has access to a given feature (without looking for its charges). Similarly to `cantConsume`, it returns the reverse of `hasFeature`. ### Feature Tickets Tickets are a simple way to allow your subscribers to acquire charges for a feature. When a user receives a ticket, he is allowed to consume its charges, just like he would do in a normal subscription. Tickets can be used to extend regular subscriptions-based systems (so you can, for instance, sell more charges of a given feature) or even to **build a fully pre-paid service**, where your users pay only for what they want to use. #### Enabling Tickets In order to use this feature, you have to enable tickets in your configuration files. First, publish the package configs: ### Publish Subscription policy Finally, open the `soulbscription.php` file and set the `feature_tickets` flag to `true`. That's it, you now can use tickets! #### Creating Tickets To create a ticket, you can use the method `giveTicketFor`. This method expects the feature name, the expiration and optionally a number of charges (you can ignore it when creating tickets for not consumable features): > This method will fire a `FeatureTicketCreated($subscriber, Feature $feature, FeatureTicket $featureTicket)` event. In the example above, the user will receive ten more minutes to execute deploys until the next month. #### Not Consumable Features You can create tickets for not consumable features, so your subscribers will receive access to them just for a certain period: #### Non-Expirable Tickets You can create tickets that never expire, so your subscribers will receive access to them forever: > Don't forget to remove these tickets when your user cancels his subscription. Otherwise, they will be able to consume the charges forever. ## Testing ### Using Gates and Policies (Laravel Authorization) If you published the package policy, you can connect subscription checks with Laravel authorization so your business rules stay in one place. #### 1) Publish policy stubs #### 2) Register policy / gates In your `AuthServiceProvider`, register the policy (or define gates) so Laravel knows how to authorize actions: > Method names can vary depending on your package version/customization. Keep the feature keys (`deploy-minutes`, `custom-domain`) consistent with your seeders. #### 3) Use authorization in controllers #### 4) Use authorization in routes and Blade This pattern gives you: - a single source of truth for access rules, - clean controllers, - safer UI (buttons/forms hidden when user is not allowed), - easy upgrade path when plans/features evolve.

All versions of squarhe-subscription with dependencies

PHP Build Version
Package Version
Requires php Version ^8.2
illuminate/contracts Version ^10.0|^11.0|^12.0|^13.0
illuminate/database Version ^10.0|^11.0|^12.0|^13.0
illuminate/support Version ^10.0|^11.0|^12.0|^13.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package vnuswilliams/squarhe-subscription contains the following files

Loading the files please wait ...