PHPBB3-10620 - Quote tag improvement

[JoshyPHP]

https://tracker.phpbb.com/browse/PHPBB3-10620
https://github.com/phpbb/phpbb/pull/3623/files

Previous discussion: viewtopic.php?f=108&t=42481
Image album showcasing other forums: http://imgur.com/a/bY24x

I'm starting a new topic to discuss the current implementation because the old RFC is too old, has a bad signal-to-noise ratio and I'd like to get moving. Pictures of the current implementation attached.

Personally, I don't like having the date displayed but I don't care either way. Currently the date is displayed as-is, e.g. "Sat May 30, 2015 11:51 pm admin wrote: ↑". It could say "On $date, $author wrote: ↑". In that case, I don't know what the lang string should be. In 3.1, the phrase is built with L_WROTE ("wrote") and L_COLON (":"). I could add something like L_ON_DATE ("On ") but building a sentence by piecing strings together feels wrong. My recommendation would be to add a L_ON_DATE_X_WROTE string with a value of "On %1$s, %2$s wrote". I don't know why the colon is in a separate string so I'd keep it that way.

[Mess]

I'm not a fan og having the date displayed either. To much information.

[Pony99CA]

I don't have a problem with the date, but don't care much, either. If you are going to have the date, though, put the user name first, like "Pony99CA wrote on June 16, 2015, at 7:57 PM:". The user name is more important than the date in my opinion, so it should be displayed first.

However, if you have post_id as a parameter, do you really need the time and user_id parameters? Can't those be retrieved automatically using post_id when previewing or posting? Having them there could also lead to mischief, like putting in other people's user IDs (having your user name link to my profile) or invalid timestamps.

Steve

[Louis7777]

I personally want to only see "user wrote:", because anything else there is distracting.

The date could be a tooltip.

And the arrow looks bad. Also, I think there shouldn't be anything after the ':', on that line. Maybe "wrote" could be the link to the post?

[JoshyPHP]

However, if you have post_id as a parameter, do you really need the time and user_id parameters? Can't those be retrieved automatically using post_id when previewing or posting? Having them there could also lead to mischief, like putting in other people's user IDs (having your user name link to my profile) or invalid timestamps.

Populating all the fields at quoting time is the simplest way. Trying to retrieve other fields at posting time comes with its own downsides. For instance, you need to be able to query the database at parsing time, the post needs to exist (not be deleted) and it has to be in a forum that the current user is allowed to read.

[Cin]

However, if you have post_id as a parameter, do you really need the time and user_id parameters? Can't those be retrieved automatically using post_id when previewing or posting? Having them there could also lead to mischief, like putting in other people's user IDs (having your user name link to my profile) or invalid timestamps.

Populating all the fields at quoting time is the simplest way. Trying to retrieve other fields at posting time comes with its own downsides. For instance, you need to be able to query the database at parsing time, the post needs to exist (not be deleted) and it has to be in a forum that the current user is allowed to read.

Yes, but it'll make quoting that much more complicated. If you have several nested quotes and want to edit them, you have to make sure you don't make any mistakes with the parameters or it won't make sense. If you just add a username and post ID like p=XXX, won't that make it that much easier?

[ quote="JoshyPHP";p=123456]blabla[/quote ]

[JoshyPHP]

You click the Quote button and the form is populated with the right data as in the screenshot above. You don't have to edit any of it, and if you want to create a completely different quote you don't have to specify every attribute, or any attribute for that matter.

[Pony99CA]

However, if you have post_id as a parameter, do you really need the time and user_id parameters? Can't those be retrieved automatically using post_id when previewing or posting? Having them there could also lead to mischief, like putting in other people's user IDs (having your user name link to my profile) or invalid timestamps.

Populating all the fields at quoting time is the simplest way. Trying to retrieve other fields at posting time comes with its own downsides. For instance, you need to be able to query the database at parsing time, the post needs to exist (not be deleted) and it has to be in a forum that the current user is allowed to read.

