Building a Front-End User Profile Editor with GreenShift Forms

Introduction

I recently saw several discussions in the GreenShift Facebook group where people seemed to have unrealistic expectations about what the native form element in GreenLight can do. Let me be clear up front: GreenShift forms are not replacements for full-featured form plugins like Fluent Forms, Gravity Forms, or WS Forms. They’re not trying to be.

But there are specific use cases where GreenShift’s form blocks are actually the better choice. This tutorial walks through one of those cases: building a front-end profile editor for logged-in users.

The Problem I Was Solving

I’m working on a website for a daycare center where children stay after school for homework help, games, and activities until their parents pick them up. The parents need accounts on the website to receive information about their children and upcoming events.

WordPress gives every user access to edit their profile in wp-admin, but let’s be honest — the WordPress admin dashboard is a confusing mess for anyone who isn’t already familiar with it. I didn’t want to force parents to navigate through that interface just to update their phone number or change their email address.

So I built a simple profile editor right into the front-end, using GreenShift blocks. Parents click an “Edit” button on their profile page, make their changes, and save. No wp-admin required.

Why GreenShift Forms Made Sense Here

Here’s why I chose GreenShift forms over a dedicated forms plugin for this:

Full control over the UI: I’m building the entire page in GreenShift anyway. Having the form as native blocks means I can style it consistently with the rest of the page without fighting against a form plugin’s CSS.

Direct data access: I’m not collecting data to be processed later — I’m directly updating WordPress user data. Form plugins add layers of abstraction that I don’t need here.

No plugin overhead: Why load an entire forms plugin just to handle three fields for logged-in users? That’s overkill.

Simple validation: I only need to validate an email address and ensure the nonce is valid. I don’t need complex conditional logic or multi-step workflows.

The key insight here is that GreenShift forms work best when you’re doing something specific and controlled. Public contact forms? Use a real forms plugin. Complex data collection? Use a real forms plugin. But for targeted user data editing like this? GreenShift forms are perfect.

What We’re Building

By the end of this tutorial, you’ll have:

• A display panel showing current user information (name, email, phone)
• An edit form (initially hidden) that appears when users click “Edit”
• Pre-populated form fields with current data
• Secure form submission with nonce validation
• Email change confirmation workflow (with a link sent to the new email)
• The ability to cancel pending email changes
• All built with GreenShift blocks and a few PHP/JavaScript snippets

What you’ll need:

• WordPress site with GreenShift/GreenLight installed
• Basic understanding of WordPress hooks and PHP
• A snippet manager like WPCodeBox (or the ability to add code to your theme)
• Familiarity with the GreenShift block editor

I’m providing all the code as downloadable resources, but I’ll walk through why each piece works the way it does. Understanding the reasoning helps you adapt this to your own needs.

Let’s get started.

Step 6: Things I Learned (and You Should Know)

Building this taught me a few things that aren’t immediately obvious from the WordPress documentation. Some of these are quirks, some are best practices, and some are just things that tripped me up along the way.

How WordPress Nonces Actually Work

I used to think WordPress nonces were like traditional nonces — used once and done. They’re not. They’re actually stateless cryptographic hashes generated from:

• A time chunk (12-hour windows)
• The action name
• The user ID
• The session token

This means they’re valid for 12-24 hours and aren’t stored anywhere. When WordPress verifies a nonce, it just regenerates the hash and compares. This also means:

• Multiple nonces on the same page work fine — they’re independent
• They protect against CSRF (cross-site request forgery) attacks
• They DON’T protect against authenticated users doing bad things within their permissions
• Logout invalidates all nonces for that user
• They’re user-specific — User A’s nonce won’t work for User B

You still need capability checks and rate limiting. Nonces are just one layer of security.

GreenShift Forms Don’t Inherit Fonts

This drove me crazy for longer than I’d like to admit. GreenShift form fields don’t automatically inherit font-family from their parent containers. You need to explicitly set it:

.acf-form-fields {
    font-family: inherit;
}

.acf-form-submit input[type="submit"] {
    font-family: inherit;
    cursor: pointer;
}

.acf-form-fields {
    font-family: inherit;
}

.acf-form-submit input[type="submit"] {
    font-family: inherit;
    cursor: pointer;
}

Input buttons are especially stubborn — sometimes you need to target the container too:

{CURRENT} * {
    font-family: inherit;
}

{CURRENT} * {
    font-family: inherit;
}

The Form Action Attribute Matters

This seems obvious in retrospect, but when I first built this, I left the form action empty thinking it would just post to the current page. Wrong. GreenShift forms need an explicit action:

<form method="post" action="/wp-admin/admin-post.php">

<form method="post" action="/wp-admin/admin-post.php">

Without it, you get unpredictable behavior depending on the page structure.

Hidden Fields Need Both ID and Value

Another “should have been obvious” gotcha: the hidden action field needs a value attribute, not just an ID:

<!-- Wrong -->
<input type="hidden" name="action" id="action">

<!-- Right -->
<input type="hidden" name="action" id="action" value="edit_user_profile">

<!-- Wrong -->
<input type="hidden" name="action" id="action">

<!-- Right -->
<input type="hidden" name="action" id="action" value="edit_user_profile">

WordPress looks for the value, not the ID.

WPCodeBox Snippet Execution Context

If you’re using WPCodeBox (or a similar snippet manager), make sure PHP snippets that handle admin_post hooks are set to run on both frontend and admin, not just on the frontend. The admin-post.php endpoint is technically in the admin context even though you’re calling it from the front-end. This tripped me up during testing — the handler just wouldn’t fire until I changed this setting.

Email Deliverability is Critical

WordPress’s default wp_mail() function uses PHP’s mail(), which many hosting providers have configured poorly (or blocked entirely). Use a proper SMTP plugin like FluentSMTP or WP Mail SMTP. Configure it with a real SMTP service (Gmail, SendGrid, Mailgun, whatever) so that your confirmation emails will actually reach users.

The Phone Field Name

Throughout this tutorial I’ve used phone_no as the meta key for phone numbers. This is specific to my setup. Make sure you adjust this to match whatever field name you’re actually using:

$phone = get_user_meta($user_id, 'your_actual_field_name', true);

$phone = get_user_meta($user_id, 'your_actual_field_name', true);

Check your existing user meta or create the field with your preferred naming convention.

Browser Compatibility Note

The JavaScript uses the Fetch API, which works in all modern browsers but not in Internet Explorer 11. If you need IE11 support (and honestly, you probably don’t in 2024), you’ll need to use XMLHttpRequest instead or include a fetch polyfill.