wpallstars/wp-fix-plugin-does-not-exist-notices
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 15 Wiki Activity
Files
main
wp-fix-plugin-does-not-exis…/.ai-assistant.md

7.1 KiB
Raw Permalink Blame History

AI Assistant Guide for WordPress Plugin Development

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

IMPORTANT: Repository Context

This workspace may contain multiple repository folders. Always focus ONLY on the current repository you're working in and avoid hallucinating functionality from other repositories in the workspace.

  • Current Repository: wp-fix-plugin-does-not-exist-notices
  • Repository Purpose: Adds missing plugins to your plugins list with a "Remove Notice" action link, allowing you to safely clean up invalid plugin references
  • Repository Scope: All code changes, documentation, and functionality discussions should be limited to THIS repository only

Project Overview

This plugin helps users clean up references to deleted plugins that cause "Plugin file does not exist" errors in the WordPress admin. It adds missing plugins to the plugins list with a "Remove Notice" link to safely remove invalid plugin entries.

AI Workflows

Detailed workflow documentation is available in the .ai-workflows/ directory:

  • @.ai-workflows/bug-fixing.md: Guidelines for identifying and fixing bugs
  • @.ai-workflows/code-review.md: Standards for reviewing code changes
  • @.ai-workflows/dev-prefs-memory.md: Persistent memory of developer preferences
  • @.ai-workflows/feature-development.md: Process for developing new features
  • @.ai-workflows/folder-structure.md: Documentation of the plugin's folder structure and naming conventions
  • @.ai-workflows/git-workflow.md: Detailed git workflow and branch management guidelines
  • @.ai-workflows/incremental-development.md: Time-efficient approach for incremental development and testing
  • @.ai-workflows/local-env-vars.md: Local development environment paths and URLs
  • @.ai-workflows/release-process.md: Steps for preparing and publishing releases

Version Management

We follow Semantic Versioning:

  • MAJOR.MINOR.PATCH (e.g., 2.2.2)
    • MAJOR: Breaking changes
    • MINOR: New features, non-breaking
    • PATCH: Bug fixes, non-breaking

Time-Efficient Development Workflow

For efficient development and testing:

  • Create descriptive branches (fix/, feature/, patch/, refactor/) without version numbers
  • Don't update version numbers during initial development and testing
  • Only create version branches (v2.2.3) and update version numbers when changes are confirmed working
  • Use patch increments for bug fixes, minor for features, and major for breaking changes
  • Mark versions as stable when confirmed working by the user
  • See @.ai-workflows/incremental-development.md for detailed guidelines

When updating version numbers, see @.ai-workflows/release-process.md for the complete checklist.

IMPORTANT: Always keep the changelogs in README.md, readme.txt, and CHANGELOG.md in sync to avoid confusion. All three files must be updated with the same changes for each release.

Git Workflow

Detailed git workflow documentation is available in @.ai-workflows/git-workflow.md.

Key Principles

  • Always pull the latest main branch from origin before creating new branches (mandatory step)
  • Create one branch per issue/feature (fix/patch/feature)
  • Submit one pull/merge request per issue
  • Run CI/CD checks for each pull request
  • Create separate branches for suggested improvements outside the current issue

Branch Naming Convention

  • Feature branches: feature/descriptive-name
  • Bug fix branches: fix/issue-description or fix/issue-number-description
  • Patch branches: patch/descriptive-name
  • 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"

Remote Repositories

The plugin is hosted on multiple repositories:

Always push changes to all remotes to keep them in sync.

Git Updater Integration

The plugin integrates with Git Updater to allow updates directly from GitHub or Gitea. Important notes:

  1. Git Updater reads version information from the readme.txt file in the main branch, not from tags or releases
  2. Always merge release changes to the main branch immediately after creating a tag
  3. The plugin includes proper headers for Git Updater in the main plugin file

See @.ai-workflows/release-process.md for detailed Git Updater integration steps.

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

Local environment variables and paths are documented in @.ai-workflows/local-env-vars.md.

Developer Preferences

AI assistants should maintain a record of developer preferences in @.ai-workflows/dev-prefs-memory.md. When you learn about a new preference through user feedback or conversation:

  1. Check if the preference is already documented
  2. If not, add it to the appropriate section in the dev-prefs-memory.md file
  3. Reference these preferences in future interactions

This ensures consistency across coding sessions and reduces the need for developers to repeatedly explain their preferences.

Avoiding Cross-Repository Confusion

When working in a multi-repository workspace, follow these guidelines to avoid confusion:

  1. Verify Repository Context: Always check which repository you're currently working in before making any changes or recommendations.

  2. Limit Code Search Scope: When searching for code or functionality, explicitly limit your search to the current repository.

  3. Don't Assume Features: Never assume that features present in one repository should be implemented in another. Each repository has its own specific purpose and feature set.

  4. Repository-Specific Documentation: Documentation should only reflect the actual features and functionality of the current repository.

  5. Cross-Repository Inspiration: If you want to implement a feature inspired by another repository, explicitly mention that it's a new feature being added, not an existing one.

  6. Verify Before Implementation: Before implementing or documenting a feature, verify that it actually exists in the current repository by checking the codebase.

Common Tasks

For detailed instructions on common tasks like creating releases, adding features, fixing bugs, and testing previous versions, see @.ai-workflows/release-process.md.