- Development - lists.drupal.org

[drupal-devel] Using Drupal as an applications framework?
by Chris Johnson 28 Feb '05

28 Feb '05

1. Executive Summary I propose to replace my employer's extranet website, which currently uses all custom-coding to generate dynamic web pages from database queries and trading partner electronic transactions, with one newly built upon Drupal. Is this a good idea? 2. Why Drupal developer might care to help me answer this question If I undertake to convert our current web applications to Drupal, I believe there are some benefits to the Drupal community which may accrue. They fall primarily in three categories: a) My employer will pay for me to spend a significant amount of my time working directly on Drupal or Drupal-related code. I expect this may be a thousand hours over the next year minimum. This means I will be paid to work on Drupal issues which affect my company, which would include bugs or limitations in core or module code. Fixing bugs is good for the Drupal community. b) My employer will need to develop a large amount of custom code to run its applications. Some of that will be very generic code which will be donated back to the Drupal community if they so desire it. For example, almost all of our applications involve date input for elements. I will spend the time necessary to perfecting a variety of form elements such as date which others in Drupal may wish to use. (It is also true that much of the code I develop with be of no interest or use to anyone else, and/or proprietary.) c) My employer currently employees several contract developers full time. I see a big opportunity to hire Drupal developers on contract to help us out with this conversion project, and with developing new applications in the future (we are constantly developing new software to meet our changing and growing business opportunities). The rest of this message is posted here: http://drupal.org/node/18124 If you are willing to help me answer the question of whether I should go ahead with this project, please respond there. Thanks, -- Chris Johnson

1 0

[drupal-devel] [bug] The DrupalCon bug -- node administrator privileges kills DISTINCT
by chx 28 Feb '05

28 Feb '05

Issue status update for http://drupal.org/node/18123 Project: Drupal Version: cvs Component: node system Category: bug reports Priority: normal Assigned to: chx Reported by: chx Updated by: chx Status: patch Attachment: http://drupal.org/files/issues/drupalcon.patch (1.07 KB) At the conf, moshe pointed out a bug, and JonBob and I fixed it on site. The $return['distinct'] in the past should have been module_implements('node_grants') but after JonBob's node_access_view_all_nodes, that part happens only if node_grants is in effect, so it is simplified to 1. This orphans module_implements, but my module.inc patch uses it, so it won't be an orphan after all. chx

1 0

Re: [drupal-devel] New taxonomy_xml.module
by Boris Mann 28 Feb '05

28 Feb '05

On Thu, 24 Feb 2005 22:59:38 -0600, Sheldon Rampton <sheldon(a)prwatch.org> wrote: > I *have* participated previously in contributing revisions to > wmfilter.module, which was written originally by Aldon Hynes and > subsequently reworked by both Aldon and myself. After some discussions, > we've decided that it ought to be renamed to "interwiki.module." What's > the procedure we should follow to deprecate "wmfilter" and replace it > with "interwiki"? Dries or Steven can move/rename the directory in CVS, so that history is preserved. -- Boris Mann http://www.bryght.com

2 1

[drupal-devel] adsense from google for drupal
by Boerland Bert 28 Feb '05

28 Feb '05

