In fact, I always worked in this module with jQuery UI library 1.7.x. I just accepted the possibility to offer support for 1.6.x after it was requested here in the issue queue: #476004: is jQuery 1.3 really required?.

However, IMHO, that decission is giving to all of us more headaches than benefits. Facts:

- jQuery UI library 1.6.x is aimed to work with jQuery library 1.2.x
- jQuery library 1.2.x seems to be dead, because real issues with latest browsers are not supported, so... it looks wiser to upgrade to jQuery 1.3.x and look at the future :)

Not so critical facts, but still important:

- Dealing with issues that end up related to issues with bugs in jQuery 1.2.x or jQuery UI 1.6.x makes everyone spend time in the wrong direction.
- It looks wiser to join all those efforts to help those that still run legacy version to upgrade.

This remainds me the war against IE6 lol, but seriously, choosing the wrong path makes us loose time that we do not really have, so... hence this issue. Feel free to comment.

CommentFileSizeAuthor
#20 modalframe_798618.patch895 bytesdrewish
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

markus_petrux’s picture

Status: Active » Needs work

Project page and README.txt file updated to reflect the jQuery and jQuery UI requirements.

http://drupal.org/cvs?commit=366870

I am going now to implement hook_requirements() to check for the jQuery UI version installed.

markus_petrux’s picture

Status: Needs work » Fixed

hook_requirements() implementation done.

http://drupal.org/cvs?commit=366874

Behavior if version of jQuery UI library installed is not equal or higher than 1.7:

- During 'runtime' phase, generate a warning so existing sites had a chance to notice the policy in regards to support of jQuery UI library has changed.
- During 'install' phase, generate an error. So it won't be possible to proceed with Modal Frame until the jQuery UI library is at the proper level.

Dublin Drupaller’s picture

@markus

The latest "runtime" commit is throwing up a status report page error about the version of jquery installed...even when you update to version 1.7.

modalframe still appears to work fine, but, I thought I would flag the above.

dub

p.s. this is a fantastic module, by the way. Very well thought out and implemented.

markus_petrux’s picture

Thanks for the kind comments. I'm glad this module is being so useful to the community.

hmm... the jQuery UI module provides version information. What do you see in the jQuery UI row of the admin/reports/status table?

Dublin Drupaller’s picture

sorry Marcus...disregard previous message. I just checked and I didn't upload the version.txt file into the /sites/all/modules/jquery_ui/jquery.ui folder.

For anyone else who runs into the same problem..the module looks for the version.txt file to determine which version of jquery ui is there. So if you're like me, who just upload the /ui folder from the jquery download...don't forget to upload the version.txt file as well.

dub

markus_petrux’s picture

Ah!

Good to know it's sorted. Cheers!

meba’s picture

To be honest, I think this was a bad idea. This is effectively breaking API compatibility in minor versions. I actually just experienced this.

The ideal situation would be to create a 2.x version of Modalframe with this requirement and leave 1.x live with 1.6 jquery_ui

meba’s picture

As an example, we just spent a lot of time on Brightcove module with a dependency on Modalframe and just few hours before a stable release, we are forced to fix this because the requirements changed...

As an another example, Acquia Distribution, used by a lot of people, uses jquery UI 1.6.

Would you please reconsider this, create a 1.8 release with this requirement rollbacked and then 2.x release with a new requirement? Old version can then be staged out...

markus_petrux’s picture

There have been so many issues that have been related to legacy versions of jQuery. All that requires time that I do not have. It's software that is not supported anymore. It's time spent for nothing.

I understand it could generate one or two headaches, but it is an effort spent on the right direction. jQuery 1.2.x and jQuery UI 1.6.x are a bad base for any new project these days. Development in jQuery land is far beyond that point. If you build a project on top of jQuery 1.2.x and jQuery UI 1.6.x you'll have issues today with these libraries, and these issues won't get fixed in those branches. You'll have to upgrade sonner than later.

That being said... existing installations still work with legacy versions, but if such an installation comes to report an issue, the first thing I'll ask is to upgrade jQuery/jQuery UI to 1.3.x/1.7.x.

I would prefer spending time in working to get jQuery 1.4 in Drupal 6 as stable as possible.

meba’s picture

Sorry to add multiple comments but I have just ran into another issue: Lightbox2 module currently doesn't support jQuery 1.3.x (at least the stable version that everybody uses) so it all starts a dependency hell which doesn't have a solution.

Since our module depends on both Modalframe and Lightbox, we will have to ask users to install Modalframe 1.6 :-( (Which means they cannot use drush, automated status updates, etc.)

meba’s picture

I totally agree with you, it's time better spent. Keeping that in mind, that's why I proposed to make a Modalframe 2.x that requires jquery 1.3.x and you will make it a supported version. Everybody will now install Modalframe 2.x but users with 1.x branch will still be safe and will have time to upgrade other modules...

(I wouldn't be proposing this unless there is a better solution. I don't see it. I am now in dependency hell which doesn't have a solution - either break modalframe or break lightbox and a lot of implementations need both)

andb’s picture

Yes, it makes sense not to spend time working on backwards compatibility. That said, it makes sense not to upgrade libraries in a minor point version. Can you imagine if Drupal core changed api calls between minor versions? I think the situation is comparable.

Anyone who uses modalframe will assume that 1.6 -> 1.7 will "just work" and that isn't the case here for many users. I also feel that this should have been a major point release.

Could you consider making this a major point release to help your userbase understand that this is actually a significant upgrade which may require testing and might not be an upgrade that some sites want to make?

markus_petrux’s picture

I could create a separate branch, but I wouldn't be giving support to the branch that allows sites run legacy versions of jQuery. This road will generate noise, as it has been, and that requires time that I do not have.

So... I'm not sure how it is the life cycle of a branch that I know I do not have time to support.

andb’s picture

You are right that for a new site its possibly suboptimal to use older versions of Jquery, but there are a lot of older sites which have a lot of custom code and can't afford the "luxury" of upgrading jquery versions.

The question is, which is the lesser of two evils, to have a branch you don't maintain or to have a branch which could break unsuspecting developers' sites... I think you can tell which I prefer from the question :) It seems to me that keeping 1.x as ui-1.6 (unsupported in the future) and making 2.x for ui-1.7 is the lesser of the evils. I think the OS analogy is useful here, can you imagine if Debian Lenny one day just decided to upgrade to PHP 5.3? Thats why library versions only change in major version releases.

I suggest clearly marking the 1.x branch as deprecated on the project page and state that it is no longer receiving any support whatsoever from the module maintainer. For any new issues raised in 6.x-1.x I'd have a standard post that states to upgrade, and perhaps the community will support them.

Thanks for considering this issue, I appreciate it.

locomo’s picture

subscribe

meba’s picture

Markus, is there any resolution on this issue? Is there anything we can do to help?

markus_petrux’s picture

I think the issue is about the time I can spend trying to provide support for this module. And I'm afraid the current situation is all I can do. This means I cannot officially support legacy versions of jQuery.

If I do not officially state that support for legacy jQuery stuff is deprecated, then I'll keep getting issues, needing time that I do not have. Also, claiming this module works ok with legacy jQuery libraries will make more than one loose some time, because there are issues with these legacy jQuery that will not be fixes in their branches any time soon. In fact, I should have never accepted this module was going to work with legacy jQuery stuff. That was my fault, but it was nice for the one who asked for that, but the real thing is time is not endless, and I have to choose.

If I was catched into legacy jQuery stuff by something else, I would spend my time on trying to help the maintainer of that "thing" to make it compatible with newer versions of jQuery. If no one does this, then those things will remain "legacy" for years, while the world keeps moving on...

That being said, you have the source code, so you can edit and remove or change the implementation of hook_requirements(), but obviously this is unofficial and not supported.

markus_petrux’s picture

FYI: If the problem was related to Lightbox2 -vs- jQuery 1.3.x... you may want to look at this: #411162: Problem with 'automatic image URL re-formatting' with jQuery 1.3.x.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

drewish’s picture

Status: Closed (fixed) » Active
FileSize
895 bytes

I'll add my vote for having future changes that bump the jquery version end up in their own branch just because it make it much easier for other module developers. This hit the hostmaster project (#818900: Modal Frame and jQuery UI upgrade) and the modalframe_requirements() changes are breaking the use of the module in an install profile.

But this isn't a democracy and you're doing what you feel is best for the module and I can respect that. So lets move things forward and get modalframe useable in an installation profile. The simple fix is to just not report any requirement errors when we're being installed by install.php.

drewish’s picture

Status: Active » Needs review
markus_petrux’s picture

Status: Needs review » Needs work

Can we document why installation profiles break and if there will be a solution any time in the future?

It is because drupal_load() is buggy? Why there's no information at api.d.o about this limitation? Can we do something to properly address this issue, if not why? I would prefer to properly document why do we exactly need this patch, and if we could remove it in the future. Thanks!

[EDITED] ...once we can document this issue, I think we would have to create a new release so that a stable package can be used in installation profiles.

PS: I never thought this module was going to be used by so many sites and projects. I just shared something I did, but that is critical enough to still get control over its evolution. I've seen enough issues where their origin is legacy jQuery stuff, and I have to measure very well the time I spend maintaining this module, because I do not have much time for that. Still I love to keep the issue queue as clean as possible. The perfect solution does not exist. I would also wish to see better documentation around jQuery UI and jQuery Update modules. However, the recommended version of jQuery Update ships the same exact version of jQuery as Drupal core. Looking at the usage stats of the module makes me feel not everyone can keep their housekeeping tasks up to date, and we all should live with that...

markus_petrux’s picture

In other words... if this module uses Drupal APIs to do what their docs say, then why do we need to patch this module if these APIs do not do what they say they do? ...the proper way to fix this issue is a) fix the docs of the Drupal APIs, or b) fix the bug in the Drupal APIs.

