Moderation bit behavior
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. -- Neil Drumm http://delocalizedham.com/
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/
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.
Maybe I'm drifting off-topic here, The published / moderate thing and the possible interference between them seem to me sort of related to the "node draft feature" patch in http://drupal.org/node/48731 briefly : allowing a node to have draft versions, that is unpublished-yet-to-be-reviewed revisions ahead of the current published version) There seems to be a consensus on the fact this feature is wanted. The patch implements this by creating another "publication option" bit.(draft) I couldn't tell wether it's the best way to do it, but with the suppression of the "historical" moderation bit being mentioned here, I can't help but thinking there might be a good opportunity to re-think and enrich drupal publication mechanisms... Sorry if this is just me adding noise... I would really like the feature (if not the patch itself) to find its way to core one way or the other. Yched Dries Buytaert a ecrit le 04/07/2006 18:53:
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/
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/
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. ..chrisxj
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/
Dries Buytaert wrote:
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?
Book.module only uses the moderate bit to block new updates if it already is in moderation. Queue.module should keep track of the moderated nodes by itself. Cheers, Gerhard
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?
Just to tie two threads together, so to speak. *content_moderator* is a recent attempt by pwolanin to give drupal.org handbook editors the ability to process the moderation queue. More reading, if required. http://drupal.org/node/71456 Khalid B wrote:
... 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/
On 7/6/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:
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 can't speak for all the modules in that list, but as for the category module, it only uses the 'moderate' bit for reading/checking, and it only does so in order to be consistent with the book module. It's just adding cruft to the code, IMO, so I would be glad to be able to remove all traces of it. Cheers, Jaza.
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?
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.
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
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. 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 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. 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. 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. My (inflammatory) $.02, Mark Fredrickson E-Advocacy Manager Planned Parenthood Minnesota, North Dakota, South Dakota 1200 Lagoon Ave. Minneapolis, MN 55408 Ph: 612.821.6154 Fax: 612.825.3522 Email: mfredrickson@ppmns.org Are you a member of the Action Network? http://www.ppaction.org/ppmsd/join.tcl
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
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).
There is a difference here. In the case of user name it is redundant information denomralized for the sake of performance. For title, it reflects the current one used, so it is not redundancy per se.
I'd be in favour of a more flexible bitfield instead of all the single fields.
-1 More complexity in the code, plus hardcodes special meanings which we have today. It does not save much storage since we are talking of an additional int per row. Moreover, it would be hard or complex to select on a bit in the field, which is not a good database practice.
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.
On 05 Jul 2006, at 18:13, Earl Miles wrote:
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
That's over-engineering, IMO. 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. -- Dries Buytaert :: http://www.buytaert.net/
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.
Dries Buytaert wrote:
On 05 Jul 2006, at 18:13, Earl Miles wrote:
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
That's over-engineering, IMO.
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.
I didn't mean for these to be a single bit field, but each one would be its own field.
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
title - remove. Titles should be set by node modules (and stored where the body and teaser are), not stored in the node table.
Having the title in the node table saves a join when listing node titles for blocks and such. Most of accesses to titles are for the most current title, and not the historical ones, so keeping the title in node makes sense.
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.
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.
How about having the "sticky" node themed differently in a list? E.g. at the top of a taxonomy listing, the sticky node at the top will have a different background color? Can nodequeue do that?
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/
I'm forking the moderation bit discussion into a separate but related discussion of what modules should be in 4.8. Is there a pre-existing list of modules slated for inclusion (and possibly exclusion in the case of current core modules) from the core package? What conditions must be met for modules to be added or removed from core? If there is not an existing list, I might propose adding: 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. As to dropping tracker - views replaces this legacy - I don't use this - does anyone who used 4.7 use it? blogapi - I am under the impression that this breaks a lot. Is it worth keeping in core? I imagine people have their preferences as to modules. For my $.02 I would prefer to see more API type modules (eg. voting API) than functional modules (eg. buddylist - though I really like this module I don't think it should be in core). Let the flaming begin! -Mark
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.
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.
How about having the "sticky" node themed differently in a list? E.g. at the top of a taxonomy listing, the sticky node at the top will have a different background color? Can nodequeue do that?
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/
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, which should be worked on. It is nice, I have some experience with it, but it is still rocket science to master. Gabor
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.
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.
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.
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. -- Neil Drumm http://delocalizedham.com/
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.
* We don't ship many other things that are very typical for blog installations, like a wysiwig editor, urlfilter.module, or Atom support.
This is very true. I still believe that Drupal For Bloggers could be one of the easiest Drupal 'distros' to assemble. Blogapi would/could be an integral part of that.
* 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.
"Badly," that's how. There are already hitches -- For example, modules that add elements to the node form, and depend on 'default' values, will never work properly with blogapi as it currently stands. That's a problem outside blogapi's scope, though -- it's the 'programmatic creation of nodes' issue that we all grapple with until FormAPI 2, The Gathering, ships.
* 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.
Lots of Drupal core developers don't give a crap about other important things. ;) I think blogapi is very important -- not just for bloggers, but for anyone who wants to use some of the widely available tools for posting/editing content. But I do agree that it is a better fit for a contrib module and a 'blogging' distribution/installer profile. --Jeff
* 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
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
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
Again, though, the issue is that forums are one feature of one kind of community. I've set up almost a dozen drupal sites and only three used forums. Six used blogging features, four included content aggregation. Ten needed the links.module APIs. This all comes back to the question we've talked about before: what is 'core'? I think that focusing on APIs, infrastructure, and toolkits in 'core' is the best bet. Repackaging the current lineup of 'core' modules as a Drupal install profile, perhaps a 'turnkey web community', is the approach we need to move towards. Obviously, just my $.02. --Jeff -----Original Message----- From: Konstantin Käfer [mailto:kkaefer@gmail.com] Sent: Friday, July 07, 2006 4: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
Since it's turning into this discussion again, I figure I'll lay out what *I* think should be cut, and why. 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. 2) Archive Better modules already exist in contrib, and other solutions (like events + views) also provide a really robust replacement. 3) Blog Again, this one is really made for 'multi-blogging' and not single-user blogging. It belongs in a blogging-specific distro. 4) Blogapi As others have said, this is really cool but really belongs in contrib and the install profiles that need it. Core support for more flexible protocols like Atom (?) might be better. 5) Forum Only useful to a specific subset of Drupal sites, and needs some love and attention anyhow. 6) Page and Story These are both eclipsed by chx's 'pave the way for cck' patch. Double plus awesome on that patch. 7) Ping Does this still work? It's blog specific anyhow, and doesn't work well conceptually with non-blog sites. 9) Tracker This works, but most sites need different displays. For contrib, Views does it better. 10) Legacy This is only useful if you're upgrading from specific old versions of Drupal. It should be a convenience module that lives in contrib, not an integral part of core. 11) Book The dedicated content type is already being stripped away by chx's 'pave the way for cck' patch, which is great. The outlining tools would be really nice to include as a tool for building rigid navigation hierarchies. 12) Poll 'Nuff said. It's neat, but very limited and of use on a relatively small cross-section of sites. There are a number of good patches for it in the queue, and others have volunteered to pick it up if it moves out of core. All of these modules couldbe rolled into a 'Drupal Classic' install profile, and subsets could be rolled into 'blogging' profiles. The result would be a 'core' that's actually core. That is all. Thank you. Please return to your regularly scheduled discussion about blogapi. --Jeff
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 7/8/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:
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.
+1...or rather, replace it with an improved version: especially with something like Drupal (everything is a slice and dice of content that lives in the DB), browsing by date out of the box is a useful feature. Yes, views does a good job. Anybody want to take a crack at a minimal views.inc that takes care of this + tracker? It's not about what modules you use or what modules you care about.
It is all about trust.
Yes! People continue to point out that install profiles will solve
things. Maybe.
They are one direction that currently look good. I, as a long time supporter/promoter of install profiles, also stress the "maybe"...people need to step up and take a crack at creating them. Ideally, a great dev combined with a passionate community leader (blogging, education, etc.) can really make things happen. 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. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
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/
I agree. For all my pique in firing off that list, I think it would be a mistake to simply pull stuff out of core *without* all the pieces in place (install profiles, etc) to make the transition smooth. --Jeff -----Original Message----- From: Dries Buytaert [mailto:dries.buytaert@gmail.com] Sent: Saturday, July 08, 2006 4:15 AM To: development@drupal.org Subject: Re: [development] Modules: The Hit List 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).
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.
that sounds nice, but in practice I doubt it will work. the modules that a pro blogger will want won't all be in core. same for brochureware and community. those will be crippled distributions. the notion that drupal.org becomes a major distributor is lousy IMO. i prefer the linux kernel model with distros like red hat and suse and such anyway, enough debate about vaporware. the install patch is here: http://drupal.org/node/68926. There has been no progress in a couple weeks so lets try to push it forward.
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
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.
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.
Ok. The patch is in the queue: http://drupal.org/node/72915 Basically a cut 'n' paste job, but it's a start. Reviews, criticism welcome. -mark 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
> I vote to remove it: I concur.
* Our core audience isn't blog users.
Once it was. Or so I think :)
* 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.
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
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?
I know at least a Drupal module I written yesterday and today :D
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
Ehem, hem, hem ehem... | The Atom API is a specification that leverages the Atom feed | format in a content editing API. Look for Atom feed format support in blogapi.module. Read this for comparision of the APIs supported now by blogapi.module and the Atom API: http://www.xml.com/lpt/a/2003/10/15/dive.html Then search for [desktop] clients supporting the Atom API (there are a few). Goba On Sat, 8 Jul 2006, Corey Bordelon wrote:
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
And, in my experience, it doesn't break any more than any other core modules do. Because of the limitations of programmatic node creation and the remote blogging protocols themselves, it *is* limited in the kinds of content it can create remotely -- making polls, for example, doesn't work too well. --Jeff -----Original Message----- From: James Walker [mailto:walkah@walkah.net] Sent: Friday, July 07, 2006 7:30 PM To: development@drupal.org Subject: Re: [development] Modules for Core 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.
On Wednesday 05 July 2006 10:00, Khalid B wrote:
hof/hof.module links/links_weblink.module
These two are my modules, and I can tell you that I don't really "use" the moderation bit per se and could easily remove the references to it. In Hall of Fame (hof.module), I had a request from a user who wanted the bit respected when checking whether nodes were counted as "published" or not yet released, so I added it to the query. If the bit goes away, I'll just drop that column from my query. One-line patch. :-) In links_weblink, the only reason for its presence is that I create a node from scratch and needed to initialize this bit along with the others based on workflow defaults for the node type. Again, if the bit goes away, so does my need to initialize it. I don't have strong feelings on the issue one way or the other, but I can say that taking away the moderation bit won't cause any significant problem for these two modules, because they don't really exploit the functionality that the moderation bit was intended to provide. They only touch it in passing. Scott -- ------------------------------------------------------------------------------- Syscrusher (Scott Courtney) Drupal page: http://drupal.org/user/9184 syscrusher at 4th dot com Home page: http://4th.com/
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
Dries Buytaert wrote:
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/
It means that those modules will need to maintain their own table if they don't already. They will need to join to this table in order to provide a queue listing. Not too expensive I think ... The admin/node option for viewing the moderation queue goes away and gets replaced by these various contrib modules. I can't think of other drawbacks. I think this is a good thing. Chris - I think a patch is in order, and we can review from there.
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
Right now we have an inconsistency with our moderation bit.
I noticed a problem with scheduler module that automatically published (set status) without regards to the moderation flag. I provided a patch to fix that, but at the time it seemed odd to have two flag fields that control visibility. I would have thought a status int would have been better and have say ==0 meaning published and non zero specifying a "state" it was in that modules could use in some way? regards --AjK
The issue for this is over at http://drupal.org/node/71730.
ref: http://drupal.org/node/61495 http://drupal.org/node/52545#comment-101755
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.
Walt Daniels wrote:
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.
I guess this means you have no views, and I didn't think to include default views in the list.
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. Please file bug reports as issues against Views ( http://drupal.org/node/add/project_issue/views ) -- when sent to the list they're just noise that I might not even see, and even though I happened to see this one (because you did a reply-to one of my posts so it appears it's in a thread completely unrelated to what you're talking about) there's a good chance I'll forget it by the time I get back around to fixing stuff like this.
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).
participants (25)
-
AjK -
Boris Mann -
Bèr Kessels -
Chris Johnson -
Corey Bordelon -
Dries Buytaert -
Earl Miles -
Gabor Hojtsy -
Gerhard Killesreiter -
James Walker -
Jeff Eaton -
Jeremy Epstein -
Karoly Negyesi -
Khalid B -
Konstantin Käfer -
Laura Scott -
Mark Fredrickson -
Mark Fredrickson -
Morbus Iff -
Moshe Weitzman -
Neil Drumm -
sime -
Syscrusher -
Walt Daniels -
Yves CHEDEMOIS