16 Comments

  1. Jay Syder

    Hmmm seems like it could be useful in some instances where you have registration open. Otherwise I would just mark the posts as private which can be done in bulk and easily filtered.

    Reply

    1. Sure but that also splits the purpose of the Private posts into two different uses. If you don’t use Private posts for anything but archiving, it might work. But if you already use them for their intended purpose, you’ll have a difficult time sorting them with archived posts mixed in.

      Reply

  2. 1.21.2015

    Hello,

    I wanted to ask if there’s ever been a discussion about the number of plugins that WordPress uses and how to keep that number down do a bare minimum. There’s even a plugin from GoDaddy (P3) that measures how plugins affect WordPress’ performance. I’ve meant to ask this question for a while.

    Thank you,
    Doug Arnold

    Reply

    1. Hi Doug, the number of plugins itself is not a factor of performance. Theoretically, you could have 10,000 plugins running on your site without issue.

      Only poorly written plugins affect site performance. If a plugin is affecting the performance of your site on a measurable level, then it was written incorrectly. Tools like P3 could be helpful in spotting the bad ones to save you the time and hassle of running benchmark tests on your own.

      I shy away from using “kitchen sink” plugins that sport 100 features, 2 of which I actually want. These types of plugins are more likely to be written poorly because their scope has likely become too broad and they end up lacking a defined purpose.

      Someone could say that by limiting the number of plugins on your site you are also decreasing the chance of accidentally using a bad plugin, but that’s just an argument of probability, and in my opinion sets a false precedent.

      Plugins are good. Use them often. Use them wisely. :-)

      Reply

  3. I love simple plugins and this looks like a great one! I can easily imagine using this for client sites in the future. Keeping a post status’s purpose discrete is valuable in the long run, even if not apparent at first.

    I was also quite happy to see that the plugin’s new status worked out-of-the-box with my plugin Post Status Menu Items. I like it so much that I added explicit support for Archived Post Status (mostly just defining an icon) this morning!

    Reply

  4. I like seeing plugins that deal with post statuses because I hope it helps push for better custom status support in core (there’s still a lot to be done). What I don’t like are statuses like this showing up for every post type because not every status belongs with every post type. Instead of the rest of us plugin authors having to explicitly exclude this status, it would’ve been far nicer for us to be able to include it when needed.

    Post statuses are only really useful in conjunction with the post type they’re being used with. Each post type must decide what that status means to it and what happens when a post has that status. A general-purpose archive status plugin can’t make those decisions without knowledge of the post types it’s used with.

    The “archive” status, as it’s used in this plugin doesn’t really do anything but register itself. Users can select it. But, what does that mean for the post? Registration is one thing. But, it’s the implementation of the status that’s important. For blog posts, I would imagine they should no longer allow comments. Maybe those posts should no longer show up in the main blog posts list. For forums, they should no longer allow threads and replies. For real estate listings, I’m guessing you could no longer purchase/rent the listing.

    Implementation matters. What I would’ve liked to see out of a plugin like this is it registering the status for specific post types and making specific decisions about what happens when a post has this status. Overall, I think custom post statuses are practically useless without the post type. Any plugin that registers post statuses like this should be built primarily for blog posts and/or pages.

    Reply

    1. because I hope it helps push for better custom status support in core

      Amen to that!

      Post statuses are only really useful in conjunction with the post type they’re being used with.

      After reading your comment, I think I mostly agree with you; however, in this case, I think there is an argument for a “this used to be published but it’s not published anymore” status that really is as simple as this plugin provides. Like this post said:

      To use drafts in this way would be to split its purpose into multiple uses, which are not clearly separated when sorting…The archived status keeps everything nicely sorted for future use.

      I’ve had many a client request exactly this feature that applies equally to all their post types. I’m a big advocate of pretty much never deleting content from the admin and I think providing a custom status identical to “Draft” but with a more accurate label for this purpose is worthwhile.

      For most other statuses—and for more complicated “archive” statuses even—I’m totally with you. I just think there’s a place for a plugin as simple as this. That’s my $0.02 at least. :)

      Reply

      1. I agree that a standalone plugin would work for something like this and has its place. I mostly just think whether it shows for CPTs should be opt-in rather than opt-out. I’d like for core WP to tie statuses into post types at some point too.

        I’d also really take this the distance. For example, no one can view or edit archived posts, not even administrators. I’d tack on a couple of custom capabilities like read_archived_posts and edit_archived_posts. Then, hook in at the appropriate points (a query-related hook for reading and map_meta_cap for editing) to check permissions.

        Reply

        1. Yeah the bottom line is that core is lacking a robust API for statuses. Couldn’t have said it better than you. And obviously, this plugin is not going to work for everyone, I just decided to take code I was using personally for my needs and make it available for anyone to use.

          I wanted an Archived status to reflect an unpublished, but more specifically, a “post-published” state. As opposed to a “pre-published” state like a Draft would be. Anything that is published or pre-published should be editable. I thought this Archived post status should simply behave a lot like trashed does. You can’t edit or view a trashed post.

          So Archiving would be like trashing without actually trashing :-)

          As you know, trashed content is automatically purged by the wp_scheduled_delete cron every 7 days (by default), which you can change pretty easily with the EMPTY_TRASH_DAYS constant. If someone is happy just to change that, then they really don’t need this plugin.

          I appreciate your suggestions too about custom capabilities! I will definitely add support for that. Will be very useful for advanced applications.

          By the way, I use your Members plugin almost every day. Love it. :-)

          Reply

          1. I’m working with several custom statuses at the moment with a plugin I’m building. It’s a pain in some ways because of the lackluster API. However, it has given me some time to build some really cool stuff for my own plugin and given me ideas about where I’d like to see core go. Tying them into specific post types and capabilities has been both frustrating and fun.

            Shoot me an email if you want to look at how I’m working with custom caps.


  5. Hmmm, what happens with “archived content”? Does it just create a 404 when you try to reach it, or does it produce a more user-friendly message, indicating that the content used to be there, but has now been archived?

    Reply

    1. The goal of this post status was for it to behave a lot like trashing without actually trashing it from the WP Admin. WordPress will automatically purge trashed posts after 7 days (by default).

      So yes, the pages will 404 because the content is unpublished, just like if you were to trash it.

      Perhaps I will add a hook though so that this behavior can be customized, as you said, maybe take the user to a friendlier page or simply the home page.

      Thanks for the suggestion!

      Reply

      1. Dave Clements’ suggestion seems incredibly good and useful. Because 404 errors means losing content, and establish a 301 redirect to the home page or other post would be exceptional.

        Reply

  6. Prevent Concurrent Logins plugin worked very well ,

    it would be nice for site admins to be able to bypass the limits, and 20 minutes later I had a function to do that.

    Reply

Leave a Reply