1

Right now, I created a custom post type "resource" that is currently set to hidden. I'm planning on getting all resource posts and displaying them on 1 page. Not like an archive page, but like a post. I estimate there will be 300-500 of these posts.

Each custom post "resource" will use the "title," "body," custom field "website," a custom taxonomy, a second custom taxonomy, ratings/votes, potentially a feature image, and potentially comments.

I do not want to create a single post and have to manage tons and tons of formatted lines of resources. Additional benefits are the fact that I can manage these resources from a CSV file and use WP All Import to mass update the list. Furthermore, each resource can store a rating or "upvote" by users and I can eventually use this to sort by "best." And, maybe even implement comments on these, so users can submit tips for how they used it...

But, I imagine pulling 500 items out of a database and then displaying each field will be very inefficient. Yes? No? Is there a better way to do this?

1

Considering the requirements that you've outlined, custom post types are definitely an appropriate choice for managing resources within WordPress.

  • You get a CRUD interface right out of the box (just in case you'd like to leverage it) and WP All Import works nicely with WordPress posts, meta data, and taxonomies.

  • There are great APIs for adding taxonomies and meta data to custom post types.

  • Comments can be easily turned on for custom post types. Rolling your own comments solution would certainly be a big challenge.

  • Plugins are available for adding voting.

Since the page that displays all of the posts (presumably the archive page) will require a large query, caching via one of the numerous caching plugins should be used to mitigate the performance hit.

I do think that this is a question that will draw opinionated answers though, so it might be better to discuss it in chat.

  • 1
    Thanks for your response! You confirmed everything I was pretty sure about. Except I'm not familiar with CRUD. I'm about to run a dummy import with several hundred duplicated posts and try and test the load time for myself. – jonbon Jun 2 '17 at 22:31
  • You got it, @jonbon. CRUD is just an acronym for create, read, update, delete (the post listing table in the admin lets you manage posts if you ever want to go that route). I've used WP All Import before and it's a great plugin. It can has various ways of dealing with large imports, so I think you'll be in good shape. – Dave Romsey Jun 2 '17 at 22:44
  • 1
    I just finished a dummy import. I loaded the fields I would need except for a photo, and then batch added unique ID's to the titles and then uploaded 750 through WP all import. Without a cache plugin it took about 5 seconds to pull all the data. Cache brought it down to about a second, but if I go this route I'll need to make sure that 1 page is always precached. – jonbon Jun 2 '17 at 23:31
  • Ok, cool. Caching is something I'd expect an improvement on with the front end, not so much the back end, but that's ok. – Dave Romsey Jun 3 '17 at 9:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.