March 2005 - Development - lists.drupal.org

[drupal-devel] [bug] file_check_location is not working on Windows 2000
by killes 01 Mar '05

01 Mar '05

Issue status update for http://drupal.org/node/10885 Project: Drupal -Version: 4.5.2 +Version: cvs Component: file system Category: bug reports Priority: critical Assigned to: Anonymous Reported by: ccourtne Updated by: killes(a)www.drop.org Status: patch Still applies. killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ September 16, 2004 - 14:46 : ccourtne Currently file_check_location is always returning false when passed a file as the $source path. If a directory is passed in $soruce file_check_location works. I've tracked this down to realpath returning an empty string when passed a relative path which points to a file. This probably goes unnoticed if you are using the file.api's to construct relative paths to the druapl file directory since check_location failing just causes the durpal file directory to get added which is what you wanted in the first place. Replacing this line $source = realpath(dirname($source)); with this $source = realpath(dirname($source)); fixes it on my windows box using PHP 4.3.8. I don't have things set up to do patches on my windows boxes here at work yet. I'll submit a formal patch tonight. ------------------------------------------------------------------------ September 16, 2004 - 14:47 : ccourtne Dag nabit. Replace $source = realpath($source); with $source = realpath(dirname($source)); Craig ------------------------------------------------------------------------ September 16, 2004 - 14:56 : Anonymous Attachment: http://drupal.org/files/issues/file-inc-file_check_location.patch (639 bytes) The sooner there are patches, the better it is... I tested this approach on my server and it works. Steef ------------------------------------------------------------------------ September 17, 2004 - 02:34 : ccourtne Attachment: http://drupal.org/files/issues/checklocation.patch (666 bytes) Here is the patch. ------------------------------------------------------------------------ February 23, 2005 - 01:30 : dan90(a)drupal.org This also fixed my file upload problems with some nonstandard paths under Linux/apache, php 4.3.4 drupal 4.5.2. maybe we should remove mention of windows 2000?

1 0

[drupal-devel] Jimmy Wales
by Jonathan Chaffer 01 Mar '05

01 Mar '05

Jimmy Wales (Wikipedia) was across the aisle from me and directly ahead of John and Matt on the way back from DrupalCon. We had a nice conversation. Some of the highlights: - He is interested in taxonomy, especially the possibility of syndicated and synchronized vocabularies. - He said it would be great if we had the ability to make a special syntax like double-brackets link automatically to Wikipedia. I briefly explained our filter system, and said that if he wanted we could knock out such a filter in an afternoon. Looking in contrib, it looks like interwiki.module can do this already; maybe it's just a matter of code review. - If we have need for writing-based tasks (like translation), he may be able to provide some manpower for us in that area. - "So, could I use this for my blog?" "Yes!" - He talked a bit about Wikinews, and how it's silly to have a news site without RSS, but the wiki format causes updates to be too frequent to make RSS sensible. He wants to move finished articles out of the wiki and into another system, and mentioned Drupal as a possibility for this. We may be getting a follow-up email at info(a)drupal.org. -- Jonathan Chaffer Applications Developer, structure:interactive (616) 364-7423 http://www.structureinteractive.com/

4 3

Re: [drupal-devel] CCK Nomenclature
by Chris Cook 01 Mar '05

01 Mar '05

On Mon, 28 Feb 2005 20:58:10 +0000, Gabor Hojtsy <gabor(a)hojtsy.hu> wrote: > Node != content. Or if we use the name 'content' for 'node', we could > actually replace all apperances of 'node' with 'content'... I assumed we > use the 'content' word on the interface to not scare people, but > acknowledging that a 'content' is less then a 'node'. It all comes down > to the definition of course, so both of these words can mean the same. > But is a 'user profile' (which is going to be buildable with CCK) a > 'content'??? Is a product a 'content'? I would not use this word for it. > But then I am not a native English speaker, so I might have a different > view on it... In my defense, perhaps I don't fully understand the purpose of the new module. Jonathan Chaffer wrote: > Suppose node.module handles all of the content types defined by node > modules as today, and a new module is added that handles the > administrator-defined content types. What should that module be called? I understood that this new module will manage administrator defined "content" types and that it would not replace node.module. I agree that a node may not necessarily be content but it does not sound like this module will be used to define user accounts as those would logically be be defined in the user module. If I am mistaken then some clarification regarding this module's purpose may be in order. As someone whose mother tongue is English I will say that I consider any entered data (i.e. is not text that is part of the user interface) to be technically content. That would include user profiles, blog comments, photos, hyperlinks, categories, et cetera. Note that I said "technically" though and that I don't think that end users should need to understand what either content or a node is. I may also be alone in my definition.

