Epic: Modernise CMS UI Technologies #6689
Comments
chillu
changed the title
|
Not sure where else to leave this, but as a developer I'm finding it increasingly cumbersome to work with/around react in Silverstripe. The whole react 'ecosystem' is overkill for most of our own projects (for our front-ends the benefits are not worth the hassle) and we're usually (still) managing just fine with a mix of plain JS, jQuery and VueJS. I know Silverstripe has chosen to adapt react for the CMS/admin area and maybe I'm just getting old, but I find having to work with react in order to be able to make tweaks or PRs, quite a barrier (actually keeping me from contributing). Also it seems basic stuff like tag-field, password-field, toggle-composite-field, just to name a few, used to be way easier to use outside the admin area in non-react projects. I'm now finding myself having to re-create basic functionality which has been locked-into react, or having to update this functionality from older SS3 JS. It's also not as easy to lookup the JS and see how it works/how to tweak it in SS4 anymore, since only the minified JS is included. Of course the whole framework and also the admin has become a lot faster due to the react/preprocessing tools in use (besides general php improvements). But for us (tiny team), the most valuable USP of Silverstripe used to be its simplicity & extensibility - being able to add simple custom functionality easily, also within the admin area with stuff like betterbuttons. Currently it seems you first need to add/extend five different classes of PHP, install a set of blackbox preprocessors and languages and be a front- and back-end virtuous in order to use some react hooks just to tweak a few behaviours or add some functionality within react-based areas. Effectively it seems Silverstripe has become a much better/faster CMS, but the CMS & admin areas in exchange have become less easily tweakable and also less welcoming to starting web devs (IMO). This is meant as a signal, not necessarily as a complaint :-) |
|
I'd second that, @micschk. Well written. |
|
I agree with @micschk |
|
Agreed here too tbh. |
|
The discussion or the comment here say similar things about customizing the CMS: I really enjoy the CMS improvements but also agree with both posts in regards of customizing the CMS. |
|
This is not meant to insult anyone, and I appreciate the hard work a lot of devs are putting into Silverstripe, as well as Silverstripe the company making it all available open source. But long story short; for us as a small development company, Silverstripe is currently losing some its strongest selling points. For client-businesses the best aspects of Silverstripe used to be its stability (tech stack wise) and the relative simplicity to develop valuable functionality for clients on top of the framework & CMS. It's currently becoming more and more of a burden to maintain existing client projects for us as the technology stack seems to keep growing and existing projects needs reworking over and over between updates. For example we recently got budget to update a client project to v4, only for it to need work yet again within a few weeks after finishing because some components/module having switched over to GraphQL/react. Details spared, but this situation is very hard if not impossible to justify to a client which I have just convinced to do the initial update so the system would be future proof again for a couple of years. Another example I recently came across is a (much appreciated) writedown by Adrian of the steps required to create a module for a combined text input + dropdown field. I cannot help but think something basic like this should never be that much work/involve that much coding languages and could actually be accomplished in only a few lines of php, one template file and maybe some JS in previous versions of Silverstripe? I have spoken to a few developers about this and it seems this sentiment may be shared. Personally, business-wise I feel it would almost seem feasible to create a "community fork" of SSv3 as feature wise not so much has changed since then (not to say V4 isn't better in a lot of areas, but from the perspective of a client they can manage their content equally well in V3 and I can sure develop a lot faster on top of it). Just look at the amount of "meta" files recommended to include in a basic module (from module skeleton). I'm afraid this is undoable and unmaintainable at least for us. And this doesn't even consider the front-end preprocessors etc required... I've made this comment on the forum here and there as well, but I'd be very interested in an assessment by Silverstripe, of the amount of time/work actually spent on converting everything to react over the past years (including the all the GraphQL stuff). I doubt it still warrants the anticipated benefits (not sure what these actually are/were other than just replacing Entwine), and we're only even half way done. Besides that, I hope for other (community) devs to chime in on these issues... |
|
@micschk I tend to agree with you. Some things that used to be easy in SS3 are more difficult in SS4. For me, there was not much added value in the new paradigm. I don't like react or graphql, and as a php dev, I don't like to have to bundle, build and process js files. However, it's still possible to use "old ways" in the admin side once you tweak things a little. For instance on my base module, I've built a simple (and a bit hacky) jquery plugin that is in charge to apply jquery module to a given html node (https://github.com/lekoala/silverstripe-base/blob/master/javascript/ModularBehaviour.js). It's basically what powers all my custom form fields (like select2, cleave, inputmask) and, as a added bonus, it's usable on the frontend as well :-) My main grief is that developping things for the admin side is most of the time not applicable on the frontend and vice versa. At least with my method, I can have one code that apply everywhere. Of course, I'm locked with my current technology but since that's my methodology I'm happy with it. I also believe that it would be nice to have some work done on a community fork of ss3, i have some big projects that are just too big to migrate so for me it would make sense to improve things on the SS3 side of things as well. I still hope that it would be possible to FINALLY upgrade jquery since it's super easy to do and only require dropping IE which is acceptable these days. |
|
In terms of why we’re moving away from Entwine and jQuery, @micschk described that pretty well above. Performance, security, maintainability (yes React is complex, but Entwine is a black box that hasn’t been updated for 5 years) and extensibility all factored into that decision. I think everyone would accept that something had to change, so then it comes down to choosing a tech stack. Given the complex UIs in Silverstripe, we needed a modern component-driven library with some beefy state management: React & Redux fit that description perfectly and have enabled some brilliant new functionality since. Yes there are alternative libraries, but without going through the same (very long) journey with them we’ll never know if they’d make these problems better or worse, or introduce their own problems.
Yeah we’re in the same boat - VueJS + GraphQL is as complex as our projects really get with regards to frontend stuff. That’s probably part of the reason React can be off-putting for contributions: we basically never use it in our projects, so it’s unfamiliar, and to then jump into a really complex React app like the CMS to make a “simple” change/fix is difficult.
Sorry that you’ve had that experience, but for balance I would like to say that our experience of updates has been very smooth ever since semantic versioning was introduced. I haven’t seen many complaints about updates breaking things, so hopefully that experience was an unfortunate one-off!
That’s partly because we’re still in the awkward position of being part-React rendered, part server-side rendered. You need a PHP file for field scaffolding and a React component - ideally that would be all you need to build a CMS UI component. Right now the
I disagree - I think we’re still only seeing some of the benefits of the newer UI technologies. Compare the old assets section to asset-admin for example, or the old elemental to the current one: if we see the same sort of improvements across the board in the CMS, I think we’ll be very happy.
I’ve recently become increasingly happy to accept modules that only work in one context: otherwise you end up with, for example, form fields that load a legacy version of jQuery and Entwine into my otherwise nicely optimised site. Ultimately as the CMS moves over to be more and more React powered, I wonder if we’ll see modules diverging into CMS-only modules and frontend modules? We’re in an awkward place where being partly React-driven and partly Entwine-driven makes development & customisation of CMS components more difficult than it needs to be. All the while Entwine is lingering in the CMS, people with existing Entwine-compatible modules will likely do the bare minimum to get them working and then leave them. I know that, because that’s exactly what I’ve done with some of my modules! I think we need to focus on finding specific issues devs are having when writing React code and see what can be done do to improve them. |
|
@kinglozzer to your last point about where devs are having issues. Here's a couple off the top of my head:
Just a couple thoughts off the top of my head. I know when I started working with react for stuff like webbuilders-group/silverstripe-add-to-campaigns it was hard to get my head around things based on the docs. |
I do not disagree with this, it is absolutely a fact that Entwine has become the primary "Technical debt" in Silverstripe. However, although I obviously never had any input in the choice to use React for the CMS, I have found that a lot of web agencies are starting to shy away from Silverstripe, because of this decision. The reason being, is that the easy way it was to add, change or update fields, as described by @micschk , has become a burden. One of my last jobs as a fulltime web engineer, was upgrade a very complex CMS build, to Silverstripe 4. The change to use React, the renewed search field implementation, and the general changes that came with it, were so complex, that I am at this stage unsure if the project ever finished due to this complexity. With VueJS, Vanilla JS, Angular JS, Backbone JS and of course jQuery, even engineers that used to primarily do PHP/backend things, now had to learn 2 or 3 new javascript frameworks, only to be able to a simple task of a customised field. for example, fields that rely on jQuery to function (for example Select2), then possibly a React component to actually show the field, and of course the PHP backend to render the field template. This has become a behemoth of requirements for a simple task. (As per Adrian's post) Another issue I have with React, is it's complexity. I have worked with VueJS, Angular, Backbone, jQuery and Vanilla JS, but never have I found a library so complex as React. I am personally not a frontend expert (really, don't ask me to do a pure design/UI project! :P ), but the time it took me to understand the basics of the libraries mentioned, was a lot less than when I even touched React. As I am not a software engineer anymore, I do not even want to touch React on any hobby project I have. If needed, I'd rather hack myself around it, than needing to learn React. It's not worth my time. I absolutely agree, that a single library, with a consistent implementation in the CMS is a good thing, but the benefits of React, to me, do not outweigh the amount of overhead it brings to the people that have to work on custom Silverstripe CMS implementations. It is however, at a massive cost to the community. When it comes to the usage of javascript, I've learned a motto from one of my former colleagues, Jess: In part, this is also due to the javascript ecosystem, and the amount of libraries out there. And I'm not even kidding, BananaJS exists. The javascript ecosystem is so volatile and constantly changing, it has become impossible to keep up with. // More to come |
|
Awesome discussion. Thank you all for your ideas and candid sharing of highs and lows. I don't have anything important to add, but would like to add a few notes in case it helps anyone. Also, I think we should add @unclecheese and @chillu to the discussion. In order for Silverstripe to survive we need to: A. Tap into the rich tapestry of PHP packages - hence SS4 has namespacing and we use composer. B. Tap into a rich front-end framework, like ReactJS. C. Get better at creating and finding existing modules (we are doing our bit with http://ssmods.com). This takes us away from the lovely ecosystem that was SS3 where you understood almost everything under the hood and you could tinker to your heart’s content. However, I don't think that is viable anymore as we would simply end up more and more behind. Believe me, I totally understand the frustration of being thrown into these giant systems and feeling utterly lost. I do too! But going back to SS3 definitely seems like a bad decision. Secondly, for better or worse, ReactJS has been selected as the front-end framework of choice. I have never written a line of ReactJS in my life, but my team has and I generally get a sense it is a good choice. It could have been worse! It is more how we use it that is the issue I feel than React as such. Also, when I look at shopify, they are super proud of having a GraphQL Api - and so should we. Let’s make it fly!. Next steps, as I see them:
If there is any CMS that does this better than Silverstripe? If so, how can we make use of their ideas and code? A couple of things I would like to improve, with a magic wand While we are talking about the CMS, here are few things I would love to see in the CMS. I think it may be of use here as I am curious if any of you see this differently and what else may be important, in order to consider how “new” / “old” ways of doing things may help us get there.
a. editor reviews front-end The disconnect between the front-end and back-end is a big issue I feel.
Our involvement with creating a custom CMS experience We have not been involved much in making anything for the CMS itself. It is basically too hard for me. Even in SS3 this was hard. Sure, we have created lots of CMS fields, of all variations, but doing anything else often ended up in the too hard basket. The main issues we found:
What we often end up doing is to create custom front-end solutions for editing custom stuff - e.g. prices per country for e-commerce (stuff that should really be done in the CMS) and simply linking to it from the CMS. Unfortunately, while the individual things may have worked, this does not look very professional for the client - i.e. having the same look and feel as the CMS makes it feel more connected. Having said that, a few months ago, I wrote my first Left And Main, ever, and it turned out to work really nicely and be simpler than I thought. I could not find any good documentation, but I simply copied another Left And Main and worked it out: https://github.com/sunnysideup/silverstripe-site-wide-search. Examples of other things we have done to make the CMS better:
None of these are very serious changes and I feel the reason we have not delved deeper into it is because we assume it is too hard, based on the few forays we have had into the deeper layers of the CMS. What may also be of use: Also, what I found weird is that each project and every module has its own webpack. Hence I developed an independent webpack module: https://github.com/sunnysideup/silverstripe-sswebpack_engine_only. The way it works is that it separates webpack from individual projects and modules. It needs work, but I like where it is going. We basically have one webpack that is simple and works, we take it from project to project and improve it as we go (and back-port those improvements to previous projects). Yes - you can still add your own vendor modules as you see fit, etc… Also, we keep working on our SS4 upgrade module: https://github.com/sunnysideup/silverstripe-upgrade_to_silverstripe_4 and I would really encourage anyone to reach out if you want to use it. It makes upgrading less costly. Lastly, I have been working on this module: https://github.com/sunnysideup/silverstripe-modulechecks. It is in a complete mess, but my long-term goal is to have some sort of automation to keep our modules up to date. It will work in conjunction with https://github.com/silverstripe/silverstripe-module. |
|
These days my work focus switched to more to Laravel, I'm still a big fan tho :) I think, most here agree that we seeing strong improvements with v4 and addressing the tech debt is due. No doubt it's a big move forward and should be kept in mind as this. Change is never painfree and I can relate to many of the feelings shared above: I can relate to @Firesphere' thoughts on React tho. Sure, it might be your natural choose if you know React and the large ecosystem well. Otherwise maybe less so (due to learn curve, complexity, etc.). At the end, most of us start to see everything as nails to some degree. It's part of human nature to develop preferences. I wonder how many SilverStripe devs saw React as a suitable solution for a website when v3 was at it's peak? My gut feeling tells me it wasn't that many. I still see jQuery regularly. My work is mostly with Vue (and Alpine for simple websites) these days. For me personally, I wouldn't pick React for most sites as it doesn't feel like a good choice for the regular "bunch of pages with three forms and a newsletter modal"-type of website. The introduction of React moved the SilverStripe community into a new direction. For some people it might have got more attractive and for some less. That's what any large change does. I think devs who choose jQuery/VanillaJS/Alpine/Vue "to do something quickly" on the frontend won't be starting to learn React. I'm in the same boat as @Firesphere here. From a purely technology-based point of view: Is SilverStripe more attractive for React developers now or is the community benefiting otherwise (more reach or external contributions)? I can't speak about community benefits as I don't know enough about this. A biased feeling regarding this: I feel React devs are more deeply rooted in the JS space (than for example Vue/Alpine devs) and less inclined to use a PHP-based framework/CMS. If holds true, it probably limits the benefits for SS. How to deal with this? Well, I don't think there is an easy answer. But here are some thoughts: Laravel takes an interesting approach. It's coming with Laravel Mix - a wrapper around webpack which allows you to isolate the JS world somewhat and giving you a simple helper to handle and extend frontend. Maybe this is an idea to help smoothing the rough egdes of JS world for SilverStripe devs? I follows the idea just minutes ago posted by @sunnysideup. I'm not sure a community fork of v3 would get more than the bare minimum of security fixes. Even these would fade out at the end. Plus the same core issue remains: Entwine is unmaintained. So sooner or later it would have solve the same problem the main project already works on. It would have the free choice of options tho and maybe could address issue differently. So much for my two cents. |
|
While I haven't built any new SilverStripe projects for quite some time now, I still do maintenance and support for several of my previous projects (SS3 and SS4 based). Personally, I've always liked the roadmap that SilverStripe took for SS4 and onwards. Being more modular and using a modern frontend stack. I have made the switch from SS3 to SS4 while I was still working as a self-employed developer, doing everything alone. I agree with the sentiment that it was quite a big leap from SS3 to SS4… some things seemed very familiar, others have changed completely. Most notably the new frontend stack. That means, that it also resulted in an increased learning-curve, especially if you had to customize frontend and backend components (for example as a module maintainer). I was always invested in frontend technology, that's why I already gathered some React and Webpack experience, before SS4 was a thing (building a React driven frontend with an SS3 backend). Maybe that eased the transition a bit for me… I still believe SilverStripe is on the right track. While it might be harder for a single person to tap into all the different areas of the CMS, it also gained a lot in terms of maturity. I personally prefer a clearly defined frontend-stack based on a framework that has a huge user-base and ecosystem (React) over some self-built wrapper where every module can load/include any code it wants. I personally believe that we'll see a lot more headless systems and sites built with JAMStack in the future and I'd much rather use SS4 than SS3 for that… |
|
I agree with the above, I'm not that familiar with React and don't use it on my projects but I understand the reasons behind choosing it for the CMS. I think we're mostly just missing documentation, examples and tutorials to make it easier for those devs to get familiar with how SS uses these technologies. Overall, I still love SilverStripe and where SS4 is going and really look forward to the GraphQL updates and speed improvements that are being worked on. 💌 |
|
Personally I do not use (or even like working with) React, however I understand the reasoning for choosing a solution like this to modernise the CMS. The Silverstripe 4 CMS is in my opinion a huge visual improvement compared to v3. It has however come at a technical cost, that being the push for module developers to use React, and adding a complexity in just getting stuff done for developers (as pointed out in earlier discussions). The documentation regarding this is also all over the place, and still promotes "jQuery, jQuery UI and jQuery.entwine: Our libraries of choice" together with multiple jQuery & entwine examples, so this remains confusing. I'm not particularity a fan of jQuery, but it's simple to use and functional, and more importantly universally understood. Knowing where the CMS is headed has meant that I have shied away from creating things in the CMS that may need custom JS, and for where I absolutely need it, I still continue to use the jQuery.entwine method to fire events when the CMS section is loaded (ie: So from my perspective, ripping out entwine is fine (if it is such a technical debt), as long as there is an alternate method provided for module developers to hook in regular (non-React) JavaScript functionality into the CMS, triggered when a "React-loaded page" finishes loading. My impression (correct me if I am wrong) is that the intention is to shift everything (in the CMS) to a React-only environment, and if this is true, it is potentially going to hamstring a lot of developers such as myself. I am sure that React has made Silverstripe's life easier in achieving consistency (and speed?) throughout the CMS, however React is not simple to learn, and in my opinion not simple to implement. As a developer I want to create a CMS module, and if it requires some additional functionality, add that functionality inside a simple readable JavaScript file if I choose to. I do not want to have to deal with complete libraries, create components, set props, inject other stuff, compile bundles in node and whatnot, all to simply display a simple character counter next to an input field. My apologies if my terminology is off, but you get the picture. The CMS needs to remain flexible enough for developers to hook in other JavaScript into the ecosystem. |
|
I don't think React is inherently hard to learn/understand. Sure, it's a bit more involving when it comes to state-management and especially tooling. |
I'd argue for anyone coming from a vanilla JS/jQuery standpoint, anything that requires a build system is indeed hard to learn and/or understand. My big takeaway from managing elements within the CMS is the amount of cruft I need to write within the PHP side of my models is just a tad confusing and not easily debuggable when you're needing to work out how the CMS objects relate internally to each other. e.g. an example of modifying the content/fields in the list page for a model: Extension w/ updateEditForm method calling this -- |
|
Very happy this discussion is gaining some traction! One point I notice is that the arguments pro React (& ecosystem) seem to be based on some combination of:
But comparable improvements in UI-consistency and loading & rendering speed have been achieved in (currently still) non-react areas of the CMS. Therefore I argue that these improvements are not inherently linked to react/interaction technologies but rather have to do with visual consistency and expectations (UI - if any 'tech', I'd credit Bootstrap for this). And (loading & rendering) speed for a large part to general framework improvements. Point being I hope we can separate UI & speed (huge improvement requiring no discussion at all), from the front-end technology stack replacing Entwine. I think a lot of pro-react arguments either; take react (& co) as a given and try to 'fix' some detail (documentation, error messages, some toolchain detail), or consider react simply a neutral/necessary replacement of Entwine. Instead, I'm hoping for Silverstripe company to take a step back/zoom out, re-evaluate this choice and consider the broader implications of this tech stack. Mainly because I think some (imo much more important) strategic implications are being underestimated (eg ROI/business-wise and developer adoption/community):
Personal preferences (of course) play a role in this discussion. React for me is something I simply do not want to invest in for the reason it introduces too much overhead and complexity. And to devs arguing React is not that complex, thank you for overestimating me but it is to me (at least for the purpose of just being able to customise Silverstripe). That being said, I feel/hope the arguments above, as well as the discussion in general go beyond personal preferences and/or technical fancyness. |
|
I just want to jump in on the point of loosing the ability to use some of the more complex fields on the front end. I've had the pleasure of trying to make them work outside the cms and I've got to say it's a pain. It does suck to have to either fight with trying to get the core js bundles to work on the front end to the point that in some cases either I end up looking for an alternative or rolling my own. In the case of webbuilders-group/silverstripe-frontendgridfield by default it uses the old jquery code from silverstripe 3 and removes the new filter component. It has the option of using the new react bindings but it's allot of hacks basically to get it working. The flexibility of using fields on the front end that can also be used in the back end I would say is probably essential. Yes fields like grid field are very rarely used on the front end but not never and they do sever a purpose in some projects. |
|
The great, unopinionated flexibilty of SS hits us here: there is no standard way how to do your frontend stuff and for smaller sites I don't care how the backend is knitted unless it works flawlessly as I do all basic frontend fields myself or rely on standard HTML form fields. I wonder, if the field's javascript could be so modular, that you can use it with react in the backend and with the js framework of your choice in the frontend? So that the main logic is encapsulated in js-framework agnostic code and the integration is done in glue code. Could webcomponents be a possible solution? I've seen some calendars or sliders (well, that are not form fields) that work either standalone vanilla or with a bunch of different js libraries. |
|
As a developer who tries to avoid the JS side of the SilverStripe admin I share some of the frustrations expressed here. Rather than weigh in on what JS tech I think should be used I'll say that in some cases I wish that the UI was less dependent on JS. I feel like a lot of my pain points with the platform come from CMS interfaces that seem more complex than they need to be. There are a fair number of frustrating issues I run into where the CMS seems to be working if you fully refresh a page, but if you navigate to the same place without a page load things are broken, or in an odd state. Things like, the published state of a view, or content of a relationship field not displaying correctly after a save until you refresh the page. Sometimes I wish I could just force a refresh on save/publish. Other times it just feels as if different pieces of JS are fighting each other. Problems like trying to get a field to work in an inline GridField editor, or inline editable Elemental block. Or some weird cases where fields seem to break in some ModelAdmin views. I hope a more standardized approach to CMS JS would resolve some of this but I also hope that such an approach leaves room for CMS views not to be entirely dependent on JS to render. |
|
On the choice to use React: I would say you can't build a modern, complex CMS without some kind of stateful library (React doesn't like being called a framework 🙄) like React. When I started using React it was a big paradigm shift for me - the possibilities it opens up for front end application development are amazing. React is a low-level library compared to other options which are more opinionated / batteries included. That probably does make it harder for new devs to learn, but it also means the greatest flexibility for core devs. Long-term community health: Embracing GraphQL (and a modern tech stack in general) can make Silverstripe a viable contender as a headless CMS. Silverstripe has enjoyed a loyal following to date, but the community is relatively small and without the support of Silverstripe Ltd the product would have died (or gone stale at least) long ago. Unfortunately all the issues outlined here may be making the community shrink in the short term but I think Silverstripe is on the right path to ensure the project stays relevant and attract a new and wider developer audience in the future. Dual-use front-end/CMS fields: As @kinglozzer said - the CMS and the front-end of your website (or whatever you are building) are different beasts, especially as the CMS becomes more modern. Reusing CMS components in the front-end could work for a React-powered website, but otherwise I don't think it's realistic in most cases. Even in SS3 days, this dual-use could mean multiple copies of jQuery loaded, or other javascript overhead, potential for conflicts, security issues etc. - basically, an un-optimised stack. React learning curve: A lot of devs are saying they don't want to learn React just to customise the CMS. I totally get that, it takes a lot of effort to learn React. Silverstripe has a great community though, and maybe that's one part of your work you can outsource to another community member? I for one would consider focusing on this as a niche if there was demand for it 🙂. I would imagine that once you've outsourced a couple of jobs like that, you could repurpose that code on your own when you have similar requirements, and end up learning React accidentally. Other:
That would be awesome as an additional customisation option. If the CMS was broken in to micro-components wherever possible, that would be an easy way to make basic changes.
IMO, these are state issues, and these should be a thing of the past when the whole CMS is React-based. The basic premise of React is that whenever your state changes, any parts of your app that rely on that state are re-rendered, so as long as the CMS is aware that the state has changed, these issues shouldn't exist in a 100% React CMS. That said, I have experienced some issues like this even in the new assets-admin area (e.g. thumbnails not showing a published status after publishing in the detail form), but that is hopefully just an oversight that can be fixed easily. |
|
Thanks to everyone who has contributed to this discussion - possibly the most lively thread we've had in the ecosystem since Silverstripe CMS 4 launched! The team at Silverstripe Ltd. are reviewing the feedback here, and I'd just like to share a few specific notes. StabilitySam has talked about this on multiple occasions, mostly recently at StripeCon 2020, which I'd encourage everyone here to watch if they haven't already. In short, we're really conscious that the CMS 4 upgrade cycle was tough on projects, and based on this we're looking to avoid significant breakages in 4.x upgrades going forwards. There will be some cases where we can't avoid this entirely (one example being the upcoming transition from GraphQL 3 to 4 - more detail coming early next year), but there are some changes we're pretty much ruling out in the CMS Recipe 4.x lifecycle, which doesn't currently have an end date:
This doesn't preclude the introduction of experimental replacements for CMS features that are currently based on these technologies, but those experiments wouldn't be included in CMS Recipe 4.x releases. This does mean we'll continue to retain and accrue technical debt throughout the lifecycle, but the trade-off to minimise upgrade woes has been deemed worthwhile at this stage. We encourage module developers to use the Entwine wrapper pattern to make their components compatible with both Entwine and React UIs where possible. DocumentationThe docs for the modern front-end stack are fairly monolithic, and haven't been significantly changed since their introduction. This is something we're all acutely aware of and want to see improved, and I don't think it's bold to suggest that more approachable docs would measurably improve developers' perception and adoption of this technology. Ultimately it comes down to capacity, and when it comes to prioritisation for the Silverstripe Ltd. team, fixing bugs nearly always outweighs improving docs. It'd be awesome to see some community contributions in this space, but we'd also like to try and tackle this internally at some point (ideally before we complete the React migration!) MigrationWe've been in the 'midst' of the migration from Entwine to React for the lifetime of CMS 4, and there hasn't been much in the way of visible progress in the past year or two. To be clear, we still intend to complete this migration in the long term, and React is still the basis of our development. Introducing yet another technology, or trying to roll back to Entwine, would simply result in further fragmentation of the codebase and major toil for contributors / module developers. Using CMS components in front-end contextsWhilst this pattern may have been usable in CMS 3, it's not something we have the capacity or inclination to support at this stage. Silverstripe CMS is shifting towards the 'Headless CMS' paradigm that many other projects have adopted in recent times, and whilst we have no plans to drop support for SSViewer, our focus is primarily on providing a solid CMS experience and exposing a powerful GraphQL API for projects to consume content through. It's worth noting that we have seen some success in re-use of the React components within the MFA module suite for producing a custom UI implementation, though these components are isolated from the rest of the core React suite. Build toolingThis is a common pain point for developers picking up the modern front-end stack. I'd like to share something we've worked on to try and minimise this pain: the module skeleton. The module skeleton repository is configured as a GitHub template, so you can generate a fresh module with only a couple of clicks, and get all of the standard configuration, build tooling, and structure laid out for you to build upon. It does need a bit of TLC, as we've shipped some updates to webpack-config over the past year, but it should still give you a functioning base to start from (and if you hit any bugs, please raise an issue.) This doesn't cover projects and existing modules trying to adopt the modern front-end stack to customise the CMS, and unfortunately we don't have a good answer for them at this stage beyond "reference the module skeleton to set up build tools." As a general rule, I'd strongly recommend keeping the CMS build tooling separate from the tooling you use in your project themes, in order to avoid any interference when one or the other needs to be updated. Generally speaking, unless your module needs to modify or use newly introduced JS components, you don't need to keep the build tools updated on a regular basis - the patterns we use here allow general interop between JS bundles that have been built against different minor versions. There are exceptions, though. At some point soon we'll need to upgrade from Webpack 2 to Webpack 5, which will definitely cause some headaches for module maintainers. For better and for worse, this sort of major change reflects the cycle of the JS ecosystem. We update these libraries at a significantly slower pace than the ecosystem itself runs, for the sake of minimising maintenance effort / frequency for all involved parties. However, particularly in the case of such a major underpinning as Webpack, such upgrade cycles are inevitable. As with other changes, we'll do our best to provide an upgrade path / guide during this transition - best case scenario, modules using Laravel Mix has been mentioned in this thread, as an example of abstracting away the underlying tools for a simpler build tooling API. Our solution in this area has been the afore-mentioned I'd like to end this with another shout out to everyone contributing to this discussion! Whilst I don't think tagging every visible member of the community to get their input is a sustainable pattern, it has definitely sparked some great feedback that has been brewing for a while. We'll continue watching this thread for further thoughts and ideas in these areas. We can't make hard commitments to address many of the items raised here in the short term, but please take this as acknowledgement of them by the Silverstripe Ltd. team, and as a challenge to chip in where you can. It's important to recognise that Silverstripe CMS is an Open Source project with several orders of magnitude less commercial resources than competitors like Drupal and Wordpress. As the age-old adage goes: PRs welcome! |
|
Some feedback on your comments @Cheddam : TL;DR: I think with all the changes, the Product team has lost sight of what the actual devs using Silverstripe would like to see.
I beg to differ here. You are not "retaining technical debt", if you keep these features alive. These features are what made the Silverstripe CMS such a great way to start a new project. However, by removing them, you are introducing a massive migration path and technical debt for your end developers. I'm curious if this has been of any consideration? It seems the way you folks have chosen to go is "Remove any bit of technical debt, regardless of the people that use our product",
Isn't that then a new major release? Breaking things should not happen in minor releases, I think?
Although I agree and understand this is a target, it is excluding a large group of developers that "just want something". Headless is great, don't get me wrong, but far from every website would need something like a headless approach. It's pretty awesome and useful, actually. But when it comes to a plain website, no fancy mobile app etc., it's quite pointless. The previous use of CMS elements in the frontend, especially on forms, was super, because it required less work on the frontend to get things going.
Although the MFA Module is, in fact a module on its own, it is not something that developers of client website can turn to, to get help. It's still quite a complex beast. It is not a useful example on how to do things, I believe.
That is the worst take, to me. A maintainer ending with "PR welcome", in my view, means "I can't be bothered to do this, but if you are willing to spend your time on it, go ahead", which, commonly, is followed by months and months and months of nothing happening (with either the PR or project progress regarding the comment). I have more comments, but it's also the weekend, so these are my main concerns 😸 |
|
Well at this point I feel I'll chuck in my 2 cents. However valuable that is these days. Tech stackPersonally I have always thought the choice to use react wasn't the best decision as it forced to write react ecosystem. I remember discussing with SS developers early on during a SS community meetup. Particularly about using react over vuejs and the only point of difference that react was built by facebook. Which wasn't a satifactory answer for me. Take the simple character counter next to a field example. Using vuejs inline templating with ssviewer you could simply update the FormField.ss to somethiing along the lines of the following. <input $AttributesHTML('class') class="form-control $extraClass" <% include SilverStripe/Forms/AriaAttributes %> />
<small>Character count: {{ props.value.length }}</small>The above is theoretically possible as I have done something similar on a recent project view-source:https://www.landcareresearch.co.nz/tools-and-resources/identification/what-is-this-bug/ (line 1020). I used a mix of ss and vuejs inline templating to apply filtering. This approach could satisfy developers that need to create quick changes to UI for small projects and heck it would even work for react developers because you can initialize react components in vuejs. On the note of creating a "community fork", the only fork I would like to see developed is a vuejs fork of silverstripe-admin. It makes sense when you look at alternative frameworks such as laravel which have multiple cms options available, both paid and community driven (It encourages healthy competition). Laravel Mix
If it helps I had worked on a proof of concept for silverstripe-mix that could still work if Dual-use front-end/CMS fieldsI agree with everything @jonom has said on this point and add that regardless of framework, thought it was bad practice. |
|
Hey, everyone. Good discussion. I'm going to weigh in a bit here. No forking wayCan we just bury this idea of making a community fork? Look, I get the spirit of it -- it's an open source product and we're all afforded boundless opportunity to pilot it where we wish, but there's also a common obligation we have to the larger community to do what will provide the most benefit. The prospect of fragmenting the already incalculably scarce resources we have contributing to Silverstripe CMS seems like a recipe for failure, frustration and conflict to me. A community fork has some really depressing implications in my mind, including:
It seems to me if telling the core to get forked is the answer, we're probably asking the wrong question. Over-ReactionsThe increasing use of React in the UI has caused a lot of toil and frustration, and I think we all understand that, while and no one ever said it would be easy and painless, we also didn't think it would be this hard. However, I think there's some context missing around the genesis of that technical pathway. This was decided many, many years ago, in 2015, when React really had yet to prove itself. It was a huge bet at the time, and we went with the best information we had, because we knew as well as anyone that you only really get one shot at this. It's years before you get a permission structure to do another massive change. I think it's fair to say that we grossly underestimated how difficult it would be to maintain Entwine and React in parallel, and also how much effort would be required to propagate React to the entire CMS. But with all that said, the questions around "why not Vue" and "did devs really want this" are kind of anachronistic. It's important we keep in mind the timeline of how this all played out, because it wasn't recent history. It's easy to critique this decision with five years of hindsight and a vast amount of new information, but that same hindsight and information also gives us a lot of reason to praise that decision. React ended up being everything we thought it would be, and probably a lot more, and as some have pointed out, we've positioned ourselves very strategically for the future. Let's not lose sight of that. Migrate(est) WeaknessLook, I think we're victims of our own success, here. The value proposition of Silverstripe CMS is basically that you can build out set of data models that closely align to your business requirements, you get a decent administrative UI with little effort, and customisation is done intuitively with PHP code and modules. So while that is what people love about Silverstripe CMS (generally speaking), what people don't like about Silverstripe CMS (generally speaking) is that it's slow and lacks a modern UI. These two conditions, in my mind, are at odds with each other, and we can't solve one without giving up some of the other. The way we're going to make the CMS faster and more modernised is through proven tooling (React/GraphQL) that we happen to already be invested in. It goes without saying that this makes extensibility much, much harder and admittedly less possible overall. There is no easy way to make this transition. We tried going halfway in to minimise the pain, but it's just made it more costly. The future of customisation in Silverstripe CMS is probably going to be through javascript, and more specifically, through React. That's just something we're going to have to get comfortable with, and it's probably not productive to challenge those assumptions at this point given the relative value of actually figuring out how we're going to implement those assumptions. There is no CMS that I'm aware of that runs in the client and also offers Silverstripe's level of customisation. There's a good reason for that. We're trying to bridge a massive gap that would be largely unprecedented, and it's not going to get done without some sacrifices to either side of that equation. Upgraders of the Lost ArkUpgrades are certainly difficult, and I can relate to all of the frustration around it, especially when trying to get clients to pay for it, but simple upgrades are also quite costly as well. A simple upgrade path hamstrings what we can do in the next release, making your clients less likely to want to pay for the upgrade. Additionally, codemod tools are extremely expensive to create and are far from perfect. Just to put that into perspective, if we skipped the upgrader tool for SS4 all together, and just said, "here's some docs.. you're on your own", we would have recovered enough dev weeks to do many of the other things of value in this thread, including, probably, rip out Entwine entirely. In my experience, most upgrades were done in the context of full site rebuilds anyway, so I'm a bit skeptical of the value of easy upgrading relative to its costs. I think we had a golden age of customisation in Silverstripe that is probably coming to an end as the paradigms we benefitted from for so long are shifting away from us, and I think the discussion needs to be focused on how we're going to adapt to that rather than whether we should at all. Change is hard, but we can do it. We got the damn thing to run on IIS, after all. ...we did, didn't we? |
All of these people are super smart, but I wonder in all of that brain power something was lost. We have a great CMS here, but the smartest people working on the CMS can not create a list of editable records (basically the core of the CMS, together with the SiteTree and HTML Editor). This raises serious concerns about the approach and the whole project. To me this idea of having half the CMS in React and the other half in jQuery and Entwine is fundamentally flawed. Surely, by itself making an editable list in React has been done before and should not be hard (if this is hard then React is not what it is supposed to be). Is this one of those situations where, in hindsight, starting from scratch would have been much easier and faster? Can we still do that (copying across what works). |
The complexity is not around how to make the React component, it's around how to build it in such a way where you don't lose the configurability of the PHP APIs for GridField while retaining the benefits of a React powered UI. We've been through the process of making |
|
Ok - so the hard part is that devs configure in PHP and that, like for like, React needs to know about that? I wonder if there would be value in a closer mapping of PHP config / models setup and React components, or is exactly trying to do this that causes all the headaches? |
|
In short, yes. The complexity of this mapping increases with the complexity of the field / component it's trying to drive - which is part of why GridField is so difficult to port, with its massive API surface. A pared-back version would be more achievable, but would lose a lot of the flexibility developers appreciate it for (and would impact the roll out across core, modules, and projects that make use of the missing parts.) |
|
I know there are probably a few forbidden words here.... but has anyone taken the time to take a look at how Advanced Custom Fields Pro handles Wordpress + Gutenberg? They allow Gutenberg blocks that typically are React (I think) can be created through very simple PHP code... |
|
It's been ages since I looked at that module, but from what I remember, it's a very denormalised schema. They basically have @chillu and I were actually chatting about this today. Maybe the path forward is to admit defeat and just accept that our implementation of graphql will be denormalised (it already is in Elemental Editor). 🤷♂️ |
You're right there. It's a long time since I worked on a WP project and as much as the schema is a pain and I prefer Silverstripe's ORM, the editing experience of Gutenberg is pretty impressive. edit: just wanted to add, I hope all of this discussion doesn't feel too negative or that the community isn't appreciative of all the work that SS put into the project. I do love the CMS and just hope that the input here helps. |
I sure hope not. The ORM and DB structure in SilverStripe are some of my favourite things about it.
We still do some WordPress work at our shop, and we usually disable Gutenberg. It just doesn't work if you wan't any sort of relational, or shared data. Just a very slick rich text editor you're meant to dump a whole page's content into. Even though the db schema is still bad, at least custom fields allow some structure and relationships on your fields. You can build a faux ORM around custom fields and custom post types and still build something rather complex. We've built an internal toolset to allow us to create something like Elemental blocks, and it deliberately avoids using Gutenberg. I see the appeal to Gutenberg for light brochurewear or blogs with minimal involvement from devs, but I see my job as delivering something more robust than that and that's why if given a choice I'm going to choose a platform like SilverStripe to do it. |
|
A bit late to the party, but I felt that all the complaints I would come up with have already been voiced. However, I've now trying to migrating my existing modules to the new react stack and within the first minute found 2 "major" bugs that basically make module development impossible for any but the most seasoned SilverStripe developers (or am I just really bad at this or have a edgecase setup?) silverstripe/vendor-plugin#34 If the mechanics for developing a module and the module starter template (skeleton) are both not working out of the box, we can kiss a healthy module eco-system goodby. The skeleton idea is great and definitely needed. But I think we need to make absolutely sure that things like that are well maintained and actually work. |
|
A bit off-topic, but perhaps relevant: @unclecheese at al. - you may look at this: https://github.com/sunnysideup/silverstripe-sswebpack_engine_only. This is a standard webpack that, in theory, could run with any module. I have used it successfully on a number of client projects and it works really well for us. In practice, rather than maintaining a ton of webpack installations, we just use one standard webpack install that can be used to compile any silverstripe project, while still allowing for any npm libraries to be included. |
Today would be a good day for this... This past week I've (amongst other things) struggled with trying to make two community modules work in SS4; my own cropping addon to focuspoint, and the Shortcodable module. Shouldn't be very difficult I figured, those guys said React isn't too hard... Oh well. Shortcodable FocusPointCropper OK, so back to Shortcodable then
Turns out this seemingly tiny & simple bit of functionality involves:
Since in the old days almost everything was better, I couldn't resist comparing this to the SS3 era code. Alas there was no embed button 'back then' so I looked at the 'insert link' button:
So less lines of code is better? I feel Silverstripe has spent the past ~5 years rebuilding the framework & CMS in a more modern way and now it seems to be at a point where it's feature wise basically comparable to the last SS3 versions(?) Just built in a much, much more complex way. I'm actually sad. It makes me wonder though, on what's your (Silverstripe the company) view on the future of Silverstripe framework & community? If you now know how much time & effort has been poured into all these injectable, stateless, componetizable, containerizable, GraphQL/React complexity, is it worth it? And are you aware of what it's gained (or cost) you outside of the technology (community, involvement)? When re-reading this thread I came across the perceived benefits as initially described by Sam;
Yes, the CMS has become (slightly) faster (but files still show 'DRAFT' after publishing the $owner)
Maybe... Some day?
Definitely not (at least for me)
Also not really I think (or did you mean Silverstripe internally, and even then not really, eg versioned-snapshot-admin?)
Hmyeah OK, but that's not really a brought on by the technology I think? |
|
Hey @micschk, Thanks for taking the time to put your thoughts and feelings into writing. As you know, you aren't alone with many of the points raised. If you (like myself) feel more comfy on the PHP-side and are put off by React, you should check out the webcasts for Laravel Livewire. It's not SilverStripe or even a CMS, but it is bringing many of the easy ways to do things back. It sparked the "oh wow, that's so easy" feeling I had with SS3. Cheers, |
Thanks Peter! I tried to stay constructive and don't compare to contenders but indeed Laravel (& Livewire) are the 'elephant in the room'... I've started watching some vids on LaraCasts a while back (sort of what UncleCheese used to make for Silverstripe :-)). There's also some quite decent 'Laravel admin areas' comparable to ModalAdmin/Gridfield to pick from. Only thing really missing in Laraland is a CMS as solid als Silverstripe. How awesome would it be today had Silverstripe chosen to 'adopt' Laravel (& Vue) a few years back... I intent to develop some small new projects on Laravel to get a better feel for it. The problem is that we have multiple longstanding (10y+) clients very deeply invested into Silverstripe for their websites and also some of their crucial business processes. We've just (almost) finished migrating one of our bigger clients/websites to Silverstripe 4 (after a few smaller ones), the hours involved in this instance add up to about 250(!). These hours are 'necessary maintenance' and result in little to no actual added value to the client. Since all of this work & frustration is starting to add up, and this is not even our most complex system, a community (maintenance) fork of SS3 is actually starting to look like a feasible option. As I understand a few other small dev shops also have some systems too complex & big to migrate so they may be willing to support such an initiative. Maybe even investigate if it'd be worth the effort to migrate the CMS to Laravel & tap into their enormous community & ecosystem at some point? (Sorry Uncle Cheese). |
|
Yeah, I get that some people don't want to mention the 'elephant in the room'. For me, SilverStripe doesn't cover the same areas as Laravel does IMHO. I haven't replaced a SS site with Laravel or the other way around... I see Laravel is quite a different tool in the toolkit really. As you mention, the CMS side is definitely not on the level SilverStripe offers. My mention of Livewire truly comes from the good feeling it brings me coding (same as SS3 did). My last project upgrade from SS3 to SS4 looked similar: Hundreds of hours and still only a partially happy client at the end. For very small sites a fresh start comes easier. Larger projects are often 'stuck'. I'm a bit worried about a long-term prospects of a community fork. It splits the small community further and leaves the good things SS4 has behind too. The main part many are unhappy with is React and complexity. I can't speak for the reasons led to this path, but it surely isn't helping SS. |
|
I really feel like this megathread is starting to go around in circles, with the airing of half-sarcastic grievances followed by the presentation of the existential constraints we're dealing with, bringing focus back to the path forward, rinse and repeat. So I'll just restate a few key things:
To reiterate, no one said that. The topic of this thread is modernising the CMS UI technologies. That's a process, not a point in time. It's a very difficult thing to do that puts us between two competing ideals -- a faster, more "modern" CMS UI, and a solid developer experience. Investing in one implicitly divests from the other given our obligations to backward compatibility and the size of our core team. In retrospect, sure, we can have the conversation about whether doing a partial React migration was worth it in the long run given the maintenance costs versus just doing the whole lot at a much greater cost, but we made the best decision we could at the time, and the end goal remains the same. Everyone agrees that the current state of React/PHP/Entwine purgatory is cumbersome and obtuse, but when we talk about modernising the CMS, it is, at the very least, a stepping stone, and I think this thread would be much more productive if it were focussed on where we want to be in terms of dev and user experience, rather than platforming numerous issues that we all know exist and promoting the use of other PHP frameworks as a solution to these problems. |
I tried not to sound sarcastic. What I actually meant to do is illustrate explicitly how some trivial customizations have now become roadblocks and are leaving me (and as far as I can tell at least some others) desperately scrambling for solutions. With this I tried to open up the "React is hard/not hard/hard in Silverstripe/deal with it" stalemate situation. Please don't see it as an attack or attempt at forcing anyone's arm. It is however an honest attempt to get Silverstripe to reconsider and hopefully even adjust direction. I get that there's lots of devs who enjoy working with advanced tech stacks and that's your good right, and probably it seems like the obvious technical solution for the challenges at hand. But my concerns involve business & community sense. Eg how does Silverstripe get their own clients to find it acceptable to pay for 250 hours on 'upgrading the CMS/framework'? And my questions on the size & involvement of the community were also meant honestly; is Silverstripe community growing or shrinking? Or (and that's also a possible answer) do you not keep track? Maybe even an implicit choice has been made to direct attention more towards a solid CMS product and less towards the 'golden age of customisation'? If so that's also valuable to know.
That's exactly my concern; given the insights you as core devs have gained by now, do you still stand by this choice? Or is this 'sunk cost fallacy' in progress? My numeration of files & lines of code involved into creating something as simple as a form in a modal, was meant to illustrate how much resources that small item must have extracted from an already small dev team. As (maybe naive) small development team, I think I'd halt any running project and re-evaluate the tech choices made if something seemingly trivial burned that much resources.
That's exactly the discussion I hoped to start off. What exactly is that end goal (the initial goals stated by Sam?), and is that end goal still correct given what we know today? Did/does that goal sufficiently take clients & dev community into consideration? Can we (you) still consider other, more accessible/less involved routes to reach that goal? To have this discussion, mentioning and comparing other frameworks and technologies seems necessary. Not as X is better than Y but to learn & see how others do stuff or solve comparable challenges and maybe save all of us some time (eg mix vs silverstripe-webpack). Conclusions don't have to be negative, for example one conclusion (for me) is that Silverstripe offers an incomparable CMS experience. But in case Silverstripe states they're not open to reconsider, any experiences other devs in the same situation have with alternative frameworks are very valuable to me.
I don't think that's exactly what was going on but maybe that's a viewpoint/framing-thing. Thing is; I'm aware the current situation is a stepping stone. To me in the current situation Silverstripe is comparable to SS3 in user-experience. But it's sadly a regression in business- and developer-experience. As a developer, small dev-business owner and long time Silverstripe fan/advocate, I don't want Silverstripe to be here, let stand go further in this direction. So the most productive I can do is attempting to make things better by trying to get core devs to reconsider/re-evaluate instead of just defending past choices. |
|
Here are some questions:
|
|
Overall I must say I admire peoples continuous positivity around these issues. Facing realityMR giving an excellent presentation on this modern stack Describing the move to modern UI tech as, well, not-yet-finished (trying to stay positive): Win some, lose some Goodbye old-style fields As for what we can do to make the current situation better (@sunnysideup); I imagine some sort of compatibility/fallback layer for legacy fields would go a long way. Eg I see LiteralFields can be rendered via React, maybe good old .ss theme based fields could be rendered and passed to react as literalfield? Community uptake (shrunk by about 30%)BW giving a positive explanation on community activity declining Headless use-caseUC explaining a possible use-case of the headless architecture beyond the CMS itself (personally enjoyed the casual mention of why one of Silverstripe's founders ‘ran off’(?) – spoiler alert: – something to do with this whole move to headless)
While looking at this presentation, I can not help but notice just of the amount of layers, files & buildtools this build process entails (and the maintenance nightmare & developer resource hog such a project would become). I honestly don't see how Silverstripe should be a backend/API framework for JS (React) based front-ends/apps and why anyone would want to build eg a company website this way. But again, maybe that's just me getting old. Interesting presentation though, thanks for that @unclecheese! |
Just want to be absolutely clear -- that was a joke. Ingo (who isn't a founder, but rather a long-standing member of the community and employee of the company), was a champion of headless, and I said that in jest, because it's the exact opposite of the truth. :)
This one really surprises me.
Which layers were surprising to you, and what would you have expected? Even if the toolchain is more complicated, were you able to see the value proposition of headless that would offset that overhead? |
|
Ah, I didn't get that you were joking. Made me smile either way :-)
Not necessarily surprising – it's more that I personally don't see why one would want build a page-oriented website this way (other than maybe it being 'new' and/or lead to slightly faster load times?). I really don't. Might just be a matter of personal preference but for me this setup seems overly complex (longer initial development + harder maintenance in the long run) at relatively little to no gain. On the specific frameworks:
In general:
So no, I'm afraid I don't see the value proposition (of building complete sites as react apps). As a side note I think Vercel also allows you to just define models in yml config and it will automatically build a database and GraphQL endpoints for you. So maybe someday we can rid Silverstripe of the PHP backend stuff altogether and just store everything on Vercel? (joking) What I do get:
So I do see a value proposition of data driven JS rendering, not necessarily of full-page JS apps (due to their relatively high overhead). |
|
tl;dr I can report a mostly positive experience in making websites using NextJS and Silverstripe and we will do this with all our sites from now on. long read In case it helps, here is our experience building our first site. We are grateful for Aaron getting this up and running.... What I am also saying is: there is help out there getting started with this sort of thing. CON:
PRO:
REALITY CHECK:
WOULD I DO IT AGAIN? WOULD I DO IT AGAIN FOR A BROCHURE SITE? WISH:
WORRY:
|
|
BUMPY MC BUMP A LOT |
Have you considered, using prisma or other DB ORM and connecting to the same DB as silverstripe? that way you don't need to rely on graphql requests |
|
Interesting idea. Would it understand the layered cake that is SS DB (e.g. get data from SiteTree, Page, and MyPage to get all the details for MyPage)? |
For other tools the Silverstripe CMS db is just a relational db like any other. You'd need to let it know what and how you want queried, what tables to join etc. |
SO then why not use SS GraphQL? I mean, what we are trying to do is to simplify it all. |
It wasn't my suggestion above, so don't know about the context there. I only mentioned that any other ORM/tool would need some massaging to understand/work with the SS db structure. |
and others
SilverStripe foundational CMS UI technologies are 5-10 years old, and are largely based on an abandoned internal project by our former CTO (Entwine). In 2015, we've started removing this technical debt through the new assets and campaigns sections, with a large investment into new tooling. This effort has often been synonymous with a "React GridField", but goes deeper in how the CMS is built.
It is important to complete this effort by rolling it out to the main CMS sections. This will provide a consistent developer experience for customising the CMS.
Benefits:
Risks:
Note: Please install zenhub.com to see tickets associated to this epic.
The text was updated successfully, but these errors were encountered: