Ingo Schommer

My feedback

  1. 14 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    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

  2. 4 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    started  ·  0 comments  ·  New Features  ·  Flag idea as inappropriate…  ·  Admin →
    Ingo Schommer shared this idea  · 
  3. 8 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  New Features  ·  Flag idea as inappropriate…  ·  Admin →
    Ingo Schommer shared this idea  · 
  4. 1 vote
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    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

  5. 32 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    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.

  6. 21 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    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.

  7. 20 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  New Features  ·  Flag idea as inappropriate…  ·  Admin →
  8. 2 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    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.

  9. 73 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    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. 10 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    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?

  11. 26 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    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. 12 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    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.

  13. 81 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    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  · 
  14. 35 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    10 comments  ·  New Features  ·  Flag idea as inappropriate…  ·  Admin →
    Ingo Schommer supported this idea  · 
  15. 21 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    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,

  16. 2 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    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?

  17. 13 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    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.

  18. 16 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    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.

  19. 3 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    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.

  20. 0 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    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