We still have 217 matches for user_error() in the 4.0 core. Related Github issue: https://github.com/silverstripe/silverstripe-framework/issues/1915
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
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.
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.
Please subscribe to the Github issue: https://github.com/silverstripe/silverstripe-framework/issues/6202
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.
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”.
This has been replaced with https://silverstripe.uservoice.com/forums/251266-new-features/suggestions/16924327-graphql-api-support
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?
Pull requests towards this at https://github.com/silverstripe/silverstripe-framework/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aclosed+font+icon
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?
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.
Do you have an example of a framework with a large ecosystem built around SQL notation either switching to NoSQL, or building out their ORM abstraction to a level where both SQL and NoSQL are supported? Allowing custom drivers for *some* DataObjects is an interesting idea, although it'll be hard to keep the same ORM API, or a consistent schema definition around types and relationships. I think OrientDB is an interesting approach with a POC in SilverStripe: http://www.silverstripe.org/blog/no-more-joins-silverstripe-and-orientdb/. Interesting because it allows using SQL notation to power a less structured and more distributed schema.
SilverStripe have planned this item
SilverStripe have planned this item
I’ve broadened this idea from ATAG compliance to wider “accessibility compliance” in the CMS.
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,
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?
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.
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.
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.