March 2005 - Development - lists.drupal.org

[drupal-devel] CivicSpace development moving to Drupal
by neil＠civicspacelabs.org 30 Mar '05

30 Mar '05

A couple things have become obvious to those of us working at CivicSpace: 1. We shouldn't be maintaining a development community. 2. We have been trying to maintain a development community. That means people who want to help out with CivicSpace will have to get on Drupal.org sooner or later. That is okay, every serious CivicSpace developer has done that anyway. This should be relatively straightforward: - All modules which are not in contrib should be in contrib. - All modules which don't have an associated project will have to get one. - Our issue tracker becomes a search over the issue tracker for the modules we include in CivicSpace. - Anyone who wants a sandbox or something else will have to go to Drupal. These things are being integrated into our development cycle soon. The overall status of our development (including moving to 4.6), can be found at http://civicspacelabs.org/home/developers/roadmap. There are a few things I could use some advice about: - Bug fix fridays in the Drupal community. The simple explanation is that Zack and I come up with a list of bugs to fix every Thursday, tell the CivicSpace developers mailing list about them, and bug assignments are made at a set time in an IRC room Which IRC room should be used, #drupal-bugfixday? Anyone else want to do this as well? - To properly release the configure [1] module it will need about 2/3 of the code pushed into individual modules using a new hook. We should have a debate about this going into Drupal core at some point. It could easily live as a contrib module, but I think we need to take a step back and think about how module installation works. - The contact [2] module. It has a naming collision, a replacement coming in some number of monthsi (CiviCRM), and hasn't had any non-bugfix updates since Drupal 4.4. This code isn't up to Drupal standards and shouldn't need to be updated, assuming CiviCRM works. - The contact module uses the forms [3] module. IMO, the forms module needs to be replaced with a core API based upon the admin-configurable forms in flexinode and profile modules. Contact uses an old version of forms module before some API changes; I like the changess, but haven't had the time to rewrite and retest contact module. - Survey [4] is forked because it has to work with the forms module we are using. And we haven't really gotten a good idea of how we expect people will want to use survey in the context of a CivicSpace site. - Our node_import [5] module is heavily forked. Things will get worse before they get better with the coming of CCK. This is something we can get working on 4.6, but we don't haven't been dedicating much resources to this module. - Install.php [6] is a heavily branded and Postgres incompatible moving target. Who is interested in helping get this into Drupal? I know people who want to make Drupal easier to install are out there. - We want to know when 4.6.0 final will be released. Yeah, I know, it is ready when it is ready and review issues and test it to make it go faster. Notes 1. Configure is a wizard to walk through the basic configurations needed to get a site running. 2. Contact keeps data from user registrations, mailing list sign ups, and data entry in a central location. 3. Forms provides an API for modules to maintain admin-configured forms. 4. Survey creates simple surveys for data collection. 5. Node_import imports CSV files as nodes. 6. Install.php loads table definitions into an SQL database and writes conf.php (yes, it is 4.5.x code right now). (This email will be cross posted to my blog at http://civicspacelabs.org/home/blog/71) -Neil Drumm Lead developer, CivicSpaceLabs.org

12 28

[drupal-devel] [feature] Administer unpublished nodes
by chx 30 Mar '05

30 Mar '05

Issue status update for http://drupal.org/node/19671 Project: Drupal Version: cvs Component: node.module Category: feature requests Priority: normal Assigned to: chx Reported by: chx Updated by: chx Status: patch Attachment: http://drupal.org/files/issues/node_unpublished.patch (9.42 KB) This patch introduces the concept of unpublished nodes' administrator. This admin can do anything with unpublished nodes, but changing node->status. Known problem: If you have some node types where the default workflow is to publish, for example storiy, and for some others you want to employ unpublished node administrators (UNAs). If you unpublish a story and a UNA changes anything in that, it will pop back to published state and the poor UNA will be unable to unpublish it. Possible workaround: UNAs never can publish anything, even if default workflow says "publish". Disadvantage: UNA will need to keep two accounts, one normal user who can publish stories and an UNA account. chx

2 2

[drupal-devel] generate random urls
by Maykel Moya 29 Mar '05

29 Mar '05

I'm trying to make the glossary have a page per letter 'glossary/a', 'glossary/b' etc... I'd even like to have every link available before hand, even if isn't content to a given letter. So a need glossary/[0-9a-z]. Is there other way to achieve this than to have a very big array with every case inside the hook_menu? Regards, maykel -- ,''`. Debian GNU/Linux : :' : The universal & free Operating System `. `' El Sistema Operativo universal y libre `- http://www.debian.org/

