On Thu, 13 Jul 2006 16:20:06 +0200, Adrian Rossouw <adrian@bryght.com> wrote:

On 13 Jul 2006, at 3:15 PM, Dries Buytaert wrote:

...

Keep up the great work folks!

this is worth de-cloaking for.

YAY!. great work guys.

You started it. We owe you and Amazon a big one. Thanks NK

Dries Buytaert wrote:

- a default profile that doesn't do anything in particular (current behavior) - an 'example profile' or 'quickstart profile' which creates some example content (eg. an about page, a contact form, some primary links, etc)

Is that a profile or is that a welcome module? Or is there a distinction when discussing it at this level?

On 13 Jul 2006, at 5:22 PM, Dries Buytaert wrote:

I think it is a simple profile. Let's not make it any more complicated than that. It is OK to embed module specific logic in a profile. That's what install profiles are about. All it takes are a dozen INSERTs.

Umm.. what I would like to see here.. and it's not because i am being funny.. is all install profiles being in their own directory , and the default content being php files. (similar to the fixture idea that dries has). I just like the idea of user-1.object, node-2.object files more than the idea of having to edit sql, especially when it comes to creation of complex data types. also. perhaps a variables.object. of course. there's the programmatically submitting nodes problem =). -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com

On 13 Jul 2006, at 5:31 PM, Adrian Rossouw wrote:

I just like the idea of user-1.object, node-2.object files more than the idea of having to edit sql, especially when it comes to creation of complex data types.

another thing i like about that .. heredoc syntax. $node->body = <<<EOT My entire contents of my node's body, can very cleanly be put into this space here, without having to mess around with 'escaping' I believe this is simpler than trying to edit the default node content, either within the sql statement, or within your usual strings. EOT; Althought I know that's kind of frowned upon here, so whatever. So you could create you initial node by just having a file that says : file: node-1.object ---- $node->type = 'story'; $node->title = "Welcome to your new blogging site"; $node->body = <<<EOT Thank you for installing the Drupal Blogging install profile. Your first step would be to create your initial account, and then to post about whatever EOT; In the case of the default variables, this would be : variables.object --- $variables['site_name'] = $edit['site_name']; // if there was a field for it. $variables['some variable'] = blah; Same could be said for taxonomy, node types etc. This is one of the reasons I think the programmatically submitting forms approach is far more powerful than trying to duplicate all the checking that happens on forms, inside node_save. Oh. and this also gives us versioned content, and provides an abstraction layer that we can maintain between version changes. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com

On 7/13/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:

But it begs the question: how are we going to handle install profiles? Where and how to maintain them? Should we have one or more profiles in core?

If you have profiles is core, does that kill the idea of Drupal developing into a set of APIs and cutting back on core modules?

On Thu, 13 Jul 2006, Earl Dunovant wrote:

On 7/13/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:

...

But it begs the question: how are we going to handle install profiles? Where and how to maintain them? Should we have one or more profiles in core?

If you have profiles is core, does that kill the idea of Drupal developing into a set of APIs and cutting back on core modules?

Who has this idea? Last time Dries said he actually intends to add more modules to core, and that the value for a module of being in core (and its reputation among the community) is not understood by most, who think that a module moved to contrib could just as easily work for anybody. Look up recent discussions on the development ML. Gabor

On 13-Jul-06, at 11:28 AM, Dries Buytaert wrote:

On 13 Jul 2006, at 17:19, Earl Dunovant wrote:

...

But it begs the question: how are we going to handle install profiles? Where and how to maintain them? Should we have one or more profiles in core?

If you have profiles is core, does that kill the idea of Drupal developing into a set of APIs and cutting back on core modules?

Earlier this week I explained why I do not intend to remove core modules, except maybe for the archive.module. The install system doesn't change that fact.

Should I move the archive module to contrib?

Or get a maintainer and replace it with that CodeMonkeyX updated one. I have no problem with archive-functionality in core...I have a problem with a *crappy* archive module in core. (to which, of course, the answer is -- supply patches) -- Boris

