Dries Buytaert wrote:

On 04 Jul 2006, at 17:11, Neil Drumm wrote:

...

Right now we have an inconsistency with our moderation bit. Is it supposed to control the visibility of posts, or is that solely dependent on status? 13 queries say it should have an effect and /up to/ 38 queries say no.

The issue for this is over at http://drupal.org/node/71730.

I think the underlying problem may be that published (status) is not mutually exclusive with moderation.

The original context of the moderate bit is the queue.module. With the queue.module, nodes that have both the moderate and published bit set were shown to authenticated users, but not to anonymous users. Nowadays we have node-level permission, something which wasn't avaiable when I originally wrote the queue.module. If the same can be achieved with a node-level permission module (and I think it can), it is probably best to take the moderation bit behind the barn, and to shoot it through the head. It's been a pain for years. :-)

Taking out the moderation bit should be both easy, fun and rewarding. SQL queries get less expensive, the user experience is likely to get better, and the code becomes easier to grok.

Maybe check with the workflow people; I believe they had some concrete suggestions about this. Either way, the workflow people figured out a mechanism to build arbitrary workflows with complex transition schemes, and I'm pretty sure they don't need the moderate bit for that. The workflow module is the way forward.

I agree with all this. That said, it would be nice to have 'bits' on the node object that can be utilized by modules. Adding flags that must be joined in is kind of annoying, and the moderation bit has its uses. It's very convenient if core provides something that's easy to utilize. Also, publication status is not really usable by the node access system. If you look carefully at the node_access function, you'll note that an unpublished node *doesn't check* node_access at all, and is only visible to people with administer nodes permission. Fixing this might actually be kind of nice, but I've been assuming it was like that for a reason.

I don't see it announced on this list, so I'll just note that pwolanin just announced (to the docs list) a contrib module to handle workflow issues we've been discussing on the docs list, including some of the concerns about moderation, publication and node_access. http://drupal.org/project/content_moderator

This module allows you to give a "moderate nodes" permission to a user role. Users with this permission may see a list of content (restriced using the node access table so they cannot see content they are normally prohibited) at /admin/content_moderator. Within this list they can either approve posts to move them out of moderation, or put them into moderation to remove them from public view.

Also, uses hook_nodeapi to prevent nodes from going back into moderation (if that's their default setting) when edited by a user with this permission.

A block is also made available to show the most recent ten posts in the moderation queue.

This module is intended to be useful for a site like Drupal.org which has a handbook where all users can add book pages, but those pages go into the moderation queue. This modules allows the work of reviewing and approving those posts to be delegated to additional users without giving out the all-powerful "administer nodes" permission.

-Laura On Jul 4, 2006, at 10:53 AM, Dries Buytaert wrote:

On 04 Jul 2006, at 17:11, Neil Drumm wrote:

...

Right now we have an inconsistency with our moderation bit. Is it supposed to control the visibility of posts, or is that solely dependent on status? 13 queries say it should have an effect and /up to/ 38 queries say no.

The issue for this is over at http://drupal.org/node/71730.

I think the underlying problem may be that published (status) is not mutually exclusive with moderation.

The original context of the moderate bit is the queue.module. With the queue.module, nodes that have both the moderate and published bit set were shown to authenticated users, but not to anonymous users. Nowadays we have node-level permission, something which wasn't avaiable when I originally wrote the queue.module. If the same can be achieved with a node-level permission module (and I think it can), it is probably best to take the moderation bit behind the barn, and to shoot it through the head. It's been a pain for years. :-)

Taking out the moderation bit should be both easy, fun and rewarding. SQL queries get less expensive, the user experience is likely to get better, and the code becomes easier to grok.

Maybe check with the workflow people; I believe they had some concrete suggestions about this. Either way, the workflow people figured out a mechanism to build arbitrary workflows with complex transition schemes, and I'm pretty sure they don't need the moderate bit for that. The workflow module is the way forward.

-- Dries Buytaert :: http://www.buytaert.net/

On 05 Jul 2006, at 14:52, Chris Johnson wrote:

