# 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
```