FireStudio – Core Concepts – Features and Services

At the core, FireStudio is a framework that makes it extremely easy to rapidly create new features and functionality for WordPress. It provides a simple Object Oriented Programming architecture which help you keep your code organized, clean, and easy to test. FireStudio also comes bundled with a number of debugging tools, making it possible to inspect and debug the environment you are developing in. Lastly, FireStudio comes bundled with a simplified interface for working with data and the database. Saving, updating, retrieving, and deleting data just got so much simpler.

There are two main concepts you need to be familiar with in FireStudio, Features and Services. A Feature, is a class that provides the custom functionality you intend to integrate into WordPress. A Service is a class that provides shared functionality to be used by features.

The main difference between features and services is that a feature implements the custom functionality (also known as business logic) you are developing. A service represents shared functionality that might be used between different services.

Other than features and services, there are some other, more advanced concepts, we will cover as well. The FireDi (The Injector), FireBug (The Debug Panel), and FireSql (The Data Interface).

Feature

Features are meant to contain the business logic (also known as custom functionality) you would like to implement within WordPress. Whether you are trying to add new admin pages, or you are trying to build out a new custom block for Gutenberg, you will implement these as a Feature within FireStudio. Creating a feature will start with the boilerplate code:

namespace My\Custom;

use \UA1Labs\Fire\Studio\Feature;

class Logic extends Feature
{
    public function __construct()
    {
    }
}

Once you have the boilerplate in place, you can have to load the feature with FireStudio:

function add_fire_studio_features(\UA1Labs\Fire\Studio $fireStudio)
{
    $fireStudio->loadFeature(\My\Custom\Logic::class);
}
add_action('firstudio_loaded', 'add_fire_studio_features');

Once a feature has been loaded into FireStudio, you can start implementing custom functionality.

In WordPress, all functionality is added through using Action/Filter Hooks. FireStudio has made it easier than ever to register Feature class methods to actions using the @action decorator. Using the boilerplate class you created above, we can register actions like so:

namespace My\Custom;

use \UA1Labs\Fire\Studio\Feature;

class Logic extends Feature
{
    public function __construct()
    {
    }

    /**
     * @action init
     * @priority 0
     */
    public function myCustomAction()
    {
        // action logic here
    }
}

Notice in the myCustomAction() method above, you will see a doc block that includes an @action and @priority decorator with a value. In the background, FireStudio will register the myCustomAction() method with the init hook at a priority of 0. It would be the equivalent of:

$myCustomLogic = new \My\Custom\Logic();
add_action('init', [$myCustomLogic, 'myCustomAction'], 0);

Which means at the point where WordPress executes the init action hook, our method myCustomAction() will be executed.

Service

Services are meant to contain shared logic that Features might need. An example of this might be something like needing to check to determine if the logged in user is an admin user. A service does not need any special boilerplate to create it. Also, it does not need to be registered with FireStudio like a Feature does.

Services are integrated into Features through the constructor method of the Feature class. Let’s say that we want to use the \UA1Labs\Fire\Studio\Service\WpHelperService that comes bundled with FireStudio, within the Feature we are building. All you need to do is add a type hint into the constructor method of your feature. Like so:

use \UA1Labs\Fire\Studio\Feature;

class MyAwesomeFeature extends Feature
{
    /**
     * @var \UA1Labs\Fire\Studio\Service\WpHelperService
     */
    private $wpHelper;

    public function __construct(WpHelperService $wpHelper)
    {
        $this->wpHelper = $wpHelper;
    }
}

When FireStudio loads this feature into the FireStudio run time environment, it will automatically find and inject the Service class you type hinted on the constructor.

FireSql – API Documentation

UA1Labs\Fire\Sql

__construct(PDO $pdo)

The class constructor.

  • @param \PDO $pdo
  • @return void
<?php
$pdo = new \PDO('sqlite:' . __DIR__ . '/demo.db');
$db = new \UA1Labs\Fire\Sql($pdo);

public function collection($name, $options = null)

Returns a collection object that will allow you to interact with the collection data.

  • @param string $name The name of the collection
  • @param array $options The collection options
  • @return \UA1Labs\Fire\Sql\Collection

Available Options:

  • versionTracking (default: false) – Determines if the collection should turn on the version tracking feature for collection updates.
<?php
$collection = $db->collection('CollectionName');

\UA1Labs\Fire\Sql\Collection

__construct($name, Connector $connector, $options = null)

Creates an instance of a new collection.

  • @param string $name The name of the collection
  • @param \UA1Labs\Fire\Sql\Connector $connector The connection to the database
  • @param array $options An array of options

Available Options:

  • versionTracking (default: false) – Determines if the collection should turn on the version tracking feature for collection updates.

find($filter = null)

Returns a collection of objects that match the filter criteria.

  • @param string | null | \UA1Labs\Fire\Sql\Filter $filter
  • @return array
<?php
$objects = $collection->find('{}');

insert($object)

Inserts an object in the collection.

  • @param object $object
<?php
$collection->insert($myObject);

update($id, $object)

Updates an object in the collection.

  • @param string $id
  • @param object $object
$collection->insert($id, $myObject);

delete($id)

Deletes an object from the database.

  • @param string $id The ID of the object you want to delete
$collection->delete($id);

count($filter = null)

Returns the total number of objects in a collection.

  • @param string | null | \UA1Labs\Fire\Sql\Filter $filter
$count = $collection->count('{}');

FireStudio 1.1.0 Release Preview

We’ve been working on the next release of FireStudio. We are excited to be bringing some new functionality and capabilities to the users of this plugin. Setting the direction of where we are going with this plugin, we are officially supporting this as a framework for building functionality into WordPress.

With the 1.1.0 release, we’ve completely refactored our code base to open up our APIs to other WordPress developers. Over the next couple of weeks, we will be producing many tutorials on how you might be able to use FireStudio to kickstart your development efforts in WordPress.

One feature we are really excited to bring you is the ability to see all WordPress Action Hooks that ran, along with callbacks. We were even able to achieve getting the order of execution to demystify WordPress all together! No more guessing on what hook you should be using, or what priority you should give it!

FireStudio Debug Panel Previewing Hook Execution

WordPress Hook Order Of Execution

In order to build anything for WordPress, you know that action and filter hooks are the way to go. But hooks are still a bit of a mystery because we don’t really have any concept of the order in which they are executed. Until now:

HookFront PageAdmin Page
muplugins_loadedXX
registered_taxonomyXX
registered_post_typeXX
plugins_loadedXX
sanitize_comment_cookiesXX
setup_themeXX
load_textdomainXX
after_setup_themeXX
auth_cookie_malformedX
auth_cookie_validXX
set_current_userXX
initXX
widgets_initXX
register_sidebarXX
wp_register_sidebar_widgetXX
wp_default_scriptsXX
wp_default_stylesXX
admin_bar_initXX
add_admin_bar_menusXX
wp_loadedXX
parse_requestX
auth_cookie_validX
auth_redirectX
admin_menuX
admin_initX
current_screenX
send_headersXX
parse_queryX
pre_get_postsXX
posts_selectionXX
wpXX
template_redirectX
get_headerX
wp_enqueue_scriptsX
wp_headX
wp_print_stylesX
admin_xml_nsX
admin_enqueue_scriptsX
admin_print_stylesX
admin_print_scriptsX
wp_print_scriptsXX
admin_headX
admin_menuX
in_admin_headerX
admin_noticesX
all_admin_noticesX
restrict_manage_postsX
get_search_formX
loop_startX
the_postXX
get_template_part_contentX
loop_endX
get_sidebarX
dynamic_sidebarX
pre_get_commentsX
wp_metaX
get_footerX
wp_footerX
wp_print_footer_scriptsX
pre_user_queryX
in_admin_footerX
admin_footerX
admin_bar_menuXX
wp_before_admin_bar_renderXX
wp_after_admin_bar_renderXX
admin_print_footer_scriptsX
shutdownXX
wp_dashboard_setupX