DOWNLOAD VM3 NOW
VirtueMart 3 component (core and AIO)

Bigger, more complex feature changes are done in the major versions such as VirtueMart 3.6. These feature changes are more similar to changing the room layout of a house, or adding an extra floor, or replacing the roof, and so on. These are changes which require much more testing and these are more likely to break other constructions attached to your house. For example, the beautiful balcony (your one-page checkout).

Sometimes we notice that our house is not really comfortable. Displaying the order details below the order list was a good idea, but if the order list was too long then buyers did not see the order details. The order details open now above the list. This way, the logic makes much more sense. If you scroll down in the order details, you can directly select the next order. These and similar changes can be found below in the list of changed behaviors.

One of them even starts with "fixed an issue editing the order...". This one is a very typical problem with the GUI, the graphical user interface. The difference of design and art. It sounds simple, but it is not easy to create a functional GUI. It is quite simple to create a nice looking GUI, but that only counts at first glance. In the long run, a GUI must work functionally. The whole order editing started as plain edit function without any assistance. When you changed a data, the new data was taken. A rough calculation system was added to help with the simple summation.

VirtueMart 3.6 extended the order editing assisting system. The tax change works by drop-down, but this system was not written for discounts. The problem here was to find an elegant GUI. For example, a VAT does not need to be overwritten. If you select a VAT, you expect a fail-proof calculation. But sometimes a discount is granted according to a certain rule or only as a result of a specific trade. As a result, changing a quantity of a discounted item did not change the discount according to the new quantity. The system accepted the discount the old way, as direct input.

The new system now works so, that the discount is always calculated by the given prices and multiplied by the quantity. However, if some of the required prices do not exist (for example, the undiscounted gross price), the discount value is transferred as direct input for the whole position. So you can still overwrite the discount by simply emptying the gross price. The GUI concepts follows the intuitive idea, that an empty price field is calculated by the existing data. So you can of course also just set the gross price and the discount and you will get your net and final price calculated automatically.

Last but not least the bug-fixes. Sometimes it happens that a "furniture feature" turns out to be a roof changer ;-). The feature "automatic thumbnailing of the 'no image set' image" is one of these types. It led to a cascade of changes in the mediahandler.php file. The feature "remote images" remained silent in its corner and only caused problems there. But the simple sounding "automatic thumbnailing of the 'no image set' image" even caused problems when adding a new media because it suddenly behaved as thumbnail "no image set" image.
Sometimes a bugfix aggravates the problem. In German we use the word "verschlimmbessern", from "schlimm" (sad) and "bessern" (to make better). Test users reported that sometimes payment/shipment methods are not correctly selected in the cart, or not visible for selection. The provided fix solved the problem if categories were not set, but created another one. Adding the extra tests for the case 'on empty' lead to a wrongly used pattern and broke the category conditions.

I hope that I gave a good insight how complex it is to deal with new features, bugs, features removing bugs, and bugfixes adding bugs, and so on.

Thanks to our good community - join us at forum.virtuemart.net