Download the PHP package featurevisor/featurevisor-php without Composer

On this page you can find all versions of the php package featurevisor/featurevisor-php. 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 featurevisor/featurevisor-php

Informations about the package featurevisor-php

Featurevisor PHP SDK

This is a port of Featurevisor Javascript SDK v3.x to PHP, providing a way to evaluate feature flags, variations, and variables in your PHP applications.

This SDK is compatible with Featurevisor v3.0 projects and v2 datafiles.

Table of contents

Installation

The Featurevisor PHP SDK requires PHP 8.0 or newer. Install it using Composer:

Public API

The main runtime API is Featurevisor::createFeaturevisor():

Most applications only need this factory and the returned Featurevisor instance. Public extension and observability APIs include modules, diagnostics, events, and the datafile arrays accepted by the factory.

Treat an instance as request-owned in normal PHP applications. If a long-running parallel runtime shares an instance, serialize calls that mutate or close it. Module, event, and diagnostic callbacks are responsible for synchronizing mutable state that they capture.

Initialization

The SDK can be initialized by passing datafile content directly:

Evaluation types

We can evaluate 3 types of values against a particular feature:

These evaluations are run against the provided context.

Context

Contexts are attribute values that we pass to SDK for evaluating features against.

Think of the conditions that you define in your segments, which are used in your feature's rules.

They are plain objects:

Context can be passed to SDK instance in various different ways, depending on your needs:

Setting initial context

You can set context at the time of initialization:

This is useful for values that don't change too frequently and available at the time of application startup.

Setting after initialization

You can also set more context after the SDK has been initialized:

This will merge the new context with the existing one (if already set).

Replacing existing context

If you wish to fully replace the existing context, you can pass true in second argument:

Manually passing context

You can optionally pass additional context manually for each and every evaluation separately, without needing to set it to the SDK instance affecting all evaluations:

When manually passing context, it will merge with existing context set to the SDK instance before evaluating the specific value.

Further details for each evaluation types are described below.

Check if enabled

Once the SDK is initialized, you can check if a feature is enabled or not:

You can also pass additional context per evaluation:

Getting variation

If your feature has any variations defined, you can evaluate them as follows:

Additional context per evaluation can also be passed:

Getting variables

Your features may also include variables, which can be evaluated as follows:

Additional context per evaluation can also be passed:

Type specific methods

Next to generic getVariable() methods, there are also type specific methods available for convenience:

Type specific methods do not coerce values. getVariableInteger() returns null for the string "1", and boolean getters return null for non-boolean values.

Global variables use the same methods without a feature key:

Global variables honour sticky values, required features, and the first matching override. When an override contains both conditions and segments, both must match.

Getting all evaluations

You can get evaluations of all features available in the SDK instance:

This is handy especially when you want to pass all evaluations from a backend application to the frontend.

Sticky features and variables

For the lifecycle of the SDK instance in your application, you can set some features with sticky values, meaning that they will not be evaluated against the fetched datafile:

Sticky values belong to an SDK or child instance. Evaluation options do not accept sticky overrides. Pass stickyFeatures or stickyVariables when a child needs its own state.

Initialize with sticky

Once initialized with sticky features, the SDK will look for values there first before evaluating the targeting conditions and going through the bucketing process.

Set sticky afterwards

You can also set sticky features after the SDK is initialized:

Setting datafile

You may also initialize the SDK without passing datafile, and set it later on:

Merging by default

By default, setDatafile($datafileContent) merges the incoming datafile with the SDK instance's existing datafile:

This means you can call setDatafile more than once with different datafiles, and the SDK instance accumulates their features and segments together.

Replacing

To replace the stored datafile completely, pass true as the second argument:

Loading datafiles on demand

Because merging is the default, a single SDK instance can start with a small datafile and load more datafiles later as your application needs them, instead of downloading every feature upfront.

This pairs well with targets, where each target produces a smaller datafile for a specific part of your application:

Updating datafile

You can set the datafile as many times as you want in your application, which will result in emitting a datafile_set event that you can listen and react to accordingly.

The triggers for setting the datafile again can be:

Diagnostics

By default, Featurevisor reports diagnostics to the console for info level and above with a [Featurevisor] prefix.

Levels

Available diagnostic levels are fatal, error, warn, info, and debug.

Set the level during initialization or update it afterwards:

Handler

Use onDiagnostic to send structured diagnostics to your observability system:

Every diagnostic has level, code, message, and an object-shaped details value. Optional module, moduleName, and originalError fields describe provenance. Evaluation metadata belongs in details.

Diagnostic handlers are isolated from SDK behaviour. An exception in a handler does not stop other handlers or evaluations.

Events

Featurevisor SDK implements a simple event emitter that allows you to listen to events that happen in the runtime.

You can listen to these events that can occur at various stages in your application:

datafile_set

The features array will contain keys of features that have either been:

compared to the previous datafile content that existed in the SDK instance.

context_set

sticky_features_set and sticky_variables_set

error

The error event is emitted for diagnostics whose level is error.

Evaluation details

Besides logging with debug level enabled, you can also get more details about how the feature variations and variables are evaluated in the runtime against given context:

For global variables, omit the feature key:

The returned object always contains reason. Feature evaluations also contain featureKey. Global variable evaluations contain variableKey without a featureKey.

And optionally these properties depending on whether you are evaluating a feature variation or a variable:

Modules

Modules allow you to intercept the evaluation process, report diagnostics, and customize behaviour further as per your needs.

Defining a module

A module is a simple array with optional lifecycle callbacks. A name is optional, but when provided it must be unique:

If setup throws, the module is not registered. Featurevisor removes subscriptions created during setup, reports module_setup_error, and calls close when present.

For feature evaluations, all before callbacks run in registration order, followed by all beforeEvaluation callbacks. After evaluation and caller defaults, all afterEvaluation callbacks run, followed by all after callbacks. Global variable evaluations use only beforeEvaluation and afterEvaluation. Required feature checks run through the complete module pipeline, and transformed defaults are preserved.

before and after remain available as deprecated feature-only compatibility callbacks. Use beforeEvaluation and afterEvaluation for new modules so the same callbacks can handle feature and global variable evaluations.

Registering modules

You can register modules at the time of SDK initialization:

Or after initialization:

Child instance

A child snapshots the parent keys that exist when it is spawned. Child values win for those keys. Parent keys introduced later are still inherited. Calling close() removes both child-owned listeners and subscriptions delegated to the parent.

When dealing with purely client-side applications, it is understandable that there is only one user involved, like in browser or mobile applications.

But when using Featurevisor SDK in server-side applications, where a single server instance can handle multiple user requests simultaneously, it is important to isolate the context for each request.

That's where child instances come in handy:

Now you can pass the child instance where your individual request is being handled, and you can continue to evaluate features targeting that specific user alone:

Similar to parent SDK, child instances also support several additional methods:

Close

Both primary and child instances support a .close() method. The primary instance also closes registered modules and removes diagnostic subscriptions.

CLI usage

This package also provides a CLI tool for running your Featurevisor project's test specs and benchmarking against this PHP SDK:

All three commands accept repeatable --target=<target> options. test builds only the selected Target datafiles and runs untargeted assertions plus assertions for those targets. benchmark and assess-distribution run independently against every selected Target datafile. Without --target, existing project-wide behaviour is preserved. Project definitions, test specs, Target discovery, and datafile generation continue to come from the Node.js CLI.

Test

Learn more about testing here.

Additional options that are available:

If assertions include target, the runner builds and selects the corresponding Target datafile automatically via npx featurevisor build --target=<target> --environment=<env> --json.

Benchmark

Learn more about benchmarking here.

Assess distribution

Learn more about assessing distribution here.

OpenFeature

The provider targets OpenFeature PHP SDK 2.x. OpenFeature remains optional and is not installed or loaded by the base Featurevisor SDK.

Installation

Provider setup

The current OpenFeature PHP SDK does not expose provider shutdown through its API. Call $provider->shutdown() when your application shuts down. This closes a Featurevisor instance created by the provider and releases provider subscriptions.

Flag key mapping

OpenFeature key Featurevisor evaluation
checkout Boolean flag for checkout
checkout:variation Variation value for checkout
checkout:title Variable title for checkout
variable:supportEmail Global variable supportEmail

Boolean variables use the boolean resolver. Integer and double variables use their matching numeric resolvers. Arrays, objects, and JSON variables use the object resolver.

The first separator divides the feature key from the selector. Use keySeparator and variationKey when project keys require a different grammar:

This makes checkout/$variation the variation key and checkout/title a variable key.

Global variables use the variable prefix by default. Configure globalVariablePrefix when that word is already meaningful in your project:

This maps global:supportEmail to the global variable supportEmail.

Context mapping

OpenFeature's targeting key maps to userId by default. Use targetingKeyField to map it to another Featurevisor context field:

OpenFeature context attributes are copied without mutating the incoming context. Nested arrays are preserved. Dates are normalized to UTC ISO strings with millisecond precision, matching the JavaScript provider.

Resolution details

The provider maps Featurevisor evaluation results to OpenFeature details:

Featurevisor result OpenFeature result
Required feature rule, forced, sticky, or rule match TARGETING_MATCH
Traffic allocation SPLIT
Unmet global variable requirements, disabled variation, or disabled variable DISABLED
No match or variable default DEFAULT
Missing feature, variable, or variations ERROR with FLAG_NOT_FOUND
Wrong resolver type ERROR with TYPE_MISMATCH
Invalid datafile ERROR with PARSE_ERROR
Evaluation failure ERROR with GENERAL

Errors return the default value supplied to OpenFeature. A malformed datafile uses the stable message Could not parse datafile. A later successful setDatafile() call clears the parse error.

Selected Featurevisor variations are exposed as the OpenFeature variant when available. OpenFeature PHP SDK 2.x does not expose flag metadata in resolution details, so Featurevisor metadata such as revision, rule key, and bucket value cannot currently be returned by this provider.

Tracking

Tracking is a no-op unless onTrack is configured:

Using an existing Featurevisor instance

You can reuse an existing Featurevisor instance:

The caller owns an instance passed this way. Calling $provider->shutdown() does not close it. Call $featurevisor->close() when every consumer is finished with it. When the provider creates the instance from options, the provider owns and closes it. If both are supplied, $featurevisor takes precedence over $options. Shutdown is safe to call more than once.

See the OpenFeature provider guide for resolution reasons, errors, lifecycle, and providers for other languages.

Example application

See a complete application using this SDK at featurevisor-example-php.

Development of this package

Setting up

Clone the repository, and install the dependencies using Composer:

Running tests

Run the complete local release check with:

The OpenFeature and base SDK tests can also be run separately with make test-openfeature and make test-base.

To run the SDK against Featurevisor example-1 from the local monorepo checkout:

Releasing

License

MIT © Fahad Heylaal

All versions of featurevisor-php with dependencies

PHP Build Version
Package Version
Requires php Version ^8.0
ext-json Version *
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 featurevisor/featurevisor-php contains the following files

Loading the files please wait ...