Php Core SDK Migration Guide

Why migrate?

• Performance: PHP Core evaluates faster than the legacy SDK.
• New Features: Access to Parameter Stores, CMAB (Contextual Multi-Armed Bandits), observabilityClient, and more.
• Future Support: All new features and improvements are only available in PHP Core.
• Maintenance: The legacy PHP SDK is in maintenance mode and only receives critical bug fixes.

Installation and setup

For the PHP Core SDK, configure composer.json to run the provided post-install.php file:

composer require statsig/statsig-php-core

// composer.json
{
  "name": "awesome-php-project",
  ...
  "scripts": {
    ...
    "post-install-cmd": [
      "cd vendor/statsig/statsig-php-core && php post-install.php"
    ],
    "post-update-cmd": [
      "cd vendor/statsig/statsig-php-core && php post-install.php"
    ]
  }
}

Both require a cron job to fetch configs and flush events:

# Setup chron job / scheduled job to sync config and flush events
*/1 * * * * /usr/bin/php /var/www/example.com/bin/StatsigSyncConfig.php 1>> /dev/null 2>&1
*/1 * * * * /usr/bin/php /var/www/example.com/bin/StatsigFlushEvents.php 1>> /dev/null 2>&1

StatsigUser

// We introduced the user builder pattern
$user_builder = StatsigUserBuilder::withUserID('my_user');
$user_builder->withEmail("example@abc.com");
$user = $user_builder->build()

API changes

Key package and class changes

Behavioral changes

StatsigOptions changes

The table below shows the mapping between legacy SDK options and Server Core SDK options:

Recommended migration path

1. Add the new Dependencies

   • Add the new SDK package/module and any required platform-specific dependencies for your environment.
   • Update import or require statements to reference the new SDK namespace or module.
   • Keep the old package in place during local testing; having both running in parallel briefly can help. Alias the new package if needed.

2. Update Initialization

   • Switch to the new initialization syntax. New SDK keys are not required. If you update them, ensure they have the same target apps.
   • Use the appropriate builder or configuration pattern for setting options, and migrate the StatsigOptions you use, because some were renamed.

3. Update User Creation

   • Migrate to the new format for creating user objects.
   • Use the builder pattern or updated constructor to set user properties if needed.

4. Update Method Calls

   • Start by migrating a few calls, replacing oldStatsig.getExperiment() with newStatsig.getExperiment().
   • Test your service locally or with existing test patterns to build confidence in the new SDK's operation.
   • As you migrate additional calls, update method names that changed (notably, get_config() to get_dynamic_config()).
   • After completing the initial migration, use refactoring tools to migrate remaining calls in bulk.

5. Test Thoroughly

   • Verify that all of your configs are successfully migrated - run your test suites end-to-end.

6. Remove old SDK

   • Remove references to the old SDK, and clean up old initialization and import logic.

Need help?

If you encounter any issues during migration, reach out:

• Statsig Slack Community
• GitHub Issues