When a WordPress sign-up field and LearnDash groups stop talking to each other

We recently helped an Irish organisation whose WordPress site runs a courses that people sign up for, and on the face of it everything was ticking along nicely. People registered, picked their organisation from a dropdown and got access to what they needed. But when the team went to export their user data, loads of people were showing up as belonging to ‘Other’ – even though behind the scenes they’d been carefully put into the right organisation.

It’s one of those problems that’s really easy to miss because nothing is actually broken… the site works, people can log in, the courses load. It’s only when two bits of data that should agree with each other turn out not to that you notice anything. So here’s what was going on, how we tracked it down, and how we used AI to fix it properly – including for all the people who’d already slipped through the gap.

What was actually going wrong?

The site uses LearnDash (a WordPress plugin for running online courses) and leans on LearnDash’s groups feature to keep track of which organisation each person belongs to. LearnDash lets you rename its labels, so on this site ‘Groups’ are called ‘Organisations’ everywhere.

When someone signs up, they choose their organisation from a dropdown on the registration form, and that choice adds them to the matching organisation group in LearnDash. Simple enough. But obviously not every organisation is going to be in that list, so people are told to pick ‘Other’ if theirs isn’t there. And if you pick ‘Other’, you don’t get added to any group at all.

So the team would follow up with each of those people, find out which organisation they were actually from, create that organisation as a new group in LearnDash and then add the person to it from their user profile in the WordPress admin. Which is exactly the right thing to do… but the organisation field from the sign-up form is a completely separate piece of data, stored against the user’s account, and there’s no editable version of it on the profile page. So nobody could update it, and it stayed set to ‘Other’ – even once the person was sitting in the right group.

Why did it only show up when exporting user data?

For a long time this didn’t really matter. The LearnDash groups were all correct, and that’s the bit LearnDash actually uses, so day to day nobody would have noticed anything was off.

It came to light when the team started exporting user data with User Insights (a WordPress plugin for filtering, analysing and exporting your users). User Insights happily pulls in the custom fields from the sign-up process, including that organisation field, but it doesn’t seem to include LearnDash group membership – or at least not in a way that was usable here. So the one column in the export that said which organisation someone belonged to was the one that was wrong for loads of people. Here’s how the two bits of data compared:

	LearnDash organisation group	Sign-up form organisation field
Set when someone signs up?	Yes (unless they pick ‘Other’)	Yes
Can admins change it from the user’s profile?	Yes	No
Updated when ‘Other’ sign-ups were sorted out?	Yes	No
Included in the User Insights export?	No	Yes

(Couldn’t you just export from LearnDash instead? You could probably cobble something together, but the team wanted everything in one export alongside all the other sign-up fields. And stitching two spreadsheets together every time you need a report isn’t really a fix – it’s a chore.)

How did we stop it happening again?

The first job was making sure every group assignment from now on keeps the two in sync. LearnDash fires an action (basically a little announcement that other code can listen out for) whenever a user is added to a group, so we hooked into that. Now, whenever someone is added to an organisation group – whether that happens at sign-up or the team adds them from the admin later – a small function updates their sign-up organisation field to match. Here’s a stripped-back version of the idea:

add_action( 'ld_added_group_access', function ( $user_id, $group_id ) {
    $organisation = get_the_title( $group_id );
    update_user_meta( $user_id, 'organisation', $organisation );
}, 10, 2 );

(If you’re thinking of borrowing this, ‘organisation’ is a stand-in for whatever your sign-up form actually saves the field as – every form plugin names these things differently.)

The really nice thing about doing it this way is that the team don’t have to change how they work at all. They carry on adding people to organisations from the profile page exactly as before, and the field just keeps up in the background.

What about everyone who was already stuck on ‘Other’?

That sorts things out going forward, but there were already lots of people sitting in the right group with ‘Other’ still against their name. So we also needed a one-off backfill (a script that goes back through the existing data and corrects it in one go, rather than someone doing it by hand). It works through things like this:

1. Find every user whose sign-up organisation field is set to ‘Other’.
2. Check whether they’ve since been added to an organisation group in LearnDash.
3. If they have, update the organisation field to the name of that group.
4. If they haven’t, leave them alone – they’re genuinely still waiting to be sorted.

Doing that by hand would have meant opening each person’s profile, checking their groups and then going into the database to change a field that has no edit box… for every single one. The script did the lot in one go, and because it only touches people set to ‘Other’ who are definitely in a group, it can’t overwrite anything someone chose for themselves. (And obviously, take a backup before you run anything that changes user data in bulk!)

Although, every time I write one of these I stop and question myself… what if someone is in more than one organisation group? It might never happen, but it’s worth deciding up front which one should win, rather than leaving the code to pick for you.

Where did AI actually help?

We used Claude (an AI assistant made by Anthropic) to write both functions, and it’s a really good example of where AI earns its keep. The hard part of this job wasn’t the code – it was working out what was going on. That LearnDash groups and the sign-up field were two separate things, that one was editable and one wasn’t, and that User Insights only saw one of them… that all came from knowing how WordPress, LearnDash and User Insights fit together, and from asking the right questions.

Once we’d pinned the problem down, describing it clearly to Claude meant we had working drafts of both functions really quickly, rather than spending a chunk of time looking up hook names and writing boilerplate. We still read through the code and checked it properly before letting it anywhere near real user data, because AI is super quick but it doesn’t know a client’s site the way we do. Roughly, the split looked like this:

Job	Who did it
Noticing the export didn’t match the organisation groups	Us
Working out why the two had drifted apart	Us
Writing the sync function and the backfill	Claude
Reviewing, checking and running the code	Us

And that’s the bit I think gets lost in a lot of the AI conversation at the moment. It didn’t replace the expertise – it just meant the expertise turned into a fix much faster, which is better for the client and their budget.

Could the same thing be happening on your site?

If your WordPress site has a sign-up form that feeds into something else – LearnDash groups, membership levels, WooCommerce customer details, whatever it might be – it’s worth having a quick look at whether the two stay in step when someone changes things in the admin later on. The giveaway is usually an export or a report that doesn’t match what you can see on screen. A few things to have a think about:

• Where does each bit of data actually live, and which one does your export or reporting read from?
• When an admin changes something on a user’s profile, does it update everywhere, or just in one place?
• Are there ‘Other’ or default options on your forms that someone has to sort out by hand later?
• Is there a field that people can fill in at sign-up but nobody can edit afterwards?

If any of those make you go ‘hmm’, it’s probably worth a closer look before your next big export. And if you’d like a second pair of eyes on it, get in touch – this kind of detective work is one of out favourite bits of the job!