Port to Drupal 5

Fixing a bug in hook_form_alter() found while testing against project D5 port

I need to roll in http://drupal.org/node/101174 and http://drupal.org/node/101170

doh, ignore patch in #1, rolled against wrong version. Here's the right one. Still need to roll in Zen's two new patches from the DRUPAL-4-7--2 branch as noted above (hence "needs work" status)

everything from DRUPAL-4-7--2 branch (as of DRUPAL-4-7--2-1) is now in HEAD (http://drupal.org/cvs?commit=47203).

please re-roll this patch against HEAD (since there were a bunch of changes in the last few days, too).

thanks!
-derek

AjK posted a new patch for this here: http://drupal.org/files/issues/cvslog_d5_15_12_2006.patch
(it's in a separate issue, but that's duplicate... let's keep using this one, instead).

thanks,
-derek

this is broken in a few important ways (mostly bugs in hook_menu()). i'll roll a new patch later, i'm just doing more testing now before i do.
overall, this patch is a great start, don't get me wrong. ;)

thanks,
-derek

haven't had a chance for the most thorough testing yet, but this at least fixes some of the bugs in hook_menu(). it also includes a cvs.info file.
needs much more testing, but at least it gets past most of the most trivial errors when running it on a live site. ;)

found a bunch more problems with the crazy FAPI stuff for release nodes. :( i'm working on it.
also, i discovered a core bug in the process: http://drupal.org/node/104280 ;)

cheers,
-derek

yay, my patch for #104280 is already committed. ;) that's nice.

furthermore, with some help from eaton in IRC, i got the evil FAPI stuff figured out. basically, in 4.7.x, form_builder() was responsible for looking at $_POST directly. in 5.x, it expects everything to be stuffed into '#post' ahead of time. so we just do that ourselves, and all appears to be well.

also, the taxonomy hackery was busted, thanks to taxonomy.module revision 1.320:

now, instead of a simple array of options, there's this crazy array of option objects, instead. :(

so, i added a _cvs_get_option_from_taxo() helper method to search the array of objects for the desired taxonomy option and return it.

after fairly heavy (but not exhaustive) testing, all the crazy N-page crap for adding release nodes seems to be working now. ;) a brief survey of other parts of cvs.module's functionality (cvs-application page, repo admin stuff, etc) is also working thanks to the menu fixes also included in this patch.

the final major TODO item is to finalize our plans for an /admin/project block and move everything there. as it is now, you can't easily get to the usual admin/cvs page on your own, since the admin page thinks you just want a cvs block, with only 1 element -- the repo editing pages.

• do we want to put all the CVS account stuff under /admin/user?
• should we leave all the CVS stuff together in an /admin/cvs block, and make sure that the accounts stuff is its own page like /admin/cvs/accounts (with subtabs under that)?
• should we use /admin/project and put all the CVS stuff under that (e.g. /admin/project/cvs-accounts vs. /admin/project/cvs-repositories vs. /admin/project/settings/cvs?

it's just not clear to me what's the best layout for all these pages.

however, once that's resolved, i think this would be fully working now. ;)

cheers,
-derek

after discussion w/ merlinofchaos in IRC, we decided it was best to use a new /admin/project block for all the project-related admin pages (settings for project, project_release, project_issue and cvs, plus the cvs accounts and cvs repositories pages).

i also discovered a bug in how we were using $may_cache in hook_menu() (since it was screwing up my attempts to get this project block working). i'll back-port that to 4.7.x-* in a separate issue.

as far as i know, this completes the patch. everything appears to be working ok, though more reviews and testing would be most appreciated!

left a little debugging output in the last patch.

committed to HEAD and installed on s.d.o (to make it easier for others to test).
i'm still leaving this issue as "needs review", since i'd appreciate more reviews and testing...
thanks,
-derek

hunmonk pointed out that the "CVS access" tab on project nodes is fubar.

a) there's form_id vs. function name disagreement for "cvs_project_access" vs. "cvs_project_access_form" in the "theme_", "_validate", and "_submit" handlers for that form.

b) the confirm form (at least for deleting access) is fubar. see http://drupal.org/node/64279#confirm_form

attached should fix both 'cvs access' tab bugs. not tested

not quite... sorry, the confirm_form() upgrade docs were a little broken (which i've now fixed). ;)
new patch based on hunmonk's previous one that gets the confirm_form() stuff right. tested locally.

code style looks good.

tested on s.d.o. all good. committed to HEAD as revision 1.134.

oh, but i was still fishing for reviews of the diff for the 5.x port. ;)

cvs diff -kk -up -r DRUPAL-4-7--2 -r HEAD

thanks,
-derek

i'm going to give up on people reviewing these porting patches, so i'm going to mark them as fixed now.