1 0

[drupal-devel] [task] Preview when clicking upload is confusing
by killes 01 Mar '05

01 Mar '05

Issue status update for http://drupal.org/node/10590 Project: Drupal Version: cvs Component: upload.module Category: tasks Priority: normal Assigned to: ccourtne Reported by: ccourtne Updated by: killes(a)www.drop.org Status: patch Still applies. Not sure we like the implementation. Sessions might be better. Screenshots to illustrate the problem too. killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ September 6, 2004 - 14:24 : ccourtne Attachment: http://drupal.org/files/issues/uploadpreview.patch (1.15 KB) The screen radically changing when the use clicks upload is confusing. Many times a user may upload an attachment half way through typing a story (for example to upload an inline image) and adding the preview to the top of the screen would only confuse what they are doing. This patch adds a new op called nodeapi which validates the node and then re-displays the form sans preview. This allows those modules who wish to add new methods not be forced to preview. Once the preview is displayed it will stay on the screen. ------------------------------------------------------------------------ September 9, 2004 - 00:02 : ccourtne Attachment: http://drupal.org/files/issues/uploadpreview2.patch (1.49 KB) new patch that fixes typo and fixes breadcrumb and title

1 0

[drupal-devel] Re: Jimmy Wales
by Sheldon Rampton 01 Mar '05

01 Mar '05

Jonathan Chaffer wrote: >- He said it would be great if we had the ability to make a special >syntax like double-brackets link automatically to Wikipedia. I briefly >explained our filter system, and said that if he wanted we could knock >out such a filter in an afternoon. Looking in contrib, it looks like >interwiki.module can do this already; maybe it's just a matter of code >review. Aldon Hynes and I wrote interwiki.module specifically for this purpose. It can handle both single brackets and double brackets. Wikipedia's MediaWiki syntax uses both; double brackets are for internal links within Wikipedia, and single brackets are for external hyperlinks. There are other aspects of MediaWiki's simplified markup syntax that also might be worth emulating. For example, an asterisk at the beginning of a line translates into a <li> tag, with surrounding <ul> as needed. A pound sign translates into <li> with surrounding <ol>. And, list markup can be nested, e.g., *this item has three sub-items *#the first *#the second *#the third *this item has no sub-items *this item has two *#alpha *#beta Personally, I'd like to see a Drupal module version of the MediaWiki software, but creating it would require more programming skill than I possess. --Sheldon Rampton

1 0

[drupal-devel] [bug] module_invoke brokes default values
by chx 01 Mar '05

01 Mar '05

Project: Drupal Version: cvs Component: base system Category: bug reports Priority: critical Assigned to: chx Reported by: chx Updated by: chx Status: patch Attachment: http://drupal.org/files/issues/module_inc_no_default_nulls.patch (685 bytes) Try this: module_invoke('taxonomy', 'get_tree', 1); and compare the results with taxonomy_get_tree(1); What happens is that taxonomy_get_tree is called by the arguments 1, NULL, NULL, NULL which breaks it. Hence the patch. Every Drupal version I have met (4.4, 4.5, CVS) contains this error. I think this led module authors to not use module_invoke (at least I did so until now) which will be quite a problem if we decide on breaking up the modules into smaller pieces. chx -- View: http://drupal.org/node/17770 Edit: http://drupal.org/project/comments/add/17770

3 9

RE: [drupal-devel] adsense from google for drupal
by Boerland Bert 01 Mar '05

01 Mar '05

-----Original Message----- From: drupal-devel-bounces(a)drupal.org [mailto:drupal-devel-bounces@drupal.org]On Behalf Of Dries Buytaert [regarding usings ads for drupal] > That is awesome, Bert. We appreciate your contribution! :) Hate to push my luck, but I might get a better response if http://drupal.org/node/17905 is promoted to the frontpage. We still have to do some stuff. I'm willing to dontate as others might. But I am not that fond on paying the taxes of all the google ad payouts (esp in the Netherlands!). So for a generic account we might we might have to setup a drupal foundation that wont have to pay taxes. This was discussed some time ago on this list but I dont remember the outcome of this. Anyone? (put response please in thread on site) > Too bad you couldn't make it to FOSDEM. I'm sure there will be more > Drupal events in future. On the plus side, nobody of the drupal team got sick by/of me/my flue by me not showing up ;-)

