- Development - lists.drupal.org

[drupal-devel] [bug] Do not execute functions in include files
by moshe weitzman 07 Jun '05

07 Jun '05

Issue status update for http://drupal.org/node/18213 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: chx Reported by: killes(a)www.drop.org Updated by: moshe weitzman Status: patch in the big case statement in drupal_bootstrap(), perhaps use defined constants instead of 0, 1, 2 ... i think the 4 phase bootstrap is perfect. perhaps move the code in the drupal_bootstrap('all') section to common.inc under a new function called drupal_bootstrap_all(). that makes the code a bit tidier and keeps a few lines out of init.inc which is useful. saves a bit of parsing on requests that don't use the whole framework. you could do that for the other phases as well although the benefit is smaller. moshe weitzman Previous comments: ------------------------------------------------------------------------ March 1, 2005 - 17:09 : killes(a)www.drop.org Drupal currently executes functions in include files. This is very annoying if you want to include files from external scripts such as update scripts or other scripts that want to use Drupal as a framework. Offending files are: database.inc: db_set_active(); session.inc: session_set_save_handler("sess_open", "sess_close", "sess_read", "sess_write", "sess_destroy", "sess_gc"); session_start(); common.inc: A bunch of stuff at the bottom. All this should be moved into a start.inc file. ------------------------------------------------------------------------ March 27, 2005 - 01:44 : adrian I haven't done this recently, but back in 4.4 era I attempted something similar to this for the install api. A _lot_ of modifications were required to be able to use (for instance) the theme api without needing to have a database connection active. ------------------------------------------------------------------------ March 27, 2005 - 01:55 : adrian It's definately not a simple problem. For instance.. the db connection needs to be started during bootstrap, and during normal execution. I think the better idea is to include a DRUPAL_INIT constant we can check before executing the function. (or a DRUPAL_NO_INIT .. i'm not picky). ------------------------------------------------------------------------ April 28, 2005 - 16:53 : killes(a)www.drop.org Here's an old patch by me that illustrates what I want to do. http://lists.drupal.org/archives/drupal-devel/2005-03/txtq23pAcHATw.txt Instead of putting the stuff into index.php, alternative file names need to be found. ------------------------------------------------------------------------ May 4, 2005 - 12:36 : chx Attachment: http://drupal.org/files/issues/boot.patch (6.83 KB) Well, I have written something to address the issue. Now you can include everything to your hearts content just include init.inc as well and do an appropriate drupal_bootstrap. Alas, ATM database and bootstrap is very interwined. This interdependency could be obliterated if we'd not use variable_get('dev_query') in database.*.inc. cvs diff -u -N -F^f against cvs.drupal.org as CVSROOT failed to include to include the two new files, so I'll include them as followups. ------------------------------------------------------------------------ May 4, 2005 - 12:37 : chx Attachment: http://drupal.org/files/issues/boot_0.patch (10.31 KB) Hm, settings.php changes were ommited. ------------------------------------------------------------------------ May 4, 2005 - 12:37 : chx Attachment: http://drupal.org/files/issues/init.inc (3.46 KB) ------------------------------------------------------------------------ May 4, 2005 - 12:38 : chx Attachment: http://drupal.org/files/issues/settings_ini_set.php (850 bytes) ------------------------------------------------------------------------ May 4, 2005 - 12:44 : chx Attachment: http://drupal.org/files/issues/boot_1.patch (14.49 KB) Following advice from darix I have now created one patch. Still, I'd like to know how could I do this with cvs. ------------------------------------------------------------------------ May 4, 2005 - 13:01 : chx Attachment: http://drupal.org/files/issues/boot_2.patch (14.48 KB) Steef found that I had $$ in settings.php. He also asked what's this good for. Several things, but most advantages come when you use only parts of Drupal. If you want use, say, only our forms functions then now you can include('common.inc'); without side effects. If you need the database layer, you do a include('init.inc') and call drupal_bootstrap('database') ------------------------------------------------------------------------ May 5, 2005 - 16:03 : chx Attachment: http://drupal.org/files/issues/boot_3.patch (17.98 KB) The database layer is now totally independent of other parts of Drupal. ------------------------------------------------------------------------ May 15, 2005 - 14:37 : chx A very stupid bug related to variable init is fixed and I am sync'd to HEAD, so timer_init('page') is called. ------------------------------------------------------------------------ May 16, 2005 - 16:12 : chx Attachment: http://drupal.org/files/issues/bootstrap_3.patch (12.36 KB) ------------------------------------------------------------------------ June 4, 2005 - 10:29 : chx Attachment: http://drupal.org/files/issues/bootstrap_4.patch (12.36 KB) Fixed drupal_bootstrap('database') -- $phase was 0 , and == FALSE fired. === FALSE is used. ------------------------------------------------------------------------ June 4, 2005 - 12:03 : nsk Some days before I was studying the Drupal source code and it caused me headaches that it executed code via include calls. I think it is better design to not execute anything automatically in includes. ------------------------------------------------------------------------ June 4, 2005 - 12:25 : chx Attachment: http://drupal.org/files/issues/bootstrap_5.patch (15.26 KB) Added phpdoc and moved drupal_unpack to init.inc thus now session handler can be used independently. ------------------------------------------------------------------------ June 5, 2005 - 04:13 : Dries Sorry but the quality of the PHPdoc is not up to standards. Please use proper punctuation, typography, line-wrapping, etc. It should also explain when/why to use this function. I can't help but think this is ugly code. drupal_bootstrap, for example, can be written more elegantly (not tested): function drupal_bootstrap($phase) { $phases = array('database', 'session', 'bootstrap', 'common'); foreach ($phases as $step) { _drupal_bootstrap($step); if ($phase == $step) { break; } } } instead of: function drupal_bootstrap($phase) { static $done = -1; $phase = array_search($phase, array('database', 'session', 'bootstrap', 'common')); if ($phase === FALSE) { return; } for (; $done <= $phase; $done++) { _drupal_bootstrap($done); } } ------------------------------------------------------------------------ June 5, 2005 - 11:34 : chx Attachment: http://drupal.org/files/issues/bootstrap_6.patch (15.56 KB) Some code simplification in drupal_bootstrap and better PHPdoc. (Thanks Dries and Steven.) ------------------------------------------------------------------------ June 6, 2005 - 10:19 : moshe weitzman i did a quick code review and this patch looks quite nice to me. note that it changes some of the same bits that are changed by my 'ban hosts' patch. i'm ok with committing this one first, and i will update accordingly. ------------------------------------------------------------------------ June 6, 2005 - 13:56 : Dries - Patch breaks update.php. Might want to double-check cron.php and xmlrpc.php. - The PHPdoc code wraps at variable width/length. Might want to tidy up that a little.

