WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 17 months 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:

  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 3 years ago.
New proposed patch that passes tje stage as parameter to the action
patch2.diff (1.7 KB) - added by Cimmo 3 years ago.
New proposed patch with no variable
19451.diff (1.7 KB) - added by jeremyfelt 19 months ago.
19451.2.diff (1.7 KB) - added by jeremyfelt 18 months ago.
19451.3.diff (2.2 KB) - added by jeremyfelt 18 months ago.
19451.4.diff (2.0 KB) - added by jeremyfelt 18 months ago.

Download all attachments as: .zip

Change History (23)

comment:1 follow-up: @scribu3 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.

comment:2 in reply to: ↑ 1 @Cimmo3 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 3 years ago by Cimmo (previous) (diff)

comment:3 @Cimmo3 years ago

  • Component changed from General to Multisite

@Cimmo3 years ago

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

comment:4 @Cimmo3 years ago

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

comment:5 @scribu3 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>.

@Cimmo3 years ago

New proposed patch with no variable

@jeremyfelt19 months ago

comment:6 @jeremyfelt19 months 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.

comment:7 @nacin18 months 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.

@jeremyfelt18 months ago

comment:8 @jeremyfelt18 months 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.

@jeremyfelt18 months ago

comment:9 follow-up: @jeremyfelt18 months ago

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

comment:10 in reply to: ↑ 9 ; follow-up: @DrewAPicture18 months 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)

comment:11 @jeremyfelt18 months ago

  • Keywords needs-docs added

comment:12 in reply to: ↑ 10 ; follow-up: @jeremyfelt18 months 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?

comment:13 in reply to: ↑ 12 ; follow-up: @DrewAPicture18 months 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.

comment:14 in reply to: ↑ 13 @nacin18 months 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.

@jeremyfelt18 months ago

comment:15 @jeremyfelt18 months ago

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

comment:16 @jeremyfelt18 months ago

  • Keywords needs-docs removed

comment:17 @nacin17 months 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.