Make WordPress Core

Opened 13 years ago

Closed 11 years ago

#19451 closed enhancement (fixed)

Cannot distinguish which WordPress Signup stage I am

Reported by: cimmo's profile Cimmo Owned by: nacin's profile nacin
Milestone: 3.7 Priority: normal
Severity: normal Version: 3.3
Component: Multisite Keywords: has-patch
Focuses: Cc:

Description

As a plug-in developer under WordPress MS I would like to recognize at which stage I am of the signup:

  1. first page because of some errors
  2. blog confirmation page in case of no errors

Unluckily as today we have:
<input type="hidden" name="stage" value="validate-blog-signup" />

that is the same for the whole process instead would be nice to have a different value there.

Plus we have:
<?php do_action( 'signup_hidden_fields' ); ?>

But even this action is called in both stages.

So how about start naming the stages differently and also call different actions?
For example I want to include some hidden fields only when I am sure all errors are gone and I am already on confirmation of blog name stage.
I don't see this possible right now.

Attachments (6)

patch.diff (2.4 KB) - added by Cimmo 13 years ago.
New proposed patch that passes tje stage as parameter to the action
patch2.diff (1.7 KB) - added by Cimmo 13 years ago.
New proposed patch with no variable
19451.diff (1.7 KB) - added by jeremyfelt 11 years ago.
19451.2.diff (1.7 KB) - added by jeremyfelt 11 years ago.
19451.3.diff (2.2 KB) - added by jeremyfelt 11 years ago.
19451.4.diff (2.0 KB) - added by jeremyfelt 11 years ago.

Download all attachments as: .zip

Change History (23)

#1 follow-up: @scribu
13 years ago

  • Keywords needs-patch added

I think it would be better if we pass the stage as a parameter to the action, instead of renaming it.

#2 in reply to: ↑ 1 @Cimmo
13 years ago

Replying to scribu:

I think it would be better if we pass the stage as a parameter to the action, instead of renaming it.

But also the stage is always the same! Form id same. Everything is a copy/paste so very hard to understand at which page I am exactly.

EDIT: Nevermind what I said, I am providing a patch already.

Last edited 13 years ago by Cimmo (previous) (diff)

#3 @Cimmo
13 years ago

  • Component changed from General to Multisite

@Cimmo
13 years ago

New proposed patch that passes tje stage as parameter to the action

#4 @Cimmo
13 years ago

  • Keywords has-patch added; needs-patch removed
  • Severity changed from normal to minor

#5 @scribu
13 years ago

That looks better, but I don't think the $stage variable is necessary. Just pass the string directly; so that it matches the one in the hidden <input>.

@Cimmo
13 years ago

New proposed patch with no variable

@jeremyfelt
11 years ago

#6 @jeremyfelt
11 years ago

  • Milestone changed from Awaiting Review to 3.7
  • Severity changed from minor to normal

19451.diff is a refresh of Cimmo's patch2.diff. Adds a parameter to the signup_hidden_fields action to differentiate between multiple uses in wp-signup.php.

#7 @nacin
11 years ago

I know gimmeanotherblog is the name of the form, but could we come up with something we'd be willing to support in the future? another-blog-signup, perhaps. And optionally s/blog/site/ across the board.

@jeremyfelt
11 years ago

#8 @jeremyfelt
11 years ago

19451.2.diff simplifies things to create-site, validate-user, and validate-site. Not sure if attaching -signup to each step was necessary, as the action is already signup_hidden_fields.

@jeremyfelt
11 years ago

#9 follow-up: @jeremyfelt
11 years ago

19451.3.diff adds docs to each of the 3 actions.

#10 in reply to: ↑ 9 ; follow-up: @DrewAPicture
11 years ago

Replying to jeremyfelt:

19451.3.diff adds docs to each of the 3 actions.

Since this is the same hook used three different places, just write a single doc block for the first one. We should probably have a long description citing the different contexts available via the passed string.

Then just mark the other two actions with //duplicate_hook (no space)

#11 @jeremyfelt
11 years ago

  • Keywords needs-docs added

#12 in reply to: ↑ 10 ; follow-up: @jeremyfelt
11 years ago

Replying to DrewAPicture:

Replying to jeremyfelt:

19451.3.diff adds docs to each of the 3 actions.

Since this is the same hook used three different places, just write a single doc block for the first one. We should probably have a long description citing the different contexts available via the passed string.

Then just mark the other two actions with //duplicate_hook (no space)

This makes more when a hook is used multiple times in one function. A little less when we're dealing with hooks in 3 different functions. If we use //duplicate hook, should it also point to the function where the hook is documented?

#13 in reply to: ↑ 12 ; follow-up: @DrewAPicture
11 years ago

Replying to jeremyfelt:

This makes more when a hook is used multiple times in one function. A little less when we're dealing with hooks in 3 different functions. If we use //duplicate hook, should it also point to the function where the hook is documented?

Nope. //duplicate_hook is the grep-able solution nacin came up with. I have the impression all the duplicate hooks will be tied together with their primaries via some kind of magic on the other end.

#14 in reply to: ↑ 13 @nacin
11 years ago

Replying to DrewAPicture:

Replying to jeremyfelt:

This makes more when a hook is used multiple times in one function. A little less when we're dealing with hooks in 3 different functions. If we use //duplicate hook, should it also point to the function where the hook is documented?

Nope. //duplicate_hook is the grep-able solution nacin came up with. I have the impression all the duplicate hooks will be tied together with their primaries via some kind of magic on the other end.

Basically, rather than re-documenting the same hook in multiple places, I figured something simple like this would be much easier to study our duplicate hooks and make a determination on what to do. We'll need to make sure "duplicate" filters are actually used in similar contexts, receive the same arguments, etc. Yes, we'll probably only document a hook once in a function, and yes, we'd like to document even a duplicate hook that is elsewhere (just because we're pulling it into the code reference doesn't mean inline documentation shouldn't also serve its purpose as informing a reader of the code). This just tries to punt on that for the moment.

@jeremyfelt
11 years ago

#15 @jeremyfelt
11 years ago

Sounds like a plan. 19451.4.diff uses //duplicate hook and consolidates the docs in the first instance a bit.

#16 @jeremyfelt
11 years ago

  • Keywords needs-docs removed

#17 @nacin
11 years ago

  • Owner set to nacin
  • Resolution set to fixed
  • Status changed from new to closed

In 25600:

Context for the signup_hidden_fields hooks.

props jeremyfelt, Cimmo.
fixes #19451.

Note: See TracTickets for help on using tickets.