October 24, 2014

Maintenance periods and software updates

In late July 2013 we introduced maintenance periods for Bugify1)For those who purchased before July 2013 you may have noticed that the “Maintenance Expires” date in Settings – Licensing says N/A – this means maintenance periods do not apply to you and you will continue to receive updates. and we haven’t enforced these expiry dates until now.

This is a message just letting you know we will begin to notify customers when their maintenance and support expiry dates are coming up (this will be in the form of a notification within Bugify). We will also begin to enforce the requirement of having a current maintenance agreement in place in order to upgrade Bugify.2)Maintenance periods allow incremental updates like v1.1 to v1.2 but does not cover major upgrades like v1.2 to v2.0

If your maintenance period has already expired, we will continue to allow you to update Bugify for a few extra weeks.

Maintenance renewals are priced at USD $42 (they are actually calculated at 60% of your original purchase price within a min/max range and a default of $42 – so expect to pay $42).

We are very grateful for all purchases of Bugify and try to keep the cost as low as possible. Renewing your maintenance period helps to ensure the ongoing development of Bugify and frequent updates.

Notes   [ + ]

1. For those who purchased before July 2013 you may have noticed that the “Maintenance Expires” date in Settings – Licensing says N/A – this means maintenance periods do not apply to you and you will continue to receive updates.
2. Maintenance periods allow incremental updates like v1.1 to v1.2 but does not cover major upgrades like v1.2 to v2.0
September 2, 2014


From 30th September, 2014 we will be increasing the price of Bugify from $59 to $70.

We still think you get such a good deal with Bugify, but suggest purchasing before the end of September if you’ve been considering it. As always, you can download a free trial of Bugify here.

August 19, 2014

Bugify translations – Transifex

We have decided to give Transifex a go for managing Bugify translations. Until now, translations have been managed by email and some languages don’t get updated often enough. Using Transifex should make it much easier for both translators and developers to keep the language files as up-to-date as possible.

I will be sending a message to customers who have provided translations in the past. If you are able to offer translation help for a language Bugify already supports or a new language, please get in touch.

November 27, 2013

Black Friday

If you’ve been holding out on purchasing Bugify, now’s the best time to do it! Use the discount code BLACKFRIDAY2013 to get 30% off the standard price.

June 14, 2013

Colour palette for labels

We need a colour palette for the new labels feature (coming soon!) The idea is that each label has a colour, Bugify provides a set of default colours (that you can change if you desire), so you can choose from the provided palette, make your own palette, or use a custom colour. We’re toying with the palette below, but aren’t entirely happy with it. If you know of any beautiful palettes (around 16 to 20 colours) let us know.

Screen Shot 2013-06-14 at 10.01.33 AM

June 13, 2013

Bugify price reduced until end of June

We’ve reduced the price of Bugify down to USD$39 until the end of June 2013. Aside from that, there are some exciting updates to Bugify coming out soon!

Get Bugify here.

March 13, 2013

Sneak preview of some new features in the upcoming release

Below are screenshots of some of the new features included in the upcoming release of Bugify…

Drag and drop attachments!

Drag and drop attachments!

Attachments with comments.

Attachments with comments.

Add attachments while creating a new issue.

Add attachments while creating a new issue.



February 11, 2013

Updating Bugify on cPanel and other hosts that require htdocs or public_html etc

Some web hosting control panels require that your publicly accessible folder for your website be named “public_html” or “htdocs” (or whatever).  In the past, this has been a bit annoying with Bugify because we have a folder called “public”, that we expect your web server config to point to (the “public” folder is the only folder that should be publicly accessible – the others should be outside the document root).

Generally, if you don’t have SSH access to create a symlink from “public_html” (or whatever) to “public”, then you would rename the Bugify “public” folder to the folder name that your hosting control panel requires.  This is fine, and Bugify still works fine like this… up to a point.

Where Bugify failed with this type of setup, is the auto-update system.  In the past, when you use the auto-update system, Bugify would actually create a new folder called “public” and copy the new public files into it, rather than using your “public_html” (or whatever) folder.

From v1.5, the update system will be a little smarter, and will handle that automatically for you.  So if you’re running Bugify from a folder other than “public”, the auto-update system will work out the correct folder, and copy the new public files there.

It is very important to note that the change will only take effect for updates after the first release in 1.5.  So, when you update to v1.5, if you’re using a folder other than “public”, you will need to copy the new files over.  You won’t have to worry about whether or not this is you, because we’re going to check for you, and let you know 🙂

January 24, 2013

Queue jobs change

Bugify runs potentially slow tasks as a job (asynchronously).  We do this to prevent holding up the interface, so we can keep Bugify feeling snappy (a slow SMTP server would make the interface grind to a halt if we were sending lots of email notifications inline).

Up until now, we were using PHP-CLI to run these tasks.  This works fantastically for most people, but every now and then it causes a major headache for a new customer.  Some web hosts have the PHP-CLI binary installed in an odd place, and Bugify has trouble figuring out where it is.  PHP (when running as an Apache module, or PHP-CGI) knows nothing about the PHP-CLI binary, so we can’t ask PHP where it lives, and we need to know the full path to the PHP-CLI binary in order to use it (otherwise PHP-CGI might run the script and cause all sorts of havoc).  So, after a lot of pain trying to make working with PHP-CLI work for everyone, we have decided to change tactics.

From the next version of Bugify, queue jobs will be run using an Ajax request.  3 seconds after loading any page in Bugify (after logging in), the queue will be run.  10 seconds later (and every 10 seconds after that) the queue will be run again.  Only a small number of jobs will be run per Ajax request, so if the jobs aren’t cleared in the first run, they will be processed in the next.  This has been working very well for us, and you shouldn’t notice any difference.

Some of you may have realised that this isn’t going to work for API requests – there is no Ajax involved.  The way we’re dealing with this is to give you the option of manually triggering the queue (by a new API method), or having the queue tasks run inline (as part of the API request).  By default, the queue will be run inline, but you can change it in settings.

The slowest queue task is usually sending notification emails.  For small teams where a change may only generate a few email notifications, the API requests should still be very snappy (even when running queue tasks inline).  If a change generally sends notification emails to more than 10 people, you might want to look at using the new API method to trigger the queue, rather than allowing the queue to run inline.  When the update is released, we’ll also update the API Explorer so you can see how the new method works.

January 21, 2013

Bugify in other languages

We have customers in 67 different countries now!  And, not everyone speaks English as their first language, so it’d be remiss if we neglected to provide Bugify in other languages.  So, we’re working hard on making Bugify translatable, and almost have the English language file finished.

We’ve had a few offers from customers to help provide a translation in their language which we really appreciate, and we’d love it if some other customers were willing to help provide a translation in their language.  If you think you might have time to translate Bugify from English into your language, please get in touch.  Ideally, someone would go through the English language strings and provide a quick translation, then someone else whose native tongue is the same will go through and make sure it all makes sense – the more eyes on it the better.