February 2008 - Development - lists.drupal.org

Making blocks from some setting in Drupal 7?
by Gábor Hojtsy 25 Feb '08

25 Feb '08

Hey, On the quest to better format support in Drupal 7, I made a spreadsheet of how certain texts are filtered in Drupal as of now: http://groups.drupal.org/node/9072 The table shows some interesting bits, like the user signature format changing based on the actual format used for a comment, which is quite interesting; or some node details filter_xss()-ed in action implementations, when they would probably better filtered with their format. (Let's follow up about these on the node.) Anyway, one itch which shows up here is to add support for site settings like "footer message", "mission", etc. These are without format support now, so even if the whole of your site uses wiki formatting, you cannot use that here. Or if you have an input policy, it is not enforced here. There are basically two ways to solve this: - add format support for site variables (that would be a format column in the db, which is only used for some settings) - move these settings to an area which supports formats already (nodes, blocks come to mind) After thinking about this more and more, I came to the realization that making these blocks would be fun. The affected settings are: - site mission - site footer - user registration help - contact page help Some reasons for why this could be cool to be blocks: - provide these with format support instantly - give examples on things put in the footer region, content top region, etc - give examples on blocks limited to pages (mission to front page, helps limited to pages they provide help for) - get rid of special "theme feature" settings for displaying the mission, as it is a normal block (btw I'd get rid of the "search feature" provided by themes and let them use/theme the search block instead - those reading the Drupal 5 Themes book probably realized how awfully confusing are the various search input options) There is still one core setting left which cannot be made a block, the site offline message. And there are certainly other contrib use cases, where making blocks is not a good idea, so moving the above stuff to blocks would not solve the generic problem. The reason I am bringing it up regardless is that it would (IMHO) provide some more consistency and better features for these settings. What do you think? Ps. As far as easy theming of these go when moved to blocks, there is a DROP task to replace numeric block deltas with named deltas: http://drupal.org/node/216072 Which would result in block-system-mission.tpl.php and the like :) Gabor

15 22

Fwd: [General inquiry (other)] The next generation drupal UI configuration?
by Konstantin Käfer 25 Feb '08

25 Feb '08

Hi, I was asked to share this link on the development mailing list. Maybe there is someone willing to convert it to a contrib module. It looks interesting. Carli claims that it's still a prototype, though. Konstantin > From: "Carli Beeli" <cbeeli(a)gmail.com> > Date: 24. Februar 2008 23:22:27 MEZ > To: kkaefer(a)gmail.com > Subject: The next generation drupal UI configuration? > > Hi Drupal Team! > > I've graduated from University and did a graduation project that > "might" > interest you. > Since I have little time to develop it further, I thought someone else > might find it useful. > There's a video of the project on: www.freesite.ch/gravity > Please watch it. => Could the next Drupal UI configuration be similar? > > If you're interested I'd happily give you further information on it > and > even send you the complete source code. The JavaScript functionality > is > done with jQuery. > > Thanks for letting me know how you find it and if it's of any use for > you! > > Best wishes > > Xapadoo > Carli Beeli

3 2

Time to take away RTBC from every Joe
by Karoly Negyesi 25 Feb '08

25 Feb '08

First of all, yes, I broke sometimes core by jumping the gun on RTBC. But, I am aware of it. Now, let's see some other developer, quoted from IRC after asking why RTBC'd a patch without any testing or reviewing whatsoever (patch, of course, was absolutely broken and took me hours to hunt down afterwards why stuff was broken and how it's related to this one): --- It means the idea of this patch is acceptable. I guess Dries understands the risk before he commits this patch, and I am not the only one to agree about its commit. so why just give me this credit because I am the one who take RTBC action? --- Onwards, I would like to see a small handful people (me not necessarily included!) to be able to RTBC core patches. As we go on, more and more people will misunderstand what this means. A nice pyramid, a few people on top deciding the patches, a few more culling the flood of patches for them. As there is already a permission for this, a little hacking (which I am willing to do) surely would make it possible to have it just for project 3060. Kind regards, Karoly Negyesi

13 15

jpegs not resolving after Drupal initialization
by Tomas J. Fulopp - Vacilando.org 24 Feb '08

24 Feb '08

Hi friends, I have been battling with a bad problem of non-resolving jpeg images in PHP in my module Brilliant Gallery. It only happens in some systems. I then found this problem is independent of Brilliant Gallery -- it happens even if you open a static jpeg and then output it to browser. After many evenings of investigating this I have found that it happens after running Drupal's initialization: |drupalize(); function drupalize() { while (!@stat('./includes/bootstrap.inc')) { chdir ('..'); } require_once './includes/bootstrap.inc'; drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL); }| I have noticed - though I am not sure it is related, that after said initialization the 'Expires' header is set to 1978 - is that normal? Could you please have a quick look at http://drupal.org/node/186863#comment-742674 ... I have described my test precisely, with header dumps before said initialization and after it, so you will see all the differences. Hope some of you have some experience with this or related problem and will be able to help me -- and many other users. (I'd be so happy to get this working before travelling to Drupalcon!) Thanks!! Tomáš (vacilando) http://www.vacilando.eu

2 1

