ZX Slideshow support thread

[DivaVocals]

Yeah this is a problem I've noticed with plugins that rely on the jQuery library. Not everyone uses the same method to include jQuery in their modules. Some modules hardcode the call to jQuery inside the add-on code, and others include the JQuery library as a file to be uploaded to the template's jscript folder..

Just to err on the side of caution and eliminate any of the weird JQuery related issues I've run across, I've gone through all of my client's sites and stripped out any hardcoded lines in modules that loads the jQuery library. I then chose to simply remove all the jQuery library files that any module includes (all the files that are to be uploaded to the templates jscript folder) and instead modified the template header file so that I am loading jQuery from a CDN (I'm using JQuery's CDN as opposed to Google's CDN as I'm of the "get it from the source" kinda mindset) This literally stopped all the strange jQuery conflict related behavior and ensures my client's sites are using the latest versions of jQuery.. I do beleive that the upcoming Zen Cart v1.6 is doing the same.. Means a LOT of modules will have to be updated to remove any jQuery libraries they load.. Bright side is that for add-on developers is they do not have to include the jQuery library in their module packages anymore..

[balihr]

Yeah this is a problem I've noticed with plugins that rely on the jQuery library. Not everyone uses the same method to include jQuery in their modules. Some modules hardcode the call to jQuery inside the add-on code, and others include the JQuery library as a file to be uploaded to the template's jscript folder..

Just to err on the side of caution and eliminate any of the weird JQuery related issues I've run across, I've gone through all of my client's sites and stripped out any hardcoded lines in modules that loads the jQuery library. I then chose to simply remove all the jQuery library files that any module includes (all the files that are to be uploaded to the templates jscript folder) and instead modified my template header file so that I am loading jQuery from a CDN (I'm using JQuery's CDN as opposed to Google's CDN as I'm of the "get it from the source" kinda mindset) This literally stopped all the strange jQuery conflict related behavior and ensures my client's sites are using the latest versions of jQuery..

I absolutely agree with that method. However, it requires an additional code edit (most html_header.php files are modified) and wouldn't allow the simple drag-n-drop installation... I've done my best to avoid any need for the user to go into the code and edit files because most people find that to be a problem. If only I could find a way to make these installations from the admin with no FTP...

IMO, the best way would be to EDUCATE everyone writing any Zen Cart modules to simply use the native functions and put all of their code in the jscript directory. Hard-coding is never a good solution and I tend to avoid it if there are better approaches.

Although, it would probably be a good idea for the Team to include jQuery in the original html_header.php and make it a standard with Zen Cart. I mean, 99.9% of Zen Cart sites are nowadays using jQuery one way or the other so why not make it included with the vanilla install...

[DivaVocals]

I absolutely agree with that method. However, it requires an additional code edit (most html_header.php files are modified) and wouldn't allow the simple drag-n-drop installation... I've done my best to avoid any need for the user to go into the code and edit files because most people find that to be a problem. If only I could find a way to make these installations from the admin with no FTP...

I agree, and on a related topic I'm also a BIG proponent of not hardcoding what should be properly included in an admin settings menu. (on/off, yes/no settings should be in the admin menu NOT in the code) Just went through this exercise in collaborating on an update to the Events Calendar module..

That said, there are places where requiring a code edit/merge is simply unavoidable, and in that case I make sure that the changes are CLEARLY commented because it makes it easy as pie to spot changes when using file merging software.. I learned this from developers I've worked with in the past, and several Zen Cart masters employ the same techniques in their code -- Conor Kerr's code is a GREAT example of this.. The way he comments his code changes it's like practically shining a SPOTLIGHT on where the modifications are..

IMO, the best way would be to EDUCATE everyone writing any Zen Cart modules to simply use the native functions and put all of their code in the jscript directory. Hard-coding is never a good solution and I tend to avoid it if there are better approaches.

I agree.. though in the defense of some modules (Zen Lightbox for example), I do believe that some of these leftover practices were from the days before the current template stucture became part of the core, and some devs didn't "fix" these hardcoded kinds of things..

Although, it would probably be a good idea for the Team to include jQuery in the original html_header.php and make it a standard with Zen Cart. I mean, 99.9% of Zen Cart sites are nowadays using jQuery one way or the other so why not make it included with the vanilla install...

Yep.. I totally agree..