Files
wp-fix-plugin-does-not-exis…/.ai-assistant.md
Marcus Quinn e3319c4959
Some checks failed
ci/woodpecker/push/woodpecker Pipeline is pending
ci/woodpecker/tag/woodpecker Pipeline is pending
Build Release / Build and Create Release (push) Has been cancelled
Build Release / Deploy to WordPress.org (push) Has been cancelled
Update README.md and improve .ai-assistant.md documentation
2025-04-12 00:50:49 +01:00

196 lines
5.7 KiB
Markdown

# AI Assistant Guide for Fix Plugin Does Not Exist Notices
This guide helps AI assistants understand the project structure, workflows, and best practices for this repository.
## Project Overview
- **Plugin Name**: Fix 'Plugin file does not exist.' Notices
- **Repository**: https://github.com/wpallstars/fix-plugin-does-not-exist-notices
- **Description**: WordPress plugin that adds missing plugins to the plugins list with a "Remove Reference" link to clean up invalid plugin entries and remove error notices.
## Version Management
### Version Numbering Convention
We follow [Semantic Versioning](https://semver.org/):
- **MAJOR.MINOR.PATCH** (e.g., 1.6.0)
- **MAJOR**: Breaking changes
- **MINOR**: New features, non-breaking
- **PATCH**: Bug fixes, non-breaking
### When to Increment Version Numbers
- **PATCH** (1.6.0 → 1.6.1):
- Bug fixes
- Small text changes
- Minor improvements that don't add new features
- **MINOR** (1.6.0 → 1.7.0):
- New features
- Significant improvements to existing functionality
- Deprecation of features (but not removal)
- **MAJOR** (1.6.0 → 2.0.0):
- Breaking changes
- Removal of features
- Major architectural changes
### Version Update Checklist
When updating the version number, always update these files:
1. `fix-plugin-does-not-exist-notices.php` (Plugin header)
2. `CHANGELOG.md` (Add new version section)
3. `readme.txt` (Stable tag and Changelog section)
4. `README.md` (Update Changelog section to match readme.txt)
5. Update `FPDEN_VERSION` constant in the main plugin file
**IMPORTANT**: Always ensure README.md is kept in sync with readme.txt for consistency across platforms.
## Git Workflow
### Branch Naming Convention
- Feature branches: `feature/descriptive-name`
- Bug fix branches: `fix/issue-description`
- Release branches: `v{MAJOR}.{MINOR}.{PATCH}`
### Commit Message Guidelines
- Use present tense ("Add feature" not "Added feature")
- Start with a verb
- Keep the first line under 50 characters
- Reference issues when relevant: "Fix #123: Resolve plugin detection issue"
### Pre-Release Checklist
Before creating a new release, verify the following:
- [ ] Determine the correct version increment (MAJOR, MINOR, or PATCH) based on the changes
- [ ] Ensure all changes are documented in CHANGELOG.md
- [ ] Verify all code changes are tested and working correctly
- [ ] Check that all files are properly formatted and follow WordPress coding standards
- [ ] Ensure Git Updater configuration is correct (if applicable)
### Release Process
1. Create a new branch for the version: `git checkout -b v{MAJOR}.{MINOR}.{PATCH}`
2. Update version numbers in ALL required files:
- `fix-plugin-does-not-exist-notices.php` (Plugin header)
- `FPDEN_VERSION` constant in the main plugin file
- `readme.txt` (Stable tag)
- `README.md` (Ensure changelog is updated)
- Any other files that reference the version number
3. Update CHANGELOG.md with all changes
4. Update readme.txt changelog section
5. Update README.md changelog section to match readme.txt
6. Commit changes: `git commit -m "Prepare release v{MAJOR}.{MINOR}.{PATCH}"`
7. Push branch to all remotes:
```
git push github HEAD:v{MAJOR}.{MINOR}.{PATCH}
git push gitea HEAD:v{MAJOR}.{MINOR}.{PATCH}
```
8. Create and push a tag to trigger the GitHub Actions workflow:
```
git tag -a v{MAJOR}.{MINOR}.{PATCH} -m "Release version {MAJOR}.{MINOR}.{PATCH}"
git push github refs/tags/v{MAJOR}.{MINOR}.{PATCH}
git push gitea refs/tags/v{MAJOR}.{MINOR}.{PATCH}
```
9. Verify the GitHub Actions workflow completes successfully
## Build Process
The build process is handled by `build.sh`:
1. Updates version numbers
2. Installs composer dependencies
3. Copies files to build directory
4. Creates ZIP file
To manually build the plugin:
```
./build.sh {MAJOR}.{MINOR}.{PATCH}
```
## Remote Repositories
The plugin is hosted on multiple repositories:
- GitHub: https://github.com/wpallstars/fix-plugin-does-not-exist-notices
- Gitea: https://gitea.wpallstars.com/wpallstars/fix-plugin-does-not-exist-notices
- WordPress.org: https://wordpress.org/plugins/fix-plugin-does-not-exist-notices/
Always push changes to all remotes to keep them in sync.
## GitHub Actions
The repository uses GitHub Actions for automated builds and deployments:
- Triggered by tags matching the pattern `v*`
- Builds the plugin
- Creates a GitHub release
- Deploys to WordPress.org
## Testing Guidelines
Before releasing:
1. Test with the latest WordPress version
2. Test with PHP 7.0+ (minimum supported version)
3. Verify all features work as expected
4. Check for any PHP warnings or notices
## Common Tasks for AI Assistants
### Creating a New Release
```
# 1. Create a new branch
git checkout -b v1.7.0
# 2. Update version numbers in ALL required files
# - fix-plugin-does-not-exist-notices.php
# - CHANGELOG.md
# - readme.txt
# - README.md
# - FPDEN_VERSION constant
# 3. Commit changes
git add .
git commit -m "Prepare release v1.7.0"
# 4. Push to remotes
git push github HEAD:v1.7.0
git push gitea HEAD:v1.7.0
# 5. Create and push tag
git tag -a v1.7.0 -m "Release version 1.7.0"
git push github refs/tags/v1.7.0
git push gitea refs/tags/v1.7.0
```
### Adding a New Feature
```
# 1. Create feature branch
git checkout -b feature/new-feature-name
# 2. Make changes and commit
git add .
git commit -m "Add new feature"
# 3. Push to remotes
git push github HEAD:feature/new-feature-name
git push gitea HEAD:feature/new-feature-name
```
### Fixing a Bug
```
# 1. Create bugfix branch
git checkout -b fix/bug-description
# 2. Make changes and commit
git add .
git commit -m "Fix #123: Fix bug description"
# 3. Push to remotes
git push github HEAD:fix/bug-description
git push gitea HEAD:fix/bug-description
```