inherit
96289
0
May 17, 2020 9:37:00 GMT -8
elli
1,822
January 2007
ebbymac
|
Post by elli on Aug 9, 2019 18:17:45 GMT -8
I'm not sure if this is intentional, but it seems the variable $[post.created_by.name] returns nothing for a guest post. For example:
Post by $[post.created_by.name] on $[post.created_on] In a default theme, a guest post generates:
Post by on Jun 27, 2019 at 5:28pm However, if a user made a post and then deleted their account, this variable returns their previous username.
Is this a bug?
|
|
inherit
6871
0
Mar 22, 2024 7:34:38 GMT -8
bigballofyarn
"If you wish to make an apple pie from scratch, you must first invent the universe." -Carl Sagan
7,329
January 2003
bigballofyarn
|
Post by bigballofyarn on Aug 10, 2019 3:17:03 GMT -8
I feel like in the case of an actual guest, they are just entering in whatever text they want for their name and that text is not actually connected to anything on your forum.
In the case of the deleted account, all those posts were at one time connected to an account and a specific user ID. So, they would forever remain connected to that username and user ID.
It doesn't sound like a bug.
|
|
inherit
96289
0
May 17, 2020 9:37:00 GMT -8
elli
1,822
January 2007
ebbymac
|
Post by elli on Aug 10, 2019 9:29:09 GMT -8
bigballofyarn $[user] in the Mini Profile template does return the guest's chosen name, though, so I would expect this variable to do the same. In any case, I don't expect that this variable should return empty.
|
|
inherit
223590
0
May 17, 2023 9:13:21 GMT -8
Kitty Katt
My Username is @kittykatt (with 2 t's in katt)
819
July 2015
kittykatt
|
Post by Kitty Katt on Aug 10, 2019 10:27:41 GMT -8
elli, What template are you using that in?
|
|
inherit
96289
0
May 17, 2020 9:37:00 GMT -8
elli
1,822
January 2007
ebbymac
|
Post by elli on Aug 10, 2019 10:46:55 GMT -8
What template are you using that in? This is the Post List template on a default theme. To clarify, this is an unexpected behavior I found and am reporting under the assumption that it's a bug. Although I appreciate your and bigballofyarn's eagerness to help, this is probably a thread that ought to be left to the PB admins. :)
|
|
inherit
96289
0
May 17, 2020 9:37:00 GMT -8
elli
1,822
January 2007
ebbymac
|
Post by elli on Aug 10, 2019 11:34:01 GMT -8
Update here since I can't edit the OP: it looks like the parent $[post.created_by] returns the member's name as a user link, or the guest's name wrapped in a <span>. But while $[post.created_by.name] returns the member's name in plain text, it returns blank for a guest.
|
|
inherit
96289
0
May 17, 2020 9:37:00 GMT -8
elli
1,822
January 2007
ebbymac
|
Post by elli on Aug 11, 2019 6:19:24 GMT -8
Haha yeah, man, I get that. That line is for SEO.
My question isn't related specifically to this line, though -- that's just how I happened to find it. My question is why is this variable unexpectedly returning blank for guest posts.
I do appreciate the attempt to help, but again, this question is really meant for an admin.
|
|
Kami
Forum Cat
Posts: 40,004
Mini-Profile Theme: Kami's Mini-Profile
#f35f71
156500
0
Offline
Jul 24, 2021 11:48:29 GMT -8
Kami
40,004
July 2010
kamiyakaoru
Kami's Mini-Profile
|
Post by Kami on Aug 11, 2019 7:50:33 GMT -8
Sorry to butt in but this was an intriguing thread and being as I do QA in my day job I was very curious to see whether or not this could, potentially, be a bug or not. Obviously a PB admin will have to confirm, but here are my findings: 1. It's interesting to me that aria-hidden is being used as a class . If it's for SEO, that line would be ignored entirely (perhaps the intent?), though 'aria-hidden' if used as an actual semantic indicator would be to have the line recognised by assisted devices (eg: screen readers) only, and would not display in the browser. Probably not relevant, but interesting (and a little confusing as to why this decision was made), nonetheless. 2. Viewing the output is interesting for a few reasons. - Structure: the structure of the surrounding content indicates the line should be read in a sentence - "Post by NAME on DATE". This points to the output of the variable being blank as unlikely, seeing as "Post by on Monday" makes no sense from a grammatical point of view.
- On initial inspection, it looked like the variable was only meant to output display names which would have explained why the guest username wasn't being output. However, after testing creating a post and then deleting the account, it looks like it does in fact output a username if the account is deleted. Based on the mini profile, it looks like there is a check somewhere in the software for an account that is deleted versus a guest ( {if $[user.is_deleted]}<em>Deleted Member</em><br />{/if}). However, it is unclear if the $[post.created_by.name] variable checks against a user being deleted versus a user being a guest.
- The only thing left would be to check whether or not the variable returns as true for all posts regardless of whether or not the creator is a member, guest, or deleted member. However the variable isn't a boolean, so I created an if/else check:
{if $[post.created_by_user.name]}This text appears if value is true{else}This text appears if value is false{/if}.
This way if the $[post.created_by_user.name] variable is present in a post, then the first line would appear, otherwise would display the second line. It's not perfect, but interestingly, both an existing account and a deleted account return true, whereas a guest returns false even though there's no check in the original <h3> tag against whether or not a user is a guest or deleted member. (You can see this in the above link)
These lead me to the following conclusions: 1. At minimum, the behaviour is unexpected. Based on what it says on the tin, the variable should return a name for a guest user because a) it is capable of returning usernames as opposed to display names (if this was limited to display names only, then my deleted account would either be blank or display "Bob"); and b) guests are expected to input a name before posting which logically should be treated like a username (as it is the guest user's intended name for the post). 2. Guests are handled differently from deleted users, which makes sense considering the software can now distinguish between the two. However, it is unclear why a guest username is handled differently from a deleted member username. A theory would be that the guest username is assigned a different designation that separates it from a username, whereas a deleted member (having actually registered) gets assigned the same designation on name as a current member. 3. It is about 50/50 whether or not this is a bug, but it doesn't make sense especially since it's included as part of the default template to indicate who the post is by. Even if it's not a bug, it should either be updated to pull a guest name so as not to leave a weird sentence or should be modified with an if/else check to input 'guest'. It would be better for SEO either way. 4. Only an admin can tell us if this behaviour is intentional, and elli is right to report it as a potential bug as the behaviour is inconsistent with how it handles different post creator designations. As a note for those that don't deal with this daily, reporting a bug to developers isn't inherently saying something is for sure buggy or incorrect, but rather drawing attention to unexpected behaviour that the developers should look into and determine whether or not the behaviour is correct. If the behaviour is incorrect, then hooray! we've found a bug and can address it. If the behaviour is correct, then steps must be taken to make the function clearer to the user so the behaviour isn't interpreted as incorrect. Either way, these things ought to be reported. In this particular case, even if this isn't a bug it doesn't make sense from an end user perspective, and thus should be addressed. If it's intentional, why would the developers intentionally make a variable that returns blank for a guest user's post if the goal of the variable is to dictate the name of the creator of the post? Why are guest users specifically excluded? I'd kick this back to a dev in my day job too.
|
|
Kami
Forum Cat
Posts: 40,004
Mini-Profile Theme: Kami's Mini-Profile
#f35f71
156500
0
Offline
Jul 24, 2021 11:48:29 GMT -8
Kami
40,004
July 2010
kamiyakaoru
Kami's Mini-Profile
|
Post by Kami on Aug 11, 2019 9:19:52 GMT -8
Lynx - Yeah probably wrong terminology. What I meant was that guests are expected to input a name of some sort when creating a guest post (the field is called "Guest Name"), whatever it's called within the software itself. When I say it's unexpected behaviour, it's because of the presumed intent of the variable, not the function as-is, which is what I think Elli's point is. Guests are obligated to provide a name of some type when they post, otherwise the post cannot be submitted to a server, so logically speaking a variable to call the [name] of the post creator should inherently include a guest, as they can (settings allowing) create a post. All indication of how the variable is used ["Post by NAME on DATE"] indicates that it's probably unintentional to have the sentence read ["Post by on"], since that makes no sense. I would expect that if I were to call the name of the post creator, there would not be a check to return as blank when calling a guest name, hence unexpected behaviour since guests posting is an inherent function of the software (even if it can be disabled). Neither Elli nor I are arguing what the actual application of the variable is, only that it makes no sense to exclude guest names from being called when attempting to specify the creator of the post. It's being reported because, again from a theoretical perspective, if you are attempting to call the name of the post creator, the expected function would be to call ALL post creator types. It's not that we don't understand the application of the variable, it's just that the application doesn't make sense because of the above -- if this is functioning as intended, then there needs to be a way to fill in the blank value (even if it's a simple if/else added to this line of the default template to input plaintext 'guest' regardless of the chosen guest name). The alternative is that it's not functioning correctly and should also be calling whatever [Guest Name] is.
|
|
#e61919
Support Manager
154778
0
1
Mar 27, 2024 12:10:09 GMT -8
Michael
19,549
May 2010
wiseowl
|
Post by Michael on Aug 12, 2019 10:06:28 GMT -8
I wouldn't say this is a bug. I'm nearly positive the logic here was that guest names are meaningless (as they're not permanent or tied to anything) so why would people want the name returned.
This is apparently something we're going to fix.
|
|
inherit
204790
0
Dec 23, 2020 14:41:29 GMT -8
Alex R Jamison
192
January 2014
alexr
|
Post by Alex R Jamison on Aug 12, 2019 10:19:07 GMT -8
I wouldn't say this is a bug. I'm nearly positive the logic here was that guest names are meaningless (as they're not permanent or tied to anything) so why would people want the name returned.This is apparently something we're going to fix. a lot of replies seem to be missing from this thread. All pointed out the same logic that guests arent tied to anything. So is that still true? And by "fix" does that mean "bug" like the OP's claim? Or do you just mean it's something you are going to change?
|
|
#e61919
Support Manager
154778
0
1
Mar 27, 2024 12:10:09 GMT -8
Michael
19,549
May 2010
wiseowl
|
Post by Michael on Aug 12, 2019 10:26:35 GMT -8
I wouldn't say this is a bug. I'm nearly positive the logic here was that guest names are meaningless (as they're not permanent or tied to anything) so why would people want the name returned.This is apparently something we're going to fix. a lot of replies seem to be missing from this thread. All pointed out the same logic that guests arent tied to anything. So is that still true? And by "fix" does that mean "bug" like the OP's claim? Or do you just mean it's something you are going to change? I don't think any replies are missing. After discussing this with the devs the logic of "no variable should ever return a blank/empty" rule won out. You can call it a bug if you like?
|
|
inherit
96289
0
May 17, 2020 9:37:00 GMT -8
elli
1,822
January 2007
ebbymac
|
Post by elli on Aug 12, 2019 10:36:12 GMT -8
After discussing this with the devs the logic of "no variable should ever return a blank/empty" rule won out. You can call it a bug if you like? Sounds less like a bug (in the sense that this particular variable was broken), but more of an oversight or early logic implementation that wasn't revisited. It happens. I do agree that variables should never return blank and am happy to hear that it will be addressed. Thank you.
|
|
inherit
223590
0
May 17, 2023 9:13:21 GMT -8
Kitty Katt
My Username is @kittykatt (with 2 t's in katt)
819
July 2015
kittykatt
|
Post by Kitty Katt on Aug 12, 2019 14:41:42 GMT -8
a lot of replies seem to be missing from this thread. All pointed out the same logic that guests arent tied to anything. So is that still true? And by "fix" does that mean "bug" like the OP's claim? Or do you just mean it's something you are going to change? I don't think any replies are missing.After discussing this with the devs the logic of "no variable should ever return a blank/empty" rule won out. You can call it a bug if you like? I recall seeing, at least, two other posts. I believe, if I recall, they were made by MSG. However, I do not see those posts now. Kami even tagged him in one of their posts: Lynx - Yeah probably wrong terminology. What I meant was that guests are expected to input a name of some sort when creating a guest post (the field is called "Guest Name"), whatever it's called within the software itself. When I say it's unexpected behaviour, ...
|
|
Kami
Forum Cat
Posts: 40,004
Mini-Profile Theme: Kami's Mini-Profile
#f35f71
156500
0
Offline
Jul 24, 2021 11:48:29 GMT -8
Kami
40,004
July 2010
kamiyakaoru
Kami's Mini-Profile
|
Post by Kami on Aug 12, 2019 19:06:25 GMT -8
yes, the posts have been removed. i let michael know they were removed via PM but we should drop this particular subject as msg discussed this privately with me via PM (:
|
|