InstallPlugins forces every discovered plugin class to be deleted and
re-required from disk on every call, so plugin_methods reflects the
.pm file as it currently exists rather than whatever was already
loaded into a long-lived Plack worker. That deletion used
Symbol::delete_package, which clears the target package's whole
symbol table -- including any already-loaded packages nested under it
(e.g. a REST API controller a plugin bundles alongside itself, such as
Koha/Plugin/Foo/Controller.pm). Those nested classes keep their own
%INC entry, so they are never re-required afterwards and are left
permanently blanked out for the rest of the worker's life.
This was caught when running
`prove -r t/db_dependent/Koha/Plugins/ t/db_dependent/Koha/REST/Plugin/`
on top of the original patch. Tests fail several files that have nothing
to do with the bug being fixed (Biblio_and_Items_plugin_hooks.t,
Holds_hooks.t, TemplateIncludePathHook.t, REST/Plugin/PluginRoutes.t),
because Koha::Plugin::Test::Controller (a bundled test-fixture
controller living in t/lib/plugins/Koha/Plugin/Test/Controller.pm)
gets its symbol table wiped as collateral damage every time
Koha::Plugin::Test is reloaded.
_forget_plugin_class() replaces the delete_package call with the same
technique used by the CPAN module Class::Unload (not added as a
dependency here, just the technique): only clear the target class's
own symbols and reset its @ISA, explicitly leaving any nested package
entries in its symbol table alone. Module::Pluggable discovers bundled
nested classes as their own entries in the plugin list regardless, so
they still get reloaded correctly on their own turn.
I also annotate the no strict 'refs' block added by the previous commit
with a '## no critic' justification, as flagged by koha-qa.pl.
Test plan:
1. Confirm the bug exists without this patch:
a) git checkout <previous commit> (drop this commit, keeping the
first 3 commits of the bug applied)
b) Inside KTD:
prove -r t/db_dependent/Koha/Plugins/ t/db_dependent/Koha/REST/Plugin/
c) Observe failing files unrelated to this bug's own tests:
Biblio_and_Items_plugin_hooks.t, Holds_hooks.t,
TemplateIncludePathHook.t and REST/Plugin/PluginRoutes.t.
2. Confirm the fix:
a) Re-apply this commit
b) Re-run the same command from 1(b) -- all tests now pass
3. Confirm the original bug this branch set out to fix is still fixed,
both via the manual UI steps from the first commit's test plan
(install Batch Permission Modifier Plugin 1.3.1, upload 1.4.1 over
it via Tools > Plugins, confirm the renamed method takes effect
without restarting Plack) and via:
prove t/db_dependent/Koha/Plugins/Plugins.t
(see the 'InstallPlugins() reloads stale symbol tables tests'
subtest)
4. Confirm QA tooling is clean:
koha-qa.pl -c 4
=> PASS for Koha/Plugins.pm and all touched test files, no critic
or tidiness failures.
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
When a plugin is upgraded in place (by uploading a new version over
the old one), the list of methods Koha knows about for that plugin
can get out of date. For example, if a plugin used to have a "tool"
method and the new version renames it to "admin", the staff interface
can still show the old "Run tool" link, and clicking it produces an
error saying the plugin has no "tool" method.
This happens because the plugin upload runs inside a long-lived
Plack worker that has already loaded the old version of the plugin
in memory. When Koha scans the plugin to record its methods, Perl
has no reason to re-read the file from disk, so the scan sees the
old method list and stores that in the plugin_methods table. The
plugin code on disk is new, but the record of what methods it has
is stale.
This patch forces Koha to throw away the in-memory copy of each
plugin and reload it from disk before scanning, so the recorded
list of methods matches the plugin that is actually installed.
Test Plan:
1) Install the Batch Permission Modifier Plugin version 1.3.1
(this version exposes a "tool" method)
2) Go to Tools > Plugins and confirm the plugin row shows
"Run tool" in its actions menu
3) Upload Batch Permission Modifier Plugin version 1.4.1 over
the top of 1.3.1 (this version exposes "admin" instead of
"tool")
4) Reload the Plugins page
5) Note the plugin still shows "Run tool" in its actions menu
6) Click "Run tool"
7) Note the error: the plugin has no "tool" method!
8) Apply this patch
9) Restart all the things!
10) Uninstall the plugin
11) Repeat steps 1-4
12) Note that "Run tool" is gone and "Run admin tool" appears
in its place
13) Click "Run admin tool" and confirm it loads without error!
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Thinking about this today, we really just need the plugins initialized anytime we are using Koha::Plugins
Moving the loading into the BEGIN there seems to resolve the issue
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch addresses the circular dependency issues and code quality
concerns identified in QA by introducing a clean architectural solution.
Changes:
1. Created Koha::Plugins::Loader - A lightweight plugin loader with
minimal dependencies that can be safely called during early
initialization. Uses DBIx::Class when available for proper
transaction support, falls back to raw DBI for early init.
2. Added Koha::Database::table_exists() - Consolidated table checking
logic into a reusable method that can be called as both class and
instance method.
3. Simplified C4::Context BEGIN block - Reduced from ~120 lines to
~13 lines (91% reduction). Removed XML::Simple dependency and
manual database connection code.
4. Updated Koha::Plugins::get_enabled_plugins() - Now delegates to
the Loader module for consistency.
5. Updated C4::Installer::TableExists - Delegates to the new
Koha::Database::table_exists method.
This addresses all QA concerns:
- Eliminates XML::Simple usage (David Cook)
- Uses Koha::Database instead of manual DBI (David Cook)
- Reuses table checking logic (Nick Clemens)
- Eliminates circular dependencies (Paul Derscheid)
- Much cleaner and maintainable code
Test plan:
1. Run tests:
prove t/db_dependent/Koha/Database.t
prove t/db_dependent/Koha/Plugins/Loader.t
prove t/db_dependent/Koha/Plugins/Plugins.t
2. All tests should pass
3. Install and enable a plugin via the UI
4. Verify plugin hooks are called correctly
5. Verify no regressions in plugin functionality
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Generated using
`perl misc/devel/tidy.pl --perl`
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch adds hooks to allow 'Valuebuilder' plugins to be installable
using the standard plugin architecture for Koha. This enables cataloguing
plugins to be dynamically installed, enabled, and disabled through the
plugin system rather than being hardcoded framework components.
Test plan:
1. Install the example valuebuilder plugin from GitHub
(https://github.com/Jacobomara901/koha-plugin-value-builder)
2. Go to Administration > Plugins
3. Verify the valuebuilder plugin appears in the plugins list
4. Enable/disable the plugin and confirm the custom valuebuilder
appears/disappears in the framework configuration
5. Assign the custom valuebuilder to a MARC subfield in the
bibliographic framework
6. Create/edit a bibliographic record and verify the valuebuilder
button appears next to the configured subfield
7. Click the valuebuilder button and confirm it functions correctly
8. Disable the plugin and verify the valuebuilder button disappears
9. Re-enable the plugin and confirm functionality is restored
10. Uninstall the plugin and verify it's completely removed
Sponsored-by: Open Fifth <https://openfifth.co.uk>
Co-authored-by: Mark Hofstetter <koha@trust-box.at>
Signed-off-by: Catherine Small <c.small@rcs.ac.uk>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch simplifies the code a bit, removing duplicated pieces of code
and making it slightly more readable.
The main change is that it now just filters the `@plugin_classes` list
as required, and leaves the original codebase for dealing with loading
the plugins untouched.
A BIG change it implements is that it now requires full class names. I
don't see the use case for partial names, and I generally think we
should be stricter in this area. If there's the need for partial class
names, this should be handled with specific parameters, etc.
It also makes it explicit that the `include` and `exclude` parameters
are mutually exclusive.
A minor idiomatic issue is fixed as well.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Hammat Wele <hammat.wele@inlibro.com>
Signed-off-by: Amaury GAU <amaurygau@gmail.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
I have added the options --include and --exclude to the install_plugins.pl script. When running the script, you can now specify which plugins you want to install (--include) and which ones you do not want to install (--exclude).
--include installs only the plugins from the specified classes.
--exclude installs all plugins except those from the specified classes.
It's possible to specify the package to install a specific plugin.
--include and --exclude cannot be used simultaneously.
Usage example:
./misc/devel/install_plugins --include <package::pluginClass> --include <anotherPluginClass>"
TEST PLAN
1) Apply the patch
2) Add at least three plugins to the plugin directory ([Koha]/plugins/Koha/Plugin/)
3) Empty the "plugin_data" and "plugin_methods" tables (SQL command: "delete from plugin_data; delete from plugin_methods;")
4) In a terminal, execute this command "./misc/devel/install_plugins.pl --include <package::pluginClass> --include <anotherPluginClass>" (Replace <package::pluginClass> and <anotherPluginClass> with the class and package of your plugins)
5) In your Koha intranet, go to "Koha administration > Manage plugins"
6) Verify that only the specified plugins are installed
7) Repeat step 3
8) In a terminal, execute this command from your Koha project"./misc/devel/install_plugins.pl --exclude <package::pluginClass> --exclude <anotherPluginClass>"
9) Verify that all plugins except the specified ones are installed
10) Run the tests from the Plugins.t file ([Koha]/t/db_dependent/Koha/Plugins/Plugins.t)
11) Ensure that all tests are successful
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Hammat Wele <hammat.wele@inlibro.com>
Signed-off-by: Amaury GAU <amaurygau@gmail.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This commit is generated using:
% perl misc/devel/tidy.pl
*within* ktd, to get the same version of perltidy than what will be used
by our CI (currently v20230309).
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We believe that plack will only spawn from one parent and children
cannot spawn further child processes.. as such we don't need to walk up
the tree.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adds the ability to disable the automated plack restart we
introduce with this patchset via configuration.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
I had a feeling we'd want to do this when I submitted the proof of
concept, though I hadn't appreciated the wider issues that have now been
highlighted.. it makes a lot of sense to limit to the plack scope.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adds a graceful plack restart to the plugin
install/uninstall routine to fully allow plugin install to work via the
staff client.
Test plan
1. list your worker processes with something like htop
2. install a plugin
https://github.com/bywatersolutions/dev-koha-plugin-kitchen-sink/releases
3. note that the PIDs of the workers stay the same and no sign of
restart (no PID changes and no CPU activity that the workers would
have if they were starting)
4. apply patches and restart services
5. unistall plugin
6. notice worker restart
7. install plugin
8. notice worker restart
9. downgrade plugin
10. notice worker restart
11. upgrade plugin
12. notice worker restart
13. disable and enable plugin
14. *no restart*
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Test plan:
Run t/db_dependent/Koha/Plugins/Plugins.t
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Extending the regex in Plugins::_verbose.
Test plan:
Run qa tools on patch set.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Three routines in Plugins got the verbose parameter on 35507.
We can refine this a bit further.
The idea here is report when you are installing plugins but not
report when just calling plugins (flooding logs).
[1] GetPlugins: Most callers do not expect (or check) results for
failing plugins. This patch makes GetPlugins only return
errors when passing the *errors* flag (in 2 cases).
[a] The misc/devel script prints warnings now using verbose,
so does not need the errors flag anymore.
[b] plugins/plugins-home is the only case left. Tiny adjustment
to keep current behavior. Fixed colspan in template.
Does not need verbose in favor of 'errors' (passed to
template).
[c] For most calls we do not want verbose. New default is 0.
[2] InstallPlugins
[a] Disabled verbose in plugin-upload. Not really needed.
Added a FIXME; we need to improve individual install.
[b] misc/devel: No warnings anymore when calling InstallPlugins
after GetPlugins.
[3] get_enabled_plugins
[a] Plugins->call does not need verbose.
[b] Plugins->feature_enabled does not need it too.
Test plan:
[1] See previous plan. With TestMR data but without patch, run
misc script and go to plugins-home. Do you see load errors on
commandline or form?
[2] Run plugins/plugins-upload (uploading just some file is good
enough); verify that you do not see TestMR lines in logfile.
[3] Run t/db_dependent/Koha/Plugins/Plugins.t for the additional
test on verbose and errors flag.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Test plan:
Run t/db_dependent/Koha/Plugins/Plugins.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Koha::Plugins::get_enabled_plugins is called by Koha::Plugins::call
which is called by C4::Templates->new, which is used in the web
installer when the database is not created yet
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Yet another approach ;)
Driemaal is scheepsrecht / Third time lucky..
Test plan:
Run prove $(git grep -l Koha::Plugin | grep -P "^t\/db")
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adds a 'feature_enabled' accessor to the Koha::Plugins class.
Passing the plugin method name for the plugin feature you're looking for
will return a boolean denoting whether any enabled plugins carry said
method.
Included in the patch is an addition to the TT KohaPlugins plugin to
enable quick access to this function.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
[EDIT] Tidied t/db_dependent/Koha/Plugins/Plugins.t
[EDIT] Tidied Koha/Template/Plugin/KohaPlugins.pm
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Make use of Koha::Cache::Memory::Lite to avoid hitting the database and
creating plugins object for every call to Koha::Plugins->call
Test plan:
1. Make sure plugins still work by executing
`prove t/db_dependent/Koha/Plugins/Plugins.t`
2. Run the test script provided in the following patch to see how it
affects performances
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds a temporary deprecation warning to let users know the
plugin needs to get updated before the next release.
To test:
1. Apply this patch
2. Run:
$ kshell
k$ prove t/db_dependent/Koha/Plugins/Holds_hooks.t
=> SUCCESS: Tests pass, warning is displayed
3. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
[1] Resolving qa warn on POD coverage.
[2] Adding a line about the passing refs-tric.
[3] Removing an outdated line on available methods.
[4] Removing POD section for after_hold_create. Strayed.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This is based on Julian's idea on bug 28026 where we could get rid of call_recursive by passing refs as arguments to call.
Test Plan:
1) Apply this patch
2) prove t/db_dependent/Koha/Plugins/Plugins.t
3) prove t/db_dependent/Koha/Plugins/Barcode_transform_hooks.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The method call() is not sufficient for all plugin hook types. It's
possible that more than one plugin will be installed that wants to
return the arguaments passed in an updated form. These transformation
plugins need to work recursively rather than independantly.
This patch adss a `call_recursive()` method that takes the output of
the first plugin and uses it as the input for the next plugin and so
on. This allowes each plugin to see the current version of the arguament
list and modify it as necessary.
Test plan
1/ Run the included tests - t/db_dependent/Koha/Plugins/Plugins.t
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds a try/catch block when instantiating plugins. Calling
->new on a plugin eventually triggers a call to ->install (this has
always been like this since bug 7804). If the ->install method is
somehow borked, then the process dies. We need to prevent that, and
report back some error took place. That's what this patch does.
The same happens to the ->upgrade.
To test:
1. Install any plugin you like
2. Restart plack (just in case)
=> SUCCESS: All good
3. Manually change its install method to:
sub install {
die "plugin, die!";
}
4. Run:
$ koha-mysql kohadev
> DELETE FROM plugin_data;
(to make sure there's no __INSTALLED__ entry, do on a safe to delete DB).
5. Point your browser to the plugins-home.pl page
=> FAIL: Boom
6. Apply up to the regression tests
7. Run:
$ kshell
k$ prove t/db_dependent/Koha/Plugins/Plugins.t \
t/Koha/Exceptions.t
=> FAIL: Tests fail!
8. Apply this patch
9. Repeat 2
=> SUCCESS: Tests pass!
10. Run:
$ restart_all
11. Repeat 5
=> SUCCESS: The page is not broken
12. Sign off :-D
Note: I used
$ kshell
k$ perl misc/devel/install_plugins.pl
to test as well.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
On bug 17591 we discovered that there was something weird going on with
the way we export and use subroutines/modules.
This patch tries to standardize our EXPORT to use EXPORT_OK only.
That way we will need to explicitely define the subroutine we want to
use from a module.
This patch is a squashed version of:
Bug 17600: After export.pl
Bug 17600: After perlimport
Bug 17600: Manual changes
Bug 17600: Other manual changes after second perlimports run
Bug 17600: Fix tests
And a lot of other manual changes.
export.pl is a dirty script that can be found on bug 17600.
"perlimport" is:
git clone https://github.com/oalders/App-perlimports.git
cd App-perlimports/
cpanm --installdeps .
export PERL5LIB="$PERL5LIB:/kohadevbox/koha/App-perlimports/lib"
find . \( -name "*.pl" -o -name "*.pm" \) -exec perl App-perlimports/script/perlimports --inplace-edit --no-preserve-unused --filename {} \;
The ideas of this patch are to:
* use EXPORT_OK instead of EXPORT
* perltidy the EXPORT_OK list
* remove '&' before the subroutine names
* remove some uneeded use statements
* explicitely import the subroutines we need within the controllers or
modules
Note that the private subroutines (starting with _) should not be
exported (and not used from outside of the module except from tests).
EXPORT vs EXPORT_OK (from
https://www.thegeekstuff.com/2010/06/perl-exporter-examples/)
"""
Export allows to export the functions and variables of modules to user’s namespace using the standard import method. This way, we don’t need to create the objects for the modules to access it’s members.
@EXPORT and @EXPORT_OK are the two main variables used during export operation.
@EXPORT contains list of symbols (subroutines and variables) of the module to be exported into the caller namespace.
@EXPORT_OK does export of symbols on demand basis.
"""
If this patch caused a conflict with a patch you wrote prior to its
push:
* Make sure you are not reintroducing a "use" statement that has been
removed
* "$subroutine" is not exported by the C4::$MODULE module
means that you need to add the subroutine to the @EXPORT_OK list
* Bareword "$subroutine" not allowed while "strict subs"
means that you didn't imported the subroutine from the module:
- use $MODULE qw( $subroutine list );
You can also use the fully qualified namespace: C4::$MODULE::$subroutine
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds handling for the newly introduced 'errors' option in
GetPlugins and reports erroroneos plugins to the user.
To test:
1 - Enable plugins in the koha-conf
2 - Install the kitchen sink plugin
3 - Your staff client should be orange now :-)
4 - The plugin should display as installed in the table at
tools/plugins.
5 - edit the plugin module
/var/lib/koha/kohadev/plugins/Koha/Plugin/Com/ByWaterSolutions/KitchenSink.pm
6 - Add a line to break compilation, like:
this won't compile
7 - Restart all
8 - Your Koha is not broken, but is no longer orange (The plugin is not
loading).
9 - The plugin should display as unable to load in the table at
tools/plugins.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1 - Enable plugins in the koha-conf
2 - Install the kitchen sink plugin
3 - Your staff client should be orange now :-)
4 - edit the plugin module
/var/lib/koha/kohadev/plugins/Koha/Plugin/Com/ByWaterSolutions/KitchenSink.pm
5 - Add a line to break compilation, like:
this won't compile
6 - Restart all
7 - Your koha is now broken
8 - kshell
9 - perl misc/devel/install_plugins.pl
10 - Restart all
11 - Koha remains broken
12 - Apply patch
13 - kshell
14 - perl misc/devel/install_plugins.pl
15 - Koha now works!
16 - Koha is not orange because the plugin methods are removed
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Plugin dirs defined in koha-conf.xml are added to @INC in order to compile perl code.
Looks like with plack those dirs are added several times.
This may lead to an error "INCLUDE_PATH exceeds 64 directories".
This bug was identified with Carrousel plugin : https://inlibro.com/instructions-carrousel/
Test plan :
1) Enable plack and plugins
2) Look at page about.pl : @INC contains one plugin dir 'var/lib/plugins'
3) Install plugin KitchenSink : https://github.com/bywatersolutions/koha-plugin-kitchen-sink
4) Dont apply patch
5) Use configure on KitchenSink
6) Look at page about.pl : @INC contains server plugin dir 'var/lib/plugins'
7) Apply patch and restart plack
8) Use configure on KitchenSink
9) Look at page about.pl : @INC contains one plugin dir 'var/lib/plugins'
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It must return an empty array in case the enable_plugins config flag is
disabled
Test plan:
Turn the config off in koha-conf
Start a search at the OPAC
Without this patch you got:
Can't use string ("0") as a HASH ref while "strict refs" in use at /home/vagrant/kohaclone/opac/opac-search.pl line 661
With this patch applied you see the search result
Followed test plan - works as described.
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
- Check that the plugin has the method before calling it
- Call the method in an eval block to prevent fatal errors
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
UseKohaPlugins has been removed by bug 20415
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It is called after a hold has been placed
Test plan:
1. Write a plugin that implements only after_hold_create (see
`perldoc Koha::Plugins` for implementation details). Install it and
enable it
2. Place a hold and verify that your plugin method has been called with
the right parameters
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Pasi Kallinen <pasi.kallinen@koha-suomi.fi>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch simplifies the logic inside GetPlugins so:
- It uses Koha::Plugins::Methods instead of plain SQL
- It doesn't do more DB calls than needed, by filtering on method in the
initial query to Koha::Plugins::Methods.
It also relies on the (newly introduced) ->is_enabled method in
Koha::Plugins::Base, for better readability.
To test:
- Run the tests and notice no behaviour changes are introduced.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch restores filtering the plugins by metadata. That got lost on
rebase at some point. Regression tests are added on a prior patch.
To test:
- Have the 'regression tests for GetPlugins' patch applied
- Run:
$ kshell
k$ prove t/db_dependent/Plugins.t
=> FAIL: Tests fail!
- Apply this patch
- Run:
k$ prove t/db_dependent/Plugins.t
=> SUCCESS: Tests pass!
- Sign off :-D
Signed-off-by: Agustin Moyano <agustinmoyano@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Agustin Moyano <agustinmoyano@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Right now, to check if a plugin is functional and what methods it exposes we load the module and test for a given method at run time. This is highly inefficient. It makes far more sense to do this at install time and store the data in the db. I believe we should store a table of methods that each plugin exposes and check that instead. Then, at install time we can test that a) the plugin can be loaded and b) add the available methods to the plugin_methods table.
Test Plan:
1) Apply this patch
2) Restart all the things
3) Run updatedatabase.pl
4) Verify you can use existing plugins
5) Verify you can install new plugins
Signed-off-by: Agustin Moyano <agustinmoyano@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test plan:
- apply this patch(es),
- launch an updatedabase,
- go to plugins/plugins-home.pl
and deal with enable/disable method
- install a plugin like KitchenSink
https://github.com/bywatersolutions/koha-plugin-kitchen-sink
- once installed, the plugin change the background color
of the staff client to orange.
- disable the plugin,
- background color should be set back to the original one
Rebased-on: 2019-03-25 Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Claire Gravely <claire.gravely@bsz-bw.de>
Signed-off-by: Agustin Moyano <agustinmoyano@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Under plack, can_load should not check if a package is in cache, but
reload it. Otherwise plugins that have been uninstalled will still get
listed.
The error raised by can_load must only be displayed if the plugin has
been removed.
Test plan:
1/ Upload a plugin
2/ Note the plugin is listed as installed
3/ Modify the package of the plugin to add a compilation error (use
'Foo' for instance)
4/ Reload the page
5/ The plugin is not listed and a warning appear in the logs
6/ Remove the compilation error and uninstall the plugin
7/ The plugin is no longer listed and no warning appear in the logs
Signed-off-by: Lee Jamison <ldjamison@marywood.edu>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Bug 19081: Remove useless $plugin_file variable
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Martin Renvoize
Nick Clemens
Kyle M Hall
Jonathan Druart
Jacob O'Mara
Tomas Cohen Arazi
Hammat Wele
Pedro Amorim
Emily-Rose Francoeur
Koha Development Team
Martin Renvoize
Marcel de Rooy
Julian Maurice
Fridolin Somers
Agustin Moyano
Alex Arnaud