4 3

[drupal-devel] [bug] illegible form elements for content administration (Safari)
by Junyor 29 Mar '05

29 Mar '05

Issue status update for http://drupal.org/node/17343 Project: Drupal Version: cvs Component: node.module Category: bug reports Priority: critical Assigned to: Anonymous Reported by: njivy Updated by: Junyor -Status: fixed +Status: patch Attachment: http://drupal.org/files/issues/fieldset.patch (1.51 KB) Here's an alternative patch. Instead of adding a BR, if you set 'overflow: hidden' on the fieldset, it will expand to contain all floats. It works well in Opera, Firefox, Safari, IE6/Win, and IE5.2/Mac. Also included in this patch is a fix for the problem Moshe mentioned. I removed the '.node-form fieldset { display: inline }' rule. The change didn't appear to cause any visual/functional differences in the above browsers, except Safari (now it works ;)). Junyor Previous comments: ------------------------------------------------------------------------ February 15, 2005 - 00:43 : njivy Attachment: http://drupal.org/files/issues/content_administration-Safari.jpg (33.21 KB) Using Safari 1.2.4 under OS 10.3, the form elements for content administration are not legible. (The path is "admin/node".) I am not enough of a CSS whiz to directly propose a solution. But I am willing to test patches. I attached a screenshot. ------------------------------------------------------------------------ February 15, 2005 - 15:43 : njivy Oops. Wrong version. ------------------------------------------------------------------------ February 25, 2005 - 02:31 : mathias This has been fixed [1]. [1] http://drupal.org/cvs?commit=13633 ------------------------------------------------------------------------ March 27, 2005 - 06:00 : adrian Attachment: http://drupal.org/files/issues/safari_error.jpg (11.03 KB) I just found the admin menu similarly messed up in the 4.6RC. I flushed my drupal.css just in case, but the bug definitely persist. ------------------------------------------------------------------------ March 27, 2005 - 09:10 : Junyor The same thing is happening in Opera. I tracked it down to having a floated object inside a fieldset. Firefox uses the fieldset as the containing block for the float, but Opera and Safari move the floated content outside of the fieldset. ------------------------------------------------------------------------ March 27, 2005 - 13:09 : Goba So then a container div might be a working solution. ------------------------------------------------------------------------ March 27, 2005 - 13:58 : adrian Attachment: http://drupal.org/files/issues/safari_float_render.diff (1.29 KB) Here is a patch that adds a break , with a class of 'clear' , and adds a .clear class to the drupal.css file. This is how I would fix it, but it's probably not semantically correct. But it does fix the problem.. ------------------------------------------------------------------------ March 27, 2005 - 13:58 : adrian err. and it's a patch. ------------------------------------------------------------------------ March 27, 2005 - 14:37 : adrian Attachment: http://drupal.org/files/issues/safari_float_render_0.diff (1.29 KB) I'm using the coffee defense as to why I missed the . infront of the .clear class ------------------------------------------------------------------------ March 27, 2005 - 14:45 : adrinux I can't see any other way to fix that, adding an ID and setting height on the fieldset would be just as ugly imo - maybe re-engineering the whole form would work but this isn't really the time to do that! Steven will moan at you for using a br probably :) ------------------------------------------------------------------------ March 27, 2005 - 16:54 : Steven The original commit referenced above did not fix the problem completely, it did make the node admin at least usable in Safari. Before, the form items would overlap eachother. Adrian's fix seems to work, and the br is sort of excusable in this case, as the browser's behaviour is quite broken with regard to fieldsets. Usually I use <span> to avoid nasty br issues in IE, but there don't seem to be any in this case. <br class="clear"> could be considered a CSS version of <br clear="both"> which is transitional XHTML. Commited to head. ------------------------------------------------------------------------ March 27, 2005 - 19:26 : Junyor Looks good in Opera and Safari now, thanks. The behavior of floats inside fieldsets is undefined in CSS, so it's not really that they're broken. They're just different. :) ------------------------------------------------------------------------ March 27, 2005 - 22:29 : moshe weitzman Perhaps this is a good spot to mention that the author and timestamp fields are broken on the node edit form in Safari. They have been busted for a long time. The browser won't even click into those fields, so they can't be changed. Perhaps the fix there is similar to the fix submitted in this issue. ------------------------------------------------------------------------ March 27, 2005 - 23:30 : Junyor The same solution will probably work there.

