wp-plugins/twilio-wp-plugin
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 29 Wiki Activity
110 Commits 2 Branches 29 Tags
feature/webview-softphone
Commit Graph
6 Commits
Author SHA1 Message Date
ClaudeandClaude Opus 4.7 d5a09fb337 Bump PHP to 8.1 minimum and resolve composer.lock in CI 
The Gitea release build failed because aws/aws-sdk-php 3.371+ requires PHP
>= 8.1, while composer.json's platform was pinned to 8.0. Production runs
PHP 8.5.4, so bumping the minimum to 8.1 is well within the runtime envelope.

Changes:
  composer.json                 — require php >=8.1, platform.php = 8.1
  .gitea/workflows/release.yml  — setup-php now installs PHP 8.1
                                  added pre-install step that runs
                                  `composer update --no-install` only when
                                  composer.lock is absent. If a lock file is
                                  ever committed later, CI uses it directly
                                  for deterministic installs instead of
                                  regenerating.
  twilio-wp-plugin.php          — added "Requires PHP: 8.1" header so
                                  WordPress itself enforces the minimum
  README.md, CLAUDE.md          — doc bump from 8.0 to 8.1, with note that
                                  the AWS SDK is the constraint driver

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
 2026-05-05 09:20:06 -07:00
ClaudeandClaude Opus 4.7 ee8e111970 Bundle Twilio + AWS SDKs in releases, add SNS install path 
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>
 2026-05-05 08:48:45 -07:00
ClaudeandClaude Opus 4.6 5d3035a62c Remove redundant update-version.yml workflow
Create Release / build (push) Successful in 4s
Details 
release.yml already handles version stamping, zipping, and release creation on push to main.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
 2026-03-06 18:34:33 -08:00
shadowdaoandClaude 026edde33b Fix update-version workflow to update TWP_VERSION constant
Create Release / build (push) Successful in 3s
Details 
The workflow was only updating the Version comment but not the TWP_VERSION constant, causing the local repository to show the placeholder while releases showed the actual version.

Now updates both:
- Version: header comment
- TWP_VERSION constant

This matches the release.yml workflow and ensures version consistency.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
 2025-12-01 16:46:46 -08:00
shadowdaoandClaude a3345ed854 Use version placeholder for auto-deployment
Create Release / build (push) Successful in 3s
Details 
Replace hardcoded version with {auto_update_value_on_deploy} placeholder that gets replaced during the Gitea workflow build process.

Changes:
- Updated Version comment to use placeholder
- Updated TWP_VERSION constant to use placeholder
- Modified release workflow to replace both instances of the placeholder

This matches the pattern used in the fourthwall plugin and ensures the version is automatically set during the release build process.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
 2025-12-01 16:32:42 -08:00
shadowdaoandClaude 384ad5e265 Add Gitea CI/CD workflows for automated releases
Create Release / build (push) Successful in 2s
Details 
Add automated release creation and versioning workflows similar to the fourthwall plugin.

Features:
- Automatically creates a release on every push to main branch
- Generates release notes from commit messages since last tag
- Updates plugin version using timestamp-based versioning (YYYY.MM.DD-HHMM)
- Creates and uploads plugin zip file to release
- Supports manual release creation/editing to update version

Workflows:
- .gitea/workflows/release.yml - Triggers on push to main
- .gitea/workflows/update-version.yml - Triggers on release creation/edit

The release zip will be automatically picked up by the Gitea auto-updater for WordPress.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
 2025-12-01 16:13:42 -08:00