Version Settings with Update Server #
The version edit form gains an "Update Server Settings" section with seven additional fields when this extension is active.
What This Extension Adds #
Core DDLS's version edit form has 5 fields: Product, Version Number, Release Date, Version Type (beta checkbox), and Changelog. With DMSI Update Server, a new section "Update Server Settings" appears below these fields, adding file upload, rollout control, channel assignment, compatibility requirements, and notification options.
The Update Server Settings Section #
Field 1: Release Channel #
| Value | Who Receives Updates |
|---|---|
| stable | All license holders on any channel |
| beta | License holders on beta or alpha channel |
| alpha | Only license holders on alpha channel |
Channel hierarchy: stable is visible to everyone. Beta is visible to beta and alpha licenses. Alpha is visible to alpha licenses only.
A license's channel is set in the license meta. Customers can change their preference in the customer portal under Notification Preferences.
Field 2: Rollout Percentage #
| Property | Description |
|---|---|
| Range | 0 to 100 |
| Default | 100 |
| Effect | Limits update delivery to this percentage of eligible license holders |
Staged rollout example:
- Set to 10% on Monday. Monitor for errors.
- Increase to 50% on Wednesday if stable.
- Use "Full Rollout" action on Friday to reach 100%.
The bucketing is deterministic per license: the same license always falls in or out of the same rollout percentage. A license at 10% will also be included at 50%.
Field 3: Is Critical Update #
| Value | Effect |
|---|---|
| Checked | Marks update as a critical security release |
| Unchecked | Normal update |
The API response includes is_critical: true for checked versions. Client SDKs can use this flag to show urgent update prompts or force updates.
Field 4: Send Email Notification #
| Value | Effect |
|---|---|
| Checked | When published, queues notification email to all active license holders for this product |
| Unchecked | No email sent on publish |
Requires the Email Notification setting to be enabled globally in Update Server Settings. The email includes the changelog and a download link.
Field 5: Upload Release File #
The file upload field accepts a ZIP file containing your release.
| Property | Description |
|---|---|
| Accepted types | .zip |
| Storage location | wp-content/uploads/dmsilm/updates/{product_id}/{version}/ |
| Protection | .htaccess blocks direct access; all downloads go through token endpoint |
| Hash | SHA-256 hash computed automatically on upload |
After upload, the field shows the file name, size, and hash. Customers can verify integrity using the hash in the API response.
Replacing a file: Upload a new file to overwrite. The hash updates automatically.
Field 6: Requires Version (Minimum Prerequisite) #
| Property | Description |
|---|---|
| Purpose | Block this update for clients running a version older than this value |
| Example | Set to "1.5.0" to require customers be on at least 1.5.0 before updating to this version |
| Leave blank | No minimum prerequisite |
Use case: Version 3.0.0 includes a database migration that requires 2.x structures. Set Requires Version to 2.0.0 to prevent 1.x customers from updating directly to 3.0.0.
Field 7: Compatibility Requirements #
Four fields control which WordPress and PHP versions this release supports:
| Field | Description |
|---|---|
| WordPress Minimum | Minimum WP version (e.g., 6.0) |
| WordPress Maximum | Maximum WP version (leave blank for no upper limit) |
| PHP Minimum | Minimum PHP version (e.g., 7.4) |
| PHP Maximum | Maximum PHP version (leave blank for no upper limit) |
Clients send their environment data in the update check request. If the client's environment does not meet these requirements, the API reports no update available for that client.