Grow your CSS skills. Land your dream job.

Login with Twitter (Kirby)

  • # January 14, 2013 at 2:46 am

    @traq Hmm. Sounds complicated.

    > … user.id of the comment author

    This is to verify and target the user, correct?

    > … date+time comment was authored

    This could be used for displaying comments in a timely order.

    > … display status (show,hide,starred,buried,etc.)

    Not quite sure what I would do with this. Perhaps be able to delete comments?

    > … comment thread id

    This sounds like it’s for displaying the information on the correct blog post.

    > You’d need an extra field if you allowed users to comment on comments – the above would work for a simple list (ordered chronologically), but you’d need more if you wanted a tree structure.

    I will not be allowing this. If the user wants to reply to another user, @username that user.

    > If you wanted to “version” comments (keep a record of edits), you’d need a field to track versions as well.

    Not sure I’m understanding why I would need a separate field just for edits?

    # January 14, 2013 at 11:18 am

    >>… display status (show,hide,starred,buried,etc.)

    > Not quite sure what I would do with this. Perhaps be able to delete comments?

    yeah, or for moderation (hide without deleting), or for featuring/downvoting comments.

    >>If you wanted to “version” comments …

    > Not sure I’m understanding why I would need a separate field just for edits?

    Not exactly what I meant: just a “version number.”

    For example, user *X* leaves a comment, then later edits it. The “edited” comment would actually be an entirely new record in the DB, with the same id (I was thinking a good Primary Key would be userID+publishTime), but a different version number. That way, you’d preserve the original comment in case you ever needed it, and it would still be easy to retrieve only the latest version:

    `SELECT `*fields*

    ` FROM comment`

    ` WHERE userID=`*userID*

    ` AND publishTime=`*timestamp*

    ` ORDER BY version DESC`

    ` GROUP BY publishTime`

    # January 14, 2013 at 1:15 pm

    @traq Thanks for the explanation and your help. I’ll have to do a bit of research on how to write this all up and retrieve content from the DB.

    # January 14, 2013 at 1:40 pm

    Can’t wait for you to get this all set up. Clearly the blog post of your life ;)

    # January 14, 2013 at 1:49 pm

    @TheDoc Haha. Thanks, Gray. It’s definitely going to be my first post for sure.

    # January 15, 2013 at 9:24 pm

    @chrisburton

    > I solved the Opauth issue myself. I only had to add my consumer key and secret into the config file and not into any other files like I was doing.

    What exactly did you do differently? I still can’t get it to authorize.

    # January 15, 2013 at 11:07 pm

    Hey @traq. I’m on my iPhone writing this as I’m not home at the moment.

    Basically I was taking my consumer and access keys/secrets, inputting them into the twitteroauth.php file in the Vendor folder. I might have placed into another file as well which was causing it to fail. The only thing you need to do to get it working is to place your Consumer key and secret into opauth-config (or whatever the filename is) inside the Example folder. It should then validate.

    # January 16, 2013 at 12:18 am

    hmm… that’s where I have them (in `./example/opauth.conf.php`, in `$config`).

    # January 16, 2013 at 12:25 am

    @traq Do you have Gmail or perhaps we can discuss this further through chat?

    # January 16, 2013 at 12:27 am

    actually, nevermind. I was using the TwitterStrategy.php file you’d sent me, which had your key and secret. Once I deleted that it worked fine.

    I’m testing my **twitter_user** class now with the live API. I’ll post with the results in your other thread.

    …thanks!

    # January 16, 2013 at 12:29 am

    @traq Awesome, thanks.

Viewing 11 posts - 46 through 56 (of 56 total)

You must be logged in to reply to this topic.

*May or may not contain any actual "CSS" or "Tricks".