- Development - lists.drupal.org

[drupal-devel] Drupal conference, Amsterdam
by Dries Buytaert 28 Sep '05

28 Sep '05

Hello world, next month, many of us will be in Amsterdam to attend the Drupal conference: http://drupal.org/conference-amsterdam-2005. The goal is to meet in person, to educate new users, to brainstorm about the future of Drupal, to get some development done, and to have fun in and around Amsterdam. Antwerp was fun, Portland was fun, Amsterdam will be fun too so better be there. People can self-organize and get some hacking done in small or large groups; we'll provide the space. To do so, we're renting a venue for either 2 or 3 days -- Ber and Bert are finalizing the deal. Furthermore, Boris secured some funding so the Drupal conference will be free to attend. More details will follow shortly. First things first. We plan to do a number of Drupal presentations and to do so we need people to present. The idea is to do many short presentations (maximum 10 minutes, lightning talks) followed by a discussion (maximum 20 minutes). Possible topics include (but are not limited to): (i) a module you've written, (ii) a module you plan to write, (iii) a website or project you've done, (iv) a proposed core change, (v) the results of a survey, analysis, or benchmark, (vi) a problem or bottleneck you observed, (vii) drupal.org related issues, etc. Anything Drupal can be discussed and everyone is encouraged to submit a topic. The presentations are fun and informal; they have proven to be a great way to get feedback and directions. If you want to present something, please send an e-mail with the topic of your proposed presentation and a two line description. I'll add the presentations to the conference page at http://drupal.org/ conference-amsterdam-2005. If you like to see something presented rather than presenting it yourself, you can request a presentation. Once we have enough presentations, we'll categorize them in groups. I hope to get more than 20 presentations by the end of next week. PS: http://www.expatica.com/source/forum_thread.asp? channel_id=1&thread_id=29858 (thanks Adrian) -- Dries Buytaert :: http://www.buytaert.net/

8 14

[drupal-devel] forms should reflect settings.php hardcodes
by Bèr Kessels 27 Sep '05

27 Sep '05

Yet another minor issue, that can lead to Mayr annoyances. when a setting is set in settings.php, for example the site slogan, one can still set that slogan in admin/settings. That is strange, and very confusing. A 'hosting provider' such as BygHost, might choose to set harcoded footers 'supported by BygHost'. Users will be very confused why they changed theyr footer, yet the site does not change it. The field of any setting that is harcoded should best dissapear, or otherwise be greyed out. Is that possible with the form API? Ber

4 3

RE: [drupal-devel] Drupal conference, Amsterdam
by Boerland, Bert 27 Sep '05

27 Sep '05

-----Original Message----- From: drupal-devel-bounces(a)drupal.org some session I would like to see and help setup. not all technical, yet maybe good to have a mix between harder and softer items. * ASK THE EXPERT one hour troubleshooting by the experts live on IRC, "you ask, we solve" [TM] * SETUP A GUILD Talk about how to make sure that quality consultants and coders are listed, how to give eachother jobs instead of competing with eachother (note: not sure if people who make money doing drupal consultancy need this?) * WHAT DIFFERS A (CM)PLATFORM FROM A (CM)SYSTEM Drupal presents itself as a content management platform but may be nothing more than than yet another content management system ("blogengine") * HOW PROJECT MANAGEMENT METHODS CAN HELP AN OSS PROJECT Drupal and most OSS projects have a natural hierarchy and just work. Why is this different from commercial projects, what can methods like PRINCE2 add to running a drupal project? * SNIPLET SESSIONS Live coding and documenting on drupal.org of some cool php blocks that can be used * WORKFLOW VS APPROVALFLOW What is drupal lacking to have true workflow and how (if needed) can this be tackled? * RELEASE 4.7 ON DRUPAL CON nuff said

2 1

[drupal-devel] CVS contribution etiquette
by Steve Dondley 27 Sep '05

27 Sep '05

I contribute small patches to Drupal core occasionally and to third party modules more frequently. I have CVS access to the Drupal contributions, however, I tend to contribute via uploaded patch files and I'm wondering if I should be using CVS instead. But I'm hesitant to make changes to someone else's module. So what are the rules and etiquette for contributing via CVS? Should I just stick to uploading patch files? -- Dondley Communications http://www.dondleycommunications.com Communicate or Die: American Labor Unions and the Internet http://www.communicateordie.com

3 2

Re: [drupal-devel] two minor usability issues, introduced recently
by Kobus Myburgh 27 Sep '05

27 Sep '05

> ... Because -i assume- usability reviewers > find it far too much hassle to maintain local devel sites where they can > apply patches. This assumption is absolutely correct, I believe, but in my case it is not practically possible. Having no internet connection at home, and being severly restricted at work (with regards to software that may be loaded) makes this a tough thing to do, so if I want to do this, I need to do this live, and the problem with that is that my host doesn't give me shell access. I have to do everything through some GUI (CPanel). Regards Kobus

1 0

Re: [drupal-devel] forms should reflect settings.php hardcodes
by Kobus Myburgh 27 Sep '05

27 Sep '05

