- Development - lists.drupal.org

Stefan's theme
by Dries Buytaert 02 Sep '06

02 Sep '06

Thoughts and comments about Stefan's theme (http://istyledthis.nl) can be posted in this thread. Like with the previous thmeme's thread (which got royally f*cked up, thank you very much), focus on the aesthetics, brand and message. We'll worry about implementation later. Thanks, -- Dries Buytaert :: http://www.buytaert.net/

17 25

module_exist() / module_exists()
by John VanDyk 01 Sep '06

01 Sep '06

From http://drupal.org/node/64279#module-exists : "module_exist() is now module_exists() For consistency with PHP function_exists, file_exists, etc. That's about all there is to say about that. :)" From my local copy of cvs: $ cd /cvs/contributions/modules $ grep -r module_exist\( . | wc -l 630 It would be nice to have a wrapper function in for one release cycle.

2 1

review and comments on Deliciously Drupal Theme (eastetics only) :)
by Bèr Kessels 01 Sep '06

01 Sep '06

Hi, First of all, the previous thread is rather messed up, so I am posting this outside of that snakepit. I did a close review on the Deliciously Drupal theme and posted it in an annotated image on my site: http://webschuur.com/node/646 (because the files are too big to attach) Let me start with general comments: I like the "air" it breathes. Space is used *very* well, the overall design is balanced very well, and the use of colors is done in an (almost) perfect way (for a general theme). The comments I have are mostly details and not all should be takcen too serious. I also only commented on the parts I could see right away, I'd love to do the same sort of review for some parts of the backend I know to be problematic in general, but because doing this is a *lot* of work, i'd rather first see what my initial effort leads to :) Bèr

1 0

Drupal.org stats August 2006
by Gerhard Killesreiter 01 Sep '06

01 Sep '06

as collected by awstats Unique visitors 2773136 Number of visits 7333803 pages 55628533 Hits 227387882 Bandwith (without the FTP downloads!) 1563.25 GB Top urls / 550000 /node/feed 300000 /rss.xml 230000 /cvs 180000 /project/Modules 180000 /security/rss.xml 150000 Browsers FF 47.2 IE 36.9 Opera 2.6 Safari 3.5 Mozilla 2.9 Referrers from search engines Google 430000 Yahoo 23800 MSN 2067 Other external Referrers themes.d.o 5100 themes.d.o/node 3305 stumbleupon 4300 http://www.nicklewis.org/node/766 3350 www.opensourcecms.com 3057 opensourcecms.com 2360 gallery.menalto,ocm 2156 Downloads from ftp.osuosl.org drupal-4.7.3 33493 drupal-4.6.9 5454 image-4.7.0 5099 tinymce-4.7.0 4691 drupal-4.7.2 3332 cck-4.7.0 3026 4.7-installing.mov 3026 event-4.7.0 2928 4.7-whats-new.mov 2666 ecommerce-4.7.0 2543 multiflex-4.7.0 2530 acidfree-4.7.0 2479 views-4.7.0 2255 gallery-4.7.0 2038 friendselectric-4.7.0 1966 front-4.7.0 1854 meta-4.7.0 1847 flatforum-4.7.0 1762 flexinode-4.7.0 1700 img_assist-4.7.0 1645 antique_modern-4.7.0 1562 panels-4.7.0 1542 nice_menus-4.7.0 1524 fancy-4.7.0 1523 gsitemap-4.7.0 1499 andreas01-4.7.0 1475 adsense-4.7.0 1445 audio-4.7.0 1440 category-4.7.0 1409 views-cvs 1409 pathauto-4.7.0 1389 internet_services-4.7.0 1382 spreadfirefox-4.7.0 1376 aquasoft-4.7.0 1361 og-4.7.0 1359 taxonomy_access-4.7.0 1333 print-4.7.0 1330 video-4.7.0 1312 fern-4.7.0 1293 burnt-4.7.0 1292 andreas09-4.7.0 1291 B7-4.7.0 1275 niftyCorners-4.7.0 1242 box_grey-4.7.0 1222 i18n-4.7.0 1218 chatbox-4.7.0 1211 google_analytics-4.7.0 1191 es-4.7.0 1172 voodoo_dolly-4.7.0 1164 controlpanel-4.7.0 1139 feedback-4.7.0 1128 emailpage-4.7.0 1125 article-4.7.0 1095 phptemplate-4.6.0 1068 webform-4.7.0 1064 logintoboggan-4.7.0 1063 advuser-4.7.0 1034 bbcode-4.7.0 1009 poormanscron-4.7.0 1004

1 0

Change in access labels
by Ken Rickard 01 Sep '06

01 Sep '06

I just downloaded the new cvs tarball and found the following error. The access control setting is now named 'administer site configuration' instead of the old 'access configuration pages'. This change caused menu errors in the system, node, and user modules. See http://drupal.org/node/81902 I post this here because the error is not visible to user 1, who always has access to all menu items. I needed to setup user 2 as an administrator to see this error. - Ken Rickard agentrickard

1 0

Code freeze in preparation of Drupal 5.0.0
by Dries Buytaert 01 Sep '06

01 Sep '06

Hello world, Drupal 5.0.0 has been frozen. Read the full announcement at: http://drupal.org/node/81861. Developer highlight: "It is estimated that it will take at least two months before Drupal 5.0.0 can be released. During that period, one or more release candidates will be made available. Furthermore, a two month code freeze should give module maintainers plenty of time to upgrade their modules. People who maintain contributed modules or themes are advised to start updating them to be compatible with Drupal 5.0.0." (Read: there will be a guaranteed time period of 2 months to upgrade your modules, and possibly more. Given that the development period only took 3 months, this seemed like a fair time period for *cough* responsible *cough* module maintainers.) -- Dries Buytaert :: http://www.buytaert.net/

