Files
wp-fix-plugin-does-not-exis…/.ai-workflows/feature-development.md
marcusquinn caa9207374
Some checks failed
Build Release / Build and Create Release (push) Has been cancelled
Build Release / Deploy to WordPress.org (push) Has been cancelled
ci/woodpecker/push/woodpecker Pipeline failed
ci/woodpecker/tag/woodpecker Pipeline was successful
Version 2.3.0 - Improved development workflow documentation
2025-04-16 19:23:46 +01:00

5.2 KiB

Feature Development Guide for AI Assistants

This document provides guidance for AI assistants to help with feature development for the Fix Plugin Does Not Exist Notices plugin.

Feature Development Workflow

1. Create a Feature Branch

Always start by creating a feature branch from the latest main branch pulled from origin (this step is mandatory):

git checkout main
git pull origin main  # Critical step - never skip this
git checkout -b feature/descriptive-name

Use a descriptive name that clearly indicates what the feature is about. If there's an issue number, include it in the branch name (e.g., feature/123-update-source-selector).

For more detailed git workflow guidelines, see @.ai-workflows/git-workflow.md.

2. Implement the Feature

When implementing a new feature:

  • Follow WordPress coding standards
  • Ensure all strings are translatable
  • Add appropriate comments
  • Consider performance implications
  • Maintain backward compatibility
  • Review reference plugins in the reference-plugins/ directory for inspiration and best practices

3. Update Documentation

Update relevant documentation to reflect the new feature:

  • Add a description to CHANGELOG.md under an "Unreleased" section
  • Update readme.txt if the feature affects user-facing functionality
  • Update inline documentation/comments
  • Remember that any feature addition will require a version increment in all relevant files

4. Testing

Test the feature thoroughly:

  • Test with the latest WordPress version
  • Test with the minimum supported WordPress version (5.0)
  • Test with PHP 7.0+ (minimum supported version)
  • Test in different environments (if possible)

5. Commit Changes

Make atomic commits with clear messages:

git add .
git commit -m "Add feature: descriptive name"

6. Prepare for Release

When the feature is ready to be released:

  1. Create a version branch with the appropriate version number (typically increment the minor version for features):
# Example: from 2.2.0 to 2.3.0
git checkout -b v{MAJOR}.{MINOR+1}.0
  1. Now update version numbers in all required files:
  • Main plugin file (wp-fix-plugin-does-not-exist-notices.php)
  • CHANGELOG.md (add a new version section)
  • readme.txt
  • README.md
  • languages/wp-fix-plugin-does-not-exist-notices.pot (Project-Id-Version)
  1. Commit the version updates:
git add .
git commit -m "Version {MAJOR}.{MINOR+1}.0 - [brief description]"
  1. Tag the version as stable:
git tag -a v{MAJOR}.{MINOR+1}.0-stable -m "Stable version {MAJOR}.{MINOR+1}.0"
  1. Follow the standard release process from this point

IMPORTANT: Don't update version numbers during initial development and testing. Only create a version branch and update version numbers when the feature is confirmed working.

For detailed guidelines on time-efficient development and testing, see @.ai-workflows/incremental-development.md.

7. Push to Remote (Optional for Collaboration)

If you need to collaborate with others on the feature before it's ready for release:

git push github HEAD:feature/descriptive-name
git push gitea HEAD:feature/descriptive-name

8. Create Pull Request (Optional)

If the repository uses pull requests for code review, create a pull request from the feature branch to the version branch.

Code Standards and Best Practices

PHP Coding Standards

  • Follow WordPress PHP Coding Standards
  • Use tabs for indentation, not spaces
  • Use proper naming conventions:
    • Class names: Class_Name
    • Function names: function_name
    • Variable names: $variable_name

JavaScript Coding Standards

Internationalization (i18n)

  • Wrap all user-facing strings in appropriate translation functions:
    • __() for simple strings
    • _e() for echoed strings
    • esc_html__() for escaped strings
    • esc_html_e() for escaped and echoed strings
  • Always use the plugin's text domain: fix-plugin-does-not-exist-notices

Security Best Practices

  • Validate and sanitize all input
  • Escape all output
  • Use nonces for form submissions
  • Use capability checks for user actions

Feature Types and Implementation Guidelines

Admin Interface Features

When adding features to the admin interface:

  • Use WordPress admin UI components for consistency
  • Follow WordPress admin UI patterns
  • Ensure accessibility compliance
  • Add appropriate help text

Plugin Functionality Features

When adding core functionality:

  • Ensure compatibility with WordPress hooks system
  • Consider performance impact
  • Maintain backward compatibility
  • Add appropriate error handling

Integration Features

When adding integration with other plugins or services:

  • Make integrations optional when possible
  • Check if the integrated plugin/service is available before using it
  • Provide fallback functionality when the integration is not available
  • Document the integration requirements