[consulting] DrupalCOM: European Small Business distro
Bèr Kessels
ber at webschuur.com
Fri Dec 16 15:42:23 UTC 2005
Thank you for replying, Dries.
First of all I think My intend target audience is *not* that CEO with some
spare time and an Apache server sitting in her serverroom.
I intent to:
* use this as our (sympal.nl) basic install. we might even call the
profile/distro Sympal. :)
* provide this in an SVN/CVS/drupl project or so, for *consultants* to grab
and use.
Op vrijdag 16 december 2005 10:01, schreef Dries Buytaert:
> > Now the funny thing with all this is: its so darn simple!. It is so
> > simple,
> > that drupal cannot do it! Drupal adds complexity all over the
> > place. And most
> > often the biggest bulk of the work lies in getting rid of that
> > complexity and
> > getting rid of all these pages, links, read-counters, attachement-
> > lists,
> > user-profiles, post-dates, and what more.
>
> Make no mistake. Much of this is not specific or limited to small
> businesses. It are core improvements.
Yup. I am aware of this. One of the things I really hope to achieve with this
'thing' (lets not call it a distro yet) is to widen the possibilities of
Drupal deployment, by limiting the default options :)
> I'd like to see most of the improvements that come out of this
> discussion to go straight into Drupal core! No, not to a DrupalCOM
> distribution. Why? Because if you want to build a community
> website, an e-commerce website, a campaign website, a news website, a
> classroom website, or any other level 3+ website, you still need
> _all_ the level 3 functionality. Everyone needs a contact form,
> everyone needs an about page, everyone has to manage one or two
> custom blocks, everyone has to create a navigation structure,
> everyone needs to upload some documents/images. Everyone. As easy
> to use as possible.
This is true. And would be ideal. Yet we (I at least) are in a similar boat as
Bryght and CS. We have to get going fast. We cannot afford to always get
everything trough the whole community process when there are targets and
deadlines luring around the corner.
But moreimportantly, Drupal Core has in this issue, too much. So I want to
split the complete 'thing' into two separate issues:
1) the files and configuration
* Collect and develop the modules and themes that are required
* Remove the modules and themes that are certainly not required.
* Configure the database (dump) to hold a ready-set-go configuration. That
will probably even include some pre-made nodes containing 'click here to
change your about us page'
2) Hacking Core :)
* Fix up all issues that cannot be dealt with trough modules and a few themes.
(think about i18n)
* Provide a default set of theme_foo functions to (re)move stuff
Both steps will produce helpfull code. Esp 2) will give us some usefull
patches for core. But 1) might also give us some usefull small modules and
themes, that can be used in Drupal itself, who knows.
For certain is, that Drupal core has still too much. Forums, profiles, queues,
community blogs, etc. I believe they are good for Drupal itself, but must be
remmoved from that 'thing'. That is stuff that cannot flow back into Drupal
itself.
But last, and certainly not least. I, and I guess no-one has the resources and
infrastructure ready to do this outside of Drupal. Esp the step 2) should be
held all in-Drupal, IMNSHO.
> None of the complaints or features in this thread were specific or
> limited to small businesses ... except for the business-specific pre-
> configured navigation structure, maybe. The DrupalCOM distribution
> should be a 50-line MySQL file. All the other improvements should go
> to core.
Not really. Many Drupal people come to Drupal for its flexibility, and its
powerfull features. While the 'thing' s main aim is to hide -or eve do away
with- that feature richness and flexibility. CEO's don't need taxonomy, they
want a page listing all their services. And if that is done with a completely
preconfigured taxonomy, or with a small module, is not yet up for discussion,
IMO.
Removing stuff cannot be done with a 50 line SQL file, unfortunately.
And if we were to say: remove profiles/archives/forums/foo/Bar from core
others with other needs would rise and fight these decisions. Who says they
don't need forums? Or user management? Or anything else?
> Keep in mind that Drupal 4.7 is what you'll have to sell to your
> customers in 2006. If your business depends on Drupal, there is
> still time to get many small improvements into Drupal 4.7.0 (eg.
> improved default configuration, improved out-of-the-box experiences,
> improved interfaces, less configuration overhead). All it takes is
> some of your time and resources and all of us (including your own
> business) get to benefit from it for months to come. You better be
> quick though.
Drupal 4.7 is -as others mentioned too- a huge improvement in all this. we
have added a lot of targetted, restult-oriented features and things (menu otf
primary links- in menu admin, better block administration etcetc). And we
have gained a huge amount of flexibility from a consultant point-of-view.
but the thing that remains, is that for a brochure site, Drupal does still far
too much. It tries to be both developer friendly and userfriendly. Both
flexible and unfriendly. Both bloggers and those that have never heard of a
blog. Both modular/expandable and offer a wealthy core. that is good! And
DrupalCom should be a distro that builds and uses that flexibility and power.
And hopefully we can make as many improvements that help Drupal grow.
> > --
> Dries Buytaert :: http://www.buytaert.net/
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting
--
PGP ber at webschuur.com
http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc
PGP berkessels at gmx.net
http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc
More information about the consulting
mailing list