Download the PHP package asioso/pimcore-doofinder without Composer

DooFinder Bundle

Prerequisites

• PHP 7.1 or higher (https://secure.php.net/)
• Composer (https://getcomposer.org/download/)
• A Pimcore Installation (Symfony 3.4)
• A doofinder account

Installation

composer

just run:

Extension manager

just enable and install the Bundle in the pimcore extension manager.

Configuration

what's absolutely necessary to be added to your config.yml file:

Define your Engine Configurations

Take a look here for a deeper insights on the internal workings of this bundle, but in short: doofinder let's you define multiple search engines for your account. Each of these engines might have several types (so to say indices) for content. Each type's content might greatly differ in structure and content, however they all must share the same language-property (also currency!) from their parent engine.

So why does this matter?

For example you want to put your webshop's products from pimcore to doofinder. Let's say you have active localization for German (DE) und English (EN) and Prices in Euro(€) and Pound(£). That would mean you would still have to create two search engines in doofinder, one for each language respectively.

So you will have add the following configurations (simplified)

Given the case you would like to offer both currencies in both languages, you will need four engines!

Keep this in mind, but apparently that's how doofinder is designed.

Note before you continue reading, I'm aware that there is some potential in mixing up terminology, because of the following:

• in doofinder:
  • an engine is just a search engine with any number of types (indices) attached.
• in this bundle:
  • an engine refers to exactly one engine and one type.

This is due to design and let's us determine an engine and type specific representation per Object. This is important, you can read more on this in the internals.

Some Example Configuration

Below you can see a configuration we have been using for a project. We are using 3 types for one search engine. So each bundle-engine here uses the same but references different types.

• products with type: test_products
• products_special with type: test_products_special
• content with type: test_content

way more interesting are the engine's item definitions. class defines the object's classname it's "listening" to, the field set defines the feed representation.

• dfAttribute: is the attribute's name obviously (this will end up in feeds header line)
• classAttribute: either:
  • 'self' with combination of a merger
  • the attributes Name. e.g 'description' - we are using PathProperty and Reflection to retrieve the value
• merger: originally designed to merge arrays, but can be used to do other things as well. just use it as a callback where you can control the output. see here for more details
• locale: very useful if the classAttribute is a localized field
• getter: if classAttribute itself is another object, then getter will be executed.

This settings and behavior came up during development, so there is still potential to do this better and more user friendly. Configuration can be quite redundant right now for example.

What's next?

After defining your configuration, to generate your datafeed you will need to define a pimcore/symfony command to do the heavy lifting for you.

If you are familiar with Pimcore you will know that you have multiple possibilities to query for objects

• use Listings via the API
• write your own SQL query
• using an Index

You can find a implementation of such a command here, which uses both default object listings and AdvancedMysql Index Service and runs with efficient ressource management in mind.

More Details

• Feeding DooFinder
• Internals
• Examples

TODO

• explain active and objectPathRegex configuration