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
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      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".

      32 votes
      Vote
      Sign in
      Check!
      (thinking…)
      Reset
      or sign in with
      • facebook
      • google
        Password icon
        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
          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
            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.

            6 votes
            Vote
            Sign in
            Check!
            (thinking…)
            Reset
            or sign in with
            • facebook
            • google
              Password icon
              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…

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

                    New Features

                    Feedback and Knowledge Base