feat: PHP SDK update for version 26.0.0

[ChiragAgg5k]

This PR contains updates to the SDK for version 26.0.0.

What's Changed

• Breaking: Removed client, OS, and device fields (osCode, clientName, deviceModel, etc.) from ActivityEvent
• Breaking: Inserted authorizationDetailsTypes mid-signature in project.updateOAuth2Server
• Added: OAuth2 device flow options verificationUrl, userCodeLength, userCodeFormat, and deviceCodeDuration to updateOAuth2Server
• Added: updateDenyCorporateEmailPolicy and PolicyDenyCorporateEmail to project
• Added: deny-corporate-email to ProjectPolicyId
• Added: oauth2 to ProjectServiceId and dedicatedDatabases.execute to ProjectKeyScopes
• Added: emailCanonical, emailIsFree, emailIsDisposable, emailIsCorporate, and emailIsCanonical to User
• Added: userAccessedAt to Membership and PolicyMembershipPrivacy
• Added: type to BackupPolicy
• Updated: Send an accept header on all requests, including chunked uploads
• Updated: Doc examples no longer show the optional setImpersonateUserId setter on location methods (downloads, previews, views, avatars)

[greptile-apps]

Greptile Summary

• Updates the PHP SDK surface for Appwrite 26.0.0.
• Adds OAuth2 device-flow options, deny-corporate-email policy support, new enums, and new response model fields.
• Removes deprecated client, OS, and device fields from ActivityEvent.
• Adds accept headers across generated service requests and refreshes docs, examples, and service tests.

Confidence Score: 4/5

The SDK update is mostly generated and consistent, but resumable storage uploads need attention before merge.

Most changed service surfaces, models, enums, docs, and tests align with the described API update; the remaining issue is isolated to resumed large-file uploads.

src/Appwrite/Services/Storage.php

T-Rex Logs

What T-Rex did

• I attempted to run the focused PHP harness for resumable upload probe headers, but the environment has no PHP binary installed.
• Before the change, the base ActivityEvent failed due to a missing osCode field, and after the change head tests returned OK for all six contract scenarios with exit code 0.
• Trex artifacts show the project-api base and after runs exit with 127 and /bin/sh: php: not found, and the environment has no php, composer, or Docker binaries available.
• Accept-header Trex runs show the same php not found, with a follow-up environment probe confirming no PHP executable is present.
• Docs-examples validations pass on both the base and head revisions, with exit code 0 and RESULT: PASS in the artifacts.

_{Ran code and verified through T-Rex}

Comments Outside Diff (1)

1. src/Appwrite/Services/Storage.php, line 448-458 (link)

   Resume probe lacks headers

   The resumable-upload lookup still calls Client::call() without the per-request headers. That means the probe does not send X-Appwrite-Project or the new accept: application/json header, so it can fail before reading chunksUploaded. Because the exception is swallowed, an interrupted large-file upload leaves $counter at 0 and starts again from the first chunk instead of resuming.

_{Reviews (5): Last reviewed commit: "chore: update PHP SDK to 26.0.0" | Re-trigger Greptile}

[ChiragAgg5k]

@greptile-apps re: "Omit null transactions" (P1, TablesDB/Databases write methods) — verified this is accurate as a description but not a defect. It is the same class as the "Omit null optionals" thread on updateOAuth2Server.

Mechanism (from the spec):

• Read/delete methods declare transactionId as an optional query parameter (no x-nullable), so the generator omits it when null.
• Write methods declare transactionId as a request-body property marked x-nullable: true, which the PHP generator intentionally serializes as an explicit null.

Why it is safe: because the write field is x-nullable: true, the backend Nullable validator accepts null, and a null transactionId is treated as "no transaction." So createRow(..., transactionId: null) / createDocument(..., transactionId: null) is not rejected and behaves exactly like a non-transactional write. The "if the backend validates transactionId as a string when present" premise is precisely what x-nullable rules out.

This is generator-faithful behavior, not an SDK bug — nothing to change in the generated code. If the read/write inconsistency is undesirable cosmetically, the fix is a spec change (model the write-body transactionId with a default, or as a query param like the reads), not the SDK.

(Separately, the earlier "Chunk uploads skip accept" finding is now resolved — the latest push regenerates with sdk-generator 2.0.2+, which adds the accept header to the rebuilt chunk-upload header arrays.)

[greptile-apps]

Thanks for the thorough breakdown — both points are well-reasoned and I agree with the conclusions.

Omit null transactions: The distinction is clear. x-nullable: true on the write-body field is the spec's explicit contract that null is a valid value (meaning "no transaction"), so the generator serializing it as an explicit null is correct and the backend will accept it. The read/write asymmetry is a spec modeling choice, not an SDK defect. No action needed here.

Chunk uploads / accept header: Confirmed resolved — the regeneration with sdk-generator 2.0.2+ covers this. Nothing left to address.

Tip: You can customize Greptile's behavior for this repo with .greptile/rules.md and .greptile/config.json.

[ChiragAgg5k]

@greptile-apps re: "Add accept headers" (P1, deleteIdentity() and similar) — checked, not a defect.

The flagged methods all return 204 No Content with no declared produces:

Method	Responses	produces
deleteIdentity	204	none
createSMTPTest	204	none
deleteUser	204	none

The generator derives the accept header from a method's produces; a 204-only method has no response body, so there is nothing to content-negotiate and Accept is moot — the server returns 204 regardless of the header. Methods that actually return content (e.g. getAccount, 200 application/json) do get accept: application/json.

So this is consistent, by-design behavior, not the gap this PR addresses (the real chunked-upload accept gap is already fixed). If uniform headers are desired purely for cosmetics, emitting a fallback accept: */* when produces is empty would be a generator-level change, but it has no functional effect on 204 responses.

[greptile-apps]

That's a clear and well-reasoned explanation — thanks for the table. The generator's behavior is correct: no produces → no Accept header, and a 204 response makes the header moot anyway. The chunked-upload fix is the actual gap addressed here, and this is consistent with that intent.

No issues on my end. This is fine as-is.