The problem started with a small change to the Joomla updater, which required us to write a system plugin for third-party VirtueMart plugins. But of course a few third-party developers did the same thing (one of them gave us the code instead of providing his own) and so we encountered several plugins trying to load the VirtuemartConfig class before the updater could load the config class from the new installation files. So the updater got the wrong paths. Normally this wouldn't be a big deal as long as the correct SQL files are loaded, because most of the installation functions are based on those of the installation program.
But one of the big design changes in VM 3.4 was to use the Joomla class loader. The old VirtueMartConfig classes didn't register the new classes and all old 'if class not exists' constructions were removed, so some users had missing classes when they updated the core program. We are sorry about that.
We noticed this problem a few months ago and updated the system installer to check if there is an update and set the correct path. But we overlooked the point that third-party system plugins can already be loaded and that our system plugin is usually updated later (most people update the core first, then AIO). So users who updated got the problem that the updater loaded the wrong SQL files. The simple fix was to use the installation files to update again, or to run our tool (usually for developers only) "Install or if necessary update tables". This was the reason why we changed the installation files within 2 days of the release. The new installer now always uses the correct directory and it is no longer dependent on the loaded VirtueMart config class. In addition, the classes are re-registered in the Joomla class loader with the correct path. Third party vendors should update their system plugins by loading the VirtueMartConfig class in the same way as ours.
r9962
Fix for vendor list (Fallback for multilang was missing)
---------------------
r9961
- fixed bug of double encrypted fields in case of table loaded with language fallback
- Enhanced installation of language tables (fullinstaller, normal install, language change)
---------------------
r9955
- backend category listing, added strip_tags to category_description (invalid html in the description could break the list layout)
- removed accidently set comment at trigger plgVmOnStoreInstallPluginTable (customs) and added an if so that the trigger is only executed when a custom with plugin is stored
- added allIds to fillVoidProduct to avoid notices
- readded function _getCustomPrice
---------------------
r9954
- VmConfig the option "Use Global Configuration" displays now the language tag of the global configuration
- installer, removed COM_VM_INSTALL_VMCONFIG_ALREADY_LOADED
---------------------
r9953
added function vRequest::vmHtmlEntities and used it anywhere in product edit (replaced old htmlentities respectivly htmlspecialchars)
---------------------
r9952
Fixed order tracking mode
---------------------
r9951
Paypal Smart Buttons added label, language, ...
---------------------
r9950
- sendVmMail: more robust code
---------------------
r9949
Fixed 404 handling, 404 is now set in the header
---------------------
r9944
eway: fixes in payment currency
---------------------
r9943
Eway uses an AJAX page using the JSONP submission script State code sent to Eway countrycode + state code payment currency fixed
---------------------
r9939
- Moved vmDefines outside config
- Important fix for the country/state checker again, when no state/country userfield was published
- Userfields, cart address should show now the country in the right language
- order status was sometimes in invoice mail not correctly translated
---------------------