Gabor Hojtsy wrote:

I am looking into updating that module. Weblabor.hu got az ISSN number partly because of having a date based browsing interface (which is the calendar and the archive module providing it). So we are in need of the functionality obviously.

views.module + event.module do a pretty good job of offering all of this and much much more. The CCK date functionality is coming along quite nicely, too.

Gabor Hojtsy wrote:

Event? What event? CCK? I would like to put a calendar (date based browsing) view of all nodes on my site as any simple blog on the net does. Archive module does this. No multimodule, multipage overkill. It has no database tables or even any settings.

Man, you don't have to be insulting.

Gabor Hojtsy wrote:
> This tone is not insulting in Hungary :) People need to understand 
> that views+cck+workflows+event+holymodule are very nice and powerful, 
> but are not universal solutions.
1) What you said you wanted in the first message didn't match what you 
said you wanted in the next message.
2) What you said you wanted in the first message sounded like a very 
generic date/calendar browsing interface.
3) What you said in the followup message is a very specific date 
browsing interface that has no flexibility and is, in fact, useful only 
for a particular class of sites. For that class of sites, it's great. 
For the rest of them, it's useless.
4) 'Overkill' is antagonistic, especially since I was responding to #2, 
not #3.

Maybe Hungary is different than the rest of the world, but saying "I 
want X" and when someone helpfully responds, you say "No, don't give me 
your "multimodule, multipage overkill" solution, I want "something that 
isn't, in fact, X"" is both a bash both to the person helping and the 
modules involved.

Finally: "People need to understand that 
views+cck+workflows+event+holymodule are very nice and powerful, but are 
not universal solutions"

Thank you for correcting my understanding of my own module. Surely I had 
no clue that views isn't for every site.

By the same token, people need to understand that 20 different versions 
of relatively narrow application modules *also* aren't good solutions 
either, and an archive module with no ability to exclude irrelevant 
content from the archive one instance of the too narrow solution.

Gabor Hojtsy wrote:

I have seen a great demand for the enhanced archive.module by codemonkeyx to get into core. Although I am fine with the archive module in core currently, it does not seem so that it has any future, so I figured I better put time into *some* archive functionality for core, so that this stuff is kept. Whether this is a relatively narrow application module I don't know, it will be decided by the community. Maybe my efforts will go unused. Maybe someone will use the enhanced archive module even if cck+views+event provides a more generic all-covering solution, as you suggested. For what it's worth, on just 'archive' functionality, which is based upon post date, CCK & Event aren't necessary. Those were only suggested because it seemed like you meant something more, and to add arbitrary dates.

For more normal use, Views does some pretty good archive stuff all on its own. Dunno if that's still overkill or not, but that was a big reason why Views was written in the first place, and a core ideal in its functionality was to do everything archive module *should* do. Well, except it still doesn't provide a mini calendar block, but that's actually fairly easily to implement at this point, it just hasn't been done.

Gabor, thanks for taking this on.

We all agree that Views etc. are a much more complete solution. I think we can also agree that views + event + CCK are not ready for a core The narrow solution which the core archive module provides -- of browsing by date -- is fine...it's just narrow.

I have updated the CVS HEAD version of the contrib archive.module, so it works nicely with Drupal 4.7 and HEAD (tested with HEAD on a database updated from 4.7). It still has three fundamental issues: - One query is not pgsql compatible. As it turned out at http://drupal.org/node/29676 it is not a trivial fix. - Timezones are surely not properly handled yet. Codemonkeyx sometimes added, sometimes substracted the timezone offset from dates. I have not yet looked into this. - Theme functions are not up to par to core standards. I tried to get CSS ids, function names, function parameters, menu system parameter handling, page callbacks and such up to core standrads. The good in the updated module is that it is now a drop in replacement for archive module (no need to patch anything). It does not have the calendar block for some reason (comment on the issue above, if you think that should not be lost). But it does have a much improved browsing interface. Since this archive module was intended as a core archive module replacement, it does not have a project page, neither an issue queue. Therefore maybe the above issue is the proper place to add your opinions on the module. Gabor

On Thu, 13 Jul 2006, Morbus Iff wrote:

...

- One query is not pgsql compatible. As it turned out at http://drupal.org/node/29676 it is not a trivial fix.

- Timezones are surely not properly handled yet. Codemonkeyx sometimes added, sometimes substracted the timezone offset from dates. I have not yet looked into this.

For what it's worth, if you based your version off the version attached to that issue, I'd blame all failures on me. I modified his version quite a bit, not only stylistically, but functionally, and I tackled timezones as well, for weeks, with lots of folks chiming in. I eventually gave up because there were some indication that timezones could not be accurately represented due to corrupted data.

See:

...

//drupal.org/node/29676#comment-41762 //drupal.org/node/29676#comment-41845

Unfortunately I thought that I will find the latest module in CVS, so I worked off of that version. Then I found the issue, and compared to the latest patch (see my findings on the issue). Will see what can be done with dates.

...

The good in the updated module is that it is now a drop in replacement for archive module (no need to patch anything). It does not have the

As was mine too. Mine also ran cleanly under 4.7 and HEAD. Up until a week

Not really. There was a CSS patch in the CVS version, and also in your version. You kept reminding people on every iteration that the previously posted CSS patch still need to be applied.

ago, I had been using it on disobey.com, but have since removed it in preparation of Views 1.0, which I'll use for archives instead.

Good, so someone will build an archive based on views :) Gabor

There is still the idea of some kind of "Golden Modules" floating around. These could fill the gap between Core and Contrib. I think the result of the last discussion here includet the following: * Versioning for Contrib - http://drupal.org/node/58066 * The "Golden Modules" (e.g. Views, Workflow, everything that gets removed from core) will have a prominent position on the drupal modules download page * They will have a real release cylce, so they have always to have a version that's considered stable * If one of the modules is not actvily maintained anymore, it gets removed from The List * By releasing a new core version, these modules have to be ready --> So the Golden Modules would be treated similar to core. However, they could possibly have releases between core releases. Out of that pool of core-like modules people will take the ones they need. The result would be a lightweight, slim core that gets its power from the core-like "Golden Modules" and can then be extended by contrib. On drupal.org, there could then be different install profiles with everywhere the same, slim core extended by the fitting "Golden Modules". As they have all to have nearly core-like quality to be a Golden Module, the effort to maintain a install profile containing only core and "Golden Modules" should be far smaller than maintaing an install profile that contains lots of contrib. btw, "Golden Modules" is propably not a good name, it's just some word that was floating around for quite a while now ... best regards, frando

On 13 Jul 2006, at 17:19, Earl Dunovant wrote:

...

But it begs the question: how are we going to handle install profiles? Where and how to maintain them? Should we have one or more profiles in core?

If you have profiles is core, does that kill the idea of Drupal developing into a set of APIs and cutting back on core modules?

Earlier this week I explained why I do not intend to remove core modules, except maybe for the archive.module. The install system doesn't change that fact.

I

On 13 Jul 2006, at 4:36 PM, Jeff Eaton wrote:

Just wait until the 'prepare the way for cck' patch hits. Heh. and now that we have the modules in their own directories, we can start maintaining the templates as a patch, instead of having to maintain an svn repository in which a set of fairly complex scripts have been run (and then additional tweaks were made on that)

-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com

Actually, you don't! ;) the 'setting up settings.php' step is no longer necessary. --Jeff -----Original Message----- From: Gabor Hojtsy [mailto:gabor@hojtsy.hu] Sent: Thursday, July 13, 2006 3:24 PM To: development@drupal.org Cc: documentation@drupal.org Subject: Re: [development] install system Note that the install.txt and database specific install files are not yet updated. Hopefully the documentation team can tackle this issue for those early adopters like me, who would immediately like to enjoy the new stuff. BTW *I* know what to expect: create database, create user, set up settings.php, load up install.php and then watch the magic :) Will see what happens :) Gabor