[Resolved] access appears to be working globally vs. by cpt (wpengine host)

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

This topic contains 12 replies, has 2 voices.

Last updated by jimP 3 years, 7 months ago.

Assigned support staff: Beda.

Author
Posts
#421384

I am trying to: Use Toolset Access, as I have many times on many sites, to tailor access to specific CPTs. In this case I am working to make a previously login-only site public, yet restrict public view (etc.) access to the relational database I've built via a series of Toolset-based CPTs.

At present, posts, pages, and all CPTs are controlled by Access. Posts and pages are available for public view; CPTs are not. Yet, when I set Settings > Readings > to a public setting, I could then see *all* posts, pages, and CPTs without logging in.

So, I thought it was a WPEngine back-end cache issue, and flushed the cache. Now, at least on certain tests, *all* posts, pages, and CPTs were *not* available for public view.

I haven't yet fully diagnosed the issue, but I'm wondering if you have had similar problems with Access (2.0; latest) vis-a-vis WPEngine's back-end cache?

I visited this URL: hidden link [currently login-only; I don't want to set to public until we can restrict access to student databases]

I attach screenshots of current Access settings on one of my CPTs and posts. I'm happy to help further diagnose. I need to expedite this; thanks for your support.

Jim P.

#421393

Beda
Supporter

Languages: English (English ) Spanish (Español ) German (Deutsch )

Timezone: Asia/Ho_Chi_Minh (GMT+07:00)

I am confused what you mean by Settings > Reading > to a public setting.

This is not a Toolset Menu path and even so, under that Path in WordPress there is no privacy setting.

Do I misread this?

Anyway, in Access, I replicated what you did:

1. Posts and Pages can be read (only) by anyone
2. The rest (CPT) can NOT be read by NOT logged in users.

And, it works fine.

The CPT throws a 404 not found for guests, and the rest is visible to guests.

It must be a specific edge case.
And yes, WP Engine can be problematic, but until now we had issues only with Views, not with Access
Important is, no cache is disturbing the tests.
Try different Browsers and also if possible, different ISPs.

Please let me know if you can replicate this with clear steps, or if it happens ONLY on WP Engine servers.
Then we should involve the Support of the WP Engine too.

Oh, and it's highly recommended to update WordPress before we troubleshoot this further.

And given the number of Plugins you use, I would also test a basic one:
Does the issue also persist with a WordPress Default Theme and NO Plugins BUT the Toolset Plugins?

If not, could you then re-enable the Plugins one after the other, and check the issue each time you enable a plugin?
Please report me when the issue comes back
It might also be due to the Theme.
Please do reactivate your Theme only after you are sure the issue isn't coming from a 3rd Party Plugin.

#421558

Beda, see attachment to this response: on our multisite: Settings > Reading for each site allows editing of site visibility (privacy) settings.

I will experiment with other sites on our multisite, and do other variations, then get back to you quite soon; many thanks.

Jim P.

#421565

Here is incremental information, from testing another site on our multisite running Toolset on WPEngine (though with a quite different constellation of plugins), and comparing access to posts (desire public) and a certain CPT (desire private):

(1) Make settings as above in Access. Set site to public visibility. At this point, both posts and target CPT are fully accessible, despite settings in Access.

(2) Flush back-end caches in WPEngine & front-end caches in browser; reload site. Now, posts are public and target CPT appears private (i.e., do not display on archive widget), but when CPT post URL entered it appears just fine, i.e., target CPT actually still public.

(3) Flush back-end cache in WPEngine and front-end cache again; reload site. Now, posts are public, target CPT appears private, and when CPT post URL entered 404 error returned; i.e., at this point behavior appears correct. But...

(4) Now, launch a different browser to confirm. Regular posts now are *private*, and CPT is *private*. (One interesting difference: post archive widgets on front page still display regular post titles/excerpts; they just cannot be accessed; CPT archive widget, however, does not display post content, as in step #2 above.)

(5) Go back to initial browser and flush front-end cache. Reload front page. Behavior in #4 is now duplicated: both regular posts and target CPT (Toolset Access settings attached) are private. This is incorrect, but duplicates the behavior I initially reported.

At this point, I have documented that the problem is not limited to our target ds.lclark.edu/envs/ site. I will continue, possibly with this test site or another test site, to further diagnose.

You can, btw, tell why I initially asked re. WPEngine, as server cache seems to be involved.

Jim P.

#421575

I have now discovered that we are not using the latest versions of Toolset plugins; our admin has not updated these plugins for a few months. This in part is due to the challenges we have faced in updating Toolset plugins (which we do not network-enable) on a multisite; see this portion of a recent support thread and below:

https://toolset.com/forums/topic/custom-field-condition-parsed-incorrectly/#post-394356

What I have discovered is that Installer is found on each *site* where Toolset is activated on our multisite; this is contrary to all multisite management, where all plugins are updated (etc.) via network admin, not via admin on any given site. And, indeed, the Installer interface does not successfully download/activate Toolset plugins; see screenshot. (I tried various options, e.g., downloading only one Toolset plugin without activating. None worked.)

As I examined file permissions for one of the files related to an error msg at bottom, I see its enclosing folder as 775, with owner/group as www-data. This implies to me that, with Installer placed at the admin (site) vs. network admin (multisite) dashboard, Toolset is not gaining www-data account access to write its files and thus actually do the plugin updates.

I will proceed with manually downloading all Toolset plugin updates, deactivating/deleting all existing Toolset plugins, and then re-adding all Toolset plugins from individual zip files...but this is not an efficient way to manage them on a multisite. I realize this is a separate issue from this support thread, but I've reported it before and there must be a better interface.

Regards,

Jim P.

#421593

I've now updated all Toolset plugins to latest. This unfortunately did not fix the problem, though the behavior seems a little different: now with all Toolset Access settings the same as above, both regular posts and the CPT are *public*, in spite of Access settings. (I cannot reproduce the setting in #4 above where both went private.)

The only effect I can observe of Toolset Access (this follows full flushing of back/front-end cache, etc.), is that if the CPT is set to private then posts as part of this CPT are not revealed in an archive widget on the front end (though you can still view these posts directly via their URL). If, in Toolset Access, the CPT is set to public then these CPT posts *are* revealed in the archive widget as well as available via URL. This clearly is not satisfactory, so I will continue my tests now with a new site built with no site-activated plugins other than Toolset (note we have a number of network-activated plugins I cannot deactivate).

Jim P.

#421618

I have now launched a new test site, ds.lclark.edu/toolsettest/ (also after updating WP to 4.5.3...apparently we didn't do that yet as well). There are zero non-Toolset plugins site-activated on this new test site (though quite a few network-activated plugins). Here is what I did:

(1) Activated Toolset Types and Access latest versions. Created new CPT. Used Toolset Access to limit access to regular posts and CPT as per desired (regular posts = public [guest]; CPT posts = private [logged in author role or higher]). Created one new regular and one new CPT post.

(2) Upon testing, behavior is exactly what I have reported most recently: both regular and CPT post are fully accessible to guests (i.e., public). This doesn't change even if I set minimum role for CPT view to admin. In short, Toolset Access is not restricting access to the CPT in spite of Access settings.

(3) As comparison, I installed and activated Advanced Access Manager (wordpress.org/plugins/advanced-access-manager/) on this site. I can do exactly what I want to do, i.e., retain all regular posts as public, but make certain CPTs private (i.e., available only to certain logged-in user roles).

I've long been a faithful user of Toolset, and would prefer to use Access to accomplish my desired end rather than maintain a separate plugin. Please, let's further diagnose and see if we can solve the problem.

Jim P.

#421699

Beda
Supporter

Languages: English (English ) Spanish (Español ) German (Deutsch )

Timezone: Asia/Ho_Chi_Minh (GMT+07:00)

OK, this is a multisite then, and we need to analyse this.

I need though to request a Multisite as this issue seems directly related to settings you have only available in MultiSites.

To do so I need to wait for the server and WordPress to be ready.
Then, I will repeat your simple steps above and either report this as a BUG or get back at you with a solution.

Thank you for your patience meanwhile.

#422036

Beda
Supporter

Languages: English (English ) Spanish (Español ) German (Deutsch )

Timezone: Asia/Ho_Chi_Minh (GMT+07:00)

I am still waiting for the Test Site.
I apologize the Delay.

I will get back at you here as soon i have news.

#422073

Beda
Supporter

Languages: English (English ) Spanish (Español ) German (Deutsch )

Timezone: Asia/Ho_Chi_Minh (GMT+07:00)

OK, I got access to the Site.

Please note all below tests are made on a SUBSITE.
Nothing is Netwerk enabled as Access settings will not work as a network setting but as a site-per-site plugin.

1. I activated Toolset Types and Access latest versions.

2. I created a new CPT.

3. I used Toolset Access to limit the access to regular posts:
Public to anyone (read permission).

4. I used Toolset Access to limit the access to CPT's
Not readable by guests.

Results:

The native Posts are visible to me (Admin), a Subscriber and the Guests.
The CPT (as restricted) are visible to me (Admin), a Subscriber but NOT to the guests.

So as far I understand this issue when we use an own server this works as expected.

If you can confirm the issue is as I tried to replicate it above, and the outcome is not as such on your end it is an issue with WP Engine cache.

We have a test ground there but it is out of my scope to play there.
I would then need to involve a 2nd Tier.

#426885

My apologies: I somehow did not receive an email copy of your latest Aug 4 support communication. It sounds like this may be a WPEngine issue, indeed, given you were successful. How shall we proceed?

Regards,

Jim P.

#426980

Beda
Supporter

Languages: English (English ) Spanish (Español ) German (Deutsch )

Timezone: Asia/Ho_Chi_Minh (GMT+07:00)

Strictly speaking, we can not help with Server Setups.
https://toolset.com/toolset-support-policy/

I also tried this on a WP Engine Server we do have.
No issues as well.

What the problem is there, that is not a multisite.

I will ask if we can upgrade it to be a multisite, but I already would like to suggest to get in touch with your Server Admins, I fear this is not an issue in Toolset.

#427087

Okay, let's put this one on hold for now.

Regards,

Jim P.