If the consensus becomes that the moderation bit needs to be removed, get my attention and I'll build the patch. I don't have the mental bandwidth to intelligently discuss moderation / workflow right now, but I do have the time to crank out global patches.

Let's take a couple minutes to figure out the drawbacks of removing the moderation bit. What does that mean for modules like the book.module and queue.module? How would they achieve their goals? -- Dries Buytaert :: http://www.buytaert.net/

The queue module has been dead since it was removed from core. Note that nobody bothered patching it for 4.7, and it does not have a .install file. The bigger question is: does any other module use this column in the database? Here is the answer from today's HEAD: $ grep "SELECT .*moderate" */*.module|awk -F: '{print $1}' | sort -u admnotify/admnotify.module category/category.module content_moderator/content_moderator.module ejournal/ejournal.module event/event.module eventfinder_filter/eventfinder_filter.module flexisearch/flexisearch.module hof/hof.module image_browse/image_browse.module linkattach/linkattach.module links/links_weblink.module nmoderation/nmoderation.module nodeperm_role/nodeperm_role.module pdfview/pdfview.module pr/pr.module queue/queue.module shazamgallery/shazamgallery.module shoutbox/shoutbox.module track/track.module tr/tr.module video/video.module weblink/weblink.module xstatistics/xstatistics.module Since this contains some obsolete modules, here is the same result from the 4.7 modules: $ grep "SELECT .*moderate" */*.module|awk -F: '{print $1}' | sort -u category/category.module content_moderator/content_moderator.module ejournal/ejournal.module event/event.module hof/hof.module nmoderation/nmoderation.module og_blocks/og_block.module pdfview/pdfview.module shazamgallery/shazamgallery.module shoutbox/shoutbox.module xstatistics/xstatistics.module More importantly, what will moderation modules do without that column, and how would they do it? Namely, the new content_moderator and nmoderation?

On 05 Jul 2006, at 16:00, Khalid B wrote:

The bigger question is: does any other module use this column in the database?

I'm pretty sure most of the modules you showed are not actually using the moderate-flag. Much like many of the Drupal core modules, they read/check the moderation-flag, rather than actually updating/using it. I think a patch is in order. *fires start sign* :) -- Dries Buytaert :: http://www.buytaert.net/

