Add Sites migration support #142
Conversation
WalkthroughAdds first-class Site migration support across the toolchain. New resource types: site, site-deployment, site-variable with model classes Site, Deployment, EnvVar. Transfer gains GROUP_SITES and related resource lists. Source base adds getSitesBatchSize and abstract exportGroupSites; CSV, Firebase, JSON, NHost, MockSource add exportGroupSites stubs. Appwrite source implements site export (sites, deployments, variables) with chunked download logic. Appwrite destination adds a Sites client, scope checks, site/variable creation, and deployment upload/import handling. Tests/mocks updated to include the new resources. Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes 🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@src/Migration/Destinations/Appwrite.php`:
- Around line 215-222: The call to Framework::STATIC() is invalid for Appwrite
v19.1.0 and will fatal; update the Sites creation in Appwrite.php by removing or
replacing Framework::STATIC() in the $this->sites->create(...) call inside the
Resource::TYPE_SITE block: either drop the framework argument if optional, or
map the incoming 'static' value to the correct Framework enum (e.g.,
Framework::REACTSTATIC or another valid Framework constant) before calling
$this->sites->create; update any other occurrences (e.g., the earlier match
handling that uses Framework::STATIC()) to perform the same mapping so the code
uses a valid Framework enum instead of Framework::STATIC().
In `@src/Migration/Transfer.php`:
- Around line 39-43: exportGroupSites currently only triggers exportSites() when
Resource::TYPE_SITE is requested, so requesting Resource::TYPE_SITE_VARIABLE
alone omits variables; update exportGroupSites() to also check for
Resource::TYPE_SITE_VARIABLE and either call exportSites() when variables are
requested or add a separate code path to export variables from exportSites()
output. Modify the conditional that tests for Resource::TYPE_SITE to include
Resource::TYPE_SITE_VARIABLE (or add an explicit branch handling
Resource::TYPE_SITE_VARIABLE) so site variables are exported even if TYPE_SITE
is not present, referencing the GROUP_SITES_RESOURCES constant and using
existing exportSites() logic to perform the actual extraction.
| public const GROUP_SITES_RESOURCES = [ | ||
| Resource::TYPE_SITE, | ||
| Resource::TYPE_SITE_VARIABLE, | ||
| Resource::TYPE_SITE_DEPLOYMENT | ||
| ]; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check exportGroupSites implementations and site-variable handling
rg -n "exportGroupSites" -g'*.php' -C3
rg -n "TYPE_SITE_VARIABLE|SiteVariable|exportSiteVariable" -g'*.php' -C2Repository: utopia-php/migration
Length of output: 8444
🏁 Script executed:
sed -n '1479,1520p' src/Migration/Sources/Appwrite.phpRepository: utopia-php/migration
Length of output: 1335
🏁 Script executed:
rg -n "exportSiteVariable|exportVariable" -g'*.php' src/Migration/Sources/Appwrite.phpRepository: utopia-php/migration
Length of output: 46
🏁 Script executed:
rg -n "def exportSites|function exportSites|protected function exportSites" -g'*.php' -A20 src/Migration/Sources/Appwrite.php | head -50Repository: utopia-php/migration
Length of output: 865
🏁 Script executed:
sed -n '1728,1800p' src/Migration/Sources/Appwrite.phpRepository: utopia-php/migration
Length of output: 2497
🏁 Script executed:
rg -n "this->callback" src/Migration/Sources/Appwrite.php -B5 | head -30Repository: utopia-php/migration
Length of output: 744
🏁 Script executed:
rg -n "callback.*=" src/Migration/Sources/Appwrite.php | head -20Repository: utopia-php/migration
Length of output: 46
🏁 Script executed:
rg -n "callback" src/Migration/Source.php -B3 -A3Repository: utopia-php/migration
Length of output: 1246
Add explicit handling for TYPE_SITE_VARIABLE in exportGroupSites.
Site variables are embedded in the exportSites() output, but exportGroupSites() only calls exportSites() when TYPE_SITE is in the requested resources. If a user requests TYPE_SITE_VARIABLE alone without TYPE_SITE, variables will not be exported. Add an explicit check for TYPE_SITE_VARIABLE in exportGroupSites() that triggers the site export or variables separately.
🤖 Prompt for AI Agents
In `@src/Migration/Transfer.php` around lines 39 - 43, exportGroupSites currently
only triggers exportSites() when Resource::TYPE_SITE is requested, so requesting
Resource::TYPE_SITE_VARIABLE alone omits variables; update exportGroupSites() to
also check for Resource::TYPE_SITE_VARIABLE and either call exportSites() when
variables are requested or add a separate code path to export variables from
exportSites() output. Modify the conditional that tests for Resource::TYPE_SITE
to include Resource::TYPE_SITE_VARIABLE (or add an explicit branch handling
Resource::TYPE_SITE_VARIABLE) so site variables are exported even if TYPE_SITE
is not present, referencing the GROUP_SITES_RESOURCES constant and using
existing exportSites() logic to perform the actual extraction.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@src/Migration/Destinations/Appwrite.php`:
- Around line 1542-1635: The code uses Appwrite enums (Framework, Adapter,
BuildRuntime) that may not exist in the installed SDK and will throw fatal
errors; replace enum usage in the match blocks (the mappings that assign
$framework, $adapter, $buildRuntime from
$resource->getFramework()/getAdapter()/getBuildRuntime()) with plain string
values (or a validated string mapping) instead of Framework::*, Adapter::*,
BuildRuntime::* calls, or alternatively add a runtime guard (class_exists for
each enum) and fallback to the raw string when the enum class is missing; update
the match blocks in src/Migration/Destinations/Appwrite.php (the $framework,
$adapter, $buildRuntime assignments) to return strings (e.g., 'react', 'static',
'node-18.0') or use a safe mapping and remove direct enum references unless the
SDK dependency is constrained to a release that includes those enum classes.
| $buildRuntime = match ($resource->getBuildRuntime()) { | ||
| 'node-14.5' => BuildRuntime::NODE145(), | ||
| 'node-16.0' => BuildRuntime::NODE160(), | ||
| 'node-18.0' => BuildRuntime::NODE180(), | ||
| 'node-19.0' => BuildRuntime::NODE190(), | ||
| 'node-20.0' => BuildRuntime::NODE200(), | ||
| 'node-21.0' => BuildRuntime::NODE210(), | ||
| 'node-22' => BuildRuntime::NODE22(), | ||
| 'php-8.0' => BuildRuntime::PHP80(), | ||
| 'php-8.1' => BuildRuntime::PHP81(), | ||
| 'php-8.2' => BuildRuntime::PHP82(), | ||
| 'php-8.3' => BuildRuntime::PHP83(), | ||
| 'ruby-3.0' => BuildRuntime::RUBY30(), | ||
| 'ruby-3.1' => BuildRuntime::RUBY31(), | ||
| 'ruby-3.2' => BuildRuntime::RUBY32(), | ||
| 'ruby-3.3' => BuildRuntime::RUBY33(), | ||
| 'python-3.8' => BuildRuntime::PYTHON38(), | ||
| 'python-3.9' => BuildRuntime::PYTHON39(), | ||
| 'python-3.10' => BuildRuntime::PYTHON310(), | ||
| 'python-3.11' => BuildRuntime::PYTHON311(), | ||
| 'python-3.12' => BuildRuntime::PYTHON312(), | ||
| 'python-ml-3.11' => BuildRuntime::PYTHONML311(), | ||
| 'python-ml-3.12' => BuildRuntime::PYTHONML312(), | ||
| 'dart-3.0' => BuildRuntime::DART30(), | ||
| 'dart-3.1' => BuildRuntime::DART31(), | ||
| 'dart-3.3' => BuildRuntime::DART33(), | ||
| 'dart-3.5' => BuildRuntime::DART35(), | ||
| 'dart-3.8' => BuildRuntime::DART38(), | ||
| 'dart-3.9' => BuildRuntime::DART39(), | ||
| 'dart-2.15' => BuildRuntime::DART215(), | ||
| 'dart-2.16' => BuildRuntime::DART216(), | ||
| 'dart-2.17' => BuildRuntime::DART217(), | ||
| 'dart-2.18' => BuildRuntime::DART218(), | ||
| 'dart-2.19' => BuildRuntime::DART219(), | ||
| 'deno-1.21' => BuildRuntime::DENO121(), | ||
| 'deno-1.24' => BuildRuntime::DENO124(), | ||
| 'deno-1.35' => BuildRuntime::DENO135(), | ||
| 'deno-1.40' => BuildRuntime::DENO140(), | ||
| 'deno-1.46' => BuildRuntime::DENO146(), | ||
| 'deno-2.0' => BuildRuntime::DENO20(), | ||
| 'dotnet-6.0' => BuildRuntime::DOTNET60(), | ||
| 'dotnet-7.0' => BuildRuntime::DOTNET70(), | ||
| 'dotnet-8.0' => BuildRuntime::DOTNET80(), | ||
| 'java-8.0' => BuildRuntime::JAVA80(), | ||
| 'java-11.0' => BuildRuntime::JAVA110(), | ||
| 'java-17.0' => BuildRuntime::JAVA170(), | ||
| 'java-18.0' => BuildRuntime::JAVA180(), | ||
| 'java-21.0' => BuildRuntime::JAVA210(), | ||
| 'java-22' => BuildRuntime::JAVA22(), | ||
| 'swift-5.5' => BuildRuntime::SWIFT55(), | ||
| 'swift-5.8' => BuildRuntime::SWIFT58(), | ||
| 'swift-5.9' => BuildRuntime::SWIFT59(), | ||
| 'swift-5.10' => BuildRuntime::SWIFT510(), | ||
| 'kotlin-1.6' => BuildRuntime::KOTLIN16(), | ||
| 'kotlin-1.8' => BuildRuntime::KOTLIN18(), | ||
| 'kotlin-1.9' => BuildRuntime::KOTLIN19(), | ||
| 'kotlin-2.0' => BuildRuntime::KOTLIN20(), | ||
| 'cpp-17' => BuildRuntime::CPP17(), | ||
| 'cpp-20' => BuildRuntime::CPP20(), | ||
| 'bun-1.0' => BuildRuntime::BUN10(), | ||
| 'bun-1.1' => BuildRuntime::BUN11(), | ||
| 'go-1.23' => BuildRuntime::GO123(), | ||
| 'static-1' => BuildRuntime::STATIC1(), | ||
| 'flutter-3.24' => BuildRuntime::FLUTTER324(), | ||
| 'flutter-3.27' => BuildRuntime::FLUTTER327(), | ||
| 'flutter-3.29' => BuildRuntime::FLUTTER329(), | ||
| 'flutter-3.32' => BuildRuntime::FLUTTER332(), | ||
| 'flutter-3.35' => BuildRuntime::FLUTTER335(), | ||
| default => throw new \Exception('Invalid Build Runtime: ' . $resource->getBuildRuntime()), | ||
| }; | ||
|
|
||
| $framework = match ($resource->getFramework()) { | ||
| 'analog' => Framework::ANALOG(), | ||
| 'angular' => Framework::ANGULAR(), | ||
| 'astro' => Framework::ASTRO(), | ||
| 'flutter', 'flutter-web' => Framework::FLUTTER(), | ||
| 'lynx' => Framework::LYNX(), | ||
| 'nextjs' => Framework::NEXTJS(), | ||
| 'nuxt' => Framework::NUXT(), | ||
| 'react' => Framework::REACT(), | ||
| 'react-native' => Framework::REACTNATIVE(), | ||
| 'remix' => Framework::REMIX(), | ||
| 'svelte-kit' => Framework::SVELTEKIT(), | ||
| 'tanstack-start' => Framework::TANSTACKSTART(), | ||
| 'vite' => Framework::VITE(), | ||
| 'vue' => Framework::VUE(), | ||
| default => Framework::OTHER(), | ||
| }; | ||
|
|
||
| $adapter = match ($resource->getAdapter()) { | ||
| 'static' => Adapter::STATIC(), | ||
| 'ssr' => Adapter::SSR(), | ||
| default => null, | ||
| }; |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Appwrite PHP SDK v19.0.0 Framework enum
💡 Result:
In Appwrite PHP SDK 19.0.0 (tagged Dec 2, 2025) the Sites service’s framework parameter is typed using the Framework enum (namespace Appwrite\Enums). (github.com)
Usage pattern (as shown in the PHP Sites API docs):
use Appwrite\Enums\Framework;
$sites->update(
siteId: '<SITE_ID>',
name: '<NAME>',
framework: Framework::ANALOG(),
);The enum values correspond to the frameworks Appwrite Sites supports (and “Other”), e.g. Next.js, Nuxt, SvelteKit, Angular, Astro, Remix, TanStack Start, Flutter Web, React Native, Other JavaScript. (appwrite.io)
Citations:
- 1: https://github.com/appwrite/sdk-for-php/tags
- 2: https://appwrite.io/docs/references/cloud/server-php/sites?utm_source=openai
- 3: https://appwrite.io/docs/products/sites/frameworks?utm_source=openai
🌐 Web query:
Appwrite PHP SDK v19.0.0 BuildRuntime enum Flutter
💡 Result:
- Appwrite PHP SDK
v19.0.0exists as the Composer packageappwrite/appwrite(with newer versions available, e.g.19.1.0). [1] - “buildRuntime” is a Sites build setting (server-side / Console + Sites API), not a Flutter SDK concept. Appwrite’s Flutter Web Sites flow is driven by selecting Framework = “Flutter Web” and using the default Flutter build commands/output (e.g.,
flutter pub get,flutter build web ..., output./build/web). [2] - If you’re trying to create a Flutter Web Site via API/SDK and you’re seeing “missing buildRuntime”, that error has been reported by users for Flutter Sites creation in the Console. [3] Appwrite later noted they “updated Flutter default build runtime” in the Appwrite
1.8.1self-hosted release notes/changelog, so upgrading your Appwrite server may be relevant. [4]
If you share the exact PHP call you’re making (which Sites API method + parameters), I can tell you what field maps to buildRuntime and what values your SDK exposes for it.
Sources: [1] Packagist appwrite/appwrite (PHP SDK versions) • [2] Appwrite Docs: Deploy a Flutter Web app to Sites • [3] Appwrite Thread: “missing buildRuntime” for Flutter Sites • [4] Appwrite changelog: Appwrite 1.8.1 (“Updated Flutter default build runtime”)
🏁 Script executed:
# Check composer.json or other dependency files to see which Appwrite SDK version is specified
find . -name "composer.json" -o -name "composer.lock" | head -5Repository: utopia-php/migration
Length of output: 95
🏁 Script executed:
cat ./composer.json | grep -A 10 "require"Repository: utopia-php/migration
Length of output: 639
🌐 Web query:
Appwrite PHP SDK v19.0.0 GitHub Framework enum class definition REACTNATIVE TANSTACKSTART
💡 Result:
In Appwrite PHP SDK 19.0.0, there is no Framework enum class in the repo (so you won’t find enum values like REACTNATIVE or TANSTACKSTART there). The 19.0.0 code at commit b0a3ffd shows only these enums under src/Appwrite/Enums: BuildRuntime, Runtime, TemplateReferenceType, VCSReferenceType. [1]
Also, the Sites PHP API reference shows use Appwrite\Enums\; and framework: ::ANALOG() (i.e., the docs intend an enum usage), but it doesn’t correspond to an actual Framework enum shipped in PHP SDK 19.0.0. [2]
If you’re trying to select React Native or TanStack Start as an Appwrite Sites “framework”, that’s a Sites feature/framework key, and TanStack Start support is documented on the Sites side (not via a PHP SDK enum in 19.0.0). [3]
Sources:
[1] appwrite/sdk-for-php@b0a3ffd
[2] https://appwrite.io/docs/references/cloud/server-php/sites
[3] https://appwrite.io/changelog/entry/2025-10-28
🌐 Web query:
Appwrite PHP SDK v19.0.0 GitHub BuildRuntime enum FLUTTER methods
💡 Result:
Appwrite PHP SDK 19.0.0 is a real tagged release (published Dec 3, 2025) in appwrite/sdk-for-php. In its GitHub release notes, 19.0.0 mentions enum/service changes like renaming VCSDeploymentType → VCSReferenceType, changing createTemplateDeployment parameters, and adding Theme, Timezone, and Output enums—but it does not mention BuildRuntime specifically. [1]
Packagist also lists appwrite/appwrite version 19.0.0 (same codebase as appwrite/sdk-for-php). [2]
If you’re trying to find the BuildRuntime enum’s Flutter-related entries/methods in v19.0.0, the authoritative place is the SDK source at tag 19.0.0, typically under something like src/Appwrite/Enums/BuildRuntime.php in the repo. [3]
Sources
[1] https://github.com/appwrite/sdk-for-php/releases (see “19.0.0”)
[2] https://packagist.org/packages/appwrite/appwrite
[3] https://github.com/appwrite/sdk-for-php/tree/19.0.0
🌐 Web query:
Appwrite PHP SDK v19.0.0 BuildRuntime enum source code methods
💡 Result:
In Appwrite PHP SDK 19.0.0 (composer package appwrite/appwrite), the BuildRuntime enum lives at:
src/Appwrite/Enums/BuildRuntime.php(github.com)
Because it’s an auto-generated “enum class” (not a native PHP 8.1 enum), its “enum values” are exposed as static methods on the class (e.g. BuildRuntime::SOME_RUNTIME() returning a string value).
How to get the exact method list (from the v19.0.0 source you have installed)
- Install the exact version:
composer require appwrite/appwrite:19.0.0- Open:
vendor/appwrite/appwrite/src/Appwrite/Enums/BuildRuntime.php
Or, from your project root:
sed -n '1,200p' vendor/appwrite/appwrite/src/Appwrite/Enums/BuildRuntime.phpThat file is the source of truth for the complete list of BuildRuntime::...() methods in v19.0.0. (github.com)
Citations:
🌐 Web query:
Appwrite PHP SDK Framework enum when introduced first version
💡 Result:
Appwrite’s Enum support (the SDK feature that adds enum/enum-like types) was announced on Feb 28, 2024. [1]
For the Appwrite PHP SDK, enum support was first shipped in v17.2.0, released on Oct 3, 2025 (“introduces support of enums in response models”). [2]
So, the first PHP SDK version where a Framework enum (or any other newly generated enums) could appear is: 17.2.0. [2]
Sources:
[1] https://appwrite.io/changelog/entry/2024-02-28
[2] https://github.com/appwrite/sdk-for-php/releases/tag/17.2.0
🏁 Script executed:
# Check if there's any reference to these enums in the codebase or imports
rg "use Appwrite.*Framework|use Appwrite.*BuildRuntime|use Appwrite.*Adapter" --type phpRepository: utopia-php/migration
Length of output: 274
🌐 Web query:
Appwrite PHP SDK v19.1.0 Framework enum
💡 Result:
In Appwrite PHP SDK 19.1.0 (appwrite/appwrite on Packagist), there is no Framework enum shipped with the SDK. [1]
Appwrite’s official SDK docs list the enums that are generated/available (OAuth providers, authenticator types, browsers, index types, image format/gravity, function runtime, etc.), and “Framework” is not one of them. [2]
So if you’re looking for a “framework” parameter (e.g., laravel, symfony, etc.), you’ll need to pass it as a plain string (if a specific API expects it) or define your own enum/constants in your app.
Sources:
[1] https://packagist.org/packages/appwrite/appwrite
[2] https://appwrite.io/docs/sdks
🌐 Web query:
Appwrite PHP SDK latest version Framework enum Adapter enum
💡 Result:
- Latest Appwrite PHP SDK version (Composer package
appwrite/appwrite): 19.1.0 (released 2025-12-18). (packagist.org) - Framework enum (PHP SDK):
Appwrite\Enums\Framework(used for Sitesframework:likeFramework::ANALOG()). (appwrite.io) - Adapter enum (PHP SDK):
Appwrite\Enums\Adapter(used for Sitesadapter:likeAdapter::STATIC()). Allowed adapter values are static and ssr (enum helpers:Adapter::STATIC()/Adapter::SSR()). (appwrite.io)
Example (from Sites API docs, PHP):
use Appwrite\Enums\Framework;
use Appwrite\Enums\Adapter;
framework: Framework::ANALOG(),
adapter: Adapter::STATIC(),Citations:
- 1: https://packagist.org/packages/appwrite/appwrite
- 2: https://appwrite.io/docs/references/cloud/server-php/sites
- 3: https://appwrite.io/docs/references/cloud/server-php/sites
- 4: https://appwrite.io/docs/references/cloud/server-php/sites
🏁 Script executed:
# Try to read BuildRuntime enum if it exists in vendor
if [ -f "vendor/appwrite/appwrite/src/Appwrite/Enums/BuildRuntime.php" ]; then
head -100 vendor/appwrite/appwrite/src/Appwrite/Enums/BuildRuntime.php
else
echo "BuildRuntime.php not found - may need to install dependencies"
fiRepository: utopia-php/migration
Length of output: 125
🏁 Script executed:
# Check what version is actually installed
composer show appwrite/appwrite 2>/dev/null | head -5Repository: utopia-php/migration
Length of output: 46
🌐 Web query:
site:github.com appwrite/sdk-for-php Framework enum class
💡 Result:
In appwrite/sdk-for-php there is no Framework enum/class (i.e., no Appwrite\Enums\Framework).
Appwrite’s docs list the SDK enum types that are generated/provided (authenticator type/name, OAuth provider, browsers, credit cards, image gravity/format, relationship types, SMTP encryption, function runtime, messaging provider type, compression algorithms, execution methods, country flags, etc.), and “framework” is not one of them. [1]
Source: appwrite/sdk-for-php is the official PHP SDK repo referenced by Appwrite/Packagist. [2]
References:
[1] (appwrite.io)
[2] (packagist.org)
Citations:
- 1: https://appwrite.io/docs/sdks?utm_source=openai
- 2: https://packagist.org/packages/appwrite/appwrite?utm_source=openai
🌐 Web query:
site:github.com appwrite/sdk-for-php/releases Framework enum Sites support
💡 Result:
As of the latest Appwrite PHP SDK release (19.1.0, Dec 18, 2025), the release notes don’t mention adding any Sites “Framework” enum (or updating enums for Sites framework selection) — the only listed change is about creating columns/indexes synchronously when creating a table. (github.com)
Also, Appwrite’s SDK documentation lists the kinds of enums the SDKs provide (auth providers, runtimes, etc.) and does not list a Sites “Framework” enum. (appwrite.io)
If you’re looking for the supported Appwrite Sites frameworks (Next.js, Nuxt, SvelteKit, etc.), they’re documented in the Sites “Frameworks” page. (appwrite.io)
Citations:
- 1: https://github.com/appwrite/sdk-for-php/releases/tag/19.1.0
- 2: https://appwrite.io/docs/sdks?utm_source=openai
- 3: https://appwrite.io/docs/products/sites/frameworks?utm_source=openai
🏁 Script executed:
# Check the actual file in the repo to see what enums are being used
head -50 src/Migration/Destinations/Appwrite.php | grep -A 5 -B 5 "Framework\|BuildRuntime\|Adapter"Repository: utopia-php/migration
Length of output: 429
🌐 Web query:
site:github.com/appwrite/sdk-for-php "class Framework" enums
💡 Result:
A web search for site:github.com/appwrite/sdk-for-php "class Framework" doesn’t turn up any matches in the appwrite/sdk-for-php repository (it’s also marked read-only). [1]
However, Appwrite’s Sites PHP API reference shows that the PHP SDK does expose a framework enum-like type as Appwrite\Enums\Framework, used like Framework::ANALOG() when creating/updating a Site. [2]
🌐 Web query:
Appwrite PHP SDK when will Framework enum be added Sites API
💡 Result:
As of the latest released Appwrite PHP SDK on Packagist (appwrite/appwrite 19.1.0, released Dec 18, 2025), the Sites API “framework” enum (e.g., Framework::ANALOG) is not yet available in the PHP SDK (the PHP Sites docs still show blank enum imports like use Appwrite\Enums\; for framework). [1] [2]
There’s currently an open PR in appwrite/sdk-for-php — #57 “Updates: sync as per latest cloud specs” (opened Jan 14, 2026) — which is the likely vehicle for adding missing/updated spec items like the Sites framework enum, but no ETA is published; it will land when that PR is merged and a new PHP SDK release is cut. [3]
Workaround until then: pass the framework value as the raw string expected by the API (e.g., "analog") instead of an enum. [2]
Sources:
[1] https://packagist.org/packages/appwrite/appwrite (release info + repo link)
[2] https://appwrite.io/docs/references/cloud/server-php/sites (PHP Sites API reference showing missing enum import)
[3] https://github.com/appwrite/sdk-for-php/pulls (shows PR #57 opened Jan 14, 2026)
Remove Framework enum usage or constrain SDK version to post-Framework support release.
The Framework enum (Appwrite\Enums\Framework) does not exist in Appwrite PHP SDK v19.0.0 or v19.1.0. The import statement will cause a fatal "Class not found" error, preventing the entire migration class from loading. The Appwrite PHP SDK team is working to add Sites framework enum support (PR #57, opened Jan 14, 2026), but no release with this enum is currently available.
Either:
- Remove the Framework enum and pass framework as a string (e.g.,
'analog','flutter','react') until the SDK adds the enum. - Constrain the SDK dependency to a future version that includes the Framework enum (once released and documented).
The same validation should apply to Adapter and BuildRuntime enums to ensure they are fully supported in the installed SDK version before use.
🤖 Prompt for AI Agents
In `@src/Migration/Destinations/Appwrite.php` around lines 1542 - 1635, The code
uses Appwrite enums (Framework, Adapter, BuildRuntime) that may not exist in the
installed SDK and will throw fatal errors; replace enum usage in the match
blocks (the mappings that assign $framework, $adapter, $buildRuntime from
$resource->getFramework()/getAdapter()/getBuildRuntime()) with plain string
values (or a validated string mapping) instead of Framework::*, Adapter::*,
BuildRuntime::* calls, or alternatively add a runtime guard (class_exists for
each enum) and fallback to the raw string when the enum class is missing; update
the match blocks in src/Migration/Destinations/Appwrite.php (the $framework,
$adapter, $buildRuntime assignments) to return strings (e.g., 'react', 'static',
'node-18.0') or use a safe mapping and remove direct enum references unless the
SDK dependency is constrained to a release that includes those enum classes.
Summary
Test plan
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.