Compare commits

...

25 Commits

Author SHA1 Message Date
100d210f7e Merge v2.3.0 into main
Some checks failed
ci/woodpecker/push/woodpecker Pipeline is pending
Plugin Asset Update / Push assets to WordPress.org (push) Has been cancelled
2025-04-16 19:26:13 +01:00
caa9207374 Version 2.3.0 - Improved development workflow documentation
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
2025-04-16 19:23:46 +01:00
1fa143b4aa Fix case of readme.md file in .ai-workflows directory 2025-04-14 23:30:51 +01:00
b02151ac2e Version 2.2.5 - Improve documentation for developer preferences memory file 2025-04-14 23:30:07 +01:00
e3960f8514 Version 2.2.4 - Add developer preferences memory file and update documentation 2025-04-14 23:20:19 +01:00
f4e09e0287 Update WordPress.org documentation with correct plugin slug and version numbers 2025-04-14 23:03:06 +01:00
dfda9ff8e5 git push -f github main
git status

git push github v2.2.3
Merge branch 'main' of https://github.com/wpallstars/wp-fix-plugin-does-not-exist-notices
2025-04-14 22:56:44 +01:00
fdf2860c10 Version 2.2.3 - Improved folder structure and organization 2025-04-14 22:56:11 +01:00
3b7f4e49a4 Version 2.2.3 - Improved folder structure and organization 2025-04-14 22:55:05 +01:00
f0c940bf49 Move admin-specific files to admin/lib directory and update references 2025-04-14 22:47:10 +01:00
0a6279a508 Add folder structure documentation and standardize folder naming 2025-04-14 22:41:53 +01:00
ef3108113e Update documentation to ensure README.md changelog is maintained 2025-04-14 22:33:59 +01:00
65f784a461 git add README.md && git commit -m "Update README.md with 2.2.2-stable changelog"
Merge tag 'v2.2.2-stable'

Version 2.2.2-stable - Cleanup and improvements
2025-04-14 22:29:24 +01:00
e4c70b5711 Version 2.2.2-stable - Cleanup and improvements 2025-04-14 22:28:37 +01:00
5fedd333e9 Merge pull request #9 from wpallstars/feature/refactor-and-improvements
Feature/refactor and improvements
2025-04-14 21:47:02 +01:00
c73964888b Update release workflow documentation to reflect current best practices
Some checks failed
ci/woodpecker/push/woodpecker Pipeline failed
2025-04-14 21:38:37 +01:00
c5d3c7672c Version 2.2.1 - Commented out version-fix.js script and fixed version consistency
Some checks are pending
ci/woodpecker/push/woodpecker Pipeline is pending
2025-04-14 21:26:27 +01:00
e1da072640 Replace custom Git Updater fixes with proper plugin headers
Some checks failed
ci/woodpecker/push/woodpecker Pipeline is pending
Build Release / Build and Create Release (push) Has been cancelled
Build Release / Deploy to WordPress.org (push) Has been cancelled
ci/woodpecker/tag/woodpecker Pipeline was successful
2025-04-14 19:43:19 +01:00
b988fbbec0 Update release workflow to include .wordpress-org directory
Some checks failed
ci/woodpecker/push/woodpecker Pipeline is pending
Build Release / Build and Create Release (push) Has been cancelled
Build Release / Deploy to WordPress.org (push) Has been cancelled
ci/woodpecker/tag/woodpecker Pipeline was successful
2025-04-14 19:28:20 +01:00
ac3e47a147 Fix release workflow to check if directories exist before copying
Some checks failed
ci/woodpecker/push/woodpecker Pipeline is pending
Build Release / Build and Create Release (push) Has been cancelled
Build Release / Deploy to WordPress.org (push) Has been cancelled
ci/woodpecker/tag/woodpecker Pipeline was successful
2025-04-14 19:26:49 +01:00
b05d01da92 Update release workflow to include new directories
Some checks failed
ci/woodpecker/push/woodpecker Pipeline is pending
Build Release / Build and Create Release (push) Has been cancelled
Build Release / Deploy to WordPress.org (push) Has been cancelled
ci/woodpecker/tag/woodpecker Pipeline was successful
2025-04-14 19:24:46 +01:00
f447811b49 Merge pull request #8 from wpallstars/feature/refactor-and-improvements
Refactor plugin to use OOP best practices with proper namespaces and …
2025-04-14 19:22:18 +01:00
15244dc687 Refactor plugin to use OOP best practices with proper namespaces and class structure
Some checks failed
ci/woodpecker/push/woodpecker Pipeline is pending
Build Release / Build and Create Release (push) Has been cancelled
Build Release / Deploy to WordPress.org (push) Has been cancelled
ci/woodpecker/tag/woodpecker Pipeline was successful
2025-04-14 19:18:05 +01:00
7c0dadac08 Remove assets directory and update references to use .wordpress-org/assets
Some checks failed
ci/woodpecker/push/woodpecker Pipeline is pending
Plugin Asset Update / Push assets to WordPress.org (push) Has been cancelled
2025-04-13 15:17:52 +01:00
717a2721e8 Update file paths to use admin directory for JS and CSS files
Some checks failed
ci/woodpecker/push/woodpecker Pipeline is pending
Plugin Asset Update / Push assets to WordPress.org (push) Has been cancelled
2025-04-13 15:10:18 +01:00
30 changed files with 2152 additions and 1534 deletions

View File

@ -2,25 +2,6 @@
This guide helps AI assistants understand the project structure, workflows, and best practices for this repository.
## AI IDE Configuration
This repository includes configuration files for various AI-powered development tools:
- `.aiconfig` - General AI configuration (model preferences, ignore patterns)
- `.augmentignore` - Ignore patterns for Augment
- `.cursorignore` - Ignore patterns for Cursor
- `.v0ignore` - Ignore patterns for v0
- `.windsurfignore` - Ignore patterns for Windsurf
- `.clinerc` - Configuration for Cline
- `.rooignore` - Ignore patterns for Roo
- `.geminiignore` - Ignore patterns for Gemini Code Assist
- `.loveablerc` - Configuration for Loveable
- `.boltignore` - Ignore patterns for Bolt
- `.codyignore` - Ignore patterns for Cody
- `.continuerc` - Configuration for Continue
All these files respect `.gitignore` patterns and only include additional tool-specific patterns. The `!` prefix can be used in these files to include files that are excluded by `.gitignore`.
## Project Overview
- **Plugin Name**: Fix 'Plugin file does not exist' Notices
@ -29,127 +10,65 @@ All these files respect `.gitignore` patterns and only include additional tool-s
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.
## Reference Plugins
## AI Workflows
The `reference-plugins/` directory contains plugins that can be used for reference or inspiration. When developing new features or improving existing ones, you should:
Detailed workflow documentation is available in the `.ai-workflows/` directory:
1. Examine these reference plugins for best practices in code structure, organization, and implementation
2. Look for patterns in how they handle similar functionality
3. Consider their approach to user interface design and user experience
4. Study their documentation style and thoroughness
These plugins are not part of the codebase and are ignored by Git, but they provide valuable examples of WordPress plugin development standards and techniques.
- **@.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
### Version Numbering Convention
We follow [Semantic Versioning](https://semver.org/):
- **MAJOR.MINOR.PATCH** (e.g., 1.6.0)
- **MAJOR.MINOR.PATCH** (e.g., 2.2.2)
- **MAJOR**: Breaking changes
- **MINOR**: New features, non-breaking
- **PATCH**: Bug fixes, non-breaking
### When to Increment Version Numbers
### Time-Efficient Development Workflow
- **PATCH** (1.6.0 → 1.6.1):
- Bug fixes
- Small text changes
- Minor improvements that don't add new features
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
- **MINOR** (1.6.0 → 1.7.0):
- New features
- Significant improvements to existing functionality
- Deprecation of features (but not removal)
When updating version numbers, see **@.ai-workflows/release-process.md** for the complete checklist.
- **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. `wp-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
6. Update `languages/wp-fix-plugin-does-not-exist-notices.pot` (Project-Id-Version and POT-Creation-Date)
**IMPORTANT**: Always ensure README.md is kept in sync with readme.txt for consistency across platforms.
**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
### Branch Naming Convention
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`
- 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"
### 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:
- `wp-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/wp-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:
@ -159,13 +78,15 @@ The plugin is hosted on multiple repositories:
Always push changes to all remotes to keep them in sync.
## GitHub Actions
## Git Updater Integration
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
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
@ -175,119 +96,18 @@ Before releasing:
3. Verify all features work as expected
4. Check for any PHP warnings or notices
### Local Testing Environment
Local environment variables and paths are documented in **@.ai-workflows/local-env-vars.md**.
Local environment variables and paths are documented in `.ai-workflows/local-env-vars.md`. This includes:
## Developer Preferences
- Repository paths
- Local WordPress testing environment paths
- URLs for testing and development tools
- Build and deploy script locations
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:
Refer to this file for the most up-to-date information about the local development environment.
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
### Using WP-CLI with LocalWP
This ensures consistency across coding sessions and reduces the need for developers to repeatedly explain their preferences.
WP-CLI can be used with LocalWP for various tasks:
## Common Tasks
```bash
# Navigate to the WordPress directory
cd ~/Local/plugin-testing/app/public
# Run WP-CLI commands
~/Local/plugin-testing/app/bin/wp plugin list
~/Local/plugin-testing/app/bin/wp transient delete --all
~/Local/plugin-testing/app/bin/wp cache flush
```
## 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
# - wp-fix-plugin-does-not-exist-notices.php
# - CHANGELOG.md
# - readme.txt
# - README.md
# - languages/wp-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
```
For detailed instructions on common tasks like creating releases, adding features, fixing bugs, and testing previous versions, see **@.ai-workflows/release-process.md**.

View File

@ -6,15 +6,17 @@ This document provides guidance for AI assistants to help with bug fixing for th
### 1. Create a Bug Fix Branch
Always start by creating a bug fix branch from the main branch:
Always start by creating a bug fix branch from the latest main branch pulled from origin (this step is mandatory):
```bash
git checkout main
git pull github main
git pull origin main # Critical step - never skip this
git checkout -b fix/bug-description
```
Use a descriptive name that clearly indicates what bug is being fixed.
Use a descriptive name that clearly indicates what bug is being fixed. If there's an issue number, include it in the branch name (e.g., `fix/123-plugin-activation-error`).
For more detailed git workflow guidelines, see **@.ai-workflows/git-workflow.md**.
### 2. Understand the Bug
@ -99,13 +101,18 @@ If the repository uses pull requests for code review, create a pull request from
## Determining Version Increment
After fixing a bug, determine the appropriate version increment:
After fixing a bug and confirming it works, determine the appropriate version increment:
- **PATCH** (e.g., 1.6.0 → 1.6.1): For most bug fixes that don't change functionality
- **IMPORTANT**: Always increment the patch version for every change, even small ones, to make rollbacks easier if issues are found in testing
- **MINOR** (e.g., 1.6.0 → 1.7.0): For bug fixes that introduce new features or significant changes
- **MAJOR** (e.g., 1.6.0 → 2.0.0): For bug fixes that introduce breaking changes
**IMPORTANT**: Don't update version numbers during initial development and testing. Only create a version branch (e.g., `v2.2.3`) and update version numbers when the fix is confirmed working.
This approach is more time-efficient as it allows you to focus on fixing the bug without worrying about version updates until the fix is confirmed working.
For detailed guidelines on time-efficient development and testing, see **@.ai-workflows/incremental-development.md**.
## Testing Previous Versions
To test a previous version of the plugin:

View File

@ -0,0 +1,62 @@
# Developer Preferences Memory
This document serves as a persistent memory for developer preferences established during coding sessions. AI assistants should refer to this document to understand the developer's preferences and update it as new preferences are established.
## Purpose
- Maintain a consistent record of developer preferences across coding sessions
- Ensure AI assistants can provide assistance that aligns with the developer's preferred coding style and practices
- Reduce the need for developers to repeatedly explain their preferences
## How to Use This Document
- **AI Assistants**: Review this document before providing assistance. Update it when new preferences are established through user feedback.
- **Developers**: Reference this document to see what preferences have been recorded. Feel free to edit it directly to add or modify preferences.
## Recorded Preferences
### File and Directory Structure
- Prefer lowercase filenames for consistency across the codebase
- Use unique folder names following best practices
- Folder references should be easily identifiable when using @mentions in AI-assisted coding
- Admin-specific functionality should be in the `admin/lib/` directory
- Core plugin functionality should be in the `includes/` directory
### Code Style
- Follow WordPress coding standards
- Use OOP best practices for WordPress plugins
- Create modular, maintainable, and efficient code structure
### Documentation
- Prefer token-efficient documentation in `.ai-assistant.md` that references `.ai-workflows/` files
- Document the release workflow in `.ai-assistant.md` and `.ai-workflows/release-process.md`
- Store environment variable documentation in `.ai-workflows/local-env-vars.md`
- Maintain consistent documentation across readme.txt, README.md, and CHANGELOG.md
### Asset Organization
- Store banner, icon, and screenshot images in `.wordpress-org/assets/`
- Store WORDPRESS_ORG files within `/wordpress-org`
- Organize files in `/assets` into relevant `/admin` folders
### Version Control
- Use standard Git practices for version control and code management
- When updating plugin versions, create a GitHub tag and trigger GitHub actions
- Follow a specific release process with proper tagging and GitHub releases
- Ensure commits are merged to the main branch as Git Updater pulls data from the readme.txt file in the primary branch
### Plugin Development
- Prefer simpler solutions over complex ones for plugins
- Use a specific formatting style for the CHANGELOG.md file, using #### for section headings
- When updating plugin versions, remember to update language files (POT/PO)
- Comment out redundant code during testing
### Potential AI Assised IDE Issues
- Check for non-standard local terminal commandline customisations that might not be understood by the AI IDE in its terminal useage and cause errors in execution or confusion in not seeing expected results, and advise on how to resolve
- Check for non-standard or multiple python and node.js versions, including homebrew versions, that might not be understood by the AI IDE in its terminal useage and cause errors in execution or confusion in not seeing expected results, and advise on how to resolve

View File

@ -6,15 +6,17 @@ This document provides guidance for AI assistants to help with feature developme
### 1. Create a Feature Branch
Always start by creating a feature branch from the main branch:
Always start by creating a feature branch from the latest main branch pulled from origin (this step is mandatory):
```bash
git checkout main
git pull github 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.
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
@ -58,21 +60,39 @@ git commit -m "Add feature: descriptive name"
When the feature is ready to be released:
1. Create a version branch for the release:
1. Create a version branch with the appropriate version number (typically increment the minor version for features):
```bash
git checkout -b v{MAJOR}.{MINOR}.{PATCH}
# Example: from 2.2.0 to 2.3.0
git checkout -b v{MAJOR}.{MINOR+1}.0
```
2. Merge your feature branch into the version branch:
2. 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)
3. Commit the version updates:
```bash
git merge feature/descriptive-name --no-ff
git add .
git commit -m "Version {MAJOR}.{MINOR+1}.0 - [brief description]"
```
3. Update version numbers and changelog entries
4. Tag the version as stable:
4. Follow the standard release process from this point
```bash
git tag -a v{MAJOR}.{MINOR+1}.0-stable -m "Stable version {MAJOR}.{MINOR+1}.0"
```
5. 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)

View File

@ -0,0 +1,59 @@
# Folder Structure
This document outlines the folder structure of the plugin and explains the purpose of each directory.
## Root Directories
- **admin/** - Contains admin-specific functionality and assets
- **includes/** - Contains core plugin functionality and classes
- **languages/** - Contains translation files
- **scripts/** - Contains build and deployment scripts
- **.ai-workflows/** - Contains documentation for AI assistants
- **.github/** - Contains GitHub-specific files like workflows
- **.wordpress-org/** - Contains WordPress.org assets like banners and screenshots
## Admin Directory Structure
- **admin/css/** - Admin-specific CSS files
- **admin/js/** - Admin-specific JavaScript files
- **admin/images/** - Admin-specific images
- **admin/partials/** - Admin-specific template partials
- **admin/settings/** - Admin settings functionality
- **admin/tools/** - Admin tools functionality
- **admin/lib/** - Admin-specific library files and helper functions
- **admin/lib/admin.php** - Admin class for handling admin-specific functionality
- **admin/lib/modal.php** - Modal class for handling the update source selector modal
## Includes Directory
The `includes/` directory contains the core plugin functionality:
- **includes/core.php** - Core class for handling the main plugin functionality
- **includes/plugin.php** - Main plugin class that initializes all components
- **includes/updater.php** - Updater class for handling plugin updates
## File Naming Conventions
- All PHP files in the `includes/` directory use lowercase filenames
- All directories use lowercase names
- JavaScript and CSS files use kebab-case (e.g., `update-source-selector.js`)
## Best Practices
1. **Unique Directory Names**: Each directory should have a unique name to avoid confusion
2. **Logical Organization**: Files should be organized logically by function
3. **Consistent Naming**: File and directory names should follow consistent naming conventions
4. **Clear Separation**: Admin functionality should be separate from core functionality
5. **Minimal Dependencies**: Files should have minimal dependencies on other files
## @mentions for AI Assistants
When referring to files or directories in AI conversations, use the following format:
- **@includes/plugin.php** - Main plugin class
- **@includes/core.php** - Core functionality
- **@admin/lib/admin.php** - Admin functionality
- **@admin/lib/modal.php** - Modal functionality
- **@includes/updater.php** - Updater functionality
- **@admin/js/update-source-selector.js** - Update source selector JavaScript
- **@admin/css/update-source-selector.css** - Update source selector CSS

View File

@ -0,0 +1,255 @@
# Git Workflow Guide for AI Assistants
This document provides guidance for AI assistants to help with git workflow management for the Fix Plugin Does Not Exist Notices plugin.
## Core Git Workflow Principles
### 1. Always Start from Latest Main Branch
Before creating any new branch, always ensure you're working with the latest code from the main branch by pulling from the origin:
```bash
git checkout main
git pull origin main
```
This critical step ensures that your new branch includes all the latest changes from the remote repository and reduces the chance of merge conflicts later. Never skip this step, as working from an outdated main branch can lead to integration problems.
### 2. One Issue Per Branch
Create a separate branch for each issue or feature you're working on:
- For bug fixes: `fix/issue-description` or `fix/issue-number-description`
- For features: `feature/descriptive-name`
- For small improvements: `patch/descriptive-name`
- For code restructuring: `refactor/descriptive-name`
**Important**: Use descriptive names without version numbers for development branches. This allows focusing on the changes without worrying about version updates until the changes are confirmed working.
Only create version branches (e.g., `v2.2.3`) when changes are ready for release, and only then update version numbers in files.
This approach keeps changes focused, makes code review easier, and provides clear rollback points if needed.
### 3. Pull Request for Each Issue
Create a separate pull request for each issue or feature. This ensures:
- Each change can be reviewed independently
- Issues can be merged as soon as they're ready
- Changes can be reverted individually if needed
- CI/CD checks can run on focused changes
## Detailed Workflow
### Starting a New Task
1. **Update Main Branch from Origin**
```bash
git checkout main
git pull origin main
```
This step is mandatory before creating any new branch to ensure you're working with the latest code.
2. **Create a New Branch**
```bash
git checkout -b [branch-type]/[description]
```
Examples:
```bash
git checkout -b fix/123-plugin-activation-error
git checkout -b feature/update-source-selector
git checkout -b patch/2.2.1
```
3. **Make Your Changes**
- Make focused changes related only to the specific issue
- Commit regularly with clear, descriptive messages
- Reference issue numbers in commit messages when applicable
4. **Testing Approach**
For efficient development:
- **Local Testing (Default)**: Test without updating version numbers
```bash
# Get current version from plugin file
CURRENT_VERSION=$(grep -o "Version: [0-9.]*" wp-fix-plugin-does-not-exist-notices.php | cut -d' ' -f2)
# Build and deploy with current version
./build.sh $CURRENT_VERSION
```
- **Remote Testing (When Requested)**: Push development branch to remote
```bash
git add .
git commit -m "[Brief description] for remote testing"
git push origin [branch-name]
```
- **Version Creation**: Only when changes are confirmed working
```bash
# Create version branch
git checkout -b v{MAJOR}.{MINOR}.{PATCH}
# Update version numbers in all required files
# Commit version updates
git add .
git commit -m "Version {MAJOR}.{MINOR}.{PATCH} - Brief description"
# Tag as stable
git tag -a v{MAJOR}.{MINOR}.{PATCH}-stable -m "Stable version {MAJOR}.{MINOR}.{PATCH}"
```
5. **Push Branch to Remote (When Needed)**
```bash
git push origin [branch-name]
```
### Creating a Pull Request
1. **Ensure Tests Pass Locally**
- Run any available tests to ensure your changes work as expected
- Fix any issues before creating a pull request
2. **Create Pull Request**
- Create a pull request from your branch to the main branch
- Include a clear description of the changes
- Reference any related issues
- Assign reviewers if appropriate
3. **Address Review Feedback**
- Make requested changes
- Push additional commits to the same branch
- Respond to comments
### CI/CD Integration
Each pull request should pass through CI/CD checks before being merged. This ensures that all changes are compatible with the existing codebase and meet quality standards.
1. **Automated Tests**
- Unit tests
- Integration tests
- Code style checks
- Compatibility checks
2. **Manual Review**
- Code review by team members
- Functional testing in test environment
- Verification of feature requirements
3. **Approval Process**
- Required approvals before merging
- Final checks for conflicts with other pending PRs
- Verification that all CI/CD checks have passed
4. **Compatibility with Unmerged PRs**
- When multiple PRs are in progress simultaneously, ensure each PR is compatible with the main branch
- For related changes, consider using feature flags to allow independent merging
- Document dependencies between PRs in the PR description
### Handling Concurrent Development
When working on multiple issues simultaneously:
1. **Keep Branches Independent**
- Always create new branches from the latest main branch pulled from origin, not from other feature branches
- This ensures each PR can be merged independently and contains all the latest changes
2. **Handle Conflicts Proactively**
- If main has been updated with other changes while you're working:
```bash
git checkout main
git pull origin main
git checkout your-branch
git merge main
```
- Resolve any conflicts locally before pushing
3. **Coordinate on Dependent Changes**
- If changes depend on each other, note this in the PR description
- Consider using the "Depends on #PR-number" notation in PR descriptions
## Release Process
When preparing for a release:
1. **Ensure All Required PRs are Merged**
- All features and fixes planned for the release should be merged to main
2. **Create a Release Branch**
```bash
git checkout main
git pull origin main
git checkout -b v{MAJOR}.{MINOR}.{PATCH}
```
3. **Follow Standard Release Process**
- Update version numbers
- Update changelogs
- Create tag
- See **@.ai-workflows/release-process.md** for complete details
## Contributing to External Repositories
When working on issues for external repositories (pull/merge requests):
### 1. Clearly Indicate Testing Status
In the PR description and comments, clearly indicate the testing status:
- **Not tested**: "This PR addresses [issue] but has not been tested locally or remotely. It's ready for community/maintainer testing."
- **Locally tested**: "This PR has been tested in a local WordPress environment and [describe results]."
- **Remotely tested**: "This PR has been tested with a remote build and [describe results]."
### 2. Provide Testing Instructions
Include clear instructions for maintainers on how to test the changes:
- Steps to reproduce the original issue (if applicable)
- Steps to verify the fix or feature
- Any specific environments or configurations needed for testing
### 3. Be Responsive to Feedback
Monitor the PR for feedback from maintainers and be prepared to make additional changes if requested.
## Best Practices
### Commit Messages
- 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"
- For more complex changes, add a detailed description after the first line
### Branch Management
- Delete branches after they've been merged
- Keep branch names descriptive but concise
- Use consistent naming conventions
### Code Review
- Review code thoroughly before approving
- Test changes locally when possible
- Provide constructive feedback
- See **@.ai-workflows/code-review.md** for detailed code review guidelines
### Suggested Improvements
If you identify potential improvements outside the scope of the current issue:
1. **Document the Suggestion**
- Note the suggestion in the PR comments
- Create a new issue for the suggestion
- Be specific about the benefits and implementation details
2. **Create a Separate Branch**
- Don't include unrelated improvements in the current PR
- Create a new branch from the latest main branch for the suggested improvement
- Submit a separate PR for the suggestion
3. **Ensure Compatibility**
- Make sure the suggested improvement is compatible with any unmerged PRs
- If the improvement depends on changes in another PR, note this dependency
- Consider how the improvement will interact with other pending changes

View File

@ -0,0 +1,225 @@
# Incremental Development and Testing Guide
This document provides guidance for AI assistants to help with incremental development and testing for the Fix Plugin Does Not Exist Notices plugin.
## Time-Efficient Development Principles
### Branch Naming for Development
1. **Initial Development Branches**
- Use descriptive names without version numbers:
- `fix/issue-description` - For bug fixes
- `feature/descriptive-name` - For new features
- `patch/descriptive-name` - For small improvements
- `refactor/descriptive-name` - For code restructuring
- **Don't update version numbers** during this phase
- Focus on implementing and testing the changes
2. **Version Branches**
- Only create after changes are confirmed working:
- `v{MAJOR}.{MINOR}.{PATCH}` (e.g., `v2.2.3`)
- Only update version numbers at this point
- This minimizes unnecessary version updates
### Version Numbering Guidelines
1. **Patch Versions (X.Y.Z → X.Y.Z+1)**
- Use for bug fixes and small improvements
- Example: `v2.2.3`
2. **Minor Versions (X.Y.Z → X.Y+1.0)**
- Use for new features or significant improvements
- Example: `v2.3.0`
3. **Major Versions (X.Y.Z → X+1.0.0)**
- Only increment when numerous features and fixes are tested and confirmed stable
- Reserved for breaking changes or significant overhauls
- Example: `v3.0.0`
### Marking Stable Versions
When the user confirms that changes are working correctly:
1. Create a version branch and update version numbers
2. Tag the version branch as stable
```bash
git tag -a v{MAJOR}.{MINOR}.{PATCH}-stable -m "Stable version {MAJOR}.{MINOR}.{PATCH}"
```
3. Document in the PR or issue that this version has been confirmed stable
## Local Testing Workflow
### 1. Create a Descriptive Branch for Development
```bash
# Ensure you have the latest main branch
git checkout main
git pull origin main
# Create a descriptive branch (without version numbers)
git checkout -b fix/plugin-activation-error
```
### 2. Make Changes Without Updating Version Numbers
During the development and testing phase:
- Implement the necessary changes
- **Don't update version numbers** in any files yet
- Focus on the functionality
### 3. Build and Deploy Locally
For local testing, use the current version number from the main plugin file:
```bash
# Get the current version from the plugin file
CURRENT_VERSION=$(grep -o "Version: [0-9.]*" wp-fix-plugin-does-not-exist-notices.php | cut -d' ' -f2)
# Build and deploy with current version
./build.sh $CURRENT_VERSION
```
This will:
1. Create a build directory
2. Copy required files to the build directory
3. Deploy the plugin to your local WordPress testing environment
**Note**: For local testing iterations, you do not need to commit changes, push to remote repositories, or create tags unless specifically requested.
### 4. Test and Evaluate
Test the changes thoroughly in the local environment:
- Verify that the specific issue is fixed or feature works as expected
- Check for any regressions or new issues
- Document the results
### 5. Based on Testing Results
- **If changes need further refinement**: Continue working in the same branch
- **If changes work as expected**: Proceed to version branch creation
### 6. Creating a Version Branch
When changes are confirmed working and ready for release:
1. Create a version branch with the appropriate version number:
```bash
# Determine the appropriate version increment (patch, minor, or major)
# based on the nature of the changes
git checkout -b v{MAJOR}.{MINOR}.{PATCH}
```
2. 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)
3. Commit the version updates:
```bash
git add .
git commit -m "Version {MAJOR}.{MINOR}.{PATCH} - [brief description]"
```
4. Tag the version as stable:
```bash
git tag -a v{MAJOR}.{MINOR}.{PATCH}-stable -m "Stable version {MAJOR}.{MINOR}.{PATCH}"
```
## Remote Testing Workflow
When the user specifically requests remote testing:
### 1. Commit Changes to Remote Repository
If testing a development branch (without version updates):
```bash
git add .
git commit -m "[brief description] for remote testing"
git push origin [branch-name]
```
If testing a version branch (with version updates):
```bash
git add .
git commit -m "Version {MAJOR}.{MINOR}.{PATCH} - [brief description]"
git push origin v{MAJOR}.{MINOR}.{PATCH}
```
### 2. Create and Push Tag (For Version Branches Only)
```bash
git tag -a v{MAJOR}.{MINOR}.{PATCH} -m "Version {MAJOR}.{MINOR}.{PATCH} for remote testing"
git push origin v{MAJOR}.{MINOR}.{PATCH}
```
This will trigger GitHub Actions to build the installable ZIP file.
### 3. Verify Remote Build
Check that the GitHub Actions workflow completed successfully and the ZIP file is available for download.
### 4. Test and Evaluate
Test the remotely built version and document the results.
## Contributing to External Repositories
When working on issues for external repositories (pull/merge requests):
### 1. Clearly Indicate Testing Status
In the PR description and comments, clearly indicate the testing status:
- **Not tested**: "This PR addresses [issue] but has not been tested locally or remotely. It's ready for community/maintainer testing."
- **Locally tested**: "This PR has been tested in a local WordPress environment and [describe results]."
- **Remotely tested**: "This PR has been tested with a remote build and [describe results]."
### 2. Provide Testing Instructions
Include clear instructions for maintainers on how to test the changes:
- Steps to reproduce the original issue (if applicable)
- Steps to verify the fix or feature
- Any specific environments or configurations needed for testing
### 3. Be Responsive to Feedback
Monitor the PR for feedback from maintainers and be prepared to make additional changes if requested.
## Rollback Procedure
If a change causes issues after release:
### 1. Identify the Last Stable Version
Find the last version that was marked as stable:
```bash
git tag -l "*-stable"
```
### 2. Create a New Branch from the Stable Version
```bash
git checkout v{MAJOR}.{MINOR}.{PATCH}-stable
git checkout -b fix/rollback-based-fix
```
### 3. Make Necessary Changes
Implement the fix based on the stable version. Don't update version numbers yet.
### 4. Test the Changes
Test thoroughly to ensure the fix resolves the issues.
### 5. When Confirmed Working
Create a version branch with an incremented patch version and update all version numbers as described in the "Creating a Version Branch" section.

View File

@ -6,7 +6,12 @@ This directory contains workflow documentation for AI assistants working with th
- **bug-fixing.md**: Guidelines for identifying and fixing bugs in the codebase
- **code-review.md**: Standards and procedures for reviewing code changes
- **dev-prefs-memory.md**: Persistent memory of developer preferences
- **feature-development.md**: Process for developing new features
- **folder-structure.md**: Documentation of the plugin's folder structure and naming conventions
- **git-workflow.md**: Detailed git workflow and branch management guidelines
- **incremental-development.md**: Time-efficient approach for incremental development and testing
- **local-env-vars.md**: Local development environment paths and URLs
- **release-process.md**: Steps for preparing and publishing new releases
These documents help ensure consistent quality and approach when using AI tools to assist with development tasks.

View File

@ -15,65 +15,121 @@ This document provides step-by-step instructions for AI assistants to help with
Based on the changes made, determine the appropriate version increment:
1. **PATCH** (e.g., 1.6.0 → 1.6.1): For bug fixes and minor improvements
- **IMPORTANT**: Always increment the patch version for every change, even small ones, to make rollbacks easier if issues are found in testing
2. **MINOR** (e.g., 1.6.0 → 1.7.0): For new features and significant improvements
3. **MAJOR** (e.g., 1.6.0 → 2.0.0): For breaking changes
- Only increment when numerous features and fixes are tested and confirmed stable
**IMPORTANT**: For time-efficient development:
- Use descriptive branches (`fix/`, `feature/`, `patch/`, `refactor/`) without version numbers during development
- Don't update version numbers during initial development and testing
- Only create version branches (e.g., `v2.2.3`) and update version numbers when changes are confirmed working
This approach allows focusing on the changes without worrying about version updates until they're ready for release.
For detailed guidelines on time-efficient development and testing, see **@.ai-workflows/incremental-development.md**.
## Release Steps
### 1. Create a New Branch
### 1. Create a Version Branch
When changes are confirmed working and ready for release:
```bash
# First, ensure you have the latest main branch
git checkout main
git pull origin main
# Option 1: If you're coming from a development branch
git checkout fix/your-fix-branch # or feature/your-feature-branch
# Option 2: Create a version branch directly from main
git checkout -b v{MAJOR}.{MINOR}.{PATCH}
```
Example:
```bash
git checkout -b v1.7.0
git checkout main
git pull origin main
# If coming from a development branch
git checkout feature/add-new-selector
# Create the version branch
git checkout -b v2.3.0
```
**IMPORTANT**: The version branch is where you'll update all version numbers. This should only be done after the changes have been tested and confirmed working.
For more detailed git workflow guidelines, see **@.ai-workflows/git-workflow.md**.
### 2. Update Version Numbers
Update the version number in the following files:
#### a. Main Plugin File (wp-fix-plugin-does-not-exist-notices.php)
Update both the plugin header and the version parameter in the Plugin class initialization:
```php
/**
* Plugin Name: Fix 'Plugin file does not exist.' Notices
* Plugin URI: https://wordpress.org/plugins/fix-plugin-does-not-exist-notices/
* Description: Adds missing plugins to the plugins list with a "Remove Reference" link so you can permanently clean up invalid plugin entries and remove error notices.
* Plugin URI: https://www.wpallstars.com
* Description: Adds missing plugins to your plugins list with a "Remove Notice" action link, allowing you to safely clean up invalid plugin references.
* Version: {MAJOR}.{MINOR}.{PATCH}
* ...
*/
// At the bottom of the file, update the version parameter:
new WPALLSTARS\FixPluginDoesNotExistNotices\Plugin(__FILE__, '{MAJOR}.{MINOR}.{PATCH}');
```
Also update the FPDEN_VERSION constant:
#### b. JavaScript Files with Version Constants
```php
define( 'FPDEN_VERSION', '{MAJOR}.{MINOR}.{PATCH}' );
Check for any JavaScript files that might contain version constants:
```javascript
// Current plugin version - this should match the version in the main plugin file
const CURRENT_VERSION = '{MAJOR}.{MINOR}.{PATCH}';
```
#### b. CHANGELOG.md
**Note**: As of version 2.2.1, we've removed redundant JavaScript files like `version-fix.js` since Git Updater now correctly detects the version from the main branch.
#### c. CHANGELOG.md
Add a new section at the top of the CHANGELOG.md file:
```markdown
## [{MAJOR}.{MINOR}.{PATCH}] - YYYY-MM-DD
### Added
- New feature 1
- New feature 2
All notable changes to this project should be documented both here and in the main Readme files.
### Changed
#### [{MAJOR}.{MINOR}.{PATCH}] - YYYY-MM-DD
#### Added/Changed/Fixed
- Change 1
- Change 2
- Change 3
### Fixed
- Bug fix 1
- Bug fix 2
#### [{PREVIOUS_VERSION}] - YYYY-MM-DD
```
#### c. POT File (languages/wp-fix-plugin-does-not-exist-notices.pot)
Note: Use the `####` heading format for consistency with the existing CHANGELOG.md structure.
#### d. README.md
Update the Changelog section in the main README.md file to match the changes in readme.txt:
```markdown
## Changelog
### {MAJOR}.{MINOR}.{PATCH}
* Change 1
* Change 2
* Change 3
### {PREVIOUS_VERSION}
```
**IMPORTANT**: Always keep the changelogs in README.md, readme.txt, and CHANGELOG.md in sync to avoid confusion.
#### e. POT File (languages/wp-fix-plugin-does-not-exist-notices.pot)
Update the Project-Id-Version and POT-Creation-Date (IMPORTANT - don't forget this step!):
@ -84,7 +140,7 @@ Update the Project-Id-Version and POT-Creation-Date (IMPORTANT - don't forget th
Note: Always use the current date for POT-Creation-Date in the format YYYY-MM-DD.
#### d. readme.txt
#### f. readme.txt
Update the stable tag:
@ -96,73 +152,116 @@ Add a new entry to the changelog section:
```
= {MAJOR}.{MINOR}.{PATCH} =
* New feature 1
* New feature 2
* Change 1
* Change 2
* Fixed bug 1
* Fixed bug 2
* Change 3
```
Update the upgrade notice section:
### 3. Build and Test
```
= {MAJOR}.{MINOR}.{PATCH} =
Brief description of the most important changes in this release
```
#### Local Testing (Default for Incremental Development)
### 3. Commit Changes
For incremental development and testing, only local testing is required unless specifically requested:
```bash
git add wp-fix-plugin-does-not-exist-notices.php CHANGELOG.md readme.txt README.md languages/wp-fix-plugin-does-not-exist-notices.pot
git commit -m "Prepare release v{MAJOR}.{MINOR}.{PATCH}"
./build.sh {MAJOR}.{MINOR}.{PATCH}
```
### 4. Test Changes Locally
Test the changes thoroughly on the version branch to ensure everything works as expected:
This will:
1. Create a build directory
2. Install composer dependencies
3. Copy required files to the build directory
4. Create a ZIP file named `wp-fix-plugin-does-not-exist-notices-{MAJOR}.{MINOR}.{PATCH}.zip`
5. Deploy the plugin to your local WordPress testing environment
Test the plugin thoroughly in your local WordPress environment:
- Test with the latest WordPress version
- Test with PHP 7.0+ (minimum supported version)
- Verify all features work as expected
- Check for any PHP warnings or notices
- Test any specific changes made in this version
### 5. Merge to Main
#### Remote Testing (When Specifically Requested)
When satisfied with testing, merge the version branch to main:
When the user specifically requests remote testing, follow these additional steps after local testing:
1. Commit changes to the remote repository
2. Create and push a tag
3. Verify that GitHub Actions builds the installable ZIP file
4. Test the remotely built version
This is necessary when testing Git Updater integration or other features that require the plugin to be installed from a remote source.
### 4. Commit Changes
```bash
git add wp-fix-plugin-does-not-exist-notices.php CHANGELOG.md README.md readme.txt languages/wp-fix-plugin-does-not-exist-notices.pot
git commit -m "Version {MAJOR}.{MINOR}.{PATCH} - Brief description of changes"
```
Note: Make sure to include README.md in your commit to keep all changelog files in sync.
### 5. Create a Tag
```bash
git tag -a v{MAJOR}.{MINOR}.{PATCH} -m "Version {MAJOR}.{MINOR}.{PATCH} - Brief description of changes"
```
#### Marking a Version as Stable
When the user confirms that a version is working correctly and stable:
```bash
# Create a stable tag for easy reference
git tag -a v{MAJOR}.{MINOR}.{PATCH}-stable -m "Stable version {MAJOR}.{MINOR}.{PATCH}"
```
This provides a clear reference point for stable versions that can be used for rollbacks if needed.
### 6. Push Branch and Tag to Remotes
```bash
# Push the branch
git push github feature/branch-name
git push gitea feature/branch-name
# Push the tag
git push github v{MAJOR}.{MINOR}.{PATCH}
git push gitea v{MAJOR}.{MINOR}.{PATCH}
```
### 7. Verify GitHub Release
Check that the GitHub release was created successfully with the ZIP file attached:
https://github.com/wpallstars/wp-fix-plugin-does-not-exist-notices/releases
If the release doesn't appear or doesn't have the ZIP file attached, check the GitHub Actions page:
https://github.com/wpallstars/wp-fix-plugin-does-not-exist-notices/actions
### 8. Merge to Main (CRITICAL STEP)
**IMPORTANT**: This step is critical for Git Updater to detect the new version. Git Updater reads the readme.txt file from the main branch, not from tags or releases.
Merge the feature branch to main immediately after pushing the tag:
```bash
git checkout main
git merge v{MAJOR}.{MINOR}.{PATCH} --no-ff
```
The `--no-ff` flag creates a merge commit even if a fast-forward merge is possible, which helps preserve the branch history.
### 6. Push Main to Remotes
```bash
git merge feature/branch-name --no-ff
git push github main
git push gitea main
```
### 7. Create and Push Tag
The `--no-ff` flag creates a merge commit even if a fast-forward merge is possible, which helps preserve the branch history.
```bash
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}
```
### 8. Monitor GitHub Actions
Open the GitHub Actions page to monitor the build and deployment process:
https://github.com/wpallstars/wp-fix-plugin-does-not-exist-notices/actions
**Note**: Only use named branches like feature/*, fix/*, etc. for development. Release branches (v*) should always be merged to main immediately after tagging to ensure Git Updater can detect the new version.
### 9. Verify Release
- [ ] Check that the GitHub release was created successfully
- [ ] Verify that the plugin was deployed to WordPress.org
- [ ] Test the plugin from WordPress.org to ensure it works correctly
- [ ] Check that the GitHub release was created successfully with the ZIP file attached
- [ ] Verify that the plugin was deployed to WordPress.org (if applicable)
- [ ] Test the plugin from the GitHub release ZIP to ensure it works correctly
- [ ] Verify that Git Updater can detect and install the new version
- [ ] Confirm that all changelog files (README.md, readme.txt, and CHANGELOG.md) are in sync
- [ ] Verify that all CI/CD checks have passed for the release
## Testing Previous Versions

View File

@ -6,7 +6,6 @@ on:
- main
paths:
- '.wordpress-org/**'
- 'assets/**'
jobs:
assets:
@ -15,10 +14,10 @@ jobs:
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: WordPress.org plugin asset/readme update
uses: 10up/action-wordpress-plugin-asset-update@stable
env:
SVN_PASSWORD: ${{ secrets.SVN_PASSWORD }}
SVN_USERNAME: ${{ secrets.SVN_USERNAME }}
SLUG: wp-fix-plugin-does-not-exist-notices
SLUG: wp-fix-plugin-does-not-exist-notices

View File

@ -28,7 +28,21 @@ jobs:
cp readme.txt build/wp-fix-plugin-does-not-exist-notices/
cp LICENSE build/wp-fix-plugin-does-not-exist-notices/
cp README.md build/wp-fix-plugin-does-not-exist-notices/
cp -r assets build/wp-fix-plugin-does-not-exist-notices/
cp -r admin build/wp-fix-plugin-does-not-exist-notices/
cp -r includes build/wp-fix-plugin-does-not-exist-notices/
# Copy directories if they exist
if [ -d "assets" ]; then
cp -r assets build/wp-fix-plugin-does-not-exist-notices/
fi
if [ -d "languages" ]; then
cp -r languages build/wp-fix-plugin-does-not-exist-notices/
fi
if [ -d ".wordpress-org" ]; then
cp -r .wordpress-org build/wp-fix-plugin-does-not-exist-notices/
fi
- name: Create ZIP file
run: |
@ -46,7 +60,7 @@ jobs:
wp-fix-plugin-does-not-exist-notices-${{ steps.get_version.outputs.VERSION }}.zip
body: |
Fix 'Plugin file does not exist.' Notices v${{ steps.get_version.outputs.VERSION }}
See [CHANGELOG.md](https://github.com/wpallstars/wp-fix-plugin-does-not-exist-notices/blob/main/CHANGELOG.md) for details.
# Deploy to WordPress.org
@ -57,7 +71,7 @@ jobs:
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: WordPress Plugin Deploy
id: deploy
uses: 10up/action-wordpress-plugin-deploy@stable

View File

@ -16,12 +16,10 @@ This directory contains assets specific to the WordPress.org plugin repository a
## Asset Organization
- **PNG Files**: All PNG files for WordPress.org are stored in this directory (`.wordpress-org/assets/`)
- **Source Files**: Source files (PXD, SVG) are stored in the main `assets/` directory:
- `assets/banner/banner-1544x500.pxd`
- `assets/icon/icon.svg`
- `assets/icon/icon-1024x1024.pxd`
- `assets/screenshots/screenshot-1.pxd`
- **All Asset Files**: All files for WordPress.org are stored in this directory (`.wordpress-org/assets/`)
- PNG files (icon-256x256.png, banner-772x250.png, etc.)
- Source files (PXD, SVG)
- Documentation
## Purpose
@ -55,9 +53,8 @@ Note that the `-rtl` suffix is specifically for Right-to-Left language support,
## Build Process
The build script (`build.sh`) is configured to:
1. Keep source files (PXD, SVG) in the `assets/` directory for development
2. Use PNG files from the `.wordpress-org/assets/` directory for the build
3. Copy these PNG files to the appropriate locations in the build directory
1. Use all asset files from the `.wordpress-org/assets/` directory
2. Copy these files to the appropriate locations in the build directory
## Additional Resources
@ -65,4 +62,4 @@ For more detailed information about WordPress.org plugin assets, please see:
- [WordPress Plugin Developer Handbook - Plugin Assets](https://developer.wordpress.org/plugins/wordpress-org/plugin-assets/)
- [WordPress Plugin Directory README.txt Standard](https://developer.wordpress.org/plugins/wordpress-org/how-your-readme-txt-works/)
- [WordPress.org Plugin Submission Assets Guide](../assets/WORDPRESS_ORG_ASSETS.md)
- [WordPress.org Plugin Submission Assets Guide](./.wordpress-org/WORDPRESS_ORG_ASSETS.md)

View File

@ -14,9 +14,9 @@ When submitting a plugin to WordPress.org, you'll work with an SVN repository th
banner-1544x500.png
screenshot-1.png
/tags/ # Contains tagged releases
/1.6.27/
/2.2.5/
[plugin files]
/1.6.26/
/2.2.4/
[plugin files]
/trunk/ # Contains the current version of the plugin
[plugin files]
@ -28,8 +28,6 @@ For languages that read from right to left (like Hebrew and Arabic), you can pro
- `banner-772x250-rtl.png`
- `icon-256x256-rtl.png`
Note: `-rtl` is specifically for Right-to-Left language support, not for dark theme versions.
## Asset Requirements
### Icon
@ -71,20 +69,20 @@ Note: `-rtl` is specifically for Right-to-Left language support, not for dark th
- When you receive SVN access, use these commands:
```bash
# Check out the repository
svn checkout https://plugins.svn.wordpress.org/fix-plugin-does-not-exist-notices/
svn checkout https://plugins.svn.wordpress.org/wp-fix-plugin-does-not-exist-notices/
# Copy plugin files to trunk
cp -r [your-local-plugin-files]/* fix-plugin-does-not-exist-notices/trunk/
cp -r [your-local-plugin-files]/* wp-fix-plugin-does-not-exist-notices/trunk/
# Copy assets to assets directory
cp .wordpress-org/assets/icon-256x256.png fix-plugin-does-not-exist-notices/assets/
cp .wordpress-org/assets/icon-128x128.png fix-plugin-does-not-exist-notices/assets/
cp .wordpress-org/assets/banner-772x250.png fix-plugin-does-not-exist-notices/assets/
cp .wordpress-org/assets/banner-1544x500.png fix-plugin-does-not-exist-notices/assets/
cp .wordpress-org/assets/screenshot-1.png fix-plugin-does-not-exist-notices/assets/
cp .wordpress-org/assets/icon-256x256.png wp-fix-plugin-does-not-exist-notices/assets/
cp .wordpress-org/assets/icon-128x128.png wp-fix-plugin-does-not-exist-notices/assets/
cp .wordpress-org/assets/banner-772x250.png wp-fix-plugin-does-not-exist-notices/assets/
cp .wordpress-org/assets/banner-1544x500.png wp-fix-plugin-does-not-exist-notices/assets/
cp .wordpress-org/assets/screenshot-1.png wp-fix-plugin-does-not-exist-notices/assets/
# Add new files
cd fix-plugin-does-not-exist-notices
cd wp-fix-plugin-does-not-exist-notices
svn add --force trunk/*
svn add --force assets/*
@ -113,10 +111,10 @@ For converting SVG to PNG or creating different sizes of images, you can use:
- **Command Line** (using ImageMagick):
```bash
# For 256x256 icon
convert -background none -size 256x256 assets/icon/icon.svg assets/icon/icon-256x256.png
convert -background none -size 256x256 .wordpress-org/assets/icon.svg .wordpress-org/assets/icon-256x256.png
# For 128x128 icon
convert -background none -size 128x128 assets/icon/icon.svg assets/icon/icon-128x128.png
convert -background none -size 128x128 .wordpress-org/assets/icon.svg .wordpress-org/assets/icon-128x128.png
```
## Resources

View File

@ -30,15 +30,15 @@ This document outlines the requirements for assets when submitting a plugin to t
## Current Status
### Icon
- ✅ SVG source available in `assets/icon/icon.svg`
- ✅ PNG files created in `assets/icon/icon-256x256.png` and `assets/icon/icon-128x128.png`
- ✅ SVG source available in `.wordpress-org/assets/icon.svg`
- ✅ PNG files created in `.wordpress-org/assets/icon-256x256.png` and `.wordpress-org/assets/icon-128x128.png`
### Banner
- ✅ Both sizes available in `assets/banner/`
- ✅ Both sizes available in `.wordpress-org/assets/`
- ✅ Properly named files: `banner-772x250.png` and `banner-1544x500.png`
### Screenshots
- ✅ One screenshot available in `assets/screenshots/screenshot-1.png`
- ✅ One screenshot available in `.wordpress-org/assets/screenshot-1.png`
- ✅ Screenshot description in readme.txt updated to reference only one screenshot
## SVN Directory Structure
@ -53,9 +53,9 @@ When submitting to WordPress.org, your SVN repository will have this structure:
banner-1544x500.png
screenshot-1.png
/tags/
/1.6.27/
/2.2.5/
[plugin files]
/1.6.26/
/2.2.4/
[plugin files]
/trunk/
[current plugin files]
@ -68,11 +68,11 @@ When submitting to WordPress.org, your SVN repository will have this structure:
```bash
# Copy assets to WordPress.org SVN assets directory
cp assets/icon/icon-256x256.png /path/to/wordpress-svn/assets/
cp assets/icon/icon-128x128.png /path/to/wordpress-svn/assets/
cp assets/banner/banner-772x250.png /path/to/wordpress-svn/assets/
cp assets/banner/banner-1544x500.png /path/to/wordpress-svn/assets/
cp assets/screenshots/screenshot-1.png /path/to/wordpress-svn/assets/
cp .wordpress-org/assets/icon-256x256.png wp-fix-plugin-does-not-exist-notices/assets/
cp .wordpress-org/assets/icon-128x128.png wp-fix-plugin-does-not-exist-notices/assets/
cp .wordpress-org/assets/banner-772x250.png wp-fix-plugin-does-not-exist-notices/assets/
cp .wordpress-org/assets/banner-1544x500.png wp-fix-plugin-does-not-exist-notices/assets/
cp .wordpress-org/assets/screenshot-1.png wp-fix-plugin-does-not-exist-notices/assets/
```
## Resources

View File

@ -1,5 +1,60 @@
All notable changes to this project should be documented both here and in the main Readme files.
#### [2.3.0] - 2025-04-15
#### Added
- Improved time-efficient development workflow documentation
- New git workflow guidelines for better branch management
- Comprehensive incremental development approach
#### Improved
- Documentation for local vs. remote testing
- Version management process for more efficient development
#### [2.2.5] - 2025-04-14
#### Added
- Documentation for the developer preferences memory file in .ai-workflows/
- Improved AI assistant instructions for maintaining developer preferences
- Updated version numbers across all files for consistency
#### [2.2.4] - 2025-04-14
#### Added
- Developer preferences memory file for AI assistants
- Improved AI assistant documentation with instructions for maintaining developer preferences
- Updated WordPress.org documentation with correct plugin slug and version numbers
#### [2.2.3] - 2025-04-14
#### Changed
- Moved admin-specific files to admin/lib directory for better organization
- Updated namespaces to reflect the new file locations
- Added comprehensive folder structure documentation
- Fixed file references in the main plugin file
#### [2.2.2-stable] - 2025-04-14
#### Changed
- Renamed includes files to lowercase for consistency with the rest of the codebase
- Removed redundant Git Updater patches and version-fix.js as they're no longer needed
- Improved documentation for Git Updater integration and release process
- Fixed token-efficient documentation with references to .ai-workflows files
- Added comprehensive release process documentation with emphasis on merging to main branch
#### [2.2.1] - 2025-04-14
#### Changed
- Commented out version-fix.js script as it's no longer needed after refactoring
- Fixed version consistency across all files
#### [2.2.0] - 2025-04-14
#### Added
- Completely refactored plugin to use OOP best practices
- New class structure with proper namespaces
- Improved code organization and maintainability
- Better separation of concerns with dedicated classes
#### Changed
- Changed "Choose Update Source" link to just "Update Source"
- Fixed close button in the update source modal
- Added links to the main page for each update source in the modal
- Replaced all instances of "WP ALLSTARS" with "WPALLSTARS"
#### [2.1.1] - 2025-04-13
#### Added
- New "Choose Update Source" feature allowing users to select their preferred update source (WordPress.org, GitHub, or Gitea)
@ -241,7 +296,7 @@ All notable changes to this project should be documented both here and in the ma
#### [1.6.12] - 2025-03-14
#### Added
- Added WP ALLSTARS as a co-author
- Added WPALLSTARS as a co-author
- Updated author information and links
- Added author websites to plugin description
- Fixed issue with multiple author URLs
@ -297,7 +352,7 @@ All notable changes to this project should be documented both here and in the ma
- Version management following semantic versioning
#### Changed
- Updated organization name from 'WP All Stars' to 'WP ALLSTARS'
- Updated organization name from 'WP All Stars' to 'WPALLSTARS'
- Updated namespace from 'WPAllStars' to 'WPALLSTARS'
#### [1.6.2] - 2025-03-04

View File

@ -209,8 +209,75 @@ The plugin works by:
3. Adding helpful notifications near error messages
4. Providing a secure method to remove plugin references from the database
### Git Updater Integration
This plugin is designed to work seamlessly with the Git Updater plugin for updates from GitHub and Gitea. To ensure proper integration:
1. **Required Headers**: The plugin includes specific headers in the main plugin file that Git Updater uses to determine update sources and branches:
```php
* GitHub Plugin URI: wpallstars/wp-fix-plugin-does-not-exist-notices
* GitHub Branch: main
* Primary Branch: main
* Release Branch: main
* Release Asset: true
* Gitea Plugin URI: https://gitea.wpallstars.com/wpallstars/wp-fix-plugin-does-not-exist-notices
* Gitea Branch: main
```
2. **Tagging Releases**: When creating a new release, always tag it with the 'v' prefix (e.g., `v2.2.0`) to ensure GitHub Actions can create the proper release assets.
3. **GitHub Actions**: The repository includes a GitHub Actions workflow that automatically builds the plugin and creates a release with the .zip file when a new tag is pushed.
4. **Update Source Selection**: The plugin includes a feature that allows users to choose their preferred update source (WordPress.org, GitHub, or Gitea).
For more information on Git Updater integration, see the [Git Updater Required Headers documentation](https://git-updater.com/knowledge-base/required-headers/).
## Changelog
### 2.3.0
* Added: Improved time-efficient development workflow documentation
* Added: New git workflow guidelines for better branch management
* Added: Comprehensive incremental development approach
* Improved: Documentation for local vs. remote testing
* Improved: Version management process for more efficient development
### 2.2.5
* Added: Documentation for the developer preferences memory file in .ai-workflows/
* Improved: AI assistant instructions for maintaining developer preferences
* Updated: Version numbers across all files for consistency
### 2.2.4
* Added: Developer preferences memory file for AI assistants
* Improved: AI assistant documentation with instructions for maintaining developer preferences
* Updated: WordPress.org documentation with correct plugin slug and version numbers
### 2.2.3
* Improved: Moved admin-specific files to admin/lib directory for better organization
* Improved: Updated namespaces to reflect the new file locations
* Added: Comprehensive folder structure documentation
* Fixed: File references in the main plugin file
### 2.2.2-stable
* Changed: Renamed includes files to lowercase for consistency with the rest of the codebase
* Removed: Redundant Git Updater patches and version-fix.js as they're no longer needed
* Improved: Documentation for Git Updater integration and release process
* Fixed: Token-efficient documentation with references to .ai-workflows files
* Added: Comprehensive release process documentation with emphasis on merging to main branch
### 2.2.1
* Changed: Commented out version-fix.js script as it's no longer needed after refactoring
* Fixed: Version consistency across all files
### 2.2.0
* Added: Completely refactored plugin to use OOP best practices
* Added: New class structure with proper namespaces
* Added: Improved code organization and maintainability
* Added: Better separation of concerns with dedicated classes
* Changed: "Choose Update Source" link to just "Update Source"
* Fixed: Close button in the update source modal
* Added: Links to the main page for each update source in the modal
* Changed: Replaced all instances of "WP ALLSTARS" with "WPALLSTARS"
### 2.1.1
* Added: New "Choose Update Source" feature allowing users to select their preferred update source (WordPress.org, GitHub, or Gitea)
* Added: Modal dialog with detailed information about each update source option
@ -385,7 +452,7 @@ The plugin works by:
* Ensured compatibility with WordPress 6.4
### 1.6.12
* Added WP ALLSTARS as a co-author
* Added WPALLSTARS as a co-author
* Updated author information and links
* Added author websites to plugin description
* Fixed issue with multiple author URLs
@ -450,7 +517,7 @@ The plugin works by:
* Fixed Git Updater repository URLs to use full repository paths
* Corrected Update URI configuration for proper update detection
* Improved version management following semantic versioning
* Updated organization name from 'WP All Stars' to 'WP ALLSTARS'
* Updated organization name from 'WP All Stars' to 'WPALLSTARS'
* Updated namespace from 'WPAllStars' to 'WPALLSTARS'
### 1.6.2

View File

@ -56,6 +56,15 @@ jQuery(document).ready(function($) {
// Separate handler for close button to ensure it works
$(document).on('click', '.fpden-close-modal', function(e) {
e.preventDefault();
e.stopPropagation(); // Prevent event bubbling
$('#fpden-update-source-modal').hide();
$('#fpden-modal-overlay').remove();
});
// Direct binding to the close button for extra reliability
$('.fpden-close-modal').on('click', function(e) {
e.preventDefault();
e.stopPropagation(); // Prevent event bubbling
$('#fpden-update-source-modal').hide();
$('#fpden-modal-overlay').remove();
});

95
admin/lib/admin.php Normal file
View File

@ -0,0 +1,95 @@
<?php
/**
* Admin Functionality
*
* @package WPALLSTARS\FixPluginDoesNotExistNotices
*/
namespace WPALLSTARS\FixPluginDoesNotExistNotices\Admin;
/**
* Admin Class
*
* Handles admin-specific functionality.
*/
class Admin {
/**
* Core instance
*
* @var \WPALLSTARS\FixPluginDoesNotExistNotices\Core
*/
private $core;
/**
* Constructor
*
* @param \WPALLSTARS\FixPluginDoesNotExistNotices\Core $core Core instance.
*/
public function __construct($core) {
$this->core = $core;
// Enqueue admin scripts and styles
add_action('admin_enqueue_scripts', array($this, 'enqueue_admin_assets'));
}
/**
* Enqueue scripts and styles needed for the admin area.
*
* @param string $hook_suffix The current admin page hook.
* @return void
*/
public function enqueue_admin_assets($hook_suffix) {
// Only load on the plugins page
if ('plugins.php' !== $hook_suffix) {
return;
}
// Version fix script is no longer needed after refactoring
// Commented out for testing
/*
wp_enqueue_script(
'fpden-version-fix',
FPDEN_PLUGIN_URL . 'admin/js/version-fix.js',
array('jquery', 'thickbox'),
FPDEN_VERSION,
true // Load in footer
);
*/
// Get invalid plugins to decide if other assets are needed
$invalid_plugins = $this->core->get_invalid_plugins();
if (empty($invalid_plugins)) {
return; // No missing plugins, no need for the special notice JS/CSS
}
wp_enqueue_style(
'fpden-admin-styles',
FPDEN_PLUGIN_URL . 'admin/css/admin-styles.css',
array(),
FPDEN_VERSION
);
wp_enqueue_script(
'fpden-admin-scripts',
FPDEN_PLUGIN_URL . 'admin/js/admin-scripts.js',
array('jquery'), // Add dependencies if needed, e.g., jQuery
FPDEN_VERSION,
true // Load in footer
);
// Add translation strings for JavaScript
wp_localize_script(
'fpden-admin-scripts',
'fpdenData',
array(
'i18n' => array(
'clickToScroll' => esc_html__('Click here to scroll to missing plugins', 'wp-fix-plugin-does-not-exist-notices'),
'pluginMissing' => esc_html__('File Missing', 'wp-fix-plugin-does-not-exist-notices'),
'removeNotice' => esc_html__('Remove Notice', 'wp-fix-plugin-does-not-exist-notices'),
),
'version' => FPDEN_VERSION, // Add version for the plugin details fix script
)
);
}
}

167
admin/lib/modal.php Normal file
View File

@ -0,0 +1,167 @@
<?php
/**
* Modal Functionality
*
* @package WPALLSTARS\FixPluginDoesNotExistNotices
*/
namespace WPALLSTARS\FixPluginDoesNotExistNotices\Admin;
/**
* Modal Class
*
* Handles the update source selector modal.
*/
class Modal {
/**
* Constructor
*/
public function __construct() {
// Add filter for plugin action links to add our update source selector
add_filter('plugin_action_links_' . plugin_basename(FPDEN_PLUGIN_DIR . 'wp-fix-plugin-does-not-exist-notices.php'), array($this, 'add_update_source_link'));
// Add AJAX handler for saving update source
add_action('wp_ajax_fpden_save_update_source', array($this, 'save_update_source'));
// Add the update source modal to admin footer
add_action('admin_footer', array($this, 'add_update_source_modal'));
}
/**
* Add the "Update Source" link to plugin action links
*
* @param array $links Array of plugin action links
* @return array Modified array of plugin action links
*/
public function add_update_source_link($links) {
if (!current_user_can('manage_options')) {
return $links;
}
// Get current update source
$current_source = get_option('fpden_update_source', 'auto');
// Add a badge to show the current source
$badge_class = 'fpden-source-badge ' . $current_source;
$badge_text = ucfirst($current_source);
if ($current_source === 'auto') {
$badge_text = 'Auto';
} elseif ($current_source === 'wordpress.org') {
$badge_text = 'WP.org';
}
// Add the link with the badge
$update_source_link = '<a href="#" class="fpden-update-source-toggle">Update Source <span class="' . $badge_class . '">' . $badge_text . '</span></a>';
$links[] = $update_source_link;
return $links;
}
/**
* Add the update source modal to the admin footer
*/
public function add_update_source_modal() {
if (!is_admin() || !current_user_can('manage_options')) {
return;
}
// Only show on plugins page
$screen = get_current_screen();
if (!$screen || $screen->id !== 'plugins') {
return;
}
// Get current source
$current_source = get_option('fpden_update_source', 'auto');
// Enqueue the CSS and JS
wp_enqueue_style(
'fpden-update-source-selector',
FPDEN_PLUGIN_URL . 'admin/css/update-source-selector.css',
array(),
FPDEN_VERSION
);
wp_enqueue_script(
'fpden-update-source-selector',
FPDEN_PLUGIN_URL . 'admin/js/update-source-selector.js',
array('jquery'),
FPDEN_VERSION,
true
);
// Add nonce to the existing fpdenData object or create it if it doesn't exist
$nonce = wp_create_nonce('fpden_update_source');
wp_localize_script(
'fpden-update-source-selector',
'fpdenData',
array(
'updateSourceNonce' => $nonce,
)
);
// Modal HTML
?>
<div id="fpden-update-source-modal">
<a href="#" class="fpden-close-modal" aria-label="Close modal">×</a>
<h2>Choose Update Source</h2>
<p>Select where you want to receive plugin updates from:</p>
<form id="fpden-update-source-form">
<label>
<input type="radio" name="update_source" value="wordpress.org" <?php checked($current_source, 'wordpress.org'); ?>>
<a href="https://wordpress.org/plugins/wp-fix-plugin-does-not-exist-notices/" target="_blank" rel="noopener noreferrer">WordPress.org</a>
<span class="fpden-source-description">Updates from the official WordPress.org plugin repository. Has a version update delay, to allow for the WP.org policy review and approval process. Best for unmonitored auto-updates.</span>
</label>
<label>
<input type="radio" name="update_source" value="github" <?php checked($current_source, 'github'); ?>>
<a href="https://github.com/wpallstars/wp-fix-plugin-does-not-exist-notices" target="_blank" rel="noopener noreferrer">GitHub</a>
<span class="fpden-source-description">Update directly from the GitHub repo main branch for the latest stable release. Git Updater plugin must be installed & active. Best for monitored updates, where the latest features and fixes are required as soon as they are merged into the main branch.</span>
</label>
<label>
<input type="radio" name="update_source" value="gitea" <?php checked($current_source, 'gitea'); ?>>
<a href="https://gitea.wpallstars.com/wpallstars/wp-fix-plugin-does-not-exist-notices" target="_blank" rel="noopener noreferrer">Gitea</a>
<span class="fpden-source-description">Update directly from the Gitea repo main branch for the latest stable release. Git Updater plugin must be installed & active. Best for monitored updates, where the latest features and fixes are required as soon as they are merged into the main branch, and independence from big-tech.</span>
</label>
<div class="fpden-submit-container">
<button type="submit" class="button button-primary">Save</button>
</div>
</form>
</div>
<?php
}
/**
* Handle AJAX request to save update source
*/
public function save_update_source() {
// Check nonce
check_ajax_referer('fpden_update_source', 'nonce');
// Check permissions
if (!current_user_can('manage_options')) {
wp_send_json_error('Permission denied');
}
// Get and sanitize source
$source = isset($_POST['source']) ? sanitize_text_field($_POST['source']) : '';
// Validate source
$valid_sources = ['wordpress.org', 'github', 'gitea'];
if (!in_array($source, $valid_sources)) {
$source = ''; // Empty means use auto-detection
}
// Save option
update_option('fpden_update_source', $source);
// Clear update cache
delete_site_transient('update_plugins');
wp_send_json_success();
}
}

View File

@ -1,50 +0,0 @@
# Plugin Assets for WordPress.org
This directory contains assets for the WordPress.org plugin repository.
## Directory Structure
- `banner/` - Banner images for the plugin page header
- `banner-772x250.jpg` - Standard banner (772x250px)
- `banner-1544x500.jpg` - Retina banner (1544x500px)
- `icon/` - Plugin icon images
- `icon-128x128.jpg` - Standard icon (128x128px)
- `icon-256x256.jpg` - Retina icon (256x256px)
- `screenshots/` - Screenshots shown on the plugin page
- `screenshot-1.jpg` - Error message with explanation notification
## WordPress.org Requirements
### Required Image Dimensions
- **Banner**: 772x250px with 2x retina version at 1544x500px
- **Icon**: 128x128px with 2x retina version at 256x256px
- **Screenshots**: No specific size requirements, but they should be clear and readable
### Image Formats
- All images should be in JPG or PNG format
- Images should be optimized for web (compressed without losing quality)
### Additional Notes
- Screenshots should be numbered sequentially starting with 1
- They should match the descriptions in the `readme.txt` file
- Right-to-Left (RTL) language versions of banners and icons can be provided by appending `-rtl` to the filename
- There is no official support for dark mode versions of assets in the WordPress.org repository
## Example Filenames
```
assets/
├── banner/
│ ├── banner-772x250.jpg
│ └── banner-1544x500.jpg
├── icon/
│ ├── icon-128x128.jpg
│ └── icon-256x256.jpg
└── screenshots/
├── screenshot-1.jpg
```

View File

@ -1,75 +0,0 @@
/**
* Fix Plugin Version Display
*
* This script directly modifies the plugin details popup to show the correct version
* when the popup is opened for our plugin.
*/
(function($) {
'use strict';
// Current plugin version - this should match the version in the main plugin file
const CURRENT_VERSION = '2.0.13';
// Plugin slugs to check for
const OUR_SLUGS = ['wp-fix-plugin-does-not-exist-notices', 'fix-plugin-does-not-exist-notices'];
// Function to fix the version in the plugin details popup
function fixPluginDetailsVersion() {
// Check if we're on the plugins page
if (window.location.href.indexOf('plugins.php') === -1) {
return;
}
// Wait for the thickbox to be initialized
$(document).on('tb_init', function() {
// Set a timeout to allow the thickbox content to load
setTimeout(function() {
// Get the thickbox iframe
const $iframe = $('#TB_iframeContent');
if (!$iframe.length) return;
// Wait for iframe to load
$iframe.on('load', function() {
try {
const iframeDoc = this.contentDocument || this.contentWindow.document;
// Get the plugin title from the iframe
const $title = $(iframeDoc).find('h2.plugin-title');
if (!$title.length) return;
// Check if this is our plugin
const titleText = $title.text();
if (titleText.indexOf('Fix \'Plugin file does not exist\' Notices') !== -1) {
console.log('Found our plugin in the details popup, fixing version...');
// Find the version element
const $version = $(iframeDoc).find('.plugin-version-author-uri');
if ($version.length) {
// Update the version text
const versionText = $version.text();
const newVersionText = versionText.replace(/Version: [0-9.]+|Version: 0\.0\.0/, 'Version: ' + CURRENT_VERSION);
$version.text(newVersionText);
console.log('Updated version to: ' + CURRENT_VERSION);
}
// Also update the version in the header if it exists
const $versionHeader = $(iframeDoc).find('.wrap h2:contains("Version:")');
if ($versionHeader.length) {
$versionHeader.text('Version: ' + CURRENT_VERSION);
console.log('Updated version header to: ' + CURRENT_VERSION);
}
}
} catch (e) {
console.error('Error updating plugin version:', e);
}
});
}, 500);
});
}
// Initialize when the document is ready
$(document).ready(function() {
fixPluginDetailsVersion();
});
})(jQuery);

View File

@ -38,27 +38,16 @@ cp -r includes/* $BUILD_DIR/includes/
mkdir -p $BUILD_DIR/languages
cp -r languages/* $BUILD_DIR/languages/
# Copy assets
mkdir -p $BUILD_DIR/assets/css
cp -r assets/css/* $BUILD_DIR/assets/css/
mkdir -p $BUILD_DIR/assets/js
cp -r assets/js/* $BUILD_DIR/assets/js/
# Copy admin assets
mkdir -p $BUILD_DIR/admin/css
cp -r admin/css/* $BUILD_DIR/admin/css/
mkdir -p $BUILD_DIR/admin/js
cp -r admin/js/* $BUILD_DIR/admin/js/
mkdir -p $BUILD_DIR/admin/lib
cp -r admin/lib/* $BUILD_DIR/admin/lib/
# Copy asset source files (PXD)
mkdir -p $BUILD_DIR/assets/banner
cp -r assets/banner/*.pxd $BUILD_DIR/assets/banner/ 2>/dev/null || :
mkdir -p $BUILD_DIR/assets/icon
cp -r assets/icon/*.pxd $BUILD_DIR/assets/icon/ 2>/dev/null || :
mkdir -p $BUILD_DIR/assets/screenshots
cp -r assets/screenshots/*.pxd $BUILD_DIR/assets/screenshots/ 2>/dev/null || :
# Copy README files from assets directories
cp -r assets/README.md $BUILD_DIR/assets/ 2>/dev/null || :
cp -r assets/banner/README.md $BUILD_DIR/assets/banner/ 2>/dev/null || :
cp -r assets/icon/README.md $BUILD_DIR/assets/icon/ 2>/dev/null || :
cp -r assets/screenshots/README.md $BUILD_DIR/assets/screenshots/ 2>/dev/null || :
cp -r assets/WORDPRESS_ORG_ASSETS.md $BUILD_DIR/assets/ 2>/dev/null || :
cp -r assets/WORDPRESS_ORG_SUBMISSION.md $BUILD_DIR/assets/ 2>/dev/null || :
# Create assets directory structure
mkdir -p $BUILD_DIR/assets
# Copy PNG files from .wordpress-org/assets to the build directory
mkdir -p $BUILD_DIR/assets/banner

619
includes/Core.php Normal file
View File

@ -0,0 +1,619 @@
<?php
/**
* Core Functionality
*
* @package WPALLSTARS\FixPluginDoesNotExistNotices
*/
namespace WPALLSTARS\FixPluginDoesNotExistNotices;
/**
* Core Class
*
* Handles the core functionality of finding and fixing invalid plugin references.
*/
class Core {
/**
* Stores a list of invalid plugins found in the active_plugins option.
*
* @var array|null
*/
private $invalid_plugins = null;
/**
* Constructor
*/
public function __construct() {
// Add our plugin to the plugins list
add_filter('all_plugins', array($this, 'add_missing_plugins_references'));
// Add our action link to the plugins list
add_filter('plugin_action_links', array($this, 'add_remove_reference_action'), 20, 4);
// Handle the remove reference action
add_action('admin_init', array($this, 'handle_remove_reference'));
// Add admin notices for operation feedback
add_action('admin_notices', array($this, 'admin_notices'));
// Filter the plugin API to fix version display in plugin details popup
add_filter('plugins_api', array($this, 'filter_plugin_details'), 10, 3);
// Prevent WordPress from caching our plugin API responses
add_filter('plugins_api_result', array($this, 'prevent_plugins_api_caching'), 10, 3);
// Clear plugin API transients on plugin activation and when viewing plugins page
add_action('admin_init', array($this, 'maybe_clear_plugin_api_cache'));
}
/**
* Get a list of invalid plugins (plugins that are active but don't exist).
*
* @return array An array of plugin file paths that don't exist.
*/
public function get_invalid_plugins() {
// Return cached result if available
if (is_array($this->invalid_plugins)) {
return $this->invalid_plugins;
}
// Initialize empty array
$invalid_plugins = array();
// Handle multisite network admin context
if (is_multisite() && is_network_admin()) {
$active_plugins = get_site_option('active_sitewide_plugins', array());
// Network active plugins are stored as key => timestamp
$active_plugins = array_keys($active_plugins);
} else {
// Single site or non-network admin context
$active_plugins = get_option('active_plugins', array());
}
// Check each active plugin
foreach ($active_plugins as $plugin_file) {
$plugin_path = WP_PLUGIN_DIR . '/' . $plugin_file;
if (!file_exists($plugin_path)) {
$invalid_plugins[] = $plugin_file;
}
}
// Cache the result
$this->invalid_plugins = $invalid_plugins;
return $invalid_plugins;
}
/**
* Check if the current page is the plugins page.
*
* @return bool True if on the plugins page, false otherwise.
*/
public function is_plugins_page() {
global $pagenow;
return is_admin() && 'plugins.php' === $pagenow;
}
/**
* Find and add invalid plugin references to the plugins list.
*
* Filters the list of plugins displayed on the plugins page to include
* entries for active plugins whose files are missing.
*
* @param array $plugins An array of plugin data.
* @return array The potentially modified array of plugin data.
*/
public function add_missing_plugins_references($plugins) {
// Only run on the plugins page
if (!$this->is_plugins_page()) {
return $plugins;
}
// Get active plugins that don't exist
$invalid_plugins = $this->get_invalid_plugins();
// Add each invalid plugin to the plugin list
foreach ($invalid_plugins as $plugin_path) {
if (!isset($plugins[$plugin_path])) {
$plugin_name = basename($plugin_path);
$plugin_slug = dirname($plugin_path);
if ('.' === $plugin_slug) {
$plugin_slug = basename($plugin_path, '.php');
}
// Create a basic plugin data array
$plugins[$plugin_path] = array(
'Name' => $plugin_name . ' <span class="error">(File Missing)</span>',
/* translators: %s: Path to wp-content/plugins */
'Description' => sprintf(
__('This plugin is still marked as "Active" in your database — but its folder and files can\'t be found in %s. Click "Remove Notice" to permanently remove it from your active plugins list and eliminate the error notice.', 'wp-fix-plugin-does-not-exist-notices'),
'<code>/wp-content/plugins/</code>'
),
'Version' => FPDEN_VERSION, // Use our plugin version instead of 'N/A'
'Author' => 'Marcus Quinn & WPALLSTARS',
'PluginURI' => 'https://www.wpallstars.com',
'AuthorURI' => 'https://www.wpallstars.com',
'Title' => $plugin_name . ' (' . __('Missing', 'wp-fix-plugin-does-not-exist-notices') . ')',
'AuthorName' => 'Marcus Quinn & WPALLSTARS',
);
// Add the data needed for the "View details" link
$plugins[$plugin_path]['slug'] = $plugin_slug;
$plugins[$plugin_path]['plugin'] = $plugin_path;
$plugins[$plugin_path]['type'] = 'plugin';
// Add Git Updater fields
$plugins[$plugin_path]['GitHub Plugin URI'] = 'wpallstars/wp-fix-plugin-does-not-exist-notices';
$plugins[$plugin_path]['GitHub Branch'] = 'main';
$plugins[$plugin_path]['TextDomain'] = 'wp-fix-plugin-does-not-exist-notices';
}
}
return $plugins;
}
/**
* Add the Remove Notice action link to invalid plugins.
*
* Filters the action links displayed for each plugin on the plugins page.
* Adds a "Remove Notice" link for plugins identified as missing.
*
* @param array $actions An array of plugin action links.
* @param string $plugin_file Path to the plugin file relative to the plugins directory.
* @param array $plugin_data An array of plugin data.
* @param string $context The plugin context (e.g., 'all', 'active', 'inactive').
* @return array The potentially modified array of plugin action links.
*/
public function add_remove_reference_action($actions, $plugin_file, $plugin_data, $context) {
// Only run on the plugins page
if (!$this->is_plugins_page()) {
return $actions;
}
// Get our list of invalid plugins
$invalid_plugins = $this->get_invalid_plugins();
// Check if this plugin file is in our list of invalid plugins
if (in_array($plugin_file, $invalid_plugins, true)) {
// Clear existing actions like "Activate", "Deactivate", "Edit"
$actions = array();
// Add our custom action
$nonce = wp_create_nonce('remove_plugin_reference_' . $plugin_file);
$remove_url = admin_url('plugins.php?action=remove_reference&plugin=' . urlencode($plugin_file) . '&_wpnonce=' . $nonce);
/* translators: %s: Plugin file path */
$aria_label = sprintf(__('Remove reference to missing plugin %s', 'wp-fix-plugin-does-not-exist-notices'), esc_attr($plugin_file));
$actions['remove_reference'] = '<a href="' . esc_url($remove_url) . '" class="delete" aria-label="' . $aria_label . '">' . esc_html__('Remove Notice', 'wp-fix-plugin-does-not-exist-notices') . '</a>';
}
return $actions;
}
/**
* Handle the remove reference action triggered by the link.
*
* Checks for the correct action, verifies nonce and permissions,
* calls the removal function, and redirects back to the plugins page.
*
* @return void
*/
public function handle_remove_reference() {
// Check if our specific action is being performed
if (!isset($_GET['action']) || 'remove_reference' !== $_GET['action'] || !isset($_GET['plugin'])) {
return;
}
// Verify user permissions
if (!current_user_can('activate_plugins')) {
wp_die(esc_html__('You do not have sufficient permissions to perform this action.', 'wp-fix-plugin-does-not-exist-notices'));
}
// Sanitize and get the plugin file path
$plugin_file = isset($_GET['plugin']) ? sanitize_text_field(wp_unslash($_GET['plugin'])) : '';
if (empty($plugin_file)) {
wp_die(esc_html__('Invalid plugin specified.', 'wp-fix-plugin-does-not-exist-notices'));
}
// Verify nonce for security
check_admin_referer('remove_plugin_reference_' . $plugin_file);
// Attempt to remove the plugin reference
$success = $this->remove_plugin_reference($plugin_file);
// Prepare redirect URL with feedback query args
$redirect_url = admin_url('plugins.php');
$redirect_url = add_query_arg($success ? 'reference_removed' : 'reference_removal_failed', '1', $redirect_url);
// Redirect and exit
wp_safe_redirect($redirect_url);
exit;
}
/**
* Remove a plugin reference from the active plugins list in the database.
*
* Handles both single site and multisite network activated plugins.
*
* @param string $plugin_file The plugin file path to remove.
* @return bool True on success, false on failure or if the plugin wasn't found.
*/
public function remove_plugin_reference($plugin_file) {
$success = false;
// Ensure plugin file path is provided
if (empty($plugin_file)) {
return false;
}
// Handle multisite network admin context
if (is_multisite() && is_network_admin()) {
$active_plugins = get_site_option('active_sitewide_plugins', array());
// Network active plugins are stored as key => timestamp
if (isset($active_plugins[$plugin_file])) {
unset($active_plugins[$plugin_file]);
$success = update_site_option('active_sitewide_plugins', $active_plugins);
}
} else { // Handle single site or non-network admin context
$active_plugins = get_option('active_plugins', array());
// Single site active plugins are stored as an indexed array
$key = array_search($plugin_file, $active_plugins, true); // Use strict comparison
if (false !== $key) {
unset($active_plugins[$key]);
// Re-index the array numerically
$active_plugins = array_values($active_plugins);
$success = update_option('active_plugins', $active_plugins);
}
}
return $success;
}
/**
* Display admin notices on the plugins page.
*
* Shows feedback messages after attempting to remove a reference.
* The main informational notice is handled by JavaScript to position it
* directly below the WordPress error message.
*
* @return void
*/
public function admin_notices() {
// Only run on the plugins page
if (!$this->is_plugins_page()) {
return;
}
// Check for feedback messages from the remove action
if (isset($_GET['reference_removed']) && '1' === $_GET['reference_removed']) {
?>
<div class="notice notice-success is-dismissible">
<p><?php esc_html_e('Plugin reference removed successfully.', 'wp-fix-plugin-does-not-exist-notices'); ?></p>
</div>
<?php
}
if (isset($_GET['reference_removal_failed']) && '1' === $_GET['reference_removal_failed']) {
?>
<div class="notice notice-error is-dismissible">
<p><?php esc_html_e('Failed to remove plugin reference. The plugin may already have been removed, or there was a database issue.', 'wp-fix-plugin-does-not-exist-notices'); ?></p>
</div>
<?php
}
}
/**
* Filter plugin details API response to provide custom data for our plugin.
*
* @param object|WP_Error $result The result object or WP_Error.
* @param string $action The type of information being requested.
* @param object $args Plugin API arguments.
* @return object|WP_Error The result object or WP_Error.
*/
public function filter_plugin_details($result, $action, $args) {
// Only modify plugin_information requests
if ('plugin_information' !== $action) {
return $result;
}
// Check if we have a slug to work with
if (empty($args->slug)) {
return $result;
}
// Get our list of invalid plugins
$invalid_plugins = $this->get_invalid_plugins();
// Check if this is our plugin or a missing plugin
$our_plugin = in_array($args->slug, array('wp-fix-plugin-does-not-exist-notices', 'fix-plugin-does-not-exist-notices'), true);
$is_missing_plugin = $this->is_missing_plugin($args->slug, $invalid_plugins);
// Only modify the result if this is our plugin or a missing plugin
if ($our_plugin || $is_missing_plugin) {
// Create a new result object
$new_result = new \stdClass();
// Set all the properties we need
$new_result->name = $our_plugin ? 'Fix \'Plugin file does not exist\' Notices' : (isset($result->name) ? $result->name : $args->slug);
$new_result->slug = $args->slug;
$new_result->version = FPDEN_VERSION;
$new_result->author = '<a href="https://www.wpallstars.com">Marcus Quinn & WPALLSTARS</a>';
$new_result->author_profile = 'https://www.wpallstars.com';
$new_result->requires = '5.0';
$new_result->tested = '6.7.2'; // Updated to match readme.txt
$new_result->requires_php = '7.0';
$new_result->last_updated = date('Y-m-d H:i:s');
// Add a cache buster timestamp
$new_result->cache_buster = time();
// Get full readme content for our plugin
$readme_file = FPDEN_PLUGIN_DIR . 'readme.txt';
$readme_content = '';
$description = '';
$changelog = '';
$faq = '';
$installation = '';
$screenshots = '';
if (file_exists($readme_file) && $our_plugin) {
$readme_content = file_get_contents($readme_file);
// Extract description
if (preg_match('/== Description ==(.+?)(?:==|$)/s', $readme_content, $matches)) {
$description = trim($matches[1]);
}
// Extract changelog
if (preg_match('/== Changelog ==(.+?)(?:==|$)/s', $readme_content, $matches)) {
$changelog = trim($matches[1]);
}
// Extract FAQ
if (preg_match('/== Frequently Asked Questions ==(.+?)(?:==|$)/s', $readme_content, $matches)) {
$faq = trim($matches[1]);
}
// Extract installation
if (preg_match('/== Installation ==(.+?)(?:==|$)/s', $readme_content, $matches)) {
$installation = trim($matches[1]);
}
// Extract screenshots
if (preg_match('/== Screenshots ==(.+?)(?:==|$)/s', $readme_content, $matches)) {
$screenshots = trim($matches[1]);
}
} else {
// Fallback content if readme.txt doesn't exist or for missing plugins
$changelog = '<h2>' . FPDEN_VERSION . '</h2><ul><li>Fixed: Plugin details popup version display issue with Git Updater integration</li><li>Added: JavaScript-based solution to ensure correct version display in plugin details</li><li>Improved: Version consistency across all plugin views</li><li>Enhanced: Cache busting for plugin information API</li></ul>';
}
// Set description based on whether this is our plugin or a missing plugin
if ($our_plugin) {
$description = !empty($description) ? wpautop($description) : 'Adds missing plugins to your plugins list with a "Remove Notice" action link, allowing you to safely clean up invalid plugin references.';
} else {
$description = sprintf(
__('This plugin is still marked as "Active" in your database — but its folder and files can\'t be found in %s. Use the "Remove Notice" link on the plugins page to permanently remove it from your active plugins list and eliminate the error notice.', 'wp-fix-plugin-does-not-exist-notices'),
'<code>/wp-content/plugins/</code>'
);
}
// Prepare sections
$new_result->sections = array(
'description' => $description,
'changelog' => !empty($changelog) ? wpautop($changelog) : $changelog,
'faq' => !empty($faq) ? wpautop($faq) : '<h3>Is it safe to remove plugin references?</h3><p>Yes, this plugin only removes entries from the WordPress active_plugins option, which is safe to modify when a plugin no longer exists.</p>',
);
// Add installation section if available
if (!empty($installation)) {
$new_result->sections['installation'] = wpautop($installation);
}
// Add screenshots section if available
if (!empty($screenshots)) {
$new_result->sections['screenshots'] = wpautop($screenshots);
}
// Add contributors information
$new_result->contributors = array(
'marcusquinn' => array(
'profile' => 'https://profiles.wordpress.org/marcusquinn/',
'avatar' => 'https://secure.gravatar.com/avatar/',
'display_name' => 'Marcus Quinn'
),
'wpallstars' => array(
'profile' => 'https://profiles.wordpress.org/wpallstars/',
'avatar' => 'https://secure.gravatar.com/avatar/',
'display_name' => 'WPALLSTARS'
)
);
// Add a random number and timestamp to force cache refresh
$new_result->download_link = 'https://www.wpallstars.com/plugins/wp-fix-plugin-does-not-exist-notices.zip?v=' . FPDEN_VERSION . '&cb=' . mt_rand(1000000, 9999999) . '&t=' . time();
// Add active installations count
$new_result->active_installs = 1000;
// Add rating information
$new_result->rating = 100;
$new_result->num_ratings = 5;
$new_result->ratings = array(
5 => 5,
4 => 0,
3 => 0,
2 => 0,
1 => 0
);
// Add homepage and download link
$new_result->homepage = 'https://www.wpallstars.com';
// Set no caching
$new_result->cache_time = 0;
// Return our completely new result object
return $new_result;
}
return $result;
}
/**
* Check if a slug matches one of our missing plugins.
*
* @param string $slug The plugin slug to check.
* @param array $invalid_plugins List of invalid plugin paths.
* @return bool True if the slug matches a missing plugin.
*/
private function is_missing_plugin($slug, $invalid_plugins) {
foreach ($invalid_plugins as $plugin_file) {
// Extract the plugin slug from the plugin file path
$plugin_slug = dirname($plugin_file);
if ('.' === $plugin_slug) {
$plugin_slug = basename($plugin_file, '.php');
}
if ($slug === $plugin_slug) {
return true;
}
}
return false;
}
/**
* Prevent WordPress from caching our plugin API responses.
*
* @param object|WP_Error $result The result object or WP_Error.
* @param string $action The type of information being requested.
* @param object $args Plugin API arguments.
* @return object|WP_Error The result object or WP_Error.
*/
public function prevent_plugins_api_caching($result, $action, $args) {
// Only modify plugin_information requests
if ('plugin_information' !== $action) {
return $result;
}
// Check if we have a slug to work with
if (empty($args->slug)) {
return $result;
}
// Get our list of invalid plugins
$invalid_plugins = $this->get_invalid_plugins();
// Check if the requested plugin is one of our missing plugins
foreach ($invalid_plugins as $plugin_file) {
// Extract the plugin slug from the plugin file path
$plugin_slug = dirname($plugin_file);
if ('.' === $plugin_slug) {
$plugin_slug = basename($plugin_file, '.php');
}
// If this is one of our missing plugins, prevent caching
if ($args->slug === $plugin_slug) {
// Add a filter to prevent caching of this response
add_filter('plugins_api_result_' . $args->slug, '__return_false');
// Add a timestamp to force cache busting
if (is_object($result)) {
$result->last_updated = current_time('mysql');
$result->cache_time = 0;
}
}
}
return $result;
}
/**
* Clear plugin API cache when viewing the plugins page.
*
* @return void
*/
public function maybe_clear_plugin_api_cache() {
// Only run on the plugins page
if (!$this->is_plugins_page()) {
return;
}
// Get our list of invalid plugins
$invalid_plugins = $this->get_invalid_plugins();
// Clear transients for each invalid plugin
foreach ($invalid_plugins as $plugin_file) {
// Extract the plugin slug from the plugin file path
$plugin_slug = dirname($plugin_file);
if ('.' === $plugin_slug) {
$plugin_slug = basename($plugin_file, '.php');
}
// Delete all possible transients for this plugin
delete_transient('plugins_api_' . $plugin_slug);
delete_site_transient('plugins_api_' . $plugin_slug);
delete_transient('plugin_information_' . $plugin_slug);
delete_site_transient('plugin_information_' . $plugin_slug);
// Clear any other transients that might be caching plugin info
$this->clear_all_plugin_transients();
}
// Also clear our own plugin's cache
$this->clear_own_plugin_cache();
}
/**
* Clear all plugin-related transients that might be caching information.
*
* @return void
*/
private function clear_all_plugin_transients() {
// Clear update cache
delete_site_transient('update_plugins');
delete_site_transient('update_themes');
delete_site_transient('update_core');
// Clear plugins API cache
delete_site_transient('plugin_information');
// Clear plugin update counts
delete_transient('plugin_updates_count');
delete_site_transient('plugin_updates_count');
// Clear plugin slugs cache
delete_transient('plugin_slugs');
delete_site_transient('plugin_slugs');
}
/**
* Clear cache specifically for our own plugin.
*
* @return void
*/
private function clear_own_plugin_cache() {
// Clear our own plugin's cache (both old and new slugs)
$our_slugs = array('wp-fix-plugin-does-not-exist-notices', 'fix-plugin-does-not-exist-notices');
foreach ($our_slugs as $slug) {
delete_transient('plugins_api_' . $slug);
delete_site_transient('plugins_api_' . $slug);
delete_transient('plugin_information_' . $slug);
delete_site_transient('plugin_information_' . $slug);
}
// Clear plugin update transients
delete_site_transient('update_plugins');
delete_site_transient('plugin_information');
// Force refresh of plugin update information if function exists
if (function_exists('wp_clean_plugins_cache')) {
wp_clean_plugins_cache(true);
}
// Clear object cache if function exists
if (function_exists('wp_cache_flush')) {
wp_cache_flush();
}
}
}

158
includes/Plugin.php Normal file
View File

@ -0,0 +1,158 @@
<?php
/**
* Main Plugin Class
*
* @package WPALLSTARS\FixPluginDoesNotExistNotices
*/
namespace WPALLSTARS\FixPluginDoesNotExistNotices;
/**
* Main Plugin Class
*
* Initializes all components of the plugin.
*/
class Plugin {
/**
* Plugin version
*
* @var string
*/
private $version;
/**
* Plugin file path
*
* @var string
*/
private $plugin_file;
/**
* Plugin directory path
*
* @var string
*/
private $plugin_dir;
/**
* Plugin directory URL
*
* @var string
*/
private $plugin_url;
/**
* Core functionality instance
*
* @var Core
*/
private $core;
/**
* Admin functionality instance
*
* @var Admin\Admin
*/
private $admin;
/**
* Updater instance
*
* @var Updater
*/
private $updater;
/**
* Constructor
*
* @param string $plugin_file Main plugin file path.
* @param string $version Plugin version.
*/
public function __construct($plugin_file, $version) {
$this->plugin_file = $plugin_file;
$this->version = $version;
$this->plugin_dir = plugin_dir_path($plugin_file);
$this->plugin_url = plugin_dir_url($plugin_file);
$this->define_constants();
$this->load_dependencies();
$this->init_components();
}
/**
* Define plugin constants
*
* @return void
*/
private function define_constants() {
if (!defined('FPDEN_VERSION')) {
define('FPDEN_VERSION', $this->version);
}
if (!defined('FPDEN_PLUGIN_DIR')) {
define('FPDEN_PLUGIN_DIR', $this->plugin_dir);
}
if (!defined('FPDEN_PLUGIN_URL')) {
define('FPDEN_PLUGIN_URL', $this->plugin_url);
}
}
/**
* Load dependencies
*
* @return void
*/
private function load_dependencies() {
// Load composer autoloader if it exists
$autoloader = $this->plugin_dir . 'vendor/autoload.php';
if (file_exists($autoloader)) {
require_once $autoloader;
}
// Load required files
require_once $this->plugin_dir . 'includes/core.php';
require_once $this->plugin_dir . 'admin/lib/admin.php';
require_once $this->plugin_dir . 'admin/lib/modal.php';
}
/**
* Initialize plugin components
*
* @return void
*/
private function init_components() {
// Initialize core functionality
$this->core = new Core();
// Initialize admin functionality
$this->admin = new Admin\Admin($this->core);
// Initialize Git Updater fixes
$this->init_git_updater_fixes();
// Initialize the updater if the class exists
if (class_exists('\WPALLSTARS\FixPluginDoesNotExistNotices\Updater')) {
$this->updater = new Updater($this->plugin_file);
}
// Initialize the modal for update source selection
new Admin\Modal();
}
/**
* Initialize Git Updater fixes
*
* This function previously added filters to fix Git Updater's handling of 'main' vs 'master' branches.
* These fixes are no longer needed with proper plugin headers.
* See: https://git-updater.com/knowledge-base/required-headers/
*
* @return void
*/
private function init_git_updater_fixes() {
// No fixes needed - we're using the proper plugin headers
// Git Updater reads version information from the readme.txt file in the main branch
}
// Git Updater override methods have been removed as they're no longer needed
// We now use the proper plugin headers for Git Updater integration
}

View File

@ -2,14 +2,14 @@
# This file is distributed under the GPL-2.0+.
msgid ""
msgstr ""
"Project-Id-Version: Fix 'Plugin file does not exist' Notices 2.1.1\n"
"Project-Id-Version: Fix 'Plugin file does not exist' Notices 2.3.0\n"
"Report-Msgid-Bugs-To: https://wordpress.org/support/plugin/wp-fix-plugin-does-not-exist-notices\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"POT-Creation-Date: 2025-04-13T00:00:00+00:00\n"
"POT-Creation-Date: 2025-04-15T00:00:00+00:00\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"X-Generator: WP-CLI 2.9.0\n"
"X-Domain: wp-fix-plugin-does-not-exist-notices\n"

View File

@ -5,11 +5,11 @@ Tags: plugins, missing plugins, cleanup, error fix, admin tools, plugin file doe
Requires at least: 5.0
Tested up to: 6.7.2
Requires PHP: 7.0
Stable tag: 2.1.1
Stable tag: 2.3.0
License: GPL-2.0+
License URI: https://www.gnu.org/licenses/gpl-2.0.html
Easily remove references to deleted plugins that cause "Plugin file does not exist" errors in your WordPress admin. By Marcus Quinn (marcusquinn.com) & WP ALLSTARS (wpallstars.com).
Easily remove references to deleted plugins that cause "Plugin file does not exist" errors in your WordPress admin. By Marcus Quinn (marcusquinn.com) & WPALLSTARS (wpallstars.com).
== Description ==
@ -98,7 +98,7 @@ If you've installed this plugin from GitHub or Gitea, you'll need Git Updater to
This plugin allows you to choose where you want to receive updates from:
1. In the Plugins list, find "Fix 'Plugin file does not exist' Notices"
2. Click the "Choose Update Source" link next to the plugin
2. Click the "Update Source" link next to the plugin
3. Select your preferred update source:
* **WordPress.org**: Updates from the official WordPress.org repository (has a version update delay due to the WP.org policy review and approval process, best for unmonitored auto-updates)
* **GitHub**: Updates directly from the GitHub repo main branch for the latest stable release (requires Git Updater plugin, best for monitored updates where the latest features and fixes are needed immediately)
@ -179,6 +179,50 @@ Manually editing the WordPress database is risky and requires technical knowledg
== Changelog ==
= 2.3.0 =
* Added: Improved time-efficient development workflow documentation
* Added: New git workflow guidelines for better branch management
* Added: Comprehensive incremental development approach
* Improved: Documentation for local vs. remote testing
* Improved: Version management process for more efficient development
= 2.2.5 =
* Added: Documentation for the developer preferences memory file in .ai-workflows/
* Improved: AI assistant instructions for maintaining developer preferences
* Updated: Version numbers across all files for consistency
= 2.2.4 =
* Added: Developer preferences memory file for AI assistants
* Improved: AI assistant documentation with instructions for maintaining developer preferences
* Updated: WordPress.org documentation with correct plugin slug and version numbers
= 2.2.3 =
* Improved: Moved admin-specific files to admin/lib directory for better organization
* Improved: Updated namespaces to reflect the new file locations
* Added: Comprehensive folder structure documentation
* Fixed: File references in the main plugin file
= 2.2.2-stable =
* Changed: Renamed includes files to lowercase for consistency with the rest of the codebase
* Removed: Redundant Git Updater patches and version-fix.js as they're no longer needed
* Improved: Documentation for Git Updater integration and release process
* Fixed: Token-efficient documentation with references to .ai-workflows files
* Added: Comprehensive release process documentation with emphasis on merging to main branch
= 2.2.1 =
* Changed: Commented out version-fix.js script as it's no longer needed after refactoring
* Fixed: Version consistency across all files
= 2.2.0 =
* Added: Completely refactored plugin to use OOP best practices
* Added: New class structure with proper namespaces
* Added: Improved code organization and maintainability
* Added: Better separation of concerns with dedicated classes
* Changed: "Choose Update Source" link to just "Update Source"
* Fixed: Close button in the update source modal
* Added: Links to the main page for each update source in the modal
* Changed: Replaced all instances of "WP ALLSTARS" with "WPALLSTARS"
= 2.1.1 =
* Added: New "Choose Update Source" feature allowing users to select their preferred update source (WordPress.org, GitHub, or Gitea)
* Added: Modal dialog with detailed information about each update source option

File diff suppressed because it is too large Load Diff