I'm having issues getting scheduled content to go from "unpublished" to "published" by setting up a lightweight cron job to run * * * * * curl -s -o /dev/null "http://example.com/scheduler/cron/92a628f76f3efefacd98" or by hitting "http://example.com/scheduler/cron/92a628f76f3efefacd98" directly in the browser as an Anonymous user.

If I hit that scheduler/cron/{access_key} link as a logged in user with permissions to view unpublished nodes (ex: Blog Post: View any unpublished content), then it successfully publishes the content according to the schedule.

An important part of this is that I'm using View Unpublished 8.x-1.0-alpha1 to prevent Anonymous visitors from being able to view unpublished content prior to Scheduler publishing it. So that module's functionality seems to be incompatible with Scheduler being able to use \Drupal::entityQuery('node') to return the list of node id's that will be published.

If I turn on this permission: "View any unpublished content" for Anonymous users, the lightweight cron job successfully publishes the content. However prior to that, I don't want Anonymous users to be able to view unpublished content... so turning on that permission is precisely the antithesis of what I'm trying to accomplish with the Views Unpublished module (i.e. prevent Anonymous from viewing unpublished content).

So in /sites/all/modules/contrib/scheduler/src/SchedulerManager.php's publish()...

Anonymous entityQuery returns no node id's that are available to be published:
empty nids

Logged in with permissions to View any unpublished content does return nid's that will be published:
populated nids

Any advice or recommendations for how to deal with this scenario of needing to run the lightweight cron Anonymously while also not allowed Anonymous users to view unpublished content?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

wesleymusgrove created an issue. See original summary.

jonathan1055’s picture

Hi Wesley,

I'm using View Unpublished 8.x-1.0-alpha1 to prevent Anonymous visitors from being able to view unpublished content prior to Scheduler publishing it.

This might sound like a silly question but is this the only reason you have installed View Unpublished? If so, then you do not need the module. Anonymous users by default cannot see any unpublished content. So unless you have a need for finer granularity over which authenticated users can see other users unpublished content you may not need it at all. Apologies if this is wrong and you already know all about that module.

I recall we had an issue similar to this before, but I can't see it in the open queue. I'll do some searching.

Jonathan

wesleymusgrove’s picture

Hi Jonathan,

Not silly at all! I feel silly having to use that module for such a simple reason. I agree that without the View Unpublished module the default functionality should prevent Anonymous users from seeing it, but in my experience, that's not the case. I have a really basic, almost out of the box, Blog Post content type, whose content is still directly accessible by Anonymous users when those nodes are unpublished. I am using the Workflow module to manage content moderation because the core Content Moderation module wasn't able to unpublish a node once it had been published see #2825579: Unable to Publish/Unpublish from Content Admin Screen when content_moderation enabled. I guess it's possible that Workflow could be enabling Anonymous users to view unpublished nodes, but I haven't tested that.

wesleymusgrove’s picture

Side note: that reminds me of the real reason I'm using View Unpublished, so that users of various roles involved with the content moderation workflow should be able to view/edit unpublished nodes that are not their own, like sending a node from creation -> draft -> review -> published.

So I'm testing this now with View Unpublished uninstalled. I have 3 roles: Content Writer, Content Reviewer, Content Publisher. As a Content Reviewer, I'm able to edit a Content Writer's node on the admin page, but not view it on the front end. I can "preview" it and swap between teaser and full view modes, but not view it on the front end as though it were already published. I suppose this is the default functionality and that it should be sufficient for my use case. It seems I may have been trying to solve a problem that didn't need solving with the View Unpublished module.

Anyway, back to the original issue... uninstalling View Unpublished will allow my lightweight scheduled cron job to return the list of nodes ready to be published instead of an empty list.

jonathan1055’s picture

I have a really basic, almost out of the box, Blog Post content type, whose content is still directly accessible by Anonymous users when those nodes are unpublished.

That really should not be happening. There must be some config/permissions/other module which is allowing anon users to see unpublished posts. I have added two related issues and the problem of interaction with View Unpublished seemed to be resolved.

I guess it's possible that Workflow could be enabling Anonymous users to view unpublished nodes, but I haven't tested that.

It would be worth checking that, definitely, but I'd be surprised if such a major bug as this was not already discovered and fixed.

Here are some ideas and questions to help prompt your investigations:

  1. When you say that anon users can see unpublished posts, is that on your ordinary front page?
  2. or via a view? or in a menu block?
  3. Does the content appear with the default theming/css for unpublished nodes? (pale pink backgorund in Bartik, for example)
  4. Is the content incorrectly viewable only after the status has been reverted from published to unpublished? If so, it could be a cache problem, and is it fixed after manually clearing the content cache (for example via devel module, or drush command)
  5. With View Unpublished uninstalled and with unpublished nodes being viewable, can you systematically uninstall other modules to find out if something else if giving the permission. As far as I understand, the permission system in D8 would have to explicitly grant view authority to anon users, it would not be a case of a module ignoring the permissions

I am sure there will be a good solution to this.

wesleymusgrove’s picture

Thanks for sticking with me on this Jonathan even though it's not really a Scheduler issue. I'll start with #5 for the TL;DR version:

5. I began systematically uninstalling the Workflow module and that brought the published/unpublished state back to the default functionality. Now Anonymous cannot view unpublished content (403 Forbidden), which is correct.

BTW, I'm using Scheduler 8.x-1.0-alpha1. It appears that the patch from #6 in #2700209: Disable node access checks during cron publish/unpublish would fix my issue. I should probably just update to 8.x-1.0-rc1...

If interested, here are my results running through your questions:

1 and 2. The views and menu blocks are handling this correctly by only including published content in their lists. The only way my Anonymous user can view unpublished content is by hitting it directly (ex: http://example.com/blog/post/testing-blog-post-as-content-writer), which limits the scope of this issue (because there shouldn't be any links to the post until it gets published and included in a view's list of content to display).

3. The content appears themed normally with my custom theme just like any other published page.

4. With the View Unpublished module uninstalled, as the content progresses through the Workflow moderation (creation -> draft -> review -> published) it's incorrectly view-able by Anonymous at any step before it's published the first time.

wesleymusgrove’s picture

Hi again, just following up to say that updating scheduler to 8.x-1.0-rc1 allowed me to hit the scheduler/cron/{access_key} path Anonymously and the $query->accessCheck(FALSE); allowed it to return nodes ready for publishing. I should have checked for updates first!

log messages

jonathan1055’s picture

Status: Active » Closed (works as designed)

Thanks for the update. I did not realise you were not on the latest Scheduler release, otherwise I would have mentioned that. Good to hear it is working OK now.