Zenphoto
The simpler media website CMS
ZenphotoThe simpler media website CMS
Forum search only. You might also want to search on the main site's user guide.
Your support helps pay for this server, and helps development of zenphoto. Thank you!
Visit the donations page
Comments
THe http://www.twospy.com/galleriffic/ says still compatible with jQuery 1.3.2. Looking at the linked Google code repo on that site the last update was in 2009! It was likely to happen some time since ZP 1.4.5 has 1.9.1 on board.
Try if this one helps:
http://blog.jquery.com/2013/02/16/jquery-migrate-1-1-1-released/
We use that with the jCarousel plugin which is also not compatible otherwise.
``
`jcarousel_thumb_nav.php` is the only Zenphoto script (we know of) that requires the migration. It outputs this from its `theme_head` filter. We are working on a replacement for this plugin, since it seems not to be being updated. But the replacement is not likely to be ready for 1.4.5.
I will have a look on it .
The replacement will be this one: https://github.com/zenphoto/zenphoto/issues/349
Since it is the successor of the script of our slideshow as well it might take over both the slideshow plugin and the jCarousel one and provide options what to use. It can even use both combine for example the image page (similar like galleriffic) Otherwise we would have to work with plugins being dependent on others.
Sadly time issue kept me to start on it in time.
http://blog.jquery.com/2013/05/08/jquery-migrate-1-2-1-released/
We have no need to follow updates as the one we load does make our script work. However for other scripts that may be different.
Thus the idea of a plugin.
Thanks for the tip.
otherwise, there are risks to load the script several times (for example, via the jcaroussel plugin and theme via zpArdoise).
with that, each tool (plugin, theme) which need of the script can activate the plugin.
considers that zpArdoise theme is distributed, and it needs migrate script, but I do not have a lot of means to verify that the migration script is already loaded or not, and avoid several loading of script.
I may do a test to see if the jcaroussel plugin is enabled or not, but it's really not very clean.
Thanks
Only the theme developer will know that the migration is required so must deal with getting the script loaded (be it plugin or simply the one line of code that is required.)
A plugin is simply overkill for one line of code that only the theme developer knows is needed.
BUT, what can happen with several loading of this script (loaded by jcarroussel plugin and by zpArdoise) ?
could be some js conflict ?
if script should loaded once, one way is to have a plugin to add the line in the header, and everything needs the script uses plugin (I do that with colorbox with my theme : whatever this plugin is allowed or not, I enable it in themeoptions)
Since we have no js/css registering like WP has, there is no except this optional (unsupported) plugin does mimic that registering:
https://github.com/zenphoto/Unsupported/tree/master/plugins/headConsolidator
Did you miss my post above? I'd like to upgrade my ZP but will hold off until zpArdoise is compatible. Can you tell what page to add the migration code?
It's too bad that development on Gallerific has stopped.
no, I don't miss anything, but I still look for a global solution (read post above).
I agree with sbillard that a plugin is overload for just one line of code. So actually the cleanest would be to either update or throw out all tools that are not compatible anymore. The migrate script logs what is outdated and needs fixing. Maybe take a look, maybe it is just minor things.
tinyZenpage was broken as well and is fixed now. There it was just the usage of one now removed function (attr() before, prop() now).
You have missed my point entirely. If this line were relegated to a plugin, then either the user would have to know to enable the plugin (which is unlikely) or the scripts that need it would have to load the plugin.
If the latter, which is the only way that you can insure a working theme, then you can just as well load the script as a plugin.
to avoid multiple loading of code, one way is to have a plugin to add the line in the header, and everything needs the script (jcarroussel or zpardoise or everything else) enables the plugin (I do that with colorbox with my theme : whatever this plugin is allowed or not, I force to use it in themeoptions for my needs).
adding the line of code needed is centralized somewhere in a plugin, and all objects that need it, force the use of the plugin, don't you think this is a simple way to manage the migration of all the objects that are not compatible with jQuery 1.9.0 (yours and third party ones)?
if not, what will I do in my theme? test if Jcarroussel is allowed, if so, I do nothing (the line of code is already added in the header), if not I add the line of code in the header.
admit that it is a very dirty way to code, right?
maybe your themes and plugin are compliant with JQuery 1.9.0 (that is not case with JCaroussel), but are you sure that all popular third party themes have no problem with it?
each third party theme should find its own solution or zenphoto should offer some capabilities to simplify the job of all others?
The best would be to make the consolidator plugin a core feature and the recommend way for themes and plugin to load CSS and JS (and somehow ensure the old ways till works to not break older themes). So we can easily prevent multiple loading of CSS and JS scripts.
Just to learn form the big ones: On WP that is the recommended way for themes/plugins to avoid the problem we are discussing. It is also possible to de-register scripts if you wish to use your own jQuery and not the included WP one. It is still possible to load things directly on a theme if you wish but clearly not recommended.
But adding such a feature and change so close befor a release will not likely happen.
Anyway, I will look at the jCarousel plugin these days to see what the migrate script complains about. If it is easy I will just try to fix it for this time.
Maybe you should do the same with the gallerffic plugin. Maybe it is just using one old function that can easily be replaced.
there is 2 removed functions used by gallerific: .live() and . browser().
for .live(), I replace easyly it by .on() function.
but for .browser(), it goes far beyond my skills.
in fact, it is the script history, used by Galleriffic, which is inconsistent because it uses .browser().
so I have to replace inital history script used by galleriffic by other one (hashchange script or BBQ script for example).
I don't know how to do that...
maybe gjr have some idea?
So I will look at jcarousel and if we can take out the migrate script there we partly solve the issue of including it several times.
jCarousel has already a new one but without backward compatibilty. So I will not work on this and instead do the planned Cycle2 plugin which is a lot more versatile.
EDIT: Great, on jCarousel it is also .browser()...
Maybe that can be re-used to fix galleriffic so the migrate plugin is not needed.
don't worry, in any case, there will be a 1.4.5 release of zpArdoise and I will find a solution.
I found a solution to replace .live() and as acrylian I'm looking for a solution for .browser()
@acrylian :
I have a look on github and I have found very closed solution on the Net.
my question : what could append if .browser() is defined twice (in jcarroussel and zpardoise) ?
in other word, do you know Charybde and Scylla ;-) ?
I ask me if a solution is to disable jcaroussel if zpArdoise is used, to avoid this conflict.