Each time Block is saved a new revision would be created by taking a snapshot from the Block fields. The following list represent the fields that are being copied while creating Block revision:

  • Code
  • Assignment Panel

So when a new revision is being created the Block code and all the assignment panel (Pages, Posts, Custom Posts, Aux, Urls and Expressions are being saved).

Currently, each Block is being saved up to 10 revisions. Block can be reverted to 10 times saves behind however take in your mind that all the other fields (Name, Order, Editor Language, Theme, etc…) cannot be restored as it doesn’t being saved anyway.

Revisions list is ordered in descendant order so that the last revision would be listed first. Once you select a revision CJT helps you look around first by checking if this revision is intended to be restored. The Block would get a read only copy of the Code and Assignment Panel values. You’ll notice that all those fields are disabled and the assignment panel is only showing the assigned Only items. You can discard that revision by click on ‘Cancel’ or save the reivision by ‘Restore’ it.

When the Revision is being cancelled CJT would take you to the last state just before you select the revision from the list however unlike restoring the revision would get a full copy of the revision and restoring the Assignment Panel to the initial/empty state.

Every created CJT Block is automatically assigned a Shortcode that can be used from WordPress Posts. Block can be delegated by using [cjtoolbox] Shortcode. If you’re running a PRO edition you can use the TinyMCE button for inserting the Shortcode. Shortcode can delegate the block by either Block Name or Id. As the Id is a little hard to remember and might broken when moving your site data to another host you its recommended to always use Block Name.

Example: Delegate Block By Name:

[cjtoolbox Name=”NAME”]

Example: Delegate Block By Id:

[cjtoolbox id=”ID”]

Another parameter is being supported by Shortcode is force parameter. force parameter is ideal when the Block you’re trying to delegate using Shortcode is already being linked to the same request via the Assignment Panel. When CJT Applier find such a case where a Block is linked to the request while its delegated via Shortcode it cannot output the same Block twice unless user being  forcing that! That’s it.  force parameter is set to false by default in order to force the Block to be executed and outputted even if its being duplicated just set force to true.

Example: Force Block to be executed via Shortcode even if its being assigned to the same request.

[cjtoolbox name=”NAME” force=”true”]

Output/Execution location is defining where is the code Block is going to be executed or outputted. So that when CJT is preparing the code Blocks it then wait for WordPress signals where those code Blocks should be executed. Currently CJT is using two Location. Header and Footer locations. Header location is being fired by WordPress via wp_head and admin_head hooks for Frontend and Backend sides respectively while Footer location is being fired by WordPress via wp_footer and admin_footer hooks for Frontend and Backend sides respectively.

Blocks executed in the Header location would got their outputs between the HTML <head></head> TAG while Blocks that uses Footer location are going to get outputted just before </body> tag closing tag.

So it would be very handy in many cases to switch between those location based on the script you create. Some Blocks might required some other scripts to be loaded first so they wait at the end/Footer while other those doesn’t require any restriction or need to take a higher priority would use the Header location.

There’re many other Location in the features queue that CJT would include in the next releases. There would a huge number of location that would serve most of the cases that CJT users might need.

NOTE: Hook location has no effect when delegating Global Block with Shortcodes! Using Shortcode for delegating Block would result of output/execute the code Block exactly in the point where the Shortcode is added.

In many case it might require to Activate/Deactivate or Enable/Disable a few code Blocks as those Blocks is not ready at the moment or for other debugging purposes.

Activate/Deactivate code Blocks can be very handy in many situation if preserving the code Block is required however only the functionality is need to be stopped for some conditions. When CJT is preparing the code Blocks to be involved with the current request is then excluded all those Deactivated Blocks as they’re not exists or assigned to the request.

Activate/Deactivate Blocks can be done the State-Switcher button from the Block Toolbox.

Please keep CJT Block names simple and briefly describe the functionality of the block. It can be very useful for remembering things about the block. The block name is also used as the shortcode name, when adding shortcodes to pages/posts.

For editing the block name do the following:

  1. Click on the block name
  2. An input field will appear over the block name
  3. Write the new name and click Enter (alternatively you can click the Save button)
  4. After a moment, your new name would be reflected as the block name

 
NOTE: There is also a pencil icon that can be clicked to allow the block name to be changed. If you did not mean to edit the block name, you can click the Cancel icon that appears next to the Save icon.