- Development - lists.drupal.org

[drupal-devel] Re: taxonomy nice URLs
by Aldon Hynes 23 Mar '05

23 Mar '05

Well, if we want to tie it together nicely, I would like to propose following the Goggle syntax e.g. horse+cars (Nodes in both the horse and the cars terms) horse+OR+cars (Nodes in either the horse or the cars terms) horse+OR+cars+-trucks (Nodes in either the horse or the cars terms but not in the trucks term) Aldon

3 2

[drupal-devel] taxonomy nice URLs
by Julian Bond 23 Mar '05

23 Mar '05

I did some work last night on tying to implement text URLs instead of the current numeric ones for taxonomy pages. So /taxonomy/vterm/Tags/horse+riding instead of /taxonomy/term/23 What I've been trying is /taxonomy/vterm/vocab_name/term_name all nodes for term term_name in vocabulary vocab_name using vterm means that the old /term/ still works. I think /taxonomy/tterm/term_name is a mistake because nodes in Forum:UK (say) are not necessarily grouped or similar to nodes tagged with Location:UK. But maybe there is a good reason to group all nodes with the same spelt tag even if the tags are from different vocabs. To achieve this I needed two helper functions taxonomy_get_vocabulary_by_name($name) taxonomy_get_term_by_name_and_vid($name, $vid) It's then pretty easy to take /taxonomy/vterm/Tags/horse+riding and turn it into a comma delimited set of tids (probably just one) and pass it to taxonomy_term_page(); In taxonomy_get_term($tid), a join to {vocabulary} to get the vocabulary.name field makes modifying taxonomy_link to generate these urls easy. Thoughts? -- Julian Bond Email&MSM: julian.bond at voidstar.com Webmaster: http://www.ecademy.com/ Personal WebLog: http://www.voidstar.com/ M: +44 (0)77 5907 2173 T: +44 (0)192 0412 433 S: callto://julian.bond/

6 16

[drupal-devel] [feature] More improvements to forum help language
by nysus 23 Mar '05

23 Mar '05

Issue status update for http://drupal.org/node/18732 Project: Drupal Version: cvs Component: forum.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: nysus Updated by: nysus Status: patch Attachment: http://drupal.org/files/issues/forum_7.patch (2.45 KB) Here's some more langauge improvements to the forum help text in the forum_help() function for the following Drupal pages: 'admin/forum': Got rid of technical jargon and improved readability and flow of sentences. 'admin/forum/add/container': added a concrete example for additional clarification 'admin/forum/add/forum': Got rid of technical jargo, improved readability and flow of sentences, added a concrete example for additional clarification. nysus

5 10

[drupal-devel] [feature] Pass include and exclude parameters to cron.php for fine grained cron timing
by moshe weitzman 23 Mar '05

23 Mar '05

Issue status update for http://drupal.org/node/19173 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: robertDouglass Reported by: robertDouglass Updated by: moshe weitzman Status: patch an alternative approach is to make a quick PHP page which simply calls mailhandler_cron and any others that need to be called more frequently than normal. then call that php page from cron every couple minutes ... not so sure this complexity is worth having. moshe weitzman Previous comments: ------------------------------------------------------------------------ March 20, 2005 - 05:08 : robertDouglass Attachment: http://drupal.org/files/issues/cronpatch.txt (1.99 KB) Some sites need fine grained timing for cron runs. For example, a site that relies heavily on moblogging, mailhandler or any other email based function would want to connect with the email server pretty often, say ever 2-5 minutes. On another site I'm working on we generate flat files for all of a certain node type on a regular basis, though not every 2-5 minutes. Thus the need for cron tasks on different schedules. This patch allows you to make a list of modules to either include or exclude when running cron, so that several cron tasks for one site can be defined. The default behavior in the absence of both parameters is to run all, so the patch preserves backwards compatibility. * Examples: * * runs all hooks * http://mysite.com/cron.php * * runs all hooks except the search and aggregator modules * http://mysite.com/cron.php?exclude=search,aggregator * * runs only search, archive and aggregator modules * http://mysite.com/cron.php?includ=search,archive,aggregator ------------------------------------------------------------------------ March 23, 2005 - 16:23 : Dries Isn't it possible to run all cron functions every 2-5 minutes? The impact of that should be minimal.

1 0

[drupal-devel] [feature] Pass include and exclude parameters to cron.php for fine grained cron timing
by Dries 23 Mar '05

23 Mar '05