Those seem to be unlikely events for simple, single-level quotes. How likely is it that the post will have been deleted or your permissions will have been revoked between quoting and posting time (in which case, you probably couldn't post anyway).

Anyway, if the post doesn't exist any longer, keep the post ID (in case it was a soft delete) but don't add the timestamp to the quote (if we even need that); the user profile link can be filled with a database query on the user name if necessary. I suppose that a soft deleted post can still have its timestamp retrieved, so maybe you can still include that in that case.

If you don't have permission to read the post that's linked to, so what? Can't the code still query the post to access its timestamp? If the user tries clicking the post link, it will give him an error, of course, but that's reasonable. He'd still have that problem trying to click the link anyway.

I presume that nested quotes will be posted with all of the information already resolved, so we don't have to worry about those, right? If not, then I could see a problem with trying to resolve all of the information in a deeply nested set of quotes. But if quotes aren't posted with the information already resolved, won't you have to generate the post link, profile link and timestamp for every quote on every display of that page?

It's not always about what's simplest, but what's best for users. I don't think that seeing those extra parameters is necessary for users, and could lead to mischief.

Steve

[JoshyPHP]

If you don't have permission to read the post that's linked to, so what?

It would leak information on posts that can't be read. It's not critical information but someone would eventually report it to a security database and it would have to be fixed.

I presume that nested quotes will be posted with all of the information already resolved, so we don't have to worry about those, right?

Why would you treat nested quotes differently though? If using user-submitted data for quotes is bad for the outermost quote, it should be bad for nested quotes as well.

It's not always about what's simplest, but what's best for users. I don't think that seeing those extra parameters is necessary for users, and could lead to mischief.

I believe that simplicity is what benefits users most directly. It's less code for bugs to creep in and unforeseen interactions to take place. I'm not worried about any abuse for two reasons. Firstly because it's already possible to set an arbitrary name as the quote author and link it to a profile, and secondly because that's what other forums do.

I'm slightly concerned about hurting readability with having too much data in BBCodes and I've already created a ticket that helps with it, but overall I don't think it's much worse than the average BBCode. Talking about readability, I'm undecided about whether quote attributes should be systematically enclosed in quotes. As far as the parser goes, it makes no difference and both will always be accepted. For example:

Code: Select all

[quote="admin" post_id="583396" time="1433029874" user_id="2"]
[quote=admin post_id=583396 time=1433029874 user_id=2]

[Pony99CA]

If you don't have permission to read the post that's linked to, so what?

It would leak information on posts that can't be read. It's not critical information but someone would eventually report it to a security database and it would have to be fixed.

What exactly would be leaked? If somebody else quoted it and I'm quoting them, I've already seen it. If I'm quoting it, I obviously can already see it.

Maybe I'm missing something, so please explain what scenario would leak information that I couldn't already see.

I presume that nested quotes will be posted with all of the information already resolved, so we don't have to worry about those, right?

Why would you treat nested quotes differently though? If using user-submitted data for quotes is bad for the outermost quote, it should be bad for nested quotes as well.

Sorry, by "Nested" I meant existing quotes that I was quoting. I'm not referring to creating multiple levels of nested quotes myself -- those would all be "unresolved", of course.

It's not always about what's simplest, but what's best for users. I don't think that seeing those extra parameters is necessary for users, and could lead to mischief.

I believe that simplicity is what benefits users most directly. It's less code for bugs to creep in and unforeseen interactions to take place. I'm not worried about any abuse for two reasons. Firstly because it's already possible to set an arbitrary name as the quote author and link it to a profile, and secondly because that's what other forums do.

End user simplicity and amount of code is often a balancing act. A "Hello world" program is usually the simplest you can get, but it doesn't help the user at all (except to see that the computer can execute a program). And, of course, "user benefit" is also subjective.

I'm also not sure what you mean by "it's already possible to set an arbitrary name as the quote author and link it to a profile." If you mean in a quote, quotes don't link to profiles now, so they can't. If you mean that I can post that now in my post text (like this: Pony99CA), sure, but it's a lot more work. I'd have to go to the user's profile, copy the URL, add long-form URL tags into my post, paste the link in, then type the user name that I wanted to spoof. With quoting your way, I'd just change the user's name or his ID (which I might have to retrieve, of course) in the BBCode.

Steve