Manipulating register_post_status() setup on pageload

  • Jonas Lundman

    (@jonas-lundman)


    10 years, 5 months ago

    When register custom post status in my functions.php. Can I provide diffrent args for diffrent user views? Will this type of manipulating totally be “out of how to?”. Ive been searching for an answer many months, but cant se anyone doing this, so I finally have to post it here.

    Here is my code:

    function my_custom_post_status(){

if(current_user_can( 'update_core')) $p = true;
    else $p = false;
register_post_status('archive', array(
    'label'                     => _x( 'Archive', 'post' ),
    'public'                    => $p,
    'exclude_from_search'       => true,
    'show_in_admin_all_list'    => true,
    'show_in_admin_status_list' => true,
    'label_count'               => _n_noop( 'Archive <span class="count">(%s)</span>', 'Archive <span class="count">(%s)</span>' )
));

}
add_action( 'init', 'my_custom_post_status' );

    This actually is working, but do I mess with the database or are this kind of register just a “page to page load” variables? ( I mean, “register”, is it just instructions how to handle the “already stored” and “to be stored” in the database? )

    Don ask why Im doing this (!), just if I can do it -or if Im making a mess…

    Thanks to all of you who contributes on this forum !

Viewing 4 replies - 1 through 4 (of 4 total)
  • Moderator bcworkz

    (@bcworkz)

    10 years, 5 months ago

    I don’t see why you could not do this. The only thing stored in the DB is the status type label for each post. The registered status data is simply stored in a global array. It is these values that determine post visibility on admin screens. They are never stored in the DB, they are reinitialized on each request. In other words, they are indeed “page to page load” variables.

    I don’t really care why you’re doing this, but I will say it appears to be an interesting concept with potential. Please do report back if you encounter any issues, though I fully expect you will not have any.

    Thread Starter Jonas Lundman

    (@jonas-lundman)

    10 years, 4 months ago

    Thanks for this input and reply.

    Everywere are people warning about using post status for front-end purposes. But I think those posts are old. It is easy as of 3.7, as I figured out to build a few post status of your own, with som jQuery to handle the inputs and selectors on edit page/ quick edit listing.

    Im trying to hide a “kind of” posts completely front end, for all users except some roles (standard wp levels). I mean HIDE, no recent comment leaks, no Titles with links/ navs/, no Password content who cant protect custom field very well, assosiated functions, no RSS, no Google boots, no subscriptions present checkboxes…

    A Draft is behaving like I want to, so why not make a structure of drafts state posts? For the back end user experiance it is in the right section, around the visibility handling area.

    I created a plugin with :

    – Archive (Just keep stuff, keep away from archives, search)
    – Family only
    – Current client

    And just create a standard WP role, for each current_user_can level. And then, I got a simple access level system. I tried everything else:

      Using custom TYPES is not working, and is a pain to get viewable and accessable as a regular post (Subscriptions ignore it and more)
      Using custom FIELDS cant hide Titles and accociated data, menu items
      Using custom FORMAT is not extendable
      Using store posts and “sort them out”, means hook into everything everywhere and still it leaks on feeds or boot, or get renundant

    The plugins of all aorund 30, I tried during this year, are slowing down the site as hell. The try to lock recursive techniques, but it just get messy. Like Role Scoper, User access manager.

    PLugins like s2member just protect urls, not the visibililty. I don want my clients to view the title “My birthday” on the category dropdown widget, and so on.

    A new “draft”, is using the built in routines, and does not effect the power more than a hook into pre get posts, and adding the status if current user can ‘read_archive’ or any extended status.

    Moderator bcworkz

    (@bcworkz)

    10 years, 4 months ago

    I’m not sure what the objection is to front end use of post_status, nearly all front end queries include a variable for ‘post_status’=>’publish’

    Which of course suits your needs to hide certain posts. But I’ve missed certain important considerations in support of unorthodox approaches before. I hope I’ve not done so again here, but one never really knows at the time of the misstep.

    It’s fairly clear the intent of registering post statuses is to offer finer control of the post workflow for certain applications. Your application does not fit this intent. I’m never one to disregard potential just because it is outside the intent, but it does bring up the question: “Is there a more conventional approach that would achieve the same purpose?”

    Controlling visibility is certainly part of the post status, but in relation to the front end it’s really the theme template’s job. But then one should be able to “skin” their blog with different themes and see the same data presented in the same context, only the appearance changes. Altering templates is not the solution.

    Taxonomies have been mentioned as way to control visibility. Queries could be modified to only return posts containing or lacking certain terms. Would that prevent your so called “leaks”? If implemented properly, it should, I think.

    Then there are custom post types. There’s potential here. All queries by default are for either pages or posts. The effect is very similar to a non-standard post status. In order to see any of this custom content type you need to specifically query for it, otherwise it show up no where on the front end and is easily managed on the back end by the presence of a particular capability.

    I’m not telling you to do anything differently, only to consider if a different approach that uses WP more in a way that was intended would meet you needs. If not, by all means keep with the direction you’re on. Or stay with your direction despite there being a better way. I’ve informed you of the possibilities, It doesn’t matter much to me which one you decide to pursue.

    Thread Starter Jonas Lundman

    (@jonas-lundman)

    10 years, 4 months ago

    Hi
    Thanks for your time to write and deliver conciderations.

    Yes it its true that the purpose is a little out of context, but as I said, it seems like there is no other context at all.

    I cant create custom “places” like types for “hidden” posts. What if a post type needs diffrent levels and be viewable in it self? I cant move around / export import / between diffrent types just becouse some roles need to access – and some dont.

    I tried to create a template level solution, but that is a really mess. There is no clean Top level hook to grab into. You need to use sooo many hooks and filters, go through every new plugin, and still, a ex “list of subscription plugin” just expose the architecture/ crashes the objectives. Then when Buddypress are in use, and other big extensions, it is a never ending story work. Some are query the database directly, and some dont.

    But they all seems to leave the “draft” status alone…

    The main problem is that I think the WordPress Core need to concider some updates here and the importants of Access levels. I mean, “Password protected posts” is just a password protected the_content(). This is a old, relic way of thinking when WordPress is a engine for E-commerce, auctions, project management, photoblogs, ALL WITH plugins and data outside the_content().

    The security of urls, and an option to remove the password protected stuff from the visibility, and no “Private: Titles” , no wp_nav() visibililty, no get_comments() etc etc. It really 90:s…

    But it seems like WP developers are more interesting in fancy icons of Video post formats, with that endless discussion before v.3.7

    / J

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Manipulating register_post_status() setup on pageload’ is closed to new replies.