- Development - lists.drupal.org

Re: [development] Getting both better internal and external APIs intoDrupal 7
by Earnie Boyd 02 Jan '08

02 Jan '08

Quoting Michelle Cox <mcox(a)charter.net>: > > On 12/31/2007 7:50:22 PM, Khalid Baheyeldin (kb(a)2bits.com) wrote: >> I tried my best to have install profiles named something else (packages, >> distros), but the counter >> argument is that it was too late to do it. >> >> This will cause a lot of confusion in the future, unless we give profile. >> module the bullet of mercy in D6 and replace it with bio (or friends) for >> example. > > It will still be confusing. I think anyone who's familiar with social > networking sites will tend to associate "profile" with people, even > though it does have other meanings. > A profile is nothing more than meta data for a something or a someone. A package install profile is correct. A user profile is correct. A clarifier should be used in both cases to make the meaning understood. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/

4 7

#ahah documentation - Re: groking ajax callbacks
by Peter Wolanin 02 Jan '08

02 Jan '08

Anyone with CVS access can commit changes to the developer docs, and looks like bdragon stepped up to the plate already. -Peter > ---------- Forwarded message ---------- > From: "Augustin (Beginner)" <drupal.beginner(a)wechange.org> > To: development(a)drupal.org > Date: Wed, 2 Jan 2008 20:27:55 +0800 > Subject: [development] #ahah documentation - Re: groking ajax callbacks > On Tuesday 01 January 2008 21:22, Peter Wolanin wrote: > > Augustin, > > > > The #ahah element was (if I recall) added after the major changes > > to the book module went in. So The page I pointed you two predates > > its existence (and is thus obviously incomplete). quicksketch and > > dmitrig01 tweaked the book module form to include #ahah later. You > > might be able ask them for some help with the docs. > > http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/book/book.adm > >in.inc?r1=1.3&r2=1.4 > > Actually, I found out a few minutes ago, that quicksketch made some > considerable effort to document all of this, but his patch never got > committed: #18 at > http://drupal.org/node/154398#comment-573549 > > > Would that mean that most of your page is now obsolete? > http://drupal.org/node/150859 > Could you review it, or at least add a note and a warning to it, re. > #ahah ? > > > Blessings, > > Augustin. > > > > >

1 0

Re: [development] groking ajax callbacks
by Peter Wolanin 02 Jan '08

02 Jan '08

Augustin, The #ahah element was (if I recall) added after the major changes to the book module went in. So The page I pointed you two predates its existence (and is thus obviously incomplete). quicksketch and dmitrig01 tweaked the book module form to include #ahah later. You might be able ask them for some help with the docs. http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/book/book.admin.inc?r… -Peter > ---------- Forwarded message ---------- > From: "Augustin (Beginner)" <drupal.beginner(a)wechange.org> > To: development(a)drupal.org > Date: Tue, 1 Jan 2008 18:37:30 +0800 > Subject: Re: [development] groking ajax callbacks > > > Neil, Earl, Peter, all, > > > thanks for your replies. > > > I have added your various links in the API section of the handbook: > http://drupal.org/node/205296 > > As far as book.module is concerned, the bit that I missed was the > #ahah part in the form: > > // Add a drop-down to select the destination book. > $form['book']['bid'] = array( > '#type' => 'select', > '#title' => t('Book'), > '#default_value' => $node->book['bid'], > '#options' => $options, > '#access' => (bool)$options, > '#description' => t('Your page will be a part of the selected > book.'), > '#weight' => -5, > '#attributes' => array('class' => 'book-title-select'), > '#ahah' => array( > 'path' => 'book/js/form', > 'wrapper' => 'edit-book-plid-wrapper', > 'effect' => 'slide', > ), > ); > > I found out that the #ahah attribute is completely undocumented, so I > added a placeholder for it in the FAPI reference: > http://api.drupal.org/api/file/developer/topics/forms_api_reference.html#ah… > (my addition might take a few hours to appear). > > It's only a placeholder though. Someone more knowledgeable needs to > complete the doc, there. If nobody does it, at least developers would > be made aware that there is such a thing as #ahah in FAPI. > > Is that something new in Drupal 6 ? > [edit: it seems to be. It is mentioned in a very unlikely place: > http://drupal.org/node/114774#choice_check . > Why not in Peter's AJAX page?] > > > > > > > Blessings, > > Augustin. > > > > > > > > > -- > [ Drupal development list | http://lists.drupal.org/ ] >

3 2

Re: [development] Best practices: Config settings
by Alan Pritt 02 Jan '08

02 Jan '08

killes wrote: > my question is: Where should contrib module authors put config options > for their modules? I've been thinking about this problem a lot lately. I'm yet to come up with a good answer, unfortunately. But... The short answer would be to add it to the module configuration screen. If we don't, users will have to hunt for settings pages and even if they know to look at the '/admin/by-module' page, we are still forcing them to move from page to page in order to set up a module. This is a huge waste of user time. However, it's not a totally satisfactory answer. We consistently place permissions and block-assignments to alternate screens, which confuses beginners. But it is handy to have them all in one place. And a module like gmap or cck addons necessarily have to place the UI deep into the core admin screens. A partial answer is to direct people to the help page once they install a module because this lists all the pages that the module alters. But it's not the most elegant of solutions and is obviously not applicable to any current Drupal releases. For now I'd say keep it in your module config page if it makes sense to put it there. And maybe make a reference to it elsewhere. It's not the optimal solution, but I think it will cause the least confusion in most circumstances. Long term I think we should be looking at presenting the UI in different contexts depending on how the user will be thinking about the problem. For example: 'I need to configure this module' vs. 'I need to make my site perform faster'. But I'm still a bit vague how that would best be implemented. Alan Pritt (alpritt)

