- Development - lists.drupal.org

[drupal-devel] Re: [contributions:mathias] /modules/tinymce INSTALL.txt
by Brian Hay 15 Apr '05

15 Apr '05

drupal-cvs(a)drupal.org wrote: > Log message: > * This module only works the CVS version of TinyMCE. See this file for more details. What has changed with this version? Readme doesn't say. I'm having a problem with 1.43 (issue here: http://drupal.org/node/20478) Although TinyMCE docs and forum seem to imply that it creates <strong> and <em> instead of <b> and <i>, I am still getting the deprecated tags. I've created a drupal input filter as advised in the readme but this didn't prevent the problem. Any ideas? -- Regards, Brian.

2 1

[drupal-devel] Proposal: change "fixed" status to mean "ready to commit"
by Nedjo Rogers 14 Apr '05

14 Apr '05

A patch I proposed nine weeks ago to improve project the project issue review process went nowhere. Issue: http://www.drupal.org/node/17052 Patch: http://drupal.org/files/issues/admin_configurable_status_options.patch But (not to be deterred, since I still believe barriers to community participation in the development process are the most pressing issues in Drupal development) I have another, much more modest suggestion, that I think could help move things along without (gasp) changing code. The problem: there is no way for qualified Drupal developers to push patches up the queue, or in other words to designate a patch as meeting acceptance criteria. Patches sit at "patch" status indefinitely, waiting until one of the three CVS committers personally reviews and accepts (or denies) them, setting the status then to "fixed" (or "won't fix"), which in many cases never happens. My proposal: that we change "fixed" to mean "ready to commit" or "meets acceptance criteria (i.e., works as promised and is a worthwhile change fitting with Drupal aims and principles)". That way, qualified developers can designate a patch as ready to apply. If it is applied, the CVS committer would set the status to "closed". This change would be consistent with e.g., bugzilla on mozilla, where "fixed" is set before a change is applied, and preceeds final review and application. A full solution? No. A valuable start, and much better than doing nothing? I think, yes. -------- Nedjo Rogers Learning Technologies Developer GroundWorks Learning Centre (250) 360-0799 nedjo(a)gworks.ca

3 3

[drupal-devel] OT: Chronicle of Philanthropy: Events Seek to 'Demystify' Open-Source Software
by Chris Messina 14 Apr '05

14 Apr '05

There was a nice write-up in the Chronicle of Philanthropy about the Bay Area PenguinDay. It can be found at http://philanthropy.com/premium/articles/v17/i12/12004801.htm, and for those without a subscription, it's posted below. During the SpeedGeek session (http://penguinday.blueoxen.net/cgi-bin/wiki.pl?CivicSpaceSpeedGeekingSession) I presented CivicSpace and talked up Drupal to non-profits who were very excited about its potential for their organizations. I also wrote up a brief blog entry about this: http://civicspacelabs.org/home/blog/chris/attending-penguinday Chris Events Seek to 'Demystify' Open-Source Software By Nicole Wallace A series of events this spring will bring together charity technology employees, consultants, and software developers to discuss the potential -- and the challenges -- of developing open-source software. "We want to demystify open-source software for nonprofit organizations," says Katrin Verclas, co-director of Aspiration, an Amherst, Mass., nonprofit group that seeks to create a software landscape in which charities have access to good-quality, low-cost tools that help them do their work. Open-source software gives users access to the "source code" of an application, which allows organizations to make changes or enhancements to fit their needs. Developers of such software encourage users to modify the programs and to share them with others. Aspiration is working with local technology charities to sponsor the gatherings, called Penguin Days after the mascot of the open-source giant Linux. Penguin Day Chicago took place on March 26, and events are scheduled in the San Francisco Bay Area on April 12, and in New York on May 7. Many nonprofit organizations have very specific software needs, but the market of potential customers that share those needs is too small for commercial software companies to build those products, says Ms. Verclas. She says charities that need to develop such specialized tools can cut their costs by adapting open-source software, rather than starting from scratch. The transparency of open-source software code can also be vital to organizations that handle sensitive information, such as international groups investigating human-rights abuses. "With open source, you can look at the code and see if there are any back doors someone could use to try to get in," says Ms. Verclas. But significant barriers keep nonprofit organizations from widely adopting open-source software. Charities' limited capacity to develop software and open-source software's tendency to be less well-documented and user-friendly than proprietary software have combined to make open source a daunting choice for nonprofit organizations, says Ms. Verclas. For nonprofit groups to be able to take advantage of the promise of open-source software, she says, technology organizations will have to develop, enhance, and support open-source tools for charities. For more information: Go to http://www.penguinday.org.

1 0

[drupal-devel] [feature] View blocks by roles
by tostinni 14 Apr '05

14 Apr '05

Issue status update for http://drupal.org/node/12988 Project: Drupal Version: cvs Component: block.module Category: feature requests Priority: normal Assigned to: tostinni Reported by: tostinni Updated by: tostinni Status: patch In fact this was the way how was working my first patch, but then drumm advice me to go ahead with the block_visibility table, that's done with last version. Any more improvement ? tostinni Previous comments: ------------------------------------------------------------------------ November 15, 2004 - 17:35 : tostinni Attachment: http://drupal.org/files/issues/block_0_0.patch (5.45 KB) After the release of drumm's work about new block.module in CVS : Make block configuration understandable [1] and another comment : Set blocks to be hidden from anonymous users. [2], I decided to create a little patch to allow use of 'roles' for 'blocks'. So my patch provide a set of checkboxes in block configure (the new field drumm has setting up) that allow roles to see a block. Way it works : 1. If no roles set, block is visible by everybody. If some roles are set, only users with at least one of the roles can see the block. 2. Database : As I'm not sure this block will be included in core because a team is working on it (see Drupal 4.6 roadmap [3] - I will post a comment on civiclabs site), I just set up a new field 'roles' in blocks table. So when you modify the roles of a block, it just update this field with a concatenation of roles_id separated by comma. I'm conscient it's quite ugly, but if this patch find his public, I was thinking in creating a new table block_roles (as done for user_roles). Also update.inc isn't updated for the reasons mentioned above. Well I hope your comments. [1] http://drupal.org/node/11875 [2] http://drupal.org/node/12168 [3] http://drupal.org/node/12202 ------------------------------------------------------------------------ November 15, 2004 - 19:55 : drumm You use user_roles(1) which, if I understand that function correctly, removes the anonymous user role from the list. I think that this should be included. Use case: you want information for non-logged in users which is useless to those who are logged in. Watch your editor's use of tabs instead of spaces. It can and should be included. I haven't started work on this, and it saves me a lot of time if I have patches such as this to review. Why not have all the boxes checked by default to indicate visible to everyone instead of none checked? I would even support adding a validate step to make sure at least one is checked (probably belongs in another patch). I think another table is the way to go. Then you could even write the test for visibility by role to that query in block_list() instead of a loop in php. ------------------------------------------------------------------------ November 15, 2004 - 20:49 : tostinni Hi, Thanks for your feedback. Well a few mistakes (tabs, my editor is now configured, and user_roles(0)) I will correct in next patch. A little comment : for the moment I choosed NULL value for everybody if not, we face a few problems : - if the admin add a new role, it won't be asigned the right to view blocks with the "everybody" grant. - also if people import their blocks or if they apply this patch with a site containing blocks settings, they would be invisble unless explicitly allowed. That's why I considered this option, but if you prefer, I can select all checkboxes. For the validate step, I was thinking of it, but for the moment and the design, It was useless. Regarding of the table, the only issue I was contempling, was the lack of a block_id in blocks table, so I would have to create one. Are you ok with that ? ------------------------------------------------------------------------ March 13, 2005 - 15:37 : killes(a)www.drop.org New patch needed nased on drumm's feedback. ------------------------------------------------------------------------ April 11, 2005 - 19:02 : tostinni Attachment: http://drupal.org/files/issues/block_visibility.patch (8.09 KB) Hi, Sorry for the delay, here is the new patch based on current CVS. *Observations :* - I created a new table : block_visibility that store the visibility for each role / block When you update db scheme it would make visible blocks for all your availables roles, i.e. it changes nothing ;), just set up correctly permissions. - When you configure blocks, you will see a set of checkboxes to allow block to be visible regarding of the user's roles. If no role checked, nobody will see it. *Know bugs (by design ?) :* - When a custom block is created it receives no permissions, it means that it would be invisible unless you configure role in "configure" screen. I'm aware of this problem, but I still don't now how to deal with it. The major issue is that I can't predict which id will be inserted in 'boxes' table as it works with auto_increment / SERIAL columns instead of Drupal own sequence table. We can work around it, but I'm not sure it's a good solution to change this, it would cause a lot of troubles... Maybe look for a db_insert_id function ? Any ideas ? For the moment, the user have to grant permissions to role to be able to see custom block. *To do :* - Add visibility rehash in _block_rehash function. - Change help messages ? - Does my queries look nice ? (It works for sure, but is it a good way to write a join : FROM blocks b LEFT JOIN role r ON 1 = 1 ? ) - Others suggestions ? ------------------------------------------------------------------------ April 12, 2005 - 13:59 : drumm "When a custom block is created it receives no permissions, it means that it would be invisible unless you configure role in "configure" screen. " It should probably display the checkboxes for permissions on the block creation screen. All checkboxes check by default. "The major issue is that I can't predict which id will be inserted in 'boxes' table as it works with auto_increment / SERIAL columns instead of Drupal own sequence table. " It really should use Drupal's sequesnces table. You can safely ignore any auto increment or SERIAL. Just use db_next_id as usual. "- Does my queries look nice ? (It works for sure, but is it a good way to write a join : FROM blocks b LEFT JOIN role r ON 1 = 1 ? ) " I've never seen the INSERT ... SELECT syntax elsewhere in Drupal. This may mean that it is not Postgres-compatible or it is avaided for other reasons. A real join condition should be used, such as r.rid = v.rid. ------------------------------------------------------------------------ April 12, 2005 - 18:51 : tostinni "It should probably display the checkboxes for permissions on the block creation screen. All checkboxes check by default. " I was thinking of this issue, it's just that I didn't find out how to display it without redundancy between form's groups from block_box_form and from block_block, it's done now. "It really should use Drupal's sequesnces table. You can safely ignore any auto increment or SERIAL. Just use db_next_id as usual. " Ok, I will make the changes. "I've never seen the INSERT ... SELECT syntax elsewhere in Drupal. This may mean that it is not Postgres-compatible or it is avaided for other reasons. " Well INSERT ... SELECT syntax is part of SQL ANSI 92 and fully implemented in Postgre. I couldn't find since when, but at least since 6.4 version [4] of Postgre. So I think it's good enough. And maybe if no drupal developer ever used it, it's maybe they never needed it ;) Btw, if there's any limitation not to use it, who can tell me ? "A real join condition should be used, such as r.rid = v.rid. " I've done this on purpose : - If I'm modifying the block options and a new role has been added posterior to the block. Now I got a sort of inconsistance in my block_visibility table, because I miss this new role_id for the (module, delta) tuple. So when I'm reviewing/modifying my block configuration, I need to detect this inconsistence to be able to add this new (module, delta, rid) tuple in block_visibility. This is made doing a JOIN between role and blocks with this strange condition : 1=1 because they don't have a commun column. The other reason I've done it this way is because my MySQL documentation told me to prefer LEFT JOIN to RIGHT JOIN for compatibility. What do you think about it ? Should I use RIGHT JOIN without fear ? It would gives us : SELECT r.rid, v.visible FROM blocks b LEFT JOIN block_visibility v ON v.module = b.module AND v.delta = b.delta RIGHT OUTER JOIN role r ON r.rid = v.rid WHERE b.module = '%s' AND b.delta = '%s' and works the same way. Tomorrow I'll post my changes. [4] http://www.postgresql.org/docs/6.4/static/sql-insert.htm ------------------------------------------------------------------------ April 13, 2005 - 18:47 : tostinni Attachment: http://drupal.org/files/issues/block_visibility_0.patch (9.95 KB) Ok here is the new version including these changes : - based on latest CVS version - I created a new function _block_roles_save to handle saving roles - when a new custom block is created, it automatically selects all availables roles (user can change it) and save it - it also handles drupal sequence system for boxes table to allow insertion of the roles next to the custom block creation Still pending : make a _block_roles_rehash. Well I'm not very sure about this one, because it would generate a lot of queries : number of rows in blocks table x num in role _block_rehash works this way, but is it reasonnable ? If _block_rehash is needed not to display blocks that doesn't exists anymore, _block_roles_rehash is only here to clean the block_visibility table, but there won't be any problem with new or missing roles, block would just respect current roles. What should I do ? ------------------------------------------------------------------------ April 14, 2005 - 05:07 : Bèr Kessels Nice feauture. Nice interface, no clutter. But a big -1 on the way you use the database. This can be done much easier by adding a single column in the existing block table. Why introduce a new table and a lot of extra sql queries, update qeuries etc? Bèr ------------------------------------------------------------------------ April 14, 2005 - 05:13 : killes(a)www.drop.org Ber: I am not sure how you do want to add visibility per role through a single column in the existing table. Can you elaborate? What I'd like to see would be block IDs that aren't only defined through the modules. Ie like the menu module handles them. ------------------------------------------------------------------------ April 14, 2005 - 11:53 : drumm The data would not fit in one column, we would end up having serialized or comma separated values which would require parsing by regexp or expansion in php on block viewing. Normalizing data in the database is always better (except for caching).

1 0

[drupal-devel] Detecting table existence/absence in a Drupally-correct way
by Syscrusher 14 Apr '05

14 Apr '05

Good evening! Is there a well-behaved way to use Drupal's DB abstraction to find out if a table exists? I'm working on a migration feature, and need to be able to detect the existence of the table so that I can issue a user-friendly "you don't need to do this step" message if the table isn't there. The obvious thing to try was calling @db_query() to try to suppress the error message. That does what I need, but puts the database error into the output shown to the user. Since I know what is the specific situation, I want to suppress that output for this call only, without overriding the site-wide setting that causes errors to go only into the log. (Ideally, this particular error doesn't belong in the log, either, since I essentially am generating it on purpose). It might be worth adding a new parameter to db_query() and db_queryd() in the HEAD version to allow this sort of error suppression, in cases like mine where the calling code wants to explicitly take responsibility for error handling. And I know this isn't a trivial thing across databases, but..."Boy, it sure would be nice if there was a way to ask Drupal for a list of names of all the tables that exist in the database." :-) I think I have some code lying about that does this (though not in the Drupal environment) which worked with at least PostgreSQL and MySQL and (if I recall) ODBC. If it's of interest to someone, I'll try to dig it up and look at porting it into Drupal. Before I put in that effort, though, I'd like to have some indication of whether or not it was likely that kind of code would be accepted into core. Comments/suggestions welcome. Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott(a)4th.com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher

