- Development - lists.drupal.org

[drupal-devel] What the difference between '==' and '==='
by Gordon Heydon 30 Mar '05

30 Mar '05

Hello, I was just doing some work, and work some reason the form_select would select every thing. Here is what I coded. form_select('', 'result][' .$payment->txnid, '', array('' => t('select result'), '1' => t('cleared'), '0' => t('dishonoured')) And for some reason every option was selected. I changed line 1329 in common.inc from ($value == $key ? ' selected="selected"' : '')) to ($value === $key ? ' selected="selected"' : '')) and it started working. Is my form_select call wrong, or is there some difference between == and === Thanks. -- Gordon Heydon <gordon(a)heydon.com.au>

3 4

[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