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. Use ReactJS/GraphQL for all CMS interfaces

    With the 4.0 release, we've redeveloped the "assets" section in ReactJS, and created a new "campaigns" section on the same foundations. We've previously blogged about why that's a good idea: https://www.silverstripe.org/blog/cutting-through-the-noise-why-silverstripe-4-will-use-reactjs/

    Major sections like "pages" or "security" are still based on jQuery/Entwine logic, with minor bits of ReactJS sprinkled in (e.g. the new TreeDropdownField ReactJS component). In order to provide a consistent developer experience in the CMS, we need to finish this transition.

    The CMS UI has often been heavily customised through jQuery/Entwine, so this transition will require many modules to rewrite view logic. It's important to ensure that the…

    4 votes
    Vote
    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      You have left! (?) (thinking…)
      planned  ·  0 comments  ·  Admin →
    • 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…

      15 votes
      Vote
      Sign in
      Check!
      (thinking…)
      Reset
      or sign in with
      • facebook
      • google
        Password icon
        I agree to the terms of service
        Signed in as (Sign out)
        You have left! (?) (thinking…)
      • 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".

        31 votes
        Vote
        Sign in
        Check!
        (thinking…)
        Reset
        or sign in with
        • facebook
        • google
          Password icon
          I agree to the terms of service
          Signed in as (Sign out)
          You have left! (?) (thinking…)
        • Add events system

          Currently we have a few ad-hoc events (like preRequestFilter and postRequestFilter), and a few event-like methods that are caught by extensions (onBeforeWrite, etc).

          These are both un-ideal from a performance point of view. Both the event raiser and all event handlers need to be loaded at all times, and the event-like behaviour of extensions is one of the things stopping us from replacing them with traits.

          Important to this working would be the ability to bind event raisers to event handlers in the config system, while still being able to specify some level of filtering (for instance be able to…

          80 votes
          Vote
          Sign in
          Check!
          (thinking…)
          Reset
          or sign in with
          • facebook
          • google
            Password icon
            I agree to the terms of service
            Signed in as (Sign out)
            You have left! (?) (thinking…)
          • 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
            Check!
            (thinking…)
            Reset
            or sign in with
            • facebook
            • google
              Password icon
              I agree to the terms of service
              Signed in as (Sign out)
              You have left! (?) (thinking…)
            • 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
              Check!
              (thinking…)
              Reset
              or sign in with
              • facebook
              • google
                Password icon
                I agree to the terms of service
                Signed in as (Sign out)
                You have left! (?) (thinking…)
              • 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.

                4 votes
                Vote
                Sign in
                Check!
                (thinking…)
                Reset
                or sign in with
                • facebook
                • google
                  Password icon
                  I agree to the terms of service
                  Signed in as (Sign out)
                  You have left! (?) (thinking…)
                  1 comment  ·  Admin →
                • 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…

                  7 votes
                  Vote
                  Sign in
                  Check!
                  (thinking…)
                  Reset
                  or sign in with
                  • facebook
                  • google
                    Password icon
                    I agree to the terms of service
                    Signed in as (Sign out)
                    You have left! (?) (thinking…)
                  • 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
                    Check!
                    (thinking…)
                    Reset
                    or sign in with
                    • facebook
                    • google
                      Password icon
                      I agree to the terms of service
                      Signed in as (Sign out)
                      You have left! (?) (thinking…)
                    • Add Drag and Drop Folder Management in CMS Files admin tree view

                      Self explanatory, but when viewing files in tree view, it would be better if we could drag and drop folder hierarchy like with site tree pages and then asset urls update accordingly.

                      You run into needing this feature as SilverStripe will force all assets into a root folder called 'Assets' which you cannot view from within CMS and causes issues with Modules (like Static Site importer) generating a second 'Assets' folder within the root "Assets" folder.

                      So being able to drag folders into root would be useful, but also useful in general to organise and manage folders.

                      35 votes
                      Vote
                      Sign in
                      Check!
                      (thinking…)
                      Reset
                      or sign in with
                      • facebook
                      • google
                        Password icon
                        I agree to the terms of service
                        Signed in as (Sign out)
                        You have left! (?) (thinking…)
                        planned  ·  Sam Minnée responded

                        This is planned as part of the new React-based files area.

                      • 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.

                        19 votes
                        Vote
                        Sign in
                        Check!
                        (thinking…)
                        Reset
                        or sign in with
                        • facebook
                        • google
                          Password icon
                          I agree to the terms of service
                          Signed in as (Sign out)
                          You have left! (?) (thinking…)
                          planned  ·  Ingo Schommer responded

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

                        • 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
                          Check!
                          (thinking…)
                          Reset
                          or sign in with
                          • facebook
                          • google
                            Password icon
                            I agree to the terms of service
                            Signed in as (Sign out)
                            You have left! (?) (thinking…)
                            planned  ·  3 comments  ·  Admin →
                          • Don't see your idea?

                          New Features

                          Feedback and Knowledge Base