1 0

[drupal-devel] some issues go to drupal-devel, others not?
by Daniel Convissor 29 Mar '05

29 Mar '05

Hi: I beg your indulgence while learning how the Drupal team/system works. I've submitted two issues. The first one has all comments being sent to the drupal-devel mailing list but the second one has not. The only difference is one is the first is a "feature" and the second is a "bug". Is that why one went an one didn't, or is there some other reason, please? SENT TO LIST ------------ settings.php: better instructions for $db_url and $db_prefix Project: Drupal Version: cvs Component: base system Category: feature Priority: normal Assigned: Unassigned Status: patch http://drupal.org/node/19474 NOT SENT TO LIST ---------------- have db_prefix_tables() handle 'default' key not being set Project: Drupal Version: cvs Component: base system Category: bug Priority: normal Assigned: Unassigned Status: active http://drupal.org/node/19609 I verified they didn't go to the list by looking in the archive: http://lists.drupal.org/archives/drupal-devel/2005-03/index.html Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409

4 4

[drupal-devel] [feature] common.inc Move textarea pre hook between title and textarea
by Dries 29 Mar '05

29 Mar '05

Issue status update for http://drupal.org/node/18828 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jbond Updated by: Dries Status: patch Attachment: http://drupal.org/files/issues/textarea.patch (1.88 KB) Ber: while all people seem to agree, it is unclear how many people tested/reviewed this patch. One ought to be careful. For example, the patch introduces a new variable, $form_element, without properly initializing it ... How about the attached patch? It is slightly cleaner, slightly faster and properly initializes all variables. I haven't tested it with the WYSIWYG editors but maybe someone else (Julian?) can? Will commit after it has been tested. Dries Previous comments: ------------------------------------------------------------------------ March 13, 2005 - 11:52 : jbond Attachment: http://drupal.org/files/issues/common.inc_10.patch (1.8 KB) This patch moves the textarea hook for 'pre' between the title and the textarea. This makes it easier for simply textarea enhancements like quicktags to add a toolbar just above the textarea. It doesn't appear to have any effect on the fckeditor or htmlarea modules. It doesn't introduce any new hooks. ------------------------------------------------------------------------ March 13, 2005 - 19:56 : killes(a)www.drop.org Guess that is a patch. ------------------------------------------------------------------------ March 14, 2005 - 15:38 : Bèr Kessels +1 From me. Any module that adds something, will want to add it after the title. I really cannot think of any case where aditional content should sit above the title, but I can think of loads of cases where content needs to sit between the title and textarea. ------------------------------------------------------------------------ March 15, 2005 - 01:20 : stefan nagtegaal Indeed, nice and simple patch! +1 from me either.. ------------------------------------------------------------------------ March 15, 2005 - 16:13 : jbond http://www.voidstar.com/node.php?id=2263 [1] If this patch gets accepted I'll drop this into contrib. It's similar to quicktags but *I* like it better. ;-) [1] http://www.voidstar.com/node.php?id=2263 ------------------------------------------------------------------------ March 29, 2005 - 12:09 : TDobes +1... I'm pretty sure the current positioning was accidental anyway... it was always meant to go directly above the textarea. ------------------------------------------------------------------------ March 29, 2005 - 16:33 : Bèr Kessels Dries, All people who use this, seem to agree. Any chance this gets in soon? Bèr

1 0

[drupal-devel] phptemplate 4.5.0 warning on drupal 4.6 rc
by Maykel Moya 29 Mar '05

29 Mar '05

I got this warning: Missing argument 1 for phptemplate_templates() in /var/www-virtuals/drupal/themes/engines/phptemplate/phptemplate.engine on line 44. after upgrade to 4.6 rc. Regards maykel

2 1

[drupal-devel] [feature] common.inc Move textarea pre hook between title and textarea
by Bèr Kessels 29 Mar '05

29 Mar '05