5 8

[drupal-devel] [feature] View blocks by roles
by drumm 14 Apr '05

14 Apr '05

Issue status update for http://drupal.org/node/12988 Project: Drupal Version: cvs Component: block.module Category: feature requests Priority: normal Assigned to: tostinni Reported by: tostinni Updated by: drumm Status: patch The data would not fit in one column, we would end up having serialized or comma separated values which would require parsing by regexp or expansion in php on block viewing. Normalizing data in the database is always better (except for caching). drumm Previous comments: ------------------------------------------------------------------------ November 15, 2004 - 16:35 : tostinni Attachment: http://drupal.org/files/issues/block_0_0.patch (5.45 KB) After the release of drumm's work about new block.module in CVS : Make block configuration understandable [1] and another comment : Set blocks to be hidden from anonymous users. [2], I decided to create a little patch to allow use of 'roles' for 'blocks'. So my patch provide a set of checkboxes in block configure (the new field drumm has setting up) that allow roles to see a block. Way it works : 1. If no roles set, block is visible by everybody. If some roles are set, only users with at least one of the roles can see the block. 2. Database : As I'm not sure this block will be included in core because a team is working on it (see Drupal 4.6 roadmap [3] - I will post a comment on civiclabs site), I just set up a new field 'roles' in blocks table. So when you modify the roles of a block, it just update this field with a concatenation of roles_id separated by comma. I'm conscient it's quite ugly, but if this patch find his public, I was thinking in creating a new table block_roles (as done for user_roles). Also update.inc isn't updated for the reasons mentioned above. Well I hope your comments. [1] http://drupal.org/node/11875 [2] http://drupal.org/node/12168 [3] http://drupal.org/node/12202 ------------------------------------------------------------------------ November 15, 2004 - 18:55 : drumm You use user_roles(1) which, if I understand that function correctly, removes the anonymous user role from the list. I think that this should be included. Use case: you want information for non-logged in users which is useless to those who are logged in. Watch your editor's use of tabs instead of spaces. It can and should be included. I haven't started work on this, and it saves me a lot of time if I have patches such as this to review. Why not have all the boxes checked by default to indicate visible to everyone instead of none checked? I would even support adding a validate step to make sure at least one is checked (probably belongs in another patch). I think another table is the way to go. Then you could even write the test for visibility by role to that query in block_list() instead of a loop in php. ------------------------------------------------------------------------ November 15, 2004 - 19:49 : tostinni Hi, Thanks for your feedback. Well a few mistakes (tabs, my editor is now configured, and user_roles(0)) I will correct in next patch. A little comment : for the moment I choosed NULL value for everybody if not, we face a few problems : - if the admin add a new role, it won't be asigned the right to view blocks with the "everybody" grant. - also if people import their blocks or if they apply this patch with a site containing blocks settings, they would be invisble unless explicitly allowed. That's why I considered this option, but if you prefer, I can select all checkboxes. For the validate step, I was thinking of it, but for the moment and the design, It was useless. Regarding of the table, the only issue I was contempling, was the lack of a block_id in blocks table, so I would have to create one. Are you ok with that ? ------------------------------------------------------------------------ March 13, 2005 - 14:37 : killes(a)www.drop.org New patch needed nased on drumm's feedback. ------------------------------------------------------------------------ April 11, 2005 - 18:02 : tostinni Attachment: http://drupal.org/files/issues/block_visibility.patch (8.09 KB) Hi, Sorry for the delay, here is the new patch based on current CVS. *Observations :* - I created a new table : block_visibility that store the visibility for each role / block When you update db scheme it would make visible blocks for all your availables roles, i.e. it changes nothing ;), just set up correctly permissions. - When you configure blocks, you will see a set of checkboxes to allow block to be visible regarding of the user's roles. If no role checked, nobody will see it. *Know bugs (by design ?) :* - When a custom block is created it receives no permissions, it means that it would be invisible unless you configure role in "configure" screen. I'm aware of this problem, but I still don't now how to deal with it. The major issue is that I can't predict which id will be inserted in 'boxes' table as it works with auto_increment / SERIAL columns instead of Drupal own sequence table. We can work around it, but I'm not sure it's a good solution to change this, it would cause a lot of troubles... Maybe look for a db_insert_id function ? Any ideas ? For the moment, the user have to grant permissions to role to be able to see custom block. *To do :* - Add visibility rehash in _block_rehash function. - Change help messages ? - Does my queries look nice ? (It works for sure, but is it a good way to write a join : FROM blocks b LEFT JOIN role r ON 1 = 1 ? ) - Others suggestions ? ------------------------------------------------------------------------ April 12, 2005 - 12:59 : drumm "When a custom block is created it receives no permissions, it means that it would be invisible unless you configure role in "configure" screen. " It should probably display the checkboxes for permissions on the block creation screen. All checkboxes check by default. "The major issue is that I can't predict which id will be inserted in 'boxes' table as it works with auto_increment / SERIAL columns instead of Drupal own sequence table. " It really should use Drupal's sequesnces table. You can safely ignore any auto increment or SERIAL. Just use db_next_id as usual. "- Does my queries look nice ? (It works for sure, but is it a good way to write a join : FROM blocks b LEFT JOIN role r ON 1 = 1 ? ) " I've never seen the INSERT ... SELECT syntax elsewhere in Drupal. This may mean that it is not Postgres-compatible or it is avaided for other reasons. A real join condition should be used, such as r.rid = v.rid. ------------------------------------------------------------------------ April 12, 2005 - 17:51 : tostinni "It should probably display the checkboxes for permissions on the block creation screen. All checkboxes check by default. " I was thinking of this issue, it's just that I didn't find out how to display it without redundancy between form's groups from block_box_form and from block_block, it's done now. "It really should use Drupal's sequesnces table. You can safely ignore any auto increment or SERIAL. Just use db_next_id as usual. " Ok, I will make the changes. "I've never seen the INSERT ... SELECT syntax elsewhere in Drupal. This may mean that it is not Postgres-compatible or it is avaided for other reasons. " Well INSERT ... SELECT syntax is part of SQL ANSI 92 and fully implemented in Postgre. I couldn't find since when, but at least since 6.4 version [4] of Postgre. So I think it's good enough. And maybe if no drupal developer ever used it, it's maybe they never needed it ;) Btw, if there's any limitation not to use it, who can tell me ? "A real join condition should be used, such as r.rid = v.rid. " I've done this on purpose : - If I'm modifying the block options and a new role has been added posterior to the block. Now I got a sort of inconsistance in my block_visibility table, because I miss this new role_id for the (module, delta) tuple. So when I'm reviewing/modifying my block configuration, I need to detect this inconsistence to be able to add this new (module, delta, rid) tuple in block_visibility. This is made doing a JOIN between role and blocks with this strange condition : 1=1 because they don't have a commun column. The other reason I've done it this way is because my MySQL documentation told me to prefer LEFT JOIN to RIGHT JOIN for compatibility. What do you think about it ? Should I use RIGHT JOIN without fear ? It would gives us : SELECT r.rid, v.visible FROM blocks b LEFT JOIN block_visibility v ON v.module = b.module AND v.delta = b.delta RIGHT OUTER JOIN role r ON r.rid = v.rid WHERE b.module = '%s' AND b.delta = '%s' and works the same way. Tomorrow I'll post my changes. [4] http://www.postgresql.org/docs/6.4/static/sql-insert.htm ------------------------------------------------------------------------ April 13, 2005 - 17:47 : tostinni Attachment: http://drupal.org/files/issues/block_visibility_0.patch (9.95 KB) Ok here is the new version including these changes : - based on latest CVS version - I created a new function _block_roles_save to handle saving roles - when a new custom block is created, it automatically selects all availables roles (user can change it) and save it - it also handles drupal sequence system for boxes table to allow insertion of the roles next to the custom block creation Still pending : make a _block_roles_rehash. Well I'm not very sure about this one, because it would generate a lot of queries : number of rows in blocks table x num in role _block_rehash works this way, but is it reasonnable ? If _block_rehash is needed not to display blocks that doesn't exists anymore, _block_roles_rehash is only here to clean the block_visibility table, but there won't be any problem with new or missing roles, block would just respect current roles. What should I do ? ------------------------------------------------------------------------ April 14, 2005 - 04:07 : Bèr Kessels Nice feauture. Nice interface, no clutter. But a big -1 on the way you use the database. This can be done much easier by adding a single column in the existing block table. Why introduce a new table and a lot of extra sql queries, update qeuries etc? Bèr ------------------------------------------------------------------------ April 14, 2005 - 04:13 : killes(a)www.drop.org Ber: I am not sure how you do want to add visibility per role through a single column in the existing table. Can you elaborate? What I'd like to see would be block IDs that aren't only defined through the modules. Ie like the menu module handles them.

