- Development - lists.drupal.org

Re: [development] including an image in the module directory
by nitin gupta 17 Sep '09

17 Sep '09

Hi, Sure, I would prefer the #description as well. Please have a look here http://publicmind.in/test/feedapi-imagegrabber-new-interface Do you think that this description is sufficient? If No, Please suggest what changes can I do to make it more clear to the end-user. Regards, Nitin Kumar Gupta http://publicmind.in/blog > > > Message: 8 > Date: Thu, 17 Sep 2009 15:45:32 +0530 > From: nitin gupta <nitingupta.iitg(a)gmail.com> > Subject: [development] including an image in the module directory. > To: development(a)drupal.org > Message-ID: > <4f59ac610909170315x5b32a97fib0715e216ed9312(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hi, > I want to include a small image in my module to provide a small tutorial > for > the module's input field. Is anyone aware if we are allowed to commit an > image into the module repository or not? > > Regards, > Nitin Kumar Gupta > http://publicmind.in/blog/ >

1 0

including an image in the module directory.
by nitin gupta 17 Sep '09

17 Sep '09

Hi, I want to include a small image in my module to provide a small tutorial for the module's input field. Is anyone aware if we are allowed to commit an image into the module repository or not? Regards, Nitin Kumar Gupta http://publicmind.in/blog/

2 1

Making your data act like a field
by Nancy Wichmann 16 Sep '09

16 Sep '09

After reading Eaton's well-written article http://www.lullabot.com/articles/great-pretender-making-your-data-act-field, I tried this in a module I work on. The fields are definitely showing on "Manage fields" in CCK. However, those added fields do not seem to be available to Views. One of the reasons why I am really interested in making this change is so that something like Node Export can see these fields automatically. What more needs to be done to the suggested code to have CCK reflect these fields to other modules? Nancy E. Wichmann, PMP Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.

5 5

form_markup
by Jeff Greenberg 16 Sep '09

16 Sep '09

I've opened an issue, but meanwhile, has anyone used form_markup - d6? I enabled it, the prefix/suffix fields appear when I edit a cck field. I put markup in. Save. Clear cache (just in case). And the node/add and edit forms don't change at all. I need to plant a line of textual instruction prior to the start of a series of groups on the form, and was hoping not to have to theme just to do that. Unfortunately, there's no cck markup type field.

3 3

Re: [development] Shortening file names downloaded from webpage
by nitin gupta 16 Sep '09

16 Sep '09

Hello, Thanks a lot to all, for such great suggestions. I hope this will solve my problem. Regards, Nitin Kumar Gupta http://publicmind.in

1 0

Get all node fields?
by Chris Johnson 15 Sep '09

15 Sep '09

Can someone suggest a way to get get a list of user-editable* fields in a node of a given content type? I'm trying to write a module which will set field defaults in nodes being created by Feed API -- including fields which do not exist in the feed, hence I need to know what's in the node, not what's in the feed. It also has to be different _per feed_, hence I can't just go by content type -- not that that is any easier. *By user-editable, I mean the actual data fields, not the meta-data fields. I don't want to mess with things like nid, vid, type, uid, status, etc. Rather, just any field which any module (e.g. CCK) might have added to a basic node to create a new content type. Obviously, I can look at the node object, but it's very flat; there's no way to tell user data from meta-data attributes. Calling content_fields() will get me the CCK-added fields, I think (I worry about the date module...). And I can hard-code the basic core node fields, if I have to. But I'd prefer a general solution. Advice? Ideas? Thanks, ..chris

4 4

Shortening file names downloaded from webpage
by nitin gupta 15 Sep '09

15 Sep '09