Maintain a separate table. Nmoderation in particular just uses the flag to determine what nodes it should show its moderation voting widget on -- everything else it handles by publishing and unpublishing. The behavior of the module wouldn't change considerably if some different mechanism were used, we'd just have to figure out what makes the most sense. (A 'moderation' module that adds the behavior we're discussing? Multiple states for the 'published' flag? 1 for published, 0 for unpublished, negative numbers ofr intermediary but not-visible-to-everyone states? That would be nice.) --Jeff

-----Original Message----- From: Khalid B [mailto:kb@2bits.com] Sent: Wednesday, July 05, 2006 9:01 AM To: development@drupal.org Subject: Re: [development] Moderation bit behavior

More importantly, what will moderation modules do without that column, and how would they do it? Namely, the new content_moderator and nmoderation?

Earl Miles wrote:

Jeff Eaton wrote:

...

Maintain a separate table.

I'm against this. I'd much rather have a set of flags attached to the node object so that we can have exandability without sacrificing performance by adding even more joins. Even if we don't keep moderate as is, it would cost us little to leave the flag, even if we remove all reference to it in core, and leave it as the purview of other modules.

This is especially true since we've removed the ability (at least, I believe we have) of modules to add fields to the node table by having removed the 'fields' op from nodeapi.

Right, this was removed. There is no reason why a contrib module can't add flags of its own to the node table. The only drawback is that the module author would need to set/read the value through nodeapi. Any such flags - be it the current moderate flag or any other one - suffers from the fact that db_rewrite_sql could be used to impose conditions on these flags, but there is no way to also select them. Cheers, Gerhard

Mark Fredrickson wrote:

On the subject of bits on nodes, I would advocate for the least number of hard wired fields as possible. Hardwired data conflicts with user configurable systems and makes administration harder and more confusing for end users. Instead, I would advocate for dynamically added data (from modules) where needed.

In more specific terms, let me argue for removing a large portion of the current node object (feel free to disagree):

From the node table: nid - keep vid - keep type - keep title - remove. Titles should be set by node modules (and stored where the body and teaser are), not stored in the node table.

This was a design decision. We often only need the title of a node (for link lists for example). If we do a join on the node_revisions table, we lose a lot of time. We are contemplating to add the author's name for the same reason (save join on user table).

uid - keep status - remove. Let a module like workflow control the state of the node. Or, don't have a state. Let the admin decide. Node_access is a better solution than an all or nothing published state, in my opinion. created - keep. changed - keep comment - remove. Why would I want this data if I don't allow comments? Spareness should be avoided if we can help it. promote - remove. Let's move nodequeue into core and make a default "front page" queue. This more extensible. moderate - remove. As this thread shows, no one is sure exactly what moderate should do. Let a moderation system control node moderation. sticky - remove. Again, let the nodequeue system decide what is first in the order.

I'd be in favour of a more flexible bitfield instead of all the single fields.

I would also like to see us move away from body and teaser fields in the node_revisions table. If I only use CCK nodes in my site, these fields will be useless for every single node I have.

Then they'll be empty and won't hurt.

If we do move towards an "everything is a node" or at least "most things are a node" model, the body and teaser fields will seem anachronistic.

Well, we don't know if we move there. Also, it would be convenient to store pre-rendered html there...

Yes, this position does require more joins. I understand there is a penalty. I think that penalty is worth the simplicity and can be overcome with better caching.

I am not sure. Getting caching right is a difficult thing and getting queries to perform better is much easier. Cheers, Gerhard

Gerhard Killesreiter wrote:

Mark Fredrickson wrote:

...

On the subject of bits on nodes, I would advocate for the least number of hard wired fields as possible. Hardwired data conflicts with user configurable systems and makes administration harder and more confusing for end users. Instead, I would advocate for dynamically added data (from modules) where needed.

In more specific terms, let me argue for removing a large portion of the current node object (feel free to disagree):

From the node table: nid - keep vid - keep type - keep title - remove. Titles should be set by node modules (and stored where the body and teaser are), not stored in the node table.

This was a design decision. We often only need the title of a node (for link lists for example). If we do a join on the node_revisions table, we lose a lot of time. We are contemplating to add the author's name for the same reason (save join on user table).

...

uid - keep status - remove. Let a module like workflow control the state of the node. Or, don't have a state. Let the admin decide. Node_access is a better solution than an all or nothing published state, in my opinion. created - keep. changed - keep comment - remove. Why would I want this data if I don't allow comments? Spareness should be avoided if we can help it. promote - remove. Let's move nodequeue into core and make a default "front page" queue. This more extensible. moderate - remove. As this thread shows, no one is sure exactly what moderate should do. Let a moderation system control node moderation. sticky - remove. Again, let the nodequeue system decide what is first in the order.

I'd be in favour of a more flexible bitfield instead of all the single fields. I'd be in favor of something along these lines:

node_flag('moderate') -- returns the name of the flag used for 'moderate' or NULL if there isn't one. node_flag_register('moderate') -- register the flag during .install, returns the real fieldname. Returns NULL if no flags are available. node_flag_list() -- return an array of all existing flags Modules can then register their flags which are directly put in the node table. We can pick some number of these; we could add a method to add more flags; Queries simply use node_flag('moderate') instead of 'moderate' if they care about it. They never need to know the field's true name. Cons: database names won't be transparent because it will just be 'flag1', 'flag2' or whatever, and some kind of translation may need to be done for things that look at a node as a whole. Also, 'flag1' on one Drupal install will have a completely different meaning from 'flag1' on another. I think both of these cons are quite minor; they allow us to kind of do away with the moderate flag without actually doing away with it. Modules which need to set flags can.

There is nothing wrong with having separate bit-fields in the database. It's easy to use, easy to write SQL queries for, and probably faster as you don't have to do binary operations in the SQL queries. Keep it simple.

Here is more: They can only be On or Off, and cannot mean anything else. If you want another state, you cannot get it from the current column, you have to create a new one. Grouping by a bit is not as simple or elegant or fast as grouping by a column (involves a function at minimum). What about database portability/abstraction? From what little I know Postgres can have a problem with this (gurus, please confirm/debunk). Since this is a database, a column for each "meaning" is far better. It makes sense to use bitwise fields for operating systems, or systems programming, but otherwise, distinct fields are better.

Op woensdag 5 juli 2006 17:41, schreef Gerhard Killesreiter:

...

Yes, this position does require more joins. I understand there is a penalty. I think that penalty is worth the simplicity and can be overcome with better caching.

I am not sure. Getting caching right is a difficult thing and getting queries to perform better is much easier.

Another one worth exploring would be to add views (not the module, but the MySQL thingy) in database.mysql(.views).inc That way a database layer could, under water, use views instead of such "expensive" joins. result: We use our tools better, we gain (a lot of) performance and most of all, we normalise our datastructure better. I'm all for pragmatic approaches, like adding title fields because it speeds things up, even if they bring us further away from having a Good Design. But I am more for using the tools to their full power, they way "it is meant" instead of abusing the tools. Bèr

On 05 Jul 2006, at 17:43, Khalid B wrote:

...

status - remove. Let a module like workflow control the state of the node. Or, don't have a state. Let the admin decide. Node_access is a better solution than an all or nothing published state, in my opinion.

Worth exploring further.

Worth exploring indeed.

...

promote - remove. Let's move nodequeue into core and make a default "front page" queue. This more extensible.

This is an interesting way of doing it and allows many flexible things to be done.

...

sticky - remove. Again, let the nodequeue system decide what is first in the order.

Worth exploring indeed. I suggest we tackle one or two fields at a time though. Let's start with the moderate field. We all agree to remove the moderate-check from the SQL queries so we can start working on that. Chris offered to work on that. The one thing we don't agree on is whether we should remove the moderate-flag from the node table, or whether we should leave it in place for other modules to use. I'd prefer to remove it, but I don't mind leaving it in place if there are good reasons for. Let's move that discussion to the patch queue, as soon Chris comes up with a patch. So if Chris is going to work on the moderate-check, maybe someone else can focus on either: a. the status-flag (as well as figure out how we can offer a 'save as draft'-feature). b. exploring the benefits of caching frequently accessed fields in the node table. This thread (http://drupal.org/node/47702) makes for a good starting point to evaluate the usefulness of this approach, as well as to figure out what fields are worth caching. -- Dries Buytaert :: http://www.buytaert.net/

On 07 Jul 2006, at 16:14, Mark Fredrickson wrote:

actions - a solid API module that can be basis of many other modules workflow - a module that uses the actions system to really get things done. This could be the replacement for the "status" field (along with the node_access module of the user's choice) nodequeue - replace the homepage with a nodequeue views - i expect to hear a lot of +1s on this. Using this we could sort a nodequeue by sticky order and then nodequeue order. This answers the question below regarding "stickiness" of nodes in the nodequeue.

My list would be: * workflow * CCK * some node-level permission module * views * i18n None of these are ready for inclusion into core. In fact, none of the authors are actively working on getting them included (and that is OK). We're building a lightweight CCK module for core at http:// drupal.org/node/62340. Similarly, we could build a lightweight workflow, a lightweight views module (or just a views API), etc. I'd accept these for inclusion. Then, over time, we can migrate the more advanced features from the contributed modules to the core modules -- or let the contributed modules focus on the more advanced features (extending the core functionality). -- Dries Buytaert :: http://www.buytaert.net/

Gabor Hojtsy wrote:

On Fri, 7 Jul 2006, Mark Fredrickson wrote:

...

views - i expect to hear a lot of +1s on this. Using this we could sort a

Mark, don't expect it. It has an admittedly horrible user interface,

Trust me, that UI isn't horrible. It's complex and very limited by the technology, but if you want to see horrible go load up the 4.6 version.

Earl Miles wrote:

Mark Fredrickson wrote:

...

blogapi - I am under the impression that this breaks a lot. Is it worth

I use blogapi, and it works. It needs some expansion (Jeff Eaton did a patch for this but it wasn't accepted for 4.7 due to lateness; I think it needs to be reconsidered for 4.8 if it hasn't been already) but blogAPI is a Good Thing.

Sure, it is a good thing. But thats not sufficient for core IMO. We want core to be lean, and let the distributions handle most end user functionality. Distributions are possible now, and will be even easier once the install profiles hit.

...

blogapi - I am under the impression that this breaks a lot. Is it worth keeping in core?

I vote to remove it: * Our core audience isn't blog users. * We don't ship many other things that are very typical for blog installations, like a wysiwig editor, urlfilter.module, or Atom support. * It is unclear how blogapi will be supported by the future of Drupal, especially with CCK hitting core and, presumably, blog moving over to that. * There's only like one or two maintainers for it, right? I don't get the impression that a large part of the Drupal core developers give a crap about it. -- Morbus Iff ( in japan, i'm known as a puchi-iede. ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

...

* Our core audience isn't blog users.

...Or discussion boards, or download sites, or portal sites, or corporate PR people.

I'm fine with seeing forum.module and aggregator.module being removed too. "Download sites" and "corporate PR people" is ambiguous, so I'll just ignore those ones ;) -- Morbus Iff ( a blivet is 11 pounds of manure in a 10 pound sack ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

I think what is missing is a distinction between Core (mostly APIs), core modules (these use the APIs to provide "essential" services and are on the critical path for a new release, and contrib modules which provide other more niche services and are not on the critical path. For example I consider ecommerce to be core but many of its pieces to be contrib. _____ From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Konstantin Käfer Sent: Friday, July 07, 2006 5:03 PM To: development@drupal.org Subject: Re: [development] Modules for Core Hi, I'm fine with seeing forum.module and aggregator.module being removed too. I disagree with removing the forum.module. Drupal's slogan is "community plumbing" which actually implies that you can create a community site (WITH a forum) out of the box. Konstantin

On Fri, 07 Jul 2006 22:01:16 +0200, Morbus Iff <morbus@disobey.com> wrote:

...

...

* Our core audience isn't blog users. ...Or discussion boards, or download sites, or portal sites, or corporate PR people.

I'm fine with seeing forum.module and aggregator.module being removed too. "Download sites" and "corporate PR people" is ambiguous, so I'll just ignore those ones ;)

Aggregator out +1

On 08 Jul 2006, at 07:38, Jeff Eaton wrote:

Since it's turning into this discussion again, I figure I'll lay out what *I* think should be cut, and why.

I'm _not_ OK with removing the aggregator, forum module or poll module -- to name a few of the modules on Jeff's list. The only module I'd be happy to remove is the archive module. It's not about what modules you use or what modules you care about. It is all about trust. It looks like many of you underestimate the importance of core's quality label in terms of security, performance, upgradability, sustainability, consistency, etc. Many people don't trust contributed modules, and rightly so. After all, many of them are insecure, are not being updated in a timely fashion, or have inconsistent user interfaces (ie. They Cap Each Word In A Title -- which is super-annoying for some people). So having all these modules in core looks vital to me. Rather than removing all those modules, I'd like to see us improve them. Worse, I'd like to add more modules to core: image handling, node-level access, workflow, views, cck, i18n, etc. ;-) People continue to point out that install profiles will solve things. Maybe. First, install profiles and distributions are still vaporware. Secondly, it might take 1-2 years for an install profile or distribution to earn sufficient trust in terms of security, performance, upgradability, sustainability, consistency, etc. Picking a distribution's modules takes 20 minutes. Creating the distribution's .install-file takes 60 minutes. Maintaining and harnessing the distribution will take thousands of hours, and ultimately, is what gains you trust. Please stop missing the point. Thanks. :) -- Dries Buytaert :: http://www.buytaert.net/

On 08 Jul 2006, at 10:57, Boris Mann wrote:

So...once again, rather than lists, take actual steps like (dev) rolling patches or (community) defining/configuring/documenting great install profiles. Heck, no reason we can't ship with 3 install profiles that are mainly config bundles in core. Community, pro blogger, and brochureware seem like obvious choices.

Yes, that's my thinking too. We have a long way to go. Let's focus on getting the install system in first. -- Dries Buytaert :: http://www.buytaert.net/

Op zaterdag 8 juli 2006 11:15, schreef Dries Buytaert:

We have a long way to go.  Let's focus   on getting the install system in first.

I would love to work more on the "brochureware" part. But from what I have seen so far, the install profiles are still vapour. Hence I will continue developing that brochureware stuff outside of core-patches and, for now, without install profiles. And I hope -sincerely- others do that too. There already is a forum distro. Maintaining a blog distro is not hard (esp if you are an active blogger yourself) and We don't need install profiles to maintain distro's. Install profiles will only make that maintainance a tad simpler. But the actual Real Work, like making modules not conflict, weeding out security issues in modules you want to provide, endless tweaking of the Start-Off Configuration, needs no install profile. Take blog-distro: looking for the Perfect Solution For Inline Images will take you weeks. Its not a matter of installing a few modules. It requires tweaking, modifying, patching etc. A distro that is simply Drupal core with three extra nmodules in a tarball, is not a distro, IMO. It's the whole experience that counts. And that requires time, not an install system per-sé. Bèr [1] If install profiles are in, in 4.8, I am sure that they need at least another round of patches before we can actaully *use* it. At least, that is the impression I get from Fapi over time. It works, It is a tep forward, but it has a lot of annoying things (and don't say: where are your patches, because that is the worst part: I don't understand the underlying code so making Fapi patches is way over my head).

I think this point got dropped in the subsequent discussion:

1) Aggregator It's an awesome feature, but it's also far from universal. If the feed parsing API were separated from the admin ui/block generation/categories/etc, I would change my tune, though. Keep robust feed parsing, but let the front end live in contrib.

