Joshua David Nelson

Just a quick follow up to note this was fixed in v0.5.3

Hey @baruch60610 thank you for alerting me to this issue. I was able to track it down, no vulnerabilities or exploitable issues, just a typo in the uninstall file that causes the WP delete to not work. I’ll have this fixed in the next release.

You can delete the plugin manually using your site’s FTP and delete the plugin folder, or update the plugin when the next version is released and delete it through the WP plugin screen.

In the future, if you have an issue or find a bug, it’s more helpful to post it in the support forum than post a low review.

Hey again! Just wanted to update you on my status, I’m working on some updates to address this issue and provide better integration with Disable Comments in general.

I have some more tests to run on this feature, but hoping to have it released in the next version sometime in the next week or two.

Oh man, what a silly thing for me to miss – not sure why the typeof didn’t get in there! ???♂?

Thanks following up on this, super appreciate it.

I’m offline for the rest of the week, but I’ll get that updated next week.

This error should be fixed in version 0.7.1 now, but please let me know if you have any other issues.

I’m closing this topic, but feel free to re-open or start a new one if needed.

Actually, I discovered the issue – duplicated plugin header is causing the error. I’ll have an update soon

hey @website-rob thanks for report this, sorry you’re encountering issues. I’d like to replicate this on my end to help debug it. Can you confirm what version of WordPress and PHP you have on these sites?

Hey @landwire – thanks for reaching out on this.

If that page returns true for the is_home() function, then it will be considered the “blog_page” by Disable Blog. You can filter the redirect url via the dwpb_redirect_blog_page filter, passing a false to disable the redirect for that template – just be sure you’re using some logic to confirm it’s your custom template and not the actual blog page.

If that doesn’t work for some reason, there is a broader filter dwpb_redirect_front_end that toggles all front-end redirects. It will disable the redirect if it returns false. You could use a similar approach as above, checking that you’re on the specific page/template and returning false or, if you have a unique template file, you could drop this in it: add_filter( 'dwpb_redirect_front_end', '__return_false' );

Let me know if you run into any issues or have any other questions.

Hey @cdbtech thank you so much for reaching out with on this issue and including these details!

That function was modeled after wp_count_comments to include caching, but I can see how a large WC shop may encounter an issue. I’ll get a fix for this in the next version – I like the idea of adding a filter to disable/change this functionality, but I’ll also likely add the shop order post type exclusion.

In the meantime, as of v0.5.1, there is a ‘remove_action’ filter available in the loader class, following this example you should be able to remove the comment count filter with the following code:

/**
 * Place the code below in a custom plugin or your theme's functions.php file
 * to remove the wp_count_comments filter in Disable Blog.
 *
 * This pattern can be used for any hook/filter in the plugin
 * using the remove_action method.
 *
 * @see /includes/class-disable-blog-loader.php#L128
 * @since 0.5.1
 * @param string $tag              The filter hook to which the function to be removed is hooked.
 * @param string $class_name       Class name registering the filter callback.
 * @param string $method_to_remove Method name for the filter's callback.
 * @param int    $priority         The priority of the method (default 10).
 */

if ( class_exists( 'Disable_Blog_Loader' ) ) {
	$loader = new \Disable_Blog_Loader();
	$loader->remove_action( 'wp_count_comments', 'Disable_Blog_Admin', 'filter_wp_count_comments' );
}

I’m out of town the rest of this week, but I’ll try to get an update out next week.

Just a follow up to note that version 0.5.2 introduced a fix for this issue.

I’m going to close this topic, but if you are still encountering issues please feel free to re-open or reach out with a new issue.

Just a follow up to note that version 0.5.2 reverts the block editor functionality introduced in 0.5.1, this filter is no longer exists and the block editor issues should be resolved with the new version.

I’m going to close this topic, but if you are still encountering issues please feel free to re-open or reach out with a new issue.

Thanks for the push on this, I finalized and deployed v0.7.0 today – including some updates to the code structure and tooling, but otherwise no major changes to the plugin functionality.

I’m going to close out this ticket, but please feel free to re-open it or start a new topic if you have any questions or run into any issues.

• This reply was modified 2 years, 1 month ago by Joshua David Nelson.

Hello again,

Thanks for the follow up. I have an update primed to go, I just need to run some last tests. I’ll have a new version up by next week at the latest.

Thanks,
Joshua

Hey there,

Sorry to hear?that you’re encountering issues. I responded to your email, but I’ll follow up here as well.

The Disable Blog plugin doesn’t do anything to the database, it relies entirely on WordPress hooks and filters, and the plugin files to be installed & activated to work. If you deactivate the plugin or, even better, delete the plugin files from your server (via File Manager or FTP), it will no longer be able to do anything.

If you continue to have issues after deleting the plugin files, that is something related to your theme or other plugins.

It sounds like you’re using a caching plugin, which may need to clear the cache and/or have the cache rebuilt. If it stopped working after activating the Disable Blog plugin, it may need to regenerate those files after deactivating Disable Blog.

All the errors in your log are related to the Cloudflare Page Cache plugin – it might be worthwhile trying to deactivate that one if you can’t successfully clear and rebuild its cache.

Just to be clear, Disable Blog can’t work if it’s deactivated or the files are removed.

I highly recommend testing new plugins, updates, and changes in a staging site before making changes to your live site – especially for a highly customized site.

Best of luck,

Joshua

• This reply was modified 2 years, 1 month ago by Joshua David Nelson.

Hey again,

Sorry it’s taken me so long to get back to this, but I took some time to review this issue further. As far as I can tell, you’ll likely want to make some changes to your permalink settings.

I was able to confirm that the %category% permalink option will result in redirecting any url in the /level1path/ format in your above example to the homepage. That is not what you would expect, but only happens with the %category% structure in place and the plugin active. Remove the %category% base and the urls will go back to the expected result: 404 pages.

For context: When the plugin is active it will disables the ‘post’ content type, which also disables functionality related to the built-in categories and tags taxonomies – by default only used by the ‘post’ type. With no categories, the plugin will remove the category as an option for the permalink structure.

So, typically if you’re disabling the blog, you won’t have categories or tags because you don’t have posts, and you also won’t use non-existent category or tags in your permalink structure.

(Sidenote: If you have a custom post type that is using the built-in ‘category’ taxonomy, then these features will remain, but most sites do not have custom post types acting in this way)

I’m going to close this topic, because after digging into this further I don’t think anything in the plugin needs to change necessarily. However, please reach out if you have additional issues or questions – feel free to re-open this topic or start a new one, as appropriate.

Thanks,
Joshua

• This reply was modified 2 years, 1 month ago by Joshua David Nelson. Reason: clarify