Behaviors in project.js cannot be executed twice

Also, you shouldn't upload attachments with spaces in the filename. :P

http://drupal.org/files/issues/Disemvowel%20with%20dreditor_0.png
http://drupal.org/files/issues/Disemvowel%20wtih%20dreditor%20after%20cl...
http://drupal.org/files/issues/Disemvowel%20dreditor%20disabled_0.png

Investigated this and tracked it down to Dreditor's initialization, where it does:

// @todo Behaviors of Dreditor are not invoked with regular behaviors.
jQuery(document).ready(function () {
  Drupal.dreditor.confInit();
  Drupal.attachBehaviors(this);
});

Commenting out Drupal.attachBehaviors(this); fixes the bug, but this means that Project module's behavior is buggy. JavaScript behaviors need to be written in a way that they can be invoked at any time, also repeatedly.

#659684: "Modules categories" lost on project edit pages as been marked as a duplicate.

bump

I installed this on d6.p.d.o and now it fails without dreditor. When you first load the page, the "Modules categories" section is gone, even if you have the "Modules" radio by default. Only if you toggle to something else and back to Modules do the module categories appear. Seems this patch just reverses the bug from dreditor users (minority) to non-dreditor users (majority). Try it yourself at:

http://d6.project.drupal.org/node/29351/edit

(or some other project node you can edit)...

+++ project.js	1 Jan 2010 23:03:12 -0000
@@ -1,17 +1,18 @@
       if (this.checked) {
-        tid = this.value;
+        var tid = this.value;
       }
+      Drupal.projectSetTaxonomy(tid);

All I can think of is that this may break JS entirely now if this.checked == false.

However, what's the default? undefined?

Powered by Dreditor.

The real bug is that the .click() event is bound all over again. Only in a second attempt I realized that the entirely wrong indentation of this behavior led to this bug.

This time for real.

+++ usage/project_usage.module	9 Mar 2010 22:02:38 -0000
@@ -164,7 +164,7 @@ function project_usage_flush_caches() {
-  if (user_access('view project usage') && $node->project_release['releases']) {
+  if (user_access('view project usage') && isset($node->project_release) && $node->project_release['releases']) {

oopsie... that hunk doesn't belong in here :P

Powered by Dreditor.

Without.

Rerolled.

Looks great to me, thanks for driving this home! I guess we need to coordinate with sun about fixing dreditor once this lands.

Fixed, thanks.

With this and #371957: Add customized per project type related vocabularies in, it would be a very good idea to remove the Drupal.behaviors.projectAuto override in dreditor once this stuff is deployed on d.o.

http://drupal.org/cvs?commit=358246

yay, thanks! I just need to know when this is deployed. Or better yet, I'll just remove Dreditor's override immediately.

EDIT: done, http://drupal.org/cvs?commit=358252

Fixing tag.

The fix has been deployed to drupal.org already.

However, the changes do not seem to be fully sufficient. The module categories are still reset to /dev/null when previewing an edited project node. Wasn't able to figure out the exact conditions yet; here's what I have so far:

1. Edit a module project having categories
2. Select the first 10 categories
3. Not sure if relevant: Add some character garbage to project title, body, and revision log.
4. Hit Preview
5. Not sure if relevant: Just click the project type "Modules", don't change it
6. Hit Preview again
7. All categories lost

Important: Make sure to disable Dreditor when trying to reproduce.

I don't think this is relevant now.

In D6, if I remember correctly, there was one hierarchical taxonomy for project type (theme/module/etc) and module category. We don’t do this in D7.