April 2005 - Development - lists.drupal.org

[drupal-devel] [bug] Brackets should not be used in IDs (primary offender: form_ functions)
by killes 05 Apr '05

05 Apr '05

Issue status update for http://drupal.org/node/19986 Project: Drupal -Version: 4.5.2 +Version: cvs Component: base system Category: bug reports Priority: critical -Assigned to: Anonymous +Assigned to: killes(a)www.drop.org Reported by: factoryjoe Updated by: killes(a)www.drop.org -Status: active +Status: patch Attachment: http://drupal.org/files/issues/valid-forms.patch (5.95 KB) Ok, here is an initial patch. The patch needs testing. I introduced a new function _form_get_id that is supposed to replace any non-allowed characters by a dash. This is not really nice, as we will get CSS IDs that have double dashes, but it is valid. We cannot simply reduce the double dashes to single dashes because there already might be another ID with only a single dash. killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ April 4, 2005 - 23:41 : factoryjoe Attachment: http://drupal.org/files/issues/blah.html (1.13 KB) Square brackets in IDs are not valid XHTML and cause a host of problems when trying to style individual elements. I have attached a page that proves this. Additionally, when you try to style an element by an ID that contains brackets, *all other styling from that rule will be ignored*. Brackets are simply not valid characters for IDs [1] (/emphasis added/): There's also a difference between CLASS and ID attributes as regards to the allowable format of values. By HTML rules, CLASS is CDATA, which basically means 'anything goes', but CSS rules impose some restrictions. /And by HTML rules, ID is ID, which means that only letters of the English alphabet ([A-Za-z]), digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods (".") are permitted, and the first character must be a letter (and underscores don't work reliably)/ " If you validate the attached document, you will get these two errors: XHTML validation error Line 25, column 19: character "]" is not allowed in the value of attribute "id" <div id="edit-16188][weight"> CSS validation errors Line: 17 Context : #edit-16188 Parse Error - #edit-16188][weight { border: 2px solid blue; } Line: 20 Context : #edit-16188 Parse Error - #edit-16188][weight, #test-2 { border: 2px solid green; } [1] http://css.nu/faq/ciwas-aFAQ.html#QA14

1 0

[drupal-devel] [bug] /blog does not respect the sticky bit
by drumm 05 Apr '05

05 Apr '05

Issue status update for http://drupal.org/node/19985 Project: Drupal Version: cvs Component: blog.module Category: bug reports Priority: normal Assigned to: drumm Reported by: drumm Updated by: drumm Status: patch Attachment: http://drupal.org/files/issues/blog.module_0.diff (1.65 KB) It is a rather straight forward fix for these sticky bits. drumm

1 0

[drupal-devel] New Archive Archive Module
by CodeMonkeyX 04 Apr '05

04 Apr '05

The current archive module for Drupal is inadequate, plain and simple. You are presented with a simple three-part form with the year, month, and day. You enter the date of the post you are looking for, and hit submit. If you do not happen to know the exact day that a post was made you are out of luck. Another problem with the current archive module is the fact that it uses a form to browse the archive. Because a form is used no feedback about the users current location in the archive is displayed in the url. So it is nearly impossible to link to a specific part of the archives. So my new module had a few features that I really felt were required. * Navigation: a new system for navigating the archives was required. The new system should provide a more granular way for users to browse the archive by date or by node type. * URL Feedback: provides the user with a familiar way to keep track of their position in the archive, and also provides a easy way for people to link to specific areas of the archive. * Filter by Date or Type: the old module just displayed all nodes. I thought it would be better if the user to specify if they wanted to view only blog nodes, or forum nodes, etc. These are the features that are in the demo I am currently using on my site. It is still under development, but if all goes well maybe this will become a part of the Drupal core for the 4.7 release. We will see how it goes. You can read more on my site: http://www.codemonkeyx.net/node/221 View a Demo: http://www.codemonkeyx.net/archive Tell me what you think, and what could be done to make it better.

9 13

[drupal-devel] [bug] left over DISTINCT
by killes 04 Apr '05

04 Apr '05

Issue status update for http://drupal.org/node/19960 Project: Drupal Version: cvs Component: book.module Category: bug reports Priority: normal Assigned to: killes(a)www.drop.org Reported by: killes(a)www.drop.org Updated by: killes(a)www.drop.org Status: patch Attachment: http://drupal.org/files/issues/book_27.patch (931 bytes) please remove, noted by BuddaBoy. killes(a)www.drop.org

