If the URL of a post called Test Post is lien caché, the output using [wpv-post-link] would look like Example 1 in the uploaded image but the output using %%POST_LINK%% would look like Example 2. How do we get the output of %%POST_LINK%% to look like Example 1?
Hello,
I assume we are talking about the email notification body of Toolset form, you can simply use Views shortcode [wpv-post-link] to replace the Placeholder %%POST_LINK%%, and test again, see our document:
https://toolset.com/documentation/user-guides/views-shortcodes/#wpv-post-link
Outputs the current post’s title as a link to the post
Hi Luo
Yes, we are talking about email notifications (sorry should have made that clear).
[wpv-post-link] only works in notifications that are sent when the post is submitted. It doesn't return anything when used in notifications sent based on a post's expiry date.
Please try to setup the link with HTML codes manually, for example:
<a href="%%POST_LINK%%">%%POST_TITLE%%</a>
Ok I've tested this and that works. I also tested specifying the post ID within the wpv-post-link shortcode and that now works.
Why are we having use either body codes or be specific & use id=%%POST_ID%% within wpv shortcodes on forms (since Forms 2.1)?
It's not at all clear from the changelog that current shortcodes formats needed to be changed to carry on working so how are we expected to have known that this needed to be done??
Since the shortcode without ID attribute, for example [wpv-post-link], works only when it in the single post, or a post view's loop, and it is in our document:
https://toolset.com/documentation/user-guides/cred-user-forms-email-notifications/
In this case when we want to output this User Field for the user being created by the form itself, we need to add user_id=”%%USER_USERID%%” argument to the shortcode, like this:
This isn't a user form, this is a post form.
Yes, it is the similar problem, because post expiration notification emails need the id=”%%POST_ID%%” attribute to output anything from Views shortcodes, so you will need to specific & use id=%%POST_ID%% within Views .shortcodes on id=”%%POST_ID%%” attribute.
I agree, it is not in our document, but it should be
https://toolset.com/documentation/user-guides/automatic-post-expiration/
Can you confirm it, I can escalate it to our editors.
Yes it should be in the documentation. Users should also be specifically informed when the required format of shortcodes etc changes (otherwise how else are we to know?)
Please escalate.
As your request, I have escalated it.
Here is the feedback from our 2nd tier supporter:
They are aware of this issue, you might be “forced” to use the ID placeholder as it is expected (from what I gather) in notifications that are not sent when the form is submitted.
It needs to be double check with our developers, then we will update the document.
This should have already been fixed in the latest version of Toolset form plugin, please test it and feedback if it is fixed or not, thanks
Hi Luo
Sorry I'm not clear about what you're asking me to test.
Are you asking me to check that the documentation has been updated to say the id=”%%POST_ID%%” attribute is needed to output anything using Views shortcodes in post expiration notification emails?
OR
Are you saying the id=”%%POST_ID%%” attribute is no longer needed (changed/fixed in the latest version of Forms) and you want me to test that this is correct?
Sorry, for the misunderstand, I mean this:
the id=”%%POST_ID%%” attribute is needed to output anything using Views shortcodes in post expiration notification emails
We will update our document or apply this featurewithout id=”%%POST_ID%%” attribute) in the future (version of Toolset form plugin.
But this attribute should be able to work out of box even in future version of Toolset form plugin
In September we agreed that information about the need to include this attribute needed to be in the documentation. You escalated that request. Now, 6 weeks later, you say it's been fixed in the latest plugin update but documentation is outside plugin files and in your last response you said you will update the documentation (meaning you haven't yet) or the need for the attribute will be dropped in a future version of the plugin. Based on this, nothing has changed since September so what is it you want me to test??
