Opened 13 years ago
Closed 11 years ago
#19451 closed enhancement (fixed)
Cannot distinguish which WordPress Signup stage I am
Reported by: | Cimmo | Owned by: | 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:
- first page because of some errors
- 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)
Change History (23)
#2
in reply to:
↑ 1
@
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.
#4
@
13 years ago
- Keywords has-patch added; needs-patch removed
- Severity changed from normal to minor
#5
@
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>.
#6
@
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
@
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.
#8
@
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
.
#10
in reply to:
↑ 9
;
follow-up:
↓ 12
@
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)
#12
in reply to:
↑ 10
;
follow-up:
↓ 13
@
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:
↓ 14
@
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
@
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.
#15
@
11 years ago
Sounds like a plan. 19451.4.diff uses //duplicate hook
and consolidates the docs in the first instance a bit.
I think it would be better if we pass the stage as a parameter to the action, instead of renaming it.