Directives de Signalement de Problèmes
Les rapports de bogues efficaces et les demandes de fonctionnalités sont cruciaux pour le développement de XOOPS. Ce guide vous aide à créer des problèmes de haute qualité.
Before Reporting
Section intitulée « Before Reporting »Check Existing Issues
Section intitulée « Check Existing Issues »Always search first:
- Go to GitHub Issues
- Search for keywords related to your issue
- Check closed issues - might be already resolved
- Look at pull requests - might be in progress
Use search filters:
is:issue is:open label:bug- Open bugsis:issue is:open label:feature- Open feature requestsis:issue sort:updated- Recently updated issues
Is It Really an Issue?
Section intitulée « Is It Really an Issue? »Consider first:
- Configuration issue? - Check the documentation
- Usage question? - Ask on forums or Discord community
- Security issue? - See #security-issues section below
- Module-specific? - Report to module maintainer
- Theme-specific? - Report to theme author
Issue Types
Section intitulée « Issue Types »Bug Report
Section intitulée « Bug Report »A bug is an unexpected behavior or defect.
Examples:
- Login not working
- Database errors
- Missing form validation
- Security vulnerability
Feature Request
Section intitulée « Feature Request »A feature request is a suggestion for new functionality.
Examples:
- Add support for new feature
- Improve existing functionality
- Add missing documentation
- Performance improvements
Enhancement
Section intitulée « Enhancement »An enhancement improves existing functionality.
Examples:
- Better error messages
- Improved performance
- Better API design
- Better user experience
Documentation
Section intitulée « Documentation »Documentation issues include missing or incorrect documentation.
Examples:
- Incomplete API documentation
- Outdated guides
- Missing code examples
- Typos in documentation
Reporting a Bug
Section intitulée « Reporting a Bug »Bug Report Template
Section intitulée « Bug Report Template »## DescriptionBrief, clear description of the bug.
## Steps to Reproduce1. Step one2. Step two3. Step three
## Expected BehaviorWhat should happen.
## Actual BehaviorWhat actually happens.
## Environment- XOOPS Version: X.Y.Z- PHP Version: 8.2/8.3/8.4- Database: MySQL/MariaDB version- Operating System: Windows/macOS/Linux- Browser: Chrome/Firefox/Safari
## ScreenshotsIf applicable, add screenshots showing the issue.
## Additional ContextAny other relevant information.
## Possible FixIf you have suggestions for fixing the issue (optional).Good Bug Report Example
Section intitulée « Good Bug Report Example »## DescriptionLogin page shows blank page when database connection fails.
## Steps to Reproduce1. Stop the MySQL service2. Navigate to the login page3. Observe the behavior
## Expected BehaviorShow a user-friendly error message explaining the database connection issue.
## Actual BehaviorThe page is completely blank - no error message, no interface visible.
## Environment- XOOPS Version: 2.7.0- PHP Version: 8.0.28- Database: MySQL 5.7- Operating System: Ubuntu 20.04- Browser: Chrome 120
## Additional ContextThis likely affects other pages too. The error should be displayed to admins or logged appropriately.
## Possible FixCheck database connection in header.php before rendering the template.Poor Bug Report Example
Section intitulée « Poor Bug Report Example »## DescriptionLogin doesn't work
## Steps to ReproduceIt doesn't work
## Expected BehaviorIt should work
## Actual BehaviorIt doesn't
## EnvironmentLatest versionReporting a Feature Request
Section intitulée « Reporting a Feature Request »Feature Request Template
Section intitulée « Feature Request Template »## DescriptionClear, concise description of the feature.
## Problem StatementWhy is this feature needed? What problem does it solve?
## Proposed SolutionDescribe your ideal implementation or UX.
## Alternatives ConsideredAre there other ways to achieve this goal?
## Additional ContextAny mockups, examples, or references.
## Expected ImpactHow would this benefit users? Would it be breaking?Good Feature Request Example
Section intitulée « Good Feature Request Example »## DescriptionAdd two-factor authentication (2FA) for user accounts.
## Problem StatementWith increasing security breaches, many CMS platforms now offer 2FA. XOOPS users want stronger account security beyond passwords.
## Proposed SolutionImplement TOTP-based 2FA (compatible with Google Authenticator, Authy, etc.).- Users can enable 2FA in their profile- Display QR code for setup- Generate backup codes for recovery- Require 2FA code at login
## Alternatives Considered- SMS-based 2FA (requires carrier integration, less secure)- Hardware keys (too complex for average users)
## Additional ContextSimilar to GitHub, GitLab, and WordPress implementations.Reference: [TOTP Standard RFC 6238](https://tools.ietf.org/html/rfc6238)
## Expected ImpactIncreases account security. Could be optional initially, mandatory in future versions.Security Issues
Section intitulée « Security Issues »Do NOT Report Publicly
Section intitulée « Do NOT Report Publicly »Never create a public issue for security vulnerabilities.
Report Privately
Section intitulée « Report Privately »- Email the security team: security@xoops.org
- Include:
- Description of the vulnerability
- Steps to reproduce
- Potential impact
- Your contact information
Responsible Disclosure
Section intitulée « Responsible Disclosure »- We will acknowledge receipt within 48 hours
- We will provide updates every 7 days
- We will work on a fix timeline
- You may request credit for the discovery
- Coordinate public disclosure timing
Security Issue Example
Section intitulée « Security Issue Example »Subject: [SECURITY] XSS Vulnerability in Comment Form
Description:The comment form in Publisher module does not properly escape user input,allowing stored XSS attacks.
Steps to Reproduce:1. Create a comment with: <img src=x onerror="alert('xss')">2. Submit the form3. The JavaScript executes when viewing the comment
Impact:Attackers can steal user session tokens, perform actions as users,or deface the website.
Environment:- XOOPS 2.7.0- Publisher Module 1.xIssue Title Best Practices
Section intitulée « Issue Title Best Practices »Good Titles
Section intitulée « Good Titles »✅ Login page shows blank error when database connection fails✅ Add two-factor authentication support✅ Form validation not preventing SQL injection in name field✅ Improve performance of user list query✅ Update installation documentation for PHP 8.2Poor Titles
Section intitulée « Poor Titles »❌ Bug in system❌ Help me!!❌ It doesn't work❌ Question about XOOPS❌ ErrorTitle Guidelines
Section intitulée « Title Guidelines »- Be specific - Mention what and where
- Be concise - Under 75 characters
- Use present tense - “shows blank page” not “showed blank”
- Include context - “in admin panel”, “during installation”
- Avoid generic words - Not “fix”, “help”, “problem”
Issue Description Best Practices
Section intitulée « Issue Description Best Practices »Include Essential Information
Section intitulée « Include Essential Information »- What - Clear description of the issue
- Where - Which page, module, or feature
- When - Steps to reproduce
- Environment - Version, OS, browser, PHP
- Why - Why this is important
Use Code Formatting
Section intitulée « Use Code Formatting »Error message: `Error: Cannot find user`
Code snippet:```php$user = $this->getUser($id);if (!$user) { echo "Error: Cannot find user";}### Include Screenshots
For UI issues, include:- Screenshot of the problem- Screenshot of expected behavior- Annotate what's wrong (arrows, circles)
### Use Labels
Add labels to categorize:- `bug` - Bug report- `enhancement` - Enhancement request- `documentation` - Documentation issue- `help wanted` - Looking for help- `good first issue` - Good for new contributors
---
## After Reporting
### Be Responsive
- Check for questions in the issue comments- Provide additional information if requested- Test suggested fixes- Verify bug still exists with new versions
### Follow Etiquette
- Be respectful and professional- Assume good intentions- Don't demand fixes - developers are volunteers- Offer to help if possible- Thank contributors for their work
### Keep Issue Focused
- Stay on topic- Don't discuss unrelated issues- Link to related issues instead- Don't use issues for feature voting
---
## What Happens to Issues
### Triage Process
1. **New issue created** - GitHub notifies maintainers2. **Initial review** - Checked for clarity and duplicates3. **Label assignment** - Categorized and prioritized4. **Assignment** - Assigned to someone if appropriate5. **Discussion** - Additional info gathered if needed
### Priority Levels
- **Critical** - Data loss, security, complete breakage- **High** - Major feature broken, affects many users- **Medium** - Part of feature broken, workaround available- **Low** - Minor issue, cosmetic, or niche use case
### Resolution Outcomes
- **Fixed** - Issue resolved in a PR- **Won't fix** - Rejected for technical or strategic reasons- **Duplicate** - Same as another issue- **Invalid** - Not actually an issue- **Needs more info** - Waiting for additional details
---
## Issue Examples
### Example: Good Bug Report
```markdown## DescriptionAdmin users cannot delete items when using MySQL with strict mode enabled.
## Steps to Reproduce1. Enable `sql_mode='STRICT_TRANS_TABLES'` in MySQL2. Navigate to Publisher admin panel3. Click delete button on any article4. Error is shown
## Expected BehaviorArticle should be deleted or show meaningful error.
## Actual BehaviorError: "SQL Error - Unknown column 'deleted_at' in ON clause"
## Environment- XOOPS Version: 2.7.0- PHP Version: 8.2.0- Database: MySQL 8.0.32 with STRICT_TRANS_TABLES- Operating System: Ubuntu 22.04- Browser: Firefox 120
## Screenshots[Screenshot of error message]
## Additional ContextThis only happens with strict SQL mode. Works fine with default settings.The query is in class/PublisherItem.php:248
## Possible FixUse single quotes around 'deleted_at' or use backticks for all column names.Example: Good Feature Request
Section intitulée « Example: Good Feature Request »## DescriptionAdd REST API endpoints for read-only access to public content.
## Problem StatementDevelopers want to build mobile apps and external services using XOOPS data.Currently limited to SOAP API which is outdated and poorly documented.
## Proposed SolutionImplement RESTful API with:- Endpoints for articles, users, comments (read-only)- Token-based authentication- Standard HTTP status codes and errors- OpenAPI/Swagger documentation- Pagination support
## Alternatives Considered- Enhanced SOAP API (legacy, not standards-compliant)- GraphQL (more complex, maybe future)
## Additional ContextSee Publisher module API refactoring for similar patterns.Would align with modern web development practices.
## Expected ImpactEnable ecosystem of third-party tools and mobile apps.Would improve XOOPS adoption and ecosystem.Documentation Connexe
Section intitulée « Documentation Connexe »- Code de Conduite
- Flux de Contribution
- Directives de Demande de Tirage
- Aperçu de la Contribution
#xoops #issues #bug-reporting #feature-requests #github