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

For more details on the new API, refer to the PHP Core SDK documentation.

Behavioral changes

StatsigOptions changes

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

For a full list of new configuration options, refer to the PHP Core SDK documentation.

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 aren't 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