I agree with Ber in principle, however, it should not disappear, but rather greyed out with a notice why it is greyed out, because people will think that Drupal don't support that specific setting. Optionally also import the content of the hardcoded text into the textarea/field before greying it out. That would clear up a lot of confusion in itself if they can see what the predefined content is. Regards, Kobus >>> berdrupal(a)tiscali.be 9/27/2005 11:05 AM >>> Yet another minor issue, that can lead to Mayr annoyances. when a setting is set in settings.php, for example the site slogan, one can still set that slogan in admin/settings. That is strange, and very confusing. A 'hosting provider' such as BygHost, might choose to set harcoded footers 'supported by BygHost'. Users will be very confused why they changed theyr footer, yet the site does not change it. The field of any setting that is harcoded should best dissapear, or otherwise be greyed out. Is that possible with the form API? Ber

1 0

[drupal-devel] two minor usability issues, introduced recently
by Bèr Kessels 27 Sep '05

27 Sep '05

I just upgrded to HEAD and very much suprised to find two rather unfortunate usability iissues introduced: MBstring support? This seems to Just Work, why do I need a collapsed form element telling me it works? Joe user (and I) should not be bothered with form options that are no options. RSS in the global settings is a bit an unfortonate choice. first of all, the amount of items set gloabally: 1) why cant this simply respect the amount-of-nodes global setting? 2) RSS without nodes (in core) is non existing. Thus this is no common setting. Therefore I think this RSS setting should live under settings >> RSS settings, so that contribs can add LOCAL_TASKS or so. The current placement requires any other RSS setting (by a contrib) to be placed elsewhere. Scattered settings are one of the mayor usability issues in Drupal. I really think we must get such changes past at least some usability test before they hit core. PAtches are tested and tweaked on comma, tab and spaces level, yet usability is often simply ignored. Herein lies a great opportunity for the community, IMO. Ber

9 15

[drupal-devel] Re: A collection of usability problems
by Kobus Myburgh 27 Sep '05

27 Sep '05

Ahhh. Thanks, ax! I know of the mailing lists, but what I find troublesome sometime is "what to search for", because I am not sure what the term is for what I am looking for. Thanks for clearing this up. Regards, Kobus >>> axel(a)kollmorgen.net 9/26/2005 10:19 PM >>> On 26.09.2005 12:58, Kobus Myburgh wrote: > Excuse the off topic post here, but I read this here and was > wondering about that many times before. Why can't we do it > /node/edit/4/* instead of /node/*/edit? Would make a lot of little > nagging problems I have to code around all the time go away... :-) http://lists.drupal.org/archives/drupal-devel/2004-05/msg00151.html pp. -- ax Je respecte trop l'idée de Dieu pour la rendre responsable d'un monde aussi absurde.Georges Duhamel

1 0

[drupal-devel] Swiss army knife of RSS feeds - SQL Search patch
by Seth Cohn 27 Sep '05

27 Sep '05

I've uploaded a very rudimentary patch to trip_search (aka SQL search) giving it the ability to generate a RSS feed based on the search. I'll let those with more drupal skills than I have take it further and bring it up to standards, but it's such a simple and easy patch (kudos to everyone who makes it easy to write drupal code) and gives such a great benefit (unlimited customizable RSS feeds of whatever content you want), I want to be sure it doesn't get lost and the right people see it to make those improvements. http://drupal.org/node/32212

2 2

RE: [drupal-devel] Admin theme
by Steven Peck 27 Sep '05

27 Sep '05

If we do put a default admin theme in core, then it should be shipped default off. I find the CS admin theme essentially unusable and a shock when I navigate to it. Admittatly my pool of people I can survey numbers about twelve, but I asked them all and they find that what things they control (blocks, users, content) are disrupted when they navigate away from the look and feel of their current site. One small voice on the -1 crowd -sp > -----Original Message----- > From: drupal-devel-bounces(a)drupal.org > [mailto:drupal-devel-bounces@drupal.org] On Behalf Of Bèr Kessels > Sent: Monday, September 26, 2005 9:24 AM > To: drupal-devel(a)drupal.org > Subject: Re: [drupal-devel] Admin theme > > On Monday 26 September 2005 17:49, James Walker wrote: > > Ok... but I thought one of the big pushes for the admin > theme camp is > > that there would be one true admin theme to rule them > all... so that > > administration of a drupal site was uniform , and thus much > easier to > > document (i.e. where to click, etc) ... then that > information can be > > reliably written in docs (and books) without a "theme depenedent" > > caveat. > > > > or am i missing something 'cause I'm not a usability guy? > > No, I think you might be mmissing the same some others seem > to overlook. I, and other consultants (AFAIK in th thread it > are all small consultants who are "against" an admin theme in > some way) want flexibility above all. > Not one of my sites is the same. Not one site will have the > same admin as another. > > Thus A 'uniform' way is very hard. We really really really > need something that is very flexible, if its up to me. > > And from the comments in here, I get the idea that most > people like the sections idea: select the pages that are > served in an admin theme in the exact same way as we define > paths for blocks. > > So, my idea is that most people in this thread preferred: > A core admin theme. > A UI that allows you to define where theme 'FooBar' will be used. > By default FooBar will be the admin theme. > > Is that correct, people? > > Ber > > >

2 1