IT Hertz

On my client’s site, the user fills out a relatively complex CF7 form for their school, on which the user makes class and payment schedule selections. The students, max 5 per parent/user, are then sorted according to class levels, and the associated product and price values are sent to WC, among other things.
With a single click of the Submit button, the following occurs:
1. new user WP account is created
2. account is populated (or updated) with WC user_meta
3. WC order is generated
4. various custom emails are sent to school personnel and the customer
5. several other operations happen behind the scenes

There’s a hold placed on each order and site access/login is blocked until the client approves the user’s application form. Once approved, the user is taken to a page upon login which explains how the user needs to pay (school has specific payment processes). There’s a button on that page, which takes the user directly to checkout when they’re ready to proceed, and in checkout they’re presented with payment options for completion of the order.

Once that initial order goes thru, the user can’t check out again with the same order without the admin soft-cancelling the order via aforementioned status change. Without the admin changing status, the user would have to fill out the complex form again so the order could get compiled and go thru the whole process all over again. With the order status change, the user can just login again and be taken to checkout and done.

The need for quick and easy repeating of the same order is in cases where a user’s role needs to be changed, based on other various things that occur on the site (I’ve set up many different roles/levels for users and school staff), or if a simple order edit is needed. The order number needs to be retained as well, for site operations and bookkeeping purposes.

Basically, instead of the CF7 form submission firing events/functions to make WC (and UM) do things, I want the order status change in WC’s admin UI to fire functions that make UM and WP account handler do things.
A major reason I want to do all of this by just changing the order status is to make things easy for subadmins, for whom I’ve created simple/limited UIs. The fewer controls they have to use, the better.

I see there’s this for detecting the change:

woocommerce_order_status_changed as in:
do_action( 'woocommerce_order_status_changed', $this->get_id(), $status_transition['from'], $status_transition['to'], $this );

Now to do the role changes and use different email templates to send out different notifications of the reorder.

Ok, I’ll try those, thanks.

You’re splitting hairs. The UM plugin contributor(s) at that time, sporting the official orange tag and ostensibly working directly with the dev team, provided the fix for the non-functional reset link tag.
For all intents and purposes, v2 could be considered officially an adjunct part of the plugin, since it made it functional. Without it, the reset password link simply was not working in the reset email template back then. Obviously, the plugin was changed later by UM, which killed v2 functionality, and so now the original tag name works instead.

Unfortunately, despite the fact that it was the official plugin contributor(s) who recommended the v2 fix in the first place, UM saw fit to not bother including mention of this reversion to the original tag name sans “_v2” in the official support docs, instead sending users on a wild goose chase by asserting that the culprits are without doubt caching and/or cookie blockage. As it turns out, these have absolutely nothing to do with the problem where v2 is still being used. This is not even alluded to at all in any of the support pages I found. Either this was intentional, or whoever wrote up the support docs had no knowledge of the v2 cure. Sinister or incompetent.

That one little sentence in the docs would have saved me hours and frustration in troubleshooting, even involving my host’s tech support personnel. UM should have alerted users to remove those 3 chars from their v2 email tag and password reset will probably work for them again. Hopefully, anyone else reading this thread will be spared that lost time and aggravation.

I never used UM to send a welcome email. In fact, I disabled the welcome email because of how the school wanted the rest of the site to handle registration — I only use UM for the login, reset/change password, and role-based restrictions.
I created a relatively complex CF7 form for simultaneously registering parents with the site, registering their kids with the school, placing tuition orders in WC, and sending out relevant emails to various parties, all with a single Submit button click.
So, no, I did not use v2 in the welcome email template. I used it in the password reset email template. Like the GitHub code comment says, it was to be used in any email template. And that’s what UM users did back then, and that’s what made reset work. And no, I didn’t code any additional functions to go beyond v2, and yes, I used UM’s built-in template editor.

ffs.. No wonder! There WAS a {password_reset_link_v2} last year when I was building this site, because UM advised us to use that in our email templates, in order to fix an issue with the link.
Here’s a thread that proves it existed: https://www.ads-software.com/support/topic/password_reset_link-not-working-in-account-welcome-email/

And this: Ultimate Member – Password Reset Link in Welcome Email · GitHub
// Usage: Add this short tag to any Email Template in UM > Email settings: {password_reset_link_v2}
/**
* UM Placeholders for reset password
*
* @param $placeholders
*
* @return array
*/
function um_121520_add_placeholder( $placeholders ) {
$placeholders[] = '{password_reset_link_v2}';
return $placeholders;
}
add_filter( 'um_template_tags_patterns_hook', 'um_121520_add_placeholder', 10, 1 );

Evidently, I never got the memo or saw anywhere in UM docs that devs had renamed the fixed version back to {password_reset_link}. Much time wasted on this, but it’s working now that I removed “_v2” from the tag.

As I needed this resolved immediately, I went ahead and redesigned the emails (e.g., simplified divs). Looks good during test emails to myself, but will wait and see what happens with real world users. I’m not marking this resolved for that reason and due to the fact that an update did cause this issue.

Well, yes, that does work in terms of having the field adhere to CF7’s default behavior of a visible placeholder on form load and when manually clearing the field. It’s not quite what I had in mind as far as overwriting only the underscores and leaving the rest of the placeholder intact, since it deletes the entire placeholder on initial user input, just like CF7 does by default. I don’t know whether you had a look at that other plugin, but the author overrides CF7’s placeholder behavior.