2 1

all fields in the create content forms now can be pre-populated from the URL
by Karoly Negyesi 01 Sep '06

01 Sep '06

Hi, I very rarely rave about contrib modules. But this worths mentioning: http://drupal.org/node/55403 got fixed. Congratulations for everyone involved: egfrith and eafarris. Regards NK

34 94

Data API
by Mark Fredrickson 01 Sep '06

01 Sep '06

After the previous round of talks on the form api, I have a proposal for future Drupal development: let us rename the form API to the data API and start to look at it as the central method of implementing a full MVC in Drupal. First, some observations: HTML forms are simply a method of getting data from users, nodes are collections of defined data, nodes are increasingly represented as "forms" - however, coupling our data to an XHTML representation blurs the line between model and view. The general benefits and costs of an MVC design pattern are outside the scope of this email, but feel free to criticize my position if you don't like MVCs. I will say, MVC isn't the only design pattern, but it's a good one if you don't have a reason to choose something else. Let me map the model, view, and controller to current and future Drupal constructs: 1. Model: I think most people would say that the current model is just the db schema. I say that the model should be the schema AND the data definition (currently in the shape of a form definition). In fact, I might argue that schemas should be phased out for a database abstracted system. Imagine if you could just define a simple data structure in the form: $mydata = array( '#type' => number, '#name' => 'My Number', '#default_value' => 1234, ); etc... While I agree that we having a drupal specific DDL is bad, the reality is that we already do have one: the current formAPI. Accepting that fact and writing tools to turn $mydata into a db schema will only help development, not raise the barrier. 2. Controller: These are the _submit and _validate functions right now. I know there is work going on to more flexibly work with these items (eg. I owe a patch to allow binding of buttons to functions). I think the controller layer probably needs the most work. The recent nodeapi vs. formAPI (call it Data API now!) illustrates this fact. 3. Views: Arguably, these are the theme_* functions; however, this is where the coupling of data to XHMTL forms I mentioned earlier comes in. Take for example '#type' => 'checkbox'. This definition makes me cry every time. Multiselects and checkboxes should be collapsed into one type: multi. Radios and drop downs should be collapsed into one type: single. Text boxes and text fields should just be one type, varied on size (and perhaps something else to allow filtering). If we move these functions into the theme layer, forms API will stop being just about forms and wills start being about data. Good. So, what are the benefits of this system? First, I think changing the semantics of the name will allieviate some confusion regarding the role of the Data API. The recent nodeapi discussions have shown that there is confusion over where and when data should be manipulated. I think it gives us CCK like features right out of the box. Since most of the data api will be used for defining nodes, it seems natural to me that users could define forms online and Drupal would turn them into types on the fly. This email is getting long as it is, so I'll end it here. Of course, discussion is welcome. Cheers, -M

3 2

Re: [development] possible theme?
by Ken Rickard 01 Sep '06

01 Sep '06

>Oh, if you do that, make text #000, then you could get away with .node > .submitted boing #666 >Or would you disagree there too Ken? No, I agree. Submitted is the perfect place for grey or light text. It's 'extra' information that I don't need to read. Making it a lighter color reiniforces that. Making it lighter actually gets it out of the way of the 'real content.' - Ken agentrickard

5 5

re: RE: RE: RE: [development] changes to hook_nodeapi
by Peter Wolanin 01 Sep '06

01 Sep '06

Jeff, My criticism was a little too broad, perhaps- I don't think the entire patch should be rolled back but that at the least 3 of the 4 ops, insert, update, delete, should stay where they are in hook_nodeapi. I might also argue for the return of hook_delete. The removal of hook_validate, hook_insert, and hook_update make more sense, becuase a module that implements them would already have to be constructing a node form. However, that still means that calling node_save() in its present form wouldn't work. I agree with your comment that node_save should be refactored as a helper function (regardless). I don't think this patch fundamentally enables programatic submission (correct me if I'm wrong) -that was in other patches. http://drupal.org/node/68418 does make *some* changes to assist programtic submission, but primarily eliminates various hooks from the node module and removes ops from hook_nodeapi. -Peter >Date: Thu, 31 Aug 2006 15:01:39 -0500 >From: "Jeff Eaton" <jeff(a)viapositiva.net> >Subject: RE: RE: RE: [development] changes to hook_nodeapi >To: <development(a)drupal.org> >Message-ID: <003e01c6cd38$4900a700$6700a8c0@JEATON2DEV> ... >Perhaps what we should ask is, 'OTHER than rolling back an important >piece of code recapturing, how can we make the new mechanism as easy for >developers as the old one was?' Not _the same as_ but _as easy as_. >Perhaps a helper function to 'register' your module's CRUD without >altering any form arrays? Perhaps node_save() existing as a wrapper >function for the functionality? > >> Even without this patch, any developer who *wants* to use the >>Forms API and submit hooks can. This patch *forces* us, even >>when it's not appropriate to the data model (as mentioned in >> a previous post). > >No. Previously, developers who wanted to use the Form API hooks for >programmatic submission could not. It didn't work. Period. That was sad, >because the provisions for validation, error handling, and extendibility >that are there in Forms API are all lacking in nodeapi's simple model. > >What is needed, IMO, is a set of simpler wrappers and interfaces for the >'simple' cases that don't cripple the complex ones. Previously, the >simple cases just used a completely different validation/submission >pipeline -- and that was a serious problem. > >We now have a different (albeit less fundamental) problem -- but one >that is solvable. IMO, at least :) > >--Jeff

4 3