> > >

Our current mission is to try and stabilize this theme on > Drupal 4.6.x before we move forward with future revisions. So, please keep > in mind the CS Theme is meant to work on Drupal 4.6.3 at this point in > time.

CivicSpace Theme Plan
>

> Also, add verticle-align: top to your #div-column-left definition. On 11/11/05, Trae McCombs wrote: > Ok, so let me post a wee bit of information. Please check this URL out > first: > > http://civicspacelabs.org/home/CivicSpaceTheme > > This will, or should, bring you up to date on some of the terms I'm > going to be using below. The CivicSpace Theme (CST) is using some new > concepts in themeing. > > Anyway, my question currently is this. > > The Federation Layout looks fine on Firefox, but for some reason it > isn't working in IE. Meaning, it doesn't match it's thumbnail. If you > simply compare both browsers, and notice how FF looks and IE doesn't > then you should see what's wrong. I can't figure out what is causing > it. Someone suggested #content, however that only changes the internal > body. > > Here is the site where I am currently working on things, and the > Federation Layout is selected at present: > > http://demo.civicspacelabs.org/home/ > > Also, this may be of some use. It is the Plan of action, or guide we > are trying to use for the CST: > > http://civicspacelabs.org/home/CivicSpaceThemePlan > > Please, feel free to join me on #cstheme on irc.freenode.netand discuss > any of these issues. I do look forward to your help. > > Thanks, > Trae > > PS. Kieran (Amazon) says I can blame him for this [and any and all > further silly questions I have -- oh wait, maybe he didn't say all of > that exactly. :)] > > -- > Trae "occy" McCombs || http://occy.net/ > Founder - Themes.org // Linux.com > CivicSpaceLabs - http://civicspacelabs.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051112/6f9fffd0/attachment.htm From karoly at negyesi.net Sat Nov 12 12:57:36 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Sat Nov 12 12:55:13 2005 Subject: [development] Forms API Question - Node with table like poll.module In-Reply-To: <4375D536.6040002@dirtbike.ws> References: <43753882.2010706@dirtbike.ws> <4375D536.6040002@dirtbike.ws> Message-ID: On Sat, 12 Nov 2005 12:42:46 +0100, Simon Lindsay wrote: > Karoly Negyesi wrote: >> form['entries']['#theme'] = 'mymodule_foo'; >> function theme_mymodule_foo($form) { >> } >> For examples, I'd grep on element_children (though there are quite a >> few forms that got updated before element_children was born). > > OK, but the timesheet module is an extension of node.module, and you're > supposed to "return $form;" at the end of the "function > timesheet_form(&$node)", not "return > drupal_get_form('timesheet_entries', $form);". Yes. Return $form and it'll call theme_mymodule_foo with the array in $form['entries'] Regards NK From ber at webschuur.com Sat Nov 12 14:24:12 2005 From: ber at webschuur.com (Ber Kessels) Date: Sat Nov 12 14:24:17 2005 Subject: [development] Files on previews In-Reply-To: <43740D94.9020509@walkah.net> References: <1912.213.46.81.27.1131667932.squirrel@www.webschuur.com> <43740D94.9020509@walkah.net> Message-ID: <20051112152412.d0c00a1b.ber@webschuur.com> On Thu, 10 Nov 2005 22:18:44 -0500 James Walker wrote: > I won't go so far as to say maybe upload.module should do something > similar... ;) I like this. It sounds like a much better solution then what upload has now. Now, in my world, I dont have that much trouble with dangling images due to peoples ugly operating systems crashing (or ppl closing the browsers). I /do/ have a lot of trouble with GD and or imagemagic crashing (mostly because morons cannot understand the difference between a 20Meg image and a 500k one!). One of my reasons for starting this general upload stuff, is to be able to handle these kind of problems in a central place. My plan in my new system is to uplaod the image, and even insert it in the table. if its there, if it has a uid/nid/wid (whateverid) it is finished, finito. even if a browser crashes: its there. files without an id are indeed orphans (like walkahs images in /tmp) as are files that were processed, but not yet inserted in that table. A cron can then delete all non-wid files from the table AND the FS. And a cron can delete all files from the FS that are not in the databasetable. Ber From ber at webschuur.com Sat Nov 12 14:35:41 2005 From: ber at webschuur.com (Ber Kessels) Date: Sat Nov 12 14:35:46 2005 Subject: [development] Re: [drupal-devel] Forms API documentation update In-Reply-To: <4374BBE4.4020208@tinpixel.com> References: <4368691D.6080508@webchick.net> <4374397C.3060700@webchick.net> <4374B5F2.30804@tejasa.com> <4374BBE4.4020208@tinpixel.com> Message-ID: <20051112153541.40e3b857.ber@webschuur.com> A big THANK you too, from me. Great job! in the mean time: if you find anything related to formsAPI, rants on weblogs, kudos, posts in forums etc etc: http://del.icio.us/tag/formsapi I think it is good to collect all sorts of pages there, for example: http://del.icio.us/tag/formsapi+rant . It will help us understand what people think and want. Ber On Fri, 11 Nov 2005 09:42:28 -0600 Chris Johnson wrote: > Moshe Weitzman wrote: > > Angie Byron wrote: > > > >> Another update. > >> > >> Tonight, Kieran, K?roly, and I worked on http://drupal.org/node/37194 > >> which > >> presents a flowchart and code example comparing the "old" forms API > >> with the new > >> one, for those who are more "visual" in their learning approach. > >> Hopefully this > >> will prove valuable for people who are struggling a bit with the > >> "bigger picture." > >> > >> I've also added the following pages since the last update: > >> > >> * Forms API FAQ: http://drupal.org/node/36899 > >> * Tips and Tricks: http://drupal.org/node/36900 > >> > > > > Great job, guys and gals. Thanks much. > > > > Absolutely. You all rock! > > Your dedication motivates me to do more for Drupal. > > ..chrisxj > From chad at apartmentlines.com Sat Nov 12 14:50:22 2005 From: chad at apartmentlines.com (Apartment Lines) Date: Sat Nov 12 14:54:50 2005 Subject: [development] Forms API Question - Node with tablelike poll.module In-Reply-To: <4375D536.6040002@dirtbike.ws> Message-ID: simon, please visit the core examples section of the handbook: http://drupal.org/node/36052 i believe you'll find that the system_user example and the system_themes example have what you're looking for. also, if you haven't yet, please visit the general forms API documentation at: http://drupal.org/node/33338 at this point, i believe the doc team has covered most of the issues necessary to convert a module to the API. chad > -----Original Message----- > From: Simon Lindsay [mailto:simon@dirtbike.ws] > Sent: Saturday, November 12, 2005 04:43 > To: development@drupal.org > Subject: Re: [development] Forms API Question - Node with tablelike > poll.module > > > Karoly Negyesi wrote: > > form['entries']['#theme'] = 'mymodule_foo'; > > > > function theme_mymodule_foo($form) { > > } > > > > For examples, I'd grep on element_children (though there are quite a > > few forms that got updated before element_children was born). > > OK, but the timesheet module is an extension of node.module, and you're > supposed to "return $form;" at the end of the "function > timesheet_form(&$node)", not "return > drupal_get_form('timesheet_entries', $form);". > > However, doing the "return $form" means that the theme doesn't get > called, and doing the "drupal_get_form" gives array errors. > > I can't find a module that extends node that uses the themeing for node > submission (despite quite a bit of grepping), although several use it > for administration. If anyone can point one out to me, or where I'm > going wrong, that would be great. > > Simon > > From drupal-devel at drupal.org Sat Nov 12 15:20:15 2005 From: drupal-devel at drupal.org (drupal-devel@drupal.org) Date: Sat Nov 12 15:20:20 2005 Subject: [development] Release critical bugs for November 12, 2005 Message-ID: <20051112152018.D5FAA138281@drupal2.osuosl.org> / bug reports PHP 4.4.1 breaks Article Categories list age: 1 week 1 day url: http://drupal.org/node/36245 / bug reports XML Parsing Error age: 1 week 4 days url: http://drupal.org/node/35872 / bug reports email spam filtering does not "see" email addresses when they are NOT preceded by a word age: 42 weeks 6 days url: http://drupal.org/node/15654 / bug reports broken config screen age: 3 days 3 hours url: http://drupal.org/node/36949 / bug reports Theme settings assigned: pofe@drupal.hu age: 1 day 17 hours url: http://drupal.org/node/37160 Query failed: ERROR: null value in column "cid" ..... age: 3 days 5 hours url: http://drupal.org/node/36932 Uploads don't go away assigned: Souvent22 age: 3 days 18 hours url: http://drupal.org/node/36875 not work hook eg. fckeditor_textarea ($op, $name) ? assigned: Kiev1.org age: 4 days 1 hour url: http://drupal.org/node/36816 Postgres 4.5.4 to 4.5.5 upgrade makes user system break. age: 5 days 7 min url: http://drupal.org/node/36670 Right blocks pushed beyond the header boundary age: 5 days 9 hours url: http://drupal.org/node/36637 >From validation won't work for user's on some ISP's age: 5 days 19 hours url: http://drupal.org/node/36591 Random "access denied" and logouts age: 1 week 18 hours url: http://drupal.org/node/36386 Profile.module accepts, but does not display, user input age: 1 week 19 hours url: http://drupal.org/node/36381 old behaviour missing on admin/themes age: 1 week 1 day url: http://drupal.org/node/36333 expecting `T_STRING' or `T_VARIABLE' or `T_NUM_STRING' age: 1 week 2 days url: http://drupal.org/node/36159 Mail warning errors age: 1 week 3 days url: http://drupal.org/node/35973 Form API missing textarea hook age: 2 weeks 20 hours url: http://drupal.org/node/35594 update makes me loose all my themes and blocks and so. age: 2 weeks 23 hours url: http://drupal.org/node/35577 Profile_values random overwritten age: 2 weeks 1 day url: http://drupal.org/node/35555 IE allocates memory until it crashes age: 2 weeks 2 days url: http://drupal.org/node/35368 $status is not returned when the vocabulary 'Forums' is being made age: 2 weeks 4 days url: http://drupal.org/node/35177 Duplicate entries in aggregator age: 2 weeks 5 days url: http://drupal.org/node/35048 Bad SQl query, postgresql, c.format column to GROUP BY clause age: 2 weeks 5 days url: http://drupal.org/node/35008 Changing theme in cvs PHP5 is not working age: 2 weeks 5 days url: http://drupal.org/node/34991 Error when using the 'Vote' button to vote at a poll age: 2 weeks 6 days url: http://drupal.org/node/34921 Search results don't include last part of longer pages age: 3 weeks 16 hours url: http://drupal.org/node/34826 Cron Search Executes PHP pages - Node Range Lost Permanently in Search age: 3 weeks 1 day url: http://drupal.org/node/34768 Can't save admin settings - "directory does not exist" age: 3 weeks 2 days url: http://drupal.org/node/34646 Permissions Too Prohibitive on Install age: 3 weeks 3 days url: http://drupal.org/node/34502 upload module and space in filenames age: 3 weeks 3 days url: http://drupal.org/node/34497 Problem with nodes when upgrading 4.6.3 ->4.7 age: 3 weeks 5 days url: http://drupal.org/node/34342 Bug in settings (if upload directory is unwritable we won't be able to change settings) assigned: chx age: 3 weeks 6 days url: http://drupal.org/node/34218 Theme settings not saved since Forms API assigned: chx age: 4 weeks 2 hours url: http://drupal.org/node/34170 overzealous file_check_directory for file_directory_path age: 4 weeks 3 days url: http://drupal.org/node/33771 Pictures (avatars) don't display age: 4 weeks 4 days url: http://drupal.org/node/33699 No checking/catching for unique database columns assigned: cyrific age: 4 weeks 6 days url: http://drupal.org/node/33478 Bug in node_load call in statistics_node_tracker age: 7 weeks 19 hours url: http://drupal.org/node/32040 Upload broken in IE age: 7 weeks 1 day url: http://drupal.org/node/31968 Comment options: broken. age: 7 weeks 4 days url: http://drupal.org/node/31641 Node update hooks are getting stale data and can't save. age: 7 weeks 6 days url: http://drupal.org/node/31495 Translation/localization import bug (Drupal 4.6.3, Fedora 4) age: 8 weeks 1 day url: http://drupal.org/node/31364 When removing a revision, the associated files are not removed. assigned: killes@www.drop.org age: 8 weeks 1 day url: http://drupal.org/node/31355 Delete filter format fails age: 9 weeks 23 hours url: http://drupal.org/node/30781 Submit button needs double-press when menu options dropped-down age: 10 weeks 3 days url: http://drupal.org/node/30097 update.php is broken when drupal is installed in subdirectory age: 10 weeks 3 days url: http://drupal.org/node/30075 Drupal "forgets" some blocks... age: 11 weeks 1 day url: http://drupal.org/node/29733 system_settings_save() bypasses access_control age: 11 weeks 1 day url: http://drupal.org/node/29680 files table needs a "module" column age: 11 weeks 6 days url: http://drupal.org/node/29297 logo uploads still broken...? can't replace default logo with new drupal 4.6.3 tar ball? age: 12 weeks 19 hours url: http://drupal.org/node/29221 Error when anonymous user creates content age: 12 weeks 3 days url: http://drupal.org/node/29032 Reset user mail variables. age: 12 weeks 5 days url: http://drupal.org/node/28868 Free Tagging broken on forums age: 13 weeks 3 days url: http://drupal.org/node/28607 js addLoadEvent not working. age: 14 weeks 6 days url: http://drupal.org/node/27884 Forum bug with drupal 462 age: 15 weeks 2 days url: http://drupal.org/node/27663 enable MySQL client side for UTF8 age: 16 weeks 4 days url: http://drupal.org/node/26990 Drupal 4.6.2 Doesn't allow login (IIS 5.1, PHP 5.0.4) assigned: bigeye age: 17 weeks 22 hours url: http://drupal.org/node/26780 use upload_tmp_dir as default for FILE_DIRECTORY_TEMP age: 18 weeks 6 days url: http://drupal.org/node/26249 postgresql autocomplete code age: 19 weeks 2 days url: http://drupal.org/node/26027 Accidentally Deleting Forums Vocabulary in Categories Breaks Forums? age: 23 weeks 13 hours url: http://drupal.org/node/24274 Getting term node counts fails without "Administer Nodes" permission age: 23 weeks 3 days url: http://drupal.org/node/24015 Mysql Password with special symbols assigned: zignit age: 27 weeks 6 days url: http://drupal.org/node/21719 4.6 aggregator showing/not interpreting HTML tags age: 31 weeks 6 days url: http://drupal.org/node/19874 New submit error, non-admin user, postgresql database assigned: adrian age: 35 weeks 3 days url: http://drupal.org/node/18552 user redirected to homepage when logging in age: 36 weeks 21 hours url: http://drupal.org/node/18381 Cache should store BINARY data as a BLOB and not as text age: 39 weeks 3 days url: http://drupal.org/node/16998 Change to sesssion.inc violates UID database constraint age: 42 weeks 6 days url: http://drupal.org/node/15666 forum.module problem with postgresql v7.4.1 age: 43 weeks 4 days url: http://drupal.org/node/15411 Argument NOT must be type boolean age: 51 weeks 5 days url: http://drupal.org/node/12950 node options reverts to default upon edit -- messages and documentation needed assigned: matt westgate age: 1 year 25 weeks url: http://drupal.org/node/7940 user error: Duplicate entry assigned: Kjartan age: 1 year 49 weeks url: http://drupal.org/node/4428 / feature requests Profile fields should be controlled by roles age: 1 week 6 days url: http://drupal.org/node/35693 Module Access Control age: 2 weeks 1 day url: http://drupal.org/node/35459 Customizable module blocks age: 3 weeks 3 days url: http://drupal.org/node/34563 Filter the title to allow HTML comments age: 16 weeks 1 day url: http://drupal.org/node/27205 No obvious way to tell which release a site is running assigned: Uwe Hermann age: 30 weeks 2 days url: http://drupal.org/node/20439 moving pages en masse age: 32 weeks 2 days url: http://drupal.org/node/19754 Taxonomy module should use nodeapi 'load' age: 35 weeks 2 days url: http://drupal.org/node/18631 Auto PHP memory maximisation age: 37 weeks 4 days url: http://drupal.org/node/17663 Allow named anchors to work without specifying full path to node age: 1 year 51 weeks url: http://drupal.org/node/4213 / support requests user logins failing - cry for help age: 2 weeks 4 days url: http://drupal.org/node/35104 Password error when changing user role age: 2 weeks 6 days url: http://drupal.org/node/34933 / feature requests Events only for registered users age: 3 weeks 2 days url: http://drupal.org/node/34640 / support requests displaying event start info in flexinode tabular view? age: 5 weeks 4 days url: http://drupal.org/node/33019 Event block missing content of many fields age: 7 weeks 6 days url: http://drupal.org/node/31532 / bug reports file size bug age: 22 weeks 1 day url: http://drupal.org/node/24728 / bug reports Search results give incorrect links age: 4 weeks 6 days url: http://drupal.org/node/33539 Full screen slideshow in Gallery module is not working (erroring out on the wrong URL) age: 18 weeks 2 days url: http://drupal.org/node/26479 / support requests import existing gallery2 user account age: 1 week 4 days url: http://drupal.org/node/35920 / feature requests Goofy Forum UI age: 6 weeks 4 days url: http://drupal.org/node/32294 / bug reports only variables can be passed by reference on line 713 age: 1 week 2 days url: http://drupal.org/node/36092 image.module 4.6.0 strange actions age: 5 weeks 1 day url: http://drupal.org/node/33292 File copy failed: source file does not exist error after running update-image.php age: 7 weeks 3 days url: http://drupal.org/node/31816 Path for image folder not inserted correctly when nodetype = image age: 10 weeks 3 days url: http://drupal.org/node/30031 image module patch & image_import module age: 11 weeks 5 days url: http://drupal.org/node/29377 image module fails on dual site configuration age: 17 weeks 2 days url: http://drupal.org/node/26657 Cannot upload .jpgs age: 36 weeks 5 days url: http://drupal.org/node/18076 / feature requests Copying original age: 1 week 1 day url: http://drupal.org/node/36321 Image deletions? age: 9 weeks 3 days url: http://drupal.org/node/30557 / support requests Image Folder Permissions age: 3 weeks 14 hours url: http://drupal.org/node/34839 Images are there but not showing assigned: Stepfordtwit age: 15 weeks 2 days url: http://drupal.org/node/27615 Image Module Permissions age: 18 weeks 6 days url: http://drupal.org/node/26280 / bug reports Listhandler caused error in "comment.module on line 996" ? age: 1 week 1 day url: http://drupal.org/node/36244 Prefix column error for SQL in Listhandler admin!! age: 5 weeks 4 days url: http://drupal.org/node/33017 / tasks Correct/Complete Documentation age: 2 weeks 6 days url: http://drupal.org/node/34909 / bug reports Naming issues with files and DB tables age: 3 weeks 5 days url: http://drupal.org/node/34298 RSS "no element found at line 1" age: 19 weeks 20 hours url: http://drupal.org/node/26185 Outdated help texts age: 1 year 14 weeks url: http://drupal.org/node/9692 Import doesn't like XML/RSS feeds with no Title element age: 1 year 23 weeks url: http://drupal.org/node/8128 / tasks move XML-parser into an inclde file. age: 20 weeks 4 days url: http://drupal.org/node/25439 / feature requests Notify.module ignores the true submission queue age: 2 years 2 weeks url: http://drupal.org/node/3765 / bug reports Login as an alias gets cached age: 7 weeks 4 days url: http://drupal.org/node/31699 / bug reports Management of french charaters age: 5 days 15 hours url: http://drupal.org/node/36605 / feature requests Internationalization support for PDF assigned: TheLibrarian age: 1 year 32 weeks url: http://drupal.org/node/6795 / bug reports privatemsg not working with current head age: 8 weeks 1 hour url: http://drupal.org/node/31469 Reminder email links don't work age: 20 weeks 1 day url: http://drupal.org/node/25677 / bug reports pgsql schema age: 22 hours 36 min url: http://drupal.org/node/37258 Pass by reference error in PHP 5.0.5 age: 3 days 19 hours url: http://drupal.org/node/36866 Get disconnected from server on attempting to add an issue age: 1 week 2 days url: http://drupal.org/node/36124 can't select all projects age: 5 weeks 1 day url: http://drupal.org/node/33262 Can't update issue title from issue comment assigned: nedjo age: 5 weeks 5 days url: http://drupal.org/node/32843 Projects not listed and page not complete age: 23 weeks 4 days url: http://drupal.org/node/23956 Date for latest is incorrect age: 30 weeks 2 days url: http://drupal.org/node/20485 / feature requests Allow subscription to individual project issues age: 3 weeks 3 days url: http://drupal.org/node/34496 Implement XML-RPC functionlality for communication between drupal.org and Drupal installations age: 4 weeks 20 hours url: http://drupal.org/node/34108 / support requests Add the project release manually without the scan feature age: 3 weeks 3 days url: http://drupal.org/node/34500 / bug reports Error with URL to recipe age: 10 weeks 5 days url: http://drupal.org/node/29885 / feature requests Request to generate email for all content changes/additions, including comments age: 17 weeks 2 hours url: http://drupal.org/node/26824 / bug reports Wrong URL mask age: 2 weeks 3 days url: http://drupal.org/node/35215 / bug reports Does not work correctly in Internet Explorer age: 5 weeks 23 hours url: http://drupal.org/node/33354 Blocks switch and reset when vocabs are modified age: 26 weeks 2 days url: http://drupal.org/node/22631 javascrip downloads square.gif for every category age: 38 weeks 4 days url: http://drupal.org/node/17366 / feature requests A unique page for each category group? age: 3 weeks 2 days url: http://drupal.org/node/34610 / support requests Taxonomy has dissapeared age: 5 weeks 3 days url: http://drupal.org/node/33061 / bug reports Sends trackbacks for unpublished nodes assigned: ankur age: 41 weeks 2 days url: http://drupal.org/node/16239 / support requests Help me help myself - is trackback working? age: 4 days 8 hours url: http://drupal.org/node/36780 / feature requests A small but effective improvement to Improvement of admin/user accessability suggestion age: 4 weeks 1 day url: http://drupal.org/node/34073 / bug reports User error: Table 'db_drpl1.weblink' doesn't exist? a pain in the neck age: 3 weeks 1 day url: http://drupal.org/node/34765 From adrian at bryght.com Sat Nov 12 18:08:26 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Sat Nov 12 18:08:49 2005 Subject: [development] Files on previews In-Reply-To: <20051112152412.d0c00a1b.ber@webschuur.com> References: <1912.213.46.81.27.1131667932.squirrel@www.webschuur.com> <43740D94.9020509@walkah.net> <20051112152412.d0c00a1b.ber@webschuur.com> Message-ID: <7B48DFDE-4EF3-4BA4-BB68-2E35A3D963B4@bryght.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12 Nov 2005, at 4:24 PM, Ber Kessels wrote: > > My plan in my new system is to uplaod the image, and even insert it > in the table. if its there, if it has a uid/nid/wid (whateverid) it > is finished, finito. even if a browser crashes: its there. Create a proper 'file' form element that handles all the background stuff for you. And then a 'files' element for multiple files (ala upload) You could add an extra couple of variable to their defaults .. ie : function system_elements() { $info['file'] = array('#domain' => 'node', '#dest' => variable_get ('files_dir', ''), '#key' => $node->nid) return $info; } This would make it absolutely braindead easy to upload a file. you just add a file element in it, and you'd use either one of the common domains, or create your own. (ie: image, user, node) - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDdi+bgegMqdGlkasRAvIiAKCVeWkyVw1LppTbsoWSkODM4vkiiwCghmfM EWjGxGiIw0ulJKnOmbJQx/0= =yEQU -----END PGP SIGNATURE----- From ber at webschuur.com Sat Nov 12 18:58:12 2005 From: ber at webschuur.com (Ber Kessels) Date: Sat Nov 12 18:58:24 2005 Subject: [development] Files on previews In-Reply-To: <7B48DFDE-4EF3-4BA4-BB68-2E35A3D963B4@bryght.com> References: <1912.213.46.81.27.1131667932.squirrel@www.webschuur.com> <43740D94.9020509@walkah.net> <20051112152412.d0c00a1b.ber@webschuur.com> <7B48DFDE-4EF3-4BA4-BB68-2E35A3D963B4@bryght.com> Message-ID: <20051112195813.e95b92bd.ber@webschuur.com> Hmm, > Create a proper 'file' form element that handles all the background > stuff for you. > > And then a 'files' element for multiple files (ala upload) > > You could add an extra couple of variable to their defaults .. ie : > > function system_elements() { > $info['file'] = array('#domain' => 'node', '#dest' => variable_get > ('files_dir', ''), '#key' => $node->nid) > return $info; > } > > This would make it absolutely braindead easy to upload a file. > > you just add a file element in it, and you'd use either one of the > common domains, or create your own. (ie: image, user, node) I absolutely do not understand what you are talking about. It probably is because i don't understand the formAPI completely. Yet. But I think you misunderstood my code/plans for the file system :) Till now, I did not use the form api niftyness in my file system, so I am very happy if someone could give a hand there, and reduce some of my code/hooks by using that niftyness! Ber From adrian at bryght.com Sat Nov 12 19:41:42 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Sat Nov 12 19:42:04 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) Message-ID: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I need to preface this by saying that I don't think our current community processes are 'broken' per se, since they have obviously brought us this far, however I have noticed some areas in which there could be improvement and I would like to make some suggestions towards getting a smoother development cycle for all of us. My primary interest with this proposal is to foster co-operation, and allow us to better manage the project in the future. I feel that one of the primary problems we have is that there is not enough co-operation between different developers, and I feel that this problem stems from lack of communication. Up to this point, communication has been strictly informal. This has the benefit of not tying up people doing ground work, and is essentially an extension of our 'talk is silver, code is gold' mantra. And this is great. Good working code is our primary goal, and it has suited our goals up to this point perfectly. The problem with this however is, that it does not scale. With one, or even two people on the project it might work, but the moment you get more than that involved, communication becomes a lot more work than it should be. The other problem is that communication on projects like these tend to be on a personal level, and the only way to get more developers involved in the project is either through direct requests, or constant badgering on the forums/irc. Even if you do get someone else interested, getting that person up to date on the goals and status of the project , and to become a contributing member is still a lot of work. Also, the only way for an external developer to become involved in such an on-going project is to search the forums, find people who might even be remotely interested in the same thing, go talk to people on irc, see if anything is being done in whichever direction they intend to work in. It's a lot of work, and most developers don't bother. They end up re-inventing the wheel, because it's really hard for them to get accurate information about what's going on in the Drupal community. What I would like to suggest, is that we introduce a proposal system, whereby we create an official proposal document for any large changes we undertake as a community. This process would be modelled on the jabber.org JEP process, which in turn is modelled on the IETF process. What we would essentially do is create a document, that has an official number, a status and an owner. This document would be modelled on JEPs (http://www.jabber.org/jeps/jep-0143.html), and would explain the basic goals of the project, reasoning behind it, requirements, security considerations and so forth. How I imagine the basic workflow would be, is that someone writes a proposal, in the correct format, that gets published as a draft. At a certain point the draft then gets sent to drupal-devel, and developer comments are factored in. Then it gets published on Drupal.org, and user comments get factored in. At this point, we have a proposed DEP, and anyone who has any interest in working towards that knows what has been decided to be the best approach, who is working on it, and what is the status of it. Another thing that led me to this conclusion, was the recent discussion about the formation of the 'theme team', which I felt was not actually aligned with our goals. We already have a theme forum, which doesn't see much action, since I think the informal communication has proven to not be adequate. What the proposal structure would do, is allow us to create SIG's (special interest groups), whose purpose would be to foster discussion, and create proposals with a certain goal in mind (ie: theme sig, usability sig, localisation sig, etc.) Benefits : For Developers : Lessens duplicated efforts. Has a summary of the current status of things. Allows us to collaboratively map out what we are working towards. It's an actual spec, and although there is such a thing as feature creep, at least we know when it's 'done' For Documentation : Provides reference information for the design and implementation of features. For End Users : A more transparent view of where we are heading, what changes we are making and why. More eyes, which might bring up more issues, helping the design along. Get them more involved with the project, without having to wade through the forums. For Investors : Allows investors to see projects within the community and financially support the right people towards meeting their goals. Creates a common process to interface commercial and community developers with each other. Reverse bounties. For Dries : Allows for more accurate roadmaps. (ie: DEPs 0341 and 0342 are destined to be in the next release) Knowing the status of things. For all of us : Gives us a better map of people's interests. More visibility to what you are busy doing, and it might make you some money. One thing I should say, is that I am not trying to stop us from developing the way we are now, it's not broken, i'm not trying to fix it. What I am saying is that we could make this more formal path available, to allow us to collaborate more effectively on things. I am also not trying to bog down what we do. Implementing for now could simply be a book page that we maintain as we are involved in the project. I have some ideas in the future to expand the integration in a meaningful way, but that's probably a topic for a DEP of it's own. Just because we are documenting what we are doing, doesn't mean we can't write code while we're doing it. We're obviously going to have times when we have a couple of different implimentations of the same thing competing with each other, provided they are different enough approaches... but that's healthy. I am also not saying that we will get this right the first time, but what I propose is that we set up such a process and then create a DEP 0001 which is the dep handling the community process, and after every release we review it again and make revisions based on what worked and what didn't. I really feel that if we decide on a method we need to stick with it for a while though. So these are some of my thoughts, and I would love to have the community's opinion on the idea. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDdkV3gegMqdGlkasRAr+aAKCoGKZ8hnqtqDm658DJBX5USTQ0fgCeI1tw rY2I2L6dSV6MBGuO767Jazk= =Z4mD -----END PGP SIGNATURE----- From nedjo at islandnet.com Sat Nov 12 19:57:34 2005 From: nedjo at islandnet.com (Nedjo Rogers) Date: Sat Nov 12 19:58:51 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> Message-ID: <001d01c5e7c3$52ff4ff0$6400a8c0@family> Thanks Adrian for putting forward this well considered proposal. I support the idea of introducing a formalized process for presenting and working through major proposed enhancements. I personally find it challenging to keep abreast of the various proposals that are working their way through our current processes, proposals that often are scattered among various email discussions, project issues, forum discussions, etc. Formalized presentation in a predictable place, with revisions so it's clear what's current, designated status, etc., sounds really great to me. From gerhard at killesreiter.de Sat Nov 12 20:32:03 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Sat Nov 12 20:33:08 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> Message-ID: <43765143.90802@killesreiter.de> Adrian Rossouw wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I need to preface this by saying that I don't think our current > community processes are 'broken' per se, since they have > obviously brought us this far, however I have noticed some areas in > which there could be improvement and I would like > to make some suggestions towards getting a smoother development cycle > for all of us. My primary interest with this > proposal is to foster co-operation, and allow us to better manage the > project in the future. We could start by setting the number of characters per line to 80, or a bit less. :p > I feel that one of the primary problems we have is that there is not > enough co-operation between different developers, > and I feel that this problem stems from lack of communication. Up to > this point, communication has been strictly > informal. This has the benefit of not tying up people doing ground > work, and is essentially an extension of our > 'talk is silver, code is gold' mantra. And this is great. Good > working code is our primary goal, and it has suited > our goals up to this point perfectly. > > The problem with this however is, that it does not scale. With one, > or even two people on the project it might work, but the > moment you get more than that involved, communication becomes a lot > more work than it should be. I don't find that the communication is a burden yet. The number of people to communicate with on a given topic is still small. > The other problem is that communication on projects like these tend > to be on a personal level, and the only way > to get more developers involved in the project is either through > direct requests, or constant badgering on the forums/irc. That is true. And even then it mostly fails. Why? Because everybody has his pet issues with Drupal. That is not a bad thing, because it ensures that things get pushed by some individuals. To get other individuals to join them in their effort is a very difficult thing to do, as I can tell you from several years of experience. And frankly, I don't see this changing. > Even if you do get someone else interested, getting that person up to > date on the goals and status of the project , and to become a > contributing > member is still a lot of work. Also, the only way for an external > developer to become involved in such an on-going project is > to search the forums, find people who might even be remotely > interested in the same thing, go talk to people on irc, see if anything > is being done in whichever direction they intend to work in. It's a > lot of work, and most developers don't bother. They end up > re-inventing the wheel, because it's really hard for them to get > accurate information about what's going on in the Drupal community. I disagree. Once some code comes forward there usually is some issue created and all you need to do is read the contained information. People who are not willign to do that won't read lenghty proposals either. > What I would like to suggest, is that we introduce a proposal system, > whereby we create an official proposal document for > any large changes we undertake as a community. This process would be > modelled on the jabber.org JEP process, which > in turn is modelled on the IETF process. > > What we would essentially do is create a document, that has an > official number, a status and an owner. This document > would be modelled on JEPs (http://www.jabber.org/jeps/jep-0143.html), > and would explain the basic goals of the project, > reasoning behind it, requirements, security considerations and so forth. It would have helped to convince me if you had chosen an example of less intimidating length and complexity. But I guess you didn't. :p Cheers, Gerhard From jareyero at wanadoo.es Sat Nov 12 21:54:44 2005 From: jareyero at wanadoo.es (Jose A. Reyero) Date: Sat Nov 12 21:55:01 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> Message-ID: <437664A4.8000101@wanadoo.es> Completely agree with Adrian. We do need this. Only I would ask that this formal proccess doesn't mean too much administrative overhead for every new project. So, basically, a new section to know other people's 'big plans' and see easily 'who's working on what' would do. If we have one html page for each project and one 'coordinator' that maintains that page, keeps a list of related queued patches, and the people involved, that would be a good start point. For the rest, the patch queue and the forum will do. One of the main problems I see with the patch queue is that it's not practical at all when trying to get big patches in. The work it takes to have the patch up to date with HEAD, while people is reviewing it is really overwhelming. So what if we took some snapshot of the core as the starting point for each of this projects, and once the code has been reviewed and polished enough by the people involved in that particular project, we update it for head once as 'ready to be committed', and... ? Cheers, Jose From adrinux at gmail.com Sat Nov 12 22:09:30 2005 From: adrinux at gmail.com (Adrian Simmons) Date: Sat Nov 12 22:09:37 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <437664A4.8000101@wanadoo.es> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> <437664A4.8000101@wanadoo.es> Message-ID: <4376681A.8050106@gmail.com> Jose A. Reyero wrote: > Completely agree with Adrian. We do need this. Me too. > The work it takes to > have the patch up to date with HEAD, while people is reviewing it is > really overwhelming. What Adrian is suggesting is facilitating better collaboration, helping to spread the work of making big changes. > So what if we took some snapshot of the core Sounds like just as much work, just in a different order. A more structured approach to making big changes should allow for agreement on what would likely go into core prior to the code being completed, it should help shorten the review process. With that and better collaboration 'chasing HEAD'* should be less of a problem. * (you at the back, stop sniggering) -- adrinux (aka Adrian Simmons) e-mail AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com From drewish at katherinehouse.com Sat Nov 12 22:36:58 2005 From: drewish at katherinehouse.com (andrew morton) Date: Sat Nov 12 22:37:00 2005 Subject: [development] Files on previews In-Reply-To: <20051112195813.e95b92bd.ber@webschuur.com> References: <1912.213.46.81.27.1131667932.squirrel@www.webschuur.com> <43740D94.9020509@walkah.net> <20051112152412.d0c00a1b.ber@webschuur.com> <7B48DFDE-4EF3-4BA4-BB68-2E35A3D963B4@bryght.com> <20051112195813.e95b92bd.ber@webschuur.com> Message-ID: On 11/12/05, Ber Kessels wrote: > I absolutely do not understand what you are talking about. It probably is because i don't understand the formAPI completely. Yet. But I think you misunderstood my code/plans for the file system :) > Till now, I did not use the form api niftyness in my file system, so I am very happy if someone could give a hand there, and reduce some of my code/hooks by using that niftyness! > > Ber I'm not any kind of Forms ninja, but I think I've got a reasonable understanding of it. Please let me know what I can do to help you with it. andrew From adrian at bryght.com Sat Nov 12 22:41:39 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Sat Nov 12 22:46:11 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <437664A4.8000101@wanadoo.es> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> <437664A4.8000101@wanadoo.es> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12 Nov 2005, at 11:54 PM, Jose A. Reyero wrote: > Completely agree with Adrian. We do need this. > > Only I would ask that this formal proccess doesn't mean too much > administrative overhead for every new project. So, basically, a new > section to know other people's 'big plans' and see easily 'who's > working > on what' would do. If we have one html page for each project and one > 'coordinator' that maintains that page, keeps a list of related queued > patches, and the people involved, that would be a good start point. > For > the rest, the patch queue and the forum will do. Exactly. I don't want us to be designing software around this. > > One of the main problems I see with the patch queue is that it's not > practical at all when trying to get big patches in. This is the other thing DEPs do, they split big patches into seperate tasks, each with their own ticket. Or atleast, theoretically. > The work it takes to > have the patch up to date with HEAD, while people is reviewing it is > really overwhelming. This is why i want to move to supplying subversion repositories for each of the large projects. It worked great with Forms. But now we're getting too deep into future architecture development again. > So what if we took some snapshot of the core as the > starting point for each of this projects, and once the code has been > reviewed and polished enough by the people involved in that particular > project, we update it for head once as 'ready to be committed', > and... ? That's why you have a seperate repository. =) - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDdm+kgegMqdGlkasRAoj7AJ4sIiZQKuZuvWwSqncELsn7OInafwCgwDY4 Tegd866gXPJdct7Z1WlcFJE= =v547 -----END PGP SIGNATURE----- From adrian at bryght.com Sat Nov 12 23:03:48 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Sat Nov 12 23:04:22 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <43765143.90802@killesreiter.de> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> <43765143.90802@killesreiter.de> Message-ID: <120ED9B6-C4CC-4746-8C41-A957F26204B1@bryght.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12 Nov 2005, at 10:32 PM, Gerhard Killesreiter wrote: > That is true. And even then it mostly fails. Why? Because everybody > has his pet issues with Drupal. That is not a bad thing, because it > ensures that things get pushed by some individuals. To get other > individuals to join them in their effort is a very difficult thing > to do, as I can tell you from several years of experience. And > frankly, I don't see this changing. Because people don't know what they are getting themselves into. Take for example all the people working on the relationship system. Would they have started working together were it not for that issue ? How easy is it to get to the conclusion of that thread and know exactly where development is now. How do you know what still needs to be done. How do you know who's involved without taking mental inventory. > I disagree. Once some code comes forward there usually is some > issue created and all you need to do is read the contained > information. People who are not willign to do that won't read > lenghty proposals either. But the person who wants to fund development in this direction might not be able to read those threads as easily, but be willing to pay people who know what they want to implement and why , actual cash money. > It would have helped to convince me if you had chosen an example of > less intimidating length and complexity. I'm going to be writing some proposals myself once I've nailed down to what I believe the format should be. The first one is going to be about the crazy idea I had for the variable_set function yesterday. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDdnTUgegMqdGlkasRAtmqAKDRXtCl5xX0xPSBwZCpe3Mpmjj6JgCgjRz5 cA6Gk/5vqbXHADI/x4886v0= =JFr5 -----END PGP SIGNATURE----- From herman.webley at gmail.com Sun Nov 13 00:08:31 2005 From: herman.webley at gmail.com (Herman Webley) Date: Sun Nov 13 00:08:33 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <120ED9B6-C4CC-4746-8C41-A957F26204B1@bryght.com> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> <43765143.90802@killesreiter.de> <120ED9B6-C4CC-4746-8C41-A957F26204B1@bryght.com> Message-ID: +1 on the DEP idea On 11/12/05, Adrian Rossouw wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 12 Nov 2005, at 10:32 PM, Gerhard Killesreiter wrote: > > That is true. And even then it mostly fails. Why? Because everybody > > has his pet issues with Drupal. That is not a bad thing, because it > > ensures that things get pushed by some individuals. To get other > > individuals to join them in their effort is a very difficult thing > > to do, as I can tell you from several years of experience. And > > frankly, I don't see this changing. > Because people don't know what they are getting themselves into. Take > for example all the people working on the relationship system. > Would they have started working together were it not for that issue ? > > How easy is it to get to the conclusion of that thread and know > exactly where development is now. How do you know what still needs to > be done. > How do you know who's involved without taking mental inventory. > > > > I disagree. Once some code comes forward there usually is some > > issue created and all you need to do is read the contained > > information. People who are not willign to do that won't read > > lenghty proposals either. > But the person who wants to fund development in this direction might > not be able to read those threads as easily, but be willing to pay > people > who know what they want to implement and why , actual cash money. > > > It would have helped to convince me if you had chosen an example of > > less intimidating length and complexity. > I'm going to be writing some proposals myself once I've nailed down > to what I believe the format should be. > The first one is going to be about the crazy idea I had for the > variable_set function yesterday. > > - -- > Adrian Rossouw > Drupal developer and Bryght Guy > http://drupal.org | http://bryght.com > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (Darwin) > > iD8DBQFDdnTUgegMqdGlkasRAtmqAKDRXtCl5xX0xPSBwZCpe3Mpmjj6JgCgjRz5 > cA6Gk/5vqbXHADI/x4886v0= > =JFr5 > -----END PGP SIGNATURE----- > -- Best regards, Herman Webley From weitzman at tejasa.com Sun Nov 13 00:28:09 2005 From: weitzman at tejasa.com (Moshe Weitzman) Date: Sun Nov 13 00:28:10 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> Message-ID: <43768899.3030409@tejasa.com> I support this. It's time. The devel list is becoming less and less useful every week. We need a way to collaborate on architecture without all that "+1" and "path alias" bickering. From drupal.org at juggernaut.com.au Sun Nov 13 01:29:54 2005 From: drupal.org at juggernaut.com.au (Richard Archer) Date: Sun Nov 13 01:29:30 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> Message-ID: At 9:41 PM +0200 12/11/05, Adrian Rossouw wrote: >What we would essentially do is create a document, that has an >official number, a status and an owner. This document >would be modelled on JEPs (http://www.jabber.org/jeps/jep-0143.html), >and would explain the basic goals of the project, >reasoning behind it, requirements, security considerations and so forth. The JEP structure looks pretty heavy handed. It might also be worth considering some of the features of PEPs. http://www.python.org/peps/pep-0001.html ...R. From neil at civicspacelabs.org Sat Nov 12 07:50:32 2005 From: neil at civicspacelabs.org (neil@civicspacelabs.org) Date: Sun Nov 13 02:06:58 2005 Subject: [development] Do I need to upgrade my database? In-Reply-To: <10344940-C08A-4E43-8DE7-A8C4EB25265B@ericscouten.com> References: <7E33C034-ACC7-41C2-A754-201B41BC19C7@civicspacelabs.org> <10344940-C08A-4E43-8DE7-A8C4EB25265B@ericscouten.com> Message-ID: <20051112075032.GA31366@localhost> On Fri, Nov 11, 2005 at 09:45:56PM -0800, Eric Scouten wrote: > Speaking of such, I think there may be a lurking problem with the > 4.6.x (where x>0) to 4.7 upgrade. > > IIRC, the mechanism for determining what updates need to be applied > is a string >= comparison on the date of the update. > > The last update for 4.6.0 was "2005-03-21" (I think). Since then, > there have been a number of updates in the 4.6.x trunk and a > different sequence of updates in the 4.7 trunk. I think this creates > the risk that some of the 4.7 upgrades (i.e. those with dates <= the > 4.6.x upgrades) will get skipped. > > Has anyone verified that the 4.6.x -> 4.7 upgrade does in fact get > all of the 4.7 schema updates? I can't; I just don't have time to > spend on Drupal until well after the 4.7 release. I noticed this and provided a workaround in my giant update patch [1]. 1. http://drupal.org/node/35924 -Neil From linux-tw at masquilier.org Sun Nov 13 03:07:44 2005 From: linux-tw at masquilier.org (Anguo) Date: Sun Nov 13 03:05:58 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <4376681A.8050106@gmail.com> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> <437664A4.8000101@wanadoo.es> <4376681A.8050106@gmail.com> Message-ID: <200511131107.44560.linux-tw@masquilier.org> On Sunday 13 November 2005 06:09 am, Adrian Simmons wrote: > * (you at the back, stop sniggering) I didn't say anything! I was just thinking that this might be a good idea. A. -- http://www.wechange.org/ Because we and the world need to change. http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple. http://www.gnosis-usa.com/ Revolutionary Psychology, White Tantrism, Dream Yoga... http://www.masquilier.org/ Condorcet, Approval alternative, better voting methods. From puregin at puregin.org Sun Nov 13 10:01:46 2005 From: puregin at puregin.org (puregin) Date: Sun Nov 13 10:02:18 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <200511131107.44560.linux-tw@masquilier.org> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> <437664A4.8000101@wanadoo.es> <4376681A.8050106@gmail.com> <200511131107.44560.linux-tw@masquilier.org> Message-ID: <42A585E9-9C6E-4FC3-BD2C-5C7C3C38459D@puregin.org> I like Adrian's idea of formalizing the development communications process for Core. The 'Issues' mechanism is suited for small and focused changes, but not really appropriate for large scale changes that cut across many modules / projects and/or have significant API changes. Discussions on a mailing list or IRC are ephemeral and/or divergent - it's hard to go to a single source for history, status, and proposed changes. I think that the proposed DEP process (though it will involve more overhead) will make teams and projects visible and accountable, and enable ownership of projects. It may also help to define roles for participants who might be willing but feeling that they don't know where to jump in. Djun From ber at webschuur.com Sun Nov 13 11:21:54 2005 From: ber at webschuur.com (Ber Kessels) Date: Sun Nov 13 11:22:01 2005 Subject: [development] FYI more drupal.css stuff Message-ID: <20051113122154.96c06772.ber@webschuur.com> NOTE: this is talk, not code! I ran drupal.css trough http://cdburnerxp.se/cssparse/css_optimiser.php a great tool. And it compressed drupal.css up to ~30% (unreadable CSS). But the standard, readable version compresses it still 23%! That is 2632 Bytes less for every uncached pageview. I certainly will use this tool on my server. But it could also ship the compressed one by default with drupal, not? It would mean that we have an unreadable drupal.css (but who reads it anyway :P) but that we can save some bandwith. Ber From jareyero at wanadoo.es Sun Nov 13 11:33:32 2005 From: jareyero at wanadoo.es (Jose A. Reyero) Date: Sun Nov 13 11:33:56 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> <437664A4.8000101@wanadoo.es> Message-ID: <4377248C.6020906@wanadoo.es> Adrian Rossouw wrote: > > > >> So what if we took some snapshot of the core as the > >> starting point for each of this projects, and once the code has been > >> reviewed and polished enough by the people involved in that particular > >> project, we update it for head once as 'ready to be committed', > and... ? > > > That's why you have a seperate repository. =) > Right after sending the email I realised that what I was describing is already invented and is called 'branches' :-) We don't really need a separate repository for each of these projects, but the ability to create branches. Maybe if it's not practical to have too many branches in the main repository -I don't know too much about cvs administration and permissions-, we could have a new repository -better svn-, in which we mirror the main one, and have a more relaxed commit policy, and the ability to create branches. Actually I could keep a branch -kind of- in a folder in my sandbox. Only I don't know whether it will be too much for the current cvs repository if we all start to create our own branches like that. From ber at webschuur.com Sun Nov 13 12:31:04 2005 From: ber at webschuur.com (Ber Kessels) Date: Sun Nov 13 12:31:11 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <43768899.3030409@tejasa.com> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> <43768899.3030409@tejasa.com> Message-ID: <20051113133104.53f0d25e.ber@webschuur.com> On Sat, 12 Nov 2005 19:28:09 -0500 Moshe Weitzman wrote: > > I support this. It's time. The devel list is becoming less and less useful > every week. We need a way to collaborate on architecture without all that > "+1" and "path alias" bickering. +1 on this DEP evil grin And here is how we work currently: I use wiki (freelinking+books) and http://www.webschuur.com/node/272 this simple template. The first two h3s are for the client. The rest for me/the techies. Once that page grows big, I make it into subpages. The fist two paragraphs also serve as (starter of) end user help. It has proven to work very well! Yet is far less (yes) administrative overhead then maintaining issue-threads and patches. (Its our think first do later philosofy) Ber -- B?r Kessels Drupal services bler.webschuur.com www.webschuur.com ber@jabber.webschuur.com From jareyero at wanadoo.es Sun Nov 13 12:59:18 2005 From: jareyero at wanadoo.es (Jose A. Reyero) Date: Sun Nov 13 12:59:36 2005 Subject: [development] FYI more drupal.css stuff In-Reply-To: <20051113122154.96c06772.ber@webschuur.com> References: <20051113122154.96c06772.ber@webschuur.com> Message-ID: <437738A6.60704@wanadoo.es> Ber Kessels wrote: >NOTE: this is talk, not code! > >I ran drupal.css trough http://cdburnerxp.se/cssparse/css_optimiser.php a great tool. And it compressed drupal.css up to ~30% (unreadable CSS). But the standard, readable version compresses it still 23%! >That is 2632 Bytes less for every uncached pageview. I certainly will use this tool on my server. > > > Not really. I think stylesheets are usually cached by the browser, and they're not reloaded unless you click on 'reload page' >But it could also ship the compressed one by default with drupal, not? It would mean that we have an unreadable drupal.css (but who reads it anyway :P) but that we can save some bandwith. > > I really prefer working with the actual file that is being used. If we want to compress something, better strip out all that php comments that are parsed for every page :-) About css's, as they can be always overridden by the theme, you can try to merge all of them together in an optimized one for your production sites -all that css element's overriding is what actually takes time when rendering the pages... From ber at webschuur.com Sun Nov 13 14:33:33 2005 From: ber at webschuur.com (Ber Kessels) Date: Sun Nov 13 14:33:39 2005 Subject: forms api for files system (was: Re: [development] Files on previews) In-Reply-To: References: <1912.213.46.81.27.1131667932.squirrel@www.webschuur.com> <43740D94.9020509@walkah.net> <20051112152412.d0c00a1b.ber@webschuur.com> <7B48DFDE-4EF3-4BA4-BB68-2E35A3D963B4@bryght.com> <20051112195813.e95b92bd.ber@webschuur.com> Message-ID: <20051113153333.283f1f48.ber@webschuur.com> On Sat, 12 Nov 2005 14:36:58 -0800 andrew morton wrote: > I'm not any kind of Forms ninja, but I think I've got a reasonable > understanding of it. Please let me know what I can do to help you with > it. In a nutshell: I introduced a fileapi system, nearly a 1-to-1 clone of nodapi, only then for any file object. It reacts on "save", "validate", etc. And it also reacts on "form". That hook_fileapi($file, 'form', $form) should return a form array, as well as that it passes along the existing form array. In that way modules can alter the form for a file. Anywhere. For example to turn a certain file form into a list of file forms (to allow uploading more then one file at once). Or to change a title or description. Or to remove something from the form. I am confident that all this no longer needs a hook, since the formapi has its own "override" system. I think that one form of type "upload", will suffice. That type should: * have automatically the javascript/ajax stuff with it. * be called anywhere a module wants to call it. * invoke the correct fileapi actions. Regards, B?r -- B?r Kessels Drupal services bler.webschuur.com www.webschuur.com ber@jabber.webschuur.com From ber at webschuur.com Sun Nov 13 14:42:17 2005 From: ber at webschuur.com (Ber Kessels) Date: Sun Nov 13 14:42:23 2005 Subject: [development] FYI more drupal.css stuff In-Reply-To: <437738A6.60704@wanadoo.es> References: <20051113122154.96c06772.ber@webschuur.com> <437738A6.60704@wanadoo.es> Message-ID: <20051113154217.4189a17d.ber@webschuur.com> On Sun, 13 Nov 2005 13:59:18 +0100 "Jose A. Reyero" wrote: > >That is 2632 Bytes less for every uncached pageview. I certainly will use this tool on my server. > Not really. I think stylesheets are usually cached by the browser, and > they're not reloaded unless you click on 'reload page' On my servers i have ~20% recurring visits and ~80% one-time visits. So for me it would save 30%80% = 24%. Or, less mathematical: on my server drupal.css is the #5 of biggest bw eating urls. It will save BW in my case. -- B?r Kessels Drupal services bler.webschuur.com www.webschuur.com ber@jabber.webschuur.com From adrinux at gmail.com Sun Nov 13 14:42:18 2005 From: adrinux at gmail.com (Adrian Simmons) Date: Sun Nov 13 14:42:24 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <4377248C.6020906@wanadoo.es> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> <437664A4.8000101@wanadoo.es> <4377248C.6020906@wanadoo.es> Message-ID: <437750CA.60208@gmail.com> Jose A. Reyero wrote: > We don't really need a separate repository for each of these projects, > but the ability to create branches. If we were using SVN, maybe - but right now using a seperate repository allows the use of SVN instead of CVS :) That's more than just SVN is better than CVS ranting, in the early stages of projects where files often get renamed 'svn rename filename' is a lot easier than CVS. But point taken. Branches can be merged. Then again I guess you could have a vendor branch in the separate SVN repository and merge with that before creating the final patch. -- adrinux (aka Adrian Simmons) e-mail AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com From piotr at mallorn.ii.uj.edu.pl Sun Nov 13 14:48:03 2005 From: piotr at mallorn.ii.uj.edu.pl (Piotr Krukowiecki) Date: Sun Nov 13 14:48:05 2005 Subject: [development] FYI more drupal.css stuff In-Reply-To: <20051113154217.4189a17d.ber@webschuur.com> References: <20051113122154.96c06772.ber@webschuur.com> <437738A6.60704@wanadoo.es> <20051113154217.4189a17d.ber@webschuur.com> Message-ID: <20051113144803.GA2299@mallorn.ii.uj.edu.pl> On Sun, Nov 13, 2005 at 03:42:17PM +0100, Ber Kessels wrote: > On Sun, 13 Nov 2005 13:59:18 +0100 > "Jose A. Reyero" wrote: > > > >That is 2632 Bytes less for every uncached pageview. I certainly will use this tool on my server. > > Not really. I think stylesheets are usually cached by the browser, and > > they're not reloaded unless you click on 'reload page' > > On my servers i have ~20% recurring visits and ~80% one-time visits. So for me it would save 30%80% = 24%. > > Or, less mathematical: on my server drupal.css is the #5 of biggest bw eating urls. It will save BW in my case. Can we have some concrete numbers? How many KB is drupal.css and how many is everything else? -- Piotrek irc: #debian.pl Mors Drosophilis melanogastribus! From ber at webschuur.com Sun Nov 13 15:20:35 2005 From: ber at webschuur.com (Ber Kessels) Date: Sun Nov 13 15:20:39 2005 Subject: [development] FYI more drupal.css stuff In-Reply-To: <20051113144803.GA2299@mallorn.ii.uj.edu.pl> References: <20051113122154.96c06772.ber@webschuur.com> <437738A6.60704@wanadoo.es> <20051113154217.4189a17d.ber@webschuur.com> <20051113144803.GA2299@mallorn.ii.uj.edu.pl> Message-ID: <20051113162035.169f15c7.ber@webschuur.com> On Sun, 13 Nov 2005 15:48:03 +0100 piotr@mallorn.ii.uj.edu.pl (Piotr Krukowiecki) wrote: > Can we have some concrete numbers? How many KB is drupal.css and how I dont have any, unfortunately. I only use webalizer in various different configurations. Just some common sense brought me the conclusion that it is my 5th biggest BW eater. Reason is: * it is available on most sites. (logo.png is different on every site, though the combined logos eat much more bw. pngcrush already helped reducing BW a lot!) * it is called on every page. While the BW for serving content of every page differs per page. * some my themes are so lightweight, that drupal.css is larger then the HTML+style.css together. I not proposing to do this for core, merely asking how interested people are in this. I am only giving this info, for others that might be interested. And for those who might want to work on drupal.css in future to consider. Too much has been said about that drupal.css already :p. -- B?r Kessels Drupal services bler.webschuur.com www.webschuur.com ber@jabber.webschuur.com From kb at 2bits.com Sun Nov 13 15:27:21 2005 From: kb at 2bits.com (Khalid B) Date: Sun Nov 13 15:27:24 2005 Subject: [development] FYI more drupal.css stuff In-Reply-To: <20051113154217.4189a17d.ber@webschuur.com> References: <20051113122154.96c06772.ber@webschuur.com> <437738A6.60704@wanadoo.es> <20051113154217.4189a17d.ber@webschuur.com> Message-ID: <4a9fdc630511130727n3bb343dfse5b2119fd4222076@mail.gmail.com> > On my servers i have ~20% recurring visits and ~80% one-time visits. So for me it > would save 30%80% = 24%. This is something that I observed a long time ago. CSS is often a large part of my web sites' bandwidth usage. I wrote about that One site has .css files taking 10.5 % of the hits, yet 19.6 % of the bandwidth. Another site with a different theme has .css as 11 % of hits, and 13.6 % of bandwidth. That site has more css that the first one, since it uses event module which emits its own css. Both sites have the css compressed, although I remember the latter one having an issue with the compressed version, so I reverted back to the normal version. I forgot about drupal.css. I will compress that next, and copy it. Thanks Piotr for the reminder. From allie at pajunas.com Sun Nov 13 15:51:47 2005 From: allie at pajunas.com (Allie Micka) Date: Sun Nov 13 15:51:55 2005 Subject: [development] FYI more drupal.css stuff In-Reply-To: <20051113162035.169f15c7.ber@webschuur.com> References: <20051113122154.96c06772.ber@webschuur.com> <437738A6.60704@wanadoo.es> <20051113154217.4189a17d.ber@webschuur.com> <20051113144803.GA2299@mallorn.ii.uj.edu.pl> <20051113162035.169f15c7.ber@webschuur.com> Message-ID: <93560955-B9C0-4416-8C19-94FD3AADB137@pajunas.com> On Nov 13, 2005, at 9:20 AM, Ber Kessels wrote: > I dont have any, unfortunately. I only use webalizer in various > different configurations. Just some common sense brought me the > conclusion that it is my 5th biggest BW eater. Reason is: > it is available on most sites. (logo.png is different on every > site, though the combined logos eat much more bw. pngcrush already > helped reducing BW a lot!) > * it is called on every page. While the BW for serving content of > every page differs per page. > * some my themes are so lightweight, that drupal.css is larger then > the HTML+style.css together. That's anecdotal information, not the hard numbers required to make an informed decision. As someone attempted to point out, browsers cache css files and will only request them once per visit. You will see in your web logs that some drupal.css requests return a 200 status and the entire file, and some return a 304 "not modified" status and 0 bytes (plus HTTP headers) The common sense way to determine a file's usage is to grep it out of your web logs. To get a list of the number of times it has requested accessed: grep drupal.css your_log_file | wc -l In my case that was 298 hits out of 3565 ( cat your_log_file | wc -l) To get a list of the number of times it's actually been downloaded: grep drupal.css your_log_file | grep 'HTTP/1.1" 200' | wc -l In my case that was 119. So, in 3565 hits (~150MB according to my stats), drupal.css has been requested 298 times and downloaded 119 times, using roughly 1MB of traffic (9315b * 119) I agree that a 9k css file borders on unreasonable, and I'm sure your mileage varies (more than 1% but less than 24%). Here are two non- drupal solutions you can effect: 1) Install mod_gzip (apache 1.3) or mod_deflate (2.0) to gzip your content. You will save 30-70% on any text file it is configured to handle. 2) If you can't access your server's configuration and care more about bandwidth than cpu, have php handle .css files and use its gzip output handler. Allie Micka pajunas interactive, inc. http://www.pajunas.com scalable web hosting and open source strategies From kb at 2bits.com Sun Nov 13 16:01:20 2005 From: kb at 2bits.com (Khalid B) Date: Sun Nov 13 16:01:22 2005 Subject: [development] FYI more drupal.css stuff In-Reply-To: <4a9fdc630511130727n3bb343dfse5b2119fd4222076@mail.gmail.com> References: <20051113122154.96c06772.ber@webschuur.com> <437738A6.60704@wanadoo.es> <20051113154217.4189a17d.ber@webschuur.com> <4a9fdc630511130727n3bb343dfse5b2119fd4222076@mail.gmail.com> Message-ID: <4a9fdc630511130801w3ba11916t52d9f84a6e411c20@mail.gmail.com> > Can we have some concrete numbers? How many KB is drupal.css and how > many is everything else? Here is my case: drupal.css is 9315 in all cases (4.6.3). First site Before compression: 13254 After compression: 11547 Second site: No compression: 12180 (This confirms that I had to undo the compression for some CSS issue). On 11/13/05, Khalid B wrote: > > On my servers i have ~20% recurring visits and ~80% one-time visits. So for me it > > would save 30%80% = 24%. > > This is something that I observed a long time ago. CSS is often a > large part of my > web sites' bandwidth usage. I wrote about that > > One site has .css files taking 10.5 % of the hits, yet 19.6 % of the bandwidth. > > Another site with a different theme has .css as 11 % of hits, and 13.6 > % of bandwidth. That site has more css that the first one, since it > uses event module which emits its own css. > > Both sites have the css compressed, although I remember the latter one > having an issue with the compressed version, so I reverted back to the > normal version. > > I forgot about drupal.css. I will compress that next, and copy it. > Thanks Piotr for the reminder. > From kb at 2bits.com Sun Nov 13 16:13:20 2005 From: kb at 2bits.com (Khalid B) Date: Sun Nov 13 16:13:22 2005 Subject: [development] FYI more drupal.css stuff In-Reply-To: <20051113162035.169f15c7.ber@webschuur.com> References: <20051113122154.96c06772.ber@webschuur.com> <437738A6.60704@wanadoo.es> <20051113154217.4189a17d.ber@webschuur.com> <20051113144803.GA2299@mallorn.ii.uj.edu.pl> <20051113162035.169f15c7.ber@webschuur.com> Message-ID: <4a9fdc630511130813t18f73a9en514897cb51590bc4@mail.gmail.com> > I dont have any, unfortunately. I only use webalizer in various different configurations. > Just some common sense brought me the conclusion that it is my 5th biggest > BW eater. Actually, my statistics were from Awstats. Webalizer is more granular: For October, site 1: Hits KB 4.82% 7.53% /misc/drupal.css 2.66% 5.21% /sites/default/themes/blah/style.css Site 2: Hits KB 3.67% 3.84% /misc/drupal.css 1.99% 2.77% /sites/default/themes/blah/style.css So, you can see that drupal.css is more of a contributer. > I not proposing to do this for core, merely asking how interested people are in this. > I am only giving this info, for others that might be interested. And for those who > might want to work on drupal.css in future to consider. Too much has been said > about that drupal.css already :p. I think that drupal.css can easily be overridden now in themes with no code changes? Am I correct? From drupal.org at juggernaut.com.au Sun Nov 13 19:21:14 2005 From: drupal.org at juggernaut.com.au (Richard Archer) Date: Sun Nov 13 19:23:04 2005 Subject: [development] FYI more drupal.css stuff In-Reply-To: <93560955-B9C0-4416-8C19-94FD3AADB137@pajunas.com> References: <20051113122154.96c06772.ber@webschuur.com> <437738A6.60704@wanadoo.es> <20051113154217.4189a17d.ber@webschuur.com> <20051113144803.GA2299@mallorn.ii.uj.edu.pl> <20051113162035.169f15c7.ber@webschuur.com> <93560955-B9C0-4416-8C19-94FD3AADB137@pajunas.com> Message-ID: At 9:51 AM -0600 13/11/05, Allie Micka wrote: >1) Install mod_gzip (apache 1.3) or mod_deflate (2.0) to gzip your >content. You will save 30-70% on any text file it is configured to >handle. If you're going to do that you will have to configure it to only compress .css files. If you compress all files being served you will double-compress pages generated by Drupal because they are already gzipped. That's probably why people are seeing so many bytes of .css being served compared with pages... pages are gzipped and only the amount of bytes sent is logged. But .css isn't compressed so the full file size is logged. >2) If you can't access your server's configuration and care more >about bandwidth than cpu, have php handle .css files and use its gzip >output handler. There are recipes on the web for storing gzipped files in the filesystem and serving them rather than compressing the file for every hit. Save CPU as well as bandwidth :) ...R. From gerhard at killesreiter.de Sun Nov 13 19:30:05 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Sun Nov 13 19:31:17 2005 Subject: [development] FYI more drupal.css stuff In-Reply-To: References: <20051113122154.96c06772.ber@webschuur.com> <437738A6.60704@wanadoo.es> <20051113154217.4189a17d.ber@webschuur.com> <20051113144803.GA2299@mallorn.ii.uj.edu.pl> <20051113162035.169f15c7.ber@webschuur.com> <93560955-B9C0-4416-8C19-94FD3AADB137@pajunas.com> Message-ID: <4377943D.4060306@killesreiter.de> Richard Archer wrote: >At 9:51 AM -0600 13/11/05, Allie Micka wrote: > > > >>1) Install mod_gzip (apache 1.3) or mod_deflate (2.0) to gzip your >>content. You will save 30-70% on any text file it is configured to >>handle. >> >> > >If you're going to do that you will have to configure it to only >compress .css files. If you compress all files being served you >will double-compress pages generated by Drupal because they are >already gzipped. > > Only cached pages are gzipped and I think that mod_gzip is bright enough to repsect the gzip header that is sent by Drupal. >That's probably why people are seeing so many bytes of .css >being served compared with pages... pages are gzipped and >only the amount of bytes sent is logged. But .css isn't >compressed so the full file size is logged. > > > Possibly. There is a "gzip the css" task on drupal.org with some links on the topic. >>2) If you can't access your server's configuration and care more >>about bandwidth than cpu, have php handle .css files and use its gzip >>output handler. >> >> > >There are recipes on the web for storing gzipped files in the >filesystem and serving them rather than compressing the file >for every hit. Save CPU as well as bandwidth :) > > That is the reason why we store cached pages in compressed form. Finally somebody who appreciates and understands that. ;p Cheers, Gerhard From drupal.org at juggernaut.com.au Sun Nov 13 20:10:01 2005 From: drupal.org at juggernaut.com.au (Richard Archer) Date: Sun Nov 13 20:11:31 2005 Subject: [development] FYI more drupal.css stuff Message-ID: At 8:30 PM +0100 13/11/05, Gerhard Killesreiter wrote: >Only cached pages are gzipped and I think that mod_gzip is bright enough >to repsect the gzip header that is sent by Drupal. On my Apache/2.0.53, PHP/4.3.11 system mod_gzip blindly compresses anything you send to it. It is not smart at all. By enabling zlib.output_compression in php.ini and mod_gzip in Apache you can triple-compress pages being served by Drupal! >Possibly. There is a "gzip the css" task on drupal.org with some links >on the topic. I know... I posted a possible solution to that issue but nobody has commented on it so I haven't taken it any further. http://drupal.org/node/11128 Dries also made some comments about a preferred solution in: http://drupal.org/node/13224 I really think that if bandwidth is an issue the solution is to merge all the css for your site and serve it gzipped using a special entry in .htaccess. In which case this would not be an issue for most site admins... it's an issue for the hosting company. Since I run a hosting company and I pay for bandwidth this issue is on some concern to me. I'll add this task to my todo list, but it could be a month before I get to actually work on it. ...R. From adrian at bryght.com Sun Nov 13 20:34:09 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Sun Nov 13 20:34:21 2005 Subject: [development] one very tiny suggestion. Message-ID: <452E162F-FCB4-4265-8CCD-BED7E0AA0DE6@bryght.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I would love to see a simple ajax thingamajig on the poll form that adds the 'more poll choices' dynamically without having to reload first. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDd6NBgegMqdGlkasRAonsAKCMx2aKMGIFz3aLUjYmsGKU9pkkxQCeJhq6 33puTCN1d8jwO8/o508IsD4= =L92Z -----END PGP SIGNATURE----- From herman.webley at gmail.com Sun Nov 13 20:56:35 2005 From: herman.webley at gmail.com (Herman Webley) Date: Sun Nov 13 20:56:37 2005 Subject: [development] one very tiny suggestion. In-Reply-To: <452E162F-FCB4-4265-8CCD-BED7E0AA0DE6@bryght.com> References: <452E162F-FCB4-4265-8CCD-BED7E0AA0DE6@bryght.com> Message-ID: No need for AJAX. This can be done in Javascript without having to access the webserver. On 11/13/05, Adrian Rossouw wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I would love to see a simple ajax thingamajig on the poll form that > adds the 'more poll choices' dynamically without having to reload first. > > > - -- > Adrian Rossouw > Drupal developer and Bryght Guy > http://drupal.org | http://bryght.com > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (Darwin) > > iD8DBQFDd6NBgegMqdGlkasRAonsAKCMx2aKMGIFz3aLUjYmsGKU9pkkxQCeJhq6 > 33puTCN1d8jwO8/o508IsD4= > =L92Z > -----END PGP SIGNATURE----- > -- Best regards, Herman Webley From gabor at hojtsy.hu Sun Nov 13 21:03:49 2005 From: gabor at hojtsy.hu (Gabor Hojtsy) Date: Sun Nov 13 21:03:55 2005 Subject: [development] one very tiny suggestion. In-Reply-To: References: <452E162F-FCB4-4265-8CCD-BED7E0AA0DE6@bryght.com> Message-ID: <4377AA35.6010307@hojtsy.hu> The need for AJAX depends on whether the form processor code checks for the number of items requested via the form and given via the submit. Goba Herman Webley wrote: > No need for AJAX. This can be done in Javascript without having to > access the webserver. > > On 11/13/05, Adrian Rossouw wrote: > > I would love to see a simple ajax thingamajig on the poll form that > adds the 'more poll choices' dynamically without having to reload first. > > > -- > Adrian Rossouw > Drupal developer and Bryght Guy > http://drupal.org | http://bryght.com > > > -- > Best regards, > Herman Webley From adrian at bryght.com Sun Nov 13 21:07:11 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Sun Nov 13 21:07:20 2005 Subject: [development] one very tiny suggestion. In-Reply-To: References: <452E162F-FCB4-4265-8CCD-BED7E0AA0DE6@bryght.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13 Nov 2005, at 10:56 PM, Herman Webley wrote: > No need for AJAX. This can be done in Javascript without having to > access the webserver. i call all javascript ajax these days, because it has more buzz, and there are fewer characters. or something =) - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDd6r/gegMqdGlkasRAmovAKDKY0kGl6FFhMKomNrSgORDEduB6gCgifsW jKju2dPD6uzVMjdTDZOtyLc= =2iDk -----END PGP SIGNATURE----- From david.carrington at gmail.com Sun Nov 13 23:41:24 2005 From: david.carrington at gmail.com (David Carrington) Date: Sun Nov 13 23:41:26 2005 Subject: [development] one very tiny suggestion. In-Reply-To: <452E162F-FCB4-4265-8CCD-BED7E0AA0DE6@bryght.com> References: <452E162F-FCB4-4265-8CCD-BED7E0AA0DE6@bryght.com> Message-ID: <49f3c93a0511131541n7fc69ff2x@mail.gmail.com> On 13/11/05, Adrian Rossouw wrote: > I would love to see a simple ajax thingamajig on the poll form that > adds the 'more poll choices' dynamically without having to reload first. Looks like a challenge to keep me awake tomorrow :) If someone could create an issue for this then I'll play with making a patch after some decent sleep. -- David Carrington From karoly at negyesi.net Sun Nov 13 23:56:02 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Sun Nov 13 23:53:24 2005 Subject: [development] one very tiny suggestion. In-Reply-To: <49f3c93a0511131541n7fc69ff2x@mail.gmail.com> References: <452E162F-FCB4-4265-8CCD-BED7E0AA0DE6@bryght.com> <49f3c93a0511131541n7fc69ff2x@mail.gmail.com> Message-ID: On Mon, 14 Nov 2005 00:41:24 +0100, David Carrington wrote: > On 13/11/05, Adrian Rossouw wrote: >> I would love to see a simple ajax thingamajig on the poll form that >> adds the 'more poll choices' dynamically without having to reload first. > > Looks like a challenge to keep me awake tomorrow :) > > If someone could create an issue for this then I'll play with making a > patch after some decent sleep. Sleep tight and use http://drupal.org/node/37489 tomorrow. From gerhard at killesreiter.de Mon Nov 14 00:18:35 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Mon Nov 14 00:20:00 2005 Subject: [development] FYI more drupal.css stuff In-Reply-To: References: Message-ID: <4377D7DB.4000201@killesreiter.de> Richard Archer wrote: >At 8:30 PM +0100 13/11/05, Gerhard Killesreiter wrote: > > > >>Only cached pages are gzipped and I think that mod_gzip is bright enough >>to repsect the gzip header that is sent by Drupal. >> >> > >On my Apache/2.0.53, PHP/4.3.11 system mod_gzip blindly compresses >anything you send to it. It is not smart at all. > > That's strange, it would mean that you couldn't use Drupal's caching with mod_gzip? It works just fine for me. Didn't we two fix this issue not too long ago? >By enabling zlib.output_compression in php.ini and mod_gzip in >Apache you can triple-compress pages being served by Drupal! > > You shouldn't be able to. >>Possibly. There is a "gzip the css" task on drupal.org with some links >>on the topic. >> >> > >I know... I posted a possible solution to that issue but nobody >has commented on it so I haven't taken it any further. >http://drupal.org/node/11128 > >Dries also made some comments about a preferred solution in: >http://drupal.org/node/13224 > >I really think that if bandwidth is an issue the solution is to >merge all the css for your site and serve it gzipped using a >special entry in .htaccess. In which case this would not be an >issue for most site admins... it's an issue for the hosting >company. > > > Maybe you could set up a handbook page that explains this. >Since I run a hosting company and I pay for bandwidth this issue >is on some concern to me. I'll add this task to my todo list, >but it could be a month before I get to actually work on it. > > > Since I usually only need between 3 and 5% of my bandwidth I am only interested in it for scientic reasons. ;) Cheers, Gerhard From herman.webley at gmail.com Mon Nov 14 00:40:28 2005 From: herman.webley at gmail.com (Herman Webley) Date: Mon Nov 14 00:40:31 2005 Subject: [development] one very tiny suggestion. In-Reply-To: References: <452E162F-FCB4-4265-8CCD-BED7E0AA0DE6@bryght.com> <49f3c93a0511131541n7fc69ff2x@mail.gmail.com> Message-ID: Hi all, I've added a patch for the 4.6 version. I coded it before I saw David's volunteer. http://drupal.org/node/37489 Adrian: you have the developers of drupal at your beck and call :D On 11/13/05, Karoly Negyesi wrote: > On Mon, 14 Nov 2005 00:41:24 +0100, David Carrington > wrote: > > > On 13/11/05, Adrian Rossouw wrote: > >> I would love to see a simple ajax thingamajig on the poll form that > >> adds the 'more poll choices' dynamically without having to reload first. > > > > Looks like a challenge to keep me awake tomorrow :) > > > > If someone could create an issue for this then I'll play with making a > > patch after some decent sleep. > > Sleep tight and use http://drupal.org/node/37489 tomorrow. > -- Best regards, Herman Webley From kb at 2bits.com Mon Nov 14 05:35:05 2005 From: kb at 2bits.com (Khalid B) Date: Mon Nov 14 05:35:07 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> Message-ID: <4a9fdc630511132135u126d9d0cta79867b10f3dbd21@mail.gmail.com> +1 from me too. It is about time we look at requirements early in the process, and discuss them and get agreement on them before we are too far off in coding. The mantra "code is gold and talk is silver" is often taken to extremes, and have undersirable effects. Adrian mentioned Jabber as an example. I will mention another CMS that written in PHP and MySQL: Xaraya has a format RFC process (Request for Comment). Here are some of them: http://xaraya.com/index.php/documentation/72 For small things, the patch process can still be used. For anything that is a bit more elaborate (e.g. forms API), we need the DEP process in place. From karoly at negyesi.net Mon Nov 14 06:07:50 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Mon Nov 14 06:05:09 2005 Subject: [development] Re: Form API updater In-Reply-To: References: Message-ID: > http://drupal.org/node/37457 Amazon pointed this out and I can tell you: this is an incredible piece of code. jjeff, congratulations. From ITBJDM at puknet.puk.ac.za Mon Nov 14 07:33:20 2005 From: ITBJDM at puknet.puk.ac.za (Kobus Myburgh) Date: Mon Nov 14 07:33:46 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) Message-ID: > I disagree. Once some code comes forward there usually is some issue > created and all you need to do is read the contained information. People > who are not willign to do that won't read lenghty proposals either. I disagree with you, Gerhard. Most people are not unwilling to read. Most people are unwilling to read when documentation is scattered all over the place. Especially if you only have a fe minutes to go through things, as has been the case with me over the past few years while I studied and work. With my final exam finishing tomorrow, it may resolve this issue for me, but how many others are there like me who want to read a small bit of information about something particular, e.g. the future of Drupal theming, but need to go through 4 or more "official" channels to get this information. If I would like to see what is on the forefront of theming, I have to check recent discussions about themes on the mailing lists, I can search the handbook pages, and I can ask around on IRC. This is a waste of my precious time. If I can read all I need to know about theming in one place, I am all for this proposal. We need more structure in the collaboration effort - that is the main reason I haven't been all that involved as I want to be, because I got only involved in stuff I could get my hands dirty with stuff I could get the full hang of within a few minutes. That's why I joined the documentation team. I have done some (I believe minor) work for the team, but at least I have an idea where things are going, and I can follow up with things that I know about. Development is not my strongest suite, and therefore catching up with difficult concepts whilst reading up 4 or more channels of communication is simply not effective nor efficient. Regards, Kobus From ITBJDM at puknet.puk.ac.za Mon Nov 14 07:35:47 2005 From: ITBJDM at puknet.puk.ac.za (Kobus Myburgh) Date: Mon Nov 14 07:36:11 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) Message-ID: > Only I would ask that this formal proccess doesn't mean too much > administrative overhead for every new project. So, basically, a new > section to know other people's 'big plans' and see easily 'who's working > on what' would do. If we have one html page for each project and one > 'coordinator' that maintains that page, keeps a list of related queued > patches, and the people involved, that would be a good start point. For > the rest, the patch queue and the forum will do. Doing a page per project is a recipe to reproduce the handbook. Again - no overview. People using different names for the same type of project would not be clearly visible with the separate page approach. I believe that this should be done for Core initially, but all on one page, as Adrian pointed out. Regards, Kobus From neil at civicspacelabs.org Mon Nov 14 08:39:01 2005 From: neil at civicspacelabs.org (neil@civicspacelabs.org) Date: Mon Nov 14 08:52:54 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> Message-ID: <20051114083901.GA31129@localhost> Overall I think this is a good idea. On Sat, Nov 12, 2005 at 09:41:42PM +0200, Adrian Rossouw wrote: > What we would essentially do is create a document, that has an > official number, a status and an owner. This document > would be modelled on JEPs (http://www.jabber.org/jeps/jep-0143.html), > and would explain the basic goals of the project, > reasoning behind it, requirements, security considerations and so forth. I think we should keep proposals written clearly and concisely. The longer something is, the less people will want to read it. > How I imagine the basic workflow would be, is that someone writes a > proposal, in the correct format, that gets published as a draft. > At a certain point the draft then gets sent to drupal-devel, and > developer comments are factored in. Then it gets published on > Drupal.org, and user comments get factored in. At this point, we have > a proposed DEP, and anyone who has any interest > in working towards that knows what has been decided to be the best > approach, who is working on it, and what is the status of it. Is this the best order- developers followed by users? I'm guessing it should be flexible. API changes go to developers first; functionality changes go to users first. -Neil From neil at civicspacelabs.org Mon Nov 14 08:57:04 2005 From: neil at civicspacelabs.org (neil@civicspacelabs.org) Date: Mon Nov 14 09:16:01 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <4a9fdc630511132135u126d9d0cta79867b10f3dbd21@mail.gmail.com> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> <4a9fdc630511132135u126d9d0cta79867b10f3dbd21@mail.gmail.com> Message-ID: <20051114085704.GA2756@localhost> On Mon, Nov 14, 2005 at 12:35:05AM -0500, Khalid B wrote: > For small things, the patch process can still be used. For anything > that is a bit > more elaborate (e.g. forms API), we need the DEP process in place. I think the process should be optional at the start. Let it evolve into something required if it is working. -Neil From dries at buytaert.net Mon Nov 14 09:50:07 2005 From: dries at buytaert.net (Dries Buytaert) Date: Mon Nov 14 09:50:16 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <4a9fdc630511132135u126d9d0cta79867b10f3dbd21@mail.gmail.com> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> <4a9fdc630511132135u126d9d0cta79867b10f3dbd21@mail.gmail.com> Message-ID: <043197E3-6D8A-4EF9-AF86-415CCAF2ED8F@buytaert.net> Having DEPs can be a good thing, however, I won't make it a requirement. - If you think that working out a detailed proposal or design document would benefit your project, by all means, write one. - If you think that is what it takes to coordinate people that want to contribute to your project, by all means, write one. Nothing stops you from taking that path: - Occasionally, we've seen written proposals and task lists; the CCK being the most prominent example. See http://drupal.org/cck-status. - Occasionally, we've seen roadmap documents; Ber strongly believed in maintaining a Drupal 4.6 roadmap (not supported by me). See http:// drupal.org/node/12202. -- Dries Buytaert :: http://www.buytaert.net/ From vlado at dikini.net Mon Nov 14 10:13:01 2005 From: vlado at dikini.net (vlado) Date: Mon Nov 14 10:13:05 2005 Subject: [development] Forms API magic question Message-ID: <1131963181.8942.17.camel@localhost.localdomain> I was wondering for some time if the forms api can help us (with some ajaxcy majic) do inplace edits of any content part. I still haven't worked out the full picture, but please comment if it is feasible, since I'm no forms/js guru at all. for every node view generate form code or retrieve the nessesary form code if the bunny double clicks on an editable part of a page they get the appropriate element, ckick save/submit to save it. Alternatively do basecamp style edit hints per editable part. I think overall it is feasible. Not sure if I can do it though :) cheers vlado From ber at webschuur.com Mon Nov 14 10:35:16 2005 From: ber at webschuur.com (Ber Kessels) Date: Mon Nov 14 10:35:20 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <043197E3-6D8A-4EF9-AF86-415CCAF2ED8F@buytaert.net> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> <4a9fdc630511132135u126d9d0cta79867b10f3dbd21@mail.gmail.com> <043197E3-6D8A-4EF9-AF86-415CCAF2ED8F@buytaert.net> Message-ID: <20051114113516.b3ee7be9.ber@webschuur.com> On Mon, 14 Nov 2005 10:50:07 +0100 Dries Buytaert wrote: > - Occasionally, we've seen roadmap documents; Ber strongly believed > in maintaining a Drupal 4.6 roadmap (not supported by me). See http:// > drupal.org/node/12202. To elaborate on this: I meant it as an experiment. To see if we could get something in place that all mayor projects seem to have: a place where humans can read whats happening. The experiment was a success, because the outcome is very clear: Users want this very badly * We dont have an infrastructure (i.e. code) to maintain something like this easy * We dont have engineers and developers around who are willing to spend the time and effort to maintain their (or others) statuses on such a place. [1] * So we failed to maintain such a place. Ber [1] This should be either by the developers themselves, or by those who understand the code and technical (drupal) jargon well enough to rephrase a set of patchesm or a module into one sentence. It is a very hard thing to do. Apparently (that roadmap was never up to date) too hard for our current way of doing stuff. -- B?r Kessels Drupal services bler.webschuur.com www.webschuur.com ber@jabber.webschuur.com From david.carrington at gmail.com Mon Nov 14 10:51:07 2005 From: david.carrington at gmail.com (David Carrington) Date: Mon Nov 14 10:51:09 2005 Subject: [development] Forms API magic question In-Reply-To: <1131963181.8942.17.camel@localhost.localdomain> References: <1131963181.8942.17.camel@localhost.localdomain> Message-ID: <49f3c93a0511140251tcc00052m@mail.gmail.com> On 14/11/05, vlado wrote: > if the bunny double clicks on an editable part of a page they get the > appropriate element, ckick save/submit to save it. Didn't UnConeD create something like this on drupaldevs? I remember playing with a demo. -- David Carrington From ber at webschuur.com Mon Nov 14 11:10:28 2005 From: ber at webschuur.com (Ber Kessels) Date: Mon Nov 14 11:10:32 2005 Subject: [development] one very tiny suggestion. In-Reply-To: <49f3c93a0511131541n7fc69ff2x@mail.gmail.com> References: <452E162F-FCB4-4265-8CCD-BED7E0AA0DE6@bryght.com> <49f3c93a0511131541n7fc69ff2x@mail.gmail.com> Message-ID: <20051114121028.bd7415c3.ber@webschuur.com> why not make this general, something like $form['type'] => 'replicate' A form item that can be added to any form to replicate a wrapped part of a form Foo times. title [ ] description [ | | ] ----- wrapped in a div, "fileStuff" -- file [ ] [browse] [X] fooBar [ ] anohterBar [Gimme 5 file fields] ------end wrap "fileStuff" --------------- the [Gimme 5 file fields] would then be a link that would: * fire some JS to replicate the wrapped part 4 times (so we have 5 fields) * in case of no JS it would link to example.com/the/page/ with a GET that will fire some PHP to replicate the part 5 times. This is what I was working on for the files stuff, well, the GET part, I left out the ajaxy stuff. Ber On Sun, 13 Nov 2005 23:41:24 +0000 David Carrington wrote: > On 13/11/05, Adrian Rossouw wrote: > > I would love to see a simple ajax thingamajig on the poll form that > > adds the 'more poll choices' dynamically without having to reload first. > > Looks like a challenge to keep me awake tomorrow :) > > If someone could create an issue for this then I'll play with making a > patch after some decent sleep. > > -- > David Carrington -- B?r Kessels Drupal services bler.webschuur.com www.webschuur.com ber@jabber.webschuur.com From david.carrington at gmail.com Mon Nov 14 12:04:32 2005 From: david.carrington at gmail.com (David Carrington) Date: Mon Nov 14 12:04:35 2005 Subject: [development] one very tiny suggestion. In-Reply-To: <20051114121028.bd7415c3.ber@webschuur.com> References: <452E162F-FCB4-4265-8CCD-BED7E0AA0DE6@bryght.com> <49f3c93a0511131541n7fc69ff2x@mail.gmail.com> <20051114121028.bd7415c3.ber@webschuur.com> Message-ID: <49f3c93a0511140404g2de46136x@mail.gmail.com> On 14/11/05, Ber Kessels wrote: > why not make this general, something like $form['type'] => 'replicate' > A form item that can be added to any form to replicate a wrapped part of a form Foo times. [snip] > This is what I was working on for the files stuff, well, the GET part, I left out the ajaxy stuff. What's the status of this? I'd much prefer to write ajax for a generic solution than a solution for poll.module. -- David Carrington From karoly at negyesi.net Mon Nov 14 12:10:32 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Mon Nov 14 12:07:48 2005 Subject: [development] one very tiny suggestion. In-Reply-To: <49f3c93a0511140404g2de46136x@mail.gmail.com> References: <452E162F-FCB4-4265-8CCD-BED7E0AA0DE6@bryght.com> <49f3c93a0511131541n7fc69ff2x@mail.gmail.com> <20051114121028.bd7415c3.ber@webschuur.com> <49f3c93a0511140404g2de46136x@mail.gmail.com> Message-ID: On Mon, 14 Nov 2005 13:04:32 +0100, David Carrington wrote: > On 14/11/05, Ber Kessels wrote: >> why not make this general, something like $form['type'] => 'replicate' >> A form item that can be added to any form to replicate a wrapped part >> of a form Foo times. > [snip] >> This is what I was working on for the files stuff, well, the GET part, >> I left out the ajaxy stuff. > > What's the status of this? I'd much prefer to write ajax for a generic > solution than a solution for poll.module. Do you think we will turn down such an excellent idea :) ? So many uses it has... Regards NK From ber at webschuur.com Mon Nov 14 12:36:10 2005 From: ber at webschuur.com (Ber Kessels) Date: Mon Nov 14 12:36:15 2005 Subject: [development] one very tiny suggestion. In-Reply-To: <49f3c93a0511140404g2de46136x@mail.gmail.com> References: <452E162F-FCB4-4265-8CCD-BED7E0AA0DE6@bryght.com> <49f3c93a0511131541n7fc69ff2x@mail.gmail.com> <20051114121028.bd7415c3.ber@webschuur.com> <49f3c93a0511140404g2de46136x@mail.gmail.com> Message-ID: <20051114133610.e3417984.ber@webschuur.com> On Mon, 14 Nov 2005 12:04:32 +0000 David Carrington wrote: > > This is what I was working on for the files stuff, well, the GET part, I left out the ajaxy stuff. > > What's the status of this? I'd much prefer to write ajax for a generic > solution than a solution for poll.module. Vapourware. Or better: snippetware. I'm still getting all the ideas organised, most of wich live in (pseudo code) all over the place. .... and off course i try to get others to write code i can use here too, harhar...... So: no, I cannot give you any code yet, but i will dedicate some time, to code this, now this gets rolling (which it does now). Ill keep an eye on the issue. Let us continue discussions there? Ber -- B?r Kessels Drupal services bler.webschuur.com www.webschuur.com ber@jabber.webschuur.com From occy at occy.net Mon Nov 14 15:12:29 2005 From: occy at occy.net (Trae McCombs) Date: Mon Nov 14 15:12:22 2005 Subject: [development] Re: [CS dev] Help with a CivicSpace Theme Layout... (Read it, you know you want to! :) In-Reply-To: <1F298344-E0CE-417F-BE0F-B4B8DB7F3110@culturekitchen.com> References: <43755749.4000209@occy.net> <1F298344-E0CE-417F-BE0F-B4B8DB7F3110@culturekitchen.com> Message-ID: <1131981149.21921.24.camel@localhost.localdomain> On Sat, 2005-11-12 at 10:10 -0500, Liza Sabater wrote: > Hey Trae, > > I'm being a bit lazy here but ... for Mac people, can you post a > screenshot of what it looks like on IE? I am assuming you mean MS/IE > not Mac/IE, which is not being supported AT ALL by Microsoft. Right, well, I am not supporting IE for Mac, as you said, neither is Microsoft. There are other better and free browsers for OSX [ Firefox / Safari ] > Which brings me to one request : CivicSpaceLabs (that means you ;) > ought to offer the option right off the bat to include in the theme a > browser sniffer so that people with older browsers can default to a > 'downgraded' version of the theme. I cannot stress how important it > is for us to move people to Firefox and this should be the way to do > so. Please remember that a lot of NGOs don't get new equipment. > Usually grassroots NGOs and educational NGOs get donated equipment > with outdated software. Let's just educate people to the best options > they can have by pointing to the obvious: If you want a better > browsing experience, go Firefox. Pardon my ignorance, NGO? I do understand about donated computers and low end systems as I've worked with groups in the past on issues dealing with Digital Divide problems. The thing is, the more we backwardly rig our websites to work with old, outdated, buggy, insecure browsers, the more problems the web will continue to have. My personal feelings are: Firefox is free, download and install it. Or grab another free browser, or if you want to use Microsoft products, upgrade to IE6. I think we, web developers, spend too much time trying to fix a website so it works on Some browser from 1994. I say make sure your CSS and HTML is validated, and work from there. > Also, and I almost forgot about it, where is Longhorn? There is a > looming development and design disaster for a lot of NGOs if Longhorn > proves to be as much as a pain in the ass as it's predecessor --no > matter how standards compliant they're claiming to be. Don't even get me started on IE7. :) > This is a huge issue that ought to be address through the development > of these themes. It's really not just about how pretty the site is > going to look off the box. CivicSpaceLabs should consider addressing > the pressing need of saving the already strained resources and man- > hours of NGOs and grassroots organizations lost to theme debugging; > especially once MicroSoft unleashes it's new OS and browser from hell. I would actually be all for some sort of browser detection thing if it worked 100% where it educated people to grab a standards compliant browser. But then again, we'd be also telling IE people to get a clue, and most people aren't for that. sigh Again, I'd love to have you hang out with us on #cstheme on irc.freenode.net where we can discuss this and other issues to help make the CStheme better. Thanks, Trae > / liza > > > > On Nov 11 2005, at 09:45 PM, Trae McCombs wrote: > > > Ok, so let me post a wee bit of information. Please check this URL > > out first: > > > > http://civicspacelabs.org/home/CivicSpaceTheme > > > > This will, or should, bring you up to date on some of the terms I'm > > going to be using below. The CivicSpace Theme (CST) is using some > > new concepts in themeing. > > > > Anyway, my question currently is this. > > > > The Federation Layout looks fine on Firefox, but for some reason it > > isn't working in IE. Meaning, it doesn't match it's thumbnail. If > > you simply compare both browsers, and notice how FF looks and IE > > doesn't then you should see what's wrong. I can't figure out what > > is causing it. Someone suggested #content, however that only > > changes the internal body. > > > > Here is the site where I am currently working on things, and the > > Federation Layout is selected at present: > > > > http://demo.civicspacelabs.org/home/ > > > > Also, this may be of some use. It is the Plan of action, or guide > > we are trying to use for the CST: > > > > http://civicspacelabs.org/home/CivicSpaceThemePlan > > > > Please, feel free to join me on #cstheme on irc.freenode.net and > > discuss any of these issues. I do look forward to your help. > > > > Thanks, > > Trae > > > > PS. Kieran (Amazon) says I can blame him for this [and any and all > > further silly questions I have -- oh wait, maybe he didn't say all > > of that exactly. :)] > > > > -- > > Trae "occy" McCombs || http://occy.net/ > > Founder - Themes.org // Linux.com > > CivicSpaceLabs - http://civicspacelabs.org/ > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: civicspace-dev-unsubscribe@civicspacelabs.org > > For additional commands, e-mail: civicspace-dev- > > help@civicspacelabs.org > > > > -- Trae "occy" McCombs || http://occy.net/ Founder - Themes.org // Linux.com CivicSpaceLabs - http://civicspacelabs.org/ From weitzman at tejasa.com Mon Nov 14 15:20:10 2005 From: weitzman at tejasa.com (Moshe Weitzman) Date: Mon Nov 14 15:21:11 2005 Subject: [development] Forms API magic question In-Reply-To: <1131963181.8942.17.camel@localhost.localdomain> References: <1131963181.8942.17.camel@localhost.localdomain> Message-ID: <4378AB2A.9000800@tejasa.com> vlado wrote: > I was wondering for some time if the forms api can help us (with some > ajaxcy majic) do inplace edits of any content part. I still haven't > worked out the full picture, but please comment if it is feasible, since > I'm no forms/js guru at all. > > for every node view generate form code or retrieve the nessesary form > code > > if the bunny double clicks on an editable part of a page they get the > appropriate element, ckick save/submit to save it. > Alternatively do basecamp style edit hints per editable part. > > I think overall it is feasible. Not sure if I can do it though :) > > cheers > vlado > would be very nice. UnConed has some code in his sandbox. he ran into troubles with the filter system but i'm hoping that those can be overcome. see readme and inlineedit.module at http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/unconed/soc/ From walkah at walkah.net Mon Nov 14 15:19:25 2005 From: walkah at walkah.net (James Walker) Date: Mon Nov 14 15:24:21 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <043197E3-6D8A-4EF9-AF86-415CCAF2ED8F@buytaert.net> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> <4a9fdc630511132135u126d9d0cta79867b10f3dbd21@mail.gmail.com> <043197E3-6D8A-4EF9-AF86-415CCAF2ED8F@buytaert.net> Message-ID: <4378AAFD.5010108@walkah.net> On 11/14/05 4:50 AM, Dries Buytaert wrote: > > Having DEPs can be a good thing, however, I won't make it a requirement. This is pretty big... I think it loses considerable effect if it's not part of the mandatory workflow... Part of the idea was to centralize the process and make it uniform project-wide. If you look at the examples where Adrian is drawing most of the ideas from (i.e. Jabber's JEPs or, one I like - PEAR's PEPr) - there is a centralized overview of what can / will be implemented. I.E. if it's not there, it can safely be presumed nobody is working on it. I understand that it's hard to introduce something like this on such a large community right now... but I think it would be hugely beneficial to have something slightly more formal in place... It's not a process we're gonna agree on overnight, but I think it's one we should work towards. my $0.02 (CAD) -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net From walkah at walkah.net Mon Nov 14 15:22:23 2005 From: walkah at walkah.net (James Walker) Date: Mon Nov 14 15:27:20 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> Message-ID: <4378ABAF.8060306@walkah.net> On 11/12/05 8:29 PM, Richard Archer wrote: > At 9:41 PM +0200 12/11/05, Adrian Rossouw wrote: > >> What we would essentially do is create a document, that has an >> official number, a status and an owner. This document >> would be modelled on JEPs (http://www.jabber.org/jeps/jep-0143.html), >> and would explain the basic goals of the project, >> reasoning behind it, requirements, security considerations and so forth. > > The JEP structure looks pretty heavy handed. It might also be worth > considering some of the features of PEPs. > > http://www.python.org/peps/pep-0001.html > > ...R. Ahh. yeah PEPs are good as well, I keep pointing Adrian (and others) to PEAR's PEPr : http://pear.php.net/pepr/pepr-overview.php ... which is kind of a formalized "+1" process ... which I think would be fairly easy to get used to. Notice the overview page gives a real easy quick look at whats upcoming / in progress /etc. -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net From walkah at walkah.net Mon Nov 14 15:30:38 2005 From: walkah at walkah.net (James Walker) Date: Mon Nov 14 15:35:37 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <4a9fdc630511132135u126d9d0cta79867b10f3dbd21@mail.gmail.com> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> <4a9fdc630511132135u126d9d0cta79867b10f3dbd21@mail.gmail.com> Message-ID: <4378AD9E.6010808@walkah.net> On 11/14/05 12:35 AM, Khalid B wrote: > For small things, the patch process can still be used. For anything > that is a bit > more elaborate (e.g. forms API), we need the DEP process in place. Of course! obviously not every little feature request will go through this process, or the project as a whole will come grinding to a halt. But exactly, major API changes, new modules , etc should. (I personally think DEPs should be required for all new contrib modules - and thus new CVS accounts). -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net From prometheus6 at gmail.com Mon Nov 14 15:55:29 2005 From: prometheus6 at gmail.com (Earl Dunovant) Date: Mon Nov 14 15:55:31 2005 Subject: [development] Re: Form API updater In-Reply-To: References: Message-ID: Thank you. I'm past the point where it will help with Amazon associate tools but it's going to make short work of my smaller modules. On 11/14/05, Karoly Negyesi wrote: > > > http://drupal.org/node/37457 > > Amazon pointed this out and I can tell you: this is an incredible piece of > code. jjeff, congratulations. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051114/2976f6f4/attachment-0001.htm From karoly at negyesi.net Mon Nov 14 16:41:03 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Mon Nov 14 16:38:18 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <4378AAFD.5010108@walkah.net> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> <4a9fdc630511132135u126d9d0cta79867b10f3dbd21@mail.gmail.com> <043197E3-6D8A-4EF9-AF86-415CCAF2ED8F@buytaert.net> <4378AAFD.5010108@walkah.net> Message-ID: > It's not a process we're gonna agree on overnight, but I think it's one > we should work towards. if need to be, I can write docs on what I plan, that's OK. And while I know there is no clear cut answer here, what's the "size" of the change when you need to roll such a doc? Or, simply, it's "big change" and we rely on common sense? Regards NK From lists at jjeff.com Mon Nov 14 19:20:31 2005 From: lists at jjeff.com (Jeff Robbins) Date: Mon Nov 14 19:20:30 2005 Subject: [development] Re: Form API updater In-Reply-To: References: Message-ID: Thanks Karoly! Thought it would help the project. (...and keep me from going crazy looking up the deprecated function calls) -Jeff On Nov 14, 2005, at 1:07 AM, Karoly Negyesi wrote: >> http://drupal.org/node/37457 > > Amazon pointed this out and I can tell you: this is an incredible > piece of code. jjeff, congratulations. From ber at webschuur.com Mon Nov 14 19:46:54 2005 From: ber at webschuur.com (Ber Kessels) Date: Mon Nov 14 19:46:59 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <4378ABAF.8060306@walkah.net> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> <4378ABAF.8060306@walkah.net> Message-ID: <20051114204654.d2cef345.ber@webschuur.com> Adrian proposed a general "get people together and work in the same direction" idea. Peps are more like "ive got this and that working and i'd like to get it in", os it seems to me. I am more for a place to work together on new ideas. I really liked that part of Adrians proposal. If, whether or when that causes more administrative overhead, we can sort that out. But IMNSHO going for a "tackle this issue together" system is what we should aim for, in the first place. It is what got that form API in. It is what holds back Those Big Issues from leveraging from yadiyadia level to Real Code Level, think drupal.css, think taxonomy.module cleanup, think CCK ideals, think install API. etcetc. I firmly beleive we reached a level where we can no longer deal with Big Changes, unless we form subgroups. Which, again, is what I got, this is all about. I hope so in any way. If this is only about getting more structured and more official administration in place, then I think we should at least start that "subgroup thingy" project rolling, now. Administration might help, but a place to work efficient, quick, efficient and dedicated, on a certain issue helps much much more, IMNSHO. Ber On Mon, 14 Nov 2005 10:22:23 -0500 James Walker wrote: > On 11/12/05 8:29 PM, Richard Archer wrote: > > At 9:41 PM +0200 12/11/05, Adrian Rossouw wrote: > > > >> What we would essentially do is create a document, that has an > >> official number, a status and an owner. This document > >> would be modelled on JEPs (http://www.jabber.org/jeps/jep-0143.html), > >> and would explain the basic goals of the project, > >> reasoning behind it, requirements, security considerations and so forth. > > > > The JEP structure looks pretty heavy handed. It might also be worth > > considering some of the features of PEPs. > > > > http://www.python.org/peps/pep-0001.html > > > > ...R. > > Ahh. yeah PEPs are good as well, I keep pointing Adrian (and others) to > PEAR's PEPr : http://pear.php.net/pepr/pepr-overview.php ... which is > kind of a formalized "+1" process ... which I think would be fairly easy > to get used to. > > Notice the overview page gives a real easy quick look at whats upcoming > / in progress /etc. > > -- > James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net -- B?r Kessels Drupal services bler.webschuur.com www.webschuur.com ber@jabber.webschuur.com From ber at webschuur.com Mon Nov 14 19:49:59 2005 From: ber at webschuur.com (Ber Kessels) Date: Mon Nov 14 19:50:03 2005 Subject: [development] Re: [CS dev] Help with a CivicSpace Theme Layout... (Read it, you know you want to! :) In-Reply-To: <1131981149.21921.24.camel@localhost.localdomain> References: <43755749.4000209@occy.net> <1F298344-E0CE-417F-BE0F-B4B8DB7F3110@culturekitchen.com> <1131981149.21921.24.camel@localhost.localdomain> Message-ID: <20051114204959.c9299a9d.ber@webschuur.com> On Mon, 14 Nov 2005 10:12:29 -0500 Trae McCombs wrote: > On Sat, 2005-11-12 at 10:10 -0500, Liza Sabater wrote: > > Hey Trae, > > > > I'm being a bit lazy here but ... for Mac people, can you post a > > screenshot of what it looks like on IE? I am assuming you mean MS/IE > > not Mac/IE, which is not being supported AT ALL by Microsoft. AFAIKR the only "real" browser for older macs is IE 5.5. I dont support it, but a friend once showed me all the other options for (older) iMac users: none. Is that true? Should we consider this at all? Should I consiuder this at all? Ber -- B?r Kessels Drupal services bler.webschuur.com www.webschuur.com ber@jabber.webschuur.com From occy at occy.net Mon Nov 14 20:16:12 2005 From: occy at occy.net (Trae McCombs) Date: Mon Nov 14 20:16:05 2005 Subject: [development] Re: [CS dev] Help with a CivicSpace Theme Layout... (Read it, you know you want to! :) In-Reply-To: <20051114204959.c9299a9d.ber@webschuur.com> References: <43755749.4000209@occy.net> <1F298344-E0CE-417F-BE0F-B4B8DB7F3110@culturekitchen.com> <1131981149.21921.24.camel@localhost.localdomain> <20051114204959.c9299a9d.ber@webschuur.com> Message-ID: <1131999372.21921.28.camel@localhost.localdomain> On Mon, 2005-11-14 at 20:49 +0100, Ber Kessels wrote: > On Mon, 14 Nov 2005 10:12:29 -0500 > Trae McCombs wrote: > > > On Sat, 2005-11-12 at 10:10 -0500, Liza Sabater wrote: > > > Hey Trae, > > > > > > I'm being a bit lazy here but ... for Mac people, can you post a > > > screenshot of what it looks like on IE? I am assuming you mean MS/IE > > > not Mac/IE, which is not being supported AT ALL by Microsoft. > > AFAIKR the only "real" browser for older macs is IE 5.5. I dont support it, but a friend once showed me all the other options for (older) iMac users: none. > > Is that true? Should we consider this at all? Should I consiuder this at all? > > Ber Can't you get Firefox for older Macs? Trae -- Trae "occy" McCombs || http://occy.net/ Founder - Themes.org // Linux.com CivicSpaceLabs - http://civicspacelabs.org/ From gabor at hojtsy.hu Mon Nov 14 20:25:50 2005 From: gabor at hojtsy.hu (Gabor Hojtsy) Date: Mon Nov 14 20:25:54 2005 Subject: [development] Re: [CS dev] Help with a CivicSpace Theme Layout... (Read it, you know you want to! :) In-Reply-To: <1131999372.21921.28.camel@localhost.localdomain> References: <43755749.4000209@occy.net> <1F298344-E0CE-417F-BE0F-B4B8DB7F3110@culturekitchen.com> <1131981149.21921.24.camel@localhost.localdomain> <20051114204959.c9299a9d.ber@webschuur.com> <1131999372.21921.28.camel@localhost.localdomain> Message-ID: <4378F2CE.4010104@hojtsy.hu> Trae McCombs wrote: >>>>I'm being a bit lazy here but ... for Mac people, can you post a >>>>screenshot of what it looks like on IE? I am assuming you mean MS/IE >>>>not Mac/IE, which is not being supported AT ALL by Microsoft. >> >>AFAIKR the only "real" browser for older macs is IE 5.5. I dont support it, but a friend once showed me all the other options for (older) iMac users: none. >> >>Is that true? Should we consider this at all? Should I consiuder this at all? > > Can't you get Firefox for older Macs? Not officially: http://www.mozilla.org/products/firefox/all.html Goba From justin at buddyping.com Mon Nov 14 20:45:57 2005 From: justin at buddyping.com (Justin Davies) Date: Mon Nov 14 20:46:04 2005 Subject: [development] Re: [CS dev] Help with a CivicSpace Theme Layout... (Read it, you know you want to! :) In-Reply-To: <4378F2CE.4010104@hojtsy.hu> References: <43755749.4000209@occy.net> <1F298344-E0CE-417F-BE0F-B4B8DB7F3110@culturekitchen.com> <1131981149.21921.24.camel@localhost.localdomain> <20051114204959.c9299a9d.ber@webschuur.com> <1131999372.21921.28.camel@localhost.localdomain> <4378F2CE.4010104@hojtsy.hu> Message-ID: <4C4116C6-ECC3-45C6-9039-C70CA5BEDD2D@buddyping.com> In all honesty, I don't think you have to worry about old Macs. There is an evolution that just happens, and forcing people away from an old, non-standards based browser on a very old Mac is not going to loose too many users. 90% of Mac users use Safari or a Mozilla variant, and those should be the people to concentrate on. You have to bear in mind that IE users on the Mac are used to websites not working properly. Not because the designers do it wrong, but because the browser is sht. Justin On 14 Nov 2005, at 20:25, Gabor Hojtsy wrote: > Trae McCombs wrote: >>>>> I'm being a bit lazy here but ... for Mac people, can you post a >>>>> screenshot of what it looks like on IE? I am assuming you mean >>>>> MS/IE >>>>> not Mac/IE, which is not being supported AT ALL by Microsoft. >>> >>> AFAIKR the only "real" browser for older macs is IE 5.5. I dont >>> support it, but a friend once showed me all the other options for >>> (older) iMac users: none. >>> >>> Is that true? Should we consider this at all? Should I consiuder >>> this at all? >> >> Can't you get Firefox for older Macs? > > Not officially: http://www.mozilla.org/products/firefox/all.html > > Goba From ber at webschuur.com Mon Nov 14 20:59:02 2005 From: ber at webschuur.com (Ber Kessels) Date: Mon Nov 14 20:59:04 2005 Subject: [development] Re: [CS dev] Help with a CivicSpace Theme Layout... (Read it, you know you want to! :) In-Reply-To: <4C4116C6-ECC3-45C6-9039-C70CA5BEDD2D@buddyping.com> References: <43755749.4000209@occy.net> <1F298344-E0CE-417F-BE0F-B4B8DB7F3110@culturekitchen.com> <1131981149.21921.24.camel@localhost.localdomain> <20051114204959.c9299a9d.ber@webschuur.com> <1131999372.21921.28.camel@localhost.localdomain> <4378F2CE.4010104@hojtsy.hu> <4C4116C6-ECC3-45C6-9039-C70CA5BEDD2D@buddyping.com> Message-ID: <20051114215902.befbb371.ber@webschuur.com> On Mon, 14 Nov 2005 20:45:57 +0000 Justin Davies wrote: > You have to bear in mind that IE users on the Mac are used to > websites not working properly. Not because the designers do it > wrong, but because the browser is sht. This, is very true! but still, to me it just "feels wrong" to leave people drown in their own sh%t, because they made the wrong choice :). Indeed, we hunted for alternatives on older macs for IE 5.5 and ended up with self-compilable firefoxen, or oddly configured lynxes. But I am not sure if /I/ should bother about these couple of poor bastards :). I dont even "officially support" ie 5 for windows anymore. as of this month! Does anyone know any? Id love to point some users to them. But to me, this chapter is closed with: get these poor folks a foudantion, donate some funds to get them a non-MS browser and stop nagging aboout that horribly broken one. Ber -- B?r Kessels Drupal services bler.webschuur.com www.webschuur.com ber@jabber.webschuur.com From justin at buddyping.com Mon Nov 14 21:19:18 2005 From: justin at buddyping.com (Justin Davies) Date: Mon Nov 14 21:19:23 2005 Subject: [development] Re: [CS dev] Help with a CivicSpace Theme Layout... (Read it, you know you want to! :) In-Reply-To: <20051114215902.befbb371.ber@webschuur.com> References: <43755749.4000209@occy.net> <1F298344-E0CE-417F-BE0F-B4B8DB7F3110@culturekitchen.com> <1131981149.21921.24.camel@localhost.localdomain> <20051114204959.c9299a9d.ber@webschuur.com> <1131999372.21921.28.camel@localhost.localdomain> <4378F2CE.4010104@hojtsy.hu> <4C4116C6-ECC3-45C6-9039-C70CA5BEDD2D@buddyping.com> <20051114215902.befbb371.ber@webschuur.com> Message-ID: <76EF8B41-8E06-4A05-96B3-A3CD2FE4E0A6@buddyping.com> Ber, There is a time to let things go, and the time for IE on the Mac is now. Don't feel guilty. Think about it as a public service to the rest of the world. You are helping to stop web designers having to worry about IE on the Mac (now they only have to concentrate on IE for Win!) It is the same thing as asking how many Apple G3 processor machines are out there? Maybe 1% of Macs ? If that is that case, does that mean you have to sacrifice the speed of delivery for 99% of people because you need to make it work for the 1% ? Let it go, don't feel guilty. Justin On 14 Nov 2005, at 20:59, Ber Kessels wrote: > On Mon, 14 Nov 2005 20:45:57 +0000 > Justin Davies wrote: > >> You have to bear in mind that IE users on the Mac are used to >> websites not working properly. Not because the designers do it >> wrong, but because the browser is sht. > > This, is very true! but still, to me it just "feels wrong" to leave > people drown in their own sh%t, because they made the wrong choice :). > > Indeed, we hunted for alternatives on older macs for IE 5.5 and > ended up with self-compilable firefoxen, or oddly configured > lynxes. But I am not sure if /I/ should bother about these couple > of poor bastards :). I dont even "officially support" ie 5 for > windows anymore. as of this month! > > Does anyone know any? Id love to point some users to them. > > But to me, this chapter is closed with: get these poor folks a > foudantion, donate some funds to get them a non-MS browser and stop > nagging aboout that horribly broken one. > > Ber > -- > B?r Kessels Drupal services > bler.webschuur.com www.webschuur.com > ber@jabber.webschuur.com From occy at occy.net Mon Nov 14 21:27:12 2005 From: occy at occy.net (Trae McCombs) Date: Mon Nov 14 21:27:05 2005 Subject: [development] Re: [CS dev] Help with a CivicSpace Theme Layout... (Read it, you know you want to! :) In-Reply-To: <76EF8B41-8E06-4A05-96B3-A3CD2FE4E0A6@buddyping.com> References: <43755749.4000209@occy.net> <1F298344-E0CE-417F-BE0F-B4B8DB7F3110@culturekitchen.com> <1131981149.21921.24.camel@localhost.localdomain> <20051114204959.c9299a9d.ber@webschuur.com> <1131999372.21921.28.camel@localhost.localdomain> <4378F2CE.4010104@hojtsy.hu> <4C4116C6-ECC3-45C6-9039-C70CA5BEDD2D@buddyping.com> <20051114215902.befbb371.ber@webschuur.com> <76EF8B41-8E06-4A05-96B3-A3CD2FE4E0A6@buddyping.com> Message-ID: <1132003633.21921.32.camel@localhost.localdomain> +1 On Mon, 2005-11-14 at 21:19 +0000, Justin Davies wrote: > Ber, > > There is a time to let things go, and the time for IE on the Mac is > now. Don't feel guilty. Think about it as a public service to the > rest of the world. You are helping to stop web designers having to > worry about IE on the Mac (now they only have to concentrate on IE > for Win!) > > It is the same thing as asking how many Apple G3 processor machines > are out there? Maybe 1% of Macs ? If that is that case, does that > mean you have to sacrifice the speed of delivery for 99% of people > because you need to make it work for the 1% ? > > > Let it go, don't feel guilty. > > Justin > > On 14 Nov 2005, at 20:59, Ber Kessels wrote: > > > On Mon, 14 Nov 2005 20:45:57 +0000 > > Justin Davies wrote: > > > >> You have to bear in mind that IE users on the Mac are used to > >> websites not working properly. Not because the designers do it > >> wrong, but because the browser is sht. > > > > This, is very true! but still, to me it just "feels wrong" to leave > > people drown in their own sh%t, because they made the wrong choice :). > > > > Indeed, we hunted for alternatives on older macs for IE 5.5 and > > ended up with self-compilable firefoxen, or oddly configured > > lynxes. But I am not sure if /I/ should bother about these couple > > of poor bastards :). I dont even "officially support" ie 5 for > > windows anymore. as of this month! > > > > Does anyone know any? Id love to point some users to them. > > > > But to me, this chapter is closed with: get these poor folks a > > foudantion, donate some funds to get them a non-MS browser and stop > > nagging aboout that horribly broken one. > > > > Ber > > -- > > B?r Kessels Drupal services > > bler.webschuur.com www.webschuur.com > > ber@jabber.webschuur.com > -- Trae "occy" McCombs || http://occy.net/ Founder - Themes.org // Linux.com CivicSpaceLabs - http://civicspacelabs.org/ From adrinux at gmail.com Mon Nov 14 22:52:23 2005 From: adrinux at gmail.com (Adrian Simmons) Date: Mon Nov 14 22:52:28 2005 Subject: [development] Re: [CS dev] Help with a CivicSpace Theme Layout... (Read it, you know you want to! :) In-Reply-To: <4C4116C6-ECC3-45C6-9039-C70CA5BEDD2D@buddyping.com> References: <43755749.4000209@occy.net> <1F298344-E0CE-417F-BE0F-B4B8DB7F3110@culturekitchen.com> <1131981149.21921.24.camel@localhost.localdomain> <20051114204959.c9299a9d.ber@webschuur.com> <1131999372.21921.28.camel@localhost.localdomain> <4378F2CE.4010104@hojtsy.hu> <4C4116C6-ECC3-45C6-9039-C70CA5BEDD2D@buddyping.com> Message-ID: <43791527.4000100@gmail.com> Justin Davies wrote: > In all honesty, I don't think you have to worry about old Macs. Well, maybe, maybe not. It really all depends on a particular site and what the audience uses. Macs are reliable, they often go on for years and years. There are plenty out there still in active use. > forcing people away from an > old, non-standards based browser on a very old Mac is not going to loose > too many users. I hate to be in the position of defending a Microsoft browser but lets set some records straight here. IE5 mac is an entirely different product from IE5 on Windows. At the time IE5 mac was released it had the most complete web standards support of any available browser. Better than Mozilla, Opera, Konqueror, better than all of them. > 90% of Mac users use Safari or a Mozilla variant, and > those should be the people to concentrate on. 90% of OS X users. There are still plenty of people out there using OS 9. As a percentage of the web they may be small, but they are there. IE5 mac is remains the best browser available for OS 9. The last versions of Mozilla available on OS 9 were around Mozilla 1.3 IIRC, and at that point Mozilla was still bloated and buggy. > You have to bear in mind that IE users on the Mac are used to websites > not working properly. Nonsense. I find most of them still work fairly well, its really only quite advanced CSS layouts that start to break. > Not because the designers do it wrong, but > because the browser is sht. Not true. That's really over stepping the mark. IE5mac is a solid browser. So good that despite my antipathy to Microsoft it was my main browser on OS 9 for quite some time, and even on OS X when it first came out. Yes it's a dead browser. Yes OS 9 is a dead OS. Yes it has some shortcomings in the CSS department. Yes it has other major flaws (can't control plugins with javascript for one). Both have been superseded by better things. But lets not reject IE5mac on the basis of opinionated foul-mouthed nonsense like this. We're about building communities, and communities are diverse things. There are workarounds if the problem is with CSS, eg: http://www.premonition.co.uk/cssd/ie51-only.html Javascript gets a bit trickier, but we try to make sure that degrades gracefully anyway. It all boils down to this - IE5mac is decent browser used by people on an old OS, they make up a small and diminishing part of the webs population. If there is a simple and quick way of fixing problems with it then lets support it, and conversely if it's taking too much time to fix let it go. But at least make an informed decision instead of rejecting it out of hand. -- adrinux (aka Adrian Simmons) e-mail AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com From dries at buytaert.net Mon Nov 14 23:07:01 2005 From: dries at buytaert.net (Dries Buytaert) Date: Mon Nov 14 23:07:12 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <20051114204654.d2cef345.ber@webschuur.com> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> <4378ABAF.8060306@walkah.net> <20051114204654.d2cef345.ber@webschuur.com> Message-ID: <2B8D1E92-BFD7-4A99-88F0-99CE043541D0@buytaert.net> On 14 Nov 2005, at 20:46, Ber Kessels wrote: > It is what got that form API in. It is what holds back Those Big > Issues from leveraging from yadiyadia level to Real Code Level, > think drupal.css, think taxonomy.module cleanup, think CCK ideals, > think install API. etcetc. Erm, the CCK plans are pretty well documented. They have been for about a year. Similarly, the install API has been documented too. Your examples show that central documentation is no guarantee for success (however they are often a necessary step). > I firmly beleive we reached a level where we can no longer deal > with Big Changes, unless we form subgroups. Which, again, is what I > got, this is all about. I hope so in any way. I firmly believe in people organizing themselves, and empowering them to do so. I do not believe in forcing people to write proposals. There are much larger projects than Jabber, Xaraya, PEAR or Python that are known to be successful without having proposals. Two random examples are the Linux kernel and KDE. Feel free to write a proposal for the drupal.css or taxonomy.module clean up, or to get consensus before you start writing code. I'm cool with that. It's just not mandatory. -- Dries Buytaert :: http://www.buytaert.net/ From justin at buddyping.com Mon Nov 14 23:10:32 2005 From: justin at buddyping.com (Justin Davies) Date: Mon Nov 14 23:10:38 2005 Subject: [development] Re: [CS dev] Help with a CivicSpace Theme Layout... (Read it, you know you want to! :) In-Reply-To: <43791527.4000100@gmail.com> References: <43755749.4000209@occy.net> <1F298344-E0CE-417F-BE0F-B4B8DB7F3110@culturekitchen.com> <1131981149.21921.24.camel@localhost.localdomain> <20051114204959.c9299a9d.ber@webschuur.com> <1131999372.21921.28.camel@localhost.localdomain> <4378F2CE.4010104@hojtsy.hu> <4C4116C6-ECC3-45C6-9039-C70CA5BEDD2D@buddyping.com> <43791527.4000100@gmail.com> Message-ID: <4C50F6FB-55FF-4048-9C51-B761B84D3E7D@buddyping.com> Adrian, I did not mean my response to be foul mouthed, but we both got the same conclusion: if it is too much hassle let it go. We just got there through different routes. I did not mean to offend anyone with my response. I am fully aware of having to accommodate what I would term "legacy" systems, but unfortunately the web is not a case of lowest common denominator like some systems, but rather the most widely used systems, and IE5 on OS9/X is not it. If it is a case of "a few minutes and it will work on IE5", then I am all for people trying to support it. If it is a case that it takes 2 more weeks to push a feature, or design, then it really is a waste of time for all concerned when talking about the number we are talking about. Justin On 14 Nov 2005, at 22:52, Adrian Simmons wrote: > Justin Davies wrote: >> In all honesty, I don't think you have to worry about old Macs. > Well, maybe, maybe not. It really all depends on a particular site > and what the audience uses. Macs are reliable, they often go on for > years and years. There are plenty out there still in active use. > >> forcing people away from an old, non-standards based browser on a >> very old Mac is not going to loose too many users. > I hate to be in the position of defending a Microsoft browser but > lets set some records straight here. > > IE5 mac is an entirely different product from IE5 on Windows. > At the time IE5 mac was released it had the* most complete web > standards support of any available browser. Better than Mozilla, > Opera, Konqueror, better than all of them. > >> 90% of Mac users use Safari or a Mozilla variant, and those should >> be the people to concentrate on. > 90% of OS X users. There are still plenty of people out there > using OS 9. As a percentage of the web they may be small, but they > are there. IE5 mac is remains the best browser available for OS 9. > The last versions of Mozilla available on OS 9 were around Mozilla > 1.3 IIRC, and at that point Mozilla was still bloated and buggy. > >> You have to bear in mind that IE users on the Mac are used to >> websites not working properly. > Nonsense. I find most of them still work fairly well, its really > only quite advanced CSS layouts that start to break. > >> Not because the designers do it wrong, but because the browser is >> sht. > Not true. That's really over stepping the mark. IE5mac is a solid > browser. So good that despite my antipathy to Microsoft it was my > main browser on OS 9 for quite some time, and even on OS X when it > first came out. > > Yes it's a dead browser. Yes OS 9 is a dead OS. Yes it has some > shortcomings in the CSS department. Yes it has other major flaws > (can't control plugins with javascript for one). Both have been > superseded by better things. But lets not reject IE5mac on the > basis of opinionated foul-mouthed nonsense like this. > > We're about building communities, and communities are diverse things. > > There are workarounds if the problem is with CSS, eg: http:// > www.premonition.co.uk/cssd/ie51-only.html > > Javascript gets a bit trickier, but we try to make sure that > degrades gracefully anyway. > > It all boils down to this - IE5mac is decent browser used by people > on an old OS, they make up a small and diminishing part of the webs > population. If there is a simple and quick way of fixing problems > with it then lets support it, and conversely if it's taking too > much time to fix let it go. But at least make an informed decision > instead of rejecting it out of hand. > > -- > adrinux (aka Adrian Simmons) > e-mail > AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com From drupal.org at juggernaut.com.au Mon Nov 14 23:33:32 2005 From: drupal.org at juggernaut.com.au (Richard Archer) Date: Mon Nov 14 23:36:05 2005 Subject: [development] Re: [CS dev] Help with a CivicSpace Theme Layout... (Read it, you know you want to! :) In-Reply-To: <76EF8B41-8E06-4A05-96B3-A3CD2FE4E0A6@buddyping.com> References: <43755749.4000209@occy.net> <1F298344-E0CE-417F-BE0F-B4B8DB7F3110@culturekitchen.com> <1131981149.21921.24.camel@localhost.localdomain> <20051114204959.c9299a9d.ber@webschuur.com> <1131999372.21921.28.camel@localhost.localdomain> <4378F2CE.4010104@hojtsy.hu> <4C4116C6-ECC3-45C6-9039-C70CA5BEDD2D@buddyping.com> <20051114215902.befbb371.ber@webschuur.com> <76EF8B41-8E06-4A05-96B3-A3CD2FE4E0A6@buddyping.com> Message-ID: At 9:19 PM +0000 14/11/05, Justin Davies wrote: >It is the same thing as asking how many Apple G3 processor machines >are out there? Maybe 1% of Macs ? If that is that case, does that >mean you have to sacrifice the speed of delivery for 99% of people >because you need to make it work for the 1% ? Here are some real stats for two sites: Site 1: 43,703 out of 2,830,400 hits (1.54%) were IE5/Mac users. Site 2: 23,175 out of 2,678,670 hits (0.09%) were IE5/Mac users. Nearly half the Mac users were using IE5. ...R. From occy at occy.net Mon Nov 14 23:52:44 2005 From: occy at occy.net (Trae McCombs) Date: Mon Nov 14 23:52:37 2005 Subject: [development] Re: [CS dev] Help with a CivicSpace Theme Layout... (Read it, you know you want to! :) In-Reply-To: References: <43755749.4000209@occy.net> <1F298344-E0CE-417F-BE0F-B4B8DB7F3110@culturekitchen.com> <1131981149.21921.24.camel@localhost.localdomain> <20051114204959.c9299a9d.ber@webschuur.com> <1131999372.21921.28.camel@localhost.localdomain> <4378F2CE.4010104@hojtsy.hu> <4C4116C6-ECC3-45C6-9039-C70CA5BEDD2D@buddyping.com> <20051114215902.befbb371.ber@webschuur.com> <76EF8B41-8E06-4A05-96B3-A3CD2FE4E0A6@buddyping.com> Message-ID: <1132012365.21921.35.camel@localhost.localdomain> Ok, I'm sorry I started this thread. I think we should take this off-line to IRC or something. This is opening a keg of nails and you aren't going to get people to agree on this subject. Thanks, Trae On Tue, 2005-11-15 at 10:33 +1100, Richard Archer wrote: > At 9:19 PM +0000 14/11/05, Justin Davies wrote: > > >It is the same thing as asking how many Apple G3 processor machines > >are out there? Maybe 1% of Macs ? If that is that case, does that > >mean you have to sacrifice the speed of delivery for 99% of people > >because you need to make it work for the 1% ? > > Here are some real stats for two sites: > > Site 1: 43,703 out of 2,830,400 hits (1.54%) were IE5/Mac users. > Site 2: 23,175 out of 2,678,670 hits (0.09%) were IE5/Mac users. > > Nearly half the Mac users were using IE5. > > ...R. -- Trae "occy" McCombs || http://occy.net/ Founder - Themes.org // Linux.com CivicSpaceLabs - http://civicspacelabs.org/ From adrian at bryght.com Tue Nov 15 00:18:49 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Tue Nov 15 00:19:01 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <2B8D1E92-BFD7-4A99-88F0-99CE043541D0@buytaert.net> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> <4378ABAF.8060306@walkah.net> <20051114204654.d2cef345.ber@webschuur.com> <2B8D1E92-BFD7-4A99-88F0-99CE043541D0@buytaert.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15 Nov 2005, at 1:07 AM, Dries Buytaert wrote: > > On 14 Nov 2005, at 20:46, Ber Kessels wrote: >> It is what got that form API in. It is what holds back Those Big >> Issues from leveraging from yadiyadia level to Real Code Level, >> think drupal.css, think taxonomy.module cleanup, think CCK ideals, >> think install API. etcetc. > > Erm, the CCK plans are pretty well documented. They have been for > about a year. Similarly, the install API has been documented too. > Your examples show that central documentation is no guarantee for > success (however they are often a necessary step). I agree. DEP's should not be required, but are a tool which can, and should be used for larger tasks. I would also like to see DEPs used to pool our ideas together, so that you can develop and spec enhancements that you might not personally have a chance to develop fully, but which other people might be interested in working on. Writing a DEP is at least providing a solid starting point for someone else to expand on and develop from. Also, all DEPs won't be developed, but something that has a DEP has a higher chance of being developed than something which doesn't have it. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDeSlqgegMqdGlkasRArKfAJ0VoCT6sigkkg0/rW9tjdqfb2tVUACgxAhs zo1V5hHT5Gqm3rEJwyrAkkY= =XRUf -----END PGP SIGNATURE----- From puregin at puregin.org Tue Nov 15 00:24:34 2005 From: puregin at puregin.org (puregin) Date: Tue Nov 15 00:24:39 2005 Subject: [development] Re: [CS dev] Help with a CivicSpace Theme Layout... (Read it, you know you want to! :) In-Reply-To: <43791527.4000100@gmail.com> References: <43755749.4000209@occy.net> <1F298344-E0CE-417F-BE0F-B4B8DB7F3110@culturekitchen.com> <1131981149.21921.24.camel@localhost.localdomain> <20051114204959.c9299a9d.ber@webschuur.com> <1131999372.21921.28.camel@localhost.localdomain> <4378F2CE.4010104@hojtsy.hu> <4C4116C6-ECC3-45C6-9039-C70CA5BEDD2D@buddyping.com> <43791527.4000100@gmail.com> Message-ID: <49D08E27-A826-436C-8ABE-FD0371F18917@puregin.org> On 14 Nov 2005, at 2:52 PM, Adrian Simmons wrote: > Justin Davies wrote: >> In all honesty, I don't think you have to worry about old Macs. > Well, maybe, maybe not. It really all depends on a particular site > and what the audience uses. Macs are reliable, they often go on for > years and years. There are plenty out there still in active use. > Hmm, unless you have a need to support old mac users in particular, I wouldn't feel too guilty about dropping support for Mac IE5 (OS9/OS X). After all, both Microsoft and Apple dropped support for it long ago. Djun P.S. on a 'would be funny if it weren't so painful' note - I had to use a provincial government/ public service site the other day that refused to let me use anything other than IE5+. When I complained, the person responsible told me this policy was 'to ensure security' :) I elected to transact my correspondence via snail mail. From walkah at walkah.net Tue Nov 15 00:47:28 2005 From: walkah at walkah.net (James Walker) Date: Tue Nov 15 00:52:25 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <2B8D1E92-BFD7-4A99-88F0-99CE043541D0@buytaert.net> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> <4378ABAF.8060306@walkah.net> <20051114204654.d2cef345.ber@webschuur.com> <2B8D1E92-BFD7-4A99-88F0-99CE043541D0@buytaert.net> Message-ID: <43793020.8090702@walkah.net> On 11/14/05 6:07 PM, Dries Buytaert wrote: > > On 14 Nov 2005, at 20:46, Ber Kessels wrote: >> It is what got that form API in. It is what holds back Those Big >> Issues from leveraging from yadiyadia level to Real Code Level, think >> drupal.css, think taxonomy.module cleanup, think CCK ideals, think >> install API. etcetc. > > Erm, the CCK plans are pretty well documented. They have been for about > a year. Similarly, the install API has been documented too. Your > examples show that central documentation is no guarantee for success > (however they are often a necessary step). > Hrm. this is a good point ... and has made me rethink my position a bit. The thing biggest thing I think i'd like to see come from this idea, is a centralized mechanism for doing such organizing. My reasoning is this - using myself as an example - there are several "bigger projects" underway, that I know of because I'm pretty involved in the community, but I'm not directly involved in them all... however, they will have fairly large impact on my work (thinking of CCK and install , e.g.). Therefore, it would be really nice to have a place where i could go to check up on the projects (and, perhaps, discover some new ones). The community is becoming very large for any one person to keep tabs on it all... this might help, no? But you're right. I withdraw my previous requirement comment. I think the important thing is not that DEPs are required - because then we end up in the rathole of which* changes require DEPs. However, central organization would be very helpful. And i mean beyond "but it's all on drupal.org". As wonderful as steven's search patches are... it's not quite a one page overview :P >> I firmly beleive we reached a level where we can no longer deal with >> Big Changes, unless we form subgroups. Which, again, is what I got, >> this is all about. I hope so in any way. > > I firmly believe in people organizing themselves, and empowering them to > do so. I do not believe in forcing people to write proposals. There > are much larger projects than Jabber, Xaraya, PEAR or Python that are > known to be successful without having proposals. Two random examples > are the Linux kernel and KDE. This is incredibly well said. But i do think empowering the proposals could prove to be very... well... powerful. but, who am I kidding... I'd be the first to whine about having to write these things :P The other thing - and I realize now it's a bit tangential - but I'd like to see a more transparent contributer approval process. but , i'll leave that for another thread some day... > Feel free to write a proposal for the drupal.css or taxonomy.module > clean up, or to get consensus before you start writing code. I'm cool > with that. It's just not mandatory. > -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net From gerhard at killesreiter.de Tue Nov 15 01:00:00 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Tue Nov 15 01:01:06 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <43793020.8090702@walkah.net> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> <4378ABAF.8060306@walkah.net> <20051114204654.d2cef345.ber@webschuur.com> <2B8D1E92-BFD7-4A99-88F0-99CE043541D0@buytaert.net> <43793020.8090702@walkah.net> Message-ID: <43793310.1010208@killesreiter.de> James Walker wrote: > The other thing - and I realize now it's a bit tangential - but I'd > like to see a more transparent contributer approval process. but , > i'll leave that for another thread some day... I think having the applicants write some multi-volumen application proposal in advance of evalutating their application would be very effective in lowering the number of applications. So I am all for it. :) Cheers, Gerhard From walkah at walkah.net Tue Nov 15 01:06:43 2005 From: walkah at walkah.net (James Walker) Date: Tue Nov 15 01:11:39 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <43793310.1010208@killesreiter.de> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> <4378ABAF.8060306@walkah.net> <20051114204654.d2cef345.ber@webschuur.com> <2B8D1E92-BFD7-4A99-88F0-99CE043541D0@buytaert.net> <43793020.8090702@walkah.net> <43793310.1010208@killesreiter.de> Message-ID: <437934A3.104@walkah.net> On 11/14/05 8:00 PM, Gerhard Killesreiter wrote: > James Walker wrote: > >> The other thing - and I realize now it's a bit tangential - but I'd >> like to see a more transparent contributer approval process. but , >> i'll leave that for another thread some day... > > > I think having the applicants write some multi-volumen application > proposal in advance of evalutating their application would be very > effective in lowering the number of applications. So I am all for it. :) this is indeed a (healthy?) side effect. it's not just about lowering the number of applications, but trying to maintain a higher level of applications... i'm also passively curious - of our 300+ cvs contributors how many stay active? -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net From zacker at skylinepublicworks.com Tue Nov 15 01:13:12 2005 From: zacker at skylinepublicworks.com (Zack Rosen) Date: Tue Nov 15 01:13:09 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> Message-ID: I will be trying to raise hundreds of thousands of dollars over the next year to support Drupal core development. Having a working DEP process in place will make my job multitudes easier. -Zack On Nov 12, 2005, at 11:41 AM, Adrian Rossouw wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I need to preface this by saying that I don't think our current > community processes are 'broken' per se, since they have > obviously brought us this far, however I have noticed some areas in > which there could be improvement and I would like > to make some suggestions towards getting a smoother development > cycle for all of us. My primary interest with this > proposal is to foster co-operation, and allow us to better manage > the project in the future. > > I feel that one of the primary problems we have is that there is > not enough co-operation between different developers, > and I feel that this problem stems from lack of communication. Up > to this point, communication has been strictly > informal. This has the benefit of not tying up people doing ground > work, and is essentially an extension of our > 'talk is silver, code is gold' mantra. And this is great. Good > working code is our primary goal, and it has suited > our goals up to this point perfectly. > > The problem with this however is, that it does not scale. With one, > or even two people on the project it might work, but the > moment you get more than that involved, communication becomes a lot > more work than it should be. > The other problem is that communication on projects like these tend > to be on a personal level, and the only way > to get more developers involved in the project is either through > direct requests, or constant badgering on the forums/irc. > > Even if you do get someone else interested, getting that person up > to date on the goals and status of the project , and to become a > contributing > member is still a lot of work. Also, the only way for an external > developer to become involved in such an on-going project is > to search the forums, find people who might even be remotely > interested in the same thing, go talk to people on irc, see if > anything > is being done in whichever direction they intend to work in. It's a > lot of work, and most developers don't bother. They end up > re-inventing the wheel, because it's really hard for them to get > accurate information about what's going on in the Drupal community. > > What I would like to suggest, is that we introduce a proposal > system, whereby we create an official proposal document for > any large changes we undertake as a community. This process would > be modelled on the jabber.org JEP process, which > in turn is modelled on the IETF process. > > What we would essentially do is create a document, that has an > official number, a status and an owner. This document > would be modelled on JEPs (http://www.jabber.org/jeps/ > jep-0143.html), and would explain the basic goals of the project, > reasoning behind it, requirements, security considerations and so > forth. > > How I imagine the basic workflow would be, is that someone writes a > proposal, in the correct format, that gets published as a draft. > At a certain point the draft then gets sent to drupal-devel, and > developer comments are factored in. Then it gets published on > Drupal.org, and user comments get factored in. At this point, we > have a proposed DEP, and anyone who has any interest > in working towards that knows what has been decided to be the best > approach, who is working on it, and what is the status of it. > > Another thing that led me to this conclusion, was the recent > discussion about the formation of the 'theme team', which I felt > was not actually aligned with our goals. We already have a theme > forum, which doesn't see much action, since I think > the informal communication has proven to not be adequate. > > What the proposal structure would do, is allow us to create SIG's > (special interest groups), whose purpose would be to > foster discussion, and create proposals with a certain goal in mind > (ie: theme sig, usability sig, localisation sig, etc.) > > Benefits : > For Developers : > Lessens duplicated efforts. > Has a summary of the current status of things. > Allows us to collaboratively map out what we are working towards. > It's an actual spec, and although there is such a thing as > feature creep, at least we know when it's 'done' > > For Documentation : > Provides reference information for the design and > implementation of features. > > For End Users : > A more transparent view of where we are heading, what changes > we are making and why. > More eyes, which might bring up more issues, helping the > design along. > Get them more involved with the project, without having to > wade through the forums. > > For Investors : > Allows investors to see projects within the community and > financially support the right people towards meeting their goals. > Creates a common process to interface commercial and community > developers with each other. > Reverse bounties. > > For Dries : > Allows for more accurate roadmaps. (ie: DEPs 0341 and 0342 are > destined to be in the next release) > Knowing the status of things. > > For all of us : > Gives us a better map of people's interests. > More visibility to what you are busy doing, and it might make > you some money. > > One thing I should say, is that I am not trying to stop us from > developing the way we are now, it's not broken, > i'm not trying to fix it. What I am saying is that we could make > this more formal path available, to allow us to > collaborate more effectively on things. > > I am also not trying to bog down what we do. Implementing for now > could simply be a book page that > we maintain as we are involved in the project. I have some ideas in > the future to expand the integration > in a meaningful way, but that's probably a topic for a DEP of it's > own. > > Just because we are documenting what we are doing, doesn't mean we > can't write code while we're doing it. > We're obviously going to have times when we have a couple of > different implimentations of the same thing > competing with each other, provided they are different enough > approaches... but that's healthy. > > I am also not saying that we will get this right the first time, > but what I propose is that we set up such a process > and then create a DEP 0001 which is the dep handling the community > process, and after every release we > review it again and make revisions based on what worked and what > didn't. I really feel that if we decide on > a method we need to stick with it for a while though. > > So these are some of my thoughts, and I would love to have the > community's opinion on the idea. > > - -- > Adrian Rossouw > Drupal developer and Bryght Guy > http://drupal.org | http://bryght.com > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (Darwin) > > iD8DBQFDdkV3gegMqdGlkasRAr+aAKCoGKZ8hnqtqDm658DJBX5USTQ0fgCeI1tw > rY2I2L6dSV6MBGuO767Jazk= > =Z4mD > -----END PGP SIGNATURE----- > > From steven at acko.net Tue Nov 15 01:43:29 2005 From: steven at acko.net (Steven Wittens) Date: Tue Nov 15 01:43:31 2005 Subject: [development] Re: Form API updater In-Reply-To: References: Message-ID: <43793D41.6040009@acko.net> Nice, but it seems to output constants rather than strings (judging from the screenshot and code): array( #type => 'foo' ); there should be quotes around #type. I think the following will fix it: - $argsout[] = "$key => $val"; + $argsout[] = "'$key' => $val"; Steven Wittens From gerhard at killesreiter.de Tue Nov 15 02:49:39 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Tue Nov 15 02:50:46 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <437934A3.104@walkah.net> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> <4378ABAF.8060306@walkah.net> <20051114204654.d2cef345.ber@webschuur.com> <2B8D1E92-BFD7-4A99-88F0-99CE043541D0@buytaert.net> <43793020.8090702@walkah.net> <43793310.1010208@killesreiter.de> <437934A3.104@walkah.net> Message-ID: <43794CC3.9000003@killesreiter.de> James Walker wrote: > On 11/14/05 8:00 PM, Gerhard Killesreiter wrote: > >> James Walker wrote: >> >>> The other thing - and I realize now it's a bit tangential - but I'd >>> like to see a more transparent contributer approval process. but , >>> i'll leave that for another thread some day... >> >> >> >> I think having the applicants write some multi-volumen application >> proposal in advance of evalutating their application would be very >> effective in lowering the number of applications. So I am all for it. :) > > > this is indeed a (healthy?) side effect. it's not just about lowering > the number of applications, but trying to maintain a higher level of > applications... i'm also passively curious - of our 300+ cvs > contributors how many stay active? Good question. First of all we are just three short of 400 approved accounts. The cvs admin screen only shows the date of the first, the most recent commit, and the total of commits. There are quite a few accounts (146!) that were never used. I wonder if that is correct. Ax Kollmorgen used to run cvsmonitor at drupal.kollm.org, but apparently he only does that for core nowadays. Cheers, Gerhard From drupal.org at juggernaut.com.au Tue Nov 15 03:17:51 2005 From: drupal.org at juggernaut.com.au (Richard Archer) Date: Tue Nov 15 03:17:27 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) Message-ID: At 8:06 PM -0500 14/11/05, James Walker wrote: >applications... i'm also passively curious - of our 300+ cvs >contributors how many stay active? There has been 119 unique people commit to CVS since I subscribed to the cvs list on 22 September. ...R. From weitzman at tejasa.com Tue Nov 15 03:20:31 2005 From: weitzman at tejasa.com (Moshe Weitzman) Date: Tue Nov 15 03:20:34 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> Message-ID: <437953FF.7010403@tejasa.com> Zack Rosen wrote: > I will be trying to raise hundreds of thousands of dollars over the next > year to support Drupal core development. Having a working DEP process > in place will make my job multitudes easier. > > -Zack two hundred thousand for me and my family would really help out. thanks zack. in all seriousness, it would be helpful to get a list from civicspace and bryght and all those who funnel money into the project. the list would itemize infrastructure improvements that would help their fundraising efforts. if you construct such a list, please post the link the infrastructure mailing list. -moshe From drupal.org at juggernaut.com.au Tue Nov 15 03:29:26 2005 From: drupal.org at juggernaut.com.au (Richard Archer) Date: Tue Nov 15 03:30:04 2005 Subject: [development] Introduction Message-ID: Greetings, I've been hanging around for a couple of months now, but I recently had a CVS account approved so a more formal introduction is called for, I believe. My background is in network and unix system management. I have some rusty skills in SunOS, Solaris, AIX and Cisco IOS and current Linux skills. I have also done quite a bit of programming over the years in all sorts of languages, but mostly in MC68000 assembly, C, Perl, PHP and I guess shell script qualifies too. I can find my way around most programming languages and operating systems. I'm self-employed, running a one-man show, although I contract work out occasionally when I get very busy. The core of my business has been building and hosting static sites with the occasional shopping cart system or basic CMS interface. This side of the business is slowly drying up though, as everyone wants to be able to build and update their own sites through a proper CMS. So I intend to begin offering a CMS-based hosting package within the next year. This is (funnily enough) going to be Drupal-based. When working on Drupal my focus will be on core features that I need in order to meet the requirements of my customers or to make my life as service provider easier. Things like primary links, which almost every site has to have, enhancements to the menu system, better themability and ease-of-use of the admin interface. I will also be helping Matteo with maintaining the Inline module. Support for images is sadly lacking in Drupal, and I think Inline forms a very nice, simple foundation for allowing images to be easily placed into pages. ...Richard. From john at handelaar.org Tue Nov 15 03:30:26 2005 From: john at handelaar.org (John Handelaar) Date: Tue Nov 15 03:30:44 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <437934A3.104@walkah.net> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> <4378ABAF.8060306@walkah.net> <20051114204654.d2cef345.ber@webschuur.com> <2B8D1E92-BFD7-4A99-88F0-99CE043541D0@buytaert.net> <43793020.8090702@walkah.net> <43793310.1010208@killesreiter.de> <437934A3.104@walkah.net> Message-ID: <43795652.8040908@handelaar.org> James Walker wrote: > On 11/14/05 8:00 PM, Gerhard Killesreiter wrote: >> >> I think having the applicants write some multi-volumen application >> proposal in advance of evalutating their application would be very >> effective in lowering the number of applications. So I am all for it. :) > > this is indeed a (healthy?) side effect. it's not just about lowering > the number of applications, but trying to maintain a higher level of > applications... i'm also passively curious - of our 300+ cvs > contributors how many stay active? I'd wager it has no effect on module developers at all, but increases the number of people who get involved with core. Certainly I'm not about to spend time on core hacking when I'm not sure if the Magic Hand of Dries(tm) will approve it in the end. Obviously if he doesn't, I'm wasting my time. But if I'm contributing to an agreed project, that worry no longer applies. I don't mind having stuff sent back if it's wrongly formatted, but I would mind having something for core written and then rejected as not something Dries wants to commit for some other reason. [Maybe Dries never does that. I have no idea one way or another. That, in its own way, is yet another reason for this idea to go forward.] jh From nedjo at islandnet.com Tue Nov 15 04:05:08 2005 From: nedjo at islandnet.com (Nedjo Rogers) Date: Tue Nov 15 04:05:27 2005 Subject: [development] replace drupal.js with prototype.js? Message-ID: <005d01c5e999$c452dc80$6400a8c0@family> I really like the approaches implemented in drupal.js. But I've been wondering--would we do better to use the now widely supported, and excellently designed, Prototype library (http://prototype.conio.net/ -- see documentation e.g. at http://www.sergiopereira.com/articles/prototype.js.html) instead? The advantages would be that we'd be using a well supported open source library, rather than our own (nice, but not used elsewhere) solution. Doing so would allow Drupal developers to use the ever-expanding range of Prototype-based libraries, including: moofx http://moofx.mad4milk.net/ behaviour http://bennolan.com/behaviour/ scriptaculous http://script.aculo.us We'd still need some custom drupal methods, but we could reduce them to a minimum. We could also draw on other open source CMS etc. softwares using Prototype, e.g, Ruby on Rails. Doing so would require some refactoring of our existing javascript (autoexpand, etc.), but really not so much. And we'd be able to take advantage of some great features and methods in Prototype and its related libraries. Prototype and its relatives are "MIT style" licensed, presumably GPL compatible, http://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses. Thoughts? From sdondley at gmail.com Tue Nov 15 05:52:25 2005 From: sdondley at gmail.com (Steve Dondley) Date: Tue Nov 15 05:52:26 2005 Subject: [development] Give a guy some love! (or at least some attention) Message-ID: <36b9121d0511142152u3091e3fdn7d3279d3c01fc89f@mail.gmail.com> Even if you think the patch at http://drupal.org/node/37283 sucks, I want to know! From kkaefer at gmail.com Tue Nov 15 07:36:34 2005 From: kkaefer at gmail.com (=?ISO-8859-1?Q?Konstantin_K=E4fer?=) Date: Tue Nov 15 07:36:36 2005 Subject: [development] replace drupal.js with prototype.js? In-Reply-To: <005d01c5e999$c452dc80$6400a8c0@family> References: <005d01c5e999$c452dc80$6400a8c0@family> Message-ID: <3ff472c00511142336g7c64bdeds@mail.gmail.com> Hi, +1 on this; I really like programming with the prototype library. Regards, Konstantin K?fer 2005/11/15, Nedjo Rogers : > I really like the approaches implemented in drupal.js. > > But I've been wondering--would we do better to use the now widely supported, > and excellently designed, Prototype library (http://prototype.conio.net/ -- > see documentation e.g. at > http://www.sergiopereira.com/articles/prototype.js.html) instead? > > The advantages would be that we'd be using a well supported open source > library, rather than our own (nice, but not used elsewhere) solution. Doing > so would allow Drupal developers to use the ever-expanding range of > Prototype-based libraries, including: > > moofx http://moofx.mad4milk.net/ > behaviour http://bennolan.com/behaviour/ > scriptaculous http://script.aculo.us > > We'd still need some custom drupal methods, but we could reduce them to a > minimum. > > We could also draw on other open source CMS etc. softwares using Prototype, > e.g, Ruby on Rails. > > Doing so would require some refactoring of our existing javascript > (autoexpand, etc.), but really not so much. And we'd be able to take > advantage of some great features and methods in Prototype and its related > libraries. > > Prototype and its relatives are "MIT style" licensed, presumably GPL > compatible, > http://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses. > > Thoughts? > > -- http://timcn.de From dries at buytaert.net Tue Nov 15 08:02:41 2005 From: dries at buytaert.net (Dries Buytaert) Date: Tue Nov 15 08:02:50 2005 Subject: [development] Introduction In-Reply-To: References: Message-ID: <20FD2C4A-B4BD-45F7-AFA7-D09E18AD0EAB@buytaert.net> On 15 Nov 2005, at 04:29, Richard Archer wrote: > My background is in network and unix system management. I have > some rusty skills in SunOS, Solaris, AIX and Cisco IOS and current > Linux skills. I have also done quite a bit of programming over the > years in all sorts of languages, but mostly in MC68000 assembly, C, > Perl, PHP and I guess shell script qualifies too. I can find my way > around most programming languages and operating systems. Welcome on board, Richard. The fact you managed to tackle the primary/secondary link work, as well as some menu system internals, makes for a great introduction. We could use some more core developers, so thanks for choosing Drupal. -- Dries Buytaert :: http://www.buytaert.net/ From dries at buytaert.net Tue Nov 15 08:22:38 2005 From: dries at buytaert.net (Dries Buytaert) Date: Tue Nov 15 08:22:50 2005 Subject: [development] Drupal-related podcasts Message-ID: <1B56B8B9-18E4-47BE-B962-BB5630210DFC@buytaert.net> http://www.echochamberproject.com/node/690 http://www.echochamberproject.com/node/691 -- Dries Buytaert :: http://www.buytaert.net/ From vlado at dikini.net Tue Nov 15 10:08:43 2005 From: vlado at dikini.net (vlado) Date: Tue Nov 15 10:08:51 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <20051114204654.d2cef345.ber@webschuur.com> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> <4378ABAF.8060306@walkah.net> <20051114204654.d2cef345.ber@webschuur.com> Message-ID: <1132049323.4740.12.camel@localhost.localdomain> > But IMNSHO going for a "tackle this issue together" system is what we should aim for, in the first place. Yes, and the documentation, ideas place, the rest will be a good side effect of this. > I firmly beleive we reached a level where we can no longer deal with Big Changes, unless we form subgroups. > Which, again, is what I got, this is all about. I hope so in any way. Subgroups as in tagreted development, I suppose. The way the form api was developed. I don't like the idea of formalising as in adding a formal layer. This will definitely scare people off. Or just piss them off. Please, keep the "technocrats" away :) Generally I'm all for such proposal, regardless the name. Because they could be helpful to keep yourself informed. A reference point and a contacts point. Vlado From adrian at bryght.com Tue Nov 15 11:01:52 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Tue Nov 15 11:02:58 2005 Subject: [development] subversion Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You guys know we could so rock with subversion / drupal integration. right ? http://pecl.php.net/package/svn http://php5.akbkhome.com:81/svn.php - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDecAhgegMqdGlkasRAqTQAJwNUGQBkonY5onX1zgl4zC0V07oPwCguWA7 kXo5tVM5Cfu2ymHcgRHb3c0= =tAlz -----END PGP SIGNATURE----- From gerhard at killesreiter.de Tue Nov 15 11:06:18 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Tue Nov 15 11:07:24 2005 Subject: [development] subversion In-Reply-To: References: Message-ID: <4379C12A.1070805@killesreiter.de> Adrian Rossouw wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > You guys know we could so rock with subversion / drupal integration. > right ? > > > http://pecl.php.net/package/svn > http://php5.akbkhome.com:81/svn.php > The one and only issue I have with svn is that it does not have a usefull equivalent to the -p flag. I know there is a langthy equivalent for this, but this is not about patches tat I create but abotu patches that I receive and need to review. Cheers, Gerhard From adrian at bryght.com Tue Nov 15 11:19:21 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Tue Nov 15 11:19:35 2005 Subject: [development] subversion In-Reply-To: <4379C12A.1070805@killesreiter.de> References: <4379C12A.1070805@killesreiter.de> Message-ID: <4BF1D26D-5977-4EB7-9DCD-F1B3EBC54D52@bryght.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15 Nov 2005, at 1:06 PM, Gerhard Killesreiter wrote: > > The one and only issue I have with svn is that it does not have a > usefull equivalent to the -p flag. I know there is a langthy > equivalent for this, but this is not about patches tat I create but > abotu patches that I receive and need to review. And it's been discussed to death and there's very good reason for applying patches that have been uploaded to the latest source, and then flagging ones that don't apply anymore and during this process we can re-create the patch in the correct way, and probably even run the code style script on them. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDecQ6gegMqdGlkasRAuuEAKCw7TXdgDmA5JyfMP2EiHcy6U3yawCgp4bt AOZKW4qgpSqHtLqzHYKUIZs= =3c18 -----END PGP SIGNATURE----- From gerhard at killesreiter.de Tue Nov 15 11:31:11 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Tue Nov 15 11:32:20 2005 Subject: [development] subversion In-Reply-To: <4BF1D26D-5977-4EB7-9DCD-F1B3EBC54D52@bryght.com> References: <4379C12A.1070805@killesreiter.de> <4BF1D26D-5977-4EB7-9DCD-F1B3EBC54D52@bryght.com> Message-ID: <4379C6FF.3010002@killesreiter.de> Adrian Rossouw wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 15 Nov 2005, at 1:06 PM, Gerhard Killesreiter wrote: > >> >> The one and only issue I have with svn is that it does not have a >> usefull equivalent to the -p flag. I know there is a langthy >> equivalent for this, but this is not about patches tat I create but >> abotu patches that I receive and need to review. > > And it's been discussed to death and there's very good reason for > applying patches that have been uploaded to the latest source, and > then flagging ones that don't apply anymore > > and during this process we can re-create the patch in the correct > way, and probably even run the code style script on them. Yeah, we have been discussing this in the bus in Brussels. I don't see anybody coding this. Cheers, Gerhard From adrian at bryght.com Tue Nov 15 11:40:23 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Tue Nov 15 11:40:37 2005 Subject: [development] subversion In-Reply-To: <4379C6FF.3010002@killesreiter.de> References: <4379C12A.1070805@killesreiter.de> <4BF1D26D-5977-4EB7-9DCD-F1B3EBC54D52@bryght.com> <4379C6FF.3010002@killesreiter.de> Message-ID: <2AB56BDF-BB67-4858-88AF-0B95D5AE49CA@bryght.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15 Nov 2005, at 1:31 PM, Gerhard Killesreiter wrote: > Yeah, we have been discussing this in the bus in Brussels. I don't > see anybody coding this. maybe because we haven't officially decided to move to svn yet. me, and probably darix, wouldn't mind coding this, but we refuse to do so for cvs. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDeckngegMqdGlkasRAm7aAJ9VaHW2ttwnPItftQYM+Nj6ajb3dQCeKryl YjORaQu1C795AYZReM9Fing= =dj3i -----END PGP SIGNATURE----- From gerhard at killesreiter.de Tue Nov 15 11:54:14 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Tue Nov 15 11:55:27 2005 Subject: [development] subversion In-Reply-To: <2AB56BDF-BB67-4858-88AF-0B95D5AE49CA@bryght.com> References: <4379C12A.1070805@killesreiter.de> <4BF1D26D-5977-4EB7-9DCD-F1B3EBC54D52@bryght.com> <4379C6FF.3010002@killesreiter.de> <2AB56BDF-BB67-4858-88AF-0B95D5AE49CA@bryght.com> Message-ID: <4379CC66.5040403@killesreiter.de> Adrian Rossouw wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 15 Nov 2005, at 1:31 PM, Gerhard Killesreiter wrote: > >> Yeah, we have been discussing this in the bus in Brussels. I don't >> see anybody coding this. > > maybe because we haven't officially decided to move to svn yet. > > me, and probably darix, wouldn't mind coding this, but we refuse to > do so for cvs. > Dries has said several times that he would be willing to move to svn as soon as the inrastructure (read: the code that integrates it) is there. That is about as official as it can get. Cheers, Gerhard From ber at webschuur.com Tue Nov 15 12:10:12 2005 From: ber at webschuur.com (Ber Kessels) Date: Tue Nov 15 12:10:17 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <43793020.8090702@walkah.net> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> <4378ABAF.8060306@walkah.net> <20051114204654.d2cef345.ber@webschuur.com> <2B8D1E92-BFD7-4A99-88F0-99CE043541D0@buytaert.net> <43793020.8090702@walkah.net> Message-ID: <20051115131012.e9164b0e.ber@webschuur.com> Ha! It sounds we are all saying the same thing. * We would like a central place where people can work on dedicated tasks. * We don't want to add extra administration by making stuff like deps required. * We do want to get all the noses into one direction by giving the infratstructure (wiki?) to write down some stuff and to inform others what this dedicated task is about. So lets get some action: * SVN server? Or are we going to use sandboxen in CVS? * Wiki or handbooks? On drupal.org or on a dedicated site (devel.drupal.org or so)? * Who will get all this rolling? Anyone volunteering to write a dep (harhar) for this work-thingy? Ber On Mon, 14 Nov 2005 19:47:28 -0500 James Walker wrote: > On 11/14/05 6:07 PM, Dries Buytaert wrote: > > > > On 14 Nov 2005, at 20:46, Ber Kessels wrote: > >> It is what got that form API in. It is what holds back Those Big > >> Issues from leveraging from yadiyadia level to Real Code Level, think > >> drupal.css, think taxonomy.module cleanup, think CCK ideals, think > >> install API. etcetc. > > > > Erm, the CCK plans are pretty well documented. They have been for about > > a year. Similarly, the install API has been documented too. Your > > examples show that central documentation is no guarantee for success > > (however they are often a necessary step). > > > > Hrm. this is a good point ... and has made me rethink my position a bit. > The thing biggest thing I think i'd like to see come from this idea, is > a centralized mechanism for doing such organizing. My reasoning is this > - using myself as an example - there are several "bigger projects" > underway, that I know of because I'm pretty involved in the community, > but I'm not directly involved in them all... however, they will have > fairly large impact on my work (thinking of CCK and install , e.g.). > Therefore, it would be really nice to have a place where i could go to > check up on the projects (and, perhaps, discover some new ones). > > The community is becoming very large for any one person to keep tabs on > it all... this might help, no? > > But you're right. I withdraw my previous requirement comment. I think > the important thing is not that DEPs are required - because then we end > up in the rathole of which changes require DEPs. However, central > organization would be very helpful. And i mean beyond "but it's all on > drupal.org". As wonderful as steven's search patches are... it's not > quite a one page overview :P > > >> I firmly beleive we reached a level where we can no longer deal with > >> Big Changes, unless we form subgroups. Which, again, is what I got, > >> this is all about. I hope so in any way. > > > > I firmly believe in people organizing themselves, and empowering them to > > do so. I do not believe in forcing people to write proposals. There > > are much larger projects than Jabber, Xaraya, PEAR or Python that are > > known to be successful without having proposals. Two random examples > > are the Linux kernel and KDE. > > This is incredibly well said. But i do think empowering the proposals > could prove to be very... well... powerful. but, who am I kidding... I'd > be the first to whine about having to write these things :P > > The other thing - and I realize now it's a bit tangential - but I'd like > to see a more transparent contributer approval process. but , i'll leave > that for another thread some day... > > > Feel free to write a proposal for the drupal.css or taxonomy.module > > clean up, or to get consensus before you start writing code. I'm cool > > with that. It's just not mandatory. > > > > > -- > James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net -- B?r Kessels Drupal services bler.webschuur.com www.webschuur.com ber@jabber.webschuur.com From ber at webschuur.com Tue Nov 15 12:13:21 2005 From: ber at webschuur.com (Ber Kessels) Date: Tue Nov 15 12:13:25 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <1132049323.4740.12.camel@localhost.localdomain> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> <4378ABAF.8060306@walkah.net> <20051114204654.d2cef345.ber@webschuur.com> <1132049323.4740.12.camel@localhost.localdomain> Message-ID: <20051115131321.61308b3b.ber@webschuur.com> Hmm, some misunderstanding. I'm to blame! On Tue, 15 Nov 2005 10:08:43 +0000 vlado wrote: > Subgroups as in tagreted development, I suppose. The way the form api was developed. Yup. I firmly beleive that people can organise themselves. Just hand them some tools to do so and it'l happen. > I don't like the idea of formalising as in adding a formal layer. This > will definitely scare people off. Or just piss them off. Please, keep > the "technocrats" away :) Neither do I, nor does Dries (or so i got from his previous post). Just set up some tools and groups like the ones tackling the forms API can get themselves going. > Generally I'm all for such proposal, regardless the name. Because they > could be helpful to keep yourself informed. A reference point and a > contacts point. -- B?r Kessels Drupal services bler.webschuur.com www.webschuur.com ber@jabber.webschuur.com From ber at webschuur.com Tue Nov 15 12:21:54 2005 From: ber at webschuur.com (Ber Kessels) Date: Tue Nov 15 12:21:58 2005 Subject: [development] replace drupal.js with prototype.js? In-Reply-To: <005d01c5e999$c452dc80$6400a8c0@family> References: <005d01c5e999$c452dc80$6400a8c0@family> Message-ID: <20051115132154.904a4078.ber@webschuur.com> I have very small knowledge of Js so I cannot comment on the quality of prototype. However, standing on the shoulders of giants is always a good idea. Better then building your own tower to get that high :) So im all for this. Ber On Mon, 14 Nov 2005 20:05:08 -0800 Nedjo Rogers wrote: > I really like the approaches implemented in drupal.js. > > But I've been wondering--would we do better to use the now widely supported, > and excellently designed, Prototype library (http://prototype.conio.net/ -- > see documentation e.g. at > http://www.sergiopereira.com/articles/prototype.js.html) instead? > > The advantages would be that we'd be using a well supported open source > library, rather than our own (nice, but not used elsewhere) solution. Doing > so would allow Drupal developers to use the ever-expanding range of > Prototype-based libraries, including: > > moofx http://moofx.mad4milk.net/ > behaviour http://bennolan.com/behaviour/ > scriptaculous http://script.aculo.us > > We'd still need some custom drupal methods, but we could reduce them to a > minimum. > > We could also draw on other open source CMS etc. softwares using Prototype, > e.g, Ruby on Rails. > > Doing so would require some refactoring of our existing javascript > (autoexpand, etc.), but really not so much. And we'd be able to take > advantage of some great features and methods in Prototype and its related > libraries. > > Prototype and its relatives are "MIT style" licensed, presumably GPL > compatible, > http://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses. > > Thoughts? > -- B?r Kessels Drupal services bler.webschuur.com www.webschuur.com ber@jabber.webschuur.com From vlado at dikini.net Tue Nov 15 12:34:42 2005 From: vlado at dikini.net (vlado) Date: Tue Nov 15 12:34:45 2005 Subject: [development] replace drupal.js with prototype.js? In-Reply-To: <005d01c5e999$c452dc80$6400a8c0@family> References: <005d01c5e999$c452dc80$6400a8c0@family> Message-ID: <1132058082.8154.10.camel@localhost.localdomain> On Mon, 2005-11-14 at 20:05 -0800, Nedjo Rogers wrote: > I really like the approaches implemented in drupal.js. > > But I've been wondering--would we do better to use the now widely supported, > and excellently designed, Prototype library (http://prototype.conio.net/ -- > see documentation e.g. at > http://www.sergiopereira.com/articles/prototype.js.html) instead? Prototype is good. Very good in fact. And there are a lot of good examples. Prototype + behaviours could make for a very interactive, userfriendly and designer friendly Drupal. +1 From web at timaltman.com Tue Nov 15 12:41:30 2005 From: web at timaltman.com (Tim Altman) Date: Tue Nov 15 12:41:59 2005 Subject: [development] replace drupal.js with prototype.js? In-Reply-To: <20051115132154.904a4078.ber@webschuur.com> References: <005d01c5e999$c452dc80$6400a8c0@family> <20051115132154.904a4078.ber@webschuur.com> Message-ID: On Tue, 15 Nov 2005 13:21:54 +0100, Ber Kessels wrote: > I have very small knowledge of Js so I cannot comment on the quality of > prototype. > > However, standing on the shoulders of giants is always a good idea. > Better then building your own tower to get that high :) > > So im all for this. Are we risking the possibility of running into problems like we did with the third-party xmlrpc library we used? I know this isn't PHP code, so there shouldn't be any exploits, but are there other issues we should keep in mind? -- Tim Altman From david.carrington at gmail.com Tue Nov 15 12:57:37 2005 From: david.carrington at gmail.com (David Carrington) Date: Tue Nov 15 12:57:40 2005 Subject: [development] replace drupal.js with prototype.js? In-Reply-To: <005d01c5e999$c452dc80$6400a8c0@family> References: <005d01c5e999$c452dc80$6400a8c0@family> Message-ID: <49f3c93a0511150457r5e5a128en@mail.gmail.com> Some people have mentioned dojo, xajax, and possibly others. The choice would be something worth discussing, but in principle I am in favour of adding a well-maintained library. See: http://wiki.osafoundation.org/bin/view/Projects/AjaxLibraries Tim: Javascript libraries can not introduce any new threats I can think of. The only chance is if the user can write some malicious javascript on your site - which we avoid already anyway. -- David Carrington From adrian at bryght.com Tue Nov 15 13:24:37 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Tue Nov 15 13:24:53 2005 Subject: [development] Drupal Enhancement Proposals (DEPs) In-Reply-To: <20051115131012.e9164b0e.ber@webschuur.com> References: <5DD14886-DB85-48D8-BA0D-3899B8CCC618@bryght.com> <4378ABAF.8060306@walkah.net> <20051114204654.d2cef345.ber@webschuur.com> <2B8D1E92-BFD7-4A99-88F0-99CE043541D0@buytaert.net> <43793020.8090702@walkah.net> <20051115131012.e9164b0e.ber@webschuur.com> Message-ID: <3A66B6A1-3EA6-469F-BBA5-84F6E7BC0A2D@bryght.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15 Nov 2005, at 2:10 PM, Ber Kessels wrote: > * Who will get all this rolling? Anyone volunteering to write a dep > (harhar) for this work-thingy? I've already volunteered to write a DEP. I just have to find the time to do so. I will make it a relatively simple on though. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDeeGWgegMqdGlkasRAuYYAKC+nhIO+KMQWyzL7xkwP/YHStjz/wCfSP7r hvj7ldDVFG2kaWZZbefpX4U= =Uj6J -----END PGP SIGNATURE----- From adrian at bryght.com Tue Nov 15 13:26:44 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Tue Nov 15 13:27:00 2005 Subject: [development] replace drupal.js with prototype.js? In-Reply-To: <49f3c93a0511150457r5e5a128en@mail.gmail.com> References: <005d01c5e999$c452dc80$6400a8c0@family> <49f3c93a0511150457r5e5a128en@mail.gmail.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15 Nov 2005, at 2:57 PM, David Carrington wrote: > > See: http://wiki.osafoundation.org/bin/view/Projects/AjaxLibraries It must be kismet. This was on digg today : http://edevil.wordpress.com/2005/11/14/javascript-libraries-roundup/ - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDeeIUgegMqdGlkasRAnAYAJ0ULHpOb8wTIG2FZbvmHU1Rqhb1LACfShqw VVecBd9b+71aBbwU4keorZo= =GwrY -----END PGP SIGNATURE----- From kb at 2bits.com Tue Nov 15 14:37:10 2005 From: kb at 2bits.com (Khalid B) Date: Tue Nov 15 14:37:13 2005 Subject: [development] replace drupal.js with prototype.js? In-Reply-To: References: <005d01c5e999$c452dc80$6400a8c0@family> <20051115132154.904a4078.ber@webschuur.com> Message-ID: <4a9fdc630511150637m5aa18e13t9ac1583f24c52cbb@mail.gmail.com> > Are we risking the possibility of running into problems like we did with > the third-party xmlrpc library we used? I know this isn't PHP code, so > there shouldn't be any exploits, but are there other issues we should keep > in mind? This is what I was thinking too when I first read this thread. More specifically, we may have XSS vulnerabilities by third party javascript libraries. Don't get me wrong: this is not NIH (Not Invented Here), and I support taking the best tools from whereever they are. All I am saying is that it needs to be audited for such possibilities. We learned the hard way with xmlrpc. From weitzman at tejasa.com Tue Nov 15 14:37:23 2005 From: weitzman at tejasa.com (Moshe Weitzman) Date: Tue Nov 15 14:37:24 2005 Subject: [development] Give a guy some love! (or at least some attention) In-Reply-To: <36b9121d0511142152u3091e3fdn7d3279d3c01fc89f@mail.gmail.com> References: <36b9121d0511142152u3091e3fdn7d3279d3c01fc89f@mail.gmail.com> Message-ID: <4379F2A3.6030407@tejasa.com> Steve Dondley wrote: > Even if you think the patch at http://drupal.org/node/37283 sucks, I > want to know! please don't beg for attention to your issue on this mail list. if you are not getting anyone to review your patch, you might email some key contributors privately. or ask in IRC. we moved issue posting away from this list for a reason. From kieran at civicspacelabs.org Tue Nov 15 14:50:59 2005 From: kieran at civicspacelabs.org (Kieran Lal) Date: Tue Nov 15 14:51:03 2005 Subject: [development] subversion In-Reply-To: <4BF1D26D-5977-4EB7-9DCD-F1B3EBC54D52@bryght.com> References: <4379C12A.1070805@killesreiter.de> <4BF1D26D-5977-4EB7-9DCD-F1B3EBC54D52@bryght.com> Message-ID: <3C8ED0F5-FF34-4F2F-A0D5-E8E3453C8F5A@civicspacelabs.org> On Nov 15, 2005, at 3:19 AM, Adrian Rossouw wrote: > agging ones that don't apply anymore and during this process we can > re-create the patch in the correct way, and probably even run the > code style script on them. It's hard to maintain a distribution, CivicSpace, between CVS and SVN. It's very hard for CSS developers to understand the complex commands of CVS. If anybody wants to code this please get in touch and I'll support it so we can move to SVN. Kieran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051115/ed8f21c6/attachment.htm From weitzman at tejasa.com Tue Nov 15 14:54:24 2005 From: weitzman at tejasa.com (Moshe Weitzman) Date: Tue Nov 15 14:55:23 2005 Subject: [development] replace drupal.js with prototype.js? In-Reply-To: <4a9fdc630511150637m5aa18e13t9ac1583f24c52cbb@mail.gmail.com> References: <005d01c5e999$c452dc80$6400a8c0@family> <20051115132154.904a4078.ber@webschuur.com> <4a9fdc630511150637m5aa18e13t9ac1583f24c52cbb@mail.gmail.com> Message-ID: <4379F6A0.8080102@tejasa.com> > We learned the hard way with xmlrpc. Not really. Code that was written by us has had loads of vulnerabilities as well. One might argue that 3rd party code like prototype is likely safer since it has ben exposed to more eyeballs. From weitzman at tejasa.com Tue Nov 15 14:56:01 2005 From: weitzman at tejasa.com (Moshe Weitzman) Date: Tue Nov 15 14:56:02 2005 Subject: [development] subversion In-Reply-To: <3C8ED0F5-FF34-4F2F-A0D5-E8E3453C8F5A@civicspacelabs.org> References: <4379C12A.1070805@killesreiter.de> <4BF1D26D-5977-4EB7-9DCD-F1B3EBC54D52@bryght.com> <3C8ED0F5-FF34-4F2F-A0D5-E8E3453C8F5A@civicspacelabs.org> Message-ID: <4379F701.1010003@tejasa.com> > If anybody wants to code this please get in touch and I'll > support it so we can move to SVN. and if you do, feel free to just commit on top of the current svn.module. i built that out of need when few php based svn repos browsers were available. -moshe From herman.webley at gmail.com Tue Nov 15 15:01:13 2005 From: herman.webley at gmail.com (Herman Webley) Date: Tue Nov 15 15:01:16 2005 Subject: [development] replace drupal.js with prototype.js? In-Reply-To: <4a9fdc630511150637m5aa18e13t9ac1583f24c52cbb@mail.gmail.com> References: <005d01c5e999$c452dc80$6400a8c0@family> <20051115132154.904a4078.ber@webschuur.com> <4a9fdc630511150637m5aa18e13t9ac1583f24c52cbb@mail.gmail.com> Message-ID: I definitely want to see some AJAX love for Drupal. 1. drupal.js is very good. 2. prototype.js is 45k. Then we're gonna want to add Rico or Scriptaculous on top of that. All of the other libraries with visual effects are pretty big as well. Thats probably too big to include on a page by default (if people are complaing about the size of the css file :) ) 3. xajax integrates very well with PHP. With just writing PHP it would allow us to have pages update via AJAX using php callbacks (it generates all the necessary javascript). I like that approach. We could extend what exists currently in drupal.js to add similar functionality. We could even simply switch to xajax or something with a similar concept. It would also remove knowledge of javascript as barrier to AJAX additions to Drupal. We can use the resources saved by not dealing with js directly to ensure that everything falls back nicely in the absence of JS. 4.Our xmlrpc system is still based on a 3rd part library. The 'Not invented here' syndrome isn't too bad in our community. I think all the jazzy js effects should be left as a contrib addition (at least for now), and that basic AJAX functionality, that can be easily used should be added to Drupal core. PS Visual effects can be very useful (not just snazz). Cinematic effects can be used as UI aids, and I think that a drag 'n drop position selector for blocks and book pages (rather than assigning weights) would just rock! On 11/15/05, Khalid B wrote: > > Are we risking the possibility of running into problems like we did with > > the third-party xmlrpc library we used? I know this isn't PHP code, so > > there shouldn't be any exploits, but are there other issues we should keep > > in mind? > > This is what I was thinking too when I first read this thread. > > More specifically, we may have XSS vulnerabilities by third party > javascript libraries. > > Don't get me wrong: this is not NIH (Not Invented Here), and I support > taking the best tools from whereever they are. > > All I am saying is that it needs to be audited for such possibilities. > We learned the hard way with xmlrpc. > -- Best regards, Herman Webley From karoly at negyesi.net Tue Nov 15 15:10:38 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Tue Nov 15 15:07:42 2005 Subject: [development] replace drupal.js with prototype.js? In-Reply-To: References: <005d01c5e999$c452dc80$6400a8c0@family> <20051115132154.904a4078.ber@webschuur.com> <4a9fdc630511150637m5aa18e13t9ac1583f24c52cbb@mail.gmail.com> Message-ID: > 4.Our xmlrpc system is still based on a 3rd part library. The 'Not > invented here' syndrome isn't too bad in our community. Yeah. The functionality of it is still mostly IXR but we are moving away day by day... So it is truly based but very soon it'll be just "loosely based on" :) From craig at dawnsedge.com Tue Nov 15 15:33:05 2005 From: craig at dawnsedge.com (Craig Courtney) Date: Tue Nov 15 15:33:11 2005 Subject: [development] Files on previews In-Reply-To: <1912.213.46.81.27.1131667932.squirrel@www.webschuur.com> References: <1912.213.46.81.27.1131667932.squirrel@www.webschuur.com> Message-ID: <4379FFB1.6070603@dawnsedge.com> Ber Kessels wrote: >Hello all files people. > >I am getting somewhere with my files stuff, but i'd like some gurus and/or >original file.inc developers to comment on an issue: > >We have a lot of code in upload.module and some in file.inc to cater >previews. In case of a preview, we try to serve the files from the temp >folder, or we try to generate temporary URLS etc (since we have no nid >yet!) >This is a bit crufty IMHO. I want to change this, in my code to behave as >follows: > >* A node (or comment or whatever) that has attachements that are valid are >inserted into the files system all the way. we only leave the obid (the >column in tghe files dir for object ids like nid) empty >* invalid files are deleted immediately >* Once the object is inserted and saved, we have an obid (nid, mostly) and >we update the table. > >That way, on loads of previews, we should be able to just use the urls, >apis and functions we use normally. > >So: >Why did we choose for the current method of writing all the exceptions for >previews? Did I miss something important that renders my idea impossible? >Should I take care of something else? > >Ber > > > Ber you should take a look at the code in my filemanager and attachment modules. They already address this problem and it requires a table to keep track of files separately from their association with nodes. I wrote this code a year ago and it was passed over as to complex specifically because it actually addressed these issues which where ignored by the existing upload module. These modules have not got much love over the last year and may need some feature updates but the filemanager does handle exactly the scenarios you are attempting to address. In addition it's handling of temp/active allows editing and previews of a node to work with out affecting the existing version until the updates are submitted. Good luck, Craig From craig at dawnsedge.com Tue Nov 15 15:38:04 2005 From: craig at dawnsedge.com (Craig Courtney) Date: Tue Nov 15 15:38:06 2005 Subject: [development] Give a guy some love! (or at least some attention) In-Reply-To: <4379F2A3.6030407@tejasa.com> References: <36b9121d0511142152u3091e3fdn7d3279d3c01fc89f@mail.gmail.com> <4379F2A3.6030407@tejasa.com> Message-ID: <437A00DC.6060200@dawnsedge.com> Moshe Weitzman wrote: > Steve Dondley wrote: > >> Even if you think the patch at http://drupal.org/node/37283 sucks, I >> want to know! > > > please don't beg for attention to your issue on this mail list. if you > are not getting anyone to review your patch, you might email some key > contributors privately. or ask in IRC. we moved issue posting away > from this list for a reason. While that change was well intended please don't pretend it did not have negative consequences. It seems like 4.7 will never get to a stable point to freeze and RC. When I picked up 4.7 a few weeks ago to evaluate for use (which seemed reasonable since I had read about a code freeze several weeks prior to that) it was pretty much non functional. Fundamental bugs in new forms API code (http://drupal.org/node/35570, http://drupal.org/node/35225, http://drupal.org/node/35594) have sat idle for 3 weeks and others where independently fixed after I delivered patches that did not know about the issues I'd filed (or at least they did not update my issues). That is not the behavior of a healthy system. When I was actively working on items for the 4.5 release it was never this bad. Craig From kieran at civicspacelabs.org Tue Nov 15 15:42:41 2005 From: kieran at civicspacelabs.org (Kieran Lal) Date: Tue Nov 15 15:42:46 2005 Subject: [development] Re: [drupal-devel] mailman wrapper module In-Reply-To: References: <89639E49-752D-4DED-ACB3-EE26D44AFB93@buytaert.net> Message-ID: <50EBBEC1-2508-40AB-AAD9-475F240A22AA@civicspacelabs.org> On Nov 8, 2005, at 3:47 PM, Peter John Hartman wrote: http://drupal.org/node/36863 > I'm also in contact with the mailman people about integrating > xmlrpc and some mysql patches that might go along with this module. Any progress on this front? Have you looked at Moshe's use of the SQL adapter? Cheers, Kieran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051115/ca8cb20f/attachment.htm From gerhard at killesreiter.de Tue Nov 15 15:59:24 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Tue Nov 15 16:00:27 2005 Subject: [development] Re: [drupal-devel] mailman wrapper module In-Reply-To: <50EBBEC1-2508-40AB-AAD9-475F240A22AA@civicspacelabs.org> References: <89639E49-752D-4DED-ACB3-EE26D44AFB93@buytaert.net> <50EBBEC1-2508-40AB-AAD9-475F240A22AA@civicspacelabs.org> Message-ID: <437A05DC.20202@killesreiter.de> Kieran Lal wrote: > > On Nov 8, 2005, at 3:47 PM, Peter John Hartman wrote: > > http://drupal.org/node/36863 > >> I'm also in contact with the mailman people about integrating xmlrpc >> and some mysql patches that might go along with this module. > > > Any progress on this front? Have you looked at Moshe's use of the > SQL adapter? > The mysql patch he mentions is the SQL adapter. Cheers, Gerhard From gerhard at killesreiter.de Tue Nov 15 16:07:06 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Tue Nov 15 16:08:09 2005 Subject: [development] Give a guy some love! (or at least some attention) In-Reply-To: <437A00DC.6060200@dawnsedge.com> References: <36b9121d0511142152u3091e3fdn7d3279d3c01fc89f@mail.gmail.com> <4379F2A3.6030407@tejasa.com> <437A00DC.6060200@dawnsedge.com> Message-ID: <437A07AA.6050808@killesreiter.de> Craig Courtney wrote: > Moshe Weitzman wrote: > >> please don't beg for attention to your issue on this mail list. if >> you are not getting anyone to review your patch, you might email some >> key contributors privately. or ask in IRC. we moved issue posting >> away from this list for a reason. > > > While that change was well intended please don't pretend it did not > have negative consequences. It seems like 4.7 will never get to a > stable point to freeze and RC. When I picked up 4.7 a few weeks ago > to evaluate for use (which seemed reasonable since I had read about a > code freeze several weeks prior to that) it was pretty much non > functional. Fundamental bugs in new forms API code > (http://drupal.org/node/35570, http://drupal.org/node/35225, > http://drupal.org/node/35594) have sat idle for 3 weeks and others > where independently fixed after I delivered patches that did not know > about the issues I'd filed (or at least they did not update my issues). We can only suggest that people subscribe to the issue tracker either by mail or rss. We cannot fore them (at least for rss ;). > That is not the behavior of a healthy system. When I was actively > working on items for the 4.5 release it was never this bad. > 4.5 didn't have that big changes as late in the game. And yes, it was neccessary to add these changes even this late. Cheers, Gerhard From dries at buytaert.net Tue Nov 15 16:49:46 2005 From: dries at buytaert.net (Dries Buytaert) Date: Tue Nov 15 16:49:50 2005 Subject: [development] Drupal 4.7.0 update Message-ID: <72FD72C7-7BD9-4BCE-B839-47F1B967B16D@buytaert.net> Hello world, - I opened up the use of the DRUPAL-4-7 tag for contributed projects (not for core). Thus, if you maintain a module, theme or translation, you can create a DRUPAL-4-7 branch. Because Drupal HEAD and Drupal 4.7 are still one and the same, it's probably premature to branch your project (unless you want to rewrite your project for Drupal 4.8.0). Also, the DRUPAL-4-7 tarballs won't be packaged for another week or so. - I haven't released a Drupal 4.7 release candidate yet because I feel we're still dealing with too many (critical) bugfixes. We need a base level of stability and confidence before we can roll out a release candidate. Nonetheless, Drupal HEAD is getting more and more stable every day so keep reporting and fixing those bugs. It is the one path to a Drupal 4.7.0 release (candidate). I think we might be able to roll a release candidate as soon as next week. - As of tomorrow, I'm not likely to make any more API or database changes, unless deemed important. (I might make an exception for some of the pending patches/work but I'm not likely to consider _new_ patches that add _new_ functionality.) I'll be more strict, and that implies that some patches will not make it into Drupal 4.7.0. - In good tradition, I plan to upgrade Drupal.org to the release candidate as soon as possible. I'm currently waiting for the simplenews.module to be "forms API"-ified, and I have yet to port some drupal.org specific modules/pages (eg. the one that generates http://drupal.org/mailing-lists/). Chances are that the cvslog.module needs more work as well -- haven't checked. As soon we can upgrade, we'll be able to roll out the improved search module. All in all, it's probably going to take another 2-3 weeks though before we can attempt to upgrade drupal.org. -- Dries Buytaert :: http://www.buytaert.net/ From gerhard at killesreiter.de Tue Nov 15 17:09:31 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Tue Nov 15 17:10:39 2005 Subject: [development] Drupal 4.7.0 update In-Reply-To: <72FD72C7-7BD9-4BCE-B839-47F1B967B16D@buytaert.net> References: <72FD72C7-7BD9-4BCE-B839-47F1B967B16D@buytaert.net> Message-ID: <437A164B.1070707@killesreiter.de> Dries Buytaert wrote: > - I opened up the use of the DRUPAL-4-7 tag for contributed projects > (not for core). Thus, if you maintain a Yay! That solves issue I have with volunteer and massmailer. > module, theme or translation, you can create a DRUPAL-4-7 branch. > Because Drupal HEAD and Drupal 4.7 are still one and the same, it's > probably premature to branch your project (unless you want to rewrite > your project for Drupal 4.8.0). Also, the DRUPAL-4-7 tarballs won't be > packaged for another week or so. > > - I haven't released a Drupal 4.7 release candidate yet because I feel > we're still dealing with too many (critical) bugfixes. We need a base > level of stability and confidence before we can roll out a release > candidate. Nonetheless, Drupal HEAD is getting more and more stable > every day so keep reporting and fixing those bugs. It is the one path > to a Drupal 4.7.0 release (candidate). I think we might be able to > roll a release candidate as soon as next week. > Sounds good. > - As of tomorrow, I'm not likely to make any more API or database > changes, unless deemed important. (I might make an exception for some > of the pending patches/work but I'm not likely to consider _new_ > patches that add _new_ functionality.) I'll be more strict, and that > implies that some patches will not make it into Drupal 4.7.0. > Can you maybe make a list of patches/issues (for features) that still do have a chance if somebody works on them? > - In good tradition, I plan to upgrade Drupal.org to the release > candidate as soon as possible. I'm currently waiting for the > simplenews.module to be "forms API"-ified, and I have yet to port some > drupal.org specific modules/pages (eg. the one that generates > http://drupal.org/mailing-lists/). Make a list and hope for help. ;) > Chances are that the cvslog.module needs more work as well -- haven't > checked. I had started the update and Jake G finished it yesterday. > As soon we can upgrade, we'll be able to roll out the improved search > module. All in all, it's probably going to take another 2-3 weeks > though before we can attempt to upgrade drupal.org. Let's see. ;) Cheers, Gerhard From chris at tinpixel.com Tue Nov 15 17:46:40 2005 From: chris at tinpixel.com (Chris Johnson) Date: Tue Nov 15 17:46:31 2005 Subject: [development] replace drupal.js with prototype.js? In-Reply-To: <4379F6A0.8080102@tejasa.com> References: <005d01c5e999$c452dc80$6400a8c0@family> <20051115132154.904a4078.ber@webschuur.com> <4a9fdc630511150637m5aa18e13t9ac1583f24c52cbb@mail.gmail.com> <4379F6A0.8080102@tejasa.com> Message-ID: <437A1F00.5070009@tinpixel.com> Moshe Weitzman wrote: >> We learned the hard way with xmlrpc. > > > Not really. Code that was written by us has had loads of vulnerabilities > as well. One might argue that 3rd party code like prototype is likely > safer since it has ben exposed to more eyeballs. > Not necessarily more eyeballs than xmlrpc. Prototype is a one-man show, as far as the code development goes, just like xmlrpc was. I recently reviewed 5 different Javascript libraries for implementation of AJAX features. They were all over the map, which to me says that the best practice or common idioms have not been established yet. Would tying Drupal to just one of a variety of competing ideas on how to implement such a library at this point be a good idea? If so, prototype's code is at least brief (not heavy like some libraries I've seen) and clean appearing. From neil at civicspacelabs.org Tue Nov 15 18:19:33 2005 From: neil at civicspacelabs.org (neil@civicspacelabs.org) Date: Tue Nov 15 18:26:18 2005 Subject: [development] replace drupal.js with prototype.js? In-Reply-To: References: <005d01c5e999$c452dc80$6400a8c0@family> <20051115132154.904a4078.ber@webschuur.com> Message-ID: <20051115181933.GA11841@localhost> On Tue, Nov 15, 2005 at 01:41:30PM +0100, Tim Altman wrote: > On Tue, 15 Nov 2005 13:21:54 +0100, Ber Kessels wrote: > > >I have very small knowledge of Js so I cannot comment on the quality of > >prototype. > > > >However, standing on the shoulders of giants is always a good idea. > >Better then building your own tower to get that high :) > > > >So im all for this. > > Are we risking the possibility of running into problems like we did with > the third-party xmlrpc library we used? I know this isn't PHP code, so > there shouldn't be any exploits, but are there other issues we should keep > in mind? The biggest problem I've seen so far with JavaScript is leaking memory. -- Neil Drumm http://delocalizedham.com/ From neil at civicspacelabs.org Tue Nov 15 18:20:13 2005 From: neil at civicspacelabs.org (neil@civicspacelabs.org) Date: Tue Nov 15 18:26:18 2005 Subject: [development] replace drupal.js with prototype.js? In-Reply-To: <1132058082.8154.10.camel@localhost.localdomain> References: <005d01c5e999$c452dc80$6400a8c0@family> <1132058082.8154.10.camel@localhost.localdomain> Message-ID: <20051115182013.GB11841@localhost> On Tue, Nov 15, 2005 at 12:34:42PM +0000, vlado wrote: > On Mon, 2005-11-14 at 20:05 -0800, Nedjo Rogers wrote: > > I really like the approaches implemented in drupal.js. > > > > But I've been wondering--would we do better to use the now widely supported, > > and excellently designed, Prototype library (http://prototype.conio.net/ -- > > see documentation e.g. at > > http://www.sergiopereira.com/articles/prototype.js.html) instead? > > Prototype is good. Very good in fact. And there are a lot of good examples. Prototype + behaviours could make > for a very interactive, userfriendly and designer friendly Drupal. > +1 JavaScript != usability -- Neil Drumm http://delocalizedham.com/ From peterjh at mennonot.net Wed Nov 16 01:14:21 2005 From: peterjh at mennonot.net (Peter John Hartman) Date: Tue Nov 15 22:35:08 2005 Subject: [development] Re: [drupal-devel] mailman wrapper module In-Reply-To: <50EBBEC1-2508-40AB-AAD9-475F240A22AA@civicspacelabs.org> References: <89639E49-752D-4DED-ACB3-EE26D44AFB93@buytaert.net> <50EBBEC1-2508-40AB-AAD9-475F240A22AA@civicspacelabs.org> Message-ID: Hey there. I'm in the midst of installing the mysql adaptor. It's fairly painless, but the distribution is misisng the patch file (there are only a few lines). It is too bad that it isn't in the vanilla code, but I suspect it will be for the next release. There also has been a flurry of activity on the mailman mailing list about an improved version of the mysql adaptor for mailman, which makes me more optimistic. I don't think I'll go xmlrpc--just out of fear of security problems. And the xmlrpc patch (just released) isn't int he vanilla code either. If you have advice, let me know. I could go either way: (a) a mostly undertested mysql adaptor or (b) a potentially security-hazard xmlrpc. I'm also going with mysql because I know it better. And, if I get clever enough, I can integrate the mailman userbase in with the drupal userbase! Which would be a blast. Peter On Tue, 15 Nov 2005, Kieran Lal wrote: > > On Nov 8, 2005, at 3:47 PM, Peter John Hartman wrote: > > http://drupal.org/node/36863 >> I'm also in contact with the mailman people about integrating xmlrpc and >> some mysql patches that might go along with this module. > > Any progress on this front? Have you looked at Moshe's use of the SQL > adapter? > > Cheers, > Kieran > > From peterjh at mennonot.net Wed Nov 16 01:14:21 2005 From: peterjh at mennonot.net (Peter John Hartman) Date: Tue Nov 15 22:35:10 2005 Subject: [development] Re: [drupal-devel] mailman wrapper module In-Reply-To: <50EBBEC1-2508-40AB-AAD9-475F240A22AA@civicspacelabs.org> References: <89639E49-752D-4DED-ACB3-EE26D44AFB93@buytaert.net> <50EBBEC1-2508-40AB-AAD9-475F240A22AA@civicspacelabs.org> Message-ID: Hey there. I'm in the midst of installing the mysql adaptor. It's fairly painless, but the distribution is misisng the patch file (there are only a few lines). It is too bad that it isn't in the vanilla code, but I suspect it will be for the next release. There also has been a flurry of activity on the mailman mailing list about an improved version of the mysql adaptor for mailman, which makes me more optimistic. I don't think I'll go xmlrpc--just out of fear of security problems. And the xmlrpc patch (just released) isn't int he vanilla code either. If you have advice, let me know. I could go either way: (a) a mostly undertested mysql adaptor or (b) a potentially security-hazard xmlrpc. I'm also going with mysql because I know it better. And, if I get clever enough, I can integrate the mailman userbase in with the drupal userbase! Which would be a blast. Peter On Tue, 15 Nov 2005, Kieran Lal wrote: > > On Nov 8, 2005, at 3:47 PM, Peter John Hartman wrote: > > http://drupal.org/node/36863 >> I'm also in contact with the mailman people about integrating xmlrpc and >> some mysql patches that might go along with this module. > > Any progress on this front? Have you looked at Moshe's use of the SQL > adapter? > > Cheers, > Kieran > > From piotr at mallorn.ii.uj.edu.pl Tue Nov 15 23:18:51 2005 From: piotr at mallorn.ii.uj.edu.pl (Piotr Krukowiecki) Date: Tue Nov 15 23:18:54 2005 Subject: [development] Drupal 4.7.0 update In-Reply-To: <72FD72C7-7BD9-4BCE-B839-47F1B967B16D@buytaert.net> References: <72FD72C7-7BD9-4BCE-B839-47F1B967B16D@buytaert.net> Message-ID: <20051115231851.GB13706@mallorn.ii.uj.edu.pl> On Tue, Nov 15, 2005 at 05:49:46PM +0100, Dries Buytaert wrote: > - As of tomorrow, I'm not likely to make any more API or database > changes, unless deemed important. (I might make an exception for > some of the pending patches/work but I'm not likely to consider _new_ > patches that add _new_ functionality.) I'll be more strict, and that > implies that some patches will not make it into Drupal 4.7.0. Postgresql cache bug, which exists since pre-4.6, has a patch at http://drupal.org/node/10407#comment-54381 It needs testing (yes, people using mysql have to test it too!) and probably some work. I'm getting some weird warnings with this patch, but I haven't confirmed if they are related to the patch. If this bug is not fixed, 4.7 will be second main Drupal release (after 4.6) which does NOT support caching AT ALL. -- Piotrek irc: #debian.pl Mors Drosophilis melanogastribus! From colin at bryght.com Tue Nov 15 23:23:23 2005 From: colin at bryght.com (Colin Brumelle) Date: Tue Nov 15 23:23:27 2005 Subject: [development] replace drupal.js with prototype.js? In-Reply-To: <20051115182013.GB11841@localhost> References: <005d01c5e999$c452dc80$6400a8c0@family> <1132058082.8154.10.camel@localhost.localdomain> <20051115182013.GB11841@localhost> Message-ID: <80a220dc0511151523u2fbef0e8p99b23023bddb7d60@mail.gmail.com> I've done some work with Prototype, and have found it to be really well thought out. I would love to see Drupal standardise on this package for adding AJAX functionality. Prototypes inclusion in Rails also offers some guarantees that it will be around for a while, developed further, and maintained. +1 from me... ------------------- Colin Brumelle colin@bryght.com http://bryght.com http://mixedcontent.com Cell: 604.351.0547 Office: 604.682.2889 skype/jabber/aim: cbrumelle -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051115/f650dce4/attachment.htm From adrinux at gmail.com Tue Nov 15 23:41:44 2005 From: adrinux at gmail.com (Adrian Simmons) Date: Tue Nov 15 23:41:50 2005 Subject: [development] Re: [CS dev] Help with a CivicSpace Theme Layout... (Read it, you know you want to! :) In-Reply-To: References: <43755749.4000209@occy.net> <1F298344-E0CE-417F-BE0F-B4B8DB7F3110@culturekitchen.com> <1131981149.21921.24.camel@localhost.localdomain> <20051114204959.c9299a9d.ber@webschuur.com> <1131999372.21921.28.camel@localhost.localdomain> <4378F2CE.4010104@hojtsy.hu> <4C4116C6-ECC3-45C6-9039-C70CA5BEDD2D@buddyping.com> <20051114215902.befbb371.ber@webschuur.com> <76EF8B41-8E06-4A05-96B3-A3CD2FE4E0A6@buddyping.com> Message-ID: <437A7238.40805@gmail.com> Richard Archer wrote: > Site 1: 43,703 out of 2,830,400 hits (1.54%) were IE5/Mac users. Personally I'd make an effort to support IE5mac on this site... > Site 2: 23,175 out of 2,678,670 hits (0.09%) were IE5/Mac users. but not this one. > Nearly half the Mac users were using IE5. That's just shocking! Trae, we are in agreement about this I think - it just comes down to the audience on a site by site basis, and how much effort it takes to make IE5mac work with your particular design/features. -- adrinux (aka Adrian Simmons) e-mail AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com From jazepstein at gmail.com Wed Nov 16 00:34:15 2005 From: jazepstein at gmail.com (Jeremy Epstein) Date: Wed Nov 16 00:34:17 2005 Subject: [development] replace drupal.js with prototype.js? In-Reply-To: <005d01c5e999$c452dc80$6400a8c0@family> References: <005d01c5e999$c452dc80$6400a8c0@family> Message-ID: Prototype does indeed seem to be a very light, clean, and extensible library: but nonetheless, it is nowhere near as light as drupal.js. Quick comparison: Drupal.js: 281 lines, 6.21KB Prototype.js: 1039 lines, 27.29KB I am confident of the quality and the benefits of the prototype library. But we really need to consider whether or not these benefits can justify quadrupling the size of our base JS file. According to websiteoptimization.com, web sites should be aiming for a to have 8KB or less of JS on any given page. This will not be possible with prototype. Jaza. From drupal.org at juggernaut.com.au Wed Nov 16 01:49:07 2005 From: drupal.org at juggernaut.com.au (Richard Archer) Date: Wed Nov 16 01:48:59 2005 Subject: [development] replace drupal.js with prototype.js? In-Reply-To: References: <005d01c5e999$c452dc80$6400a8c0@family> Message-ID: At 11:34 AM +1100 16/11/05, Jeremy Epstein wrote: >Prototype does indeed seem to be a very light, clean, and extensible >library: but nonetheless, it is nowhere near as light as drupal.js. >Quick comparison: > >Drupal.js: 281 lines, 6.21KB >Prototype.js: 1039 lines, 27.29KB All the Drupal .js files combines come to 18 kB. Is it possible to strip prototype down a bit? There are a lot of comments in the file that wouldn't be needed in a live site. What about separating it into function-related files and just sending the bits the page needs? ...R. From chris.messina at gmail.com Wed Nov 16 02:07:55 2005 From: chris.messina at gmail.com (Chris Messina) Date: Wed Nov 16 02:07:57 2005 Subject: [development] subversion In-Reply-To: <4379F701.1010003@tejasa.com> References: <4379C12A.1070805@killesreiter.de> <4BF1D26D-5977-4EB7-9DCD-F1B3EBC54D52@bryght.com> <3C8ED0F5-FF34-4F2F-A0D5-E8E3453C8F5A@civicspacelabs.org> <4379F701.1010003@tejasa.com> Message-ID: <1bc4603e0511151807s7e2f1e86pfc76ccbd199e5d67@mail.gmail.com> Just an FYI, we recently decided at Flock not to go with SVN for our browser work but to instead use Mercurial (http://www.selenic.com/mercurial/wiki/index.cgi). Here are the reasons: Up sides: 1. distributed source model local versioning and ability to merge with other repositories 2. native binary support no stupid corrupt image files from forgetting to tag things, better performance 3. 3 way merge better merging logic for changes 4. native client-server concept better network performance 5. good performance on all platforms 6. simple clear architecture this is as opposed to svk, or CVS. I don't see it quite as clean as svn, where you can just imagine everything as a file sitting in a path 7. Has concept of both versions and change-sets nicer ways to think about changes Down Sides 1. mediocre windows support seems to work on windows, but the dev team does not have a full-time windows user, and there are more "minor" bugs on the windows version than UNX versions (double warning messages, fewer command-line shortcuts) 2. rename support is not yet there this is in dev tree 3. medium disk space usage 340MB in CVS -> 700MB in HG 4. Not much integration with existing software There is no bug/project tracking system integrations, or very many web front ends to it, though the one it has is pretty good 5. mediocre branching branching is no worse than CVS, but not really much better, not as nice as svn/svk 6. still a bit immature but pretty well documented, this is a very active developing project Other things we evaluated: svn: is no because of poor performance on large projects especially on windows svk: is no because it is written in perl and that is not liked by some developers cvs: is no because it is old and there are several better options monotone: is no because it doesn't have real version numbers, and a very complicated data model clearcase: is no because it is obscenely expensive, and doesn't have a detached working mode, and is super complicated, and proprietary perforce: is no because it doesn't have a good concept of detached working and is proprietary git: is no because it doesn't work on windows and has a very specific work flow in mind arch: honestly haven't looked at that much, has a complicated model for versions. So we're going to use SVN for managing our website and Drupal on our end, but for browser development, we're using something other than SVN. Just thought you guys might like another (poosibly OT) opinion. Chris On 11/15/05, Moshe Weitzman wrote: > > If anybody wants to code this please get in touch and I'll > > support it so we can move to SVN. > > and if you do, feel free to just commit on top of the current > svn.module. i built that out of need when few php based svn repos > browsers were available. > > -moshe > > From occy at occy.net Wed Nov 16 02:35:06 2005 From: occy at occy.net (Trae McCombs) Date: Wed Nov 16 02:34:56 2005 Subject: [development] subversion In-Reply-To: <1bc4603e0511151807s7e2f1e86pfc76ccbd199e5d67@mail.gmail.com> References: <4379C12A.1070805@killesreiter.de> <4BF1D26D-5977-4EB7-9DCD-F1B3EBC54D52@bryght.com> <3C8ED0F5-FF34-4F2F-A0D5-E8E3453C8F5A@civicspacelabs.org> <4379F701.1010003@tejasa.com> <1bc4603e0511151807s7e2f1e86pfc76ccbd199e5d67@mail.gmail.com> Message-ID: <1132108506.21921.78.camel@localhost.localdomain> It took a while, but I finally found the License. It seems it is GPL, which gets a thumbs up from me. :) That said, isn't it best to simply stay with a devil you know vs. one you don't? Trae On Tue, 2005-11-15 at 18:07 -0800, Chris Messina wrote: > Just an FYI, we recently decided at Flock not to go with SVN for our > browser work but to instead use Mercurial > (http://www.selenic.com/mercurial/wiki/index.cgi). Here are the > reasons: > > Up sides: > > 1. distributed source model > local versioning and ability to merge with other repositories > 2. native binary support > no stupid corrupt image files from forgetting to tag things, > better performance > 3. 3 way merge > better merging logic for changes > 4. native client-server concept > better network performance > 5. good performance on all platforms > 6. simple clear architecture > this is as opposed to svk, or CVS. I don't see it quite as clean > as svn, where you can just imagine everything as a file sitting in > a path > 7. Has concept of both versions and change-sets > nicer ways to think about changes > > Down Sides > > 1. mediocre windows support > seems to work on windows, but the dev team does not have a > full-time windows user, and there are more "minor" bugs on the > windows version than UNX versions (double warning messages, fewer > command-line shortcuts) > 2. rename support is not yet there > this is in dev tree > 3. medium disk space usage > 340MB in CVS -> 700MB in HG > 4. Not much integration with existing software > There is no bug/project tracking system integrations, or very > many web front ends to it, though the one it has is pretty good > 5. mediocre branching > branching is no worse than CVS, but not really much better, not as > nice as svn/svk > 6. still a bit immature > but pretty well documented, this is a very active developing project > > Other things we evaluated: > > svn: is no because of poor performance on large projects especially on windows > svk: is no because it is written in perl and that is not liked by some > developers > cvs: is no because it is old and there are several better options > monotone: is no because it doesn't have real version numbers, and a > very complicated data model > clearcase: is no because it is obscenely expensive, and doesn't have a > detached working mode, and is super complicated, and proprietary > perforce: is no because it doesn't have a good concept of detached > working and is proprietary > git: is no because it doesn't work on windows and has a very specific > work flow in mind > arch: honestly haven't looked at that much, has a complicated model > for versions. > > So we're going to use SVN for managing our website and Drupal on our > end, but for browser development, we're using something other than > SVN. > > Just thought you guys might like another (poosibly OT) opinion. > > Chris > > On 11/15/05, Moshe Weitzman wrote: > > > If anybody wants to code this please get in touch and I'll > > > support it so we can move to SVN. > > > > and if you do, feel free to just commit on top of the current > > svn.module. i built that out of need when few php based svn repos > > browsers were available. > > > > -moshe > > > > -- Trae "occy" McCombs || http://occy.net/ Founder - Themes.org // Linux.com CivicSpaceLabs - http://civicspacelabs.org/ From karoly at negyesi.net Wed Nov 16 02:43:48 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Wed Nov 16 02:40:46 2005 Subject: [development] subversion In-Reply-To: <1bc4603e0511151807s7e2f1e86pfc76ccbd199e5d67@mail.gmail.com> References: <4379C12A.1070805@killesreiter.de> <4BF1D26D-5977-4EB7-9DCD-F1B3EBC54D52@bryght.com> <3C8ED0F5-FF34-4F2F-A0D5-E8E3453C8F5A@civicspacelabs.org> <4379F701.1010003@tejasa.com> <1bc4603e0511151807s7e2f1e86pfc76ccbd199e5d67@mail.gmail.com> Message-ID: On Wed, 16 Nov 2005 03:07:55 +0100, Chris Messina wrote: > Just an FYI, we recently decided at Flock not to go with SVN for our > browser work but to instead use Mercurial If there is no Windows GUI, we can't use it. Case closed. I wanted to write that if this statement would not stand I'd vote on bzr. But... http://meld.sourceforge.net/ since november 9 Meld has bzr support! Yay! And there is GTK+ on Windows: http://www.gimp.org/~tml/gimp/win32/ and there is PyGTK on Windows: http://www.pcpm.ucl.ac.be/~gustin/win32_ports/ so let me ask very happily this from the list: What do you think of bzr (aka bazaar-ng)? I say, get prepared now, and launch in sync with bzr 2.0. Regards NK Ps. For those with Google allergies: http://bazaar.canonical.com From Curtis_Nelson at health.state.ak.us Wed Nov 16 03:16:24 2005 From: Curtis_Nelson at health.state.ak.us (Nelson, Curtis) Date: Wed Nov 16 03:13:47 2005 Subject: [development] subversion Message-ID: <959170B7B87DD711A7CB00065BF85BB30142F635@anc7.hss.state.ak.us> > What do you think of bzr (aka bazaar-ng)? I say, get prepared now, and launch in sync with bzr 2.0. Uh oh. This could be the start of a very long thread. One idea might be to take a look at using Tailor (http://www.darcs.net/DarcsWiki/Tailor) to try out or offer different repositories -- its seems to work well for syncing between cvs and subversion and I've seen projects that just off-load from CVS to mercurial for development. In any case you can use it to see what the code-base might look like in a different system. -Curtis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051116/958b8b54/attachment.htm From walkah at walkah.net Wed Nov 16 03:17:20 2005 From: walkah at walkah.net (James Walker) Date: Wed Nov 16 03:17:09 2005 Subject: [development] subversion In-Reply-To: <1bc4603e0511151807s7e2f1e86pfc76ccbd199e5d67@mail.gmail.com> References: <4379C12A.1070805@killesreiter.de> <4BF1D26D-5977-4EB7-9DCD-F1B3EBC54D52@bryght.com> <3C8ED0F5-FF34-4F2F-A0D5-E8E3453C8F5A@civicspacelabs.org> <4379F701.1010003@tejasa.com> <1bc4603e0511151807s7e2f1e86pfc76ccbd199e5d67@mail.gmail.com> Message-ID: <437AA4C0.4050702@walkah.net> On 11/15/05 9:07 PM, Chris Messina wrote: > So we're going to use SVN for managing our website and Drupal on our > end, but for browser development, we're using something other than > SVN. okaaay.. so all those of us developing browsers should have a look at mercurial. i'm picking on you, but we're talking about a much larger development community than flock's (where it's mostly flock inc. + a few EFA's). Things like good support on all platforms, and integrations in popular IDE's etc are pretty crucial to adoption. I'm not particularly wedded to any SCM system... but right now, I think there are bigger things to worry about in the community than version control systems. I like SVN because it fixes some of CVS's braindeadedness without working too much differently. -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net From chris.messina at gmail.com Wed Nov 16 05:11:12 2005 From: chris.messina at gmail.com (Chris Messina) Date: Wed Nov 16 05:11:15 2005 Subject: [development] subversion In-Reply-To: <437AA4C0.4050702@walkah.net> References: <4379C12A.1070805@killesreiter.de> <4BF1D26D-5977-4EB7-9DCD-F1B3EBC54D52@bryght.com> <3C8ED0F5-FF34-4F2F-A0D5-E8E3453C8F5A@civicspacelabs.org> <4379F701.1010003@tejasa.com> <1bc4603e0511151807s7e2f1e86pfc76ccbd199e5d67@mail.gmail.com> <437AA4C0.4050702@walkah.net> Message-ID: <1bc4603e0511152111s54eebb61reb1a5f618830b36f@mail.gmail.com> Fair enough. It just seemed like it might be interesting to see another perspective, though I grant you our needs are notably different than Drupal's. Chris On 11/15/05, James Walker wrote: > On 11/15/05 9:07 PM, Chris Messina wrote: > > So we're going to use SVN for managing our website and Drupal on our > > end, but for browser development, we're using something other than > > SVN. > > okaaay.. so all those of us developing browsers should have a look at > mercurial. i'm picking on you, but we're talking about a much larger > development community than flock's (where it's mostly flock inc. + a few > EFA's). > > Things like good support on all platforms, and integrations in popular > IDE's etc are pretty crucial to adoption. > > I'm not particularly wedded to any SCM system... but right now, I think > there are bigger things to worry about in the community than version > control systems. I like SVN because it fixes some of CVS's > braindeadedness without working too much differently. > > -- > James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net > From dries at buytaert.net Wed Nov 16 07:21:20 2005 From: dries at buytaert.net (Dries Buytaert) Date: Wed Nov 16 07:21:25 2005 Subject: [development] Drupal 4.7.0 update In-Reply-To: <20051115231851.GB13706@mallorn.ii.uj.edu.pl> References: <72FD72C7-7BD9-4BCE-B839-47F1B967B16D@buytaert.net> <20051115231851.GB13706@mallorn.ii.uj.edu.pl> Message-ID: > It needs testing (yes, people using mysql have to test it too!) and > probably some work. I'm getting some weird warnings with this > patch, but > I haven't confirmed if they are related to the patch. > > If this bug is not fixed, 4.7 will be second main Drupal release > (after > 4.6) which does NOT support caching AT ALL. Full PostgreSQL support is a release requirement. I encourage everybody to help with this issue. -- Dries Buytaert :: http://www.buytaert.net/ From john at handelaar.org Wed Nov 16 07:24:49 2005 From: john at handelaar.org (John Handelaar) Date: Wed Nov 16 07:24:59 2005 Subject: [development] subversion In-Reply-To: <437AA4C0.4050702@walkah.net> References: <4379C12A.1070805@killesreiter.de> <4BF1D26D-5977-4EB7-9DCD-F1B3EBC54D52@bryght.com> <3C8ED0F5-FF34-4F2F-A0D5-E8E3453C8F5A@civicspacelabs.org> <4379F701.1010003@tejasa.com> <1bc4603e0511151807s7e2f1e86pfc76ccbd199e5d67@mail.gmail.com> <437AA4C0.4050702@walkah.net> Message-ID: <437ADEC1.7040308@handelaar.org> James Walker wrote: > I'm not particularly wedded to any SCM system... but right now, I think > there are bigger things to worry about in the community than version > control systems. I like SVN because it fixes some of CVS's > braindeadedness without working too much differently. +1 Also, I'm not about to start wasting eyeball time reading a thread where everyone and his dog mentions his own mutually-incompatible alternative to cvs. And nobody (correct for rounding) is going to touch it if we're not using cvs or svn. Why on earth would I want to learn to use a different tool for each project I'm involved with? That's like using a different browser for each web site. Although I see we're also having _that_ discussion at the moment with respect to Mac users. [sigh]. jh From kkaefer at gmail.com Wed Nov 16 07:35:31 2005 From: kkaefer at gmail.com (=?ISO-8859-1?Q?Konstantin_K=E4fer?=) Date: Wed Nov 16 07:35:33 2005 Subject: [development] replace drupal.js with prototype.js? In-Reply-To: References: <005d01c5e999$c452dc80$6400a8c0@family> Message-ID: <3ff472c00511152335t794cfb4dm@mail.gmail.com> In fact, prototype are separate files. They are just put together for the release. See http://dev.conio.net/repos/prototype/src/ for the single files. 2005/11/16, Richard Archer : > At 11:34 AM +1100 16/11/05, Jeremy Epstein wrote: > > >Prototype does indeed seem to be a very light, clean, and extensible > >library: but nonetheless, it is nowhere near as light as drupal.js. > >Quick comparison: > > > >Drupal.js: 281 lines, 6.21KB > >Prototype.js: 1039 lines, 27.29KB > > All the Drupal .js files combines come to 18 kB. > > Is it possible to strip prototype down a bit? > > There are a lot of comments in the file that wouldn't be needed > in a live site. > > What about separating it into function-related files and just > sending the bits the page needs? > > ...R. > -- http://timcn.de From drupal.org at juggernaut.com.au Wed Nov 16 08:05:46 2005 From: drupal.org at juggernaut.com.au (Richard Archer) Date: Wed Nov 16 08:05:37 2005 Subject: [development] How big is contrib? Message-ID: If I wanted to check out all the contributions, how much disk space and bandwidth would I be looking at? Or... is there any other way to grep through contrib modules? I want to know how many use the forms API's #post_process feature to evaluate the impact of a potential patch. ...R. From karoly at negyesi.net Wed Nov 16 08:16:19 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Wed Nov 16 08:13:15 2005 Subject: [development] How big is contrib? In-Reply-To: References: Message-ID: > I want to know how many use the forms API's #post_process > feature to evaluate the impact of a potential patch. Noone even knows that exists :) I am about to rename it because it's damned confusing -- new is #after_build. If you want to merge the rename and param removal patch into one, be my guest. Regards NK From karoly at negyesi.net Wed Nov 16 08:17:37 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Wed Nov 16 08:14:31 2005 Subject: [development] How big is contrib? In-Reply-To: References: Message-ID: > I want to know how many use the forms API's #post_process > feature to evaluate the impact of a potential patch. And already I am wrong: image does use it... From karoly at negyesi.net Wed Nov 16 08:24:43 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Wed Nov 16 08:21:40 2005 Subject: [development] subversion In-Reply-To: <437ADEC1.7040308@handelaar.org> References: <4379C12A.1070805@killesreiter.de> <4BF1D26D-5977-4EB7-9DCD-F1B3EBC54D52@bryght.com> <3C8ED0F5-FF34-4F2F-A0D5-E8E3453C8F5A@civicspacelabs.org> <4379F701.1010003@tejasa.com> <1bc4603e0511151807s7e2f1e86pfc76ccbd199e5d67@mail.gmail.com> <437AA4C0.4050702@walkah.net> <437ADEC1.7040308@handelaar.org> Message-ID: > And nobody (correct for rounding) is going to touch it if we're > not using cvs or svn. Why on earth would I want to learn to use > a different tool for each project I'm involved with? To quote James Blackwell from bzr: If that argument were true, everyone would be running windows xp, there would be no macs, and every webserver would be apache. :) and we'd all _still_ be running sendmail. =) CVS has been around for roughly forever, but it too displaced something else -- cssc and sccs. SVN has prided itself on retaining CVS's feel with the addition of a couple features. Which is fine, but would you really want to deal with something trying to be like CVS for the rest of your life? From puregin at puregin.org Wed Nov 16 08:55:59 2005 From: puregin at puregin.org (puregin) Date: Wed Nov 16 08:56:04 2005 Subject: [development] subversion In-Reply-To: <437ADEC1.7040308@handelaar.org> References: <4379C12A.1070805@killesreiter.de> <4BF1D26D-5977-4EB7-9DCD-F1B3EBC54D52@bryght.com> <3C8ED0F5-FF34-4F2F-A0D5-E8E3453C8F5A@civicspacelabs.org> <4379F701.1010003@tejasa.com> <1bc4603e0511151807s7e2f1e86pfc76ccbd199e5d67@mail.gmail.com> <437AA4C0.4050702@walkah.net> <437ADEC1.7040308@handelaar.org> Message-ID: On 15 Nov 2005, at 11:24 PM, John Handelaar wrote: > > That's like using a different browser for each web site. Although > I see we're also having _that_ discussion at the moment with respect > to Mac users. [sigh]. > RIght! That's why I use Flock for every website :) Thanks for sharing the results of your review, Chris - I found it interesting and thought provoking. Any ideas why subversion is slow? DB implementation? Transactional model? Djun From ber at webschuur.com Wed Nov 16 10:13:25 2005 From: ber at webschuur.com (Ber Kessels) Date: Wed Nov 16 10:13:27 2005 Subject: [development] replace drupal.js with prototype.js? In-Reply-To: <80a220dc0511151523u2fbef0e8p99b23023bddb7d60@mail.gmail.com> References: <005d01c5e999$c452dc80$6400a8c0@family> <1132058082.8154.10.camel@localhost.localdomain> <20051115182013.GB11841@localhost> <80a220dc0511151523u2fbef0e8p99b23023bddb7d60@mail.gmail.com> Message-ID: <20051116111325.e1c65325.ber@webschuur.com> prototype is not GPL, it is MIT. we only allow GPL. I think this is a big problem. Ber On Tue, 15 Nov 2005 15:23:23 -0800 Colin Brumelle wrote: > I've done some work with Prototype, and have found it to be really well > thought out. I would love to see Drupal standardise on this package for > adding AJAX functionality. Prototypes inclusion in Rails also offers some > guarantees that it will be around for a while, developed further, and > maintained. > > +1 from me... > > ------------------- > Colin Brumelle > colin@bryght.com > http://bryght.com > http://mixedcontent.com > Cell: 604.351.0547 > Office: 604.682.2889 > skype/jabber/aim: cbrumelle > -- B?r Kessels Drupal services bler.webschuur.com www.webschuur.com ber@jabber.webschuur.com From karoly at negyesi.net Wed Nov 16 10:51:01 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Wed Nov 16 10:47:57 2005 Subject: [development] Mark "dangerous" permissions Message-ID: Hi! What about marking with an ugly big red something administer filters and administer user access? Regards NK From dries.knapen at versateladsl.be Wed Nov 16 11:33:27 2005 From: dries.knapen at versateladsl.be (dries.knapen@versateladsl.be) Date: Wed Nov 16 11:33:31 2005 Subject: [development] How big is contrib? Message-ID: <1132140807.437b190781c28@www.versateladsl.be> > If I wanted to check out all the contributions, how much > disk space and bandwidth would I be looking at? If you still want to know: contributions/modules is 43.8 MB. From bmansion at mamasam.com Wed Nov 16 11:50:23 2005 From: bmansion at mamasam.com (Bertrand Mansion) Date: Wed Nov 16 11:50:16 2005 Subject: [development] No HEAD in bug report version select Message-ID: Hi, I just submitted a bug report about taxonomy.module inserting duplicates in term_node table: http://drupal.org/node/37829 But it seems there is no 4.7 or HEAD or MAIN in the version select box so it was assigned to 4.6.3 by default. Is there a way to correctly assign the version to the current version in CVS ? Thanks, -- Bertrand Mansion http://www.mamasam.com - creative internet solutions http://golgote.freeflux.net - my blog From eafarris at gmail.com Wed Nov 16 11:50:23 2005 From: eafarris at gmail.com (eric Farris) Date: Wed Nov 16 11:50:26 2005 Subject: [development] How big is contrib? In-Reply-To: References: Message-ID: <99197af20511160350x7b727f23u37e2db5e92cd5347@mail.gmail.com> On 11/16/05, Richard Archer wrote: > If I wanted to check out all the contributions, how much > disk space and bandwidth would I be looking at? > Here's my mirrors: $ du -sh drupal-cvs/* 52M drupal-cvs/contrib-4.6 119M drupal-cvs/contributions 2.2M drupal-cvs/drupal 2.0M drupal-cvs/drupal-4.6 -- e one inch frame: http://eafarris.al.umces.edu/ From piotr at mallorn.ii.uj.edu.pl Wed Nov 16 11:56:22 2005 From: piotr at mallorn.ii.uj.edu.pl (Piotr Krukowiecki) Date: Wed Nov 16 11:56:24 2005 Subject: [development] How big is contrib? In-Reply-To: <99197af20511160350x7b727f23u37e2db5e92cd5347@mail.gmail.com> References: <99197af20511160350x7b727f23u37e2db5e92cd5347@mail.gmail.com> Message-ID: <20051116115622.GA23016@mallorn.ii.uj.edu.pl> On Wed, Nov 16, 2005 at 06:50:23AM -0500, eric Farris wrote: > On 11/16/05, Richard Archer wrote: > > If I wanted to check out all the contributions, how much > > disk space and bandwidth would I be looking at? > > > > Here's my mirrors: > > $ du -sh drupal-cvs/* > 52M drupal-cvs/contrib-4.6 > 119M drupal-cvs/contributions > 2.2M drupal-cvs/drupal > 2.0M drupal-cvs/drupal-4.6 Bear in mind that cvs can transfer files compressed (-z 9 switch), so the bw needed is much smaller. -- Piotrek irc: #debian.pl Mors Drosophilis melanogastribus! From piotr at mallorn.ii.uj.edu.pl Wed Nov 16 11:57:16 2005 From: piotr at mallorn.ii.uj.edu.pl (Piotr Krukowiecki) Date: Wed Nov 16 11:57:18 2005 Subject: [development] No HEAD in bug report version select In-Reply-To: References: Message-ID: <20051116115716.GB23016@mallorn.ii.uj.edu.pl> On Wed, Nov 16, 2005 at 12:50:23PM +0100, Bertrand Mansion wrote: > But it seems there is no 4.7 or HEAD or MAIN in the version select box so it was > assigned to 4.6.3 by default. Is there a way to correctly assign the version to > the current version in CVS ? There's "cvs" version (even a couple of them ;)) -- Piotrek irc: #debian.pl Mors Drosophilis melanogastribus! From bmansion at mamasam.com Wed Nov 16 11:58:18 2005 From: bmansion at mamasam.com (Bertrand Mansion) Date: Wed Nov 16 11:58:11 2005 Subject: [development] No HEAD in bug report version select In-Reply-To: <20051116115716.GB23016@mallorn.ii.uj.edu.pl> Message-ID: Piotr Krukowiecki wrote: >On Wed, Nov 16, 2005 at 12:50:23PM +0100, Bertrand Mansion wrote: >> But it seems there is no 4.7 or HEAD or MAIN in the version select box so it >was >> assigned to 4.6.3 by default. Is there a way to correctly assign the version >to >> the current version in CVS ? > >There's "cvs" version (even a couple of them ;)) Yes, maybe too many of them. How do I know I picked the right one ? :) -- Bertrand Mansion http://www.mamasam.com - creative internet solutions http://golgote.freeflux.net - my blog From piotr at mallorn.ii.uj.edu.pl Wed Nov 16 11:59:46 2005 From: piotr at mallorn.ii.uj.edu.pl (Piotr Krukowiecki) Date: Wed Nov 16 11:59:47 2005 Subject: [development] Drupal 4.7.0 update In-Reply-To: <20051115231851.GB13706@mallorn.ii.uj.edu.pl> References: <72FD72C7-7BD9-4BCE-B839-47F1B967B16D@buytaert.net> <20051115231851.GB13706@mallorn.ii.uj.edu.pl> Message-ID: <20051116115946.GC23016@mallorn.ii.uj.edu.pl> On Wed, Nov 16, 2005 at 12:18:51AM +0100, Piotr Krukowiecki wrote: > It needs testing (yes, people using mysql have to test it too!) and What I meant is that although the bug is in Postgres the patch changes db_query() function which is used by everyone so I need people with mysql to test if it works. Also, there seems to be similar bug in mysql: http://drupal.org/node/16998 -- Piotrek irc: #debian.pl Mors Drosophilis melanogastribus! From piotr at mallorn.ii.uj.edu.pl Wed Nov 16 12:00:37 2005 From: piotr at mallorn.ii.uj.edu.pl (Piotr Krukowiecki) Date: Wed Nov 16 12:00:39 2005 Subject: [development] No HEAD in bug report version select In-Reply-To: References: <20051116115716.GB23016@mallorn.ii.uj.edu.pl> Message-ID: <20051116120037.GD23016@mallorn.ii.uj.edu.pl> On Wed, Nov 16, 2005 at 12:58:18PM +0100, Bertrand Mansion wrote: > Piotr Krukowiecki wrote: > >There's "cvs" version (even a couple of them ;)) > > Yes, maybe too many of them. How do I know I picked the right one ? :) You don't ;) But if you choose the first one it'll be ok. -- Piotrek irc: #debian.pl Mors Drosophilis melanogastribus! From drupal.org at juggernaut.com.au Wed Nov 16 12:13:26 2005 From: drupal.org at juggernaut.com.au (Richard Archer) Date: Wed Nov 16 12:13:08 2005 Subject: [development] How big is contrib? In-Reply-To: <1132140807.437b190781c28@www.versateladsl.be> References: <1132140807.437b190781c28@www.versateladsl.be> Message-ID: At 12:33 PM +0100 16/11/05, dries.knapen@versateladsl.be wrote: >If you still want to know: contributions/modules is 43.8 MB. Thanks for all those responses... I'll clean up some disk space and pull all that down... one day :) ...Richard. From lsmoura at gmail.com Wed Nov 16 13:09:09 2005 From: lsmoura at gmail.com (Sergio) Date: Wed Nov 16 13:09:11 2005 Subject: [development] Node referencing Message-ID: <20a3038c0511160509g11d6a34ue0a500b301b925c9@mail.gmail.com> Hello, folks, I'm in need of a little help... I have a module with 3 types of node. Node A, B and C. I am trying to do something like A is the main node and B & C references A. So that, when I show the node A (teaser or full node), I get some informations about nodes type B and C that makes reference to A. Also, I want to node types B and C have a reference to the parent (A). When the user inserts the data, it must be transparent to him as who the parent is (like there is a link on node type A that allows the user to create type B or C and the node creation page will not ask the user who the parent is). The only creation method shoud be like this for nodes B and C (there should not have a link on the node creation list. Just for type A) I took a look at the project module, but I couldn't get much out of it... Any help is appreciated... Thanks, - Luis Sergio Moura -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051116/0cf404cd/attachment.htm From gerhard at killesreiter.de Wed Nov 16 13:18:34 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Wed Nov 16 13:19:36 2005 Subject: [development] How big is contrib? In-Reply-To: References: Message-ID: <437B31AA.2060702@killesreiter.de> Richard Archer wrote: >If I wanted to check out all the contributions, how much >disk space and bandwidth would I be looking at? > > killes@theo-dhcp-42:~/checkouts/contributions$ du -ks 131136 >Or... is there any other way to grep through contrib modules? > > > Not really. >I want to know how many use the forms API's #post_process >feature to evaluate the impact of a potential patch. > > > Not too many yet; image/image.module: $form['thumbnail']['#post_process'] = 'image_form_add_thumbnail'; project/comment.inc: $form['#post_process'] = 'node_form_add_preview'; Also, we don't care for the number of times something needs to be changed in contrib. Cheers, Gerhard From walkah at walkah.net Wed Nov 16 13:59:24 2005 From: walkah at walkah.net (James Walker) Date: Wed Nov 16 14:04:23 2005 Subject: [development] How big is contrib? In-Reply-To: References: Message-ID: <437B3B3C.40807@walkah.net> On 11/16/05 3:17 AM, Karoly Negyesi wrote: >> I want to know how many use the forms API's #post_process >> feature to evaluate the impact of a potential patch. > > And already I am wrong: image does use it... yeah it does, and can you please outline why exactly it needs to change? i don't think just renaming for the heck of it at this point makes much sense. that's the kind of stuff that should have been done before formapi hit core, imnsho. -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net From walkah at walkah.net Wed Nov 16 14:08:55 2005 From: walkah at walkah.net (James Walker) Date: Wed Nov 16 14:13:54 2005 Subject: [development] subversion In-Reply-To: References: <4379C12A.1070805@killesreiter.de> <4BF1D26D-5977-4EB7-9DCD-F1B3EBC54D52@bryght.com> <3C8ED0F5-FF34-4F2F-A0D5-E8E3453C8F5A@civicspacelabs.org> <4379F701.1010003@tejasa.com> <1bc4603e0511151807s7e2f1e86pfc76ccbd199e5d67@mail.gmail.com> <437AA4C0.4050702@walkah.net> <437ADEC1.7040308@handelaar.org> Message-ID: <437B3D77.1090206@walkah.net> On 11/16/05 3:24 AM, Karoly Negyesi wrote: >> And nobody (correct for rounding) is going to touch it if we're >> not using cvs or svn. Why on earth would I want to learn to use >> a different tool for each project I'm involved with? > > To quote James Blackwell from bzr: > > If that argument were true, everyone would be running windows xp, there > would be no macs, and every webserver would be apache. :) and we'd all > _still_ be running sendmail. =) CVS has been around for roughly forever, > but it too displaced something else -- cssc and sccs. SVN has prided > itself on retaining CVS's feel with the addition of a couple features. > Which is fine, but would you really want to deal with something trying > to be like CVS for the rest of your life? that's a pretty weak argument. first off, macs predate windows XP (and windows in general) - fraknly i've never run XP for anything... most webservers are apache... and as for sendmail... no we don't run sendmail we run things that are functionally equivalent to sendmail but much easier to setup & maintain and that have some added features. y'know ... kinda like svn vs. cvs. -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net From adrian at bryght.com Wed Nov 16 14:02:12 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Wed Nov 16 14:37:17 2005 Subject: [development] Node referencing In-Reply-To: <20a3038c0511160509g11d6a34ue0a500b301b925c9@mail.gmail.com> References: <20a3038c0511160509g11d6a34ue0a500b301b925c9@mail.gmail.com> Message-ID: <159BF9C2-C02A-428A-8E9B-A8AB0FA44E07@bryght.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16 Nov 2005, at 3:09 PM, Sergio wrote: > Hello, folks, > I'm in need of a little help... > I have a module with 3 types of node. Node A, B and C. > I am trying to do something like A is the main node and B & C > references A. So that, when I show the node A (teaser or full > node), I get some informations about nodes type B and C that makes > reference to A. > Also, I want to node types B and C have a reference to the parent > (A). Welcome to the wonderful world of node relationships. We're busy working on a generalized API that allows you to do this kind of thing, but i don't know if there's any code you can use today (you can try clipper.module). > - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDezvkgegMqdGlkasRAhowAJ9qoGdgkMHJt5szWlr6RiIlBkyclgCgtgc4 jYcY6+AHFSPLfFyV8mz68/U= =QKcE -----END PGP SIGNATURE----- From karoly at negyesi.net Wed Nov 16 14:44:13 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Wed Nov 16 14:41:08 2005 Subject: [development] How big is contrib? In-Reply-To: <437B3B3C.40807@walkah.net> References: <437B3B3C.40807@walkah.net> Message-ID: On Wed, 16 Nov 2005 14:59:24 +0100, James Walker wrote: > On 11/16/05 3:17 AM, Karoly Negyesi wrote: >>> I want to know how many use the forms API's #post_process >>> feature to evaluate the impact of a potential patch. >> And already I am wrong: image does use it... > > yeah it does, and can you please outline why exactly it needs to change? > i don't think just renaming for the heck of it at this point makes > much sense. that's the kind of stuff that should have been done before > formapi hit core, imnsho. James, for heaven's sake, where were you when we ported core? Have you said that 'stop, this will confuse users'? We made an error by naming that so, and we correct it before spreads. It confuses people because here post refers to "after" as in "after the build is done" and not $_POST. Why is it so bad to adjust it after it hit core? If it wouldn't do you think anyone would have tested a four houndred kilobyte patch? Regards NK From prometheus6 at gmail.com Wed Nov 16 15:11:45 2005 From: prometheus6 at gmail.com (Earl Dunovant) Date: Wed Nov 16 15:11:49 2005 Subject: [development] Node referencing In-Reply-To: <20a3038c0511160509g11d6a34ue0a500b301b925c9@mail.gmail.com> References: <20a3038c0511160509g11d6a34ue0a500b301b925c9@mail.gmail.com> Message-ID: You just need to get the nid of the main node into the creation of the subordinate node typoes. How about using a query string to specify the parent, like node/add/B?mainnode=(nid of A) or maybe node/add/B/(nid of A) Populate the new field in hook_form(). You can even choose to show an input control for the field if it's not specified On 11/16/05, Sergio wrote: > > Hello, folks, > I'm in need of a little help... > I have a module with 3 types of node. Node A, B and C. > I am trying to do something like A is the main node and B & C references > A. So that, when I show the node A (teaser or full node), I get some > informations about nodes type B and C that makes reference to A. > Also, I want to node types B and C have a reference to the parent (A). > When the user inserts the data, it must be transparent to him as who the > parent is (like there is a link on node type A that allows the user to > create type B or C and the node creation page will not ask the user who the > parent is). The only creation method shoud be like this for nodes B and C > (there should not have a link on the node creation list. Just for type A) > > I took a look at the project module, but I couldn't get much out of it... > Any help is appreciated... > > Thanks, > - Luis Sergio Moura > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051116/ec0de50a/attachment.htm From nicolast at logis.com.mx Wed Nov 16 15:41:45 2005 From: nicolast at logis.com.mx (Nicolas Tostin) Date: Wed Nov 16 15:41:58 2005 Subject: [development] How big is contrib? References: <99197af20511160350x7b727f23u37e2db5e92cd5347@mail.gmail.com> <20051116115622.GA23016@mallorn.ii.uj.edu.pl> Message-ID: <006201c5eac4$40c09660$b400a8c0@Nikko> > Bear in mind that cvs can transfer files compressed (-z 9 switch), so the bw > needed is much smaller. > > Thanks for the -z 9 switch From lsmoura at gmail.com Wed Nov 16 15:48:38 2005 From: lsmoura at gmail.com (Sergio) Date: Wed Nov 16 15:48:42 2005 Subject: [development] Node referencing In-Reply-To: References: <20a3038c0511160509g11d6a34ue0a500b301b925c9@mail.gmail.com> Message-ID: <20a3038c0511160748x5efd6990ja8bf4d690949c73a@mail.gmail.com> Earl, I tought about that... I have a ?q=node/add/B/5 and I changed the hook_form to function B_form(&$node, &$param, $nidA = 0) But I don't get the desired result... The page at drupaldocs http://drupaldocs.org/api/4.6/function/page_example_menusays that the 'extra' parameters will be passed as arguments to the function, but it seems that those don't get to the hook_form function. Is there any way to create a custom function and re-create the form as the node/add/B would do? That way I could create the form and it would work transparently to the user... Also, is it that the desired hook_form behavior? Have I found a bug? :-) Thanks for the help... On 11/16/05, Earl Dunovant wrote: > > You just need to get the nid of the main node into the creation of the > subordinate node typoes. How about using a query string to specify the > parent, like > > node/add/B?mainnode=(nid of A) > > or maybe > > node/add/B/(nid of A) > > Populate the new field in hook_form(). You can even choose to show an > input control for the field if it's not specified > > On 11/16/05, Sergio wrote: > > > > Hello, folks, > > I'm in need of a little help... > > I have a module with 3 types of node. Node A, B and C. > > I am trying to do something like A is the main node and B & C references > > A. So that, when I show the node A (teaser or full node), I get some > > informations about nodes type B and C that makes reference to A. > > Also, I want to node types B and C have a reference to the parent (A). > > When the user inserts the data, it must be transparent to him as who the > > parent is (like there is a link on node type A that allows the user to > > create type B or C and the node creation page will not ask the user who the > > parent is). The only creation method shoud be like this for nodes B and C > > (there should not have a link on the node creation list. Just for type A) > > > > I took a look at the project module, but I couldn't get much out of > > it... > > Any help is appreciated... > > > > Thanks, > > - Luis Sergio Moura > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051116/917a28cb/attachment.htm From lsmoura at gmail.com Wed Nov 16 16:10:16 2005 From: lsmoura at gmail.com (Sergio) Date: Wed Nov 16 16:10:19 2005 Subject: [development] Node referencing In-Reply-To: <20a3038c0511160748x5efd6990ja8bf4d690949c73a@mail.gmail.com> References: <20a3038c0511160509g11d6a34ue0a500b301b925c9@mail.gmail.com> <20a3038c0511160748x5efd6990ja8bf4d690949c73a@mail.gmail.com> Message-ID: <20a3038c0511160810t51cd182dr5f47473b282a6c78@mail.gmail.com> I don't have a DIFF here, but here it goes... I tweaked the node.module a bit (4.6.3) so the I could make the /node/add// works and I get the desires result... This need to be tweaked further so that more parameters can be added... function node_page() { (...) case 'add': print theme('page', node_add(arg(2), arg(3))); break; (...) function node_add($type, $_extra = 0) { (...) } $output = node_form($node, $_extra); drupal_set_title(t('Submit %name', array('%name' => node_invoke($node, 'node_name')))); (...) function node_form($edit, $_extra = 0) { (...) if (function_exists($function)) { if ($_extra) $form .= $function($edit, $param, $_extra); else $form .= $function($edit, $param); } (...) function B_form(&$node, &$param, $nidA = 0) That does the trick... But as I don't think that this is the desired function of node.module, I will try and write my code another way so that it stays compatible with the official version... Altough I get no warnings with the above changes (so far). Back to the module coding now... Thanks all - Sergio On 11/16/05, Sergio wrote: > > Earl, > I tought about that... > > I have a ?q=node/add/B/5 and I changed the hook_form to function > B_form(&$node, &$param, $nidA = 0) But I don't get the desired result... The > page at drupaldocs > http://drupaldocs.org/api/4.6/function/page_example_menu says that the > 'extra' parameters will be passed as arguments to the function, but it seems > that those don't get to the hook_form function. Is there any way to create a > custom function and re-create the form as the node/add/B would do? That way > I could create the form and it would work transparently to the user... > Also, is it that the desired hook_form behavior? Have I found a bug? :-) > > Thanks for the help... > > On 11/16/05, Earl Dunovant < prometheus6@gmail.com> wrote: > > > > You just need to get the nid of the main node into the creation of the > > subordinate node typoes. How about using a query string to specify the > > parent, like > > > > node/add/B?mainnode=(nid of A) > > > > or maybe > > > > node/add/B/(nid of A) > > > > Populate the new field in hook_form(). You can even choose to show an > > input control for the field if it's not specified > > > > On 11/16/05, Sergio wrote: > > > > > > Hello, folks, > > > I'm in need of a little help... > > > I have a module with 3 types of node. Node A, B and C. > > > I am trying to do something like A is the main node and B & C > > > references A. So that, when I show the node A (teaser or full node), I get > > > some informations about nodes type B and C that makes reference to A. > > > Also, I want to node types B and C have a reference to the parent (A). > > > When the user inserts the data, it must be transparent to him as who > > > the parent is (like there is a link on node type A that allows the user to > > > create type B or C and the node creation page will not ask the user who the > > > parent is). The only creation method shoud be like this for nodes B and C > > > (there should not have a link on the node creation list. Just for type A) > > > > > > I took a look at the project module, but I couldn't get much out of > > > it... > > > Any help is appreciated... > > > > > > Thanks, > > > - Luis Sergio Moura > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051116/5b174079/attachment.htm From colin at bryght.com Wed Nov 16 16:55:24 2005 From: colin at bryght.com (Colin Brumelle) Date: Wed Nov 16 16:55:27 2005 Subject: [development] replace drupal.js with prototype.js? In-Reply-To: <20051116111325.e1c65325.ber@webschuur.com> References: <005d01c5e999$c452dc80$6400a8c0@family> <1132058082.8154.10.camel@localhost.localdomain> <20051115182013.GB11841@localhost> <80a220dc0511151523u2fbef0e8p99b23023bddb7d60@mail.gmail.com> <20051116111325.e1c65325.ber@webschuur.com> Message-ID: <80a220dc0511160855se3a147exd0682b3fb000dc05@mail.gmail.com> I believe the two licenses are compatible. See: http://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses On 11/16/05, Ber Kessels wrote: > > prototype is not GPL, it is MIT. we only allow GPL. I think this is a big > problem. > > Ber > > On Tue, 15 Nov 2005 15:23:23 -0800 > Colin Brumelle wrote: > > > I've done some work with Prototype, and have found it to be really well > > thought out. I would love to see Drupal standardise on this package for > > adding AJAX functionality. Prototypes inclusion in Rails also offers > some > > guarantees that it will be around for a while, developed further, and > > maintained. > > > > +1 from me... > > > > ------------------- > > Colin Brumelle > > colin@bryght.com > > http://bryght.com > > http://mixedcontent.com > > Cell: 604.351.0547 > > Office: 604.682.2889 > > skype/jabber/aim: cbrumelle > > > > > -- > B?r Kessels Drupal services > bler.webschuur.com www.webschuur.com > ber@jabber.webschuur.com > -- ------------------- Colin Brumelle colin@bryght.com http://bryght.com http://mixedcontent.com Cell: 604.351.0547 Office: 604.682.2889 skype/jabber/aim: cbrumelle -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051116/cf5c91e9/attachment.htm From prometheus6 at gmail.com Wed Nov 16 17:07:28 2005 From: prometheus6 at gmail.com (Earl Dunovant) Date: Wed Nov 16 17:07:35 2005 Subject: [development] Node referencing In-Reply-To: <20a3038c0511160748x5efd6990ja8bf4d690949c73a@mail.gmail.com> References: <20a3038c0511160509g11d6a34ue0a500b301b925c9@mail.gmail.com> <20a3038c0511160748x5efd6990ja8bf4d690949c73a@mail.gmail.com> Message-ID: Assuming /node/add/B?mainnode=5, something like this should work. function B_form(&$node, &$params) { $mainnode = $_GET['mainnode']; // make sure it's a valid node for the purpose if (nid_passes_the_test($mainnode) { $node->mainnode = $mainnode; } else { // yell at them for making an error } ... } On 11/16/05, Sergio wrote: > > Earl, > I tought about that... > > I have a ?q=node/add/B/5 and I changed the hook_form to function > B_form(&$node, &$param, $nidA = 0) But I don't get the desired result... The > page at drupaldocs > http://drupaldocs.org/api/4.6/function/page_example_menu says that the > 'extra' parameters will be passed as arguments to the function, but it seems > that those don't get to the hook_form function. Is there any way to create a > custom function and re-create the form as the node/add/B would do? That way > I could create the form and it would work transparently to the user... > Also, is it that the desired hook_form behavior? Have I found a bug? :-) > > Thanks for the help... > > On 11/16/05, Earl Dunovant < prometheus6@gmail.com> wrote: > > > > You just need to get the nid of the main node into the creation of the > > subordinate node typoes. How about using a query string to specify the > > parent, like > > > > node/add/B?mainnode=(nid of A) > > > > or maybe > > > > node/add/B/(nid of A) > > > > Populate the new field in hook_form(). You can even choose to show an > > input control for the field if it's not specified > > > > On 11/16/05, Sergio wrote: > > > > > > Hello, folks, > > > I'm in need of a little help... > > > I have a module with 3 types of node. Node A, B and C. > > > I am trying to do something like A is the main node and B & C > > > references A. So that, when I show the node A (teaser or full node), I get > > > some informations about nodes type B and C that makes reference to A. > > > Also, I want to node types B and C have a reference to the parent (A). > > > When the user inserts the data, it must be transparent to him as who > > > the parent is (like there is a link on node type A that allows the user to > > > create type B or C and the node creation page will not ask the user who the > > > parent is). The only creation method shoud be like this for nodes B and C > > > (there should not have a link on the node creation list. Just for type A) > > > > > > I took a look at the project module, but I couldn't get much out of > > > it... > > > Any help is appreciated... > > > > > > Thanks, > > > - Luis Sergio Moura > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051116/3f688df7/attachment-0001.htm From ber at webschuur.com Wed Nov 16 17:53:19 2005 From: ber at webschuur.com (=?utf-8?q?B=C3=A8r_Kessels?=) Date: Wed Nov 16 17:53:23 2005 Subject: [development] Node referencing In-Reply-To: References: <20a3038c0511160509g11d6a34ue0a500b301b925c9@mail.gmail.com> Message-ID: <200511161853.24997.ber@webschuur.com> Clipper module has an add child link; to add a relation to teh node you are looking at. Op woensdag 16 november 2005 16:11, schreef Earl Dunovant: > You just need to get the nid of the main node into the creation of the > subordinate node typoes. How about using a query string to specify the > parent, like > > node/add/B?mainnode=(nid of A) > > or maybe > > node/add/B/(nid of A) > > Populate the new field in hook_form(). You can even choose to show an input > control for the field if it's not specified B?r -- [ B?r Kessels | Drupal services www.webschuur.com ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20051116/625154a6/attachment.pgp From ber at webschuur.com Wed Nov 16 17:54:59 2005 From: ber at webschuur.com (=?utf-8?q?B=C3=A8r_Kessels?=) Date: Wed Nov 16 17:54:57 2005 Subject: [development] Mark "dangerous" permissions In-Reply-To: References: Message-ID: <200511161855.00154.ber@webschuur.com> Op woensdag 16 november 2005 11:51, schreef Karoly Negyesi: > What about marking with an ugly big red something administer filters and > administer user access? I like it. Though we should si,ply use drupal_set_message for that. "security is most of all, about education" B?r -- [ B?r Kessels | Drupal services www.webschuur.com ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20051116/e101bb8c/attachment.pgp From drupal-devel at istyledthis.nl Wed Nov 16 18:02:57 2005 From: drupal-devel at istyledthis.nl (Stefan) Date: Wed Nov 16 18:03:05 2005 Subject: [development] Mark "dangerous" permissions In-Reply-To: <200511161855.00154.ber@webschuur.com> References: <200511161855.00154.ber@webschuur.com> Message-ID: <43AE78D9-90EE-40DB-A13E-69CE52FAF8C0@istyledthis.nl> Op 16-nov-2005, om 18:54 heeft B?r Kessels het volgende geschreven: > Op woensdag 16 november 2005 11:51, schreef Karoly Negyesi: >> What about marking with an ugly big red something administer >> filters and >> administer user access? > > I like it. Though we should si,ply use drupal_set_message for that. > > "security is most of all, about education" there should be a patch in the patch queue which let module developers document permissions (inside _perm()), and show these notices in the permissions overview.. Unfortunatly I cannot seem to find the correspong threath anymore... Steef --- Stefan Nagtegaal Drupal-Devel@iStyledThis.nl Drupal Development Mailinglist From drumm at delocalizedham.com Wed Nov 16 18:30:11 2005 From: drumm at delocalizedham.com (Neil Drumm) Date: Wed Nov 16 18:44:47 2005 Subject: [development] Mark "dangerous" permissions In-Reply-To: References: Message-ID: <437B7AB3.50401@delocalizedham.com> Karoly Negyesi wrote: > What about marking with an ugly big red something administer filters > and administer user access? I'd like to see the ability for modules to omit checkboxes from the table. For example, remove all 'administer ...' options for anonymous and remove things like 'access private messages' which are meaningless for anonymous. -- Neil Drumm http://delocalizedham.com/ From piotr at mallorn.ii.uj.edu.pl Wed Nov 16 19:34:03 2005 From: piotr at mallorn.ii.uj.edu.pl (Piotr Krukowiecki) Date: Wed Nov 16 19:34:07 2005 Subject: [development] Drupal 4.7.0 update In-Reply-To: <20051115231851.GB13706@mallorn.ii.uj.edu.pl> References: <72FD72C7-7BD9-4BCE-B839-47F1B967B16D@buytaert.net> <20051115231851.GB13706@mallorn.ii.uj.edu.pl> Message-ID: <20051116193403.GA30613@mallorn.ii.uj.edu.pl> On Wed, Nov 16, 2005 at 12:18:51AM +0100, Piotr Krukowiecki wrote: > probably some work. I'm getting some weird warnings with this patch, but > I haven't confirmed if they are related to the patch. I've tested and the notices appear also with not patched, fresh drupal with mysql. So they are not related to my patch. Thus, I'd consider the patch ready to be commited, but I still need people to test it (or at least read the patch? It's not long ;)) http://drupal.org/node/10407#comment-54381 -- Piotrek irc: #debian.pl Mors Drosophilis melanogastribus! From listas at wundo.net Wed Nov 16 21:11:05 2005 From: listas at wundo.net (Fabiano Sant'Ana) Date: Wed Nov 16 21:13:32 2005 Subject: [development] Translations License Message-ID: <437BA069.7080708@wundo.net> Hello, Last week I was looking for a Brazilian Portuguese translation of Drupal, then I get the CVS version. But when I opened the files, almost all of them are Copyrighted. I am a bit afraid about use this files, I think the files should be released in a "open-like" license, am I wrong? Thanks, Fabiano Sant'Ana From gordon at heydon.com.au Wed Nov 16 21:13:54 2005 From: gordon at heydon.com.au (Gordon Heydon) Date: Wed Nov 16 21:13:50 2005 Subject: [development] replace drupal.js with prototype.js? In-Reply-To: <80a220dc0511160855se3a147exd0682b3fb000dc05@mail.gmail.com> References: <005d01c5e999$c452dc80$6400a8c0@family> <1132058082.8154.10.camel@localhost.localdomain> <20051115182013.GB11841@localhost> <80a220dc0511151523u2fbef0e8p99b23023bddb7d60@mail.gmail.com> <20051116111325.e1c65325.ber@webschuur.com> <80a220dc0511160855se3a147exd0682b3fb000dc05@mail.gmail.com> Message-ID: <1132175634.8014.127.camel@localhost.localdomain> Hi, Even though they are compatible, the basic thing is that only GPL'ed software is allowed in drupal. This is not a compatibility issue, but more the philosophy of drupal. Gordon. On Wed, 2005-11-16 at 08:55 -0800, Colin Brumelle wrote: > I believe the two licenses are compatible. > See: > http://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses > > > > On 11/16/05, Ber Kessels wrote: > prototype is not GPL, it is MIT. we only allow GPL. I think > this is a big problem. > > Ber > > On Tue, 15 Nov 2005 15:23:23 -0800 > Colin Brumelle wrote: > > > I've done some work with Prototype, and have found it to be > really well > > thought out. I would love to see Drupal standardise on this > package for > > adding AJAX functionality. Prototypes inclusion in Rails > also offers some > > guarantees that it will be around for a while, developed > further, and > > maintained. > > > > +1 from me... > > > > ------------------- > > Colin Brumelle > > colin@bryght.com > > http://bryght.com > > http://mixedcontent.com > > Cell: 604.351.0547 > > Office: 604.682.2889 > > skype/jabber/aim: cbrumelle > > > > > -- > B?r Kessels Drupal > services > bler.webschuur.com > www.webschuur.com > ber@jabber.webschuur.com > > > > -- > ------------------- > Colin Brumelle > colin@bryght.com > http://bryght.com > http://mixedcontent.com > Cell: 604.351.0547 > Office: 604.682.2889 > skype/jabber/aim: cbrumelle !DSPAM:437b6997218851329013704! From gerhard at killesreiter.de Wed Nov 16 21:16:37 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Wed Nov 16 21:18:31 2005 Subject: [development] Translations License In-Reply-To: <437BA069.7080708@wundo.net> References: <437BA069.7080708@wundo.net> Message-ID: <437BA1B5.2020701@killesreiter.de> Fabiano Sant'Ana wrote: > Hello, > Last week I was looking for a Brazilian Portuguese translation of > Drupal, then I get the CVS version. > > But when I opened the files, almost all of them are Copyrighted. > It may surprise you, but each file of Drupal is copyrighted. > I am a bit afraid about use this files, I think the files should be > released in a "open-like" license, am I wrong? > No, the GPL is included with the downloaded tarballs. Cheers, Gerhard From robert at garrigos.org Wed Nov 16 21:24:08 2005 From: robert at garrigos.org (=?ISO-8859-1?Q?Robert_Garrig=F3s_Castro?=) Date: Wed Nov 16 21:24:19 2005 Subject: [development] new sorting.module Message-ID: <437BA378.8020209@garrigos.org> Hi all, I needed a new type of node sorting for a drupal implementation I'm working on and I wrote a simple sorting.module that does the job. I thought it might be a nice feature to have for the new 4.7 so I uploaded a zip file with the module and a couple of patches here: http://drupal.org/node/37899 I will appreciate any feedback on this in order to evaluate the possibility to have something ready for a 4.7RC. Robert Garrig?s From dopry at thing.net Wed Nov 16 21:35:15 2005 From: dopry at thing.net (Darrel O'Pry) Date: Wed Nov 16 21:35:19 2005 Subject: [development] subversion In-Reply-To: References: <4379C12A.1070805@killesreiter.de> <4BF1D26D-5977-4EB7-9DCD-F1B3EBC54D52@bryght.com> <3C8ED0F5-FF34-4F2F-A0D5-E8E3453C8F5A@civicspacelabs.org> <4379F701.1010003@tejasa.com> <1bc4603e0511151807s7e2f1e86pfc76ccbd199e5d67@mail.gmail.com> <437AA4C0.4050702@walkah.net> <437ADEC1.7040308@handelaar.org> Message-ID: <1132176915.8066.29.camel@localhost.localdomain> Just for fun, how about gits... It works for the linux kernel :) On Wed, 2005-11-16 at 00:55 -0800, puregin wrote: > On 15 Nov 2005, at 11:24 PM, John Handelaar wrote: > > > > > That's like using a different browser for each web site. Although > > I see we're also having _that_ discussion at the moment with respect > > to Mac users. [sigh]. > > > RIght! That's why I use Flock for every website :) > > Thanks for sharing the results of your review, Chris - I found it > interesting and thought provoking. > > Any ideas why subversion is slow? DB implementation? > Transactional model? > > Djun > > From listas at wundo.net Wed Nov 16 21:33:54 2005 From: listas at wundo.net (Fabiano Sant'Ana) Date: Wed Nov 16 21:36:05 2005 Subject: [development] Translations License In-Reply-To: <437BA1B5.2020701@killesreiter.de> References: <437BA069.7080708@wundo.net> <437BA1B5.2020701@killesreiter.de> Message-ID: <437BA5C2.3090102@wundo.net> Gerhard Killesreiter wrote: > It may surprise you, but each file of Drupal is copyrighted. May be I'm just misunderstanding, but look here: http://cvs.drupal.org/viewcvs/drupal/contributions/translations/pt-br/aggregator-module.po?r1=1.3&r2=1.1 I have some doubts, may I change/redistribute this file? What is the license of the 1.3 version? GPL? thanks, fabiano. From weitzman at tejasa.com Wed Nov 16 21:37:57 2005 From: weitzman at tejasa.com (Moshe Weitzman) Date: Wed Nov 16 21:38:01 2005 Subject: [development] new sorting.module In-Reply-To: <437BA378.8020209@garrigos.org> References: <437BA378.8020209@garrigos.org> Message-ID: <437BA6B5.6090103@tejasa.com> Robert Garrig?s Castro wrote: > Hi all, > > I needed a new type of node sorting for a drupal implementation I'm > working on and I wrote a simple sorting.module that does the job. I > thought it might be a nice feature to have for the new 4.7 so I uploaded > a zip file with the module and a couple of patches here: > http://drupal.org/node/37899 > > I will appreciate any feedback on this in order to evaluate the > possibility to have something ready for a 4.7RC. > > Robert Garrig?s Hi Robert. The issue tracker is the place for posting feature requests, bugs, and proposed changes to core. I suggest you use this issue, http://drupal.org/node/5738, or post a new one. Also note the contributed module called weight: http://drupal.org/node/35984. It's approach is slightly different than yours though (I like weight.module approach slightly better). From karoly at negyesi.net Wed Nov 16 21:41:51 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Wed Nov 16 21:38:41 2005 Subject: [development] subversion In-Reply-To: <1132176915.8066.29.camel@localhost.localdomain> References: <4379C12A.1070805@killesreiter.de> <4BF1D26D-5977-4EB7-9DCD-F1B3EBC54D52@bryght.com> <3C8ED0F5-FF34-4F2F-A0D5-E8E3453C8F5A@civicspacelabs.org> <4379F701.1010003@tejasa.com> <1bc4603e0511151807s7e2f1e86pfc76ccbd199e5d67@mail.gmail.com> <437AA4C0.4050702@walkah.net> <437ADEC1.7040308@handelaar.org> <1132176915.8066.29.camel@localhost.localdomain> Message-ID: On Wed, 16 Nov 2005 22:35:15 +0100, Darrel O'Pry wrote: > > Just for fun, how about gits... It works for the linux kernel :) And nothing else. That's for Linux kernel and really nothing else. One workflow in mind, absolutely not a generic thing. From kb at 2bits.com Wed Nov 16 21:41:10 2005 From: kb at 2bits.com (Khalid B) Date: Wed Nov 16 21:41:13 2005 Subject: [development] Translations License In-Reply-To: <437BA5C2.3090102@wundo.net> References: <437BA069.7080708@wundo.net> <437BA1B5.2020701@killesreiter.de> <437BA5C2.3090102@wundo.net> Message-ID: <4a9fdc630511161341i41139279rc165d1ddf75334e2@mail.gmail.com> Fabiano Anything that goes into the Drupal CVS repository has to be GPL. This is a requirement that we have set a long time ago to avoid arguments about licenses. So, whoever put them in must have known that. Also, they can still keep their own copyright on it. The two are not mutually exclusive. On 11/16/05, Fabiano Sant'Ana wrote: > > > Gerhard Killesreiter wrote: > > > It may surprise you, but each file of Drupal is copyrighted. > > May be I'm just misunderstanding, but look here: > http://cvs.drupal.org/viewcvs/drupal/contributions/translations/pt-br/aggregator-module.po?r1=1.3&r2=1.1 > > I have some doubts, may I change/redistribute this file? > What is the license of the 1.3 version? GPL? > > thanks, > fabiano. > > > > From dopry at thing.net Wed Nov 16 21:48:23 2005 From: dopry at thing.net (Darrel O'Pry) Date: Wed Nov 16 21:48:26 2005 Subject: [development] new sorting.module In-Reply-To: <437BA6B5.6090103@tejasa.com> References: <437BA378.8020209@garrigos.org> <437BA6B5.6090103@tejasa.com> Message-ID: <1132177703.8066.36.camel@localhost.localdomain> Instead of patching node.module and taxonomy.module this would probably work better as a part of db_rewrite_sql. It would be nice to pass ordering and grouping data through hook_db_rewrite_sql. On Wed, 2005-11-16 at 16:37 -0500, Moshe Weitzman wrote: From dopry at thing.net Wed Nov 16 21:53:57 2005 From: dopry at thing.net (Darrel O'Pry) Date: Wed Nov 16 21:54:00 2005 Subject: [development] subversion In-Reply-To: References: <4379C12A.1070805@killesreiter.de> <4BF1D26D-5977-4EB7-9DCD-F1B3EBC54D52@bryght.com> <3C8ED0F5-FF34-4F2F-A0D5-E8E3453C8F5A@civicspacelabs.org> <4379F701.1010003@tejasa.com> <1bc4603e0511151807s7e2f1e86pfc76ccbd199e5d67@mail.gmail.com> <437AA4C0.4050702@walkah.net> <437ADEC1.7040308@handelaar.org> <1132176915.8066.29.camel@localhost.localdomain> Message-ID: <1132178037.8066.42.camel@localhost.localdomain> On Wed, 2005-11-16 at 22:41 +0100, Karoly Negyesi wrote: > On Wed, 16 Nov 2005 22:35:15 +0100, Darrel O'Pry wrote: > > > > > Just for fun, how about gits... It works for the linux kernel :) > > And nothing else. That's for Linux kernel and really nothing else. One > workflow in mind, absolutely not a generic thing. Haven't even played with it, just stirring the water... I wouldn't mind seeing svn become the defacto... But I used both svn and cvs (excluding checkouts) for the first time in the last two weeks. They're alot easier to use than I expected. From david.carrington at gmail.com Wed Nov 16 22:12:36 2005 From: david.carrington at gmail.com (David Carrington) Date: Wed Nov 16 22:12:39 2005 Subject: [development] Mark "dangerous" permissions In-Reply-To: <437B7AB3.50401@delocalizedham.com> References: <437B7AB3.50401@delocalizedham.com> Message-ID: <49f3c93a0511161412o5f842c6dp@mail.gmail.com> On 16/11/05, Neil Drumm wrote: > I'd like to see the ability for modules to omit checkboxes from the > table. For example, remove all 'administer ...' options for anonymous I'd disagree on this one, as it is very useful during testing to get people to visit your test site anonymously and play with admin settings. A warning or highlighting should be enough IMO. -- David Carrington From karoly at negyesi.net Wed Nov 16 22:16:56 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Wed Nov 16 22:13:47 2005 Subject: [development] Fwd: bzr usage example In-Reply-To: <20051116204246.GA21982@merconline.com> References: <20051116204246.GA21982@merconline.com> Message-ID: I'll send a lot more text to the list concerning bzr, we had an irc chat on #drupal with James Blackwell after he sent this letter, I will sum that up. Note that for these examples to work you do not need a special apache setup. ------- Forwarded message ------- From: "James Blackwell" To: karoly@negyesi.net Cc: Subject: bzr usage example Date: Wed, 16 Nov 2005 21:42:47 +0100 A lead developer: $ tar xvf mysources.tgz $ cd mysources $ bzr init $ bzr add * $ bzr commit -m"I imported my branch with no history" $ [edit a few files] $ bzr commit -m"I fixed up a variety of typos" $ bzr push sftp://jblack@merconline.com/~/public_html/sources_head A contributor: $ bzr branch http://merconline.com/~jblack/sources_head my_sources $ cd my_sources [wait a few days] $ bzr pull $ [edit a few files] $ bzr commit -m"fixed that buffer overflow holding up release" $ bzr push sftp://someone@somewhere.com/~/public_html/sources_bug-8312 $ echo "Hey! Merge http://somewhere.com/~me/sources_bug-8132" | mutt jblack@merconline.com -s "merge me" A lead: $ cd mysources $ bzr merge http://somewhere.com/~someone/sources_bug-8312 $ bzr diff [ things look good ] $ bzr commit -m "someone fixed sources_bug-8312 $ bzr push sftp://jblack@merconline.com/~/public_html_sources_1.1 The contributor: [decides to work more permanantly] $ bzr branch http://merconline.com/~jblack/sources_head code/source_head echo "12 * * * * * cd ~/code/source_head; bzr pull > /dev/null" \ > /var/spool/cron/someuser $ cd code/source_head $ bzr branch ../source_fix1 $ bzr branch ../source_feature2 $ bzr branch ../allmyfixes $ cd ../source_fix1 [hack hack hack commit] $ cd ../source_fix2 [hack hack hack commit] $ cd ../allmyfixes $ bzr merge # bzr merge defaults to where a branch was branched from $ bzr merge ../source_fix1 $ bzr merge ../source_fix2 The developer can now keep up with mainstream, keep his patches independant, and enjoy the fruits of his own labor. :) From weitzman at tejasa.com Wed Nov 16 22:26:51 2005 From: weitzman at tejasa.com (Moshe Weitzman) Date: Wed Nov 16 22:26:52 2005 Subject: [development] Fwd: bzr usage example In-Reply-To: References: <20051116204246.GA21982@merconline.com> Message-ID: <437BB22B.3090208@tejasa.com> wow, thats some concise documentation! this distributed revision control (DRCS) paradigm looks pretty damn cool. can we dip our toes into the water before trying to change huge workflows like core and contrib repositories? maybe we should use distributed RCS in order to prepare our next "boil the ocean" patch like forms api. -moshe Karoly Negyesi wrote: > I'll send a lot more text to the list concerning bzr, we had an irc > chat on #drupal with James Blackwell after he sent this letter, I will > sum that up. > > Note that for these examples to work you do not need a special apache > setup. > > ------- Forwarded message ------- > From: "James Blackwell" > To: karoly@negyesi.net > Cc: > Subject: bzr usage example > Date: Wed, 16 Nov 2005 21:42:47 +0100 > > > A lead developer: > > $ tar xvf mysources.tgz > $ cd mysources > $ bzr init > $ bzr add * > $ bzr commit -m"I imported my branch with no history" > $ [edit a few files] > $ bzr commit -m"I fixed up a variety of typos" > $ bzr push sftp://jblack@merconline.com/~/public_html/sources_head > > A contributor: > > $ bzr branch http://merconline.com/~jblack/sources_head my_sources > $ cd my_sources > [wait a few days] > $ bzr pull > $ [edit a few files] > $ bzr commit -m"fixed that buffer overflow holding up release" > $ bzr push sftp://someone@somewhere.com/~/public_html/sources_bug-8312 > $ echo "Hey! Merge http://somewhere.com/~me/sources_bug-8132" | mutt > jblack@merconline.com -s "merge me" > > A lead: > > $ cd mysources > $ bzr merge http://somewhere.com/~someone/sources_bug-8312 > $ bzr diff > [ things look good ] > $ bzr commit -m "someone fixed sources_bug-8312 > $ bzr push sftp://jblack@merconline.com/~/public_html_sources_1.1 > > The contributor: > [decides to work more permanantly] > $ bzr branch http://merconline.com/~jblack/sources_head code/source_head > echo "12 * * * * * cd ~/code/source_head; bzr pull > /dev/null" \ > > /var/spool/cron/someuser > $ cd code/source_head > $ bzr branch ../source_fix1 > $ bzr branch ../source_feature2 > $ bzr branch ../allmyfixes > $ cd ../source_fix1 > [hack hack hack commit] > $ cd ../source_fix2 > [hack hack hack commit] > $ cd ../allmyfixes > $ bzr merge # bzr merge defaults to where a branch was branched from > $ bzr merge ../source_fix1 > $ bzr merge ../source_fix2 > > The developer can now keep up with mainstream, keep his patches > independant, and enjoy the fruits of his own labor. :) > > From adrian at bryght.com Wed Nov 16 23:03:02 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Wed Nov 16 23:03:16 2005 Subject: [development] Fwd: bzr usage example In-Reply-To: <437BB22B.3090208@tejasa.com> References: <20051116204246.GA21982@merconline.com> <437BB22B.3090208@tejasa.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17 Nov 2005, at 12:26 AM, Moshe Weitzman wrote: > wow, thats some concise documentation! > > this distributed revision control (DRCS) paradigm looks pretty damn > cool. can we dip our toes into the water before trying to change > huge workflows like core and contrib repositories? maybe we should > use distributed RCS in order to prepare our next "boil the ocean" > patch like forms api. More with boiling the ocean =) - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDe7qogegMqdGlkasRAhN2AKCoj1eZvD2NPbvyodPe27+9vm0K/ACffhsk xCtuVitt1K6rTc+QzzXbZk0= =2sA2 -----END PGP SIGNATURE----- From karoly at negyesi.net Wed Nov 16 23:09:17 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Wed Nov 16 23:06:06 2005 Subject: [development] Fwd: bzr usage example In-Reply-To: <437BB22B.3090208@tejasa.com> References: <20051116204246.GA21982@merconline.com> <437BB22B.3090208@tejasa.com> Message-ID: On Wed, 16 Nov 2005 23:26:51 +0100, Moshe Weitzman wrote: > wow, thats some concise documentation! > > this distributed revision control (DRCS) paradigm looks pretty damn > cool. can we dip our toes into the water before trying to change huge > workflows like core and contrib repositories? maybe we should use > distributed RCS in order to prepare our next "boil the ocean" patch like > forms api. jblack will set up a playground of us. Yes, I think we need to go distributed because we are quickly outgrowing our current model. Sending in a patch is great when one guy is working on a patch, when two, we have a small problem, when a dozen, it does not work. I think I will write a Drupal module that parses bzr logs... From robert at garrigos.org Wed Nov 16 23:10:53 2005 From: robert at garrigos.org (=?ISO-8859-1?Q?Robert_Garrig=F3s_Castro?=) Date: Wed Nov 16 23:11:01 2005 Subject: [development] new sorting.module In-Reply-To: <437BA6B5.6090103@tejasa.com> References: <437BA378.8020209@garrigos.org> <437BA6B5.6090103@tejasa.com> Message-ID: <437BBC7D.4050103@garrigos.org> Thank you, Moshe. I wasn't aware of those issues. I was looking for sorting features, not weighting. In the case of the weight.module (http://drupal.org/node/35984): I like the idea of not having to patch the core, but for what I can see, this weight.module will not sort nodes alphabetically, which is the only reason of sorting.module. In any case this module is not working with 4.6.3 nor with head. As per http://drupal.org/node/5738: this is patching the core a lot, changing database ('sticky' field to 'weight' field) and doesn't sort alphabetically either. Thus, for what I can see, it would be impossible to sort nodes alphabetically without patching the core. Now the question is if you think this is important enough to go on to patching the core. I think it pays off. In that case, which is the best approach? Is my approach something I could carry on? This sorting.module is just working for my site right now but it would need some more work to take it to a release state. That's why I'm asking the core developers if it will pay off to work on this AND if there was something there to work on, that I was missing, which you already answered. Robert G. Moshe Weitzman wrote: > Robert Garrig?s Castro wrote: > >> Hi all, >> >> I needed a new type of node sorting for a drupal implementation I'm >> working on and I wrote a simple sorting.module that does the job. I >> thought it might be a nice feature to have for the new 4.7 so I >> uploaded a zip file with the module and a couple of patches here: >> http://drupal.org/node/37899 >> >> I will appreciate any feedback on this in order to evaluate the >> possibility to have something ready for a 4.7RC. >> >> Robert Garrig?s > > > Hi Robert. The issue tracker is the place for posting feature > requests, bugs, and proposed changes to core. I suggest you use this > issue, http://drupal.org/node/5738, or post a new one. Also note the > contributed module called weight: http://drupal.org/node/35984. It's > approach is slightly different than yours though (I like weight.module > approach slightly better). > > From robert at garrigos.org Wed Nov 16 23:20:40 2005 From: robert at garrigos.org (=?ISO-8859-1?Q?Robert_Garrig=F3s_Castro?=) Date: Wed Nov 16 23:20:47 2005 Subject: [development] new sorting.module In-Reply-To: <1132177703.8066.36.camel@localhost.localdomain> References: <437BA378.8020209@garrigos.org> <437BA6B5.6090103@tejasa.com> <1132177703.8066.36.camel@localhost.localdomain> Message-ID: <437BBEC8.1000108@garrigos.org> Wouldn't this be a major core change? I just wanted to patch the core at minimum. Darrel O'Pry wrote: >Instead of patching node.module and taxonomy.module this would probably >work better as a part of db_rewrite_sql. It would be nice to pass >ordering and grouping data through hook_db_rewrite_sql. > > > > > > >On Wed, 2005-11-16 at 16:37 -0500, Moshe Weitzman wrote: > > > > > From ber at webschuur.com Thu Nov 17 00:57:05 2005 From: ber at webschuur.com (=?utf-8?q?B=C3=A8r_Kessels?=) Date: Thu Nov 17 00:57:11 2005 Subject: [development] Fwd: bzr usage example In-Reply-To: References: <20051116204246.GA21982@merconline.com> Message-ID: <200511170157.05627.ber@webschuur.com> Aaah. that topic... http://lists.drupal.org/archives/development/2005-05/msg00264.html FYI Op woensdag 16 november 2005 23:16, schreef Karoly Negyesi: > I'll send a lot more text to the list concerning bzr, we had an irc chat > on #drupal with James Blackwell after he sent this letter, I will sum that > up. > > Note that for these examples to work you do not need a special apache > setup. > > ------- Forwarded message ------- > From: "James Blackwell" > To: karoly@negyesi.net > Cc: > Subject: bzr usage example > Date: Wed, 16 Nov 2005 21:42:47 +0100 > > > A lead developer: > > $ tar xvf mysources.tgz > $ cd mysources > $ bzr init > $ bzr add * > $ bzr commit -m"I imported my branch with no history" > $ [edit a few files] > $ bzr commit -m"I fixed up a variety of typos" > $ bzr push sftp://jblack@merconline.com/~/public_html/sources_head > > A contributor: > > $ bzr branch http://merconline.com/~jblack/sources_head my_sources > $ cd my_sources > [wait a few days] > $ bzr pull > $ [edit a few files] > $ bzr commit -m"fixed that buffer overflow holding up release" > $ bzr push sftp://someone@somewhere.com/~/public_html/sources_bug-8312 > $ echo "Hey! Merge http://somewhere.com/~me/sources_bug-8132" | mutt > jblack@merconline.com -s "merge me" > > A lead: > > $ cd mysources > $ bzr merge http://somewhere.com/~someone/sources_bug-8312 > $ bzr diff > [ things look good ] > $ bzr commit -m "someone fixed sources_bug-8312 > $ bzr push sftp://jblack@merconline.com/~/public_html_sources_1.1 > > The contributor: > [decides to work more permanantly] > $ bzr branch http://merconline.com/~jblack/sources_head code/source_head > echo "12 * * * * * cd ~/code/source_head; bzr pull > /dev/null" \ > > > /var/spool/cron/someuser > > $ cd code/source_head > $ bzr branch ../source_fix1 > $ bzr branch ../source_feature2 > $ bzr branch ../allmyfixes > $ cd ../source_fix1 > [hack hack hack commit] > $ cd ../source_fix2 > [hack hack hack commit] > $ cd ../allmyfixes > $ bzr merge # bzr merge defaults to where a branch was branched from > $ bzr merge ../source_fix1 > $ bzr merge ../source_fix2 > > The developer can now keep up with mainstream, keep his patches > independant, and enjoy the fruits of his own labor. :) From kb at 2bits.com Thu Nov 17 03:26:11 2005 From: kb at 2bits.com (Khalid B) Date: Thu Nov 17 03:26:13 2005 Subject: [development] Formproc: duplication of effort? Message-ID: <4a9fdc630511161926p6e934d6bkba825ceb51ed0832@mail.gmail.com> Looks to me that this duplicates the form API in 4.7. Formproc project http://drupal.org/node/37543 I sent him an email... From gordon at heydon.com.au Thu Nov 17 04:11:34 2005 From: gordon at heydon.com.au (Gordon Heydon) Date: Thu Nov 17 04:11:48 2005 Subject: [development] Formproc: duplication of effort? In-Reply-To: <4a9fdc630511161926p6e934d6bkba825ceb51ed0832@mail.gmail.com> References: <4a9fdc630511161926p6e934d6bkba825ceb51ed0832@mail.gmail.com> Message-ID: <1132200694.14659.32.camel@localhost.localdomain> Hi, I read through all the screen shots and it all looked very familiar. I think it is a case of great minds thinking a like. I say that because the formapi is stroke of genesis, and not the other end of the scale. Gordon. On Wed, 2005-11-16 at 22:26 -0500, Khalid B wrote: > Looks to me that this duplicates the form API in 4.7. > > Formproc project > http://drupal.org/node/37543 > > I sent him an email... > > !DSPAM:437c019772912003247560! > From gildas.cotomale at gmail.com Thu Nov 17 04:21:15 2005 From: gildas.cotomale at gmail.com (Gildas COTOMALE) Date: Thu Nov 17 04:21:16 2005 Subject: [development] subversion In-Reply-To: <1132178037.8066.42.camel@localhost.localdomain> References: <3C8ED0F5-FF34-4F2F-A0D5-E8E3453C8F5A@civicspacelabs.org> <4379F701.1010003@tejasa.com> <1bc4603e0511151807s7e2f1e86pfc76ccbd199e5d67@mail.gmail.com> <437AA4C0.4050702@walkah.net> <437ADEC1.7040308@handelaar.org> <1132176915.8066.29.camel@localhost.localdomain> <1132178037.8066.42.camel@localhost.localdomain> Message-ID: <99469d070511162021v5f6fcb54q@mail.gmail.com> 2005/11/16, Darrel O'Pry : > > Haven't even played with it, just stirring the water... I wouldn't mind > seeing svn become the defacto... But I used both svn and cvs (excluding > checkouts) for the first time in the last two weeks. They're alot easier > to use than I expected. > http://wiki.gnuarch.org/SubVersionAndCvsComparison http://www.dwheeler.com/essays/scm.html http://better-scm.berlios.de/comparison/ > SVN is still new but is already the winner: It will be the next defacto as it is an enhancement of CVS and keep the major compatibility with it (that's important for easy and safe migration...) That's exactly the way CVS overcome RCS :) > > -- - when i come to cvs, what was great is i could migrate my rcs with ease - don't care, it will be easier to switch to svn From larry at garfieldtech.com Thu Nov 17 05:22:41 2005 From: larry at garfieldtech.com (Larry Garfield) Date: Thu Nov 17 05:22:58 2005 Subject: [development] Mark "dangerous" permissions In-Reply-To: <43AE78D9-90EE-40DB-A13E-69CE52FAF8C0@istyledthis.nl> References: <200511161855.00154.ber@webschuur.com> <43AE78D9-90EE-40DB-A13E-69CE52FAF8C0@istyledthis.nl> Message-ID: <200511162322.41795.larry@garfieldtech.com> On Wednesday 16 November 2005 12:02 pm, Stefan wrote: > Op 16-nov-2005, om 18:54 heeft B?r Kessels het volgende geschreven: > > Op woensdag 16 november 2005 11:51, schreef Karoly Negyesi: > >> What about marking with an ugly big red something administer > >> filters and > >> administer user access? > there should be a patch in the patch queue which let module > developers document permissions (inside _perm()), and show these > notices in the permissions overview.. > Unfortunatly I cannot seem to find the correspong threath anymore... That's actually one I've picked up. :-) http://drupal.org/node/30984 It's been waiting on review from a higher-up who can comment on API changes for a month. At the moment I don't have high hopes for it making 4.7, but it would be nice. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson From larry at garfieldtech.com Thu Nov 17 05:28:41 2005 From: larry at garfieldtech.com (Larry Garfield) Date: Thu Nov 17 05:29:00 2005 Subject: [development] replace drupal.js with prototype.js? In-Reply-To: <1132175634.8014.127.camel@localhost.localdomain> References: <005d01c5e999$c452dc80$6400a8c0@family> <80a220dc0511160855se3a147exd0682b3fb000dc05@mail.gmail.com> <1132175634.8014.127.camel@localhost.localdomain> Message-ID: <200511162328.41732.larry@garfieldtech.com> Um, I really don't want to start a license flame war here, but claiming that we shouldn't use code under a less restrictive license than the GPL even if it's legal because that author didn't choose the Holy GPL goes beyond arrogant to asinine. The Linux kernel uses BSD networking code quite happily, for instance, and not even Stallman has a problem with that. An MIT/BSD/esque library, included into Drupal and distributed with it, is distributed by Drupal under the GPL. It's 100% legal and 100% Free Software compliant. vrms would be perfectly happy with it. :-) I've not used Prototype so I cannot speak to its technical qualities, but from a legal/licensing standpoint there's really no legitimate dispute if it's MIT-esque licensed. On Wednesday 16 November 2005 03:13 pm, Gordon Heydon wrote: > Hi, > > Even though they are compatible, the basic thing is that only GPL'ed > software is allowed in drupal. This is not a compatibility issue, but > more the philosophy of drupal. > > Gordon. > > On Wed, 2005-11-16 at 08:55 -0800, Colin Brumelle wrote: > > I believe the two licenses are compatible. > > See: > > http://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses > > > > > > > > On 11/16/05, Ber Kessels wrote: > > prototype is not GPL, it is MIT. we only allow GPL. I think > > this is a big problem. > > > > Ber > > > > On Tue, 15 Nov 2005 15:23:23 -0800 > > > > Colin Brumelle wrote: > > > I've done some work with Prototype, and have found it to be > > > > really well > > > > > thought out. I would love to see Drupal standardise on this > > > > package for > > > > > adding AJAX functionality. Prototypes inclusion in Rails > > > > also offers some > > > > > guarantees that it will be around for a while, developed > > > > further, and > > > > > maintained. > > > > > > +1 from me... -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson From adrian at bryght.com Thu Nov 17 10:03:31 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Thu Nov 17 10:03:44 2005 Subject: [development] Formproc: duplication of effort? In-Reply-To: <1132200694.14659.32.camel@localhost.localdomain> References: <4a9fdc630511161926p6e934d6bkba825ceb51ed0832@mail.gmail.com> <1132200694.14659.32.camel@localhost.localdomain> Message-ID: <429882B6-932C-4A14-A61F-A70C7702E06C@bryght.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17 Nov 2005, at 6:11 AM, Gordon Heydon wrote: > Hi, > > I read through all the screen shots and it all looked very familiar. > > I think it is a case of great minds thinking a like. I say that > because > the formapi is stroke of genesis, and not the other end of the scale. It does however contain validation functions. Which we can re-use for the current form api. Also, there seems to be database merging things too. This is why it's better if people develop things in the open. (deps) /** * Rule: numeric value. * All characters must be digit, comma, dot, or minus. * * @ingroup formproc_rules * @param string $val * @param string $msg * @return string / function formproc_is_numeric($val, $msg = null) { if (!strlen($val)) { return false; } // accept empty string return preg_match('/^[\d\.,\-]+$/', $val) ? false : $msg !== null ? $msg : t('Must be a number.'); } > > Gordon. > > On Wed, 2005-11-16 at 22:26 -0500, Khalid B wrote: >> Looks to me that this duplicates the form API in 4.7. >> >> Formproc project >> http://drupal.org/node/37543 >> >> I sent him an email... >> >> !DSPAM:437c019772912003247560! >> > - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDfFV0gegMqdGlkasRAm6+AJ9ZgI5QqBTGcmUCk/JVYVhOkjPf1ACg4s+w lUZy+obtR9mmx/LoDKaPE6Y= =2xq0 -----END PGP SIGNATURE----- From occy at occy.net Thu Nov 17 14:20:13 2005 From: occy at occy.net (Trae McCombs) Date: Thu Nov 17 14:19:56 2005 Subject: [development] Help with getting CVS HEAD -> DRUPAL-4-6 [CivicSpace Theme] Message-ID: <1132237213.29228.23.camel@localhost.localdomain> Howdy gang, I'm trying my hardest to get what I have in CVS HEAD tagged as DRUPAL-4-6 so I can begin the 4-7 work on the CivicSpace Theme. I have tried a variety of things, but none have succeeded. I initially thought I could simply do a checkout of HEAD and then do: cvs tag -F DRUPAL-4-6 But it turns out that only works for the directories, not the actual files. Next, when working with James (walkah) on #drupal, he showed me this method to try: cvs co HEAD (of civicspace theme) cvs CO DRUPAL-4-6 (of civicspace theme) Then, on those two directories, do: rsync -azvC CSTHEME-HEAD-DIR/ CSTHEME-DRUPAL-4-6-DIR/ Then, I did a cvs commit . inside of the cstheme 4-6 dir after the rysnc. This still didn't seem to fix the problem. You can compare here: http://cvs.drupal.org/viewcvs/drupal/contributions/themes/civicspace/?only_with_tag=HEAD http://cvs.drupal.org/viewcvs/drupal/contributions/themes/civicspace/?only_with_tag=DRUPAL-4-6 Again, to try and re-state the task I need to do more clearly: I want to tag HEAD of the CSTheme to be DRUPAL-4-6 Thanks in advance, please help! Trae PS. you can find me (and others) in #cstheme on irc.freenode.net if you want to help out with this. -- Trae "occy" McCombs || http://occy.net/ Founder - Themes.org // Linux.com CivicSpaceLabs - http://civicspacelabs.org/ From ber at webschuur.com Thu Nov 17 14:43:02 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Thu Nov 17 14:43:06 2005 Subject: [development] cache_set trouble Message-ID: <200511171543.03106.ber@webschuur.com> Hello, I ma not sure if I stumbled on a critical bug or if I am just reading teh wrong docs. Or if I am just being stupid. I use this: cache_set('gallery_'. $node->nid, $gallery, CACHE_TEMPORARY); To define a cache chnuk for every $gallery object ($gallery is an array with all $image node objects preloaded) But, when I do so everything breaks enomously. I get a fatal error (something with unlocked tables) Any help would be appreciated. And I really hope this is not something broken in core, because we could easily do without new bugs every day. :) -------------------------------------- Warning: sprintf(): Too few arguments in /var/www/staging/includes/database.inc on line 158 Fatal error: Query was empty query: in /var/www/staging/includes/database.mysql.inc on line 99 Fatal error: Table 'sessions' was not locked with LOCK TABLES query: UPDATE sessions SET uid = 2, cache = 0, hostname = '81.11.226.132', session = 'messages|a:0:{}watchdog_overview_filter|s:3:\"all\";', timestamp = 1132238132 WHERE sid = '06ade4989cd77ea1fec28bcb8ac426c6' in /var/www/staging/includes/database.mysql.inc on line 99 Warning: Unknown(): A session is active. You cannot change the session module's ini settings at this time. in Unknown on line 0 -------------------------------------------- B?r -- [ B?r Kessels | Drupal services www.webschuur.com ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20051117/04c57024/attachment.pgp From gerhard at killesreiter.de Thu Nov 17 15:12:08 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Thu Nov 17 15:13:56 2005 Subject: [development] Help with getting CVS HEAD -> DRUPAL-4-6 [CivicSpace Theme] In-Reply-To: <1132237213.29228.23.camel@localhost.localdomain> References: <1132237213.29228.23.camel@localhost.localdomain> Message-ID: <437C9DC8.3050902@killesreiter.de> Trae McCombs wrote: >Howdy gang, > >I'm trying my hardest to get what I have in CVS HEAD tagged as >DRUPAL-4-6 so I can begin the 4-7 work on the CivicSpace Theme. I have >tried a variety of things, but none have succeeded. > >I initially thought I could simply do a checkout of HEAD and then do: >cvs tag -F DRUPAL-4-6 > > Bad idea. According to the FAQ in contrib you should use -b. We use branches or telling 4.6 and HEAD apart, not tags. >But it turns out that only works for the directories, not the actual >files. > >Next, when working with James (walkah) on #drupal, he showed me this >method to try: > >cvs co HEAD (of civicspace theme) >cvs CO DRUPAL-4-6 (of civicspace theme) > >Then, on those two directories, do: >rsync -azvC CSTHEME-HEAD-DIR/ CSTHEME-DRUPAL-4-6-DIR/ > >Then, I did a cvs commit . inside of the cstheme 4-6 dir after the >rysnc. > >This still didn't seem to fix the problem. You can compare here: >http://cvs.drupal.org/viewcvs/drupal/contributions/themes/civicspace/?only_with_tag=HEAD >http://cvs.drupal.org/viewcvs/drupal/contributions/themes/civicspace/?only_with_tag=DRUPAL-4-6 > >Again, to try and re-state the task I need to do more clearly: > >I want to tag HEAD of the CSTheme to be DRUPAL-4-6 > > I've fixed this by removing the tags and adding a branch as appropriate. The approprate way to work in Drupal contrib cvs is as follows: You start a project by adding it to HEAD. When you think it is ok to release it for the current version, you _branch_ not _tag_. See the FAW for the command. If you need to make changes to the released version, you get a checkout of that branch, make changes and commit _on_ _that_ _branch_. This works for me since I got a cvs account and I never got any mess in my directories. Cheers, Gerhard From occy at occy.net Thu Nov 17 15:53:32 2005 From: occy at occy.net (Trae McCombs) Date: Thu Nov 17 15:53:16 2005 Subject: [development] Help with getting CVS HEAD -> DRUPAL-4-6 [CivicSpace Theme] In-Reply-To: <437C9DC8.3050902@killesreiter.de> References: <1132237213.29228.23.camel@localhost.localdomain> <437C9DC8.3050902@killesreiter.de> Message-ID: <1132242812.29228.32.camel@localhost.localdomain> Thanks Gerhard, You helped me on IRC and I think I understand things more clearly now. Trae On Thu, 2005-11-17 at 16:12 +0100, Gerhard Killesreiter wrote: > Trae McCombs wrote: > > >Howdy gang, > > > >I'm trying my hardest to get what I have in CVS HEAD tagged as > >DRUPAL-4-6 so I can begin the 4-7 work on the CivicSpace Theme. I have > >tried a variety of things, but none have succeeded. > > > >I initially thought I could simply do a checkout of HEAD and then do: > >cvs tag -F DRUPAL-4-6 > > > > > > Bad idea. According to the FAQ in contrib you should use -b. > We use branches or telling 4.6 and HEAD apart, not tags. > > > >But it turns out that only works for the directories, not the actual > >files. > > > >Next, when working with James (walkah) on #drupal, he showed me this > >method to try: > > > >cvs co HEAD (of civicspace theme) > >cvs CO DRUPAL-4-6 (of civicspace theme) > > > >Then, on those two directories, do: > >rsync -azvC CSTHEME-HEAD-DIR/ CSTHEME-DRUPAL-4-6-DIR/ > > > >Then, I did a cvs commit . inside of the cstheme 4-6 dir after the > >rysnc. > > > >This still didn't seem to fix the problem. You can compare here: > >http://cvs.drupal.org/viewcvs/drupal/contributions/themes/civicspace/?only_with_tag=HEAD > >http://cvs.drupal.org/viewcvs/drupal/contributions/themes/civicspace/?only_with_tag=DRUPAL-4-6 > > > >Again, to try and re-state the task I need to do more clearly: > > > >I want to tag HEAD of the CSTheme to be DRUPAL-4-6 > > > > > > I've fixed this by removing the tags and adding a branch as appropriate. > > The approprate way to work in Drupal contrib cvs is as follows: > > You start a project by adding it to HEAD. > > When you think it is ok to release it for the current version, you > _branch_ not _tag_. > See the FAW for the command. > > If you need to make changes to the released version, you get a checkout > of that branch, make changes and commit _on_ _that_ _branch_. > > This works for me since I got a cvs account and I never got any mess in > my directories. > > Cheers, > Gerhard -- Trae "occy" McCombs || http://occy.net/ Founder - Themes.org // Linux.com CivicSpaceLabs - http://civicspacelabs.org/ From herman.webley at gmail.com Thu Nov 17 16:01:50 2005 From: herman.webley at gmail.com (Herman Webley) Date: Thu Nov 17 16:01:54 2005 Subject: [development] replace drupal.js with prototype.js? In-Reply-To: <200511162328.41732.larry@garfieldtech.com> References: <005d01c5e999$c452dc80$6400a8c0@family> <80a220dc0511160855se3a147exd0682b3fb000dc05@mail.gmail.com> <1132175634.8014.127.camel@localhost.localdomain> <200511162328.41732.larry@garfieldtech.com> Message-ID: I don't think choosing to allow on GPL code in the Drupal project is any more arrogant or assine than choosing to select the GPL for the code we write. (I don't think of either as being arrogant or assine) More important might be the current CVS rule of no 3rd party software. GPL or not prototype would have to be downloaded from its upstream source. This obviously cannot work for a core javascript file. (The difference between prototype.js/drupal.js and the xmlrpc library is that the xmlrpc library was just used as a base (and as such our fork of the library isn't hosted anywhere else) while prototype would ideally follow the upstream source which would be the definitive source). On 11/16/05, Larry Garfield wrote: > Um, I really don't want to start a license flame war here, but claiming that > we shouldn't use code under a less restrictive license than the GPL even if > it's legal because that author didn't choose the Holy GPL goes beyond > arrogant to asinine. The Linux kernel uses BSD networking code quite > happily, for instance, and not even Stallman has a problem with that. > > An MIT/BSD/esque library, included into Drupal and distributed with it, is > distributed by Drupal under the GPL. It's 100% legal and 100% Free Software > compliant. vrms would be perfectly happy with it. :-) > > I've not used Prototype so I cannot speak to its technical qualities, but from > a legal/licensing standpoint there's really no legitimate dispute if it's > MIT-esque licensed. > > On Wednesday 16 November 2005 03:13 pm, Gordon Heydon wrote: > > Hi, > > > > Even though they are compatible, the basic thing is that only GPL'ed > > software is allowed in drupal. This is not a compatibility issue, but > > more the philosophy of drupal. > > > > Gordon. > > > > On Wed, 2005-11-16 at 08:55 -0800, Colin Brumelle wrote: > > > I believe the two licenses are compatible. > > > See: > > > http://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses > > > > > > > > > > > > On 11/16/05, Ber Kessels wrote: > > > prototype is not GPL, it is MIT. we only allow GPL. I think > > > this is a big problem. > > > > > > Ber > > > > > > On Tue, 15 Nov 2005 15:23:23 -0800 > > > > > > Colin Brumelle wrote: > > > > I've done some work with Prototype, and have found it to be > > > > > > really well > > > > > > > thought out. I would love to see Drupal standardise on this > > > > > > package for > > > > > > > adding AJAX functionality. Prototypes inclusion in Rails > > > > > > also offers some > > > > > > > guarantees that it will be around for a while, developed > > > > > > further, and > > > > > > > maintained. > > > > > > > > +1 from me... > > -- > Larry Garfield AIM: LOLG42 > larry@garfieldtech.com ICQ: 6817012 > > "If nature has made any one thing less susceptible than all others of > exclusive property, it is the action of the thinking power called an idea, > which an individual may exclusively possess as long as he keeps it to > himself; but the moment it is divulged, it forces itself into the possession > of every one, and the receiver cannot dispossess himself of it." -- Thomas > Jefferson > -- Best regards, Herman Webley From ber at webschuur.com Thu Nov 17 16:03:27 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Thu Nov 17 16:03:38 2005 Subject: [development] Help with getting CVS HEAD -> DRUPAL-4-6 [CivicSpace Theme] In-Reply-To: <437C9DC8.3050902@killesreiter.de> References: <1132237213.29228.23.camel@localhost.localdomain> <437C9DC8.3050902@killesreiter.de> Message-ID: <200511171703.38815.ber@webschuur.com> Op donderdag 17 november 2005 16:12, schreef Gerhard Killesreiter: > Bad idea. According to the FAQ in contrib you should use -b. > We use branches or telling 4.6 and HEAD apart, not tags. Then some CVS guru must fix: http://drupal.org/node/17570 In gebneral I think we should get rid of the distributed docs. Get rid of the textfiles in CVS. If we have uptodate stuff online, that is searchable, bookmarkable, etc, then who reads them in CVS anyway? I vote for removing all textfile docs, except the licence statement from CVS repositories. B?r -- [ B?r Kessels | Drupal services www.webschuur.com ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20051117/db3b52de/attachment.pgp From karoly at negyesi.net Thu Nov 17 18:35:11 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Thu Nov 17 18:31:52 2005 Subject: [development] replace drupal.js with prototype.js? In-Reply-To: References: <005d01c5e999$c452dc80$6400a8c0@family> <80a220dc0511160855se3a147exd0682b3fb000dc05@mail.gmail.com> <1132175634.8014.127.camel@localhost.localdomain> <200511162328.41732.larry@garfieldtech.com> Message-ID: > (The difference between prototype.js/drupal.js and the xmlrpc library > is that the xmlrpc library was just used as a base (and as such our > fork of the library isn't hosted anywhere else) No. The difference is that I asked Simon Willison (the original author) and he GPL'd the Drupal fork. Thanks Simon if you are ever reading this. Regards NK From herman.webley at gmail.com Thu Nov 17 18:49:42 2005 From: herman.webley at gmail.com (Herman Webley) Date: Thu Nov 17 18:50:11 2005 Subject: [development] replace drupal.js with prototype.js? In-Reply-To: References: <005d01c5e999$c452dc80$6400a8c0@family> <80a220dc0511160855se3a147exd0682b3fb000dc05@mail.gmail.com> <1132175634.8014.127.camel@localhost.localdomain> <200511162328.41732.larry@garfieldtech.com> Message-ID: On 11/17/05, Karoly Negyesi wrote: > > (The difference between prototype.js/drupal.js and the xmlrpc library > > is that the xmlrpc library was just used as a base (and as such our > > fork of the library isn't hosted anywhere else) > > No. The difference is that I asked Simon Willison (the original author) > and he GPL'd the Drupal fork. Thanks Simon if you are ever reading this. > > Regards > > NK > /me stands corrected -- Best regards, Herman Webley From boris at bryght.com Thu Nov 17 18:55:35 2005 From: boris at bryght.com (Boris Mann) Date: Thu Nov 17 18:55:43 2005 Subject: [development] replace drupal.js with prototype.js? In-Reply-To: References: <005d01c5e999$c452dc80$6400a8c0@family> <80a220dc0511160855se3a147exd0682b3fb000dc05@mail.gmail.com> <1132175634.8014.127.camel@localhost.localdomain> <200511162328.41732.larry@garfieldtech.com> Message-ID: <7A97FD97-75D1-44E6-99DB-9D0DA34B7506@bryght.com> On 17-Nov-05, at 10:35 AM, Karoly Negyesi wrote: >> (The difference between prototype.js/drupal.js and the xmlrpc library >> is that the xmlrpc library was just used as a base (and as such our >> fork of the library isn't hosted anywhere else) > > No. The difference is that I asked Simon Willison (the original > author) and he GPL'd the Drupal fork. Thanks Simon if you are ever > reading this. Great...luckily the MIT license is less restrictive than the GPL, so we could in fact GPL license "our" local copy. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com From gabor at hojtsy.hu Thu Nov 17 22:09:28 2005 From: gabor at hojtsy.hu (Gabor Hojtsy) Date: Thu Nov 17 22:09:32 2005 Subject: [development] How big is contrib? In-Reply-To: <006201c5eac4$40c09660$b400a8c0@Nikko> References: <99197af20511160350x7b727f23u37e2db5e92cd5347@mail.gmail.com> <20051116115622.GA23016@mallorn.ii.uj.edu.pl> <006201c5eac4$40c09660$b400a8c0@Nikko> Message-ID: <437CFF98.8030400@hojtsy.hu> >>Bear in mind that cvs can transfer files compressed (-z 9 switch), so the > bw >>needed is much smaller. > > Thanks for the -z 9 switch I always wondered why isn't this the default, but this is offtopic here :) Goba From gordon at heydon.com.au Thu Nov 17 23:48:18 2005 From: gordon at heydon.com.au (Gordon Heydon) Date: Thu Nov 17 23:48:25 2005 Subject: [development] SCM tools Message-ID: <1132271299.8272.36.camel@localhost.localdomain> Hi, With all this talk about different scm's. I have been using darcs (darcs.net) and I use it for a number of projects. Basically darcs is a distributed similar to bzr or git. I find that it works well, and has a number of features that I like, such as patch picking (means you can select which patches you take) and when you are recording a change set you can pick what changes are going to be included into the patch. Using tailor I have gone one step further and I have set up a darcs drupal repository which people can download from. To get the cvs version of drupal you can execute the following command. darcs get --partial http://repos.heydon.com.au/drupal this will get the latest version of the drupal repository. I have set it up so this repository will be synced with the drupal cvs repository every 6 hours. To update you local repository you just do the following in the drupal directory darcs pull -a and it will download all the new patches that have been applied. When you have made changes to your copy of drupal you can then do a darcs whatsnew and it will show you all the changes, and to record these use the following darcs record and you can then choose which changes will be included in the patch. I also have the web frontend going which can be gotten to at the following. http://repos.heydon.com.au/darcsweb/darcsweb.cgi?r=drupal;a=summary which is a little ugly at the moment as tailor doesn't really look that nice. There is also some problem ATM with the web frontend, but I think this is because of the version of python or something that dreamhost has done to python. Let me know what you think. Gordon. From gordon at heydon.com.au Fri Nov 18 02:38:32 2005 From: gordon at heydon.com.au (Gordon Heydon) Date: Fri Nov 18 02:38:39 2005 Subject: [development] SCM tools In-Reply-To: <1132271299.8272.36.camel@localhost.localdomain> References: <1132271299.8272.36.camel@localhost.localdomain> Message-ID: <1132281512.8272.64.camel@localhost.localdomain> Hi, One other things that I feel is important which darcs and other distributed scm tools do is that the author of the patch gets directly credited, even if they do not have write access to the main repository. So instead of Dries says patch x by y they will be credited directly. Gordon. On Fri, 2005-11-18 at 10:48 +1100, Gordon Heydon wrote: > Hi, > > With all this talk about different scm's. I have been using darcs > (darcs.net) and I use it for a number of projects. > > Basically darcs is a distributed similar to bzr or git. I find that it > works well, and has a number of features that I like, such as patch > picking (means you can select which patches you take) and when you are > recording a change set you can pick what changes are going to be > included into the patch. > > Using tailor I have gone one step further and I have set up a darcs > drupal repository which people can download from. To get the cvs version > of drupal you can execute the following command. > > darcs get --partial http://repos.heydon.com.au/drupal > > this will get the latest version of the drupal repository. > > I have set it up so this repository will be synced with the drupal cvs > repository every 6 hours. > > To update you local repository you just do the following in the drupal > directory > > darcs pull -a > > and it will download all the new patches that have been applied. > > When you have made changes to your copy of drupal you can then do a > > darcs whatsnew > > and it will show you all the changes, and to record these use the > following > > darcs record > > and you can then choose which changes will be included in the patch. > > I also have the web frontend going which can be gotten to at the > following. > > http://repos.heydon.com.au/darcsweb/darcsweb.cgi?r=drupal;a=summary > > which is a little ugly at the moment as tailor doesn't really look that > nice. There is also some problem ATM with the web frontend, but I think > this is because of the version of python or something that dreamhost has > done to python. > > Let me know what you think. > Gordon. > > > > !DSPAM:437d2078323347020818619! > From gildas.cotomale at gmail.com Fri Nov 18 05:49:30 2005 From: gildas.cotomale at gmail.com (Gildas COTOMALE) Date: Fri Nov 18 05:49:32 2005 Subject: [development] Help with getting CVS HEAD -> DRUPAL-4-6 [CivicSpace Theme] In-Reply-To: <200511171703.38815.ber@webschuur.com> References: <1132237213.29228.23.camel@localhost.localdomain> <437C9DC8.3050902@killesreiter.de> <200511171703.38815.ber@webschuur.com> Message-ID: <99469d070511172149v4bd293dbh@mail.gmail.com> 2005/11/17, B?r Kessels : > In gebneral I think we should get rid of the distributed docs. Get rid of the > textfiles in CVS. If we have uptodate stuff online, that is searchable, > bookmarkable, etc, then who reads them in CVS anyway? > Not a great idea. It's always good to have README.txt, INSTALL.txt, UPGRADE.txt and so with a module or a Drupal core. Keeping them in CVS allow updating'em... In another hand, don't forget that every body is not always connected to the net.. This apply to the translations to... > I vote for removing all textfile docs, except the licence statement from CVS > repositories. > I vote against :) > B?r > -- > [ B?r Kessels | Drupal services www.webschuur.com ] > > > -- vi is a real WYSIWYG editor: you see text, you get text. From ber at webschuur.com Fri Nov 18 08:58:35 2005 From: ber at webschuur.com (=?utf-8?q?B=C3=A8r_Kessels?=) Date: Fri Nov 18 08:58:33 2005 Subject: [development] SCM tools In-Reply-To: <1132271299.8272.36.camel@localhost.localdomain> References: <1132271299.8272.36.camel@localhost.localdomain> Message-ID: <200511180958.36158.ber@webschuur.com> Gordon, I love Darcs, unfortunately had no chance to test it in a larger developer environment yet. But in any case: darcs was designed exactly* for developer communities and workflows like Drupal has. Not like svn that noly fixes the mayor annoyences of an ancient RCS. Darcs has no frontends, but who cares :) zwe dont even ship with an install frontend, so should we care about developer frontends? Thank you, Gordon for getting this going! Ber Op vrijdag 18 november 2005 00:48, schreef Gordon Heydon: > Hi, > > With all this talk about different scm's. I have been using darcs > (darcs.net) and I use it for a number of projects. > > Basically darcs is a distributed similar to bzr or git. I find that it > works well, and has a number of features that I like, such as patch > picking (means you can select which patches you take) and when you are > recording a change set you can pick what changes are going to be > included into the patch. > > Using tailor I have gone one step further and I have set up a darcs > drupal repository which people can download from. To get the cvs version > of drupal you can execute the following command. > > darcs get --partial http://repos.heydon.com.au/drupal > > this will get the latest version of the drupal repository. > > I have set it up so this repository will be synced with the drupal cvs > repository every 6 hours. > > To update you local repository you just do the following in the drupal > directory > > darcs pull -a > > and it will download all the new patches that have been applied. > > When you have made changes to your copy of drupal you can then do a > > darcs whatsnew > > and it will show you all the changes, and to record these use the > following > > darcs record > > and you can then choose which changes will be included in the patch. > > I also have the web frontend going which can be gotten to at the > following. > > http://repos.heydon.com.au/darcsweb/darcsweb.cgi?r=drupal;a=summary > > which is a little ugly at the moment as tailor doesn't really look that > nice. There is also some problem ATM with the web frontend, but I think > this is because of the version of python or something that dreamhost has > done to python. > > Let me know what you think. > Gordon. B?r -- [ B?r Kessels | Drupal services www.webschuur.com ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20051118/2de33153/attachment.pgp From kb at 2bits.com Fri Nov 18 14:30:15 2005 From: kb at 2bits.com (Khalid B) Date: Fri Nov 18 14:30:17 2005 Subject: [development] SCM tools In-Reply-To: <200511180958.36158.ber@webschuur.com> References: <1132271299.8272.36.camel@localhost.localdomain> <200511180958.36158.ber@webschuur.com> Message-ID: <4a9fdc630511180630v2a2f9295n88a30654bad4d870@mail.gmail.com> Ber You mean it has no GUI? I guess that is not a major setback. The people used to Tortoise CVS, WinCVS or Eclipse will see that now they have to write commands and options though ... Maybe it is worth a poll (what repository software do you use for drupal development?) > But in any case: darcs was designed exactly for developer communities and > workflows like Drupal has. Not like svn that noly fixes the mayor annoyences > of an ancient RCS. Darcs has no frontends, but who cares :) zwe dont even > ship with an install frontend, so should we care about developer frontends? From dries.buytaert at gmail.com Fri Nov 18 14:55:45 2005 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Fri Nov 18 14:55:49 2005 Subject: [development] SCM tools In-Reply-To: <4a9fdc630511180630v2a2f9295n88a30654bad4d870@mail.gmail.com> References: <1132271299.8272.36.camel@localhost.localdomain> <200511180958.36158.ber@webschuur.com> <4a9fdc630511180630v2a2f9295n88a30654bad4d870@mail.gmail.com> Message-ID: > Maybe it is worth a poll (what repository software do you use for > drupal development?) Let's not launch polls for the sake of launching polls. I'm not convinced it is useful to open up this discussion to the Drupal community at large. -- Dries Buytaert :: http://www.buytaert.net/ From kb at 2bits.com Fri Nov 18 15:05:33 2005 From: kb at 2bits.com (Khalid B) Date: Fri Nov 18 15:05:35 2005 Subject: [development] SCM tools In-Reply-To: References: <1132271299.8272.36.camel@localhost.localdomain> <200511180958.36158.ber@webschuur.com> <4a9fdc630511180630v2a2f9295n88a30654bad4d870@mail.gmail.com> Message-ID: <4a9fdc630511180705ld666333t21dc3eda6e10eb50@mail.gmail.com> On 11/18/05, Dries Buytaert wrote: > > Maybe it is worth a poll (what repository software do you use for > > drupal development?) > > Let's not launch polls for the sake of launching polls. I'm not > convinced it is useful to open up this discussion to the Drupal > community at large. Agreed. Perhaps within the development list only? From allie at pajunas.com Fri Nov 18 15:29:15 2005 From: allie at pajunas.com (Allie Micka) Date: Fri Nov 18 15:29:21 2005 Subject: [development] Encouraging Collaboration Message-ID: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> The 4.7 / Forms API upgrade is going to create a learning curve for many module developers, and some of the less-active module owners may not have the time and inclination to make the switch. That could be good news. A lot of these efforts are "learning experiences" that are not being maintained at all. Some of the authors can't be reached, and if you're too polite to overwrite those modules you start new. Some developers feel that it's more rewarding to have their name in lights than to collaborate on a module that's more useful and stable overall. Some people just don't play well with others. As an alternative to upgrading, some module developers could look at modules with similar functionality and try to help upgrade and enhance those. Do we really need 3 Amazon modules? 6 "mail this thing" modules? (one of these is my fault) Can the Flikr Block module be part of the Flikr Module? The list is endless. This is a big problem for new Drupal users and old timers alike. It's not clear which modules are being maintained and how well they work. A few months ago, I tried all the Amazon modules and discovered that each gave me about 60% of a solution. I finally just dropped the idea if using Amazon at all. I'm sure this sort of thing happens a lot, and we never even hear about it. I'm not saying that any of these modules deserves to die, or that they can't possibly be bringing anything new to the table, but I would offer these suggestions: - As part of the call for upgrades 4.7, recommend that module developers try to combine efforts - Encourage people to maintain TODO lists for modules so that others can understand overall goals and see if added functionality would be useful - Encourage people to archive and retire their abandoned projects from CVS. Allie Micka pajunas interactive, inc. http://www.pajunas.com scalable web hosting and open source strategies From prometheus6 at gmail.com Fri Nov 18 15:46:29 2005 From: prometheus6 at gmail.com (Earl Dunovant) Date: Fri Nov 18 15:46:31 2005 Subject: [development] Encouraging Collaboration In-Reply-To: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> References: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> Message-ID: For the record, there will only be two Amazon modules in 4.7...I have Amazon associate tools and Amazon search...the search will be folded entirely into AAT. And back when I first released it, Ber suggested I combine efforts with the author of the othe one. We agreed, but I got zero input so I just wrote what I needed for myself. I think I'm seen as one who doesn't play well with others...I've noticed my comments only get responses when someone thinks they can correct me. You got gatekeepers here like in any other group, and I'm finally going to mention something that annoyed me. Before becoming familiar with the cultural aspects of this group AAT shipped with my associate code as the default. I figured anyone that used it would change it. Lot of objections...we don't want people to think we're hustling them. So fine, i change it...as I said, I didn't feel it would have a significant impact one way or the other. The comment said i changed it because community sentiment ran against it. I got an email complaining that I said it was "mere sentiment." My response was, relax...your project, so your sentiment is enough reason to change it. I'm not the one to whine in a public forum. I offer help when I think I can be of help, I return code to the project that I benefit from. I am offered little beyond the code base. That's just the way it is, I guess. But since the topic came up... On 11/18/05, Allie Micka wrote: > > The 4.7 / Forms API upgrade is going to create a learning curve for > many module developers, and some of the less-active module owners may > not have the time and inclination to make the switch. That could be > good news. > > A lot of these efforts are "learning experiences" that are not being > maintained at all. Some of the authors can't be reached, and if > you're too polite to overwrite those modules you start new. Some > developers feel that it's more rewarding to have their name in lights > than to collaborate on a module that's more useful and stable > overall. Some people just don't play well with others. > > As an alternative to upgrading, some module developers could look at > modules with similar functionality and try to help upgrade and > enhance those. Do we really need 3 Amazon modules? 6 "mail this > thing" modules? (one of these is my fault) Can the Flikr Block > module be part of the Flikr Module? The list is endless. > > This is a big problem for new Drupal users and old timers alike. > It's not clear which modules are being maintained and how well they > work. A few months ago, I tried all the Amazon modules and > discovered that each gave me about 60% of a solution. I finally just > dropped the idea if using Amazon at all. I'm sure this sort of thing > happens a lot, and we never even hear about it. > > I'm not saying that any of these modules deserves to die, or that > they can't possibly be bringing anything new to the table, but I > would offer these suggestions: > > - As part of the call for upgrades 4.7, recommend that module > developers try to combine efforts > - Encourage people to maintain TODO lists for modules so that > others can understand overall goals and see if added functionality > would be useful > - Encourage people to archive and retire their abandoned projects > from CVS. > > > Allie Micka > pajunas interactive, inc. > http://www.pajunas.com > > scalable web hosting and open source strategies > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051118/c7541059/attachment.htm From ber at webschuur.com Fri Nov 18 16:41:19 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Fri Nov 18 16:41:26 2005 Subject: [development] Encouraging Collaboration In-Reply-To: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> References: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> Message-ID: <200511181741.22196.ber@webschuur.com> Hi Please update http://drupal.org/node/23789 a little, you explain it so much better, then I do. Also, we could choose to make that page more prominent. All in all, i totally agree that this is a big problem, but I don't know a solution. You are right to state, that this /is/ a problem. But an example of where this collaboration worked well, was links [1]: Anyone doing anything with weblinks should really check that project. There are APIs tables, modules, hooks, and what more for your weblinks in there. But also; I think anyone needs to monitor the projects [2] and contact the author if someone checks in a project that does what your project has done for years already. Oh, and last, I think we could set up a smal team on drupal.org and get approx 20 people who can "unpublish" projects. This needs no code, just some guidelines. Unpublishing projects can be done after sommunication with an author and after a project was found unfit for drupal.org. B?r Op vrijdag 18 november 2005 16:29, schreef Allie Micka: > The 4.7 / Forms API upgrade is going to create a learning curve for > many module developers, and some of the less-active module owners may > not have the time and inclination to make the switch. That could be > good news. > > A lot of these efforts are "learning experiences" that are not being > maintained at all. Some of the authors can't be reached, and if > you're too polite to overwrite those modules you start new. Some > developers feel that it's more rewarding to have their name in lights > than to collaborate on a module that's more useful and stable > overall. Some people just don't play well with others. > > As an alternative to upgrading, some module developers could look at > modules with similar functionality and try to help upgrade and > enhance those. Do we really need 3 Amazon modules? 6 "mail this > thing" modules? (one of these is my fault) Can the Flikr Block > module be part of the Flikr Module? The list is endless. > > This is a big problem for new Drupal users and old timers alike. > It's not clear which modules are being maintained and how well they > work. A few months ago, I tried all the Amazon modules and > discovered that each gave me about 60% of a solution. I finally just > dropped the idea if using Amazon at all. I'm sure this sort of thing > happens a lot, and we never even hear about it. > > I'm not saying that any of these modules deserves to die, or that > they can't possibly be bringing anything new to the table, but I > would offer these suggestions: > > - As part of the call for upgrades 4.7, recommend that module > developers try to combine efforts > - Encourage people to maintain TODO lists for modules so that > others can understand overall goals and see if added functionality > would be useful > - Encourage people to archive and retire their abandoned projects > from CVS. > > > Allie Micka > pajunas interactive, inc. > http://www.pajunas.com > > scalable web hosting and open source strategies B?r -- | B?r Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20051118/cec406ff/attachment.pgp From dan at civicactions.com Fri Nov 18 16:43:22 2005 From: dan at civicactions.com (Dan Robinson) Date: Fri Nov 18 16:43:44 2005 Subject: [development] Encouraging Collaboration In-Reply-To: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> References: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> Message-ID: <437E04AA.7000406@civicactions.com> One of the biggest selling points of Drupal (IMHO) is the sheer number of contributed modules (and developers behind them). One of the biggest drawbacks is the amount of stuff that doesn't work right. It seems that there are a number of forces at play here - 1) What is out there? While I love going through the list of contributed modules there is so much out there that I have no idea where to start sometimes. 2) Core vs. Contrib - This pattern seems to be mainly about general vs. specific - but it is also about quality vs. quantity. It seems that quality vs. quantity needs more attention. 3) Who is this product for? Drupal is a very mature product - but it seems like it hasn't grown up yet :) - which is kinda cool - and kinda infuriating. I think that there needs to be a better definition of who this product is for - is it for the people who spend most of their time developing/contributing to it? Is it for web developers? Is it for webmasters? Is it for end-users? At the end of the day we all sit somewhere in a very long chain which starts with dreamers and ends with a person at the end of a wire plunking at their keyboard. 4) How do things get done around here? The only sure way to do anything is to do it yourself - which is fine - but it limits participation (see 3 above). There are a bunch of different possible solutions to any given problem (like the one pointed out in Allie's email). However without a roadmap it is difficult to know which way to go. Here are some specific things that might work to solve this problem - 1) Right now there are three module categories -> core, modules, sandbox. Perhaps there should be another? "community modules" - being stuff that the "community" endorses? Perhaps by a straight up or down vote of contributors? I know this is radical. 2) There could be a "reviews" blog attached directly to each module - I'm sure this is an old discussion - sorry for bringing it up again. I would love to see Allie's notes from her investigation of the "Amazon" modules so I knew what was in and not in each module. IMHO Drupal is going through some growing pains - Dries pointed this out in Amsterdam when he talked about the phenominal growth of the community. There is a lot of work to be done. Here's one last idea - perhaps what is needed is a community manager? Someone who is committed to full-time work on Drupal and is directed by a clearly agreed upon set of deliverables. We would chip $$ in to pay for this as an experiment - and honestly I think that in a community this size it would be trivial to raise $$ to do this. Of course this entire email is worth less than silver :). Dan > The 4.7 / Forms API upgrade is going to create a learning curve for > many module developers, and some of the less-active module owners may > not have the time and inclination to make the switch. That could be > good news. > > A lot of these efforts are "learning experiences" that are not being > maintained at all. Some of the authors can't be reached, and if > you're too polite to overwrite those modules you start new. Some > developers feel that it's more rewarding to have their name in lights > than to collaborate on a module that's more useful and stable > overall. Some people just don't play well with others. > > As an alternative to upgrading, some module developers could look at > modules with similar functionality and try to help upgrade and > enhance those. Do we really need 3 Amazon modules? 6 "mail this > thing" modules? (one of these is my fault) Can the Flikr Block > module be part of the Flikr Module? The list is endless. > > This is a big problem for new Drupal users and old timers alike. > It's not clear which modules are being maintained and how well they > work. A few months ago, I tried all the Amazon modules and > discovered that each gave me about 60% of a solution. I finally just > dropped the idea if using Amazon at all. I'm sure this sort of thing > happens a lot, and we never even hear about it. > > I'm not saying that any of these modules deserves to die, or that > they can't possibly be bringing anything new to the table, but I > would offer these suggestions: > > - As part of the call for upgrades 4.7, recommend that module > developers try to combine efforts > - Encourage people to maintain TODO lists for modules so that > others can understand overall goals and see if added functionality > would be useful > - Encourage people to archive and retire their abandoned projects > from CVS. > > > Allie Micka > pajunas interactive, inc. > http://www.pajunas.com > > scalable web hosting and open source strategies > > > From dan at civicactions.com Fri Nov 18 16:43:22 2005 From: dan at civicactions.com (Dan Robinson) Date: Fri Nov 18 16:43:45 2005 Subject: [development] Encouraging Collaboration In-Reply-To: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> References: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> Message-ID: <437E04AA.7000406@civicactions.com> One of the biggest selling points of Drupal (IMHO) is the sheer number of contributed modules (and developers behind them). One of the biggest drawbacks is the amount of stuff that doesn't work right. It seems that there are a number of forces at play here - 1) What is out there? While I love going through the list of contributed modules there is so much out there that I have no idea where to start sometimes. 2) Core vs. Contrib - This pattern seems to be mainly about general vs. specific - but it is also about quality vs. quantity. It seems that quality vs. quantity needs more attention. 3) Who is this product for? Drupal is a very mature product - but it seems like it hasn't grown up yet :) - which is kinda cool - and kinda infuriating. I think that there needs to be a better definition of who this product is for - is it for the people who spend most of their time developing/contributing to it? Is it for web developers? Is it for webmasters? Is it for end-users? At the end of the day we all sit somewhere in a very long chain which starts with dreamers and ends with a person at the end of a wire plunking at their keyboard. 4) How do things get done around here? The only sure way to do anything is to do it yourself - which is fine - but it limits participation (see 3 above). There are a bunch of different possible solutions to any given problem (like the one pointed out in Allie's email). However without a roadmap it is difficult to know which way to go. Here are some specific things that might work to solve this problem - 1) Right now there are three module categories -> core, modules, sandbox. Perhaps there should be another? "community modules" - being stuff that the "community" endorses? Perhaps by a straight up or down vote of contributors? I know this is radical. 2) There could be a "reviews" blog attached directly to each module - I'm sure this is an old discussion - sorry for bringing it up again. I would love to see Allie's notes from her investigation of the "Amazon" modules so I knew what was in and not in each module. IMHO Drupal is going through some growing pains - Dries pointed this out in Amsterdam when he talked about the phenominal growth of the community. There is a lot of work to be done. Here's one last idea - perhaps what is needed is a community manager? Someone who is committed to full-time work on Drupal and is directed by a clearly agreed upon set of deliverables. We would chip $$ in to pay for this as an experiment - and honestly I think that in a community this size it would be trivial to raise $$ to do this. Of course this entire email is worth less than silver :). Dan > The 4.7 / Forms API upgrade is going to create a learning curve for > many module developers, and some of the less-active module owners may > not have the time and inclination to make the switch. That could be > good news. > > A lot of these efforts are "learning experiences" that are not being > maintained at all. Some of the authors can't be reached, and if > you're too polite to overwrite those modules you start new. Some > developers feel that it's more rewarding to have their name in lights > than to collaborate on a module that's more useful and stable > overall. Some people just don't play well with others. > > As an alternative to upgrading, some module developers could look at > modules with similar functionality and try to help upgrade and > enhance those. Do we really need 3 Amazon modules? 6 "mail this > thing" modules? (one of these is my fault) Can the Flikr Block > module be part of the Flikr Module? The list is endless. > > This is a big problem for new Drupal users and old timers alike. > It's not clear which modules are being maintained and how well they > work. A few months ago, I tried all the Amazon modules and > discovered that each gave me about 60% of a solution. I finally just > dropped the idea if using Amazon at all. I'm sure this sort of thing > happens a lot, and we never even hear about it. > > I'm not saying that any of these modules deserves to die, or that > they can't possibly be bringing anything new to the table, but I > would offer these suggestions: > > - As part of the call for upgrades 4.7, recommend that module > developers try to combine efforts > - Encourage people to maintain TODO lists for modules so that > others can understand overall goals and see if added functionality > would be useful > - Encourage people to archive and retire their abandoned projects > from CVS. > > > Allie Micka > pajunas interactive, inc. > http://www.pajunas.com > > scalable web hosting and open source strategies > > > From ber at webschuur.com Fri Nov 18 16:44:31 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Fri Nov 18 16:44:28 2005 Subject: [development] SCM tools In-Reply-To: <4a9fdc630511180630v2a2f9295n88a30654bad4d870@mail.gmail.com> References: <1132271299.8272.36.camel@localhost.localdomain> <200511180958.36158.ber@webschuur.com> <4a9fdc630511180630v2a2f9295n88a30654bad4d870@mail.gmail.com> Message-ID: <200511181744.31883.ber@webschuur.com> Op vrijdag 18 november 2005 15:30, schreef Khalid B: > You mean it has no GUI? > > I guess that is not a major setback. ?The people used to Tortoise CVS, > WinCVS or Eclipse will see that now they have to write commands and > options though ... Neither do I. CVS (and SVN) are in essense so complex that they need GUI tools to help folks around. I beleive that darcs is so easy to learn (anyone can copy paste some commands, not?) that it needs no GUI. But then again, I am used to the commandline. click-kiddies might not agree. B?r -- [ B?r Kessels | Drupal services www.webschuur.com ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20051118/cc0610fb/attachment.pgp From ber at webschuur.com Fri Nov 18 16:54:37 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Fri Nov 18 16:54:39 2005 Subject: defined audience (Re: [development] Encouraging Collaboration) In-Reply-To: <437E04AA.7000406@civicactions.com> References: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> <437E04AA.7000406@civicactions.com> Message-ID: <200511181754.39594.ber@webschuur.com> Op vrijdag 18 november 2005 17:43, schreef Dan Robinson: > ?I think that there needs to be a better definition of who > this product is for - is it for the people who spend most of their time > developing/contributing to it? One of the reasons Ruby on rails does so well, is because it has this VERY well defined. Thus they have a very targeted audience. We dont have this, which in some way is cool, but on the flipside makes it impossible to get Drupal "just right". A result of not being able to say: 'this is for Charlie, not for Joe' is that we can cater neither Charly nor Joe. And both are then annoyed in some way (Joe wants an online installer, Charlie wants a clean development platform, without all these options and unneeded bloat) And another result is these endless usabilty nitpickyish discussions; whether Foo should be called Bar, whether it should be an option, or rather a theme function etcetc. I, for myself, made a choice. For me, drupal is a Development platform. My modules will no longer 'just work'. All modules I develop from now on, will need some theming, some menu fiddling and maybe even some PHP blocks and/or pages, to be full featured. B?r -- | B?r Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20051118/e99ea9e9/attachment.pgp From larry at garfieldtech.com Fri Nov 18 16:55:38 2005 From: larry at garfieldtech.com (larry@garfieldtech.com) Date: Fri Nov 18 16:56:13 2005 Subject: [development] SCM tools In-Reply-To: <200511181744.31883.ber@webschuur.com> References: <1132271299.8272.36.camel@localhost.localdomain> <200511180958.36158.ber@webschuur.com> <4a9fdc630511180630v2a2f9295n88a30654bad4d870@mail.gmail.com> <200511181744.31883.ber@webschuur.com> Message-ID: <49719.64.7.13.237.1132332938.squirrel@home.garfieldtech.com> > Op vrijdag 18 november 2005 15:30, schreef Khalid B: >> You mean it has no GUI? >> >> I guess that is not a major setback. The people used to Tortoise CVS, >> WinCVS or Eclipse will see that now they have to write commands and >> options though ... > > Neither do I. CVS (and SVN) are in essense so complex that they need GUI > tools > to help folks around. > > I beleive that darcs is so easy to learn (anyone can copy paste some > commands, > not?) that it needs no GUI. But then again, I am used to the commandline. > click-kiddies might not agree. Being a nix guy I use the command line version of CVS or SVN anyway. I find it easier than the GUIs. :-) I am in the minority, however, and I know that. Another point in SVN's favor is that it's conceptually the same as CVS. Any brain-space our current developers have devoted to the CVS modus operandi will translate to SVN very easily. I don't know that you can say the same for any of the distributed managers. That applies to new developers, too. Some random would-be developer who wants to get started is far far more likely to know, understand, and already have installed CVS or SVN than darcs, git, or whatever. That should be a consideration, too. --Larry Garfield From gordon at heydon.com.au Fri Nov 18 18:11:57 2005 From: gordon at heydon.com.au (Gordon Heydon) Date: Fri Nov 18 18:11:54 2005 Subject: [development] SCM tools In-Reply-To: <200511180958.36158.ber@webschuur.com> References: <1132271299.8272.36.camel@localhost.localdomain> <200511180958.36158.ber@webschuur.com> Message-ID: <1132337517.8014.132.camel@localhost.localdomain> Hi, On Fri, 2005-11-18 at 09:58 +0100, B?r Kessels wrote: > Gordon, > > I love Darcs, unfortunately had no chance to test it in a larger developer > environment yet. > > But in any case: darcs was designed exactly* for developer communities and > workflows like Drupal has. Not like svn that noly fixes the mayor annoyences > of an ancient RCS. Darcs has no frontends, but who cares :) zwe dont even > ship with an install frontend, so should we care about developer frontends? Even though it doesn't have any gui front ends the commands are very easy, and could be used by just about any developer. > Thank you, Gordon for getting this going! I am glad it is appreciated. Gordon. From allie at pajunas.com Fri Nov 18 18:18:14 2005 From: allie at pajunas.com (Allie Micka) Date: Fri Nov 18 18:18:21 2005 Subject: [development] Encouraging Collaboration In-Reply-To: References: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> Message-ID: <6A4469C0-37A9-4BC7-B5C3-65D826A75EC0@pajunas.com> On Nov 18, 2005, at 9:46 AM, Earl Dunovant wrote: > For the record, there will only be two Amazon modules in 4.7...I > have Amazon associate tools and Amazon search...the search will be > folded entirely into AAT. And back when I first released it, Ber > suggested I combine efforts with the author of the othe one. We > agreed, but I got zero input so I just wrote what I needed for myself. I'm positive that you aren't the only who has gone this route > I think I'm seen as one who doesn't play well with others...I've > noticed my comments only get responses when someone thinks they can > correct me. You got gatekeepers here like in any other group, and > I'm finally going to mention something that annoyed me. Before > becoming familiar with the cultural aspects of this group AAT > shipped with my associate code as the default. I figured anyone > that used it would change it. Lot of objections...we don't want > people to think we're hustling them. So fine, i change it...as I > said, I didn't feel it would have a significant impact one way or > the other. The comment said i changed it because community > sentiment ran against it. I got an email complaining that I said it > was "mere sentiment." My response was, relax...your project, so > your sentiment is enough reason to change it. Please understand that I wasn't trying to single any person or project out. I was relating my problem with Amazon because I had it in recent memory, and frankly, because it's on the top of the modules list page. The issue is much broader and I'm sorry if it did not seem that way. But your feedback is important, because it shows the cause/effect of group communications. I know my own reasons for duplicating efforts, and I think it's helpful to hear others' experiences. All communities/projects are implicitly defined by their most vocal members/contributors. We don't have to discuss how to define Drupal's objectives, that definition occurs when core members choose to speak up. For example, I adhere to Drupal's coding standards for my modules. Not because it's a requirement (I think it's just a recommendation). And not just because it's documented someplace. I do it because I have seen other community members chastised for submitting non- conforming core and module code. Since it's being brought up consistently, I've become aware that it's a core value of the Drupal community. I am on a number of technical mailing lists. On some of these lists, it's acceptable to yack about the latest slashdot news, ask for Windows tech support, offer up a room for rent, or send silly pictures of your pets. That rarely happens here. Why? There are OT guidelines on all of these lists, but they are community-enforced. On other lists, it would be acceptable for me to discuss my bellybutton lint as long as my subject line was "OT: My Bellybutton Lint" But if I sent a similarly off-topic post here, I would get responses indicating that I should seek a more appropriate forum. Even if these suggestions were gentle and helpful, I would never ask that type of question here again, and I would send a similar recommendation to the next OT-poster, who would inform the next poster, and so-on. This is why the development list is usually helpful and on-topic (well, except for SCM preferences), even without constant reminders. There are some knee-jerk responses I would change ("code is gold! " "too many checkboxes!" ) but Drupal's culture of professionalism and consistency is the most important reason I use it. Without assigning tasks or defining objectives or creating workflows, I hope we can inject some cultural mojo for duplicate work efforts. But if there ARE tasks and work efforts, I +1 in advance any work towards categorizing and/or reviewing modules, or separating them out by some maturity threshold (code conformance, feature-complete, review ranking, peer review, etc.) My standing policy is to avoid installing any module whose author I don't recognize from this list or irc. That's hardly a system that works for new Drupal users! Allie Micka pajunas interactive, inc. http://www.pajunas.com scalable web hosting and open source strategies From piotr at mallorn.ii.uj.edu.pl Fri Nov 18 20:42:31 2005 From: piotr at mallorn.ii.uj.edu.pl (Piotr Krukowiecki) Date: Fri Nov 18 20:42:34 2005 Subject: [development] Encouraging Collaboration In-Reply-To: <437E04AA.7000406@civicactions.com> References: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> <437E04AA.7000406@civicactions.com> Message-ID: <20051118204231.GA30820@mallorn.ii.uj.edu.pl> On Fri, Nov 18, 2005 at 08:43:22AM -0800, Dan Robinson wrote: > 1) What is out there? While I love going through the list of > contributed modules there is so much out there that I have no idea where > to start sometimes. Some categorization would be nice. -- Piotrek irc: #debian.pl Mors Drosophilis melanogastribus! From boris at bryght.com Fri Nov 18 20:48:23 2005 From: boris at bryght.com (Boris Mann) Date: Fri Nov 18 20:48:31 2005 Subject: [development] Encouraging Collaboration In-Reply-To: References: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> Message-ID: <77BE1E64-3299-4738-8ED7-36448314CC51@bryght.com> On 18-Nov-05, at 7:46 AM, Earl Dunovant wrote: > I think I'm seen as one who doesn't play well with others...I've > noticed my comments only get responses when someone thinks they can > correct me. You got gatekeepers here like in any other group, and > I'm finally going to mention something that annoyed me. Before > becoming familiar with the cultural aspects of this group AAT > shipped with my associate code as the default. I figured anyone > that used it would change it. Lot of objections...we don't want > people to think we're hustling them. So fine, i change it...as I > said, I didn't feel it would have a significant impact one way or > the other. The comment said i changed it because community > sentiment ran against it. I got an email complaining that I said it > was "mere sentiment." My response was, relax...your project, so > your sentiment is enough reason to change it. Just wanted to say Earl that I've been following your work on your blog with aggregator/paggregator with interest. It's a core module that only sporadically gets attention. I had brought up before that we might consider designated maintainers for core modules -- see http://drupal.org/node/34439 -- there are still the majority that are theoretically "maintained" by Dries. Dries, do you want to speak up and say which ones you actually want to maintain, which might be in need of an official maintainer, etc.? I agree with many of Dan's comments, and some of those are "in progress" with upgrades to the project.module being funded by CS Labs and implemented by nedjo. We probably need more of a battle plan and assigning dev tasks to people to get some of the other work done, as outlined by the recent poll results. Lastly, the concept of "verified" modules (e.g. image, event) that are non-core has been brought up a couple of times. Essentially, the question becomes, how do modules become verified? Some thoughts I've had are: * at least 2 "maintainers", both of which agree to commit patches regarding bugs, etc. * a commitment from those maintainers to keep updating/port to the next version * ??? Cheers, -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com From prometheus6 at gmail.com Fri Nov 18 20:51:13 2005 From: prometheus6 at gmail.com (Earl Dunovant) Date: Fri Nov 18 20:51:16 2005 Subject: [development] Encouraging Collaboration In-Reply-To: <6A4469C0-37A9-4BC7-B5C3-65D826A75EC0@pajunas.com> References: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> <6A4469C0-37A9-4BC7-B5C3-65D826A75EC0@pajunas.com> Message-ID: I didn't feel singled out in any way. It was an opportunity to speak on something that has shaped my participation. Let he who has ears, and all that. On 11/18/05, Allie Micka wrote: > > Please understand that I wasn't trying to single any person or > project out. I was relating my problem with Amazon because I had it > in recent memory, and frankly, because it's on the top of the modules > list page. The issue is much broader and I'm sorry if it did not > seem that way. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051118/2f8f098e/attachment.htm From jeff at viapositiva.net Fri Nov 18 21:05:14 2005 From: jeff at viapositiva.net (Jeff Eaton) Date: Fri Nov 18 21:05:25 2005 Subject: [development] Encouraging Collaboration In-Reply-To: <77BE1E64-3299-4738-8ED7-36448314CC51@bryght.com> Message-ID: <003a01c5ec83$c8daf1b0$6700a8c0@JEATON2DEV> > > Just wanted to say Earl that I've been following your work on your > blog with aggregator/paggregator with interest. It's a core module > that only sporadically gets attention. > As have I. I'm actually hoping that some of those changes make it into the core aggregator. I only have a handful of feeds and I've run into some of the same management problems that Earl did when creating his 'mega aggregator.' The aggregator module is really one of Drupal's impressive 'differentiating features'. --Jeff From drumm at delocalizedham.com Fri Nov 18 21:12:18 2005 From: drumm at delocalizedham.com (Neil Drumm) Date: Fri Nov 18 21:15:21 2005 Subject: [development] SCM idea Message-ID: <437E43B2.2050402@delocalizedham.com> What if we set up a parallel contributions repository using a different SCM which we would optionally put our modules in? If a few of the large contrib projects moved we could get a good idea of how well it works without risking productivity on core. This of course would be horribly technically complex since the cvs module and release scripts would have to deal with two systems in parallel. -- Neil Drumm http://delocalizedham.com/ From piotr at mallorn.ii.uj.edu.pl Fri Nov 18 21:23:38 2005 From: piotr at mallorn.ii.uj.edu.pl (Piotr Krukowiecki) Date: Fri Nov 18 21:23:41 2005 Subject: [development] An issue needs resolution Message-ID: <20051118212338.GA31799@mallorn.ii.uj.edu.pl> Hello, http://drupal.org/node/36352 Currently search is broken in HEAD. The bug is know, two possibile fixes are known and simple. But which one to choose is a bit political issue ;) Anyway, this bug blocks at least 1 other patch, so maybe some people can take a look at the url? I probably won't like the decision, but any decision is better then no decision at all. -- Piotrek irc: #debian.pl Mors Drosophilis melanogastribus! From karoly at negyesi.net Fri Nov 18 21:41:47 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Fri Nov 18 21:38:16 2005 Subject: [development] SCM idea In-Reply-To: <437E43B2.2050402@delocalizedham.com> References: <437E43B2.2050402@delocalizedham.com> Message-ID: > What if we set up a parallel contributions repository using a different > SCM which we would optionally put our modules in? If a few of the large > contrib projects moved we could get a good idea of how well it works > without risking productivity on core. > > This of course would be horribly technically complex since the cvs > module and release scripts would have to deal with two systems in > parallel. I will develop a bzr.module very soon (this weekend) and also will set up a read-only mirror of, I think, core, and maybe a few contrib modules, we shall see. If CVS moves to drupal3 and I get the chance I will be happy to work on making a bzr-CVS parallel two way synched repo. Regards NK From dries.buytaert at gmail.com Fri Nov 18 22:28:19 2005 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Fri Nov 18 22:32:04 2005 Subject: [development] Encouraging Collaboration In-Reply-To: <77BE1E64-3299-4738-8ED7-36448314CC51@bryght.com> References: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> <77BE1E64-3299-4738-8ED7-36448314CC51@bryght.com> Message-ID: <8EA5859C-349E-41BE-A8D2-83FDFF591C62@buytaert.net> > I had brought up before that we might consider designated > maintainers for core modules -- see http://drupal.org/node/34439 -- > there are still the majority that are theoretically "maintained" by > Dries. Dries, do you want to speak up and say which ones you > actually want to maintain, which might be in need of an official > maintainer, etc.? Having 'official maintainers' matters for me: in the best case scenario people will bug the maintainer and not me. Other than being the official point of contact, very little changes. People become the official maintainer of a core module after they have been given the module some 'love', where 'love' implies that a steady stream of their patches made it into core. For example, I recently invited Cvgbe (Piotr Krukowiecki) to become the official PostgreSQL maintainer after he contributed a dozen PostgreSQL patches. Being the 'official maintainer' doesn't really matter for you (you, being a developer). What matters for you are your patches that make it into core. The more good patches, the higher you are on my list, the more weight you get, and the more trust you gain. Furthermore, for almost all of the core contributors, I know exactly what they are good at, so the weighting actually differs from topic to topic. For example, I may blindly trust Cvgbe's PostgreSQL contributions but I'll be a lot more conservative when he proposes a big forms API change. Don't ask me to write down the list, because not only is it per topic, it is also ever changing. For example, recently Richard Archer has done a number of great menu module patches that have been known to be hard, he demonstrated persistence, and he clearly communicated a vision; as a result, he gained quite a bit of trust with regard to the menu module. -- Dries Buytaert :: http://www.buytaert.net/ From dries.buytaert at gmail.com Fri Nov 18 22:31:37 2005 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Fri Nov 18 22:32:08 2005 Subject: [development] Encouraging Collaboration In-Reply-To: <437E04AA.7000406@civicactions.com> References: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> <437E04AA.7000406@civicactions.com> Message-ID: <3E3A04B6-460A-4510-A02C-B95B74A72586@buytaert.net> > IMHO Drupal is going through some growing pains - Dries pointed > this out > in Amsterdam when he talked about the phenominal growth of the > community. There is a lot of work to be done. Correct. Bear in mind that there always have been growing pains, and that there always will be growing pains. It's perfectly normal. What matters is how we counter the growing pains. To answer your questions: 1. Download page: we are working on improving the download page. 2. Quantity vs quality: we are working on project ratings. (Check with Boris for the latest details?) 3. Who is this product for? Drupal is for users who want to setup a website _and_ for developers who need a platform. 4. How do things get done around here? Either you do it yourself, or you work on it with others. So we are working on the growing pains -- even though you might not have noticed. -- Dries Buytaert :: http://www.buytaert.net/ From adrian at bryght.com Fri Nov 18 22:36:07 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Fri Nov 18 22:36:19 2005 Subject: [development] Encouraging Collaboration In-Reply-To: <8EA5859C-349E-41BE-A8D2-83FDFF591C62@buytaert.net> References: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> <77BE1E64-3299-4738-8ED7-36448314CC51@bryght.com> <8EA5859C-349E-41BE-A8D2-83FDFF591C62@buytaert.net> Message-ID: <288393C1-5C0F-4B57-9803-B585A9FD2AFC@bryght.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19 Nov 2005, at 12:28 AM, Dries Buytaert wrote: > > Don't ask me to write down the list, because not only is it per > topic, it is also ever changing. For example, recently Richard > Archer has done a number of great menu module patches that have > been known to be hard, he demonstrated persistence, and he clearly > communicated a vision; as a result, he gained quite a bit of trust > with regard to the menu module. Richard Archer++ =) - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDfldYgegMqdGlkasRAtlMAJ0ecNs0YzYkKbOaUf1ruGZ7ggUDywCeKsJB 60wL2fWevMsVcs8BCvDRmsI= =/xLU -----END PGP SIGNATURE----- From ber at webschuur.com Fri Nov 18 23:15:09 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Fri Nov 18 23:15:13 2005 Subject: [development] SCM idea In-Reply-To: <437E43B2.2050402@delocalizedham.com> References: <437E43B2.2050402@delocalizedham.com> Message-ID: <200511190015.15175.ber@webschuur.com> Op vrijdag 18 november 2005 22:12, schreef Neil Drumm: > What if we set up a parallel contributions repository using a different > SCM which we would optionally put our modules in? If a few of the large > contrib projects moved we could get a good idea of how well it works > without risking productivity on core. > > This of course would be horribly technically complex since the cvs > module and release scripts would have to deal with two systems in parallel. Gordon and others interested in Darcs: I am very willing to help you with work on darcs. Antyhing that needs to be done now, in order to get some contribs into a repository? Can we use Gordons server or should I set one up myself? Most notably id like to see the development of the files stuff get in there, that is a big project ,with in future (hopefully?) a few developers working on one base. B?r -- [ B?r Kessels | Drupal services www.webschuur.com ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20051118/a1da32ee/attachment.pgp From boris at bryght.com Fri Nov 18 23:36:44 2005 From: boris at bryght.com (Boris Mann) Date: Fri Nov 18 23:36:53 2005 Subject: [development] Encouraging Collaboration In-Reply-To: <8EA5859C-349E-41BE-A8D2-83FDFF591C62@buytaert.net> References: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> <77BE1E64-3299-4738-8ED7-36448314CC51@bryght.com> <8EA5859C-349E-41BE-A8D2-83FDFF591C62@buytaert.net> Message-ID: On 18-Nov-05, at 2:28 PM, Dries Buytaert wrote: >> I had brought up before that we might consider designated >> maintainers for core modules -- see http://drupal.org/node/34439 >> -- there are still the majority that are theoretically >> "maintained" by Dries. Dries, do you want to speak up and say >> which ones you actually want to maintain, which might be in need >> of an official maintainer, etc.? > > Having 'official maintainers' matters for me: in the best case > scenario people will bug the maintainer and not me. Other than > being the official point of contact, very little changes. Right. That's all that I meant. Later on you say "Don't ask me to write down the list"...I guess what I'm asking is if it would be useful to have the list for some more of the core modules. There is a certain responsibility in that case to look at patches for a particular core module, and then it is known by those people. e.g. James knows that he has to personally look at all Blog API bugs/ features/etc. Just as now, any that you feel don't have maintainers (i.e. people with enough trust to be responsible for them) still fall into the everybody looks at them/needs to +1 them. Or, of course, ones that you want to maintain yourself. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com From chris at tinpixel.com Fri Nov 18 23:59:37 2005 From: chris at tinpixel.com (Chris Johnson) Date: Sat Nov 19 00:00:19 2005 Subject: [development] Encouraging Collaboration In-Reply-To: <288393C1-5C0F-4B57-9803-B585A9FD2AFC@bryght.com> References: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> <77BE1E64-3299-4738-8ED7-36448314CC51@bryght.com> <8EA5859C-349E-41BE-A8D2-83FDFF591C62@buytaert.net> <288393C1-5C0F-4B57-9803-B585A9FD2AFC@bryght.com> Message-ID: <437E6AE9.3020609@tinpixel.com> Adrian Rossouw wrote: > Richard Archer++ =) Having worked with Richard Archer on PHPLIB (if what I did could be called work), I knew he would be a good addition to the Drupal team. I was very happy to see his name appear on the dev email list. +1 indeed! :-) ..chrisxj From karoly at negyesi.net Sat Nov 19 00:08:57 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Sat Nov 19 00:05:45 2005 Subject: [development] Encouraging Collaboration In-Reply-To: <437E6AE9.3020609@tinpixel.com> References: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> <77BE1E64-3299-4738-8ED7-36448314CC51@bryght.com> <8EA5859C-349E-41BE-A8D2-83FDFF591C62@buytaert.net> <288393C1-5C0F-4B57-9803-B585A9FD2AFC@bryght.com> <437E6AE9.3020609@tinpixel.com> Message-ID: On Sat, 19 Nov 2005 00:59:37 +0100, Chris Johnson wrote: > Adrian Rossouw wrote: >> Richard Archer++ =) > > > Having worked with Richard Archer on PHPLIB (if what I did could be > called work), I knew he would be a good addition to the Drupal team. I > was very happy to see his name appear on the dev email list. A guy who out of the blue first does menu then plays patch pingpong with we on a forms API related patch? I was astonished. Big ++ From karoly at negyesi.net Sat Nov 19 00:47:02 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Sat Nov 19 00:43:37 2005 Subject: [development] Encouraging Collaboration In-Reply-To: References: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> <77BE1E64-3299-4738-8ED7-36448314CC51@bryght.com> <8EA5859C-349E-41BE-A8D2-83FDFF591C62@buytaert.net> Message-ID: > have the list for some more of the core modules. And includes ;) From mark at nullcraft.org Sat Nov 19 01:08:37 2005 From: mark at nullcraft.org (Mark) Date: Sat Nov 19 01:08:49 2005 Subject: [development] Node referencing In-Reply-To: <20a3038c0511160509g11d6a34ue0a500b301b925c9@mail.gmail.com> References: <20a3038c0511160509g11d6a34ue0a500b301b925c9@mail.gmail.com> Message-ID: <437E7B15.1080303@nullcraft.org> Sergio wrote: > Hello, folks, > I'm in need of a little help... > I have a module with 3 types of node. Node A, B and C. > I am trying to do something like A is the main node and B & C > references A. So that, when I show the node A (teaser or full node), I > get some informations about nodes type B and C that makes reference to A. > Also, I want to node types B and C have a reference to the parent (A). > When the user inserts the data, it must be transparent to him as who > the parent is (like there is a link on node type A that allows the > user to create type B or C and the node creation page will not ask the > user who the parent is). The only creation method shoud be like this > for nodes B and C (there should not have a link on the node creation > list. Just for type A) > > I took a look at the project module, but I couldn't get much out of > it... > Any help is appreciated... > > Thanks, > - Luis Sergio Moura As others have mentioned, there are many modules out there that manage node-to-node relationships. One thing that was a problem the last time I looked was how to go about restricting access to node/add/[type that requires parent]/[nid of parent] without other things breaking. Previous discussions led me to override the menu settings to disallow access to this path, but since the menu system does not prioritize it's entries, you may find that your modification of the menu permissions doesn't always work. The result is that the node/add page shows links to add content that is not allowed to exist without a parent. The Node Relativity module (http://drupal.org/node/17004) essentially does what you're looking for, but hasn't been updated in a while. It is big and needs some refactoring and is probably a heavier solution than you're looking for, though. Regards, -Mark From gordon at heydon.com.au Sat Nov 19 02:12:40 2005 From: gordon at heydon.com.au (Gordon Heydon) Date: Sat Nov 19 02:12:36 2005 Subject: [development] SCM idea In-Reply-To: <200511190015.15175.ber@webschuur.com> References: <437E43B2.2050402@delocalizedham.com> <200511190015.15175.ber@webschuur.com> Message-ID: <1132366360.8014.144.camel@localhost.localdomain> Hi, On Sat, 2005-11-19 at 00:15 +0100, B?r Kessels wrote: > Op vrijdag 18 november 2005 22:12, schreef Neil Drumm: > > What if we set up a parallel contributions repository using a different > > SCM which we would optionally put our modules in? If a few of the large > > contrib projects moved we could get a good idea of how well it works > > without risking productivity on core. > > > > This of course would be horribly technically complex since the cvs > > module and release scripts would have to deal with two systems in parallel. > > Gordon and others interested in Darcs: > > I am very willing to help you with work on darcs. Antyhing that needs to be > done now, in order to get some contribs into a repository? Can we use Gordons > server or should I set one up myself? I could set up the contrib repository if you want. and I am happy to have darcs running on my web site. The only thing is that the web front end sometime gets killed by the dreamhost house keeping because darcs is a little cpu hungry sometimes. > Most notably id like to see the development of the files stuff get in there, > that is a big project ,with in future (hopefully?) a few developers working > on one base. This can all be done, I am just not really up to speed on what happens on the backend for the current drupal cvs setup. But because every darcs repository is a working system then we could actually have with very little work a automated test suite that gets run after every commit. Not exactly sure if we could do this this contrib, but it could be done. Gordon. From dan at civicactions.com Sat Nov 19 03:45:58 2005 From: dan at civicactions.com (Dan Robinson) Date: Sat Nov 19 03:46:06 2005 Subject: [development] Encouraging Collaboration In-Reply-To: <3E3A04B6-460A-4510-A02C-B95B74A72586@buytaert.net> References: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> <437E04AA.7000406@civicactions.com> <3E3A04B6-460A-4510-A02C-B95B74A72586@buytaert.net> Message-ID: <437E9FF6.4050503@civicactions.com> >> IMHO Drupal is going through some growing pains - Dries pointed this >> out >> in Amsterdam when he talked about the phenominal growth of the >> community. There is a lot of work to be done. > > > Correct. Bear in mind that there always have been growing pains, and > that there always will be growing pains. It's perfectly normal. > What matters is how we counter the growing pains. agreed. However as the speed of growth accelerates it will place new strains on the community - IMHO. > > To answer your questions: > > 1. Download page: we are working on improving the download page. great is there a discussion about this somewhere? > 2. Quantity vs quality: we are working on project ratings. (Check > with Boris for the latest details?) great. > 3. Who is this product for? Drupal is for users who want to setup a > website _and_ for developers who need a platform. That's reasonable - but pretty ambitious. There aren't many products out there that are developers tools as well as non-web developers tools. As a matter of fact I can't think of any off hand at all. This doesn't mean that Drupal can't do it - it just means that it is new territory (the fun kind). > 4. How do things get done around here? Either you do it yourself, or > you work on it with others. > > So we are working on the growing pains -- even though you might not > have noticed. no I actually have noticed - and everyone is doing a great job. I did not mean to be negative nor critical - sorry if it came off that way. > > -- > Dries Buytaert :: http://www.buytaert.net/ > > From nedjo at islandnet.com Sat Nov 19 04:06:54 2005 From: nedjo at islandnet.com (Nedjo Rogers) Date: Sat Nov 19 04:06:55 2005 Subject: [development] Encouraging Collaboration References: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> <437E04AA.7000406@civicactions.com> <3E3A04B6-460A-4510-A02C-B95B74A72586@buytaert.net> <437E9FF6.4050503@civicactions.com> Message-ID: <000d01c5ecbe$ad25e390$6400a8c0@family> >> 1. Download page: we are working on improving the download page. > > great is there a discussion about this somewhere? A first step patch was applied to the Project module to enable full categorization of projects (e.g., with multiple vocabularies), see http://drupal.org/node/32121. An issue and draft patch for the next steps - sorting by date and category as well as alphabetically - is at: http://drupal.org/node/33803 I've been working this week on a revised patch and should have it posted next week. Comments meantime would be welcome. And Kieran at CivicSpace Labs is organizing a 'card sort' approach to deciding how to classify existing modules and themes. There is also a proposal to implement (opt in) XML-RPC calls between Drupal installs and drupal.org, see issue at http://drupal.org/node/34108. I'm beginning work on this issue--other ideas and contributions very welcome. >From that issue: Dries: "rather than using explicit rating where users have to submit a score by hand, I'd prefer to use automatic ratings. I envision some XML-RPC function that posts a list of one's modules to Drupal.org. Drupal.org uses that to update/compile ratings. A key advantage is that: (i) it needs no manual rating/interaction (no interface cruft) (ii) easy to make it temporal so that the ratings automatically adapt over time (iii) better matches the reality." ... We could also extend this to enable drupal installs to query drupal.org for newer versions of installed modules, recent bugfixes, newly released modules, etc., thus providing significant benefits to the installed base. From speck at blkmtn.org Sat Nov 19 05:01:38 2005 From: speck at blkmtn.org (Steven Peck) Date: Sat Nov 19 04:43:01 2005 Subject: [development] SCM idea Message-ID: Speaking as one of those using Windows primarily for reasons of work and games. I will note that I only care that tools are available for Windows users. CMD line or otherwise I don't care if they are GUI. If there are tons of switches, then I can make batch files with the switches preseelcted. As long as there are tools that run Windows, then I don't care. I only would like something to be selected so I can go about learning it. Whatever we pick, I plan on making my co-workers learn it so we can control our inhouse administative scripts at work and avoid learning more. As I am lazy, I plan on learning only one of them :). -sp ________________________________ From: development-bounces@drupal.org on behalf of Gordon Heydon Sent: Fri 11/18/2005 6:12 PM To: development@drupal.org Subject: Re: [development] SCM idea Hi, On Sat, 2005-11-19 at 00:15 +0100, B?r Kessels wrote: > Op vrijdag 18 november 2005 22:12, schreef Neil Drumm: > > What if we set up a parallel contributions repository using a different > > SCM which we would optionally put our modules in? If a few of the large > > contrib projects moved we could get a good idea of how well it works > > without risking productivity on core. > > > > This of course would be horribly technically complex since the cvs > > module and release scripts would have to deal with two systems in parallel. > > Gordon and others interested in Darcs: > > I am very willing to help you with work on darcs. Antyhing that needs to be > done now, in order to get some contribs into a repository? Can we use Gordons > server or should I set one up myself? I could set up the contrib repository if you want. and I am happy to have darcs running on my web site. The only thing is that the web front end sometime gets killed by the dreamhost house keeping because darcs is a little cpu hungry sometimes. > Most notably id like to see the development of the files stuff get in there, > that is a big project ,with in future (hopefully?) a few developers working > on one base. This can all be done, I am just not really up to speed on what happens on the backend for the current drupal cvs setup. But because every darcs repository is a working system then we could actually have with very little work a automated test suite that gets run after every commit. Not exactly sure if we could do this this contrib, but it could be done. Gordon. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 5283 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20051119/327d9052/attachment-0001.bin From speck at blkmtn.org Sat Nov 19 05:48:23 2005 From: speck at blkmtn.org (Steven Peck) Date: Sat Nov 19 05:29:45 2005 Subject: [development] Encouraging Collaboration Message-ID: Subject: Re: [development] Encouraging Collaboration >>> IMHO Drupal is going through some growing pains - Dries pointed this >>> out >>> in Amsterdam when he talked about the phenominal growth of the >>> community. There is a lot of work to be done. >> >> >> Correct. Bear in mind that there always have been growing pains, and >> that there always will be growing pains. It's perfectly normal. >> What matters is how we counter the growing pains. > >agreed. However as the speed of growth accelerates it will place new >strains on the community - IMHO. Not really. It's the same strain it's been for the two years I've been playing. This cycle has repeated several times during that time period as more people joined. Each active participant we get brings subtle and dramatic changes to the project. Sometimes the change is in doing the invisible stuff that paves the way for the dramatic visible later. Few see the groundwork, just the result. We probably need to do better writeups on the scale and scope of the work involved when any more new features get added/introduced to Drupal.org. People who are not involved miss a sense of understanding at the work involved by all the contributors. It seems if you can last about six months, then you tend to begin to understand the scale and scope of what is going on. :) >> To answer your questions: >> >> 1. Download page: we are working on improving the download page. > great is there a discussion about this somewhere? I thought it was in the archives, I easily could be wrong, I know it's in writing somewhere. >> 3. Who is this product for? Drupal is for users who want to setup a >> website _and_ for developers who need a platform. > >That's reasonable - but pretty ambitious. There aren't many products >out there that are developers tools as well as non-web developers >tools. As a matter of fact I can't think of any off hand at all. This >doesn't mean that Drupal can't do it - it just means that it is new >territory (the fun kind). How is this different that what we have now? I am not a developer. Two years ago I needed to setup a website and never left. This was with no knowledge of php or MySQL and I was able with minimal assistence using the documentaiton in the forums and the install.txt to do so on an IIS server. I undertstand MySQL a bit better now, php marginally (enough to play with phpTemplate but that's it). Where we are making lots of progress every release is in making it even easier for the non developer. There is documentation in the various snippets sections of the handbook that is improving bit by bit every month. >> 4. How do things get done around here? Either you do it yourself, or >> you work on it with others. >> >> So we are working on the growing pains -- even though you might not >> have noticed. > >no I actually have noticed - and everyone is doing a great job. I did >not mean to be negative nor critical - sorry if it came off that way. You didn't to me, but the really weird thing is, that is absolutly is the way things get done here. The way you find this out is to be involved as you are now. Track developement, say hi in #drupal sometimes. Submit patches, documentation, answer forums questions, etc. So you've noticed. What have you noticed? I'm curious. Perhaps it's something that can be mentioned in the newsletter because we've all forgotten or missed it because we were involved. Don't forget, have fun too. -sepeck -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 6696 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20051119/ac746f8e/attachment.bin From dries.buytaert at gmail.com Sat Nov 19 07:39:25 2005 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Sat Nov 19 07:40:43 2005 Subject: [development] Encouraging Collaboration In-Reply-To: References: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> <77BE1E64-3299-4738-8ED7-36448314CC51@bryght.com> <8EA5859C-349E-41BE-A8D2-83FDFF591C62@buytaert.net> Message-ID: <45BDD863-2078-401C-A749-5A548ED60FAD@buytaert.net> On 19 Nov 2005, at 00:36, Boris Mann wrote: >>> I had brought up before that we might consider designated >>> maintainers for core modules -- see http://drupal.org/node/34439 >>> -- there are still the majority that are theoretically >>> "maintained" by Dries. Dries, do you want to speak up and say >>> which ones you actually want to maintain, which might be in >>> need of an official maintainer, etc.? >> >> Having 'official maintainers' matters for me: in the best case >> scenario people will bug the maintainer and not me. Other than >> being the official point of contact, very little changes. > > Right. That's all that I meant. Later on you say "Don't ask me to > write down the list"...I guess what I'm asking is if it would be > useful to have the list for some more of the core modules. There is > a certain responsibility in that case to look at patches for a > particular core module, and then it is known by those people. e.g. > James knows that he has to personally look at all Blog API bugs/ > features/etc. James is listed as the blogapi module maintainer, but he somewhat stopped caring about it, I think. He didn't look at any of the recent blogapi.module patches. In my book, James stopped doing core development months ago. > Just as now, any that you feel don't have maintainers (i.e. people > with enough trust to be responsible for them) still fall into the > everybody looks at them/needs to +1 them. Or, of course, ones that > you want to maintain yourself. Listing someone as the maintainer doesn't change a thing nor is it a guarantee for success. All it does, is associate an e-mail address with a module. If someone wants to be in the MAINTAINERS.txt, drop me a mail, or better yet, upload a patch against MAINTAINERS.txt. I'll try to update the MAINTAINERS.txt (remove some people, add some people) before I roll a Drupal 4.7.0 RC1. -- Dries Buytaert :: http://www.buytaert.net/ From dries.buytaert at gmail.com Sat Nov 19 08:04:01 2005 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Sat Nov 19 08:05:00 2005 Subject: [development] Encouraging Collaboration In-Reply-To: <437E9FF6.4050503@civicactions.com> References: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> <437E04AA.7000406@civicactions.com> <3E3A04B6-460A-4510-A02C-B95B74A72586@buytaert.net> <437E9FF6.4050503@civicactions.com> Message-ID: <14506D0F-6677-4DC4-82C4-47744F24EFBB@buytaert.net> >> Correct. Bear in mind that there always have been growing pains, and >> that there always will be growing pains. It's perfectly normal. >> What matters is how we counter the growing pains. > > agreed. However as the speed of growth accelerates it will place new > strains on the community - IMHO. Sure. As we grow bigger, the challenges we face grow bigger too. It isn't any different in life. When you are a kid, the challenges you face look big (eg. making it through high school, getting grades, breaking up with a girlfriend) but when you reflect on them at later age, they are peanuts. At later age, you have bigger challenges (getting a job, running a company, paying a loan, taking care of your family). It hasn't been any different in Drupal's lifecycle. To me, growing is learning to deal with bigger challenges (or growing pains). >> 3. Who is this product for? Drupal is for users who want to setup a >> website _and_ for developers who need a platform. > > That's reasonable - but pretty ambitious. There aren't many products > out there that are developers tools as well as non-web developers > tools. As a matter of fact I can't think of any off hand at all. > This > doesn't mean that Drupal can't do it - it just means that it is new > territory (the fun kind). I don't think it is ambitious; it is merely logical. If we focus on making Drupal a great developer platform, then that implies that other developers use it to make products. If they can or have to make products using Drupal, we should be able to make a base product too, shouldn't we? In fact, by making a base product, we get better understanding of the shortcomings. Furthermore, by being (or attracting) both users and developers we have our own feedback loop. As you said, it makes for a much more interesting situation and a diverse community. I'd say that is how most -- if not all -- open source communities work so there are actually plenty of examples out there. (It is also why I fundamentally disagree with the stuff Ber wrote about making a choice and giving up one aspect.) -- Dries Buytaert :: http://www.buytaert.net/ From karoly at negyesi.net Sat Nov 19 09:44:47 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Sat Nov 19 09:41:13 2005 Subject: [development] Doc the new theme functions Message-ID: Hi! grep "function theme_" module|wc -l 55 grep -B1 "function theme_" module|grep \/|wc -l 17 If my greps are correct, then there are 38 theme functions in core now which are undocumented. Regards NK From ber at webschuur.com Sat Nov 19 10:24:52 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Sat Nov 19 10:24:50 2005 Subject: [development] Encouraging Collaboration In-Reply-To: <14506D0F-6677-4DC4-82C4-47744F24EFBB@buytaert.net> References: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> <437E9FF6.4050503@civicactions.com> <14506D0F-6677-4DC4-82C4-47744F24EFBB@buytaert.net> Message-ID: <200511191124.52769.ber@webschuur.com> Op zaterdag 19 november 2005 09:04, schreef Dries Buytaert: > (It is also why I fundamentally disagree with the stuff Ber wrote ? > about making a choice and giving up one aspect.) I think we don't disagree. A diverse community is very good. But IMHO that communtiy does not have to livz all on one place. Linux's distro system works great: you have a huge and diverse community. When I got kernelfreezeson my new/odd AMD, I reported that to mandrake, they told me it went all the way up to the kernel guys (woo). So, while I have to only talk to folks trained for helpdesks (mandrake payed helpdesk), I am still part of the community. I strongly beleive in Drupal itself as a 'nothing in particular' (not as much as RoR, but maybe in the direction of typo3-but-then-easy). Around that, a flock of distro's that are very particular can be maintained. Too often do I hear the comlpain that 'Movable Type is much better then Drupal'. This is simply untrue. Not because MT is better/worse, but because Drupal cannot be compared to a focused CMS. Now, if we would have Dan Developer maintaining a (maintained) drupalBLOG solely for blogging, al these endless discussions about taxonomy/themes/options/usability being too hard to grok would stop. But also DrupalBLOG could be compared to MT, and would do very, very well. ATM the model is Joe User <-> Drupal While, the model could be: Joe User <-> Dan Developer <-> Drupal. We don't loose feedback. Instead: we then know that when Dan Developer speaks, or comes with a patch, he does so for hundreds (of thousands) of users. While in our current situation, there is a lot of buzz. And Joe Users voice (or issue or patch) is lost in that noise. I for one, know, that when Boris/James/Adrian/Roland say that we really need [tm] clean URLS in core, that that weights far more, then when I say "i want theme_foo to get more info". It is because Bright talks to real users on a daily base. And not only to these few users that manage to fight themselves into the forums. How many of you do not think 'RTFM' when someone asks "how do I delete a user". That Question itself indeed is a RTFM Q. But it is also valuable, because if fiften people a week answer that, we have found another usaility bug. B?r -- | B?r Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20051119/3a30532d/attachment.pgp From gildas.cotomale at gmail.com Sat Nov 19 10:49:49 2005 From: gildas.cotomale at gmail.com (Gildas COTOMALE) Date: Sat Nov 19 10:49:51 2005 Subject: [development] Encouraging Collaboration In-Reply-To: <000d01c5ecbe$ad25e390$6400a8c0@family> References: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> <437E04AA.7000406@civicactions.com> <3E3A04B6-460A-4510-A02C-B95B74A72586@buytaert.net> <437E9FF6.4050503@civicactions.com> <000d01c5ecbe$ad25e390$6400a8c0@family> Message-ID: <99469d070511190249y38a31455k@mail.gmail.com> 2005/11/19, Nedjo Rogers : > > We could also extend this to enable drupal installs to query drupal.org for > newer versions of installed modules, recent bugfixes, newly released > modules, etc., thus providing significant benefits to the installed base. > This will be a great enhancement (also for themes) > -- vi is a real WYSIWYG editor: you see text, you get text. From adrian at bryght.com Sat Nov 19 11:00:37 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Sat Nov 19 11:00:57 2005 Subject: [development] Encouraging Collaboration In-Reply-To: <99469d070511190249y38a31455k@mail.gmail.com> References: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> <437E04AA.7000406@civicactions.com> <3E3A04B6-460A-4510-A02C-B95B74A72586@buytaert.net> <437E9FF6.4050503@civicactions.com> <000d01c5ecbe$ad25e390$6400a8c0@family> <99469d070511190249y38a31455k@mail.gmail.com> Message-ID: <7001B787-CD08-4CFF-813B-6AE9825310D2@bryght.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19 Nov 2005, at 12:49 PM, Gildas COTOMALE wrote: > 2005/11/19, Nedjo Rogers : >> >> We could also extend this to enable drupal installs to query >> drupal.org for >> newer versions of installed modules, recent bugfixes, newly released >> modules, etc., thus providing significant benefits to the >> installed base. >> > This will be a great enhancement (also for themes) It's already planned. http://drupal.org/install-system-overview I will be writing DEP's about each of the different phases still outstanding pretty soon. (once 4.7 is out) - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDfwXWgegMqdGlkasRAj+CAKDHOcrHOAAjfOtLos3AIsgeWn3EVgCfeptS aFk8eEGsR1d4retNNHacBl0= =55L8 -----END PGP SIGNATURE----- From prometheus6 at gmail.com Sat Nov 19 12:32:00 2005 From: prometheus6 at gmail.com (Earl Dunovant) Date: Sat Nov 19 12:32:03 2005 Subject: [development] Node referencing In-Reply-To: <437E7B15.1080303@nullcraft.org> References: <20a3038c0511160509g11d6a34ue0a500b301b925c9@mail.gmail.com> <437E7B15.1080303@nullcraft.org> Message-ID: So...an easy way to add a parent reference plus a straightforward way to keep type creation links off the content/add page would pretty much do it? Am I missing something? Because the new node identification method in 4.7can be adjusted slightly to hide those links. A small change to the array hook_node_info() returns (add an element to indicate visibility), a new op for _node_names() (call it "display create link" or something) and a small change to node_add() would do it. On 11/18/05, Mark wrote: > > One thing that was a problem the last time > I looked was how to go about restricting access to node/add/[type that > requires parent]/[nid of parent] without other things breaking. > Previous discussions led me to override the menu settings to disallow > access to this path, but since the menu system does not prioritize it's > entries, you may find that your modification of the menu permissions > doesn't always work. The result is that the node/add page shows links > to add content that is not allowed to exist without a parent. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051119/08a0b920/attachment.htm From adrian at bryght.com Sat Nov 19 12:37:36 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Sat Nov 19 12:37:51 2005 Subject: [development] Node referencing In-Reply-To: References: <20a3038c0511160509g11d6a34ue0a500b301b925c9@mail.gmail.com> <437E7B15.1080303@nullcraft.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19 Nov 2005, at 2:32 PM, Earl Dunovant wrote: > So...an easy way to add a parent reference plus a straightforward > way to keep type creation links off the content/add page would > pretty much do it? http://drupal.org/node/28480 - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDfxyRgegMqdGlkasRAlxGAJ4w/XPaTTqzSdi/UhC0dkb4hwceKwCgv4pl v3KQTNOukxam6qCHgKNoD4E= =Xd/w -----END PGP SIGNATURE----- From weitzman at tejasa.com Sat Nov 19 13:01:52 2005 From: weitzman at tejasa.com (Moshe Weitzman) Date: Sat Nov 19 13:01:56 2005 Subject: [development] Node referencing In-Reply-To: <437E7B15.1080303@nullcraft.org> References: <20a3038c0511160509g11d6a34ue0a500b301b925c9@mail.gmail.com> <437E7B15.1080303@nullcraft.org> Message-ID: <437F2240.8060807@tejasa.com> > As others have mentioned, there are many modules out there that manage > node-to-node relationships. One thing that was a problem the last time > I looked was how to go about restricting access to node/add/[type that > requires parent]/[nid of parent] without other things breaking. > Previous discussions led me to override the menu settings to disallow > access to this path, but since the menu system does not prioritize it's > entries, you may find that your modification of the menu permissions > doesn't always work. The result is that the node/add page shows links > to add content that is not allowed to exist without a parent. The Node > Relativity module (http://drupal.org/node/17004) essentially does what > you're looking for, but hasn't been updated in a while. It is big and > needs some refactoring and is probably a heavier solution than you're > looking for, though. what about simply removing the node/add page using menus module? that page is often worthless anyway (as is the whole navigation block IMO). -moshe From adrian at bryght.com Sat Nov 19 13:34:59 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Sat Nov 19 13:35:15 2005 Subject: [development] Node referencing In-Reply-To: <437F2240.8060807@tejasa.com> References: <20a3038c0511160509g11d6a34ue0a500b301b925c9@mail.gmail.com> <437E7B15.1080303@nullcraft.org> <437F2240.8060807@tejasa.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19 Nov 2005, at 3:01 PM, Moshe Weitzman wrote: > > As others have mentioned, there are many modules out there that > manage >> node-to-node relationships. One thing that was a problem the last >> time I looked was how to go about restricting access to node/add/ >> [type that requires parent]/[nid of parent] without other things >> breaking. Previous discussions led me to override the menu >> settings to disallow access to this path, but since the menu >> system does not prioritize it's entries, you may find that your >> modification of the menu permissions doesn't always work. The >> result is that the node/add page shows links to add content that >> is not allowed to exist without a parent. The Node Relativity >> module (http://drupal.org/node/17004) essentially does what you're >> looking for, but hasn't been updated in a while. It is big and >> needs some refactoring and is probably a heavier solution than >> you're looking for, though. > > what about simply removing the node/add page using menus module? > that page is often worthless anyway (as is the whole navigation > block IMO). For the new version of oasismag I am dropping the use of the nagivation block. 1) i am moving the admin menu to it's own block, enabled only for admins. 2) i am putting site wide links (journals, poetry, forum and about) into the primary links (underneath the header). [ anything that is shared space ] 3) I am putting personal links (my account, my journal, my inbox (n) etc.) into the secondary links, which are placed to the top right of the header. [ anything that is personal space ] 4) I am moving all the 'actions' into a flat menu at the top right block. (new journal entry, new forum post, new private message etc.) [ anything that results in an object being created ] I like this because everything has it's place, and it keeps each of the menu's to the bare minimum. Since we have tabs now, i see no reason for deeply nested configurations anymore. I also want to make all the things you can do and see , visible most of the time, without having to click down into trees. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDfyoEgegMqdGlkasRAjAZAKC9oYx2QQLXmOWpbLlCm84esHr2fwCeMpAO /TNLR/G2Tyt1g/o5AZ2dMxk= =RwIj -----END PGP SIGNATURE----- From weitzman at tejasa.com Sat Nov 19 13:58:45 2005 From: weitzman at tejasa.com (Moshe Weitzman) Date: Sat Nov 19 13:58:47 2005 Subject: [development] bashing the navigation block In-Reply-To: References: <20a3038c0511160509g11d6a34ue0a500b301b925c9@mail.gmail.com> <437E7B15.1080303@nullcraft.org> <437F2240.8060807@tejasa.com> Message-ID: <437F2F95.5050105@tejasa.com> >> what about simply removing the node/add page using menus module? that >> page is often worthless anyway (as is the whole navigation block IMO). > > For the new version of oasismag I am dropping the use of the nagivation > block. > > 1) i am moving the admin menu to it's own block, enabled only for admins. > 2) i am putting site wide links (journals, poetry, forum and about) into > the primary links (underneath the header). [ anything that is shared > space ] > 3) I am putting personal links (my account, my journal, my inbox (n) > etc.) into the secondary links, which are placed to the top right of the > header. [ anything that is personal space ] > 4) I am moving all the 'actions' into a flat menu at the top right > block. (new journal entry, new forum post, new private message etc.) [ > anything that results in an object being created ] > > I like this because everything has it's place, and it keeps each of the > menu's to the bare minimum. Since we have tabs now, i see no reason for > deeply nested > configurations anymore. > > I also want to make all the things you can do and see , visible most of > the time, without having to click down into trees. yeah, thats what i am now doing for my sites too. the navigation block is a failed experiment IMO. A site of any magnitude needs custom navigation beyond what is provided by that block. furthermore, the navigation block is extremely expensive to calculate. thats why we do the whole menu_build() and menu cache. if we get rid of it, we can move the callback system to the DB and skip the menu building business. jonbob posted a note on 10/30 to this list that he was working on this (list archives are mysteriously missing this time period).he said: "I've done some initial work toward separating the data structures for callbacks and for the visible tree. At the moment I can't imagine it has a performance impact in either direction, but it cleans things up a little bit and might be a stepping stone for further separation. I'll post the patch when it's further tested. " we should think a bit about what 'out of the box' experience we can offer without a navigation block. i'm thinking that we offer some default primary links. From ber at webschuur.com Sat Nov 19 15:18:56 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Sat Nov 19 15:18:55 2005 Subject: [development] Node referencing In-Reply-To: <437F2240.8060807@tejasa.com> References: <20a3038c0511160509g11d6a34ue0a500b301b925c9@mail.gmail.com> <437E7B15.1080303@nullcraft.org> <437F2240.8060807@tejasa.com> Message-ID: <200511191618.57340.ber@webschuur.com> Op zaterdag 19 november 2005 14:01, schreef Moshe Weitzman: > what about simply removing the node/add page using menus module? that page > is often worthless anyway (as is the whole navigation block IMO). > > -moshe Pease +1. it is broken ATM, hard to get fixed and indeed is quite useless. (do you really read what a blog is, every time you want to add a blog post?) I have no time to code this, though; So my +1 is not worth much :) B?r -- | B?r Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20051119/5a195941/attachment.pgp From drupal-devel at drupal.org Sat Nov 19 15:20:42 2005 From: drupal-devel at drupal.org (drupal-devel@drupal.org) Date: Sat Nov 19 15:20:44 2005 Subject: [development] Release critical bugs for November 19, 2005 Message-ID: <20051119152042.E81CA137A6E@drupal2.osuosl.org> / bug reports Article tag repeating age: 5 days 2 hours url: http://drupal.org/node/37544 PHP 4.4.1 breaks Article Categories list age: 2 weeks 1 day url: http://drupal.org/node/36245 / bug reports XML Parsing Error age: 2 weeks 4 days url: http://drupal.org/node/35872 / bug reports email spam filtering does not "see" email addresses when they are NOT preceded by a word age: 43 weeks 6 days url: http://drupal.org/node/15654 / bug reports broken config screen age: 1 week 3 days url: http://drupal.org/node/36949 / bug reports Use of array_merge() and book_admin_edit_book() not working age: 2 hours 14 min url: http://drupal.org/node/38196 Duplicate values for insert with multiple taxonomy select (new form API) age: 3 days 3 hours url: http://drupal.org/node/37829 Clean URLs not working properly with Firefox and Opera! age: 3 days 12 hours url: http://drupal.org/node/37794 if you edit a page with activated "moderation queue" the node gets completely hidden age: 4 days 17 hours url: http://drupal.org/node/37613 Unable to delete multiple nodes age: 5 days 2 hours url: http://drupal.org/node/37547 New Forms API bug with "date" type form field (in profile.module) age: 5 days 14 hours url: http://drupal.org/node/37494 File uploading is broken by patch #36791 age: 5 days 23 hours url: http://drupal.org/node/37452 Apply "Request New Password Security" to 4.6.x branch age: 6 days 58 min url: http://drupal.org/node/37440 Theme settings assigned: pofe@drupal.hu age: 1 week 1 day url: http://drupal.org/node/37160 Uploads don't go away assigned: Souvent22 age: 1 week 3 days url: http://drupal.org/node/36875 not work hook eg. fckeditor_textarea ($op, $name) ? assigned: Kiev1.org age: 1 week 4 days url: http://drupal.org/node/36816 It is possible to delete uid=1 age: 1 week 4 days url: http://drupal.org/node/36701 Postgres 4.5.4 to 4.5.5 upgrade makes user system break. age: 1 week 5 days url: http://drupal.org/node/36670 Right blocks pushed beyond the header boundary age: 1 week 5 days url: http://drupal.org/node/36637 >From validation won't work for user's on some ISP's age: 1 week 5 days url: http://drupal.org/node/36591 Random "access denied" and logouts age: 2 weeks 18 hours url: http://drupal.org/node/36386 Profile.module accepts, but does not display, user input age: 2 weeks 19 hours url: http://drupal.org/node/36381 expecting `T_STRING' or `T_VARIABLE' or `T_NUM_STRING' age: 2 weeks 2 days url: http://drupal.org/node/36159 Mail warning errors age: 2 weeks 3 days url: http://drupal.org/node/35973 Form API missing textarea hook age: 3 weeks 20 hours url: http://drupal.org/node/35594 update makes me loose all my themes and blocks and so. age: 3 weeks 23 hours url: http://drupal.org/node/35577 Profile_values random overwritten age: 3 weeks 1 day url: http://drupal.org/node/35555 IE allocates memory until it crashes age: 3 weeks 2 days url: http://drupal.org/node/35368 $status is not returned when the vocabulary 'Forums' is being made age: 3 weeks 4 days url: http://drupal.org/node/35177 Duplicate entries in aggregator age: 3 weeks 5 days url: http://drupal.org/node/35048 Bad SQl query, postgresql, c.format column to GROUP BY clause age: 3 weeks 5 days url: http://drupal.org/node/35008 Changing theme in cvs PHP5 is not working age: 3 weeks 5 days url: http://drupal.org/node/34991 Error when using the 'Vote' button to vote at a poll age: 3 weeks 6 days url: http://drupal.org/node/34921 Search results don't include last part of longer pages age: 4 weeks 16 hours url: http://drupal.org/node/34826 Cron Search Executes PHP pages - Node Range Lost Permanently in Search age: 4 weeks 1 day url: http://drupal.org/node/34768 Can't save admin settings - "directory does not exist" age: 4 weeks 2 days url: http://drupal.org/node/34646 Permissions Too Prohibitive on Install age: 4 weeks 3 days url: http://drupal.org/node/34502 upload module and space in filenames age: 4 weeks 3 days url: http://drupal.org/node/34497 Problem with nodes when upgrading 4.6.3 ->4.7 age: 4 weeks 5 days url: http://drupal.org/node/34342 Bug in settings (if upload directory is unwritable we won't be able to change settings) assigned: chx age: 4 weeks 6 days url: http://drupal.org/node/34218 Theme settings not saved since Forms API assigned: chx age: 5 weeks 2 hours url: http://drupal.org/node/34170 overzealous file_check_directory for file_directory_path age: 5 weeks 3 days url: http://drupal.org/node/33771 Pictures (avatars) don't display age: 5 weeks 4 days url: http://drupal.org/node/33699 No checking/catching for unique database columns assigned: cyrific age: 5 weeks 6 days url: http://drupal.org/node/33478 Bug in node_load call in statistics_node_tracker age: 8 weeks 19 hours url: http://drupal.org/node/32040 Upload broken in IE age: 8 weeks 1 day url: http://drupal.org/node/31968 Comment options: broken. age: 8 weeks 4 days url: http://drupal.org/node/31641 Node update hooks are getting stale data and can't save. age: 8 weeks 6 days url: http://drupal.org/node/31495 Translation/localization import bug (Drupal 4.6.3, Fedora 4) age: 9 weeks 1 day url: http://drupal.org/node/31364 When removing a revision, the associated files are not removed. assigned: killes@www.drop.org age: 9 weeks 1 day url: http://drupal.org/node/31355 Delete filter format fails age: 10 weeks 23 hours url: http://drupal.org/node/30781 Submit button needs double-press when menu options dropped-down age: 11 weeks 3 days url: http://drupal.org/node/30097 update.php is broken when drupal is installed in subdirectory age: 11 weeks 3 days url: http://drupal.org/node/30075 Drupal "forgets" some blocks... age: 12 weeks 1 day url: http://drupal.org/node/29733 files table needs a "module" column age: 12 weeks 6 days url: http://drupal.org/node/29297 logo uploads still broken...? can't replace default logo with new drupal 4.6.3 tar ball? age: 13 weeks 19 hours url: http://drupal.org/node/29221 Error when anonymous user creates content age: 13 weeks 3 days url: http://drupal.org/node/29032 Reset user mail variables. age: 13 weeks 5 days url: http://drupal.org/node/28868 Free Tagging broken on forums age: 14 weeks 3 days url: http://drupal.org/node/28607 js addLoadEvent not working. age: 15 weeks 6 days url: http://drupal.org/node/27884 Forum bug with drupal 462 age: 16 weeks 2 days url: http://drupal.org/node/27663 enable MySQL client side for UTF8 age: 17 weeks 4 days url: http://drupal.org/node/26990 Drupal 4.6.2 Doesn't allow login (IIS 5.1, PHP 5.0.4) assigned: bigeye age: 18 weeks 22 hours url: http://drupal.org/node/26780 use upload_tmp_dir as default for FILE_DIRECTORY_TEMP age: 19 weeks 6 days url: http://drupal.org/node/26249 postgresql autocomplete code age: 20 weeks 2 days url: http://drupal.org/node/26027 Accidentally Deleting Forums Vocabulary in Categories Breaks Forums? age: 24 weeks 13 hours url: http://drupal.org/node/24274 Getting term node counts fails without "Administer Nodes" permission age: 24 weeks 3 days url: http://drupal.org/node/24015 Mysql Password with special symbols assigned: zignit age: 28 weeks 6 days url: http://drupal.org/node/21719 4.6 aggregator showing/not interpreting HTML tags age: 32 weeks 6 days url: http://drupal.org/node/19874 New submit error, non-admin user, postgresql database assigned: adrian age: 36 weeks 3 days url: http://drupal.org/node/18552 user redirected to homepage when logging in age: 37 weeks 21 hours url: http://drupal.org/node/18381 Cache should store BINARY data as a BLOB and not as text age: 40 weeks 3 days url: http://drupal.org/node/16998 Change to sesssion.inc violates UID database constraint age: 43 weeks 6 days url: http://drupal.org/node/15666 forum.module problem with postgresql v7.4.1 age: 44 weeks 4 days url: http://drupal.org/node/15411 Argument NOT must be type boolean age: 1 year 4 days url: http://drupal.org/node/12950 node options reverts to default upon edit -- messages and documentation needed assigned: matt westgate age: 1 year 26 weeks url: http://drupal.org/node/7940 user error: Duplicate entry assigned: Kjartan age: 1 year 50 weeks url: http://drupal.org/node/4428 / feature requests Profile fields should be controlled by roles age: 2 weeks 6 days url: http://drupal.org/node/35693 Module Access Control age: 3 weeks 1 day url: http://drupal.org/node/35459 Customizable module blocks age: 4 weeks 3 days url: http://drupal.org/node/34563 Filter the title to allow HTML comments age: 17 weeks 1 day url: http://drupal.org/node/27205 No obvious way to tell which release a site is running assigned: Uwe Hermann age: 31 weeks 2 days url: http://drupal.org/node/20439 moving pages en masse age: 33 weeks 2 days url: http://drupal.org/node/19754 Taxonomy module should use nodeapi 'load' age: 36 weeks 2 days url: http://drupal.org/node/18631 Auto PHP memory maximisation age: 38 weeks 4 days url: http://drupal.org/node/17663 Allow named anchors to work without specifying full path to node age: 1 year 52 weeks url: http://drupal.org/node/4213 / support requests Loop Requests age: 19 hours 57 min url: http://drupal.org/node/38124 XAMPP \ Mercury Mail Server interrupt on hotmail emails age: 1 day 4 hours url: http://drupal.org/node/38088 Automatically assign taxonomy to Forum, Container or Forum Topic? age: 2 days 18 hours url: http://drupal.org/node/37893 user logins failing - cry for help age: 3 weeks 4 days url: http://drupal.org/node/35104 Password error when changing user role age: 3 weeks 6 days url: http://drupal.org/node/34933 / bug reports event_add_item - no such function found in the source. age: 14 hours 35 min url: http://drupal.org/node/38151 / feature requests Events only for registered users age: 4 weeks 2 days url: http://drupal.org/node/34640 / support requests displaying event start info in flexinode tabular view? age: 6 weeks 4 days url: http://drupal.org/node/33019 Event block missing content of many fields age: 8 weeks 6 days url: http://drupal.org/node/31532 / bug reports file size bug age: 23 weeks 1 day url: http://drupal.org/node/24728 / bug reports Search results give incorrect links age: 5 weeks 6 days url: http://drupal.org/node/33539 Full screen slideshow in Gallery module is not working (erroring out on the wrong URL) age: 19 weeks 2 days url: http://drupal.org/node/26479 / support requests import existing gallery2 user account age: 2 weeks 4 days url: http://drupal.org/node/35920 / feature requests Goofy Forum UI age: 7 weeks 4 days url: http://drupal.org/node/32294 / bug reports imagemagick.inc file does not contain the function... age: 6 days 18 hours url: http://drupal.org/node/37372 Error when Submitting New Image Node age: 6 days 18 hours url: http://drupal.org/node/37366 only variables can be passed by reference on line 713 age: 2 weeks 2 days url: http://drupal.org/node/36092 image.module 4.6.0 strange actions age: 6 weeks 1 day url: http://drupal.org/node/33292 File copy failed: source file does not exist error after running update-image.php age: 8 weeks 3 days url: http://drupal.org/node/31816 Path for image folder not inserted correctly when nodetype = image age: 11 weeks 3 days url: http://drupal.org/node/30031 image module patch & image_import module age: 12 weeks 5 days url: http://drupal.org/node/29377 image module fails on dual site configuration age: 18 weeks 2 days url: http://drupal.org/node/26657 Cannot upload .jpgs age: 37 weeks 5 days url: http://drupal.org/node/18076 / feature requests Copying original age: 2 weeks 1 day url: http://drupal.org/node/36321 Image deletions? age: 10 weeks 3 days url: http://drupal.org/node/30557 / support requests Image Folder Permissions age: 4 weeks 14 hours url: http://drupal.org/node/34839 Images are there but not showing assigned: Stepfordtwit age: 16 weeks 2 days url: http://drupal.org/node/27615 Image Module Permissions age: 19 weeks 6 days url: http://drupal.org/node/26280 / bug reports Listhandler prints HTML tags in outgoing messages age: 4 days 18 hours url: http://drupal.org/node/37598 Listhandler caused error in "comment.module on line 996" ? age: 2 weeks 1 day url: http://drupal.org/node/36244 Prefix column error for SQL in Listhandler admin!! age: 6 weeks 4 days url: http://drupal.org/node/33017 / tasks Correct/Complete Documentation age: 3 weeks 6 days url: http://drupal.org/node/34909 / bug reports Naming issues with files and DB tables age: 4 weeks 5 days url: http://drupal.org/node/34298 RSS "no element found at line 1" age: 20 weeks 20 hours url: http://drupal.org/node/26185 Outdated help texts age: 1 year 15 weeks url: http://drupal.org/node/9692 Import doesn't like XML/RSS feeds with no Title element age: 1 year 24 weeks url: http://drupal.org/node/8128 / tasks move XML-parser into an inclde file. age: 21 weeks 4 days url: http://drupal.org/node/25439 / feature requests Notify.module ignores the true submission queue age: 2 years 3 weeks url: http://drupal.org/node/3765 / bug reports Login as an alias gets cached age: 8 weeks 4 days url: http://drupal.org/node/31699 / bug reports support dynamic content? age: 7 hours 13 min url: http://drupal.org/node/38181 please explain html2fpdf age: 3 days 20 hours url: http://drupal.org/node/37748 Management of french charaters age: 1 week 5 days url: http://drupal.org/node/36605 / feature requests Internationalization support for PDF assigned: TheLibrarian age: 1 year 33 weeks url: http://drupal.org/node/6795 / bug reports privatemsg not working with current head age: 9 weeks 1 hour url: http://drupal.org/node/31469 Reminder email links don't work age: 21 weeks 1 day url: http://drupal.org/node/25677 / feature requests Simplified Chinese translations age: 5 days 13 hours url: http://drupal.org/node/37505 / bug reports No Components are Loading age: 20 hours 25 min url: http://drupal.org/node/38120 Pass by reference error in PHP 5.0.5 age: 1 week 3 days url: http://drupal.org/node/36866 Get disconnected from server on attempting to add an issue age: 2 weeks 2 days url: http://drupal.org/node/36124 can't select all projects age: 6 weeks 1 day url: http://drupal.org/node/33262 Can't update issue title from issue comment assigned: nedjo age: 6 weeks 5 days url: http://drupal.org/node/32843 Projects not listed and page not complete age: 24 weeks 4 days url: http://drupal.org/node/23956 Date for latest is incorrect age: 31 weeks 2 days url: http://drupal.org/node/20485 / feature requests Search by Version age: 20 hours 49 sec url: http://drupal.org/node/38122 Assign Anyone age: 23 hours 12 min url: http://drupal.org/node/38107 Allow subscription to individual project issues age: 4 weeks 3 days url: http://drupal.org/node/34496 Implement XML-RPC functionlality for communication between drupal.org and Drupal installations age: 5 weeks 20 hours url: http://drupal.org/node/34108 / support requests Add the project release manually without the scan feature age: 4 weeks 3 days url: http://drupal.org/node/34500 / bug reports Error with URL to recipe age: 11 weeks 5 days url: http://drupal.org/node/29885 / feature requests Request to generate email for all content changes/additions, including comments age: 18 weeks 2 hours url: http://drupal.org/node/26824 / bug reports Wrong URL mask age: 3 weeks 3 days url: http://drupal.org/node/35215 / bug reports Does not work correctly in Internet Explorer age: 6 weeks 1 day url: http://drupal.org/node/33354 Blocks switch and reset when vocabs are modified age: 27 weeks 2 days url: http://drupal.org/node/22631 javascrip downloads square.gif for every category age: 39 weeks 4 days url: http://drupal.org/node/17366 / feature requests A unique page for each category group? age: 4 weeks 2 days url: http://drupal.org/node/34610 / support requests Taxonomy has dissapeared age: 6 weeks 3 days url: http://drupal.org/node/33061 / bug reports Sends trackbacks for unpublished nodes assigned: ankur age: 42 weeks 2 days url: http://drupal.org/node/16239 / feature requests A small but effective improvement to Improvement of admin/user accessability suggestion age: 5 weeks 1 day url: http://drupal.org/node/34073 / bug reports Resolution appears to be in the cvs version of the linkattach module assigned: hintbw age: 4 weeks 1 day url: http://drupal.org/node/34765 From gerhard at killesreiter.de Sat Nov 19 15:24:30 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Sat Nov 19 15:26:09 2005 Subject: [development] Node referencing In-Reply-To: <200511191618.57340.ber@webschuur.com> References: <20a3038c0511160509g11d6a34ue0a500b301b925c9@mail.gmail.com> <437E7B15.1080303@nullcraft.org> <437F2240.8060807@tejasa.com> <200511191618.57340.ber@webschuur.com> Message-ID: <437F43AE.10500@killesreiter.de> B?r Kessels wrote: >Op zaterdag 19 november 2005 14:01, schreef Moshe Weitzman: > > >>what about simply removing the node/add page using menus module? that page >>is often worthless anyway (as is the whole navigation block IMO). >> >> > >Pease +1. it is broken ATM, hard to get fixed and indeed is quite useless. (do >you really read what a blog is, every time you want to add a blog post?) > > > On a site like Drupal.org where you have a constant influx of new members, this page is quite usefull. In fact, I've long wanted that page to be themable in order to be able to add some nice icons. I think Vlado has done some work on this. node_add is one of those functions that are around like forever, time to make it themable. >I have no time to code this, though; So my +1 is not worth much :) > > > Removing the menu with menu.module should not require any code. Cheers, Gerhard From prometheus6 at gmail.com Sat Nov 19 16:48:32 2005 From: prometheus6 at gmail.com (Earl Dunovant) Date: Sat Nov 19 16:48:33 2005 Subject: [development] Node referencing In-Reply-To: References: <20a3038c0511160509g11d6a34ue0a500b301b925c9@mail.gmail.com> <437E7B15.1080303@nullcraft.org> Message-ID: On 11/19/05, Adrian Rossouw wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 19 Nov 2005, at 2:32 PM, Earl Dunovant wrote: > > > So...an easy way to add a parent reference plus a straightforward > > way to keep type creation links off the content/add page would > > pretty much do it? > > http://drupal.org/node/28480 Okay, there's a lot there. I'll read it. what about simply removing the node/add page using menus module? that page > is often worthless anyway (as is the whole navigation block IMO). > That's a real option if you're not using the navigation block. If you are the "create content" link needs a destination. When I get less busy I may code a patch for those three points I mentioned. I can think of uses for it. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051119/b7974e1a/attachment.htm From jareyero at wanadoo.es Sat Nov 19 18:31:45 2005 From: jareyero at wanadoo.es (Jose A. Reyero) Date: Sat Nov 19 18:32:00 2005 Subject: [development] One core, many distributions Message-ID: <437F6F91.40600@wanadoo.es> Well, I was writing this as a reply to a reply to the previous 'Encouraging collaboration' thread, but it's grown too big, so sorry, but I want to open a new thread. A "great developer platform" is how I see Drupal, and I'm sure most of the developers too. But the thing is: we need some focus, some targets to agree on. The problem is: currently we are pretending Drupal -core- to be too many things at the same time, mostly that great developer platform (1), but also an out of the box ready to use community portal (2) or kind of that. And the consequence is we are handling too many issues when fixing bugs for 'Drupal core' that are too specific of some more 'user level, site specific' modules. The main point is core shouldn't need to be an out of the box nice site* that anyone can use, and we need to jump in the one core, many distributions idea for that. And that need to be an out of the box nice site is actually consuming far more effort than what could be a proper CMS core. IMHO we are wasting efforts in some higher level modules, that should be more focused to get what is properly the core system working right in the first place. And I'm not making any judgement about which modules should be in core and which ones not. I mean,, ok to have a few nice modules in core, but when a module grows too much, because people wants all that nice features, and them to be easy to set up, we can a) move it out of 'core' or b) provide a basic one in core that can be extended by a contrib module. Just as an example -and I have nothing against forum module: At some point, we are duplicating the taxonomy interface to handle a forum specific vocabulary. Then, this causes some bug -like this one, again just an example: http://drupal.org/node/24274 -, and then we have a core bug, module specific, but as it is a core module, this one has the same importance -in the bug tracking system- as any other critical bug -like a basic API not working properly. Notice that on one side we have a very big module in core to handle forums, but on the other side we don't have an small one for what could be a badly needed feature for other modules to build upon: a basic image node module. -again just an example, but I'm not talking about forum vs image at all. And as a side effect... How many modules you need to patch for what could be a small 'core patch' -if core was smaller- before your patch can be even considered because you can say at least 'it applys to HEAD' ?? And how many modules you need to re-patch again because of a minimum detail has changed in the main core patch during the follow up on the issue tracker? So I want to insist on the idea of "many distributions to serve different sites, one core to serve them all" --nice 'mantra', isn't it? ;-) But, anyway, that's an old idea. Just look at Linux.... Could you install 'Linux' --properly understood as the core OS- and pretend you have a nice OS ready to play with your computer? Cheers, Jose -- Jose A. Reyero http://www.reyero.net From karoly at negyesi.net Sat Nov 19 18:52:17 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Sat Nov 19 18:48:39 2005 Subject: [development] One core, many distributions In-Reply-To: <437F6F91.40600@wanadoo.es> References: <437F6F91.40600@wanadoo.es> Message-ID: > The problem is: currently we are pretending Drupal -core- to be too many > things at the same time, mostly that great developer platform (1), but > also an out of the box ready to use community portal (2) or kind of > that. And the consequence is we are handling too many issues when fixing > bugs for 'Drupal core' that are too specific of some more 'user level, > site specific' modules. Without a doubt, blog or aggregator is not the same level of functionality as node or taxonomy not to mention the required modules. Here is a proposed core set: block comment filter help locale (because this lets you change strings so its always useful) menu node path search story system taxonomy throttle upload user watchdog (hope I have not missed any required ones :) ) Regards NK From adrian at bryght.com Sat Nov 19 19:14:48 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Sat Nov 19 19:15:00 2005 Subject: [development] One core, many distributions In-Reply-To: <437F6F91.40600@wanadoo.es> References: <437F6F91.40600@wanadoo.es> Message-ID: <30BE7FE5-2125-44B4-BF7E-C8BDB2BB9697@bryght.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19 Nov 2005, at 8:31 PM, Jose A. Reyero wrote: > Well, I was writing this as a reply to a reply to the previous > 'Encouraging collaboration' thread, but it's grown too big, so sorry, > but I want to open a new thread. > > A "great developer platform" is how I see Drupal, and I'm sure most of > the developers too. But the thing is: we need some focus, some targets > to agree on. The install system makes provisions for this. You can create virtual packages, which have no actual modules / code of their own except for depending on other packages and having some configuration and possibly an installation wizard. When I said that the forms api is a key component of the install system, I wasn't joking. The new form api (only in 4.8 though. the 4.7 forms api is only phase one) will allow us to record macros, (ie: record all the forms you fill in), and create install profiles programmatically. It will also be possible to auto-create configuration wizards from these recorded macros, as wizards are just macros that have configurable values. I have a feeling we might even be able to clear up some of our menu mess. > Just as an example -and I have nothing against forum module: At some > point, we are duplicating the taxonomy interface to handle a forum > specific vocabulary. Then, this causes some bug -like this one, again > just an example: http://drupal.org/node/24274 -, and then we have a > core bug, module specific, but as it is a core module, this one > has > the same importance -in the bug tracking system- as any other critical > bug -like a basic API not working properly. I would like to see the relationship API take over forum, taxonomy and book. So we have one system instead of all these disparate implementations of the same thing. The same with the aggregator module which implements it's own node system, and taxonomy. The same with the project module which implements it's own comment system and taxonomy system. Whenever we need to implement something like this, it means our core system isn't flexible enough. And you have it wrong. The Drupal mantra is 'we should write an API for that' > But, anyway, that's an old idea. Just look at Linux.... Could you > install 'Linux' --properly understood as the core OS- and pretend you > have a nice OS ready to play with your computer? I'd love to see core only be a handful of modules, but I really don't see it being an option before the install system is finished. Once 4.7 is out, I'm going to be putting together the DEP's for the rest of the install system, so we can discuss them (I actually have started writing my first DEP, it's just kind of hard since I don't have a format to follow, I am just playing it all by ear.) - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDf3mogegMqdGlkasRAs2UAJwNIEJenhnSL/mlEZlVdJ0WiD9VlACeNjj2 8PGqFYN8FF3OJIJzywWwT0A= =C3Xd -----END PGP SIGNATURE----- From larry at garfieldtech.com Sat Nov 19 19:29:23 2005 From: larry at garfieldtech.com (Larry Garfield) Date: Sat Nov 19 19:29:31 2005 Subject: [development] One core, many distributions In-Reply-To: <437F6F91.40600@wanadoo.es> References: <437F6F91.40600@wanadoo.es> Message-ID: <200511191329.23948.larry@garfieldtech.com> I see two separate issues here, actually. 1) Is Drupal a developer platform, a CMS, or both? I see no reason why it can't be both, personally. I also don't like the "Core and derivative systems" model. That will very likely result in "The Debian Problem", vis, the mainline system takes so long for anything to happen that you get fragmented derived distributions that are "mostly compatible" and also have added administrative overhead to keep them in sync. (I say this as a Debian Sid user. ) That's not a good thing. As a developer platform, it should encourage developers to build drop-in modules that can make it do whatever they want. That's what we do now (although some parts could be done better, which is the point of most discussion on this list ). Easily-interchangeable modules ALSO allows for a good user-CMS, because then the user can mix and match modules without having to worry about code. If the module isn't at that point, then the developer's job is not done. (And yes, I am speaking as a web developer.) 2) There's too many modules in core. Hey, I won't disagree with you there. :-) I've no use for most of the modules in core by default. At the same time, though, contrib is, as others have pointed out, not always reliable. There's overlap, modules are unmaintained, there's no vetting of a module or a developer before code gets in or gets flagged ready for a given release, etc. So how do I know WHICH method of image handling to use? (To date I've used inline and upload rather than image, because I've not figured image out. I'm sure there's a usability lesson in there somewhere.) My recommendation would be to have another "level" of modules, "endorsed" (or something less stupid sounding). First, strip the core shipped modules down to a minimum: the required modules, throttle, taxonomy, path, menu, upload, comment, image, page (the one node type), and possibly xml-rpc. (The exact list is subject to debate, of course.) That creates a core system that is lean, mean, but still functional for a basic bunch-of-pages site. Then, create an online "Download and install from archive" function, as others have said is slowly in the works, that lists only "endorsed" modules. forum, blog, email-this-page (or one of the dozen versions of it), story, many of the taxonomy_ modules, etc. A module only gets into the "endorsed" archive by meeting a certain level of stability, up-to-date-ness, having an active maintainer (which could be "the Drupal core team" like many are now), being sufficiently generally useful that more than one or two sites would need it, etc. They would not necessarily have to meet the same schedule as core, however. That way, core's stability is easier to maintain since there's less code, which also reduces the workload for big changes like the forms API. (Speaking of which, great job guys!!) It also encourages more modular, no-I-can't-take-that-hacky-shortcut design for the endorsed modules. It could also allow a larger selection of easily-available modules (categorized?), which in turn would, hopefully, reduce the amount of duplication that goes on because people simply don't know a module is there. (See also: email-this-page, tellafriend, etc.) A new version of core would require only a fraction of endorsed to be fully rock solid before it's released, though, say 1/3 or 1/2. The rest can be updated in the few weeks after launch. The "contrib" archive would remain the "someone thought this might be useful" dumping ground, and endorsed modules would start there before being brought up to the major leagues, but would not get any special billing the way endorsed modules would. Endorsed modules would be addressed by the docs team, but the big mass of contrib would not. This way, we have a lot more flexibility and modularity of the development process, improve the user experience for Joe User, don't alienate Peter Power user (this is the most important group!), and still allow Dan Developer free reign in contrib. OK, enough of me talking. :-) Any thoughts? On Saturday 19 November 2005 12:31 pm, Jose A. Reyero wrote: > Well, I was writing this as a reply to a reply to the previous > 'Encouraging collaboration' thread, but it's grown too big, so sorry, > but I want to open a new thread. > > A "great developer platform" is how I see Drupal, and I'm sure most of > the developers too. But the thing is: we need some focus, some targets > to agree on. > > The problem is: currently we are pretending Drupal -core- to be too many > things at the same time, mostly that great developer platform (1), but > also an out of the box ready to use community portal (2) or kind of > that. And the consequence is we are handling too many issues when fixing > bugs for 'Drupal core' that are too specific of some more 'user level, > site specific' modules. > > The main point is core shouldn't need to be an out of the box nice > site that anyone can use, and we need to jump in the one core, many > distributions idea for that. And that need to be an out of the box nice > site is actually consuming far more effort than what could be a proper > CMS core. > > IMHO we are wasting efforts in some higher level modules, that should be > more focused to get what is properly the core system working right in > the first place. And I'm not making any judgement about which modules > should be in core and which ones not. I mean,, ok to have a few nice > modules in core, but when a module grows too much, because people wants > all that nice features, and them to be easy to set up, we can a) move it > out of 'core' or b) provide a basic one in core that can be extended by > a contrib module. > > Just as an example -and I have nothing against forum module: At some > point, we are duplicating the taxonomy interface to handle a forum > specific vocabulary. Then, this causes some bug -like this one, again > just an example: http://drupal.org/node/24274 -, and then we have a > core bug, module specific, but as it is a core module, this one has > the same importance -in the bug tracking system- as any other critical > bug -like a basic API not working properly. > > Notice that on one side we have a very big module in core to handle > forums, but on the other side we don't have an small one for what could > be a badly needed feature for other modules to build upon: a basic image > node module. -again just an example, but I'm not talking about forum vs > image at all. > > And as a side effect... How many modules you need to patch for what > could be a small 'core patch' -if core was smaller- before your patch > can be even considered because you can say at least 'it applys to HEAD' > ?? And how many modules you need to re-patch again because of a minimum > detail has changed in the main core patch during the follow up on the > issue tracker? > > So I want to insist on the idea of "many distributions to serve > different sites, one core to serve them all" --nice 'mantra', isn't it? ;-) > > But, anyway, that's an old idea. Just look at Linux.... Could you > install 'Linux' --properly understood as the core OS- and pretend you > have a nice OS ready to play with your computer? > > Cheers, > > Jose -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson From larry at garfieldtech.com Sat Nov 19 19:33:29 2005 From: larry at garfieldtech.com (Larry Garfield) Date: Sat Nov 19 19:33:38 2005 Subject: [development] One core, many distributions In-Reply-To: References: <437F6F91.40600@wanadoo.es> Message-ID: <200511191333.29851.larry@garfieldtech.com> OK, I like Karoly's list of core minimum modules a lot better than mine. :-) I'd recommend using page as the stock nodetype rather than story, but otherwise yeah, this is the core list, not the one on my email. :-) On Saturday 19 November 2005 12:52 pm, Karoly Negyesi wrote: > Without a doubt, blog or aggregator is not the same level of functionality > as node or taxonomy not to mention the required modules. > > Here is a proposed core set: > > block > comment > filter > help > locale (because this lets you change strings so its always useful) > menu > node > path > search > story > system > taxonomy > throttle > upload > user > watchdog > > (hope I have not missed any required ones :) ) > > Regards > > NK -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson From ber at webschuur.com Sat Nov 19 19:51:12 2005 From: ber at webschuur.com (=?utf-8?q?B=C3=A8r_Kessels?=) Date: Sat Nov 19 19:51:12 2005 Subject: [development] One core, many distributions In-Reply-To: <200511191333.29851.larry@garfieldtech.com> References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> Message-ID: <200511192051.13259.ber@webschuur.com> Yup great one, again, Charlie! I love the fact satistics is not there; I would say path has to go too (in favour of a more complete, pathauto combination, lliving in contribs) Op zaterdag 19 november 2005 20:33, schreef Larry Garfield: > OK, I like Karoly's list of core minimum modules a lot better than mine. > :-) I'd recommend using page as the stock nodetype rather than story, but > otherwise yeah, this is the core list, not the one on my email. :-) > > On Saturday 19 November 2005 12:52 pm, Karoly Negyesi wrote: > > Without a doubt, blog or aggregator is not the same level of > > functionality as node or taxonomy not to mention the required modules. > > > > Here is a proposed core set: > > > > block > > comment > > filter > > help > > locale (because this lets you change strings so its always useful) > > menu > > node > > path > > search > > story > > system > > taxonomy > > throttle > > upload > > user > > watchdog > > > > (hope I have not missed any required ones :) ) > > > > Regards > > > > NK B?r -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20051119/c493355e/attachment.pgp From adrian at bryght.com Sat Nov 19 19:54:03 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Sat Nov 19 19:54:15 2005 Subject: [development] One core, many distributions In-Reply-To: <200511191329.23948.larry@garfieldtech.com> References: <437F6F91.40600@wanadoo.es> <200511191329.23948.larry@garfieldtech.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19 Nov 2005, at 9:29 PM, Larry Garfield wrote: > My recommendation would be to have another "level" of modules, > "endorsed" (or > something less stupid sounding). First, strip the core shipped > modules down > to a minimum: the required modules, throttle, taxonomy, path, menu, > upload, > comment, image, page (the one node type), and possibly xml-rpc. > (The exact > list is subject to debate, of course.) That creates a core system > that is > lean, mean, but still functional for a basic bunch-of-pages site. This is one of the things I've wanted to do forever. I would like to see separate repositories too, with stricter security review rules and a group of commiters, with their own assigned modules/tasks. Essentially so that we can implement a code signing system that is required before we allow modules to be downloaded to their machines via the install system, and only allow them to get other modules which haven't matured enough yet, if they physically edit a very big warning laden file. The same file would have an option to disable all traces of internet downloading from the system, to allow for closed systems. And i believe the default node module included, should be content.module, or more pointedly. CCK. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDf4LcgegMqdGlkasRAoh7AJ4iwpgFPgsp1vCeO5ORz8MQaBgn2ACeMIE+ UO12dMRU4YLLkJRfn6UPwUI= =YC0p -----END PGP SIGNATURE----- From adrian at bryght.com Sat Nov 19 19:56:27 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Sat Nov 19 19:56:35 2005 Subject: [development] One core, many distributions In-Reply-To: <200511191333.29851.larry@garfieldtech.com> References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> Message-ID: <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19 Nov 2005, at 9:33 PM, Larry Garfield wrote: >> path I agree, but I believe that pathauto like functionality should be part of our default install, and we should emphasise it. It's one of our more powerful features, and the improvements in usabilty and browsability are amazing. Plus google loves you much much much more. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDf4NrgegMqdGlkasRAjiCAKDUArqbsVsS22qKTNYJy2YZqw+lPgCgiZlz 3fHwmUKLRNcZlOOgdbrAdLo= =TK/S -----END PGP SIGNATURE----- From jeff at viapositiva.net Sat Nov 19 19:58:19 2005 From: jeff at viapositiva.net (Jeff Eaton) Date: Sat Nov 19 19:58:26 2005 Subject: [development] One core, many distributions In-Reply-To: <200511192051.13259.ber@webschuur.com> Message-ID: <001a01c5ed43$99813260$0300a8c0@mjolnir> Interesting that you'd mention that. Pathauto currently has some unpleasant snafus (goofy things happen when your rules generate the same alias for an 'index' and a taxonomy term, for example)... but the combination of path and pathauto are so essential that I can't imagine any site not wanting to use them. -----Original Message----- From: B?r Kessels [mailto:ber@webschuur.com] Sent: Saturday, November 19, 2005 1:51 PM To: development@drupal.org Subject: Re: [development] One core, many distributions Yup great one, again, Charlie! I love the fact satistics is not there; I would say path has to go too (in favour of a more complete, pathauto combination, lliving in contribs) From larry at garfieldtech.com Sat Nov 19 20:17:42 2005 From: larry at garfieldtech.com (Larry Garfield) Date: Sat Nov 19 20:18:46 2005 Subject: [development] One core, many distributions In-Reply-To: <001a01c5ed43$99813260$0300a8c0@mjolnir> References: <001a01c5ed43$99813260$0300a8c0@mjolnir> Message-ID: <200511191417.42162.larry@garfieldtech.com> I've only toyed with pathauto a little, but found it a bit quirky. It liked to put '0' at the end of names, and the underscores in names is highly ugly. I'm also not overjoyed about the visable path list suddenly becoming gigantic. If I have 1000 users, do I REALLY want 1000 visable path aliases listed in admin/path? I don't. :-) Either way, I think we can all agree that a "human-friendly URL-making thingie module" should be one of the reduced core modules, whichever it ends up being. That's something to deal with later. On Saturday 19 November 2005 01:58 pm, Jeff Eaton wrote: > Interesting that you'd mention that. Pathauto currently has some > unpleasant snafus (goofy things happen when your rules generate the same > alias for an 'index' and a taxonomy term, for example)... but the > combination of path and pathauto are so essential that I can't imagine > any site not wanting to use them. > > -----Original Message----- > From: B?r Kessels [mailto:ber@webschuur.com] > Sent: Saturday, November 19, 2005 1:51 PM > To: development@drupal.org > Subject: Re: [development] One core, many distributions > > > Yup great one, again, Charlie! > > I love the fact satistics is not there; > I would say path has to go too (in favour of a more complete, pathauto > combination, lliving in contribs) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson From jareyero at wanadoo.es Sat Nov 19 20:22:40 2005 From: jareyero at wanadoo.es (Jose A. Reyero) Date: Sat Nov 19 20:22:56 2005 Subject: [development] Encouraging Collaboration In-Reply-To: <437E04AA.7000406@civicactions.com> References: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> <437E04AA.7000406@civicactions.com> Message-ID: <437F8990.4080102@wanadoo.es> Dan Robinson wrote: >2) Core vs. Contrib - This pattern seems to be mainly about general vs. >specific - but it is also about quality vs. quantity. It seems that >quality vs. quantity needs more attention. >3) Who is this product for? Drupal is a very mature product - but it >seems like it hasn't grown up yet :) - which is kinda cool - and kinda >infuriating. I think that there needs to be a better definition of who >this product is for - is it for the people who spend most of their time >developing/contributing to it? Is it for web developers? Is it for >webmasters? Is it for end-users? > I'd say "Drupal is for everybody"...but what I think needs some definition is the concept of "Drupal", "Drupal core" and who/what it is for... Then we can build on that, maybe having some distributions. I've post some other e-mail abt core vs. distributions.. Actually I'd point all new users who have trouble setting up Drupal, directly to CivicSpace -which I do sometimes :-) But in general, we should build upon the idea of 'distributions' better than 'making Drupal core user friendly' >4) How do things get done around here? The only sure way to do anything >is to do it yourself - which is fine - but it limits participation (see >3 above). There are a bunch of different possible solutions to any >given problem (like the one pointed out in Allie's email). However >without a roadmap it is difficult to know which way to go. > > > Yes, a roadmap would be great. And some more organization and coordination too -but not too much :-). Actually there's been a number of posts lately about how we could better organize ourselves. >Here are some specific things that might work to solve this problem - > >1) Right now there are three module categories -> core, modules, >sandbox. Perhaps there should be another? "community modules" - being >stuff that the "community" endorses? Perhaps by a straight up or down >vote of contributors? I know this is radical. > > > I'd like to have: - core: minimum cms engine with few basic modules - standard modules: a few more than the ones that are currently in core, but these must be the ones maintanined by core developers with 'core quality' - contributed modules: all the rest (and same for themes) As you can see, my idea is not based on ratings -which would be nice to have anyway- , but on who with which standards maintains it. IMHO ratings provided by users are too prone to put features before quality and stability. >2) There could be a "reviews" blog attached directly to each module - >I'm sure this is an old discussion - sorry for bringing it up again. I >would love to see Allie's notes from her investigation of the "Amazon" >modules so I knew what was in and not in each module. > > Let?s bring it up again and again until its there :-) I haven't used too much the 'project module' but my question is: as 'projects' seem to be nodes, is it that difficult to enable comments -call it reviews- on them? From jareyero at wanadoo.es Sat Nov 19 20:25:00 2005 From: jareyero at wanadoo.es (Jose A. Reyero) Date: Sat Nov 19 20:25:21 2005 Subject: [development] One core, many distributions In-Reply-To: <200511192051.13259.ber@webschuur.com> References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <200511192051.13259.ber@webschuur.com> Message-ID: <437F8A1C.1080305@wanadoo.es> Well, I didn't want to start a discussion about which modules should be in core, and which ones shouldn't. But it seems I did anyway :-( B?r Kessels wrote: >Yup great one, again, Charlie! > >I love the fact satistics is not there; >I would say path has to go too (in favour of a more complete, pathauto >combination, lliving in contribs) > > >Op zaterdag 19 november 2005 20:33, schreef Larry Garfield: > > >>OK, I like Karoly's list of core minimum modules a lot better than mine. >>:-) I'd recommend using page as the stock nodetype rather than story, but >>otherwise yeah, this is the core list, not the one on my email. :-) >> >>On Saturday 19 November 2005 12:52 pm, Karoly Negyesi wrote: >> >> >>>Without a doubt, blog or aggregator is not the same level of >>>functionality as node or taxonomy not to mention the required modules. >>> >>>Here is a proposed core set: >>> >>>block >>>comment >>>filter >>>help >>>locale (because this lets you change strings so its always useful) >>>menu >>>node >>>path >>>search >>>story >>>system >>>taxonomy >>>throttle >>>upload >>>user >>>watchdog >>> >>>(hope I have not missed any required ones :) ) >>> >>>Regards >>> >>>NK >>> >>> > B?r > > From ber at webschuur.com Sat Nov 19 20:48:18 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Sat Nov 19 20:48:24 2005 Subject: [development] Encouraging Collaboration In-Reply-To: <437F8990.4080102@wanadoo.es> References: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> <437E04AA.7000406@civicactions.com> <437F8990.4080102@wanadoo.es> Message-ID: <200511192148.25857.ber@webschuur.com> Op zaterdag 19 november 2005 21:22, schreef Jose A. Reyero: > IMHO ratings provided by users ?are too prone to put features before > quality and stability. This, is a very interesting idea. currently, IMO, Drupal is so stable, and solid, because we /don't/ have a rating system for core. In the same time, Drupal contribs range from awfull to great yet are in the same place. I think a (technically) worked out idea for this "second contrib" thing is great. I volunteer for joining some folks to get that going. Anyone else? B?r -- | B?r Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20051119/26447776/attachment.pgp From jareyero at wanadoo.es Sat Nov 19 20:56:41 2005 From: jareyero at wanadoo.es (Jose A. Reyero) Date: Sat Nov 19 20:56:55 2005 Subject: [development] One core, many distributions In-Reply-To: <30BE7FE5-2125-44B4-BF7E-C8BDB2BB9697@bryght.com> References: <437F6F91.40600@wanadoo.es> <30BE7FE5-2125-44B4-BF7E-C8BDB2BB9697@bryght.com> Message-ID: <437F9189.1070407@wanadoo.es> Adrian Rossouw wrote: > > The install system makes provisions for this. > > You can create virtual packages, which have no actual modules / code > of their > own except for depending on other packages and having some configuration > and possibly an installation wizard. > That's great! > When I said that the forms api is a key component of the install > system, I wasn't joking. > > The new form api (only in 4.8 though. the 4.7 forms api is only phase > one) > will allow us to record macros, (ie: record all the forms you fill > in), and create install profiles > programmatically. It will also be possible to auto-create > configuration wizards from > these recorded macros, as wizards are just macros that have > configurable values. > You're scaring me a little bit ;-) > I have a feeling we might even be able to clear up some of our menu mess. > > >> Just as an example -and I have nothing against forum module: At some > >> point, we are duplicating the taxonomy interface to handle a forum > >> specific vocabulary. Then, this causes some bug -like this one, again > >> just an example: http://drupal.org/node/24274 -, and then we have a > >> core bug, module specific, but as it is a core module, this > one has > >> the same importance -in the bug tracking system- as any other critical > >> bug -like a basic API not working properly. > > I would like to see the relationship API take over forum, taxonomy > and book. > So we have one system instead of all these disparate implementations > of the same thing. > > The same with the aggregator module which implements it's own node > system, > and taxonomy. > > The same with the project module which implements it's own comment system > and taxonomy system. > > Whenever we need to implement something like this, it means our core > system isn't > flexible enough. Well, I think our core system is flexible enough -because all that implementations don't need to patch the basic taxonomy system. Only that our core system 'is not user friendly enough' but it shouldn't have to be that anyway. It's the whole thing of 'Flexibility/options' vs 'usability for end users' > > And you have it wrong. > > The Drupal mantra is 'we should write an API for that' > Ok, we should write an API for having one smaller core and may distributions :-) > > > >> But, anyway, that's an old idea. Just look at Linux.... Could you > >> install 'Linux' --properly understood as the core OS- and pretend you > >> have a nice OS ready to play with your computer? > > > I'd love to see core only be a handful of modules, but I really don't > see it being an option before > the install system is finished. Once 4.7 is out, I'm going to be > putting together the DEP's for the > rest of the install system, so we can discuss them (I actually have > started writing my first DEP, it's > just kind of hard since I don't have a format to follow, I am just > playing it all by ear.) > Well, me too. I want to see Drupal 4.7 out. I din't mean changing anything now, but start thinking about it before it grows more and more. What worries me is that, at the end, we may have that install system with a lot of profiles in core too, so it will grow bigger after all :-( I have some DEP in mind too, but I'll wait to see your DEP first. Btw, did you know that 'DEP' is Spanish for 'RIP', --Anyway I'm not superstitious and see a good future por DEPs ;-) > > > -- > Adrian Rossouw > Drupal developer and Bryght Guy > http://drupal.org | http://bryght.com > > From fabio.varesano at gmail.com Sat Nov 19 21:59:04 2005 From: fabio.varesano at gmail.com (Fabio Varesano) Date: Sat Nov 19 20:58:50 2005 Subject: [development] cvs commit of a 4.6 module when cvs main is going for 4.7 Message-ID: <437FA028.1060903@gmail.com> Hi everybody! I'm the maintainer of video.module . We have realeased a good 4.6 video.module then the past weeks worked hard for the new 4.7 version (MAIN). Now we have a patch for a bug in the 4.6 branch but I'm not able to submit it to the 4.6 branch I tried it but not luky with cvs... I'm getting: cvs commit: sticky tag `DRUPAL-4-6' for file `video.module' is not a branch Does someone could explain how can I do it? Thanks Fabio From jareyero at wanadoo.es Sat Nov 19 20:58:57 2005 From: jareyero at wanadoo.es (Jose A. Reyero) Date: Sat Nov 19 20:59:11 2005 Subject: [development] One core, many distributions In-Reply-To: References: <437F6F91.40600@wanadoo.es> <200511191329.23948.larry@garfieldtech.com> Message-ID: <437F9211.8000309@wanadoo.es> Like this? - copy & paste from another email I've just sent What I'd like to have: - core: minimum cms engine with few basic modules - standard modules: a few more than the ones that are currently in core, but these must be the ones maintanined by core developers with 'core quality' - contributed modules: all the rest (and same for themes) Adrian Rossouw wrote: > On 19 Nov 2005, at 9:29 PM, Larry Garfield wrote: > > >> My recommendation would be to have another "level" of modules, > "endorsed" (or > >> something less stupid sounding). First, strip the core shipped > modules down > >> to a minimum: the required modules, throttle, taxonomy, path, > menu, upload, > >> comment, image, page (the one node type), and possibly xml-rpc. > (The exact > >> list is subject to debate, of course.) That creates a core system > that is > >> lean, mean, but still functional for a basic bunch-of-pages site. > > This is one of the things I've wanted to do forever. > > I would like to see separate repositories too, with stricter security > review rules > and a group of commiters, with their own assigned modules/tasks. > Essentially > so that we can implement a code signing system that is required before we > allow modules to be downloaded to their machines via the install system, > and only allow them to get other modules which haven't matured enough > yet, if they physically > edit a very big warning laden file. > > The same file would have an option to disable all traces of internet > downloading from the system, > to allow for closed systems. > > And i believe the default node module included, should be content.module, > or more pointedly. CCK. > > > > > -- > Adrian Rossouw > Drupal developer and Bryght Guy > http://drupal.org | http://bryght.com > > From jareyero at wanadoo.es Sat Nov 19 21:02:22 2005 From: jareyero at wanadoo.es (Jose A. Reyero) Date: Sat Nov 19 21:02:33 2005 Subject: [development] One core, many distributions In-Reply-To: References: <437F6F91.40600@wanadoo.es> Message-ID: <437F92DE.7020209@wanadoo.es> Hi Charlie, I meant to discuss more on the 'core' concept than about which modules... But anyway I'd just propose some module that creates simple node types on the fly -only with a new name- I've heard of, but I haven't seen yet :-) -- Then we can drop story, page, blog.... Karoly Negyesi wrote: >> The problem is: currently we are pretending Drupal -core- to be too many >> things at the same time, mostly that great developer platform (1), but >> also an out of the box ready to use community portal (2) or kind of >> that. And the consequence is we are handling too many issues when fixing >> bugs for 'Drupal core' that are too specific of some more 'user level, >> site specific' modules. > > > Without a doubt, blog or aggregator is not the same level of > functionality as node or taxonomy not to mention the required modules. > > Here is a proposed core set: > > block > comment > filter > help > locale (because this lets you change strings so its always useful) > menu > node > path > search > story > system > taxonomy > throttle > upload > user > watchdog > > (hope I have not missed any required ones :) ) > > Regards > > NK > From jareyero at wanadoo.es Sat Nov 19 21:17:10 2005 From: jareyero at wanadoo.es (Jose A. Reyero) Date: Sat Nov 19 21:17:23 2005 Subject: [development] Encouraging Collaboration In-Reply-To: <200511192148.25857.ber@webschuur.com> References: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> <437E04AA.7000406@civicactions.com> <437F8990.4080102@wanadoo.es> <200511192148.25857.ber@webschuur.com> Message-ID: <437F9656.9020704@wanadoo.es> Well, this 'users like features vs. quality and stability' is actually an old story: It is the Windows vs. Linux saga. And guess which one is the more used? :-( So... do we want to become rich, like Bill Gates, or to produce a world class bullet proof system, like Linux/Linus ? ;-) Just joking.... I volunteer for that too :-) B?r Kessels wrote: >Op zaterdag 19 november 2005 21:22, schreef Jose A. Reyero: > > >>IMHO ratings provided by users are too prone to put features before >>quality and stability. >> >> > >This, is a very interesting idea. currently, IMO, Drupal is so stable, and >solid, because we /don't/ have a rating system for core. In the same time, >Drupal contribs range from awfull to great yet are in the same place. > >I think a (technically) worked out idea for this "second contrib" thing is >great. I volunteer for joining some folks to get that going. Anyone else? > > B?r > > From karoly at negyesi.net Sat Nov 19 21:41:40 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Sat Nov 19 21:38:06 2005 Subject: [development] One core, many distributions In-Reply-To: <437F92DE.7020209@wanadoo.es> References: <437F6F91.40600@wanadoo.es> <437F92DE.7020209@wanadoo.es> Message-ID: On Sat, 19 Nov 2005 22:02:22 +0100, Jose A. Reyero wrote: > Hi Charlie, > > I meant to discuss more on the 'core' concept than about which > modules... But anyway I'd just propose some module that creates simple > node types on the fly -only with a new name- I've heard of, but I > haven't seen yet :-) -- Then we can drop story, page, blog.... mmmm I had a simplenodes concept module, i think it's in the issue queue, for more complex stuff, we have cck. From drumm at delocalizedham.com Sat Nov 19 22:36:09 2005 From: drumm at delocalizedham.com (Neil Drumm) Date: Sat Nov 19 22:46:31 2005 Subject: [development] Node referencing In-Reply-To: References: <20a3038c0511160509g11d6a34ue0a500b301b925c9@mail.gmail.com> <437E7B15.1080303@nullcraft.org> <437F2240.8060807@tejasa.com> Message-ID: <437FA8D9.2020905@delocalizedham.com> Adrian Rossouw wrote: > 3) I am putting personal links (my account, my journal, my inbox (n) > etc.) into the secondary links, which are placed to the top right of > the header. [ anything that is personal space ] I'd like to keep the 'my account' and 'logout' links in the user login block for it's logged in state. Copies of these links would remain as suggested menu items. This would remove the need to put the username at the top of the standard navigation block, which would make a lot more sense for those who do use it. And the block title would actually be configurable, which it isn't now. -- Neil Drumm http://delocalizedham.com/ From adrian at bryght.com Sat Nov 19 22:52:33 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Sat Nov 19 22:52:42 2005 Subject: [development] Node referencing In-Reply-To: <437FA8D9.2020905@delocalizedham.com> References: <20a3038c0511160509g11d6a34ue0a500b301b925c9@mail.gmail.com> <437E7B15.1080303@nullcraft.org> <437F2240.8060807@tejasa.com> <437FA8D9.2020905@delocalizedham.com> Message-ID: <1F5D4197-F56F-4AD1-9704-A294EA641804@bryght.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20 Nov 2005, at 12:36 AM, Neil Drumm wrote: > Adrian Rossouw wrote: >> 3) I am putting personal links (my account, my journal, my inbox >> (n) etc.) into the secondary links, which are placed to the top >> right of the header. [ anything that is personal space ] > > I'd like to keep the 'my account' and 'logout' links in the user > login block for it's logged in state. Copies of these links would > remain as suggested menu items. What if you don't use the login block. I think a seperate menu for anything relating to the current user is all that's needed, but it can be placed wherever you want with regions (in the secondary links location, or in one of the sidebars for what you are looking for) - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDf6yygegMqdGlkasRAr4GAKCw/2wVGYLTSCTm13rF//t2bhc3GgCgqsdu kMSUjRmk6nqNkM8uMm4o/94= =4kot -----END PGP SIGNATURE----- From drumm at delocalizedham.com Sat Nov 19 22:42:24 2005 From: drumm at delocalizedham.com (Neil Drumm) Date: Sat Nov 19 22:52:47 2005 Subject: [development] Node referencing In-Reply-To: <437F2240.8060807@tejasa.com> References: <20a3038c0511160509g11d6a34ue0a500b301b925c9@mail.gmail.com> <437E7B15.1080303@nullcraft.org> <437F2240.8060807@tejasa.com> Message-ID: <437FAA50.2000808@delocalizedham.com> Moshe Weitzman wrote: > what about simply removing the node/add page using menus module? that > page is often worthless anyway (as is the whole navigation block IMO). I'd like to see a real draft state and other workflow things. The node/add page would be a good place to put a listing of unfinished posts, although it probably isn't the only possibility. (The workflow in core possibilities I'm thinking of are putting the workflow module in core in some form and removing as many of the existing checkboxes from node/add/... since they could be handled with workflow.) If we standardize local links to add nodes (such as the way you can create a forum topic when you are looking at the forum) I think the existing node/add page becomes unnecessary. -- Neil Drumm http://delocalizedham.com/ From dopry at thing.net Sun Nov 20 02:53:37 2005 From: dopry at thing.net (Darrel O'Pry) Date: Sun Nov 20 02:53:40 2005 Subject: [development] Node referencing In-Reply-To: <437E7B15.1080303@nullcraft.org> References: <20a3038c0511160509g11d6a34ue0a500b301b925c9@mail.gmail.com> <437E7B15.1080303@nullcraft.org> Message-ID: <1132455217.7818.16.camel@localhost.localdomain> On Fri, 2005-11-18 at 19:08 -0600, Mark wrote: > Sergio wrote: > > > Hello, folks, > > I'm in need of a little help... > > I have a module with 3 types of node. Node A, B and C. > > I am trying to do something like A is the main node and B & C > > references A. So that, when I show the node A (teaser or full node), I > > get some informations about nodes type B and C that makes reference to A. > > Also, I want to node types B and C have a reference to the parent (A). > > When the user inserts the data, it must be transparent to him as who > > the parent is (like there is a link on node type A that allows the > > user to create type B or C and the node creation page will not ask the > > user who the parent is). The only creation method shoud be like this > > for nodes B and C (there should not have a link on the node creation > > list. Just for type A) > > > > I took a look at the project module, but I couldn't get much out of > > it... > > Any help is appreciated... > > > > Thanks, > > - Luis Sergio Moura > > As others have mentioned, there are many modules out there that manage > node-to-node relationships. One thing that was a problem the last time > I looked was how to go about restricting access to node/add/[type that > requires parent]/[nid of parent] without other things breaking. > Previous discussions led me to override the menu settings to disallow > access to this path, but since the menu system does not prioritize it's > entries, you may find that your modification of the menu permissions > doesn't always work. The result is that the node/add page shows links > to add content that is not allowed to exist without a parent. The Node > Relativity module (http://drupal.org/node/17004) essentially does what > you're looking for, but hasn't been updated in a while. It is big and > needs some refactoring and is probably a heavier solution than you're > looking for, though. > > Regards, > -Mark Couldn't you handle checking for missing parents with hook_access? in the if $op == create if there isn't a parent, just theme a page stating a parent must exist to create this node, and exit? From gordon at heydon.com.au Sun Nov 20 03:49:32 2005 From: gordon at heydon.com.au (Gordon Heydon) Date: Sun Nov 20 03:49:27 2005 Subject: [development] SCM idea In-Reply-To: References: Message-ID: <1132458572.8014.208.camel@localhost.localdomain> Hi, On Fri, 2005-11-18 at 21:01 -0800, Steven Peck wrote: > Speaking as one of those using Windows primarily for reasons of work and games. I will note that I only care that tools are available for Windows users. CMD line or otherwise I don't care if they are GUI. If there are tons of switches, then I can make batch files with the switches preseelcted. > > As long as there are tools that run Windows, then I don't care. I only would like something to be selected so I can go about learning it. > > Whatever we pick, I plan on making my co-workers learn it so we can control our inhouse administative scripts at work and avoid learning more. As I am lazy, I plan on learning only one of them :). Darcs has a couple of windows versions. One which requires cygwin and one that doesn't. I have at a client site the darcsweb running on windows under IIS. This works great. I do not think bzr has a windows verison, but personally I have found the bzr/arch way of doing things hurts my head. Gordon. From scott at 4th.com Sun Nov 20 03:58:41 2005 From: scott at 4th.com (Syscrusher) Date: Sun Nov 20 03:58:55 2005 Subject: [development] cvs commit of a 4.6 module when cvs main is going for 4.7 In-Reply-To: <437FA028.1060903@gmail.com> References: <437FA028.1060903@gmail.com> Message-ID: <200511192258.41310.scott@4th.com> On Saturday 19 November 2005 16:59, Fabio Varesano wrote: > I tried it but not luky with cvs... I'm getting: > cvs commit: sticky tag `DRUPAL-4-6' for file `video.module' is not a branch > > Does someone could explain how can I do it? {CHUCKLE} I couldn't have helped you an hour ago, but I can now. I just ran across the same problem with one of my modules, and, using advice from the list archives, fixed it thusly: $ cd $YOUR_MODULE_DIRECTORY_FOR_4_6 $ cvs update # ... if you hadn't already done so $ cvs tag -b -F DRUPAL-4-6 $ cvs commit The problem is caused by by not having added "-b" when originally tagging the directory. Source of info: http://lists.drupal.org/archives/development/2005-04/msg01068.html Hope this helps. Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher From karoly at negyesi.net Sun Nov 20 05:59:14 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Sun Nov 20 05:55:29 2005 Subject: [development] SCM idea In-Reply-To: <1132458572.8014.208.camel@localhost.localdomain> References: <1132458572.8014.208.camel@localhost.localdomain> Message-ID: > I do not think bzr has a windows verison, but personally I have found > the bzr/arch way of doing things hurts my head. There is native and cygwin too. http://bazaar.canonical.com I think you should drop into irc and have a chat with jblack over those headaches. Regards NK From gordon at heydon.com.au Sun Nov 20 06:48:56 2005 From: gordon at heydon.com.au (Gordon Heydon) Date: Sun Nov 20 06:48:51 2005 Subject: [development] SCM idea In-Reply-To: References: <1132458572.8014.208.camel@localhost.localdomain> Message-ID: <1132469336.7489.7.camel@localhost.localdomain> Hi, On Sun, 2005-11-20 at 06:59 +0100, Karoly Negyesi wrote: > > I do not think bzr has a windows verison, but personally I have found > > the bzr/arch way of doing things hurts my head. > > There is native and cygwin too. > > http://bazaar.canonical.com It has been a while since I looked. I know that I looked after the talk from Martin Pool at lca, but I there was only version 1 which was the python version. > I think you should drop into irc and have a chat with jblack over those > headaches. I might do that some time. Gordon. From dopry at thing.net Sun Nov 20 06:52:53 2005 From: dopry at thing.net (Darrel O'Pry) Date: Sun Nov 20 06:52:58 2005 Subject: [development] SCM idea In-Reply-To: <1132469336.7489.7.camel@localhost.localdomain> References: <1132458572.8014.208.camel@localhost.localdomain> <1132469336.7489.7.camel@localhost.localdomain> Message-ID: <1132469574.7818.19.camel@localhost.localdomain> On Sun, 2005-11-20 at 17:48 +1100, Gordon Heydon wrote: > Hi, > > On Sun, 2005-11-20 at 06:59 +0100, Karoly Negyesi wrote: > > > I do not think bzr has a windows verison, but personally I have found > > > the bzr/arch way of doing things hurts my head. > > > > There is native and cygwin too. > > > > http://bazaar.canonical.com > > It has been a while since I looked. I know that I looked after the talk > from Martin Pool at lca, but I there was only version 1 which was the > python version. > > > I think you should drop into irc and have a chat with jblack over those > > headaches. > > I might do that some time. > > Gordon. > > > he's there working on windows now. From ber at webschuur.com Sun Nov 20 08:32:49 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Sun Nov 20 08:32:52 2005 Subject: [development] Node referencing In-Reply-To: <1F5D4197-F56F-4AD1-9704-A294EA641804@bryght.com> References: <20a3038c0511160509g11d6a34ue0a500b301b925c9@mail.gmail.com> <437FA8D9.2020905@delocalizedham.com> <1F5D4197-F56F-4AD1-9704-A294EA641804@bryght.com> Message-ID: <200511200932.54924.ber@webschuur.com> http://dev.bryght.com/t/wiki/RestructureDrupal is still there. I got there after testing a few different menu structures with several clients. This one seemed most logaical to all. The "Configure Note 2 my profile (my subscriptions)" Part is where all the personal settings go. It is a top level menu entry, but can be made into a separate block very easy. All the top level items can. Ber Op zaterdag 19 november 2005 23:52, schreef Adrian Rossouw: > On 20 Nov 2005, at 12:36 AM, Neil Drumm wrote: > > Adrian Rossouw wrote: > >> 3) I am putting personal links (my account, my journal, my inbox > >> (n) etc.) into the secondary links, which are placed to the top > >> right of the header. [ anything that is personal space ] > > > > I'd like to keep the 'my account' and 'logout' links in the user > > login block for it's logged in state. Copies of these links would > > remain as suggested menu items. > > What if you don't use the login block. > > I think a seperate menu for anything relating to the current user is > all that's needed, but it can be placed wherever you want with > regions (in the secondary links location, or in one of the sidebars > for what you are looking for) B?r -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20051120/b93c852d/attachment.pgp From drupal at dave-cohen.com Sun Nov 20 15:30:36 2005 From: drupal at dave-cohen.com (Dave Cohen) Date: Sun Nov 20 15:31:33 2005 Subject: [development] requesting CVS account again Message-ID: <200511200730.36657.drupal@dave-cohen.com> A while back I requested a CVS account to contribute a new module. My request was denied for perfectly reasonable reasons. Today I tried to request again, proposing a new module. After I hit "Request CVS account", I got an error: "You already requested/have a CVS account." So.... Can I make a second request? -Dave From gerhard at killesreiter.de Sun Nov 20 16:08:37 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Sun Nov 20 16:10:17 2005 Subject: [development] requesting CVS account again In-Reply-To: <200511200730.36657.drupal@dave-cohen.com> References: <200511200730.36657.drupal@dave-cohen.com> Message-ID: <43809F85.8010802@killesreiter.de> Dave Cohen wrote: >A while back I requested a CVS account to contribute a new module. My request >was denied for perfectly reasonable reasons. > >Today I tried to request again, proposing a new module. After I hit "Request >CVS account", I got an error: "You already requested/have a CVS account." > >So.... Can I make a second request? > > > Just mail it to me, including your drupal.org ID. I hope you can remember the password you chose the first time... Cheers, Gerhard From ber at webschuur.com Sun Nov 20 16:14:01 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Sun Nov 20 16:13:59 2005 Subject: [development] Help with getting CVS HEAD -> DRUPAL-4-6 [CivicSpace Theme] In-Reply-To: <99469d070511172149v4bd293dbh@mail.gmail.com> References: <1132237213.29228.23.camel@localhost.localdomain> <200511171703.38815.ber@webschuur.com> <99469d070511172149v4bd293dbh@mail.gmail.com> Message-ID: <200511201714.01784.ber@webschuur.com> Op vrijdag 18 november 2005 06:49, schreef Gildas COTOMALE: > Not a great idea. > It's always good to have README.txt, INSTALL.txt, UPGRADE.txt and so > with a module or a Drupal core. Keeping them in CVS allow > updating'em... In another hand, don't forget that every body is not > always connected to the net.. > This apply to the translations to... I was not referring to INSTALL README and so, sorry. Should have made that clear. I only meant the docs in the root of contribs: -rw-r--r-- 1 berub berub 7,7K 2005-11-07 00:00 CODING_STANDARDS.html -rwxr--r-x 1 berub berub 3,8K 2005-04-01 14:39 FAQ.txt -rw-r--r-- 1 berub berub 15K 2005-04-01 14:39 LICENSE.txt -rwxr--r-x 1 berub berub 2,9K 2005-04-01 14:39 README.txt -rw-r--r-- 1 berub berub 4,6K 2005-04-01 14:39 TERMS.txt B?r -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20051120/9107bd05/attachment.pgp From rob at web.ca Sun Nov 20 18:35:02 2005 From: rob at web.ca (Rob Ellis) Date: Sun Nov 20 18:35:05 2005 Subject: [development] Another translation module Message-ID: <20051120183502.GA46384@web.ca> I just added yet another content translation module to CVS: contributions/modules/tr Apologies about the name, but 'translation' is already taken, and I couldn't think of something short-but-meaningful to use instead... 'tr' was used for development, so I just left it as that. The module is a recent complete rewrite of something that was developed early this year for the Canadian New Democratic Party web site (www.ndp.ca). At the time, we had requirements that the existing i18n module didn't meet, and I wasn't aware of the contributed 'translation' module. The 'tr' module in it's current incarnation is being used by my former employer for several sites, in french and english, english and inuktitut, and french and english and inuktitut... They're finding it useful. Some features are: - content switching based on language - language switching based on hostname or url-path-prefix or ?l=xx - per node 'translate' links for untranslated content - per language 'edit' links for existing translations - generated translation links for use in templates - custom 404 page for missing translations (optional -- will show untranslated content otherwise) - admin node list filtered by language or "untranslated" - translated taxonomy term names - translated menu item titles It's a little sketchy in places, and it requires patches to the Drupal core, but small ones. The patches at the moment are for DRUPAL-4-6-3. At least it might be interesting for people working on similar content translation schemes, and some people might find it useful as is. I'm not sure about how to tag this initial import -- since the patches are for DRUPAL-4-6-3, I thought branching it for 4.6.3 would be the thing to do, but I'm not sure. Help, comments would be appreciated. Thanks. - Rob -- Rob Ellis From mcsparkerton at yahoo.co.uk Sun Nov 20 21:21:58 2005 From: mcsparkerton at yahoo.co.uk (Andre Molnar) Date: Sun Nov 20 21:24:35 2005 Subject: [development] One core, many distributions In-Reply-To: <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> Message-ID: <4380E8F6.4060109@yahoo.co.uk> Adrian Rossouw wrote: > I agree, but I believe that pathauto like functionality should be part > of our default install, and we should emphasise it. > It's one of our more powerful features, and the improvements in > usabilty and browsability are amazing. > Plus google loves you much much much more. Okay - people have lost their minds (sorry don't mean to single you out here Adrian - especially considering your comments later on in this thread - and all the work that you do, but this comment just floored me enough to end months of silence). What floored me is the irony that the topic should come up in a thread about creating a leaner core that can support multiple distributions. Path auto is the epitome of a contributed module. It serves a purpose that many people may find useful, but is NOT REQUIRED and does not serve a CORE purpose. (Core module = module absolutely required to make the software/development environment work.) I've more or less given up trying to define what Drupal is. Its a lot of things to a lot of different people. (I'm finally coming around to thinking of it as two distinct things: 1) a rapid software development platform 2) a Drupal Branded CMS that uses has the rapid software development platform at its core). But I can define what Civicspace is - I can define what DrupalArt is - I can define what Drupal Blog is - I can define what DrupalEd is etc. And I know that Drupal is at the CORE of all of them. So I'm in full agreement with Jose's idea of 'one core to serve them all'. If something doesn't 'serve them all' it has no place in core. Take this idea to its logical conclusion and Forum.module should be dropped from core. "HERESY!!!," the masses rise up and shout. "That's where drupal all began. BURN THE HERETIC." Fine - light your torches - but when your done and Drupal 5.0 comes out with a full installer that starts with a lean core and adds only whatever users need and/or want - you'll realize that your already on the same page. andre p.s. As for multiple contributed modules that do more or less the same thing. If people don't want to work together it doesn't matter. Natural selection will take place. Competition is good. The module that adapts the quickest to the needs of the community will become the defacto standard - until a new competitor comes along. Why did someone write Drupal when there was another forum tool available at the time? Why do people improve Drupal when they could be working on phpNuke ;-)? The multiple contrib module issue is a non-issue. From ber at webschuur.com Sun Nov 20 21:37:01 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Sun Nov 20 21:37:10 2005 Subject: [development] that admin theme (from money/ work point of view), call for arms? Message-ID: <200511202237.06060.ber@webschuur.com> Hi there, First of all, i don't want to restart this endless debate, I just want to get those that are already behind this idea, going. :) I have just managed to set up a theme, for my sister. She is graphical designer so it had to be "nifty" or "appealing". But I refuse to get into flash and that crap. I managed to create a theme from scratch, that uses image galleries, books and a few static pages, in less then four hours. (will launch somwhere December) That is, four hours after I did the layout in inkscape and illustrator (just a drawing suite). So, that is four hours to: * make the HTML (validate) * test the CSS on various platform. (okay, ie5 (mac) is omitted, for now) * make that a theme But, off course, the admin part breaks horribly. Absolute positioning, hardcoded CSS dimensions and more of such 'niftyness' + Drupal admin don't go together, never. So why this mail? Not to tell you how quick I can theme ;) But because I have now proved, to myself, that I really need that admin theme. It shortens the themeing, or design of a site with over 750%. That is an afternoon vs a week! So, as of today, I really beleive that a lot of developers, themers and users can get their site online in at least half the time they would usually need, had they not have to bother abotu that admin part. And yes, I beleive it reduces usability, but if it obviously saves so much, I think it is worth that loss! Here is my plan: * get the amin part out of civicspace (Robert Douglas, did you not already do this?) * upgrade sections to ship as teh engine to achieve this admin-theme-magic. Anyone who wats to jump on this boat, please grab me on IRC, or by mail (ber curlything webschuur com). It should be a matter of hours to get this done. From then on we can look if more plp are interested, maybe even get all this shipped with core in a distant future. B?r Oh and for the record: the HTML is non-table, the complete stylesheet (i trew out drupal.css, off course) is just under 120 lines! -- | B?r Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20051120/62e5fb24/attachment.pgp From karoly at negyesi.net Sun Nov 20 23:05:57 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Sun Nov 20 23:02:04 2005 Subject: [development] that admin theme (from money/ work point of view), call for arms? In-Reply-To: <200511202237.06060.ber@webschuur.com> References: <200511202237.06060.ber@webschuur.com> Message-ID: > * upgrade sections to ship as teh engine to achieve this > admin-theme-magic. A one-line in hook_init() will do: if (arg(0)=='admin' || arg(2) == 'edit') $GLOBALS['custom_theme'] = 'admin'; or something very close to this. Regards NK From karoly at negyesi.net Sun Nov 20 23:11:43 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Sun Nov 20 23:07:48 2005 Subject: [development] One core, many distributions In-Reply-To: <4380E8F6.4060109@yahoo.co.uk> References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> Message-ID: > "HERESY!!!," the masses rise up and shout. "That's where drupal all > began. BURN THE HERETIC." Could you please show me forum module in my list? http://lists.drupal.org/pipermail/development/2005-November/011429.html Of course forum is not core. What should be in core? Required modules and those that have a fairly extensive API. From ber at webschuur.com Mon Nov 21 07:09:01 2005 From: ber at webschuur.com (=?utf-8?q?B=C3=A8r_Kessels?=) Date: Sun Nov 20 23:08:37 2005 Subject: [development] that admin theme (from money/ work point of view), call for arms? In-Reply-To: References: <200511202237.06060.ber@webschuur.com> Message-ID: <200511210809.01207.ber@webschuur.com> Op maandag 21 november 2005 00:05, schreef Karoly Negyesi: > A one-line in hook_init() will do: > > if (arg(0)=='admin' || arg(2) == 'edit') $GLOBALS['custom_theme'] = ? > 'admin'; > > or something very close to this. nah, unfortunately its a littlebit more co+plicated user/ , node/add , comment, forums edit/moderation/edit, qnd so on. Drupal is a littlebit more complex then two locations..... From adrian at bryght.com Sun Nov 20 23:15:41 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Sun Nov 20 23:15:54 2005 Subject: [development] One core, many distributions In-Reply-To: <4380E8F6.4060109@yahoo.co.uk> References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> Message-ID: <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20 Nov 2005, at 11:21 PM, Andre Molnar wrote: > Path auto is the epitome of a contributed module. It serves a > purpose that many people may find useful, but is NOT REQUIRED and > does not serve a CORE purpose. User-friendliness is a core purpose imo. I believe being able to create human readable URL's automatically is something we should build upon wherever possible. I also think we should turn pathauto into more of an API, so modules / nodes / pages can expose properties to be used in url's. I also believe we should never ever show a node id to an end user. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDgQOdgegMqdGlkasRAkkiAJ9Q2lD2IRoAgqhiN0GYSr1PFRqDxQCgmyEh kQenWdx41vN6dcj3hVUlGz8= =FQZK -----END PGP SIGNATURE----- From jeff at viapositiva.net Sun Nov 20 23:16:16 2005 From: jeff at viapositiva.net (Jeff Eaton) Date: Sun Nov 20 23:16:29 2005 Subject: [development] that admin theme (from money/ work point of view), call for arms? In-Reply-To: <200511210809.01207.ber@webschuur.com> Message-ID: <000c01c5ee28$6b11d340$0300a8c0@mjolnir> I'm in. The 4.7 update patch for section that I contributed is probably a little more complicated because it includes the block-like 'change the section if this PHP evals to true' functionality. With it, though, making a PHP block that test for all normal admin-only pages in one fell swoop is relatively simple. There are other wish-list features I'd love to tinker with, but I have the feeling that they don't fit in your vision for sections. ;) Even still, I think that it's tremendously powerful, especially when combined with drupal's ability for themes to inherit code and functionality from each other. (One main theme, with named sub-themes for each section, using sections.module to assign them, is VERY easy to pull off)... --Jeff -----Original Message----- From: B?r Kessels [mailto:ber@webschuur.com] Sent: Monday, November 21, 2005 1:09 AM To: development@drupal.org Subject: Re: [development] that admin theme (from money/ work point of view),call for arms? Op maandag 21 november 2005 00:05, schreef Karoly Negyesi: > A one-line in hook_init() will do: > > if (arg(0)=='admin' || arg(2) == 'edit') $GLOBALS['custom_theme'] = > 'admin'; > > or something very close to this. nah, unfortunately its a littlebit more co+plicated user/ , node/add , comment, forums edit/moderation/edit, qnd so on. Drupal is a littlebit more complex then two locations..... From drewish at katherinehouse.com Sun Nov 20 23:24:01 2005 From: drewish at katherinehouse.com (andrew morton) Date: Sun Nov 20 23:24:03 2005 Subject: [development] One core, many distributions In-Reply-To: <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> Message-ID: On 11/20/05, Adrian Rossouw wrote: > > I believe being able to create human readable URL's automatically is > something we should build upon wherever possible. I also think we > should turn > pathauto into more of an API, so modules / nodes / pages can expose > properties to be used in url's. > > I also believe we should never ever show a node id to an end user. +1, IMHO, pathauto is one of the most useful druapl modules, it really should be in core. From adrian at bryght.com Sun Nov 20 23:29:04 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Sun Nov 20 23:29:14 2005 Subject: [development] One core, many distributions In-Reply-To: References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> Message-ID: <9DCDA7A3-FB5F-4E96-963D-248CF7B23A0C@bryght.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21 Nov 2005, at 1:24 AM, andrew morton wrote: > > +1, IMHO, pathauto is one of the most useful druapl modules, it really > should be in core. Also.. keep in mind we probably don't mean the actual pathauto module.. more like the gist (functionality) of it, integrated properly into the current path module. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDgQbBgegMqdGlkasRAm48AKCmIP4q+WqdCcxH43ERGDPuEZ/hkACgjVLg Q/GYg1ijzXUAGCVJy/1lqvA= =6e+X -----END PGP SIGNATURE----- From dan at civicactions.com Sun Nov 20 23:39:12 2005 From: dan at civicactions.com (Dan Robinson) Date: Sun Nov 20 23:39:53 2005 Subject: [development] One core, many distributions In-Reply-To: <4380E8F6.4060109@yahoo.co.uk> References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> Message-ID: <43810920.1050201@civicactions.com> How about a stack? (Read from bottom to top) Drupal Verticals (Education, Blogging, CivicSpace yada yada) Drupal Experimental - All the other stuff (this is sandbox) Drupal Community Contribs - Lots of other stuff (new / part of current contribs) Drupal Base Modules - relatively generic, popular, highly desireable, maintained stuff (new / part of current contribs) Drupal Core - totally generic everyone needs them stuff (this is core) If I was drawing a picture it would be a bunch of stacked boxes and L shapes showing a somewhat more sophisticated "stacking". Don't go all wacky on the naming (just put it here for a conversation starter). And who are the "customers" Accidental Webmaster Webmasters ISVs / Consultants / VARs Developers Each of the above is it's own defined group with specific needs/desires. IMHO Drupal currently does an excellent job with Developers (and pretty well (but not as well) with the others). Simply making more of a distinction between the modules would go a long way in helping these users. Dan > Adrian Rossouw wrote: > >> I agree, but I believe that pathauto like functionality should be >> part of our default install, and we should emphasise it. >> It's one of our more powerful features, and the improvements in >> usabilty and browsability are amazing. >> Plus google loves you much much much more. > > > Okay - people have lost their minds (sorry don't mean to single you > out here Adrian - especially considering your comments later on in > this thread - and all the work that you do, but this comment just > floored me enough to end months of silence). > > What floored me is the irony that the topic should come up in a thread > about creating a leaner core that can support multiple distributions. > > Path auto is the epitome of a contributed module. It serves a purpose > that many people may find useful, but is NOT REQUIRED and does not > serve a CORE purpose. > > (Core module = module absolutely required to make the > software/development environment work.) > > I've more or less given up trying to define what Drupal is. Its a lot > of things to a lot of different people. (I'm finally coming around to > thinking of it as two distinct things: 1) a rapid software development > platform 2) a Drupal Branded CMS that uses has the rapid software > development platform at its core). But I can define what Civicspace > is - I can define what DrupalArt is - I can define what Drupal Blog is > - I can define what DrupalEd is etc. And I know that Drupal is at the > CORE of all of them. > > So I'm in full agreement with Jose's idea of 'one core to serve them > all'. If something doesn't 'serve them all' it has no place in core. > > Take this idea to its logical conclusion and Forum.module should be > dropped from core. > > "HERESY!!!," the masses rise up and shout. "That's where drupal all > began. BURN THE HERETIC." > > Fine - light your torches - but when your done and Drupal 5.0 comes > out with a full installer that starts with a lean core and adds only > whatever users need and/or want - you'll realize that your already on > the same page. > > andre > > p.s. As for multiple contributed modules that do more or less the same > thing. If people don't want to work together it doesn't matter. > Natural selection will take place. Competition is good. The module > that adapts the quickest to the needs of the community will become the > defacto standard - until a new competitor comes along. > > Why did someone write Drupal when there was another forum tool > available at the time? Why do people improve Drupal when they could > be working on phpNuke ;-)? The multiple contrib module issue is a > non-issue. > From dreed10 at gmail.com Mon Nov 21 01:18:05 2005 From: dreed10 at gmail.com (David Reed) Date: Mon Nov 21 01:18:06 2005 Subject: [development] that admin theme (from money/ work point of view), call for arms? In-Reply-To: <200511202237.06060.ber@webschuur.com> References: <200511202237.06060.ber@webschuur.com> Message-ID: +1 for the concept. I'm doing this today for my sites. I use the sections module plus the admin theme from civicspace plus my controlpanel module and I agree it saves a lot when trying to theme your site. der On 11/20/05, B?r Kessels wrote: > > Hi there, > > First of all, i don't want to restart this endless debate, I just want to > get > those that are already behind this idea, going. :) > > I have just managed to set up a theme, for my sister. She is graphical > designer so it had to be "nifty" or "appealing". But I refuse to get into > flash and that crap. > > I managed to create a theme from scratch, that uses image galleries, books > and > a few static pages, in less then four hours. (will launch somwhere > December) > That is, four hours after I did the layout in inkscape and illustrator > (just a > drawing suite). So, that is four hours to: > * make the HTML (validate) > * test the CSS on various platform. (okay, ie5 (mac) is omitted, for now) > * make that a theme > > But, off course, the admin part breaks horribly. Absolute positioning, > hardcoded CSS dimensions and more of such 'niftyness' + Drupal admin don't > go > together, never. > > So why this mail? Not to tell you how quick I can theme ;) But because I > have > now proved, to myself, that I really need that admin theme. It shortens > the > themeing, or design of a site with over 750%. That is an afternoon vs a > week! > So, as of today, I really beleive that a lot of developers, themers and > users > can get their site online in at least half the time they would usually > need, had they not have to bother abotu that admin part. > And yes, I beleive it reduces usability, but if it obviously saves so > much, I > think it is worth that loss! > > Here is my plan: > * get the amin part out of civicspace (Robert Douglas, did you not already > do > this?) > * upgrade sections to ship as teh engine to achieve this > admin-theme-magic. > > Anyone who wats to jump on this boat, please grab me on IRC, or by mail > (ber > curlything webschuur com). It should be a matter of hours to get this > done. > From then on we can look if more plp are interested, maybe even get all > this > shipped with core in a distant future. > > B?r > > Oh and for the record: the HTML is non-table, the complete stylesheet (i > trew out drupal.css, off course) is just under 120 lines! > -- > | B?r Kessels | webschuur.com | website development > | > | Jabber & Google Talk: ber@jabber.webschuur.com > | http://bler.webschuur.com | http://www.webschuur.com | > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051121/86a762ae/attachment.htm From mcsparkerton at yahoo.co.uk Mon Nov 21 02:43:39 2005 From: mcsparkerton at yahoo.co.uk (Andre Molnar) Date: Mon Nov 21 02:46:16 2005 Subject: [development] One core, many distributions In-Reply-To: References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> Message-ID: <4381345B.9030000@yahoo.co.uk> Karoly Negyesi wrote: >> "HERESY!!!," the masses rise up and shout. "That's where drupal all >> began. BURN THE HERETIC." > Could you please show me forum module in my list? > > http://lists.drupal.org/pipermail/development/2005-November/011429.html > > Of course forum is not core. > > What should be in core? Required modules and those that have a fairly > extensive API. Agreed - I wasn't commenting on your list. I was commenting on what Jose said: > Just as an example -and I have nothing against forum module: At some > point, we are duplicating the taxonomy interface to handle a forum > specific vocabulary. Then, this causes some bug -like this one, again > just an example: http://drupal.org/node/24274 -, and then we have a > core bug, module specific, but as it is a core module, this one has > the same importance -in the bug tracking system- as any other critical > bug -like a basic API not working properly. andre From mcsparkerton at yahoo.co.uk Mon Nov 21 03:30:25 2005 From: mcsparkerton at yahoo.co.uk (Andre Molnar) Date: Mon Nov 21 03:33:02 2005 Subject: [development] One core, many distributions In-Reply-To: <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> Message-ID: <43813F51.4010103@yahoo.co.uk> Adrian Rossouw wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 20 Nov 2005, at 11:21 PM, Andre Molnar wrote: > >> Path auto is the epitome of a contributed module. It serves a >> purpose that many people may find useful, but is NOT REQUIRED and >> does not serve a CORE purpose. > User-friendliness is a core purpose imo. > > I believe being able to create human readable URL's automatically is > something we should build upon wherever possible. I also think we > should turn > pathauto into more of an API, so modules / nodes / pages can expose > properties to be used in url's. > > I also believe we should never ever show a node id to an end user. I hate software that tries to think for me. (If another word processing program dares to, by default, capitalize something that I didn't capitalize to begin with - or another IDE, by default, adds so much as a line break to my code - or if any software suggests another file name for me when I go to save - so help me god I'm going to... ... fume because there's nothing else I can do). How can we as developers presume to KNOW how the end user wants to see their URL's? And if the user / developer wants to change the default 'human readable' URL, they will still have to turn to path-alias or another path tool to do so AND/OR hack some code to do it (API or no API). What have we gained? > Also.. keep in mind we probably don't mean the actual pathauto module.. > > more like the gist (functionality) of it, integrated properly into the current path module. Yes - I assumed that - considering pathauto does an okay job - but is still a bit glitchy. And don't get me wrong - path auto is fine and is a nice feature that should make it into several distributions of Drupal - but if I don't want it - or I want to bake my own way of auto aliasing paths that should be left up to me. andre p.s. Am I the only one that sees beauty in the simplicity of example.com/node/13 meaning the 13th node of content on a site - and node/1000345 being the 1,000,345th node on a site... and am I the only one that thinks 1 million aliases might be a bit silly to generate automatically? From larry at garfieldtech.com Mon Nov 21 05:59:52 2005 From: larry at garfieldtech.com (Larry Garfield) Date: Mon Nov 21 06:00:00 2005 Subject: [development] One core, many distributions In-Reply-To: <43813F51.4010103@yahoo.co.uk> References: <437F6F91.40600@wanadoo.es> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> Message-ID: <200511202359.53055.larry@garfieldtech.com> On Sunday 20 November 2005 09:30 pm, Andre Molnar wrote: > Adrian Rossouw wrote: > > I also believe we should never ever show a node id to an end user. > > I hate software that tries to think for me. (If another word processing > program dares to, by default, capitalize something that I didn't > capitalize to begin with - or another IDE, by default, adds so much as a > line break to my code - or if any software suggests another file name > for me when I go to save - so help me god I'm going to... ... fume > because there's nothing else I can do). How can we as developers presume > to KNOW how the end user wants to see their URL's? Agreed. Some are obvious. (Eg, user/username vs. user/userid is a no-brainer that's easy to code and isn't being "smarter" than the user.) Others, I dare say most, are not. > p.s. Am I the only one that sees beauty in the simplicity of > example.com/node/13 meaning the 13th node of content on a site - and > node/1000345 being the 1,000,345th node on a site... and am I the only > one that thinks 1 million aliases might be a bit silly to generate > automatically? See, my problem with pathauto is not the auto-generation, it's that putting 1 million entries into the path_alias table is going to kill your system. Of course at that point, the numbers make more sense anyway (or some other numeric format, like issue # and then article # for a magazine, but still numeric). Really, though, I'm trying to avoid thinking of new and cool things for Drupal until after 4.7 ships. :-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson From blogdiva at culturekitchen.com Mon Nov 21 06:08:21 2005 From: blogdiva at culturekitchen.com (Liza Sabater) Date: Mon Nov 21 06:08:26 2005 Subject: [development] One core, many distributions In-Reply-To: <43813F51.4010103@yahoo.co.uk> References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> Message-ID: On Nov 20 2005, at 10:30 PM, Andre Molnar wrote: > p.s. Am I the only one that sees beauty in the simplicity of > example.com/node/13 meaning the 13th node of content on a site - > and node/1000345 being the 1,000,345th node on a site... and am I > the only one that thinks 1 million aliases might be a bit silly to > generate automatically? yes. From jeff at viapositiva.net Mon Nov 21 06:15:26 2005 From: jeff at viapositiva.net (Jeff Eaton) Date: Mon Nov 21 06:15:36 2005 Subject: [development] One core, many distributions In-Reply-To: <43813F51.4010103@yahoo.co.uk> Message-ID: <001c01c5ee62$f9380150$0300a8c0@mjolnir> Andre Molnar wrote: > p.s. Am I the only one that sees beauty in the simplicity of > example.com/node/13 meaning the 13th node of content on a site - and > node/1000345 being the 1,000,345th node on a site... and am I the only > one that thinks 1 million aliases might be a bit silly to generate > automatically? As a unique ID, that works smashingly. As a recognizable URL, it works quite badly. Obviously, there are some cases where it is unecessary. I DO think, though, that path.module is next to useless on any site that gets updated unless you combine it with pathauto.module. --Jeff From weitzman at tejasa.com Mon Nov 21 06:42:21 2005 From: weitzman at tejasa.com (Moshe Weitzman) Date: Mon Nov 21 06:42:25 2005 Subject: [development] One core, many distributions In-Reply-To: <200511202359.53055.larry@garfieldtech.com> References: <437F6F91.40600@wanadoo.es> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> <200511202359.53055.larry@garfieldtech.com> Message-ID: <43816C4D.3070007@tejasa.com> > See, my problem with pathauto is not the auto-generation, it's that putting 1 > million entries into the path_alias table is going to kill your system. Of > course at that point, the numbers make more sense anyway (or some other > numeric format, like issue # and then article # for a magazine, but still > numeric). > > Really, though, I'm trying to avoid thinking of new and cool things for Drupal > until after 4.7 ships. :-) who says that they all need to go into a table? it is plausible to use an url strategy like article/mytitle. when drupal receives that request, it does a node_load(array('title' => mytitle)); From bmansion at mamasam.com Mon Nov 21 07:43:24 2005 From: bmansion at mamasam.com (Bertrand Mansion) Date: Mon Nov 21 07:43:11 2005 Subject: [development] One core, many distributions In-Reply-To: <43813F51.4010103@yahoo.co.uk> Message-ID: Andre Molnar wrote: >Adrian Rossouw wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 20 Nov 2005, at 11:21 PM, Andre Molnar wrote: >> >>> Path auto is the epitome of a contributed module. It serves a >>> purpose that many people may find useful, but is NOT REQUIRED and >>> does not serve a CORE purpose. >> User-friendliness is a core purpose imo. >> >> I believe being able to create human readable URL's automatically is >> something we should build upon wherever possible. I also think we >> should turn >> pathauto into more of an API, so modules / nodes / pages can expose >> properties to be used in url's. >> >> I also believe we should never ever show a node id to an end user. > >I hate software that tries to think for me. (If another word processing >program dares to, by default, capitalize something that I didn't >capitalize to begin with - or another IDE, by default, adds so much as a >line break to my code - or if any software suggests another file name >for me when I go to save - so help me god I'm going to... ... fume >because there's nothing else I can do). How can we as developers presume >to KNOW how the end user wants to see their URL's? > >And if the user / developer wants to change the default 'human readable' > URL, they will still have to turn to path-alias or another path tool >to do so AND/OR hack some code to do it (API or no API). What have we >gained? I agree. My experience shows that newbies are comfortable dealing with node ids. They are easier to remember and understand. I don't know about pathauto, but if it can't handle transliteration of unicode correctly, it's not worth it. The only way today to do this is to use the translit[1] extension AFAIK. [1] http://pecl.php.net/translit -- Bertrand Mansion http://www.mamasam.com - creative internet solutions http://golgote.freeflux.net - my blog From ber at webschuur.com Mon Nov 21 08:15:22 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Mon Nov 21 08:15:37 2005 Subject: [development] One core, many distributions In-Reply-To: References: <437F6F91.40600@wanadoo.es> <43813F51.4010103@yahoo.co.uk> Message-ID: <200511210915.29432.ber@webschuur.com> Op maandag 21 november 2005 07:08, schreef Liza Sabater: > > the only one that thinks 1 million aliases might be a bit silly to ? > > generate automatically? > > yes. No B?r -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20051121/6789bb2b/attachment.pgp From ber at webschuur.com Mon Nov 21 08:20:10 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Mon Nov 21 08:20:15 2005 Subject: [development] that admin theme (from money/ work point of view), call for arms? In-Reply-To: <000c01c5ee28$6b11d340$0300a8c0@mjolnir> References: <000c01c5ee28$6b11d340$0300a8c0@mjolnir> Message-ID: <200511210920.10829.ber@webschuur.com> Op maandag 21 november 2005 00:16, schreef Jeff Eaton: > There are other wish-list features I'd love to tinker with, but I have > the feeling that they don't fit in your vision for sections. ;) Even > still, I think that it's tremendously powerful, especially when combined > with drupal's ability for themes to inherit code and functionality from > each other. (One main theme, with named sub-themes for each section, > using sections.module to assign them, is VERY easy to pull off)... Previously i wanteed sections to follow core (aka blocks) on the foot. But I don't see that evolvin as fast as we could. So i think we should turn it around, make a cool, nifty, fancy interface on sections and then see if someone feels like porting it to blocks :) B?r -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20051121/39429bcd/attachment.pgp From adrian at bryght.com Mon Nov 21 08:21:25 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Mon Nov 21 08:21:51 2005 Subject: [development] One core, many distributions In-Reply-To: <200511210915.29432.ber@webschuur.com> References: <437F6F91.40600@wanadoo.es> <43813F51.4010103@yahoo.co.uk> <200511210915.29432.ber@webschuur.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21 Nov 2005, at 10:15 AM, B?r Kessels wrote: > Op maandag 21 november 2005 07:08, schreef Liza Sabater: >>> the only one that thinks 1 million aliases might be a bit silly to >>> generate automatically? >> >> yes. > > No There will only (really) ever be as many aliases as you have nodes / users. If you have 1 million nodes/users, you have for more problems than the path_alias table. The path alias table is really simple, and we improved the performance a ton, so it only loads aliases as needed (instead of caching all of them the whole time) The unicode problem is a good one though. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDgYOFgegMqdGlkasRAiP6AKCnxdCITcwYoRWRGAn5cYWFv1wX+gCfefa7 0Jo1oAkPtPCULPhaVB4u/1Y= =XFCl -----END PGP SIGNATURE----- From gerhard at killesreiter.de Mon Nov 21 08:28:11 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Mon Nov 21 08:30:36 2005 Subject: [development] One core, many distributions In-Reply-To: References: <437F6F91.40600@wanadoo.es> <43813F51.4010103@yahoo.co.uk> <200511210915.29432.ber@webschuur.com> Message-ID: <4381851B.8020005@killesreiter.de> Adrian Rossouw wrote: > There will only (really) ever be as many aliases as you have nodes / > users. > > If you have 1 million nodes/users, you have for more problems than > the path_alias table. > > The path alias table is really simple, and we improved the > performance a ton, so it only loads > aliases as needed (instead of caching all of them the whole time) > Well, we try to find an alias for every link and end up sending at least a few dozen requests to that table per page view. I'd still like to see this more centralized so we can get away with less queries. Cheers, Gerhard From adrian at bryght.com Mon Nov 21 08:30:23 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Mon Nov 21 08:31:10 2005 Subject: [development] that admin theme (from money/ work point of view), call for arms? In-Reply-To: <200511210920.10829.ber@webschuur.com> References: <000c01c5ee28$6b11d340$0300a8c0@mjolnir> <200511210920.10829.ber@webschuur.com> Message-ID: <3B3879EE-9650-4DF5-8411-9B27B4C38C54@bryght.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21 Nov 2005, at 10:20 AM, B?r Kessels wrote: > So i think we should turn it around, make a cool, nifty, fancy > interface on > sections and then see if someone feels like porting it to blocks :) I am going to be rebuilding core to have 'sections support' for 4.8 As per my presentation in my user configurable themes talk. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDgYWggegMqdGlkasRAg1lAJ495xI8XzThuweEwCFJtGLiImZa/gCff4Vf mdvOfubQrEoPemS9ZVJBsZI= =ozCm -----END PGP SIGNATURE----- From ber at webschuur.com Mon Nov 21 08:43:51 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Mon Nov 21 08:43:56 2005 Subject: [development] One core, many distributions In-Reply-To: References: <437F6F91.40600@wanadoo.es> <200511210915.29432.ber@webschuur.com> Message-ID: <200511210943.52150.ber@webschuur.com> Op maandag 21 november 2005 09:21, schreef Adrian Rossouw: > On 21 Nov 2005, at 10:15 AM, B?r Kessels wrote: > > Op maandag 21 november 2005 07:08, schreef Liza Sabater: > >>> the only one that thinks 1 million aliases might be a bit silly to > >>> generate automatically? > >> > >> yes. > > > > No > > There will only (really) ever be as many aliases as you have nodes / > users. > > If you have 1 million nodes/users, you have for more problems than > the path_alias table. > > The path alias table is really simple, and we improved the > performance a ton, so it only loads > aliases as needed (instead of caching all of them the whole time) No, nAliases = nPages = nNodes + (nUsers * 2) + (nTags ^ nTags) + (nByModules) (nByModules, for tagadelic, 2 * (nVocabularies ^ 25), or for image: nImages + nGalleries) so, nAliases can be enourmous, humongous, redicoulous big, if this is to be used, we need to follow Moshes road of 'dynamic' aliases, i.e. aliases made on-the-fly. That is, what I wanted to do for tagadeli. So, not store /tagadelic/chunk/Foo, /tagadelic/chunk/Foo+Bar /tagadelic/chunk/Foo,Bar /tagadelic/chunk/Foo+Faa and so on, but rather just match Foo, Faa, Bar against the db on call of that page. B?r -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20051121/3ff8a6ca/attachment-0001.pgp From dries.buytaert at gmail.com Mon Nov 21 09:20:39 2005 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Mon Nov 21 09:20:44 2005 Subject: [development] that admin theme (from money/ work point of view), call for arms? In-Reply-To: <3B3879EE-9650-4DF5-8411-9B27B4C38C54@bryght.com> References: <000c01c5ee28$6b11d340$0300a8c0@mjolnir> <200511210920.10829.ber@webschuur.com> <3B3879EE-9650-4DF5-8411-9B27B4C38C54@bryght.com> Message-ID: > On 21 Nov 2005, at 10:20 AM, B?r Kessels wrote: >> So i think we should turn it around, make a cool, nifty, fancy >> interface on >> sections and then see if someone feels like porting it to blocks :) > > I am going to be rebuilding core to have 'sections support' for 4.8 > As per my presentation in my user configurable themes talk. +1 I'll be the first to work with Adrian to get this committed to core. :) -- Dries Buytaert :: http://www.buytaert.net/ From larry at garfieldtech.com Mon Nov 21 09:22:21 2005 From: larry at garfieldtech.com (Larry Garfield) Date: Mon Nov 21 09:22:41 2005 Subject: [development] One core, many distributions In-Reply-To: <200511210943.52150.ber@webschuur.com> References: <437F6F91.40600@wanadoo.es> <200511210943.52150.ber@webschuur.com> Message-ID: <200511210322.21751.larry@garfieldtech.com> Actually, I'd suggest something even easier. In 4.7, there's a menu settings fieldset for every node. First, expand that to tie to just ONE menu instead of all of them, for size reasons. Call that menu "Site Structure" (or "Navigation" ). Then any page that gets put into that menu automagically gets a dynamic alias (read: not stored in path_alias) of that menu location. So a node with ID 47 called "stuff" that is placed in the menu with parent: Site Menu > mysection > mysubsection will be accessible via both node/47 AND mysection/mysubsection/stuff. That way the node_alias table doesn't get hammered, there's a clean interface to it, it makes logical sense for a deep site structure as well as a shallow one, and you also get to leverage all of the menu module magic. In fact, set that site menu to be the Primary Links menu, thanks to Richard's great new patch, and you automagically get your primary and secondary links based on your URLs. (If you don't want them to be, though, you don't have to.) That should scale as large as large as sites that need a unique non-numeric name for everything. (Eg, drupal.org has no need to give a string name to every single node.) The path module can stay as is for adding additional paths to a page if needed (say, the diffandpatch page which we do want to have a nice short URL but doesn't belong in the primary links), but won't be necessary for most "normal" pages. usernames, frankly, should be a built-in feature. It should be trivial to tweak user.module to accept an ID or name, since both are required to be unique anyway. Besides, path_alias doesn't scale for larger sites. (Drupal.org has over 40,000 users, if I'm interpreting the URL correctly. pathauto would die horribly.) That eliminates the two largest needs for path/pathauto. The rest are taxonomy categories, which could also be automated the same was as user, or not, take your pick. :-) Either way it would clean up the largest needs for path/pathauto, and offer additional functionality. I think it's too late to put that into 4.7, but what do you think? On Monday 21 November 2005 02:43 am, B?r Kessels wrote: > So, not > store /tagadelic/chunk/Foo, /tagadelic/chunk/Foo+Bar > /tagadelic/chunk/Foo,Bar /tagadelic/chunk/Foo+Faa and so on, but rather > just match Foo, Faa, Bar against the db on call of that page. > > B?r -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson From ber at webschuur.com Mon Nov 21 09:42:24 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Mon Nov 21 09:42:28 2005 Subject: [development] that admin theme (from money/ work point of view), call for arms? In-Reply-To: References: <000c01c5ee28$6b11d340$0300a8c0@mjolnir> <3B3879EE-9650-4DF5-8411-9B27B4C38C54@bryght.com> Message-ID: <200511211042.24320.ber@webschuur.com> Op maandag 21 november 2005 10:20, schreef Dries Buytaert: > > On 21 Nov 2005, at 10:20 AM, B?r Kessels wrote: > >> So i think we should turn it around, make a cool, nifty, fancy > >> interface on > >> sections and then see if someone feels like porting it to blocks :) > > > > I am going to be rebuilding core to have 'sections support' for 4.8 > > As per my presentation in my user configurable themes talk. > > +1 > > I'll be the first to work with Adrian to get this committed to core. :) So, Do i understand it correctly? Should I wait with the sections + admin theme for this core solution? What timeframe are we speaking? Section + admin thee is almost ready. Whaen do we expect this core thing to land? B?r -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20051121/ce314f18/attachment.pgp From rob at robshouse.net Mon Nov 21 10:30:33 2005 From: rob at robshouse.net (Robert Douglass) Date: Mon Nov 21 10:31:53 2005 Subject: [development] that admin theme (from money/ work point of view), call for arms? In-Reply-To: <200511202237.06060.ber@webschuur.com> References: <200511202237.06060.ber@webschuur.com> Message-ID: <4381A1C9.8040303@robshouse.net> B?r Kessels wrote: > Here is my plan: > * get the amin part out of civicspace (Robert Douglas, did you not already do > this?) There are now two page.tpl.php files inside of the CivicSpace theme, the normal one and page_admin.tpl.php. I'm not sure this will be a terrible lot of help to you as the CS theme is a monster unto itself. However, instead of switching themes (which I don't like at all), you should consider using the _phptemplate_variables function in template.php. PHPTemplate comes with the little publicized but built-in ability to work with as many versions of any given file as you care to make. To avoid the baggage of maintaining multiple themes (bad), you can switch like this: // Set admin theme if (civicspace_is_admin()) { $vars['template_file'] = 'page_admin'; } This is a much better way than switching themes, imo. cheers Robert From adrian at bryght.com Mon Nov 21 10:37:08 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Mon Nov 21 10:37:20 2005 Subject: [development] that admin theme (from money/ work point of view), call for arms? In-Reply-To: <4381A1C9.8040303@robshouse.net> References: <200511202237.06060.ber@webschuur.com> <4381A1C9.8040303@robshouse.net> Message-ID: <531C3D69-46C5-4830-8E6E-40AD3434E767@bryght.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21 Nov 2005, at 12:30 PM, Robert Douglass wrote: > However, instead of switching themes (which I don't like at all), > you should consider using the _phptemplate_variables function in > template.php. PHPTemplate comes with the little publicized but > built-in ability to work with as many versions of any given file as > you care to make. To avoid the baggage of maintaining multiple > themes (bad), you can switch like this: Heh. sometimes even I forget what cool sht I built into phptemplate =P - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDgaNVgegMqdGlkasRAog6AKCKf/XKKfQaz/NSMaL/e0TxrcD9ewCfZSeq 1ij1PWbYlanbWcx/DXYPAVY= =zMs+ -----END PGP SIGNATURE----- From ber at webschuur.com Mon Nov 21 10:49:16 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Mon Nov 21 10:49:22 2005 Subject: [development] that admin theme (from money/ work point of view), call for arms? In-Reply-To: <4381A1C9.8040303@robshouse.net> References: <200511202237.06060.ber@webschuur.com> <4381A1C9.8040303@robshouse.net> Message-ID: <200511211149.17878.ber@webschuur.com> Op maandag 21 november 2005 11:30, schreef Robert Douglass: > To avoid the baggage of maintaining multiple themes (bad), you can > switch like this: > > ? ? ?// Set admin theme > ? ? ?if (civicspace_is_admin()) { > ? ? ????$vars['template_file'] = 'page_admin'; > ? ? ?} > > This is a much better way than switching themes, imo. My initial plan was, to just put a standalone theme "admin" on drupal So then you do not need to maintain more themes. All you need to do then is installa the admin theme and your own theme, and then configure sections A howto or recipe should suffice for the users. B?r -- [ B?r Kessels | Drupal services www.webschuur.com ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20051121/b931db73/attachment.pgp From adrian at bryght.com Mon Nov 21 11:10:20 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Mon Nov 21 11:10:34 2005 Subject: [development] that admin theme (from money/ work point of view), call for arms? In-Reply-To: <200511211042.24320.ber@webschuur.com> References: <000c01c5ee28$6b11d340$0300a8c0@mjolnir> <3B3879EE-9650-4DF5-8411-9B27B4C38C54@bryght.com> <200511211042.24320.ber@webschuur.com> Message-ID: <8769398B-0803-40B6-A670-FB450F439C8C@bryght.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21 Nov 2005, at 11:42 AM, B?r Kessels wrote: > So, Do i understand it correctly? Should I wait with the sections + > admin > theme for this core solution? It means that I am planning functionality for core which will supercede the sections module, and probably make it obsolete (at least in it's current state). > > What timeframe are we speaking? Section + admin thee is almost > ready. Whaen do > we expect this core thing to land? This is meant for 4.8. We could build the interface for selecting sections in contrib right now, and then move it to core later. The interface I have in mind is a generic filter ruleset interface (a real one, not that horrible admin nodes filter), almost exactly like the one you see in just about every email client. I want to make the block configuration be attached to the 'section' (or 'layout' in my model). So when you set up a 'section', it controls the block layout, the theme selection, and any other settings related to display (the theme settings). We would ship with 2 layouts by default. The default layout (configurable via admin/display) and the admin layout (configurable via admin/layouts/, if you have the layout module installed.) Not that many people need to be able to configure anything other than the default layout, and making the admin layout customisable, but not in core, and not requiring any code/ recipes is a better match for users. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDgascgegMqdGlkasRAra2AKCK+rRNPRYUTV5d3BMxdotSTznacQCg2Tl5 R6/MfpO2truo0xi0l0KfeFQ= =wgAh -----END PGP SIGNATURE----- From jareyero at wanadoo.es Mon Nov 21 12:48:22 2005 From: jareyero at wanadoo.es (Jose A. Reyero) Date: Mon Nov 21 12:48:44 2005 Subject: [development] Another translation module In-Reply-To: <20051120183502.GA46384@web.ca> References: <20051120183502.GA46384@web.ca> Message-ID: <4381C216.1070308@wanadoo.es> Hi Rob, I've been looking at your module, mostly looking for some new ideas to add into i18n module :-) -Btw, the .htaccess part of the patch doesn't apply It seems to me that the data model to keep the translations is quite similar, and compatible in both modules, but the management of paths and links is quite different. Actually, I was thinking of adding some options about that 'links to node translations' in next version of i18n module. A few things I dont fully understand are: - What is the idea of that "System locale settings" ? - Why aren't you using locale strings for that "string_translation" table? - Does it play nice with the cache system? Besides that, I think both modules share the same goal, and quite similar approach. So, could you tell me the features you are missing in i18n.module so maybe we can work out something together? Regards, Jose Rob Ellis wrote: >I just added yet another content translation module to CVS: > > contributions/modules/tr > >Apologies about the name, but 'translation' is already taken, >and I couldn't think of something short-but-meaningful >to use instead... 'tr' was used for development, so I just >left it as that. > >The module is a recent complete rewrite of something that was >developed early this year for the Canadian New Democratic Party >web site (www.ndp.ca). At the time, we had requirements that the >existing i18n module didn't meet, and I wasn't aware of the >contributed 'translation' module. > >The 'tr' module in it's current incarnation is being used by >my former employer for several sites, in french and english, >english and inuktitut, and french and english and inuktitut... >They're finding it useful. > >Some features are: > > - content switching based on language > - language switching based on hostname or url-path-prefix or ?l=xx > - per node 'translate' links for untranslated content > - per language 'edit' links for existing translations > - generated translation links for use in templates > - custom 404 page for missing translations (optional -- will > show untranslated content otherwise) > - admin node list filtered by language or "untranslated" > - translated taxonomy term names > - translated menu item titles > >It's a little sketchy in places, and it requires patches to >the Drupal core, but small ones. The patches at the moment >are for DRUPAL-4-6-3. > >At least it might be interesting for people working on similar >content translation schemes, and some people might find it >useful as is. > >I'm not sure about how to tag this initial import -- since the >patches are for DRUPAL-4-6-3, I thought branching it for >4.6.3 would be the thing to do, but I'm not sure. > >Help, comments would be appreciated. > >Thanks. > >- Rob > >-- >Rob Ellis > > > From rob at web.ca Mon Nov 21 13:56:41 2005 From: rob at web.ca (Rob Ellis) Date: Mon Nov 21 13:56:43 2005 Subject: [development] Another translation module In-Reply-To: <4381C216.1070308@wanadoo.es> References: <20051120183502.GA46384@web.ca> <4381C216.1070308@wanadoo.es> Message-ID: <20051121135641.GA62087@web.ca> On Mon, Nov 21, 2005 at 01:48:22PM +0100, Jose A. Reyero wrote: > Hi Rob, > > I've been looking at your module, mostly looking for some new ideas to > add into i18n module :-) -Btw, the .htaccess part of the patch doesn't apply Jose, feel free to take anything. :-) The .htaccess patch applies for me on a fresh DRUPAL-4-6-3 checkout, and I just checked it with the tarball distribution and get: Hunk #1 succeeded at 58 with fuzz 1. I'll see if I can figure out what the 'fuzz 1' is about. > It seems to me that the data model to keep the translations is quite > similar, and compatible in both modules, but the management of paths and > links is quite different. Actually, I was thinking of adding some > options about that 'links to node translations' in next version of i18n > module. I will have to install i18n again, I haven't done that for a while. There are two ways 'tr' can get the language: by parsing out a path prefix with mod_rewrite, or from matching the base url. I think the first is closer to what i18n is doing (?), but using mod_rewrite means that Drupal itself can handle the path normally after that. With 'sites' configurations, matching the base url might be cleaner, but it requires extra setup. The path parsing works with a default setup. > A few things I dont fully understand are: > - What is the idea of that "System locale settings" ? That's just to get the PHP locale setting right, which is useful, e.g., for using date functions in template code. That might not be the best place to do it. I was switching between FreeBSD and Linux environments, different versions, and finding that a pain. > - Why aren't you using locale strings for that "string_translation" table? That string_translation code works, but it's there really as a stub for something better. I read on this list somewhere that the locale string translation wasn't a good thing to use for content translation. I forget why... something to do with scaling/cache/efficiency...? I'm mainly using it for menu titles, which have their own caching. > - Does it play nice with the cache system? I think so. There may be things that need fixing there. The main thing it does is make per language cache ids, so the menu translations get cached differently. > > Besides that, I think both modules share the same goal, and quite > similar approach. So, could you tell me the features you are missing in > i18n.module so maybe we can work out something together? I will have to look at i18n again, I have to admit. When I started working on the problem, it was in February... There were more DB changes for i18n then, and I was worried about the extent of the core modifications (for keeping up with Drupal). The main thing that was missing was switching language based on the hostname, and the different path handling that entails. I also like the closer integration of translation editing with normal node editing in 'tr' -- no separate admin interface. This works well for just a few languages. I don't know how much demand there is for many-language sites where all the 'translate' tabs might be cluttered. Another thing you might want to look at is the hook into Drupal's url() function -- I found that ended up being simpler than getting into the path functions. - Rob > Rob Ellis wrote: > > >I just added yet another content translation module to CVS: > > > > contributions/modules/tr > > > >Apologies about the name, but 'translation' is already taken, > >and I couldn't think of something short-but-meaningful > >to use instead... 'tr' was used for development, so I just > >left it as that. > > > >The module is a recent complete rewrite of something that was > >developed early this year for the Canadian New Democratic Party > >web site (www.ndp.ca). At the time, we had requirements that the > >existing i18n module didn't meet, and I wasn't aware of the > >contributed 'translation' module. > > > >The 'tr' module in it's current incarnation is being used by > >my former employer for several sites, in french and english, > >english and inuktitut, and french and english and inuktitut... > >They're finding it useful. > > > >Some features are: > > > > - content switching based on language > > - language switching based on hostname or url-path-prefix or ?l=xx > > - per node 'translate' links for untranslated content > > - per language 'edit' links for existing translations > > - generated translation links for use in templates > > - custom 404 page for missing translations (optional -- will > > show untranslated content otherwise) > > - admin node list filtered by language or "untranslated" > > - translated taxonomy term names > > - translated menu item titles > > > >It's a little sketchy in places, and it requires patches to > >the Drupal core, but small ones. The patches at the moment > >are for DRUPAL-4-6-3. > > > >At least it might be interesting for people working on similar > >content translation schemes, and some people might find it > >useful as is. > > > >I'm not sure about how to tag this initial import -- since the > >patches are for DRUPAL-4-6-3, I thought branching it for > >4.6.3 would be the thing to do, but I'm not sure. > > > >Help, comments would be appreciated. > > > >Thanks. > > > >- Rob > > > >-- > >Rob Ellis > > > > > > > From occy at occy.net Mon Nov 21 14:07:55 2005 From: occy at occy.net (Trae McCombs) Date: Mon Nov 21 14:07:26 2005 Subject: [development] that admin theme (from money/ work point of view), call for arms? In-Reply-To: <200511202237.06060.ber@webschuur.com> References: <200511202237.06060.ber@webschuur.com> Message-ID: <4381D4BB.3040605@occy.net> Hey Ber, It would be cool if there was a way we could work some of this into the CivicSpace Theme. Are you saying you did a complete re-write of things from the ground up? If so, I would like to see what you did. Trae PS. #cstheme - the civicspace theme channel B?r Kessels wrote: >Hi there, > >First of all, i don't want to restart this endless debate, I just want to get >those that are already behind this idea, going. :) > >I have just managed to set up a theme, for my sister. She is graphical >designer so it had to be "nifty" or "appealing". But I refuse to get into >flash and that crap. > >I managed to create a theme from scratch, that uses image galleries, books and >a few static pages, in less then four hours. (will launch somwhere December) >That is, four hours after I did the layout in inkscape and illustrator (just a >drawing suite). So, that is four hours to: > make the HTML (validate) >* test the CSS on various platform. (okay, ie5 (mac) is omitted, for now) >* make that a theme > >But, off course, the admin part breaks horribly. Absolute positioning, >hardcoded CSS dimensions and more of such 'niftyness' + Drupal admin don't go >together, never. > >So why this mail? Not to tell you how quick I can theme ;) But because I have >now proved, to myself, that I really need that admin theme. It shortens the >themeing, or design of a site with over 750%. That is an afternoon vs a week! >So, as of today, I really beleive that a lot of developers, themers and users >can get their site online in at least half the time they would usually >need, had they not have to bother abotu that admin part. >And yes, I beleive it reduces usability, but if it obviously saves so much, I >think it is worth that loss! > >Here is my plan: > * get the amin part out of civicspace (Robert Douglas, did you not already do >this?) > * upgrade sections to ship as teh engine to achieve this admin-theme-magic. > >Anyone who wats to jump on this boat, please grab me on IRC, or by mail (ber >curlything webschuur com). It should be a matter of hours to get this done. >From then on we can look if more plp are interested, maybe even get all this >shipped with core in a distant future. > > B?r > >Oh and for the record: the HTML is non-table, the complete stylesheet (i >trew out drupal.css, off course) is just under 120 lines! > > From ber at webschuur.com Mon Nov 21 14:16:14 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Mon Nov 21 14:16:34 2005 Subject: [development] that admin theme (from money/ work point of view), call for arms? In-Reply-To: <4381D4BB.3040605@occy.net> References: <200511202237.06060.ber@webschuur.com> <4381D4BB.3040605@occy.net> Message-ID: <200511211516.23260.ber@webschuur.com> Op maandag 21 november 2005 15:07, schreef Trae McCombs: > Are you saying you did a complete re-write of things > from the ground up? ?If so, I would like to see what you did. Noo, just a new theme. In phptemplate. B?r -- | B?r Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20051121/3dd93b49/attachment.pgp From karoly at negyesi.net Mon Nov 21 14:35:04 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Mon Nov 21 14:31:02 2005 Subject: [development] Another translation module In-Reply-To: <20051121135641.GA62087@web.ca> References: <20051120183502.GA46384@web.ca> <4381C216.1070308@wanadoo.es> <20051121135641.GA62087@web.ca> Message-ID: > the first is closer to what i18n is doing (?), but using mod_rewrite > means that Drupal itself can handle the path normally after that. aye and making the module useless on hosts without mod_rewrite. Regards NK From walkah at walkah.net Mon Nov 21 15:15:37 2005 From: walkah at walkah.net (James Walker) Date: Mon Nov 21 15:15:15 2005 Subject: [development] Encouraging Collaboration In-Reply-To: <45BDD863-2078-401C-A749-5A548ED60FAD@buytaert.net> References: <59A38760-4882-4436-B584-2CA197ACCFDA@pajunas.com> <77BE1E64-3299-4738-8ED7-36448314CC51@bryght.com> <8EA5859C-349E-41BE-A8D2-83FDFF591C62@buytaert.net> <45BDD863-2078-401C-A749-5A548ED60FAD@buytaert.net> Message-ID: <4381E499.3020301@walkah.net> On 11/19/05 2:39 AM, Dries Buytaert wrote: > > On 19 Nov 2005, at 00:36, Boris Mann wrote: >>>> I had brought up before that we might consider designated >>>> maintainers for core modules -- see http://drupal.org/node/34439 -- >>>> there are still the majority that are theoretically "maintained" by >>>> Dries. Dries, do you want to speak up and say which ones you >>>> actually want to maintain, which might be in need of an official >>>> maintainer, etc.? >>> >>> Having 'official maintainers' matters for me: in the best case >>> scenario people will bug the maintainer and not me. Other than being >>> the official point of contact, very little changes. >> >> Right. That's all that I meant. Later on you say "Don't ask me to >> write down the list"...I guess what I'm asking is if it would be >> useful to have the list for some more of the core modules. There is a >> certain responsibility in that case to look at patches for a >> particular core module, and then it is known by those people. e.g. >> James knows that he has to personally look at all Blog API >> bugs/features/etc. > > James is listed as the blogapi module maintainer, but he somewhat > stopped caring about it, I think. He didn't look at any of the recent > blogapi.module patches. In my book, James stopped doing core > development months ago. > Say what?? -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net From jeff at viapositiva.net Mon Nov 21 15:20:11 2005 From: jeff at viapositiva.net (Jeff Eaton) Date: Mon Nov 21 15:20:21 2005 Subject: [development] Encouraging Collaboration In-Reply-To: <4381E499.3020301@walkah.net> Message-ID: <000401c5eeaf$1422ce40$6700a8c0@JEATON2DEV> > On 11/19/05 2:39 AM, Dries Buytaert wrote: > > > > James is listed as the blogapi module maintainer, but he somewhat > > stopped caring about it, I think. He didn't look at any of > the recent > > blogapi.module patches. In my book, James stopped doing core > > development months ago. > > > > Say what?? I can say first-hand that James was in fact involved in the troubleshooting and fixing of the last round of blogapi patches. Even when he wasn't directly involved in the threads for a while, he was coordinating with at least a couple of us about the issues via irc. --Jeff From walkah at walkah.net Mon Nov 21 15:40:26 2005 From: walkah at walkah.net (James Walker) Date: Mon Nov 21 15:40:05 2005 Subject: [development] Encouraging Collaboration In-Reply-To: <000401c5eeaf$1422ce40$6700a8c0@JEATON2DEV> References: <000401c5eeaf$1422ce40$6700a8c0@JEATON2DEV> Message-ID: <4381EA6A.90804@walkah.net> On 11/21/05 10:20 AM, Jeff Eaton wrote: >> On 11/19/05 2:39 AM, Dries Buytaert wrote: >>> James is listed as the blogapi module maintainer, but he somewhat >>> stopped caring about it, I think. He didn't look at any of >> the recent >>> blogapi.module patches. In my book, James stopped doing core >>> development months ago. >>> >> Say what?? > > I can say first-hand that James was in fact involved in the > troubleshooting and fixing of the last round of blogapi patches. Even > when he wasn't directly involved in the threads for a while, he was > coordinating with at least a couple of us about the issues via irc. yeah, we're all good. I think Dries had too much sun in Barcelona ;) -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net From vernon-drupal at mauery.com Mon Nov 21 16:00:09 2005 From: vernon-drupal at mauery.com (Vernon Mauery) Date: Mon Nov 21 15:56:47 2005 Subject: [development] One core, many distributions In-Reply-To: <43816C4D.3070007@tejasa.com> References: <437F6F91.40600@wanadoo.es> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> <200511202359.53055.larry@garfieldtech.com> <43816C4D.3070007@tejasa.com> Message-ID: <4381EF09.1000201@mauery.com> Moshe Weitzman wrote: >> See, my problem with pathauto is not the auto-generation, it's that >> putting 1 million entries into the path_alias table is going to kill >> your system. Of course at that point, the numbers make more sense >> anyway (or some other numeric format, like issue # and then article # >> for a magazine, but still numeric). >> Really, though, I'm trying to avoid thinking of new and cool things >> for Drupal until after 4.7 ships. :-) > > > who says that they all need to go into a table? it is plausible to use > an url strategy like article/mytitle. when drupal receives that request, > it does a node_load(array('title' => mytitle)); But then you make title a unique field... > > From vlado at dikini.net Mon Nov 21 16:15:12 2005 From: vlado at dikini.net (vlado) Date: Mon Nov 21 16:15:17 2005 Subject: [development] One core, many distributions In-Reply-To: <4381EF09.1000201@mauery.com> References: <437F6F91.40600@wanadoo.es> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> <200511202359.53055.larry@garfieldtech.com> <43816C4D.3070007@tejasa.com> <4381EF09.1000201@mauery.com> Message-ID: <1132589712.8112.18.camel@localhost.localdomain> On Mon, 2005-11-21 at 08:00 -0800, Vernon Mauery wrote: > Moshe Weitzman wrote: > >> See, my problem with pathauto is not the auto-generation, it's that > >> putting 1 million entries into the path_alias table is going to kill > >> your system. Of course at that point, the numbers make more sense > >> anyway (or some other numeric format, like issue # and then article # > >> for a magazine, but still numeric). > >> Really, though, I'm trying to avoid thinking of new and cool things > >> for Drupal until after 4.7 ships. :-) > > > > > > who says that they all need to go into a table? it is plausible to use > > an url strategy like article/mytitle. when drupal receives that request, > > it does a node_load(array('title' => mytitle)); > > But then you make title a unique field... Or display a list of all nodes+teasers with the same title From gerhard at killesreiter.de Mon Nov 21 16:31:13 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Mon Nov 21 16:33:36 2005 Subject: [development] Another translation module In-Reply-To: References: <20051120183502.GA46384@web.ca> <4381C216.1070308@wanadoo.es> <20051121135641.GA62087@web.ca> Message-ID: <4381F651.3020707@killesreiter.de> Karoly Negyesi wrote: >> the first is closer to what i18n is doing (?), but using mod_rewrite >> means that Drupal itself can handle the path normally after that. > > > aye and making the module useless on hosts without mod_rewrite. > I would not consider this a major problem. Drupal already uses its SEO friendliness without mod_rewrite. Cheers, Gerhard From dries at buytaert.net Mon Nov 21 16:36:09 2005 From: dries at buytaert.net (Dries Buytaert) Date: Mon Nov 21 16:36:13 2005 Subject: [development] Encouraging Collaboration In-Reply-To: <4381EA6A.90804@walkah.net> References: <000401c5eeaf$1422ce40$6700a8c0@JEATON2DEV> <4381EA6A.90804@walkah.net> Message-ID: >> I can say first-hand that James was in fact involved in the >> troubleshooting and fixing of the last round of blogapi patches. Even >> when he wasn't directly involved in the threads for a while, he was >> coordinating with at least a couple of us about the issues via irc. > > yeah, we're all good. I think Dries had too much sun in Barcelona ;) Yes, I had. James did indeed work on blogapi.module; it just went under my radar while in Barcelona. -- Dries Buytaert :: http://www.buytaert.net/ From chris at tinpixel.com Mon Nov 21 16:50:38 2005 From: chris at tinpixel.com (Chris Johnson) Date: Mon Nov 21 16:50:42 2005 Subject: [development] One core, many distributions In-Reply-To: References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> Message-ID: <4381FADE.9090009@tinpixel.com> Liza Sabater wrote: > > On Nov 20 2005, at 10:30 PM, Andre Molnar wrote: > >> p.s. Am I the only one that sees beauty in the simplicity of >> example.com/node/13 meaning the 13th node of content on a site - and >> node/1000345 being the 1,000,345th node on a site... and am I the >> only one that thinks 1 million aliases might be a bit silly to >> generate automatically? > > > yes. > I prefer a dev list with as little noise as possible, but in this case, I think this needs to be said: No, Andre is not the only sees that simplicity and not the only who thinks 1 million automatic aliases might be silly. I agree with Andre. Liza seems to be saying "yes, Andre is the only one who thinks that way" but perhaps it was just sloppy use of English and she meant "yes, I agree with Andre." ..chrisxj From rob at web.ca Mon Nov 21 17:31:31 2005 From: rob at web.ca (Rob Ellis) Date: Mon Nov 21 17:31:33 2005 Subject: [development] Another translation module In-Reply-To: <4381F651.3020707@killesreiter.de> References: <20051120183502.GA46384@web.ca> <4381C216.1070308@wanadoo.es> <20051121135641.GA62087@web.ca> <4381F651.3020707@killesreiter.de> Message-ID: <20051121173131.GA22183@web.ca> On Mon, Nov 21, 2005 at 05:31:13PM +0100, Gerhard Killesreiter wrote: > Karoly Negyesi wrote: > > >>the first is closer to what i18n is doing (?), but using mod_rewrite > >>means that Drupal itself can handle the path normally after that. > > > > > >aye and making the module useless on hosts without mod_rewrite. > > > > I would not consider this a major problem. Drupal already uses its SEO > friendliness without mod_rewrite. If mod_rewrite isn't available, it uses ?l=xx -- like Drupal's ?q=... mod_rewrite's only used for nicer paths. - rob -- Rob Ellis From fabio.varesano at gmail.com Mon Nov 21 19:15:07 2005 From: fabio.varesano at gmail.com (Fabio Varesano) Date: Mon Nov 21 18:14:53 2005 Subject: [development] Securing Login: MD5 password hashing using javascript Message-ID: <43821CBB.2090806@gmail.com> Hi! I started this thread about MD5 password hashing thinking that should be useful for users. I posted to this mail-list ant to http://drupal.org/node/36793. But I received only few comments on the feature request... so I was thinking that nobody were interested on it... Instead on this mailing list (which I did't read for some time) discussion was live.. So on http://drupal.org/node/36793 there is the patch (one week cvs) which is a beginning of implementation (still not working) of a challenge-response auth. Hope someone still interested in this. Fabio From adrinux at gmail.com Mon Nov 21 21:34:58 2005 From: adrinux at gmail.com (Adrian Simmons) Date: Mon Nov 21 21:35:03 2005 Subject: [development] that admin theme (from money/ work point of view), call for arms? In-Reply-To: <200511202237.06060.ber@webschuur.com> References: <200511202237.06060.ber@webschuur.com> Message-ID: <43823D82.4020004@gmail.com> B?r Kessels wrote: > It shortens the themeing, or design of a site with over 750%. That's because you only made a quarter of a theme =P > That is an afternoon vs a week! That is something of a point though... But I still think separate admin/editor themes are bad for usability, even if they fix current usability problems caused by layout issues. Swings, roundabouts, all that. > And yes, I beleive it reduces usability, Damn, I should read ahead before commenting. > Anyone who wats to jump on this boat Sounds like Adrian once again has the boat planned, if not built. I suspect the best solution in usability terms would be something more like a desktop application, with pop-ups (maybe iframes) and all sorts of other stuff when you want to edit or make admin changes, but with current technologies doing that sort of stuff means supporting a narrow set of browsers. -- adrinux (aka Adrian Simmons) e-mail AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com From rob at robshouse.net Mon Nov 21 22:31:47 2005 From: rob at robshouse.net (Robert Douglass) Date: Mon Nov 21 22:33:06 2005 Subject: [development] Drupal module (was One core, many distributions) In-Reply-To: <1132589712.8112.18.camel@localhost.localdomain> References: <437F6F91.40600@wanadoo.es> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> <200511202359.53055.larry@garfieldtech.com> <43816C4D.3070007@tejasa.com> <4381EF09.1000201@mauery.com> <1132589712.8112.18.camel@localhost.localdomain> Message-ID: <43824AD3.7000404@robshouse.net> While discussing what to ship with core I'd like to reiterate my vote to move the drupal.module to the contributions repository for this release. There are very few good uses of the "Drupal sites" feature, and the distributed login is, imo, a security risk. http://drupal.org/node/31716 -Robert From boris at bryght.com Mon Nov 21 22:41:56 2005 From: boris at bryght.com (Boris Mann) Date: Mon Nov 21 22:42:01 2005 Subject: [development] Drupal module (was One core, many distributions) In-Reply-To: <43824AD3.7000404@robshouse.net> References: <437F6F91.40600@wanadoo.es> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> <200511202359.53055.larry@garfieldtech.com> <43816C4D.3070007@tejasa.com> <4381EF09.1000201@mauery.com> <1132589712.8112.18.camel@localhost.localdomain> <43824AD3.7000404@robshouse.net> Message-ID: <7DB351EC-B889-498F-AF7F-87A251E04CED@bryght.com> On 21-Nov-05, at 2:31 PM, Robert Douglass wrote: > While discussing what to ship with core I'd like to reiterate my > vote to move the drupal.module to the contributions repository for > this release. There are very few good uses of the "Drupal sites" > feature, and the distributed login is, imo, a security risk. > > http://drupal.org/node/31716 Once we take it out, it's hard to get back in, especially as we talked about the various "phone home" features to gather statistics on installed modules. I would be in favour of keeping the hooks for login/authentication maintained within the drupal module, and the actual implementation moved to something like drupalauth.module. Or we could just fix it :P -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com From drumm at delocalizedham.com Mon Nov 21 22:04:22 2005 From: drumm at delocalizedham.com (Neil Drumm) Date: Mon Nov 21 22:46:59 2005 Subject: [development] Drupal module (was One core, many distributions) In-Reply-To: <7DB351EC-B889-498F-AF7F-87A251E04CED@bryght.com> References: <437F6F91.40600@wanadoo.es> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> <200511202359.53055.larry@garfieldtech.com> <43816C4D.3070007@tejasa.com> <4381EF09.1000201@mauery.com> <1132589712.8112.18.camel@localhost.localdomain> <43824AD3.7000404@robshouse.net> <7DB351EC-B889-498F-AF7F-87A251E04CED@bryght.com> Message-ID: <43824466.4000609@delocalizedham.com> Boris Mann wrote: > I would be in favour of keeping the hooks for login/authentication > maintained within the drupal module, and the actual implementation > moved to something like drupalauth.module. +1 > Or we could just fix it :P -- Neil Drumm http://delocalizedham.com/ From dries.buytaert at gmail.com Tue Nov 22 08:39:19 2005 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Tue Nov 22 08:39:15 2005 Subject: [development] New mailing list: translations@drupal.org Message-ID: <71779FDA-FDA7-4E9D-857F-A809D07C3420@buytaert.net> Hello world, a new mailing list has been created: translations@drupal.org. The goal of the mailing list is to discuss and coordinate everything 'translations'. The list is open to all, but I'll explicitly invite everyone who has the 'Drupal translator' checkbox checked in their user profile at drupal.org. If you want to be on the mailing list, you should accept the invitation. If you don't have the 'Drupal translator' checkbox checked in your user profile at drupal.org, you can subscribe at http://drupal.org/ mailing-lists/ or http://lists.drupal.org/. -- Dries Buytaert :: http://www.buytaert.net/ From gerhard at killesreiter.de Tue Nov 22 08:42:46 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Tue Nov 22 08:45:10 2005 Subject: [development] New mailing list: translations@drupal.org In-Reply-To: <71779FDA-FDA7-4E9D-857F-A809D07C3420@buytaert.net> References: <71779FDA-FDA7-4E9D-857F-A809D07C3420@buytaert.net> Message-ID: <4382DA06.1070806@killesreiter.de> Dries Buytaert wrote: > a new mailing list has been created: translations@drupal.org. The > goal of the mailing list is to discuss and coordinate everything > 'translations'. > Yay! Can you make me a moderator of that list so that I can see how many people joined and help with the running of that list? I would not mind becoming the admin to take it off your plate. Cheers, Gerhard From gerhard at killesreiter.de Tue Nov 22 09:12:33 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Tue Nov 22 09:14:55 2005 Subject: [development] New mailing list: translations@drupal.org In-Reply-To: <4382DA06.1070806@killesreiter.de> References: <71779FDA-FDA7-4E9D-857F-A809D07C3420@buytaert.net> <4382DA06.1070806@killesreiter.de> Message-ID: <4382E101.8020209@killesreiter.de> Gerhard Killesreiter wrote: > Dries Buytaert wrote: > >> a new mailing list has been created: translations@drupal.org. The >> goal of the mailing list is to discuss and coordinate everything >> 'translations'. >> > > Yay! Can you make me a moderator of that list so that I can see how > many people joined and help with the running of that list? Seems that already happened. :) Now I just need a password. Cheers, Gerhard From ber at webschuur.com Tue Nov 22 17:27:22 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Tue Nov 22 09:27:34 2005 Subject: [development] New mailing list: translations@drupal.org In-Reply-To: <71779FDA-FDA7-4E9D-857F-A809D07C3420@buytaert.net> References: <71779FDA-FDA7-4E9D-857F-A809D07C3420@buytaert.net> Message-ID: <200511221827.22750.ber@webschuur.com> I once read (but forgot to bookmark) a quote from some OSS hot-shot: "In OSS the best way to measure the quality and maturity of a project is to measure the activity of the translation community" I think this indicates Drupal, again, made a step up that ladder today. Op dinsdag 22 november 2005 09:39, schreef Dries Buytaert: > Hello world, > > a new mailing list has been created: translations@drupal.org. The > goal of the mailing list is to discuss and coordinate everything > 'translations'. > > The list is open to all, but I'll explicitly invite everyone who has > the 'Drupal translator' checkbox checked in their user profile at > drupal.org. If you want to be on the mailing list, you should accept > the invitation. > > If you don't have the 'Drupal translator' checkbox checked in your > user profile at drupal.org, you can subscribe at http://drupal.org/ > mailing-lists/ or http://lists.drupal.org/. > > -- > Dries Buytaert :: http://www.buytaert.net/ From feher.janos at mindworks.hu Tue Nov 22 11:45:30 2005 From: feher.janos at mindworks.hu (=?ISO-8859-1?Q?Feh=E9r_J=E1nos?=) Date: Tue Nov 22 11:45:55 2005 Subject: [development] One core, many distributions In-Reply-To: References: <437F6F91.40600@wanadoo.es> Message-ID: <1132659930.5697.7.camel@pulsar.devel.mindworks.hu> Hi, I'm new on the list. I've subscribed to this list because I'd like to contribute Drupal if I can get enough knowledge and time. 2005-11-19, szo keltez?ssel 19.52-kor Karoly Negyesi ezt ?rta: > Here is a proposed core set: > > block > comment I think, i18n functions should be handled by the core. The problem of a multilanguage site is too global to handle by an outside module. Just look to the ecommerce module (locations, zones for taxes, etc.) or node translations (there's no "good" association between the translation and the original node) or menu.module. You have to patch the core if you'd like to get the existing i18n to work. On the whole, I'd like to see i18n in the core. Bests, -- Aries From feher.janos at mindworks.hu Tue Nov 22 12:32:51 2005 From: feher.janos at mindworks.hu (=?ISO-8859-1?Q?Feh=E9r_J=E1nos?=) Date: Tue Nov 22 12:33:14 2005 Subject: [development] Another translation module In-Reply-To: <4381C216.1070308@wanadoo.es> References: <20051120183502.GA46384@web.ca> <4381C216.1070308@wanadoo.es> Message-ID: <1132662771.5697.24.camel@pulsar.devel.mindworks.hu> Hi, 2005-11-21, h keltez?ssel 13.48-kor Jose A. Reyero ezt ?rta: > I've been looking at your module, mostly looking for some new ideas to > add into i18n module :-) -Btw, the .htaccess part of the patch doesn't apply Do you have any specification or detailed roadmap about the future of i18n? > links is quite different. Actually, I was thinking of adding some > options about that 'links to node translations' in next version of i18n > module. Absolutely agreed. Can we think about it as an other (kind) implementation of revisioning system? > Besides that, I think both modules share the same goal, and quite > similar approach. So, could you tell me the features you are missing in > i18n.module so maybe we can work out something together? Relations between the original version and the translated one, not for only nodes but menu, taxonomy, etc. My problem is that, when I switch to an other language, the node / taxonomy system won't switch. There's no real relation between the original and the translated site, they're separated. But i18n are not just about translation, but date, currency, eg. formats, regions, countries, counties, taxes, currency rates and much much more. The developers should take care about that. Because it's a large problem, you should specify it before you try to implement them. Bests, -- Aries From jareyero at wanadoo.es Tue Nov 22 12:47:52 2005 From: jareyero at wanadoo.es (Jose A. Reyero) Date: Tue Nov 22 12:48:03 2005 Subject: [development] One core, many distributions In-Reply-To: <1132659930.5697.7.camel@pulsar.devel.mindworks.hu> References: <437F6F91.40600@wanadoo.es> <1132659930.5697.7.camel@pulsar.devel.mindworks.hu> Message-ID: <43831378.9060501@wanadoo.es> Hi Feh?r, Feh?r J?nos wrote: >I think, i18n functions should be handled by the core. The problem >of a multilanguage site is too global to handle by an outside module. > > I agree. I am the module maintainer. >Just look to the ecommerce module (locations, zones for taxes, etc.) >or node translations (there's no "good" association between the >translation and the original node) or menu.module. You have to patch >the core if you'd like to get the existing i18n to work. > > > The next version -4.7- won't need patches anymore -unless we want to go for some new features, of course... >On the whole, I'd like to see i18n in the core. > > Well, that one, let's take it easy. The current i18n.module has too many hacks and workarounds to avoid core patches, and would need to be reworked to be a core module. But we are making progress :-) Quite slowly though :-( Hope to see you around helping and supporting the idea of 'multilingual Drupal' -whatever form -module, core...- it takes at the end :-) Cheers, Jose >Bests, > > From jazepstein at gmail.com Tue Nov 22 12:50:28 2005 From: jazepstein at gmail.com (Jeremy Epstein) Date: Tue Nov 22 12:50:30 2005 Subject: [development] One core, many distributions In-Reply-To: <200511210322.21751.larry@garfieldtech.com> References: <437F6F91.40600@wanadoo.es> <200511210943.52150.ber@webschuur.com> <200511210322.21751.larry@garfieldtech.com> Message-ID: On 11/21/05, Larry Garfield wrote: > Actually, I'd suggest something even easier. In 4.7, there's a menu settings > fieldset for every node. First, expand that to tie to just ONE menu instead > of all of them, for size reasons. Call that menu "Site Structure" (or > "Navigation" ). Then any page that gets put into that menu automagically > gets a dynamic alias (read: not stored in path_alias) of that menu location. > So a node with ID 47 called "stuff" that is placed in the menu with parent: > > Site Menu > mysection > mysubsection > > will be accessible via both node/47 AND mysection/mysubsection/stuff. I've played around with this idea of "dynamically constructed URLs" quite a bit in Drupal, and my conclusion, at the end of the day, is that they're more trouble than it's worth. The biggest problem is performance: the URL is parsed IN easily, because only the part after the last slash ('/') needs to be processed; but when the URL gets printed OUT (i.e. through the url() or l() function), the system has to crawl up the menu tree, from the current page through all its parents, and find the URL for each ancestor before joining them all together with slashes. This is how my own site's URL handling system works - I developed it just before pathauto came out (almost a year ago!) - you can read all about it in my article: http://www.greenash.net.au/posts/thoughts/hierarchical_url_aliasing The above URL is an example that shows the performance problems I was just talking about. Another problem is unique URLs: with constructed URLs, every part of the URL (where a 'part' is the bit between each slash) has to be unique for every URL on the site - this problem can be avoided, but only with even more sacrifice in performance. Basically, I consider my approach of constructing URLs by walking up the menu tree to be the wrong approach, particularly if performance is critical and the site has many nodes. Despite seeming 'less right' (IMO), the pathauto approach of static aliases is simpler and scales better. It also fits in with the current core system, whereas my approach requires patching the core in order to work. Although I'm a huge fan of pathauto, and of Drupal's support for configurable URLs in general, I don't think that pathauto belongs in core. I also don't agree with the idea that users should never see a node ID: this is like saying that book readers should never see an ISBN, or that people who buy electronics should never see the model number. Like these things, a node ID is sometimes useful, even for an end user; but also like these things, a node ID should be made as inconspicuous as possible, and it should still be there for users that look for it. Rather than moving pathauto to core, I'd like to keep in the spirit of Adrian's "API fever", and suggest that a "path API" would be a better alternative for core. This would allow more advanced features, such as overriding path aliases, bringing back the conf_url_rewrite() type functionality (or has it never left?), etc. Jaza. From jazepstein at gmail.com Tue Nov 22 12:57:02 2005 From: jazepstein at gmail.com (Jeremy Epstein) Date: Tue Nov 22 12:57:04 2005 Subject: [development] One core, many distributions In-Reply-To: References: <437F6F91.40600@wanadoo.es> Message-ID: On 11/20/05, Karoly Negyesi wrote: > Here is a proposed core set: > > block > comment > filter > help > locale (because this lets you change strings so its always useful) > menu > node > path > search > story > system > taxonomy > throttle > upload > user > watchdog This is great: all those other modules SHOULD be moved out of core. But what concerns me is that they don't just get pulled out of core, and dumped straight into the spaghetti pit that is contrib ATM. We have to set up the 'endorsed modules' system first, so that these extra modules (e.g. forum, blog, aggregator, book) have a home to go to, rather than risk them getting 'lost in contrib'. These modules are currently (despite being too domain-specific for core) well-maintained and constantly improved, and this is because they're in core. We have to ensure that when they leave core, they're still in a place where this high-maintenance requirement continues. Jaza. From drupal-devel at istyledthis.nl Tue Nov 22 13:28:20 2005 From: drupal-devel at istyledthis.nl (Stefan) Date: Tue Nov 22 13:28:28 2005 Subject: [development] One core, many distributions In-Reply-To: References: <437F6F91.40600@wanadoo.es> Message-ID: <42E27BE2-C5CD-437D-A5FC-495E8BDDAB0C@istyledthis.nl> Op 22-nov-2005, om 13:57 heeft Jeremy Epstein het volgende geschreven: > On 11/20/05, Karoly Negyesi wrote: >> Here is a proposed core set: >> >> block >> comment >> filter >> help >> locale (because this lets you change strings so its always useful) >> menu >> node >> path >> search >> story >> system >> taxonomy >> throttle >> upload >> user >> watchdog > > This is great: all those other modules SHOULD be moved out of core. > But what concerns me is that they don't just get pulled out of core, > and dumped straight into the spaghetti pit that is contrib ATM. We > have to set up the 'endorsed modules' system first, so that these > extra modules (e.g. forum, blog, aggregator, book) have a home to go > to, rather than risk them getting 'lost in contrib'. These modules are > currently (despite being too domain-specific for core) well-maintained > and constantly improved, and this is because they're in core. We have > to ensure that when they leave core, they're still in a place where > this high-maintenance requirement continues. Well, the fact is that when a module doesn't get updated/improved the usage of the module is probably questionable.. Also the list above does still point to a certain direction of sites. I would vote for a light-weight core with even less modules and become a broader base for even more kind of websites, like: - block; - comment; - filter; - locale; - menu; - node; - path; - search; - story; - system; - taxonomy; - user; - watchdog. you see that help and throttle are moved from the list. Help because it points to newbies. Advanced users don't need it IMO, but I'm not very sure of this decision. Maybe it's better to display help by default, for everybody who's new. the throttle.module is only interesting and usable by high-traffic sites like kerneltrap.org and/or drupal.org-a-like sites. IMO it's too much for core, because there are lot's of people who use drupal for their own personal site and small business sites. the throttle.module is a little bit of an overkill for sites like that. Just some of my thoughts about this topic... --- Stefan Nagtegaal Drupal-Devel@iStyledThis.nl Drupal Development Mailinglist From rob at web.ca Tue Nov 22 13:51:20 2005 From: rob at web.ca (Rob Ellis) Date: Tue Nov 22 13:51:23 2005 Subject: [development] Another translation module In-Reply-To: <1132662771.5697.24.camel@pulsar.devel.mindworks.hu> References: <20051120183502.GA46384@web.ca> <4381C216.1070308@wanadoo.es> <1132662771.5697.24.camel@pulsar.devel.mindworks.hu> Message-ID: <20051122135120.GA21017@web.ca> On Tue, Nov 22, 2005 at 01:32:51PM +0100, Feh?r J?nos wrote: > Hi, > > 2005-11-21, h keltez?ssel 13.48-kor Jose A. Reyero ezt ?rta: > > I've been looking at your module, mostly looking for some new ideas to > > add into i18n module :-) -Btw, the .htaccess part of the patch doesn't apply > > Do you have any specification or detailed roadmap about the future of > i18n? > > > links is quite different. Actually, I was thinking of adding some > > options about that 'links to node translations' in next version of i18n > > module. > > Absolutely agreed. Can we think about it as an other (kind) > implementation of revisioning system? > > > Besides that, I think both modules share the same goal, and quite > > similar approach. So, could you tell me the features you are missing in > > i18n.module so maybe we can work out something together? > > Relations between the original version and the translated one, not for > only nodes but menu, taxonomy, etc. That's one of the goals for the 'tr' module... fields for translating menu items are on the regular menu edit form, fields for translating taxonomy terms are on the taxonomy term form, node translation links are available when you view nodes, you can filter by language in the regular content admin interface. > My problem is that, when I switch to an other language, the node / > taxonomy system won't switch. There's no real relation between the > original and the translated site, they're separated. 'tr' uses generated links, content switching, and relations in the menu system to maintain those connections. Menu translation, where translated menu items link to translated content, is key. > But i18n are not just about translation, but date, currency, eg. > formats, regions, countries, counties, taxes, currency rates and > much much more. The developers should take care about that. Because > it's a large problem, you should specify it before you try to implement > them. If you get the php system locale set correctly for the current language, php already has some functionality for handling locale differences that can be used in the template system (especially easy with phptemplates). E.g., you can use strftime() to generate local dates, etc. And if you know the requested language in the template, you can use if/else to make appropriate changes. I think off-loading a lot of the per-locale customization to templates and custom filters makes sense. I don't think you need to plan it all out in advance. - Rob -- Rob Ellis From feher.janos at mindworks.hu Tue Nov 22 13:59:31 2005 From: feher.janos at mindworks.hu (=?ISO-8859-1?Q?Feh=E9r_J=E1nos?=) Date: Tue Nov 22 13:59:49 2005 Subject: [development] One core, many distributions In-Reply-To: <43831378.9060501@wanadoo.es> References: <437F6F91.40600@wanadoo.es> <1132659930.5697.7.camel@pulsar.devel.mindworks.hu> <43831378.9060501@wanadoo.es> Message-ID: <1132667971.5697.31.camel@pulsar.devel.mindworks.hu> 2005-11-22, k keltez?ssel 13.47-kor Jose A. Reyero ezt ?rta: > Well, that one, let's take it easy. The current i18n.module has too many > hacks and workarounds to avoid core patches, and would need to be > reworked to be a core module. > But we are making progress :-) Quite slowly though :-( > > Hope to see you around helping and supporting the idea of 'multilingual > Drupal' -whatever form -module, core...- it takes at the end :-) I'd like to help, that's why I ask you to write down what do you think about the future of the i18n. It would helpful to split the tasks into parts. Bests, -- Aries From jeremy at kerneltrap.org Tue Nov 22 14:03:06 2005 From: jeremy at kerneltrap.org (Jeremy Andrews) Date: Tue Nov 22 14:02:01 2005 Subject: [development] One core, many distributions In-Reply-To: <42E27BE2-C5CD-437D-A5FC-495E8BDDAB0C@istyledthis.nl> References: <437F6F91.40600@wanadoo.es> <42E27BE2-C5CD-437D-A5FC-495E8BDDAB0C@istyledthis.nl> Message-ID: <20051122090306.3a2ff3b5.jeremy@kerneltrap.org> On Tue, 22 Nov 2005 14:28:20 +0100 Stefan wrote: > the throttle.module is only interesting and usable by > high-traffic sites like kerneltrap.org and/or > drupal.org-a-like sites. IMO it's too much for core, > because there are lot's of people who use drupal for their > own personal site and small business sites. the > throttle.module is a little bit of an overkill for sites > like that. The throttle is useful to sites that have limited resources and usually are not that busy. It is actually less useful to consistently high-traffic sites, as by necessity they will already have the required infrastructure to survive high loads. The throttle works well for a website that's on a shared host with limited CPU and bandwidth, that usually only gets a handful of visitors, and then is suddenly Slashdotted. Of course, it will only help in that case if it has been enabled and properly configured. Cheers, -Jeremy From occy at occy.net Tue Nov 22 14:43:49 2005 From: occy at occy.net (Trae McCombs) Date: Tue Nov 22 14:43:54 2005 Subject: [development] Building Theme Documentation, Need Help. Message-ID: <43832EA5.4000201@occy.net> Hi everyone, I'm trying to whip up some documentation that will help the average person who is new to Drupal Themeing get started. I have come up with a few questions they might have, but I was wondering if you guys might know of a few more. 1. How do I change colors in my theme? 2. How do I change the layout of my theme? 3. How can I manage inconsistancy in the different themes? 4. How do I solve browser compatibility issues? 5. What is a Theme Engine? Etc... These are just a few questions, but I would love to hear of more from you guys(and gals) as to what you feel people want to know. Also, for those of you out there who are just starting to theme, feel free to put your questions in the ring. As always you can find me on #cstheme (The CivicSpace Theme Channel) on irc.freenode.net Thanks in advance, Trae -- Trae "occy" McCombs || http://occy.net/ Founder - Themes.org // Linux.com CivicSpaceLabs - http://civicspacelabs.org/ From prolibertine at gmail.com Tue Nov 22 14:53:00 2005 From: prolibertine at gmail.com (prolibertine) Date: Tue Nov 22 14:57:41 2005 Subject: [development] i want to know how to add friend web link in drupal Message-ID: <438330CC.7090803@gmail.com> i want to add some friend link,but i can not find where to do that who can tell me thanks From admin at authentic-empowerment.net Tue Nov 22 17:54:16 2005 From: admin at authentic-empowerment.net (Charles (Chuck) Mattice) Date: Tue Nov 22 17:58:48 2005 Subject: [development] Building Theme Documentation, Need Help. In-Reply-To: <43832EA5.4000201@occy.net> References: <43832EA5.4000201@occy.net> Message-ID: <43835B48.9050605@authentic-empowerment.net> One area I have trouble with is the stylesheets. I think this should be included for those of us that are css noobie. Trae McCombs wrote: > Hi everyone, > > I'm trying to whip up some documentation that will help the average > person who is new to Drupal Themeing get started. I have come up with > a few questions they might have, but I was wondering if you guys might > know of a few more. > > 1. How do I change colors in my theme? > 2. How do I change the layout of my theme? > 3. How can I manage inconsistancy in the different themes? > 4. How do I solve browser compatibility issues? > 5. What is a Theme Engine? > > Etc... > > These are just a few questions, but I would love to hear of more from > you guys(and gals) as to what you feel people want to know. Also, for > those of you out there who are just starting to theme, feel free to > put your questions in the ring. > > As always you can find me on #cstheme (The CivicSpace Theme Channel) > on irc.freenode.net > > Thanks in advance, > Trae > From blogdiva at culturekitchen.com Tue Nov 22 18:23:20 2005 From: blogdiva at culturekitchen.com (Liza Sabater) Date: Tue Nov 22 18:23:28 2005 Subject: [development] Building Theme Documentation, Need Help. In-Reply-To: <43835B48.9050605@authentic-empowerment.net> References: <43832EA5.4000201@occy.net> <43835B48.9050605@authentic-empowerment.net> Message-ID: Trae, Code snippets babe. Do you know how template for MT or WordPress? Can we talk themeing on those terms? / liza On Nov 22 2005, at 12:54 PM, Charles (Chuck) Mattice wrote: > One area I have trouble with is the stylesheets. I think this > should be included for those of us that are css noobie. > > Trae McCombs wrote: > >> Hi everyone, >> >> I'm trying to whip up some documentation that will help the >> average person who is new to Drupal Themeing get started. I have >> come up with a few questions they might have, but I was wondering >> if you guys might know of a few more. >> >> 1. How do I change colors in my theme? >> 2. How do I change the layout of my theme? >> 3. How can I manage inconsistancy in the different themes? >> 4. How do I solve browser compatibility issues? >> 5. What is a Theme Engine? >> >> Etc... >> >> These are just a few questions, but I would love to hear of more >> from you guys(and gals) as to what you feel people want to know. >> Also, for those of you out there who are just starting to theme, >> feel free to put your questions in the ring. >> >> As always you can find me on #cstheme (The CivicSpace Theme >> Channel) on irc.freenode.net >> >> Thanks in advance, >> Trae >> > > From jeff at viapositiva.net Tue Nov 22 18:27:40 2005 From: jeff at viapositiva.net (Jeff Eaton) Date: Tue Nov 22 18:27:47 2005 Subject: [development] Building Theme Documentation, Need Help. In-Reply-To: Message-ID: <000e01c5ef92$6f36e760$6700a8c0@JEATON2DEV> One aspect of MT templating is a little goofy. Every different view -- 'category view', 'index page' view, 'individual entry' view, etc, is a template for a full and complete HTML page. Code for displaying each individual entry is duplicated in each template. I spent a few days setting up a series of template for my MT blog that mirrored PHPTemplate's system: a 'page' template, and a smaller repeating 'entry' template that's included. It takes work, though, and the system doesn't lend itself to that very easily. --Jeff > -----Original Message----- > From: Liza Sabater [mailto:blogdiva@culturekitchen.com] > Sent: Tuesday, November 22, 2005 12:23 PM > To: development@drupal.org > Subject: Re: [development] Building Theme Documentation, Need Help. > > > Trae, > > Code snippets babe. Do you know how template for MT or > WordPress? Can > we talk themeing on those terms? > > / liza > From blogdiva at culturekitchen.com Tue Nov 22 18:50:04 2005 From: blogdiva at culturekitchen.com (Liza Sabater) Date: Tue Nov 22 18:50:09 2005 Subject: [development] Building Theme Documentation, Need Help. In-Reply-To: <000e01c5ef92$6f36e760$6700a8c0@JEATON2DEV> References: <000e01c5ef92$6f36e760$6700a8c0@JEATON2DEV> Message-ID: <68FE9006-6128-4DBD-97C2-2E5C02817882@culturekitchen.com> Yeah, that's goofy but there are easy work arounds ... but that is not the point. The point is that it's really, really easy to use code snippets here and there to template one of those --not so in Drupal. So, how can we make it easy? After a nap or a good night's sleep I may be able to explain better :) On Nov 22 2005, at 01:27 PM, Jeff Eaton wrote: > One aspect of MT templating is a little goofy. Every different view -- > 'category view', 'index page' view, 'individual entry' view, etc, is a > template for a full and complete HTML page. Code for displaying each > individual entry is duplicated in each template. > > I spent a few days setting up a series of template for my MT blog that > mirrored PHPTemplate's system: a 'page' template, and a smaller > repeating 'entry' template that's included. It takes work, though, and > the system doesn't lend itself to that very easily. > > --Jeff > >> -----Original Message----- >> From: Liza Sabater [mailto:blogdiva@culturekitchen.com] >> Sent: Tuesday, November 22, 2005 12:23 PM >> To: development@drupal.org >> Subject: Re: [development] Building Theme Documentation, Need Help. >> >> >> Trae, >> >> Code snippets babe. Do you know how template for MT or >> WordPress? Can >> we talk themeing on those terms? >> >> / liza >> > > > From jeff at viapositiva.net Tue Nov 22 18:52:00 2005 From: jeff at viapositiva.net (Jeff Eaton) Date: Tue Nov 22 18:52:07 2005 Subject: [development] Building Theme Documentation, Need Help. In-Reply-To: <68FE9006-6128-4DBD-97C2-2E5C02817882@culturekitchen.com> Message-ID: <000f01c5ef95$d57f9140$6700a8c0@JEATON2DEV> Well, overriding how a given node is displayed with PHPTemplate is easy. Node.tpl.php is a pretty tiny file, and looking at it, it's obvious what's going on. Do you mean larger-scale stuff like page.tpl.php, or theme function overrides? --Jeff > -----Original Message----- > From: Liza Sabater [mailto:blogdiva@culturekitchen.com] > Sent: Tuesday, November 22, 2005 12:50 PM > To: development@drupal.org > Cc: Liza Sabater > Subject: Re: [development] Building Theme Documentation, Need Help. > > > Yeah, that's goofy but there are easy work arounds ... but that is > not the point. The point is that it's really, really easy to > use code > snippets here and there to template one of those --not so in Drupal. > So, how can we make it easy? After a nap or a good night's sleep I > may be able to explain better :) From puregin at puregin.org Tue Nov 22 20:04:44 2005 From: puregin at puregin.org (puregin) Date: Tue Nov 22 20:04:55 2005 Subject: [development] i want to know how to add friend web link in drupal In-Reply-To: <438330CC.7090803@gmail.com> References: <438330CC.7090803@gmail.com> Message-ID: On 22-Nov-2005, at 6:53 AM, prolibertine wrote: > i want to add some friend link,but i can not find where to do that > who can tell me > thanks What is a friend link? From mfredrickson at ppmns.org Tue Nov 22 20:14:52 2005 From: mfredrickson at ppmns.org (Mark Fredrickson) Date: Tue Nov 22 20:14:56 2005 Subject: [bcc][faked-from] Re: [development] i want to know how to add friend web link in drupal In-Reply-To: Message-ID: I replied to the original poster off-list, but I thought I'd just do a quick repeat: I suspect he/she is using buddylist.module. The way to add individuals to a buddylist is not especially obvious at first (I think the only way is to show a node in page view and have the buddylist block enabled. Oh, and you can do it from profile pages too, I think). I agree that the current method is a little obscure. I think a better way would be to have the 'add buddy' text appear after every name (authors, frequent posters, etc). I have a feature patch at: http://drupal.org/node/33373 It's waiting for an update to l() before I recode it to provide the functionality using l(). Mark Fredrickson E-Advocacy Manager Planned Parenthood Minnesota, North Dakota, South Dakota 1200 Lagoon Ave. Minneapolis, MN 55408 Ph: 612.821.6154 Fax: 612.825.3522 Email: mfredrickson@ppmns.org Are you a member of the Action Network? http://www.ppaction.org/ppmsd/join.tcl > From: puregin > Reply-To: > Date: Tue, 22 Nov 2005 12:04:44 -0800 > To: > Subject: [bcc][faked-from] Re: [development] i want to know how to add friend > web link in drupal > > > On 22-Nov-2005, at 6:53 AM, prolibertine wrote: > >> i want to add some friend link,but i can not find where to do that >> who can tell me >> thanks > > What is a friend link? > From puregin at puregin.org Tue Nov 22 20:23:20 2005 From: puregin at puregin.org (puregin) Date: Tue Nov 22 20:23:26 2005 Subject: [development] i want to know how to add friend web link in drupal In-Reply-To: References: Message-ID: <6B4F02DD-AA4C-4159-AF43-CC135AD1DC2D@puregin.org> Ah! It's all clear to me now.... thanks! Djun From nedjo at islandnet.com Wed Nov 23 00:18:38 2005 From: nedjo at islandnet.com (Nedjo Rogers) Date: Wed Nov 23 00:18:41 2005 Subject: [development] please review patch for sorting & categorizing modules Message-ID: <004401c5efc3$7394a5f0$6400a8c0@family> As part of CivicSpace Labs contributions to drupal.org, I've been working on introducing into the project module the ability to browse projects by multiple criteria (date, category, etc.). I've posted a patch at http://drupal.org/node/33803, including a link to a demo site (with only a couple of sample projects). Reviews, please! Thanks, Nedjo From agentrickard at gmail.com Wed Nov 23 04:10:57 2005 From: agentrickard at gmail.com (Ken Rickard) Date: Wed Nov 23 04:10:59 2005 Subject: [development] Re: One core, many distributions Message-ID: <25b45da00511222010m3bcb894fhd4c098e952a3e093@mail.gmail.com> I've been deep in Drupal planning and development (using 4.6.3) for a prototype site that extends the experiments that my company (www.morris.com) started on BlufftonToday.com. I just took me a good hour to catch up on the devel list, and here are some thoughts that I hope are helpful. And remember, I know PHP and MySQL, but haven't used my CVS account 'cause i need a few hours to spare to learn how cvs works (so there's my devel background in the open). We're likely to be dedicating more resources to the platform if our tests go well for a coupe of reasons: -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051123/16d6b308/attachment-0001.htm From agentrickard at gmail.com Wed Nov 23 04:30:17 2005 From: agentrickard at gmail.com (Ken Rickard) Date: Wed Nov 23 04:30:19 2005 Subject: [development] Re: One core, many distributions Message-ID: <25b45da00511222030n2d29bdetb8a1365aa7d165fd@mail.gmail.com> Sorry 'bout that last one. :-( Stupid Gmail. Anyway, we came to Drupal to run BlufftonToday precisely because core is compact and stable. The module system is a big plus, but managing contributions is a big issue. For our current project, I've been selecting and testing modlues against our core environment, noting the conflicts (not to pick on one, but, for example, events.module and sections.module don't play together). I am acting as gatekeeper for all module installs for the project. If I sanction it, we install it. An officially maintained list of 'approved' Drupal modules would be a huge bonus for the non-developer community. At the same time, I think that 'core' should be as lightweight as possible, even if my list of approved modules is up around 40 or so. I sort of like the auto-update from homebase (along the Apple or Mozilla models) but at the same time think that people who get into Drupal should realize that the platform takes some cultivating. You have to pay attention to module releases, security patches, etc. That's one reason why I like having 'throttle' in core. I don't use it, but it reminds me of an important aspect of site maintenance. Don't take this as a vote for or against any core modules, (though +1 for configurable URLs IMO). I'd also like to second the idea of a community gardener for Drupal.org, who maintains the list of contributions in a meaningful way (e.g. what modules have been tested in what environments; what the newest updates are). Sounds kinda fun to me. I'd be for Drupal "packages" of modules that set up common types of Drupal sites (art, education, projects, news), even if those packages are just lists of modules maintained by a trusted source. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051123/ae3b13fc/attachment.htm From agentrickard at gmail.com Wed Nov 23 04:32:59 2005 From: agentrickard at gmail.com (Ken Rickard) Date: Wed Nov 23 04:33:01 2005 Subject: [development] Usability testing Message-ID: <25b45da00511222032t695878e3sf789f6ca62f791c0@mail.gmail.com> Since I haven't been giving back through contrib, here's one: We did a usability test (filming users while they performed specificly assigned tasks) of BlufftonToday.com. The biggest problem our users had, as it turns out, was that there were often three or more ways to solve the same problem (do I post my meeting annoucenment in forums? as an event? in my blog? post it to the non-Drupal classifieds?) Now Drupal only runs 70% of the site, so not all the results are Drupal related. if the devel group is interested, I'll see if I can get some corporate permission to share the results (if not the actual video) for those who are interested. -- Ken Rickard drupal: agentken gmail: agentrickard -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051123/0b3df86c/attachment.htm From weitzman at tejasa.com Wed Nov 23 04:54:40 2005 From: weitzman at tejasa.com (Moshe Weitzman) Date: Wed Nov 23 04:54:47 2005 Subject: [development] Usability testing In-Reply-To: <25b45da00511222032t695878e3sf789f6ca62f791c0@mail.gmail.com> References: <25b45da00511222032t695878e3sf789f6ca62f791c0@mail.gmail.com> Message-ID: <4383F610.5090306@tejasa.com> > The biggest problem our users had, as it turns out, was that there were > often three or more ways to solve the same problem (do I post my meeting > annoucenment in forums? as an event? in my blog? post it to the > non-Drupal classifieds?) > > Now Drupal only runs 70% of the site, so not all the results are Drupal > related. if the devel group is interested, I'll see if I can get some > corporate permission to share the results (if not the actual video) for > those who are interested. thanks for the offer, Ken. IMO, there isn't much that the drupal development team can do to fix this problem. it is an information architecture problem first, and then Drupal can be used to skillfully implement your plan. expecting drupal to address this is unrealistic IMO. -moshe From prolibertine at gmail.com Wed Nov 23 04:53:13 2005 From: prolibertine at gmail.com (prolibertine) Date: Wed Nov 23 04:57:53 2005 Subject: [development] where to download more and more drupal themes Message-ID: <4383F5B9.4030404@gmail.com> i want to know where to download more drupal themes i see http://drupal.org/project/Themes/4.5 but it too less i want to found more for my website thanks From puregin at puregin.org Wed Nov 23 05:10:59 2005 From: puregin at puregin.org (puregin) Date: Wed Nov 23 05:11:05 2005 Subject: [development] where to download more and more drupal themes In-Reply-To: <4383F5B9.4030404@gmail.com> References: <4383F5B9.4030404@gmail.com> Message-ID: <91C67FFD-FE3F-4C29-AB6B-A34A843D99EC@puregin.org> On 22-Nov-2005, at 8:53 PM, prolibertine wrote: > i want to know where to download more drupal themes > i see http://drupal.org/project/Themes/4.5 but it too less > i want to found more for my website > thanks This kind of request should probably go to the 'support' list, support@drupal.org. If you are installing the latest release of Drupal, you probably want to look for themes at http://drupal.org/project/Themes The URL you gave is for Drupal version 4.5 themes. Regards, Djun From dan at drob.org Wed Nov 23 05:18:56 2005 From: dan at drob.org (Dan Robinson) Date: Wed Nov 23 05:19:04 2005 Subject: [development] Usability testing In-Reply-To: <4383F610.5090306@tejasa.com> References: <25b45da00511222032t695878e3sf789f6ca62f791c0@mail.gmail.com> <4383F610.5090306@tejasa.com> Message-ID: <4383FBC0.3080409@drob.org> >> The biggest problem our users had, as it turns out, was that there >> were often three or more ways to solve the same problem (do I post my >> meeting annoucenment in forums? as an event? in my blog? post it to >> the non-Drupal classifieds?) >> >> Now Drupal only runs 70% of the site, so not all the results are >> Drupal related. if the devel group is interested, I'll see if I can >> get some corporate permission to share the results (if not the actual >> video) for those who are interested. > > > thanks for the offer, Ken. > > IMO, there isn't much that the drupal development team can do to fix > this problem. it is an information architecture problem first, and > then Drupal can be used to skillfully implement your plan. expecting > drupal to address this is unrealistic IMO. Ken's comments are very interesting (and ring authentic to me). I understand and agree with Moshe that this is a problem that is not being dealt with by Drupal right now as an information architecture problem. However I also believe that there are solution sets that will deal with many common problems (like the one's that Ken has outlined). If we had another module "layer" and made the system easier for folks to create distros it would go a long way towards improving usability for a large number of users (IMHO). > > -moshe > From blogdiva at culturekitchen.com Wed Nov 23 06:16:05 2005 From: blogdiva at culturekitchen.com (Liza Sabater) Date: Wed Nov 23 06:16:09 2005 Subject: [development] One core, many distributions In-Reply-To: <4381FADE.9090009@tinpixel.com> References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> <4381FADE.9090009@tinpixel.com> Message-ID: <3EA1E24A-D998-4AE7-A0BD-6AE3BF21728E@culturekitchen.com> On Nov 21 2005, at 11:50, Chris Johnson wrote: > Liza seems to be saying "yes, Andre is the only one who thinks that > way" but perhaps it was just sloppy use of English and she meant > "yes, I agree with Andre." Heh. No, I did mean the first meaning. Don't get me wrong, I love most of the time how software developers think. It's sexy, but just like a lot of sexy stuff out there, it has somewhat to do with reality :) The way regular, non-software developers use Drupal seems to be very different from the way you guys conceive of it. I personally do not care about the url BUT the reality is that you will most likely get faster indexing of your sites by bots --and better stumble upon traffic-- if you have verbose links as opposed to those "node/ doohickey/numbers" system. It's not your fault or the users, it's just is. So having flexibility on how those links are created, right off the bat, is what Drupal ought to be striving for. Look, someone did a really bad, and I mean, really HORRIDLY BAD call when they decided to take out the sessions setting options for the 4.6 release. It was in 4.5, my site never logged me out and it seemed that a lot of people found it useful as well. Not only did y'all take it out, but it is nowhere stated in your documentation that this was taken out. And not only did you take it out but, guess what, a lot of people have grumbled about this on the support list (or so it seems), because it was not announced nor was there an option offered to deal with potential log-out problems. I had 5 people look at this problem on my site and one of them came across this story by diving into your support archives. And you did changes to the RSS system as well, and not for the good of the user but for the good of your geekatude. Rule #1 : If it aint broke, dont fix it. You broke so many rules about market strategy, usability and software development, I can't even fathom how you came to the conclusion this was a good idea. Then again, yes, I can fathom the logic just by the discussion we are having here. You think about the beauty of the code, the simplicity of your logic. That's nice and good. The problem is that it has nothing to do with reality. You are not thinking about the users --you are not really trying to find real world solutions for the people who are actually going to implement the product. Why does this have to be an either or set-up? Why not add pathauto to the core and give it as an option for people to implement during installation? It is sloppy thinking to say you know better because you are a developer. Earth to geeks : Software development is never ending, it is never done. You will never be satisfied ---treat your skill as a disease not as a gift. You do not have to release 4.7 ---- you are JONESING for a new coding high. And in the process, undermining many a vendor, web admin and end user by pushing into obsolescence their just installed site. If you have to release 4.7, go ahead and do it. But make sure that it is as flexible and user centric as possible so that you can stop, stand back and think of what better ways to implement the product as opposed to just talk about code as art. For that, there is always bitforms gallery [ www.bitforms.com ] and software and net art lists sites like Rhizome [ www.rhizome.org ] and The Thing [www.thing.net ]. Best, liza, who's been on the software art scene for far too long, sabater From blogdiva at culturekitchen.com Wed Nov 23 06:20:37 2005 From: blogdiva at culturekitchen.com (Liza Sabater) Date: Wed Nov 23 06:20:41 2005 Subject: [development] One core, many distributions In-Reply-To: <42E27BE2-C5CD-437D-A5FC-495E8BDDAB0C@istyledthis.nl> References: <437F6F91.40600@wanadoo.es> <42E27BE2-C5CD-437D-A5FC-495E8BDDAB0C@istyledthis.nl> Message-ID: <26FDE063-1C5D-4C04-A11F-97B87D01E007@culturekitchen.com> On Nov 22 2005, at 08:28, Stefan wrote: > Advanced users don't need it IMO, but I'm not very sure of this > decision. Maybe it's better to display help by default, for > everybody who's new. Sigh. Perfect example of what I was referring to in my previous email. / liza From dries at buytaert.net Wed Nov 23 06:23:36 2005 From: dries at buytaert.net (Dries Buytaert) Date: Wed Nov 23 06:23:45 2005 Subject: [development] Usability testing In-Reply-To: <4383FBC0.3080409@drob.org> References: <25b45da00511222032t695878e3sf789f6ca62f791c0@mail.gmail.com> <4383F610.5090306@tejasa.com> <4383FBC0.3080409@drob.org> Message-ID: <8B7DCCBF-4E24-49DB-81BF-148C80477A56@buytaert.net> > Ken's comments are very interesting (and ring authentic to me). I > understand and agree with Moshe that this is a problem that is not > being > dealt with by Drupal right now as an information architecture problem. > However I also believe that there are solution sets that will deal > with > many common problems (like the one's that Ken has outlined). If we > had > another module "layer" and made the system easier for folks to create > distros it would go a long way towards improving usability for a large > number of users (IMHO). Agreed. While this might not be Drupal's fault, I'm confident this is a common problem. If there is anything we can do to overcome common problems, I'm all ears. I, for one, am very much interested in the results of their study, as well as their proposed solution(s). -- Dries Buytaert :: http://www.buytaert.net/ From jeff at viapositiva.net Wed Nov 23 06:25:18 2005 From: jeff at viapositiva.net (Jeff Eaton) Date: Wed Nov 23 06:25:26 2005 Subject: [development] One core, many distributions In-Reply-To: <3EA1E24A-D998-4AE7-A0BD-6AE3BF21728E@culturekitchen.com> Message-ID: <000a01c5eff6$af59ac10$0300a8c0@mjolnir> >Why does this have to be an either or set-up? Why not add pathauto to >the core and give it as an option for people to implement during >installation? It is sloppy thinking to say you know better because >you are a developer. Liza, As someone who's a die-hard evangelist for pathauto, I'll be the first to say that it needs work before being unleashed on every single Drupal site. As others have noted, it gets unwieldy with large lists of nodes (say, 10,000) and it gets tremendously confused when your rules result in the same path for multiple pieces of content. There are other issues, too. They're certainly not insurmountable! But one of the things that keeps Drupal useful as a platform for developing web apps is the lean-and-mean highly-focused core. As others have noted, actual end-user installations will almost ALWAYS require additional contrib modules and tweaking. I think that incorporating the concept of pathauto into the core path.module is an awesome idea. Making sure it doesn't paint users into a corner is just as important, though. Does that make any sense? --Jeff From boris at bryght.com Wed Nov 23 06:42:34 2005 From: boris at bryght.com (Boris Mann) Date: Wed Nov 23 06:42:43 2005 Subject: [development] Usability testing In-Reply-To: <8B7DCCBF-4E24-49DB-81BF-148C80477A56@buytaert.net> References: <25b45da00511222032t695878e3sf789f6ca62f791c0@mail.gmail.com> <4383F610.5090306@tejasa.com> <4383FBC0.3080409@drob.org> <8B7DCCBF-4E24-49DB-81BF-148C80477A56@buytaert.net> Message-ID: <217A98B3-6301-4E5A-A746-E682A31C05F5@bryght.com> On 22-Nov-05, at 10:23 PM, Dries Buytaert wrote: >> Ken's comments are very interesting (and ring authentic to me). I >> understand and agree with Moshe that this is a problem that is not >> being >> dealt with by Drupal right now as an information architecture >> problem. >> However I also believe that there are solution sets that will deal >> with >> many common problems (like the one's that Ken has outlined). If >> we had >> another module "layer" and made the system easier for folks to create >> distros it would go a long way towards improving usability for a >> large >> number of users (IMHO). > > Agreed. While this might not be Drupal's fault, I'm confident this > is a common problem. If there is anything we can do to overcome > common problems, I'm all ears. I, for one, am very much interested > in the results of their study, as well as their proposed solution(s). I also think the answers would be interesting but also believe, much like custom themes and Jeff's great post (see http:// jeff.viapositiva.net/archives/2005/11/on_the_complexi.html), that the solutions will be very site/audience specific. Ken: at some point, we're going to want to work on a citizen journalism install profile...I'm surprised the concept didn't come up during the one core/many distributions (or maybe people were just waiting for me to harp on this :P ). Adrian's install system....actually, wait, that's the whole problem....Drupal's install system, which Adrian has been the main person working on, can/ will support the concept. Adrian and Drumm (his work on update system is hand in hand with install) are the two "maintainers/architects" currently...I'm sure they wouldn't be opposed to further assistance here. Continuing to look at optimizing core and making choices about what goes in/out is a somewhat useful discussion...but needs to be tempered by contributions. As evidenced by the pathauto discussion, there is hidden complexity between features/need (node IDs needn't be displayed) and performance (oops! pathauto may have some additional usability/management issues which need work before it makes it into core). So: in general, the group of us will act as gatekeepers to ensure that core remains stable and lean (perhaps leaner than usability might dictate) until code is mature enough. And: who's signing up to be the path.module maintainer(s)? A citizen journalism install profile would in essence have two audiences: one being the gardeners/editors of the site, geared toward managing users (troll issues etc.), highlighting/organizing/ moderating content, and some basic site administration. The other audience would be the potential citizen journalists and readers -- reading/being notified of content (from "main" posts to comments) of interest to them, seeing interfaces that bubble-up content (popular, highly rated, rated by their friends, etc.), and submitting base content types. At the very least, this is a custom front page and an explorative interface that hides initial complexity ("I'm just a news reader") but lets users easily get to more complexity as needed ("what is this whole submitting content thing? oh, this is easy..."). Man, this list is just like the old days, before the whole issues-to- the-list thing...lots of fun, and I'm excited and energized to be talking through some of these ideas. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com From blogdiva at culturekitchen.com Wed Nov 23 06:51:07 2005 From: blogdiva at culturekitchen.com (Liza Sabater) Date: Wed Nov 23 06:51:11 2005 Subject: [development] One core, many distributions In-Reply-To: <000a01c5eff6$af59ac10$0300a8c0@mjolnir> References: <000a01c5eff6$af59ac10$0300a8c0@mjolnir> Message-ID: On Nov 23 2005, at 01:25, Jeff Eaton wrote: > I think that incorporating the concept of pathauto into the core > path.module is an awesome idea. Making sure it doesn't paint users > into > a corner is just as important, though. Does that make any sense? Totally. And again, I don't think it has to be an either/or issue. Make it so people can choose at the moment of installation whether they want to have their links blurbed or not. Which means, stop a minute and think about how Drupal can take the CivicSpace installer and make it even yummier. Again, sexy can be as simple as making it easy to have multiple small or middle sized options as opposed to just one efficient yet not quite satisfying big one. / liza From blogdiva at culturekitchen.com Wed Nov 23 06:54:50 2005 From: blogdiva at culturekitchen.com (Liza Sabater) Date: Wed Nov 23 06:54:55 2005 Subject: [development] Fwd: CivicSpace timeout issue References: <5.1.1.6.0.20051123003239.025eea10@pop.rcn.com> Message-ID: I will be posting this as an issue. This is incomprehensible to me that nobody seems to have a straight answer to this log out problem. C'est la vie. / liza Begin forwarded message: > From: napier > Date: November 23 2005 12:40:46 EST > To: Liza Sabater > Subject: CivicSpace timeout issue > > This are the threads I looked at on drupal.org: > http://drupal.org/node/2974 > http://drupal.org/node/20002 > http://drupal.org/node/17303 > > I made this change in the sites/default/settings.php: > > ini_set('session.cookie_lifetime', 72000); > > I think we need a developer to tell us what's going on with this. > Maybe there are PHP or Apache settings we need to adjust as well. > > mark > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051123/3404ccfc/attachment.htm From dries.buytaert at gmail.com Wed Nov 23 09:30:15 2005 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Wed Nov 23 09:30:19 2005 Subject: [development] One core, many distributions In-Reply-To: <3EA1E24A-D998-4AE7-A0BD-6AE3BF21728E@culturekitchen.com> References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> <4381FADE.9090009@tinpixel.com> <3EA1E24A-D998-4AE7-A0BD-6AE3BF21728E@culturekitchen.com> Message-ID: <1B4206D7-4A29-4B71-8C71-674B3A336A00@buytaert.net> > Look, someone did a really bad, and I mean, really HORRIDLY BAD > call when they decided to take out the sessions setting options for > the 4.6 release. > You broke so many rules about market strategy, usability and > software development, I can't even fathom how you came to the > conclusion this was a good idea. Then again, yes, I can fathom the > logic just by the discussion we are having here. That clueless person would have been me. (Make no mistake, I don't regret that change.) > And you did changes to the RSS system as well, and not for the good > of the user but for the good of your geekatude. I don't know what RSS changes you are talking about. > You think about the beauty of the code, the simplicity of your > logic. That's nice and good. The problem is that it has nothing to > do with reality. You are not thinking about the users --you are not > really trying to find real world solutions for the people who are > actually going to implement the product. Please, either provide some constructive suggestions, learn how open source software development works, find a CMS that you like better, or pass the crack-pipe around so us idiotic geeks can share your unanimous insights on market strategy, usability, communication, software development and real world solutions. -- Dries Buytaert :: http://www.buytaert.net/ From gerhard at killesreiter.de Wed Nov 23 09:55:14 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Wed Nov 23 09:58:22 2005 Subject: [development] One core, many distributions In-Reply-To: <3EA1E24A-D998-4AE7-A0BD-6AE3BF21728E@culturekitchen.com> References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> <4381FADE.9090009@tinpixel.com> <3EA1E24A-D998-4AE7-A0BD-6AE3BF21728E@culturekitchen.com> Message-ID: <43843C82.7060704@killesreiter.de> Liza Sabater wrote: > On Nov 21 2005, at 11:50, Chris Johnson wrote: > >> Liza seems to be saying "yes, Andre is the only one who thinks that >> way" but perhaps it was just sloppy use of English and she meant >> "yes, I agree with Andre." > > > Heh. > > No, I did mean the first meaning. > > Don't get me wrong, I love most of the time how software developers > think. It's sexy, but just like a lot of sexy stuff out there, it has > somewhat to do with reality :) > > The way regular, non-software developers use Drupal seems to be very > different from the way you guys conceive of it. I personally do not > care about the url BUT the reality is that you will most likely get > faster indexing of your sites by bots --and better stumble upon > traffic-- if you have verbose links as opposed to those "node/ > doohickey/numbers" system. It's not your fault or the users, it's > just is. So having flexibility on how those links are created, right > off the bat, is what Drupal ought to be striving for. > > Look, someone did a really bad, and I mean, really HORRIDLY BAD call > when they decided to take out the sessions setting options for the > 4.6 release. It was in 4.5, my That option was actually taken out long before. It might have been in 4.4 but I think it was already removed there, at least if you are referring to the horrible little "remember me" checkbox. > site never logged me out and it seemed that a lot of people found it > useful as well. Not only did y'all take it out, but it is nowhere > stated in your documentation that this was taken out. And not only > did you take it out but, guess what, a lot of people have grumbled > about this on the support list (or so it seems), Yes, was great fun. > because it was not announced nor was there an option offered to > deal with potential log-out problems. I had 5 people look at this > problem on my site and one of them came across this story by diving > into your support archives. And you did changes to the RSS system as > well, and not for the good of the user but for the good of your > geekatude. > You show us that you ain't no clue. > Rule #1 : If it aint broke, dont fix it. > Teh horrible little checkbox thing was broken, that is why it was removed. > You broke so many rules about market strategy, usability and software > development, I can't even fathom how you came to the conclusion this > was a good idea. Then again, yes, I can fathom the logic just by the > discussion we are having here. > A discussion? You are biting the hand that codes your software. Very bad move. > You think about the beauty of the code, the simplicity of your > logic. That's nice and good. The problem is that it has nothing to do > with reality. You are not thinking about the users --you are not > really trying to find real world solutions for the people who are > actually going to implement the product. Right. Why on earth should we? Why should we give a damn about any of your problems? They are your problems after all, not ours. > Why does this have to be an either or set-up? Why not add pathauto to > the core and give it as an option for people to implement during > installation? Because we have many users that already whine about not being able to LOCK their tables and us evil developers using such a feature. because people insist on using hoisters that charge them 5 of whatever currency and the people still expect they can run kick-ass software with kick-ass features on their el-cheapo hosting. > It is sloppy thinking to say you know better because you are a > developer. Earth to No, it is just right. We know better because we simply know our software, the software it depends on, and so on. We are the Gods, you are the dust on our feet. > geeks : Software development is never ending, it is never done. You > will never be satisfied ---treat your skill as a disease not as a > gift. You do not have to release 4.7 ---- you are JONESING for a new > coding high. And in the process, undermining many a vendor, web admin > and end user by pushing into obsolescence their just installed site. > Again, why should we care? > If you have to release 4.7, go ahead and do it. But make sure that it > is as flexible and user centric as possible so that you can stop, > stand back and think of what better ways to implement the product as > opposed to just talk about code as art. For that, there is always > bitforms gallery [ www.bitforms.com ] and software and net art lists > sites like Rhizome [ www.rhizome.org ] and The Thing [www.thing.net ]. > You really, really have no clue. You should be a specimen at the no-clue museum. > Best, > liza, who's been on the software art scene for far too long, sabater Liza, I think we've had enough of you. Please close the door - from the outside. From feher.janos at mindworks.hu Wed Nov 23 11:19:38 2005 From: feher.janos at mindworks.hu (=?ISO-8859-1?Q?Feh=E9r_J=E1nos?=) Date: Wed Nov 23 11:19:57 2005 Subject: [development] Another translation module In-Reply-To: <20051122135120.GA21017@web.ca> References: <20051120183502.GA46384@web.ca> <4381C216.1070308@wanadoo.es> <1132662771.5697.24.camel@pulsar.devel.mindworks.hu> <20051122135120.GA21017@web.ca> Message-ID: <1132744778.6735.33.camel@pulsar.devel.mindworks.hu> 2005-11-22, k keltez?ssel 08.51-kor Rob Ellis ezt ?rta: > That's one of the goals for the 'tr' module... fields for translating > menu items are on the regular menu edit form, fields for translating > taxonomy terms are on the taxonomy term form, node translation links > are available when you view nodes, you can filter by language in > the regular content admin interface. I see. But why don't you extend the i18n.module? Jose said that the aproaches of the two module are the same. > > But i18n are not just about translation, but date, currency, eg. > > formats, regions, countries, counties, taxes, currency rates and > > much much more. The developers should take care about that. Because > > it's a large problem, you should specify it before you try to implement > > them. > > If you get the php system locale set correctly for the current language, > php already has some functionality for handling locale differences > that can be used in the template system (especially easy with > phptemplates). E.g., you can use strftime() to generate > local dates, etc. And if you know the requested language in the > template, you can use if/else to make appropriate changes. Ok, but these features can be useful for other modules (like ecommerce). These additions can be contributed extensions to the tr or i18n module, like flexinode contributions. > I think off-loading a lot of the per-locale customization to templates > and custom filters makes sense. I don't think you need to plan it all > out in advance. When I implement a site, I have to be sure that the technology won't be depreciated in the near future. I'd like to be sure. :) Bests, -- Aries From ber at webschuur.com Wed Nov 23 11:56:18 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Wed Nov 23 11:56:24 2005 Subject: [development] One core, many distributions In-Reply-To: <1132667971.5697.31.camel@pulsar.devel.mindworks.hu> References: <437F6F91.40600@wanadoo.es> <43831378.9060501@wanadoo.es> <1132667971.5697.31.camel@pulsar.devel.mindworks.hu> Message-ID: <200511231256.18248.ber@webschuur.com> Op dinsdag 22 november 2005 14:59, schreef Feh?r J?nos: > 2005-11-22, k keltez?ssel 13.47-kor Jose A. Reyero ezt ?rta: > > Well, that one, let's take it easy. The current i18n.module has too many > > hacks and workarounds to avoid core patches, and would need to be > > reworked to be a core module. > > But we are making progress :-) Quite slowly though :-( > > > > Hope to see you around helping and supporting the idea of 'multilingual > > Drupal' -whatever form -module, core...- it takes at the end :-) > > I'd like to help, that's why I ask you to write down what do you > think about the future of the i18n. It would helpful to split the > tasks into parts. Agreed. We all recognise Drupal clearly lacks any support in this region. But if you look around, you will see all the ingredients are there. It is "just" a matter of getting some cooks that can prepare those ingredients and make a nice dish from it. We, that is the people who want this supprt most, seem to all lack time and or skills to get this finished. Drupal itsself is very much developer oriented, while the biggest professional installations are all situated in the US. That makes the need for proper i18n rather small. US corporations dont need it, developers dont need it, they all talk english in the developer places. so, i think above all, we need something done. We need a renewed i18n for 4.7 and a group of active developers around that. Jos?, what do you think about makeing i18n maintained by a group, rather then only you? I am not saying you cannot do the job, don't get me wrong, I am just saying we need more hands to get this on rails and get a bunch of good solutions out the door for 4.7, Ber From weitzman at tejasa.com Wed Nov 23 13:23:40 2005 From: weitzman at tejasa.com (Moshe Weitzman) Date: Wed Nov 23 13:23:48 2005 Subject: [development] One core, many distributions In-Reply-To: <200511231256.18248.ber@webschuur.com> References: <437F6F91.40600@wanadoo.es> <43831378.9060501@wanadoo.es> <1132667971.5697.31.camel@pulsar.devel.mindworks.hu> <200511231256.18248.ber@webschuur.com> Message-ID: <43846D5C.9040204@tejasa.com> > so, i think above all, we need something done. We need a renewed i18n for 4.7 > and a group of active developers around that. Jos?, what do you think about > makeing i18n maintained by a group, rather then only you? I am not saying you > cannot do the job, don't get me wrong, I am just saying we need more hands to > get this on rails and get a bunch of good solutions out the door for 4.7, jose just stated that he would love some help. what kind of a solution is it to propose a committee? i think you proposed the same thing with theme system. IMO, the way to "get this on rails" is to make tickets for things that should change, and then work to close those tickets. skip the committee. From rob at web.ca Wed Nov 23 13:53:59 2005 From: rob at web.ca (Rob Ellis) Date: Wed Nov 23 13:54:01 2005 Subject: [development] Another translation module In-Reply-To: <1132744778.6735.33.camel@pulsar.devel.mindworks.hu> References: <20051120183502.GA46384@web.ca> <4381C216.1070308@wanadoo.es> <1132662771.5697.24.camel@pulsar.devel.mindworks.hu> <20051122135120.GA21017@web.ca> <1132744778.6735.33.camel@pulsar.devel.mindworks.hu> Message-ID: <20051123135359.GA20087@web.ca> On Wed, Nov 23, 2005 at 12:19:38PM +0100, Feh?r J?nos wrote: > 2005-11-22, k keltez?ssel 08.51-kor Rob Ellis ezt ?rta: > > That's one of the goals for the 'tr' module... fields for translating > > menu items are on the regular menu edit form, fields for translating > > taxonomy terms are on the taxonomy term form, node translation links > > are available when you view nodes, you can filter by language in > > the regular content admin interface. > > I see. But why don't you extend the i18n.module? > Jose said that the aproaches of the two module are the same. The basic idea of associating nodes with a node_translation table and doing content switching is the same, but in several ways the two modules are quite different -- in how they determine the request language, in how they plug into Drupal's path functions, in how they handle content admin. My original decision not to use i18n was made back in February when i18n required core db modifications and generally was less developed than it is now. In the meantime, I worked on a few multi-lingual sites based on my own code, and got interested in the problem... When I had some time this fall I decided to write a new module from scratch based on what I'd learned. I'm hoping it will be useful to people, maybe as a contribution to i18n's development, I don't know. - Rob -- Rob Ellis From jvandyk at iastate.edu Wed Nov 23 14:20:47 2005 From: jvandyk at iastate.edu (John VanDyk) Date: Wed Nov 23 14:20:48 2005 Subject: [development] One core, many distributions In-Reply-To: <3EA1E24A-D998-4AE7-A0BD-6AE3BF21728E@culturekitchen.com> References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> <4381FADE.9090009@tinpixel.com> <3EA1E24A-D998-4AE7-A0BD-6AE3BF21728E@culturekitchen.com> Message-ID: I think people are confusing core with distribution. The node/id system is simple, effective, and the best way to have nodes with unique ids at the highest performance. Whatever aliasing system you use (path, pathauto, supermegahoochypath) should be optional. If by "part of core" people mean the core distribution and that means it's a disablable module that is well-maintained, great. If by "part of core" people mean it's the new standard for identifying all nodes, no way. Liza makes some good points, and we should be mature enough to recognize the points she makes and ignore her offensive style instead of lashing back, which accomplishes nothing. Yes, Drupal has a marketing problem. Yes, most of us don't care about that and feel that if she thinks Drupal has a marketing problem she should start marketing Drupal and get involved with decision making, and maybe roll her own easy-to-use distribution (maybe pathauto will even be on by default!). Or maybe she could fund implementation of session remembrance. She is also right that 4.7 is going to be a lot of work for a lot of people without a lot of tangible benefit and we should recognize that (I know I do). I don't have a problem with that if we are steadily working towards best practices in everything. 4.7 is an example of best practices with forms, since they are now (more) secure. From mcsparkerton at yahoo.co.uk Wed Nov 23 14:35:19 2005 From: mcsparkerton at yahoo.co.uk (andre) Date: Wed Nov 23 14:35:25 2005 Subject: [development] One core, many distributions In-Reply-To: <43843C82.7060704@killesreiter.de> References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> <4381FADE.9090009@tinpixel.com> <3EA1E24A-D998-4AE7-A0BD-6AE3BF21728E@culturekitchen.com> <43843C82.7060704@killesreiter.de> Message-ID: <43847E27.30703@yahoo.co.uk> > No, it is just right. We know better because we simply know our > software, the software it depends on, and so on. We are the Gods, you > are the dust on our feet. I'm not here to defend or flame Liza (though it seems that she deserves a little of both)... I'm just going to toss this out there: When developers start referring to themselves as Deities - they also start to believe that they are infallible - and they start to believe that they know all and can do no wrong. Such arrogance is the downfall of all empires. Be great - but also be humble. Biting the hand that codes your software may be a faux pas - but so is pissing on the community that gives you your raison detre. and finally > Why on earth should we? Why should we give a damn about any of your problems? They are your problems after all, not ours. If you don't bother to even consider the comments or concerns of community members - i.e. joe average-end-user or jane super-user - you are no longer a software engineer or developer - your just a code monkey flinging meticulously polished elegant and efficient turds of code. andre (who happens to like the meticulously polished elegant efficient code - and appreciates every ounce of effort the authors put into the code - but can never lose sight of his clients needs - and if the code doesn't meet their needs - I will have no choice but to do some ugly hacks and workarounds that even if contributed to the community would never get past the gatekeeps - and perhaps rightly so) ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com From tom.willis at gmail.com Wed Nov 23 14:50:22 2005 From: tom.willis at gmail.com (Thomas G. Willis) Date: Wed Nov 23 14:50:28 2005 Subject: [development] One core, many distributions In-Reply-To: References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> <4381FADE.9090009@tinpixel.com> <3EA1E24A-D998-4AE7-A0BD-6AE3BF21728E@culturekitchen.com> Message-ID: Just a bit of insight from another drupal user. First post too. When I first stumbled on drupal everything I read/was told led me to believe it was a kick ass CMS. Now that I've been working with it for a few months I tend to think of it as more of a development platform. Or I guess the best comparison I can give is that drupal is to websites as debian is to linux. Lots of high quality infrastructure, flxibility and extendibility, not much focus on any particular area outside of the core idea. And like debian, it has it's benefits and drawbacks. One benefit is it can be all things to all people, and it's biggest drawback is that it's generic and requires work on the users part to get the solution they actually want. And in the debian world, more specialized distributions have cropped up to meet the needs of a large portion of users (ubuntu). The existence of ubuntu doesn't necessarily effect what the debian team chooses to make a priority. Though it could, but there's no guarantees. If drupal doesn't meet your specific needs you have choices. That's good news!!!!! I'm glad that opensource software is getting more and more popular with normal human beings. At the same time though I'm looking forward to a time when normal human beings finally understand that they are participating in a community, not depending on companies providing free software. -- Thomas G. Willis ----------------------------------------------- http://i-see-sound.com http://tomwillis.sonicdiscord.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051123/2afc1195/attachment.htm From gerhard at killesreiter.de Wed Nov 23 14:50:52 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Wed Nov 23 14:53:57 2005 Subject: [development] One core, many distributions In-Reply-To: <43847E27.30703@yahoo.co.uk> References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> <4381FADE.9090009@tinpixel.com> <3EA1E24A-D998-4AE7-A0BD-6AE3BF21728E@culturekitchen.com> <43843C82.7060704@killesreiter.de> <43847E27.30703@yahoo.co.uk> Message-ID: <438481CC.9040207@killesreiter.de> andre wrote: > >> No, it is just right. We know better because we simply know our >> software, the software it depends on, and so on. We are the Gods, you >> are the dust on our feet. > > > I'm not here to defend or flame Liza (though it seems that she > deserves a little of both)... > > I'm just going to toss this out there: > > When developers start referring to themselves as Deities - they also > start to believe that they are infallible - and they start to believe > that they know all and can do no wrong. > You don't think I was serious about that, do you? I avoid to use smileys, they take away the element of surprise. > Such arrogance is the downfall of all empires. > > Be great - but also be humble. > > Biting the hand that codes your software may be a faux pas - but so is > pissing on the community that gives you your raison detre. > No, no, and no. The "community" (I hate that word) is not the reason d'etre for Drupal or the reason why anybody would develop for it. The reason is to get stuff done for our own needs. You are free to use it, too. But that's it. > and finally > >> Why on earth should we? Why should we give a damn about any of your >> problems? They are your problems after all, not ours. > > > If you don't bother to even consider the comments or concerns of > community members - i.e. joe average-end-user or jane super-user - you > are no longer a software engineer or developer - your just a code > monkey flinging meticulously polished elegant and efficient turds of > code. > No, I am solving my problems. If those problems are somebody else's problems too, then that is fine with me. But I am not adopting problems I am not interested in. Not without a fee, anyway. Cheers, Gerhard From adrian at bryght.com Wed Nov 23 14:54:37 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Wed Nov 23 14:54:50 2005 Subject: [development] One core, many distributions In-Reply-To: References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> <4381FADE.9090009@tinpixel.com> <3EA1E24A-D998-4AE7-A0BD-6AE3BF21728E@culturekitchen.com> Message-ID: <9280EBB0-43B3-47DE-82C9-27C316B5D6AA@bryght.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23 Nov 2005, at 4:50 PM, Thomas G. Willis wrote: > Just a bit of insight from another drupal user. First post too. > > When I first stumbled on drupal everything I read/was told led me > to believe it was a kick ass CMS. Now that I've been working with > it for a few months I tend to think of it as more of a development > platform. Or I guess the best comparison I can give is that drupal > is to websites as debian is to linux. Yup. drupal is the debian of the web. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDhIKtgegMqdGlkasRAop3AJ9O937skvXrgAAO2oVtS9yBVwzOZACgqM9P QgItDhhWi38Wpn9HljaXyMY= =OvAA -----END PGP SIGNATURE----- From agentrickard at gmail.com Wed Nov 23 14:55:50 2005 From: agentrickard at gmail.com (Ken Rickard) Date: Wed Nov 23 14:55:53 2005 Subject: [development] Re: Usability Testing Message-ID: <25b45da00511230655g536ce21bqe47136baba866ef5@mail.gmail.com> Moshe- I would agree that custom site usability testing is not something that needs to be address by core developers. Our testing methods might be useful for core admin and setup development, so I can help write some tests for those if people need. More to my skill set, I would like, at some point (given personal time constraints) to be able to hook up with the Best Practices folks to write up some of our findings. Case in point: In our 4.5 environment, there is so little difference in user behavior between forums and blogs that the two need not both be run. In our next install, we're simply removing forums. If this were a universal truth -- and I'm not suggesting it is -- then I'd say, hey, devels, drop forum from core. Those who are insterested in going down the usability path should, I think, contact me off-list agentrickard at gmail dot com And we'll see what good I can share with the documentation / help folks. I'm particularly interested in the "who is your audience" question. (For some starting thoughts on where I'm coming from, interested parties can see http://ken.therickards.com/2005/08/31/10/). / Close thread -- Ken Rickard drupal: agentken gmail: agentrickard -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051123/4c94f03d/attachment-0001.htm From gerhard at killesreiter.de Wed Nov 23 14:56:00 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Wed Nov 23 14:59:02 2005 Subject: [development] One core, many distributions In-Reply-To: References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> <4381FADE.9090009@tinpixel.com> <3EA1E24A-D998-4AE7-A0BD-6AE3BF21728E@culturekitchen.com> Message-ID: <43848300.1030003@killesreiter.de> John VanDyk wrote: > I think people are confusing core with distribution. > People are confusing a lot of things. > The node/id system is simple, effective, and the best way to have > nodes with unique ids at the highest performance. > > Whatever aliasing system you use (path, pathauto, supermegahoochypath) > should be optional. If by "part of core" people mean the core > distribution and that means it's a disablable module that is > well-maintained, great. If by "part of core" people mean it's the new > standard for identifying all nodes, no way. > > Liza makes some good points, and we should be mature enough to > recognize the points she makes and ignore her offensive style instead > of lashing back, which accomplishes nothing. Heh, you have no idea; it gives a lot of pleasure and relieves tension to wield the clue bat. My blood pressure is at an all time low. > Yes, Drupal has a marketing problem. Does it? Somebody recently did a google query and found 60000 Drupal sites. He probably missed half of them since he used an English search string. > Yes, most of us don't care about that and feel that if she thinks > Drupal has a marketing problem she should start marketing Drupal and > get involved with decision making, and maybe roll her own easy-to-use > distribution (maybe pathauto will even be on by default!). Or maybe > she could fund implementation of session remembrance. > In any case she should keep it off this list, since it is not development related. > She is also right that 4.7 is going to be a lot of work for a lot of > people without a lot of tangible benefit and we should recognize that > (I know I do). I don't have a problem with that if we are steadily > working towards best practices in everything. 4.7 is an example of > best practices with forms, since they are now (more) secure. So what are you trying to say? I don't get it. Nobody forces people to upgrade the same moment that 4.7 is released. They can take their own time, set up a test site, and migrate once they are ready. We will be providing security patches for 4.6 until 4.8 will be available. So they probably have at the very least half a year from now. And if they don't want to upgrade at all, they can even do that. And if they don't want to do updates, they will need to get a nice hosting provider which runs their Drupal for them and makes updated modules available, etc. Plenty of possibilities. Cheers, Gerhard From adrian at bryght.com Wed Nov 23 15:06:27 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Wed Nov 23 15:06:53 2005 Subject: [development] One core, many distributions In-Reply-To: <43848300.1030003@killesreiter.de> References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> <4381FADE.9090009@tinpixel.com> <3EA1E24A-D998-4AE7-A0BD-6AE3BF21728E@culturekitchen.com> <43848300.1030003@killesreiter.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23 Nov 2005, at 4:56 PM, Gerhard Killesreiter wrote: > > And if they don't want to do updates, they will need to get a nice > hosting provider which runs their Drupal for them and makes updated > modules available, etc. I wonder if we know anyone that does that kind of thing ? - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDhIV9gegMqdGlkasRAsnkAJ4nhWQD22LMBdksTfbJ5C0yXDr7eQCfToAZ zQOgupiGHsOA185QL3YEeRk= =c7lZ -----END PGP SIGNATURE----- From larry at garfieldtech.com Wed Nov 23 15:16:47 2005 From: larry at garfieldtech.com (Larry Garfield) Date: Wed Nov 23 15:17:15 2005 Subject: [development] One core, many distributions In-Reply-To: <9280EBB0-43B3-47DE-82C9-27C316B5D6AA@bryght.com> References: <437F6F91.40600@wanadoo.es> <9280EBB0-43B3-47DE-82C9-27C316B5D6AA@bryght.com> Message-ID: <200511230916.48205.larry@garfieldtech.com> On Wednesday 23 November 2005 08:54 am, Adrian Rossouw wrote: > > When I first stumbled on drupal everything I read/was told led me > > to believe it was a kick ass CMS. Now that I've been working with > > it for a few months I tend to think of it as more of a development > > platform. Or I guess the best comparison I can give is that drupal > > is to websites as debian is to linux. > > Yup. > > drupal is the debian of the web. No wonder I like it (he writes from a Debian Sid box). :-) Although 4.7 seems to have slipped as far as sarge, schedule wise. Boy the comparison just gets better and better... All we need now is aptitude (automated module installer) and we can start using that as our slogan. "Drupal: The Debian of the Web". (This post provided with its very own grain of salt. We recommend holding it against your cheek with your tongue. --The Management) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson From tom.willis at gmail.com Wed Nov 23 15:28:03 2005 From: tom.willis at gmail.com (Thomas G. Willis) Date: Wed Nov 23 15:28:05 2005 Subject: [development] One core, many distributions In-Reply-To: <200511230916.48205.larry@garfieldtech.com> References: <437F6F91.40600@wanadoo.es> <9280EBB0-43B3-47DE-82C9-27C316B5D6AA@bryght.com> <200511230916.48205.larry@garfieldtech.com> Message-ID: I've had it with sid at home. I'm a somewhat happy ubuntu user now, got tired of shit breaking everyday. Something like aptitude would be nice. if you could work that into the 4.7core after you get pathauto in there that would be great. ;) Also, my particular need is to replace jinzora with drupal for my mp3 collection at home. Can we put that in Core too? (sooooo kidding) Honestly I think a well defined core is probably the best approach. It's the only way I can think of that potentially yields a solid foundation for someone else to run with to get their needs met. And probably remove all instances of CMS/Content Management System off the website as to not mislead people in thinking that they've found something to replace wordpress with. On 11/23/05, Larry Garfield wrote: > > On Wednesday 23 November 2005 08:54 am, Adrian Rossouw wrote: > > > > When I first stumbled on drupal everything I read/was told led me > > > to believe it was a kick ass CMS. Now that I've been working with > > > it for a few months I tend to think of it as more of a development > > > platform. Or I guess the best comparison I can give is that drupal > > > is to websites as debian is to linux. > > > > Yup. > > > > drupal is the debian of the web. > > No wonder I like it (he writes from a Debian Sid box). :-) > > Although 4.7 seems to have slipped as far as sarge, schedule wise. Boy > the > comparison just gets better and better... > > All we need now is aptitude (automated module installer) and we can start > using that as our slogan. "Drupal: The Debian of the Web". > > (This post provided with its very own grain of salt. We recommend holding > it > against your cheek with your tongue. --The Management) > > -- > Larry Garfield AIM: LOLG42 > larry@garfieldtech.com ICQ: 6817012 > > "If nature has made any one thing less susceptible than all others of > exclusive property, it is the action of the thinking power called an idea, > which an individual may exclusively possess as long as he keeps it to > himself; but the moment it is divulged, it forces itself into the > possession > of every one, and the receiver cannot dispossess himself of it." -- > Thomas > Jefferson > -- Thomas G. Willis ----------------------------------------------- http://i-see-sound.com http://tomwillis.sonicdiscord.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051123/782f8e41/attachment.htm From jvandyk at iastate.edu Wed Nov 23 15:29:13 2005 From: jvandyk at iastate.edu (John VanDyk) Date: Wed Nov 23 15:29:15 2005 Subject: [development] One core, many distributions In-Reply-To: <43848300.1030003@killesreiter.de> References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> <4381FADE.9090009@tinpixel.com> <3EA1E24A-D998-4AE7-A0BD-6AE3BF21728E@culturekitchen.com> <43848300.1030003@killesreiter.de> Message-ID: >>She is also right that 4.7 is going to be a lot of work for a lot >>of people without a lot of tangible benefit and we should recognize >>that (I know I do). I don't have a problem with that if we are >>steadily working towards best practices in everything. 4.7 is an >>example of best practices with forms, since they are now (more) >>secure. > > >So what are you trying to say? I don't get it. I have lots of Drupal sites running. Many of these sites have special modules. These modules will have to be rewritten for 4.7 to do exactly the same thing they are already doing. This will take time. Time = money. Every time we break backwards compatibility there is a cost. I'm saying that I'm OK with that as long as it improves Drupal, but that the cost should be recognized as well, and as Drupal's popularity increases, so does the cost. From dries.buytaert at gmail.com Wed Nov 23 15:31:29 2005 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Wed Nov 23 15:31:34 2005 Subject: [development] One core, many distributions In-Reply-To: References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> <4381FADE.9090009@tinpixel.com> <3EA1E24A-D998-4AE7-A0BD-6AE3BF21728E@culturekitchen.com> Message-ID: <86C23E19-A1DD-4DF8-B73A-833093528958@buytaert.net> On 23 Nov 2005, at 15:20, John VanDyk wrote: > Liza makes some good points, and we should be mature enough to > recognize the points she makes and ignore her offensive style > instead of lashing back, which accomplishes nothing. Yes, Drupal > has a marketing problem. Yes, most of us don't care about that and > feel that if she thinks Drupal has a marketing problem she should > start marketing Drupal and get involved with decision making, and > maybe roll her own easy-to-use distribution (maybe pathauto will > even be on by default!). Or maybe she could fund implementation of > session remembrance. I agree that Liza made some good points, as well as bad points. Liza has high expectations of Drupal (a good thing), and it shows. Fortunately, we're well aware of most points. If she did her research, she would have known, and she would not have to offend the many contributors that donate time, money and resources trying to advance Drupal. Either way, let's focus on constructive action points as how to overcome some of Liza's concerns, and see if someone steps forward to take on the work it takes. Let's define a number of manageable tasks that could be implemented ... > She is also right that 4.7 is going to be a lot of work for a lot > of people without a lot of tangible benefit and we should recognize > that (I know I do). I don't have a problem with that if we are > steadily working towards best practices in everything. 4.7 is an > example of best practices with forms, since they are now (more) > secure. Whether 4.7 will have tangible benefit depends on your situation. Fact is that 4.7 comes with many improvements that are visible to the user; better templating, free-tagging, contact forms, better search, better syndication, and usability improvements all over the map. At the same time, there are many improvements that are less visible to the user, but that are essential to advance Drupal's technical capabilities; the new forms API and the improved node revisions being prominent examples. Changes like this will help advance the many contributed modules to become simpler and/or more feature-rich. For example, the forms API will help flexinode/CCK, the improved node revisions will help the wiki module(s). It is what it takes, and unfortunately, it can be disruptive. As both you point, the challenge is to get Drupal 4.7 out, to update the contributed projects, and to simplify the migration process for those who want to upgrade to Drupal 4.7. -- Dries Buytaert :: http://www.buytaert.net/ From dries.buytaert at gmail.com Wed Nov 23 16:15:21 2005 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Wed Nov 23 16:15:27 2005 Subject: [development] One core, many distributions In-Reply-To: References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> <4381FADE.9090009@tinpixel.com> <3EA1E24A-D998-4AE7-A0BD-6AE3BF21728E@culturekitchen.com> <43848300.1030003@killesreiter.de> Message-ID: <006A0406-BB54-4D50-B3CD-AD159A06D86D@buytaert.net> > These modules will have to be rewritten for 4.7 to do exactly the > same thing they are already doing. This will take time. Time = money. if (benefits > costs) { upgrade_to_47(); } else { stick_with_46(); } Whether the benefits of upgrading to Drupal 4.7 outweight the costs of upgrading to Drupal 4.7, is something only you can determine: it's unique to your situation. For the exact same reason, people are still using WinNT or Win98. > Every time we break backwards compatibility there is a cost. True, but at the same time we gain things too. Similarly, not breaking code often comes at a cost as well; it holds back improvements, makes code harder to maintain, makes it harder to customize Drupal, has performance implications, etc. Clearly, there is a tension between breaking backward compatibility and not breaking backward compatibility. Unfortunately, there is no "winner" because the costs can't be quantified. Not the absolute costs. Not the relative costs. I'm in the camp that, we are best of breaking backward compatibility when necessary; it buys us maintainability and flexibility, which, in turn, makes for a longer product lifecycle. -- Dries Buytaert :: http://www.buytaert.net/ From dopry at thing.net Wed Nov 23 16:37:34 2005 From: dopry at thing.net (Darrel O'Pry) Date: Wed Nov 23 16:37:39 2005 Subject: [development] One core, many distributions In-Reply-To: <006A0406-BB54-4D50-B3CD-AD159A06D86D@buytaert.net> References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> <4381FADE.9090009@tinpixel.com> <3EA1E24A-D998-4AE7-A0BD-6AE3BF21728E@culturekitchen.com> <43848300.1030003@killesreiter.de> <006A0406-BB54-4D50-B3CD-AD159A06D86D@buytaert.net> Message-ID: <1132763854.30104.25.camel@localhost.localdomain> On Wed, 2005-11-23 at 17:15 +0100, Dries Buytaert wrote: > > These modules will have to be rewritten for 4.7 to do exactly the > > same thing they are already doing. This will take time. Time = money. > > if (benefits > costs) { > upgrade_to_47(); > } > else { > stick_with_46(); > } > Clearly, there is a tension between breaking backward compatibility > and not breaking backward compatibility. Unfortunately, there is no > "winner" because the costs can't be quantified. Not the absolute > costs. Not the relative costs. I'm in the camp that, we are best of > breaking backward compatibility when necessary; it buys us > maintainability and flexibility, which, in turn, makes for a longer > product lifecycle. And more billable development hours if you play your cards right ;). I'm in the same camp. I was poking through some of the earlier versions of drupal... I think the changelogs indicated late 90's early 00's... I'm glad drupal isn't 100% backwards compatible. From cel4145 at cyberdash.com Wed Nov 23 16:38:25 2005 From: cel4145 at cyberdash.com (Charlie Lowe) Date: Wed Nov 23 16:38:26 2005 Subject: WARNING(virus check bypassed): Re: [development] One core, many distributions Message-ID: <43849B01.3000306@cyberdash.com> Gerhard wrote, "No, no, and no. The "community" (I hate that word) is not the reason d'etre for Drupal or the reason why anybody would develop for it. The reason is to get stuff done for our own needs. You are free to use it, too. But that's it." Okay. I'm non-coder, but I do work with Drupal for my "own needs," and would suggest that here is part of the conflict which traces back to Liza's post. It all depends on your perspective of what is important about open source (or free software if that is your term). I've been doing lots of reasearch on open source lately, and IMHO, the idea that the community is unimportant and that the code is "free to use" is very short-sighted. In The Success of Open Source, Stephen Weber explains that ?the essence of open source is not the software. It is the process by which software is created? (56). The licensing merely gives users rights. The fact that the open source product becomes available in a gift economy for everyone to use is not the end in itself, but rather the means to that end as Ilkka Tuomi pointed out in an article on First Monday, ?open-source communities control the developmental dynamic of an evolving good. The 'openness' of open source, therefore, is more about open future than about access to currently existing source-code text? (442). So for those for whom Drupal is not just a short term solution for a client, but part of a long strategy for developing a successful consulting business (or other types of career advancement), the community is very important, and even the end users of which Liza speaks. Open source depends on collaboration--and as long as the workflow processes and organizational structure can handle it--increased growth in the community. End users play an important role in this. For every 100 new end users, there are 100 new people potentially marketing Drupal for those trying to build a client base. And out of those 100, there are probably at least a few who will contribute to development and increase the functionality of the product. Need further convincing? I sent the following statistics to Dries at the end of October. For anyone who's long term prosperity depends on Drupal's brand name succcess (and I think it does; IMHO, DeanSpace, for example, did a lot for advancing Drupal's community growth), consider the followiong statistics. I'm sure they haven't changed much in the last month. Are the perceptions represented there going to make a difference in everyone's current client work. Probably not. Is it going to affect most people's ability to build a larger client base and more successfuly consulting opportunities? Most definitely so. Charlie Lowe Check out the Google results on these phrase and term combinations: "Drupal sucks" 627 hits "Mambo sucks" 289 hits "PostNuke sucks" 341 hits "Plone sucks" 123 hits "Drupal is easy" 100 hits "Mambo is easy" 656 hits "PostNuke is easy" 117 hits "Plone is easy" 514 hits "Drupal is hard" 52 hits "Mambo is hard" 43 hits "PostNuke is hard" 5 hits "Plone is hard" 28 hits "Drupal is difficult" 280 hits "Mambo is difficult" 89 hits "PostNuke is difficult" 44 hits "Plone is difficult" 14 hits Now what's interesting are these keyword stats: Drupal usability 372,000 hits Mambo usability 338,000 hits PostNuke usability 82,900 hits Plone usability 147,000 hits A lot of talk about Drupal usability, but it seems that more needs to be accomplished to change public perception. From dan at drob.org Wed Nov 23 17:01:33 2005 From: dan at drob.org (Dan Robinson) Date: Wed Nov 23 17:01:50 2005 Subject: [development] One core, many distributions In-Reply-To: <20051122090306.3a2ff3b5.jeremy@kerneltrap.org> References: <437F6F91.40600@wanadoo.es> <42E27BE2-C5CD-437D-A5FC-495E8BDDAB0C@istyledthis.nl> <20051122090306.3a2ff3b5.jeremy@kerneltrap.org> Message-ID: <4384A06D.5090402@drob.org> > > >>the throttle.module is only interesting and usable by >>high-traffic sites like kerneltrap.org and/or >>drupal.org-a-like sites. IMO it's too much for core, >>because there are lot's of people who use drupal for their >>own personal site and small business sites. the >>throttle.module is a little bit of an overkill for sites >>like that. >> >> > >The throttle is useful to sites that have limited resources >and usually are not that busy. It is actually less useful to >consistently high-traffic sites, as by necessity they will >already have the required infrastructure to survive high >loads. > >The throttle works well for a website that's on a shared >host with limited CPU and bandwidth, that usually only gets a >handful of visitors, and then is suddenly Slashdotted. Of >course, it will only help in that case if it has been enabled >and properly configured. > > This is exactly the kind of information that would be useful to people. A description of what the module does, who it is for and an endorsement of it's quality. I wonder if we could start a book about this somewhere. >Cheers, > -Jeremy > > > > From jeff at viapositiva.net Wed Nov 23 17:06:12 2005 From: jeff at viapositiva.net (Jeff Eaton) Date: Wed Nov 23 17:06:19 2005 Subject: [development] One core,many distributions In-Reply-To: <43849B01.3000306@cyberdash.com> Message-ID: <001f01c5f050$38270b60$6700a8c0@JEATON2DEV> > Check out the Google results on these phrase and term combinations: > > "Drupal sucks" 627 hits > "Mambo sucks" 289 hits > "PostNuke sucks" 341 hits > "Plone sucks" 123 hits I only got 165 hits for "drupal sucks", and the first two were my posts on drupal.org explaining why it doesn't suck. :-) I should take that phrase out of my .sig on drupal.org -- with drupal's good SEO results, I could drive the number of hits for that term up singlehandedly. :-) It's also a matter of what you're looking for. "Drupal is powerful" - 207 hits "Mambo is powerful" - 75 hits "PostNuke is powerful" - 16 hits "Plone is powerful" - 362 hits "Drupal is flexible" - 246 hits "Mambo is flexible" - 32 hits "PostNuke is flexible" - 0 hits "Plone is flexible" - 3 hits There's always a danger in putting too much weight on google results like that -- even using it to measure 'buzz' is touchy due to the way search engines work. That said, if people are saying that Drupal sucks, it might be good to ask why. I notice that a lot of the 'Drupal Sucks' flames (the ones that were actually about Drupal) revolved around the limitations of the forum system. That point certainly is a good one. --Jeff From karoly at negyesi.net Wed Nov 23 17:22:15 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Wed Nov 23 17:17:50 2005 Subject: WARNING(virus check bypassed): Re: [development] One core, many distributions In-Reply-To: <43849B01.3000306@cyberdash.com> References: <43849B01.3000306@cyberdash.com> Message-ID: I see all this more simpler, to quote one of my favourite writers: If you anger a bear, do not be surprised if it rips your guts out! Lisa tried to provoke a flame war. Succeeded. Of course the developers and I am sure Gerhard too cares about the community -- why do you think he answers the forums, shepherds the translators and manages CVS accounts besides coding? Regards NK On Wed, 23 Nov 2005 17:38:25 +0100, Charlie Lowe wrote: From karoly at negyesi.net Wed Nov 23 17:38:01 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Wed Nov 23 17:33:36 2005 Subject: [development] One core,many distributions In-Reply-To: <001f01c5f050$38270b60$6700a8c0@JEATON2DEV> References: <001f01c5f050$38270b60$6700a8c0@JEATON2DEV> Message-ID: > I should take that > phrase out of my .sig on drupal.org Yes and you should feel yourself miserable for having that there for so long. From blogdiva at culturekitchen.com Wed Nov 23 17:35:11 2005 From: blogdiva at culturekitchen.com (Liza Sabater) Date: Wed Nov 23 17:35:18 2005 Subject: [development] One core, many distributions In-Reply-To: <43843C82.7060704@killesreiter.de> References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> <4381FADE.9090009@tinpixel.com> <3EA1E24A-D998-4AE7-A0BD-6AE3BF21728E@culturekitchen.com> <43843C82.7060704@killesreiter.de> Message-ID: <56EA50BD-F7D3-4073-9BEF-E03C42811FD2@culturekitchen.com> Gerard, On Nov 23 2005, at 04:55, Gerhard Killesreiter wrote: >> You broke so many rules about market strategy, usability and >> software development, I can't even fathom how you came to the >> conclusion this was a good idea. Then again, yes, I can fathom >> the logic just by the discussion we are having here. >> > > A discussion? You are biting the hand that codes your software. > Very bad move. No, I am not. I want to bring attention to what other people around the world are saying about you. And I am trying to do it in a way that starts a conversation that gives us all a positive outcome. I know you are the lead developers and I am grateful for your work. If I did not think it was worthy, I'd go find something else. What I am trying to get to here is that you have a world of improvements to make that do not necessarily involve re-coding Drupal --that is, if Drupal is a product and not a software development lab. Why is this important? If you are not in the business of creating a product but instead are just here as a software development lab, then instead of coming to Drupal for a CMS; vendors, users, and web developers might just have to stand back and say : OK, I am going to stick to the features in 4.6 and create a parallel support structure just for that release. So, in effect, people might have to make a decision as to look at each release as not just a code fork but a market development fork for the release as well. To you as a developer this does not make sense. You are always on the lookout for better code.That's normal; it means you're coder. But for people who are looking at Drupal as a product to build a business infrastructure, it may well be the only way to go. And that means, right now, that there is no business support infrastructure for people looking at Drupal AS A PRODUCT and not a software development lab. It means that people like me have to stand and think ... hmmm ... what can I do to create a support infrastructure that will work for the next 18 months; all the while creating an "upgrade bridge" for OUR (not Drupal's) next upgrade. Do you get where I am coming from? So, I need to be in here to understand your process as an outsider because Gerhard Killesreiter at this moment, does not seem to have the business objectivity to answer these questions. I mean, c'mon, you're releases are coming out every 4-6 months. That's insane for people in the real world. Whatever happened to the 12-18 months for new releases? There is so much that could be done just in UI in between releases that, honestly, why are you rushing to the next decimal? Again, the pertinent question : Is Drupal a product or a software development lab? > No, it is just right. We know better because we simply know our > software, the software it depends on, and so on. We are the Gods, > you are the dust on our feet. Jokes are a great way of presenting our view of reality and this joke of yours is your truth. The question is, should it be Drupal's? Liza Sabater, Publisher www.culturekitchen.com From dan at civicactions.com Wed Nov 23 17:44:43 2005 From: dan at civicactions.com (Dan Robinson) Date: Wed Nov 23 17:44:55 2005 Subject: [development] One core, many distributions In-Reply-To: <43849B01.3000306@cyberdash.com> References: <43849B01.3000306@cyberdash.com> Message-ID: <4384AA8B.1020002@civicactions.com> > So for those for whom Drupal is not just a short term solution for a > client, but part of a long strategy for developing a successful > consulting business (or other types of career advancement), the > community is very important, and even the end users of which Liza speaks. hear hear... > > Check out the Google results on these phrase and term combinations: > > "Drupal sucks" 627 hits > "Mambo sucks" 289 hits > "PostNuke sucks" 341 hits > "Plone sucks" 123 hits > > "Drupal is easy" 100 hits > "Mambo is easy" 656 hits > "PostNuke is easy" 117 hits > "Plone is easy" 514 hits > > "Drupal is hard" 52 hits > "Mambo is hard" 43 hits > "PostNuke is hard" 5 hits > "Plone is hard" 28 hits > > "Drupal is difficult" 280 hits > "Mambo is difficult" 89 hits > "PostNuke is difficult" 44 hits > "Plone is difficult" 14 hits > > > Now what's interesting are these keyword stats: > > Drupal usability 372,000 hits > Mambo usability 338,000 hits > PostNuke usability 82,900 hits > Plone usability 147,000 hits > > A lot of talk about Drupal usability, but it seems that more needs to > be accomplished to change public perception. > I am convinced that a lot of this is about expectations. If I buy a chair at the furniture store and I get home and find a boxful of wood and screws then I may not be very happy (yes I should have done more research - but I'm not the smartest person in the world - a characteristic I happily share with a large number of people). I think we could make a huge impact on perceptions without having to write a single line of code. From gunnar at langemark.com Wed Nov 23 18:00:08 2005 From: gunnar at langemark.com (Gunnar Langemark) Date: Wed Nov 23 18:00:29 2005 Subject: [development] One core, many distributions In-Reply-To: <56EA50BD-F7D3-4073-9BEF-E03C42811FD2@culturekitchen.com> References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> <4381FADE.9090009@tinpixel.com> <3EA1E24A-D998-4AE7-A0BD-6AE3BF21728E@culturekitchen.com> <43843C82.7060704@killesreiter.de> <56EA50BD-F7D3-4073-9BEF-E03C42811FD2@culturekitchen.com> Message-ID: <4384AE28.5060705@langemark.com> Liza Sabater wrote: > Again, the pertinent question : Is Drupal a product or a software > development lab? Liza That's a very good question. Fortunately it is not very hard to answer. Drupal is Open Source. Open Source is driven by coders who have an itch. They scratch the itch they have. They have no obligation to scratch yours or mine. Some even have the audacity to mention it openly! ;-) Drupal is not a product first. It is a process, a way of life, a living system and an experimental development lab. Drupal is also a product, but it is not a commercial product, so don't expect the same culture around it as you'll find around word for instance. We don't have paid supporters to take the abuse from frustrated customers and turn it into satisfying solutions. Also - even though Drupal people are quite focussed on usability issues, help and support - these tasks are not a "attractive" to most people in the community. That is the way it is. Don't expect anything else. The Drupal community has hitherto been very friendly and forthcoming when people had issues with the software. Drupal is now so bogged down by its own success, that the core developers cannot be expected to be as available as the next release is approaching fast. Development cycles: Even large professional systems (like MBS Axapta - the system I work with on a daily basis) have more than one "rhythm". Full releases are two years, smaller ones more frequent. (I'm not a programmer, I'm a communications guy and an Information Architect and I love Drupal and the community around it) Best Gunnar From blogdiva at culturekitchen.com Wed Nov 23 18:10:47 2005 From: blogdiva at culturekitchen.com (Liza Sabater) Date: Wed Nov 23 18:10:51 2005 Subject: [development] One core, many distributions In-Reply-To: <438481CC.9040207@killesreiter.de> References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> <4381FADE.9090009@tinpixel.com> <3EA1E24A-D998-4AE7-A0BD-6AE3BF21728E@culturekitchen.com> <43843C82.7060704@killesreiter.de> <43847E27.30703@yahoo.co.uk> <438481CC.9040207@killesreiter.de> Message-ID: <286DB1BB-2214-420C-8E0B-74D7BAA43EFB@culturekitchen.com> On Nov 23 2005, at 09:50, Gerhard Killesreiter wrote: > No, no, and no. The "community" (I hate that word) is not the > reason d'etre for Drupal or the reason why anybody would develop > for it. The reason is to get stuff done for our own needs. You are > free to use it, too. But that's it. Gerard, This is shocking for me to read. Seriously. I neve intended to offend people with my lame jokes about geekatude but this comment is ... well ... wow. I've had my eye on Drupal since 2002. Back then I did not had a clue of what a blog was. All I wanted was something that would make my life easier publishing on the web. I liked what you had but held off because, as a power user of blogging software and not a developer, I needed something that was easier to deal with. b2 is what I really wanted but by then the software had been abandoned (it reappeared later as both WordPress and b2evolution). So I went the route of MovableType because of its support and vendor communities. I came back to Drupal for one reason : CivicSpace. What Zack et al have accomplished with that distribution is impressive. And as political bloggers like me grow their practices from personal op-ed diaries to activist communities, CivicSpace is, in my not so humble opinion, the best thing out there for the potential growth of networks of online political communities. From a strategic POV, CivicSpace/Drupal makes more sense to me than Scoop. But most activist community sites in the US are going the route of Scoop. It took just one person, who happens to be also the owner of the largest political community site in the US, to make the decision of Drupal vs. Scoop and he went the route of Scoop for 2 reasons : it's support and vendor communities. Do you see a pattern here? Scoop, MovableType and WordPress are gaining big chunks of market share (especially in publishing) in the US while Drupal/CivicSpace is on tentative ground due in part to the dichotomy between the development and the marketing of Drupal. I am the only blogger from the top 100 moving to CivicSpace at the moment. MediaGirl runs a Drupal site (not CivicSpace). Bob Brigham of Swing State Project (another top 100) started a site on CivicSpace but that's another short-term campaign site. In this case the campaign is www.scalito.org. He was converted to CivicSpace in part by me. Epluribus Media, a citizen journalism site that came out of DailyKos, has 2 sites running : one on Scoop for their research work and the other one on CivicSpace for their blogging. They were converted to CivicSpace in part by Lynn Siprelle. Yeah, a lot of you call blogs hype and all that; but the reality is that blogging is here to stay. If anything, you are poised to get more development resources with long-term political community sites than short-term campaigns because you'll have people who've had enough time to understand the product --even if they were not developers . So your disregard about community in creating a community and content platform is troubling. / liza From colin at bryght.com Wed Nov 23 18:28:27 2005 From: colin at bryght.com (Colin Brumelle) Date: Wed Nov 23 18:28:30 2005 Subject: [development] Module tagged DRUPAL-4-6 doesn't show up on list of '4.6.x ' modules Message-ID: <80a220dc0511231028l5d61a75fi120850bcf32370f2@mail.gmail.com> Hi, I've spoken briefly to Dries about this, but I know he's a busy man and there may be a simple solution to this. I have (I think) correctly tagged my audio module with DRUPAL-4-6. It used to show up on the list of 4-6 modules on drupal.org, but a few weeks ago, it disappeared, and now only is listed under 'cvs'. Am I doing something wrong with my CVS tags? Is something strange with project module? Hmmm... -- ------------------- Colin Brumelle colin@bryght.com http://bryght.com http://mixedcontent.com Cell: 604.351.0547 Office: 604.682.2889 skype/jabber/aim: cbrumelle -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051123/097c3f28/attachment.htm From boris at bryght.com Wed Nov 23 18:39:37 2005 From: boris at bryght.com (Boris Mann) Date: Wed Nov 23 18:39:45 2005 Subject: [development] One core, many distributions In-Reply-To: <56EA50BD-F7D3-4073-9BEF-E03C42811FD2@culturekitchen.com> References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> <4381FADE.9090009@tinpixel.com> <3EA1E24A-D998-4AE7-A0BD-6AE3BF21728E@culturekitchen.com> <43843C82.7060704@killesreiter.de> <56EA50BD-F7D3-4073-9BEF-E03C42811FD2@culturekitchen.com> Message-ID: On 23-Nov-05, at 9:35 AM, Liza Sabater wrote: > On Nov 23 2005, at 04:55, Gerhard Killesreiter wrote: > >>> You broke so many rules about market strategy, usability and >>> software development, I can't even fathom how you came to the >>> conclusion this was a good idea. Then again, yes, I can fathom >>> the logic just by the discussion we are having here. >>> >> >> A discussion? You are biting the hand that codes your software. >> Very bad move. > > > No, I am not. I want to bring attention to what other people around > the world are saying about you. And I am trying to do it in a way > that starts a conversation that gives us all a positive outcome. This is prefaced with an acknowledgment that there are valid points from all parties (there are no "sides" here, just people talking). The use of attack language on both sides is troubling ("you" rather than "we")...we're all in this together, and can contribute different things. IMHO, this is not the right forum. These -- as much as you would like to think they are -- are not development issues (which this list is for), but rather community/marketing issues. The documentation list has a marketing sub-component, and at some point the consultants@drupal.org list will be up that will be more business and best practice oriented. I'm happy to discuss this further off-list. > To you as a developer this does not make sense. You are always on > the lookout for better code.That's normal; it means you're coder. > But for people who are looking at Drupal as a product to build a > business infrastructure, it may well be the only way to go. And > that means, right now, that there is no business support > infrastructure for people looking at Drupal AS A PRODUCT and not a > software development lab. It means that people like me have to > stand and think ... hmmm ... what can I do to create a support > infrastructure that will work for the next 18 months; all the while > creating an "upgrade bridge" for OUR (not Drupal's) next upgrade. Help build/fund the installer and updater, which should make things a lot easier for non-technical users. 4.6 is never abandoned, it just doesn't get new features. If your business roadmap includes a need for certain features, consider setting aside funding for these. I admit I am confused about the perceived need to upgrade existing sites? I used to routinely skip upgrades (e.g. 4.0 --> 4.2 --> 4.4). > Do you get where I am coming from? So, I need to be in here to > understand your process as an outsider because Gerhard Killesreiter > at this moment, does not seem to have the business objectivity to > answer these questions. I mean, c'mon, you're releases are coming > out every 4-6 months. That's insane for people in the real world. > Whatever happened to the 12-18 months for new releases? There is so > much that could be done just in UI in between releases that, > honestly, why are you rushing to the next decimal? > > Again, the pertinent question : Is Drupal a product or a software > development lab? Neither. It is most like Ruby on Rails -- a web application framework. The framework doesn't care about users...that is up to individual consultants, developers, and yes, businesses. If the economics are there to have business support structures arise...they will arise. That is exactly why distributions -- whether CivicSpace, DrupalED, or anything else -- make sense. Communities can form on pushing and supporting products, rather than a toolkit. Drupal has gotten MORE framework-like over time, and less like a "product". Hope that was a useful contribution. That's all from me on the subject on this list. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com From kieran at civicspacelabs.org Wed Nov 23 18:43:03 2005 From: kieran at civicspacelabs.org (Kieran Lal) Date: Wed Nov 23 18:43:23 2005 Subject: [development] One core, many distributions In-Reply-To: <4384A06D.5090402@drob.org> References: <437F6F91.40600@wanadoo.es> <42E27BE2-C5CD-437D-A5FC-495E8BDDAB0C@istyledthis.nl> <20051122090306.3a2ff3b5.jeremy@kerneltrap.org> <4384A06D.5090402@drob.org> Message-ID: <86EE9FEA-9052-4377-B69B-FBB70FDA2793@civicspacelabs.org> On Nov 23, 2005, at 9:01 AM, Dan Robinson wrote: > This is exactly the kind of information that would be useful to > people. > A description of what the module does, who it is for and an > endorsement > of it's quality. I wonder if we could start a book about this > somewhere. In Drupal 4.7 the administration help for throttle has been improved. It is sourced from here: http://drupal.org/handbook/ modules/throttle At the end of the help there is a link back to the page above. I have just added a child page called "When to use the throttle module". http://drupal.org/node/38661 Thanks to Jeremy and Dan for pointing this out. Cheers, Kieran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051123/175f5df4/attachment.htm From dan at drob.org Wed Nov 23 18:49:14 2005 From: dan at drob.org (Dan Robinson) Date: Wed Nov 23 18:49:32 2005 Subject: [development] One core, many distributions In-Reply-To: <286DB1BB-2214-420C-8E0B-74D7BAA43EFB@culturekitchen.com> References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> <4381FADE.9090009@tinpixel.com> <3EA1E24A-D998-4AE7-A0BD-6AE3BF21728E@culturekitchen.com> <43843C82.7060704@killesreiter.de> <43847E27.30703@yahoo.co.uk> <438481CC.9040207@killesreiter.de> <286DB1BB-2214-420C-8E0B-74D7BAA43EFB@culturekitchen.com> Message-ID: <4384B9AA.9090102@drob.org> >> No, no, and no. The "community" (I hate that word) is not the reason >> d'etre for Drupal or the reason why anybody would develop for it. >> The reason is to get stuff done for our own needs. You are free to >> use it, too. But that's it. > > > Gerard, > > This is shocking for me to read. Seriously. I neve intended to offend > people with my lame jokes about geekatude but this comment is ... > well ... wow. Don't be shocked - there is no overall agreement about what this project is or whom it is for. Gerhard has his opinions. I happen to disagree with him that "The "community" (I hate that word) is not the reason d'etre for Drupal or the reason why anybody would develop for it." - but I get to have my own opinion. > > > But most activist community sites in the US are going the route of > Scoop. It took just one person, who happens to be also the owner of > the largest political community site in the US, to make the decision > of Drupal vs. Scoop and he went the route of Scoop for 2 reasons : > it's support and vendor communities. This doesn't mean that Scoop is a better product, that it has better support or that there is a stronger vendor community. From what I could tell Kos went with Scoop because people in his social network thought it would be a good idea. > > Do you see a pattern here? well yes this is the description of a pattern - but I'm not sure where the data is coming from. We all have our perceptions of where thing are going. In my view Scoop is a minor player (in terms of market acceptance) > > Scoop, MovableType and WordPress are gaining big chunks of market > share (especially in publishing) in the US while Drupal/CivicSpace is > on tentative ground due in part to the dichotomy between the > development and the marketing of Drupal. I'm not sure how you arrive at "Drupal/CivicSpace is on tentative ground"... MoveableType - Drupal is not - yet. > > I am the only blogger from the top 100 moving to CivicSpace at the > moment. MediaGirl runs a Drupal site (not CivicSpace). Bob Brigham of > Swing State Project (another top 100) started a site on CivicSpace > but that's another short-term campaign site. In this case the > campaign is www.scalito.org. He was converted to CivicSpace in part > by me. Epluribus Media, a citizen journalism site that came out of > DailyKos, has 2 sites running : one on Scoop for their research work > and the other one on CivicSpace for their blogging. They were > converted to CivicSpace in part by Lynn Siprelle. if the goal is to move Drupal into the top 100 blog sites then we should do that - in my view it would be pretty easy. That isn't the goal of this community (I don't think that is on many people's radar). > > Yeah, a lot of you call blogs hype and all that; but the reality is > that blogging is here to stay. If anything, you are poised to get > more development resources with long-term political community sites > than short-term campaigns because you'll have people who've had > enough time to understand the product --even if they were not > developers . > > So your disregard about community in creating a community and content > platform is troubling. So I think that your point of view is interesting and worthwhile - but I'm not sure that I buy into all your assumptions and metrics. > > / liza > From dan at civicactions.com Wed Nov 23 18:52:36 2005 From: dan at civicactions.com (Dan Robinson) Date: Wed Nov 23 18:52:52 2005 Subject: [development] One core, many distributions In-Reply-To: <86EE9FEA-9052-4377-B69B-FBB70FDA2793@civicspacelabs.org> References: <437F6F91.40600@wanadoo.es> <42E27BE2-C5CD-437D-A5FC-495E8BDDAB0C@istyledthis.nl> <20051122090306.3a2ff3b5.jeremy@kerneltrap.org> <4384A06D.5090402@drob.org> <86EE9FEA-9052-4377-B69B-FBB70FDA2793@civicspacelabs.org> Message-ID: <4384BA74.60809@civicactions.com> > > >> This is exactly the kind of information that would be useful to people. >> >> A description of what the module does, who it is for and an endorsement >> >> of it's quality. I wonder if we could start a book about this >> somewhere. >> > > In Drupal 4.7 the administration help for throttle has been improved. > It is sourced from here: http://drupal.org/handbook/modules/throttle > > At the end of the help there is a link back to the page above. I have > just added a child page called "When to use the throttle > module". http://drupal.org/node/38661 right - and now we need (IMHO) a section of the website that will contextualize all these modules, tell me why I should care, and assure me that they are well supported and engineered. > > Thanks to Jeremy and Dan for pointing this out. > > Cheers, > Kieran > From cel4145 at cyberdash.com Wed Nov 23 19:00:43 2005 From: cel4145 at cyberdash.com (Charlie Lowe) Date: Wed Nov 23 18:59:47 2005 Subject: WARNING(virus check bypassed): Re: [development] One, core, many distributions Message-ID: <4384BC5B.1080300@cyberdash.com> NK wrote: "Lisa tried to provoke a flame war. Succeeded. Of course the developers and I am sure Gerhard too cares about the community -- why do you think he answers the forums, shepherds the translators and manages CVS accounts besides coding?" Sorry. It was not my intention to flame and I hadn't even thought of this discussion as a flame war (well, except for the highly inflammatory nature of Liza's post). It seems quite civil :) And I might be wrong, but as direct as Gerhard likes to be, I suspect he didn't take my response personally. But I do believe that more community focus, more end user focus, would benefit everyone in the long term. The payoff's not immediately apparent up front, but one must invest in the future. This, I believe, is the crux of Liza's complaint, and it's a perception of balance. More short term reward with less emphasis on long term marketing benefits vs. weighing promotion through more sensitiviy of end user needs as the means to long term prosperity. So the everyone does their own thing, "that's it," is not the mantra I would choose for Drupal. Maybe I'm wrong, but I happen to believe in the collaborative process and facilitating it as the best means to the end, and that process depends on everyone. For instance, I would suspect that if Drupal made a major push to focus on a mini-usability release for 4.8 with significantly improved documentation (no long waits for newer features), that the pay off in the next few years would be incredible. From gerhard at killesreiter.de Wed Nov 23 19:00:39 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Wed Nov 23 19:03:43 2005 Subject: [development] One core, many distributions In-Reply-To: <43849B01.3000306@cyberdash.com> References: <43849B01.3000306@cyberdash.com> Message-ID: <4384BC57.30307@killesreiter.de> Charlie Lowe wrote: > Gerhard wrote, > > "No, no, and no. The "community" (I hate that word) is not the reason > d'etre for Drupal or the reason why anybody would develop for it. The > reason is to get stuff done for our own needs. You are free to use it, > too. But that's it." > > Okay. I'm non-coder, but I do work with Drupal for my "own needs," and > would suggest that here is part of the conflict which traces back to > Liza's post. It all depends on your perspective of what is important > about open source (or free software if that is your term). I've been > doing lots of reasearch on open source lately, and IMHO, the idea that > the community is unimportant and that the code is "free to use" is > very short-sighted. Heh, I was just trying to formulate what seems to be important to most people who make unreasonable demands "free as in beer and deliver yesterday and according to my specs". > In The Success of Open Source, Stephen Weber explains that ?the > essence of open source is not the software. It is the process by which > software is created? (56). The licensing merely gives users rights. > The fact that the open source product becomes available in a gift > economy for everyone to use is not the end in itself, but rather the > means to that end as Ilkka Tuomi pointed out in an article on First > Monday, ?open-source communities control the developmental dynamic of > an evolving good. The 'openness' of open source, therefore, is more > about open future than about access to currently existing source-code > text? (442). > Ummm. Dunno. Too much talk. Good software needs to get stuff done. The advantage of OS is that I can get stuff faster done by collaborating with other people. Just imagine all the core developers had signed mutually exclusive NDAs, where would Drupal be? > So for those for whom Drupal is not just a short term solution for a > client, but part of a long strategy for developing a successful > consulting business (or other types of career advancement), the > community is very important, and even the end users of which Liza > speaks. Open source depends on collaboration--and as long as the > workflow processes and organizational structure can handle > it--increased growth in the community. End users play an important > role in this. For every 100 new end users, there are 100 new people > potentially marketing Drupal for those trying to build a client base. > And out of those 100, there are probably at least a few who will > contribute to development and increase the functionality of the product. > > Need further convincing? I sent the following statistics to Dries at > the end of October. For anyone who's long term prosperity depends on > Drupal's brand name succcess (and I think it does; IMHO, DeanSpace, > for example, did a lot for advancing Drupal's community growth), It did create a great number of Drupal sites, but how many core developers did we get from it? There's Neil Drumm, Aaron Welch and ...? And if I look closely at the Drupal project as an Open Source project, the number and quality of people working on core is the only thing that is _really_ important. > consider the followiong statistics. I think Jeff Eaton had a good reply on that part. Generally, I don't mind if people with limited abilities/ experience think that Drupal is hard to use if this enables people with the ability and experience to do amazing things. Cheers, Gerhard (and no I didn't take your post personally, why would I?) From gerhard at killesreiter.de Wed Nov 23 19:13:23 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Wed Nov 23 19:16:26 2005 Subject: [development] One core, many distributions In-Reply-To: <286DB1BB-2214-420C-8E0B-74D7BAA43EFB@culturekitchen.com> References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> <4381FADE.9090009@tinpixel.com> <3EA1E24A-D998-4AE7-A0BD-6AE3BF21728E@culturekitchen.com> <43843C82.7060704@killesreiter.de> <43847E27.30703@yahoo.co.uk> <438481CC.9040207@killesreiter.de> <286DB1BB-2214-420C-8E0B-74D7BAA43EFB@culturekitchen.com> Message-ID: <4384BF53.5010002@killesreiter.de> Liza Sabater wrote: > On Nov 23 2005, at 09:50, Gerhard Killesreiter wrote: > >> No, no, and no. The "community" (I hate that word) is not the reason >> d'etre for Drupal or the reason why anybody would develop for it. The >> reason is to get stuff done for our own needs. You are free to use >> it, too. But that's it. > > > > This is shocking for me to read. Seriously. I neve intended to offend > people with my lame jokes about geekatude but this comment is ... well > ... wow. > Lisa, this shows me that you have never been involved with open source development before. Welcome in the kitchen... > I've had my eye on Drupal since 2002. Back then I did not had a clue > of what a blog was. All I wanted was something that would make my life > easier publishing on the web. I liked what you had but held off > because, as a power user of blogging software and not a developer, I > needed something that was easier to deal with. b2 is what I That's completely ok. I am not one of the people who wants all people to use Drupal for all kind of use cases. I think that Drupal is simply too much if you look for single user blog. Use wordpress instead. > really wanted but by then the software had been abandoned (it > reappeared later as both WordPress and b2evolution). So I went the > route of MovableType because of its support and vendor communities. > And you paid for it (which is completely acceptable). > I came back to Drupal for one reason : CivicSpace. > > What Zack et al have accomplished with that distribution is > impressive. And as True, but I'd have that spelled Neil et al. ;) (merely for the reason that I don't really know what Zack does and Neil sends patches) > political bloggers like me grow their practices from personal op-ed > diaries to activist communities, CivicSpace is, in my not so humble > opinion, the best thing out there for the potential growth of networks > of online political communities. From a strategic POV, > CivicSpace/Drupal makes more sense to me than Scoop. > I am rather surprized that you mention Scoop. It isn't a topic of debate on drupal.org unlike Mambo, Wordpress, .... > But most activist community sites in the US are going the route of > Scoop. It took just one person, who happens to be also the owner of > the largest political community site in the US, to make the decision > of Drupal vs. Scoop and he went the route of Scoop for 2 reasons : > it's support and vendor communities. > > Do you see a pattern here? You want to pay for using Drupal and getting paid support? This is not a problem. > > Scoop, MovableType and WordPress are gaining big chunks of market > share (especially in publishing) in the US while Drupal/CivicSpace is > on tentative ground due in part to the dichotomy between the > development and the marketing of Drupal. > I am not really interested in market share. I want people to use software that does what they need done. If MT fits the bill better than Drupal for a particular use case, then so be it. > I am the only blogger from the top 100 moving to CivicSpace at the > moment. MediaGirl runs a Drupal site (not CivicSpace). Bob Brigham of > Swing State Project (another top 100) started a site on CivicSpace but > that's another short-term campaign site. In this case the campaign is > www.scalito.org. He was converted to CivicSpace in part by me. > Epluribus Media, a citizen journalism site that came out of DailyKos, > has 2 sites running : one on Scoop for their research work and the > other one on CivicSpace for their blogging. They were converted to > CivicSpace in part by Lynn Siprelle. > This is all very nice, but is only helpfull if Drupal is better software for their use cases. (Of course I think it is) > Yeah, a lot of you call blogs hype and all that; but the reality is > that blogging is here to stay. I always cringe when blogging is mentioned in conjunction with Drupal. Drupal is not a blogging tool (not in the sense the LJ or MT are). > If anything, you are poised to get more development resources with > long-term political community sites than short-term campaigns because > you'll have people who've had enough time to understand the product > --even if they were not developers . You probably know that I am on contract with CivicSpace, atm. I therefore get a lot of insight into the needs of such community sites. I am not sure this is in all cases directly related to Drupal core development. They are not different than other clients with regard to this. > So your disregard about community in creating a community and content > platform is troubling. The problem I have with the term "community" is that it is used to often and often not very specific. Incidentally, my own use case of Drupal involves communities. But those communities are real-life and not on-the-web and the membership of those is thus clearly defined. Cheers, Gerhard From gerhard at killesreiter.de Wed Nov 23 19:45:20 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Wed Nov 23 19:48:22 2005 Subject: WARNING(virus check bypassed): Re: [development] One core, many distributions In-Reply-To: References: <43849B01.3000306@cyberdash.com> Message-ID: <4384C6D0.4010605@killesreiter.de> Karoly Negyesi wrote: > Of course the developers and I am sure Gerhard too cares about the > community -- why do you think he answers the forums, I do that when I am bored and sometimes in the hope I might offend somebody. > shepherds the translators I like looking at exotic scripts. > and manages CVS accounts I am afraid Boris would do that if I didn't. > besides coding? > That I do for fun and intellectual curiosity. Cheers, Gerhard From starbow at citris-uc.org Wed Nov 23 20:11:59 2005 From: starbow at citris-uc.org (Tao Starbow) Date: Wed Nov 23 20:08:58 2005 Subject: [development] creating forward compatable modules? Message-ID: <4384CD0F.7060401@citris-uc.org> Hi Drupal devs, First, thank you all for an amazingly useful tool. I am a programmer at the CITRIS center at UC Berkeley. We recently finished moving our own web site (http://www.citris-uc.org) over to Drupal and I am now working on the infrastructure to allow us to start providing Drupal-based sites for more of the campus community. So far I have been able to do everything I need with the available modules and a bit of hacking, but I am now starting to create custom modules. I was wondering if it is possible to create modules that will be compatible with both 4.6 and 4.7? Also, does anyone have advice on how to calculate how many Drupal sites a server can handle? Installing new hardware can take months around here, so I need to stay well ahead of the curve. thanks, Tao Starbow CITRIS From prometheus6 at gmail.com Wed Nov 23 20:30:02 2005 From: prometheus6 at gmail.com (Earl Dunovant) Date: Wed Nov 23 20:30:05 2005 Subject: [development] creating forward compatable modules? In-Reply-To: <4384CD0F.7060401@citris-uc.org> References: <4384CD0F.7060401@citris-uc.org> Message-ID: Not really...the node type identifying and form creation functions are very different. I'd suggest writing for 4.6, keeping this in mind: http://drupal.org/node/22218 It's all the functionality you need to change between 4.6 and 4.7. On 11/23/05, Tao Starbow wrote: > > Hi Drupal devs, > > First, thank you all for an amazingly useful tool. > > I am a programmer at the CITRIS center at UC Berkeley. We recently > finished moving our own web site (http://www.citris-uc.org) over to > Drupal and I am now working on the infrastructure to allow us to start > providing Drupal-based sites for more of the campus community. So far I > have been able to do everything I need with the available modules and a > bit of hacking, but I am now starting to create custom modules. I was > wondering if it is possible to create modules that will be compatible > with both 4.6 and 4.7? > > Also, does anyone have advice on how to calculate how many Drupal sites > a server can handle? Installing new hardware can take months around > here, so I need to stay well ahead of the curve. > > thanks, > Tao Starbow > CITRIS > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051123/7bf06fb3/attachment.htm From kieran at civicspacelabs.org Wed Nov 23 20:32:00 2005 From: kieran at civicspacelabs.org (Kieran Lal) Date: Wed Nov 23 20:32:04 2005 Subject: [development] creating forward compatable modules? In-Reply-To: <4384CD0F.7060401@citris-uc.org> References: <4384CD0F.7060401@citris-uc.org> Message-ID: <40D9192F-9AEE-492A-80C2-8CAE7610AA6F@civicspacelabs.org> On Nov 23, 2005, at 12:11 PM, Tao Starbow wrote: > Hi Drupal devs, > > First, thank you all for an amazingly useful tool. > > I am a programmer at the CITRIS center at UC Berkeley. We recently > finished moving our own web site (http://www.citris-uc.org) over to > Drupal and I am now working on the infrastructure to allow us to > start providing Drupal-based sites for more of the campus > community. So far I have been able to do everything I need with the > available modules and a bit of hacking, but I am now starting to > create custom modules. I was wondering if it is possible to create > modules that will be compatible with both 4.6 and 4.7? http://drupal.org/node/22218 > > Also, does anyone have advice on how to calculate how many Drupal > sites a server can handle? Bryght runs over a thousand. It's totally traffic dependent. > Installing new hardware can take months around here, so I need to > stay well ahead of the curve. > > thanks, > Tao Starbow > CITRIS > From starbow at citris-uc.org Wed Nov 23 20:56:17 2005 From: starbow at citris-uc.org (Tao Starbow) Date: Wed Nov 23 20:53:13 2005 Subject: [development] creating forward compatable modules? In-Reply-To: <40D9192F-9AEE-492A-80C2-8CAE7610AA6F@civicspacelabs.org> References: <4384CD0F.7060401@citris-uc.org> <40D9192F-9AEE-492A-80C2-8CAE7610AA6F@civicspacelabs.org> Message-ID: <4384D771.20105@citris-uc.org> > http://drupal.org/node/22218 > Thanks. I had hoped there was some way to emulate the new 4.7 infrastructure in 4.6. I guess I will wait on the 4.7 issues until we upgrade everything. >> Also, does anyone have advice on how to calculate how many Drupal >> sites a server can handle? > > > Bryght runs over a thousand. It's totally traffic dependent. > Over a thousand sites on a single server? Wow, that is much more scalable that I would have guessed. I am coming from the JSP world, which is more or a resource hog. Is there a more useful metric, like total simultaneous authorized users or total hits per hour? How does Bryght make the call, "time to pop another server in the rack"? From dan at drob.org Wed Nov 23 20:54:00 2005 From: dan at drob.org (Dan Robinson) Date: Wed Nov 23 20:54:13 2005 Subject: [development] creating forward compatable modules? In-Reply-To: <4384CD0F.7060401@citris-uc.org> References: <4384CD0F.7060401@citris-uc.org> Message-ID: <4384D6E8.8020905@drob.org> Hi Tao, Glad to hear things are working for you. Rather than ask a very open ended question about how Drupal scales - for which the only reasonable answer is "it depends" - you might try outlining your requirements. How many sites, how many users, how are the sites going to be used, administered etc. Also some information on your current IT infrastructure - types of servers, network etc. would be helpful. Dan > Hi Drupal devs, > > First, thank you all for an amazingly useful tool. > > I am a programmer at the CITRIS center at UC Berkeley. We recently > finished moving our own web site (http://www.citris-uc.org) over to > Drupal and I am now working on the infrastructure to allow us to start > providing Drupal-based sites for more of the campus community. So far > I have been able to do everything I need with the available modules > and a bit of hacking, but I am now starting to create custom modules. > I was wondering if it is possible to create modules that will be > compatible with both 4.6 and 4.7? > > Also, does anyone have advice on how to calculate how many Drupal > sites a server can handle? Installing new hardware can take months > around here, so I need to stay well ahead of the curve. > > thanks, > Tao Starbow > CITRIS > From karoly at negyesi.net Wed Nov 23 21:13:54 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Wed Nov 23 21:09:27 2005 Subject: [development] creating forward compatable modules? In-Reply-To: <4384CD0F.7060401@citris-uc.org> References: <4384CD0F.7060401@citris-uc.org> Message-ID: > wondering if it is possible to create modules that will be compatible > with both 4.6 and 4.7? Yes. You write both modules, put each them into a .inc file and all the module is if (function_exists('_node_name')) { include 'mymodule_4.7.inc'; } else { include 'mymodule_4.7.inc'; } But I do not think this approach worths it... From cel4145 at cyberdash.com Wed Nov 23 21:40:18 2005 From: cel4145 at cyberdash.com (Charlie Lowe) Date: Wed Nov 23 21:39:21 2005 Subject: [development] One core, many distributions Message-ID: <4384E1C2.8080302@cyberdash.com> Gerhard wrote, "It did create a great number of Drupal sites, but how many core developers did we get from it? There's Neil Drumm, Aaron Welch and ...? And if I look closely at the Drupal project as an Open Source project, the number and quality of people working on core is the only thing that is _really_ important." And how many projects did its influence directly or indirectly fund so that core developers could be core developers, devoting more of their time to Drupal (hint: anyone you and I know making money through working on CivicSpace)? How many extra clients did it turn on to Drupal so that they sought core developers? How many other people have contributed patch reviews and bug fixes as a result? It's the trickle down effect. That's what is also really important ;) "(and no I didn't take your post personally, why would I?)" (I didn't think so :) From starbow at citris-uc.org Wed Nov 23 21:43:05 2005 From: starbow at citris-uc.org (Tao Starbow) Date: Wed Nov 23 21:40:07 2005 Subject: [development] creating forward compatable modules? In-Reply-To: <4384D6E8.8020905@drob.org> References: <4384CD0F.7060401@citris-uc.org> <4384D6E8.8020905@drob.org> Message-ID: <4384E269.5060001@citris-uc.org> Hi Dan, Good point. Right now our infrastructure consists of a single dell poweredge (3GHz Xeno, 2GB ram, 70 GB scsi raid), running FreeBSD. We can pretty much dedicate this box to serving Drupal (apache and mysql on the same box). We are using the engineering department's network, so I am not worried about running out of bandwidth. We hope to be able to serve as many sites as there is interest. The first stage is to set up sites for about half-a-dozen projects and centers and see how they use them. My feeling is that we could end up filling a very important niche on campus, and demand could grow quite large, once the word gets out. And CITRIS is not just UCB. Our charter is to encourage inter-departmental & multi-campus collaboration at UCB, UC Santa Cruz, UC David & UC Merced. My guess is that the typical site will have a few dozen, or less, registered users producing content that is consumed by a few thousand, or less, viewers. This is my initial target as I pick the supported modules and default configurations. But that is just my guess, and the groups might end up using the system very differently. That is why Drupal's combination of features and costomizabilty seems like such a great fit. -tao Dan Robinson wrote: >Hi Tao, > >Glad to hear things are working for you. Rather than ask a very open >ended question about how Drupal scales - for which the only reasonable >answer is "it depends" - you might try outlining your requirements. >How many sites, how many users, how are the sites going to be used, >administered etc. Also some information on your current IT >infrastructure - types of servers, network etc. would be helpful. > >Dan > > > >>Hi Drupal devs, >> >>First, thank you all for an amazingly useful tool. >> >>I am a programmer at the CITRIS center at UC Berkeley. We recently >>finished moving our own web site (http://www.citris-uc.org) over to >>Drupal and I am now working on the infrastructure to allow us to start >>providing Drupal-based sites for more of the campus community. So far >>I have been able to do everything I need with the available modules >>and a bit of hacking, but I am now starting to create custom modules. >>I was wondering if it is possible to create modules that will be >>compatible with both 4.6 and 4.7? >> >>Also, does anyone have advice on how to calculate how many Drupal >>sites a server can handle? Installing new hardware can take months >>around here, so I need to stay well ahead of the curve. >> >>thanks, >>Tao Starbow >>CITRIS >> >> >> From gerhard at killesreiter.de Wed Nov 23 21:46:46 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Wed Nov 23 21:49:49 2005 Subject: [development] creating forward compatable modules? In-Reply-To: <4384E269.5060001@citris-uc.org> References: <4384CD0F.7060401@citris-uc.org> <4384D6E8.8020905@drob.org> <4384E269.5060001@citris-uc.org> Message-ID: <4384E346.4030802@killesreiter.de> Tao Starbow wrote: > Good point. Right now our infrastructure consists of a single dell > poweredge (3GHz Xeno, 2GB ram, 70 GB scsi raid), running FreeBSD. We > can pretty much dedicate this box to serving Drupal (apache and mysql > on the same box). We are using the engineering department's network, > so I am not worried about running out of bandwidth. The main limiting number with the old drupal.org server was the number of concurrent, active registered users. Other factors were the fact that due to a lot of content being added the caching was less effective than we thought (has been worked on) and that MySQL used quite a lot of memory (we only had 1G). Cheers, Gerhard From ber at webschuur.com Wed Nov 23 13:27:27 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Wed Nov 23 21:59:01 2005 Subject: [development] bunch of minor blog module thingies Message-ID: <200511231427.27362.ber@webschuur.com> Hello, While rewriting my blog-as-container patch, I came across the following minor issues. They are certainly worth looking at, if the blog as container patch does not make it in: Blog help refers to the old location of content-settings blog_feed_last uses INNER JOINS with revisions. I thought rewrite_sql took care of that blog_page_last defines global $user yet it is never used function blog_validate calls node_validate_title is that not better handled with formapi? My patch will follow, once I got enough confidence it works as expected and after I did some usability reviews. Ber Ps: for sake of completeness: the blog as container patch will remove the blog as node type and add a checkbox to any node allowing the owner of that node to put that in his/her blog. From weitzman at tejasa.com Wed Nov 23 21:59:53 2005 From: weitzman at tejasa.com (Moshe Weitzman) Date: Wed Nov 23 21:59:57 2005 Subject: [development] creating forward compatable modules? In-Reply-To: <4384E346.4030802@killesreiter.de> References: <4384CD0F.7060401@citris-uc.org> <4384D6E8.8020905@drob.org> <4384E269.5060001@citris-uc.org> <4384E346.4030802@killesreiter.de> Message-ID: <4384E659.6070705@tejasa.com> > The main limiting number with the old drupal.org server was the number > of concurrent, active registered users. Other factors were the fact that > due to a lot of content being added the caching was less effective than > we thought (has been worked on) and that MySQL used quite a lot of > memory (we only had 1G). also it was getting slammed by misbehaving web crawlers. if we had an automatic ban module, it might have extended the life of that server. From tobias.maier at gmail.com Wed Nov 23 22:11:11 2005 From: tobias.maier at gmail.com (Tobias Maier) Date: Wed Nov 23 22:11:26 2005 Subject: [development] Re: One core, many distributions In-Reply-To: <4384E1C2.8080302@cyberdash.com> References: <4384E1C2.8080302@cyberdash.com> Message-ID: <200511232311.12452.tobias.maier@gmail.com> Charlie, are you not able to reply to the old posts? what you are doing messes up the thread... cu tobi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051123/d8568aa2/attachment.htm From ber at webschuur.com Wed Nov 23 22:11:57 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Wed Nov 23 22:11:41 2005 Subject: [development] One core, many distributions In-Reply-To: <006A0406-BB54-4D50-B3CD-AD159A06D86D@buytaert.net> References: <437F6F91.40600@wanadoo.es> <006A0406-BB54-4D50-B3CD-AD159A06D86D@buytaert.net> Message-ID: <200511232311.57621.ber@webschuur.com> Op woensdag 23 november 2005 17:15, schreef Dries Buytaert: > Clearly, there is a tension between breaking backward compatibility ? > and not breaking backward compatibility. ?Unfortunately, there is no ? > "winner" because the costs can't be quantified. ?Not the absolute ? > costs. ?Not the relative costs. ?I'm in the camp that, we are best of ? > breaking backward compatibility when necessary; it buys us ? > maintainability and flexibility, which, in turn, makes for a longer ? > product lifecycle. Lets see this is as a test case. But let us measure the "costs" in amounts of developers leqving Drupal, or even sticking with 4.6 (and thus not upgrading their contribs, or thus not contributing back to bugs and so in 4.7). And let us hope that the amount of new developers that are attracted by the easier development will at least break us even. I think we cannot quatify these costs, but we can catch an overal feeling. Ber From karoly at negyesi.net Wed Nov 23 22:21:49 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Wed Nov 23 22:17:22 2005 Subject: [development] One core, many distributions In-Reply-To: <200511232311.57621.ber@webschuur.com> References: <437F6F91.40600@wanadoo.es> <006A0406-BB54-4D50-B3CD-AD159A06D86D@buytaert.net> <200511232311.57621.ber@webschuur.com> Message-ID: > developers leqving Drupal, or even sticking with 4.6 (and thus not > upgrading > their contribs IMO this release is easier for newcomers and harder for those who already know Drupal. There is a lot to re-learn, the new node hooks/nodeapi ops, the form API (in Morbus speak: fapi :D). Regards NK From ber at webschuur.com Wed Nov 23 22:18:05 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Wed Nov 23 22:17:49 2005 Subject: [development] One core, many distributions In-Reply-To: <43846D5C.9040204@tejasa.com> References: <437F6F91.40600@wanadoo.es> <200511231256.18248.ber@webschuur.com> <43846D5C.9040204@tejasa.com> Message-ID: <200511232318.05680.ber@webschuur.com> Op woensdag 23 november 2005 14:23, schreef Moshe Weitzman: > what kind of a solution is it to propose a committee? i think you proposed > the same thing with theme system. IMO, the way to "get this on rails" is to > make tickets for things that should change, and then work to close those > tickets. skip the committee. heh, Is it still not clear that I am the hater of any comittee. I used to run around with anarchy signs all over me ;) A group is not a committee. A group is a bunch of people that have a common denominator (or some other word). What I propose is to FIRST think what we all need. I spoke to Jose and to Gerhard, who both want some internationalization. But all three of us need different things. So we could go out and make three i18n-s. But much better would it be if we grouped around what all three of us need, and on top of that build our own little house. Ber From ber at webschuur.com Wed Nov 23 22:24:44 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Wed Nov 23 22:24:27 2005 Subject: [development] creating forward compatable modules? In-Reply-To: <4384E269.5060001@citris-uc.org> References: <4384CD0F.7060401@citris-uc.org> <4384D6E8.8020905@drob.org> <4384E269.5060001@citris-uc.org> Message-ID: <200511232324.44102.ber@webschuur.com> On factor I found, and one that we used to estimate our business model is that it hardly matters if you run one site with 1000 visitors or 100 with 100. Hope that helps you finetuning your model. Ber Op woensdag 23 november 2005 22:43, schreef Tao Starbow: > Hi Dan, > > Good point. Right now our infrastructure consists of a single dell > poweredge (3GHz Xeno, 2GB ram, 70 GB scsi raid), running FreeBSD. We > can pretty much dedicate this box to serving Drupal (apache and mysql on > the same box). We are using the engineering department's network, so I > am not worried about running out of bandwidth. > > We hope to be able to serve as many sites as there is interest. The > first stage is to set up sites for about half-a-dozen projects and > centers and see how they use them. My feeling is that we could end up > filling a very important niche on campus, and demand could grow quite > large, once the word gets out. And CITRIS is not just UCB. Our charter > is to encourage inter-departmental & multi-campus collaboration at UCB, > UC Santa Cruz, UC David & UC Merced. > > My guess is that the typical site will have a few dozen, or less, > registered users producing content that is consumed by a few thousand, > or less, viewers. This is my initial target as I pick the supported > modules and default configurations. But that is just my guess, and the > groups might end up using the system very differently. That is why > Drupal's combination of features and costomizabilty seems like such a > great fit. > > -tao > > Dan Robinson wrote: > >Hi Tao, > > > >Glad to hear things are working for you. Rather than ask a very open > >ended question about how Drupal scales - for which the only reasonable > >answer is "it depends" - you might try outlining your requirements. > >How many sites, how many users, how are the sites going to be used, > >administered etc. Also some information on your current IT > >infrastructure - types of servers, network etc. would be helpful. > > > >Dan > > > >>Hi Drupal devs, > >> > >>First, thank you all for an amazingly useful tool. > >> > >>I am a programmer at the CITRIS center at UC Berkeley. We recently > >>finished moving our own web site (http://www.citris-uc.org) over to > >>Drupal and I am now working on the infrastructure to allow us to start > >>providing Drupal-based sites for more of the campus community. So far > >>I have been able to do everything I need with the available modules > >>and a bit of hacking, but I am now starting to create custom modules. > >>I was wondering if it is possible to create modules that will be > >>compatible with both 4.6 and 4.7? > >> > >>Also, does anyone have advice on how to calculate how many Drupal > >>sites a server can handle? Installing new hardware can take months > >>around here, so I need to stay well ahead of the curve. > >> > >>thanks, > >>Tao Starbow > >>CITRIS From starbow at citris-uc.org Wed Nov 23 22:38:32 2005 From: starbow at citris-uc.org (Tao Starbow) Date: Wed Nov 23 22:35:27 2005 Subject: [development] creating forward compatable modules? In-Reply-To: <200511232324.44102.ber@webschuur.com> References: <4384CD0F.7060401@citris-uc.org> <4384D6E8.8020905@drob.org> <4384E269.5060001@citris-uc.org> <200511232324.44102.ber@webschuur.com> Message-ID: <4384EF68.6020202@citris-uc.org> So you are saying that Drupal acts like one big app, independent of the number of sites (I am assuming you mean 10,000 visitors vs 100 sites with 100 visitors)? That's really good to know. Is there a rule of thumb for 1 registered user = X anonymous users? -tao B?r Kessels wrote: >On factor I found, and one that we used to estimate our business model is that >it hardly matters if you run one site with 1000 visitors or 100 with 100. > >Hope that helps you finetuning your model. > >Ber >Op woensdag 23 november 2005 22:43, schreef Tao Starbow: > > >>Hi Dan, >> >>Good point. Right now our infrastructure consists of a single dell >>poweredge (3GHz Xeno, 2GB ram, 70 GB scsi raid), running FreeBSD. We >>can pretty much dedicate this box to serving Drupal (apache and mysql on >>the same box). We are using the engineering department's network, so I >>am not worried about running out of bandwidth. >> >>We hope to be able to serve as many sites as there is interest. The >>first stage is to set up sites for about half-a-dozen projects and >>centers and see how they use them. My feeling is that we could end up >>filling a very important niche on campus, and demand could grow quite >>large, once the word gets out. And CITRIS is not just UCB. Our charter >>is to encourage inter-departmental & multi-campus collaboration at UCB, >>UC Santa Cruz, UC David & UC Merced. >> >>My guess is that the typical site will have a few dozen, or less, >>registered users producing content that is consumed by a few thousand, >>or less, viewers. This is my initial target as I pick the supported >>modules and default configurations. But that is just my guess, and the >>groups might end up using the system very differently. That is why >>Drupal's combination of features and costomizabilty seems like such a >>great fit. >> >>-tao >> >>Dan Robinson wrote: >> >> >>>Hi Tao, >>> >>>Glad to hear things are working for you. Rather than ask a very open >>>ended question about how Drupal scales - for which the only reasonable >>>answer is "it depends" - you might try outlining your requirements. >>>How many sites, how many users, how are the sites going to be used, >>>administered etc. Also some information on your current IT >>>infrastructure - types of servers, network etc. would be helpful. >>> >>>Dan >>> >>> >>> >>>>Hi Drupal devs, >>>> >>>>First, thank you all for an amazingly useful tool. >>>> >>>>I am a programmer at the CITRIS center at UC Berkeley. We recently >>>>finished moving our own web site (http://www.citris-uc.org) over to >>>>Drupal and I am now working on the infrastructure to allow us to start >>>>providing Drupal-based sites for more of the campus community. So far >>>>I have been able to do everything I need with the available modules >>>>and a bit of hacking, but I am now starting to create custom modules. >>>>I was wondering if it is possible to create modules that will be >>>>compatible with both 4.6 and 4.7? >>>> >>>>Also, does anyone have advice on how to calculate how many Drupal >>>>sites a server can handle? Installing new hardware can take months >>>>around here, so I need to stay well ahead of the curve. >>>> >>>>thanks, >>>>Tao Starbow >>>>CITRIS >>>> >>>> From nedjo at islandnet.com Wed Nov 23 22:39:51 2005 From: nedjo at islandnet.com (Nedjo Rogers) Date: Wed Nov 23 22:39:54 2005 Subject: [development] creating forward compatable modules? References: <4384CD0F.7060401@citris-uc.org> Message-ID: <006501c5f07e$d169bb00$6400a8c0@family> > I was wondering if it is possible to create modules that will be > compatible with both 4.6 and 4.7? You could write a backport of selected 4.7 features as a 4.6 module, and then write your 4.6 module using the backported 4.7 methods. This would allow you to write with 4.7-like code, and thus ease your eventual upgrading. I've taken this approach with 4.7 javascript, see: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/nedjo/modules/drupaljs/ From gordon at heydon.com.au Wed Nov 23 23:10:51 2005 From: gordon at heydon.com.au (Gordon Heydon) Date: Wed Nov 23 23:10:59 2005 Subject: [development] hook_comment() php5 issues Message-ID: <1132787451.23257.81.camel@localhost.localdomain> Hi, I have had a problem with the hook_comment() which is that the $comment var is not consistent. If it is called with the insert or update operation then the $comment is passed as an array(), where as the delete operation is an object. For php4 this doesn't matter so much, but in php5 you cannot treat an object as an array without getting a fatal error. Also from my quick investigation this is also going to be an issue with 4.7 as the edits are passing array's and the delete is an object. My question is, which way should it be so that I can roll a patch for both 4.6 and 4.7. Looking at the api, and other implementations of the hook_comment() I think it should be an array, but I think this is a little inconsistent with other parts of drupal such as nodes which are always objects. However making it an array means that it is a very small patch (change db_fetch_object() t db_fetch_array()) Thanks for any input. Gordon. From scott at 4th.com Wed Nov 23 23:30:09 2005 From: scott at 4th.com (Syscrusher) Date: Wed Nov 23 23:30:26 2005 Subject: [development] creating forward compatable modules? In-Reply-To: <4384CD0F.7060401@citris-uc.org> References: <4384CD0F.7060401@citris-uc.org> Message-ID: <200511231830.09680.scott@4th.com> On Wednesday 23 November 2005 15:11, Tao Starbow wrote: > I was > wondering if it is possible to create modules that will be compatible > with both 4.6 and 4.7? This particular upgrade happens to have the new forms API, which is a clean break with previous form-handling architecture, so although it's possible to to this, with a lot of checking for functions existing or not, it's generally not practical to do so. Easier to just create a clean copy of the module then optimize for 4.7+. In the past, though, multi-version modules haven't been too hard, at least within a close range of versions. I have several contributed modules that used the same code base for 4.5 and 4.6, with just a little conditional logic. Of course, no one can say what will be the situation between 4.7 and 4.8. :-) Drupal's philosophy seems to be one of treating database schemas and logic flow patterns as "semi-solid" and the code itself as being largely "fluid". I think that's one of the things I like about Drupal, because although it means some recode work with each version, it also tends to keep out the cruft. If you have application-specific functions that are independent of Drupal itself, you can easily separate them into an "include" file that is shared across multiple versions of your module. Hope this helps. Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher From cel4145 at cyberdash.com Thu Nov 24 00:16:47 2005 From: cel4145 at cyberdash.com (Charlie Lowe) Date: Thu Nov 24 00:15:50 2005 Subject: [development] Re: One core, many distributions Message-ID: <4385066F.50001@cyberdash.com> "are you not able to reply to the old posts? what you are doing messes up the thread..." Sorry. Digest mode. From jareyero at wanadoo.es Thu Nov 24 01:59:44 2005 From: jareyero at wanadoo.es (Jose A. Reyero) Date: Thu Nov 24 01:59:55 2005 Subject: [development] One core, many distributions In-Reply-To: <200511232318.05680.ber@webschuur.com> References: <437F6F91.40600@wanadoo.es> <200511231256.18248.ber@webschuur.com> <43846D5C.9040204@tejasa.com> <200511232318.05680.ber@webschuur.com> Message-ID: <43851E90.9090307@wanadoo.es> B?r Kessels wrote: >heh, Is it still not clear that I am the hater of any comittee. I used to run >around with anarchy signs all over me ;) > > > Same here. Every time I read "committee", I just think of people discussing all day but producing nothing at all... >What I propose is to FIRST think what we all need. I spoke to Jose and to >Gerhard, who both want some internationalization. But all three of us need >different things. So we could go out and make three i18n-s. But much better >would it be if we grouped around what all three of us need, and on top of >that build our own little house. > > > Yes, I've already been doing some work about Drupal + i18n, and think Gerhard has been doing the same... Hope we can share the results soon.. And I remember from the DrupalCon that you had some very interesting ideas about it. No doubt we should group together and get something done. And hope we won't end up producing some i19n, i20n modules -we are running out of available names in the contrib repository... ;-) >Ber > > > From jareyero at wanadoo.es Thu Nov 24 02:15:37 2005 From: jareyero at wanadoo.es (Jose A. Reyero) Date: Thu Nov 24 02:15:47 2005 Subject: [development] One core, many distributions In-Reply-To: <3EA1E24A-D998-4AE7-A0BD-6AE3BF21728E@culturekitchen.com> References: <437F6F91.40600@wanadoo.es> <200511191333.29851.larry@garfieldtech.com> <419064F6-D337-445D-A61D-28CA1ADCB95B@bryght.com> <4380E8F6.4060109@yahoo.co.uk> <8F28C7EE-48B0-41CD-ADD1-A3BADEA3C8C4@bryght.com> <43813F51.4010103@yahoo.co.uk> <4381FADE.9090009@tinpixel.com> <3EA1E24A-D998-4AE7-A0BD-6AE3BF21728E@culturekitchen.com> Message-ID: <43852249.8030704@wanadoo.es> Hi Liza, Wow! This should be a "must read" for developers. No joking. I won't say I fully agree with all the points, but it's really worth reading. Actually I'd say your opinions are equally unbalanced, on the side of the site admins who only want to keep their site up to date with a minimum pain. But we need some 'balance' here anyway - I mean in this devs list. :-) Thanks, Jose Liza Sabater wrote: > On Nov 21 2005, at 11:50, Chris Johnson wrote: > >> Liza seems to be saying "yes, Andre is the only one who thinks that >> way" but perhaps it was just sloppy use of English and she meant >> "yes, I agree with Andre." > > > Heh. > > No, I did mean the first meaning. > > Don't get me wrong, I love most of the time how software developers > think. It's sexy, but just like a lot of sexy stuff out there, it has > somewhat to do with reality :) > > The way regular, non-software developers use Drupal seems to be very > different from the way you guys conceive of it. I personally do not > care about the url BUT the reality is that you will most likely get > faster indexing of your sites by bots --and better stumble upon > traffic-- if you have verbose links as opposed to those "node/ > doohickey/numbers" system. It's not your fault or the users, it's > just is. So having flexibility on how those links are created, right > off the bat, is what Drupal ought to be striving for. > > Look, someone did a really bad, and I mean, really HORRIDLY BAD call > when they decided to take out the sessions setting options for the > 4.6 release. It was in 4.5, my site never logged me out and it seemed > that a lot of people found it useful as well. Not only did y'all take > it out, but it is nowhere stated in your documentation that this was > taken out. And not only did you take it out but, guess what, a lot of > people have grumbled about this on the support list (or so it seems), > because it was not announced nor was there an option offered to deal > with potential log-out problems. I had 5 people look at this problem > on my site and one of them came across this story by diving into your > support archives. And you did changes to the RSS system as well, and > not for the good of the user but for the good of your geekatude. > > Rule #1 : If it aint broke, dont fix it. > > You broke so many rules about market strategy, usability and software > development, I can't even fathom how you came to the conclusion this > was a good idea. Then again, yes, I can fathom the logic just by the > discussion we are having here. > > You think about the beauty of the code, the simplicity of your > logic. That's nice and good. The problem is that it has nothing to do > with reality. You are not thinking about the users --you are not > really trying to find real world solutions for the people who are > actually going to implement the product. > > Why does this have to be an either or set-up? Why not add pathauto to > the core and give it as an option for people to implement during > installation? It is sloppy thinking to say you know better because > you are a developer. Earth to geeks : Software development is never > ending, it is never done. You will never be satisfied ---treat your > skill as a disease not as a gift. You do not have to release 4.7 ---- > you are JONESING for a new coding high. And in the process, > undermining many a vendor, web admin and end user by pushing into > obsolescence their just installed site. > > If you have to release 4.7, go ahead and do it. But make sure that it > is as flexible and user centric as possible so that you can stop, > stand back and think of what better ways to implement the product as > opposed to just talk about code as art. For that, there is always > bitforms gallery [ www.bitforms.com ] and software and net art lists > sites like Rhizome [ www.rhizome.org ] and The Thing [www.thing.net ]. > > Best, > liza, who's been on the software art scene for far too long, sabater > > > From john at userfrenzy.com Thu Nov 24 02:49:41 2005 From: john at userfrenzy.com (John Handelaar) Date: Thu Nov 24 02:49:51 2005 Subject: [development] creating forward compatable modules? In-Reply-To: <4384D771.20105@citris-uc.org> References: <4384CD0F.7060401@citris-uc.org> <40D9192F-9AEE-492A-80C2-8CAE7610AA6F@civicspacelabs.org> <4384D771.20105@citris-uc.org> Message-ID: <43852A45.300@userfrenzy.com> Tao Starbow wrote: >> >> Bryght runs over a thousand. It's totally traffic dependent. >> > Over a thousand sites on a single server? Wow, that is much more > scalable that I would have guessed. I am coming from the JSP world, > which is more or a resource hog. > Is there a more useful metric, like total simultaneous authorized users > or total hits per hour? Ever the helpful answer: "It depends". I have a few very high-traffic sites (>50K pages per day) and they'd all be dying on their arse without several patches found in the forums, persistent connections and some ruthless timeout limits. Out of the box, Drupal 4.6 doesn't cut it for scaling (for those clients). It's a "3-D" sort of thing with server performance. You balance memory usage and indexing and thread spawning on the MySQL side, possibly using one or more external DB servers. At the front end you balance memory, simultaneous connections, threads spawned and process-murder with Apache/$webserver. Plus, of course, it always works just fine until you throw users at it. In the end all this stuff comes down to a process of screwing with everything until it stops being broken, then leaving it the hell alone. That's not a Drupal thing. That applies to everything I ever worked on. jh From weitzman at tejasa.com Thu Nov 24 03:20:56 2005 From: weitzman at tejasa.com (Moshe Weitzman) Date: Thu Nov 24 03:21:04 2005 Subject: [development] creating forward compatable modules? In-Reply-To: <43852A45.300@userfrenzy.com> References: <4384CD0F.7060401@citris-uc.org> <40D9192F-9AEE-492A-80C2-8CAE7610AA6F@civicspacelabs.org> <4384D771.20105@citris-uc.org> <43852A45.300@userfrenzy.com> Message-ID: <43853198.8000905@tejasa.com> > In the end all this stuff comes down to a process of screwing with > everything until it stops being broken, then leaving it the hell > alone. That's not a Drupal thing. That applies to everything I > ever worked on. spoken like someone who's done it before. performance optimization really is an art, and a messy one at that. From karoly at negyesi.net Thu Nov 24 05:05:20 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Thu Nov 24 05:00:51 2005 Subject: [development] bzr mirror of Drupal HEAD Message-ID: Hi! At http://drupal.revisioncontrol.net/core/head you can find a bzr branch, which hourly mirrors from cvs. Also, as a proof of concept, this site is also a working Drupal install. I copied default in site to drupal.revisioncontrol.net and it's working nicely. That directory is not revisioned, of course. You need bzr 0.6 to use this branch, the 0.0.8 in cygwin won't cut it. Please understand that all this is highly experimental. You need to run first bzr get http://drupal.revisioncontrol.net/core/head in a directory, which will create you a head directory (have patience -- a progress bar is coming, for now you need patience). This head directory is also known as branch -- in bzr, a branch is just a directory, if you copy that directory to some other name, then congratulations, you have branched, it's so very easy! Actually, the get commmand above is an alias to branch (and so is clone). To update this branch, use: bzr pull and that's it. I recommend setting up an hourly cron to do this for you. If you want to actually hack core, I recommend branching first: bzr branch head drupal from the dir you issued get. Now go to your new drupal directory, hack away, and use bzr commit often, whenever you are complete with a step. You can have as many branches you want. When you want to update your own branch to head, then issue from the branch you want to update: bzr merge ../head bzr commit -m"Synching with HEAD" You want to roll a patch? bzr diff ../head You can, of course do all this against the mirror itself instead of ../head but it's much faster to use your own local mirror -- and also the http://drupal.revisioncontrol.net is running on James Blackwell's donated space and bandwidth for which I am thankful, but let's not overuse it folks, OK :) ? Later I'd like to move this our own infrastructure. If you want to work together with someone then you need to make your branch public. The first thing is that you need to copy the working tree to some webspace and then you can just: bzr push sftp://somewhere.domain/path/to/my/bzr/branch Of course, ftp://username:password@ also works. The web space does not need to run bzr or anything at all. You are storing static files. Last tip: bzr help is really helpful. Have fun! NK From drupal-devel at webchick.net Thu Nov 24 05:12:35 2005 From: drupal-devel at webchick.net (Angie Byron) Date: Thu Nov 24 05:10:23 2005 Subject: [development] bzr mirror of Drupal HEAD In-Reply-To: References: Message-ID: <43854BC3.1080604@webchick.net> Just a follow-up. To download bzr to try it out, see: http://bazaar.canonical.com/DownloadBzr Make sure the version you acquire is at least 0.6. There are a lot of older ones for different distros there but 0.6+ is required. -Angie From gordon at heydon.com.au Thu Nov 24 05:29:57 2005 From: gordon at heydon.com.au (Gordon Heydon) Date: Thu Nov 24 05:30:07 2005 Subject: [development] bzr mirror of Drupal HEAD In-Reply-To: References: Message-ID: <1132810197.23257.133.camel@localhost.localdomain> Hi, This is great, I think that present a couple of choices is a good thing. On a side note I do that that having a working repository like bzr and the darcs repository is a good thing. This means that we could actually set up some automated testing to make sure that anything that is committed to core works. I do have a few mirror issues with this. (I am not anti bzr because I have put forward the darcs respository, I want to see a code management system like darcs, bzr, hg, etc) I do not like the fact that we have to be running on such a new release of bzr. I am running Ubuntu Breezy and I had to download from source. I couldn't get this from the ubuntu distribution. I like that we are getting a couple of different repositories so we can experiment and be able to make an informed decision on which code management system to move too. Now we just need to work out how to make add the contributions repository in a form that can be added to the drupal installation and have automatic testing enabled. Gordon. On Thu, 2005-11-24 at 06:05 +0100, Karoly Negyesi wrote: > Hi! > > At http://drupal.revisioncontrol.net/core/head you can find a bzr branch, > which hourly mirrors from cvs. > > Also, as a proof of concept, this site is also a working Drupal install. I > copied default in site to drupal.revisioncontrol.net and it's working > nicely. That directory is not revisioned, of course. > > You need bzr 0.6 to use this branch, the 0.0.8 in cygwin won't cut it. > > Please understand that all this is highly experimental. > > You need to run first > > bzr get http://drupal.revisioncontrol.net/core/head > > in a directory, which will create you a head directory (have patience -- a > progress bar is coming, for now you need patience). This head directory is > also known as branch -- in bzr, a branch is just a directory, if you copy > that directory to some other name, then congratulations, you have > branched, it's so very easy! Actually, the get commmand above is an alias > to branch (and so is clone). To update this branch, use: > > bzr pull > > and that's it. I recommend setting up an hourly cron to do this for you. > > If you want to actually hack core, I recommend branching first: > > bzr branch head drupal > > from the dir you issued get. Now go to your new drupal directory, hack > away, and use bzr commit often, whenever you are complete with a step. You > can have as many branches you want. > > When you want to update your own branch to head, then issue from the > branch you want to update: > > bzr merge ../head > bzr commit -m"Synching with HEAD" > > You want to roll a patch? > > bzr diff ../head > > You can, of course do all this against the mirror itself instead of > ../head but it's much faster to use your own local mirror -- and also the > http://drupal.revisioncontrol.net is running on James Blackwell's donated > space and bandwidth for which I am thankful, but let's not overuse it > folks, OK :) ? Later I'd like to move this our own infrastructure. > > If you want to work together with someone then you need to make your > branch public. The first thing is that you need to copy the working tree > to some webspace and then you can just: > > bzr push sftp://somewhere.domain/path/to/my/bzr/branch > > Of course, ftp://username:password@ also works. The web space does not > need to run bzr or anything at all. You are storing static files. > > Last tip: bzr help is really helpful. > > Have fun! > > NK > > !DSPAM:43854a06227071513039914! > From karoly at negyesi.net Thu Nov 24 06:04:35 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Thu Nov 24 06:00:05 2005 Subject: [development] bzr mirror of Drupal HEAD In-Reply-To: <1132810197.23257.133.camel@localhost.localdomain> References: <1132810197.23257.133.camel@localhost.localdomain> Message-ID: > of bzr. I am running Ubuntu Breezy and I had to download from source. I > couldn't get this from the ubuntu distribution. I am on Ubuntu Breezy as well (OK, Kubuntu Breezy) and I have this in sources.conf: deb http://people.ubuntu.com/~jbailey/snapshot/bzr/ ./ Works great. From karoly at negyesi.net Thu Nov 24 06:32:31 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Thu Nov 24 06:28:01 2005 Subject: [development] bzr battle plan Message-ID: bzr and Drupal. We now have a bzr mirror of the core. It's easier for a group of people to work on a bigger change in their own branch and submit a final diff. (hint. bzr diff --diff-options -F^f) Eventually, Dries may use a bzr branch, too and then instead of patches we may submit a link to a bzr branch instead of a patch file but this is not so important. We will provide and advertise a readonly bzr mirror for all contrib directories. If the module maintainer decides that he he does not want to deal with CVS but uses bzr instead, he will have a checkbox in project module to indicate that (or if we do not want project change, just text that). If it's a bzr maintained module then you can contribute two ways: a) send in patches (like now) b) from the bzr mirror, create your branch and submit a link to the maintainer. When the maintainer wants to commit changes back to the repo, he merges changes and pushes that to a private branch. When this push happens, a simple script is run, which commits these changes back to cvs, and from there we mirror to bzr and the cycle is complete. The problem is -- how we avoid conflicts? Simply, if a module is bzr maintained, then we make it clear that you should not commit into the CVS repository dir by the means of CVS. Either submit a patch (as you do now) or use bzr but do not commit into that dir. Ideally, cvs.drupal.org rejects this kind of commit by the means of a pre-commit script. Lacking that, the bzr to cvs script will take care of it. Then this script needs to track of the revision of the cvs revision of the files in the readonly bzr mirror (first ancestor): # check out the first ancestor cvs co foo -r$known_revision # make sure the cvs is in that state cvs commit # bring in the new/changed files bzr pull $maintainers_private_branch # make sure CVS knows about new files cvs add * # put the log into an obscure named file bzr log $maintainers_private_branch -r -1 >bzrlog # reuse that for cvs log message cvs com -F bzrlog Yes, that's the actual script. Advanced versions will be able to branch for Drupal versions. Even that should not be too hard, because the bzr mirrors (including the maintainers_private_branch) will have directories modules/eventrepeat/4.6 -- one dir for every Drupal major version. Updating the readonly bzr mirror is easy: cvs up -dP bzr commit Probably the scripts will be written in PHP and linked through the database -- after all, you need store somehwere the known_revision and maintainers_private_branch. The bzrlog also should be saved and reused when commit in the readonly space. Or to maintain simplicity maybe we could get away even with some bash scripts which store info in text files. Caveat: I am no expert of that. (note. file additions and removals needs to handled. Maybe tailor will be used here.) If the module is a CVS maintained one, then those that are on the bright side can _still_ use the readonly bzr mirror only they are not submitting bzr branch links but patches. Let's see some benefits: The necessary scripts are simple. If someone wants to run cvs update -- (s)he can do that. If a module/theme/translator maintainer is sick of cvs -- there is bzr. Also, a web upload interface is coming for bzr. If a module/theme/translator maintainer wants to use cvs -- (s)he does not need to face bzr yet his/her contributors can use that and submit patches. What's lost? If a module is bzr maintained then you can't just walk in and do an update of the module. The maintainers' responsibility is bigger. Solution? Multiple maintainers with a $maintainers_private_branch for each maintainer. You still can't just walk in, but there always will be someone who can commit your change. Note that this is pretty rare, as most module maintainers do not like if you commit into their directory in the current situation. One more thing: there should be another privilege level, they can commit against any module. Note that we do not need to change _anything_ in the modules currently used Drupal.org! Still CVS is the common denominator This is a plan which needs time. Also, bzr itself needs some time. I do not plan on posting the whole Drupal community through drupal.org until bzr 2.0 is out next spring. From karoly at negyesi.net Thu Nov 24 06:39:35 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Thu Nov 24 06:35:04 2005 Subject: [development] bzr mirror of Drupal HEAD In-Reply-To: References: Message-ID: > You want to roll a patch? > > bzr diff ../head Forgot -F^f: bzr diff --diff-options -F^f ../head From adrian at bryght.com Thu Nov 24 06:39:22 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Thu Nov 24 06:39:39 2005 Subject: [development] bzr mirror of Drupal HEAD In-Reply-To: References: Message-ID: <9C619ADE-50CB-4381-BCE1-4EF89EAD3A36@bryght.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24 Nov 2005, at 8:39 AM, Karoly Negyesi wrote: >> You want to roll a patch? >> >> bzr diff ../head >> > > Forgot -F^f: > > bzr diff --diff-options -F^f ../head isn't this the same issue that killes has with svn?? - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDhWAfgegMqdGlkasRAmdLAJ9uqs4WgF+x1k9FFiQiEhMEbpJbrwCfUepS Yo61mXXRpMA9Sgsr7oWyJHg= =JixV -----END PGP SIGNATURE----- From karoly at negyesi.net Thu Nov 24 07:07:43 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Thu Nov 24 07:03:11 2005 Subject: [development] bzr mirror of Drupal HEAD In-Reply-To: <9C619ADE-50CB-4381-BCE1-4EF89EAD3A36@bryght.com> References: <9C619ADE-50CB-4381-BCE1-4EF89EAD3A36@bryght.com> Message-ID: > isn't this the same issue that killes has with svn?? I do not think so, with svn you need to run an external diff, here all you needed was to give options. From adrian at bryght.com Thu Nov 24 08:11:29 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Thu Nov 24 08:11:45 2005 Subject: [development] bzr battle plan In-Reply-To: References: Message-ID: My major issue with BZR is source repository browsing. We need a central web based interface to browse the repository, and do diffs and the like. Applications like this exist for both svn and cvs, but not for bzr. There is a php library for svn that would allow us to directly integrate it into Drupal (which would be great for a project management tool. Think trac in php, but with Drupal). So long as the files are in one location, I'm happy .. but I really do think we need to give cvs the boot. SVN is far simpler to comprehend, and script. On 24 Nov 2005, at 8:32 AM, Karoly Negyesi wrote: > bzr and Drupal. > > We now have a bzr mirror of the core. It's easier for a group of > people > to work on a bigger change in their own branch and submit a final > diff. > (hint. bzr diff --diff-options -F^f) Eventually, Dries may use a > bzr branch, > too and then instead of patches we may submit a link to a bzr > branch instead > of a patch file but this is not so important. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com From larry at garfieldtech.com Thu Nov 24 08:19:30 2005 From: larry at garfieldtech.com (Larry Garfield) Date: Thu Nov 24 08:19:40 2005 Subject: [development] bzr battle plan In-Reply-To: References: Message-ID: <200511240219.30621.larry@garfieldtech.com> Agreed. Subversion makes branching and merging much easier than in CVS, which I understand is one of the main things people like about the non-CVS options being bandied about. You don't need a fully distributed archive in order to maintain multiple branches! The KDE project is several times the size of Drupal and they manage just fine with Subversion. Subversion also beats everything out there except CVS for adoption. The toolchain is there, the mindshare is there, and new people coming to Drupal are far more likely to be able to say "Subversion, oh I know that" than with darcs, bzr, git, or whatever. bzr only increases the barrier to entry for new developers. On Thursday 24 November 2005 02:11 am, Adrian Rossouw wrote: > My major issue with BZR is source repository browsing. > > We need a central web based interface to browse the repository, and > do diffs and the like. > Applications like this exist for both svn and cvs, but not for bzr. > > There is a php library for svn that would allow us to directly > integrate it into Drupal > (which would be great for a project management tool. Think trac in > php, but with Drupal). > > So long as the files are in one location, I'm happy .. but I really > do think we need to > give cvs the boot. SVN is far simpler to comprehend, and script. > > On 24 Nov 2005, at 8:32 AM, Karoly Negyesi wrote: > > bzr and Drupal. > > > > We now have a bzr mirror of the core. It's easier for a group of > > people > > to work on a bigger change in their own branch and submit a final > > diff. > > (hint. bzr diff --diff-options -F^f) Eventually, Dries may use a > > bzr branch, > > too and then instead of patches we may submit a link to a bzr > > branch instead > > of a patch file but this is not so important. > > -- > Adrian Rossouw > Drupal developer and Bryght Guy > http://drupal.org | http://bryght.com -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson From dries.buytaert at gmail.com Thu Nov 24 08:42:46 2005 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Thu Nov 24 08:42:52 2005 Subject: [development] creating forward compatable modules? In-Reply-To: <4384E269.5060001@citris-uc.org> References: <4384CD0F.7060401@citris-uc.org> <4384D6E8.8020905@drob.org> <4384E269.5060001@citris-uc.org> Message-ID: <6C6A7B4C-74B2-411E-84BC-EE8BB41055B1@buytaert.net> On 23 Nov 2005, at 22:43, Tao Starbow wrote: > Good point. Right now our infrastructure consists of a single dell > poweredge (3GHz Xeno, 2GB ram, 70 GB scsi raid), running FreeBSD. > We can pretty much dedicate this box to serving Drupal (apache and > mysql on the same box). We are using the engineering department's > network, so I am not worried about running out of bandwidth. Looks like that machine should be able to host quite a few Drupal sites; I'm thinking 250 sites should be possible, but it obviously depends on a number of parameters as mentioned elsewhere in this thread. Fact is that many small sites scale better than one really big site; because each site is actually fairly small and reasonably static, Drupal's page caching mechanism should be very effective. (I'm somewhat puzzled by Ber's numbers and would like to know more about why he thinks otherwise.) Creating "forward compatible modules" does not look like a practical option. It's better to stick with Drupal 4.6 and to upgrade to Drupal 4.7 when the time is right. Upgrading to Drupal 4.7 (including custom modules) should be relatively straightforward but might take a bit of time depending on the amount of custom changes and custom modules. One thing you can do is start off with PHPTemplate-based themes rather than XTemplate-based themes; PHPTemplate will be the default theme engine in Drupal 4.7. If you are somewhat adventurous you could start out with Drupal CVS HEAD (the forthcoming Drupal 4.7); it shouldn't be too bad if you stick with core modules. A good formula for success is to participate in the development of Drupal; you'll quickly learn the ins and outs and will be able to weight decisions much more efficiently. Tao, some of us (including myself) are very interested in improving Drupal's multi-site features. It is inevitable that you'll run into some gotchas so I'm hoping you'll participate in the development of said feature. (Eg. Adrian has been working on a patch to lock or restrict certain settings.) So welcome on board, and looking forward to your contributions. ;) -- Dries Buytaert :: http://www.buytaert.net/ From ber at webschuur.com Thu Nov 24 09:02:39 2005 From: ber at webschuur.com (=?utf-8?q?B=C3=A8r_Kessels?=) Date: Thu Nov 24 09:02:23 2005 Subject: [development] One core, many distributions In-Reply-To: References: <437F6F91.40600@wanadoo.es> <200511232311.57621.ber@webschuur.com> Message-ID: <200511241002.39059.ber@webschuur.com> Op woensdag 23 november 2005 23:21, schreef Karoly Negyesi: > > developers leqving Drupal, or even sticking with 4.6 (and thus not > > upgrading > > their contribs > > IMO this release is easier for newcomers and harder for those who already > know Drupal. There is a lot to re-learn, the new node hooks/nodeapi ops, > the form API (in Morbus speak: fapi :D). Yes, this is what I mean. If, netto, we have substantial more developers at the end of 4.7, we made the correct choice. I beleive we should count our success mostly in the "currency" Developers. I do not care about amount of users, per se, to me they are but a factor to get more developers. We should take the word "developer" with a grain of salt, though. Anyone contributing to the development of Drupal is a developer in this case. Ber From ber at webschuur.com Thu Nov 24 09:05:31 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Thu Nov 24 09:05:14 2005 Subject: [development] One core, many distributions In-Reply-To: <43851E90.9090307@wanadoo.es> References: <437F6F91.40600@wanadoo.es> <200511232318.05680.ber@webschuur.com> <43851E90.9090307@wanadoo.es> Message-ID: <200511241005.31861.ber@webschuur.com> Op donderdag 24 november 2005 02:59, schreef Jose A. Reyero: > And I remember from the DrupalCon that you had some very interesting > ideas about it. Next week I start a project where I will use flexinode / form API for this, So any field can be duplicated for each language. What I wat to do too, is pull out the langauge switcher, and make that a separate module. Ber From ber at webschuur.com Thu Nov 24 09:12:50 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Thu Nov 24 09:12:35 2005 Subject: [development] creating forward compatable modules? In-Reply-To: <4384EF68.6020202@citris-uc.org> References: <4384CD0F.7060401@citris-uc.org> <200511232324.44102.ber@webschuur.com> <4384EF68.6020202@citris-uc.org> Message-ID: <200511241012.50430.ber@webschuur.com> This is what i calculated on about 40 sites. When one site was very active, I saw the same issues / problems then when several sites had slightly higher load. Op woensdag 23 november 2005 23:38, schreef Tao Starbow: > So you are saying that Drupal acts like one big app, independent of the > number of sites (I am assuming you mean 10,000 visitors vs 100 sites > with 100 visitors)? Sorry, it was late :) 10.000 == 100 x 100 I am not sure if this is linear in every amount, but the way drupal multisite works, I would think it does. > That's really good to know. Is there a rule of thumb > for 1 registered user = X anonymous users? That really depends on the used modules. In fact it all does. Especially contributed modules often perform very bad. But I do not have any such figures. > > -tao > > B?r Kessels wrote: > >On factor I found, and one that we used to estimate our business model is > > that it hardly matters if you run one site with 1000 visitors or 100 with > > 100. > > > >Hope that helps you finetuning your model. > > > >Ber > > > >Op woensdag 23 november 2005 22:43, schreef Tao Starbow: > >>Hi Dan, > >> > >>Good point. Right now our infrastructure consists of a single dell > >>poweredge (3GHz Xeno, 2GB ram, 70 GB scsi raid), running FreeBSD. We > >>can pretty much dedicate this box to serving Drupal (apache and mysql on > >>the same box). We are using the engineering department's network, so I > >>am not worried about running out of bandwidth. > >> > >>We hope to be able to serve as many sites as there is interest. The > >>first stage is to set up sites for about half-a-dozen projects and > >>centers and see how they use them. My feeling is that we could end up > >>filling a very important niche on campus, and demand could grow quite > >>large, once the word gets out. And CITRIS is not just UCB. Our charter > >>is to encourage inter-departmental & multi-campus collaboration at UCB, > >>UC Santa Cruz, UC David & UC Merced. > >> > >>My guess is that the typical site will have a few dozen, or less, > >>registered users producing content that is consumed by a few thousand, > >>or less, viewers. This is my initial target as I pick the supported > >>modules and default configurations. But that is just my guess, and the > >>groups might end up using the system very differently. That is why > >>Drupal's combination of features and costomizabilty seems like such a > >>great fit. > >> > >>-tao > >> > >>Dan Robinson wrote: > >>>Hi Tao, > >>> > >>>Glad to hear things are working for you. Rather than ask a very open > >>>ended question about how Drupal scales - for which the only reasonable > >>>answer is "it depends" - you might try outlining your requirements. > >>>How many sites, how many users, how are the sites going to be used, > >>>administered etc. Also some information on your current IT > >>>infrastructure - types of servers, network etc. would be helpful. > >>> > >>>Dan > >>> > >>>>Hi Drupal devs, > >>>> > >>>>First, thank you all for an amazingly useful tool. > >>>> > >>>>I am a programmer at the CITRIS center at UC Berkeley. We recently > >>>>finished moving our own web site (http://www.citris-uc.org) over to > >>>>Drupal and I am now working on the infrastructure to allow us to start > >>>>providing Drupal-based sites for more of the campus community. So far > >>>>I have been able to do everything I need with the available modules > >>>>and a bit of hacking, but I am now starting to create custom modules. > >>>>I was wondering if it is possible to create modules that will be > >>>>compatible with both 4.6 and 4.7? > >>>> > >>>>Also, does anyone have advice on how to calculate how many Drupal > >>>>sites a server can handle? Installing new hardware can take months > >>>>around here, so I need to stay well ahead of the curve. > >>>> > >>>>thanks, > >>>>Tao Starbow > >>>>CITRIS From dries.buytaert at gmail.com Thu Nov 24 09:12:41 2005 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Thu Nov 24 09:12:45 2005 Subject: [development] bzr battle plan In-Reply-To: References: Message-ID: <99551D52-1ECB-4952-85B9-0952E9DB741D@buytaert.net> On 24 Nov 2005, at 07:32, Karoly Negyesi wrote: > We now have a bzr mirror of the core. It's easier for a group of > people > to work on a bigger change in their own branch and submit a final > diff. > (hint. bzr diff --diff-options -F^f) Eventually, Dries may use a > bzr branch, > too and then instead of patches we may submit a link to a bzr > branch instead > of a patch file but this is not so important. I do not plan to use bzr at this point. (Please note that this is a chx-ism, and not something I approved up front.) Furthermore, I'll continue to make changes to contributed projects using CVS, whether they are "bzr maintained" or not. The setup should not impose restrictions on anyone's workflow. Right now, it seems to complicate collaboration by forcing people to use bzr. If they can't co-exist, bzr is not a viable solution, and I will not accept the project module and CVS changes it takes. -- Dries Buytaert :: http://www.buytaert.net/ From ber at webschuur.com Thu Nov 24 09:15:58 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Thu Nov 24 09:15:42 2005 Subject: [development] creating forward compatable modules? In-Reply-To: <6C6A7B4C-74B2-411E-84BC-EE8BB41055B1@buytaert.net> References: <4384CD0F.7060401@citris-uc.org> <4384E269.5060001@citris-uc.org> <6C6A7B4C-74B2-411E-84BC-EE8BB41055B1@buytaert.net> Message-ID: <200511241015.58094.ber@webschuur.com> Op donderdag 24 november 2005 09:42, schreef Dries Buytaert: > (I'm somewhat puzzled by Ber's numbers and would like to know more ? > about why he thinks otherwise.) These were measured. But now you mention that caching I am somehwat puzzled too. But I think I know the answer. All sites are non-community sites. Meaning that they are not updated as frequent as a community site would. Does anybody know a good method to measure the amount of cached pages / uncached pages. Furhtermore, this was measured with 4.6 only. Ber From dries.buytaert at gmail.com Thu Nov 24 09:19:28 2005 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Thu Nov 24 09:19:34 2005 Subject: [development] creating forward compatable modules? In-Reply-To: <200511241012.50430.ber@webschuur.com> References: <4384CD0F.7060401@citris-uc.org> <200511232324.44102.ber@webschuur.com> <4384EF68.6020202@citris-uc.org> <200511241012.50430.ber@webschuur.com> Message-ID: > When one site was very active, I saw the same issues / problems > then when > several sites had slightly higher load. I don't agree with Ber's conclusion. Ber, what test methodology did you use to draw that conclusion? Because each site has its own cache, multiple sites should scale better than one big site. No? -- Dries Buytaert :: http://www.buytaert.net/ From dries.buytaert at gmail.com Thu Nov 24 09:23:18 2005 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Thu Nov 24 09:23:27 2005 Subject: [development] creating forward compatable modules? In-Reply-To: <200511241015.58094.ber@webschuur.com> References: <4384CD0F.7060401@citris-uc.org> <4384E269.5060001@citris-uc.org> <6C6A7B4C-74B2-411E-84BC-EE8BB41055B1@buytaert.net> <200511241015.58094.ber@webschuur.com> Message-ID: > These were measured. But now you mention that caching I am somehwat > puzzled > too. But I think I know the answer. All sites are non-community sites. > Meaning that they are not updated as frequent as a community site > would. If you are measuring static sites, your conclusion makes sense. If, however, your site has a dynamic aspect (forums, comments, RSS aggregator, etc) this is no longer valid, I think. -- Dries Buytaert :: http://www.buytaert.net/ From gildas.cotomale at gmail.com Thu Nov 24 09:28:39 2005 From: gildas.cotomale at gmail.com (Gildas COTOMALE) Date: Thu Nov 24 09:28:42 2005 Subject: [development] bzr battle plan In-Reply-To: <200511240219.30621.larry@garfieldtech.com> References: <200511240219.30621.larry@garfieldtech.com> Message-ID: <99469d070511240128q6e1894aq@mail.gmail.com> 2005/11/24, Larry Garfield : > Subversion also beats everything out there except CVS for adoption. The > toolchain is there, the mindshare is there, and new people coming to Drupal > are far more likely to be able to say "Subversion, oh I know that" than with And, i used to say, those who don't know SVN often know CVS and can switch easely... That's why SVN is a good compromission imho. > darcs, bzr, git, or whatever. bzr only increases the barrier to entry for > new developers. However, let's keep an eye on others alternatives... So we'll be fully ready when time will come to another (or better) choice ;-) > Suggest: why not add a poll on http://drupal.org to ask people what's their favorite CSM..? We'll have so a good idea how ready future dev' are ready to switch to something else and what.. -- vi is a real WYSIWYG editor: you see text, you get text. From karoly at negyesi.net Thu Nov 24 09:48:47 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Thu Nov 24 09:44:15 2005 Subject: [development] bzr battle plan In-Reply-To: <99551D52-1ECB-4952-85B9-0952E9DB741D@buytaert.net> References: <99551D52-1ECB-4952-85B9-0952E9DB741D@buytaert.net> Message-ID: >> Eventually, Dries may use a bzr > I do not plan to use bzr at this point. (Please note that this is a > chx-ism, and not something I approved up front.) I emphasize then "eventually" and "may". > Furthermore, I'll continue to make changes to contributed projects using > CVS, whether they are "bzr maintained" or not. The setup should not > impose restrictions on anyone's workflow. Here is an addon then: When there is a cvs commit to a 'bzr maintained' module, the maintainer can decide whether he likes it or not and if he does like it, then he can issue an update of the readonly bzr mirror. The maintainer now needs to issue a bzr merge so that his branch contains the cvs update, too. bzr merge is excellent in handling three ways merges so there should not be a problem. As the typical way to contribute to someone else's project is submitting patches in the issue queue, this won't be necessary often. Note that the current situation is very similar: if you are working on your local checkout and someone does a commit against your module then you need to merge that. bzr merge is just better for this task. Regards NK From ber at webschuur.com Thu Nov 24 09:45:33 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Thu Nov 24 09:45:17 2005 Subject: [development] creating forward compatable modules? In-Reply-To: References: <4384CD0F.7060401@citris-uc.org> <200511241015.58094.ber@webschuur.com> Message-ID: <200511241045.33446.ber@webschuur.com> Op donderdag 24 november 2005 10:23, schreef Dries Buytaert: > If, however, your site has a dynamic aspect (forums, comments, RSS ? > aggregator, etc) this is no longer valid, I think. * These sites have hardly any registered users. only those adminstrating and moderating and those adding a few stories / images a day. * I do use node aggragator on several sites and aggregator on hardly any. it is ran every two hours. * Comments are neglecatble. Average of all sites brings me a comment rate of 0.2 (two comments on ten posts) * No forums, no buddylists and no dynamic filters. I hope this clarifies it even more: I think the conclusion again is: "it depends", in this case on the sort of site. Ber From karoly at negyesi.net Thu Nov 24 09:55:54 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Thu Nov 24 09:51:22 2005 Subject: [development] bzr battle plan In-Reply-To: <99469d070511240128q6e1894aq@mail.gmail.com> References: <200511240219.30621.larry@garfieldtech.com> <99469d070511240128q6e1894aq@mail.gmail.com> Message-ID: > And, i used to say, those who don't know SVN often know CVS and can > switch easely... That's why SVN is a good compromission imho. My concern are developers, translators and themers who know neither. I'd like to provide a web service so they do not need to know either. > Suggest: why not add a poll on http://drupal.org to ask people what's > their favorite CSM..? We'll have so a good idea how ready future dev' > are ready to switch to something else and what.. I think there is no need. Here's why: you have people who are working on making bzr for Drupal happen, at this moment it's hunmonk, chx -- and jblack from the bzr project itself. No matter what you poll, you need people to get things rolling. And note that with my battle plan I am not forcing _any_ change. I plan to offer bzr, if you like it, that's great, but if you do not, so be it. Again and again I will state that SVN solves none of our growing problems. It could if we would change dramatically our workflow but I do not think we are ready for that. I set up the bzr mirror of core so that people who want to work together on something bigger just can. A loose team of contributors needs a distributed RCS IMO. So if Drupal goes to SVN, my battle plan applies just the same. But again, that needs work, and so far I have seen only talk, including myself. I am sold to the bzr idea and actually working on it, and yes the bzr.module will happen sooner than later. From jareyero at wanadoo.es Thu Nov 24 09:55:39 2005 From: jareyero at wanadoo.es (Jose A. Reyero) Date: Thu Nov 24 09:55:49 2005 Subject: [development] One core, many distributions In-Reply-To: <200511241005.31861.ber@webschuur.com> References: <437F6F91.40600@wanadoo.es> <200511232318.05680.ber@webschuur.com> <43851E90.9090307@wanadoo.es> <200511241005.31861.ber@webschuur.com> Message-ID: <43858E1B.3090105@wanadoo.es> B?r Kessels wrote: >Op donderdag 24 november 2005 02:59, schreef Jose A. Reyero: > > >>And I remember from the DrupalCon that you had some very interesting >>ideas about it. >> >> > >Next week I start a project where I will use flexinode / form API for this, So >any field can be duplicated for each language. > >What I wat to do too, is pull out the langauge switcher, and make that a >separate module. > > Great, well have another one then :( What I was thinking was: pulling out the translation from i18n and make it a separate module, then have a lightweight i18n that would be mostly a language switcher :-) But I intended to do it for 4.7... Are you developing for 4.6 or 4.7 ? >Ber > > > From dries.buytaert at gmail.com Thu Nov 24 10:23:31 2005 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Thu Nov 24 10:23:36 2005 Subject: [development] bzr battle plan In-Reply-To: References: <99551D52-1ECB-4952-85B9-0952E9DB741D@buytaert.net> Message-ID: <854B0362-B583-4492-AE5A-99C74B7DF5DE@buytaert.net> On 24 Nov 2005, at 10:48, Karoly Negyesi wrote: >> I do not plan to use bzr at this point. (Please note that this is >> a chx-ism, and not something I approved up front.) > > I emphasize then "eventually" and "may". I know. I just wanted to point out that: 1. I won't switch to bzr (yet), and that 2. bzr is not officially supported (yet). I actively used darcs for a couple months. It looked exciting in the beginning, but even after a while, I could not get used to it and I decided to stick with CVS. Having to adapt your workflow only to find out it isn't what you hoped for can be frustrating. I still use darcs occasionally because of a research project I'm involved in. Also, I know that bzr is not darcs, and that bzr has some functionality that is sorely missing in darcs. The point is that I'm somewhat reluctant to go through this again. That said, the bzr repository makes for an interesting experiment, and I understand the potential benefit of a distributed model in the context of Drupal (it had big impact on Linux kernel development). If bzr gets support within the Drupal community, we could consider hosting the bzr repository ourselves and actively supporting it. If it doesn't take off, no harm done. We'll see how it goes. :-) In the mean time, I'll toy with bzr a little, and keep an eye on how it gets used within the Drupal community. Hopefully that clarifies my take on this, -- Dries Buytaert :: http://www.buytaert.net/ From ber at webschuur.com Thu Nov 24 10:21:03 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Thu Nov 24 10:31:09 2005 Subject: [development] One core, many distributions In-Reply-To: <43858E1B.3090105@wanadoo.es> References: <437F6F91.40600@wanadoo.es> <200511241005.31861.ber@webschuur.com> <43858E1B.3090105@wanadoo.es> Message-ID: <200511241121.03518.ber@webschuur.com> Op donderdag 24 november 2005 10:55, schreef Jose A. Reyero: > What I was thinking was: pulling out the translation from i18n and make > it a separate module, then have a lightweight i18n that would be mostly > a language switcher Sorry for the misunderstanding, we mean the same! And yes, this will be for HEAD, From ber at webschuur.com Thu Nov 24 11:11:07 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Thu Nov 24 11:10:52 2005 Subject: [development] bzr battle plan In-Reply-To: <854B0362-B583-4492-AE5A-99C74B7DF5DE@buytaert.net> References: <854B0362-B583-4492-AE5A-99C74B7DF5DE@buytaert.net> Message-ID: <200511241211.08007.ber@webschuur.com> I "branched" upload to make it a full blown modular file system. It now lives in CVS contribs. Recently some developers showed interest, it seems this porject is taking off. I think this might be an interesting testcase, because I think these useacases is exactly what BZR is good at. If someone can hold my hand while getting this "contrib" out of CVS and into that BZR, we have a nice place to work, we can see how well bzr takes off. And in the end we can evaluate this. Ber Op donderdag 24 november 2005 11:23, schreef Dries Buytaert: > On 24 Nov 2005, at 10:48, Karoly Negyesi wrote: > >> I do not plan to use bzr at this point. (Please note that this is > >> a chx-ism, and not something I approved up front.) > > > > I emphasize then "eventually" and "may". > > I know. I just wanted to point out that: > > 1. I won't switch to bzr (yet), and that > 2. bzr is not officially supported (yet). > > I actively used darcs for a couple months. It looked exciting in the > beginning, but even after a while, I could not get used to it and I > decided to stick with CVS. Having to adapt your workflow only to > find out it isn't what you hoped for can be frustrating. I still use > darcs occasionally because of a research project I'm involved in. > Also, I know that bzr is not darcs, and that bzr has some > functionality that is sorely missing in darcs. The point is that I'm > somewhat reluctant to go through this again. > > That said, the bzr repository makes for an interesting experiment, > and I understand the potential benefit of a distributed model in the > context of Drupal (it had big impact on Linux kernel development). > If bzr gets support within the Drupal community, we could consider > hosting the bzr repository ourselves and actively supporting it. If > it doesn't take off, no harm done. We'll see how it goes. :-) In > the mean time, I'll toy with bzr a little, and keep an eye on how it > gets used within the Drupal community. > > Hopefully that clarifies my take on this, > > -- > Dries Buytaert :: http://www.buytaert.net/ From adrinux at gmail.com Thu Nov 24 12:21:35 2005 From: adrinux at gmail.com (Adrian Simmons) Date: Thu Nov 24 12:21:40 2005 Subject: [development] bzr mirror of Drupal HEAD In-Reply-To: References: Message-ID: <4385B04F.1050605@gmail.com> Karoly Negyesi wrote: > You need bzr 0.6 to use this branch, the 0.0.8 in cygwin won't cut it. Those of us on OS X with Fink can do: fink install bzr-py24 bzr-py24-bin > (have patience -- > a progress bar is coming, for now you need patience). Indeed, it wasn't fast and it looks like it's hung...but it hasn't. Patience. -- adrinux (aka Adrian Simmons) e-mail AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com From adrinux at gmail.com Thu Nov 24 12:26:54 2005 From: adrinux at gmail.com (Adrian Simmons) Date: Thu Nov 24 12:26:59 2005 Subject: [development] bzr battle plan In-Reply-To: References: Message-ID: <4385B18E.8030801@gmail.com> Karoly Negyesi wrote: > we may submit a link to a bzr branch instead > of a patch file but this is not so important. I think that is actually a flaw - someone's web site goes down and suddenly you can't test there work. Code could get lost to the project in some instances. I think we'd always want to specify a patch should be provided as well as a link. This is all just experimentation at the moment though :) -- adrinux (aka Adrian Simmons) e-mail AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com From adrinux at gmail.com Thu Nov 24 12:57:37 2005 From: adrinux at gmail.com (Adrian Simmons) Date: Thu Nov 24 12:57:40 2005 Subject: SVN battle plan? was Re: [development] bzr battle plan In-Reply-To: References: Message-ID: <4385B8C1.6000506@gmail.com> Adrian Rossouw wrote: > but I really do think we need to > give cvs the boot. SVN is far simpler to comprehend, and script. Indeed, I really think CVS actually does harm in the confusion it causes for new users. SVN is a little bit more intuitive, and it's easier to fix mistakes (versioned directories, "svn move" and "svn rename"). But we are left with the same questions: Will Dries ever approve the move to SVN? What would it take for that to happen? What do we need to do to make it happen? I have to point out that we are probably already loosing out because of sticking with CVS. I for one don't use drupal.org's CVS for my development (one unpopular module and one reasonably popular theme), I keep everything in a local SVN repository, do all the changes in that then "svn export" and upload that to drupal.org CVS. It's more work than it should be but less painful than working with CVS directly. I suspect I'm not the only one doing this. bzr is interesting, and I will hopefully find the time to play with it, but it's not mature, and I still think we'd be better of allowing some branches to be created for collaborative work (such as the form-API). I believe it's possible to limit access to parts of the repository with SVN, so perhaps a limited set of people could be granted access to a specific branch, this would also work in nicely with Adrian's DEP suggestion, a DEP would be required before the branch is created. I really feel we're not making proper use use of current versioning systems ability to facilitate collaboration, it might be nice to see what we can do with that before going for something like bzr. -- adrinux (aka Adrian Simmons) e-mail AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com From bmansion at mamasam.com Thu Nov 24 13:42:58 2005 From: bmansion at mamasam.com (Bertrand Mansion) Date: Thu Nov 24 13:42:39 2005 Subject: SVN battle plan? was Re: [development] bzr battle plan In-Reply-To: <4385B8C1.6000506@gmail.com> Message-ID: Adrian Simmons wrote: >Adrian Rossouw wrote: >> but I really do think we need to >> give cvs the boot. SVN is far simpler to comprehend, and script. >Indeed, I really think CVS actually does harm in the confusion it causes for new > users. SVN is a little bit more intuitive, and it's easier to fix mistakes >(versioned directories, "svn move" and "svn rename"). > >But we are left with the same questions: > >Will Dries ever approve the move to SVN? >What would it take for that to happen? >What do we need to do to make it happen? I didn't really follow the thread so excuse me if I am missing the point. In my opinion, Drupal is better using CVS than SVN. With SVN, you get a new revision number on every commit. That's fine with compact projects like Drupal core. But that's not so fine if commits done to themes, modules, etc are done in the same repository. It will make it hard for everyone to follow what's going on. This is especially true since I have noticed that a few developers still don't understand how to make grouped commits and keep on commiting 100s files one at a time... With SVN and this kind of behavior, you get a +100 revision number on the main repository. So unless you create one repository per module, theme, projects, you are safer using CVS. -- Bertrand Mansion Mamasam Tel : +33 1 48 89 88 26 http://www.mamasam.com Creative Internet Solutions From adrian at bryght.com Thu Nov 24 14:04:57 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Thu Nov 24 14:05:13 2005 Subject: SVN battle plan? was Re: [development] bzr battle plan In-Reply-To: References: Message-ID: <03AB5334-9015-4E47-AC84-386307017A9D@bryght.com> On 24 Nov 2005, at 3:42 PM, Bertrand Mansion wrote: > In my opinion, Drupal is better using CVS than SVN. With SVN, you > get a new > revision number on every commit. That's fine with compact projects > like Drupal > core. But that's not so fine if commits done to themes, modules, > etc are done in > the same repository. It will make it hard for everyone to follow > what's going > on. It's just a number. It doesn't matter if the numbers don't follow on each other inside the directory. Our versioning will be based on the path .. ie : branches/4.6/modules/ modulename. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com From prometheus6 at gmail.com Thu Nov 24 14:20:17 2005 From: prometheus6 at gmail.com (Earl Dunovant) Date: Thu Nov 24 14:20:20 2005 Subject: [development] One core, many distributions In-Reply-To: <200511241002.39059.ber@webschuur.com> References: <437F6F91.40600@wanadoo.es> <200511232311.57621.ber@webschuur.com> <200511241002.39059.ber@webschuur.com> Message-ID: I think I want to be sure I understand this. On 11/24/05, B?r Kessels wrote: > > If, netto, we have substantial more developers at the end of 4.7, we made > the > correct choice. I beleive we should count our success mostly in the > "currency" Developers. I do not care about amount of users, per se, to me > they are but a factor to get more developers. > We should take the word "developer" with a grain of salt, though. Anyone > contributing to the development of Drupal is a developer in this case. > By "users" you mean 'people that use web sites built using Drupal'? And by "developers" you mean 'people that build web sites using Drupal, + plus project contributors"? I hope? Because when I think of Drupal users I think of "people that build web sites using Drupal' and developers, to me, are project contributors. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051124/a90a9979/attachment.htm From gerhard at killesreiter.de Thu Nov 24 14:19:32 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Thu Nov 24 14:22:34 2005 Subject: [development] bzr mirror of Drupal HEAD In-Reply-To: References: <9C619ADE-50CB-4381-BCE1-4EF89EAD3A36@bryght.com> Message-ID: <4385CBF4.4090403@killesreiter.de> Karoly Negyesi wrote: >> isn't this the same issue that killes has with svn?? > > > I do not think so, with svn you need to run an external diff, here all > you needed was to give options. Yep, I still think it is too long (maybe there is short option too?) but it is a different issue and only half the length of the svn command. Rest assured that I will not review any patch which hasn't been produced with these options, though. Cheers, Gerhard From ber at webschuur.com Thu Nov 24 14:40:21 2005 From: ber at webschuur.com (=?utf-8?q?B=C3=A8r_Kessels?=) Date: Thu Nov 24 14:40:07 2005 Subject: [development] One core, many distributions In-Reply-To: References: <437F6F91.40600@wanadoo.es> <200511241002.39059.ber@webschuur.com> Message-ID: <200511241540.21366.ber@webschuur.com> Let me stress that this is my opinion. Op donderdag 24 november 2005 15:20, schreef Earl Dunovant: > I think I want to be sure I understand this. > > On 11/24/05, B?r Kessels wrote: > > If, netto, we have substantial more developers at the end of 4.7, we made > > the > > correct choice. I beleive we should count our success mostly in the > > "currency" Developers. I do not care about amount of users, per se, to me > > they are but a factor to get more developers. > > We should take the word "developer" with a grain of salt, though. Anyone > > contributing to the development of Drupal is a developer in this case. > > By "users" you mean 'people that use web sites built using Drupal'? And by > "developers" you mean 'people that build web sites using Drupal, + plus > project contributors"? No. I mean people that download drupal and use it for their website. A developer would be any of these users that actually contributes something back. I (and again, let me stress that letter I), am not really waiting for people filing feature requests on my contribs. Nor people filing bug reports for OddFlavouredHostingProvider. Those are their itches. My itches are to get stuff working here. Nor for those that ask support, because they cannot find docs for one of these contribs. I am waiting, however for people whom either contribute a patch, or write a nice howto or doc page on something. Or who actively help by handing me good ways to improve my experience of these contribs. I know. This is selfish. But I do this for myself, in the first place. I am not developing stuff for FooBar Inc. or Joe User. If they can reuse my work that is great. If they then contribute bak that is even better. But once they start costing me, my time, and my efforts (and sometimes even manage to flame me in that process.....) I can really do without them. They use "our" bandwith, "our" CPU cycles, demanding our time and give nothing back. Hence comes my statement that one should not calculate an OSS project based on numbers of users, but on amount of actively involved people. > I hope? Because when I think of Drupal users I think of "people that build > web sites using Drupal' and developers, to me, are project contributors. From gerhard at killesreiter.de Thu Nov 24 14:40:35 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Thu Nov 24 14:43:37 2005 Subject: [development] bzr battle plan In-Reply-To: <99469d070511240128q6e1894aq@mail.gmail.com> References: <200511240219.30621.larry@garfieldtech.com> <99469d070511240128q6e1894aq@mail.gmail.com> Message-ID: <4385D0E3.3030005@killesreiter.de> Gildas COTOMALE wrote: >Suggest: why not add a poll on http://drupal.org to ask people what's >their favorite CSM..? We'll have so a good idea how ready future dev' >are ready to switch to something else and what.. > > > It qould be quite pointless as the popular opinion does not matter at all as is often the case in software development. If Dries doesn't like it it won't get used by the project. Of course people can set up their own mirros using whatever tool they like. In the end all what counts is the quality of the code. Cheers, Gerhard From scott at 4th.com Thu Nov 24 16:20:23 2005 From: scott at 4th.com (Syscrusher) Date: Thu Nov 24 16:20:41 2005 Subject: [development] Trying to understand hook_nodeapi() invocation sequence from node.module Message-ID: <200511241120.23817.scott@4th.com> Good morning! I've run into some odd behavior from node.module in Drupal HEAD (updated as of 2005-11-23 at about 2300 UTC). I'm not reporting an "issue" on the module yet, because I strongly suspect the "problem" is ignorance on my part rather than a bug in the core code. I have a module that adds extra fields to node edit screens, similar to the way the upload.module does. The difference is that my module can have zero, one, or more instances of my custom fields, and I've got code that examines how many are defined and always ensures that all the existing ones are shown plus one blank one, on each preview or initial entry into the Edit page for an existing node. The particulars of my code aren't really relevant, and I'm not asking for help debugging that. Instead, what I'm seeking is to understand why hook_nodeapi() is being invoked in the particular sequence that I'm seeing. I have the following trace enabled in my hook_nodeapi() implementation: function mymodule_nodeapi(&$node, $op, $teaser=NULL, $page=NULL) { // DEBUG: Extra trace logic drupal_set_message("nodeapi $op $node->nid"); switch($op) { // .... the usual stuff here } } Now, on initial entry into the edit form on node with $nid == 8, here is the output of that drupal_set_message(): nodeapi load 8 nodeapi load 8 nodeapi prepare 8 nodeapi form 8 And on a "preview" of the node after editing, I see this: nodeapi load 8 nodeapi load 8 nodeapi prepare 8 nodeapi form 8 nodeapi validate 8 nodeapi view 8 nodeapi validate 8 My question is, why is $op=='load' being always invoked twice, and why is $op=='validate' being invoked twice for previews? The problem I'm having with my logic has to do with that second invocation of "load", and I'm finding that I have to build explicit conditional logic in the load function to detect whether I've already done it before. It seems to me that represents extra database hits, if nothing else, and in my particular case a design obstacle as well. I've checked the documentation for hook_nodeapi(), but it doesn't seem to be fully updated for 4.7 yet, and also doesn't really talk about the sequence of calls to the function, but rather treats each one individually. Can someone offer some general commentary on how this is supposed to work in 4.7? I suspect I'm not the only one who's confused. Or if I've overlooked it in the docs, please point me to a page, and I'll cheerfully apologize for wasting your time. I did try to RTFM before asking on list, but I may have missed something. Many thanks! Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher From fabiana at circodepulgas.org Thu Nov 24 16:39:59 2005 From: fabiana at circodepulgas.org (Fabiana) Date: Thu Nov 24 16:40:09 2005 Subject: [development] Support with XML-RPC and Flash remoting. Message-ID: <4385ECDF.3010702@circodepulgas.org> Hello, everybody! I'm using the last version of Drupal with taxonomy_menu.module to build the hierarchy menu and taxonomy_images.module to have one image per term. I want a Flash movie to get and show these images accordingly to the category the user is visiting. I know I have to use XML-RPC library for Flash, but I don't know if I need to build a custom module to output these images or I can handle this just making the appropriate actionscripting using the xmlrcpflash library. I don't know much of actionscripting, that's why I really need help. Can someone gimme support? I don't have much money, but we can negotiate a price, so I'll pay for the work if someone could help me finish this stuff today. Thanks in advance. Fabiana From larry at garfieldtech.com Thu Nov 24 17:26:43 2005 From: larry at garfieldtech.com (Larry Garfield) Date: Thu Nov 24 17:27:16 2005 Subject: SVN battle plan? was Re: [development] bzr battle plan In-Reply-To: References: Message-ID: <200511241126.44151.larry@garfieldtech.com> On Thursday 24 November 2005 07:42 am, Bertrand Mansion wrote: > In my opinion, Drupal is better using CVS than SVN. With SVN, you get a new > revision number on every commit. That's fine with compact projects like > Drupal core. But that's not so fine if commits done to themes, modules, etc > are done in the same repository. It will make it hard for everyone to > follow what's going on. The KDE project passed its 10,000th commit to its SVN repository a few months after migrating from CVS. So far it's been smooth sailing. The commit number has no real significance. If anything SVN makes this easier since commits are project atomic. (You don't commit each file individually; you commit all your inter-related changes as a single atomic action.) > This is especially true since I have noticed that a few developers still > don't understand how to make grouped commits and keep on commiting 100s > files one at a time... With SVN and this kind of behavior, you get a +100 > revision number on the main repository. > > So unless you create one repository per module, theme, projects, you are > safer using CVS. There are, I think, valid arguments to do that anyway, regardless of the SCM in use, but keeping the commit count number low is not one of them. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson From dan at drob.org Thu Nov 24 18:46:48 2005 From: dan at drob.org (Dan Robinson) Date: Thu Nov 24 18:47:33 2005 Subject: [development] One core, many distributions In-Reply-To: <200511241540.21366.ber@webschuur.com> References: <437F6F91.40600@wanadoo.es> <200511241002.39059.ber@webschuur.com> <200511241540.21366.ber@webschuur.com> Message-ID: <43860A98.6090105@drob.org> I undersatnd the attitude that "the only thing that matters are contributors", however I would argue that the more users you have, the more contributors you will have. It all gets back (IMHO) to how you define the project, what the goals and objectives are etc. Drupal is a very strong project and if nothing changed it would continue to be so I think. I believe that a lot of this conversation is because you have new people coming into the arena with their own ideas, aspirations and needs. Dan >Let me stress that this is my opinion. > >Op donderdag 24 november 2005 15:20, schreef Earl Dunovant: > > >>I think I want to be sure I understand this. >> >>On 11/24/05, B?r Kessels wrote: >> >> >>>If, netto, we have substantial more developers at the end of 4.7, we made >>>the >>>correct choice. I beleive we should count our success mostly in the >>>"currency" Developers. I do not care about amount of users, per se, to me >>>they are but a factor to get more developers. >>>We should take the word "developer" with a grain of salt, though. Anyone >>>contributing to the development of Drupal is a developer in this case. >>> >>> >>By "users" you mean 'people that use web sites built using Drupal'? And by >>"developers" you mean 'people that build web sites using Drupal, + plus >>project contributors"? >> >> > >No. I mean people that download drupal and use it for their website. > >A developer would be any of these users that actually contributes something >back. > >I (and again, let me stress that letter I), am not really waiting for people >filing feature requests on my contribs. Nor people filing bug reports for >OddFlavouredHostingProvider. Those are their itches. My itches are to get >stuff working here. Nor for those that ask support, because they cannot find >docs for one of these contribs. > >I am waiting, however for people whom either contribute a patch, or write a >nice howto or doc page on something. Or who actively help by handing me good >ways to improve my experience of these contribs. > >I know. This is selfish. But I do this for myself, in the first place. I am >not developing stuff for FooBar Inc. or Joe User. If they can reuse my work >that is great. If they then contribute bak that is even better. > >But once they start costing me, my time, and my efforts (and sometimes even >manage to flame me in that process.....) I can really do without them. They >use "our" bandwith, "our" CPU cycles, demanding our time and give nothing >back. > >Hence comes my statement that one should not calculate an OSS project based on >numbers of users, but on amount of actively involved people. > > > > >>I hope? Because when I think of Drupal users I think of "people that build >>web sites using Drupal' and developers, to me, are project contributors. >> >> > > > > From ber at webschuur.com Thu Nov 24 19:38:00 2005 From: ber at webschuur.com (=?utf-8?q?B=C3=A8r_Kessels?=) Date: Thu Nov 24 19:37:44 2005 Subject: [development] One core, many distributions In-Reply-To: <43860A98.6090105@drob.org> References: <437F6F91.40600@wanadoo.es> <200511241540.21366.ber@webschuur.com> <43860A98.6090105@drob.org> Message-ID: <200511242038.00599.ber@webschuur.com> Op donderdag 24 november 2005 19:46, schreef Dan Robinson: > I undersatnd the attitude that "the only thing that matters are > contributors", however I would argue that the more users you have, the > more contributors you will have. I already mentioned that users are a route towards new developers, Not only because the more users you have the bigger the chances are there is a contributer inbetween, but also because a lot of users spend money on hiring developers for drupal. However, to the project itself, IMO the only thing that really counts, in the end, is the amount of active contributors. All the rest can be ignored. > I believe that a lot of this conversation is because you have > new people coming into the arena with their own ideas, aspirations and > needs. Oh, buit this is a good thing, imo. It keeps drupal from rusting. From dan at civicactions.com Thu Nov 24 19:55:10 2005 From: dan at civicactions.com (Dan Robinson) Date: Thu Nov 24 19:55:40 2005 Subject: [development] One core, many distributions In-Reply-To: <200511242038.00599.ber@webschuur.com> References: <437F6F91.40600@wanadoo.es> <200511241540.21366.ber@webschuur.com> <43860A98.6090105@drob.org> <200511242038.00599.ber@webschuur.com> Message-ID: <43861A9E.5050205@civicactions.com> I'm totally not arguing with you btw :). > >>I undersatnd the attitude that "the only thing that matters are >>contributors", however I would argue that the more users you have, the >>more contributors you will have. >> >> > >I already mentioned that users are a route towards new developers, Not only >because the more users you have the bigger the chances are there is a >contributer inbetween, but also because a lot of users spend money on hiring >developers for drupal. > >However, to the project itself, IMO the only thing that really counts, in the >end, is the amount of active contributors. All the rest can be ignored. > > isn't what you just said contradictory? What am I missing - Users [help create] new developers [and create] marketplace [which brings] new developers so how can you then turn around and say "...the only thing that really counts, in the end, is that amount of active contributors.." I'm just wondering :). Also I just had a thought (everybody cover your ears...) Is the project about the developers/contributors or is it about the code. I wonder... > > >>I believe that a lot of this conversation is because you have >>new people coming into the arena with their own ideas, aspirations and >>needs. >> >> > >Oh, buit this is a good thing, imo. It keeps drupal from rusting. > > agreed :) From drupal-devel at webchick.net Thu Nov 24 20:57:12 2005 From: drupal-devel at webchick.net (Angie Byron) Date: Thu Nov 24 20:55:02 2005 Subject: [development] Support with XML-RPC and Flash remoting. In-Reply-To: <4385ECDF.3010702@circodepulgas.org> References: <4385ECDF.3010702@circodepulgas.org> Message-ID: <43862928.100@webchick.net> I did some work with Flash => XML-RPC => Drupal which is unfortunately under NDA so I can't actually post sample code. :( But I can give you some pointers which will hopefully help shave many hours off your journey: 1. There are basically two Flash XML-RPC libraries floating around out there. Use this one: http://members.netmadeira.com/killer/xmlrpc/. It's much simpler and also better in terms of performance. 2. The demo on the above site does not work, and neither will the sample demo files on new-ish versions of PHP because of function naming conflicts. Replace the xmlrpc.inc and xmlrpcs.inc files from the current version of the script at http://phpxmlrpc.sourceforge.net/ and it should work. This will allow you to see a working example which makes it a lot easier to see how this stuff fits together. 3. You will need to create a custom module that implements hook_xmlrpc. chx and I just worked the other day on improving the documentation here: http://drupaldocs.org/api/head/function/hook_xmlrpc to help explain better how this hook call should look. 4. The BlogAPI module shows an example of a hook_xmlrpc implementation, so you can get a feel for what the custom module should look like. 5. There's a user on Drupal.org called 'averageyoungman' who was very helpful in me finally arriving at my solution. I'm pretty sure he's available for consulting work (where I'm pretty swamped). His contact page can be reached from http://drupal.org/user/24428/contact. That's about all the info I can give you, but hopefully that will give you a head-start and eliminate some head-on-desk pounding. ;) -Angie Fabiana wrote: > Hello, everybody! > > I'm using the last version of Drupal with taxonomy_menu.module to build > the hierarchy menu and taxonomy_images.module to have one image per term. > I want a Flash movie to get and show these images accordingly to the > category the user is visiting. > I know I have to use XML-RPC library for Flash, but I don't know if I > need to build a custom module to output these images or I can handle > this just making the appropriate actionscripting using the xmlrcpflash > library. > I don't know much of actionscripting, that's why I really need help. > > Can someone gimme support? I don't have much money, but we can negotiate > a price, so I'll pay for the work if someone could help me finish this > stuff today. > > Thanks in advance. > Fabiana From es-lists at ericscouten.com Thu Nov 24 21:11:56 2005 From: es-lists at ericscouten.com (Eric Scouten) Date: Thu Nov 24 21:12:04 2005 Subject: [development] One core, many distributions In-Reply-To: <200511232311.57621.ber@webschuur.com> References: <437F6F91.40600@wanadoo.es> <006A0406-BB54-4D50-B3CD-AD159A06D86D@buytaert.net> <200511232311.57621.ber@webschuur.com> Message-ID: <573D8A0D-135F-483D-8321-9CC5EC66FB17@ericscouten.com> On 23 Nov 2005, at 14:11, B?r Kessels wrote: > Op woensdag 23 november 2005 17:15, schreef Dries Buytaert: >> Clearly, there is a tension between breaking backward compatibility >> and not breaking backward compatibility. Unfortunately, there is no >> "winner" because the costs can't be quantified. Not the absolute >> costs. Not the relative costs. I'm in the camp that, we are best of >> breaking backward compatibility when necessary; it buys us >> maintainability and flexibility, which, in turn, makes for a longer >> product lifecycle. > > Lets see this is as a test case. But let us measure the "costs" in > amounts of > developers leqving Drupal, or even sticking with 4.6 (and thus not > upgrading > their contribs, or thus not contributing back to bugs and so in > 4.7). And let > us hope that the amount of new developers that are attracted by the > easier > development will at least break us even. Ber, very nicely stated. I think that's an entirely reasonable criteria. Unfortunately, the 4.7 cycle has placed me in the drop-out camp. Somewhere around August or September, I realized that each CVS pull would cost me several hours of development time (downloading from CVS; merging into my local Perforce repository; figuring out what APIs had changed out from under me -- I have quite a bit of custom code; and dealing with many white-screens-of-death). Many of those multi-hour sessions were prompted by the false hope that what had been broken by the previous CVS pull would be fixed this time around. After my "day job" (I hate that term, but can't think of anything better) and family life, I have maybe 10 to 20 hours per week to spend on my web sites. Far too much of that time was going into this debugging effort, so I've now backtracked to 4.6.x plus a few specific upgrades that are useful to me (notably freetagging). No value judgement here, just a data point. I'd love to be able to contribute bug fixes and some of the custom work I'm doing, but the cost of keeping up has become too high. I'll probably wait until a month or two after 4.7 is released before considering an upgrade again. -Eric From drupal-devel at webchick.net Thu Nov 24 23:17:36 2005 From: drupal-devel at webchick.net (Angie Byron) Date: Thu Nov 24 23:15:20 2005 Subject: [development] bzr battle plan In-Reply-To: <4385D0E3.3030005@killesreiter.de> References: <200511240219.30621.larry@garfieldtech.com> <99469d070511240128q6e1894aq@mail.gmail.com> <4385D0E3.3030005@killesreiter.de> Message-ID: <43864A10.6030204@webchick.net> Gerhard Killesreiter wrote: > Gildas COTOMALE wrote: > >> Suggest: why not add a poll on http://drupal.org to ask people what's >> their favorite CSM..? We'll have so a good idea how ready future dev' >> are ready to switch to something else and what.. > > It qould be quite pointless as the popular opinion does not matter at > all as is often the case in software development. I agree with Gerhard here. I wouldn't want for us to pick a version control software based on popular opinion (nor, "hey it works fine for so-and-so" for that matter), but rather how well it addresses our specific needs as developers for Drupal. Probably the best place to start this conversation is to establish answers the following questions (and probably some others), and choose a product based on that: 1. What are our major gripes about CVS and where has CVS failed us? 2. On the flip-side, what are some cool things about CVS that we like and want to make sure the next package has? 3. What types of development ventures have we embarked on in the past that were difficult to do with CVS and patches? 4. What kinds of "Wouldn't it be cool if..?" scenarios could we think of that would help ease development? For my part: 1. I've been bitten by the fact that the only way to grab a snapshot of the code at a certain date and time is by timestamp. If there were 50 commits to Drupal one day, and I want to know "What did the source look like right before patch #23344 was committed?" it's extremely difficult to do that. This could be lack of knowledge of CVS on my part, but I remember asking in #drupal about this and basically being told, "you're screwed." (though killes suggested a workaround that seemed to work in my case). 2. Morbus is going to slap me, but I really like the convenience of TortoiseCVS. DUCK I also like the fact that I can browse the CVS repo on the web and do quickie diffs between versions to spot changes. 3. Forms API. This was a huge, sweeping change against almost every file in Drupal. We were trying to have 10 or more developers each changing little chunks here and there and rolling them into one huge monster patch. This was an absolute nightmare before we had a SVN repository of our own to commit to so we had something stable to commit against. 4. I don't really have enough knowledge in this area to comment on this. The only thing I could think of is CSL, Bryght, and Drupal.org all sharing the same RCS, but I don't know what specific advantages that would have only that it would be more "unified." -Angie From nedjo at islandnet.com Thu Nov 24 23:15:24 2005 From: nedjo at islandnet.com (Nedjo Rogers) Date: Thu Nov 24 23:15:41 2005 Subject: [development] menu gurus? question about local tasks and 'active' tab Message-ID: <002a01c5f14c$f2d48670$6400a8c0@family> I'm wrestling with a question related to local tasks and could use some help from a menu guru. As part of the proposed classification approach for projects, I've used tertiary/third-level local tasks as an aid for browsing, see the demo at: http://www.islandnet.com/~nedjo/costarica/?q=project/Modules The code is posted as a patch to the issue at: http://drupal.org/node/33803#comment-56410 The issue has to do with the 'active' secondary task tab. When the tertiary task is the default, the secondary task is correctly highlighted. But for any other third-level task (e.g., in the demo, click on the category 'utility'), the 'active' class selector disappears from the secondary tabs. Apparently, the secondary task is not recognized as being on the active path. Anyone tried to use third-level local tasks before? Any troubleshooting tips? Anyone able to spot what I'm doing wrong? I don't follow the menu.inc code well enough to easily determine where the issue is. Thanks, Nedjo From drupal.org at juggernaut.com.au Thu Nov 24 23:23:53 2005 From: drupal.org at juggernaut.com.au (Richard Archer) Date: Thu Nov 24 23:23:24 2005 Subject: [development] menu gurus? question about local tasks and 'active' tab In-Reply-To: <002a01c5f14c$f2d48670$6400a8c0@family> References: <002a01c5f14c$f2d48670$6400a8c0@family> Message-ID: At 3:15 PM -0800 24/11/05, Nedjo Rogers wrote: >The issue has to do with the 'active' secondary task tab. When the tertiary >task is the default, the secondary task is correctly highlighted. But for >any other third-level task (e.g., in the demo, click on the category >'utility'), the 'active' class selector disappears from the secondary tabs. >Apparently, the secondary task is not recognized as being on the active >path. I had huge problems with the active trail when menu-ifying primary links. Email me a var_export of $menu and I'll wade through it and try to work out what's going wrong. ...Richard. From gordon at heydon.com.au Thu Nov 24 23:52:17 2005 From: gordon at heydon.com.au (Gordon Heydon) Date: Thu Nov 24 23:52:23 2005 Subject: [development] bzr mirror of Drupal HEAD In-Reply-To: References: <1132810197.23257.133.camel@localhost.localdomain> Message-ID: <1132876337.23257.162.camel@localhost.localdomain> Hi, On Thu, 2005-11-24 at 07:04 +0100, Karoly Negyesi wrote: > > of bzr. I am running Ubuntu Breezy and I had to download from source. I > > couldn't get this from the ubuntu distribution. > > I am on Ubuntu Breezy as well (OK, Kubuntu Breezy) and I have this in > sources.conf: > > deb http://people.ubuntu.com/~jbailey/snapshot/bzr/ ./ > > Works great. Cool, I will add this to my source.list. But it does concern me, trusting such an important part of the drupal development process to such a new piece of software. Gordon. From gordon at heydon.com.au Fri Nov 25 00:18:20 2005 From: gordon at heydon.com.au (Gordon Heydon) Date: Fri Nov 25 00:18:27 2005 Subject: [development] SCM discussion. Message-ID: <1132877900.23257.187.camel@localhost.localdomain> Hi, With all the discussion on which SCM (Source Code Management) system we should be using. There has always been talk of using SVN, and recently I proposed darcs and in the last couple of days there has been bzr. These are all good SCM's but I am wondering if we are going to not have some of the important functionality that we currently have. I think I am most likely in the minority of users that use nesting to set up a site. I know that with darcs I am going to loss this ability and I also think with bzr we would as well. Basically this is how I set up a brand new site. First I check out the core of drupal $ cvs -z9 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal checkout -d drupal_new drupal Using the -d option I can specify the directory to put it into. Also if I am doing a 4.6 install I add -r DRUPAL_4_6 Once I have the base setup, edited the settings, create the database, create user 1, etc. Then I go to the modules directory and I start checking out the modules that I need, with the following command to get it out of cvs. $ cvs -d:pserver:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -d htmlarea contributions/modules/htmlarea This will check out the htmlarea module and put it into my modules directory. I repeat this for all the modules that I need. if this is a 4.6 install I will then go to the themes/engines and use the same command to checkout phptemplate, and then I will usually check out the bluemarine phptemplate theme into the themes directory like co. $ cvs -d:pserver:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -d bluemarine-phptemplate -r DRUPAL_4_6 contributions/themes/bluemarine Now once I have done all this, keeping the site up to date is extremely simple. all I do is go to the root of the drupal install and do a. $ cvs update -dP which will not only update the core but also update the contributed modules which are in a different repository. I can also do things like upgrade between versions with a cvs update -r DRUPAL_4_7 which will do the same. This is a function of cvs that makes my life so much easier to maintain sites, and keep them current. It also makes things easier when I am doing development of my contributed modules as I do not need to copy them back to another directory to be commited, I can commit them from my working directory. I know that darcs can't do this, and I am not sure about bzr. I feel this is an underused function that really more people should know about and should really not be lost. Any SCM that is chosen needs to be done wisely, and make sure that it does fit our method of working. Because of the 2 repositories we are not what would be called normal, so we need to allow for this. Gordon. Gordon. From drewish at katherinehouse.com Fri Nov 25 00:22:57 2005 From: drewish at katherinehouse.com (andrew morton) Date: Fri Nov 25 00:22:59 2005 Subject: [development] SCM discussion. In-Reply-To: <1132877900.23257.187.camel@localhost.localdomain> References: <1132877900.23257.187.camel@localhost.localdomain> Message-ID: On 11/24/05, Gordon Heydon wrote: > I think I am most likely in the minority of users that use nesting to > set up a site. I know that with darcs I am going to loss this ability > and I also think with bzr we would as well. I do exactly the same thing for my sites. I hadn't even thought of it being affected by a change of SCM. This is one feature I'd really like to keep. andrew From kb at 2bits.com Fri Nov 25 00:46:34 2005 From: kb at 2bits.com (Khalid B) Date: Fri Nov 25 00:46:36 2005 Subject: [development] bzr battle plan In-Reply-To: <43864A10.6030204@webchick.net> References: <200511240219.30621.larry@garfieldtech.com> <99469d070511240128q6e1894aq@mail.gmail.com> <4385D0E3.3030005@killesreiter.de> <43864A10.6030204@webchick.net> Message-ID: <4a9fdc630511241646s7de55cd7w709228183437b42c@mail.gmail.com> Angie I fully agree with you. chx is to be commended for taking the initiative of introducing us to bzr, but that should not sway is on its own. We should really evaluate what is out there, and make an informed decision. We should see what other open source projects are doing too, and learn from their experience. Dries: you should take action on this. You have said you want to stay on CVS. Fair enough. But what about: - Are there any pains with CVS? - Are there better features elsewhere? - Do we benefit from a new tool? Discuss more, form a team, argue, pros/cons, ...etc. This is what we need. This is how the discussion should start, not as a forgone conclusion or preempting the issue. > I agree with Gerhard here. I wouldn't want for us to pick a version control > software based on popular opinion (nor, "hey it works fine for so-and-so" for > that matter), but rather how well it addresses our specific needs as > developers for Drupal. > > Probably the best place to start this conversation is to establish answers the > following questions (and probably some others), and choose a product based on that: > > 1. What are our major gripes about CVS and where has CVS failed us? > > 2. On the flip-side, what are some cool things about CVS that we like and want > to make sure the next package has? > > 3. What types of development ventures have we embarked on in the past that were > difficult to do with CVS and patches? > > 4. What kinds of "Wouldn't it be cool if..?" scenarios could we think of that > would help ease development? From karoly at negyesi.net Fri Nov 25 01:12:25 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Fri Nov 25 01:07:47 2005 Subject: [development] SCM discussion. In-Reply-To: <1132877900.23257.187.camel@localhost.localdomain> References: <1132877900.23257.187.camel@localhost.localdomain> Message-ID: > I know that darcs can't do this, and I am not sure about bzr. I know that bzr can do this. http://drupal.revisioncontrol.net itself is a bzr repo AND a running drupal, check it. Your local branch can be that, too. And yes, you will be able to do this with the contrib mirror too. Regards NK From karoly at negyesi.net Fri Nov 25 01:13:56 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Fri Nov 25 01:09:18 2005 Subject: [development] bzr mirror of Drupal HEAD In-Reply-To: <1132876337.23257.162.camel@localhost.localdomain> References: <1132810197.23257.133.camel@localhost.localdomain> <1132876337.23257.162.camel@localhost.localdomain> Message-ID: > But it does concern me, trusting such an important part of the drupal > development process to such a new piece of software. Huh? You are not trusting anything, you submit a patch if it does not apply then that's it. Also, --diff-options causes bzr to fall back to GNU diff... From gerhard at killesreiter.de Fri Nov 25 01:10:39 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Fri Nov 25 01:10:44 2005 Subject: [development] SCM discussion. In-Reply-To: References: <1132877900.23257.187.camel@localhost.localdomain> Message-ID: <4386648F.50203@killesreiter.de> andrew morton wrote: >On 11/24/05, Gordon Heydon wrote: > > >>I think I am most likely in the minority of users that use nesting to >>set up a site. I know that with darcs I am going to loss this ability >>and I also think with bzr we would as well. >> >> > >I do exactly the same thing for my sites. I hadn't even thought of it >being affected by a change of SCM. This is one feature I'd really like >to keep. > > I use the same with the exception that I usually link to the contributed modules' directories rather making a checkout. This also avoids having a checkout per site. I of course cannot use the single update command this way, but this is not too bad. Cheers, Gerhard From drewish at katherinehouse.com Fri Nov 25 01:22:16 2005 From: drewish at katherinehouse.com (andrew morton) Date: Fri Nov 25 01:22:18 2005 Subject: [development] SCM discussion. In-Reply-To: References: <1132877900.23257.187.camel@localhost.localdomain> Message-ID: On 11/24/05, Karoly Negyesi wrote: > > I know that darcs can't do this, and I am not sure about bzr. > > I know that bzr can do this. http://drupal.revisioncontrol.net itself is a > bzr repo AND a running drupal, check it. Your local branch can be that, > too. And yes, you will be able to do this with the contrib mirror too. Just to be clear, will it freak out if sub-directories (i.e. the modules) are from different repositories? andrew From karoly at negyesi.net Fri Nov 25 01:51:36 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Fri Nov 25 01:46:57 2005 Subject: [development] Support with XML-RPC and Flash remoting. In-Reply-To: <43862928.100@webchick.net> References: <4385ECDF.3010702@circodepulgas.org> <43862928.100@webchick.net> Message-ID: > 3. You will need to create a custom module that implements hook_xmlrpc. In this I can help you. Flash is not my expertise, hook_xmlrpc is. From karoly at negyesi.net Fri Nov 25 02:02:10 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Fri Nov 25 01:57:30 2005 Subject: [development] SCM discussion. In-Reply-To: References: <1132877900.23257.187.camel@localhost.localdomain> Message-ID: On Fri, 25 Nov 2005 02:22:16 +0100, andrew morton wrote: > On 11/24/05, Karoly Negyesi wrote: >> > I know that darcs can't do this, and I am not sure about bzr. >> >> I know that bzr can do this. http://drupal.revisioncontrol.net itself >> is a >> bzr repo AND a running drupal, check it. Your local branch can be that, >> too. And yes, you will be able to do this with the contrib mirror too. > > Just to be clear, will it freak out if sub-directories (i.e. the > modules) are from different repositories? No. Here is what happening: you do a bzr get http://drupal.revisioncontrol.net/core/head , then bzr will download some control files from http://drupal.revisioncontrol.net/core/head/.bzr and based on that it'll determine what Drupal files it needs to download. Now, if you do bzr get http://drupal.revisioncontrol.net/core/head/modules/cck (no, it's not there yet!) then it'll go to bzr get http://drupal.revisioncontrol.net/core/head/modules/cck/.bzr Only thing you need is to take care that cck is not versioned for the core mirror. But as you need to explicitely bzr add foo to make foo versioned, this is not a problem. In short: a bzr branch is simply a directory with some versioned files. If you put another such directory under it, that's fine. Regards NK From tobias.maier at gmail.com Fri Nov 25 01:59:32 2005 From: tobias.maier at gmail.com (Tobias Maier) Date: Fri Nov 25 01:59:48 2005 Subject: [development] Re: SCM discussion. In-Reply-To: <1132877900.23257.187.camel@localhost.localdomain> References: <1132877900.23257.187.camel@localhost.localdomain> Message-ID: <200511250259.32730.tobias.maier@gmail.com> I use it also. I have also a tip some people maybe not using this: do you know the tool sitecopy? its very usefull it updates your local copy of your site with the online-version so after you got with "cvs update" the new version do this: sitecopy --update --quiet mydrupalsite thats it you have updated your site at once :D ofcourse you have to set up sitecopy first but this is simple here is my ~/.sitecopyrc # Drupal Testsite # ----------------------- # The name of the project site mydrupalsite # FTP-Server server example.com # Loginname username fooo # Password password bar # dir on my pc local /home/tobi/drupal/drupal-4-6 # dir on the server remote /html/drupal # Exclude exclude /files exclude ~ From gordon at heydon.com.au Fri Nov 25 02:00:48 2005 From: gordon at heydon.com.au (Gordon Heydon) Date: Fri Nov 25 02:01:01 2005 Subject: [development] SCM discussion. In-Reply-To: References: <1132877900.23257.187.camel@localhost.localdomain> Message-ID: <1132884049.23257.199.camel@localhost.localdomain> Hi, On Thu, 2005-11-24 at 17:22 -0800, andrew morton wrote: > On 11/24/05, Karoly Negyesi wrote: > > > I know that darcs can't do this, and I am not sure about bzr. > > > > I know that bzr can do this. http://drupal.revisioncontrol.net itself is a > > bzr repo AND a running drupal, check it. Your local branch can be that, > > too. And yes, you will be able to do this with the contrib mirror too. > > Just to be clear, will it freak out if sub-directories (i.e. the > modules) are from different repositories? So it can't do what I and other people are doing. Gordon. From karoly at negyesi.net Fri Nov 25 02:06:30 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Fri Nov 25 02:01:50 2005 Subject: [development] SCM discussion. In-Reply-To: References: <1132877900.23257.187.camel@localhost.localdomain> Message-ID: > download. Now, if you do bzr get > http://drupal.revisioncontrol.net/core/head/modules/cck (no, it's not > there yet!) then it'll go to bzr get > http://drupal.revisioncontrol.net/core/head/modules/cck/.bzr then bzr will get files from http://drupal.revisioncontrol.net/core/head/modules/cck/.bzr sorry for the typo. From gordon at heydon.com.au Fri Nov 25 02:02:43 2005 From: gordon at heydon.com.au (Gordon Heydon) Date: Fri Nov 25 02:02:51 2005 Subject: [development] SCM discussion. In-Reply-To: <4386648F.50203@killesreiter.de> References: <1132877900.23257.187.camel@localhost.localdomain> <4386648F.50203@killesreiter.de> Message-ID: <1132884163.23257.202.camel@localhost.localdomain> Hi, On Fri, 2005-11-25 at 02:10 +0100, Gerhard Killesreiter wrote: > andrew morton wrote: > > >On 11/24/05, Gordon Heydon wrote: > > > > > >>I think I am most likely in the minority of users that use nesting to > >>set up a site. I know that with darcs I am going to loss this ability > >>and I also think with bzr we would as well. > >> > >> > > > >I do exactly the same thing for my sites. I hadn't even thought of it > >being affected by a change of SCM. This is one feature I'd really like > >to keep. > > > > > > I use the same with the exception that I usually link to the contributed > modules' directories rather making a checkout. This also avoids having a > checkout per site. I of course cannot use the single update command this > way, but this is not too bad. I did think of this, but I decided not to do it as I want to make sure that I only update the current site and not all sites. But this is 6 of 1, half a dozen of another. Actually I do have a full contributions repository checked out but I think it is really out of date. Gordon. From gordon at heydon.com.au Fri Nov 25 02:04:18 2005 From: gordon at heydon.com.au (Gordon Heydon) Date: Fri Nov 25 02:04:25 2005 Subject: [development] bzr mirror of Drupal HEAD In-Reply-To: References: <1132810197.23257.133.camel@localhost.localdomain> <1132876337.23257.162.camel@localhost.localdomain> Message-ID: <1132884258.23257.204.camel@localhost.localdomain> Hi, On Fri, 2005-11-25 at 02:13 +0100, Karoly Negyesi wrote: > > But it does concern me, trusting such an important part of the drupal > > development process to such a new piece of software. > > Huh? You are not trusting anything, you submit a patch if it does not > apply then that's it. Also, --diff-options causes bzr to fall back to GNU > diff... This is a single part of the process, the SCM is still a big part of the development process. Gordon. From karoly at negyesi.net Fri Nov 25 02:24:20 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Fri Nov 25 02:19:40 2005 Subject: [development] SCM discussion. In-Reply-To: <1132884049.23257.199.camel@localhost.localdomain> References: <1132877900.23257.187.camel@localhost.localdomain> <1132884049.23257.199.camel@localhost.localdomain> Message-ID: > So it can't do what I and other people are doing. Reread what you asked first. The answer is: there are plans to do some kidn of a recursive pull plugin, at this moment you need a third party tool, called config-manager to do it. Regards NK From scott at 4th.com Fri Nov 25 02:37:40 2005 From: scott at 4th.com (Syscrusher) Date: Fri Nov 25 02:37:57 2005 Subject: [development] Trying to understand hook_nodeapi() invocation sequence from node.module -- updated In-Reply-To: <200511241120.23817.scott@4th.com> References: <200511241120.23817.scott@4th.com> Message-ID: <200511242137.40529.scott@4th.com> On Thursday 24 November 2005 11:20, Syscrusher wrote: > Now, on initial entry into the edit form on node with $nid == 8, here is the > output of that drupal_set_message(): > > nodeapi load 8 > nodeapi load 8 > nodeapi prepare 8 > nodeapi form 8 > > And on a "preview" of the node after editing, I see this: > > nodeapi load 8 > nodeapi load 8 > nodeapi prepare 8 > nodeapi form 8 > nodeapi validate 8 > nodeapi view 8 > nodeapi validate 8 > > My question is, why is $op=='load' being always invoked twice, and why is > $op=='validate' being invoked twice for previews? After examining the code in node.module, I've found what I think is the cause of this behavior, but I'm still not sure why it's done this way. At line 370, in function node_load(), we see the following: if ($node->nid) { // Call the node specific callback (if any) and piggy-back the // results to the node or overwrite some values. if ($extra = node_invoke($node, 'load')) { foreach ($extra as $key => $value) { $node->$key = $value; } } if ($extra = node_invoke_nodeapi($node, 'load')) { foreach ($extra as $key => $value) { $node->$key = $value; } } My module doesn't define a new node type, but just adds fields to existing types, so it doesn't define its own hook_load() function. Thus, the call to node_invoke($node, 'load') ends up calling node_load recursively, I think. Thus, the second recursion may be calling my module's hook_nodeapi() function again for each load. I'd still be curious to understand better what's going on here. Thanks for any comments. Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher From scott at 4th.com Fri Nov 25 03:25:19 2005 From: scott at 4th.com (Syscrusher) Date: Fri Nov 25 03:25:35 2005 Subject: [development] Forms API: Duplication of "#prefix" string in elements of type "weight" Message-ID: <200511242225.19584.scott@4th.com> Good evening, all. I'm not sure how to go about reporting this issue, but I've found that the new forms API is duplicating the value of #prefix on form elements of type "weight". It doesn't seem to happen with other types. If I change the type of the form element from "weight" to "textfield", making no other changes in the $form array, the prefix string is no longer emitted twice. So it's type-specific. I'm looking to see if I can find the cause and contribute a patch, but wanted to make the team aware of the problem. Just out of curiosity, how does one submit an issue on a core file like forms.inc? I've never done that before, but have only filed reports on contrib modules using the links from each module's project page. Sorry for my ignorance of this. Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher From gordon at heydon.com.au Fri Nov 25 03:30:59 2005 From: gordon at heydon.com.au (Gordon Heydon) Date: Fri Nov 25 03:31:05 2005 Subject: [development] Re: SCM discussion. In-Reply-To: <200511250259.32730.tobias.maier@gmail.com> References: <1132877900.23257.187.camel@localhost.localdomain> <200511250259.32730.tobias.maier@gmail.com> Message-ID: <1132889459.23257.212.camel@localhost.localdomain> Hi, This is a great tool if you only have ftp access. I use it all the time. Now I have ssh access to my web site and I user rsync which is alot better. Gordon. On Fri, 2005-11-25 at 02:59 +0100, Tobias Maier wrote: > I use it also. > > I have also a tip some people maybe not using this: > do you know the tool sitecopy? > its very usefull > it updates your local copy of your site with the online-version > so after you got with "cvs update" the new version > do this: > sitecopy --update --quiet mydrupalsite > > thats it you have updated your site at once :D > > ofcourse you have to set up sitecopy first but this is simple here is my > ~/.sitecopyrc > > # Drupal Testsite > # ----------------------- > # The name of the project > site mydrupalsite > > # FTP-Server > server example.com > > # Loginname > username fooo > > # Password > password bar > > # dir on my pc > local /home/tobi/drupal/drupal-4-6 > > # dir on the server > remote /html/drupal > > # Exclude > exclude /files > exclude ~ > > !DSPAM:43867532239893248454204! > From scott at 4th.com Fri Nov 25 03:48:13 2005 From: scott at 4th.com (Syscrusher) Date: Fri Nov 25 03:48:30 2005 Subject: [development] Forms API: Duplication of "#prefix" string in elements of type "weight" In-Reply-To: <200511242225.19584.scott@4th.com> References: <200511242225.19584.scott@4th.com> Message-ID: <200511242248.13581.scott@4th.com> On Thursday 24 November 2005 22:25, Syscrusher wrote: > Good evening, all. > > I'm not sure how to go about reporting this issue, but I've found that the new > forms API is duplicating the value of #prefix on form elements of type "weight". [...] > > I'm looking to see if I can find the cause and contribute a patch, but wanted > to make the team aware of the problem. Bingo! The problem was that form_render() was being called from theme_weight as well as from drupal_get_form(). Each call appended the prefix and appended the suffix, so you were actually getting this: $PREFIX $PREFIX $FORM_STUFF $SUFFIX $SUFFIX I happened not to notice the extra suffix at first in the HTML output, but it was there. All that was needed was a pair of unset() calls added to theme_weight(). Under the "code is gold" premise, I've filed this as an issue (#38790) and have contributed a patch to includes/form.inc. I hope the forms API team find this helpful. Great piece of code, other than this little glitch. Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher From walkah at walkah.net Fri Nov 25 04:24:24 2005 From: walkah at walkah.net (James Walker) Date: Fri Nov 25 04:23:56 2005 Subject: [development] Support with XML-RPC and Flash remoting. In-Reply-To: References: <4385ECDF.3010702@circodepulgas.org> <43862928.100@webchick.net> Message-ID: <438691F8.6060208@walkah.net> On 11/24/05 8:51 PM, Karoly Negyesi wrote: >> 3. You will need to create a custom module that implements hook_xmlrpc. > > In this I can help you. Flash is not my expertise, hook_xmlrpc is. i too have had a run in or two with hook_xmlrpc .. and while i don't speak flash meself, i've had to speak to a fair bit of flash. -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net From ber at webschuur.com Fri Nov 25 08:53:29 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Fri Nov 25 08:53:14 2005 Subject: [development] bzr battle plan In-Reply-To: <43864A10.6030204@webchick.net> References: <4385D0E3.3030005@killesreiter.de> <43864A10.6030204@webchick.net> Message-ID: <200511250953.29403.ber@webschuur.com> Op vrijdag 25 november 2005 00:17, schreef Angie Byron: > 1. What are our major gripes about CVS and where has CVS failed us? CVS forces everyone to keep patches in a queue up to date (revisions patch). CVS does nothing to help ease this pain. CVS has a very hard to grok concept. It requires users to get a complete new idea of file management. > 2. On the flip-side, what are some cool things about CVS that we like and > want to make sure the next package has? The amount of tools available for it. Not only GUIS, also scripts and all that. > 3. What types of development ventures have we embarked on in the past that > were difficult to do with CVS and patches? Grouped efforts on a certain issue. Forms API indeed. Usability improvments. Most often a patch does not "explain" anything in usability improvements, because patches are really "hardcore developers communication". Distribution management. This has not even been tried. > 4. What kinds of "Wouldn't it be cool if..?" scenarios could we think of > that would help ease development? Manage distributions and "flavours" of Drupal. Make a patch, then let it do its own pimping (instead of me going around IRC, jabber, mail, bumping issues etc). Make it possible to let a patch linger in a queue for a while, yet it can still be applied. Allow me to branch off (core) modules to work on that for * my own projects (yet someone might be interested in that work too) * improvement of a core project. Patches alone are unfit for large changes * Distributions. They might want slightly modified version of stuff. Or additional files Ber From ber at webschuur.com Fri Nov 25 08:56:49 2005 From: ber at webschuur.com (=?utf-8?q?B=C3=A8r_Kessels?=) Date: Fri Nov 25 08:56:32 2005 Subject: [development] One core, many distributions In-Reply-To: <43861A9E.5050205@civicactions.com> References: <437F6F91.40600@wanadoo.es> <200511242038.00599.ber@webschuur.com> <43861A9E.5050205@civicactions.com> Message-ID: <200511250956.49501.ber@webschuur.com> This is a very interesting issue, IMHO. Sorry for all those bored with this thread. Op donderdag 24 november 2005 20:55, schreef u: > I'm totally not arguing with you btw :). No, I got that; I think we agree, but i think this is an interesting discussion. > >>I undersatnd the attitude that "the only thing that matters are > >>contributors", however I would argue that the more users you have, the > >>more contributors you will have. > >I already mentioned that users are a route towards new developers, Not > > only because the more users you have the bigger the chances are there is > > a contributer inbetween, but also because a lot of users spend money on > > hiring developers for drupal. > > > >However, to the project itself, IMO the only thing that really counts, in > > the end, is the amount of active contributors. All the rest can be > > ignored. > > isn't what you just said contradictory? What am I missing - > > Users [help create] new developers [and create] marketplace [which > brings] new developers > > so how can you then turn around and say "...the only thing that really > counts, in the end, is that amount of active contributors.." > > I'm just wondering :). No this does not contradict: If one runs a company, one can easily say: in the end its all about the balance, the money. Having clients is cool: But clients that only cost money, or even clients that do not bring any money, are nice, yet do not help. in the end, A company can then say "The profit is all that matters, in the very end. Whether that is genrated by no clients at all, only one client or thousands of clients does not matter". In the same line we can say: The only thing that we can calculate our value off, is the amount of contributors, not the amount of users". Hell, we can have a million of users, yet only two developers. In that case we have a serious problem :) > Also I just had a thought (everybody cover your ears...) Is the project > about the developers/contributors or is it about the code. I wonder... > > >>I believe that a lot of this conversation is because you have > >>new people coming into the arena with their own ideas, aspirations and > >>needs. > > > >Oh, buit this is a good thing, imo. It keeps drupal from rusting. > > agreed :) From ber at webschuur.com Fri Nov 25 09:10:30 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Fri Nov 25 09:10:17 2005 Subject: [development] SCM discussion. In-Reply-To: <4386648F.50203@killesreiter.de> References: <1132877900.23257.187.camel@localhost.localdomain> <4386648F.50203@killesreiter.de> Message-ID: <200511251010.30643.ber@webschuur.com> Op vrijdag 25 november 2005 02:10, schreef Gerhard Killesreiter: > andrew morton wrote: > >On 11/24/05, Gordon Heydon wrote: > >>I think I am most likely in the minority of users that use nesting to > >>set up a site. I know that with darcs I am going to loss this ability > >>and I also think with bzr we would as well. > > > >I do exactly the same thing for my sites. I hadn't even thought of it > >being affected by a change of SCM. This is one feature I'd really like > >to keep. > > I use the same with the exception that I usually link to the contributed > modules' directories rather making a checkout. This also avoids having a > checkout per site. I of course cannot use the single update command this > way, but this is not too bad. I use linking, when I run a stable drupal (463) then I can be sure that the 46 contribs fit with those. I copy modules when I want to hack them up or when I need to develop on them. In the last case, I also commit anything to my private SVN and then work from there. Esp if it is not only me wrking on the code this is really nessecary. Then all sorts of hackish scripts do nightly updates of CVS into my HEAD in svn, and with some fillding we can merge changes into our working repository. now this part is where it all gracefully fails. Both SVN and CVS are simply not fit for working across multiple repositories with multiple versions. Ber From larry at garfieldtech.com Fri Nov 25 09:16:46 2005 From: larry at garfieldtech.com (Larry Garfield) Date: Fri Nov 25 09:17:14 2005 Subject: [development] Defining success [WAS: One core, many distributions] In-Reply-To: <200511250956.49501.ber@webschuur.com> References: <437F6F91.40600@wanadoo.es> <43861A9E.5050205@civicactions.com> <200511250956.49501.ber@webschuur.com> Message-ID: <200511250316.46829.larry@garfieldtech.com> I'd throw in a different metric, just for kicks. An open source project, since it doesn't have a money or income issue (at least not directly), is not financially driven. It is driven by need, vis, solving a problem. It is a tool. No more, no less. Therefore, the success of a tool is the number of problems (either unique problems or number of problem cases) that the tool solves. A hammer solves pretty much just one problem, but it's an extremely common problem and it solves it really well, so it's a successful tool. Drupal can be used to solve a large number of different problems, and it's being used in several thousand unique problems. It's not actually the number of people using the tool that determines its success, it's the number of problems solved with it; by whom doesn't matter. One person solving 1 million problems or a million people solving one problem each are both 1 million problems solved, and so its success is 1 million. On Friday 25 November 2005 02:56 am, B?r Kessels wrote: > This is a very interesting issue, IMHO. Sorry for all those bored with this > thread. > > Op donderdag 24 november 2005 20:55, schreef u: > > I'm totally not arguing with you btw :). > > No, I got that; I think we agree, but i think this is an interesting > discussion. > > > >>I undersatnd the attitude that "the only thing that matters are > > >>contributors", however I would argue that the more users you have, the > > >>more contributors you will have. > > > > > >I already mentioned that users are a route towards new developers, Not > > > only because the more users you have the bigger the chances are there > > > is a contributer inbetween, but also because a lot of users spend money > > > on hiring developers for drupal. > > > > > >However, to the project itself, IMO the only thing that really counts, > > > in the end, is the amount of active contributors. All the rest can be > > > ignored. > > > > isn't what you just said contradictory? What am I missing - > > > > Users [help create] new developers [and create] marketplace [which > > brings] new developers > > > > so how can you then turn around and say "...the only thing that really > > counts, in the end, is that amount of active contributors.." > > > > I'm just wondering :). > > No this does not contradict: > If one runs a company, one can easily say: in the end its all about the > balance, the money. > Having clients is cool: But clients that only cost money, or even clients > that do not bring any money, are nice, yet do not help. in the end, > A company can then say "The profit is all that matters, in the very end. > Whether that is genrated by no clients at all, only one client or thousands > of clients does not matter". > > In the same line we can say: The only thing that we can calculate our value > off, is the amount of contributors, not the amount of users". > > Hell, we can have a million of users, yet only two developers. In that case > we have a serious problem :) > > > Also I just had a thought (everybody cover your ears...) Is the project > > about the developers/contributors or is it about the code. I wonder... > > > > >>I believe that a lot of this conversation is because you have > > >>new people coming into the arena with their own ideas, aspirations and > > >>needs. > > > > > >Oh, buit this is a good thing, imo. It keeps drupal from rusting. > > > > agreed :) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson From dan at drob.org Fri Nov 25 09:48:52 2005 From: dan at drob.org (Dan Robinson) Date: Fri Nov 25 09:49:38 2005 Subject: [development] One core, many distributions In-Reply-To: <200511250956.49501.ber@webschuur.com> References: <437F6F91.40600@wanadoo.es> <200511242038.00599.ber@webschuur.com> <43861A9E.5050205@civicactions.com> <200511250956.49501.ber@webschuur.com> Message-ID: <4386DE04.3020104@drob.org> >This is a very interesting issue, IMHO. Sorry for all those bored with this >thread. > > oh c'mon - we must be close to setting a record :) >Op donderdag 24 november 2005 20:55, schreef u: > > >>I'm totally not arguing with you btw :). >> >> > >No, I got that; I think we agree, but i think this is an interesting >discussion. > > yes. I think so as well :) > > >>>>I undersatnd the attitude that "the only thing that matters are >>>>contributors", however I would argue that the more users you have, the >>>>more contributors you will have. >>>> >>>> >>>I already mentioned that users are a route towards new developers, Not >>>only because the more users you have the bigger the chances are there is >>>a contributer inbetween, but also because a lot of users spend money on >>>hiring developers for drupal. >>> >>>However, to the project itself, IMO the only thing that really counts, in >>>the end, is the amount of active contributors. All the rest can be >>>ignored. >>> >>> >>isn't what you just said contradictory? What am I missing - >> >>Users [help create] new developers [and create] marketplace [which >>brings] new developers >> >>so how can you then turn around and say "...the only thing that really >>counts, in the end, is that amount of active contributors.." >> >>I'm just wondering :). >> >> > >No this does not contradict: >If one runs a company, one can easily say: in the end its all about the >balance, the money. > > yeah - you can say it is all about the money - but if it is for you then that is sad. There's a process - and you better enjoy that process, otherwise you won't be very happy. >Having clients is cool: But clients that only cost money, or even clients that >do not bring any money, are nice, yet do not help. in the end, >A company can then say "The profit is all that matters, in the very end. >Whether that is genrated by no clients at all, only one client or thousands >of clients does not matter". > >In the same line we can say: The only thing that we can calculate our value >off, is the amount of contributors, not the amount of users". > > I think this is way too simplistic and reductionist. I agree that just having lots of users isn't it either (if I thought so I would go off and use mambo or whatever it is called now :) ). But to say that users don't matter is silly (for me). >Hell, we can have a million of users, yet only two developers. In that case we >have a serious problem :) > > it seems unlikely that that could ever happen. Also there are hundreds of drupal developers (perhaps 1000s) who don't contribute code back - we should try to fix that. One thing that I'm starting to conclude from this conversation is that the motivations and interests between different participants is really different. I wonder if there are not clusters. Very interesting discussion - I need to think about this for a while. > > >>Also I just had a thought (everybody cover your ears...) Is the project >>about the developers/contributors or is it about the code. I wonder... >> >> >> >>>>I believe that a lot of this conversation is because you have >>>>new people coming into the arena with their own ideas, aspirations and >>>>needs. >>>> >>>> >>>Oh, buit this is a good thing, imo. It keeps drupal from rusting. >>> >>> >>agreed :) >> >> > > > From rafacouto at gmail.com Fri Nov 25 10:00:18 2005 From: rafacouto at gmail.com (Rafa Couto) Date: Fri Nov 25 10:00:22 2005 Subject: [development] bzr battle plan In-Reply-To: <43864A10.6030204@webchick.net> References: <200511240219.30621.larry@garfieldtech.com> <99469d070511240128q6e1894aq@mail.gmail.com> <4385D0E3.3030005@killesreiter.de> <43864A10.6030204@webchick.net> Message-ID: <22df564b0511250200k6be175d0o@mail.gmail.com> 2005/11/25, Angie Byron : > 1. What are our major gripes about CVS and where has CVS failed us? CVS authentication via pserver sends password as plain text. SVN uses WebDAV (over HTTPS) and it can plug in with apache DB authentication (PostgreSQL or MySQL) with mod_auth_. I am thinking in a SQL JOIN of drupal site users by drupal developers write access to repository. I have used CVS in my projects by enough time but since I use SVN it is a little better. By the way, I am lost no change using the tool cvs2svn. -- Rafa Couto (caligari) mailto:rafacouto @gmail.com Linux user #99126 (http://counter.li.org) From dries.buytaert at gmail.com Fri Nov 25 10:52:36 2005 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Fri Nov 25 10:52:42 2005 Subject: [development] SCM discussion. In-Reply-To: References: <1132877900.23257.187.camel@localhost.localdomain> Message-ID: <2B332C06-2ADE-4F66-9821-87D548F69229@buytaert.net> On 25 Nov 2005, at 01:22, andrew morton wrote: >> I think I am most likely in the minority of users that use nesting to >> set up a site. I know that with darcs I am going to loss this ability >> and I also think with bzr we would as well. > > I do exactly the same thing for my sites. I hadn't even thought of it > being affected by a change of SCM. This is one feature I'd really like > to keep. I do exactly the same, and I'd really like to keep it that way. Something else that I /hate/ about some SCM systems (like SVN) is that they make grep'ng a pain. You always end up grepping their "internal kitchen". -- Dries Buytaert :: http://www.buytaert.net/ From karoly at negyesi.net Fri Nov 25 11:22:03 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Fri Nov 25 11:17:21 2005 Subject: [development] Re: [task] Allow non-workflow form elements on the node type settings page In-Reply-To: References: Message-ID: On Fri, 25 Nov 2005 11:12:35 +0100, Dries wrote: > Tue, 22 Nov 2005 00:40:04 +0000 : adrian > > +1 > > > we use array_merge_recursive on the node form. I agree in that we should but I found no trace of this. From gordon at heydon.com.au Fri Nov 25 11:49:43 2005 From: gordon at heydon.com.au (Gordon Heydon) Date: Fri Nov 25 11:49:38 2005 Subject: [development] SCM discussion. In-Reply-To: <2B332C06-2ADE-4F66-9821-87D548F69229@buytaert.net> References: <1132877900.23257.187.camel@localhost.localdomain> <2B332C06-2ADE-4F66-9821-87D548F69229@buytaert.net> Message-ID: <1132919383.7489.66.camel@localhost.localdomain> Hi, On Fri, 2005-11-25 at 11:52 +0100, Dries Buytaert wrote: > On 25 Nov 2005, at 01:22, andrew morton wrote: > >> I think I am most likely in the minority of users that use nesting to > >> set up a site. I know that with darcs I am going to loss this ability > >> and I also think with bzr we would as well. > > > > I do exactly the same thing for my sites. I hadn't even thought of it > > being affected by a change of SCM. This is one feature I'd really like > > to keep. > > I do exactly the same, and I'd really like to keep it that way. > > Something else that I /hate/ about some SCM systems (like SVN) is > that they make grep'ng a pain. You always end up grepping their > "internal kitchen". Yes I hate this, I find that with darcs I have to do some fancy find to exclude _darcs from the grep. Gordon. From dries.buytaert at gmail.com Fri Nov 25 12:01:14 2005 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Fri Nov 25 12:01:20 2005 Subject: [development] Defining success [WAS: One core, many distributions] In-Reply-To: <200511250316.46829.larry@garfieldtech.com> References: <437F6F91.40600@wanadoo.es> <43861A9E.5050205@civicactions.com> <200511250956.49501.ber@webschuur.com> <200511250316.46829.larry@garfieldtech.com> Message-ID: <32A22407-7149-4BCE-9DAE-60B8F320B43C@buytaert.net> On 25 Nov 2005, at 10:16, Larry Garfield wrote: > I'd throw in a different metric, just for kicks. An open source > project, > since it doesn't have a money or income issue (at least not > directly), is not > financially driven. It is driven by need, vis, solving a problem. > It is a > tool. No more, no less. For a metric to be useful, we must be able to quantify it. We can quantify the number of users, the number of downloads, the number of developers, the number of projects, the number of forum topics, the number of CVS commits, etc. We can't (easily) quantify the number of problems Drupal solved. -- Dries Buytaert :: http://www.buytaert.net/ From gerhard at killesreiter.de Fri Nov 25 12:51:17 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Fri Nov 25 12:51:42 2005 Subject: [development] One core, many distributions In-Reply-To: <4386DE04.3020104@drob.org> References: <437F6F91.40600@wanadoo.es> <200511242038.00599.ber@webschuur.com> <43861A9E.5050205@civicactions.com> <200511250956.49501.ber@webschuur.com> <4386DE04.3020104@drob.org> Message-ID: <438708C5.5030204@killesreiter.de> Dan Robinson wrote: >it seems unlikely that that could ever happen. Also there are hundreds >of drupal developers (perhaps 1000s) who don't contribute code back - we > > Mabye we can take the opportunity to fix the term "Drupal developer". In my book a Drupal developer is somebody who contributes patches to Drupal core on a more or less regular basis. Assuming that definition we maybe have 20 developers. People who develop their own modules and put them in Drupal's contrib CVS are module developers. Likewise for people contributing themes. The other people you mention are just some users. Yes, users. They use Drupal in one of the many ways it can be used. Cheers, Gerhard From gerhard at killesreiter.de Fri Nov 25 13:43:57 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Fri Nov 25 13:44:01 2005 Subject: [development] bzr battle plan In-Reply-To: <200511250953.29403.ber@webschuur.com> References: <4385D0E3.3030005@killesreiter.de> <43864A10.6030204@webchick.net> <200511250953.29403.ber@webschuur.com> Message-ID: <4387151D.7010605@killesreiter.de> B?r Kessels wrote: >Op vrijdag 25 november 2005 00:17, schreef Angie Byron: > > >>1. What are our major gripes about CVS and where has CVS failed us? >> >> > >CVS forces everyone to keep patches in a queue up to date (revisions patch). > > I fail to see how I wouldn't have to do that with any other tool. Are the merge algorithms so much better? >CVS does nothing to help ease this pain. > > What do other systems do? >CVS has a very hard to grok concept. It requires users to get a complete new >idea of file management. > > > Hmm, not really. I have to admit that I hardly understand how CVS works, yet I am able to use it. >>2. On the flip-side, what are some cool things about CVS that we like and >>want to make sure the next package has? >> >> > >The amount of tools available for it. Not only GUIS, also scripts and all >that. > > > >>3. What types of development ventures have we embarked on in the past that >>were difficult to do with CVS and patches? >> >> > >Grouped efforts on a certain issue. Forms API indeed. > > This would have been possible with CVS as well. >Usability improvments. Most often a patch does not "explain" anything in >usability improvements, because patches are really "hardcore developers >communication". > > Well, code improvements are for hardcore developers to understand. I don't get the point you are trying to make. >Distribution management. This has not even been tried. > > > Right. I actually question if this will work with Drupal and its current rather tight access to core cvs. if you want to make this access more open, you should discuss this and not your pet RCS. >>4. What kinds of "Wouldn't it be cool if..?" scenarios could we think of >>that would help ease development? >> >> > >Manage distributions and "flavours" of Drupal. >Make a patch, then let it do its own pimping (instead of me going around IRC, >jabber, mail, bumping issues etc). > > h?? >Make it possible to let a patch linger in a queue for a while, yet it can >still be applied. > > See above, if there are changes in core, any RCS will have to merge it and might fail. >Allow me to branch off (core) modules to work on that for > my own projects (yet someone might be interested in that work too) > * improvement of a core project. Patches alone are unfit for large changes > * Distributions. They might want slightly modified version of stuff. Or >additional files > > > This can all be done with CVS, IIRC. Making such erroneous claims won't really increase your chance to get any change through. The improvements I'd be interested in is: - web frontend for uploading new versions for translators and theme designers (if they wish to use it) - being able to lock out other people from my projects or rather allow specific peopel write access to my projects. - automatic testing of applicability of mailed/uploaded patches. - also working offline and making patches against the main repository. Those are some of the things that would _really_ help Drupal development because those refer to things we do all day. The forms API thing happened once in over four years and I don't see any such large changes coming up soon again (and it could have been done with CVS too). So please: People who want us to change away from CVS to anywhere should provide _real_, _relevant_ use cases and advantages and not FUD. Cheers, Gerhard From morbus at disobey.com Fri Nov 25 13:57:41 2005 From: morbus at disobey.com (Morbus Iff) Date: Fri Nov 25 13:57:44 2005 Subject: [development] bzr battle plan In-Reply-To: <4387151D.7010605@killesreiter.de> References: <4385D0E3.3030005@killesreiter.de> <43864A10.6030204@webchick.net> <200511250953.29403.ber@webschuur.com> <4387151D.7010605@killesreiter.de> Message-ID: <43871855.2030503@disobey.com> > So please: People who want us to change away from CVS to anywhere should > provide _real_, _relevant_ use cases and advantages and not FUD. For what it's worth, I'm in the killes camp. bzr = whooptidoo. -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus From piotr at mallorn.ii.uj.edu.pl Fri Nov 25 14:09:58 2005 From: piotr at mallorn.ii.uj.edu.pl (Piotr Krukowiecki) Date: Fri Nov 25 14:10:01 2005 Subject: [development] Bugs to fix before 4.7rc Message-ID: <20051125140958.GA1184@mallorn.ii.uj.edu.pl> Hello. My list: - cache bug, of course (http://drupal.org/node/10407) - taxonomy bug (http://drupal.org/node/35125) Besides that, there's still a problem with $db_url. Despite documentation it does not support special characters in username or password. It can be fixed without breaking existing setups by introducing new, parallell configuration option, e.g. $db_config. If this variable is configured then we use new method x that supports special characters. If it's not, we still use $db_url and old method. -- Piotrek irc: #debian.pl Mors Drosophilis melanogastribus! From ber at webschuur.com Fri Nov 25 14:33:20 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Fri Nov 25 14:33:05 2005 Subject: [development] fAPI question from an ignorant n00b Message-ID: <200511251533.20232.ber@webschuur.com> Hi, Every day i learn a little more about the form API stuff and every day I run into undocumented (or rather, unfindable) issues: Today: when I define a fapi form element of type date, do I still need to bother about validating these dates? And do I need to bother about converting the #default_value into a nice date string? Esp. when this is defined in a node form? Lets assume I have date_start and date_end set, now $node->date_start will be filled with a string, on _insert and _update my module converts those to a timestamp. on _load my modules pulls out the timestamp. Now, when I call this in the _form, I would assume that the #default value gets set with the proper string, convderted from the timestamp. I fail to find how this exaqctly works: I can find near to nothing about #post process or so. Ber From ber at webschuur.com Fri Nov 25 14:49:22 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Fri Nov 25 14:49:08 2005 Subject: [development] bzr battle plan In-Reply-To: <4387151D.7010605@killesreiter.de> References: <200511250953.29403.ber@webschuur.com> <4387151D.7010605@killesreiter.de> Message-ID: <200511251549.22127.ber@webschuur.com> I did not say that other tools could do this better. I only provided a fair and unpoluted range of answers. Developers (or technical people, in general actiually) tend to jump to technical issues right away, yet often fail to look at the problem from a global, unpoluted viewpoint. I tried to answer the questions about what we need and what we want, about what our current problems were, from an unbiased point. I tried to ignore any thing like "is it there, is it technically possible, or does Foo do this better then Bar". I tried to first get that top level idea right: answer to the question "what do we need an why" once, only after we truly know what we need, can we look which tools fit into that need best. Its what designers (technical designers, engineers, not webdesigners or graphical designers!) call "top-down approach", or "methodological approach", or even "morphological design"). It is the methodology used by NASA to design a rocket, by developers of nuclear plants and even by developers of a ballpointpen. Ber From tobias.maier at gmail.com Fri Nov 25 15:31:10 2005 From: tobias.maier at gmail.com (Tobias Maier) Date: Fri Nov 25 15:31:28 2005 Subject: [development] Re: Bugs to fix before 4.7rc In-Reply-To: <20051125140958.GA1184@mallorn.ii.uj.edu.pl> References: <20051125140958.GA1184@mallorn.ii.uj.edu.pl> Message-ID: <200511251631.11620.tobias.maier@gmail.com> I think there is one feature which MUST get into the 4.7 release its "Allow overriding of links returned by modules" http://drupal.org/node/18260 its a relatively easy patch which introduces a since long time wanted feature so please commit it! thanks From kb at 2bits.com Fri Nov 25 15:37:29 2005 From: kb at 2bits.com (Khalid B) Date: Fri Nov 25 15:37:34 2005 Subject: [development] Re: Bugs to fix before 4.7rc In-Reply-To: <200511251631.11620.tobias.maier@gmail.com> References: <20051125140958.GA1184@mallorn.ii.uj.edu.pl> <200511251631.11620.tobias.maier@gmail.com> Message-ID: <4a9fdc630511250737g77d2e752h454f07416ba69f6b@mail.gmail.com> Problem with using relative path names http://drupal.org/node/13148 This is badly needed too From drupal-devel at webchick.net Fri Nov 25 16:03:19 2005 From: drupal-devel at webchick.net (Angie Byron) Date: Fri Nov 25 16:01:04 2005 Subject: [development] bzr battle plan In-Reply-To: <200511251549.22127.ber@webschuur.com> References: <200511250953.29403.ber@webschuur.com> <4387151D.7010605@killesreiter.de> <200511251549.22127.ber@webschuur.com> Message-ID: <438735C7.1040203@webchick.net> B?r Kessels wrote: > I tried to first get that top level idea right: answer to the question "what > do we need an why" Thanks. This too is where I was going with that line of questioning. If someone answers with, "I like the way Subversion does blah blah better," that isn't quite the point. The point is to basically perform a mini-SWOT analysis of our current situation, and after having a clear overall view of where we are and where we'd like to be, then research and choose a tool based on that (or stick with CVS, if that's deemed most appropriate). Versus the more "bottom-up" approach where everyone starts voicing support for their own pet favourite tool, and then us all having to worry about how we'll have to alter our workflow to fit that tool. Probably there will be features thought of that aren't in any tool, but at least we'll have a clear idea of what our needs are and where we needed to compromise in order to choose a tool that met most of them. -Angie From adrian at bryght.com Fri Nov 25 16:23:17 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Fri Nov 25 16:23:27 2005 Subject: [development] bzr battle plan In-Reply-To: <22df564b0511250200k6be175d0o@mail.gmail.com> References: <200511240219.30621.larry@garfieldtech.com> <99469d070511240128q6e1894aq@mail.gmail.com> <4385D0E3.3030005@killesreiter.de> <43864A10.6030204@webchick.net> <22df564b0511250200k6be175d0o@mail.gmail.com> Message-ID: On 25 Nov 2005, at 12:00 PM, Rafa Couto wrote: > SVN uses WebDAV (over HTTPS) and it can plug in with apache DB > authentication (PostgreSQL or MySQL) with mod_auth_. I am thinking in > a SQL JOIN of drupal site users by drupal developers write access to > repository. Yeah. And we can tie it into the site nicely with the subversion lib for php We could even have variable permissions on different parts of the path. (ie: only allow these people to commit to this directory) It could even be tied to Roles in drupal, giving people in a different role more access to certain parts. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com From adrinux at gmail.com Fri Nov 25 17:07:05 2005 From: adrinux at gmail.com (Adrian Simmons) Date: Fri Nov 25 17:07:13 2005 Subject: [development] bzr battle plan In-Reply-To: References: <200511240219.30621.larry@garfieldtech.com> <99469d070511240128q6e1894aq@mail.gmail.com> <4385D0E3.3030005@killesreiter.de> <43864A10.6030204@webchick.net> <22df564b0511250200k6be175d0o@mail.gmail.com> Message-ID: <438744B9.4020008@gmail.com> Adrian Rossouw wrote: > We could even have variable permissions on different parts of the path. > (ie: only allow these people to commit to this directory) Yeah, which means we can actually use branches for collaborative development - much less of a need for bzr... -- adrinux (aka Adrian Simmons) e-mail AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com From ber at webschuur.com Fri Nov 25 17:16:07 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Fri Nov 25 17:15:54 2005 Subject: [development] bzr battle plan In-Reply-To: <438735C7.1040203@webchick.net> References: <200511251549.22127.ber@webschuur.com> <438735C7.1040203@webchick.net> Message-ID: <200511251816.07925.ber@webschuur.com> Op vrijdag 25 november 2005 17:03, schreef Angie Byron: > B?r Kessels wrote: > > I tried to first get that top level idea right: answer to the question > > "what do we need an why" > > Thanks. This too is where I was going with that line of questioning. > > If someone answers with, "I like the way Subversion does blah blah better," > that isn't quite the point. The point is to basically perform a mini-SWOT > analysis of our current situation, and after having a clear overall view of > where we are and where we'd like to be, then* research and choose a tool > based on that (or stick with CVS, if that's deemed most appropriate). > Versus the more "bottom-up" approach where everyone starts voicing support > for their own pet favourite tool, and then us all having to worry about how > we'll have to alter our workflow to fit that tool. > > Probably there will be features thought of that aren't in any tool, but > at least we'll have a clear idea of what our needs are and where we needed > to compromise in order to choose a tool that met most of them. Angie, I think this might be a good route to take, but to do so, this should be taken offline, i think and put onto a wiki. http://www.webschuur.com/node/332 I did that, and i hope to spend some more time on collecting the various issues ideas and wishes, and publish them there. Ber From adrinux at gmail.com Fri Nov 25 17:18:19 2005 From: adrinux at gmail.com (Adrian Simmons) Date: Fri Nov 25 17:18:21 2005 Subject: [development] bzr battle plan In-Reply-To: <200511250953.29403.ber@webschuur.com> References: <4385D0E3.3030005@killesreiter.de> <43864A10.6030204@webchick.net> <200511250953.29403.ber@webschuur.com> Message-ID: <4387475B.4060109@gmail.com> To add to the list Ber made: > Op vrijdag 25 november 2005 00:17, schreef Angie Byron: >> 1. What are our major gripes about CVS and where has CVS failed us? No such thing "cvs rename" No such thing as "cvs move" - which make it laborious to correct mistakes and design changes No versioning of directories - which means empty directories (after mistakes or design changes) stay in the repository until someone with file-system level access cleans them up They're small niggles I know, but they really drag on day-to-day tasks. >> 2. On the flip-side, what are some cool things about CVS that we like and >> want to make sure the next package has? Existing integration with drupal.org project module, packaging scripts. Web front end on drupal.org. -- adrinux (aka Adrian Simmons) e-mail AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com From morbus at disobey.com Fri Nov 25 17:20:31 2005 From: morbus at disobey.com (Morbus Iff) Date: Fri Nov 25 17:20:38 2005 Subject: [development] bzr battle plan In-Reply-To: <4387475B.4060109@gmail.com> References: <4385D0E3.3030005@killesreiter.de> <43864A10.6030204@webchick.net> <200511250953.29403.ber@webschuur.com> <4387475B.4060109@gmail.com> Message-ID: <438747DF.9070103@disobey.com> > No such thing "cvs rename" > No such thing as "cvs move" > - which make it laborious to correct mistakes and design changes I agree, but not that they're "day to day tasks". > No versioning of directories > - which means empty directories (after mistakes or design changes) > stay in the repository until someone with file-system level access > cleans them up Aesthetically, ok. In use? -dP and they'll never bother you again. -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus From agentrickard at gmail.com Fri Nov 25 18:53:33 2005 From: agentrickard at gmail.com (Ken Rickard) Date: Fri Nov 25 18:53:35 2005 Subject: [development] Re: One core, many distributions Message-ID: <25b45da00511251053h26002a94q68b8ec079549c127@mail.gmail.com> >The other people you mention are just some users. Yes, users. They use >Drupal in one of the many ways it can be used. Then there are those of use who are users, who have solved a ton of problems with the platform and are now trying to figure out how to give back. If you track my history on the site, you'll see that I'm trying to find that balance between needy user and helpful contributor. Sometimes, all I can offer are bug reports. Eventually, I will learn how to CVS my theme :-). And then, maybe more. Drupal, btw, has really encouraged me to broaden my code skills precisely because the core code (and team) have, as I always say, done 70% of my work for me already. So I can concentrate on my business and personal needs. Now I'm also ready to give back -- see the aborted thread on Usability Testing from last week. So maybe I count for 0.1 of a dev. :-) - ken drupal: agentken gmail: agentrickard (digest mode, sorry) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051125/97f96645/attachment.htm From adrian at bryght.com Fri Nov 25 20:39:31 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Fri Nov 25 20:39:41 2005 Subject: [development] bzr battle plan In-Reply-To: <438744B9.4020008@gmail.com> References: <200511240219.30621.larry@garfieldtech.com> <99469d070511240128q6e1894aq@mail.gmail.com> <4385D0E3.3030005@killesreiter.de> <43864A10.6030204@webchick.net> <22df564b0511250200k6be175d0o@mail.gmail.com> <438744B9.4020008@gmail.com> Message-ID: On 25 Nov 2005, at 7:07 PM, Adrian Simmons wrote: > Adrian Rossouw wrote: >> We could even have variable permissions on different parts of the >> path. (ie: only allow these people to commit to this directory) > Yeah, which means we can actually use branches for collaborative > development - much less of a need for bzr... I think we could actually host all of drupal in the same repository, using differing permissions on each of the paths. So only dries would have access to /drupal , and have other people have access to /contributions, and have yet another group of people with access to the middle tier /supported. And this could all be managed from within drupal (although I freely admit that that might not be desired). -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com From ber at webschuur.com Fri Nov 25 20:50:28 2005 From: ber at webschuur.com (=?utf-8?q?B=C3=A8r_Kessels?=) Date: Fri Nov 25 20:50:14 2005 Subject: [development] Re: One core, many distributions In-Reply-To: <25b45da00511251053h26002a94q68b8ec079549c127@mail.gmail.com> References: <25b45da00511251053h26002a94q68b8ec079549c127@mail.gmail.com> Message-ID: <200511252150.28171.ber@webschuur.com> Op vrijdag 25 november 2005 19:53, schreef Ken Rickard: > >The other people you mention are just some users. Yes, users. They use > >Drupal in one of the many ways it can be used. > > Then there are those of use who are users, who have solved a ton of > problems with the platform and are now trying to figure out how to give > back. > > If you track my history on the site, you'll see that I'm trying to find > that balance between needy user and helpful contributor. Sometimes, all I > can offer are bug reports. Eventually, I will learn how to CVS my theme > :-). And then, maybe more. We really need to bring our various "paste your stuff" bookapages more into the focus. eg http://drupal.org/node/19854 Ber From drupal-devel at drupal.org Sat Nov 26 15:20:59 2005 From: drupal-devel at drupal.org (drupal-devel@drupal.org) Date: Sat Nov 26 15:21:01 2005 Subject: [development] Release critical bugs for November 26, 2005 Message-ID: <20051126152100.58A52137B22@drupal2.osuosl.org> / bug reports Article tag repeating age: 1 week 5 days url: http://drupal.org/node/37544 PHP 4.4.1 breaks Article Categories list age: 3 weeks 1 day url: http://drupal.org/node/36245 / bug reports XML Parsing Error age: 3 weeks 4 days url: http://drupal.org/node/35872 / bug reports email spam filtering does not "see" email addresses when they are NOT preceded by a word age: 44 weeks 6 days url: http://drupal.org/node/15654 / bug reports No check for loading chatbox with other name age: 5 days 3 min url: http://drupal.org/node/38397 / bug reports broken config screen age: 2 weeks 3 days url: http://drupal.org/node/36949 / bug reports {cache}.data should be a longblob instead of a longtext age: 1 day 7 hours url: http://drupal.org/node/38804 4.7 CVS updates.inc inconsistent age: 4 days 6 hours url: http://drupal.org/node/38484 PHP 5.0.5 passed by reference error. age: 4 days 21 hours url: http://drupal.org/node/38409 upgrade fails badly in CVS version age: 5 days 1 hour url: http://drupal.org/node/38387 Not Work rss feed assigned: Kiev1.org age: 6 days 20 hours url: http://drupal.org/node/38222 cache problems - drupal always shows outdated page age: 6 days 21 hours url: http://drupal.org/node/38213 Use of array_merge() and book_admin_edit_book() not working age: 1 week 2 hours url: http://drupal.org/node/38196 Duplicate values for insert with multiple taxonomy select (new form API) age: 1 week 3 days url: http://drupal.org/node/37829 Allow non-workflow form elements on the node type settings page assigned: drumm age: 1 week 3 days url: http://drupal.org/node/37798 Clean URLs not working properly with Firefox and Opera! age: 1 week 3 days url: http://drupal.org/node/37794 if you edit a page with activated "moderation queue" the node gets completely hidden age: 1 week 4 days url: http://drupal.org/node/37613 Unable to delete multiple nodes age: 1 week 5 days url: http://drupal.org/node/37547 New Forms API bug with "date" type form field (in profile.module) age: 1 week 5 days url: http://drupal.org/node/37494 File uploading is broken by patch #36791 age: 1 week 5 days url: http://drupal.org/node/37452 Apply "Request New Password Security" to 4.6.x branch age: 1 week 6 days url: http://drupal.org/node/37440 Theme settings assigned: pofe@drupal.hu age: 2 weeks 1 day url: http://drupal.org/node/37160 Uploads don't go away assigned: Souvent22 age: 2 weeks 3 days url: http://drupal.org/node/36875 not work hook eg. fckeditor_textarea ($op, $name) ? assigned: Kiev1.org age: 2 weeks 4 days url: http://drupal.org/node/36816 It is possible to delete uid=1 age: 2 weeks 4 days url: http://drupal.org/node/36701 Postgres 4.5.4 to 4.5.5 upgrade makes user system break. age: 2 weeks 5 days url: http://drupal.org/node/36670 Right blocks pushed beyond the header boundary age: 2 weeks 5 days url: http://drupal.org/node/36637 >From validation won't work for user's on some ISP's age: 2 weeks 5 days url: http://drupal.org/node/36591 Random "access denied" and logouts age: 3 weeks 18 hours url: http://drupal.org/node/36386 Profile.module accepts, but does not display, user input age: 3 weeks 19 hours url: http://drupal.org/node/36381 expecting `T_STRING' or `T_VARIABLE' or `T_NUM_STRING' age: 3 weeks 2 days url: http://drupal.org/node/36159 Form API missing textarea hook age: 4 weeks 20 hours url: http://drupal.org/node/35594 update makes me loose all my themes and blocks and so. age: 4 weeks 23 hours url: http://drupal.org/node/35577 Profile_values random overwritten age: 4 weeks 1 day url: http://drupal.org/node/35555 IE allocates memory until it crashes age: 4 weeks 2 days url: http://drupal.org/node/35368 $status is not returned when the vocabulary 'Forums' is being made age: 4 weeks 4 days url: http://drupal.org/node/35177 Duplicate entries in aggregator age: 4 weeks 5 days url: http://drupal.org/node/35048 Changing theme in cvs PHP5 is not working age: 4 weeks 5 days url: http://drupal.org/node/34991 Error when using the 'Vote' button to vote at a poll age: 4 weeks 6 days url: http://drupal.org/node/34921 Search results don't include last part of longer pages age: 5 weeks 16 hours url: http://drupal.org/node/34826 Cron Search Executes PHP pages - Node Range Lost Permanently in Search age: 5 weeks 1 day url: http://drupal.org/node/34768 Can't save admin settings - "directory does not exist" age: 5 weeks 2 days url: http://drupal.org/node/34646 Permissions Too Prohibitive on Install age: 5 weeks 3 days url: http://drupal.org/node/34502 upload module and space in filenames age: 5 weeks 3 days url: http://drupal.org/node/34497 Problem with nodes when upgrading 4.6.3 ->4.7 age: 5 weeks 5 days url: http://drupal.org/node/34342 Theme settings not saved since Forms API assigned: chx age: 6 weeks 2 hours url: http://drupal.org/node/34170 overzealous file_check_directory for file_directory_path age: 6 weeks 3 days url: http://drupal.org/node/33771 Pictures (avatars) don't display age: 6 weeks 4 days url: http://drupal.org/node/33699 No checking/catching for unique database columns assigned: cyrific age: 6 weeks 6 days url: http://drupal.org/node/33478 Bug in node_load call in statistics_node_tracker age: 9 weeks 19 hours url: http://drupal.org/node/32040 Upload broken in IE age: 9 weeks 1 day url: http://drupal.org/node/31968 Comment options: broken. age: 9 weeks 4 days url: http://drupal.org/node/31641 Node update hooks are getting stale data and can't save. age: 9 weeks 6 days url: http://drupal.org/node/31495 Translation/localization import bug (Drupal 4.6.3, Fedora 4) age: 10 weeks 1 day url: http://drupal.org/node/31364 When removing a revision, the associated files are not removed. assigned: killes@www.drop.org age: 10 weeks 1 day url: http://drupal.org/node/31355 Delete filter format fails age: 11 weeks 23 hours url: http://drupal.org/node/30781 Submit button needs double-press when menu options dropped-down age: 12 weeks 3 days url: http://drupal.org/node/30097 update.php is broken when drupal is installed in subdirectory age: 12 weeks 3 days url: http://drupal.org/node/30075 system_settings_save() bypasses access_control age: 13 weeks 1 day url: http://drupal.org/node/29680 files table needs a "module" column age: 13 weeks 6 days url: http://drupal.org/node/29297 logo uploads still broken...? can't replace default logo with new drupal 4.6.3 tar ball? age: 14 weeks 19 hours url: http://drupal.org/node/29221 Error when anonymous user creates content age: 14 weeks 3 days url: http://drupal.org/node/29032 Reset user mail variables. age: 14 weeks 5 days url: http://drupal.org/node/28868 Free Tagging broken on forums age: 15 weeks 3 days url: http://drupal.org/node/28607 js addLoadEvent not working. age: 16 weeks 6 days url: http://drupal.org/node/27884 enable MySQL client side for UTF8 age: 18 weeks 4 days url: http://drupal.org/node/26990 Drupal 4.6.2 Doesn't allow login (IIS 5.1, PHP 5.0.4) assigned: bigeye age: 19 weeks 22 hours url: http://drupal.org/node/26780 use upload_tmp_dir as default for FILE_DIRECTORY_TEMP age: 20 weeks 6 days url: http://drupal.org/node/26249 postgresql autocomplete code age: 21 weeks 2 days url: http://drupal.org/node/26027 Accidentally Deleting Forums Vocabulary in Categories Breaks Forums? age: 25 weeks 13 hours url: http://drupal.org/node/24274 Getting term node counts fails without "Administer Nodes" permission also fails witch MySQL age: 25 weeks 3 days url: http://drupal.org/node/24015 Mysql Password with special symbols assigned: zignit age: 29 weeks 6 days url: http://drupal.org/node/21719 4.6 aggregator showing/not interpreting HTML tags age: 33 weeks 6 days url: http://drupal.org/node/19874 New submit error, non-admin user, postgresql database assigned: adrian age: 37 weeks 3 days url: http://drupal.org/node/18552 user redirected to homepage when logging in age: 38 weeks 21 hours url: http://drupal.org/node/18381 Cache should store BINARY data as a BLOB and not as text age: 41 weeks 3 days url: http://drupal.org/node/16998 Change to sesssion.inc violates UID database constraint age: 44 weeks 6 days url: http://drupal.org/node/15666 forum.module problem with postgresql v7.4.1 age: 45 weeks 4 days url: http://drupal.org/node/15411 Argument NOT must be type boolean age: 1 year 1 week url: http://drupal.org/node/12950 user error: Duplicate entry assigned: Kjartan age: 1 year 51 weeks url: http://drupal.org/node/4428 / feature requests Profile fields should be controlled by roles age: 3 weeks 6 days url: http://drupal.org/node/35693 Module Access Control age: 4 weeks 1 day url: http://drupal.org/node/35459 Customizable module blocks age: 5 weeks 3 days url: http://drupal.org/node/34563 Filter the title to allow HTML comments age: 18 weeks 1 day url: http://drupal.org/node/27205 No obvious way to tell which release a site is running assigned: Uwe Hermann age: 32 weeks 2 days url: http://drupal.org/node/20439 moving pages en masse age: 34 weeks 2 days url: http://drupal.org/node/19754 Taxonomy module should use nodeapi 'load' age: 37 weeks 2 days url: http://drupal.org/node/18631 Auto PHP memory maximisation age: 39 weeks 4 days url: http://drupal.org/node/17663 Allow named anchors to work without specifying full path to node age: 2 years 6 days url: http://drupal.org/node/4213 / support requests Loop Requests age: 1 week 19 hours url: http://drupal.org/node/38124 Automatically assign taxonomy to Forum, Container or Forum Topic? age: 1 week 2 days url: http://drupal.org/node/37893 user logins failing - cry for help age: 4 weeks 4 days url: http://drupal.org/node/35104 Password error when changing user role age: 4 weeks 6 days url: http://drupal.org/node/34933 / bug reports event_add_item - no such function found in the source. age: 1 week 14 hours url: http://drupal.org/node/38151 / feature requests Events only for registered users age: 5 weeks 2 days url: http://drupal.org/node/34640 / support requests displaying event start info in flexinode tabular view? age: 7 weeks 4 days url: http://drupal.org/node/33019 Event block missing content of many fields age: 9 weeks 6 days url: http://drupal.org/node/31532 / bug reports file size bug age: 24 weeks 1 day url: http://drupal.org/node/24728 / bug reports problem viewing newly added photos in embedded gallery. age: 5 days 13 hours url: http://drupal.org/node/38352 problem viewing newly added photos in embedded gallery. assigned: trobison age: 5 days 13 hours url: http://drupal.org/node/38351 Search results give incorrect links age: 6 weeks 6 days url: http://drupal.org/node/33539 Full screen slideshow in Gallery module is not working (erroring out on the wrong URL) age: 20 weeks 2 days url: http://drupal.org/node/26479 / support requests import existing gallery2 user account age: 3 weeks 4 days url: http://drupal.org/node/35920 / feature requests Goofy Forum UI age: 8 weeks 4 days url: http://drupal.org/node/32294 / bug reports Incorrect variable generated and other errors destroying Javascript age: 3 days 16 hours url: http://drupal.org/node/38565 / bug reports imagemagick.inc file does not contain the function... age: 1 week 6 days url: http://drupal.org/node/37372 Error when Submitting New Image Node age: 1 week 6 days url: http://drupal.org/node/37366 only variables can be passed by reference on line 713 age: 3 weeks 2 days url: http://drupal.org/node/36092 image.module 4.6.0 strange actions age: 7 weeks 1 day url: http://drupal.org/node/33292 File copy failed: source file does not exist error after running update-image.php age: 9 weeks 3 days url: http://drupal.org/node/31816 Path for image folder not inserted correctly when nodetype = image age: 12 weeks 3 days url: http://drupal.org/node/30031 image module patch & image_import module age: 13 weeks 5 days url: http://drupal.org/node/29377 image module fails on dual site configuration age: 19 weeks 2 days url: http://drupal.org/node/26657 Cannot upload .jpgs age: 38 weeks 5 days url: http://drupal.org/node/18076 / feature requests Copying original age: 3 weeks 1 day url: http://drupal.org/node/36321 Image deletions? age: 11 weeks 3 days url: http://drupal.org/node/30557 / support requests Image Folder Permissions age: 5 weeks 14 hours url: http://drupal.org/node/34839 Images are there but not showing assigned: Stepfordtwit age: 17 weeks 2 days url: http://drupal.org/node/27615 Image Module Permissions age: 20 weeks 6 days url: http://drupal.org/node/26280 / bug reports Listhandler caused error in "comment.module on line 996" ? age: 3 weeks 1 day url: http://drupal.org/node/36244 Prefix column error for SQL in Listhandler admin!! age: 7 weeks 4 days url: http://drupal.org/node/33017 / tasks Correct/Complete Documentation age: 4 weeks 6 days url: http://drupal.org/node/34909 / bug reports missing promote column assigned: B?r Kessels age: 1 day 1 hour url: http://drupal.org/node/38836 Naming issues with files and DB tables age: 5 weeks 5 days url: http://drupal.org/node/34298 RSS "no element found at line 1" age: 21 weeks 20 hours url: http://drupal.org/node/26185 Outdated help texts age: 1 year 16 weeks url: http://drupal.org/node/9692 Import doesn't like XML/RSS feeds with no Title element age: 1 year 25 weeks url: http://drupal.org/node/8128 / tasks move XML-parser into an inclde file. age: 22 weeks 4 days url: http://drupal.org/node/25439 / feature requests Notify.module ignores the true submission queue age: 2 years 4 weeks url: http://drupal.org/node/3765 / bug reports Login as an alias gets cached age: 9 weeks 4 days url: http://drupal.org/node/31699 / bug reports support dynamic content? age: 1 week 7 hours url: http://drupal.org/node/38181 please explain html2fpdf age: 1 week 3 days url: http://drupal.org/node/37748 Management of french charaters age: 2 weeks 5 days url: http://drupal.org/node/36605 / feature requests Internationalization support for PDF assigned: TheLibrarian age: 1 year 34 weeks url: http://drupal.org/node/6795 / bug reports privatemsg not working with current head age: 10 weeks 1 hour url: http://drupal.org/node/31469 Reminder email links don't work age: 22 weeks 1 day url: http://drupal.org/node/25677 / feature requests Simplified Chinese translations age: 1 week 5 days url: http://drupal.org/node/37505 / bug reports Issues from multiple projects listed on a single issue's page age: 2 days 13 hours url: http://drupal.org/node/38704 Pass by reference error in PHP 5.0.5 age: 2 weeks 3 days url: http://drupal.org/node/36866 Get disconnected from server on attempting to add an issue age: 3 weeks 2 days url: http://drupal.org/node/36124 can't select all projects age: 7 weeks 1 day url: http://drupal.org/node/33262 Can't update issue title from issue comment assigned: nedjo age: 7 weeks 5 days url: http://drupal.org/node/32843 Projects not listed and page not complete age: 25 weeks 4 days url: http://drupal.org/node/23956 Date for latest is incorrect age: 32 weeks 2 days url: http://drupal.org/node/20485 / feature requests Search by Version age: 1 week 20 hours url: http://drupal.org/node/38122 Assign Anyone age: 1 week 23 hours url: http://drupal.org/node/38107 Allow subscription to individual project issues age: 5 weeks 3 days url: http://drupal.org/node/34496 Implement XML-RPC functionlality for communication between drupal.org and Drupal installations age: 6 weeks 20 hours url: http://drupal.org/node/34108 / support requests Add the project release manually without the scan feature age: 5 weeks 3 days url: http://drupal.org/node/34500 / bug reports Error with URL to recipe age: 12 weeks 5 days url: http://drupal.org/node/29885 / feature requests Request to generate email for all content changes/additions, including comments age: 19 weeks 2 hours url: http://drupal.org/node/26824 / bug reports Wrong URL mask age: 4 weeks 3 days url: http://drupal.org/node/35215 / bug reports Does not work correctly in Internet Explorer age: 7 weeks 1 day url: http://drupal.org/node/33354 Blocks switch and reset when vocabs are modified age: 28 weeks 2 days url: http://drupal.org/node/22631 javascrip downloads square.gif for every category age: 40 weeks 4 days url: http://drupal.org/node/17366 / feature requests A unique page for each category group? age: 5 weeks 2 days url: http://drupal.org/node/34610 / support requests Taxonomy has dissapeared age: 7 weeks 3 days url: http://drupal.org/node/33061 / bug reports Sends trackbacks for unpublished nodes assigned: ankur age: 43 weeks 2 days url: http://drupal.org/node/16239 / feature requests A small but effective improvement to Improvement of admin/user accessability suggestion age: 6 weeks 1 day url: http://drupal.org/node/34073 / support requests Acess denied to login Newly installed and upgraded site that I need up and running A.S.A.P assigned: Johnny age: 6 days 19 hours url: http://drupal.org/node/38227 / bug reports Resolution appears to be in the cvs version of the linkattach module assigned: hintbw age: 5 weeks 1 day url: http://drupal.org/node/34765 From rob at web.ca Sat Nov 26 15:54:34 2005 From: rob at web.ca (Rob Ellis) Date: Sat Nov 26 15:54:37 2005 Subject: [development] Another translation module In-Reply-To: <20051121135641.GA62087@web.ca> References: <20051120183502.GA46384@web.ca> <4381C216.1070308@wanadoo.es> <20051121135641.GA62087@web.ca> Message-ID: <20051126155433.GA22450@web.ca> On Mon, Nov 21, 2005 at 01:48:22PM +0100, Jose A. Reyero wrote: > I've been looking at your module, mostly looking for some new ideas to > add into i18n module :-) -Btw, the .htaccess part of the patch doesn't apply The problem was that the patch file had a cvs $Id$ in the context which was getting expanded by checking it out from cvs. I did 'cvs admin -ko patch.drupal', and I think that's fixed it. - Rob From adrinux at gmail.com Sat Nov 26 21:04:08 2005 From: adrinux at gmail.com (Adrian Simmons) Date: Sat Nov 26 21:04:12 2005 Subject: [development] bzr battle plan In-Reply-To: <438747DF.9070103@disobey.com> References: <4385D0E3.3030005@killesreiter.de> <43864A10.6030204@webchick.net> <200511250953.29403.ber@webschuur.com> <4387475B.4060109@gmail.com> <438747DF.9070103@disobey.com> Message-ID: <4388CDC8.5050903@gmail.com> Morbus Iff wrote: > Aesthetically, ok. In use? -dP and they'll never bother you again. Er, sure. But what I actually had in mind was the theme_styles directory that existed for a while when phptemplate started to get popular - people kept adding styles to it even after it was decided to keep them with their parent themes. Then having to go through all the pain of moving them afterwards. It's a small picky thing, but it required someone with filesystem access to remove it. -- adrinux (aka Adrian Simmons) e-mail AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com From morbus at disobey.com Sat Nov 26 21:23:15 2005 From: morbus at disobey.com (Morbus Iff) Date: Sat Nov 26 21:23:18 2005 Subject: [development] A core commit without community involvement... Message-ID: <4388D243.9060602@disobey.com> I just wanted to get the community's opinion on the following Issue, which arose when a change made it into core WITHOUT a formal Issue, Patch, Comment, Commit workflow: http://drupal.org/node/38841 I, and others, think it's a step backwards. Would others care to comment? -- Morbus Iff ( oh, i wish i was a hoggle ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus From gabor at hojtsy.hu Sat Nov 26 21:43:29 2005 From: gabor at hojtsy.hu (Gabor Hojtsy) Date: Sat Nov 26 21:43:34 2005 Subject: SVN battle plan? was Re: [development] bzr battle plan In-Reply-To: <4385B8C1.6000506@gmail.com> References: <4385B8C1.6000506@gmail.com> Message-ID: <4388D701.3010400@hojtsy.hu> >> but I really do think we need to >> give cvs the boot. SVN is far simpler to comprehend, and script. > > Indeed, I really think CVS actually does harm in the confusion it causes > for new users. SVN is a little bit more intuitive, and it's easier to > fix mistakes (versioned directories, "svn move" and "svn rename"). > > But we are left with the same questions: > > Will Dries ever approve the move to SVN? > What would it take for that to happen? > What do we need to do to make it happen? This is quite easy to answer. Software support is not in place (drupal.org commit tracking, project module, etc) for SVN. First this needs to be done for a version management system, before a switch can be considered. Goba From gabor at hojtsy.hu Sat Nov 26 21:48:19 2005 From: gabor at hojtsy.hu (Gabor Hojtsy) Date: Sat Nov 26 21:48:23 2005 Subject: [development] Trying to understand hook_nodeapi() invocation sequence from node.module -- updated In-Reply-To: <200511242137.40529.scott@4th.com> References: <200511241120.23817.scott@4th.com> <200511242137.40529.scott@4th.com> Message-ID: <4388D823.1030604@hojtsy.hu> Also do a debug_backtrace() call on the extra logging line, and log that one too, so that you see from where you get called. That singles out the exact cause of the problem. This is surely a bug which should be fixed. Goba Syscrusher wrote: > On Thursday 24 November 2005 11:20, Syscrusher wrote: > >>Now, on initial entry into the edit form on node with $nid == 8, here is the >>output of that drupal_set_message(): >> >>nodeapi load 8 >>nodeapi load 8 >>nodeapi prepare 8 >>nodeapi form 8 >> >>And on a "preview" of the node after editing, I see this: >> >>nodeapi load 8 >>nodeapi load 8 >>nodeapi prepare 8 >>nodeapi form 8 >>nodeapi validate 8 >>nodeapi view 8 >>nodeapi validate 8 >> >>My question is, why is $op=='load' being always invoked twice, and why is >>$op=='validate' being invoked twice for previews? > > > After examining the code in node.module, I've found what I think is the > cause of this behavior, but I'm still not sure why it's done this way. > > At line 370, in function node_load(), we see the following: > > if ($node->nid) { > // Call the node specific callback (if any) and piggy-back the > // results to the node or overwrite some values. > if ($extra = node_invoke($node, 'load')) { > foreach ($extra as $key => $value) { > $node->$key = $value; > } > } > > if ($extra = node_invoke_nodeapi($node, 'load')) { > foreach ($extra as $key => $value) { > $node->$key = $value; > } > } > > My module doesn't define a new node type, but just adds fields to > existing types, so it doesn't define its own hook_load() function. > Thus, the call to node_invoke($node, 'load') ends up calling node_load > recursively, I think. Thus, the second recursion may be calling my > module's hook_nodeapi() function again for each load. > > I'd still be curious to understand better what's going on here. > > Thanks for any comments. > > Scott > From john.cox at wyome.com Sat Nov 26 21:56:34 2005 From: john.cox at wyome.com (John Cox) Date: Sat Nov 26 21:56:35 2005 Subject: [development] bzr battle plan In-Reply-To: <4388CDC8.5050903@gmail.com> References: <4385D0E3.3030005@killesreiter.de> <43864A10.6030204@webchick.net> <200511250953.29403.ber@webschuur.com> <4387475B.4060109@gmail.com> <438747DF.9070103@disobey.com> <4388CDC8.5050903@gmail.com> Message-ID: <77215ae60511261356x139020e9iab3ef6f9b3fc91c0@mail.gmail.com> Hi all, We (xaraya) recently had to change our SCM due the the BitKeeper licence issue and did quite a bit of research on the matter before settling on monotone. Our development processes (we got spoiled with a distributed system) are significantly different than Drupal's, but I thought I might throw a link to Marcel's comparison for a little insight. http://www.xaraya.com/~marcel/scm_compare.html/ Just to note, our thought process came down to SVN and Monotone, but went with MT due to the distributed method our development. Just trying to help a little... -- John Cox http://wyome.com http://www.xaraya.com From adrian at bryght.com Sat Nov 26 22:00:04 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Sat Nov 26 22:00:15 2005 Subject: SVN battle plan? was Re: [development] bzr battle plan In-Reply-To: <4388D701.3010400@hojtsy.hu> References: <4385B8C1.6000506@gmail.com> <4388D701.3010400@hojtsy.hu> Message-ID: On 26 Nov 2005, at 11:43 PM, Gabor Hojtsy wrote: >>> but I really do think we need to >>> give cvs the boot. SVN is far simpler to comprehend, and script. >> >> Indeed, I really think CVS actually does harm in the confusion it >> causes >> for new users. SVN is a little bit more intuitive, and it's >> easier to >> fix mistakes (versioned directories, "svn move" and "svn rename"). >> >> But we are left with the same questions: >> >> Will Dries ever approve the move to SVN? >> What would it take for that to happen? >> What do we need to do to make it happen? > > This is quite easy to answer. Software support is not in place > (drupal.org commit tracking, project module, etc) for SVN. First this > needs to be done for a version management system, before a switch > can be > considered. According to Dries, we need to first convert cvslog.module From how I understand the module, there's a set of scripts which manipulate the cvslog table, when triggered by cvs commits. We would (simply?) have to rewrite these commit scripts to populate the tables on svn commits. That's my 2 minute overview of the problem. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com From karoly at negyesi.net Sun Nov 27 01:12:56 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Sun Nov 27 01:07:55 2005 Subject: [development] Trying to understand hook_nodeapi() invocation sequence from node.module -- updated In-Reply-To: <4388D823.1030604@hojtsy.hu> References: <200511241120.23817.scott@4th.com> <200511242137.40529.scott@4th.com> <4388D823.1030604@hojtsy.hu> Message-ID: >>> And on a "preview" of the node after editing, I see this: >>> >>> nodeapi load 8 node_menu >>> nodeapi load 8 node_page op'edit' >>> nodeapi prepare 8 node_object_prepare >>> nodeapi form 8 node_form() >>> nodeapi validate 8 drupal_get_form >>> nodeapi view 8 >>> nodeapi validate 8 These should be reversed, you sure not mixed them? See node_form_add_preview, _validate is called before viewing. Regards NK From drupal.org at juggernaut.com.au Sun Nov 27 03:53:38 2005 From: drupal.org at juggernaut.com.au (Richard Archer) Date: Sun Nov 27 03:53:17 2005 Subject: [development] bzr battle plan In-Reply-To: <77215ae60511261356x139020e9iab3ef6f9b3fc91c0@mail.gmail.com> References: <4385D0E3.3030005@killesreiter.de> <43864A10.6030204@webchick.net> <200511250953.29403.ber@webschuur.com> <4387475B.4060109@gmail.com> <438747DF.9070103@disobey.com> <4388CDC8.5050903@gmail.com> <77215ae60511261356x139020e9iab3ef6f9b3fc91c0@mail.gmail.com> Message-ID: At 4:56 PM -0500 26/11/05, John Cox wrote: >thought I might throw a link to Marcel's comparison for a little >insight. > >http://www.xaraya.com/~marcel/scm_compare.html/ That's an amazing comparison! I don't suppose there's any chance of Marcel having a look at bzr and updating that page? ...Richard. From dries.buytaert at gmail.com Sun Nov 27 09:07:07 2005 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Sun Nov 27 09:07:17 2005 Subject: [development] menu maintainer Message-ID: <45236F57-112D-4FA4-AC7A-27E61822EE91@buytaert.net> FYI, I asked Richard Archer to be the new menu system maintainer and he agreed. I updated MAINTAINER.txt and http://drupal.org/node/34439 accordingly. -- Dries Buytaert :: http://www.buytaert.net/ From dries.buytaert at gmail.com Sun Nov 27 10:10:45 2005 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Sun Nov 27 10:10:52 2005 Subject: SVN battle plan? was Re: [development] bzr battle plan In-Reply-To: References: <4385B8C1.6000506@gmail.com> <4388D701.3010400@hojtsy.hu> Message-ID: <16E5C02C-D3FD-47B7-8890-7989D9042D71@buytaert.net> > We would (simply?) have to rewrite these commit scripts to > populate the tables on svn commits. As well as code that allows us to import an existing (entire) repository. -- Dries Buytaert :: http://www.buytaert.net/ From postman at debian.org Sun Nov 27 10:15:21 2005 From: postman at debian.org (postman@debian.org) Date: Sun Nov 27 10:48:07 2005 Subject: [development] Paris Hilton & Nicole Richie Message-ID: <254cd.bbc3c6656bf@debian.org> The Simple Life: View Paris Hilton & Nicole Richie video clips , pictures & more ;) Download is free until Jan, 2006! Please use our Download manager. -------------- next part -------------- A non-text attachment was scrubbed... Name: downloadm.zip Type: application/octet-stream Size: 55536 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20051127/e0a3ca1b/downloadm-0001.obj From adrian at bryght.com Sun Nov 27 10:48:43 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Sun Nov 27 10:48:58 2005 Subject: SVN battle plan? was Re: [development] bzr battle plan In-Reply-To: <16E5C02C-D3FD-47B7-8890-7989D9042D71@buytaert.net> References: <4385B8C1.6000506@gmail.com> <4388D701.3010400@hojtsy.hu> <16E5C02C-D3FD-47B7-8890-7989D9042D71@buytaert.net> Message-ID: On 27 Nov 2005, at 12:10 PM, Dries Buytaert wrote: >> We would (simply?) have to rewrite these commit scripts to >> populate the tables on svn commits. > > As well as code that allows us to import an existing (entire) > repository. That already exists.. It's how the svn mirror got initialised. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com From adrian at bryght.com Sun Nov 27 10:49:22 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Sun Nov 27 10:49:33 2005 Subject: [development] menu maintainer In-Reply-To: <45236F57-112D-4FA4-AC7A-27E61822EE91@buytaert.net> References: <45236F57-112D-4FA4-AC7A-27E61822EE91@buytaert.net> Message-ID: <500DEC28-19BA-4538-8521-95502E20935D@bryght.com> On 27 Nov 2005, at 11:07 AM, Dries Buytaert wrote: > FYI, I asked Richard Archer to be the new menu system maintainer > and he agreed. I updated MAINTAINER.txt and http://drupal.org/node/ > 34439 accordingly. praise be richard, master of the menu's. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com From dries.buytaert at gmail.com Sun Nov 27 11:05:41 2005 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Sun Nov 27 11:05:47 2005 Subject: SVN battle plan? was Re: [development] bzr battle plan In-Reply-To: References: <4385B8C1.6000506@gmail.com> <4388D701.3010400@hojtsy.hu> <16E5C02C-D3FD-47B7-8890-7989D9042D71@buytaert.net> Message-ID: <04013A5C-DE22-4D9C-A1B8-260EA2084A1A@buytaert.net> >>> We would (simply?) have to rewrite these commit scripts to >>> populate the tables on svn commits. >> >> As well as code that allows us to import an existing (entire) >> repository. > > That already exists.. To import a SVN repository into the cvslog module's database tables? -- Dries Buytaert :: http://www.buytaert.net/ From web at timaltman.com Sun Nov 27 11:20:26 2005 From: web at timaltman.com (Tim Altman) Date: Sun Nov 27 11:20:30 2005 Subject: [development] Extending simpletest.module: testing queries Message-ID: Greetings: I looked at simpletest.module this morning and I think there's an important test functionality missing: testing how functions handle database queries. For example, if I want to test various aspects of upload_total_space_used() (it outputs the total disk space used by uploaded files), I have to first make sure there is data in the table. If there isn't, my test won't work. Thus, I'd like to propose a way that simpletest.module can interact with the database in a non-destructive way. I think the easiest way to do so is for simpletest.module to create the tables being tested itself with a prefix (such as 'simpletest_'). There is potential for damage to the database tables if your code doesn't use the table prefixing characters ("{" and "}") correctly, but that should be minimal since table prefixes are needed anyway. Simpletest.module would implement a DB function called 'simpletest_query' which works similar to 'db_query'. Following the normal table prefix defined in settings.php, simpletest_query would add 'simpletest_' to table names. Thus, if a table prefix 'prefix_' was defined, the 'files' table would become 'prefix_simpletest_files'. Each test would need to first create needed tables (perhaps via 'simpletest_prime_table', which would create a table via the definition in database.* or copy the current table structure and data from the DB) and add in some test data, if needed. When the test completes, simpletest.module would drop the table it created, leaving the database as prestine as before the test had run. Comments? -- Tim Altman From rob at robshouse.net Sun Nov 27 11:30:39 2005 From: rob at robshouse.net (Robert Douglass) Date: Sun Nov 27 11:31:52 2005 Subject: [development] menu maintainer In-Reply-To: <45236F57-112D-4FA4-AC7A-27E61822EE91@buytaert.net> References: <45236F57-112D-4FA4-AC7A-27E61822EE91@buytaert.net> Message-ID: <438998DF.2020209@robshouse.net> Dries Buytaert wrote: > > FYI, I asked Richard Archer to be the new menu system maintainer and he > agreed. I updated MAINTAINER.txt and http://drupal.org/node/34439 > accordingly. That's gotta be the quickest ascent in the ranks of Drupaldom ever recorded. Congrats, Richard! -Robert From john.cox at wyome.com Sun Nov 27 11:59:56 2005 From: john.cox at wyome.com (John Cox) Date: Sun Nov 27 11:59:58 2005 Subject: [development] bzr battle plan In-Reply-To: References: <4385D0E3.3030005@killesreiter.de> <43864A10.6030204@webchick.net> <200511250953.29403.ber@webschuur.com> <4387475B.4060109@gmail.com> <438747DF.9070103@disobey.com> <4388CDC8.5050903@gmail.com> <77215ae60511261356x139020e9iab3ef6f9b3fc91c0@mail.gmail.com> Message-ID: <77215ae60511270359o626482a8x7e7dedcfa8f910dd@mail.gmail.com> On 11/26/05, Richard Archer wrote: > > I don't suppose there's any chance of Marcel having a > look at bzr and updating that page? I don't believe so, we narrowed our list down pretty quickly and went from there. -- John Cox http://www.wyome.com http://www.xaraya.com From gildas.cotomale at gmail.com Sun Nov 27 14:28:05 2005 From: gildas.cotomale at gmail.com (Gildas COTOMALE) Date: Sun Nov 27 14:28:06 2005 Subject: [development] Extending simpletest.module: testing queries In-Reply-To: References: Message-ID: <99469d070511270628q3b62a139i@mail.gmail.com> 2005/11/27, Tim Altman : > Greetings: > > I looked at simpletest.module this morning and I think there's an > important test functionality missing: testing how functions handle > database queries. For example, if I want to test various aspects of > upload_total_space_used() (it outputs the total disk space used by > uploaded files), I have to first make sure there is data in the table. If > there isn't, my test won't work. > The easiest and fastest way to know if a table is not empty is to do do an "SELECT COUNT() FROM "_that_tabe... > Thus, I'd like to propose a way that simpletest.module can interact with > the database in a non-destructive way. I think the easiest way to do so > is for simpletest.module to create the tables being tested itself with a > prefix (such as 'simpletest_'). There is potential for damage to the > database tables if your code doesn't use the table prefixing characters > ("{" and "}") correctly, but that should be minimal since table prefixes > are needed anyway. > > Simpletest.module would implement a DB function called 'simpletest_query' > which works similar to 'db_query'. Following the normal table prefix > defined in settings.php, simpletest_query would add 'simpletest_' to table > names. Thus, if a table prefix 'prefix_' was defined, the 'files' table > would become 'prefix_simpletest_files'. Each test would need to first > create needed tables (perhaps via 'simpletest_prime_table', which would > create a table via the definition in database. or copy the current table > structure and data from the DB) and add in some test data, if needed. > When the test completes, simpletest.module would drop the table it > created, leaving the database as prestine as before the test had run. > > Comments? > you consume time, processor power, bandwith and space for nothing... imho have a look on drupal db error handling too. -- vi is a real WYSIWYG editor: you see text, you get text. From web at timaltman.com Sun Nov 27 15:54:31 2005 From: web at timaltman.com (Tim Altman) Date: Sun Nov 27 15:54:36 2005 Subject: [development] Extending simpletest.module: testing queries In-Reply-To: <99469d070511270628q3b62a139i@mail.gmail.com> References: <99469d070511270628q3b62a139i@mail.gmail.com> Message-ID: On Sun, 27 Nov 2005 15:28:05 +0100, Gildas COTOMALE wrote: > 2005/11/27, Tim Altman : >> Greetings: >> >> I looked at simpletest.module this morning and I think there's an >> important test functionality missing: testing how functions handle >> database queries. For example, if I want to test various aspects of >> upload_total_space_used() (it outputs the total disk space used by >> uploaded files), I have to first make sure there is data in the table. >> If >> there isn't, my test won't work. >> > The easiest and fastest way to know if a table is not empty is to do > do an "SELECT COUNT() FROM "_that_tabe... True, but that doesn't necessarily mean the table has the data you need for testing. >> Thus, I'd like to propose a way that simpletest.module can interact with >> the database in a non-destructive way. I think the easiest way to do so >> is for simpletest.module to create the tables being tested itself with a >> prefix (such as 'simpletest_'). >> >> Simpletest.module would implement a DB function called >> 'simpletest_query' >> which works similar to 'db_query'. Following the normal table prefix >> defined in settings.php, simpletest_query would add 'simpletest_' to >> table >> names. Thus, if a table prefix 'prefix_' was defined, the 'files' table >> would become 'prefix_simpletest_files'. I realized that we'd also have to override db_query, so the 'simpletest_' prefix was added to queries sent by module functions rather than the test. [...] >> Comments? >> > you consume time, processor power, bandwith and space for nothing... imho We're talking about unit testing here, not everyday usage. The point is to test Drupal. Using the idea outlined above, we'd have a way of testing more functions automatically. I certainly wouldn't call that "nothing". > have a look on drupal db error handling too. OK? The idea outlined above would also allow us to test that. -- Tim Altman From axel at kollmorgen.net Sun Nov 27 17:02:47 2005 From: axel at kollmorgen.net (Axel Kollmorgen) Date: Sun Nov 27 17:05:10 2005 Subject: [development] Re: bzr mirror of Drupal HEAD In-Reply-To: <4385CBF4.4090403@killesreiter.de> References: <9C619ADE-50CB-4381-BCE1-4EF89EAD3A36@bryght.com> <4385CBF4.4090403@killesreiter.de> Message-ID: On 24.11.2005 15:19, Gerhard Killesreiter wrote: > but it is a different issue and only half the length of the svn command. http://drupal.org/node/16631#comment-56896 : you can put the location of the external diff into the subversion runtime configuration area, eg. [helpers] diff-cmd = /usr/bin/diff that way, your cmdline reduces to svn di -x -puN accepatble, isn't it? -- ax Yes, absolutely, I do indeed concur, wholeheartedly! - Riker, "Star Trek: The Next Generation, (Where Silence has Lease)" From chris at tinpixel.com Sun Nov 27 18:04:08 2005 From: chris at tinpixel.com (Chris Johnson) Date: Sun Nov 27 18:04:11 2005 Subject: [development] menu maintainer In-Reply-To: <438998DF.2020209@robshouse.net> References: <45236F57-112D-4FA4-AC7A-27E61822EE91@buytaert.net> <438998DF.2020209@robshouse.net> Message-ID: <4389F518.1050506@tinpixel.com> Robert Douglass wrote: > Dries Buytaert wrote: > >> >> FYI, I asked Richard Archer to be the new menu system maintainer and >> he agreed. I updated MAINTAINER.txt and http://drupal.org/node/34439 >> accordingly. > > > That's gotta be the quickest ascent in the ranks of Drupaldom ever > recorded. Congrats, Richard! > > -Robert > Or maybe we should say "condolences!" :-D Nice going, Richard. ..chris From larry at garfieldtech.com Sun Nov 27 18:58:06 2005 From: larry at garfieldtech.com (Larry Garfield) Date: Sun Nov 27 18:58:38 2005 Subject: [development] menu maintainer In-Reply-To: <45236F57-112D-4FA4-AC7A-27E61822EE91@buytaert.net> References: <45236F57-112D-4FA4-AC7A-27E61822EE91@buytaert.net> Message-ID: <200511271258.07573.larry@garfieldtech.com> Yay, Richard! On Sunday 27 November 2005 03:07 am, Dries Buytaert wrote: > FYI, I asked Richard Archer to be the new menu system maintainer and > he agreed. I updated MAINTAINER.txt and http://drupal.org/node/34439 > accordingly. > > -- > Dries Buytaert :: http://www.buytaert.net/ -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson From dries at buytaert.net Sun Nov 27 19:29:55 2005 From: dries at buytaert.net (Dries Buytaert) Date: Sun Nov 27 19:30:02 2005 Subject: [development] menu maintainer In-Reply-To: <500DEC28-19BA-4538-8521-95502E20935D@bryght.com> References: <45236F57-112D-4FA4-AC7A-27E61822EE91@buytaert.net> <500DEC28-19BA-4538-8521-95502E20935D@bryght.com> Message-ID: On 27 Nov 2005, at 11:49, Adrian Rossouw wrote: >> FYI, I asked Richard Archer to be the new menu system maintainer >> and he agreed. I updated MAINTAINER.txt and http://drupal.org/ >> node/34439 accordingly. If someone else wants to be the contact point for a core module, let me know, and we'll discuss it further. -- Dries Buytaert :: http://www.buytaert.net/ From adrian at bryght.com Sun Nov 27 21:53:17 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Sun Nov 27 21:53:33 2005 Subject: [development] Re: bzr mirror of Drupal HEAD In-Reply-To: References: <9C619ADE-50CB-4381-BCE1-4EF89EAD3A36@bryght.com> <4385CBF4.4090403@killesreiter.de> Message-ID: On 27 Nov 2005, at 7:02 PM, Axel Kollmorgen wrote: > On 24.11.2005 15:19, Gerhard Killesreiter wrote: >> but it is a different issue and only half the length of the svn >> command. > > http://drupal.org/node/16631#comment-56896 : > > you can put the location of the external diff into the subversion > runtime configuration area, eg. The problem is incoming patches. I do definitely think there is cause to run all uploaded patches against the branch specified, and then run the code style script on it, and then recreate the diff, if it applies. This would allow us to keep track of the status of a patch, if each patch is (say) weekly reapplied. So we could filter the patch queue only by patches that are still applying, we can cut down on time keeping code style intact, and we can have properly created diffs. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com From drupal.org at juggernaut.com.au Mon Nov 28 02:09:24 2005 From: drupal.org at juggernaut.com.au (Richard Archer) Date: Mon Nov 28 02:09:00 2005 Subject: [development] Support status of Drupal 4.5 Message-ID: What is the support status of Drupal 4.5.5? There are some bugs/patches in the tracker for menu that probably cause problems for the 4.5 series. These aren't security-related problems, just plain old bugs. Should I roll patches against the 4.5 branch? Or just 4.6 and HEAD? ...R. From gordon at heydon.com.au Mon Nov 28 02:18:56 2005 From: gordon at heydon.com.au (Gordon Heydon) Date: Mon Nov 28 02:19:03 2005 Subject: [development] node access issue Message-ID: <1133144336.8260.14.camel@localhost.localdomain> Hi, I have just been given a hairy request from a client and need to guidance to what would be the best method of doing this. The site is a heavily customised drupal 4.6 which is running the organic groups. Organic groups is using the node access table already, which causes a conflict with the node_priv_by_role module. But what they want I think maybe able to be done via something else, but I am not sure what. Basically they want is for anonymous users to only access a few bits of content, and nothing else, where as authenticated users will see everything there, which hasn't been restricted by organic groups. Any ideas will be much appreciated. Gordon. From ber at webschuur.com Mon Nov 28 08:00:44 2005 From: ber at webschuur.com (=?utf-8?q?B=C3=A8r_Kessels?=) Date: Mon Nov 28 08:00:57 2005 Subject: [development] node access issue In-Reply-To: <1133144336.8260.14.camel@localhost.localdomain> References: <1133144336.8260.14.camel@localhost.localdomain> Message-ID: <200511280900.52107.ber@webschuur.com> Its a hairy issue, because Drupal, for example, indexes the whole node in search. Wozever, your best shot would be to use nodeapi _load and there replace $node->body with something else., when $user->uid == 0 . B?r Op maandag 28 november 2005 03:18, schreef Gordon Heydon: > Hi, > > I have just been given a hairy request from a client and need to > guidance to what would be the best method of doing this. > > The site is a heavily customised drupal 4.6 which is running the > organic groups. Organic groups is using the node access table already, > which causes a conflict with the node_priv_by_role module. > > But what they want I think maybe able to be done via something else, but > I am not sure what. > > Basically they want is for anonymous users to only access a few bits of > content, and nothing else, where as authenticated users will see > everything there, which hasn't been restricted by organic groups. > > Any ideas will be much appreciated. > Gordon. B?r -- | B?r Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20051128/d16e2751/attachment.pgp From dries.buytaert at gmail.com Mon Nov 28 08:37:45 2005 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Mon Nov 28 08:37:46 2005 Subject: [development] Performance: Drupal 4.6 vs Drupal 4.7 Message-ID: <5795E769-ED7C-4546-9DEB-163889EA5972@buytaert.net> Add your comments, suggestions or benchmark results to http:// drupal.org/node/38738. -- Dries Buytaert :: http://www.buytaert.net/ From dries.buytaert at gmail.com Mon Nov 28 09:33:33 2005 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Mon Nov 28 09:33:33 2005 Subject: [development] coordinators Message-ID: Hello world, I made the following changes to MAINTAINERS.txt 1. I added Gerhard as the translations coordinator. 2. I added Karoly as the security coordinator. 3. I added Charlie as the documentation coordinator. -- Dries Buytaert :: http://www.buytaert.net/ From gordon at heydon.com.au Mon Nov 28 11:01:48 2005 From: gordon at heydon.com.au (Gordon Heydon) Date: Mon Nov 28 11:01:41 2005 Subject: [development] node access issue In-Reply-To: <200511280900.52107.ber@webschuur.com> References: <1133144336.8260.14.camel@localhost.localdomain> <200511280900.52107.ber@webschuur.com> Message-ID: <1133175708.7305.23.camel@localhost.localdomain> Hi, Thanks for this, this seems like a fairly simple option that may work fairly well, and meet the requirements. Thanks Gordon. On Mon, 2005-11-28 at 09:00 +0100, B?r Kessels wrote: > Its a hairy issue, because Drupal, for example, indexes the whole node in > search. > > Wozever, your best shot would be to use nodeapi _load and there replace > $node->body with something else., when $user->uid == 0 . > > B?r > > > Op maandag 28 november 2005 03:18, schreef Gordon Heydon: > > Hi, > > > > I have just been given a hairy request from a client and need to > > guidance to what would be the best method of doing this. > > > > The site is a heavily customised drupal 4.6 which is running the > > organic groups. Organic groups is using the node access table already, > > which causes a conflict with the node_priv_by_role module. > > > > But what they want I think maybe able to be done via something else, but > > I am not sure what. > > > > Basically they want is for anonymous users to only access a few bits of > > content, and nothing else, where as authenticated users will see > > everything there, which hasn't been restricted by organic groups. > > > > Any ideas will be much appreciated. > > Gordon. > B?r From justin at buddyping.com Mon Nov 28 12:09:25 2005 From: justin at buddyping.com (Justin Davies) Date: Mon Nov 28 12:09:11 2005 Subject: [development] User module and redirection Message-ID: <4B50D85B-21CD-4D77-99C8-7FA26C7E0B65@buddyping.com> Hi all, Sorry to post this to here, but I am not sure if I found a bug or a "feature. I need to redirect my users to a landing page (drupal url: land), and I hacked around with user.module to make this happen. I started with the login block, and when I changed the form call to: $output = form($output, 'post', url('user/login?destination=land')); ...it seems to work on every page apart from node (i.e. the front page). Any ideas why this would happen ? I have had a few issues with the user module in that it is not very customisable from an end admin's point of view, and any changes (e.g. redirect to a page on login, and adding user picture upload during registration) have to be done in code. If no-one minds, I would like to make it a bit more customisable for admin's as I think the user module holds so much of the user functionality for Drupal, it stops an admin from customising the Drupal experience for users. Let me know, Justin -- t: CEO/CTO buddyPing e: justin@buddyping.com m: 07833 530876 From justin at buddyping.com Mon Nov 28 13:47:12 2005 From: justin at buddyping.com (Justin Davies) Date: Mon Nov 28 13:46:59 2005 Subject: [development] Update on redirect after login Message-ID: <0628F94D-0CB4-46FE-8980-998C2E1AFA37@buddyping.com> Ok, this gets weirder. It looks like the redirect after login regardless of the page you are on when you login works flawlessly on Firefox (OSX), but doesn't work on Safari v2. J From jchaffer at structureinteractive.com Mon Nov 28 14:32:07 2005 From: jchaffer at structureinteractive.com (Jonathan Chaffer) Date: Mon Nov 28 14:32:11 2005 Subject: [development] menu maintainer In-Reply-To: <45236F57-112D-4FA4-AC7A-27E61822EE91@buytaert.net> References: <45236F57-112D-4FA4-AC7A-27E61822EE91@buytaert.net> Message-ID: <6E3A9463-372D-4E19-8A66-58C8A5AA7A4A@structureinteractive.com> On Nov 27, 2005, at 4:07 AM, Dries Buytaert wrote: > FYI, I asked Richard Archer to be the new menu system maintainer > and he agreed. I updated MAINTAINER.txt and http://drupal.org/node/ > 34439 accordingly. Thanks for stepping up, Richard. Time constraints have obviously been getting in my way. I'm still happy to consult on menu-related issues as they come along. -- Jonathan Chaffer Algorithm Alchemist, Structure Interactive (616) 364-7423 http://www.structureinteractive.com/ From tom.willis at gmail.com Mon Nov 28 14:44:20 2005 From: tom.willis at gmail.com (Thomas G. Willis) Date: Mon Nov 28 14:44:23 2005 Subject: [development] module dev. mysql like operator problem. Message-ID: I apologize if this isn't the right list. didn't know if this would be support necessarily since it's a custom module. I'm at a loss as to whether this is a bug or whether I'm just trying to do something I'm not supposed to. I can't get a query working using the like operator in drupal. the same sql runs fine in in phpmyadmin. not like will return results though weird. any ideas? function _db_getartistlist($filter=''){ //Example $filter='A%'; /filter not working yet ??/ /doesn't work/ / if($filter!=''){ return db_query('select distinct artist from {mp3col_data} where artist like \'' .$filter . '\' order by artist'); //return db_query('select distinct artist from {mp3col_data} where artist like \'%s\' order by artist',$filter); }else{ return db_query('select distinct artist from {mp3col_data} order by artist'); } / /works/ return db_query('select distinct artist from {mp3col_data} order by artist'); } -- Thomas G. Willis ----------------------------------------------- http://i-see-sound.com http://tomwillis.sonicdiscord.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051128/57d1c302/attachment.htm From justin at buddyping.com Mon Nov 28 15:17:44 2005 From: justin at buddyping.com (Justin Davies) Date: Mon Nov 28 15:17:30 2005 Subject: [development] module dev. mysql like operator problem. In-Reply-To: References: Message-ID: Thomas, Not a huge amount of help, but may give you some pointers: Get the devel module and turn on query output. You will be able to see exactly what is being sent to the database. The other thing is that db_query might* be escaping the % character so it will never return a result unless you have an artist starting with A%. Justin -- t: CEO/CTO buddyPing e: justin@buddyping.com m: 07833 530876 On 28 Nov 2005, at 14:44, Thomas G. Willis wrote: > I apologize if this isn't the right list. didn't know if this would > be support necessarily since it's a custom module. > > I'm at a loss as to whether this is a bug or whether I'm just > trying to do something I'm not supposed to. > I can't get a query working using the like operator in drupal. the > same sql runs fine in in phpmyadmin. > > not like will return results though weird. any ideas? > > function _db_getartistlist($filter=''){ > //Example $filter='A%'; > /filter not working yet ??/ > > /doesn't work/ > /* > if($filter!=''){ > return db_query('select distinct artist from {mp3col_data} > where artist like \'' .$filter . '\' order by artist'); > > //return db_query('select distinct artist from {mp3col_data} > where artist like \'%s\' order by artist',$filter); > > }else{ > return db_query('select distinct artist from {mp3col_data} > order by artist'); > > } > / > > /works/ > return db_query('select distinct artist from {mp3col_data} order > by artist'); > } > > > -- > Thomas G. Willis > ----------------------------------------------- > http://i-see-sound.com > http://tomwillis.sonicdiscord.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051128/f7ad3a10/attachment.htm From tom.willis at gmail.com Mon Nov 28 15:24:50 2005 From: tom.willis at gmail.com (Thomas G. Willis) Date: Mon Nov 28 15:24:54 2005 Subject: [development] module dev. mysql like operator problem. In-Reply-To: References: Message-ID: I bet it's escaping the percent sign. anyone know of a way to control that? I'm doing this on the cvs version forgot to mention that? On 11/28/05, Justin Davies wrote: > > Thomas, > Not a huge amount of help, but may give you some pointers: > > Get the devel module and turn on query output. You will be able to see > exactly what is being sent to the database. > > The other thing is that db_query might* be escaping the % character so it > will never return a result unless you have an artist starting with A%. > Justin > -- > t: CEO/CTO buddyPing > e: justin@buddyping.com > m: 07833 530876 > > > On 28 Nov 2005, at 14:44, Thomas G. Willis wrote: > > I apologize if this isn't the right list. didn't know if this would be > support necessarily since it's a custom module. > > I'm at a loss as to whether this is a bug or whether I'm just trying to do > something I'm not supposed to. > I can't get a query working using the like operator in drupal. the same > sql runs fine in in phpmyadmin. > > not like will return results though weird. any ideas? > > > function _db_getartistlist($filter=''){ > //Example $filter='A%'; > /filter not working yet ??/ > > /doesn't work/ > /* > if($filter!=''){ > return db_query('select distinct artist from {mp3col_data} where artist like \'' .$filter . '\' order by artist'); > > //return db_query('select distinct artist from {mp3col_data} where artist like \'%s\' order by artist',$filter); > > }else{ > return db_query('select distinct artist from {mp3col_data} order by artist'); > > } > / > > /works/ > return db_query('select distinct artist from {mp3col_data} order by artist'); > } > > > > -- > Thomas G. Willis > ----------------------------------------------- > http://i-see-sound.com > http://tomwillis.sonicdiscord.com > > > > -- Thomas G. Willis ----------------------------------------------- http://i-see-sound.com http://tomwillis.sonicdiscord.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051128/c8b51a76/attachment.htm From karoly at negyesi.net Mon Nov 28 15:33:46 2005 From: karoly at negyesi.net (Karoly Negyesi) Date: Mon Nov 28 15:28:29 2005 Subject: [development] module dev. mysql like operator problem. In-Reply-To: References: Message-ID: On Mon, 28 Nov 2005 16:24:50 +0100, Thomas G. Willis wrote: > I bet it's escaping the percent sign. anyone know of a way to control > that? two percent signs instead of one. From justin at buddyping.com Mon Nov 28 15:31:09 2005 From: justin at buddyping.com (Justin Davies) Date: Mon Nov 28 15:31:01 2005 Subject: [development] module dev. mysql like operator problem. In-Reply-To: References: Message-ID: Thomas, Just occurred to me, try %% instead. Justin -- t: CEO/CTO buddyPing e: justin@buddyping.com m: 07833 530876 On 28 Nov 2005, at 15:24, Thomas G. Willis wrote: > I bet it's escaping the percent sign. anyone know of a way to > control that? > > I'm doing this on the cvs version forgot to mention that? > > > On 11/28/05, Justin Davies wrote: > Thomas, > > Not a huge amount of help, but may give you some pointers: > > Get the devel module and turn on query output. You will be able to > see exactly what is being sent to the database. > > The other thing is that db_query might* be escaping the % > character so it will never return a result unless you have an > artist starting with A%. > Justin > -- > t: CEO/CTO buddyPing > e: justin@buddyping.com > m: 07833 530876 > > > On 28 Nov 2005, at 14:44, Thomas G. Willis wrote: > >> I apologize if this isn't the right list. didn't know if this >> would be support necessarily since it's a custom module. >> >> I'm at a loss as to whether this is a bug or whether I'm just >> trying to do something I'm not supposed to. >> I can't get a query working using the like operator in drupal. the >> same sql runs fine in in phpmyadmin. >> >> not like will return results though weird. any ideas? >> >> function _db_getartistlist($filter=''){ >> //Example $filter='A%'; >> /filter not working yet ??/ >> >> /doesn't work/ >> /* >> if($filter!=''){ >> >> return db_query('select distinct artist from {mp3col_data} >> where artist like \'' .$filter . '\' order by artist'); >> >> //return db_query('select distinct artist from {mp3col_data} >> where artist like \'%s\' order by artist',$filter); >> >> >> }else{ >> return db_query('select distinct artist from {mp3col_data} >> order by artist'); >> >> } >> / >> >> /works/ >> return db_query('select distinct artist from {mp3col_data} >> order by artist'); >> >> } >> >> >> -- >> Thomas G. Willis >> ----------------------------------------------- >> http://i-see-sound.com >> http://tomwillis.sonicdiscord.com >> >> > > > > > -- > Thomas G. Willis > ----------------------------------------------- > http://i-see-sound.com > http://tomwillis.sonicdiscord.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051128/4112c492/attachment-0001.htm From tom.willis at gmail.com Mon Nov 28 15:39:23 2005 From: tom.willis at gmail.com (Thomas G. Willis) Date: Mon Nov 28 15:39:26 2005 Subject: [development] module dev. mysql like operator problem. In-Reply-To: References: Message-ID: Thanks Karoly and Justin. I'll try that when I get home. it will probably work I know \% and \\% does not. hadn't trie %% yet. On 11/28/05, Justin Davies wrote: > > Thomas, > Just occurred to me, try %% instead. > > Justin > -- > t: CEO/CTO buddyPing > e: justin@buddyping.com > m: 07833 530876 > > > On 28 Nov 2005, at 15:24, Thomas G. Willis wrote: > > I bet it's escaping the percent sign. anyone know of a way to control > that? > > I'm doing this on the cvs version forgot to mention that? > > > On 11/28/05, Justin Davies wrote: > > > > Thomas, > > Not a huge amount of help, but may give you some pointers: > > > > Get the devel module and turn on query output. You will be able to see > > exactly what is being sent to the database. > > > > The other thing is that db_query might* be escaping the % character so > > it will never return a result unless you have an artist starting with A%. > > > Justin > > -- > > t: CEO/CTO buddyPing > > e: justin@buddyping.com > > m: 07833 530876 > > > > > > On 28 Nov 2005, at 14:44, Thomas G. Willis wrote: > > > > I apologize if this isn't the right list. didn't know if this would be > > support necessarily since it's a custom module. > > > > I'm at a loss as to whether this is a bug or whether I'm just trying to > > do something I'm not supposed to. > > I can't get a query working using the like operator in drupal. the same > > sql runs fine in in phpmyadmin. > > > > not like will return results though weird. any ideas? > > > > > > function _db_getartistlist($filter=''){ > > //Example $filter='A%'; > > /filter not working yet ??/ > > > > /doesn't work/ > > /* > > if($filter!=''){ > > > > return db_query('select distinct artist from {mp3col_data} where artist like \'' .$filter . '\' order by artist'); > > > > //return db_query('select distinct artist from {mp3col_data} where artist like \'%s\' order by artist',$filter); > > > > > > }else{ > > return db_query('select distinct artist from {mp3col_data} order by artist'); > > > > } > > / > > > > /works/ > > return db_query('select distinct artist from {mp3col_data} order by artist'); > > > > } > > > > > > > > -- > > Thomas G. Willis > > ----------------------------------------------- > > http://i-see-sound.com > > http://tomwillis.sonicdiscord.com > > > > > > > > > > > -- > Thomas G. Willis > ----------------------------------------------- > http://i-see-sound.com > http://tomwillis.sonicdiscord.com > > > > -- Thomas G. Willis ----------------------------------------------- http://i-see-sound.com http://tomwillis.sonicdiscord.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051128/48431c36/attachment.htm From steven at acko.net Mon Nov 28 17:11:12 2005 From: steven at acko.net (Steven Wittens) Date: Mon Nov 28 17:11:15 2005 Subject: [development] Re: [drupal:dries] /includes menu.inc In-Reply-To: <20051128154504.8263.qmail@zind.net> References: <20051128154504.8263.qmail@zind.net> Message-ID: <438B3A30.3080304@acko.net> drupal-devel@drupal.org schreef: >User: dries Branch: HEAD Date: Mon, 28 Nov 2005 15:45:04 +0000 > >Modified files: > /includes menu.inc > >Log message: > - Patch #11758 by Richard Archer: fixed mbstring clash. > >Links: > http://cvs.drupal.org/diff.php?path=drupal/includes/menu.inc&old=1.90&new=1.91 > > > Deze patch heeft echt geen zin op head: mbstring met function overloading wordt niet ondersteund (en er is een expliciete check voor, in unicode.inc). Voor 4.6.x is die check er nog niet, maar mbstring function overloading leidt sowieso tot subtiele bugs (vb in truncate_utf8) zodat het zeker niet aan te raden is. Ik vind het nog steeds cruft. Steven From steven at acko.net Mon Nov 28 17:11:49 2005 From: steven at acko.net (Steven Wittens) Date: Mon Nov 28 17:11:52 2005 Subject: [development] Re: [drupal:dries] /includes menu.inc In-Reply-To: <438B3A30.3080304@acko.net> References: <20051128154504.8263.qmail@zind.net> <438B3A30.3080304@acko.net> Message-ID: <438B3A55.1020200@acko.net> Sorry everyone, this was meant for Dries only ;) Steven From mfredrickson at ppmns.org Mon Nov 28 18:40:02 2005 From: mfredrickson at ppmns.org (Mark Fredrickson) Date: Mon Nov 28 18:40:05 2005 Subject: [bayes][bcc][faked-from] Re: [development] node access issue In-Reply-To: <1133175708.7305.23.camel@localhost.localdomain> Message-ID: I was thinking about og for a project that I'm working on, with a similar goal: organic groups for users but high privacy restriction for non-users. A more elegant solution might be to automatically subscribe all users to an "authenticated" organic group. All default content would be assigned to the "authenticated" group, providing the same sort of privacy node_perm could provide. I haven't gone so far as to looking at implementing this, but if it something you would like to collaborate on, I would be eager to work with you. Cheers, Mark Fredrickson E-Advocacy Manager Planned Parenthood Minnesota, North Dakota, South Dakota 1200 Lagoon Ave. Minneapolis, MN 55408 Ph: 612.821.6154 Fax: 612.825.3522 Email: mfredrickson@ppmns.org Are you a member of the Action Network? http://www.ppaction.org/ppmsd/join.tcl > From: Gordon Heydon > Reply-To: > Date: Mon, 28 Nov 2005 22:01:48 +1100 > To: > Subject: [bayes][bcc][faked-from] Re: [development] node access issue > > Hi, > > Thanks for this, this seems like a fairly simple option that may work > fairly well, and meet the requirements. > > Thanks > Gordon. > > On Mon, 2005-11-28 at 09:00 +0100, B?r Kessels wrote: >> Its a hairy issue, because Drupal, for example, indexes the whole node in >> search. >> >> Wozever, your best shot would be to use nodeapi _load and there replace >> $node->body with something else., when $user->uid == 0 . >> >> B?r From dopry at thing.net Mon Nov 28 20:11:06 2005 From: dopry at thing.net (Darrel O'Pry) Date: Mon Nov 28 20:11:12 2005 Subject: [development] creating forward compatable modules? In-Reply-To: References: <4384CD0F.7060401@citris-uc.org> <200511232324.44102.ber@webschuur.com> <4384EF68.6020202@citris-uc.org> <200511241012.50430.ber@webschuur.com> Message-ID: <1133208666.8879.77.camel@localhost.localdomain> On Thu, 2005-11-24 at 10:19 +0100, Dries Buytaert wrote: > > When one site was very active, I saw the same issues / problems > > then when > > several sites had slightly higher load. > > I don't agree with Ber's conclusion. Ber, what test methodology did > you use to draw that conclusion? > > Because each site has its own cache, multiple sites should scale > better than one big site. No? > > -- > Dries Buytaert :: http://www.buytaert.net/ > > I think that may somewhat depend on mysql's query cache as well in a mysql environment... Ber's notation of 1 site w/1000 visitor vs 100 sites with 100 visitors(10K users total) seems to be inline with the idea that many small sites scale better than 1 large site. .darrel. From mfredrickson at ppmns.org Mon Nov 28 20:13:18 2005 From: mfredrickson at ppmns.org (Mark Fredrickson) Date: Mon Nov 28 20:13:20 2005 Subject: [development] Theme('confirm'...) in 4.7? Message-ID: Hi- It seems theme('confirm'...) has disappeared in HEAD. I assume this is meant to be replaced with a form. An easy enough change, but I just thought I would confirm before I go too far down that road. There is no mention at: http://drupal.org/node/22218 Mark Fredrickson E-Advocacy Manager Planned Parenthood Minnesota, North Dakota, South Dakota 1200 Lagoon Ave. Minneapolis, MN 55408 Ph: 612.821.6154 Fax: 612.825.3522 Email: mfredrickson@ppmns.org Are you a member of the Action Network? http://www.ppaction.org/ppmsd/join.tcl From dopry at thing.net Mon Nov 28 20:19:27 2005 From: dopry at thing.net (Darrel O'Pry) Date: Mon Nov 28 20:19:31 2005 Subject: [development] bzr mirror of Drupal HEAD In-Reply-To: <1132810197.23257.133.camel@localhost.localdomain> References: <1132810197.23257.133.camel@localhost.localdomain> Message-ID: <1133209167.8879.81.camel@localhost.localdomain> On Thu, 2005-11-24 at 16:29 +1100, Gordon Heydon wrote: > I do not like the fact that we have to be running on such a new release > of bzr. I am running Ubuntu Breezy and I had to download from source. I > couldn't get this from the ubuntu distribution. You can grab the .deb out of the dapper repository as well. From dries.knapen at versateladsl.be Mon Nov 28 20:26:19 2005 From: dries.knapen at versateladsl.be (Dries Knapen) Date: Mon Nov 28 20:26:26 2005 Subject: [development] Theme('confirm'...) in 4.7? In-Reply-To: References: Message-ID: > It seems theme('confirm'...) has disappeared in HEAD. I assume this > is meant > to be replaced with a form. An easy enough change, but I just > thought I > would confirm before I go too far down that road. This is now done by confirm_form() http://drupaldocs.org/api/head/function/confirm_form There are several examples of how to use this function in core (comment.module, node.module, menu.module, taxonomy.module, ...) Maybe this should be mentioned in the documentation somewhere? From mfredrickson at ppmns.org Mon Nov 28 20:32:02 2005 From: mfredrickson at ppmns.org (Mark Fredrickson) Date: Mon Nov 28 20:32:05 2005 Subject: [bcc][faked-from] Re: [development] Theme('confirm'...) in 4.7? In-Reply-To: Message-ID: It should. I note that it is not in the API reference under form generation, nor in "upgrading your modules," nor in the form API quickstart doc: http://drupaldocs.org/api/head/group/form http://drupal.org/node/22218 http://drupaldocs.org/api/head/file/contributions/docs/developer/topics/form s_api.html I dropped a comment into the upgrading page. Cheers, Mark Fredrickson E-Advocacy Manager Planned Parenthood Minnesota, North Dakota, South Dakota 1200 Lagoon Ave. Minneapolis, MN 55408 Ph: 612.821.6154 Fax: 612.825.3522 Email: mfredrickson@ppmns.org Are you a member of the Action Network? http://www.ppaction.org/ppmsd/join.tcl > From: Dries Knapen > Reply-To: > Date: Mon, 28 Nov 2005 21:26:19 +0100 > To: > Subject: [bcc][faked-from] Re: [development] Theme('confirm'...) in 4.7? > >> It seems theme('confirm'...) has disappeared in HEAD. I assume this >> is meant >> to be replaced with a form. An easy enough change, but I just >> thought I >> would confirm before I go too far down that road. > > This is now done by confirm_form() > http://drupaldocs.org/api/head/function/confirm_form > > There are several examples of how to use this function in core > (comment.module, node.module, menu.module, taxonomy.module, ...) > > Maybe this should be mentioned in the documentation somewhere? > From dopry at thing.net Mon Nov 28 22:18:33 2005 From: dopry at thing.net (Darrel O'Pry) Date: Mon Nov 28 22:18:46 2005 Subject: [development] A core commit without community involvement... In-Reply-To: <4388D243.9060602@disobey.com> References: <4388D243.9060602@disobey.com> Message-ID: <1133216313.8879.125.camel@localhost.localdomain> On Sat, 2005-11-26 at 16:23 -0500, Morbus Iff wrote: > I just wanted to get the community's* opinion on the following Issue, > which arose when a change made it into core WITHOUT a formal Issue, > Patch, Comment, Commit workflow: > > http://drupal.org/node/38841 > > I, and others, think it's a step backwards. > Would others care to comment? > I'm not very aware of the workflow, but this topic has me thinking about a problem that came up a few weeks ago regarding secure user login. The issue was switching protocol between http and https. Offhand user.module and ecommerce.module could take advantage of that functionality in core. I proposed adding an SSL flag to url/l, but that seemed to meet with some resistance... Since both issues involve drupal's existing $base_url and how its handled... I was interested in knowing if my time would be wasted by try to push a patch that changes settings.php to use a format like... this could be put in settings.php $url['base'] = $base_url $url['ssl'] = https://www.example.com/ $url['ecommerce_ssl'] = https://sharedssl.example.com/example.com/ bootstrap.inc + $url_name = (isset($_SESSION['default_url'])) ? ' $_SESSION['default_url'] : 'base'; +url_set_active($url_name); .................................................................... The in common.inc add function url_set_active($url_name = 'base') { global $active_url if (array_key_exists($url[$url_name]) { $active_url = $url[$urlname]; } else { //maybe some sort of error instead. //but this should at least keep things functioning. $active_url = $url['base']; } } .... and for function url(...) - global $base_url + global $active_url - $base = ($absolute ? $base_url .'/' : ''); + $base = ($absolute ? $active_url .'/' : ''); ..................................................................... I can roll the idea as a patch against whatever if it seems like something that would fit in core. It would give module developers a familiar method for switching base_urls(see db_set_active), will not change any existing api function calls, can be made backwards compatible to hide it from end users. I also think its performance impact is minimal with only a few assignments and smidgeon of memory for a few more globals. With an option to store the url array key in the session it enables users the option to switch their browsing context between http and https.... any suggestions are welcome. From starbow at citris-uc.org Tue Nov 29 19:32:22 2005 From: starbow at citris-uc.org (Tao Starbow) Date: Tue Nov 29 19:29:59 2005 Subject: [development] creating forward compatable modules? In-Reply-To: <6C6A7B4C-74B2-411E-84BC-EE8BB41055B1@buytaert.net> References: <4384CD0F.7060401@citris-uc.org> <4384D6E8.8020905@drob.org> <4384E269.5060001@citris-uc.org> <6C6A7B4C-74B2-411E-84BC-EE8BB41055B1@buytaert.net> Message-ID: <438CACC6.7020803@citris-uc.org> Thanks for both the information and the encouragement! I have a cvs head version for my own testing, but I think I am going to stick with 4.6 for what we are rolling out to others. I am happy to contribute as I learn. I am moving my development notes off of our internal wiki and on to a public blog at http://www.citris-uc.org/blog/1, if anyone wants to keep up with my trials and tribulations. cheers, -tao Dries Buytaert wrote: > On 23 Nov 2005, at 22:43, Tao Starbow wrote: > >> Good point. Right now our infrastructure consists of a single dell >> poweredge (3GHz Xeno, 2GB ram, 70 GB scsi raid), running FreeBSD. >> We can pretty much dedicate this box to serving Drupal (apache and >> mysql on the same box). We are using the engineering department's >> network, so I am not worried about running out of bandwidth. > > > Looks like that machine should be able to host quite a few Drupal > sites; I'm thinking 250 sites should be possible, but it obviously > depends on a number of parameters as mentioned elsewhere in this > thread. Fact is that many small sites scale better than one really > big site; because each site is actually fairly small and reasonably > static, Drupal's page caching mechanism should be very effective. > (I'm somewhat puzzled by Ber's numbers and would like to know more > about why he thinks otherwise.) > > Creating "forward compatible modules" does not look like a practical > option. It's better to stick with Drupal 4.6 and to upgrade to > Drupal 4.7 when the time is right. Upgrading to Drupal 4.7 > (including custom modules) should be relatively straightforward but > might take a bit of time depending on the amount of custom changes > and custom modules. One thing you can do is start off with > PHPTemplate-based themes rather than XTemplate-based themes; > PHPTemplate will be the default theme engine in Drupal 4.7. > > If you are somewhat adventurous you could start out with Drupal CVS > HEAD (the forthcoming Drupal 4.7); it shouldn't be too bad if you > stick with core modules. A good formula for success is to > participate in the development of Drupal; you'll quickly learn the > ins and outs and will be able to weight decisions much more efficiently. > > Tao, some of us (including myself) are very interested in improving > Drupal's multi-site features. It is inevitable that you'll run into > some gotchas so I'm hoping you'll participate in the development of > said feature. (Eg. Adrian has been working on a patch to lock or > restrict certain settings.) So welcome on board, and looking forward > to your contributions. ;) > > -- > Dries Buytaert :: http://www.buytaert.net/ > From john at userfrenzy.com Tue Nov 29 20:25:25 2005 From: john at userfrenzy.com (John Handelaar) Date: Tue Nov 29 20:25:36 2005 Subject: [development] Tip for large site scaling: tracker.module considered harmful Message-ID: <438CB935.7030305@userfrenzy.com> First off, apols for the 'considered harmful' clich?. Description: http://mbr.org Forum posts: 8576, with 63015 comments 1. Some tracker module queries, particularly the one which shows 'all my posts' to individual users, stop functioning on large data sets. In this case, queries ran for >600s 2. An INSERT/UPDATE on {comments} while those queries are trying to complete will be stalled, waiting for a full-table lock (MySQL + MyISAM). 3. While there is an INSERT/UPDATE waiting to execute, all other SELECTS on the same table are frozen and marked as 'Locked' in MySQL's process list until 1) and 2) are complete. Add 100 logged-in users, simmer for about 3 minutes -> MySQL server drops dead with 'Too many connections' (whether using mysql_pconnect() or not). Workaround: under no circumstances enable tracker.module on a heavily-used site which gives posting rights to visitors. There is, of course, a fix out there waiting to be written in either the query or the schema, but while I'm OK with adding indexes to tables, multi-table indexing is outside my comfort zone. [cross-posted to tracker: http://drupal.org/node/39351 ] The good news: disabling the tracker has reverted server load back down to 0.1 - 0.3 (from >30.00) and MBR is once again serving about 60,000 pages per day without complaint. Serious request for Infrastructure people: this sort of thing doesn't affect many of us, but it kills us when bad things happen. I'm not the first person to ask --- can we please have a "Scaling / Large site issues" forum on Drupal.org to collect war stories? jh From deekayen at deekayen.net Tue Nov 29 20:43:40 2005 From: deekayen at deekayen.net (David K Norman) Date: Tue Nov 29 20:43:44 2005 Subject: [development] 404 search Message-ID: <438CBD7C.2030603@deekayen.net> I just wanted to make sure this wasn't implemented before I submitted an official feature request issue. Sometimes I remove an attachment from a node, but Google still keeps it indexed for a while. I can see people still trying to access the file in my logs, but they get a 404. I think it would be cool if the 404 message was able to say "Page not found", but then use the missing URL as a search string to display other possible similar pages in the site under the Page not found message. David Norman http://deekayen.net/ From boris at bryght.com Tue Nov 29 20:46:56 2005 From: boris at bryght.com (Boris Mann) Date: Tue Nov 29 20:47:04 2005 Subject: [development] 404 search In-Reply-To: <438CBD7C.2030603@deekayen.net> References: <438CBD7C.2030603@deekayen.net> Message-ID: <4442EEC7-959E-4F67-9F03-A183AA6F4724@bryght.com> On 29-Nov-05, at 12:43 PM, David K Norman wrote: > I just wanted to make sure this wasn't implemented before I > submitted an > official feature request issue. > > Sometimes I remove an attachment from a node, but Google still > keeps it > indexed for a while. I can see people still trying to access the > file in > my logs, but they get a 404. I think it would be cool if the 404 > message > was able to say "Page not found", but then use the missing URL as a > search string to display other possible similar pages in the site > under > the Page not found message. See http://dev.bryght.com/t/wiki/CustomPageNotFoundSearchPage Steven has this in his sandbox or somewhere, I believe...called i404.module? -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com From adrian at bryght.com Tue Nov 29 21:59:17 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Tue Nov 29 21:59:33 2005 Subject: [development] DEP - cascading variable system Message-ID: This is my first attempt at writing something like this, to me it's not as much about creating a useful DEP out of this, as it is getting a working format going. I apologise for having left this so long, it's been in my drafts for week now. I am just sending the incomplete document to see where we can go from. If you have any other suggestions, please make them. I'd like to keep the format as simple as possible. Title : Cascading variable system. Abstract: This DEP defines a method to allow for more flexibility in the way we handle variables. Author: Adrian Rossouw Dependencies: None Repository: Core Status: Suggestion? 1. Introduction : This DEP specifies a way to clear up and centralise the variable system in Drupal, and hopefully abstracts some code that we are often using for specific cases. 2. Motivation : Variables in Drupal ( records in the variable table ), are primarily used to store settings for the site. Frequently however, we have the need to override the specified variable. Two such cases are a. variables that can be overridden for each user (the theme setting, for instance) b. variables that can be overridden for each theme (such as whether or not to display the site title). This is done to allow us to specify defaults for the site, and then allow these defaults to be altered. In the case of (a.), we manually test for the overridden value with each occurence of the variable, and in the case of (b.) we have centralised all the theme variable changes by introducing the theme_get_variable() function. This has the benefit of allowing us to define even more layers of variables, such as .. blog specific settings, node specific settings, locale specific settings (allowing us to localise the variables like site_name etc.) and even install specific settings (so install profiles can provide default values for the system). Additionally, it allows host administrators to specify system wide overrides. variables that an administrator can define as non-changeable (the files path, for instance) 3. Approach : This DEP proposes that we add 2 columns to the variable table, namely 'domain' and 'key'. This extra information would be used to store data against a certain object. In the case of the user system saving variables, it would save the variable with 'user' as the domain and $user->uid as the key. In the case of themes, it would save the variable with 'theme' as the domain and the theme name as the key. By default, only the system wide settings would be loaded, and then each module that wants to add a new layer to the variable stack, can add it's own layer of settings. (ie: user module will load all the settings related to the user). The only variables that will actually be overridden are variables that an explicit interface element is defined for, and the only variables that will be saved are the ones that differ from the original variables. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com From kb at 2bits.com Tue Nov 29 22:22:17 2005 From: kb at 2bits.com (Khalid B) Date: Tue Nov 29 22:22:19 2005 Subject: [development] 404 search In-Reply-To: <438CBD7C.2030603@deekayen.net> References: <438CBD7C.2030603@deekayen.net> Message-ID: <4a9fdc630511291422v9152458l1da65c6725a8eaa0@mail.gmail.com> Here is another variant by someone else (also based on Steven's). http://www.settingtheworldtorights.com/files/drupal/ii404-4.6.tar.gz On a small site this may be acceptable. However for a large site I would think twice, since reorganizing content can cause a lot of 404s. There are even cases where 404s from missing images, or confused crawlers, relative pathnames, RSS readers, ... etc such as this issue: http://drupal.org/node/13148 So, a search will be performed for all 404s, whether human generation or not. On 11/29/05, David K Norman wrote: > I just wanted to make sure this wasn't implemented before I submitted an > official feature request issue. > > Sometimes I remove an attachment from a node, but Google still keeps it > indexed for a while. I can see people still trying to access the file in > my logs, but they get a 404. I think it would be cool if the 404 message > was able to say "Page not found", but then use the missing URL as a > search string to display other possible similar pages in the site under > the Page not found message. > > David Norman > http://deekayen.net/ > From kb at 2bits.com Tue Nov 29 22:45:00 2005 From: kb at 2bits.com (Khalid B) Date: Tue Nov 29 22:45:02 2005 Subject: [development] Tip for large site scaling: tracker.module considered harmful In-Reply-To: <438CB935.7030305@userfrenzy.com> References: <438CB935.7030305@userfrenzy.com> Message-ID: <4a9fdc630511291445u5b3b5c90u6bb0fc5e628a5b52@mail.gmail.com> Seems like your site should move to a more modern ACID table database, for example switching from MyISAM to Inno should help, since it provides row level locking. In conjunction with this, a few changes to the db layer will be needed (e.g. locking the whole table should not be done). On 11/29/05, John Handelaar wrote: > > First off, apols for the 'considered harmful' clich?. > > Description: http://mbr.org > Forum posts: 8576, with 63015 comments > > > > 1. Some tracker module queries, particularly the one which > shows 'all my posts' to individual users, stop functioning > on large data sets. In this case, queries ran for >600s > > 2. An INSERT/UPDATE on {comments} while those queries are > trying to complete will be stalled, waiting for a full-table > lock (MySQL + MyISAM). > > 3. While there is an INSERT/UPDATE waiting to execute, all > other SELECTS on the same table are frozen and marked as > 'Locked' in MySQL's process list until 1) and 2) are complete. > > > Add 100 logged-in users, simmer for about 3 minutes -> MySQL server > drops dead with 'Too many connections' (whether using mysql_pconnect() > or not). > > Workaround: under no circumstances enable tracker.module on a > heavily-used site which gives posting rights to visitors. > > There is, of course, a fix out there waiting to be written in either > the query or the schema, but while I'm OK with adding indexes to > tables, multi-table indexing is outside my comfort zone. > > [cross-posted to tracker: http://drupal.org/node/39351 ] > > > The good news: disabling the tracker has reverted server load > back down to 0.1 - 0.3 (from >30.00) and MBR is once again serving > about 60,000 pages per day without complaint. > > > Serious request for Infrastructure people: this sort of thing doesn't > affect many of us, but it kills us when bad things happen. I'm not > the first person to ask --- can we please have a "Scaling / Large site > issues" forum on Drupal.org to collect war stories? > > > > jh > > From axel at kollmorgen.net Tue Nov 29 23:24:55 2005 From: axel at kollmorgen.net (Axel Kollmorgen) Date: Tue Nov 29 23:29:17 2005 Subject: [development] Re: bzr battle plan In-Reply-To: References: Message-ID: On 24.11.2005 09:11, Adrian Rossouw wrote: > My major issue with BZR is source repository browsing. > > We need a central web based interface to browse the repository, and do > diffs and the like. > Applications like this exist for both svn and cvs, but not for bzr. http://google.com/search?q=bzrweb ? -- ax Il n'est de probl?me qu'une absence de solution ne sache r?soudre. QUEUILLE From zacker at skylinepublicworks.com Wed Nov 30 00:00:36 2005 From: zacker at skylinepublicworks.com (Zack Rosen) Date: Wed Nov 30 00:00:47 2005 Subject: [development] DEP - cascading variable system In-Reply-To: References: Message-ID: This is a very cool idea Adrian. I have a few questions... * Other than the theme_get_variable function is there other code this helps you abstract? * Do you got good ideas of use cases where different users want different settings variables? I definitely see the coolness of letting people have different configs for their blog / organic groups, but not quite getting the advantage of letting users configure the site to their own preference. * What in the heck is the user interface going to look like for managing different sets of settings? -Zack On Nov 29, 2005, at 1:59 PM, Adrian Rossouw wrote: > This is my first attempt at writing something like this, to me it's > not as much about creating a useful DEP out of this, as it is > getting a working format going. I apologise for having left this > so long, it's been in my drafts for week now. I am just sending > the incomplete document to see where we can go from. > > If you have any other suggestions, please make them. I'd like to > keep the format as simple as possible. > > Title : Cascading variable system. > Abstract: This DEP defines a method to allow for more flexibility > in the way we handle variables. > Author: Adrian Rossouw > Dependencies: None > Repository: Core > Status: Suggestion? > > 1. Introduction : > This DEP specifies a way to clear up and centralise the variable > system in Drupal, and hopefully abstracts some code that > we are often using for specific cases. > > 2. Motivation : > Variables in Drupal ( records in the variable table ), are > primarily used to store settings for the site. > Frequently however, we have the need to override the specified > variable. > > Two such cases are > a. variables that can be overridden for each user (the theme > setting, for instance) > b. variables that can be overridden for each theme (such as > whether or not to display the site title). > > This is done to allow us to specify defaults for the site, and then > allow these defaults to be altered. > In the case of (a.), we manually test for the overridden value with > each occurence of the variable, and > in the case of (b.) we have centralised all the theme variable > changes by introducing the theme_get_variable() > function. > > This has the benefit of allowing us to define even more layers of > variables, such as .. blog specific settings, > node specific settings, locale specific settings (allowing us to > localise the variables like site_name etc.) > and even install specific settings (so install profiles can provide > default values for the system). > Additionally, it allows host administrators to specify system wide > overrides. variables that an administrator > can define as non-changeable (the files path, for instance) > > 3. Approach : > This DEP proposes that we add 2 columns to the variable table, > namely 'domain' and 'key'. > > This extra information would be used to store data against a > certain object. In the case of the user system > saving variables, it would save the variable with 'user' as the > domain and $user->uid as the key. In the case > of themes, it would save the variable with 'theme' as the domain > and the theme name as the key. > > By default, only the system wide settings would be loaded, and then > each module that wants to add a new > layer to the variable stack, can add it's own layer of settings. > (ie: user module will load all the settings > related to the user). > > The only variables that will actually be overridden are variables > that an explicit interface element is defined > for, and the only variables that will be saved are the ones that > differ from the original variables. > > > > > -- > Adrian Rossouw > Drupal developer and Bryght Guy > http://drupal.org | http://bryght.com > > > From adrian at bryght.com Wed Nov 30 00:16:03 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Wed Nov 30 00:16:13 2005 Subject: [development] DEP - cascading variable system In-Reply-To: References: Message-ID: <587DFAD9-A583-4406-A849-D4339422C1E8@bryght.com> On 30 Nov 2005, at 2:00 AM, Zack Rosen wrote: > This is a very cool idea Adrian. I have a few questions... > > * Other than the theme_get_variable function is there other code > this helps you abstract? > * Do you got good ideas of use cases where different users want > different settings variables? I definitely see the coolness of > letting people have different configs for their blog / organic > groups, but not quite getting the advantage of letting users > configure the site to their own preference. We already do this for all user specific settings (like whether or not tinymce is enabled.) > * What in the heck is the user interface going to look like for > managing different sets of settings? (i'll add this to the bottom) User interface doesn't change, only the flexibility of where saved settings take effect is added. So instead of saving settings to the data column in the user table, or stuffing all of the theme specific settings in a single variable, we store them in a nice normalised table. You would set variables using function variable_set($variable, $value, $domain = null, $id = null) { and you would get variable using function variable_set($variable, $default, $domain = null, $id = null) { The code specified default would go to the bottom of the queue, followed by the defaults the install profile specified (install profiles need this. otherwise any default setting change involves changing code wherever it happens) followed by the system wide settings, followed by the layout/section/ theme specific settings (this is the next DEP I want to write) and then at the very top of the stacks, the system overrides (like when a hosting provider doesn't want people to touch the files dir) [5] $GLOBALS['override'] [4] user settings. system table, user domain, userid key. [3] theme settings. system table, theme domain, theme name key. [2] system settings. system table, system domain. [1] $GLOBALS['defaults'] [0] $default -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com From john at userfrenzy.com Wed Nov 30 01:22:48 2005 From: john at userfrenzy.com (John Handelaar) Date: Wed Nov 30 01:23:05 2005 Subject: [development] Tip for large site scaling: tracker.module considered harmful In-Reply-To: <4a9fdc630511291445u5b3b5c90u6bb0fc5e628a5b52@mail.gmail.com> References: <438CB935.7030305@userfrenzy.com> <4a9fdc630511291445u5b3b5c90u6bb0fc5e628a5b52@mail.gmail.com> Message-ID: <438CFEE8.1000508@userfrenzy.com> Khalid B wrote: > Seems like your site should move to a more modern ACID table > database, for example switching from MyISAM to Inno should > help, since it provides row level locking. Well, yeah, but as I tried to get across, there are two parts to this. Fixing MyISAM is one (not something we can or should address), fixing indexless mega-queries is quite another. tracker.module (on this site) hit over 9 million rows on a query which may return none. Ideally it should hit indexes and return none right now, not in 11 minutes' time. Comment module, as shipped, is similarly expensive, but more easily fixed (a simple "add index" or two fixed that). I know Dries is having a think about my forum request before tomorrow, so I'm hoping for a yea then. Meanwhile I think: that, generally speaking, we do have the answers for these performance bumps-in-the-road; that it would help us to make a place to consolidate those discussions rather than having them dotted around private blogs, bug reports and uncommitted patches; and that making that place visible might (as a side effect) make it more obvious to the casual observer that Drupal can punch at this weight. OK. That's one more argument in favour than I intended to make today. :) jh [ Responsible for evolt.org , mbr.org , abctales.com ] From boris at bryght.com Wed Nov 30 02:02:40 2005 From: boris at bryght.com (Boris Mann) Date: Wed Nov 30 02:02:46 2005 Subject: [development] Tip for large site scaling: tracker.module considered harmful In-Reply-To: <438CFEE8.1000508@userfrenzy.com> References: <438CB935.7030305@userfrenzy.com> <4a9fdc630511291445u5b3b5c90u6bb0fc5e628a5b52@mail.gmail.com> <438CFEE8.1000508@userfrenzy.com> Message-ID: <871E346A-64FE-4097-8ADE-A80FCB2FA1BE@bryght.com> On 29-Nov-05, at 5:22 PM, John Handelaar wrote: > I know Dries is having a think about my forum request before > tomorrow, so I'm hoping for a yea then. Meanwhile I think: > that, generally speaking, we do have the answers for these > performance bumps-in-the-road; that it would help us to > make a place to consolidate those discussions rather than > having them dotted around private blogs, bug reports and > uncommitted patches; and that making that place visible might > (as a side effect) make it more obvious to the casual observer > that Drupal can punch at this weight. Yep. I'm in favour of the forum, and I think a private mailing list would be useful as well. The forum to discuss and toss options back and forth, the private mailing list (scale@drupal.org? :P) for allowing lots of big site maintainers to have private conversations. OK, ok....the mailing list doesn't HAVE to be private (I wouldn't mind either way), just thinking it might allow things to be a little more open. What do you think, John? -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com From john at userfrenzy.com Wed Nov 30 02:14:30 2005 From: john at userfrenzy.com (John Handelaar) Date: Wed Nov 30 02:14:40 2005 Subject: [development] Tip for large site scaling: tracker.module considered harmful In-Reply-To: <871E346A-64FE-4097-8ADE-A80FCB2FA1BE@bryght.com> References: <438CB935.7030305@userfrenzy.com> <4a9fdc630511291445u5b3b5c90u6bb0fc5e628a5b52@mail.gmail.com> <438CFEE8.1000508@userfrenzy.com> <871E346A-64FE-4097-8ADE-A80FCB2FA1BE@bryght.com> Message-ID: <438D0B06.9080408@userfrenzy.com> Boris Mann wrote: > > Yep. I'm in favour of the forum, and I think a private mailing list > would be useful as well. The forum to discuss and toss options back and > forth, the private mailing list (scale@drupal.org? :P) for allowing > lots of big site maintainers to have private conversations. I'd settle for a list if it's what we can get. Don't really see a need for privacy though. jh From drupal.org at juggernaut.com.au Wed Nov 30 02:20:08 2005 From: drupal.org at juggernaut.com.au (Richard Archer) Date: Wed Nov 30 02:20:11 2005 Subject: [development] Tip for large site scaling: tracker.module considered harmful In-Reply-To: <871E346A-64FE-4097-8ADE-A80FCB2FA1BE@bryght.com> References: <438CB935.7030305@userfrenzy.com> <4a9fdc630511291445u5b3b5c90u6bb0fc5e628a5b52@mail.gmail.com> <438CFEE8.1000508@userfrenzy.com> <871E346A-64FE-4097-8ADE-A80FCB2FA1BE@bryght.com> Message-ID: At 6:02 PM -0800 29/11/05, Boris Mann wrote: >Yep. I'm in favour of the forum, and I think a private mailing list >would be useful as well. The forum to discuss and toss options back >and forth, the private mailing list (scale@drupal.org? :P) for >allowing lots of big site maintainers to have private conversations. I used to participate in the "biglinux" mailing list. It was for mainly ISPs trying to roll out reliable infrastructure based on the 1.0 and 1.2 kernels. We found that almost all our hacks and "war stories" translated into committed improvements to the kernel. There are very few optimizations that, if beneficial to large sites, wouldn't also make small sites faster. If they do happen to make a small site a little slower, well, it's only a small site and doesn't generate much load anyway :) I guess what I'm getting at is that rather than a list or a book chapter on drupal.org I would prefer to see war stories posted as bugs to the issues tracker with either a patch or a description of the work-around. Things like tables missing indexes on key columns, un-optimized database queries, wasteful algorithms... they're all bugs. ...Richard. From john at userfrenzy.com Wed Nov 30 02:34:00 2005 From: john at userfrenzy.com (John Handelaar) Date: Wed Nov 30 02:34:17 2005 Subject: [development] Tip for large site scaling: tracker.module considered harmful In-Reply-To: References: <438CB935.7030305@userfrenzy.com> <4a9fdc630511291445u5b3b5c90u6bb0fc5e628a5b52@mail.gmail.com> <438CFEE8.1000508@userfrenzy.com> <871E346A-64FE-4097-8ADE-A80FCB2FA1BE@bryght.com> Message-ID: <438D0F98.2070306@userfrenzy.com> Richard Archer wrote: > I guess what I'm getting at is that rather than a list or a > book chapter on drupal.org I would prefer to see war stories > posted as bugs to the issues tracker with either a patch or a > description of the work-around. I'd assume we'd do that too. But that on its own is not an answer for those of us who run into this stuff when a site suddenly stops functioning. Needles, haystacks. Bugs are (rightly) filed against their components, not their target audience. jh From mcsparkerton at yahoo.co.uk Wed Nov 30 02:37:23 2005 From: mcsparkerton at yahoo.co.uk (Andre Molnar) Date: Wed Nov 30 02:40:26 2005 Subject: [development] 404 search In-Reply-To: <4a9fdc630511291422v9152458l1da65c6725a8eaa0@mail.gmail.com> References: <438CBD7C.2030603@deekayen.net> <4a9fdc630511291422v9152458l1da65c6725a8eaa0@mail.gmail.com> Message-ID: <438D1063.9010108@yahoo.co.uk> A simple solution: Createa a full PHP page: Include your standard 404 not found text ('sorry you didn't find what you were looking for') Parse the request URI and create a query string Use that to generate a link (to the search page) No automatic search result - but it gives the user the option to use the search with a pre filled query in the form of a link. [whatever they searched for] (or whatever the proper code would be these days) make that page your 404 page andre Khalid B wrote: > Here is another variant by someone else (also based on Steven's). > http://www.settingtheworldtorights.com/files/drupal/ii404-4.6.tar.gz > > On a small site this may be acceptable. However for a large site I would > think twice, since reorganizing content can cause a lot of 404s. There > are even cases where 404s from missing images, or confused crawlers, > relative pathnames, RSS readers, ... etc such as this issue: > http://drupal.org/node/13148 > > So, a search will be performed for all 404s, whether human generation > or not. > > On 11/29/05, David K Norman wrote: > >>I just wanted to make sure this wasn't implemented before I submitted an >>official feature request issue. >> >>Sometimes I remove an attachment from a node, but Google still keeps it >>indexed for a while. I can see people still trying to access the file in >>my logs, but they get a 404. I think it would be cool if the 404 message >>was able to say "Page not found", but then use the missing URL as a >>search string to display other possible similar pages in the site under >>the Page not found message. >> >>David Norman >>http://deekayen.net/ >> > > From chris at tinpixel.com Wed Nov 30 04:41:33 2005 From: chris at tinpixel.com (Chris Johnson) Date: Wed Nov 30 04:41:42 2005 Subject: [development] Tip for large site scaling: tracker.module considered harmful In-Reply-To: <4a9fdc630511291445u5b3b5c90u6bb0fc5e628a5b52@mail.gmail.com> References: <438CB935.7030305@userfrenzy.com> <4a9fdc630511291445u5b3b5c90u6bb0fc5e628a5b52@mail.gmail.com> Message-ID: <438D2D7D.7000901@tinpixel.com> This is a good example of why one might want to use PostgreSQL instead of MySQL for a Drupal site. ..chrisxj Khalid B wrote: > Seems like your site should move to a more modern ACID table > database, for example switching from MyISAM to Inno should > help, since it provides row level locking. > > In conjunction with this, a few changes to the db layer will be needed > (e.g. locking the whole table should not be done). > > On 11/29/05, John Handelaar wrote: >>1. Some tracker module queries, particularly the one which >> shows 'all my posts' to individual users, stop functioning >> on large data sets. In this case, queries ran for >600s >> >>2. An INSERT/UPDATE on {comments} while those queries are >> trying to complete will be stalled, waiting for a full-table >> lock (MySQL + MyISAM). >> >>3. While there is an INSERT/UPDATE waiting to execute, all >> other SELECTS on the same table are frozen and marked as >> 'Locked' in MySQL's process list until 1) and 2) are complete. >> >> >>Add 100 logged-in users, simmer for about 3 minutes -> MySQL server >>drops dead with 'Too many connections' (whether using mysql_pconnect() >>or not). >> >>Workaround: under no circumstances enable tracker.module on a >>heavily-used site which gives posting rights to visitors. From walkah at walkah.net Wed Nov 30 05:55:42 2005 From: walkah at walkah.net (James Walker) Date: Wed Nov 30 06:01:00 2005 Subject: [development] 404 search In-Reply-To: <438D1063.9010108@yahoo.co.uk> References: <438CBD7C.2030603@deekayen.net> <4a9fdc630511291422v9152458l1da65c6725a8eaa0@mail.gmail.com> <438D1063.9010108@yahoo.co.uk> Message-ID: <438D3EDE.60507@walkah.net> On 11/29/05 9:37 PM, Andre Molnar wrote: > A simple solution: > > Createa a full PHP page: > Include your standard 404 not found text ('sorry you didn't find what > you were looking for') > > Parse the request URI and create a query string > Use that to generate a link (to the search page) > > No automatic search result - but it gives the user the option to use the > search with a pre filled query in the form of a link. > > [whatever they > searched for] > > (or whatever the proper code would be these days) > > make that page your 404 page good god man! escape them strings! -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net From drupal.org at juggernaut.com.au Wed Nov 30 06:00:36 2005 From: drupal.org at juggernaut.com.au (Richard Archer) Date: Wed Nov 30 06:01:06 2005 Subject: [development] Re: [drupal-devel] performance improvements - avoiding big unserialize() In-Reply-To: <4358E8DD.3000901@tejasa.com> References: <4358E8DD.3000901@tejasa.com> Message-ID: At 3:10 PM +0200 21/10/05, Moshe Weitzman wrote: >In speaking with Rasmus last night, he discouraged us from using >unserialize() on large arrays when possible. This eats memory and speed. We >do this at lkeast twice on evrry page view: the menu cache and the variables >cache (i.e. $conf). > >Rasmus' suggestion was to store these arrays without serialization in a >shared memory system like APC. I have set up and run some tests comparing various ways of retrieving an array from storage. The storage mechanisms I have tested are: Storing serialized data in a file, Storing var_export output in a file, Storing the array in APC. I haven't tested storing the serialized array in a database because that would just be testing the database performance, whereas I'm primarily interested in testing unserialize. With each test I verified how much memory was available to the script by allocating memory to exhaustion as the last step. This confirmed the summary results below. As I understand it, Rasmus said at DrupalCon that unserialize allocates and does not release a certain amount of memory. I don't see any evidence of this. I do however see a massive memory leak in apc_fetch! It seems to lose about 7 kB of memory each time it's called. I wouldn't like to roll out a system which uses APC in its current state, and I have disabled it on my server. It is interesting to note that the only way to benefit from using APC is to store the array in a file and include it. Not worth the security risk, IMHO. My conclusion is that using unserialize is quite OK and there is no need or benefit to changing the way arrays are stored. The test script can be downloaded from: http://mel01.juggernaut.com.au/arraytest.php.gz Here are the results of my tests. Reading serialized data from a file with fread and then unserializing it: time: 0.5022668838501 seconds elapsed for 100 iterations. memory: 120808 bytes consumed. Reading serialized data from a file with implode('', file()) and then unserializing it: time: 0.52363586425781 seconds elapsed for 100 iterations. memory: 118408 bytes consumed. Including var_export output from a file, APC disabled: time: 1.392637014389 seconds elapsed for 100 iterations. memory: 122096 bytes consumed. Including var_export output from a file, APC enabled: time: 0.33631801605225 seconds elapsed for 100 iterations. memory: 121640 bytes consumed. Fetching data from APC: time: 0.48792600631714 seconds elapsed for 100 iterations. memory: 836016 bytes consumed. Test system is: Apache/2.0.53 (Fedora) PHP Version 4.3.11 APC Version 3.0.8 ...Richard. From dries.buytaert at gmail.com Wed Nov 30 08:11:30 2005 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Wed Nov 30 08:11:35 2005 Subject: [development] Tip for large site scaling: tracker.module considered harmful In-Reply-To: References: <438CB935.7030305@userfrenzy.com> <4a9fdc630511291445u5b3b5c90u6bb0fc5e628a5b52@mail.gmail.com> <438CFEE8.1000508@userfrenzy.com> <871E346A-64FE-4097-8ADE-A80FCB2FA1BE@bryght.com> Message-ID: > Things like tables missing indexes on key columns, un-optimized > database queries, wasteful algorithms... they're all bugs. I agree that these are bugs, and that they need fixing. John, can you file issues for those, and mark them critical? You indicated that you fixed a comment.module issue, but we haven't seen an issue or patch yet? Please work with us to fix these bugs. Thanks. I'm still undecided about creating a dedicated mailing list or forum for this, but I'm looking to hear people opinion on this. That said, I'm going to setup two more mailing lists: consulting@drupal.org and themes@drupal.org. An overview of the existing list can be found at http://lists.drupal.org/. -- Dries Buytaert :: http://www.buytaert.net/ From ber at webschuur.com Wed Nov 30 08:38:14 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Wed Nov 30 08:38:33 2005 Subject: [development] Tip for large site scaling: tracker.module considered harmful In-Reply-To: References: <438CB935.7030305@userfrenzy.com> Message-ID: <200511300938.19515.ber@webschuur.com> Op woensdag 30 november 2005 09:11, schreef Dries Buytaert: > I'm still undecided about creating a dedicated mailing list or forum > for this, but I'm looking to hear people opinion on this. I think in this case the "reference" part is more important (Where others can read what has been done and tried). Hence I think a forum is a better choice then a ML I am very interested in a forum where I can read other peoples tricks and stories. But, maybe we should make it a bit more general (the con is that stuff is still spread around then). And make a forum dedicated for large Drupal deployments. Whether that is optimisation of one big site or a hosting provider sharing tips on how to deal with hosting issues. B?r -- | B?r Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com | From ber at webschuur.com Wed Nov 30 10:14:30 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Wed Nov 30 10:14:39 2005 Subject: [development] DEP - cascading variable system In-Reply-To: <587DFAD9-A583-4406-A849-D4339422C1E8@bryght.com> References: <587DFAD9-A583-4406-A849-D4339422C1E8@bryght.com> Message-ID: <200511301114.35885.ber@webschuur.com> > > * What in the heck is the user interface going to look like for > > managing different sets of settings? > > (i'll add this to the bottom) I think this can be doe a lot easier. Just leave it all as it its now. Forms API (fapi) will detect where it gets teh setting from, and will grey out the form field if a variable cannot be changed by a user. No idea how to solve this technically though. B?r -- [ B?r Kessels | Drupal services www.webschuur.com ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20051130/274a5350/attachment.pgp From adrian at bryght.com Wed Nov 30 10:21:29 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Wed Nov 30 10:21:40 2005 Subject: [development] DEP - cascading variable system In-Reply-To: <200511301114.35885.ber@webschuur.com> References: <587DFAD9-A583-4406-A849-D4339422C1E8@bryght.com> <200511301114.35885.ber@webschuur.com> Message-ID: <9F9F6989-F15E-4489-AA17-BE3EB53BB112@bryght.com> On 30 Nov 2005, at 12:14 PM, B?r Kessels wrote: > >>> * What in the heck is the user interface going to look like for >>> managing different sets of settings? >> >> (i'll add this to the bottom) > > I think this can be doe a lot easier. Just leave it all as it its now. > > Forms API (fapi) will detect where it gets teh setting from, and > will grey out > the form field if a variable cannot be changed by a user. I'm explicitly not getting involved in forms api with this DEP. forms api can be extended to handle different levels of setting variables, but i don't believe it's the right place. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com From ber at webschuur.com Wed Nov 30 11:39:54 2005 From: ber at webschuur.com (=?iso-8859-1?q?B=E8r_Kessels?=) Date: Wed Nov 30 11:40:03 2005 Subject: [development] DEP - cascading variable system In-Reply-To: <9F9F6989-F15E-4489-AA17-BE3EB53BB112@bryght.com> References: <200511301114.35885.ber@webschuur.com> <9F9F6989-F15E-4489-AA17-BE3EB53BB112@bryght.com> Message-ID: <200511301239.59942.ber@webschuur.com> Op woensdag 30 november 2005 11:21, schreef Adrian Rossouw: > forms api can be extended to handle different levels of setting ? > variables, but i don't believe it's the right place. I think it is important to have a place in the DEP to say what it does /not/ involve too. B?r -- | B?r Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com | From adrian at bryght.com Wed Nov 30 11:50:51 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Wed Nov 30 11:51:19 2005 Subject: [development] DEP - cascading variable system In-Reply-To: <200511301239.59942.ber@webschuur.com> References: <200511301114.35885.ber@webschuur.com> <9F9F6989-F15E-4489-AA17-BE3EB53BB112@bryght.com> <200511301239.59942.ber@webschuur.com> Message-ID: On 30 Nov 2005, at 1:39 PM, B?r Kessels wrote: > Op woensdag 30 november 2005 11:21, schreef Adrian Rossouw: >> forms api can be extended to handle different levels of setting >> variables, but i don't believe it's the right place. > > I think it is important to have a place in the DEP to say what it > does /not/ > involve too. and perhaps a 'security considerations' section. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com From vlado at dikini.net Wed Nov 30 12:43:17 2005 From: vlado at dikini.net (vlado) Date: Wed Nov 30 12:43:21 2005 Subject: [development] DEP - cascading variable system In-Reply-To: References: <200511301114.35885.ber@webschuur.com> <9F9F6989-F15E-4489-AA17-BE3EB53BB112@bryght.com> <200511301239.59942.ber@webschuur.com> Message-ID: <1133354597.13168.8.camel@localhost.localdomain> > > Op woensdag 30 november 2005 11:21, schreef Adrian Rossouw: > >> forms api can be extended to handle different levels of setting > >> variables, but i don't believe it's the right place. > > > > I think it is important to have a place in the DEP to say what it > > does /not/ > > involve too. > > and perhaps a 'security considerations' section. and a status - draft, ..., core, contrib From walkah at walkah.net Wed Nov 30 12:48:10 2005 From: walkah at walkah.net (James Walker) Date: Wed Nov 30 12:54:23 2005 Subject: [development] Tip for large site scaling: tracker.module considered harmful In-Reply-To: References: <438CB935.7030305@userfrenzy.com> <4a9fdc630511291445u5b3b5c90u6bb0fc5e628a5b52@mail.gmail.com> <438CFEE8.1000508@userfrenzy.com> <871E346A-64FE-4097-8ADE-A80FCB2FA1BE@bryght.com> Message-ID: <438D9F8A.4090207@walkah.net> On 11/30/05 3:11 AM, Dries Buytaert wrote: >> Things like tables missing indexes on key columns, un-optimized >> database queries, wasteful algorithms... they're all bugs. > > I agree that these are bugs, and that they need fixing. John, can you > file issues for those, and mark them critical? You indicated that you > fixed a comment.module issue, but we haven't seen an issue or patch > yet? Please work with us to fix these bugs. Thanks. yes please. > I'm still undecided about creating a dedicated mailing list or forum for > this, but I'm looking to hear people opinion on this. That said, I'm > going to setup two more mailing lists: consulting@drupal.org and > themes@drupal.org. An overview of the existing list can be found at > http://lists.drupal.org/. > I agree with the others that having a forum or someplace more readily available / properly archived is most useful (i.e. over a mailing list)... but one thing that Boris mentioned about privacy is an interesting point, as larger installations may (for good reason) be unwilling to discuss issues until they've been resolved... in which case a they might be more inclined to share details to a closed audience ... but perhaps IRC (or something more "real time" ) is sufficient (with results / recap then posted to the forum or wherever is deemed appropriate). basically i see 2 issues : 1) large site owners / admins / maintainers having a resource for "prior art" best practices, etc. 2) a place for those people to get attention to fix a current issue. Though perhaps #2 isn't the community's problem ... (i.e. for the realm of the marketplace). Bottom line is, large installations tell a lot about where weaknesses are because they generate scenarios that are hard to duplicate in a pure testing environment... capturing this info is pretty important, imo. -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net From larssg at gmail.com Wed Nov 30 13:08:21 2005 From: larssg at gmail.com (Lars Sehested Geisler) Date: Wed Nov 30 13:08:24 2005 Subject: [development] 404 search In-Reply-To: <438CBD7C.2030603@deekayen.net> References: <438CBD7C.2030603@deekayen.net> Message-ID: <55474bb0511300508s476396e7gc87c8277e7058ad0@mail.gmail.com> I made a module once which you can find at http://cvs.drupal.org/viewcvs/drupal/contributions/modules/search404/ It shows a message that the page was not found and then presents the results of a search. On 11/29/05, David K Norman wrote: > I just wanted to make sure this wasn't implemented before I submitted an > official feature request issue. > > Sometimes I remove an attachment from a node, but Google still keeps it > indexed for a while. I can see people still trying to access the file in > my logs, but they get a 404. I think it would be cool if the 404 message > was able to say "Page not found", but then use the missing URL as a > search string to display other possible similar pages in the site under > the Page not found message. > > David Norman > http://deekayen.net/ > From ber at webschuur.com Wed Nov 30 13:08:23 2005 From: ber at webschuur.com (=?utf-8?q?B=C3=A8r_Kessels?=) Date: Wed Nov 30 13:08:32 2005 Subject: [development] DEP - cascading variable system In-Reply-To: <1133354597.13168.8.camel@localhost.localdomain> References: <1133354597.13168.8.camel@localhost.localdomain> Message-ID: <200511301408.28569.ber@webschuur.com> Op woensdag 30 november 2005 13:43, schreef vlado: > > > Op woensdag 30 november 2005 11:21, schreef Adrian Rossouw: > > >> forms api can be extended to handle different levels of setting > > >> variables, but i don't believe it's the right place. > > > > > > I think it is important to have a place in the DEP to say what it > > > does /not/ > > > involve too. > > > > and perhaps a 'security considerations' section. > > and a status - draft, ..., core, contrib Added those: http://drupal.org/node/39407 B?r -- | B?r Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20051130/f1c8aa4a/attachment.pgp From charikane at ecrin.asso.fr Wed Nov 30 15:20:22 2005 From: charikane at ecrin.asso.fr (Eric Charikane) Date: Wed Nov 30 15:20:27 2005 Subject: [development] node access issue In-Reply-To: <1133144336.8260.14.camel@localhost.localdomain> References: <1133144336.8260.14.camel@localhost.localdomain> Message-ID: <42FEC864-7340-455E-8DC3-B5FADC912850@ecrin.asso.fr> Hi, you may find useful to look at this http://drupal.org/node/24868, Robb had made a module that works very well in 4.6.x that let you use many modules using node_access. eric Le 28 nov. 05 ? 03:18, Gordon Heydon a ?crit : > Organic groups is using the node access table already, > which causes a conflict with the node_priv_by_role module. From scott at 4th.com Wed Nov 30 16:34:15 2005 From: scott at 4th.com (Syscrusher) Date: Wed Nov 30 16:34:34 2005 Subject: [development] Trying to understand hook_nodeapi() invocation sequence from node.module -- updated In-Reply-To: References: <200511241120.23817.scott@4th.com> <4388D823.1030604@hojtsy.hu> Message-ID: <200511301134.15470.scott@4th.com> On Saturday 26 November 2005 20:12, Karoly Negyesi wrote: > >>> And on a "preview" of the node after editing, I see this: > >>> > >>> nodeapi load 8 > > node_menu > > >>> nodeapi load 8 > > node_page op'edit' [....] Just wanted to say thanks to you and Goba for the replies...I got busy in my work life and haven't had a chance to try these suggestions yet, but will do so ASAP. Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher From weitzman at tejasa.com Wed Nov 30 16:55:11 2005 From: weitzman at tejasa.com (Moshe Weitzman) Date: Wed Nov 30 16:56:41 2005 Subject: [development] DEP - cascading variable system In-Reply-To: <587DFAD9-A583-4406-A849-D4339422C1E8@bryght.com> References: <587DFAD9-A583-4406-A849-D4339422C1E8@bryght.com> Message-ID: <438DD96F.5010606@tejasa.com> [5] $GLOBALS['override'] > [4] user settings. system table, user domain, userid key. > [3] theme settings. system table, theme domain, theme name key. > [2] system settings. system table, system domain. > [1] $GLOBALS['defaults'] > [0] $default so variable_get() will return the right value based on the priority above? please add that to the DEP if it isn't there already. about #4. I'd like for user variables to be loaded into the $user object so that we don't go to the DB for them multiple times on a page view. For example, lets say we invent a user pref called 'show signatures' and I set that to FALSE because I am on a low bandwidth connection. I would not want a variable_get('show signatures') to hit the DB every time we show a node or comment. maybe a static cache would solve this. in general, i'm a bit hesitant about storing user variables in the variables table. thats what $user object and users.data column and $_SESSION are for. Would you get rid of users.data? Maybe get rid of that users.data and change users.module to write to variables table instead. while you are there, move users.timezone and other non critical fields from columns in the users table to records in the variables table. one other nit - in drupal, higher numbers have lower priority so the table above could be numbered in reverse. FEATURE REQUESTS for a rainy day ... - have some way to cleanup the variables table of cruft from disabled modules - in variable_get(), return a hint about what layer provided the value, so the front end can grey out the form field if necessary. From weitzman at tejasa.com Wed Nov 30 17:21:19 2005 From: weitzman at tejasa.com (Moshe Weitzman) Date: Wed Nov 30 17:21:38 2005 Subject: [development] Re: [drupal-devel] performance improvements - avoiding big unserialize() In-Reply-To: References: <4358E8DD.3000901@tejasa.com> Message-ID: <438DDF8F.8080207@tejasa.com> thanks for providing these benchmarks, richard. > It is interesting to note that the only way to benefit from > using APC is to store the array in a file and include it. > Not worth the security risk, IMHO. i don't understand this. you get no benefit by just storing the array directly? for example, apc_store('conf', $conf); > > My conclusion is that using unserialize is quite OK and there > is no need or benefit to changing the way arrays are stored. > maybe so. the fact remains that we spend significant time during every request unserializing these large arrays, and if we want to speed up drupal, we have to concentrate in this area. you can verify this using xdebug profiler or zend studio. the profiler does not lie. From chris at tinpixel.com Wed Nov 30 17:36:25 2005 From: chris at tinpixel.com (Chris Johnson) Date: Wed Nov 30 17:36:29 2005 Subject: [development] DEP - cascading variable system In-Reply-To: <438DD96F.5010606@tejasa.com> References: <587DFAD9-A583-4406-A849-D4339422C1E8@bryght.com> <438DD96F.5010606@tejasa.com> Message-ID: <438DE319.3090409@tinpixel.com> Moshe Weitzman wrote: > about #4. I'd like for user variables to be loaded into the $user object > so that we don't go to the DB for them multiple times on a page view. > For example, lets say we invent a user pref called 'show signatures' and > I set that to FALSE because I am on a low bandwidth connection. I would > not want a variable_get('show signatures') to hit the DB every time we > show a node or comment. maybe a static cache would solve this. Umm, doesn't variable_get() only hit the database the _first_ time the variable is requested on a page? After that, it's in the global $conf, isn't it? In general, I think it makes sense to keep user variables in user-related tables, not in the {variables} table. ..chrisxj From adrian at bryght.com Wed Nov 30 17:53:35 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Wed Nov 30 17:53:47 2005 Subject: [development] DEP - cascading variable system In-Reply-To: <438DE319.3090409@tinpixel.com> References: <587DFAD9-A583-4406-A849-D4339422C1E8@bryght.com> <438DD96F.5010606@tejasa.com> <438DE319.3090409@tinpixel.com> Message-ID: <9DF7287C-BC65-4F65-A0A1-1B78A18346E2@bryght.com> On 30 Nov 2005, at 7:36 PM, Chris Johnson wrote: > Moshe Weitzman wrote: > >> about #4. I'd like for user variables to be loaded into the $user >> object so that we don't go to the DB for them multiple times on a >> page view. For example, lets say we invent a user pref called >> 'show signatures' and I set that to FALSE because I am on a low >> bandwidth connection. I would not want a variable_get('show >> signatures') to hit the DB every time we show a node or comment. >> maybe a static cache would solve this. > > Umm, doesn't variable_get() only hit the database the _first_ time > the variable is requested on a page? After that, it's in the > global $conf, isn't it? > > In general, I think it makes sense to keep user variables in user- > related tables, not in the {variables} table. This is only for places where we want to override the defaults specified by the system. Like for instance whether or not to display tinymce, the user's frontpage (if that's customisable), the user's theme (if that's customisable). So that every time we want to use (say) the site_frontpage variable, we don't have to explicitly code and check for the different kinds of overrides. We could put the user's variables in the user table, and variable_get needs to know how to check variables for different domains. I don't like the 'data' field. It's great if you are doing fast development, but what happens when (in recent memory), we disable comment paging on drupal.org, and the interface element to configure that has been removed. You'd need to open up every user object and unset that, and then save it back to the database. With that in the variables table, it would be a single line of sql. SO what happens when you stop a theme that some people had as a default.? With these variables (not properties) in the variables table, we can control stuff like this. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com From gerhard at killesreiter.de Wed Nov 30 19:01:45 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Wed Nov 30 18:02:12 2005 Subject: [development] Re: [drupal-devel] performance improvements - avoiding big unserialize() In-Reply-To: <438DDF8F.8080207@tejasa.com> References: <4358E8DD.3000901@tejasa.com> <438DDF8F.8080207@tejasa.com> Message-ID: <438DF719.7080504@killesreiter.de> Moshe Weitzman wrote: > thanks for providing these benchmarks, richard. > Yep, very interesting! >> It is interesting to note that the only way to benefit from >> using APC is to store the array in a file and include it. >> Not worth the security risk, IMHO. > > > i don't understand this. you get no benefit by just storing the array > directly? for example, apc_store('conf', $conf); > >> >> My conclusion is that using unserialize is quite OK and there >> is no need or benefit to changing the way arrays are stored. >> > > maybe so. the fact remains that we spend significant time during every > request unserializing these large arrays, and if we want to speed up > drupal, we have to concentrate in this area. There are a lot of areas we can look into. > you can verify this using xdebug profiler or zend studio. the profiler > does not lie. I would not be so sure about the latter... I got quite different results (on another topic) using both xdebug and the PEAR profiler. I think that xdebug got it right, but I can't be certain. Cheers, Gerhard From gerhard at killesreiter.de Wed Nov 30 19:33:02 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Wed Nov 30 18:33:25 2005 Subject: [development] DEP - cascading variable system In-Reply-To: <438DE319.3090409@tinpixel.com> References: <587DFAD9-A583-4406-A849-D4339422C1E8@bryght.com> <438DD96F.5010606@tejasa.com> <438DE319.3090409@tinpixel.com> Message-ID: <438DFE6E.100@killesreiter.de> Chris Johnson wrote: > Moshe Weitzman wrote: > >> about #4. I'd like for user variables to be loaded into the $user >> object so that we don't go to the DB for them multiple times on a >> page view. For example, lets say we invent a user pref called 'show >> signatures' and I set that to FALSE because I am on a low bandwidth >> connection. I would not want a variable_get('show signatures') to hit >> the DB every time we show a node or comment. maybe a static cache >> would solve this. > > > Umm, doesn't variable_get() only hit the database the _first_ time the > variable is requested on a page? After that, it's in the global > $conf, isn't it? Right. More specifically: The cached serialized array of variables is retrieved from the cache table and the vars are assigned to the $conf array. You can override those with vars from settings.php > > In general, I think it makes sense to keep user variables in > user-related tables, not in the {variables} table. > Anybody pursuing the user-variables-in-variable-table idea in earnest has just had a bad idea. (no, that is not waht I intended to write originally) Cheers, Gerhard From weitzman at tejasa.com Wed Nov 30 18:47:20 2005 From: weitzman at tejasa.com (Moshe Weitzman) Date: Wed Nov 30 18:47:19 2005 Subject: [development] DEP - cascading variable system In-Reply-To: <438DFE6E.100@killesreiter.de> References: <587DFAD9-A583-4406-A849-D4339422C1E8@bryght.com> <438DD96F.5010606@tejasa.com> <438DE319.3090409@tinpixel.com> <438DFE6E.100@killesreiter.de> Message-ID: <438DF3B8.9050302@tejasa.com> > Anybody pursuing the user-variables-in-variable-table idea in earnest > has just had a bad idea. (no, that is not waht I intended to write > originally) Noone suggested this. Adrian proposed automatically loading system variables into memory like our current $conf. I think Chris missed this distinction and then asked for assurance about how our current system works. From michelangelo_pm at cantv.net Wed Nov 30 18:55:44 2005 From: michelangelo_pm at cantv.net (Michelangelo Partipilo) Date: Wed Nov 30 18:55:47 2005 Subject: [development] DEP - cascading variable system In-Reply-To: <438DFE6E.100@killesreiter.de> References: <587DFAD9-A583-4406-A849-D4339422C1E8@bryght.com> <438DD96F.5010606@tejasa.com> <438DE319.3090409@tinpixel.com> <438DFE6E.100@killesreiter.de> Message-ID: <438DF5B0.2070805@cantv.net> What about module settings per user? Let's say I write an Album Module and I want each user to be able to select the way his gallery should be presented, or the theme that should be used for it. Of course I could put these on a DB table, but that wouldn't that just add more tables and module logic? These wouldn't be needed if this is implemented. Gerhard Killesreiter wrote: > Chris Johnson wrote: > >> Moshe Weitzman wrote: >> >>> about #4. I'd like for user variables to be loaded into the $user >>> object so that we don't go to the DB for them multiple times on a >>> page view. For example, lets say we invent a user pref called 'show >>> signatures' and I set that to FALSE because I am on a low bandwidth >>> connection. I would not want a variable_get('show signatures') to hit >>> the DB every time we show a node or comment. maybe a static cache >>> would solve this. >> >> >> >> Umm, doesn't variable_get() only hit the database the _first_ time the >> variable is requested on a page? After that, it's in the global >> $conf, isn't it? > > > > Right. More specifically: The cached serialized array of variables is > retrieved from the cache table and the vars are assigned to the $conf > array. You can override those with vars from settings.php > >> >> In general, I think it makes sense to keep user variables in >> user-related tables, not in the {variables} table. >> > > Anybody pursuing the user-variables-in-variable-table idea in earnest > has just had a bad idea. (no, that is not waht I intended to write > originally) > > Cheers, > Gerhard > From gerhard at killesreiter.de Wed Nov 30 20:12:16 2005 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Wed Nov 30 19:12:38 2005 Subject: [development] DEP - cascading variable system In-Reply-To: <438DF5B0.2070805@cantv.net> References: <587DFAD9-A583-4406-A849-D4339422C1E8@bryght.com> <438DD96F.5010606@tejasa.com> <438DE319.3090409@tinpixel.com> <438DFE6E.100@killesreiter.de> <438DF5B0.2070805@cantv.net> Message-ID: <438E07A0.2070704@killesreiter.de> Michelangelo Partipilo wrote: > What about module settings per user? Let's say I write an Album Module > and I want each user to be able to select the way his gallery should > be presented, or the theme that should be used for it. Of course I > could put these on a DB table, but that wouldn't that just add more > tables and module logic? These wouldn't be needed if this is implemented. > Hi, glad you are back. it is a bad idea because you would have a variable for each user. On Drupal.org it would mean 40000 variables. Those would be (with the current design) loaded per page view and maybe break you php memory limit. The current recommended way of adding user variables is to a) store them in the user object. This way they will end up in the user.data column. Example: block.module pro: easy to do contra: hard to get the setting for all users as it is in a serialized array inside user.data or b) make a db table for this and store it yourself pro: easy to get all users with setting "foo" contra: needs a little bit more work There is also option c): add to the $_SESSION variable pro: easy to do contra: only lasts for the current session Cheers, Gerhard From adrian at bryght.com Wed Nov 30 19:13:42 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Wed Nov 30 19:13:59 2005 Subject: [development] DEP - cascading variable system In-Reply-To: <438DF5B0.2070805@cantv.net> References: <587DFAD9-A583-4406-A849-D4339422C1E8@bryght.com> <438DD96F.5010606@tejasa.com> <438DE319.3090409@tinpixel.com> <438DFE6E.100@killesreiter.de> <438DF5B0.2070805@cantv.net> Message-ID: <5236E0B1-3DFE-470A-8F84-C60168581B3E@bryght.com> On 30 Nov 2005, at 8:55 PM, Michelangelo Partipilo wrote: > What about module settings per user? Let's say I write an Album > Module and I want each user to be able to select the way his > gallery should be presented, or the theme that should be used for > it. Of course I could put these on a DB table, but that wouldn't > that just add more tables and module logic? These wouldn't be > needed if this is implemented. Yeah. It would also allow each blog to have it's own settings. Or each section of the site. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com From adrian at bryght.com Wed Nov 30 19:24:37 2005 From: adrian at bryght.com (Adrian Rossouw) Date: Wed Nov 30 19:24:48 2005 Subject: [development] DEP - cascading variable system In-Reply-To: <438E07A0.2070704@killesreiter.de> References: <587DFAD9-A583-4406-A849-D4339422C1E8@bryght.com> <438DD96F.5010606@tejasa.com> <438DE319.3090409@tinpixel.com> <438DFE6E.100@killesreiter.de> <438DF5B0.2070805@cantv.net> <438E07A0.2070704@killesreiter.de> Message-ID: <16183A7D-50EB-4972-909F-1D80178C9B46@bryght.com> On 30 Nov 2005, at 10:12 PM, Gerhard Killesreiter wrote: > Michelangelo Partipilo wrote: > >> What about module settings per user? Let's say I write an Album >> Module and I want each user to be able to select the way his >> gallery should be presented, or the theme that should be used for >> it. Of course I could put these on a DB table, but that wouldn't >> that just add more tables and module logic? These wouldn't be >> needed if this is implemented. >> > > Hi, glad you are back. > > it is a bad idea because you would have a variable for each user. > On Drupal.org it would mean 40000 variables. Those would be (with > the current design) loaded per page view and maybe break you php > memory limit. They would not all be loaded into memory at the same time.. each layer gets loaded individually. So the only ones loaded by default are the ones specified in code (default or override), and then each other layer would get initialised seperately. ie: variable_load('user', $user->uid); blog module might have variable_load('blog', $user->uid); themes might have variable_load($themes, $GLOBALS['theme']); This would only load something IF the user has overridden any specific settings, and then only specifically those variables that have been changed. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com From rob at robshouse.net Wed Nov 30 19:25:53 2005 From: rob at robshouse.net (Robert Douglass) Date: Wed Nov 30 19:27:03 2005 Subject: [development] DEP - cascading variable system In-Reply-To: <438E07A0.2070704@killesreiter.de> References: <587DFAD9-A583-4406-A849-D4339422C1E8@bryght.com> <438DD96F.5010606@tejasa.com> <438DE319.3090409@tinpixel.com> <438DFE6E.100@killesreiter.de> <438DF5B0.2070805@cantv.net> <438E07A0.2070704@killesreiter.de> Message-ID: <438DFCC1.1020503@robshouse.net> I have a feature request: get_or_set_variable() This will look to see if a variable is in the system, and if not, write the default value to the database. This stops the situation where some of the state is in the database and some is in the code (in the form of defaults). I find it better to have all the state in one place. -Robert From kieran at civicspacelabs.org Wed Nov 30 20:10:46 2005 From: kieran at civicspacelabs.org (Kieran Lal) Date: Wed Nov 30 20:10:52 2005 Subject: [development] Administration Survey: Theme improvements, theme help system, theme mailing list Message-ID: As part of the Drupal administration user experience survey we identified Drupal theme issues as the most difficult administration issues( http://www.surveymonkey.com/DisplaySummary.asp? SID=1425065&U=142506581557). There was some confusion about the results so Trae McCombs, from CivicSpace Labs, conducted six additional theme development interviews. Trae identified some common goals of theme developers, basic theme tasks, and difficult theme tasks. I have created a documentation page, http://drupal.org/node/39451, which outlines all this. I also spoke with Dries yesterday and requested that a theme developers mailing list be started to focus on helping with Drupal's most difficult administration task. In summary here are the actions we are taking to improve administration specifically focused on Drupale theme development. 1) Identified Drupal theming as the most difficult Drupal administration task. 2) Improved the project module to allow for categorization so that themes can be categorized to help themers pick a solid base theme. Designed by Dries and implemented by Nedjo Rogers for CivicSpace Labs. This is coming in the next few weeks on Drupal.org. 3) Provided a "Manage inconsistency in themes" documentation page with best practices. http://drupal.org/node/37156 4) Created a support channel #cstheme to support development of the CivicSpace theme. This may lead to a dedicated Drupal theme channel. 5) Added a link to theme help from the theme admin interface using the CivicSpace theme. Added several base layouts to the CS theme for theme developers to customize with styles. 6) Created a theme help documentation page to focus on basic and difficult theme tasks. http://drupal.org/node/39451 7) Requested a themers mailing list to focus specifically on the tasks of Drupal theme development Please help us to develop theme help documentation(http://drupal.org/ node/39451). Understanding basic and difficult theme tasks, and how to solve them, will allow us to attract more themers to the platform and make it easier for all of us to theme our sites. I'll leave you with a quote: Dries_:it's the reason I didn't convert buytaert.net yet -- it takes too f*****g long to make a theme Cheers, Kieran Development Manager CivicSpace Labs -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20051130/6dff7828/attachment-0001.htm From gordon at heydon.com.au Wed Nov 30 20:29:27 2005 From: gordon at heydon.com.au (Gordon Heydon) Date: Wed Nov 30 20:29:18 2005 Subject: [development] node access issue In-Reply-To: <42FEC864-7340-455E-8DC3-B5FADC912850@ecrin.asso.fr> References: <1133144336.8260.14.camel@localhost.localdomain> <42FEC864-7340-455E-8DC3-B5FADC912850@ecrin.asso.fr> Message-ID: <1133382567.7320.72.camel@localhost.localdomain> Hi, Thanks for this. It looks like exactly what I need. Does anyone know the status on this? how stable is it? could it be used on a production site. Thanks again. On Wed, 2005-11-30 at 16:20 +0100, Eric Charikane wrote: > Hi, you may find useful to look at this http://drupal.org/node/24868, > Robb had made a module that works very well in 4.6.x that let you use > many modules using node_access. eric > > Le 28 nov. 05 ? 03:18, Gordon Heydon a ?crit : > > > Organic groups is using the node access table already, > > which causes a conflict with the node_priv_by_role module. > > > !DSPAM:438dcaa2143069855420151! > From ber at webschuur.com Wed Nov 30 20:47:56 2005 From: ber at webschuur.com (Ber Kessels) Date: Wed Nov 30 20:48:00 2005 Subject: [development] DEP - cascading variable system In-Reply-To: <587DFAD9-A583-4406-A849-D4339422C1E8@bryght.com> References: <587DFAD9-A583-4406-A849-D4339422C1E8@bryght.com> Message-ID: <200511302147.56793.ber@webschuur.com> Op woensdag 30 november 2005 01:16, schreef Adrian Rossouw: > [5] $GLOBALS['override'] > [4] user settings. system table, user domain, userid key. > [3] theme settings. system table, theme domain, theme name key. > [2] system settings. system table, system domain. > [1] $GLOBALS['defaults'] > [0] $default What about: [6] $GLOBALS['override'] [5] $SESSION [4] user settings. system table, user domain, userid key. [3] theme settings. system table, theme domain, theme name key. [2] system settings. system table, system domain. [1] $GLOBALS['defaults'] [0] $default Taht would allow us to do fancy stuff, like themeswitching in a very easey way. B?r From dries at buytaert.net Wed Nov 30 21:56:12 2005 From: dries at buytaert.net (Dries Buytaert) Date: Wed Nov 30 21:56:28 2005 Subject: [development] Drupal 4.6.4 / 4.5.6 released Message-ID: Hello world, Drupal 4.6.4 is available for download. Drupal 4.6.4 is a maintenance release that fixes problems reported using the bug tracking system, as well as 3 security vulnerabilities (two "less critical", one "not critical") that affect all previous versions of Drupal. Since the vulnerabilities are also present in the Drupal 4.5 series, Drupal 4.5.6 is released as well. Upgrading your existing Drupal sites is strongly recommended. More information about the Drupal 4.6.4 and 4.5.6 release is available at http://drupal.org/drupal-4.6.4. Security advisories are available at http://drupal.org/security. Kudos to the security team for their work on getting these releases out, -- Dries Buytaert :: http://www.buytaert.net/ From weitzman at tejasa.com Wed Nov 30 22:21:54 2005 From: weitzman at tejasa.com (Moshe Weitzman) Date: Wed Nov 30 22:22:08 2005 Subject: [development] Re: [drupal-devel] performance improvements - avoiding big unserialize() In-Reply-To: References: <4358E8DD.3000901@tejasa.com> Message-ID: <438E2602.2030907@tejasa.com> >>Rasmus' suggestion was to store these arrays without serialization in a >>shared memory system like APC. I should add that APC will be included as part of PHP6: http://www.php.net/~derick/meeting-notes.html#id60 From drupal.org at juggernaut.com.au Wed Nov 30 23:24:22 2005 From: drupal.org at juggernaut.com.au (Richard Archer) Date: Wed Nov 30 23:34:08 2005 Subject: [development] Re: [drupal-devel] performance improvements - avoiding big unserialize() In-Reply-To: <438DDF8F.8080207@tejasa.com> References: <4358E8DD.3000901@tejasa.com> <438DDF8F.8080207@tejasa.com> Message-ID: At 12:21 PM -0500 30/11/05, Moshe Weitzman wrote: >i don't understand this. you get no benefit by just storing the array >directly? for example, apc_store('conf', $conf); That's correct, my tests showed no performance gain from using apc_store and apc_fetch. Looking through the APC source it is easy to see why this is the case. APC manipulates the array before storing it, creating an overhead similar to serialize and unserialize. I wonder if the APC authors wouldn't have saved themselves a lot of headaches by just using the PHP serialize and unserialize functions? While I haven't tested memcached, it is unlikely to be any better because it DOES call the PHP serialize and unserialize functions! I added a couple more tests to my script, and it seems unserialize is actually a very efficient way of restoring an array. It is twice as fast as building the array in a for loop. Which isn't surprising since a for loop is interpreted and unserialize is optimized C code. Building the array in a for loop: time: 0.94807291030884 seconds elapsed for 100 iterations. memory: 115920 bytes consumed. Unserialize from an existing global variable (no I/O): time: 0.45300388336182 seconds elapsed for 100 iterations. memory: 76880 bytes consumed. If you doubt my test results, please check out the script. It's not particularly nice code, but I think the results are valid. http://mel01.juggernaut.com.au/arraytest.php.gz Perhaps someone would like to run this test script through a profiler? >maybe so. the fact remains that we spend significant time during every >request unserializing these large arrays, and if we want to speed up >drupal, we have to concentrate in this area. Not necessarily. There are lots of areas in Drupal in which performance improvement is possible. The best way to improve performance is to process less data. Smaller data means: - more filesystem buffer hits - more disk cache hits - more database cache hits - less memory moved to unserialize the data - less memory moved to process the data. In this case processing less data could involve: - optimizing the size of the data stored in the arrays - storing less data in the arrays - splitting the arrays so only required portions are retrieved And of course trying to serve more pages from the page cache. >I should add that APC will be included as part of PHP6: Well, if it's going to be included in core it might receive some more love and attention. I certainly wouldn't leave APC in its current state running on my production server. ...Richard.

CivicSpace Theme Plan >

CivicSpace Theme Plan
>