I also never really liked that.
But I prefer that over moving everything into CMS, I do use the minimal version of the CMS sometimes.

So, yeah, I would approve of moving the basic admin into new module, so that when you want the full cms, you would have 3 packages to include: framework, cms-base (or what ever) and cms.

(A little to big for this proposal, and slightly off topic, but my wish for SilverStripe is to also make it a component based framework, where those components can also be used standalone and the developer can select only the components needed. And if we do decide to move towards that in the future, this proposal would become obsolete.)

The key point, albeit it a subtle one, that you're missing is that 3.0 aimed to decouple the cms, not the admin. It sounds like semantics, but there is a difference.

IIRC, when SilverStripe decided to enter the PHP framework space, there was a lot of talk about how to differentiate from the myriad others. Concurrently, there was also a lot of debate about what parts of the CMS were truly tied to the CMS and not some abstract "admin" feature of the framework -- ModelAdmin, GridField, SiteTree, etc. The decision to make them part of the framework was done in the interest of giving SS Framework some kind of differentiating set of attributes.

I'm not saying it was a great idea, but just providing the context. "CMS" still is very much decoupled. It just piggybacks on the "admin" features afforded by the framework.

Yeah, the choice was a deliberate one—the intention was to mirror the idea that Djano bundles an admin interface. I've certainly found it useful in a lot of projects that don't require the CMS and would strongly vote against including it with the CMS.

However, the fact that it was all bundled into framework/admin/ hints at the fact that it was a borderline call as to whether it should be a separate module. At the time, we weren't using Composer, and an extra module was seen as inappropriate overhead. Now, with Composer, I think it makes perfect sense to break out into a separate module.

Related:

• It's not clear if GridField should be part of the admin module, or part of the forms system, as it currently is.

• Should we shard out other parts of framework into separate modules?

• Is this a 3.2 or a 4.0 change?

I wonder what the main practical reasons are for removing "admin" from framework (e.g. it makes it faster, allows you to add another "admin" type module???).

@Nicolaas: decluttering your project is a good idea for a number of reasons. It's less code to introduce bugs, less code to have security holes, less code to upload to your server or download to your dev environment.

In and of itself, it might be of limited value, but it makes a lot of sense if it's part of breaking down the current framework module into components.

It’s not clear if GridField should be part of the admin module, or part of the forms system, as it currently is

I don't see any reason to break it out from framework, unless we break out the forms as well. I'm trying (not working without a shim) to use gridfield in the front-end from time to time without having a backend.

Moving out admin to another module makes sense. It would make it easier to maintain and do security fixes without re-releasing everything.

However I wonder if we will end up with individual PR's against CMS, admin and Framework that all solves one issue and will that cause problems?

I would say this should come out after vendor prefixed modules gets included otherwise it's another module at the root.

As pointed out earlier I would like to break up the framework into many components / modules.

decoupling admin and form into separate modules is a good place to start.
as for gridfield, with stig here that it has to stay in forms as I often use gridfield in the frontend.

to the question if 3.x vs 4, I am not quiet sure.
I'd like it to happen sooner than later, but then again will has a good point with saying that we should fix the module folder issue first and make sure modules go into vendor/ instead of project root.
What's actually the status on that? I remember there was a lot of work done on it during the google summer of code, but it kind of went quiet and I haven't heard anything since.