Frequently Asked Questions (FAQ)

Getting the Project, Project issue tracking, and Project releases modules set up properly can sometimes be tricky. Often users run into one of the common problems below. If you have read through the rest of the project* documentation in this handbook and you question isn't answered below, first check the appropriate support queue and if there is not a relevant issue there you can create a support request issue:

• Project and Project releases support issues
• Project issue tracking support issues

Project and Project releases module

1. Why are some projects on my site not showing up in the project "browse by category", "browse by name", or "browse by date" pages?
   There are a few reasons why projects might exist on your site but not show up in the project listings. The first is that the project node is unpublished. The second, and most common problem, is that you have the Project releases module enabled and the project in question does not have any associated releases.

   When the Project releases module is enabled, the only projects that show up in the project listings are ones with one or more releases. On large sites like Drupal.org it makes sense to do this so that projects in their early stages do not show up to most users yet their developer(s) can still have the benefit of the project page and issue tracker. In the future there may be an administrative setting that will allow site administrators to determine whether projects without releases should be displayed. See http://drupal.org/node/156049 for more information.

2. After installing, uninstalling, and reinstalling the "Project Releases" module I am unable to add releases to my projects. Why?
   The "Project Releases" module depends on a 'Project release API compatibility' vocabulary, as described in the Project Releases documentation. When you initially install the module this vocabulary is created and the newly created vocabulary id is stored by the Project Releases module in the database. When the module is uninstalled the Project Releases module "forgets" about its associated vocabulary id, but does not delete the vocabulary because it may be used by other modules and nodes. When the module is reinstalled, the 'Project release API compatibility' vocabulary already exists but now needs to be manually associated with the Project Releases module (admin/content/taxonomy). There is a similar scenario with installing, uninstalling, and reinstalling the project module. These are not bugs, but behavior by design with these edge cases.

Project issue tracking module

1. When I edit an issue on my site, it gets separated/detached from the appropriate project. What is going on?
   This problem is commonly associated with issue #98278: project* namespace bugs in $node. Basically, many modules populate the $node object with their properties, and often different modules use the same property name for different things. For example, project module uses 'pid' for project id. The pathauto module uses 'pid' for path id. If project sets $node->pid but then another module comes along and changes $node->pid to something else, the issue will be unattached from the proper project. There's no real workaround for this right now, other than to not use modules known to have name space conflicts on your site or at least not on project and project_issue nodes. There's a patch for the issue mentioned above, but as of this writing it still needs work.

   Modules that are known to conflict with the project and/or project issue tracking modules include:

   • Book (core)
   • Path (core)
   • Pathauto
   • Category
   • Casetracker