Customizing osTicket (and Why You Should)
osTicket is striving to develop the world’s most popular open source ticketing system more openly. Starting with osTicket 1.7, the mainline development has been available on GitHub. If you are maintaining or creating a customized version of osTicket, using git and following the mainline development’s GitHub repo can make you far more successful.
Follow the Source
GitHub allows you to fork the mainline repository and make custom changes to the software, while tracking the mainline development and allowing you to merge upstream changes into your custom code.
osTicket development can be managed from a git repo — even on a local level on your own server. If you’re customizing osTicket, you should be using git, and you should be following the upstream development. However, you should not be serving the git repo from your web server. The repo should be located somewhere outside the path served from your web server.
CUSTOMIZE THE SOFTWARE
You’re probably still reading this article because you want or need to customize osTicket. Customizations are welcome and expected. We are working hard to implement a full extension and plugin system to make modifications easier to port between osTicket versions. In the mean time, you can modify the source directly while still following the upstream activity for big fixes and new features.
FORK THE GITHUB REPO
Create a GitHub account and fork the osTicket repo. Then, clone the repo onto your web server or add a remote to point to your fork. If you’re super lazy, it is possible to follow the upstream development directly, while still tracking changes locally. For instance, if you manage source code in a folder in the home folder on your box called sandbox, you could do something like this
git clone https://github.com/osTicket/osTicket-1.7 ~/sandbox/osTicket-1.7
Then, make all the changes you need. Once completed, you can deploy them to the folder where osTicket is installed on your box using the included deployment script.
DEPLOYING THE SOURCE
First, checkout the git repo onto your web server. Then, use the deploy cli module to deploy osTicket for an installation.
php setup/cli/manage.php deploy --setup /path/to/installation
As an added bonus, the deployment script also supports managing a separate location for the include/
folder. See deploy --help
for more information. The location of the include path is only necessary on the initial deployment. Thereafter, it is automatically detected.
Follow the general installation directions and delete the setup folder as usual. Then, you can deploy osTicket updates from GitHub similar to the following. Use the command-line and change directories to your git repo path, and then into the setup/cli folder
git pull php setup/cli/manage.php deploy -v /path/to/installation
Development Guidelines
We encourage you to change osTicket to suit your individual needs. However, be careful not to make changes that will make it difficult or impossible to follow others’ changes including upstream changes made to the mailine osTicket repository
DATABASE TABLES
If your customization makes changes to the main osTicket tables, you will likely get merge conflicts when the core stream is updated. If you need to add columns to an upstream table, add another table with the extra columns and link the data to the upstream table using the primary key of the upstream table. This will keep your data model separate from the upstream data model.
DATABASE STREAMS
If you need the installer or the upgrader to manage database changes outside of osTicket core, you can create a different database migration stream to create and migrate changes to your stream. See the docs for streams in the repo under setup/docs/streams.md
TRACKING CHANGES
After getting your changes initially staged, checked in, and deployed, you can merge changes between your code and another contributor’s or the mainline repo. First, add the repo to your git remotes if it not already in the list of remotes
This process might be done frequently to pull upstream changes. You might add the mainline repo under the name of upstream
git remote add upstream https://github.com/osTicket/osTicket-1.7 git fetch upstream
And then merge in the upstream changes into your own
git checkout develop git merge upstream/develop
If you get merge conflicts, follow the usual git approach. Edit the conflicted files and add them to be staged for a commit. After resolving all the merge conflicts, commit the merge.
git remote add friend git@github.com:friend/osTicket-1.7 git fetch friend
Then you can merge their changes with your own
git checkout develop git merge friend/develop
Thoughts
A git how-to is really beyond the scope of this blog post. There are numerous articles concerning how git works and how it is used in this manner. However, once you learn to manage software codebase changes using git, you’ll find it extremely effective to manage your custom changes to osTicket while still maintaining compatibility with upstream osTicket. This affords you the ability to continuously reintegrate your custom changes into the ever-changing osTicket upstream codebase.
Cheers,