4 7

RE: [drupal-devel] adsense from google for drupal
by Kobus Myburgh 01 Mar '05

01 Mar '05

Hi, What would this responsibility entail? I don't think my Drupal knowledge is good enough to start such a system from scratch, but I can surely maintain the code once it was written, and can research the legalities and so on. If I can get more detail on what this would entail, I might volunteer. Regards, Kobus >>> vlado(a)dikini.net 3/1/2005 9:01:00 AM >>> > > So for a generic account we might we > > might have to setup a drupal foundation that wont have to pay taxes. > > This was discussed some time ago on this list but I dont remember > > the outcome of this. Anyone? (put response please in thread on site) > Unfortunately, this has not been discussed in Antwerp. Should we set up > an IRC meeting to discuss this further? I think the foundation should be > EU-based. I cannot recommend Germany as a good place for something like > this... +1 for EU based foundation - the laws in Europe are generally very friendly to non-for profit foundations (AFAIK) I am not sure of the status and the legalities in UK but can do some research on that. What I suggest is let's take the facts in and decide on that basis - what will be the maintenance, administration involved, taxes, benefits, ease of access, etc... If anyone has experience running such a thing it's fine, but it might take over somebody's life. Any volunteers ? :) Cheers, Vlado

1 0

[drupal-devel] issues listings reverse chronologically.
by Bèr Kessels 01 Mar '05

01 Mar '05

Hi, Cross posting this to -docs ML, because people in there will have good ideas about this too. Whenever I look into the patch queue, I start at the end, wlaking up slowly. This works very well, because: * you can close a lot of them. * you are looking at them chonologically. * less chance of duplicating (old) bugs. * we get mails of the bugs/features etc when they are new anyway, s owe do not miiss new features because they are "on the last page". So I suggest we turn around all these listings [1] to speed up cleaning of the queues. So oldest first, newest last. At least try my approach once (starting at the end). You will notice it works pretty well. Bèr [1] http://drupal.org/project/issues?from=220&projects=3060&states=1&categories… -- [ Bèr Kessels | Drupal services www.webschuur.com ]

2 1

[drupal-devel] [feature] Option to disable printer friendly version for book module
by Bèr Kessels 01 Mar '05

01 Mar '05

