Closed joshuadavidnelson closed 4 years ago
Hey @szepeviktor and @chesio - any chance you would be able/willing to review these changes? There is a lot of improvements here and some overlap with #36, I would be grateful for a second and/or third pair of eyes before release. Thanks again for your contributions so far!
Hello Joshua! I refer you to these 3 basic tools: https://github.com/joshuadavidnelson/disable-blog/pull/27/files#diff-d948ac4d33809eeb8eafe9eb59a6d05a Please merge that PR or use these 3 tools in any other way.
After that I would gladly review your code ❤️
Please consider moving old-style todo-in-code to sustainable GitHub Issue.
Hey Viktor! Thanks for the quick feedback. I have to move onto other things today, but my next task is to circle back to your PR. I'll try to get that integrated into this PR in the next day or two and then I'll reach out again. Thanks for the help!
Requires at least: 3.1.0
Does it mean that disable-blog must be able to run on PHP 5.2?
Requires at least: 3.1.0
Does it mean that disable-blog must be able to run on PHP 5.2?
Hmm, I guess it could be interpreted that way based on the core PHP compatibility. I haven't updated the min WP version in some time, it was originally based on this tool, but I believe that tool only checks for WordPress functions used in the plugin to determine the minimum version.
I could update the Requires at least
to WP 5.2 in order to drop the older versions of PHP and/or add the Requires PHP
header to the readme.txt. My preference is provide a reasonable level of backwards compatibility, but honestly I'd rather see PHP 7.0 and greater. That said, we're testing from 5.3 and up, so that would be a good middle ground and provide a large net of backwards compatibility
Huzaah! Took a little time to get all those checks passed, aside from moving abroad this last month I've also setup a new computer - so finding time to work on this took some time, and then getting vscode to replicate the checks being run in github correctly took some trail-and-error. I haven't gone back through to manually check that all the plugin functionality is working as expected, but I will over the weekend.
I went back through this and since I've updated the post_type
arguments to make posts non-public, etc there were some functions that could be removed, also wiping out the default supports
argument for posts - this pulls posts out of a variety of places in the admin.
Includes the following:
post_type
arguments for posts so they are no longer public and removes all post_type support parameters. This disables the post-related admin redirects, as WordPress will now show users an error page stating "Sorry, you are not allowed to edit posts in this post type." It also pulls posts out of a lot of other locations (menus, etc, achieving the same thing as #36. Thanks to @chesio for his contribution there) and is a much more efficient method of "disabling" the 'post' type. This method is also used on built-in taxonomies, unless another post type supports them. This change may impact other plugins or themes, be sure to back up your site and, if you can, test these changes prior to updating the plugin on a production site.edit-comments.php
admin page if no other post type support comments (note that WordPress default is for pages and attachments to support comments).plugins_loaded
hook.post
post types from all archives, previously it was just author archives and search results.dwpb_redirect_feeds
filter now has (3) params, to match those in thedwpb_disable_feed
filter: $bool, $post, $is_comment_feed.dwpb_author_post_types
filter is nowdwpb_archive_post_types
, as the query modification now includes all pages passingis_archive
.dwpb_disable_rest_api
,dwpb_remove_post_comment_support
,dwpb_remove_post_trackback_support
,dwpb_redirect_admin_edit_single_post
,dwpb_redirect_single_post_edit
,dwpb_redirect_admin_edit_post
,dwpb_redirect_edit
,dwpb_redirect_admin_post_new
,dwpb_redirect_post_new
as these are rendered obsolute by above changes.