• Resolved macbookandrew

    (@macbookandrew)


    Unfortunately I don’t have a minimally reproducible test case for this or a URL where you can see the behavior because we need to get it fixed for our client, but here’s what we observed.

    In v1.8.0, the wp-content/plugins/charitable/includes/admin/class-charitable-admin-blocks.php file uses a faked REST API request to check whether the create-block/campaignblock block is registered.

    This resulted in some conflict with FacetWP and deregistered the /wp-json/facetwp/v1/refresh endpoint that FacetWP uses on the frontend, resulting in 404 errors.

    Rather than using a fake REST API request, I propose using the WP_Block_Type_Registry class to check for the existence of the block to avoid similar unintended side effects.

    Here is a patch file showing the proposed changes that fix the issue for me:

    diff --git a/wp-content/plugins/charitable/includes/admin/class-charitable-admin-blocks.php b/wp-content/plugins/charitable/includes/admin/class-charitable-admin-blocks.php
    index 093e3184a..6c5c7210d 100644
    --- a/wp-content/plugins/charitable/includes/admin/class-charitable-admin-blocks.php
    +++ b/wp-content/plugins/charitable/includes/admin/class-charitable-admin-blocks.php
    @@ -80,16 +80,7 @@ if ( ! class_exists( 'Charitable_Admin_Blocks' ) ) :
     		}
     
     		private function is_block_registered( $block_name ) {
    -			// Use REST API to query if block exists by <namespace>/<name>.
    -			$route   = new WP_REST_Request( 'GET', '/wp/v2/block-types/' . $block_name );
    -			$request = rest_do_request( $route );
    -
    -			if ( $request->status == 404 ) {
    -				// Block is not found/registered.
    -				return false;
    -			}
    -			// Block is registered (status is 200).
    -			return true;
    +			return WP_Block_Type_Registry::get_instance()->is_registered( $block_name );
     		}
     
     		/**
    
Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Author WPCharitable

    (@wpcharitable)

    @macbookandrew

    First of all, thanks for reaching out to us about the conflict with FacetWP and providing a patch. I’m going to pass this along to the team to review with the information you provided so far.

    Would it be possible to supply additional information:
    1. What version of FacetWP you are using.
    2. I know you saw you couldn’t provide a test case, but can you describe what settings/setup the site had with FacetWP, where you saw the 404 errors, etc. so we can duplicate the issue on our end to confirm the (eventual) fix?

    Since this is part of Charitable core we wouldn’t also mind reaching out to you to ensure a possible fix in a future version works fine for your client. If you want to share your contact information securely with us here (and feel free if you want to include the above info we requested in that sharing), we would def. follow up. And, thank you!

    Thread Starter macbookandrew

    (@macbookandrew)

    1. What version of FacetWP you are using.

    Currently 4.0.9, though I did also test with the most recent 4.2.8 as part of troubleshooting.

    2. I know you saw you couldn’t provide a test case, but can you describe what settings/setup the site had with FacetWP, where you saw the 404 errors, etc. so we can duplicate the issue on our end to confirm the (eventual) fix?

    I set up a demo site showing the behavior: https://charitable-facetwp-demo.luminfire.dev/facetwp/

    It’s pretty basic…no special configuration or anything.

    1. Installed Charitable and didn’t do anything else with it
    2. Installed FacetWP and used the default facet for post categories
    3. Added a couple of posts in different categories
    4. Created a facet listing for blog posts and added it to the page

    If you use the checkboxes and watch network requests, you’ll see the 404 Not Found response and nothing will happen on the page. If you perform a full page refresh, you’ll see the filters from the URL applied.

    When both plugins are active, visiting https://charitable-facetwp-demo.luminfire.dev/wp-json/facetwp/v1 will produce rest_no_route error with the message “No route was found matching the URL and request method.”

    If you disable Charitable, you’ll see two valid REST API endpoints at the same URL: GET /wp-json/facetwp/v1 and POST /wp-json/facetwp/v1/refresh

    Thread Starter macbookandrew

    (@macbookandrew)

    Since this is part of Charitable core we wouldn’t also mind reaching out to you to ensure a possible fix in a future version works fine for your client. If you want to?share your contact information securely with us here?(and feel free if you want to include the above info we requested in that sharing), we would def. follow up. And, thank you!

    I actually don’t have a login for that…but if you register on the demo site I can give you access to the settings and then email you directly.

    Plugin Author WPCharitable

    (@wpcharitable)

    @macbookandrew thank you. never got the register email back, but we did confirm with a recent version of facetwp what was being observed with the REST API endpoints. Our team is going to look further and it seems likely an update to resolve this will be in the next version (either next minor or next major) version of Charitable coming in the upcoming weeks. ????

    Thread Starter macbookandrew

    (@macbookandrew)

    @wpcharitable I just sent you an email directly.

    Thanks for your help!

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Charitable conflicts with FacetWP REST API’ is closed to new replies.