1 0

Re: [drupal-devel] Re: [contributions(DRUPAL-4-5):sheldon]
by K B 04 Apr '05

04 Apr '05

After the initial message in this thread, I went in and checked cvs.drupal.org using viewcvs at http://cvs.drupal.org/viewcvs/drupal/contributions/ I checked a couple of my modules and themes, and it seems that the tags were not messed up. For example, http://cvs.drupal.org/viewcvs/drupal/contributions/modules/stock/stock.modu… This shows that the DRUPAL-4-5 tag is from 1 Feb for version 1.3 So I don't know if someone fixed it or what, but it does not seem messed up. -- Date: Mon, 4 Apr 2005 10:55:59 +0200 From: Dries Buytaert <dries(a)buytaert.net> Subject: Re: [drupal-devel] Re: [contributions(DRUPAL-4-5):sheldon] To: drupal-devel(a)drupal.org Message-ID: <c2a4d5c356f2f4edb6e1d049316bd811(a)buytaert.net> Content-Type: text/plain; charset=US-ASCII; format=flowed On 04 Apr 2005, at 10:40, Gabor Hojtsy wrote: >> This is my mistake. I apologize. I was trying to simply tag my >> interwiki module, and got confused by the program I'm using (CVL on >> Mac OS X). It has a "Tag Files" command in its "Work Area" menu, so I >> selected the interwiki module in my work area and then selected the >> "Tag Files" command. To my surprise, it started iterating through all >> of contrib, and I didn't know how to stop it. >> After this happened, I realized that there's a separate "Tag" command >> in CVL's "File" menu. I'm guessing that this is what I should have >> used. >> I'm new to CVS and to CVL, and this isn't the first frustrating >> experience I've had with it. However, it's the first time that >> something like this has negatively affected Drupal's contributions >> repository. >> Once again, I apologize, but in my defense, the interface to CVL is >> pretty damn confusing. I'd like to find a simple tutorial so I can >> learn how to just use CVS directly from my terminal command line. Can >> someone point me to one? Does that mean all Drupal 4.5 releases are messed up now? Err. -- Dries Buytaert :: http://www.buytaert.net/

2 2

[drupal-devel] image_import.module ready for early testing
by Scott Courtney 04 Apr '05

04 Apr '05

