In the previous article, we got acquainted with the capabilities of the Joomla smart search component, talked about the parameters and configuration of scheduled indexing using CRON. Let's start creating the code for our own plugin.
Before starting the technical part, I will mention some articles that directly address the main topic. As well as articles that generally cover the creation and/or updating of a plugin for the modern architecture of Joomla 4 / Joomla 5. Next, I will assume that the reader has read them and generally has an idea of how to make a working plugin for Joomla:
For experienced developers, I will say that the search plugin extends the JoomlaComponentFinderAdministratorIndexerAdapter class, the class file is located in administrator/components/com_finder/src/Indexer/Adapter.php. Well, then they will figure it out for themselves. Also, as a sample, you can study the Joomla core smart search plugins - for articles, categories, contacts, tags, etc. - in the plugins/finder folder. I worked on a smart search plugin for JoomShopping (Joomla e-commerce component) and SW JProjects (your own Joomla extensions directory component with update server) components, so the class names and some nuances will be associated with them. I will show most of it using the example of JoomShopping. The solution to the issue of multilingualism is based on the example of SW JProjects.
The file structure of the smart search plugin for Joomshopping does not differ from the typical one:
Joomla 5 smart searh plugin file structure
The file provider.php allows you to register a plugin in a Joomla DI container and allows you to access plugin methods from the outside using MVCFactory.
<?php /** * @package Joomla.Plugin * @subpackage Finder.Wtjoomshoppingfinder * * @copyright (C) 2023 Open Source Matters, Inc. <https://www.joomla.org> * @license GNU General Public License version 2 or later; see LICENSE.txt */ \defined('_JEXEC') or die; use Joomla\CMS\Extension\PluginInterface; use Joomla\CMS\Factory; use Joomla\CMS\Plugin\PluginHelper; use Joomla\Database\DatabaseInterface; use Joomla\DI\Container; use Joomla\DI\ServiceProviderInterface; use Joomla\Event\DispatcherInterface; use Joomla\Plugin\Finder\Wtjoomshoppingfinder\Extension\Wtjoomshoppingfinder; return new class () implements ServiceProviderInterface { /** * Registers the service provider with a DI container. * * @param Container $container The DI container. * * @return void * * @since 4.3.0 */ public function register(Container $container) { $container->set( PluginInterface::class, function (Container $container) { $plugin = new Wtjoomshoppingfinder( $container->get(DispatcherInterface::class), (array) PluginHelper::getPlugin('finder', 'wtjoomshoppingfinder') ); $plugin->setApplication(Factory::getApplication()); // Our plugin uses DatabaseTrait, so the setDatabase() method appeared // If it is not present, then we use only setApplication(). $plugin->setDatabase($container->get(DatabaseInterface::class)); return $plugin; } ); } };
This is the file that contains the main working code of your plugin. It should be located in the src/Extension folder. In my case, the plugin class JoomlaPluginFinderWtjoomshoppingfinderExtensionWtjoomshoppingfinder is in the file plugins/finder/wtjoomshoppingfinder/src/Extension/Wtjoomshoppingfinder.php. The namespace of the plugin is JoomlaPluginFinderWtjoomshoppingfinderExtension.
There is a minimal set of class properties and methods required for operation (they are accessed, including by the parent Adapter class).
<?php /** * @package Joomla.Plugin * @subpackage Finder.Wtjoomshoppingfinder * * @copyright (C) 2023 Open Source Matters, Inc. <https://www.joomla.org> * @license GNU General Public License version 2 or later; see LICENSE.txt */ \defined('_JEXEC') or die; use Joomla\CMS\Extension\PluginInterface; use Joomla\CMS\Factory; use Joomla\CMS\Plugin\PluginHelper; use Joomla\Database\DatabaseInterface; use Joomla\DI\Container; use Joomla\DI\ServiceProviderInterface; use Joomla\Event\DispatcherInterface; use Joomla\Plugin\Finder\Wtjoomshoppingfinder\Extension\Wtjoomshoppingfinder; return new class () implements ServiceProviderInterface { /** * Registers the service provider with a DI container. * * @param Container $container The DI container. * * @return void * * @since 4.3.0 */ public function register(Container $container) { $container->set( PluginInterface::class, function (Container $container) { $plugin = new Wtjoomshoppingfinder( $container->get(DispatcherInterface::class), (array) PluginHelper::getPlugin('finder', 'wtjoomshoppingfinder') ); $plugin->setApplication(Factory::getApplication()); // Our plugin uses DatabaseTrait, so the setDatabase() method appeared // If it is not present, then we use only setApplication(). $plugin->setDatabase($container->get(DatabaseInterface::class)); return $plugin; } ); } };
... and here we start to dive into the details, since the getListQuery() method is not really mandatory, despite the fact that both the documentation and most articles talk about it.
Any picture on the topic of "complex scheme" will do here.
It's amazing how many times some information or idea sometimes passes by us in a circle before we notice and realize it! Many things, being in front of our eyes for more than one year, still do not reach awareness, and our attention focuses on them only after years of experience.
In connection with Joomla, for some reason, the vision does not immediately come that its components assume some kind of common architecture characteristic of Joomla (although this is an obvious fact). Including at the level of the database table structure. Let's look at some fields of the Joomla content table. I will make a reservation that specific column names are not so important to us (you can always query SELECT name AS title), how much is the data structure for one indexed element:
If we compare the tables #__content (Joomla articles), #__contact_details (contact component), #__tags (Joomla tags), #__categories (Joomla category component), then we will find almost all the listed data types everywhere.
If the component for which smart search plugins are created followed the "Joomla way" and inherits its architecture, then you can do with a minimum of methods in the plugin class. If the developers decide not to look for easy ways and go their own way, then you will have to go the hard way, redefining almost all the methods of the Adapter class.
This method is called in 3 cases:
Let's look at an example of implementation in Joomla core plugins:
<?php /** * @package Joomla.Plugin * @subpackage Finder.Wtjoomshoppingfinder * * @copyright (C) 2023 Open Source Matters, Inc. <https://www.joomla.org> * @license GNU General Public License version 2 or later; see LICENSE.txt */ \defined('_JEXEC') or die; use Joomla\CMS\Extension\PluginInterface; use Joomla\CMS\Factory; use Joomla\CMS\Plugin\PluginHelper; use Joomla\Database\DatabaseInterface; use Joomla\DI\Container; use Joomla\DI\ServiceProviderInterface; use Joomla\Event\DispatcherInterface; use Joomla\Plugin\Finder\Wtjoomshoppingfinder\Extension\Wtjoomshoppingfinder; return new class () implements ServiceProviderInterface { /** * Registers the service provider with a DI container. * * @param Container $container The DI container. * * @return void * * @since 4.3.0 */ public function register(Container $container) { $container->set( PluginInterface::class, function (Container $container) { $plugin = new Wtjoomshoppingfinder( $container->get(DispatcherInterface::class), (array) PluginHelper::getPlugin('finder', 'wtjoomshoppingfinder') ); $plugin->setApplication(Factory::getApplication()); // Our plugin uses DatabaseTrait, so the setDatabase() method appeared // If it is not present, then we use only setApplication(). $plugin->setDatabase($container->get(DatabaseInterface::class)); return $plugin; } ); } };
The getListQuery() method returns a DatabaseQuery object, an object of the query constructor, where the name of the table and fields for selection are already specified. Work with it continues in the methods that call it.
If getListQuery() is called from getContentCount() in the DatabaseQuery $query object, the set values for select are replaced with COUNT(*).
If getListQuery() is called from getItem($id), the condition $query->where('a.id = ' . (int) $id) and only a specific element is selected. And already here we see that the parent Adapter class contains the table name in the query as a.*. This means that we should also use these prefixes in our implementation of the getListQuery() method.
In the case of calling getListQuery() from getItems(), $offset and $limit are added to the query that we have constructed in order to move through the list of elements for indexing.
Summary: getListQuery() - must contain a "work piece" for three different SQL queries. And there is nothing particularly difficult about implementing Joomla here. But, if necessary, you can implement 3 methods yourself without creating getListQuery().
Non Joomla way: In the case of JoomShopping, I came across the fact that a product can have several categories and historically the category id (catid) component for the product was stored in a separate table. At the same time, for many years it was not possible to specify the main category for the product. Upon receipt of the product category, a query was sent to the table with categories, where just the first query result was taken, sorted by default category id - i.e. ascending. If we changed categories when editing a product, then the main product category was the one with the lower id number. The URL of the product was based on it and the product could jump from one category to another.
But, almost 2 years ago, this JoomShopping behavior was fixed. Since the component has a long history, a large audience and cannot just break backward compatibility, the fix was made optional. The ability to specify the main category for the product must be enabled in the component settings. Then the main_category_id will be filled in the table with the products.
But this functionality is disabled by default. And in the smart search plugin, we need to get the parameters of the JoomShopping component, see if the option to specify the main product category is enabled (and it may be enabled recently and the main category for some products is not specified - also a nuance...) and generate an SQL query to receive the product(s) based on the component parameters: either a simple query where we add the main_category_id field, or a JOIN request to get the category id in the old wrong way.
Immediately, the nuance of multilingualism comes to the fore in this request. According to the Joomla way, a separate element is created for each language of the site and associations are set up between them. So, for the Russian language - one article. The same article in English is being created separately. Then we connect them with each other using language associations and when switching the language on the Joomla frontend, we will be redirected from one article to another.
This is not how it is done in JoomShopping: data for all languages is stored in the same table with products (Ok). Adding data for other languages is done by adding columns with the suffix of these languages (hmm...). That is, we do not have just a title or name field in the database. But there are fields name_ru-RU, name_en-GB, etc.
Joomla JoomShopping product table structure fragment
At the same time, we need to design a universal SQL query so that it can be indexed from both the admin panel and the CLI. At the same time, choosing the indexing language when launching the CLI using CRON is also a task. I admit, at the time of writing this article, I have postponed a full-fledged solution to this problem for the time being. The language is selected using our own getLangTag() method, where we either take the main language from the JoomShopping parameters, or the default language of the site. That is, so far this solution is only for a monolingual site. The search in different languages will not work yet.
However, 3 months later I solved this problem, but already in the smart search plugin for SW JProjects component. I will tell you about the solution further.
In the meantime, let's look at what happened for JoomShopping
<?php /** * @package Joomla.Plugin * @subpackage Finder.Wtjoomshoppingfinder * * @copyright (C) 2023 Open Source Matters, Inc. <https://www.joomla.org> * @license GNU General Public License version 2 or later; see LICENSE.txt */ \defined('_JEXEC') or die; use Joomla\CMS\Extension\PluginInterface; use Joomla\CMS\Factory; use Joomla\CMS\Plugin\PluginHelper; use Joomla\Database\DatabaseInterface; use Joomla\DI\Container; use Joomla\DI\ServiceProviderInterface; use Joomla\Event\DispatcherInterface; use Joomla\Plugin\Finder\Wtjoomshoppingfinder\Extension\Wtjoomshoppingfinder; return new class () implements ServiceProviderInterface { /** * Registers the service provider with a DI container. * * @param Container $container The DI container. * * @return void * * @since 4.3.0 */ public function register(Container $container) { $container->set( PluginInterface::class, function (Container $container) { $plugin = new Wtjoomshoppingfinder( $container->get(DispatcherInterface::class), (array) PluginHelper::getPlugin('finder', 'wtjoomshoppingfinder') ); $plugin->setApplication(Factory::getApplication()); // Our plugin uses DatabaseTrait, so the setDatabase() method appeared // If it is not present, then we use only setApplication(). $plugin->setDatabase($container->get(DatabaseInterface::class)); return $plugin; } ); } };
We created a method to query the database from Joomla and learned a lot about how the smart search plugin works.
In the next article, we will create a method for indexing content and complete the creation of plugin. We will also get acquainted with how indexed items are stored in the database and understand why this is important and solve the problem of indexing content for multilingual components with a non-standard implementation of multilingualism.
The above is the detailed content of The anatomy of smart search in Joomla art Creating a plugin I.. For more information, please follow other related articles on the PHP Chinese website!