1 0

[drupal-devel] [bug] Form element labels should not show a : if the label ends in a '?'
by rbarreca 07 Jun '05

07 Jun '05

Issue status update for http://drupal.org/node/24482 Project: Drupal Version: cvs Component: theme system Category: bug reports Priority: minor Assigned to: Anonymous Reported by: rbarreca Updated by: rbarreca Status: patch Attachment: http://drupal.org/files/issues/patch_no_colon_after_question_mark.patch (710 bytes) Not sure if this goes under theme system or other. When fields end in a '?', the theme_form_element function shows a label like this "Label?:" which looks weird. I added a patch to check if it ends in a question mark, and if so, don't add the colon to the label. I know this function is themeable so I could've done it there, but I feel this should be the default behavior for all those fields like "Are you a smoker?", "Add to front page?", etc. rbarreca

4 3

[drupal-devel] [bug] Strange markup in book render functions
by Dries 07 Jun '05

07 Jun '05

Issue status update for http://drupal.org/node/1898 Project: Drupal Version: cvs Component: book.module Category: bug reports Priority: critical Assigned to: puregin Reported by: kika Updated by: Dries Status: patch Committed to HEAD. Great job, Djun. If any outstanding bugs need to be updated, please do. Dries Previous comments: ------------------------------------------------------------------------ June 10, 2003 - 00:06 : kika Snippet from book_render(): $output .= "<dt>". l($node->title, "node/view/$node->nid") ."</dt><dd>". book_body($node) ."<br /><br /></dd>"; Is using definition list here is really correct? This should be replaced with appropiate div's or even better, funnel through theme() Same goes for the function book_print(): $output .= "$node->title"; if ($node->body) { $output .= "<ul>". book_body($node) ."</ul>"; } Why wrap body inside <ul>? ------------------------------------------------------------------------ June 11, 2003 - 02:31 : al Yeah, it's all nasty. I patched this ages ago, but no one seemed interested. The patch now won't apply due to all the changes since then. I'm on this - expect a new patch to hit my sandbox shortly. ------------------------------------------------------------------------ June 11, 2003 - 08:03 : ax please remove the superfluous <ul>s and <li> [1], too. to solve the problem of invalid nested <hx> tags, maybe we should change <h$depth> to <h1 class="book-h$depth">? this way, we could use <h2> - <h6> in book pages. alternatively, we should only use <h5> and <h6> in book pages - we shouldn't have nestings deeper than 4 in printed books, then. additionally, i think it would be a good idea to add id's to all book headings so they can be jumped to via fragment identifiers (url#fragment-identifier). i often wish this would be possible when referencing the last paragraph of a long page of documentation ... these id's should be of the form <hx id="foo" name="foo"> [2], with foo probably being the node-id of the single book page. adding id's to headings would also be a good idea for headings / sections in single book nodes. for example, it would be nice if i could link to list point 10 in the drupal installation instructions [3] via something like url#10. these id's had to be added manually. the question is: how can these id's be named to be unique within a /printed/ book? probably <node_id>_<section_id> ... [1] [ [drupal-devel] Drupal handbook formatting and heading tags | http://lists.drupal.org/pipermail/drupal-devel/2003-June/025860.html ] [2] [ XHTML Spec, HTML Compatibility Guidelines, Fragment Identifiers | http://www.w3.org/TR/xhtml1/#C_8 ] [3] http://drupal.org/node/view/260 ------------------------------------------------------------------------ June 15, 2003 - 16:23 : al Fixed in latest CVS. Uses all of Ax's suggestions: - <h1 class="depthX"> - Fixed to use CSS rather than tables. - Changes link at top to standard "breadcrumb" style, rather than hierarchy in tree view. - Removes odd and superfluous <ul> tags and the like. - Makes printed docs have proper <html> and <body> wrapping, etc. ------------------------------------------------------------------------ May 5, 2005 - 09:20 : puregin I'm re-opening this, because the problem persists in CVS. 1) The current CVS version (1.288.2.4) of book module still wraps $node->body in an <ul> element in book_print_recurse(). This produces non-conformant HTML. I'm not sure why this was done in the first place - I'm guessing someone wanted to insulate from having bad markup in a book page throw off the enclosing page. Getting rid of the offending UL tags is a one-line solution, but what is the right thing to do here? I'd like to see something very structural - wrapping the /entire/ output (including the generated sectional header) of the book_print_recurse() wrapped in a <div> element. This will properly nest true structural sections, making the structure accessible to applications via DOM. It will also make it easier to use XSLT, for example, to transform into various XML based export formats, for example. Any reason not to do so? Also... when we get the 'printer-friendly' version of a page, the subtree rooted at that page is returned, and the root page is marked up with a class="book-h1". Is there any reason why we don't compute the depth of the root page, and use that to generate the "in-place" header? In other words, if a section is "book-h3" relative to the top-level book, shouldn't it be "book-h3" whenever it is viewed? In this case, we could apply the same principal to generating the <div> tags around each section. ------------------------------------------------------------------------ May 6, 2005 - 00:58 : puregin Attachment: http://drupal.org/files/issues/book_printer_friendly_div.patch (1.57 KB) I am attaching a patch which fixes improper printer-friendly output, as discussed. The patch fixes book_print and book_print_recurse() to insert a <div> start tag before emitting the header, and to close this after subsections have been recursively generated. The <div> tag has an id attribute of the form id="sect-123", where the node's nid is 123, and a class attribute of form class="sect/n/" where the depth of the section is /n/. I'm marking this issue as critical, since the present HTML output plays havoc with any attempts at sane PDF generation. I will address the issue of where printer-friendly subsections should be 'rooted' in a follow-up. Djun ------------------------------------------------------------------------ May 6, 2005 - 10:53 : Dries Let's not abbreviate 'section' to 'sect'. Also, we use '-' to separate words in CSS names. - If the section ID uses the node ID, maybe we should use 'node-' instead of 'sect-'? - If the class uses depth, maybe we should use 'depth-' instead of 'sect'? The same is true for your other patch where you suggest to use 'n'. Better to make that 'node-'. (Feel free to merge both patches.) Looks like the book.module generates a _lot_ of CSS IDs/classes. If the introduction of these new IDs/classes allows us to remove some of the existing IDs/classes, please do. ------------------------------------------------------------------------ May 7, 2005 - 06:26 : Steven Here's my idea.. why not use regular h tags for the book structure, and renumber the header tags in the content, starting one level after the current book depth? Here's a function which does this: <?php function fix_up_headers($text, $level = 1) { // Find all header tags that are used (if any) if (preg_match_all('/<h[0-9]+/i', $text, $tags) == 0) { return $text; } // Discard duplicates and sort them by number $tags = array_unique(array_map('strtolower', $tags[0])); natsort($tags); // Renumber them and replace them $i = $level; foreach ($tags as $tag) { $from[] = '@'. preg_quote($tag) .'(?![0-9])@i'; $from[] = '@'. preg_quote(str_replace('<', '</', $tag)) .'(?![0-9])@i'; $to[] = '<h'. $i; $to[] = '</h'. $i; $i++; } $text = preg_replace($from, $to, $text); // Change level 7 headers and higher to divs. return preg_replace(array('!<h([7-9]|[1-9][0-9]+)!i', '!</h([7-9]|[1-9][0-9]+)!i'), array('<div class="header-\1"', '</div'), $text); } ?> That way you can use header tags safely in the content (which is useful in the context of a single page) without messing up the book output. ------------------------------------------------------------------------ May 7, 2005 - 09:50 : puregin Attachment: http://drupal.org/files/issues/02_book_printer_friendly_div.patch (1.78 KB) The attached patch changes the div id to the form 'node-123'. I was concerned that a document fragment might be created with both a book section and a non-book section from the same node, leading to non-unique id's, but at this point it seems like an unlikely scenario. I've changed 'class=sect1' to 'class=section-1'. I was trying to be lazy and use the DocBook section name convention to make XSLT conversion a little easier, but it's really not saving any effort, in the end, and this is clearer. I think 'section' rather than 'depth' is appropriate - it describes what the role of the div element is. I've closed the other issue regarding id's in header elements, because I've replaced the whole 'class="book-hx"' business in headers with 'class="book-header"'. Since the level can now be selected by context with respect to the enclosing div, separate classes for headers are not required. That is, we can style with CSS like the following: .section-1 h1.book-header { font-weight: bold; font-size: 2.2em; } .section-2 h1.book-header { font-size: 2em; } .section-1 p { text-align: justified; } .section-3 p { margin-left: 3em; margin-right: 3em; } Note that the section-2 h1 will be bold, since the section-2 div is nested within the section-1 div. Also, all paragraphs regardless of section will be justified; and section-3 paragraphs will be indented left and right. Because we can style /everything/ by section, not just headers, and because the styling specifications respect the sectional hierarchy, it's possible to create very elegant and sophisticated book pages with very little CSS. Even I can do it! :) I'm definitely *not* a designer, but I've played around a bit with this - have a look at http://www.puregin.org/book/print/129 for an example. I will attach patches for misc/print.css and misc/drupal.css separately. I don't understand why, but the present version (cvs) of these files has all of the h1.book-hx selectors in drupal.css - the printer-friendly page actually looks at print.css. Am I missing something? For the record, this approach seems to have been suggested by clairem in http://drupal.org/node/8049 where I have a little rant about headings in book pages. Twice :) Djun ------------------------------------------------------------------------ May 7, 2005 - 10:10 : puregin Steven - that's a neat idea, and very clever, clean code! But it still doesn't catch problems such as, for example, an h5 inside of an h1 section with no intervening h2..h4 headers, or? I'm inclined to be a bit suspicious of the approach, though - I rather think it's 'doing magic behind the user's back'. If people are going to insist on putting headings inside of pages, it should be possible. And it would be odd for users to discover that what they typed isn't what they get. ------------------------------------------------------------------------ May 7, 2005 - 10:32 : puregin Attachment: http://drupal.org/files/issues/print_css_div.patch (1.36 KB) Here's the patch for print.css. There's a couple of commented-out lines - these show how to make section headings 'run in' as part of the following paragraph (or other inline element). I am assuming that print.css is supposed to be something of an example that people would use to experiment with? Please feel free to improve this in any way - as I said, I'm far from being a graphic designer, and I'm also not really sure what the intention of this file is. ------------------------------------------------------------------------ May 7, 2005 - 20:40 : Steven Puregin: nope, the code correctly handles missing h numbers. If the book page only uses h2, then that will be the first new level. If it uses h2 and h4, and it is inside a 3rd level book page for example (whose title would be h3), they they get renumbered to respectively h4 and h5 (no missing number). >From a semantic point of view it is crazy not to use h# for book titles. ------------------------------------------------------------------------ May 7, 2005 - 20:44 : Steven A bit more verbose: I think the overwhelming majority of users browse a book on the site itself. Within a single page, there is a h1 tag for the page title. So it makes sense for a writer to use h2, h3, etc inside a single page. This is semantically valid HTML. On the other hand, the print output places the content in a whole new context. I would expect the book module to take whatever steps necessary 'behind the user's back' to ensure it displays correctly. ------------------------------------------------------------------------ May 7, 2005 - 22:43 : puregin Sorry, I replied to the last post on the list - I'll include the post here for the record, and expand a little. Steven, I think that the issue you're addressing is actually a different one than I am trying to fix in my patch, which addresses how sections are wrapped. My patch would still allow users to write headers in their book pages - it would then be up to post-processing - or something like your approach - to deal with how embedded headers are dealt with. Perhaps we should take up your suggestion in another of the book.module issues dealing with the sequences of headers? How about http://drupal.org/node/8049, or http://drupal.org/node/4118? With respect to your suggestion - I understand now that you're proposing to apply the re-writing only to the printer-friendly output. I'm conflicted about this idea - on the one hand, the output which it produces is clearly an improvement over the present output. On the other hand, it changes what the user types to make it 'right' - I guess this is in the long tradition of HTML being interpreted very forgivingly by web-browsers and other applications. On the balance, I support your idea - I guess it's in the spirit of 'make things easier for the user'. With respect to the actual code - I don't think it will handle the case where h2, h3, and h4 are all used in the text, but the sequence h2, h4 occurs. To put it another way, the problem of checking whether headers are in a legal sequence is context sensitive, while a regular-expression search and replace (even if the replacement sequence remaps the targets) is context-free. When I say legal sequence, I mean legal in terms of book hierarchy, not in terms of the XHTML definition, which doesn't address hierarchy, because headers are titles, not sectional elements. SGML/XML publishing DTDs define such things via inclusion/exclusion on true sectional elements) The case I described is, admittedly, a relatively infrequent occurrence, and the general solution would be way to difficult to deal with - it would involve constructing and manipulating a DOM, or something along those lines. Ugh! Djun ------------------------------------------------------------------------ May 18, 2005 - 19:24 : cel4145 The Drupal doc team is very interested in being able to import/export book content. I'm sure that others would be interested in it, too. Djun has indicated that this patch is a good step toward having that functionality So +1 if the developers can help him to get this patch so that it can be implemented. ------------------------------------------------------------------------ June 1, 2005 - 12:37 : puregin This patch is subsumed in my patch for issue http://drupal.org/project/comments/add/1482, which provides for XML export of books. Note that the patch for print.css in this issue still applies with the new patch. ------------------------------------------------------------------------ June 6, 2005 - 11:30 : puregin This issue has been fixed with the application of patch from http://drupal.org/node/1482. However, I'm not sure if the print.css file patch has been commited. Dries? Also, as I mentioned, someone with real page/graphic designer's expertise should probably look over this and tweak/replace with better layout. ------------------------------------------------------------------------ June 6, 2005 - 22:30 : Dries Attachment: http://drupal.org/files/issues/opml.png (39.94 KB) I think this version generates invalid OPML and invalid Docbook code. The Docbook does not seems to validate as XML because sometimes a book-tag is closed with a section-tag. In OPML's case, the section-classes look weird (see screenshot). I'm guessing something is wrong with the computation of the depth. Are the class-sections part of the OPML standard? I'm having a hard time guessing what they are about or why one wants to use these. A couple of code comments: 1. Don't use tabs. Even in absence of tabs, the spacing isn't always 100% consistent -- sometimes two spaces are used. 2. The use of " (double quotes) and ' (single quotes) is sometimes confusing. Only use single quotes when it shortens the code. Often your code can be shortened by using double quotes (and escaping double quotes in the embedded string). Example: $output .= '<div id="node-'.$node->nid. '" class="section-'.$depth.'">'."\n"; 3. Write $depth == 2, not 2 == $depth. ------------------------------------------------------------------------ June 7, 2005 - 02:07 : puregin Attachment: http://drupal.org/files/issues/xml-export-04.patch (23.89 KB) I am now supplying the correct number of parameters to the '_post_node' visitor definitions, so the depth is now passed correctly. This fixes the problems with mismatched tags and strange section depths. The DocBook output for top-level nodes validates against Docbook XML V4.1.2 (using onsgmls). Level 2 and deeper nodes generate Chapters and sections as document fragments and so won't validate per-se. I've checked that they are well-formed, and that they validate on a manual embedding. OPML now validates against the 1.0 DTD (though there seem to be some problems with the DTD itself) I now encode the "id" attribute as string in type attribute of outline for OPML, in order to store this metadata in an existing attribute. The use case I have in mind is someone exporting the book structure (hierarchy) via OPML, editing it and re-importing to modify the structure of the book. I have removed the "class" metadata. Checked for tabs/whitespace - I hope this is now OK. Now using ($depth == 2) rather than (2 == $depth). I've replace single quotes with double where code is simplified by this. ------------------------------------------------------------------------ June 7, 2005 - 02:17 : puregin Attachment: http://drupal.org/files/issues/xml-export-05.patch (23.89 KB) Sorry, ignore the last patch - I goofed with escaping a string. The new patchfile is attached -- Djun

