Update appwrite/appwrite SDK to ^27.0.0

[claudear]

What & why

A dependency update in appwrite/appwrite#12895 prompted keeping this playground current with the upstream Appwrite PHP SDK.

The linked upstream PR is a test-only reliability fix (it hardens a flaky realtime execution test) with no public API changes. The substantive work here is bumping the SDK to the latest release and adapting the playground to the SDK's response-model changes that have landed since ^12.0.0.

Changes

• composer.json — bump appwrite/appwrite from ^12.0.0 to ^27.0.0, and the PHP constraint from >=8.0 to >=8.2 (required by SDK 27).
• playground.php — SDK 27 hydrates API responses into typed readonly Model objects instead of associative arrays, so returned IDs are now read via property access ($response->id) instead of array access ($response['$id']). Six call sites updated (database, collection, bucket, file, function, async execution).
• Dockerfile — base image bumped from php:8.1.11-alpine3.16 to php:8.3-alpine to satisfy the SDK's PHP >=8.2 requirement.

Validation

• composer install resolves cleanly to appwrite/appwrite 27.0.0.
• php -l passes on playground.php and global.inc.php.
• Reflection check against the installed SDK confirms every method and named argument the playground uses still exists with compatible signatures (Databases, Storage, Users, Functions, plus the Runtime / ExecutionMethod enums).

Note: a full end-to-end run requires a live Appwrite instance, which isn't available in CI here; validation was done statically against the installed SDK.

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This PR upgrades the Appwrite PHP SDK from ^12.0.0 to ^27.0.0, adapting the playground to SDK 27's typed response model objects and raising the PHP runtime requirements to match.

• composer.json: SDK bumped to ^27.0.0 and PHP constraint raised from >=8.0 to >=8.2 to match the new SDK requirement.
• playground.php: Six array-access sites ($response['$id']) replaced with property access ($response->id) for the new typed model objects returned by SDK 27 service methods.
• Dockerfile: Base image updated from php:8.1.11-alpine3.16 to php:8.3-alpine to satisfy the PHP 8.2+ requirement; the new tag is floating rather than pinned to a specific patch release.

Confidence Score: 4/5

Safe to merge; the property-access migration is mechanically correct for SDK 27 and no logic is altered beyond the response-field accessor pattern.

The cloud function in createFunction() still targets the PHP 8.0 runtime, which is EOL and may no longer be available in the Appwrite server version this SDK targets. If that runtime was retired, the function creation step will fail at runtime. The Dockerfile also switches from a pinned image tag to a floating one, making future builds less reproducible. Both are non-blocking quality concerns with no impact on the core migration logic.

playground.php (Runtime::PHP80 usage) and Dockerfile (floating image tag) deserve a second look before merging.

Important Files Changed

Filename	Overview
playground.php	Six array-access sites migrated to property access for SDK v27 typed model objects; Runtime::PHP80() still used for cloud function creation despite PHP 8.0 being EOL
Dockerfile	Base image bumped from pinned php:8.1.11-alpine3.16 to floating php:8.3-alpine, losing patch-level pinning and making builds less reproducible over time
composer.json	SDK bumped from ^12.0.0 to ^27.0.0 and PHP constraint raised from >=8.0 to >=8.2, matching SDK 27's requirements

Comments Outside Diff (1)

1. playground.php, line 407 (link)

   The playground now uses PHP 8.3 (Dockerfile) and requires PHP >=8.2 (composer.json), but still creates cloud functions with the PHP 8.0 runtime — which reached end-of-life in November 2023. If Appwrite server 1.9.x has retired the php-8.0 runtime executor, createFunction will fail at runtime. Updating to a current PHP runtime makes the playground more representative anyway.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: playground.php
   Line: 407
   
   Comment:
   The playground now uses PHP 8.3 (Dockerfile) and requires PHP `>=8.2` (composer.json), but still creates cloud functions with the PHP 8.0 runtime — which reached end-of-life in November 2023. If Appwrite server 1.9.x has retired the `php-8.0` runtime executor, `createFunction` will fail at runtime. Updating to a current PHP runtime makes the playground more representative anyway.
   
   
   
   How can I resolve this? If you propose a fix, please make it concise.

   

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
playground.php:407
The playground now uses PHP 8.3 (Dockerfile) and requires PHP `>=8.2` (composer.json), but still creates cloud functions with the PHP 8.0 runtime — which reached end-of-life in November 2023. If Appwrite server 1.9.x has retired the `php-8.0` runtime executor, `createFunction` will fail at runtime. Updating to a current PHP runtime makes the playground more representative anyway.

```suggestion
        runtime: Runtime::PHP84(),
```

### Issue 2 of 2
Dockerfile:8
The previous base image was pinned to an exact patch version (`php:8.1.11-alpine3.16`), making builds fully reproducible. The new tag `php:8.3-alpine` is a floating tag that silently picks up new PHP 8.3 patch releases and Alpine upgrades. A minor PHP patch could introduce a behavioural change that’s hard to trace back to the image. Pinning to a specific release (e.g. `php:8.3.22-alpine3.22`) preserves reproducibility.

```suggestion
FROM php:8.3.22-alpine3.22
```

_{Reviews (1): Last reviewed commit: "Update appwrite/appwrite SDK to ^27.0.0" | Re-trigger Greptile}

[greptile-apps]

The previous base image was pinned to an exact patch version (php:8.1.11-alpine3.16), making builds fully reproducible. The new tag php:8.3-alpine is a floating tag that silently picks up new PHP 8.3 patch releases and Alpine upgrades. A minor PHP patch could introduce a behavioural change that’s hard to trace back to the image. Pinning to a specific release (e.g. php:8.3.22-alpine3.22) preserves reproducibility.

Suggested change

	FROM php:8.3-alpine
	FROM php:8.3.22-alpine3.22

Prompt To Fix With AI

This is a comment left during a code review.
Path: Dockerfile
Line: 8

Comment:
The previous base image was pinned to an exact patch version (`php:8.1.11-alpine3.16`), making builds fully reproducible. The new tag `php:8.3-alpine` is a floating tag that silently picks up new PHP 8.3 patch releases and Alpine upgrades. A minor PHP patch could introduce a behavioural change that’s hard to trace back to the image. Pinning to a specific release (e.g. `php:8.3.22-alpine3.22`) preserves reproducibility.

```suggestion
FROM php:8.3.22-alpine3.22
```

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!