rrecurse

My issue was apparently due to another plugin. Excuse false alarm.

I forgot to mention, your screenshot of the plugin settings page:

.. does in-fact show the behavior we’re looking for, e.g. “Select the User Roles that are able to view this content (or its sub content)…

How can we restore this functionality? Perhaps there is a previous version of your plugin that does this? OF course having the option for both include or exclude would be great, but we’ll settle for the behavior outlined in the screen shot.

Please advise. Thank you!

• This reply was modified 8 years, 5 months ago by rrecurse.
• This reply was modified 8 years, 5 months ago by rrecurse.

Hi Matt,

While a batch remove feature would be a great addition, so would a reverse Role restriction (and forgive me for hijacking this thread):

An option to either Include or Exclude the selected roles to access page/post.

Similar to how Role based widget plugins are doing things, there are options to apply your role selections to include or exclude the widget based on a secondary option to include roles or exclude role.

Example: I select 2 roles, then select an option from a secondary pull-down which contains two options:
1) Hide for All except for selected (new feature)
2) Show to All except for selected (current behavior)

What would it take to commission such a feature?

Great an thank you for resolving!

I can confirm 404 option is now behaving as expected.

Cheers!

Thank you for resolving! Can confirm everything works and no more warnings.

Cheers!

Just a follow up,

The author of if-menu plugin released a patch after I notified them of this issue. Marking resolved.

Hi John,

All scheduled tasks in the table list show incorrect offsets. Even ones scheduled by script (e.g. wp_schedule_event). If I mind the UTC time when entering the task, the display time in that table is still off by an additional GMT offset.

If I enter in your example time of:

2016-09-01 01:23:45

…it displays:

2016-08-31 21:23:45.

I think an idiot-proof solution is having a date/time js calendar to select schedule times in human readable format, and have display times reflect the times entered with said calendar. The actual event would be scheduled correctly in the background while admin-user will see human readable local time.

I also don’t think the logic in function get_date_from_gmt() is accurate. Why apply the TZ to the time if $tz is not empty/null. It seems to be taking the time, after offset and reapplying the offset found. But that is a core wp function and probably outside the scope of your plugin.

We tried the latest version of your plugin found here on the wp plugins directory site. Our WP version is latest 4.6+

We’ve skipped on using your plugin due to errors out of the box, so no need for us to open a support ticket. We simply went with an alternative plugin.

But I would recommend you correct this issue for future users.

Good luck.

Hi Maria,

First, if you must use your rule, fix it by changing to:

order deny,allow
deny from all
allow from 222.222.222.222 # YOUR REAL IP HERE

Remember, spaces are respected, so ensure yours is exactly like the above.

Assuming you’re using Apache, I recommend installing mod_evasive, fail2ban, mod_security and enabling iptables.

I would also recommend installing a security plugin or two from the plugins directory.

Here is one, although it hasn’t been updated in some time. Seems to work with no issues on my end:

https://www.ads-software.com/plugins/brute-force-login-protection/

Here is another called WordFENCE:
https://www.ads-software.com/plugins/wordfence/

And last but not least, change ALL your passwords and ensure they are strong!

Try something like this password generator:

https://lastpass.com/generatepassword.php

Hope this helps.

Hi John,

Both UTC time and local time summary below event schedule table show correct times. The display issue seems limited to the event lines which use the get_date_from_gmt() function.

Using the date/time you suggested (2016-09-01 01:23:45), upon saving a job called test_cron, the date/time displays as 2016-08-31 21:23:45

As you suggested, the function get_date_from_gmt() inside /wp-includes/formatting.php must be the culprit.

Notice line 2984 of /wp-includes/formatting.php:

$datetime->setTimezone( new DateTimeZone( 'UTC' ) );

I’d have to thoroughly test this hunch, but I suspect it’s setting the time zone to UTC AFTER already setting time zone with $tz. Perhaps only trigger the timezone reset to UTC if $tz is not defined:

if(empty($tz)) {
    $datetime->setTimezone( new DateTimeZone( 'UTC' ) );
}

Since you’re using a core wp function (get_date_from_gmt()), why not swap to the suggested date_i18n() function and call it a day?

Worked for me.

We also set the DISABLE_WP_CRON constant to true, intentionally of course.

A “hide” option for this WP_Cron warning would be nice. This can be saved similar to how other modules or plugins save notification states (as a simple user_meta flag in the db).

As you may be aware, scheduled tasks run dependent on traffic to your site. For critical background tasks that need to run regardless of traffic, the normal alternative is to setup a real cronjob and having it run https://www.example.com/wp-cron.php?doing_wp_cron at needed intervals.

For example:

* * * * * wget -q -O - https://www.example.com/wp-cron.php?doing_wp_cron

… will run that job once per minute.

In our case we need to query an external server for company memo’s and trigger push notifications to mobile devices as the memo’s came in. If a memo is pushed out after working hours and no one is using the WordPress site, the memo notifications weren’t being sent until some traffic was generated. This could be two days later if we’re talking about a weekend!

The current WordPress mechanism to schedule tasks, although nifty, has it’s limitations. Using an actual cronjob solves this issue. But now there is a warning in the admin which doesn’t go away. There should be at least a hide option.

Just my two cents.

If you’re like me and have buddypress groups turned off, this will produce the error shown. I fixed by adding this to

/wp-content/plugins/buddypress/bp-groups/classes/class-bp-group-extension.php

change:

$group_id = bp_get_current_group_id();

to:

$group_id = (bp_is_active('groups') ? bp_get_current_group_id() : '');

and change:

if ( empty( $group_id ) && bp_get_new_group_id() ) {
    $group_id = bp_get_new_group_id();
}

to:

if(bp_is_active('groups')) {
    if ( empty( $group_id ) && bp_get_new_group_id() ) {
        $group_id = bp_get_new_group_id();
    }
}

IMO, they should have tested this before pushing out an update. Hopefully they figure things out.