New Features

Please add your suggestions for new SilverStripe CMS & Framework features (Note: bugs should be logged over in GitHub).

A new feature for SilverStripe should be ...

You've used all your votes and won't be able to post a new idea, but you can still search and comment on existing ideas.

There are two ways to get more votes:

  • When an admin closes an idea you've voted on, you'll get your votes back from that idea.
  • You can remove your votes from an open idea you support.
  • To see ideas you have already voted on, select the "My feedback" filter and select "My open ideas".
(thinking…)

Enter your idea and we'll search to see if someone has already suggested it.

If a similar idea already exists, you can support and comment on it.

If it doesn't exist, you can post your idea so others can support it.

Enter your idea and we'll search to see if someone has already suggested it.

  1. Ability to "fully delete" Page from Archive

    Currently a page can only go through published, draft and archived states. Technically it always will exist in the database after initially being created with no real complete removal. This can eventually be quite cumbersome if you have a large website with situations where assets and other relations that need to be cleaned up after a while manually by the user.

    Here is a proposed full list of transitions that a page can go through :

    - Published
    - Draft
    - Archived (we are here)
    - Fully deleted (doesn't exist in the database in any form).

    Additionally, I think this…

    20 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  Flag idea as inappropriate…  ·  Admin →
  2. Simultaneous editing support

    Currently there's no good support for two editors editing the same Page (or other Data Object).

    We should at least allow locking a page, but better would be adding simultaneous editing a-la Google Docs, etc. If we couldn't get totally simultaneous editing working (TinyMCE might be tricky) we could at least allow simultaneous viewing, with a single person being the current "editor".

    33 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    7 comments  ·  Flag idea as inappropriate…  ·  Admin →
  3. Replace extensions with traits

    Extensions are quite slow, and PHP 5.4 introduced traits which does a lot of the same stuff but as a language feature (so is much faster).

    One caveat is the event-like methods in Extensions (onAfterWrite, etc), but they can be replaced with an event system (see http://silverstripe.uservoice.com/forums/251266-new-features/suggestions/6425842-add-events-system)

    Once that's done it'd be easy to replace extensions with traits.

    It will require upgrading the minimum PHP version to 5.4, or doing some dynamic class compilation in the autoloader in 5.3 to maintain compatibility

    35 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    10 comments  ·  Flag idea as inappropriate…  ·  Admin →
  4. Behat testing should be as easy as unit testing

    Right now Behat testing isn't used very much - it's harder to get running than it should be, and is quite slow.

    We should try and get Behat testing to be more popular by improving the ease with which tests can be written.

    11 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  Flag idea as inappropriate…  ·  Admin →
  5. Make CRUD permissions ACL based

    RIght now we do permissions exclusively client side with canView, canEdit, etc.

    Not only is this not easy to extend, it's also hard to apply to sets of objects, especially for objects that don't inherit from Page (which provides a bulk-check feature, as long as you haven't tweaked canView) - each one needs to be checked in turn.

    We should look at changing permissions to be something that can be applied in bulk - ideally on the SQL server.

    6 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Flag idea as inappropriate…  ·  Admin →
  6. Core state handling to fix subsites / translatable / etc

    Right now we have _lots_ of ad-hoc cross-request state tracking.

    State is any inputs that affects the cross-section of data that ends up being visible to DataObject

    Versioned, Subsites, Translatable and several others are examples of this.

    We already have DataQuery#$queryParams to track some of this state internally, but when it comes to tracking it across requests, every module has it's own solution.

    The worst are those modules that store it in the session, since this affects all tabs / windows being used by that user, which can lead to unexpected behaviour.

    This API would instead allow reading state encoded…

    10 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  7. Rework extensions to be less dynamically controllable

    Currently extensions can be dynamically added and removed via Object::add_extension and Object::remove_extension. This limits the caching the config system can do.

    Since this dynamicity isn't really required, and is used primarily for tests, we could replace this with "extension sets" - a pre-configured list of extensions that can be switched between.

    This would allow pre-computing of a merged config for each extension set.

    5 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  8. Accessibiility compliance in CMS

    Ensure that less able CMS authors can work with our core toolset.

    - Follow guidance of the W3C for Rich Internet Applications (ARIA): https://www.w3.org/WAI/intro/aria
    - Follow guidance of the W3C for Authoring Tools (ATAG): https://www.w3.org/WAI/intro/atag

    Notes:
    - WCAG compliance is often mandated in tools used by government. See Australia (https://www.dta.gov.au/standard/9-make-it-accessible/) or New Zealand (https://webtoolkit.govt.nz/standards/web-accessibility-standard-1-0/) for examples.

    21 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  Flag idea as inappropriate…  ·  Admin →
    planned  ·  Ingo Schommer responded

    I’ve broadened this idea from ATAG compliance to wider “accessibility compliance” in the CMS.

  9. Include Root should be configured

    The root path for files processed by SilverStripe should be configured, rather than assumed as the Document root. Preferably, the SilverStripe root should be *above* the server Document root. This narrows the range of bugs which could allow these configuration files to be leaked.

    Most files - most particularly those containing sensitive data such as database passwords - should be processed relative to the Include Root, not the Document Root. (The Include Root, of course, still needs to have its own configuration set in a known location. Presumably that is the only configuration under the Document Root).

    If a developer…

    4 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    planned  ·  3 comments  ·  Flag idea as inappropriate…  ·  Admin →
  • Don't see your idea?

New Features

Feedback and Knowledge Base