Token导航 LogoToken导航TokenDH.com
研究检索需要联网github未标认证来源可访问许可证需确认审计异常

drupal-update德鲁普更新

Agent Skill

drupal-update 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

945

周安装

39

GitHub Stars

公开资料未说明

下载量

309
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:drupal-update(德鲁普更新)
来源仓库:https://github.com/bethamil/agent-skills
仓库路径:skills/drupal-update
安装命令:
npx skills add https://github.com/bethamil/agent-skills --skill drupal-update
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/bethamil/agent-skills --skill drupal-update

简介

该技能提供 Drupal 模块安全更新的自动化处理,包含快照创建和变更日志生成。

  • 适用于 DDEV 环境中的模块更新,支持自动和手动更新模式。
  • 包含重大版本升级检查和兼容性验证,确保更新过程安全可靠。
  • 安装需从 GitHub 仓库获取,使用前应确认 DDEV 环境配置和项目路径正确。
  • 涉及生产环境时,应先在 staging 环境测试更新结果,确认无误后再部署。

SKILL.md

Drupal Module Updates

Safely update Drupal modules in DDEV environments with automatic snapshots, intelligent update handling, and comprehensive changelog generation.

Quick Start

When the user requests a module update:

  1. Create safety snapshot
  2. Check and apply security updates automatically
  3. Run automatic updates for all semver-safe versions
  4. Check for major version updates
  5. Check compatibility for major updates with current Drupal core
  6. Ask user about compatible major updates
  7. Apply confirmed major updates
  8. Run database updates and export configuration
  9. Generate changelog with all changes

Script Path Convention

Throughout this skill, [skill-directory] refers to the location where this skill is installed. Common locations include:

  • Project skills directory
  • Personal skills directory
  • Custom skills directory

Replace [skill-directory] with the actual path to this skill on your system when running the changelog fetch script.

Pre-Flight Checklist

Before starting updates, copy this checklist:

Update Progress:
- [ ] Verify DDEV environment is running
- [ ] Create snapshot for rollback
- [ ] Check for security updates
- [ ] Run automatic composer updates
- [ ] Review major version updates available
- [ ] Check compatibility for major updates
- [ ] Apply confirmed major updates
- [ ] Run database updates (drush updb)
- [ ] Export configuration (drush cex)
- [ ] Clear caches
- [ ] Generate changelog
- [ ] Verify site functionality

Step-by-Step Workflow

Step 1: Verify Environment

Check DDEV is running:

ddev describe

If not running, start it:

ddev start

Step 2: Create Safety Snapshot

Always create a snapshot before updates:

ddev snapshot --name=pre-update-$(date +%Y%m%d-%H%M%S)

Store the snapshot name for rollback instructions later.

Step 3: Security Updates (Auto-Apply)

Check for security vulnerabilities:

ddev composer audit

If vulnerabilities found: Security updates are automatically applied without asking. Inform the user which security issues were found and will be fixed.

If no vulnerabilities: Proceed to next step.

Step 4: Automatic Updates

Run composer update to handle all semver-safe updates:

ddev composer update

This automatically updates:

  • Patch versions (e.g., 3.6.2 → 3.6.3)
  • Minor versions within constraints (e.g., 3.6.0 → 3.7.0 if constraint is ^3.6)

Monitor the output for:

  • Number of packages updated
  • Any warnings or errors
  • Dependency conflicts (rare but possible)

Capture updated packages for changelog:

After composer update completes, extract the list of updated Drupal modules and their version changes. For each updated Drupal module, you'll fetch the changelog in Step 11.

To get the list of updated packages:

# Compare composer.lock before and after, or parse composer update output
# The output shows: "Updating drupal/module (1.0.7 => 1.0.9)"

Store the list of updates in format: drupal/[module]: [old_version] → [new_version] for changelog generation.

Step 5: Check for Major Version Updates

Get all outdated Drupal modules:

ddev composer outdated 'drupal/*' --direct --format=json

Parse the JSON output and filter for modules with "latest-status": "update-possible". These are major version updates that require explicit version constraint changes.

Example major updates:

  • drupal/anchor_link: 2.7.0 → 3.0.3
  • drupal/webform: 6.2.0 → 7.0.0

