wp-fix-plugin-does-not-exist-notices/.ai-assistant.md

# AI Assistant Guide for WordPress Plugin Development

This guide helps AI assistants understand the project structure, workflows, and best practices for this repository.

## AI IDE Configuration

This repository includes configuration files for various AI-powered development tools:

- `.aiconfig` - General AI configuration (model preferences, ignore patterns)
- `.augmentignore` - Ignore patterns for Augment
- `.cursorignore` - Ignore patterns for Cursor
- `.v0ignore` - Ignore patterns for v0
- `.windsurfignore` - Ignore patterns for Windsurf
- `.clinerc` - Configuration for Cline
- `.rooignore` - Ignore patterns for Roo
- `.geminiignore` - Ignore patterns for Gemini Code Assist
- `.loveablerc` - Configuration for Loveable
- `.boltignore` - Ignore patterns for Bolt
- `.codyignore` - Ignore patterns for Cody
- `.continuerc` - Configuration for Continue

All these files respect `.gitignore` patterns and only include additional tool-specific patterns. The `!` prefix can be used in these files to include files that are excluded by `.gitignore`.

## Project Overview

- **Plugin Name**: [PLUGIN_NAME]
- **Repository**: [REPOSITORY_URL]
- **Description**: [PLUGIN_DESCRIPTION]

This section should be updated with your specific plugin information. The current implementation is for the "Fix 'Plugin file does not exist.' Notices" plugin, which adds missing plugins to the plugins list with a "Remove Notice" link to clean up invalid plugin entries and remove error notices.

## Reference Plugins

The `reference-plugins/` directory contains plugins that can be used for reference or inspiration. When developing new features or improving existing ones, you should:

1. Examine these reference plugins for best practices in code structure, organization, and implementation
2. Look for patterns in how they handle similar functionality
3. Consider their approach to user interface design and user experience
4. Study their documentation style and thoroughness

These plugins are not part of the codebase and are ignored by Git, but they provide valuable examples of WordPress plugin development standards and techniques.

## 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)
   - `languages/fix-plugin-does-not-exist-notices.pot` (Project-Id-Version)
   - 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. Test changes locally on the version branch
8. When satisfied with testing, merge to main:
   ```
   git checkout main
   git merge v{MAJOR}.{MINOR}.{PATCH} --no-ff
   ```
9. Push main to all remotes:
   ```
   git push github main
   git push gitea main
   ```
10. 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}
    ```
11. 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 main
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
# - languages/fix-plugin-does-not-exist-notices.pot
# - FPDEN_VERSION constant

# 3. Commit changes
git add .
git commit -m "Prepare release v1.7.0"

# 4. Test changes locally on the version branch
# (Run tests, verify functionality)

# 5. Merge to main when ready
git checkout main
git merge v1.7.0 --no-ff

# 6. Push main to remotes
git push github main
git push gitea main

# 7. 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 from main
git checkout main
git checkout -b feature/new-feature-name

# 2. Make changes and commit
git add .
git commit -m "Add new feature"

# 3. Test locally
# (Run tests, verify functionality)

# 4. When ready for release, merge to a version branch
git checkout -b v1.7.0
git merge feature/new-feature-name --no-ff

# 5. Continue with the release process
# (Update version numbers, etc.)
```

### Fixing a Bug

```
# 1. Create bugfix branch from main
git checkout main
git checkout -b fix/bug-description

# 2. Make changes and commit
git add .
git commit -m "Fix #123: Fix bug description"

# 3. Test locally
# (Run tests, verify functionality)

# 4. When ready for release, merge to a version branch
git checkout -b v1.6.5
git merge fix/bug-description --no-ff

# 5. Continue with the release process
# (Update version numbers, etc.)
```

### Testing a Previous Version

```
# Checkout a specific tag for testing
git checkout v1.6.3

# Or create a test branch from a specific tag
git checkout v1.6.3 -b test/some-feature
```