1 0

Re: [development] Getting both better internal and external APIs intoDrupal 7
by Michelle Cox 01 Jan '08

01 Jan '08

On 12/30/2007 10:21:32 AM, blogdiva(a)culturekitchen.com wrote: > HOT! > > +1 for including into core : > > CCK > Bio > Panels > > I need more coffee so I can find the notes of a wishlist I have been > compiling for a while. I do know that ICONIZER and BUEditor would be > ideal for those of us who would like Drupal to focus on usability and > better design. I also understand the need to make the default distro > lightweight. For that matter, I still believe there needs to be a > serious push for different "default" distributions --and please, > let's > stop calling those "profiles" because it's confusing with the > term "profile". I've never used iconizer but I really like bueditor. It's easy to use for newbies and yet doesn't get in the way like a true WYSIWYG does. I don't know if the code is core worthy but I think it would be a nice addition if it is. A compromise between those who think Drupal needs a WYSIWYG in core and those who say no way. Of course, it would need to be an optional module, not just hardcoded in. As someone up to her ears in user profiles stuff, I second the changing of install profiles to something else. :) Michelle

2 1

Special new yeat post!!
by ad4m 01 Jan '08

01 Jan '08

Hi gays!! I would like to say something diffrent than ordinary day's problmes.... wish you all guys very happy new year!! Dries some more such great ideas? I'm always ready for your requests! Drupal team - you make my work the best on the world! thx :) keep going... -- Serdecznie pozdrawiam, Adam Ludwinski adam(a)ludwinski.net http://www.ludwinski.net

3 2

preg_match bug or regex help needed?
by Doug Green 31 Dec '07

31 Dec '07

I'm pretty good with regex, but I'm beating my head against the wall with this one, and wondering if there's a bug in php. Any help is much appreciated. (This is for nicedit.) <?php $text = 'style="font-style: italic; font-weight: bold;"'; $regex = "(\s*([a-z][a-z0-9\-]*)\s*:\s*([a-z][a-z0-9\-]*)\s*;)+"; if (preg_match('/'. $regex .'+/i', $text, $matches)) { print_r($matches); } ?> If the regex is confusing, just think of it simply as ((\w+):(\w+);)+ ... with extra spaces and a definition for words that includes dashes. The regex vars $1 and $2 seem to only put the last matching value in the matches array. Array ( [0] => font-style: italic; font-weight: bold; [1] => font-weight: bold; [2] => font-weight [3] => bold ) I was hoping that it would also write font-style: italic into the matches. Thanks, Doug Green

4 5

Re: [development] Getting both better internal and external APIs intoDrupal 7
by Michelle Cox 31 Dec '07

31 Dec '07

On 12/29/2007 11:46:34 PM, Khalid Baheyeldin (kb(a)2bits.com) wrote: > Users as nodes has 3 modules at least in contrib: > > - bio: the most straight forward of them. > - node profile: a more complex way. > - usernode: the original concept. > > The need to customize how profiles look is the driver here, plus cck and > views. > > Core profile should go away soon, replaced by node + cck. Most of this discussion is over my head but I wanted to comment on this. My upcoming Advanced Profile module uses Panels 2 for displaying the user profile on the view tab of the user page. It currently uses bio but will eventually be able to use bio, node profile, or even the core profile module. I'm designing it so it doesn't care where it gets the profile information from. What would be ideal is to have in core some way of optionally associating a user with a node type as bio does and also include in core a lightweight non-node solution for holding profile data for those who don't want a node for every user. Then people could use Panels 2 (which would be lovely to have in core someday) to display this "user profile object" as well as anything else they want on that page. For now, I'm making this possible in contrib, but having some of it in core would reduce the module dependency for this method. Michelle

5 5

Locked The Thread
by Karoly Negyesi 31 Dec '07

31 Dec '07

So there can be no misunderstanding, this mail is BCC'd to Dub. I also contacted him but I want to be sure. I locked the thread because of repeated pleas to stop and because I and many have been called a psychopant. This is just flaming and not constructive any more.

3 3

Using Admin Theme on Other Pages
by Ben Wheeler 31 Dec '07

31 Dec '07

Hi All, I think this is fairly simple to do, but I couldn't find anything in the forum/handbooks. I have a theme that's very specific and doesn't work well for admin type situations, so I have an admin theme set up. I'd like to use my admin theme on other pages, so in my custom module hook_menu (taking a cue from system.module) i have: function custom_menu($may_cache) { $items = array(); if ($may_cache) { blah blah blah } else { if (arg(0) == 'webfm' OR arg(0) == 'user') { global $custom_theme; $custom_theme = variable_get('admin_theme', '0'); } } return $items; } Which doesn't work at all, although it does set the variable $custom_theme quite nicely. I'm thinking I have to set this at another time, but I don't know how the whole admin theme thing works. Any suggestions? Thanks. -Ben

2 1