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

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:

• 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