The problem seems to be that drupal_load() does NOT work when installing profiles. So the proper fix for this issue is, IMO, fix drupal_load() so that it works for install profiles. I do not know if this has been reported, or which is the official alternative because it is not documented in the API.

hmm... I'm thinking about a different approach. If we cannot provide a proper method to ensure the Modal Frame API cannot be installed under a known state of requirements (because Drupal 6 is not really ready for that), then maybe I could move this check somewhere, at the cost of runtime resources, and refuse to do anything if requirements are not met during hook_requirements('runtime') which is not checked as often as we may need, or hook_init() which is probably checked too often.

The patch in #20 seems easy, but it is just bypassing the requirements check under certain circumstancies, so there will be issues where users keep reporting jQuery library problems. IMO, that's not acceptable.

We need to find a method that ensures that module requirements are properly installed. If Drupal 6 does not help, then we need to document why and code and alternative method that works, not one that bypasses requirement checks.

markus_petrux’s picture

Status: Needs work » Closed (won't fix)

Since nobody seems to be doing anything to solve the source of the problem, I'm going ahead and mark this issue as won't fix.

I had a similar issue with another module of mine: #857928: Breaks installation profiles (new versions of Formatted Number CCK require a particular version of Format Number API).

Well, the thing is if I remove the hook_requirements() check, then I need to implement the check somewhere else, but that will penalize performance, so it is not a good solution. It is also hackish because the real problem remains unfixed, which is drupal_load() broken for installation profiles, and that's something out of the scope for contrib modules. It is Drupal core who should provide a solution to this.

To those working with (or in need of) installation profiles: you should first fight to fix the root of the problem, and that points to Drupal core itself. I'm sorry but I do not have the time to start that war, and I do not like the idea to deal with issues caused by not checking for module requirements properly, which is not just a matter of "taste", but something that may lead to unexpected results and even loss of data. No, thanks.