View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0017360||mantisbt||plug-ins||public||2014-05-20 05:36||2017-01-25 10:51|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||1.3.0-beta.1||Fixed in Version||1.3.0-beta.1|
|Summary||0017360: Prevent loading of jQuery related plugins|
1.3.x comes with bundled jQuery, jQuery-UI and jQuery Mobile.
I did not test until now, but having the embedded scripts in addition to the plugins might introduce unexpected behaviour.
I prefer a)
|Tags||No tags attached.|
I actually ran into this issue myself with jQuery plugin last year , although I don't exactly remember what the symptoms were. The fix I implemented was to add a maximum dependency on version 1.3 in the plugin's requirement .
When the requirements are not met, the plugin framework does not load the plugin.
I did not check the jQuery-UI plugin as I have never used it, but I would recommend to apply the same logic to it.
Not sure if it's worth adding an upgrade step or admin checks for that.
Made some tests:
Installed MantisBT 1.2.17
After removing your latest change in jQuery all works fine.
Advantages if we add two steps in schema update to remove the jQuery, jQueryUI entries from
Personally, I'm tempted to say that 1.3 (or 2.0) for that matter shouldn't load plugins that are written for a different version.
This could then be used for the model of when we bounce version numbers.
i.e. a plugin written for 1.2 will load in 1.2.0 as well as 1.2.100, but once we bounce to a new release e.g. 1.3 or 2.0, the plugin requires an update.
From our point of view, that would mean that we'd generate a new 1.X or X.0 release if it requires plugin authors or SOAP api users to change existing code.
We'd generate a 1.X.Y release if the changes in the release should not affect existing plugins/api's
In any case, trying to load a 1.2 plugin in 1.3 / 2.0/ whatever feels like it's something that will likely cause grief. I'm looking at the jump between 1.2 and 1.3 for instance being similar to moving between visual studio 2010 and 2012 - i.e. it's normally fairly trivial to update the code (i.e. often no changes required), but you need a recompile to use the new libraries.
I'll take a look at the plugin detection logic tomorrow with a view to implementing the above.
Reminder sent to: atrol, dregad
did the proposal in my last bug note seem sensible and worth authoring?
I was expecting some feedback before I did anything, although I definitely wasn't clear in what I said to reflect that!
I didn't enter this issue to change the dependency mechanism of plugins in general.
I still think that adding two steps in schema update to remove the jQuery, jQueryUI entries from
It will force the authors of plugins that used these plugins to check/update their code.
EDIT: fix link
Coming back to atrol's comment 0017360:0040722, with the code I'm proposing plugins not explicitly supporting the latest version will be automatically disabled, so I don't think it's necessary to add an upgrade step.
It may be useful on the other hand, to add a test in the Admin Checks, to provide information about disabled plugins.
MantisBT: master f5882b33
2014-07-22 19:00:05Details Diff
|Plugin dependency fail with new Mantis release
If the plugin's minimum dependency for MantisCore is unspecified or
lower than the current release (i.e. the plugin does not specifically
list the current core version as supported) and the plugin does not
define a maximum dependency, we add one with the current version's minor
release (i.e. for 1.3.1 we would add '<1.3').
The purpose of this is to avoid compatibility issues by disabling
plugins which have not been updated for a new Mantis release; authors
have to revise their code (if necessary), and release a new version of
the plugin with updated dependencies.
|mod - core/plugin_api.php||Diff File|
MantisBT: master 574dfa29
2017-01-15 18:33:30Details Diff
|Fix MantisCore plugin dependencies
In issue 0017360, we introduced setting a default maximum version for
MantisCore to avoid compatibility issues by disabling plugins which have
not been updated for a new Mantis release, with a break on every minor
With 2.0 and the decision to only introduce breaking changes on major
versions (X.y.z), this code has to be changed.
|mod - core/plugin_api.php||Diff File|
|2014-05-20 05:36||atrol||New Issue|
|2014-05-20 07:39||dregad||Note Added: 0040593|
|2014-05-20 07:39||dregad||Status||new => feedback|
|2014-05-25 15:21||atrol||Note Added: 0040635|
|2014-05-25 15:21||atrol||Status||feedback => new|
|2014-05-26 18:35||grangeway||Note Added: 0040643|
|2014-05-26 18:39||grangeway||Assigned To||=> grangeway|
|2014-05-26 18:39||grangeway||Status||new => assigned|
|2014-06-01 17:25||grangeway||Note Added: 0040702|
|2014-06-02 16:16||atrol||Note Added: 0040722|
|2014-08-08 17:32||dregad||Note Added: 0041038|
|2014-08-08 17:32||dregad||Assigned To||grangeway => dregad|
|2014-08-12 06:06||dregad||Note Edited: 0041038||View Revisions|
|2014-08-12 06:10||dregad||Note Added: 0041053|
|2014-09-05 20:03||dregad||Changeset attached||=> MantisBT master f5882b33|
|2014-09-05 20:03||dregad||Status||assigned => resolved|
|2014-09-05 20:03||dregad||Resolution||open => fixed|
|2014-09-05 20:03||dregad||Fixed in Version||=> 1.3.0-beta.1|
|2014-12-08 00:34||vboctor||Status||resolved => closed|
|2017-01-25 10:51||dregad||Changeset attached||=> MantisBT master 574dfa29|