Issue status update for http://drupal.org/node/18828 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jbond Updated by: Bèr Kessels Status: patch Dries, All people who use this, seem to agree. Any chance this gets in soon? Bèr Bèr Kessels Previous comments: ------------------------------------------------------------------------ March 13, 2005 - 10:52 : jbond Attachment: http://drupal.org/files/issues/common.inc_10.patch (1.8 KB) This patch moves the textarea hook for 'pre' between the title and the textarea. This makes it easier for simply textarea enhancements like quicktags to add a toolbar just above the textarea. It doesn't appear to have any effect on the fckeditor or htmlarea modules. It doesn't introduce any new hooks. ------------------------------------------------------------------------ March 13, 2005 - 18:56 : killes(a)www.drop.org Guess that is a patch. ------------------------------------------------------------------------ March 14, 2005 - 14:38 : Bèr Kessels +1 From me. Any module that adds something, will want to add it after the title. I really cannot think of any case where aditional content should sit above the title, but I can think of loads of cases where content needs to sit between the title and textarea. ------------------------------------------------------------------------ March 15, 2005 - 00:20 : stefan nagtegaal Indeed, nice and simple patch! +1 from me either.. ------------------------------------------------------------------------ March 15, 2005 - 15:13 : jbond http://www.voidstar.com/node.php?id=2263 [1] If this patch gets accepted I'll drop this into contrib. It's similar to quicktags but *I* like it better. ;-) [1] http://www.voidstar.com/node.php?id=2263 ------------------------------------------------------------------------ March 29, 2005 - 11:09 : TDobes +1... I'm pretty sure the current positioning was accidental anyway... it was always meant to go directly above the textarea.

1 0

[drupal-devel] [feature] Lazy loading of theme system
by moshe weitzman 29 Mar '05

29 Mar '05

Issue status update for http://drupal.org/node/19590 Project: Drupal Version: cvs Component: theme system Category: feature requests Priority: normal Assigned to: moshe weitzman Reported by: moshe weitzman Updated by: moshe weitzman Status: patch Attachment: http://drupal.org/files/issues/init_theme_lazy.patch (1.04 KB) Don't initialize the theme system during common.inc. Instead, wait for the first call to theme() and do it there. There are 2 big benefits: - sometimes you never call theme(), and thus don't ever need to include theme engine and template. thats a performance win. examples include RSS feeds, blogapi, distributed auth, ... - module developers are currently forced to use hook_init() to set a custom theme for a given page view. with this patch, they can wait and do this during hook_menu(). Without this delay, module developers are tempted, sometimes forced, to break the bootstrap and inadvertently load all the modules for every page view. I almost did this in Organic Groups module, where each group can shoose its own theme. You can break the bootstrap by doing something as simple as node_load(). This is a tiny patch, and merits consideration for 4.6, i think. moshe weitzman

6 8

[drupal-devel] [feature] Menu fast edit node links
by Dries 29 Mar '05

29 Mar '05

