The Gradle wrapper jar and properties were already tracked but the matching
gradlew (bash) and gradlew.bat (Windows) launcher scripts were not, leaving
the wrapper unusable without a separately-installed Gradle. Adding both so
./gradlew works on a fresh clone.
.flutter-plugins is a generated file containing absolute machine-specific
pub-cache paths and is explicitly marked "do not check into version control"
in its own header. Adding it to mobile/.gitignore alongside the already-
ignored .flutter-plugins-dependencies.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Gitea release workflow now runs composer install --no-dev before zipping, so
each release ships vendor/ with both Twilio and AWS SDKs. The plugin's loader
priority is flipped to match: internal vendor/autoload.php first (always
current after every plugin update), external wp-content/twilio-sdk/ second
(legacy/manual install fallback).
AWS SDK detection wired in alongside Twilio: composer's bundled autoloader
covers Aws\… natively when present; otherwise plugin falls back to a new
external location wp-content/aws-sdk/ via install-aws-sdk-external.sh, which
drops the AWS SDK PHAR with a tiny autoload shim. AWS-missing admin notice
fires only when twp_sms_provider === 'aws_sns' so existing Twilio SMS users
see no new noise.
Loader priority flip applied in three places that all had the same
external-first pattern: twilio-wp-plugin.php (twp_check_sdk_installation),
class-twp-twilio-api.php (init_sdk_client), class-twp-webhooks.php
(constructor). twp_check_sdk_after_update messaging updated to reflect that
plugin updates now bundle the SDK.
Files:
.gitea/workflows/release.yml — composer install before ZIP
twilio-wp-plugin.php — TWP_EXTERNAL_AWS_SDK_DIR, dual-SDK
detection, twp_aws_sdk_missing_notice
includes/class-twp-twilio-api.php — internal-first autoloader
includes/class-twp-webhooks.php — internal-first autoloader
install-aws-sdk-external.sh — new AWS SDK PHAR installer
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The activator class was only loaded during plugin activation, on admin_init
when the DB version differed, and in a few explicit admin handlers. Twilio
webhook callbacks (voicemail in particular, but also any non-admin caller of
TWP_Activator::force_table_updates() / ::ensure_tables_exist()) hit the public
REST endpoint where none of those load paths fire, so the static call fataled.
Load class-twp-activator.php in TWP_Core::load_dependencies() so every plugin
context — webhook, REST, cron, admin — has the class available. The activator
file is a pure class definition with no load-time side effects.
This single change covers all 9 runtime call sites (webhook, scheduler, and
six admin sites) that previously assumed the class would already be loaded.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
