Hello,
In short: I want to completely disable VM from loading the default fancybox script, but ONLY for the frontend.
More details...
I am using a different/custom version of fancybox, which is nicely integrated in my template.
A crude approach to prevent the default fancybox from being loaded at all, is by renaming the folder:
/components/com_virtuemart/assets/js/fancybox
However, this breaks some stuff in the VM administrator, and I want that to still keep working as it was.
Any ideas on the best way to solve this?
Thanks
And all works fine... except the backend! Which also
Yep, we use this solution before 5 years (fancybox 3.X),
I don't remember exactly, but I think we change some core code in VM, where is old fancy is loaded (for FE)....
The version of Fancybox included with VM is an old one. A license is required for all commercial applications using later versions, which means that it could not be included with VM, or would require a special (costly) licencing arrangement. Who would pay for that.....
QuoteA license is required for all commercial applications using later versions, which means that it could not be included with VM, or would require a special (costly) licencing arrangement. Who would pay for that.....
Yes, every new VM with new fancybox 3.X must be pay license - then VM use old free version Fancybox still.
In our shops we changed and use bootstrap now.
I understand.
I am trying to find (and override in the template) the code that loads Fancybox on the front-end. If anyone knows it would save me some digging.
My thoughts below...
Regarding fancybox/facebox... VM has a tight integration with old deprecated libraries.
VM provides an option to use fancybox (1.x) OR facebox, but no option to use neither (so we can use a custom solution)!
Also, I don't mind fancybox 1.x in the VM admin panel, it does its job.
Also, to avoid the common issues of version collisions, and backwards incompatibilities... we should use versioning!
It's not "Use Fancybox", it's "Use Fancybox 1.x".
The relevant folder should be called "fancybox1", or something that makes it explicit, and allows room for future change.
Avoid ambiguities. Be certain that the future will bring change, and be ready for it.
(a similar case happened with Joomla, heavily depending on Bootstrap 2.x, calling it simply Bootstrap, and making it difficult to move on to v3 or v4 later on)