WTG Plugin Template Checklist   

Sep 15th, 2011 // In: WTG Plugin Template // By: Comments 0

WebTechGlobal has developed and maintains a plugin template, used to create more plugins. It is intended to eventually become public but is currently only offered to a closed group. The release of the plugin is being strictly controlled as it is to become a premium product. Early users are alpha testing.

Follow this checklist when using the WTG Plugin Template to create a new plugin. Preparing your new plugin requires variables to be set and even new page files to be created. Individual tabs within pages have their own file and must be configured in an array that controls them. It is recommended that you follow the checklist at all times especially as the plugin changes and more is added. This checklist will bring your attention to important requirements that could avoid problems for your users.

1. Branding and Communication

The WebTechGlobal Plugin Template so far has a very integrated help system and it is planned to get even better. It is important that all help content reflects the plugin you are created and that any outbound links added do point towards the plugins own website and not the WebTechGlobal site. These instructions point out the places to look to ensure that your plugin is branded in your own name, that any form of communication is between you, your users and your own site.

Coming Soon

2. Coding Requirements

No matter how flexible I make the Plugin Template plugin and no matter how many variables I create in a list to save developers searching through hundreds of lines of script. We will always need to make mass code changes to prevent conflicts. The main changes are function names and global variables. The plugins prep-pend value is “wtgpt” or you if you want you could say “wtgpt_” with an underscore but I recommend leaving the underscore. These instructions will point out how to ensure they are all replaced and where in the plugin you may easily fail to make the required code changes.

Coming Soon

3. Installation

The installation can be very simple or a little complicated. You can use functions for displaying messages to your user regarding potential conflicts with other plugins or even the lack of requirements for the plugin to operate i.e. php version. You can make it easier on yourself by not using any of of that. If you need to install option records or database tables you will need to know a few functions and understand how the installation system works. It is a little different from any other plugin I’ve used. It does not install on activation but instead requires the user to initiate installation after activation of the plugin. This is to break down the process of getting the plugin ready, provide installations options and information about what changes will, did or may take place during the installation process. This to me is important for premium plugins and users are often impressed with what appears to be a very controlled install. Let me be clear that the installation, is very controlled and recorded. Troubleshooting is far easier and so with all these benifits it is not currently possibly to bypass this system, unless you want to code in your “add_option” function calls etc to the main wtgpt_install function.

More coming later.

4. Menus, Pages and Tabs

I made a hard decision to stick with the same page layout and general navigation approach for all my plugins. This means the template plugin I’m creating to help me and then offer to others will not have a lot of options in regards to changing the overall approach. That can be changed but probably won’t be until I receive funding. Pages and tabs do have their own files but the tab menus are generated from an array of values. You need to understand what each value does and how to maintain the array inline with the files you create i.e. we copy and paste a page folder with the main page file, plus (currently) at least 3 tab files then rename them and finally we must update the menu array so that it reflects the new page plus tabs.

More coming later

5. Support Links/Buttons

Description: The support links look like buttons and can be found directly under tabs on every page. The URL is not exactly the same for every page and tab. Details about the page and tab being viewed are added to the URL for being received by the destination page. This is usually the plugins main support site. I’m creating a plugin to process the $_GET variables in the URL and register requests by plugin users. The information in the URL will automatically fill out form fields and the user can also provide further information about their request or bug report.

Specifications: The important variables are $wtgpt_support_blog_category and $wtgpt_support_blog_page, found in the wtgpt_variables.php file. The function that creates the support links and outputs them is eci_support_links, found in the wtgpt_interface.php file. You can configure the output within your plugin there. The first parameter $wtgpt_page is populated using $pageid where it is called within any tab file. The variable $pageid is created in the main page file, the one that calls the tab files. It is populated using values in the wtgpt_menus_variables.php file.

Requirements: Configure the two variables $wtgpt_support_blog_category and $wtgpt_support_blog_page to match your plugins support site. It expects a category and main page. Use the WTG Customer Service plugin to process clicks on these links and form submissions. Also use the customer service plugin to setup the forms that your users will arrive at.

Leave a Reply

You must be logged in to post a comment.