View Issue Details

IDProjectCategoryView StatusLast Update
0017360mantisbtplug-inspublic2017-01-25 10:51
ReporteratrolAssigned Todregad 
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Product Version 
Target Version1.3.0-beta.1Fixed in Version1.3.0-beta.1 
Summary0017360: Prevent loading of jQuery related plugins

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:
a) check when upgrading from 1.2. to 1.3, uninstall existing jQuery
b) introduce a hardcoded "do no load" list
c) ???

I prefer a)

TagsNo tags attached.




2014-05-20 07:39

developer   ~0040593

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.




2014-05-25 15:21

developer   ~0040635

Made some tests:

Installed MantisBT 1.2.17
Installed plugins jQuery, jQueryUI and InlineColumnConfiguration (needs jQuery and
Updated the installation using nightly 1.3 build.

Plugins jQuery is invalid (expected after your latest change)
Curious results InlineColumnConfiguration (cluttered UI in IE, maybe caused by a
mixture of JavaScript code)

After removing your latest change in jQuery all works fine.
This will also be the case if users have not installed latest version of jQUery plugin.
But we will transfer two times the whole JavaScript stuff (about 600KB).

Advantages if we add two steps in schema update to remove the jQuery, jQueryUI entries from

  • don't deal with issues caused by different combinations of JavaScript code
  • avoid unnecessary network traffic when sending two versions of the JavaScript
  • avoid unnecessary operations when checking plugin dependencies


2014-05-26 18:35

reporter   ~0040643

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.



2014-06-01 17:25

reporter   ~0040702

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!



2014-06-02 16:16

developer   ~0040722

I didn't enter this issue to change the dependency mechanism of plugins in general.
This is for the special case where something which has been available as a plugin for 1.2.x is no longer needed as a plugin for 1.3 because it is now part of the core.

I still think that adding two steps in schema update to remove the jQuery, jQueryUI entries from
mantis_plugin_table is a good way to deal with it.

It will force the authors of plugins that used these plugins to check/update their code.

  • all the other advantages I mentioned above.


2014-08-08 17:32

developer   ~0041038

Last edited: 2014-08-12 06:06

View 2 revisions

I implemented grangeway's suggestion (see 0017360:0040643) for the plugin api in PR which should solve this issue.

EDIT: fix link



2014-08-12 06:10

developer   ~0041053

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.

Related Changesets

MantisBT: master f5882b33

2014-07-22 19:00:05


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
mod - core/plugin_api.php Diff File

MantisBT: master 574dfa29

2017-01-15 18:33:30


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
mod - core/plugin_api.php Diff File

Issue History

Date Modified Username Field Change
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