A Git mirror for Drupal CVS
by Caleb Gilbert 23 Feb '08

23 Feb '08

I agree with Karoly's opinion on this one, at least where hastiness is concerned: A) 'The devil you know, vs. the devil you don't know'...meaning, why bother re-training everyone for anything less than something *truly* easy/fantastic. Love it or hate it, most of the highest contributing people within the Drupal community can get things done with cvs at the moment. It's cvs can be an obstacle, but it's not insurmountable. B) Implementing :something truly easy/fantastic" in place is likely going to be at least an 18 month process. C) Anything less than a browser based gui, why bother...does the community really want to get in the business of maintaining OS-specific clients? </me sticks two cents back in pocket>

1 0

This version is incompatible with the 6.0 version of Drupal core.
by Feijó 21 Feb '08

21 Feb '08

I have D6 final version If my module has a depedency not enabled, that error (in subject) apear. But it shouldnt show as D5 does: depends on: MyModule (disabled) ? regards Feijó

3 2

implementing #format
by Gábor Hojtsy 21 Feb '08

21 Feb '08

Hey, In light of http://hojtsy.hu/blog/2008-feb-04/supporting-wysiwyg-editing-better-drupal-… I'd like to implement direct input format support for Form API constructs. I have been thinking and researching on the following lately: 1. What form API element to support? - Drupal core only uses input formats with textareas - CCK also supports input formats with textfields Any other field one would need to support? Do we need to support textfields really? 2. How to add to the form structure? - Core does wrap the field in a wrapper FAPI element and then add the textarea and the 'format' fieldset / radio group to that wrapper. - CCK adds the field and adds the format fieldset / radio group with name: $field_name .'_format' (no specific wrapper). Core things like teasers and the splitter require that wrapper so that related fields are together. We should either enforce the wrapper (which could complicate life for #tree forms), or do not care about a wrapper existing or not, leave that off to the implementor. 3. How to make adding format selectors and acting on them easy? - The different (free to modify) methods of adding input format support on fields makes it hard to act on it from form altering, etc. - Devise a unified approach to add format (selection) support => add a #format (#input_format, something else?) key to FAPI - Expand textareas with #format to a textarea and a format selector (or just help if there is only one format) with the help of #process This should provide a one and only standard way to tie formats to textareas, and form altering would have the important metadata available at a predictable place. (I'd also like to add more metadata about what type of field is actually presented for format selection, so we would be able to limit input formats available for blocks, nodes, comments, etc). Anything obvious I am missing or total misdirection I am taking? Better ideas or tips to get this done easier? Does someone see where I'll stop and freeze without a way forward (because certain APIs will not allow me to proceed without major refactoring)? :) If #format a good idea for input format specification on forms, or should I use a better name? (I would not like to get in conflict with #formatter and friends). Gabor

8 9

Re: [development] abandoned module needs a good home
by Karen Stevenson 20 Feb '08

20 Feb '08

We hope to get field permissions into CCK core in D6, although it isn't done yet and won't be until we get an initial release out the door. I don't know yet what field permissions will look like when we do this, it's unlikely they will work the exactly the same. How to create a simple UI is the biggest issue. Anyone who is interested in this subject is welcome to take a look at a g.d.o page I just started for that purpose (http://groups.drupal.org/node/9045) and chime in. Karen ----- Original Message ---- From: arthur <arthur(a)civicactions.com> To: development(a)drupal.org Sent: Wednesday, February 20, 2008 6:54:07 AM Subject: [development] abandoned module needs a good home Hi- The CCK Field Perms module (http://drupal.org/project/cck_field_perms) module needs a good home. I created it to fill an need, and though many other people seem to have the same need, I don't have time to support it. Can anybody take this one on? Lots of people seem to want it. thanks! arthur ----------------------------------- arthur(a)civicactions.com

1 0

abandoned module needs a good home
by arthur 20 Feb '08

20 Feb '08

Hi- The CCK Field Perms module (http://drupal.org/project/cck_field_perms) module needs a good home. I created it to fill an need, and though many other people seem to have the same need, I don't have time to support it. Can anybody take this one on? Lots of people seem to want it. thanks! arthur ----------------------------------- arthur(a)civicactions.com

1 0

CSV export image path
by Marolijo - Pol maresma 20 Feb '08

20 Feb '08

Hello, I'm tryin' to change how the views csv exports cck image. It puts entire <img src="...> tag but I need only the URL of the file. I think I need to use something like this if (fieldtype = image){ $value = $field['id']['filepath']; } into this part of the module, but I don't know how... I tried also the img parameter on preg_replace() but it strips all the fiel foreach ($view->field as $field) { if ($fields[$field['id']]['visible'] !== false) { $value = views_theme_field('views_handle_field', $field['queryname'], $fields, $field, $node, $view); $value = preg_replace('/<\/?(a|span|li|ul|div) ?.*?>/', '', $value); // strip 'a' and 'span' tags $value = str_replace(array("\r", "\n", ','), ' ', $value); // strip line breaks and commas $value = str_replace('"', '""', $value); // escape " characters $value = decode_entities($value); $values[] = '"' . $value . '"'; } } Thank's for all! Pol Maresma / PolNetwork.com / Serveis d'Internet msn: marolijo

1 0