Ingo Schommer

My feedback

  1. 14 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  ·  New Features  ·  Flag idea as inappropriate…  ·  Admin →
      Ingo Schommer commented  · 

      We still have 217 matches for user_error() in the 4.0 core. Related Github issue: https://github.com/silverstripe/silverstripe-framework/issues/1915

    • 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…)
        started  ·  0 comments  ·  New Features  ·  Flag idea as inappropriate…  ·  Admin →
        Ingo Schommer shared this idea  · 
      • 8 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  ·  New Features  ·  Flag idea as inappropriate…  ·  Admin →
          Ingo Schommer shared this idea  · 
        • 1 vote
          Vote
          Sign in
          Check!
          (thinking…)
          Reset
          or sign in with
          • facebook
          • google
            Password icon
            Signed in as (Sign out)
            You have left! (?) (thinking…)
            2 comments  ·  New Features  ·  Flag idea as inappropriate…  ·  Admin →
            Ingo Schommer commented  · 

            Hey Jeremy, that's sad to hear - end of an era! :( Thank you for all your hard work over the years of course. I don't want silverstripe-archive to become the graveyard of everyone's modules if at all possible heh. So I'd suggest you simply flag these modules as unmaintained in the README. You could also mark it as abandoned on https://packagist.org/.

            In terms of finding new maintainers, I'd suggest you create a github issue on every module you think people still care about, and ping everyone that's interacted with the module over the last years (issues, pull requests, etc)

            I assume that doesn't heavily affect http://silvershop.io/ since it's still got other active maintainers?

            Here's a list of your modules ordered by most packagist downloads: http://addons.silverstripe.org/add-ons?search=burnbright

          • 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…)
              7 comments  ·  New Features  ·  Flag idea as inappropriate…  ·  Admin →
              Ingo Schommer commented  · 

              It seems like there's two ideas here:

              1. Auto-save content so it can be recovered (Patrick's version?). I'd rather keep this out of the server altogether, and rely on localstorage in the browser. It should survive most browser crashes, and scales a lot better (less calls to the server, no additional database storage).

              2. Auto-save content to reduce manual user saving actions (Paul's version?). That would require server calls and additional database storage. We're definitely not adding a fourth table to each versioned record, it's already getting out of hand in terms of table count. So we'd have to figure out how to make this work in _Versions, e.g. through a separate "auto-save" flag which is separate from the remaining versions collection for a record.

              I'd much rather implement #1 than #2, since it's simpler - particularly once we've rolled out React and Form Schema in all SS4 UIs, at which point it's easy to restore a view from localStorage state.

            • 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…)
                5 comments  ·  New Features  ·  Flag idea as inappropriate…  ·  Admin →
                Ingo Schommer commented  · 

                We've tried to avoid having those resize requests exceeding available PHP memory by implementing some heuristics: https://github.com/silverstripe/silverstripe-assets/blob/dc175b6587699ecc5bafca42ecd069a8e92469f8/src/GDBackend.php#L160

                But you're right, that just leads to an image that can't be manipulated through SilverStripe code (e.g. to produce a more lightweight thumbnail). Max filesize limitations on upload isn't very effective either, since fairly small file sizes can cause huge memory use when run through GD2 (and no compression).

                You could look into moving the heuristics into upload, and allow configuration of max image dimensions there? Alternatively, a hook in Upload::load() sounds good to me.

              • 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…)
                  2 comments  ·  New Features  ·  Flag idea as inappropriate…  ·  Admin →
                • 2 votes
                  Vote
                  Sign in
                  Check!
                  (thinking…)
                  Reset
                  or sign in with
                  • facebook
                  • google
                    Password icon
                    Signed in as (Sign out)
                    You have left! (?) (thinking…)
                    2 comments  ·  New Features  ·  Flag idea as inappropriate…  ·  Admin →
                    Ingo Schommer commented  · 

                    I think now that semantic versioning is more established in the wider SilverStripe ecosystem, that becomes more feasible. I'd expect the main use case would be patch-level upgrades of existing modules for security releases. In practice, it means that you opt out of maintaining a composer.json and composer.lock as part of your website repository, and bypass other controls like UAT environments, pre-deploy builds etc. That might be feasible for some projects, but I don't think it'll serve the wider community well in terms of making this a core feature - one aspect that has always distinguished SilverStripe is the certainty of what is getting deployed: You don't have to deal with database state merges for configuration, since it's all in code (and your repo).

                    You might want to dig through groups.google.com/forum/#!forum/silverstripe-dev, this idea has been discussed before there.

                  • 73 votes
                    Vote
                    Sign in
                    Check!
                    (thinking…)
                    Reset
                    or sign in with
                    • facebook
                    • google
                      Password icon
                      Signed in as (Sign out)
                      You have left! (?) (thinking…)
                      8 comments  ·  New Features  ·  Flag idea as inappropriate…  ·  Admin →
                      under review  ·  Ingo Schommer responded

                      We’re doing some GraphQL API work instead of REST support for SilverStripe 4: http://silverstripe.uservoice.com/forums/251266-new-features/suggestions/16924327-graphql-api-support

                      GraphQL is an alternative to REST, and well suited for modern frontend architectures. There’s still valid use cases for REST in SilverStripe, but from a core perspective we’re unlikely to build out core support for a REST layer in parallel to GraphQL, so moving this back from “planned” to “under review”.

                      Ingo Schommer shared this idea  · 
                    • 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…)
                        2 comments  ·  New Features  ·  Flag idea as inappropriate…  ·  Admin →
                        Ingo Schommer commented  · 

                        Thanks for the suggestion, Barry! Can you be a bit more specific about the limitations of the current Zend_Locale based solution? Wouldn't a second $locale parameter SS_DateTime::Format() be sufficient? Or are you using APIs "one layer up" and don't have access to the Format() call? For example, DateField in SS CMS auto-formats with the right locale already.

                        And: What's the reasoning for using Carbon? I'm aware its more modern and lightweight, but has a fairly big gotcha: It relies on PHP's native setlocale(), which in turn relies on i18n data on the specific operating system. In contrast, Zend_Locale is self contained, relying on XML sourced from the fairly comprehensive and official cldr.unicode.org.

                        You can see the effect of relying on system locales on a randomly picked Carbon issue: https://github.com/briannesbitt/Carbon/issues/430. Which is why I opted for Zend_Locale a few years back. But it does add quite a bit of bloat to the framework checkout, and is rarely used in this depth.

                        Maybe we can create an abstraction layer which works with both Zend_Locale and the native setlocale(), and remove the Zend_Locale dependency from core? This needs a lot more deliberation though, which I don't have time for at the moment. Maybe you want to think this through a bit more and get the effort rolling?

                      • 26 votes
                        Vote
                        Sign in
                        Check!
                        (thinking…)
                        Reset
                        or sign in with
                        • facebook
                        • google
                          Password icon
                          Signed in as (Sign out)
                          You have left! (?) (thinking…)
                          8 comments  ·  New Features  ·  Flag idea as inappropriate…  ·  Admin →
                          Ingo Schommer commented  · 

                          Great idea! I think it'll be easiest to tie this in with a UI refresh (flatter look), but also not opposed to revamping the icons as a first step. Some tasks to get closer to this goal:

                          - Find a font set with a BSD compat license (any recommendations?)
                          - Are we OK with the limitations of web fonts (no multi-colour icons)?
                          - Performance implications of webfonts vs. vectors. Which one is more future proof?
                          - Ensure existing CSS classes for page tree and menu icons continue to work
                          - Can devs add their own icons without requiring individual file loading for each of them in the CMS?
                          - Can we completely replace the current bitmap sprites, or what's left?

                        • 12 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  ·  New Features  ·  Flag idea as inappropriate…  ·  Admin →
                            Ingo Schommer commented  · 

                            That's difficult to implement since we don't know what "used" means from a framework perspective. For example, does an image related to a deleted blog post via a many_many relationship count as "used"? You'd need to follow a lot of relationship paths across the whole database to identify images, and then you'll still miss any files which are referenced directly through their file path in templates, PHP code or JavaScript.

                            We could provide a list UI of "potentially unused" files which you can select to delete with specific knowledge on how files are used in your application, but I don't see that as a good feature for core.

                          • 80 votes
                            Vote
                            Sign in
                            Check!
                            (thinking…)
                            Reset
                            or sign in with
                            • facebook
                            • google
                              Password icon
                              Signed in as (Sign out)
                              You have left! (?) (thinking…)
                              under review  ·  4 comments  ·  New Features  ·  Flag idea as inappropriate…  ·  Admin →
                              Ingo Schommer supported this idea  · 
                            • 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…)
                                10 comments  ·  New Features  ·  Flag idea as inappropriate…  ·  Admin →
                                Ingo Schommer supported this idea  · 
                              • 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…)
                                  2 comments  ·  New Features  ·  Flag idea as inappropriate…  ·  Admin →
                                  planned  ·  Ingo Schommer responded

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

                                  Ingo Schommer commented  · 

                                  Could you refer to any govt policy documents which mandate or favour ATAG compliant CMS? Do you have an example of a compliant CMS? I'm always interested in making the CMS more accessible, but fear that without external funding or a commercial business case other features will take precedence (sadly).

                                  We're already reasonably accessible (document structure, link targets, titles, jQuery UI modals), but need to do better in declaring content areas, hierarchical structures like the tree, dropdowns, and announcing ajax updates appropriately,

                                • 2 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  ·  New Features  ·  Flag idea as inappropriate…  ·  Admin →
                                    Ingo Schommer commented  · 

                                    I'd consider this too technical for the default feature set, and hard to abstract into more user friendly UI controls. In your example, we could use a "make image responsive" checkbox, but that'd rely on a specific frontend implementation so can't be in core. Instead we should write a tutorial in how to customize the HTMLEditorField behaviour (you can add a dropdown or text field there), and the JS parser which generates the tag. Could even be a module?

                                  • 13 votes
                                    Vote
                                    Sign in
                                    Check!
                                    (thinking…)
                                    Reset
                                    or sign in with
                                    • facebook
                                    • google
                                      Password icon
                                      Signed in as (Sign out)
                                      You have left! (?) (thinking…)
                                      11 comments  ·  New Features  ·  Flag idea as inappropriate…  ·  Admin →
                                      Ingo Schommer commented  · 

                                      I've added my thoughts on this here already: https://silverstripe.uservoice.com/forums/251266-new-features/suggestions/6286170-make-debugging-info-look-nice
                                      In short, I agree with making dev options more accessible than "magic" query parameters, but think they should be separated from the CMS UI, a toolbar is a better approach there IMHO.

                                    • 16 votes
                                      Vote
                                      Sign in
                                      Check!
                                      (thinking…)
                                      Reset
                                      or sign in with
                                      • facebook
                                      • google
                                        Password icon
                                        Signed in as (Sign out)
                                        You have left! (?) (thinking…)
                                        5 comments  ·  New Features  ·  Flag idea as inappropriate…  ·  Admin →
                                        Ingo Schommer commented  · 

                                        When I've built the WYISYWIG partial abstraction layer in HTMLEditorField.js for 3.0, I verified the approach through a second implementation of CKEditor: https://github.com/chillu/silverstripe-ckeditor. Its experimental and hasn't been tested in a while, but should give you a good handle on what's required to replace the editor, while retaining SilverStripe's custom link and media insertion.

                                      • 3 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  ·  New Features  ·  Flag idea as inappropriate…  ·  Admin →
                                          Ingo Schommer commented  · 

                                          Wow, that's an awesome library! Unfortunately its 107KB minified, which would make the CMS a lot heavier. Owen, is there a reason this would need to be in core? Have you tried incorporating it through a module? I'm happy to add extension points into the HtmlEditorField.js where required.

                                        • 0 votes
                                          Vote
                                          Sign in
                                          Check!
                                          (thinking…)
                                          Reset
                                          or sign in with
                                          • facebook
                                          • google
                                            Password icon
                                            Signed in as (Sign out)
                                            You have left! (?) (thinking…)
                                            2 comments  ·  New Features  ·  Flag idea as inappropriate…  ·  Admin →
                                            Ingo Schommer commented  · 

                                            Should this be transformed into a usability improvement of making the filter more obvious?

                                          ← Previous 1

                                          Feedback and Knowledge Base