Hello, I am maintaining a module FeedAPI ImageGrabber. It downloads a relevant image from a webpage of the feed-item and stores it along with the node. I found that the module sometimes gave the 'filename too long error' ( http://drupal.org/node/505964) It happens because I was saving the image file with the name as basename($image_url). But to solve the issue, I am now trying this code to shorten the filename. $arr = parse_url($image_url); $filename = basename($arr['path']); This code solves the problem by removing the query and fragments of the url. Does anyone know of any better way to handle this? Can anyone point out any issues with this code? Regards, Nitin Kumar Gupta http://publicmind.in/blog

4 4

Re: [development] Shortening file names downloaded from webpage
by nitin gupta 15 Sep '09

15 Sep '09

Hi, Any webpage contains a lot of images, I am not aware of the time complexity of the function implementation, but won't it will be an overkill to generate so many md5 hashes? Looking forward. Message: 1 Date: Mon, 14 Sep 2009 21:16:12 +0530 From: nitin gupta <nitingupta.iitg(a)gmail.com> Subject: [development] Shortening file names downloaded from webpage To: development(a)drupal.org Message-ID: <4f59ac610909140846x5efff3bai3bc4a5deb5054b37(a)mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Hello, I am maintaining a module FeedAPI ImageGrabber. It downloads a relevant image from a webpage of the feed-item and stores it along with the node. I found that the module sometimes gave the 'filename too long error' ( http://drupal.org/node/505964) It happens because I was saving the image file with the name as basename($image_url). But to solve the issue, I am now trying this code to shorten the filename. $arr = parse_url($image_url); $filename = basename($arr['path']); This code solves the problem by removing the query and fragments of the url. Does anyone know of any better way to handle this? Can anyone point out any issues with this code? Regards, Nitin Kumar Gupta http://publicmind.in/blog

2 1

Announcing DRUPAL-7-0-UNSTABLE-9
by Angela Byron 15 Sep '09

15 Sep '09

Tonight seemed like as good a night as any to roll another interim unstable release for Drupal 7, so say hello to DRUPAL-7-0-UNSTABLE-9. I'll detail the exciting changes in a bit here, but first a few procedural things. For those who missed Dries's keynote at Drupalcon Paris (http://www.archive.org/details/TheStateofDrupal ), I'll give a recap of the parts that pertain to Drupal 7's development/release cycle: * Code freeze was extended an extra week until 9/8 to allow people in Paris (as well as abroad) to collaborate on last-minute frenzied features. Dries and I are working through last week's RTBC queue now that we're both home for a couple of days. ;) * We're now in a "code slush" phase, which means that Drupal 7 is feature frozen, apart from a few hand-selected exceptions, as well as API and markup clean-ups for existing features. Additionally, we allow improvements to Drupal's usability (minor changes), accessibility, performance, testing framework, documentation, and user interface text during this phase. Code slush is time-boxed until Oct. 15, at which point we'll enter a "hard" freeze. Then, no more XHTML markup changes, no more function signature changes, and no more database changes. * That means it'd be a /really/ good idea to begin poking at your Drupal 7 module/theme porting, oh... now-ish... so that if we missed something blatantly obvious during development of D7, we can fix it while the code is still somewhat malleable. Coder has a 7.x version to help with this: http://drupal.org/project/coder, and also consider taking the #D7CX pledge for your project: http://drupal.org/project/modules?solrsort=sort_title%20asc&text=d7cx&displ… * From Oct. 15 to Nov. 15 will be the "strictly polish" phase, where we can continue to do things such as minor accessibility and usability improvements, performance improvements, and documentation and string improvements. November 15 will then mark both a string *and* UI freeze, so that the documentation and translation teams can get busy preparing for the Drupal 7 release. * Patches that expand Drupal's automated test coverage, as well as bug fixes, can be accepted at any time up through release. * Drupal 7 will be released "when it's ready", which is when all critical issues are resolved. Keep your eyes on http://drupal.org/project/issues/search/drupal?status []= Open&priorities[]=1&categories[]=bug&categories[]=task&version[]=7.x, or enable the "Contributor block" in your drupal.org user profile to get a handy count (currently at 400). Here are some "hit lists" along with helpful deadlines for you all: * Feature freeze exceptions (Oct. 15): http://drupal.org/project/issues/search/drupal?issue_tags=Exception+code+fr… * API clean-ups for existing features (Oct. 15): http://drupal.org/project/issues/search/drupal?&issue_tags=API%20clean-up * XHTML markup (Oct. 15): http://drupal.org/project/issues/search/drupal?issue_tags=tpl-refresh * Testing framework (Oct. 15): http://drupal.org/project/issues/search/drupal? component[]=simpletest.module * Minor usability improvements (Nov. 15): [some of] http://drupal.org/project/issues/search/drupal?issue_tags=Usability * Accessibility (Nov. 15): http://drupal.org/project/issues/search/drupal?issue_tags=accessibility * Performance patches (Nov. 15): http://drupal.org/project/issues/search/drupal?issue_tags=Performance * Documentation improvements (Nov. 15): http://drupal.org/project/issues/search/drupal? component[]=documentation * String fixes (Nov. 15): http://drupal.org/project/issues/search/drupal?component[]=user +interface+text * Test coverage (Any time): http://drupal.org/project/issues/search/drupal?issue_tags=Needs+tests Ok, now that the whip-cracking is out of the way, here are the changes in this snapshot! :D As always, the full change log is attached below. Changes for developers: ======================= * Database-wise, core is now fully DBTNG-compliant! YAY! We also added basic support for 'date' and 'time' types to Schema API, update_sql() is dead, dead, dead, AND now hook_uninstall() and hook_install() will automatically handle your schema definitions. Ahhh. * The File API now uses stream wrappers for accessing files, which basically means that all functions that used to take a file path now take a URI like public://old_photos/banana.jpg. Core ships with three default stream wrappers: temp://, public://, and private:// (which means that public and private files FINALLY co-exist!) with support for contrib to offer wrappers such as s3:// for Amazon S3, flickr:// for getting data into/out of Flickr, and so on. We also added a hook_file_url_alter() for content delivery network (CDN) support. w00t! * Remember that awesome code registry I talked about back in UNSTABLE-1 or so that was going to solve all of our performance woes? Yeeeah... Turns out, it caused severe developer experience issues, in addition to not offering performance improvements on par with more well-supported systems such as APC, so this got partially rolled back. The registry no longer caches functions, though we do still offer a class registry, which means that $foo = new Foo; will work from anywhere. * Field API improvements: Taxonomy terms are now fields, comments and taxonomy terms are fieldable, and fields are also now translatable. * In terms of clean-ups, we now have the R part of a real CRUD API in core with standardized, swappable entity loaders. We also have a *real* user and permissions API, as well as a filter API. We also renamed 'box' to 'custom_block' in the name of sanity. * Performance-wise, we now ship with "smushed" images that are lighter on bandwidth, and we've now added a caching system to the render API which is currently implemented by blocks, and because it happens early in the page render cycle, it works for both authenticated users and with node access modules. Yum. * Install profile improvements! Shock! Install profiles are now basically modules with .install files, .info files to declare dependencies, etc. If you can write a module, you can write an install profile, and you can also do everything from install profiles you can do with modules including use the full Drupal API and write update functions to move from one version to another. Speaking of versions, you can now specify version-level dependencies in your .info files, so you can say your module depends on at least Views 2.0-rc1 but less than Views 3.0. And finally, you can run update.php and install.php from the command line without Drush having to do unholy things. Yay! * In terms of our testing framework, there's now a debug() function which can be used as a 'lite' version of dsm(), and also prints debugging data as SimpleTest assertions. There's also a new "verbose" mode which logs screen captures of the pages SimpleTest hit on its way through, along with the assertion messages. This should make figuring out why tests are failing MUCH easier! Thanks to the testing sprint in LA back in mid-August, we also greatly grew our test coverage and cleaned up a lot of lingering test patches from back in Szeged. Changes for themers: ==================== * Regions $sidebar_left and $sidebar_right are now called $sidebar_first and $sidebar_second, for better semantics and to make them more RTL-friendly. * The AJAX framework from CTools is now in core, and core now supports a new .once() method for ensuring that a behaviour applies only a single time. I don't really know what any of this means, but the JS folks are really excited about it. ;) * You can now use a "wildcard" operator in tpl.php files, for example page-user-%.tpl.php to affect any user/xxx while letting page- user.tpl.php affect only the actual page /user. * In accessibility news, there are now system-wide classes for marking elements as either completely hidden (.element-hidden: equivalent to jQuery's hide() function) or invisible (.element-invisible: visible only to screen readers). We're now working to apply those classes to various points in core, as well as other important accessibility improvements. Changes for end-users: ===================== * CC-FREAKING-K IN CORE! OH YEAH! :D Not to mention Token, FileField, and Poormanscron! * As a trade-off, lots of extraneous features were removed from core in favour of either contributed modules or field API alternatives: minimum number of words on the body field, related terms for taxonomy terms, per-user theme selection, Blog API module. * The D7UX IA is fully in place; no more confusing "half the items are in 'Site configuration' and half under 'Configuration & Modules'" stuff. Thanks for bearing with us while we went through that transition! * Some nice security improvements. Users are now prompted at install time to get notified via e-mail about security updates for their sites. This is great because I'm pretty sure almost no one realizes this is a setting in Drupal 5 and 6. :P We also now limit the number of login attempts to help prevent brute force attacks. And running update.php is now tied to a permission rather than having to open it up to the entire universe if you don't like sharing your user 1 password. Oh, and last but not least, SSL support in core! :D

3 2

Re: [development] How to reuse uploaded files
by Peter Droogmans 14 Sep '09

14 Sep '09

You can also have a look at the webfm project. Met vriendelijke groeten, Peter Droogmans Attiks Ketsstraat 94 2140 Borgerhout peter(a)attiks.com 03-288 61 17 0497-44 44 77 ________________________________ From: Ken Winters <kwinters(a)coalmarch.com> Sent: zondag 13 september 2009 18:37 To: development(a)drupal.org <development(a)drupal.org> Subject: Re: [development] How to reuse uploaded files Unfortunately file management is one of the big weaknesses in Drupal 6, and I've never found a solution that I really liked. There are a lot of efforts toward improving that in D7 (the Media project, and assorted core file handling improvements) but for now there are only half-measures. John's suggestion is one of the reasonable methods, and IMCE plus TinyMCE is the common way to manage embedded images. - Ken Winters John Fiala wrote: Hey there, Gaston. (I aplogize for not spelling your name quite right, but I'm not sure how to produce that o with my keyboard.) Basically, once a file is uploaded, it exists in the files directory - so if you know the name, you can fairly easily use it (as in an image tag) anywhere you like. As for associating that file with another node, that I'm not as familiar with off of the top of my head. (Indeed, for re-using image files, I've tended to use an image node, which consists of a simple node with an imagefield, and then using nodereference to associate it with various nodes.) 2009/9/12 Gastón Pablo Pérez <gpperez(a)gmail.com><mailto:gpperez@gmail.com>: Hi everybody! I'm using the upload module to upload files into the Drupal nodes. The question is, how can I reuse the files uploaded in a particular node in other nodes? Exists a module to do this? thanks Gastón Pablo Perez Email:gpperez@gmail.com<mailto:Email:gpperez@gmail.com>

1 0