- Development - lists.drupal.org

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

Re: [development] Tell if current page is viewable by anonymous users
by Petr Vacha 19 Feb '08

19 Feb '08

You can use function menu_valid_path() > Hi, > > is there a way to determine (in a module) whether the current page can > be viewed by anonymous users? > > I've found user_access() and drupal_anonymous_user() - but this would > require a node. Do all "public" pages have a node? > > Kind regards, > > Salgar

3 4

Tell if current page is viewable by anonymous users
by Salgar 19 Feb '08

19 Feb '08

Hi, is there a way to determine (in a module) whether the current page can be viewed by anonymous users? I've found user_access() and drupal_anonymous_user() - but this would require a node. Do all "public" pages have a node? Kind regards, Salgar

1 0

view filter on 3 or 4 zip code digits
by Brett Evanson 19 Feb '08

19 Feb '08

I have a view that is pulling back a list of nodes. Right now, I can filter them based on a full 5 digit zip code. However, I don't have enough nodes right now to make that a good idea. There will be lots of zip codes that come back with empty results. My question is, can I make it only use the first 3 or 4 digits of the zip, and use a wild card for the 4th and/or 5th? Can I use a * in the search? Could I just swap out the last digit(s) of the user input with a *? -- Brett Evanson <mailto:brettev@gmail.com> brettev(a)gmail.com

1 0

Any solution for solving DB reserved word conflict?
by Edison Wong 19 Feb '08

19 Feb '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Folk, I would like to ask for some support and suggestion for a 6-year-old issue: DB reserved word conflict within Drupal core (http://drupal.org/node/371) Support multiple databases within core should be one of the possible solution for expand market sharing. BTW, the conflict with DB specific reserved words is an always pain for abstraction layer designer and developer, and so affect the daily work of contribute developers. Drupal has also faced this problem since June 30, 2002. As Drupal 7.x is now open for public development, this issues is activated once again. Based on research and compare with other OSS web application, there is some possible solutions: ~ 1. Avoid the use of ALL reserved words within core. This is our traditional approach since 2002; on the other hand, Moodle 1.7+ also apply this solution, which support totally 4 databases: MySQL, PostgreSQL, Oracle and MSSQL (http://docs.moodle.org/en/XMLDB_reserved_words) ~ 2. Escape ALL potential reserved words with escape characters. Gallery2 is using this solution, and is able to support totally 6 databases: MySQL, PostgreSQL, Oracle, DB2, MSSQL and SQLite (http://www.garfieldtech.com/blog/database-abstraction#comment-446) Some hybrid suggestions are also proposed, but most of them can't solve this problem perfectly. E.g. Handling the escape of reserved word within each database drivers implementation (slow, complicated, and always miss), only handle the conflict of table name (can't solve the problem), using non-pair-up token as escape character (potentially buggy and not the optimal solution), etc. Both Moodle and Gallery2 are using ADOdb for DB abstraction, but finally solve the reserved word conflict problem in totally different direction. We can find that what DB abstraction can do for this issues is very limited, and usually require for the help from standardizing core query syntax, and be careful in our daily development. This issue can't be solved by normal simple patch, and usually need the help from most core developers. We may need to find out the best solution which we are all agreed to follow it. If you are interested in solving this 6-year-old issue, please refer to http://drupal.org/node/371 for more technical detail. Thanks a lot. Regard - -- Edison Wong hswong3i(a)gmail.com http://edin.no-ip.com/html/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHt+zABPIQaq+ZRd8RAtQQAJ9/cT7ewpFdWwG4ckStooiz/MlcBwCfS/rW 5g8txeXaitkSqkSN62wTpjg= =vZiU -----END PGP SIGNATURE-----

7 18

rich text editor
by Chris Johnson 19 Feb '08

19 Feb '08

I thought I'd convey the remarks about Rich Text Editors (RTE) one implementor of Drupal sites posted to our internal development team's collaboration space. We use TinyMCE for our 90+ sites currently. But TinyMCE has a lot of drawbacks -- including that its code base is bigger than all of core Drupal. We are planning our migration to Drupal 6. We will re-evaluate which RTE to use as we do that. Here are the remarks: "a google of "jquery rte" yields this: http://batiste.dosimple.ch/blog/posts/2007-09-11-1/rich-text-editor-jquery.… would seem to make sense to start with something like this as a base and add only what is needed, rather than strip out stuff from tinyMCE of FCK. sorry, this is one of my peeves. if drupal is using jquery as js library then it needs to be leveraged. austere or not, every bit counts in the field." To restate: If Drupal is using jQuery, then we ought to have a few RTEs to choose from based upon jQuery. That sounds like a golden opportunity to me.

25 37

Module developers, please do *proper* releases !
by Caleb Gilbert 18 Feb '08

18 Feb '08

That seems like a great idea, especially if the default is set to not show the unofficial versions. This would be a gain for users of Drupal.org (more reliable downloads) and it would likely encourage better practices among developers without forcing anyone. Devs can opt-in or not, but I'm guessing that most developers would indeed like to have their modules listed by default. I'll put my effort where my mouth is and help get this done, if anyone is willing to take me up on it. :-) - Caleb - But then, these modules should be filtered out of the modules list on - drupal.org, unless one ticks an "include unreleased modules" checkbox. - That would help greatly in building a module set. - Xav

1 0