Arriving at CPT, viewed with Content Template, non-logged-in user should not see post author's selected custom meta fields next to their labels.
Arriving at CPT, viewed with Content Template, logged-in user - custom role "registered buyer" - should see post author's selected custom meta fields.
What we're trying to do here is make guest register, or registered user log in, before seeing the post author's selected custom meta fields next to their labels.
Have review all documentation available from TS and find no previous thread that answers the question, nor any documentation on the subject.
There is no similar example. This is the instance that will determine how we are able to handle the requirement that only if a guest is willing to register their email, or login, (probably need cookie here to not force registered users to go through the login every time they navigate to a particular post) in order to see specific details on the seller's state location, telephone, website, facebook page, instagram, About Us, View all listings by this seller, and Email seller with SENDTO:
Here's a particular post that looks like it would look to an unregistered buyer. We would add some appropriate conditional message in place of the empty Seller Information fields to register as a Buyer, or login to view the Seller Information => versteckter Link
Hi, this sounds like something you can accomplish with inline Access Control shortcodes. Here is an example showing how to restrict access to content in a page based on non-logged in Users (role = Guest) and custom role "Shop Manager":
[toolset_access role="Guest" operator="allow"]
Login to see more information
[/toolset_access]
[toolset_access role="Shop manager" operator="allow"]
This information will only be seen by the shop manager role
[/toolset_access]
We have more information about Access Control shortcodes here:
https://toolset.com/documentation/user-guides/access-control-texts-inside-page-content/
Let me know if you have additional questions about this.
Ok. So this would require that in place of labels and user-meta shortcodes, we would substitute text-only inline access control shortcode that would advise a user a non-logged-in buyer user to either login, or register a buyer account before Seller Information can be viewed.
The information subject to the restriction is a list of labels and user-meta field shortcodes. Ideally we would allow the non-eligible user (unregistered guest, or non-logged in buyer) to see the labels, but not the fields until they have either logged in, or registered, then logged in. If we can only put a text-only message in place of showing anything at all, how would we do this so that the ineligible user can:
1. See the labels;
2. Not see the seller meta-fields;
3. Have links to either login, or register/login and return to the page to view the meta fields.
Thanks Christian
Expanding on the code I shared before, here is the general idea. The actual shortcode syntax used to display the custom field value may be slightly different, depending on what type of shortcode you use and the slugs you assign to each field.
[toolset_access role="Guest" operator="allow"]
Login for more information:
[wpv-login-form]
[/toolset_access]
Breed: [toolset_access role="Guest" operator="deny"]
[types field="breed"][/types]
[/toolset_access]
Sex: [toolset_access role="Guest" operator="deny"]
[types field="sex"][/types]
[/toolset_access]
The wpv-login-form shortcode will generate a standard WordPress login form. By default, the login form will redirect to this same page. You can modify the redirect URL if you'd like. The documentation for this shortcode is here: https://toolset.com/documentation/user-guides/views-shortcodes/#wpv-login-form
Per your last update, posted this at the beginning of Seller's Info on a Puppy Profile page:
[php]
Seller Information
Login to view Seller Info for {!{types field='puppy-name'}!}{!{/types}!}
[wpv-login-form]
versteckter Link"><span style="color: #3eb0bb; font-weight: bold;">Create Your Free Buyer Account</span><br>
<span class="pp-info-label">Contact-Kennel Name: </span>
[toolset_access role="Guest" operator="deny"]
<span class="pp-info-field">{!{types field='contact-kennel-name'}!}{!{/types}!}
[/toolset_access]
[php]
What I get, disregarding the login & create buyer account parts is the posted image. If it is relevant, I am using a Divi Child theme and the option to use Divi Builder in the Puppy Profile Content Template.
I've tried the label/field code/shortcodes in both the Code Module and Text Module. Keep getting the same result. Thanks
What I get, disregarding the login & create buyer account parts is the posted image. If it is relevant, I am using a Divi Child theme and the option to use Divi Builder in the Puppy Profile Content Template.
I see you have the Layouts plugin active. We do not recommend using Layouts and Divi together, because they can cause conflicts with each other. Before anything else, I recommend deactivating Layouts.
I deactivated the Layout for the puppy Rojo4 as a test. Then I was able to edit the assigned Content Template using Divi Builder. I saw at least 3 problems:
1. The Access plugin was not active. This is why the toolset_access shortcode was appearing in the screenshot you provided. I activated Access for you and that problem was resolved.
2. There was an extra space in the Types field shortcode for Contact Kennel Name. This is why the closing Types field shortcode was appearing on the site. I removed the extra space and the closing shortcode is no longer displayed.
3. There is no custom field contact-kennel-name, as far as I can tell, so not even logged in Users will ever see any information displayed here. The pp-info-field span, however, is hidden from Guests as expected.
New Test Conditions Set:
1. Deactivated the TS Layouts plugin because of the known conflict with Divi.
2. Activated the Access Plugin.
3. Deleted the Rojo4 test CPT - deleted the test Seller Account.
4. Created a new Seller Account under the above conditions.
5. Listed a new test Puppy - Fido - a French Bulldog Puppy.
Results:
1. Seller Account Created.
2. List a New Puppy was not possible - returned Permission denied.
2. List a New Puppy was not possible - returned Permission denied.
I see, this sounds like a separate issue. Our policy is to address one issue per ticket, and we are using this ticket to discuss showing or hiding meta fields based on the logged-in User's role. If you need help correcting Form permissions, feel free to create a separate ticket.
Hi Christian,
Sorry for the delay. With several things not yet working properly, we had to take the site live 3 days ago. Because we still cannot get the single login working, we created to separate logins, Login Buyer and Login Seller to get us going. This is not ideal, because I tested logging in as a seller with a buyer account and it was accepted. Also tried the other way .. same result. We still need to get a single login that redirects successful credentials the appropriate account Page:
Seller - My Account
Buyer - My Buyer Account
I assume you still have all the access credentials sent earlier to take a look to see what we're missing here. Thanks Christian.
Hi Christian,
My Previous reply is misleading. This problem of showing post user meta data only if the user is logged in is on hold until we've gotten a resolution to another thread you're handling for getting a single login for Buyer and Seller working to get either to the correct account page after logging in. It is related because it seems we're unable to distinguish effectively what type of user slug: ftm-puppy-buyer or ftm-pupper seller is on the page or post.
Still unable to display Author meta on a puppy post. Per your suggestions.
Access is activated.
Layouts is deactivated (using Divi).
The attached image serves to verify that there is a User Field Group with the contact-kennel-name field defined for a Seller (ftm-puppy-seller).
From the Content Template for Puppies in the Fields Test text module you can see that I have tried every combination of ways to display user meta fields that we have covered. Nothing appears in any case. Thanks again Christian for your help on this that first started on June 4th.
Earlier you said this issue is on hold until a resolution is found for the other ticket.
I'm still waiting for your feedback in the other ticket:
https://toolset.com/forums/topic/need-to-have-1-login-form-that-redirects-based-on-wp_user-role
Can you please follow up there or let me know if you would prefer to continue with this ticket?
