In this post we’ll discuss two major components of the upcoming update (v1.0.3): layout changes to the page builder and extending views. In addition, we’ll discuss the next phase of better and easier customisations and a few others things we’re working on.

New layout for the page builder

The sidebar and style editor layout were, without a doubt, generating a large number of complaints from our customers. And to be honest, it’s something that has been bugging us for a long time as well. So, it’s time to get this dealt with.

The complaints we were receiving were mostly related to the sidebar containing blocks and components automatically disappearing when moving the mouse cursor away from the sidebar. In addition, we received a lot of complaints about the style editor being placed partly on top of the canvas. In certain cases, this made it impossible to edit certain elements or it would prevent the user from seeing the changes on the canvas while making them in the style editor.

The new layout contains a static sidebar. This sidebar contains buttons for templates, blocks, components and pages. Clicking any of these buttons will result in the secondary sidebar appearing. Instead of being placed partly on top of the canvas, it pushes out to the left while decreasing the width of the canvas. The result is the sidebars appear next to the canvas instead of on top of it.

Below is short video clip of the new sidebars in action:

The second component of the new layout is the style editor. Previously the style editor panel had a fixed position, resulting in it being placed on top of the canvas. This was rather annoying, as it prevented users from editing certain elements on the canvas. In addition, it was impossible to the see the results when editing an element hidden by the style editor.

To make this better, we’ve started by moving the sidebar to the right side of the screen. In addition, as with the new sidebars, the style editor no longer has a fixed position. As with the sidebars, the result is the style editor appearing next to the canvas, instead of on top of it.

Below is a short video clip of the new style editor in action:

Extending views while maintaining forward compatibility

As we explained in last week’s blog post, being able to safely modify Pagestead while still being able to use official Pagestead updates is a major concern to many of our customers. To facilitate this, we decided to implement a number of features. The first of which will be available in the v1.0.3 update: extending views. This feature allows developers to implement their own custom views without having to modify the original views. More information on the specifics of this feature can be found in the blog post announcing the feature.

Moving forward with improved modification functionality

It goes without saying this feature only covers certain modification scenarios and might not be sufficient for more extensive modifications to the application. To tackle more complex modification cases, we are currently working on a custom hook infrastructure allowing developers to modify controller functions while leaving the original functions intact.

To make this happen, we will be implementing custom points through our existing controllers. Consider the sample code below which implements a hook:

$hook['auth_index_post'][] = array(
    'class'    => 'MY_Auth',
    'function' => 'auth_index_post',
    'filename' => 'MY_Auth.php',
    'filepath' => 'hooks',
    'params'   => ''
);

$hook[‘auth_index_post’]
This would set the desired hook point, in this case “auth_index_post”. This particular hook point is implemented at the end of the index() function in the auth controller (/application/modules/auth/controllers/Auth.php).

‘class’    => ‘MY_Auth’
This is the name of the class containing your custom code.

‘function’ => ‘auth_index_post’
This is the function/method that will be run in the hook point.

‘filename’ => ‘MY_Auth.php’
The filename containing your class (we recommend that you stick with the convention of matching class and file names).

‘filepath’ => ‘hooks’
The folder containing your class, relative to the /application folder. In this scenario, this would be /application/hooks/.

‘params’ > ‘’
Optional parameters to pass to your function as an array.

Now, to implement some customisation within the Auth.php controller, consider the following code (which would be placed in /application/hooks/MY_Auth.php):

class MY_Auth {

    private $CI;

    public function __construct()
    {
        $this->CI =& get_instance();
    }

    public function auth_index_post ()
    {
        $this->CI->data['title'] = 'Test Hooks';
    }

}

The constructor function retrieves a reference to CodeIgniter, allowing for the entire framework to be available in your custom code.

Our function auth_index_post accesses the $data array (which is passed to the auth view) and modifies the title entry with a custom value. When loading the login screen, you will now see the page title reads “Test Hooks” instead of the default value set by the Auth.php controller.

Currently, we’re working on implementing additional custom hooks, writing documentation and testing. Even though the hook infrastructure won’t be included in the v1.0.3 update, we are planning to have it ready for v1.0.4.

Update on Paypal integration

We are getting close to completing Paypal integration. However, we still have a couple of loose ends to tie up and some serious testing to do. Therefore, Paypal integration will not yet be included in the upcoming v1.0.3 release. We are confident we will have it ready for v1.0.4 though.

I have been building web applications and other digital products for more then a decade. Currently on an exciting journey discovering the ins and outs of content marketing while growing my newest business. Dedicated to helping digital agencies and entrepreneurs around the world succeed!

Share This