[development] Core vs profile [was: Drupal 7 "When it's Ready"]
s.nerz at orestes-sol.com
Thu Mar 5 12:28:29 UTC 2009
I apologize right in front - I'm new to Drupal development (so neither
to programming nor to php/webprogramming), nevertheless I want to voice
some of my concerns regarding "core" vs "profiles", as the problem was
mentioned in the discussion /Drupal 7 "When it's Ready"/.
Matt Chapman schrieb:
> You may say, 'What about modules that are so generic that they are
> used in most any site?' I'd suggest that those are exactly the sorts
> of modules that should be included in Core. We're seeing this happen
> with CCK, and Views seems poised to follow shortly. We could even make
> the criteria for core eligibility more explicit: If a module is used
> in EVERY supported profile, then it should be moved to core in some
> (And the converse: if a module is not used by any supported profile,
> it should probably be removed from core.)
> One thing that would really help this is more street cred for profile
> maintainers. However about some front-page case studies for a couple
I am a big fan of modular development - and in my eyes modular
development means: Keep core as minimal as possible and provide modules
For Drupal this would mean: A minimal core (might include minimal CCK
and Views (API), but e.g. not Blog or Forum) that is required, abd not a
single optional module. Then provide some "standard profiles/usecases".
Most users would download the standard profile (thus including e.g.
Blog, Forum and Views UI). Replace the standard download link with a
link to the standard profile.
What is the difference? Core is more critical then optional modules.
Thus every module-update has to be part of a core-update - while
updating single non-core modules is far easier for both, the developer
and the user. A minimal core thus provides the highest flexibility.
You can e.g. see that in Drupal - core modules tend to develop much
slower then contrib ones. This is ok, but does Drupal really need a
For the average user (and even the average developer) a minimal core
with a standard profile wouldn't change anything.
This would change the scope of profiles, but I think it would be for the
> It's not so important to users that module X be available, but that
> feature Y be provided by some module; preferably with an upgrade path
> from module X, but that is secondary from a development perspective.
I agree - and believe that this again is an argument in favor of
"minimal core, maximal profile".
> Rather than golden modules, what we need are golden 'use cases.' Perhaps
> this takes the form of supported Profiles or Patterns. (I'll use the
> term 'profile' to mean any means of collecting modules and
> configurations for implementing a specific end-user functionality. I
> think installation profiles as currently supported by Drupal are
> severely lacking, having abandoned one in favor of database dumps for
> the time being.)
Profiles would need to be changed into something more generic. In fact,
an automatic download tool in combination with use-cases would solve
even more problems: Use-cases (or profiles) could be
downloaded/selected, and the needed modules are automatically downloaded
and installed. I agree, that quite a couple of professional webmasters
wouldn't use automatic downloaders out of the box - but they should be
able to download needed modules by themselves, provided the use-case
lists the needed modules.
A use-case could e.g. be a module with requirements, but without content
(define what modules you need for the given use-case, possible link them
together, but provide no functionality for yourself). If a use-case
needs functionality that is not defined in any module - add a
corresponding module. If the functionality is only needed in the given
use-case, add it to the use-case module.
This would allow a much more flexible combination of use-cases/profiles,
it would allow for extending use-cases (e.g. Blogpage, Reviewblog
extends Blogpage, etc)
> Finally, supporting profiles instead of modules makes the system less
> susceptible to single points of failure. It takes less technical
> expertise to maintain a profile than it does to maintain a module. If I
> maintain the Community Events Management profile, and there's no e-mail
> reminder functionality available for Drupal 7, I can petition 3 or 4
> different module developers to upgrade their module, or I can try to
> organize some developers to create a new, better one, to leverage the
> new DX features of Drupal 7.
Again: I believe that this is an argument pro "profiles" and against
"core" as it would be easier to maintain a set of use-cases/profiles
with a minimal core, provided use-cases could include other use-cases.
Mit freundlichen Grüßen / Best regards / Saludos cordiales
D-72076 Tuebingen - Deutschland
Of. : +49-7071-56519-30 - Fax : +49-7071-56519-31
s.nerz at orestes-sol.com <mailto:s.nerz at orestes-sol.com>
More information about the development