Closed (fixed)
Project:
Date
Version:
6.x-2.x-dev
Component:
Date Popup
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
16 Nov 2010 at 23:51 UTC
Updated:
7 Jun 2015 at 22:23 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
beanjammin commentedPatch against current head adding the jquery_ui dependency to date popup.
Comment #2
karens commentedIt is deliberately not a dependency because adding a new dependency to an existing configuration causes the dependent module to get its checkbox disabled so it cannot be enabled. I instead just display a warning message so you can enable the module.
Comment #3
beanjammin commentedI suspect I'm missing something obvious, but without the dependency there's nothing to stop someone from enabling date_popup without jquiry_ui, which leads to a WSOD on admin/settings/date_popup and the following error "PHP Fatal error: Call to undefined function jquery_ui_get_version()".
Comment #4
karens commentedI've added new dependencies before. If I just make it a dependency my issue queue will be full of people complaining that there is no way to enable the module. If I don't you may get errors. There is no way to win. I've chosen one of two bad solutions. It's a core bug that there is no clean way to do this.
Comment #5
beanjammin commentedThanks for the explanation.
I did some quick searching in the issue queue, is this the core bug you are referring to?
http://drupal.org/node/655896
http://drupal.org/node/389126 sounds somewhat similar, but not module updating related.
Comment #6
donquixote commentedFatal error: Call to undefined function jquery_ui_get_version() in /[..]/sites/all/modules/date/date_popup/date_popup.module on line 129
(added a date_popup element in a custom form)
I understand the argument about not adding a dependency.
But can we not at least wrap these calls in some if/else logic, to have a non-wsod fallback and error message?
Comment #7
gabor_h commentedI agree with donquixote, please wrap these calls in some if/else logic.
Comment #8
gabor_h commentedComment #9
kenorb commentedThe same problem:
Comment #10
kenorb commentedIn Status I see following description:
It says that's not yet a requirement.
I'm trying to install it anyway, but there is related bug, where I can't: #970974: The jQuery UI plugin is missing.
Comment #11
Crell commentedIf you're enabling date_popup via Drush, you get no such message. Adding a line to the .info file is the correct solution. It's been warned about forever. Anyone who complains you can point out a core bug. :-) Is there an issue for it?
(You can enable it via drush if the UI borks on you.)
Comment #12
Crell commentedI just marked #937108: Date/JQuery update modules as a duplicate.
Comment #13
Crell commentedKarenS: Another option is to force-enable the dependent module in an update hook. The update hook can refuse to run itself if the required module is not available. That gives people a UI-only way out of the core checkbox bug.
Comment #14
karens commentedAnother report is here #1132756: Add jQuery UI module to the dependencies list for Date Popup.
Comment #15
arlinsandbulte commentedI think d.o tests are failing due to the jquery_ui dependency not being in the .info.
So... just as an experiment, I am adding it to see if it fixes tests.
I may regret it later, but let's see what happens.
commit: http://drupalcode.org/project/date.git/commit/3515ed3
I'll follow up later...
Comment #16
alanpeart commentedJust want to add my voice to the chorus here. This dependency has caught me out several times (WSOD after updating date module on several sites), it's all very well for me to read the Apache log to figure out why I'm getting 500 errors but the intern I had hired to update Drupal sites on my behalf was pulling their hair out!
Comment #17
escoles commentedJust had to spend 20 minutes looking for the reason uc_discounts_alt (which depends on date) was failing, because the dependency between date and jquery_ui is not documented. Would have been simpler if it were.
Comment #18
RytoEX commentedIf this was released in 6.x-2.10, shouldn't this be marked as "Closed (fixed)" instead of "Postponed"? It seems to have been included in 6.x-2.10. I'm just looking for confirmation that I'm not crazy and that changing the status is the right thing to do. If I don't hear from one of the maintainers within two weeks, I'll change it myself.
Comment #19
jiv_e commented