It’s not a biggie, just aesthetic preference. At least my form now informs users what the phone string is going to look like when they’ve filled in the field, which is plenty good enough.

I set clearIfNotMatch to false in order to also have a minlength:14 error prompt on failure to complete the phone number. Works like a charm, thanks for the plugin!

After trying various ways, I see now. Default must come before placeholder in tag options. That does work.

That’s not clear from your docs, as the table flow shows placeholder above/before default. And, since default doesn’t appear in your text example and placeholder doesn’t appear in your default example, I incorrectly assumed the table order indicated syntax/option order, but it’s reversed.

Is it safe to assume that because the default option doesn’t appear in the table spec for date type that this is not currently available? And, because default is the item number/position with dropdowns, checkboxes and radios this means this selection is hard and cannot be pulled from the meta data (i.e., if I were to translate the meta data to an item number in functions.php it still can’t be passed to the field)? This would be helpful, as I use a lot of these field types in my form as well.

It should be relatively simple. The plugin could check if the specified default data exists. If not (null), then use the placeholder and ignore the default tag parameter.

I jumped the gun on my post and unfortunately there’s no delete button. The issue is with CF7 not allowing placeholders and defaults to be used in the same tag.
I’ve contacted Takayuki Miyoshi about possibly allowing conditional tags, so that defaults override placeholders to prefill fields for logged-in users and placeholders show for new/unregistered users.

How do you achieve this?

With the built-in tag function: https://contactform7.com/setting-default-values-to-the-logged-in-user/

In this particular case, my client is a dance school. I use a single CF7 form to perform the following functions:
Apply for site registration to access exclusive Parent Portal content
Apply for school registration of their child(ren)
Sort dancers by class & strip all but 2 highest levels (all others train free)
Sign application form (sign the box or upload existing sig file)
Create tuition order for the 2 highest levels (or single item if 1 dancer)
Create separate WooCommerce account
Send application emails to school staff; modified copy goes to applicant
Send WC email of payment to bookkeeper; modded copy to applicant
Copy all data to separate database plugin for review/revision by school staff

My goal was to automate the process as much as possible, so all of the above is carried out with one click of the submit button. There’s a separate checkout page for making payments, of course.

An example of how I use placeholders on my form is my Emergency Contact fields. I have two of them, because separating first and last names and splitting into separate meta data entries is better for filing/spreadsheet purposes. I use the same label for both, because long labels such as “Emergency Contact First Name” cause display issues (wraps, pushes fields down on mobile due to the field widths being reduced, etc.). It’s really messy looking. Hence, I use placeholders like so: [text* Emergency_Contact_First_Name placeholder "First Name"], same for Last Name field.

It would be helpful to have conditional tags, where the default would override the placeholder in the case of a logged-in user, else the placeholder is used, like so: [text* Emergency_Contact_First_Name placeholder "First Name" default:user_emergency_contact_first]

I have several other fields that guide the new user with placeholders. I really would rather not use hover tooltips for this particular form – they would also be pointless for logged-in users, so unless the tooltips are conditional, it would look odd presenting them to existing users who are already familiar with the form and whose data is prefilled to begin with.

As mentioned before, I can create a duplicate form if need be, for the sole purpose of using placeholder tags, and use redirects for logged vs. non-logged users to take them to the appropriate form, but having two [almost] identical forms seems redundant and a waste of storage space.

Btw, it would also be helpful to preset/prefill all other field types, such as calendar, dropdowns, etc. I haven’t checked whether this is already covered, but if default only prefills text fields, adding the other field types would be great.

• This reply was modified 1 year, 3 months ago by IT Hertz. Reason: last paragraph

Thanks for the update. It restores the form to its original appearance.

I fixed the overlay by giving the icon a background color that matches the form page and setting left padding and margin to conceal the bullets (necessary with FF, since it uses huge bullets, and on mobile devices, where the fields are reduced in width).
However, I’m having trouble pushing the icon down, as top margin/padding don’t work. I tried to set a flexbox to align the items that way, but no joy. My fields are a little taller than default height, and the icon isn’t quite centered vertically.

At any rate, I see the onclick="pushHideButton('Password') attribute. I haven’t looked at your js to see what the listener is doing, but this isn’t working in any browser.

Fixed. The problem was my Select2 CSS. It was preventing the rest of the dropdown box from being displayed past the first rendered item. It’s still a mystery why it didn’t affect the previous version of WC.

So was I.

I didn’t see it mentioned in the list. Can you be more specific?

There is a conflict with my theme, specifically my modifications to the Customify theme. Other themes work, and the stock Customify theme works.

The previous version of WooCommerce is working on my production site with the exact same theme modifications that are NOT working on my staging site with the latest WC update. I have changed nothing between the two sites. They are identical other than the staging site receiving the WC update.

Thus, your update has introduced a conflict. While a search can still be performed, it is now more difficult/annoying when I or my subadmins need to create a new order where numerous, similarly titled products exist.

I need to know what you changed regarding the dropdowns, more specifically the product search in the backend. My presumption at this point is that you’ve changed something regarding Select2 handling.
I will need to add several similar usernames on my staging site to check whether this conflict also occurs with the user search.