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