paulipar

Related to this issue the “hidden” option for woocommerce categories doesn’t seem to be working. It simply doesn’t hide the category from the shop page and doesn’t seem to have any effect on hiding the items for the role.

1. Make new category
2. Go to Woocommerce -> Categories -> New gategory
3. Manage default access on category -> Set to hidden on front, back and API
4. Category still shows up on shop, no effect whatsoever

Goal is to make a category that is only visible for a certain role users and hidden for all others. I am using the plus package.

• This reply was modified 4 years, 11 months ago by paulipar.

If disabling the plugin folder didnt fix the issue it means that the issue is not in any of the plugins. Thus making these forums proly not the right place to discuss it ??

This makes me think the issue might be in the .htaccess file.

I found this page by googling your issue: https://www.hostinger.com/tutorials/fix-sorry-you-are-not-allowed-to-access-this-page-wordpress maybe one of the steps in here will fix it? if the error is not in the .htaccess it might be deeper inside the database.

One way to tackle this is to setup a complete new site and migrate the old site step by step to the new site. At some point it should break and then you will know in where the issue is. For this youd need a second host if your current host doesnt support multiple sites.

Current version 6.1.0 has fixed this error on the admin page.

Just something i faced one day with similar problem you had was i was editing the wrong page via FTP since i manage multiple pages ?? Try disabling whole AAM plugin by renaming the plugin in the plugin director to see if this has no effect on your site. If your host uses any additional caching mechanisms you may also want to try to clear those caches. You can also try renaming the whole plugin page via FTP, if you still can’t see any changes on your page you are likely not editing the actual page and might be editing a development site etc

Why do you want to rename backend menu names?

If you want to have different menu names for admins and visitors you can create 2 different menus and restrict access to the other menu for all visitors while letting the admins (or other roles) to access the other menu.

Over all 6.1.0 seems to working OK depending on how complex rules you have. Simple page restrictions are working fine for me. However there are still some issues as you can see by reading these forums.

Myself I’m mad enough to update to 6.x since i don’t use this plugin on any “real company page” and only use it for a gaming page.

My personal opinion is that if you use this on any real site where revealing sensitive information may harm your business, you should maybe wait a bit longer until more bugs are tackled and keep using 5.11. If you use it on a less sensitive site and have only simple restriction rules like the page restriction rules the 6.x good for that. Keep in mind that if you are looking to update to increase your sites security there have not been any found security issues in 5.11 and since 6.x is a complete rewrite of the plugin in my opinion its more likely to get these security vunerabilities. So all in all if you run a sensitive site keep 5.11 until security issues possibly are found in it and if you run a less sensitive site you can swap to 6.x and keep on receiving updates as it goes.

After updating to 6.1.0 now all blog posts are shown on the blog page.

Posts that have been labeled as private posts will result in redirect rule when clicked and public posts will open as they should open.

Just need to hide the private posts from showing up on the blog page now ??

Currently:
Post with private category is set to hidden from anonymous users and redirected.
When user tries to read this post directly via URL they are redirected.
When anonymous user views the blog page where all posts are shown they are able to see the private posts.

Posts with public category is set to be visible for everyone. Anonymous users are able to read theses posts via URL and also able to see them currently on the blog page (fixed from the original bug post)

Are you sure you remembered to change the mode from default to Anonymous when you added the rule? As your description makes it sound like you set the default rule to prevent access on the page which applies on everyone including admins.

I keep making this mistake myself as each time you reload the access rule page it defaults on the default role

If i remember it right in our case the issue was for FI local code missing from https://github.com/woocommerce/woocommerce-gateway-paypal-express-checkout/blob/80a2c174879dc30bd38dc565a6a9df85c744c678/includes/class-wc-gateway-ppec-settings.php#L24

This could be fixed with the following:

add_filter('woocommerce_paypal_express_checkout_paypal_locale','set_default_language_paypal_express');

function set_default_language_paypal_express()
{
    return 'fi_FI';
}

Im currently using the 2.0 plugin that has the option to restrict login with free version so i see no point to upgrade to the rather costly permium version (since this is all for gaming usage for me).

For EVE Online login needs to be restricted based on: alliance ID, Corporation ID and Character id.

With 2.0 there is also a bug where if alliance ID is determined in the restricted field then the corporations in the corporation fields are not taken into the if condition for login. So you want to have if not in alliance and not in corp … then restrict login instead of if not in alliance, restrict login as a corporation can be inside an alliance, and a single character can be inside a corporation. Just for your info to not to repeat this bug in this plugin as well ??

You should also use this endpoint: /characters/affiliation/ instead of /characters/{character_id}/ as the character ID endpoint has a 24 hour cache (changed recently)

• This reply was modified 5 years, 3 months ago by paulipar.

This plugin was working just fine until the 6.0 rewrite patch that seems to have just broken it completely. Based on my experience pre 6.0 this is a good plugin, so you might want to give it a while until the current problems are fixed (or use a later version).

As in its current state i can agree that there is no point buying it (also have paid version myself).

mo_oauth_settings_page.php line 2182

resourceownerdetailsurl should be https://esi.evetech.net/verify/ instead of https://esi.tech.ccp.is/verify/ as the URL has changed. (https://forums.eveonline.com/t/esi-base-url-update/63210)

This sadly has not been fixed in 1.8.0 either.

After you change the url you will need to delete the old eve app and create a new one or it wont take effect. Tok me a good while to figure this out.

This issue is very likely related to the URl change CCP made for ESi.

https://forums.eveonline.com/t/esi-base-url-update/63210

Oauth seems to be calling https://esi.tech.ccp.is/verify/ where it should now be https://esi.evetech.net/verify

Edit: Confirm. Changing resourceownerdetailsurl to the correct one fixes the problem.

• This reply was modified 6 years, 2 months ago by paulipar.

Thx for the info. I am indeed using the Pro version.

Do you have any idea when the bug where the role based prices are removed during manual WPALlImport jobs run is going to be fixed?