Issue status update for http://drupal.org/node/13211 Project: Drupal Version: cvs Component: book.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: kbahey Updated by: Bèr Kessels Status: patch Levering this over to http://drupal.org/node/636 Bèr Kessels Previous comments: ------------------------------------------------------------------------ November 20, 2004 - 07:30 : kbahey Attachment: http://drupal.org/files/issues/book_17.patch (2.18 KB) I wanted an option for the book module to NOT display a 'printer-friendly version' link for every node. So, I implemented an option for the book module to allow this to be turned off. Using this option: - Go to the /admin/node/book - Uncheck the box that say 'show printer friendly links for books' if you want - Click 'Save settings' There will be no printer friendly links after you do this. Please consider applying this patch to CVS. ------------------------------------------------------------------------ November 21, 2004 - 18:01 : kbahey Setting status to patch, so that it is discussed on the mailing list. ------------------------------------------------------------------------ November 26, 2004 - 00:36 : kbahey Attachment: http://drupal.org/files/issues/book_18.patch (2.3 KB) I have remade this patch to match what is in the current CVS version. The previous patch had conflicts with the latest CVS version. Will this be included in the base any time soon? ------------------------------------------------------------------------ November 26, 2004 - 01:07 : Bèr Kessels options, options, options. Alltough an option is an easy method to add fetaures, while not breaking backwards compatibility, it is generally very bad for useability. I am therefore a -1 for this patch. kbahey, Eventhough the functionality is very nice, I would rather see you either make thisa single site wide setting (in books settings). Or -even better IMO- make the link dis(appear) through a theme function. Or -and thats the best option IMO- help the folks who are working on a better $links (the links under each node) and introduce a general API and theme system to show, hide and markup those links on nodes. ------------------------------------------------------------------------ November 26, 2004 - 22:55 : Anonymous "I would rather see you either make thisa single site wide setting (in books settings). " That is what it already does. The setting is global in books settings, and not in every individual book. It just so happens, for a reason unknown to me, that book's setting page is under administer -> content -> books, and not under administer -> settings -> book like other modules. "Or -even better IMO- make the link dis(appear) through a theme function. Or -and thats the best option IMO- help the folks who are working on a better $links (the links under each node) and introduce a general API and theme system to show, hide and markup those links on nodes. " Those sound like a better option for sure. If the option is in admin -> themes -> configure, under the "Toggle display" part. I am not familiar with that code at this point. Will do some digging to see what can be done. ------------------------------------------------------------------------ February 17, 2005 - 15:58 : kbahey One of the objections to this patch is that it introduces one more option. If I resubmit this patch without an option, does it have a change to be accepted? I will rely on the new $conf variable being able to override variable_get(), so there is no option screen needed. How about that? ------------------------------------------------------------------------ February 17, 2005 - 16:23 : stefan nagtegaal Imo this is a theme feature, so it should be handled in there.. A link management system should be the best to handle such things, but is - unfortunatly - quite hard to inplement... ------------------------------------------------------------------------ February 17, 2005 - 21:41 : kbahey Ideally it would be a theme function. However, most themes, specially the ones that ship with the standard Drupal distribution, do not provide a way to turn that off at will. Most ideal solution is the link management interface you mention, where site admins can turn on off any link they like for any module. But that does not exist so far, so until either one of the above solutions exist, I will be submitting a patch that allows turning off the printer friendly link. ------------------------------------------------------------------------ February 17, 2005 - 21:52 : Bèr Kessels With a theme function, is not meant a function that will make an option on your screen. "Ideally it would be a theme function. However, most themes, specially the ones that ship with the standard Drupal distribution, do not provide a way to turn that off at will." With a theme function, stefan most probablt meant a function theme_printer_friendly(). That function would return the link. If you want to turn it off, you woudl have to make a function yourtheme_printer_friendly() that does /not/ return that link. Problemd solved, without adding more clutter to the UI. ------------------------------------------------------------------------ February 18, 2005 - 03:48 : kbahey Attachment: http://drupal.org/files/issues/book-2.patch (1017 bytes) There are no UI changes in this patch. If someone wants to turn off the printer friendly link, then all they do is : - Go to settings.php - Uncomment the lines that have the $conf variable and the closing bracket - Add a line like this: 'book_hide_printer_friendly' => 1, That is it. No menus, no options, nothing ... Preferrably, we should document these 'hidden' options in the future, under an 'Advanced Configuration' section. ------------------------------------------------------------------------ February 18, 2005 - 06:42 : nedjo kbahey's point reflects a general problem in Drupal--much of the content returned is hard-coded, generated in modules, and therefore without any way of being overridden. As a site administrator, my feeling is that I should have full control over what I present to my users and therefore /nothing/ should be forced on me. My observation is that, many times when suggestions are made to try to free Drupal's core from hard-coded content, there is resistance on the basis that this would require more configuration. Fair enough--but sticking us with content we don't want isn't much of an option either. The three options suggested in this issue - theming, ui configuration options, and settings.php configuration options - all have some merit, and are all currently in use; but it looks like we need a larger discussion, and perhaps some fresh approaches. I'm thinking the proposed solution of passing the content filtering to theming is tempting, but ultimately problematic. Basically, the theme approach would say: generate content pass to theme function optionally (and manually), insert theme override function that doesn't display the content that's been generated In a practical sense, this approach is cumbersome because it requires, for every optional content element, (a) edits to the core module to pass content through a theme_ function, and (b) manual theme editing to write an override function. (This second piece, of course, necessitates extra work every time a theme is updated, even if we use otherwise unmodified themes). The workflow of first generating content and then overriding it is more than inefficient--it suggests a confusion in the separation of content and presentation. Ideally, I still believe, a theme should answers the question /how/ do you want to present content--not /what/ do you want to present. Of course, in Drupal, we break this ideal routinely. But to push even more decision-making logic into the themes feels like a step in the wrong direction. Ultimately, if we don't want content displayed, probably we shouldn't generate it in the first place. My own preference is configuration options over hard-coded content (thought the lastest suggestion of hiding this option in settings.php seems a bit confusing--most admins will never know about this option). But maybe we need a completely different approach. It strikes me that the menu system provides a possible model. It offers a way to assign generated content to various categories, e.g., MENU_SUGGESTED_ITEM. Could we extend this approach to other types of content--allowing administrative override, as we do with the menu module? ------------------------------------------------------------------------ February 18, 2005 - 12:28 : Anonymous I plan to address this issue shortly on the Interface and useability meetings on dropalCOM. My vision on this is: If a setting requires frequent change, or if a setting is that of an oblect, such as a taxonomy term, or if a setting is user, role or permission sepcific, or if we cannot find a "good default" because an option differs per case [1] ** we will allow UI elelements ** we should not have UI config options, but settings in conf.php or htacess If a setting is technical, server aimed site specific and a good default can be found (e.g. settings for time to remain logged in) ** we should not have UI config options, but theme functions, for setting that are: clearly layout settings or, provide output (e.g should horizontal tabs be UL or not) or, very site specific [1] and on all outputted HTML,( off course.) [1] this is a debatable part, and thus needs some clarification. With cases i mean a targetted group. An example of a case is "community site" or "personal blog". Specific suites, will fit within these cases, but is more specific. This print_link thing is obviously very specific. There is not one case that would not want a print link. on contrary: the user-details with each post are only interesting for cases of community sites. "corporate sites" are not interested. So that post-info should be ui configurable, since 50% of the sites wants it, and 50% does not. A print link will suit 98% of the people, while hiding is only interesting for 2%. Thus it it specific. Bèr ------------------------------------------------------------------------ February 18, 2005 - 12:29 : Bèr Kessels ^-- That was me. logged out for some reason ------------------------------------------------------------------------ February 18, 2005 - 16:57 : kbahey Nedjo, You feel my pain. Here is another example of the need for options to turn on/off certain links. This site uses image gallery to display products. http://originaltilly.com/node/view/144&n=all As you notice, there are no links at the bottom for resolution, gallery, ...etc. When I asked the author (asitis.org) how he did it, he said he edited out the links he does not need! On other sites, he overrode it in the theme. Doing this stuff in the theme is really ugly, because a theme should not have a lot of logic in it, and I agree with nedjo it should be about presentation of content not fiddling with content. The other problem that I pointed out is that no 'standard' theme does that today. My resorting to $conf was basically to get over the "no new options" objection. The option would be there and are hidden from view. We can have a note in a ADVANCED.txt file describing what options can be set there are how to set them, then we have satisfied both camps, the average user will not get confused, the advanced user can do what they want. Another approach is to have those infrequent options grouped under an advanced tab or something, where theywould not confuse the average user. Guys: Please! Let us be more pragmatic about this options thing. We may be introducing options that have the potential for confusion, but the price we pay is more than that: - Creating fragmented and ugly hacks in some themes - Forcing the introduction of unneeded complexity in some themes - Not having a general solution out of the box - Depriving functionality for others who cannot modify themes. ------------------------------------------------------------------------ February 18, 2005 - 17:02 : moshe weitzman Personally, I like the 'Advanced' tab. There should be a permission which is universal across all modules which says 'access advanced configuration options'. If user has that permission, he can see these tabs. -moshe ------------------------------------------------------------------------ February 24, 2005 - 16:41 : javanaut On the topic of an "advanced settings" tab, I implemented this for a module I'm working on here: http://drupal.org/node/17781#comment-29737 It does simplify an otherwise very messy UI (ok, it's still messy :). Additionally, I like the idea of a global flag/permission that would hide the "advanced" tab. I would think that every setting under the advanced tab would have a sensible default that, in general, wouldn't need to be modified for default module behavior. Ber, would such a feature offset your hesitation to add new configuration options? -Mark ------------------------------------------------------------------------ February 28, 2005 - 13:07 : Bèr Kessels I would like to close this issue. IMO we should just get a mechanism for handling /any/ link from the _link hook, not a book specific solution. Anyone objects against closing this, in favour of a more general solution/feature? ------------------------------------------------------------------------ February 28, 2005 - 13:13 : Junyor +1 for a generic _link editor. ------------------------------------------------------------------------ February 28, 2005 - 18:24 : kbahey +10 for a generic link editor too. Why solve it in book module only, and then solve it bit by bit in every module and every link. That would solve another problem I faced with image.module where there is a need to turn off the links at the bottom (e.g. when using ecommerce module).

1 0