Issue status update for http://drupal.org/node/19173 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: robertDouglass Reported by: robertDouglass Updated by: Dries Status: patch Isn't it possible to run all cron functions every 2-5 minutes? The impact of that should be minimal. Dries Previous comments: ------------------------------------------------------------------------ March 20, 2005 - 12:08 : robertDouglass Attachment: http://drupal.org/files/issues/cronpatch.txt (1.99 KB) Some sites need fine grained timing for cron runs. For example, a site that relies heavily on moblogging, mailhandler or any other email based function would want to connect with the email server pretty often, say ever 2-5 minutes. On another site I'm working on we generate flat files for all of a certain node type on a regular basis, though not every 2-5 minutes. Thus the need for cron tasks on different schedules. This patch allows you to make a list of modules to either include or exclude when running cron, so that several cron tasks for one site can be defined. The default behavior in the absence of both parameters is to run all, so the patch preserves backwards compatibility. * Examples: * * runs all hooks * http://mysite.com/cron.php * * runs all hooks except the search and aggregator modules * http://mysite.com/cron.php?exclude=search,aggregator * * runs only search, archive and aggregator modules * http://mysite.com/cron.php?includ=search,archive,aggregator

1 0

[drupal-devel] Core Folksonomy > 98% Finished. Review Needed.
by Morbus Iff 23 Mar '05

23 Mar '05

Alright. I've just committed to sandbox/morbus/folksonomy_shared what I've considered my "worthy of being an official patch" code. At this point, I'm looking for code review, UI comments, blah blah blah blah. I'll pause for comments before I consider making this an Issue/Feature Request. To recap: * only one new column is added: vocabulary.tags. * there is nothing in here about "My Tags" or "Similar", etc. * the big difference between core / "free tagging": * an input box for tags to be typed in, not a selectbox. * free tagging vocabularies can grow very very large. As such, the patch: * uses the new vocabulary.tags to determine what sort of UI to use. * enhances the admin/taxonomy to use paged displays for tagged vids. * besides the above, treats "free tags" vid as any other vid, which means admins can define a hierarchy, related terms, synonyms, RSS feeds are possible, tid+tid+tid URLs are fine, etc., etc. Everything else is just elementary changes to support the above. Here are the latest round of screenshots. http://disobey.com/detergent/2005/drupal_folkdef.jpg Create/edit vocabulary screen. Per discussions with #drupal, I've dropped all mention of "Community created". "Free tagging", and the help text beneath it, were tweaked/hemmed/hawed amongst #drupal participants. http://disobey.com/detergent/2005/drupal_folknodeedit.jpg Creating/editing a node. Notice the help text, the input box, and the fact multiple vocabularies are still possible (the "Controlled Test" is a regular, admin-controlled vocabulary). http://disobey.com/detergent/2005/drupal_folknodesubmit.jpg The result of the previous screenshot. Notice how, on output, tags are treated just like any other vocabulary term. "Alice" is from our "Controlled Test" in the previous screenshot. http://disobey.com/detergent/2005/drupal_folkpager1.jpg The new admin/taxonomy. Lots of tiny improvements here. Non- "free tagging" vocabularies are display as they are in core. Free tagging vocabularies, on the assumption that they can grow very large, only display under "view terms". Also note the addition of help text for vocabs without terms. http://disobey.com/detergent/2005/drupal_folkpager2.jpg What happens when you click on "view terms" of any vocabulary (free tagging or not). Pages are divided at the 25 term mark. The grey squiggly means "this screenshot was too long so just imagine a bunch of terms here"). Comments? Go nuts. -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

2 1

[drupal-devel] [bug] image.gd.inc isn't compatible with gd 1
by walkah 23 Mar '05

23 Mar '05