1 0

[drupal-devel] AJAX approach to free tagging (Multiple text Applicator)
by a f 07 Jun '05

07 Jun '05

Have you seen the Multiple Text Applicator at http://sparkcasting.com/assets/ajax/mta/ ? This could come really handy for free tagging. What it does is that it tranforms a comma seperated list in a text filed to an UI for managing lists. I've attached a simple mockup for how it could look in Drupal for a free tagging text field. The only drawback I've seen so far is that it adds an extra textfield when stylesheets is turn off in the browser. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 3

[drupal-devel] Can't edit my slash theme project page
by Fredrik Jonsson 07 Jun '05

07 Jun '05

I noticed some days ago that I can't edit my slash theme project page anymore. <http://drupal.org/project/slash> It's still listed under "my projekts" together with my adminblock module projekt page that I can edit. User frjo <http://drupal.org/user/5546>. Fredrik -- Web site: <http://xdeb.org/wiki/Fredrik>

4 3

[drupal-devel] Etiquette for webform.module patches -- can't reach maintainer
by Syscrusher 07 Jun '05

07 Jun '05

Good morning. I apologize for the bandwidth, but I'm stuck until I can reach the maintainer of webform.module. I had the good fortune a couple of weeks ago that my employer needed a couple of new features added to webform.module, some additional flexibility in how it generates the emails. So they paid me to do the code on company time, but are willing (because we are an Open Source friendly company) to let me release it under GPL back to the Drupal community. There's absolutely nothing specific to our application about these enhancements; in fact, they broaden rather than narrow what the module can do. It's not a lot of code, but I'd like to commit the changes to CVS. The thing is, I've tried unsuccessfully to reach the maintainer listed for the project. How long do I wait before I assume this module is dormant and just go ahead and commit? Or is there someone on this list who has taken over as maintainer and just not put their name on the project yet? I don't want to violate the rules of Drupal etiquette, so I'm asking before doing. But the code is not a conceptual pipe dream -- it's in production on my employer's web site right now -- so I want to contrib it back to the community. Advice? Kind regards, Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher

4 7

Re: [drupal-devel] Etiquette for webform.module patches -- can't reach maintainer
by Pontus Ullgren 07 Jun '05

07 Jun '05

Syscrusher said: > Good morning. > Morning, > I apologize for the bandwidth, but I'm stuck until I can reach the maintainer > of webform.module. > Sorry about that. I've been away to do some "day-time" work and haven't been very active looking thru the issue tracker. > I had the good fortune a couple of weeks ago that my employer needed a couple > of new features added to webform.module, some additional flexibility in how > it generates the emails. So they paid me to do the code on company time, but > are willing (because we are an Open Source friendly company) to let me release > it under GPL back to the Drupal community. There's absolutely nothing specific > to our application about these enhancements; in fact, they broaden rather than > narrow what the module can do. > Sound great ... > It's not a lot of code, but I'd like to commit the changes to CVS. The thing is, > I've tried unsuccessfully to reach the maintainer listed for the project. How > long do I wait before I assume this module is dormant and just go ahead and > commit? Or is there someone on this list who has taken over as maintainer and > just not put their name on the project yet? > Please open issues in the issue tracket with a attached patch file (mark them as patches). I will tend to them as soon as possible (maybe not to night but in a week or so). > I don't want to violate the rules of Drupal etiquette, so I'm asking before > doing. But the code is not a conceptual pipe dream -- it's in production on > my employer's web site right now -- so I want to contrib it back to the community. > > Advice? > Contact me thru the issue tracker or using my users(a)sourceforge.net email address. > Kind regards, > > Scott > > -- > ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" > http://drupal.org/user/9184 > scott at 4th dot com Drupal projects: > http://drupal.org/project/user/9184 > Sandbox: > http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher >

