Add a project creation landing page

We keep running into this. ;) I wonder if we can generalize these landing pages at all via some shared functions. But yeah, we do need this.

Devil's advocate: Upon further reflection, why do we need a separate landing page? What's wrong with node/add?

Unlike the other landing pages where we need to know the parent project before we can add a release or issue, this would just be a page to group all the project node types into one screen. Basically just providing a subset of the node/add landing page. I know it might be nice to have a "Create a new project" link in various places that just gave you the project-enabled node types as options, but this seems like a minor feature request, not a launch-blocking need.

Thoughts?
-Derek

I really like the idea of remaining standardized on the node/add/* path, especially because other contrib modules generally presume that this is true. As @dww points out in #2 above, we don't seem to *need* a special landing page from a workflow or a functionality standpoint, so it's just a matter of making sure that when adding a new project node, one can see what other project node types already exist, right?

Do it. (@dww, you wanna take this one?)

In D6, at the bottom of the table of projects at the top of the Your Projects page, there's an Add a new project link. The point of this issue is where does that link (or something like it) send you in D7? My proposal is it sends you to node/add, e.g.: http://git7site.devdrupal.org/node/add with no additional code or magic.

Sure, it'd be *nice* if it was a custom landing page like node/add but limited to the project-enabled node types (and if the site only had a single node type configured to act like a project, we could just directly redirect to node/add/project-whatever). However, that seems like additional coding we don't have time to do for a relatively small UX win.

I don't understand what this means:

so it's just a matter of making sure that when adding a new project node, one can see what other project node types already exist, right?

If you're at http://git7site.devdrupal.org/node/add/project-module I don't know why you need to know about other project node types. Can you elaborate?

Thanks,
-Derek

Here code for landing page :-)

Any suggestions are welcome.

#6: 0001-Issue-1801566-Added-a-project-creation-landing-page.patch queued for re-testing.

Awesome, thanks! A few minor concerns before this is ready:

A) I'm not sure /project/add is a good path for this. We've historically done all sorts of horrible things to the /project/ URL namespace, and I'd like to think carefully before claiming another reserved word for this.

B) Cut + paste description bug:

+    'description' => t('Configure system-wide settings for the Project module.'),

C) I always prefer return drupal_goto().

D) I'm glad you're doing something sane in the case there are no project types configured. However, ideally it would only show the "Configure one of the available content types to be a project." part to users with 'administer content types' permissions, and perhaps include a link to admin/structure/types for them. ;) And while we're changing this error message, perhaps the first part should say something like "There are no content types available to be projects." or "There are no content types configured to be projects."

Thanks!
-Derek

Thanks for the feedback :-)

A) I think it is a meaningful url, but I am open to suggestions.
B) Fixed.
C) drupal_goto() does not have a return value, so return is not needed (i.e. core never use return when using it), so I think it's ok, but I am curious about the reason of using it.
D) You are right, I changed it to make more sense.

A) It is meaningful. I'm just reluctant to use another /project/[whatever] without a plan. ;)

B) Thanks. Although we're never supposed to use the word "node" in the UI. ;)

C) It's not the return value from drupal_goto(). It's about preventing anything else from being executed in the function. There have been various security bugs in Drupal over the years from people calling drupal_goto(), expecting that to abort a function, and then letting things that were supposed to have been prevented by the goto happen later in the function. So, I'm always in the habit of using return drupal_goto() to ensure that nothing else happens once I decide to redirect somewhere.

D) Thanks. Looks great.

Doesn't the return on goto break all shutdown/exit functions? This cannot good/correct... It also breaks caching (varnish, etc.) in many situations if you don't run the shutdown stuff as headers may not correctly set. I may be wrong here, but in general this is the way how it should not implemented with propper coding.

@hass: No. exit()would do that. return just ends the current method, but all exit hooks still happen. This is absolutely proper coding.

Perhaps what you're confusing this with is directly calling drupal_goto() inside a form submit handler, instead of setting $form_state['redirect']. But that's not what's happening here, either.

A well... Nobrainer. Sorry

Committed this and a followup with dww's drupal_goto() suggestion, and I moved some logic out of the theme function: http://drupalcode.org/project/project.git/commitdiff/a43c8a4?hp=3ee37bfb...