Hi Due to the flue, I wont be able to make it top Belgium :-( Have a good one and I hope to see some results on drupal.org. In the mean time I propossed a way of contributing money to drupal at [1]. I "make" -running gooooooogle ads on my site- about 100 USD per 2 month and am willing to donate this to drupal. If others are willing to contribute money as well, it might be worth to combine forces. Once again, I wish you all a cool conference! Wish I was there. [1] http://drupal.org/node/17905 -- Bert Boerland

3 2

Re: [drupal-devel] New module nameing.
by Boris Mann 28 Feb '05

28 Feb '05

On Fri, 25 Feb 2005 17:21:36 -0800 (PST), Aran Clary Deltac <aran(a)arandeltac.com> wrote: > I've written a new module and would like other module devels to give me > their opinion. > > This module allows editing of the help messages for any page on a drupal > site from within the administration pages. Nice! Interested in trying it out to see how it works. I think "helpeditor.module" would be a good name. -- Boris Mann http://www.bryght.com

6 9

[drupal-devel] [feature] Option to disable printer friendly version for book module
by kbahey 28 Feb '05

28 Feb '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: kbahey Status: patch +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). kbahey Previous comments: ------------------------------------------------------------------------ November 20, 2004 - 01: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 - 12:01 : kbahey Setting status to patch, so that it is discussed on the mailing list. ------------------------------------------------------------------------ November 25, 2004 - 18: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 25, 2004 - 19: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 - 16: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 - 09: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 - 10: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 - 15: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 - 15: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 17, 2005 - 21: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 - 00: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 - 06: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 - 06:29 : Bèr Kessels ^-- That was me. logged out for some reason ------------------------------------------------------------------------ February 18, 2005 - 10: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 - 11: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 - 10: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 - 07: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 - 07:13 : Junyor +1 for a generic _link editor.

1 0

[drupal-devel] New image.module
by James Walker 28 Feb '05

28 Feb '05

Hey all, As promised, I've just committed brand new versions of "my" image.module to my sandbox. A working version for CVS HEAD is at : contributions/sandbox/walkah/image (compatible with the new "image api"). There is also a 4.5 version available in the "45" subdirectory. As I've mentioned in #drupal and briefly on this list, this version comes with a slightly new approach. You may notice that the image.*sql files have been removed. This is because image.module no longer requires it's own tables. Instead, it uses the files table (previously only used by upload.module) to store information about all files (various resolutions) in this table. This has several benefits: First, it greatly simplifies the installation of image.module, but more importantly it keeps better track of each image associated with the node. Where previous image.modules (mine included) relied on naming conventions to keep track of various sizes & resolutions, this image module actually has a record for each size - including it's filesize (making it easy to write a quota.module - for instance). The other major addition (which was previously left out intentionally) is the re-introduction of basic image gallery functionality. This is minimalistic intentionally - and not meant to stifle or otherwise conflict with other initiatives (such as moshe's album.module). A couple things to note: the maintenance of gallery albums is done at ?q=admin/image and should be familiar in style for those of you who have tried HEAD's latest forum.module. Also, the layout no longer uses tables - as I'm sure some of you will enjoy. However, I don't fancy myself much of a designer, so suggestions / recommendations on "default" look and feel are of course very welcome. For those of you that don't like the approach at all - theme('image_album', $albums, $images) :) Now, due to the change in DB storage approach - I have included an 'update-images.php' ... which needs to be run from the root of your drupal installation. I have done testing on this - however, I'm not gonna claim complete perfection here. I'd love to have folks with image.module installations test this out - PLEASE backup your image files and tables first !!!! Moving forward - I'd really like to get this into modules/image as soon as possible so that we (as a community) can use project.module for bug & feature tracking (rather than random emails / IRC chats / etc). Ideally, I'd like this to happen by the time contrib is branched for DRUPAL-4-6 so for 4.6 there will be no confusion of which image.module to use, etc. As there is a 4.5 version as well, I'm willing to move that into the DRUPAL-4-5 branch, but I'd like to get some consensus on that - as I worry it might 'cause more confusion than is really necessary. Again, this is not intended as a final version - lots of people are using image in a lot of interesting ways, I'd be happy to try and accommodate all features, either through "API"-style functions & features or as base functionality in the module - but would like to get some feedback from the community at large as to what people would like to see. Cheers, -- James Walker :: http://www.walkah.net/

8 16

[drupal-devel] [feature] Small fix for conf.php.
by Dries 28 Feb '05

28 Feb '05

Issue status update for http://drupal.org/node/11645 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Chris Johnson Reported by: Uwe Hermann Updated by: Dries Status: patch Err, your patch looks inconsistent: it only uses underscore on some strings. I'll fix it up and commit it to HEAD. Dries Previous comments: ------------------------------------------------------------------------ October 16, 2004 - 15:11 : Uwe Hermann As seen here [1] it's not so obvious what to fill into the $dburl line in include/conf.php. My suggestion to clarify this a bit: Replace # $db_url = "mysql://user:password@hostname/database"; with # $db_url = "mysql://dbuser:dbpassword@dbhostname/database"; This should make it a little clearer that the database user, password and host is meant. The same should be done with the PostgreSQL line... [1] http://drupal.org/node/11325#comment-17968 ------------------------------------------------------------------------ February 24, 2005 - 17:31 : Chris Johnson Attachment: http://drupal.org/files/issues/conf.php.patch (579 bytes) Here's a simple patch against 4.5.2. ------------------------------------------------------------------------ February 24, 2005 - 17:35 : Chris Johnson Attachment: http://drupal.org/files/issues/settings.php.patch (551 bytes) And here is the equivalent patch for HEAD, against settings.php. ------------------------------------------------------------------------ February 24, 2005 - 19:27 : tangent Makes sense to me. +1 ------------------------------------------------------------------------ February 28, 2005 - 14:42 : Bèr Kessels Attachment: http://drupal.org/files/issues/db_hostname.patch (550 bytes) +1 from me. This very small change makes it very clear that we do not want the hostname of the server, but of the database. One small question: in drupal we use underscores to mark words everywhere (functions, variables, modules, themes etc.) so can you use db_hostname? Attached patch does that.

1 0

[drupal-devel] postgres update problem (database/updates.inc)
by Ross Kendall 28 Feb '05

28 Feb '05

Was just using today's drupal-cvs.tar.gz and found this problem running update.php: Parse error: parse error, unexpected '[' in /drupal/database/updates.inc on line 2294 The offending line looks like this ( part of update_125() ): $ret[] = update_sql[] = ("CREATE FUNCTION "if"( ... maybe it should look like this?: $ret[] = update_sql ("CREATE FUNCTION if( ... Actually, the whole line doesn't make much sense to me, and looks broken. Since it is postgres specific (and I use mysql), I made the above change and it worked for me, but really someone with postgres running needs to look at this. Cheers, Ross.

1 0

[drupal-devel] [feature] Options: RSS max items + pubDate from modification/creation date
by elonen 28 Feb '05

28 Feb '05

Issue status update for http://drupal.org/node/18068 Project: Drupal Version: 4.5.0 Component: node.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: elonen Updated by: elonen Status: patch Attachment: http://drupal.org/files/issues/rss-date-and-len.diff (3.25 KB) Using modification date in pubDate is suboptimal if you just want to promote new content, not updates. Also, 15 is too small maximum for RSS item count in some cases. This patch against 4.5. adds an option for changing these defaults. (It would be even better if the admin/users could create custom feeds but that'd be a much bigger change.) elonen

5 6