Issue status update for http://drupal.org/node/9178 Project: Drupal Version: cvs Component: menu system Category: feature requests Priority: minor Assigned to: mathias Reported by: mathias Updated by: Dries Status: patch Yes, we need something like this in core but as explained, there is a depency on the new node form (and collapsible form/page elements in particular). Is anyone going to work on this? I'm determined to help get this in core ASAP but can't take a lead in this. Takers? Dries Previous comments: ------------------------------------------------------------------------ July 9, 2004 - 19:15 : mathias Attachment: http://drupal.org/files/issues/menu_fast_edit.patch (1.18 KB) When developers are creating custom menus, the process of adding content becomes twofold: 1. Create content 2. Navigate to administer > menus > add menu item and add the latest node entry This patch adds a link hook to the menu module. Specifically if a node does not have a menu entry the 'add menu item' link appears. If a menu item exists, the 'edit menu item' and 'delete menu item' are displayed thereby speeding up the publishing workflow. Note: This feature is only present when the menu module is enabled. Status: Waiting for JonBobs blessing ... ------------------------------------------------------------------------ July 10, 2004 - 19:21 : JonBob This is interesting. I do have a couple reservations. This adds a bunch of queries to node listing pages, since it has to check for every node whether that node has a menu item set. I also wonder how much time this saves the user in reality. It saves navigating to the menu admin screen, sure, but provides little other help. It seems that if we are to provide a link to the menu item add page, we should at least be pre-filling in the path and title fields for the user. The provided method is little better than having the menu admin page open in another browser tab. Maybe a node link isn't the right interface for this, anyway? Possibly a tab, or a hook_nodeapi('form admin') injection? If done right, this could finally replace that aging "link title" field in page.module nodes. ------------------------------------------------------------------------ January 24, 2005 - 23:23 : mathias Attachment: http://drupal.org/files/issues/menu_quick_link.patch (5.91 KB) This new patch gives users the ability to define menu items on any node creation/editing form. Screenshot here: http://asitis.org/tmp/menu_quick_link_form.png [1] It does this through nodeapi (as suggested by Jonbob), which means that any node has access to these fields unless specified otherwise via the new menu configuration settings. The functionality lives in menu.module, and users with 'administer menus' permission are allowed to edit the menu item fields inside the node form. One more note. I'm also proposing the addition of a misc/drupal.js [2] file to Drupal core (* gasp *). Currently it includes javascript functions to hide regions of a page. When a link is clicked on for a collapsed region, the region unfolds revealing the additional parts of a page. In this case the menu item fields are displayed after clicking the 'Menu item settings' link. I think it helps make best use of screen real estate, but we'll leave that verdict up to the usability experts. Let's remove the js file if it's the only thing stopping this patch from being submitted. I thought it might be worth exploring, especially for form pre and form post regions of the node form. [1] http://asitis.org/tmp/menu_quick_link_form.png [2] http://asitis.org/tmp/drupal.js ------------------------------------------------------------------------ January 24, 2005 - 23:34 : mathias Woops. Setting status to 'patch'. ------------------------------------------------------------------------ January 25, 2005 - 15:17 : Bèr Kessels +1 on the feature, I use menu_otf all the time. -1 for the javascript. Not that i am against it, ion contrary. I think we should not start implementing JS on a per-case basis, but we should introduce a javascript system that can do your accordeon-magick on any element. So it should wait IMO. ------------------------------------------------------------------------ January 25, 2005 - 17:07 : Dries I agree with Ber: +1 for the feature, -1 for the Javascript. This would (or should) be easy to implement/integrate as soon the new node forms are done. Both the new node forms, and this feature are crucial. ------------------------------------------------------------------------ January 27, 2005 - 22:39 : mathias Attachment: http://drupal.org/files/issues/menu_quick_link_0.patch (4.12 KB) Okay, here's the latest patch, footloose and javascript free. ------------------------------------------------------------------------ February 1, 2005 - 10:04 : robertDouglass +1 to the feature, with or without javascript. The Menu item title:* is showing that it is required, but it can't be required as that would force users to create menu items (and it doesn't validate to be required). The patch does, however, open up a big can of permissions worms, and lacks configuration. I would like to see a checkbox on the Workflow (/admin/node/configure/types/{type}) page so that I can hide this on a per-type basis. Then, I think we need some way of limiting this by role, by user, and by menu. I would at least want an "excluded menus" list where I could, say turn off the main Navigation menu so that people don't go and trash it. Very cool feature in a very important direction! I sincerely hope this makes it into the code freeze. ------------------------------------------------------------------------ February 3, 2005 - 00:37 : Anonymous I removed the required mark next to menu item form field. Thanks for spotting that. I don't completely understand what you mean by this patch 'opening up a big can of permissions worms'. User's with 'administer menus' permission are simply given an easier way to add menu items while creating content. I think it's better to keep it simple to begin with. http://asitis.org/tmp/menu_quick_link_form.png [3] There actually is a configuration interface (settings/menu). Your menu cache probably needed to be cleared after applying the patch :-) On that page you can choose which node types acquire the quick menu item form field as well as define the default menu item. I disagree with putting the menu item form visibility settings on the admin/node/configure/types/{type} page. Those settings are for the default state of the node instance, not what's visible on the form field. For example, I wouldn't want to see a list of all 'form pre' and 'form post' fields on that page to select from, but it could be useful as a standard interface elsewhere. [3] http://asitis.org/tmp/menu_quick_link_form.png ------------------------------------------------------------------------ February 3, 2005 - 00:40 : mathias Last comment by 'learning to login' mathias. ------------------------------------------------------------------------ February 6, 2005 - 12:23 : Dries I'm going to put this on hold until the collapsbile form groups [4] settled. I encourage you to participate in the design and discussion so that it meets your requirements. The same should be done for other parts of the node edit form, so let's try to come up with a generic solution that can be used through an API that shields you from all Javascript details. [4] http://drupal.org/node/16204 ------------------------------------------------------------------------ March 14, 2005 - 00:13 : killes(a)www.drop.org Hmm, should we have a status "on hold"? I am unsure what to do with this one. It still applies. ------------------------------------------------------------------------ March 29, 2005 - 12:15 : TDobes +1 on this... trying to explain to users that they need to add their pages, then add their pages to the menu system (and explain why) was incredibly difficult... menu_otf has helped with this, and I think this sort of functionality really belongs in core.

1 0