1 0

[drupal-devel] Re: CVS question: Multiple branch tags on a module
by Sheldon Rampton 14 Apr '05

14 Apr '05

I wrote: > > However, the 4.5 branch still doesn't appear as the "latest >> release" when I go to the project page: >> >> http://drupal.org/project/interwiki >> >> If people click on the "download latest release," they still get an >> old version of the module rather than the current version. What can > > I do to fix this? And Jim Riggs replied: >It looks like you just committed changes over an hour ago. There is >a script that runs on the server that packages the tar.gz files every >6 hours (I think). Wait a few hours and check it again. It will get >updated. OK, I waited and Jim was right. The tar.gz file now reflects my commit. The only thing now is that the project page still lists December 31, 2004 as the "latest release" date. This is a minor detail, of course. My main concern was making a current version available for download, and that's now accomplied. However, is there any way to get the latest release date changed on the project page? --Sheldon Rampton

3 2

[drupal-devel] [bug] Failure to respect node status upon editing (reverts to default)
by killes 14 Apr '05

14 Apr '05

Issue status update for http://drupal.org/node/7940 Project: Drupal Version: cvs Component: node system Category: bug reports Priority: normal Assigned to: mathias Reported by: mathias Updated by: killes(a)www.drop.org Status: patch Some people think, that the node settings _should_ be reset after editing. There are good reasons for some of the settings to be reset, for exampel in case of the "promote" bit. I cannot see such reasons in case of the "comment" bit and would like to see that part of the patch included. killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ May 21, 2004 - 04:00 : mathias How to recreate: 1. As admin, navigate to: administer » content » settings, and uncheck 'publish' for stories. 2. As admin, create a story and assign it to a user that can create and maintain their own stories, say this user's name is Mark. 3. Login as Mark and edit that story. 4. Instead of staying published, it reverts back to it's unpublished state. I think this behavior is a bug as these content settings are default settings and should only be applied during node creation (not editing). I know Drupal-contrib project owners get bitten with this everytime they edit their project pages. I'll work on a patch within the next day. ------------------------------------------------------------------------ May 21, 2004 - 16:59 : mathias Attachment: http://drupal.org/files/issues/node_defaults.patch (1.05 KB) Proposed solution: If a node is being updated: respect the following existing settings: 1. node status (published/unpublished) 2. node promotion (promoted on front page) 3. node static (static on front page) For any node, force the defaults for: 1. moderation 2. revisions With our current situation, say the admin makes 'promote to front page' and 'static on front page' the default settings for stories. Another user posts a story and bam! it's of course immediately visible. The admin decides he/she doesn't like that story and demotes it. Well as soon as that user edits his story, the default settings are re-assigned and his post is right back on the front page. ------------------------------------------------------------------------ August 3, 2004 - 20:38 : mathias Attachment: http://drupal.org/files/issues/node_defaults_0.patch (1.19 KB) When editing nodes, the following node properties should not be overwritten - node status (published/unpublished) - node promotion (promoted on front page) - node sticky (top of the list) Currently, if the author of a node doesn't have 'administer node' privileges, than the above settings will always revert to the default behavior of their node type group. This makes nodes disappear and node authors very very confused. ------------------------------------------------------------------------ August 3, 2004 - 20:56 : ccourtne Don't forget to take moderation into account. If a node is edited should it go back through moderation? Some sites may want the behavior of going back some sites may not. This is probably best as a toggle option on workflow default config screen. ------------------------------------------------------------------------ August 3, 2004 - 22:21 : mathias I don't think my patch interferes with the moderation features. If the default workflow for a type of nodes is set to 'moderate', than the moderation flag will always reset itself to 'moderation' upon editing. I did not alter this functionality. ------------------------------------------------------------------------ September 29, 2004 - 23:00 : mathias Attachment: http://drupal.org/files/issues/node_defaults_1.patch (1.64 KB) I was recently bitten by this bug again, so I'll try to describe the exact nature of the problem. If an user of a node doesn't have 'administer nodes' permission, than whenever they edit their own node the status, promotion, static, moderation and revision settings revert to their default state. This can cause: - A demoted post to once again be promoted. - A promoted post to be demoted. - A static post to disappear from the front page. All of these scenarios have happened to me simply by authors editing their own content. This patch allows all options except moderation and revision to stay with a node once it's created. Note: along a very similar line, the one-line 'node_validate does not respect group editing patch [1]' has been rolled into this as well. I'll take it out if need be. [1] http://drupal.org/node/11071 ------------------------------------------------------------------------ September 29, 2004 - 23:00 : mathias I was recently bitten by this bug again, so I'll try to describe the exact nature of the problem. If an user of a node doesn't have 'administer nodes' permission, than whenever they edit their own node the status, promotion, static, moderation and revision settings revert to their default state. This can cause: - A demoted post to once again be promoted. - A promoted post to be demoted. - A static post to disappear from the front page. All of these scenarios have happened to me simply by authors editing their own content. This patch allows all options except moderation and revision to stay with a node once it's created. Note: along a very similar line, the one-line 'node_validate does not respect group editing patch [2]' has been rolled into this as well. I'll take it out if need be. [2] http://drupal.org/node/11071 ------------------------------------------------------------------------ September 30, 2004 - 20:08 : Dries When someone edits a node that has been promoted, I do want to demote it from the main page. If not, the system is open for abuse. IMO, this is 'by design'. ------------------------------------------------------------------------ September 30, 2004 - 21:00 : Bèr Kessels Both Dries and Mathias have valid points here. If I add a post with loads of ugly stuff inside it, but an adminstrator decides not to delete it (because the post is still not too bad, or because of policy), but demote it, I can promote my spam next minute again by simply editing my content. This is bad. If I add a post with lots of good information, so that an administratr promotes it, next thing i can do is open it up and add loads of ugly spam to it. Buth are unwanted scenarios. The first is what we have now. The second is when this patch is committed. I think we need to seriously rething the workflow logic, maybe splitting workflow up into "add" and "edit". But maybe there are even better options? ------------------------------------------------------------------------ September 30, 2004 - 21:01 : Bèr Kessels Both Dries and Mathias have valid points here. If I add a post with loads of ugly stuff inside it, but an adminstrator decides not to delete it (because the post is still not too bad, or because of policy), but demote it, I can promote my spam next minute again by simply editing my content. This is bad. If I add a post with lots of good information, so that an administrator promotes it, next thing i can do is open it up and add loads of ugly spam to it. and then i have a promoted post with spam on that site. Both are unwanted scenarios. The first is what we have now. The second is when this patch is committed. I think we need to seriously rething the workflow logic, maybe splitting workflow up into "add" and "edit". But maybe there are even better options? ------------------------------------------------------------------------ September 30, 2004 - 21:02 : Bèr Kessels Both Dries and Mathias have valid points here. If I add a post with loads of ugly stuff inside it, but an adminstrator decides not to delete it (because the post is still not too bad, or because of policy), but demote it, I can promote my spam next minute again by simply editing my content. This is bad. If I add a post with lots of good information, so that an administrator promotes it, next thing i can do is open it up and add loads of ugly spam to it. and then i have a promoted post with spam on that site. Both are unwanted scenarios. The first is what we have now. The second is when this patch is committed. I think we need to seriously rething the workflow logic, maybe splitting workflow up into "add" and "edit". But maybe there are even better options? ------------------------------------------------------------------------ September 30, 2004 - 21:11 : Dries The first problem can be solved by blocking the user account, or by revoking the user's permissions. The second problem can probably be solved using the node-level permissions. Whenever I promote a post to the front page, I could revoke the user's edit rights. It would only work, if the modules don't by-pass the access rights, of course (I believe some do). ------------------------------------------------------------------------ October 3, 2004 - 22:28 : mathias Attachment: http://drupal.org/files/issues/node_defaults_2.patch (4.22 KB) Dries is right about using the power of node-level permissions for community editing. I think this patch would assist that goal. As it stands, node-level permissions don't work with community editing, at least in the sense we're used to. For one node_validate transfers ownership of the node to the current editing user which may not always be the author. This causes many problems since original authorship usually implies special privileges (e.g. 'edit own foo', delete). Second, sites have different trust levels for users. On some sites there's just a handful of trusted users that edit and maintain all the content. The current approach for community editing is to create a new role and give it the 'administer nodes' permission, which in my opinion makes the node form interface much more cluttered and gives users in that role full access to node properties. Full access is not always desired. Using a combination of node-level permissions and allowing a node to retain some or all of its options makes a clean, easy to use approach to maintainance. This new patch lets the admin control how node_validate handles node options during editing. It splits the default workflow screen into two parts: Creation settings, and Editing options. The creation settings is the default workflow we're all used to. The editing options allow the admin to say what happens to those node options when they are edited. I've created a node-level permissions module [3] based on JonBob's work that allows a user to choose which roles can view and/or edit their post. Unfortunately it needs this patch to allow node_validate to be a little less controlling. I'd like to contribute this module if it didn't need a patch. [3] http://www.asitis.org/tmp/ ------------------------------------------------------------------------ October 3, 2004 - 22:30 : mathias Attachment: http://drupal.org/files/issues/node_defaults_admin_content.png (22.39 KB) Screenshot of the new default 'node editing options' interface. ------------------------------------------------------------------------ October 4, 2004 - 16:16 : Bèr Kessels Mathias, First: using radio's for a Boolean is bad UI design IMO. It would be much better if you use checkboxes. Second: If you use radio's you can make the same matrix as above, for each node-type a reset foo flag. This will not only make the UI more consistent, but also improve usability by allowing per-node-type reset flag. Ber ------------------------------------------------------------------------ October 4, 2004 - 19:08 : Dries The settings GUI's help text is rather hard-core and will scare many user away. It will even frighten most Drupal developers. Also, I'm not sure I understood the screenshot correctly. The functionality introduced is much needed but the GUI and configuration parts needs work IMO. Keep working on it. ------------------------------------------------------------------------ October 14, 2004 - 22:55 : mathias Attachment: http://drupal.org/files/issues/node_defaults_3.patch (4.74 KB) As per Ber's feedback, I changed the interface to use checkboxes and allowed the reset flags to be set for each node-type. The result is a much more familiar and consistent experience. Dries: I revamped the help text, removing the scary bits and sticking to the bare essentials. The dialog concerning this patch has been excellent, and the result of which I feel is a sweet slice of code ready for core :) ------------------------------------------------------------------------ October 14, 2004 - 22:56 : mathias Attachment: http://drupal.org/files/issues/node_defaults_admin_content_0.png (18.68 KB) Latest screenshot of patch. ------------------------------------------------------------------------ October 28, 2004 - 21:08 : mathias Attachment: http://drupal.org/files/issues/node_defaults_4.patch (4.81 KB) Updated the help text to be slightly more descriptive, informing the reader that: Users with "administer nodes" permission can override the editing options. ------------------------------------------------------------------------ October 29, 2004 - 00:51 : Steven I'm not sure I like that admin interface. My brain tries to correlate the two tables, but the meanings are different (what is the value, keep the value?). Maybe it would be better just to have one checkbox per node type to allow you to either revert the published/frontpage/moderate/sticky fields on editing, or not. This should cover 99% of all use cases with an admin interface that is much easier to understand. ------------------------------------------------------------------------ October 30, 2004 - 20:29 : mathias Attachment: http://drupal.org/files/issues/node_defaults_5.patch (5.06 KB) It provides a consistant look and feel if the creation settings are the same as the editing settings since they both manipulate the same components of a node and you're just toggling states based on different actions. I think it is a bad idea to only give site admins an 'all or none' approach to override node options upon editing. Here are some examples why: - You want nodes to remember their 'sticky' setting, but unpublish themselves after editing. Once the node is approved, it goes right back to where it was. - You want nodes to remember their 'promote to front page' setting, but unpublish themselves after editing. Once the node is approved, it goes right back to where it was. - You want nodes to remember all their settings except moderation. The node is still published, but it goes into the queue to be rated again since the content has changed. - By default nodes are unpublished. Once it's been tagged as published it stays that way. Perhaps the moderation tag is reset. I've updated the code to hopefully make things even more clearer. Here's the latest screenshot [4]. [4] http://asitis.org/tmp/node_defaults_admin_content_1.png ------------------------------------------------------------------------ January 24, 2005 - 17:41 : moshe weitzman this patch fixes a fairly undesirable problem with our workflow. lets consider it along with other proposed changes to default workflow. ------------------------------------------------------------------------ March 13, 2005 - 23:04 : killes(a)www.drop.org Does not apply anymore. ------------------------------------------------------------------------ April 12, 2005 - 20:07 : r11r I'm still experiencing this problem with latest CVS (head and drupal-4-6) and in addition to the publishing options (Published, Promoted to front page, etc), it also affects the settings for comments. When a user edits the page, the settings revert to the default value for that content type, instead of what is currently set for the specific node. Example of this problem with respect to Comments: ( Create a user with permissions to edit own pages, but not administer comments. ) 1. user creates page (comments default to read/write) 2. admin edits page and turns off comments 3. user edits page and saves 4. comments are reset to read/write Help :) (Am willing to assist in fixing this if necessary) ------------------------------------------------------------------------ April 12, 2005 - 20:31 : killes(a)www.drop.org Ok, just some remarks from irc: 21:23 < killes> r11r: After looking a bit more at the code I think it is more of a feature request than a bug. 21:23 < killes> Not that I would mind some more flexibility, of course. 21:24 < r11r> killes: well, node settings magically resetting themselves could be considered a bug.. hehe 21:25 < killes> Well, it is not magically, it is "by design". ;) 21:25 < killes> i don't think we will get that into 4.6. But I woul dwork with you to get it into 4.7. 21:27 < killes> This needs to be part of a more general improved workflow thingie. 21:27 < killes> Did you try clousseau's workflow module? it is amazing. ------------------------------------------------------------------------ April 13, 2005 - 14:59 : r11r Haven't yet looked at workflow, but this issue can be fixed by simply unsetting the node properties for which the user doing the edit does not have permissions. i.e. in node.module (around line 1255) if (!$node->nid): -- load defaults from database settings else: -- unset node->status, moderate, promote, sticky, revision, created also in comment.module (around line 247, the nodeapi hooks) if (!user_access('administer nodes')): -- unset node->comment Because any properties that are not set in the node object do not get passed into the update sql statement, the node will retain its previous values after being edited by a user instead of reverting to the default values for the content-type. Can anyone think of problems with this approach for the time being? ------------------------------------------------------------------------ April 13, 2005 - 17:52 : r11r Change in comment.module, line 257 for head and 4.6, line 254 for 4.5. case 'validate': if (!user_access('administer nodes')) { if (!$node->nid) { // Force default for normal users: $node->comment = variable_get("comment_$node->type", 2); } else { // If the node is being updated, respect its previous settings unset($node->comment); } } break; ------------------------------------------------------------------------ April 13, 2005 - 18:02 : r11r Didn't really mean to change the title! ------------------------------------------------------------------------ April 13, 2005 - 18:05 : r11r Change in node.module, for head and 4.6, around line 1258 $node_options = variable_get('node_options_'. $node->type, array('status', 'promote')); if (!$node->nid) { // Force defaults in case people modify the form: $node->status = in_array('status', $node_options); $node->moderate = in_array('moderate', $node_options); $node->promote = in_array('promote', $node_options); $node->sticky = in_array('sticky', $node_options); } else { // If the node is being updated, respect is previous settings unset($node->status); unset($node->moderate); unset($node->promote); unset($node->sticky); } $node->revision = in_array('revision', $node_options); unset($node->created); For 4.5, the code is slightly different in node.module, around line 1095... if (!$node->nid) { // Force defaults in case people modify the form: $node->status = variable_get("node_status_$node->type", 1); $node->promote = variable_get("node_promote_$node->type", 1); $node->moderate = variable_get("node_moderate_$node->type", 0); $node->sticky = variable_get("node_sticky_$node->type", 0); } else { // If the node is being updated, respect is previous settings unset($node->status); unset($node->moderate); unset($node->promote); unset($node->sticky); } ------------------------------------------------------------------------ April 13, 2005 - 18:06 : r11r Attachment: http://drupal.org/files/issues/node.module_head.patch (1.38 KB) Patch for node.module in HEAD ------------------------------------------------------------------------ April 13, 2005 - 18:06 : r11r Attachment: http://drupal.org/files/issues/comment_head.module (76.29 KB) Patch for comment.module in HEAD ------------------------------------------------------------------------ April 13, 2005 - 18:07 : r11r Attachment: http://drupal.org/files/issues/comment.module_head.patch (976 bytes) Err, sorry too many files to pick from in the directory . :) Here's the patch again. (for comment.module, in HEAD) ------------------------------------------------------------------------ April 13, 2005 - 18:09 : r11r Attachment: http://drupal.org/files/issues/node.module_drupal-4-6.patch (1.39 KB) Patch for node.module in DRUPAL-4-6 ------------------------------------------------------------------------ April 13, 2005 - 18:09 : r11r Attachment: http://drupal.org/files/issues/comment.module_drupal-4-6.patch (988 bytes) Patch for comment.module in DRUPAL-4-6 ------------------------------------------------------------------------ April 13, 2005 - 18:10 : r11r Attachment: http://drupal.org/files/issues/node.module_drupal-4-5.patch (1.38 KB) Patch for node.module in DRUPAL-4-5 ------------------------------------------------------------------------ April 13, 2005 - 18:10 : r11r Attachment: http://drupal.org/files/issues/comment.module_drupal-4-5.patch (1010 bytes) Patch for comment.module in DRUPAL-4-5