Let's ignore the front-end issue for now. Can we get a feed.inc? For starters it can just pull out the feed parsing from aggegrator - but it would be nice if it could also provide some feed generation features. eg. create_feed(array($node1, $node2, $node3)); I'll take a crack at it if people think it is worthwhile. -M

I know there is a general distaste for 3rd party libraries, but is there any interest in building on the work of an exisiting RSS/Atom parser? For example: http://simplepie.org The problem that I've seen with most GPL'd parsers is that they are classes, which is certainly not the "drupal way." Any recommendations? Any thoughts? Or should we just keep the homebrew solution? -M On 7/8/06, Earl Miles <merlin@logrus.com> wrote:

Mark Fredrickson wrote:

...

Let's ignore the front-end issue for now. Can we get a feed.inc? For starters it can just pull out the feed parsing from aggegrator - but it would be nice if it could also provide some feed generation features. eg. create_feed(array($node1, $node2, $node3));

I'll take a crack at it if people think it is worthwhile.

Personally, I do think it's worthwhile; this wouldn't *remove* aggregator from core (and in fact, I'd probably actually keep aggregator, just with most of it moved to feed.inc and then aggregator.module kept as a simple implementation of it) allowing contrib modules to utilize feed.inc and add fancy bells and whistles.

Op zaterdag 8 juli 2006 18:39, schreef Mark Fredrickson:

Let's ignore the front-end issue for now. Can we get a feed.inc? For starters it can just pull out the feed parsing from aggegrator - but it would be nice if it could also provide some feed generation features. eg. create_feed(array($node1, $node2, $node3));

Here is a feed.inc. Feel free to change it into a .inc and make it coreworthy. » http://cvs.drupal.org/viewcvs/drupal/contributions/modules/feedparser/ I, however, think its a better idea to first work on this module, outside core, a little more. So that we have something nice and something that has proven itself for core. BÈr

On Sat, 8 Jul 2006, Karoly Negyesi wrote:

...

* We don't ship many other things that are very typical for blog installations, like a wysiwig editor, urlfilter.module, or Atom support.

As I have just written a blog API client module, I can tell that the world is rushing towards Atom. So, providing an ancient API server is not bad, but not core worthy any more.

Think about the other end, the clients connecting to this blogger API server. There are a multitude of blogger API / metaweblog API / movabletype API clients. What about *Atom API* clients? Note to those quick reading, Atom API is not the Atom syndication format, but the publishing protocol. Gabor

The Blogger API is the Atom API with an addition for converting line breaks<http://code.blogger.com/archives/atom-docs.html#extensions>. So all the Blogger API clients *are* Atom API clients. On 7/8/06, Gabor Hojtsy <gabor@hojtsy.hu> wrote:

On Sat, 8 Jul 2006, Karoly Negyesi wrote:

...

...

* We don't ship many other things that are very typical for blog installations, like a wysiwig editor, urlfilter.module, or Atom support.

As I have just written a blog API client module, I can tell that the world is rushing towards Atom. So, providing an ancient API server is not bad, but not core worthy any more.

Think about the other end, the clients connecting to this blogger API server. There are a multitude of blogger API / metaweblog API / movabletype API clients. What about *Atom API* clients? Note to those quick reading, Atom API is not the Atom syndication format, but the publishing protocol.

Gabor

On 7-Jul-06, at 2:21 PM, Neil Drumm wrote:

Mark Fredrickson wrote:

...

blogapi - I am under the impression that this breaks a lot. Is it worth keeping in core?

I don't use this personally, but I think it is a good idea and should stick around in core.

I obviously use it, but I'm not wedded to it being in core... I'll happily maintain it in contrib if there's consensus that's where it should live. -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net

On 7/6/06, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:

There is no reason why a contrib module can't add flags of its own to the node table. The only drawback is that the module author would need to set/read the value through nodeapi.

Any such flags - be it the current moderate flag or any other one - suffers from the fact that db_rewrite_sql could be used to impose conditions on these flags, but there is no way to also select them.

A while back, I posted http://drupal.org/node/60853 - "hook_db_rewrite_sql should support SELECT and other clauses". I haven't had time to work on a patch for this, but if anyone else has the time and the motivation, then please post your patch to this issue thread. As I said in the post, I think that this feature would be a huge benefit to Drupal, in terms of performance, and in terms of developer-friendliness. Cheers, Jaza.

Op woensdag 5 juli 2006 16:00, schreef Khalid B:

shazamgallery/shazamgallery.module Uses it in its "views". To render "virtual" galleries, that do not show images in moderation.

xstatistics/xstatistics.module Shows a line in your statistics that tells you how many nodes are in moderation.

I suspect most of the listed modules use the moderation flag in a similar way: IE they won't really break if we remove the moderation flag. Bèr

Issue for removal of moderation flag from core SQL: http://drupal.org/node/72343 It looks like we are in agreement that I proceed to create a patch for this. Add any pertinent comments to the issue. ..chrisxj

warning: Invalid argument supplied for foreach() in /home/.makadisa/nynjtc/nynjtc.net/includes/form.inc on line 641. I am a newbie in this area so I might not have done all the setup necessary somewhere. To repeat this click on Administer/views and then the theme wizard tab. The select a view pulldown is empty. Also on the list tab the actions column is confusing having add | disable when it really seems to mean edit | disable.

I guess this means you have no views, and I didn't think to include default views in the list.

I noticed this same thing on the page that lists the content types. It does not list the builtin ones. I have not read the code, but the implication is that builtins in both views and content types are treated differently from user added ones, rather than getting a uniform treatment (and possibly smaller code for not having to special case them.)

...

Also on the list tab the actions column is confusing having add | disable when it really seems to mean edit | disable.

No, it definitely means add, not edit. That view is a default view, and when you actually use it, you'll get a *new* view that will override that default view.

Perhaps some explaination of this is needed somewhere. (It may already be somewhere unknown to me).