model13

Yes, it absolutely does. Sorry about that — fire drill happened in the middle of posting. I missed a set of parentheses. Here it is, tested and working:

function remove_plt_from_custom_type( $post_types )
{
if ( in_array( ‘mycustomtype’, $post_types ) ) {
$index = array_search ( ‘mycustomtype’, $post_types );
unset( $post_types[$index] );
}
return $post_types;
}
add_filter( ‘page-links-to-post-types’, ‘remove_plt_from_custom_type’ );

The plugin is coded so you can apply a filter to remove it from types you don’t want. The function goes something like this (this is untested):

function remove_plt_from_custom_type( $post_types )
{
if ( in_array( ‘mycustomtype’, $post_types ) ) {
$index = array_search ( ‘mycustomtype’, $post_types );
unset $post_types[$index];
}
return $post_types;
}
add_filter( ‘page-links-to-post-types’, ‘remove_plt_from_custom_type’ );

You’d replace ‘mycustomtype’ with the slug of the post type you want to remove the meta box from.

I was coming to inquire about the same thing. The reason it’s not working in Gutenberg is because there’s a function in the plugin, do_meta_boxes(), that checks $context to see if the value is ‘advanced’ before adding the meta box. (The $context variable determines whether the meta box is added to the sidebar or below the WYSIWYG field.)

I’m not clear if the value ‘advanced’ is not valid in Gutenberg, or if $context itself is no longer a thing, but the references to “advanced” are what’s keeping it from working. It’s an easy fix, and I was rather surprised that recent updates to the plugin didn’t include this.

Thanks again!

Thank you for your prompt attention and response! Will you let the developers know that when they do resolve all the issues, it would be helpful to site administrators if they include that detail in the update’s release notes? We appreciate the help in getting ready for 7.x.

Thank you! I appreciate the info. I’ve encountered this with a couple of other plugins as well. As much as I’d like to dissect them all myself, we’re running too many installations (including several multisites) to cover all the bases at short notice.

I’m getting the same errors. The rest of the error message is:

made by activate_plugin, do_action(‘activate_broken-link-checker/broken-link-checker.php’), WP_Hook->do_action, WP_Hook->apply_filters, blc_activation_hook, require(‘/plugins/broken-link-checker/includes/activation.php’), blcModuleManager->plugin_activated, blcModule->plugin_activated, blcContainerManager->activated, blcAnyPostContainerManager->resynch, blcPostTypeOverlord->resynch

I’m seeing three warnings when I test:

FILE: [path redacted]/wp-content/plugins/broken-link-checker/core/core.php
———————————————————————–
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
———————————————————————–
957 | WARNING | Function create_function() is deprecated since PHP 7.2; Use an anonymous function instead
———————————————————————–

FILE: [path redacted]/wp-content/plugins/broken-link-checker/includes/utility-class.php
———————————————————————–
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
———————————————————————–
42 | WARNING | INI directive ‘safe_mode’ is deprecated since PHP 5.3 and removed since PHP 5.4
———————————————————————–

FILE: [path redacted]/wp-content/plugins/broken-link-checker/modules/checkers/http.php
———————————————————————–
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
———————————————————————–
147 | WARNING | Function create_function() is deprecated since PHP 7.2; Use an anonymous function instead
———————————————————————–

I was coming here to report this. We’re currently running tests of plugins with PHP Compatibility Checker. It generates the following warning for CMS Tree Page View when tested on PHP 7.2:

FILE: [path redacted]/wp-content/plugins/cms-tree-page-view/functions.php
———————————————————————–
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
———————————————————————–
654 | WARNING | Function create_function() is deprecated since PHP 7.2; Use an anonymous function instead
———————————————————————–

Thank you! I appreciate your response — and this great plugin. We’ve renamed our own searchform shortcode and updated our top-level sites to make this less urgent on our end.

I ran multiple tests on a dev installation with WP_DEBUG enabled, and the timeout option is appearing there. Then I triple-checked my existing sites and confirmed that I didn’t imagine that they’re missing. I didn’t imagine it.

No idea why they’re working now and weren’t last fall (our stats all seem to have hung in November), but I’m optimistic that flushing the transients will fix the problem and that it won’t reappear.

It’s not really resolved for me. I have 200+ sites and can’t really stop and clear the cache manually for each one.

Looking into the code, I see that the plugin stores the dashboard data in a transient that’s supposed to time out after 12 hours. However — and I’ve checked seven or eight sites and found the same thing on each — the corresponding timeout option isn’t in the options table. I have no idea why at this point (will report it if I find out in short order).

Since WP can’t find the timeout data it’s hanging onto the out-of-date stats permanently. As this clearly wasn’t the intent of the developer I hope it can be checked out and resolved with an update.

Let me restate this one more time. We have a multisite. On the child sites where Events Manager is activated, whenever a user on that child site accesses a page in /wp-admin/ on the child site, that user is being added as a Subscriber on the root site.

There is no creation of new users, just adding existing users. And yes, this behavior happens any time the user loads any admin page on the child site.

This happens when the multisite setting “Locations on main blog?” is set to Yes.

No, this is not desired behavior.

OK, I flushed out this installation of WP — not only uninstalled and deleted Events Manager but went in and removed related capabilities and sitemeta entries left behind when the plugin is removed.

Once that was done I started over again with the same process described above, but using the plugin’s default settings. When using it straight out of the box it doesn’t create the Subscriber account on root.

I repeated this process, turning on the Multi Site Options in network admin one by one. When I set “Locations on main blog?” to Yes and tested it out, that’s when Events Manager started adding accounts from the child site as a Subscriber on the root site. So whatever is happening seems to be tied to that feature. I’ll continue testing and report any other settings that may be involved.

OK, to be absolutely sure it’s the plugin, I set up a virgin installation of WP multisite on localhost on my desktop. I started with 4.3.1 and upgraded it to 4.4 before starting this test.

There are three sites on this installation. All three are using Twenty Fifteen. No plugin other than Events Manager is installed and there is no custom code of any kind running. Events Manager is activated on the root site and the first child but not on the second child.

I set up a test user account (I’ll call this one “joe”) with Administrator access on the first child site where Events Manager is activated. I logged out and then logged in as joe. I went to Posts. I went to Pages. I did not go to Events or touch anything related to it. I logged out.

When I logged back in as the super admin I went to the root site and found joe had been added as a Subscriber.

For the second child site where Events Manager is not activated, I repeated this process with a second test user account (which I’ll call “fred”) with Administrator access. I repeated the process I followed with the joe account.

After I logged out as fred and logged back in as super admin, I went to the root site and found fred had NOT added as a Subscriber.

So this is specific to Events Manager. As on the production site, this virgin installation does not have Bookings activated and is not using the submission form in any way. I copied over the settings from the root and a child site on production to this virgin installation on setup.