Controlling access to your functions

We have a custom router which handles the URLs of the user section of our application. Next, we need a controller to handle the requests and generate the template for the user. This works similar to the controllers in the MVC pattern.

Even though we have changed the default routing, WordPress will look for an existing template to be sent back to the user. Therefore, we need to intercept this process and create our own templates. WordPress offers an action hook called template_redirect for intercepting requests. So, let's implement our frontend controller based on template_redirect. First, we need to update the constructor of the WPWAF_Config_Manager class with the template_redirect action, as shown in the following code:

    add_action( 'template_redirect', array( $this, 'front_controller' ) ); 

Now, let's take a look at the implementation of the front_controller function using the following code:

    public function front_controller() { 
      global $wp_query,$wpwaf; 
      $control_action = isset ( $wp_query-
     >query_vars['control_action'] ) ? $wp_query-
     >query_vars['control_action'] : ''; ; 
        switch ( $control_action ) { 
        case 'register': 
          do_action( 'wpwaf_before_registeration_form' ); 
          $wpwaf->registration->display_registration_form(); 
          break; 
      } 
    } 

We will be handling custom routes based on the value of the control_action query variable assigned in the previous section. The value of this variable can be grabbed through the global query_vars array of the $wp_query object. Then, we can use a simple switch statement to handle the controlling based on the action.

The first action to consider will be to register as we are in the registration process. Once the control_action query variable is matched with registration, we execute an action and a function call to display_registration_form.

You might be confused about the location of this function and how it was executed. Basically, we need a separate class to handle the registration-related functionality. So we need to create a new class called WPWAF_Registration inside the classes folder and create an object inside the instance function of the WPWAF_Forum class using the following code:

    self::$instance->registration    = new WPWAF_Registration();  

Then we need to also include this file inside the includes function of the WPWAF_Forum class with similar code to that used for the WPWAF_Config_Manager class. Next, we can add an empty function called display_registration_form to the WPWAF_Registration class. Finally, we need to identify how this function was called inside our controller.

We structured our main class based on the singleton pattern. So, only one object will be initialized and it will be responsible for handling all the system calls. We created a global object called $wpwaf in our main forum class. We can call other class functions using the global object. First, we need to add it as a global object to our front_controller function. Then we can call the registration object on top of the global $wpwaf object. Finally, we call the display_registration_form function on top of both of those objects as follows:

    $wpwaf->registration->display_registration_form(); 

You might be confused about why we use do_action in this scenario. These actions allow us to customize and extend the registration form display in different scenarios without modifying the core code. Let's discuss do_action in more detail in the next section.