1 0

[drupal-devel] [feature] Improved caching with eAccelerator/turck mmcache
by Yrlec 07 Jun '05

07 Jun '05

Issue status update for http://drupal.org/node/24260 Project: Drupal Version: 4.6.0 Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Yrlec Updated by: Yrlec Status: patch Attachment: http://drupal.org/files/issues/newcache.php (3.82 KB) I'm not sure if this is the best place to post, please let me know if I should post somewhere else. I've done some changes to bootstrap.inc to make it use the semaphore cache of either eAccelerator or Turck mmCache instead of the database to handle the caching. I've not done any benchmarking but I'm quiet sure that it will speed things up. I'm afraid that I didn't base my code on the latest version so I apologize if my changes aren't compatible with the current cvs-version. As you can see, if neither eAccelerator nor Turck mmCache isn't available on the system the old caching mechanism will be used. The changes are in cache_get, cache_set and cache_clear_all. I'm sorry I didn't post a diff but I think it will be quiet easy to implement anyway. Yrlec

9 13

[drupal-devel] [bug] Search box for pushbutton and bluemarin themes
by maca 07 Jun '05

07 Jun '05

Issue status update for http://drupal.org/node/24461 Project: Drupal Version: 4.6.0 Component: theme system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: maca Updated by: maca Status: patch Hi drupies, there is a small bug in %subj%. File xtemplate.xtmpl contain: <input class="form-text" type="text" size="15" value="" name="keys" alt="{search_description}" /> If you search from this box you receive no results. This is my patch: <input class="form-text" type="text" size="15" value="" name="edit[keys]" alt="{search_description}" /> maca

2 1

[drupal-devel] [task] Unnecessary line of code
by drumm 07 Jun '05

07 Jun '05

Issue status update for http://drupal.org/node/24450 Project: Drupal Version: cvs Component: system.module Category: tasks Priority: normal Assigned to: drumm Reported by: drumm Updated by: drumm Status: patch Attachment: http://drupal.org/files/issues/system.module_3.diff (844 bytes) As far as I can tell this line isn't doing anything. drumm

1 0