1 0

[drupal-devel] Improve Drupal themability
by Stefan Nagtegaal 14 Apr '05

14 Apr '05

All, to improve theming of drupal I would like to introduce two new functions, which are theme_list() and theme_list_item().. function theme_list($items = array(), $id) { if (isset($items)) { $output .= '<ul id="'. $id .'">'; foreach ($items as $item) { $output .= theme('list_item', $item); } $output .= '</ul>'; } return $output; } function theme_list_item($item, $class = NULL) { return '<li class="'. $class .'">'. $item .'</li>'; } These two functions will help us, theme drupal. Every list is getting a unique id like $module-$method. For example we get: <ul id="book navigation"> <li class="leaf"><a href="#">...</a></li> <li class="leaf"><a href="#">...</a></li> <li class="leaf"><a href="#">...</a></li> </ul> With these two functions we can get all hardcoded lists (<ul><li>) out of drupal.. At the end, a lot of theme function will be deprecated. you can think about theme_status_messages(), theme_node_list(). Combining this with the modified theme_box()-approach of Ber Kessels (http://drupal.org/node/15332) we can theme almost anything we want and how we want, with less extraneous markup.. I would like to know what you guys think about this, and dicuss before having some major patches hitting the patch queue.. Stefan.

2 4

[drupal-devel] Caching and Opera
by Karoly Negyesi 14 Apr '05

14 Apr '05

I just chatted with an Opera person who fixed my Opera via VNC. I asked about caching woes. He pointed me that I could configure my Opera so it always checks for fresh pages (it only checks whether there is something new, so it's not THAT big a problem). I asked whether we could omit some headers so that Opera won't cache the page (like node edit page): "Once we didn't cache pages if the http headers told opera not to cache the page, but as many webservers are configured to set those headers without any good reason we had to remove that again. Many forums and dynamic pages send that header which made opera reload the page everytime. and _many_ users complained, so we disabled this behaviour for unsecure sites. So, in short, it's not possible, the users shall configure their Opera? Yes, you'll have to configure your opera that way. May I publish the last question and answer to it? That's public information, so yes." So here you are. This is the latest, official word. Regards NK

2 1