- This topic has 13 replies, 2 voices, and was last updated 5 years, 11 months ago by
.
-
Posts
-
Hi Franky,
I have tried to use a few conditionals on booleans (0/1) values, but can’t use eq or value to detect their values. I had to resort to using gt and lt which work fine.
Conditionals I have tried:
#_AVAILABLESPACES{n}
#_IS_USER_MEMBER_OF{xxx}Here’s the syntax I tried (of course with the correct name in there):
[eme_if tag='#_IS_USER_MEMBER_OF{name}' eq=1] [eme_if tag='#_IS_USER_MEMBER_OF{name}' value=1] [eme_if tag='#_IS_USER_MEMBER_OF{name}' value='1'] [eme_if tag='#_IS_USER_MEMBER_OF{name}' eq='1']They all seem to default to false.
Using gt=0 or lt=1 works fine.The IS_USER_MEMBER_OF was failing due to a wrong sql statement, not the conditions.
This fixes that issue:
https://plugins.trac.wordpress.org/changeset/2002206/#_AVAILABLESPACES{n} only works if your event is multiseat … is that the case?
Yes, I definitely have a multiseat event. My event has seats for all 4 levels. This code returns false when it should not:
[eme_if tag='#_AVAILABLESPACES{1}' eq=1]While this code works perfectly:
[eme_if tag='#_AVAILABLESPACES{1}' gt=0]Upon testing IS_USER_MEMBER_OF further, I find that indeed it returns false all the time, whether I am logged in as a member or not and no matter which attribute I use to detect the value (eq/value/gt/lt/ge/le).
Given the situation with #_AVAILABLESPACES though, I feel we may indeed be looking at two separate bugs here, the SQL bug you detailed in IS_USER_MEMBER_OF, along with an eq/value attribute number parsing (?) bug.
I added the line of your fix from Changeset 2002206 to my eme_people.php file, but my conditional using IS_USER_MEMBER_OF still always returns false no matter what value comparison attribute I use.
The only thing I can think of is that my membership name has uppercase and lowercase letters (no spaces though)… could that affect its use?
By the way, I’m using #_MEMBERID for testing as well, and it does not parse (it displays on the page as “#_MEMBERID”) either, even though that browser is logged in as an active member. So, perhaps this is yet another bug, this time in member detection?
#_IS_USER_MEMBER_OF is meant to evaluate if the logged in user is a member of a EME membership, and that is checked by linking your WP user with an EME person (go in EME=>People and edit the person of choice, you can there link your wp id to that person).
#_MEMBERID only results in something related to EME member (like a mail, or a pdf when in the EME member overview).
I’ll check #_AVAILABLESPACES{nn} later on.Thank you Franky! Linking the WP user to the member worked for the #_IS_USER_MEMBER_OF conditional. Is there a way for that linking to happen automatically for anyone that signs up for a membership?
Now that the conditional works to detect whether the logged-in user is a member, I thought I could try some of the member placeholders. So far none of these work for me (they just output the placeholder text as is) and so I stopped testing:
#_MEMBERID
#_MEMBERSHIPNAME
#_MEMBERSHIPPRICE
#_MEMBERCREATIONDATEStrangely, on this #_IS_USER_MEMBER_OF conditional,
eq=1works, buteq=0returns false when logged out (should be true). Currently usingne=1instead, which does work. I will check what value it is returning . . . perhaps -1 instead of 0?Okay, I see now #_IS_USER_MEMBER_OF returns 1 if true, and nothing at all if false, which is not in accordance with your documentation – it should be returning 0.
So perhaps the problem is in the values some of these placeholders return rather than the functionality of the eq and value attributes themselves.
You’re correct for the logged-in part This should fix that:
https://plugins.trac.wordpress.org/changeset/2002594/events-made-easy/trunk/events-manager.phpConcerning your tests with other placeholders: like I already said: they waork only in a membership context. Testing them on a plain wordpress page or event won’t work.
And for your question about adding the wp-id automatically: I stopped doing that because of the problems with maintaining that link (for rsvp forms, in the backend, multiple member signups for other people with the same admin account in the front, …). So it needs to be set manually.
Thanks for the fix! It worked.
Concerning your tests with other placeholders: like I already said: they waork only in a membership context. Testing them on a plain wordpress page or event won’t work.
Ah, I didn’t understand that. Can you give me an example of a page that is “in a membership context”?
After further testing, I see now that #_AVAILABLESPACES{n} works as it should after all! Sorry for the confusion, I got mixed up with the other bugs that you fixed.
Pages are not in membership context. For events, you can use event placeholders in rsvp mails, thank-you message, the event format etc … And this is identical for memberships: the membership placeholders are only valid in membership mails, membership signup etc …
The conditinal tag is_user_member_of is handy so people can show/hide stuff (be it custom fields in a rsvp form, text, the whole event) based on wp-login and eme membership.Thank you, now I understand.
Also, thank you for explaining the reasoning behind why you don’t link WP users and EME members automatically anymore. Makes sense!
- The forum ‘Bug fixed or feature request implemented’ is closed to new topics and replies.