I may be the only person that prefers the File Browser to “Your Pages”, but I wish there was a way to see at a glance in the File Browser which pages are “hidden”.
Is there any reason why a backend JS that hits the JSON API to check each page in the list wouldn’t be a good idea?
Here is a proof of concept that I was toying with:
// Add "hidden" badges in File Browser
if ( $('body').is('#pages_browse') ) {
$('#pages_browser .pages_file_editable').each(function(){
var $this = $(this);
var id = $this.attr('href').split('=')[1];
$.getJSON( '/live/json/pages/id/'+id, function( data ) {
if (data.length == 0) { // hidden pages don't show in the API
$('<span class="label label-danger">hidden</span>').insertAfter($this);
$this.after(' ');
}
});
})
}
Could that have a performance impact, especially in folders with lots of pages? Would there be a better way to do this?
It may be fine with shorter lists of pages, but yes probably a better approach would be to do something like request /live/json/pages/group/{current group} and then get a longer list that way. Then, your .each() function could just check if the page ID is present in that result rather than making a request per-page. (I’ll also note, in our next release you can make authenticated requests using ?include_hidden=1 and they’ll have an optional status:1 and status:2 response field that you can use to explicitly identify Live vs Hidden results.)
Loop through the JSON data and mark pages that are in it as live. Then loop through the pages that aren’t marked as live, and add a “hidden” badge to those. Seems much better for performance than my original approach.
And I just found an issue with this. The group you have selected is not always the group that owns the list of files you are viewing in the file browser. When those don’t match, none of the pages will be in the JSON and they will all be marked as hidden. Somehow I will need to identify the group owner of the folder path visible in the file browser and use that for the JSON. Back to the drawing board.
I tried using the ID of the first page in the file browser along with /live/json/pages/id/{id} to get the group id of that page (and therefore the group id of all pages in the list). Then /live/json/groups/id/{gid} to get the name of that group. Then I can use that group name in my previous script.
That works great unless the first page in the list happens to be hidden, in which case the first JSON results are empty and everything else fails.
I guess the next step would be to loop through all pages in the list until I find one with JSON results. That could be a lot of JSON calls if the displayed directory happens to have a lot of hidden pages.
I tinkered with this a bit more and have come to the conclusion that this goal probably isn’t realistic at the moment. Even if I can reliably get the group that owns the currently viewed directory in the file browser, the JSON data does not return pages that are set to any Privacy option other than “Everyone”, nor does it list .test pages, so all of those erroneously get marked as hidden, even if they aren’t.