Skip to content

Commit c69e94f

Browse files
PDowneyPDowney
authored
Updates
1 parent 5f3b469 commit c69e94f

13 files changed

+553
-41
lines changed

‎.github/CODE_OF_CONDUCT.md

Lines changed: 57 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,57 @@
1+
# Contributor Covenant Code of Conduct
2+
3+
## Our Pledge
4+
5+
We as members, contributors, and leaders pledge to make participation in our
6+
community a harassment-free experience for everyone, regardless of age, body
7+
size, visible or invisible disability, ethnicity, sex characteristics, gender
8+
identity and expression, level of experience, education, socio-economic status,
9+
nationality, personal appearance, race, religion, or sexual identity and orientation.
10+
11+
We pledge to act and interact in ways that contribute to an open, welcoming,
12+
diverse, inclusive, and healthy community.
13+
14+
## Our Standards
15+
16+
Examples of behavior that contributes to a positive environment for our community include:
17+
18+
* Demonstrating empathy and kindness toward other people
19+
* Being respectful of differing opinions, viewpoints, and experiences
20+
* Giving and gracefully accepting constructive feedback
21+
* Accepting responsibility and apologizing to those affected by our mistakes
22+
* Focusing on what is best for the overall community
23+
24+
Examples of unacceptable behavior include:
25+
26+
* The use of sexualized language or imagery, and sexual attention or advances
27+
* Trolling, insulting or derogatory comments, and personal or political attacks
28+
* Public or private harassment
29+
* Publishing others' private information without explicit permission
30+
* Other conduct which could reasonably be considered inappropriate in a professional setting
31+
32+
## Enforcement Responsibilities
33+
34+
Project maintainers are responsible for clarifying and enforcing our standards of
35+
acceptable behavior and will take appropriate and fair corrective action in
36+
response to any behavior that they deem inappropriate, threatening, offensive,
37+
or harmful.
38+
39+
## Scope
40+
41+
This Code of Conduct applies within all community spaces, and also applies when
42+
an individual is officially representing the community in public spaces.
43+
44+
## Enforcement
45+
46+
Instances of abusive, harassing, or otherwise unacceptable behavior may be
47+
reported to the project maintainers responsible for enforcement at
48+
[email protected].
49+
50+
Project maintainers will review and investigate all complaints, and will
51+
respond in a way that they deem appropriate to the circumstances.
52+
53+
## Attribution
54+
55+
This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org),
56+
version 2.1, available at
57+
[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html](https://www.contributor-covenant.org/version/2/1/code_of_conduct.html).

‎.github/FUNDING.yml

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
# These are supported funding model platforms
2+
3+
#patreon: # Replace with a single Patreon username
4+
5+
github: enginescript
6+
ko_fi: enginescript
7+
buy_me_a_coffee: enginescript
8+
liberapay: enginescript
9+
thanks_dev: gh/pdowney

‎.github/copilot-instructions.md

Lines changed: 155 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,155 @@
1+
---
2+
applyTo: '**'
3+
---
4+
Coding standards, domain knowledge, and preferences that AI should follow.
5+
6+
# Work Environment
7+
8+
This project is coded entirely in a remote development environment using GitHub Codespaces. The AI will never ask me to run Terminal commands or use a local development environment. All code changes, tests, and debugging will be done within remote repositories on GitHub.
9+
10+
Change summaries should be concise and clear, focusing on the specific changes made. The AI should not ask for confirmation before making changes, as all code modifications will be done directly in the remote environment.
11+
12+
# Responses
13+
14+
When delivering responses, the AI should provide clear, concise, and actionable information. Responses should be formatted in a way that is easy to read and understand, with a focus on clarity and precision. The AI should avoid unnecessary verbosity or complexity in its explanations.
15+
16+
Responses, change summaries, and code comments should be written in English. The AI should not use any other languages or dialects, including regional variations of English. All communication should be clear and professional, adhering to standard English grammar and spelling conventions.
17+
18+
Responses should be delivered only in the chat interface. Formatting and styling should be utilized to enhance readability.
19+
20+
Change summaries should never be created in the form of new .md files.
21+
22+
# Code Analysis and Reading Standards
23+
24+
You must read files completely and thoroughly, with a minimum of 1000 lines per read operation when analyzing code. Never truncate files or stop reading at arbitrary limits like 50 or 100 lines - this lazy approach provides incomplete context and leads to poor suggestions. When you encounter any file, read it from the very first line to the absolute last line, processing all functions, classes, variables, imports, exports, and code structures. Your analysis must be based on the complete file content, not partial snapshots. Always read at least 1000 lines minimum per read operation, and if the file is larger, continue reading until you've processed the entire file. Do not use phrases like "showing first X lines" or "truncated for brevity" or "rest of file omitted" - these indicate lazy, incomplete analysis. Instead, demonstrate that you've read the complete file by referencing specific sections throughout the entire codebase, understanding the full context of how functions interact, how variables are used across the entire file, and how the complete code structure works together. Your suggestions and recommendations must reflect knowledge of the entire file, not just the beginning portions. Take the time to read everything properly because thoroughness and accuracy based on complete file knowledge is infinitely more valuable than quick, incomplete reviews that miss critical context and lead to incorrect suggestions.
25+
26+
# Coding Standards and Preferences
27+
28+
## WordPress Focused Design
29+
30+
- This project is focused on WordPress development.
31+
- Use WordPress coding standards and best practices.
32+
- Leverage WordPress APIs and functions where applicable.
33+
- Ensure compatibility with modern WordPress versions and PHP standards. WordPress 6.5+ and PHP 7.4+ are the baseline.
34+
- Use WordPress hooks (actions and filters) to extend functionality.
35+
- Follow WordPress theme and plugin development guidelines.
36+
- Use WordPress REST API for custom endpoints and data retrieval.
37+
- Ensure all code is compatible with the WordPress ecosystem, including themes and plugins.
38+
- As this is a WordPress-focused project, avoid using frameworks or libraries that are not compatible with WordPress.
39+
- Do not use frameworks or libraries that are not commonly used in the WordPress ecosystem.
40+
- Avoid using non-standard or experimental features that are not widely adopted in the WordPress community.
41+
- For any project that utilizes WooCommerce, ensure minimum version compatibility with WooCommerce 5.0+.
42+
43+
## WordPress Coding Standards
44+
45+
- Use WordPress coding standards for PHP, JavaScript, and CSS:
46+
- [PHP Coding Standards](https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/)
47+
- [JavaScript Coding Standards](https://developer.wordpress.org/coding-standards/wordpress-coding-standards/javascript/)
48+
- [CSS Coding Standards](https://developer.wordpress.org/coding-standards/wordpress-coding-standards/css/)
49+
- Use WordPress coding standards for HTML and template files:
50+
- [HTML Coding Standards](https://developer.wordpress.org/coding-standards/wordpress-coding-standards/html/)
51+
- Use WordPress coding standards for accessibility:
52+
- [Accessibility Coding Standards](https://developer.wordpress.org/coding-standards/wordpress-coding-standards/accessibility/)
53+
- Use WordPress Gutenberg Project Coding Guidelines:
54+
- [Gutenberg Project Coding Guidelines](https://developer.wordpress.org/block-editor/contributors/code/coding-guidelines/)
55+
- Use WordPress JavaScript Documentation Standards:
56+
- [JavaScript Documentation Standards](https://developer.wordpress.org/coding-standards/inline-documentation-standards/javascript/)
57+
- Use WordPress PHP Documentation Standards:
58+
- [PHP Documentation Standards](https://developer.wordpress.org/coding-standards/inline-documentation-standards/php/)
59+
60+
## Supported Versions
61+
62+
- This project supports modern software versions:
63+
- WordPress 6.5+ (minimum)
64+
- PHP 7.4+ (minimum)
65+
- WooCommerce 5.0+ (if applicable)
66+
- Do not use features or functions that are not available in these versions.
67+
68+
## Version Control and Documentation
69+
70+
- Release versions, software tested versions, and minimum software supported versions for this project are listed in numerous places, when updating the release version for this project, ensure that all of these locations are updated accordingly.
71+
- Version Locations:
72+
- README.md
73+
- changelog.txt
74+
- changelog.md
75+
- plugin header (in the main plugin file)
76+
- plugin section: "// Define plugin constants"
77+
- plugin *.pot files (e.g., languages/plugin-name.pot)
78+
- package.json (if applicable)
79+
- composer.json (if applicable)
80+
- documentation files (e.g., docs/README.md)
81+
- Use semantic versioning (MAJOR.MINOR.PATCH) for all releases.
82+
- Always add new information to the changelog when we make changes to the codebase, even if a new version is not released.
83+
- When adding new information to the changelogs, changes will first be added to an "Unreleased" section at the top of the changelog file, and then later moved to a new version section when a new version is released. Be sure to follow this pattern and do not skip any of the changelog files.
84+
- Do not automatically update the version number in the plugin header or other files. Instead, provide a clear and concise change summary that includes the version number and a brief description of the changes made.
85+
- When making changes to the codebase, always update the relevant documentation files, including README.md, readme.txt, changelog.txt, and changelog.md, even when a new version is not released.
86+
- Please do not skip these locations, as all of the changelog files must be in sync with each other, and the version numbers must be consistent across all files.
87+
- I will instruct you when to update the version number, and you should not do this automatically. Always ask for confirmation before updating the version number.
88+
- When the version number is updated, ensure that the new version number is reflected in all relevant files, including the plugin header, changelog files, and documentation files.
89+
- WHen the version number is updated, make special note to update the "Unreleased" section in the changelog files to reflect the new version number and a brief description of the changes made. This ensures that all changes are documented and easily accessible for future reference.
90+
91+
# General Coding Standards
92+
93+
- The above standards are prioritized over general coding standards.
94+
- The standards below are general coding standards that apply to all code, including WordPress code. Do not apply them if they conflict with WordPress standards.
95+
96+
## Accessibility & UX
97+
98+
- Follow accessibility best practices for UI components
99+
- Ensure forms are keyboard-navigable and screen reader friendly
100+
- Validate user-facing labels, tooltips, and messages for clarity
101+
102+
## Performance & Optimization
103+
104+
- Optimize for performance and scalability where applicable
105+
- Avoid premature optimization—focus on correctness first
106+
- Detect and flag performance issues (e.g., unnecessary re-renders, N+1 queries)
107+
- Use lazy loading, memoization, or caching where needed
108+
109+
## Type Safety & Standards
110+
111+
- Use strict typing wherever possible (TypeScript, C#, etc.)
112+
- Avoid using `any` or untyped variables
113+
- Use inferred and narrow types when possible
114+
- Define shared types centrally (e.g., `types/` or `shared/` folders)
115+
116+
## Security & Error Handling
117+
118+
- Sanitize all input and output, especially in forms, APIs, and database interactions
119+
- Escape, validate, and normalize all user-supplied data
120+
- Automatically handle edge cases and error conditions
121+
- Fail securely and log actionable errors
122+
- Avoid leaking sensitive information in error messages or logs
123+
- Use secure coding practices to prevent common vulnerabilities (e.g., XSS, CSRF, SQL injection)
124+
- Use prepared statements for database queries
125+
- Use secure authentication and authorization mechanisms
126+
- When using third-party libraries or APIs, ensure they are well-maintained and secure
127+
- Regularly update dependencies to their latest stable versions
128+
- Use HTTPS for all API requests and data transmission
129+
- When handling sensitive data, ensure it is encrypted both in transit and at rest
130+
- If you suspect a security vulnerability, immediately notify the project maintainers and provide details for investigation
131+
- If you encounter a security vulnerability in the codebase, do not disclose it publicly. Instead, report it privately to the project maintainers or through a responsible disclosure process.
132+
- If you are unsure about the security implications of a specific code change, ask for clarification or guidance before proceeding.
133+
- Always follow the principle of least privilege when implementing security features, ensuring that users and processes have only the permissions they need to perform their tasks.
134+
- If you encounter a security vulnerability in a third-party library or dependency, check if there is an updated version that addresses the issue. If not, consider alternatives or report the vulnerability to the library maintainers.
135+
- If there is a possible security vulnerability in the codebase, you should always ask for confirmation before proceeding with any changes. This ensures that the project maintainers are aware of the potential risk and can provide guidance on how to address it safely.
136+
- If I ask you to make changes that could potentially introduce security vulnerabilities, you should always ask for confirmation before proceeding. This ensures that the project maintainers are aware of the potential risk and can provide guidance on how to address it safely.
137+
138+
## Code Quality & Architecture
139+
140+
- Organize code using **feature-sliced architecture** when applicable
141+
- Group code by **feature**, not by type (e.g., keep controller, actions, and helpers together by feature)
142+
- Write clean, readable, and self-explanatory code
143+
- Use meaningful and descriptive names for files, functions, and variables
144+
- Remove unused imports, variables, and dead code automatically
145+
146+
## Task Execution & Automation
147+
148+
- Always proceed to the next task automatically unless confirmation is required
149+
- Only ask for confirmation when an action is destructive (e.g., data loss, deletion)
150+
- Always attempt to identify and fix bugs automatically
151+
- Only ask for manual intervention if domain-specific knowledge is required
152+
- Auto-generate missing files, boilerplate, and tests when possible
153+
- Auto-lint and format code using standard tools (e.g., Prettier, ESLint, dotnet format)
154+
- Changes should be made directly to the file in question. Example: admin.php should be modified directly, not by creating a new file like admin-changes.php.
155+
- New files may be created when appropriate, but they should be relevant to the task at hand, so long as they are not a rewrite of an existing file. We want to avoid unnecessary duplication of files.

‎.github/workflows/new-pull-request.yml

Lines changed: 13 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -23,7 +23,16 @@ jobs:
2323
body: |
2424
Thanks for contributing to Simple WP Optimizer! 🎉
2525
26-
27-
We'll review your PR soon!
28-
# Token is implicitly provided with the defined permissions
29-
# token: ${{ secrets.GITHUB_TOKEN }} # This line can be removed
26+
**Before we review:**
27+
- [ ] Have you tested your changes with WordPress 6.5+?
28+
- [ ] Are your changes compatible with PHP 7.4+?
29+
- [ ] Have you followed WordPress coding standards?
30+
- [ ] Did you update the CHANGELOG.md if needed?
31+
32+
**Security Reminder:**
33+
This plugin can handle sensitive site configuration information, so please ensure:
34+
- All user inputs are properly sanitized
35+
- All outputs are properly escaped
36+
- No security vulnerabilities are introduced
37+
38+
We'll review your PR soon! 🚀

‎.github/workflows/wp-plugin-check.yml renamed to ‎.github/workflows/wp-compatibility-test.yml

Lines changed: 9 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22
# It runs multiple validation processes including:
33
# - WordPress Plugin Check for WordPress.org compatibility
44
# - PHP compatibility testing across multiple PHP versions (7.4, 8.0, 8.1, 8.2, 8.3, 8.4)
5-
# - WordPress compatibility testing across multiple WP versions (6.0, latest, nightly)
5+
# - WordPress compatibility testing across multiple WP versions (6.5, latest, nightly)
66
# - PHPStan static analysis for WordPress-specific code quality
77
# - WordPress security vulnerability scanning using pattern analysis
88
# - PHPCS code standards validation for WordPress coding standards
@@ -129,6 +129,9 @@ jobs:
129129
composer global config allow-plugins.dealerdirect/phpcodesniffer-composer-installer true
130130
composer global require --dev squizlabs/php_codesniffer:"^3.7"
131131
composer global require --dev wp-coding-standards/wpcs:"^3.0"
132+
composer global require --dev phpcompatibility/php-compatibility:"^9.3"
133+
composer global require --dev phpcompatibility/phpcompatibility-wp:"^2.1"
134+
composer global require --dev automattic/vipwpcs:"^3.0"
132135
composer global require --dev dealerdirect/phpcodesniffer-composer-installer:"^1.0"
133136
134137
# Add composer bin to PATH
@@ -188,14 +191,9 @@ jobs:
188191

189192
- name: Run PHPMD
190193
run: |
191-
# Use WordPress-specific PHPMD configuration to suppress WordPress-specific patterns
192-
if [ -f phpmd-wordpress.xml ]; then
193-
echo "Using WordPress-specific PHPMD configuration..."
194-
phpmd . text phpmd-wordpress.xml --exclude vendor,tests,node_modules
195-
else
196-
echo "WordPress PHPMD config not found, using standard rules..."
197-
phpmd . text cleancode,codesize,controversial,design,naming,unusedcode --exclude vendor,tests,node_modules
198-
fi
194+
# Use WordPress-specific PHPMD configuration (WordPress snake_case compatible)
195+
echo "Using WordPress-specific PHPMD configuration (WordPress snake_case compatible)..."
196+
phpmd simple-wp-optimizer.php text phpmd.xml
199197
200198
- name: Create issue on PHPMD failure
201199
if: ${{ failure() }}
@@ -376,7 +374,7 @@ jobs:
376374
strategy:
377375
matrix:
378376
php-version: ['7.4', '8.0', '8.1', '8.2', '8.3', '8.4']
379-
wp-version: ['6.0', 'latest', 'nightly']
377+
wp-version: ['6.5', 'latest', 'nightly']
380378
fail-fast: false
381379

382380
services:
@@ -595,7 +593,7 @@ jobs:
595593
$this->assertNotEmpty($wp_version, 'WordPress version should be available');
596594
597595
// Test that we're running on a supported WordPress version
598-
$min_wp_version = '5.0';
596+
$min_wp_version = '6.5';
599597
$this->assertTrue(version_compare($wp_version, $min_wp_version, '>='),
600598
"WordPress version {$wp_version} should be >= {$min_wp_version}");
601599
}

‎CHANGELOG.md

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -4,6 +4,11 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
44
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
55

66
## [Unreleased]
7+
### Updated
8+
- **Requirements**: Updated minimum WordPress version requirement to 6.5+ across all files for modern WordPress compatibility
9+
- **Files Created**: Added changelog.txt for WordPress.org compatibility as per version control guidelines
10+
- **Internationalization**: Created languages/simple-wp-optimizer.pot file for translation support
11+
- **Documentation**: Updated all version references to reflect new WordPress 6.5+ minimum requirement
712

813
## [1.5.8] - 2025-06-15
914
### Added

0 commit comments

Comments
 (0)