Issue status update for http://drupal.org/node/18700 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: critical Assigned to: stefan nagtegaal Reported by: stefan nagtegaal Updated by: walkah Status: patch Attachment: http://drupal.org/files/issues/image-inc_2.patch (6.3 KB) cleaner version. busted by the punctuation police. also fixes the settings page (merged that too quickly). walkah Previous comments: ------------------------------------------------------------------------ March 10, 2005 - 13:13 : stefan nagtegaal The idea behind the image.gd.inc file is that it should be usable for people who are using GD 1 and GD 2. Unfortunatly, the way it is written now, only support for GD 2 can be given because: Current way of determining GD 2, is not right: if (function_exists('imageCreateTrueColor')) { // GD 2 Handling; } else { // GD 1 Handling } this doesn't work.. imageCreateTrueColor() was already implemented in GD 1, only it failed to work properly.. See these pages: http://www.php.net/imagecratetruecolor#25234 & http://www.php.net/imagecratetruecolor#25487 According to this comments, we should implement this like this: // Silence errors using the @ $image = @imageCreateTrueColor(......); if (!$image) { // GD 1 Handling; } ------------------------------------------------------------------------ March 11, 2005 - 13:03 : stefan nagtegaal Attachment: http://drupal.org/files/issues/image-inc.patch (2.26 KB) Attached patch improves: - the way which deals with the detection of GD 1 or GD 2; - error messages as reported by Steven here: http://drupal.org/node/17645; After applying this to HEAD/Drupal 4.6 RC, we can close the following issues: - http://drupal.org/node/17645; - http://drupal.org/node/13027; Please test/comment and apply attached patch.. ------------------------------------------------------------------------ March 12, 2005 - 03:41 : Dries Isn't the approach taking in http://drupal.org/node/13027 nicer? It doesn't surpress warnings/errors. Maybe that approach doesn't work? ------------------------------------------------------------------------ March 12, 2005 - 03:50 : Bèr Kessels -1 on supressing errors with @. Its ugly, and hardly used in Drupal. We should use our own error handling at all times. ------------------------------------------------------------------------ March 12, 2005 - 04:42 : stefan nagtegaal I will make a new patch, with the more elegant approach you mentioned Dries... ------------------------------------------------------------------------ March 12, 2005 - 12:05 : stefan nagtegaal As noticed before in this issue.. The function imageCreateTrueColor _does_ exist, even in versions of GD before 1.8 only it was broken.. So, function_exist() doesn't work on that the function, because it really _does_ exist, but the fact is that it's simply broken.. So unfortunatly, the more elegant solution doesn't seem to work.. ------------------------------------------------------------------------ March 12, 2005 - 13:01 : pz Stupid question, why not just use the gd_info function? ------------------------------------------------------------------------ March 13, 2005 - 03:54 : Dries What versions of PHP have those old GD toolkits? PHP 4.3.10 comes with GD 2.0.28, it seems, as does PHP 5.0.3. PHP 4.3.3, Drupal's current minimum PHP requirement, comes with GD 2.0.15. >From the looks, we don't need GD 1 handling at all ... (but we might need a global version check). Thoughts? ------------------------------------------------------------------------ March 13, 2005 - 05:32 : stefan nagtegaal PHP 4.1.2 comes with GD 1.62.. The nasty/hackish code with the build-in GD toolkit, is exactly why I proposed to split the image.inc into a separate image.gd1.inc and image.gd2.inc. I would propose a patch which does: - remove all the GD < 2 function calls like imageCreate() and imageCopyResized() and have a real GD 2 compatible image.inc; - introduce a new image.gd1.inc file into Walkahs sandbox; If the module is being moved to the contributions, the image.gd1.inc is also available for people without proper GD 2 support; - more userfriendly and helpfull error reporting for the image-api.. If we agree about this, I'll make patches for inclusion into 4.6.. Which does contain the before mentioned problems with the current usage.. Please, I would like to have some feedback about this... ------------------------------------------------------------------------ March 13, 2005 - 07:55 : stefan nagtegaal Attachment: http://drupal.org/files/issues/image-inc_0.patch (2.99 KB) As proposed above, patch for image.inc.. Please comment or apply... The image.gd1.inc file wil be posted after this post... ------------------------------------------------------------------------ March 13, 2005 - 07:57 : stefan nagtegaal Attachment: http://drupal.org/files/issues/image.gd1.inc (2.07 KB) And the image.gd1.inc file for Walkahs sandbox... Tell me what you all think about this.. ------------------------------------------------------------------------ March 13, 2005 - 10:11 : Dries I'm OK with this! I'd like to await James' input though. ------------------------------------------------------------------------ March 15, 2005 - 05:16 : stefan nagtegaal Walkah, are you out there??? Ber, do you agree with Dries that this is a better approach? ------------------------------------------------------------------------ March 15, 2005 - 06:15 : Bèr Kessels I like this approach because it: uses a good default, and uses that well. Provides flexibility for those not wanting that default, without extra complexity. Uses modules to add extra functionality instead of configuration options. big +1 from me. ------------------------------------------------------------------------ March 16, 2005 - 09:33 : walkah Hey guys, sorry I've been silentlly watching this thread. Here's my take: +1 - I like the approach, and I agree that (especially now that we're requiring 4.3.x) making the "default" support gd2 only isn't a bad idea. I'm working on some additions to this patch, however, to basically make the toolkit checking a bit more robust (working on top of Stefan's). Great job Stefan, keep it up! ------------------------------------------------------------------------ March 23, 2005 - 14:40 : walkah Attachment: http://drupal.org/files/issues/image-inc_1.patch (5.39 KB) OK - attached is said patch. It also includes a fix to the recent system.module patch (where it was reporting that no toolkits were installed if only the built-in one was). I've also included a link on admin/settings to http://drupal.org/project/image where I will post information about getting other toolkits, etc. (I think that makes sense). comments?

1 0

[drupal-devel] [bug] image.gd.inc isn't compatible with gd 1
by walkah 23 Mar '05

23 Mar '05

Issue status update for http://drupal.org/node/18700 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: critical Assigned to: stefan nagtegaal Reported by: stefan nagtegaal Updated by: walkah Status: patch Attachment: http://drupal.org/files/issues/image-inc_1.patch (5.39 KB) OK - attached is said patch. It also includes a fix to the recent system.module patch (where it was reporting that no toolkits were installed if only the built-in one was). I've also included a link on admin/settings to http://drupal.org/project/image where I will post information about getting other toolkits, etc. (I think that makes sense). comments? walkah Previous comments: ------------------------------------------------------------------------ March 10, 2005 - 13:13 : stefan nagtegaal The idea behind the image.gd.inc file is that it should be usable for people who are using GD 1 and GD 2. Unfortunatly, the way it is written now, only support for GD 2 can be given because: Current way of determining GD 2, is not right: if (function_exists('imageCreateTrueColor')) { // GD 2 Handling; } else { // GD 1 Handling } this doesn't work.. imageCreateTrueColor() was already implemented in GD 1, only it failed to work properly.. See these pages: http://www.php.net/imagecratetruecolor#25234 & http://www.php.net/imagecratetruecolor#25487 According to this comments, we should implement this like this: // Silence errors using the @ $image = @imageCreateTrueColor(......); if (!$image) { // GD 1 Handling; } ------------------------------------------------------------------------ March 11, 2005 - 13:03 : stefan nagtegaal Attachment: http://drupal.org/files/issues/image-inc.patch (2.26 KB) Attached patch improves: - the way which deals with the detection of GD 1 or GD 2; - error messages as reported by Steven here: http://drupal.org/node/17645; After applying this to HEAD/Drupal 4.6 RC, we can close the following issues: - http://drupal.org/node/17645; - http://drupal.org/node/13027; Please test/comment and apply attached patch.. ------------------------------------------------------------------------ March 12, 2005 - 03:41 : Dries Isn't the approach taking in http://drupal.org/node/13027 nicer? It doesn't surpress warnings/errors. Maybe that approach doesn't work? ------------------------------------------------------------------------ March 12, 2005 - 03:50 : Bèr Kessels -1 on supressing errors with @. Its ugly, and hardly used in Drupal. We should use our own error handling at all times. ------------------------------------------------------------------------ March 12, 2005 - 04:42 : stefan nagtegaal I will make a new patch, with the more elegant approach you mentioned Dries... ------------------------------------------------------------------------ March 12, 2005 - 12:05 : stefan nagtegaal As noticed before in this issue.. The function imageCreateTrueColor _does_ exist, even in versions of GD before 1.8 only it was broken.. So, function_exist() doesn't work on that the function, because it really _does_ exist, but the fact is that it's simply broken.. So unfortunatly, the more elegant solution doesn't seem to work.. ------------------------------------------------------------------------ March 12, 2005 - 13:01 : pz Stupid question, why not just use the gd_info function? ------------------------------------------------------------------------ March 13, 2005 - 03:54 : Dries What versions of PHP have those old GD toolkits? PHP 4.3.10 comes with GD 2.0.28, it seems, as does PHP 5.0.3. PHP 4.3.3, Drupal's current minimum PHP requirement, comes with GD 2.0.15. >From the looks, we don't need GD 1 handling at all ... (but we might need a global version check). Thoughts? ------------------------------------------------------------------------ March 13, 2005 - 05:32 : stefan nagtegaal PHP 4.1.2 comes with GD 1.62.. The nasty/hackish code with the build-in GD toolkit, is exactly why I proposed to split the image.inc into a separate image.gd1.inc and image.gd2.inc. I would propose a patch which does: - remove all the GD < 2 function calls like imageCreate() and imageCopyResized() and have a real GD 2 compatible image.inc; - introduce a new image.gd1.inc file into Walkahs sandbox; If the module is being moved to the contributions, the image.gd1.inc is also available for people without proper GD 2 support; - more userfriendly and helpfull error reporting for the image-api.. If we agree about this, I'll make patches for inclusion into 4.6.. Which does contain the before mentioned problems with the current usage.. Please, I would like to have some feedback about this... ------------------------------------------------------------------------ March 13, 2005 - 07:55 : stefan nagtegaal Attachment: http://drupal.org/files/issues/image-inc_0.patch (2.99 KB) As proposed above, patch for image.inc.. Please comment or apply... The image.gd1.inc file wil be posted after this post... ------------------------------------------------------------------------ March 13, 2005 - 07:57 : stefan nagtegaal Attachment: http://drupal.org/files/issues/image.gd1.inc (2.07 KB) And the image.gd1.inc file for Walkahs sandbox... Tell me what you all think about this.. ------------------------------------------------------------------------ March 13, 2005 - 10:11 : Dries I'm OK with this! I'd like to await James' input though. ------------------------------------------------------------------------ March 15, 2005 - 05:16 : stefan nagtegaal Walkah, are you out there??? Ber, do you agree with Dries that this is a better approach? ------------------------------------------------------------------------ March 15, 2005 - 06:15 : Bèr Kessels I like this approach because it: uses a good default, and uses that well. Provides flexibility for those not wanting that default, without extra complexity. Uses modules to add extra functionality instead of configuration options. big +1 from me. ------------------------------------------------------------------------ March 16, 2005 - 09:33 : walkah Hey guys, sorry I've been silentlly watching this thread. Here's my take: +1 - I like the approach, and I agree that (especially now that we're requiring 4.3.x) making the "default" support gd2 only isn't a bad idea. I'm working on some additions to this patch, however, to basically make the toolkit checking a bit more robust (working on top of Stefan's). Great job Stefan, keep it up!