It's not done yet, but the image_import module that works with walkah's new (and wonderful!) image module is feature-complete and ready for functional testing to begin. I tested it last night by importing batches of images ranging from 1 file to 50+ files, with and without auxiliary caption files, and although there are some things I still want to improve (such as adding really "deep" clickable help links within the module, and fixing a minor menu annoyance), it is working correctly. The code is *not* yet compliant with Drupal standards for tabs and indents and such, so don't yell at me yet for that. I happen to prefer editing with tab indents rather than spaces, so I typically use a global replace to convert the code to space indents only after I'm done with it. My CVS commit notice has hit the drupal-devel list, but I'm contacting the two of you individually because I would very much value your input and testing assistance, if you have the time, since my module specifically interacts with both of yours. James, I would also like to ask a favor of you with regard to your code. I found myself having to call _image_build_derivatives() from my code, because there just wasn't any other good way to get the resizing task done. All the higher-level published functions that call that one do a security check to see if the file came from the $_FILES[] global HTTP variable, and since my import images are pre-uploaded using FTP, SCP, etc., I can't pass that security test. So what I'm asking is, would you consider making that function non-private, a supported part of the API for your module, so that I can [reasonably] rely on it in future releases? Alternatively, would you consider exposing a new public function that accepts a skeletal $node object, with attributes of type ('image'), body, teaser, uid, title, and file (all of which I can supply), but which has not yet been created as a node in the database? The function I propose would add the node, retaining any pre-supplied attributes, and would return either $nid (integer) or the $node object itself (with new attributes, especially nid, populated). In effect, this would migrate about 25 lines of code from import_image.module to image.module, and would be a hook that other importing modules could use if their image files came from a non-HTTP source. If you aren't interested in making these changes, I'll abide with what you have now, and just risk that I might have to do a rewrite in the future. But I think the image_build_derivatives() [non-private] and/or the other proposed function [which might be called image_build_node() for example) might have value to other developers. For instance, a module might someday exist that takes PDF or PS files, renders the first page as a PNG or JPG, and turns that into an image node for placement in a book hierarchy along with a download attachment of the original file. How do I know this is plausible? Well, my boss asked me just last week if such a thing were possible, because we may have a customer willing to pay me to develop it and release the code as GPL when it's done. :-) [This is by no means a certainty; we're just exploring options. The customer has an extremely large document library of PDF/PS files and they are wanting to webify access to it.] I would very much appreciate and respect your opinions, testing reports, suggestions, and constructive criticism of my module so far. I'm looking to get it polished up in the next couple of days and then move it from sandbox to contributions/modules. I've also submitted a project node for it, but experience says it may be a week or more before that gets approved (my last one was a week ago and still isn't on drupal.org yet). The code repository is at: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher/image… Kind regards, Scott (drupal.org "syscrusher") -- -----------------------+------------------------------------------------------ Scott Courtney | "I don't mind Microsoft making money. I mind them scott(a)4th.com | having a bad operating system." -- Linus Torvalds http://4th.com/ | ("The Rebel Code," NY Times, 21 February 1999) | PGP Public Key at http://4th.com/keys/scott.pubkey

2 6

[drupal-devel] Re: [contributions(DRUPAL-4-5):sheldon]
by Sheldon Rampton 04 Apr '05

04 Apr '05

Jim Riggs wrote: >So what's up with all of contrib being tagged for 4.5 this morning? >Did that mess up the branching of a lot of contrib? All of my >modules look fine, because they already had 4.5 branches. Items that >didn't, though, may now be branched even though they don't work with >4.5. Looks like some repair work may be in order... This is my mistake. I apologize. I was trying to simply tag my interwiki module, and got confused by the program I'm using (CVL on Mac OS X). It has a "Tag Files" command in its "Work Area" menu, so I selected the interwiki module in my work area and then selected the "Tag Files" command. To my surprise, it started iterating through all of contrib, and I didn't know how to stop it. After this happened, I realized that there's a separate "Tag" command in CVL's "File" menu. I'm guessing that this is what I should have used. I'm new to CVS and to CVL, and this isn't the first frustrating experience I've had with it. However, it's the first time that something like this has negatively affected Drupal's contributions repository. Once again, I apologize, but in my defense, the interface to CVL is pretty damn confusing. I'd like to find a simple tutorial so I can learn how to just use CVS directly from my terminal command line. Can someone point me to one? --Sheldon

4 3

[drupal-devel] Re: [contributions(DRUPAL-4-5):baudolino] contributions/modules/atom
by Dries Buytaert 04 Apr '05

04 Apr '05

On 04 Apr 2005, at 08:23, drupal-cvs(a)drupal.org wrote: > User: baudolino Branch: DRUPAL-4-5 Date: Mon, 4 Apr 2005 06:23:04 > +0000 > > Log message: > > - Added DRUPAL-4-5. baudoline, I blocked your CVS access. Randomly branching modules is _not_ a good idea. -- Dries Buytaert :: http://www.buytaert.net/

1 0

[drupal-devel] [bug] buffering not stopped after buffer done with
by willmoy 04 Apr '05

04 Apr '05

Issue status update for http://drupal.org/node/19933 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: willmoy Reported by: willmoy Updated by: willmoy Status: patch Attachment: http://drupal.org/files/issues/bootstrap.inc_1.patch (547 bytes) When visiting a page which is being buffered so it can be cached, the output buffer is not flushed when buffering is done with (i.e. when the cache is saved, before hook_exit is invoked). The page is not returned to the client until after hook_exit. Adding ob_end_flush solves that and maintains php 4.* compatibility. (Most ob_* functions came in php 4.2) willmoy

2 1

[drupal-devel] Re: [contributions(DRUPAL-4-5):baudolino] contributions/docs/developer
by Jonathan Chaffer 04 Apr '05

04 Apr '05

On Apr 4, 2005, at 2:22 AM, drupal-cvs(a)drupal.org wrote: > User: baudolino Branch: DRUPAL-4-5 Date: Mon, 4 Apr 2005 06:22:53 > +0000 > > Log message: > > - Added DRUPAL-4-5. Did this mistake happen *twice* in two days? Kjartan, can we roll back to before this mess? -- Jonathan Chaffer Applications Developer, structure:interactive (616) 364-7423 http://www.structureinteractive.com/

1 0