ruzel

Have you taken a look at post levels?
https://fortes.com/projects/wordpress/postlevels/

That will allow you to set multiple levels of security (0-9) for posts and for users.

Other than that, private posts shouldn’t show up at all unless you’re logged in and the author of the post.

Thanks nonletter. That looks like a highly useful plugin. I also found this nifty trick on another thread (from pifucan)

When making a specific query (such as query_posts('category_name=conferences');) in a template, if you then use the_content to show your posts, the more tag will be ignored. If you use the_excerpt, your formatting will be stripped. To get around this, create a global variable called $more and set it equal to true before calling your query. And then, if afterwards you would like following posts to show their full content, you can set back to “true” after the query is run; like so:

<?php global $more; $more = false;
    query_posts('category_name=conferences');
    the_content('Continue Reading');
    //this last line is only necessary if you have more posts
    //to show in your template and want to show their full bodies,
    //not excerpts
    $more = true; ?>

You can find more info on this technique here

I should add, that pfinucan trick works for me (Thanks pifucan!) but that I still think that the default behavior given specified queries is incorrect (inconsistent).

Ivovic,

I should point out that when I say this is a bug, it’s a little more subtle than what I first wrote. The “bug” is that if you write your own query string to fetch posts with, you will get all the post content before the <!–more–> but stripped of its formatting. Overwriting the author’s intended formatting is the bug. The same thing happens when you call the_excerpt and *in addition* your post is now cut-off at a default length and not where an author intended. The end consequence of this is that outside of the loop, there is no way to call a post’s pre-more content with formatting intact. Surely, that’s not what WordPress’s default behavior should be.

On the Write Post page there is a box on the left column that says “Password Protected.” You need to remove the password from that box.

Private posts really accomplish what you’re looking for. A private post is only accessible to users who are logged in.

Slight refinement to the code above:

wp_get_current_user() also returns an object, so you need to do this instead:

$user_obj = wp_get_current_user(); //fetch information about who is logged in

$user_info = get_userdata($user_obj->id); //fetch user info based on known user id

echo 'Hey there, ' . $user_info->first_name . '!';

And that should do it!

Doh! Thank you for that.

Here’s a fix for your problem (although I haven’t got all the kinks worked out). What I think you’re looking for is the user_data() function. In order to call up user data–like a display name, you call user_data() with the user’s id as the argument. Butwaitthere’s more!

There is also a function called wp_get_current_user() You can use this function as an argument as well, ala user_data(wp_get_current_user()) and now what you have is an object with all the user’s info stored in it. So your final code (as a simple example) on your template page would look like this:

$user_info = get_userdata(wp_get_current_user());

echo 'Hey there, ' . $user_info->user_login . '!';

You can learn more about the user_data object here:
https://codex.www.ads-software.com/Function_Reference/get_userdata

I don’t understand why everyone thinks this is nonsense. What if you have a home page with an article that you want to feature, and then have other posts flow below it. If you write your own query string, WordPress ignores the <!–more–> quicktag. It’s a bug. Plain and simple and needs to be fixed.

I am having this problem too! Anyone out there want to say that this is a bug?

Nevermind! The problem was a plugin that was improperly generating links by using the GUID for posts, which it looks like does not update after changes.

I just found this out elsewhere;

If you are on a MAC, the line ending in your document will be incorrect and can cause this problem. If you are using BBedit or Texwrangler you can change the line endings to Unix Style in the menu bar of the document (the drop down menu that looks like a doc will have “mac” and “unix”–switch to Unix)

I was just having this problem. If you are using BBedit or Texwrangler you can change the line endings to Unix Style in the menu bar of the document (the drop down menu that looks like a doc will have “mac” and “unix”–switch to Unix)

This is exactly the problem I’m having now. It’s never happened before so I thought it was the new version of WP. I guess not. Did you manage to find an answer?