search

chnm / anthologize

Anthologize is a free, open-source, WordPress-based platform for publishing. Grab posts from your WordPress blog, pull in feeds from external sites, or create new content directly in Anthologize. Then outline, order, and edit your work, crafting it into a coherent volume for export in several formats, including PDF, EPUB, and TEI.
http://anthologize.org
GNU General Public License v3.0
174 stars 29 forks source link

when fetching posts for items, exclude drafts #101

Closed mnelson4 closed 5 years ago

mnelson4 commented 5 years ago

When fetching posts from the project organizer, exclude draft posts by default. Specifically, only include published, pending, future, and private posts. Maybe we should only include published and private posts by default, though? Or maybe we should have a group of checkboxes (or multi-select) to show all the post statuses to choose from? This isn't really meant to be the final PR, this is mostly meant to just get the ball rolling.

mnelson4 commented 5 years ago

this is a PR for issue https://github.com/chnm/anthologize/issues/98

boonebgorges commented 5 years ago

Thanks for starting this. I'm guessing that, in the vast majority of cases, public and private will be enough. I wouldn't want to go to the trouble of introducing new UI for the very rare case where someone wants to include future or pending items (or items from custom statuses). On the flip side, I'd wager that most sites have so few items in future and pending that it doesn't actually do any harm to include them in the query. So, my inclination is to go with all four status, but run it through apply_filters() so that anyone who really wants the to change the behavior can do so via plugin. Seem reasonable?

mnelson4 commented 5 years ago

Yeah that seems fine by me. I added a filter so the post statuses could be changed easily. I put the same filter in two spots, which seems a bit weird to me. Normally, I'd put that logic into a function/method, and add the filter onto its return value, and call it from the two spots. But I'm not sure if we want to embark on that extra bit of refactoring here...

mnelson4 commented 5 years ago

yeah I'll give it a shot

mnelson4 commented 5 years ago

I presumptuously added a new method to Anthologize_Project_Organizer instead of to functions.php because it seemed to be in that vein, and the class was easily available for the two places we want to use it. But I'm totally not offended if you'd still rather it be in functions.php. Also, I notice a lot of the other filters used the prefix anth_ instead of anthologize_ (also they didn't have the normal php doc above them). Is that just old code, nowadays we'd rather filters start with anthologize_?

boonebgorges commented 5 years ago

Also, I notice a lot of the other filters used the prefix anth instead of anthologize (also they didn't have the normal php doc above them). Is that just old code, nowadays we'd rather filters start with anthologize_?

Ah, I hadn't noticed. In general, best to use the whole unique identifier, unless there are character limits (like the 20-character limit on post type names, thus anth_library_item.)

mnelson4 commented 5 years ago

:+1: