Version 5 supported

Contributing Issues and Opinions

Reporting Bugs

If you have discovered a bug in Silverstripe CMS, we'd be glad to hear about it - well written bug reports can be half of the solution already!

Before submitting a bug:

  • Ask for assistance in our community channels if you're unsure if it's really a bug.
  • Search for similar, existing tickets. You can list all issues across modules, then add your search phrase at the start of the existing search filters (for example all issues with label "type/ux")
  • Is this a security issue? Please follow our separate reporting guidelines below.
  • Which modules does this issue belong to? Each one has its own issue tracker. If you are unsure, create an issue on the the "framework" repository.
  • Note that documentation issues are tracked in the "developer-docs" repository.
  • Try to reproduce your issue on a clean installation, maybe the bug has already been fixed on an unreleased branch?
  • The bugtracker is not the place to discuss enhancements, please use the "feature ideas" forum category and our community channels. Only log enhancement tickets if they gather a large interest in the community and the enhancement is likely to be implemented in the next couple of months.

If the issue does look like a new bug:

  • Create an issue on the right module repository in GitHub
  • Describe the steps required to reproduce your issue, and the expected outcome. Unit tests, screenshots and screencasts can help here.
  • Describe your environment as detailed as possible: SilverStripe version, Browser, PHP version, Operating System, any installed SilverStripe modules.
  • (optional) Submit a pull request which fixes the issue.

Lastly, don't get your hopes up too high. Unless your issue is a blocker affecting a large number of users, don't expect SilverStripe developers to jump onto it right way. Your issue is a starting point where others with the same problem can collaborate with you to develop a fix.

Feature Requests

Please don't file "feature requests" as Github issues. If there's a new feature you'd like to see in SilverStripe, you either need to write it yourself (and submit a pull request or convince somebody else to write it for you. Any "wishlist" type issues without code attached can be expected to be closed as soon as they're reviewed.

In order to gain interest and feedback in your feature, we encourage you to present it to the community through the community channels.

Reporting Security Issues

If you think a bug may have security implications, do not create a GitHub issue for it. This may lead to a zero-day vulnerability.

Report potential security issues to security@silverstripe.org. See our "Release Process" documentation for more info, and read our guide on how to write secure code.

Silverstripe CMS does not operate a bug bounty program.

Review our Managing Security Guidelines guidelines to understand what happens once a vulnerability is reported.

Sharing your Opinion

Identifying issues and pull request relevant to your own project

Our issue browser can be helpful to identify known issues and pending pull requests in supported modules. But you're usually only running some of these modules, and others from the wider module ecosystem.

In order to only show issues and pull requests relevant to your project, we've written a little composer utility which inspects your own composer.lock file dependencies, and searches across all Silverstripe CMS modules in there.

After installing the composer utility, use this command to pass through a lock file, and get a URL to open in your favourite browser.

cat /my/project/composer.lock | ss-issue-search get-url

Protip: You can further filter to certain issue labels such as label:impact/high to make the results more relevant.

Edit on Github