@tplowe56 :
no, I don't miss anything, but I still look for a global solution (read post above).

The problem is still that jCarousel requires it to not confuse normal users. I will not manage the replacement plugin for 1.4.5, even if I would it would not be in 1.4.5 because 1.4.5dev is in feature freeze status already.

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).

Vincent:

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.

Quote:the scripts that need it would have to load the plugin.
it's exactly my point of vue!!
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?

A separate plugin does not really help, I agree with sbillard. Because a normal theme user will just see something broken without having clue why.

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.

I had a look on gallerific issues.
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?

Seems there is no replacement for .browser() and it was deprecated since jQuery 1.3 already. They are following the way not to use browser specific things apparently. I fear beyond my abilities (and time..) to help out, since that is a more complex script, too.

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()...

So nothing will be done to fix this? This is the end of the line for zpArdoise?

jCarousel does not load the jquery migrate plugin anymore, instead we recreate the missing function: https://github.com/zenphoto/zenphoto/commit/467a672f3633b34b50dd64076fe509f85018466a

Maybe that can be re-used to fix galleriffic so the migrate plugin is not needed.

@tplowe56 :
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.

@vincent: Good question regarding double defines. I'll have to ask sbillard who implemented this.

.browser is a variable, so it may be set as many times as one wants. Of course, the "last" one wins, but that should not be a problem if they all do the same thing.