Step 5.5: Verify Compatibility with Current Drupal Core

For each major update found in Step 5, verify compatibility with current Drupal core:

Get current Drupal core version:

CORE_VERSION=$(ddev composer show drupal/core --format=json | jq -r '.versions[0]')

For each major update, get all available versions:

ddev composer show drupal/[module] --all --format=json

Parse the JSON to find compatible versions:

The output is an array of version objects, each containing:

  • version: The version number (e.g., "3.0.0", "2.5.1")
  • require.drupal/core: Core version constraint (e.g., "^10.2", "^11")
  • require.php: PHP version requirement (e.g., ">=8.1")

Logic for finding compatible version:

  1. Parse all versions from the JSON output
  2. For each version, check if its require.drupal/core constraint is satisfied by current core version
  3. Find the highest compatible version
  4. If the highest compatible version is greater than the currently installed version, present it to the user
  5. If the latest version requires Drupal 11 but we have Drupal 10, find the highest Drupal 10-compatible version

Example constraint checking:

  • Current core: 10.3.5
  • Module version 3.0.0 requires: ^11 → NOT compatible
  • Module version 2.5.0 requires: ^10.2 → Compatible
  • Module version 2.0.0 requires: ^9.5 || ^10 → Compatible
  • Result: Offer version 2.5.0 (highest compatible)

Constraint syntax reference:

  • ^10.2 = >=10.2.0 <11.0.0
  • ^11 = >=11.0.0 <12.0.0
  • ^9.5 || ^10 || ^11 = Multiple versions supported
  • >=10.2 = Any version from 10.2.0 onwards

Note: When checking compatibility, compare the module's require.drupal/core constraint against the current Drupal core version. If the latest version is incompatible, iterate through available versions (sorted descending) to find the highest version that is compatible with the current core.

Step 6: Interactive Major Update Selection

For each major update available, present to the user with compatibility information:

If the latest version is compatible:

Major update available:
- Module: drupal/anchor_link
- Current: 2.7.0
- Latest: 3.0.3 (compatible with current Drupal core)
- Risk: Major version update may contain breaking changes

Update this module? (y/n)

If the latest version is NOT compatible, show recommended version:

Major update available:
- Module: drupal/anchor_link
- Current: 2.7.0
- Latest: 3.0.3 (requires Drupal ^11, not compatible)
- Recommended: 2.9.0 (highest version compatible with Drupal 10.3.5)
- Risk: Major version update may contain breaking changes

Update to version 2.9.0? (y/n)

If no compatible major version exists:

Major update available:
- Module: drupal/anchor_link
- Current: 2.7.0
- Latest: 3.0.3 (requires Drupal ^11, not compatible)
- Warning: No compatible major version found for current Drupal core
- Note: Consider upgrading Drupal core first, or skip this update

Skip this update? (y/n)

Build a list of modules the user confirms, along with the compatible version to install for each.

Step 7: Apply Major Updates

For each confirmed major update, use the compatible version determined in Step 5.5:

ddev composer require drupal/[module]:^[compatible-version] --update-with-all-dependencies

Examples:

If compatible version is 2.9.0:

ddev composer require drupal/anchor_link:^2.9 --update-with-all-dependencies

If latest version (3.0.3) is compatible:

ddev composer require drupal/anchor_link:^3.0 --update-with-all-dependencies

Note: Always use the compatible version determined in Step 5.5, not necessarily the latest version. This ensures the update will work with the current Drupal core version.

Handle errors: If a major update fails due to dependency conflicts:

  1. Show the error to the user
  2. Ask if they want to continue with other updates
  3. Document the failed update in the changelog
  4. If the error indicates incompatibility, re-check compatibility in Step 5.5

Step 8: Database Updates

Run database updates to apply schema changes:

ddev drush updb -y

Monitor for errors: If database updates fail, stop immediately and inform the user.

Step 9: Export Configuration

Export active configuration to sync directory:

ddev drush config:export -y

Verify the export location:

ddev drush status --field=config-sync

Step 10: Clear Caches

Clear all caches to ensure changes take effect:

ddev drush cache:rebuild

Step 11: Generate Changelog

Create a changelog file by fetching release notes for all updates (security, minor, patch, and major versions).

For each updated Drupal module, fetch the changelog:

ddev exec php [skill-directory]/scripts/fetch_changelog.php drupal/[module] [old_version] [new_version]

Process all updates:

  1. Security updates (from Step 3): Fetch changelog for each security update applied
  2. Automatic updates (from Step 4): Fetch changelog for each minor/patch update
  3. Major updates (from Step 7): Fetch changelog for each major version update

Example for multiple updates:

# Security update
ddev exec php [skill-directory]/scripts/fetch_changelog.php drupal/admin_toolbar 3.6.2 3.6.3

# Minor update
ddev exec php [skill-directory]/scripts/fetch_changelog.php drupal/admin_audit_trail 1.0.7 1.0.9

# Major update
ddev exec php [skill-directory]/scripts/fetch_changelog.php drupal/anchor_link 2.7.0 3.0.3

If the PHP script is unavailable, manually create UPDATES-[DATE].md with this structure:

# Drupal Module Updates - [YYYY-MM-DD]

## Security Updates (Auto-Applied)
[List security updates that were applied]

## Automatic Updates (composer update)
[List all packages updated by composer update - includes patch and minor versions]

For each update, include:
- drupal/admin_audit_trail: 1.0.7 → 1.0.9
  - Release: https://www.drupal.org/project/admin_audit_trail/releases/1.0.9
  - Changes: [Key changes from release notes fetched via fetch_changelog.php script]

## Major Version Updates
[List major updates applied via composer require]
- drupal/anchor_link: 2.7.0 → 3.0.3
  - Command: `composer require drupal/anchor_link:^3.0`
  - Release: https://www.drupal.org/project/anchor_link/releases/3.0.3
  - Changes: [Key changes and breaking changes]

## Post-Update Tasks Completed
- [x] Database updates applied (drush updb)
- [x] Configuration exported (drush cex)
- [x] Caches cleared (drush cr)

## Rollback Instructions
To rollback these updates:
\`\`\`bash
ddev snapshot restore --name=pre-update-[timestamp]
\`\`\`

Validation and Testing

After updates are complete:

Check for errors:

ddev drush watchdog:show --count=20 --severity=Error

Verify configuration status:

ddev drush config:status

If there are configuration changes not exported, review them:

ddev drush config:export --diff

Test critical functionality:

Inform the user to test:

  • User authentication
  • Content creation/editing
  • Forms and submissions
  • Any custom functionality

Error Handling

Composer Update Fails

If composer update fails:

  1. Check the error message for dependency conflicts
  2. Try updating specific packages that failed: ddev composer update drupal/[module] --with-all-dependencies
  3. If still failing, check for known issues on drupal.org

Database Updates Fail

If drush updb fails:

  1. Review the error message carefully
  2. Check watchdog logs: ddev drush watchdog:show
  3. Consider rolling back: ddev snapshot restore --name=[snapshot-name]
  4. Report the issue to the user with full error details

Configuration Export Issues

If configuration export shows unexpected changes:

  1. Review the diff: ddev drush config:export --diff
  2. Check if changes are expected from the updates
  3. If uncertain, ask the user to review before exporting

Rollback Procedure

If something goes wrong:

# List available snapshots
ddev snapshot list

# Restore to pre-update state
ddev snapshot restore --name=pre-update-[timestamp]

# Verify restoration
ddev drush status

After rollback:

  1. Clear caches: ddev drush cr
  2. Verify site functionality
  3. Investigate the issue before attempting updates again

Common Scenarios

For real-world examples of update workflows including security updates, major version upgrades, compatibility issues, and error recovery, see examples.md.

Additional Resources

For detailed composer command options, troubleshooting guides, and a quick commands reference, see reference.md.

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

36.91%
按下载量换算114

Claude

28.35%
按下载量换算88

Cursor

20.44%
按下载量换算63

Gemini CLI

8.93%
按下载量换算28

安全审计

Gen Agent Trust Hub

未通过

Socket

通过

Snyk

可疑

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在 warning/failed 结果,不能写成本站确认安全。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills