Severity: 8192
Message: Methods with the same name as their class will not be constructors in a future version of PHP; MarkdownExtraExtended_Parser has a deprecated constructor
Filename: helpers/markdown_extended_helper.php
Line Number: 10
Severity: 8192
Message: Methods with the same name as their class will not be constructors in a future version of PHP; Markdown_Parser has a deprecated constructor
Filename: helpers/markdown_helper.php
Line Number: 223
Severity: 8192
Message: Methods with the same name as their class will not be constructors in a future version of PHP; MarkdownExtra_Parser has a deprecated constructor
Filename: helpers/markdown_helper.php
Line Number: 1696
A Context is an area of similar responsibility within the code and/or UI. They appear as top-level navigation objects within the main menu, and should all cover a similar topic, or theme. The following are all good candidates for Contexts:
Context | Description |
---|---|
Security | Holds menu items from different modules that provide security tools and reports. |
Forums | You can group all of your forums admin panels in a single context. |
Design | You might provide methods for editing your templates or various error pages |
Tools | Might contain collections of utilities that don't belong elsewhere. |
Role-Specific | A single role might have access to a set of tools that no one else does. These could be grouped so they are easier to provide access to. |
Contexts map directly to controllers of the same name in your module. If you are creating a controller to handle your Settings Context for your module, the controller should be named content.php
and the class should be named Content
.
class Content extends Admin_Controller {
...
}
All views for your contexts should be stored within the views folder of your module, under a sub-folder named after the context. Continuing our example, the view for the index method would exist at my_module/views/content/index.php
.
A Public Context is just a fancy name for what you would typically do in a CodeIgniter application. This controller is named the same as your module and can have as many methods that map directly to the URI as you need.
Views are stored directly in your views folder. For front-facing page, or Public Contexts, there's little-to-no magic going on behind the scenes other than what you're already used to working with. The file would then be available at:
http://yoursite.com/module_name
Bonfire requires only two contexts to exist, and will create them if they don’t. They are the Developer and Settings Contexts.
Context | Description |
---|---|
Developer | This context is meant for tools designed to make the application developer’s life easier and may include database tools, code generation, deploy helpers, etc. |
Settings | Any settings related to your module. These are typically items that are infrequently changed, like the number of events to show on each page, etc. |
You can create any number of contexts to fit your application’s specific needs. Doing so is a very simple task that only requires a single step.
To create a new context that will be displayed in the admin area, you only need to add the name of the context to the
To make your context's name localized, you simply need to add a new entry in the
$lang['bf_context_new'] = 'New Context';
The localized version will automatically be used if present, otherwise the name displayed will be the name of the context.
You can restrict access to your contexts by creating a new permission. This permission should be named 'Site.{context}.View', where
In order to manage the permission, you will need to create another permission called 'Permissions.{context}.Manage'.
To customize the context menus for your module, simply add any of the following entries to your module's config.php
file's 'module_config'
array:
'menu_topic'
. The same 'menu_topic'
may be used by multiple modules within the application to group related functionality within a single sub-menu.Values specified under 'menu_topic'
or 'name'
may optionally use the lang:
prefix to indicate an entry in the 'application_lang'
file to be used for translating that particular item in the menu; any 'menu_topic'
specified with a lang:
prefix should be specified with that prefix consistently throughout the application's modules.
In most cases, only 'name'
and 'description'
are specified (along with 'author'
and 'version'
, which are not used within the context menu).
An example config.php
file may look like the following:
<?php defined('BASEPATH') || exit('No direct script access allowed');
$config['module_config'] = array(
'name' => 'lang:bf_menu_blog_name',
'description' => 'A Simple Blog Example',
'author' => 'Your Name',
'homepage' => 'http://...',
'version' => '1.0.1',
'menus' => array(
'context' => 'path/to/view',
),
'menu_topic' => array(
'context' => 'lang:bf_menu_blog_context_name',
),
'weights' => array(
'context' => 0,
),
);
Note that 'context'
under 'menus'
, 'menu_topic'
, and 'weights'
is a placeholder for the name of the context (e.g. content
, settings
, etc.).
Bonfire makes use of the 'menus'
setting in the database
and emailer
modules to create sub-menus in the developer
and settings
contexts.
The 'menu_topic'
setting is used to group menu entries for Bonfire's migrations
module with those from the database
module.
The 'weights'
setting is used to weight the 'Users'
entry in the settings
context, which, by default, causes the Users
entry to be listed first in the menu.