I'm confused about how the custom tokens work at site-level versus client-level

In a relatively newer release MainWP introduced having clients. And then clients could then “own” various sites.

A small problem arose because my custom tokens became “Client Fields”. As an example, I have a token called “client.plan” that shows what plan the website belongs to (silver, gold etc).
This client owns many websites on plans, but not all the plans are the same across sites.
This broke my reports because all the reports for all sites showed “Silver” plans for example, instead of being individual per-site. This is because Silver got set on the client field on the client edit page.

I was able to fix that by editing each site and entering the token info again. When I changed the token within the individual sites, it was corrected in the reports.
How does this work exactly? Do the tokens on the client take precedence only when tokens on the site itself are not edited? And if I leave the token un-edited on the site, does the token at the client-level take over instead?

Part of me thinks we should have two sets of custom tokens here; those that are set at the client level, and another set of custom tokens we can set per-site. It doesn’t make sense to have tokens that are only meaningful per-site, to be located at the client level, unless they are only used as defaults or something.

It makes total sense to me that we might want special tokens that apply only to a client, and other tokens that only apply per-site. Right now the system acts like these “Client Fields” are specifically a client-only thing, but then they show up on the site edit screen too, so it’s confusing. Is it a client thing, or a site thing, or trying to handle both at the same time?

Maybe the UX for this just needs to be improved if nothing else changes. Just call them “Custom Fields” generically and not act like they are only part of the client instead of part of the site. When I open the Clients menu, I see Client Fields. When I open the Sites menu, I don’t see “Site Fields” for example. Again, it’s just a little confusing in the UX. They are not just “Client Fields” if they are acting as site fields too.

Thanks for considering!

Hi @zackw

The tokens defined per-site (on the Edit page of a Child Dashboard) have priority over tokens defined for the Client. If site token is left empty, the Client token is used in the report.

Client Fields are a client-only thing.
The site-only tokens are available on the Dashboard > Extensions > Pro Reports > Tokens page. You can edit, delete and create new tokens here.

It may be somewhat confusing that the site-only tokens also named [client.*], and that many of them have identical names to the ones defined per Client.
However, they are indeed different, and if the token with the same name (e.g. [client.email]) is defined for a site and for a client, the site token will be used.

Ok I see.

If there is a token in the Client Tokens that has the same name as the Pro Reports tokens screen, should I delete one or the other? I don’t believe I did it this way manually, I think the system picked it up after the client tokens were added? No idea.

So if Pro Reports has a custom token “client.plan”, I should delete the token with the same name in the client token area? It’s redundant in that case, as I don’t need a “default” for tokens like client.plan.

You don’t need to necessarily delete any of them.
You can just simply enter the value for a token field where it makes sense, either on a client level or a site level, and leave the other field empty. Pro Reports will prioritize the token entered for a site if both are entered.

If you don’t need that token on a client level, then sure, you can delete it but leaving it empty won’t interfere with Pro Reports functionality.

Thanks.

Last question about this. I understand how Pro Reports can create these tokens to be able to use within reports, but there could be a situation where myself or anyone might not need or want reports, but still wants some custom fields on their sites to store meta-data.

If I didn’t need Pro Reports any more, I assume I would lose all those per-site fields.
Is there a way to add meta data to sites that is just personal info and not dependent on plugins?

1 Like

Sure, you can create custom fields to the Child Site Edit screen as @bogdan explained in this discussion:

Thanks. Looks like I was already messing around with that a couple months ago. Bookmarked!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.