1 0

[drupal-devel] image tool kits
by Gordon Heydon 23 Mar '05

23 Mar '05

Hello, I have just uploaded 2 image tool kits for use with the new image api that is now in drupal, and going to appear in 4.6. The first uses the php imagick extension so there is no shelling out to execute the convert command. This works well except I do find it a bit slow. The second uses the php imlib extension which is extremely fast, and uses all native php. I have uploaded these into my sandbox, and if possible I would like these included in James new image module. But I do think that there should be a better place to put these. Maybe not in core, but maybe a place in contributions somewhere for image tool kits. -- Gordon Heydon <gordon(a)heydon.com.au>

3 2

[drupal-devel] Drupal 4.6 update
by Dries Buytaert 23 Mar '05

23 Mar '05

Hello world, some important updates on the Drupal 4.6 release process. Either tonight or tomorrow I'm going to create the DRUPAL-4-6 branch for core. Clearly, this has a number of implications: 1. The newly created DRUPAL-4-6 branch will go into "maintenance mode". This means that I'll be more strict as to what gets committed. 2. At the same time, Drupal HEAD will be opened up for development! This means I'll begin committing larger patches and new features. Dust off your editors and repeat after me: "Yay!". 3. I will not commit "intrusive patches" (like the node revision patch) until Drupal 4.6 is released. Breaking APIs during the release process would complicate the life of those who are in the process of preparing their contributions for use with Drupal 4.6. Fortunately, only a few patches qualify as being "intrusive". Unfortunately these patches will have to be maintained for another week or two. 4. If you promised to provide one or more improvements for inclusion in DRUPAL-4-6, you better be quick, or you might have to provide two versions of your patch -- one against HEAD and one against DRUPAL-4-6. 5. I don't know when Drupal 4.6 will be released, but as hinted above, I will take at least another week or two (I'll be traveling next week). If all goes well, Drupal 4.6 should be released in the beginning of April. 6. We could do with a "Bugfix Friday" -- or some other concentrated effort to resolve a number of bugs filed against DRUPAL-4-6. I won't be around on Friday but maybe someone else wants to take a lead in organizing this. If anything, please help look at the (critical) bug reports. -- Dries Buytaert :: http://www.buytaert.net/

5 4