Repository files navigation

This repository is what we call a "subtree split": a read-only copy of one directory of the main repository.It is used by Composer to allow developers to depend on specific bundles.

If you want to report or contribute, you should instead open your issue on the main repository:https://github.com/Novactive/Nova-eZPlatform-Bundles

Documentation is available in this repository via.md files but also packaged here:https://novactive.github.io/Nova-eZPlatform-Bundles/master/Accelerator/README.md.html

Accelerate your Ibexa DXP (eZ Platform)

This bundles helps and aims to accelerate:

• the overhall performances
• your developments
• productivity of your marketing/content creation teams
• your business

eZ Accelerator leverages Symfony Messenger and adds asynchronoucity to eZ Platform allowing many thingswith NO OVERHEAD and quite the opposite accelerating native actions.

For now, eZ Accelerator allows you to:

• catch and dispatch asynchronouslyany Events. (Careful though not all can be handle asynchronously)
• handle HTTP Cache Purge asynchronously
• handle Search Indexation asynchronously

Bonus! You can inject Middleware into the game!

First you need to understand theSymony Messenger Component.

eZ Accelerator decorates the eZ Platform purger to dispatch the corresponding messages.To enable the asynchronicity, you just need to know the Message FQDN

• Tag Purge: Novactive\Bundle\eZAccelerator\Message\PurgeHttpCacheTags
• Purge All: Novactive\Bundle\eZAccelerator\Message\PurgeAllHttpCache

that's it! See the config example below

eZ Accelerator decorates the eZ Platform Search Handler to dispatch the corresponding messages.To enable the asynchronicity, you just need to know the Message FQDN

• Index Content: Novactive\Bundle\eZAccelerator\Message\Search\IndexContent
• Index Location: Novactive\Bundle\eZAccelerator\Message\Search\IndexLocation
• Remove Content: Novactive\Bundle\eZAccelerator\Message\Search\UnindexContent
• Remove Location: Novactive\Bundle\eZAccelerator\Message\Search\UnindexLocation
• Purge All: Novactive\Bundle\eZAccelerator\Message\Search\PurgeIndex

that's it! See the config example below

The concept is simple, everytime eZ Platform is doing something an event is triggered. eZ Accelerator gives you theopportunity to handle the event through a bus which gives you the opportunity to handle that event via a messagesynchronously or asynchronicity using the transport of your choice.

Everything is opt-in, you can still use the default event dispatcher or you can switch to the bus approach.

nova_ezaccelerator:system:default:# default_bus: a.default.bus.for.this.siteaccess.configevent_to_message:eZ\Publish\API\Repository\Events\Bookmark\CreateBookmarkEvent:message:Novactive\Bundle\eZAccelerator\Message\VoidEventMessage# should be your own# stop_propagation: false # default# bus: a.specific.bus.for.this.siteaccess.config.and.that.event

You can decide to stop the event propagation as well if it makes sense.

framework:messenger:buses:my.bus:# could be anything and you can have manymiddleware:                    -Novactive\Bundle\eZAccelerator\Core\SiteAccessAwareMiddlewaretransports:ezaccelerator:'doctrine://default?queue_name=nova_ezaccelerator'# you decide the name does not matterrouting:Novactive\Bundle\eZAccelerator\Message\VoidEventMessage:ezacceleratorNovactive\Bundle\eZAccelerator\Message\HTTPCache\PurgeAllHttpCache:ezacceleratorNovactive\Bundle\eZAccelerator\Message\HTTPCache\PurgeHttpCacheTags:ezacceleratorNovactive\Bundle\eZAccelerator\Message\Search\IndexContent:ezacceleratorNovactive\Bundle\eZAccelerator\Message\Search\IndexLocation:ezacceleratorNovactive\Bundle\eZAccelerator\Message\Search\UnindexContent:ezacceleratorNovactive\Bundle\eZAccelerator\Message\Search\UnindexLocation:ezacceleratorNovactive\Bundle\eZAccelerator\Message\Search\PurgeIndex:ezaccelerator

With this configuration you can handleasynchronously whatever you want when you want.

Again, careful when all the AfterEvent can probably all be handle asynchronously the main work has to be synchronousfor most of the case. (Ex: Content Creation, etc.)

When running the consumers, you will probably run them via1 siteaccess (default maybe).

Thing is you might want to know the original SiteAccess. That's why eZ Accelerator injects theSiteAccessAwareMiddlewarewhich tags the Message with the Orginal SiteAccess.

Nevertheless, and even more importantly, in your handler you need to handle according to the correct configuration.

Let's imagine a situation where you have 2 siteaccess:

• A: where the Varnish server isV.IP.A and databaseDB.A (default)
• B: where the Varnish server isV.IP.B and databaseDB.B

When you run your consumer, it will usedefault siteaccess which is setup for Varnish hostV.IP.AA message from the siteaccessB is dispatched, it will be handle by the only consumer you ran connected in-memory to siteaccessATherefore in this situationV.IP.B won't never be purged.

To handle those situations you can run and setup different consumers and transports and play with eZ Accelerator / Messsenger config.

Ex:

• All defaultconfig bin/console messenger:consume
• SiteAccessAbin/console messenger:consume --siteaccess=A

But you can also specify thebus and thereceiver

• bin/console messenger:consume ezaccelerator --siteaccess=A --bus=something

Implemented

Installation

Changelog