Skip Navigation

[Resolved] First name field in notification email stopped working

This thread is resolved. Here is a description of the problem and solution.

Problem:

Shortcode in Toolset form email notification does not work, for example:
[wpv-user field='user_firstname' id="%%USER_USERID%%"]

Solution:

It is a known bug, It is fixed in next stable version of CRED(Toolset Form) plugin 2.1.

Relevant Documentation:

This support ticket is created 6 years, 7 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

No supporters are available to work today on Toolset forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.

Sun Mon Tue Wed Thu Fri Sat
- 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 -
- 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 -

Supporter timezone: Asia/Hong_Kong (GMT+08:00)

This topic contains 10 replies, has 3 voices.

Last updated by daveG-7 6 years, 6 months ago.

Assisted by: Luo Yang.

Author
Posts
#790453

Hello. Following this thread: https://toolset.com/forums/topic/cred-user-registration-first-and-last-name-fields-notification/ I put in the following shortcode in email notifications that are sent when a new user is registered:
[wpv-user field='user_firstname' id="%%USER_USERID%%"]

On my development site, that shortcode worked to call the first name of the user who used the registration form to sign up, but on the live hosting the field is blank in the emails with the same shortcode.

Both forms use the same shortcode for the user to enter their first name:
[cred_field field='first_name' post='user' value='' urlparam='' class='form-control' output='bootstrap']

I can see two possible differences between the sites that might explain the discrepancy. The first is that the live hosting uses PHP 7, while the old hosting used PHP 5. The second is that I have CRED 1.9.5 on the development site, while I've updated it to 1.9.6 on the live site. If you want, I can update CRED on the development site to see if this causes the issue there, too.

The debug info below is for the live site where the shortcode isn't working.

#792832

Hello,

The problem you mentioned above is abnormal, in case it is a compatibility problem, please try this in your website:

1) Upgrade CRED to the latest version 1.9.6.1 and Views plugin 2.5.2, you can download them here:
https://toolset.com/account/downloads/

2) deactivate other plugins and switch to wordpress default theme, and test again

3) If the problem still persists, please provide a database dump file (ZIP file) of your website in below private detail box, also point out the problem page URL and CRED form URL, I need to test and debug it in my localhost, thanks

#808023

Thanks for the details, it is a known issue, I have escalated this thread to 2nd tier supporters, our developers will take care of it.

#837930

Here is the feedback from our developers:

It is fixed in next stable version of CRED(Toolset Form) plugin 2.1, I am not sure when will it be released, you can subscribe to our blog to get the updated news:
https://toolset.com/blog/

#845086

Ok. Is there a place I can download the version that was previously working, CRED 1.9.5, to roll back to until the new version is out, or a patch that can be installed? I can't really have this issue on a live site indefinitely. Thanks.

#846850

I hope you don't mind me butting in on your thread; i have this issue on my sites too. Toolset support staff will normally refer users to a patch if there is one. All previous versions of each Toolset plugins are available for download here https://toolset.com/account/downloads/.

Personally, I don't think it's advisable to roll back to a previous version (for security reasons).

Luo: It's not acceptable for there to be no timeframe for a resolution to this issue. The fields form the backbone of email notifications and set a standard and a level of personalisation in the way we communicate with our customers, the benefits of which can't be underestimated. If there's a patch available, please confirm its location. If there is no patch then the developers need to prioritise this issue, provide a timeframe for its fix and suggest other ways of displaying the required content whilst we are waiting. Thank you.

#851512

Our developers have provided a hot-fix for it, you can try these:

1) Upgrade all Toolset plugins to the latest beta version, you can download them here:
https://toolset.com/download/

2) Apply the hot-fix, download it here:
hidden link

All the files: base.php, post.php and user.php must be saved in plugin folder
cred-frontend-editor\application\controllers\notification_manager\

Please test it and feedback if it is fixed or not. thanks.

And you can download old version of CRED plugin here:
https://toolset.com/download/toolset-cred/#changelog

#864820

Thanks Luo - much appreciated. Of the three options, I'd prefer to use the hotfix for now but the link is showing as 'hidden link' - can you provide an unhidden link please? Thank you!

#865937

@julieP, this is ticket created by daveG-7, so only he can see the google drive disk link, I can not unhidden the link to you, but you can create a new thread for it, where we can show you the google drive disk link

#866007

Ok I've created a thread of my own (https://toolset.com/forums/topic/email-notifications-custom-fields-body-codes-no-longer-displaying/).

I won't post here again but do you not think it's a bit ridiculous to hide the contents of a link for something like this? The contents aren't private to daveG-7; they're actually of use to anyone else who is experiencing this issue. All this does is make (extra) work for all of us. In a wider context, since you introduced hidden links, a lot of content in past threads has been rendered useless which means the forum doesn't provide the same level of self-help support that it used to. I'm all for not displaying link addresses for members' websites but the hidden links have been applied non-selectively; not helpful.

#874093

Thanks. I ended up downgrading rather than switching to beta versions of the core plugins of a production site - I'll update again when the fix is in a stable version.

I agree with julieP's comments regarding the hidden links - for links like this and to solutions on other sites, they do make the forum much less useful for self-help support.