Documentation

We realise this documentation (below) is massively outdated, so we are starting again. The new documentation will be more thorough with less words, more practical with great examples, as well as a lot more easier to understand overall. Please continue to come back to the progress here: https://css-javascript-toolbox.com/documentation

The abbreviation CJT stands for ‘CSS & Javascript Toolbox’.

CJT was originally developed to help users, bloggers, novice and professional developers with integrating code into their WordPress-powered website. It was developed to provide solutions to many common tasks. For example, adding JavaScript snippets or CSS stylesheets into WordPress pages and posts.

CJT was designed to be flexible and very easy to use. In fact, it can be used in as little as two steps – simply adding your code and assigning where the code goes. The possibility of assigning/associating a piece of code to output or run anywhere within WordPress is just the beginning of what CJT can do!

History of CJT

We released our first version of CJT (v0.3) on the WordPress.org plugin repository in September 2011. CJT until version 0.8, could only allow users to run JavaScript and CSS stylesheet code in parallel with WordPress pages and posts. Since then, HTML and PHP support has been added.

Today, CJT (including CJT Free and CJT Dev) has been solidly worked on by two developers for over two years, equating to around 3000 hours of development time. CJT Pro/Dev has now grown to over 930 files and folders totalling 4.3MB (as of v6.4)

CJT’s internal structure is based on the MVC design pattern. In order to make CJT software maintainable over time and to provide our customers with the best support and upgrade service, a lot of development work has gone into the internal structure.

Specific care has also been taken when it comes to deferring. CJT only reserves memory resources and usage processes when it needs to, otherwise it will not get involved. WordPress plugins that get involved when not being used can risk Memory size has been exceeded issues.

The most basic and fundamental task that CJT is developed for, is to allow assigning a piece of code to WordPress pages/posts.

Creating a separate small plugin might be a good solution, however the user has to identify visitor requests and find a way to associate the parallel code. Also when reassigning the code to different pages/posts, updating the plugin would then be required.

CJT is doing all of its functionality behind the scenes. It not only takes the responsibility for identifying the request and running the code, it allows users to manage and organise their code. This is what gives CJT users the chance to clear their headspace from all the other complexities and just focus on the model they wish to create.

Not all users are able to create a WordPress plugin – even a single line WordPress plugin. Some users prefer not to deal with the technical things like connecting through FTP and dealing with programming editors. CJT solves that problem by providing a simple UI that would be easy for most WordPress users who know the basics of making a web site.

Fresh install — WordPress Plugins interface

1. Download CJT zip package (for CJT Dev – see purchase receipt)
2. Login to WordPress Dashboard
3. Open Plugins page
4. Upload the zip package and Activate the plugin
5. Click on the CSS & JavaScript Toolbox Dashboard menu and follow the admin notice on the TOP to complete the installation process

Fresh install — FTP

1. Connect to WordPress server using FTP
2. Unzip the CJT package
3. Upload css-javascript-toolbox folder found in the zip package to wp-content/plugins folder
4. Open Plugins page and Activate the CJT plugin
5. Click on the CSS & JavaScript Toolbox Dashboard menu and follow the admin notice on the TOP to complete the installation process

Fresh install — Host Panel File Manager

1. Login to Host Panel
2. Open Files Manager provided by the Host Panel
3. Upload the zip package to wp-content/plugins folder
4. Use File Manager Tools to unzip the package
5. After a new folder named ‘css-javascript-toolbox’ appears, delete the zip package you uploaded
6. Open Plugins page and Activate the CJT plugin
7. Click on the CSS & JavaScript Toolbox Dashboard menu and follow the admin notice on the TOP to complete the installation process

Automatic upgrades

Like any WordPress plugin, CJT would notify you if updates are available from the CJT server. Click on the Update Now link. If there is a database upgrade to be performed, CJT will display admin notification to guide you through this process. You can also go directly to the CSS & Javascript Toolbox page and follow the upgrade steps.

Uninstall

NOTE: CJT does not clean up its database records when deactivated/deleted. If you require all data associated with CJT to be deleted, please click the General Plugin Settings button (cog icon), and under the Uninstall tab, select the Wipe all data! option. Then simply:

1. Deactivate CJT plugin via WordPress Plugins list page.
2. Delete CJT plugin via WordPress Plugins list page.

CJT comes with an Advanced Code Editor that supports many languages, which is a necessity these days for almost all WordPress users.

• Syntax highlighting for four languages (i.e. CSS, HTML, JavaScript, PHP)
• Over 20 editor themes (GitHub, Eclipse, Chrome, Textmate, etc – more can be imported)
• Automatic indent and outdent
• Handles huge documents (four million lines seems to be the limit!)
• Fully customizable key bindings including Vim and Emacs modes
• Highlight matching parentheses
• Toggle between soft tabs and real tabs
• Displays hidden characters
• Drag and drop text using the mouse
• Line wrapping
• Code folding
• Multiple cursors and selections
• Live syntax checker (currently JavaScript, CoffeeScript, CSS, XQuery)
• Cut, copy, and paste functionality

Supported Languages

The CJT code editor currently supports syntax highlighting and error checking for four languages.

• CSS (Cascading Style Sheet)
• HTML (HyperText Markup Language)
• JS (JavaScript)
• PHP (PHP: Hypertext Preprocessor)

CJT Code Blocks are the basic unit for writing code and assigning it to specific WordPress requests (e.g. for a Page, Post, Category, Blog index, Expression, etc). It is the main gateway for interaction, allowing users to have their codes assigned. In general, blocks should always be created when you need to assign a piece of code with specific requests.

CJT is very flexible, allowing you to create multiple blocks, while:

• assigning each block to different requests
• assigning each block to the same request

You can assign multiple blocks to the same request, and allow multiple requests to share the same block (or blocks). The possibilities are endless.

CJT Blocks require only two steps in order to get them involved with the request. The first is to tell CJT where this block should be assigned (to the request), and the second is to write the code that needs to be assigned. 

Blocks can be arranged in different levels. This includes the Global Block Level and the Page/Post Level (Metabox Block).

Writing code is the step taken within the code editor window of the code block, and is what carries out the functionality that’s intended to be performed by the block.

CJT is providing users with a number of tools for writing code. One of these powerful tools is the Advanced Code Editor (ACE) with syntax highlighting and error checking. The editor can also support a majority of the modern functions that’s currently being used by a lot of code editors like: folding, unfolding, collapsing and expanding code regions.

More helpful tools that can be utilised include: restore block revisions, switch editor languages, switch editor themes, full-width and full-screen mode, adjust font sizing, and the Code Auto Complete (CAC) extension.

Before writing HTML, JavaScript, CSS or PHP code, it is advised to set the editor to your chosen language. This way you will get the benefits from language-dependant features such as syntax highlighting and error checking. CJT is currently not doing that automatically for you. Although that said, in our development pipeline is a feature called a Multiple Code Files Block that should be able to handle those things automatically.

The following languages are currently being supported:

• CSS (Cascading Style Sheet)
• HTML (HyperText Markup Language)
• JS (JavaScript)
• PHP (PHP: Hypertext Preprocessor)

CJT is not going to insert any tags or wrappers for any language. Setting the editor language is currently a conduit for syntax highlighting and error checking. CJT does not alter the code at all, so users have the ability and freedom to do whatever they like while writing code.

CJT provides two types of code block – Global Block and Metabox Block.

• Global Block – this occurs in the main CSS & Javascript Toolbox dashboard page, where you can create multiple blocks and assign them to WordPress requests. Global Blocks can even be ordered so that blocks override other blocks. Additionally, blocks can be Activated/Deactivated and output in different locations. Global Blocks are used for providing shortcode support to block scripts, and also for assigning blocks to multiple WordPress requests.
• Metabox Block – this occurs at the edit Page/Post level as a metabox, and when permitted in the Security settings, will show below the Visual/Text editor. Metabox Blocks will only affect the specific WordPress page or post it is attached to.

Global Blocks is the Block type that works globally and can be assigned to multiple WordPress requests. CJT Global Blocks can be created through the CSS & JavaScript Toolbox main dashboard.

A Global Block has two components that build up the Global Block unit. The Code Editor and the Assignment Panel. The Assignment Panel allows you to assign the code block to multiple WordPress requests via both predefined and custom requests. Please visit the @Assignment Panel documents for more information.

Global Blocks share a few attributes and one of them is the order. Global Blocks can be reordered so that the top (higher up) blocks would be executed first before the bottom (lower down) blocks. This can be useful when you require a higher block to override a lower block.

You will notice that all Global Blocks are created in one single page and they are not categorised. With many blocks in play, this may get confusing to know the order of block execution, and whether some will not get involved on the same request. In the near future, CJT will be organised as separate individual Projects where each Project may contain multiple Global Blocks inside.

All Global Blocks are automatically assigned a shortcode with its name and can be used directly by typing the shortcode into the page or post content. Please visit @Shortcode section for more information about Global Block shortcodes.

Creating a Global Block is a very simple process that can be done by clicking the ‘Create New Block’ button from the CSS & Javascript Toolbox dashboard page. You will have to fill out the Create New Code Block form and click OK.

New Block Fields:

• Name: Block name that will be used for giving a hint about the block function and to be used as the shortcode name/parameters
• Activate: Check it to initially Activate the newly created block, or leave it unchecked to initially make it disabled. Value can be changed later
• Location Hook: Header/Footer is the initial location hook for the block, where the block would be executed and outputted
• Position: The block order position for the Global Blocks list allows block creation in either the first block position (default position) or the last block position. The top (higher up) blocks would be executed first before the bottom (lower down) blocks

After the block has been created the popup form will close and the new block is added on the main Global Blocks manager page. It will be initially loaded/opened and the keyboard cursor will be activated for the code editor, allowing you to write code directly on there.

Deleting CJT Global Blocks can be done by clicking on the Delete (cross icon) from the block main toolbar. You’ll then need to confirm the delete message.

After confirming the deletion, nothing actually deletes just yet as the block is only removed from the UI list. You have to click the ‘Save All Changes’ button from the CJT main toolbar to save the deleted blocks.

Currently CJT is not supporting a way so the deleted blocks can be reverted back when the ‘Save All Changes’ button has not been clicked, however we plan to do that soon. So if you need to undo deleting your blocks, as long as did not click the ‘Save All Changes’ button, you can simply refresh the page to get them back.

Warning: After clicking the ‘Save All Changes’ button, blocks cannot be reverted back as they are permanently deleted from the database. Therefore, all the deleted blocks data will be lost.

Initially all closed Global Blocks are in the unloaded state until they are opened. When it changes into the open state, it will then be loaded from the server. This means when you go into the main CJT block management page, all closed blocks are still not loaded from the server. Only basic details that identify the blocks are loaded, so users can take any primary actions that does not require the block to be loaded such as clicking the Activate/Deactivate or Header/Footer toggle switches. If more actions need to be taken (such as code editing), then the block needs to be loaded by clicking on the block toolbar.

Loading the block would fetch block code, initialise the code editor, and other resources such as the Assignment Panel window and so on. When this happens, the block is in the loaded state and ready for editing.

Block state is saved in your user profile so it would always be in the same state next time you access/refresh the CJT block management page.

It’s highly recommended to close all your code blocks before leaving CJT blocks manager page. This is very important because loading many blocks when the page is loading might cause the browser to crash or cause a server time out error. CJT blocks have no pagination. It has been tested with more than 600 closed blocks and works perfectly fine, however opening say all of them at once would most-certainly prevent them from opening due to the server error.

Global Blocks can be reordered so that the top (higher up) blocks would be executed first before the bottom (lower down) blocks. Ordering Global Blocks can be very useful especially when functionality or output is dependant on the execution order. If for example you need to move a number of bottom (lower down) blocks higher up to override blocks above, you need to do the following:

1. Drag the block you want to move by clicking the block toolbar
2. Drop it in the new position
3. After re-ordering all target blocks, click ‘Save All’ Changes’ button

 
Note: Nothing will be saved until the ‘Save All Changes’ button is clicked. As long as you have not clicked the ‘Save All Changes’ button, you can revert the block orders back by simply refreshing the page.

CJT is basically built over the assignment/association feature that allow users to run their codes in parallel with WordPress requests. A single Global Block might be assigned to multiple requests at the same time. This feature can be done through the Assignment Panel window.

The Assignment Panel can be classified into three parts:

• WordPress (Posts, Pages, Custom Posts and Categories)
• Auxiliary  (All Pages, All Posts, Blog index, etc)
• Advanced (URL’s and Expressions)

By assigning Global Blocks to a WordPress request, you’re simply telling CJT to load these blocks when that specific request is submitted to the server. CJT would then prepare the blocks, run them, and provide the output.

When assigning a block to a page, only that page would get the block applied. It doesn’t include the child pages automatically by default. This is intended so users can get more control by selecting the child pages (sub-pages) manually. Applying a block to all the child pages can be a problem if a few pages in the tree should not be included.

Assigning to single/multiple Pages

As the nature of WordPress pages are hierarchical, the CJT Assignment Panel also reflects that in the Pages tab. It list all WordPress Pages in a hierarchical form so that a user can find the relation between pages while assigning a block.

Include many or all child Pages

CJT provides a shaded secondary checkbox for every parent page that help users to check/uncheck all the child pages with a single click. It is still possible to uncheck some child pages after selecting all with the secondary checkbox. This is part of the helper tools that is intended to give you the maximum combination – that often fits most cases, and all for minimal work.

Assigning to All Pages

In order to assign a block to all pages, you should use the Auxiliary tab in the Assignment panel, and then check the ‘All Pages’ option. Checking this would apply the block to all pages – even those that would be added in the future. It’s like a live event that will always automatically assign new pages to the existing page set.

Assigning single/multiple Posts

As the nature of WordPress Posts are flat (non-hierarchical), the assignment is straight-forward to the post itself and doesn’t include any other posts or categories that the post is related to.

The Post tab in the Assignment Panel provides you with the entire list of all existing posts in a flat, non-hierarchical form.

Assigning to All Posts

In order to assign a block to all posts, you should use the Auxiliary tab in the Assignment panel, and then check the ‘All Posts’ option. Checking this would apply the block to all posts – even those that would be added in the future. It’s like a live event that will always automatically assign new posts to the existing post set.

Why Assign to a Category?

By assigning a Global Block to a category, you are applying the block to the category Archive (index) page and all the posts laying under that category! Yes, this is it. The idea behind applying blocks is to include all the child posts.

When assigning a block to a category, only that category and child posts would get the block applied. It doesn’t include the child categories automatically by default. This is intended so users can get more control by selecting the child categories (sub-categories) manually. Applying a block to all the child categories can be a problem if a few categories in the tree should not be included.

Assigning to single/multiple Categories

As the nature of WordPress Categories are hierarchical, the CJT Assignment Panel also reflects that in the Categories tab. It list all WordPress Categories in a hierarchical form so that a user can find the relation between categories while assigning a block.

Include many or all child Categories

CJT provides a shaded secondary checkbox for every parent category that help users to check/uncheck all the child categories with a single click. It is still possible to uncheck some child categories after selecting all with the secondary checkbox. This is part of the helper tools that is intended to give you the maximum combination – that often fits most cases, and all for minimal work.

Assigning to All Categories

In order to assign a block to all categories, you should use the Auxiliary tab in the Assignment panel, and then check the ‘All Categories’ option. Checking this would apply the block to all categories – even those that would be added in the future. It’s like a live event that will always automatically assign new categories to the existing category set.

As most WordPress sites almost always have some form of custom posts (Products, Downloads, etc) created by using other plugins and themes, CJT supports assigning Global Blocks to custom posts.

Custom posts might be hierarchical like WordPress Pages or flat like WordPress Posts. CJT is able to detect the custom post type and list it hierarchically or flat as defined.

Based on the custom post layout, CJT will display it hierarchically like pages with secondary shaded checkboxes, or flat like posts. However all custom posts are listed under a single Assignment Panel tab with a toggle-able list inside. If there are no custom posts defined, then a notice message will show in place of the list.

Note: Only custom posts that have dashboard admin page and front-end access would be listed under the Custom Posts tab. Other custom post types such as Logs, History, etc, which is only intended to be used internally by the plugin or theme should not be listed.

Auxiliary assignments are predefined assignments that group some common WordPress request types.

When assignments are required for cases where: the request currently exists AND the request does not yet exist, then it would be a good idea to use Auxiliary assignments. Auxiliary assignments give you the option of assigning a block to WordPress request items (e.g. posts, pages, categories, etc) whereby the item does not yet exist, so that whenever a new item gets added, it’s automatically added to the list.

It can also simplify assigning a block to a large group of WordPress items that cannot be assigned directly, as it would take sometime, or as it has not even been presented as WordPress items. Most of the Auxiliary assignments do logically exist but not physically on the database or disk.

Auxiliary assignment types

• Entire Website: Apply to WordPress entire frontend website
• Website Backend: Apply to WordPress dashboard/backend
• All Pages: Apply to all WordPress pages that do not yet exist
• All Posts: Apply to all WordPress posts that do not yet exist
• Blog index: When Settings->Reading->’Front page displays’ with the option being set to show ‘Your latest posts’ for the homepage, then this Auxiliary assignment will apply to the blog index page
• All Categories: Apply to all WordPress categories and all posts laying under those categories even though they do not yet exist
• Search Pages
• 404 Error: Apply to error page when WordPress cannot reach the requested item
• Tag Archive
• Author Archive
• Attachments Archive
• All Archive: Includes all of the above archives (including categories). However, it has the lowest priority, so if any archive assignment from the above items are being assigned, then that would take a priority over the All Archive assignment

When to use?

As in some cases, users might need to cover more areas/requests where the assignment items are just not enough. URLs can be passed through the CJT Assignment Panel.

CJT URL parser accepts a list of URLs separated by a newline. so each line would have the full URL you wish to use. You must write the full URL including the WordPress home page/domain. CJT is not adding any trailer or prefixes to the URL you write.

CJT URL checker is splitting all URLs that are being passed, checking if it’s exactly equal the current request URI based on the PHP $_SERVER[‘REQUEST_URI’) and $_SERVER[‘HTTP_HOST’]. The URL can contain a custom Port number, with either HTTP or HTTPS is being supported.

Example of using URLs include:

Home Page: http://mywordpresssite.com/

WordPress Page: http://mywordpresssite.com/mypage/

Secure HTTP: https://mysecurewordpressite

Custom Port Number: http://mysecurewordpressite:PORT-NUMBER

When to use?

In some cases, users might need to cover more areas/requests where the assignment items fall short. This is when Expressions can be used and passed to the CJT Assignment Panel.

What kind of Expression is it?

CJT currently supports only Regular Expression as PHP, except that you don’t need to write the Expression delimiters. The expression will be automatically wrapped by the forward-slashes /EXPRESSION/ delimiters.

Difference Between Expressions and URLs

Although URLs are a custom assignment, each URL can only cover a single WordPress request. Since each URL is internal and can only point to a single request, Expressions on the other hand can evaluate what URLs it has to apply the block with.

How it’s being evaluated

The CJT expressions parser accepts a list of expressions separated by a new line. In other words, each line would contain a full single expression.

Each expression (line) would be automatically wrapped by double forward slashes (as specified by PHP) and then evaluated to the current request URL. Once a single expression is valid and matching, the block is then added to the In-Load Blocks Queue (IBsQ). The blocks queue will process and then go onto the next block that has expressions and repeat.

Regular Expression References

PHP Offical Regular Expression

Examples using Expressions

Matching all the site pages including frontend and backend:

.+

Matching all Pages that start with ‘mypage’ including the ‘mypage’ page:

\/mypage.*

Matching any page that contains the word ‘test’:

test.*

Matching any page that ends up with the word ‘test’:

test\/$

A Metabox Block is a CJT block that is assigned to one single WordPress page or post. This type of block cannot be assigned to multiple items (i.e. pages/posts) at the same time. The main visual difference between a Metabox Block to a standard Global Block is a Metabox Block does not have the Assignment Panel.

These blocks are created at the page/post level (i.e. when editing a page or post). They can be useful when working with the post content and having the code in the same place is required. It can also provide better code management, if say your code organisation requires each block to be assigned to a specific post, and you want to leave the Global Blocks for global cases. Metabox Blocks provides another option to help you manage your development in a structured way.

Security

CJT gives web-masters the control to specify which post types are allowed to have Metabox Block creation. No post type would allow the creation of a Metabox Block unless it’s specified in the CSS & Javascript Toolbox->Settings->Metabox option.

Performance

Posts/pages do not have Metabox Blocks created by default. Users have to create a Metabox Block for each post that requires it. This is intentional as it allows for better performance for posts/pages that do not need them.

By default CJT is not associating or creating a Metabox Block for WordPress pages/posts until it is created by the user. This is ideal for performance as it saves database processing, server memory and page loading time. Instead of creating a full Metabox Block for every WordPress page/post, CJT is placing a ‘creation block’ from which users can create a Metabox Block for the desired posts. Once created, it would reserve a database record and it would always be there.

Creating a Metabox Block is done behind the scenes using AJAX technology so that users wouldn’t need to refresh the whole page after creating or even editing the block.

By default when a Metabox Block is created it is automatically assigned a default name generated by CJT. The name would be as following:

CJT Block – Post #ID

Where ID is the post ID that the block is being create for. This name can be changed later.

Deleting a Metabox Block is to remove the internal link/association between the block and the page or post that it is associated with. It would also delete all of your database records that are related to the block.

As long as a Metabox Block is not required any more, it is recommended to delete them to enhance your page loading time.

In a case where there is a Global Block assigned/associated to a page/post that already contains a Metabox Block, then the Metabox Block will get higher priority over the Global Block.

So that the Global Blocks those assigned to the Post is getting in the queue before the Metabox Block that’s give the Metabox Block priority as it running after them all therefor might override or revert what Global Block has done.

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.

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.

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.

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”]

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.

Template is a peace of reusable code that can be embedded or linked to code Blocks, Global or Metabox Blocks.

Unlike code Blocks that is just created to do specific function by assigned to specific requests. Templates is to be used by Code Blocks as Code Libraries that might be required to be used by Multiple Code Blocks. It is independent peace of code and not related to anything. It can either embedded or Linked to code Blocks.

It keeps Blocks code cleaned and organised as it give the chance to separate the Code into Model and Library codes that is represented in CJT as Block and Template.

Its originally developer for big library files that is not logically related to the Block Model, might be reused by other Blocks and provided by third-party developers. jQuery is an example of using Templates as its not a part of the code Block and also it shouldn’t be in the code Block as its huge file that would prevent you from editing your code in a simple professional way. Also having those huge library files away from code Block is great for performance as those template files is rarely modified.

Linking Template can be used when centralizing a peace of code is required. As Multiple Code Blocks can be linked to the same Template file its force a centralisation as those all code Blocks is being use one Template file.

Updating Centralised Template file is always reflected to the Blocks so there is no need to re-link code Blocks after updating the Template file.

Creating a template is a very easy process that required few fields to be filled.

• Name: Require template name that would be used when link/embedded templates through Templates Lookup. Please keep the name clean, brief and descrbing the Job of the template. Once the template is created this field cannot be changed.
• Language: Require template language to be used by identifying the template type and how it would be linked by CJT. Its also set the Editor Syntax Highlight and Error checker based on the selected language. Once the template is created this field cannot be changed.

Currently the following languages are being supported:

• HTML
• Javascript
• CSS
• PHP

Deleting Template is to remove the Template record from the database and also unlink it from all the Block that being linked this Template. This is it! Embedded Template is getting a copy from the template code and pasting it to code Block and deleting Template has no effect on embedded templates. Only linked Blocks would lose the deleted template, those Blocks should be updated as the dependencies has been changed.

Embedding Templates is simply to Copy the template into the Code Block Editor where in the location of the Editor Cursor. Currently CJT is not adding any Tags to the embedded templates, its simply geta Template copy.

If the embedded Templates is then updated later it doesn’t reflect that update to the Code Block as its already copied. If reflecting update is required Linking Template then would be used instead of embedding.

Template can be embedded to the same Code Block Multiple time, CJT is not confirming that. Its up to Block Author to handle em,bedding Templates unlike Linking Templates is linked to the Block only once and managed by the CJT internal Queue.

Its the most useful feature provided by Templates system. Linking Template is to Import Template into one or more Code Block. The method of how the Template would be linked by CJT is based on the Template Type/Language. Each Type is linked differently. We’re going to show how each type would be linked.

HTML & PHP

CJT Template Linker is appending all the Templatee Code that being linked to the Block and then execute them all (including Block code) as PHP code.

Example:

Block

<div id="block-layer">
<span><?php echo 'Hello World'; ?></span>
</div>

Linked HTML Template

<div class="block-footer"></div>

Linked PHP Template

<span><?php echo "Footer Text"; ?></span>

All the above Codes would be aggregated as following and then executed as PHP.

<div id="block-layer">
<span><?php echo 'Hello World'; ?></span>
</div>
<div class="block-footer"></div>
<span><?php echo "Footer Text"; ?></span>

The Final Result would be:

<div id="block-layer">
<span>Hello World</span>
</div>
<div></div>
<span>Footer Text</span>

Javascript and Stylesheets

CJT is linked Javascript and Stylesheet Templates by using <script> and <link> HTML tags respectively.

Template Types is to tell CJT what Language specifications (Syntax Highlights, Error Checker, etc…) and also tell Template Linker of how to link this Template. Finally its used by the Template Author for identifying different type of scripts (Javascript, CSS, etc…). Different types would be handled differently while its being linked.

Currently, CJT is support the following Types/Languages for Templates:

• HTML
• Javascript
• CSS
• PHP

When writing Javascript and CSS Templates it would be considered like writing separated .js or .css files, no <script> or <style> or <link> tags should be added in those templates. Those Tags are being added automatically by CJT Templates linker. Adding those tag would break those Templates.

Embedding Template is current will embedded Javascript and CSS templates without any tags appended. Its still a good practice to follow the Above strategy of avoiding adding any Tags as next CJT release would start adding those templates while embedding too.

CJT Template Lookup allows WordPress built-in Scripts and Styles to be linked or embedded to Code Blocks. Its one of the powerful features that CJT Template Lookup is providing for Blocks. Almost there is no Third-Party script is not depending on some famous scripts like jQuery. CJT user don’t have to add those manually or copy their codes into the Code Blocks. They’re all available through Template Lookup.

Content is in progress …

Thanks for your patient!