Deprecated: Joomla\Input\Input implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /homepages/13/d380392445/htdocs/Jlive/libraries/vendor/joomla/input/src/Input.php on line 41

Deprecated: Return type of Joomla\Input\Input::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /homepages/13/d380392445/htdocs/Jlive/libraries/vendor/joomla/input/src/Input.php on line 170

Deprecated: Joomla\CMS\Input\Input implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /homepages/13/d380392445/htdocs/Jlive/libraries/src/Input/Input.php on line 31

Deprecated: Joomla\CMS\Input\Cookie implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /homepages/13/d380392445/htdocs/Jlive/libraries/src/Input/Cookie.php on line 21

Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /homepages/13/d380392445/htdocs/Jlive/libraries/src/Uri/Uri.php on line 141
Issue Tracker Template Overrides - Macrotone Blogs

Macrotone Blogs

Macrotone blogs upon Joomla, our products and other matters.
Categories
Tags
Archives
Calendar
Categories:   All Categories
Suggested keywords
x
Font size: + –
  Print

Issue Tracker Template Overrides

3362 Hits

b2ap3 icon joomlaWe have recently been ‘playing’ with a new ‘Bootstrap v3’ template for the front end of our site.  This involved use creating a set of template overrides for our Issue Tracker component and we decided to share the details with our users.

Joomla has long had the ability to create Template Overrides, which are modifications to the Joomla components or modules. This permits changes to be made upon a ‘local site’ basis without the need to change or hack the supplied code.

We are primarily concerned with the Issue Tracker component and we have tried hard to produce front end displays of Individual Issues and of the Issue Entry form that would be usable in the majority of installations. However the differences between the various template used on sites are many and vast, and it is almost inevitable that they will not be suitable for everyone. This was indeed the situation we discovered ourselves when using a BootStrap template for the site.

 

The mechanism for creating a template override is relatively simple but does require a little PHP knowledge.  The first thing is to identify the files that we wish to change. In our case we were aware that it was the template fields for the front end ‘itissues’ and ‘form’ views.  These files are located in the directories:

components/com_issuetracker/views/itissues/tmpl

components/com_issuetracker/views/form/tmpl

We need to copy all of the files located in these two directories into our template html folder and use the same structure that it has in our component.  In this case, it will be: html/com_issuetracker/form/*.php  and html/com_issuetracker/itissues/*.php.  (Note that we don't need the view or the tmpl folder here).

Having copied our files, and there are several in each folder we are ready to start changing them.

As mentioned above, making changes here requires basic PHP knowledge, but you will notice that simple changes are also achievable by applying simple logic and identifying the tags used in the HTML generated from Joomla.

The changes one wants to make will obviously depend upon what one is trying to achieve, but here are a few changes that we have made.

a) The use of

<div class=”clr”>

in the files doesn’t work in BootStrap v3, so we change it to read

<div class=”clearfix”>

instead. This change ensure that breaks occur at the correct places in the output display, particularly after ‘editor textarea’ fields.

b) Changes to the div class that surrounds the elements in the form to make use of the BootStrap class equivalents’. We also added layouts for the column widths at the same time.

i.e. Instead of:

<div class="form-group">
   <div class="col-sm-2 control-label">
      <?php echo $this->form->getLabel('alias'); ?>
   </div>
   <div class="col-sm-10">
      <?php echo $this->form->getInput('alias'); ?>
   </div>
<div>

We changed it to be:

<div class="form-group">
   <div class="col-sm-2 control-label">
      <?php echo $this->form->getLabel('alias'); ?>
   </div>
   <div class="col-sm-10">
      <?php echo $this->form->getInput('alias'); ?>
   </div>
<div>

These changes go some way to creating a more pleasing output.  One can go much further and the limit is really ones own limitation.  Once the changes are made all that has to be done is to clear any Joomla cache and browser cache that may be in use and to redisplay the output page.  If the result is not ideal then one can choose to re-edit the file(s) again confident in the knowledge that we are not changing the ‘base’ code in any way.

The advantage to this approach is that when (or if) the component is updated any changes one has made are preserved.  Of course if the ‘updated’ component has changed the ‘base’ files in any way, such as to introduce a new field, it will be necessary to update our overridden template files, but this in not usually a very frequent change between versions. Unfortunately there is no real solution to this, other that keeping a record of all the changes one has made and checking which files are required in each update. It's also highly recommended that one backs up the website each time one updates the components and Joomla version. 

Aside:

There is one situation which is often forgotten and that is, sometimes if an AJAX mechanism is being used to create ‘parts’ of a web page, the template overrides will not apply to the part for the page using Ajax. the reason is that the ‘page html’ is generated ‘on the fly’ by the server and then presented to the browser. In this case it is the ‘code generator’ that will require changing. The Issue Tracker component used Ajax to present the ‘Custom Fields’ feature in the front end forms. The reason is that when an Issue is being entered the project against which the issue is being raised is not known until the information is entered by the customer. Only once they have entered the project details is it possible to know which ‘custom fields’ need to be presented, to collect any additional information.

We discovered a few peculiarities in the ‘standard’ output from BootStrap v3 which has temporarily caused our testing to pause. The specific problems involve the display of an ‘additional label’ on textarea fields ( despite the label having a marked style of display:none; ), and a mis-formatting on form ‘tooltips’. This is being investigated but was not seen when using a BootStrap v2 based template.  Our rationale for using BootStrap v3 being that if we are moving to a BootStrap template then one might just as well move to the latest version instead of an ‘old’ version.

[The reason for the differences (and we mean here the 'peculiarities not the layout etc), that we are seeing between the BootStrap v3 and BootStrap v2 displays is that the BootStrap v2 is a version modified by Joomla, where as we are/were using an as release BootStrap v3 version. Need to ensure that the changes made by Joomla are also in the version of v3 that we use.]

Tags:
PHP Template joomla Issue Tracker components
Test email in foreign languages
Mail ISO-8859-2 character sets

About the author

Geoffrey Chapman

Geoffrey Chapman

Subscribe to updates from author Unsubscribe to updates from author Geoffrey Chapman

An IT professional with a wide experience of IT systems, specialising in Database Management and Security.

Author's recent posts
More posts from author
 
Go To Top

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries