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 |
Reporter | atrol | Assigned To | dregad | ||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
Target Version | 1.3.0-beta.1 | Fixed in Version | 1.3.0-beta.1 | ||
Summary | 0017360: Prevent loading of jQuery related plugins | ||||
Description | 1.3.x comes with bundled jQuery, jQuery-UI and jQuery Mobile. There is no longer the need for plugins like I did not test until now, but having the embedded scripts in addition to the plugins might introduce unexpected behaviour. Possible solutions: I prefer a) | ||||
Tags | No tags attached. | ||||
I actually ran into this issue myself with jQuery plugin last year [1], 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 [2]. 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. [1] https://github.com/mantisbt-plugins/jquery/issues/1 |
|
Made some tests: Installed MantisBT 1.2.17 Result: 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.
|
|
I implemented grangeway's suggestion (see 0017360:0040643) for the plugin api in PR https://github.com/mantisbt/mantisbt/pull/239 which should solve this issue. 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 15:00 Details 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. Fixes 0017360 |
Affected Issues 0017360 |
|
mod - core/plugin_api.php | Diff File | ||
MantisBT: master 574dfa29 2017-01-15 13:33 Details 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 version (x.Y.z). With 2.0 and the decision to only introduce breaking changes on major versions (X.y.z), this code has to be changed. Fixes 0022171 |
Affected Issues 0017360, 0022171 |
|
mod - core/plugin_api.php | Diff File |