Kevin Behrens

@yoursql719 We are debugging the issue and will soon release a Planner update to prevent the invalid notifications. To help us narrow down the condition that triggered this, can you list any other PublishPress plugins that were active on your site at the time?

@ldwd Are you using Statuses Pro or the free Statuses plugin?

Hello @priyankac,

Please try the following troubleshooting / workaround steps:

1. Use a website file manager to delete the folder press-permit-core folder (inside wp-content/plugins).
   
2. Use phpMyAdmin or a similar database utility to execute the following query:
   DELETE from wp_options WHERE option_name = 'presspermit_version'
   Note that you will need to change “wp_options” to your actual table name including the unique database prefix.
   
3. Edit your wp-config.php file, adding the following code snippet just below existing constant definitions:
   define( 'PRESSPERMIT_LEGACY_DB_SETUP', true );
   
4. Re-activate the plugin.

If you can’t execute a database query, try using your database utility to browse the options folder, search for the option_name presspermit_version, then delete the matching row in the search result.

@prachi-vashishtha Do you have a stack trace tying those Revisions plugin lines to the PHP warning? If not, how did you make the connection? My code review shows that none of them are actually instances of passing a null value into the function. If the issue is repeatable only with the Revisions plugin activated, please let me know what site access seems to trigger it, and what other plugins you are running.

Please also tell us your Revisions plugin version.

[deleted reply due to cross-posting to Revisions plugin support]

@noman56 miniOrange should update their ‘use_block_editor_for_post’ filter function to bypass processing if a null post argument is passed in. We will provide a fix on our end in the next Permissions release. Until then, you can install the newly updated PublishPress Permissions development version (4.0.36-beta).

In marking this as resolved, I will also mention that there’s a plugin setting to control this behavior:

Permissions > Settings > Editing > Editor Options > Auto-assign available term if default term is unavailable

@comaxxdevelopment Can you please upload the newly updated PublishPress Permissions development version (4.0.35-beta) and confirm that it clears your error? There are no other changes from the 4.0.35 release.

Hello, @lucasbustamante. You are correct that the only result of removing that filter is non-display of the “Has Revision” caption and “Revision Queue” action link for each post that has a revision in the queue.

Your alternative would be to give the posts table of your database indexes on the comment_count and post_mime_type fields.

@katerinamo Please install our PublishPress Capabilities plugin, then navigate to Capabilities > Capabilities. Set the dropdown selector to load your Custom Admin role, then click on the PublishPress Permissions tab. Give this role the following capabilities:

• pp administer content
• pp assign roles
• pp create groups
• pp delete groups
• pp edit groups
• pp manage members
• pp manage settings
• pp set associate exceptions
• pp set edit exceptions
• pp set read exceptions
• pp set revise exceptions
• pp set term assign exceptions
• pp set term associate exceptions
• pp set term manage exceptions
• pp unfiltered

@valerieeskens As a pro plugin user, please submit support tickets through the PublishPress website.

That said, we will be releasing an update to resolve this Elementor conflict today.

Hi, @aayushb051. You can find an explanation of this new safeguard by following the “See documentation” link in that error message. To revert to the previous behavior, disable the following plugin setting:

Revisions > Settings > Revision Creation > “If post contains custom html, require unfiltered_html capability”

@doume2ga The PHP warning is fixed in the newly updated PublishPress Permissions development version (4.0.31-rc2). The fix will also be included in the next Permissions release (4.0.31)

@hroem Thanks for reporting that conflict with Events Manager. This is fixed in the newly updated PublishPress Permissions development version (4.0.31-rc2). The fix will also be included in the next Permissions release (4.0.31)

@doume2ga This will be fixed in the next plugin release.