Update from v4.5.x to v4.6¶
This update procedure applies if you are using a v4.5 installation.
Update from v4.5.x to v4.5.latest¶
Before you update to v4.6, you need to go through the following steps to update to the latest maintenance release of v4.5 (v4.5.7).
Note which version you actually have before starting.
Update the application to v4.5.latest¶
Run:
1 |
|
1 |
|
1 |
|
v4.5.2¶
Database update¶
Run the following scripts:
1 |
|
1 |
|
v4.5.3¶
Database update ¶
Run the following scripts:
1 |
|
1 |
|
v4.5.4¶
Database update¶
Run the following scripts:
1 |
|
1 |
|
Update from v4.5.latest to v4.6¶
When you have the latest version of v4.5, you can update to v4.6. Check the requirements first. This version adds support for PHP 8.2 and 8.3, but requires using at least Node 18.
Update the application¶
First, run:
1 2 3 4 5 6 7 |
|
1 2 3 4 |
|
1 2 3 4 |
|
The recipes:install
command installs new YAML configuration files.
Review the old YAML files and move your custom configuration to the relevant new files.
Remove node_modules
and yarn.lock
¶
Next, remove node_modules
and yarn.lock
before running composer run post-update-cmd
,
otherwise you can encounter errors during compiling.
1 2 |
|
Finish code update¶
Finish the code update by running:
1 |
|
Known issues¶
You may encounter one of the following errors during the process.
Non-existent parameter¶
If you encounter a You have requested a non-existent parameter
error
(like, for example, You have requested a non-existent parameter "ibexa.dashboard.ibexa_news.limit".
),
this is due to incorrect order of entries in config/bundles.php
.
To fix this, use the order from the skeleton you're using, and add any extra bundles again.
Use https://github.com/ibexa/headless-skeleton/blob/v4.6.11/config/bundles.php as a reference.
Use https://github.com/ibexa/experience-skeleton/blob/v4.6.11/config/bundles.php as a reference.
Use https://github.com/ibexa/commerce-skeleton/blob/v4.6.11/config/bundles.php as a reference.
Non-existent service¶
If you encounter the You have requested a non-existent service "payum.storage.doctrine.orm".
error,
replace the config/packages/payum.yaml file with the contents from https://github.com/ibexa/recipes-dev/blob/master/ibexa/commerce/4.6/config/packages/payum.yaml.
Update the database¶
Next, update the database:
Caution
Always back up your data before running any database update scripts.
After updating the database, clear the cache.
Do not use --force
argument for mysql
/ psql
commands when performing update queries.
If there is any problem during the update, it is best if the query fails immediately, so you can fix the underlying problem before you execute the update again.
If you leave this for later you risk ending up with an incompatible database, though the problems might not surface immediately.
Apply the following database update scripts:
1 |
|
1 |
|
Update Ibexa Commerce database ¶
For Ibexa Commerce installations, you also need to run the following command line:
1 |
|
1 |
|
And apply the following database script:
1 2 3 4 5 6 7 8 |
|
1 2 3 4 5 6 7 8 9 10 |
|
Run data migration¶
Image picker migration¶
The new Image picker by default expects an ezkeyword
Field Type to exist in the image
content type.
You can add it running the following commands:
1 2 |
|
Dashboard migration ¶
If you are using Ibexa Experience or Ibexa Commerce, you must run data migration required by the dashboard and other features to finish the upgrade process:
1 2 3 4 5 6 |
|
Caution
The 2023_10_10_16_14_dashboard_permissions.yaml
migration creates a Role dedicated for dashboard management and assigns it to the Editors User Group. If you have custom User Groups which need to manipulate dashboards, you need to skip this migration, copy it to your migrations folder (by default, src/Migrations/Ibexa/migrations
) and adjust it according to your needs before execution.
For Ibexa Commerce there's an additional migration:
1 2 |
|
Ibexa Open Source¶
If you don't have access to Ibexa DXP's ibexa/installer
package and cannot apply the scripts from vendor/ibexa/installer
directory, apply the following database update instead:
1 2 |
|
1 2 |
|
Revisit configuration¶
Revisit mandatory configuration¶
Dashboard configuration ¶
Define "Dashboards" location as contextual tree root:
1 2 3 4 5 6 7 8 |
|
User profile¶
Ibexa DXP v4.6 introduced user profile for Backoffice users, allowing users to upload avatars, and provide personal information.
This feature is optional, and you can disable it by setting enabled
flag to false
in ibexa.system.<scope>.user_profile
configuration:
1 2 3 4 5 6 7 |
|
To enable the user profile, you must specify content type identifiers which represent the "editor" user, and field groups to be rendered in the user profile summary:
1 2 3 4 5 6 7 8 9 |
|
You can use your own content type that represents the Back Office user, or use the default one provided by Ibexa DXP:
1 2 3 |
|
Site context¶
Site context is used in Content Tree to display only those content items that belong to the selected website.
You can add locations that shoudn't be publicly accessible to the list of excluded paths:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
Revisit optional configuration¶
Activity log ¶
By default, activity log keeps entries for 30 days.
You can change this value by setting ibexa.repositories.<name>.activity_log.truncate_after_days
parameter:
1 2 3 4 5 6 |
|
Revisit permissions¶
Recent activity ¶
You must add the "Activity Log / Read" policy (activity_log/read
) to every role that has access to the Back Office, at least with the "Only own log" limitation.
This policy is mandatory to display the "Recent activity" block in dashboards, and the "Recent activity" block in user profiles.
The following migration example allows users with the Editor
role to access their own activity log:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
Update Solr configuration¶
Solr configuration changes with the addition of spellchecking feature.
Configure the spellcheck
component in solrconfig.xml
:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
Add this spellcheck
component to the /select
request handler:
1 2 3 4 5 6 |
|
Note
You can generate new Solr configuration files using generate-solr-config.sh
,
and merge spellcheck
configuration by comparing new files with your existing setup.
Restart Solr for solrconfig.xml
changes to take effect.
Update Elasticsearch schema¶
Elasticsearch schema's templates change, for example, with the addition of new features such as spellchecking. When this happens, you need to erase the index, update the schema, and rebuild the index.
To delete the index, you can use an HTTP request. Use the command as in the following example:
1 |
|
To update the schema, and then reindex the content, use the following commands:
1 2 |
|
v4.6.2¶
Database update¶
Run the following scripts:
1 |
|
1 |
|
v4.6.3¶
Notification config update¶
The configuration of the package ibexa/notifications
has changed.
This package is required by other packages, such as ibexa/connector-actito
for Transactional emails, ibexa/payment
, or ibexa/user
.
If you are customizing the configuration of the ibexa/notifications
package, and using SiteAccess aware configuration to change the Notification
subscriptions, you have to manually change your configuration by using the new node name notifier
instead of the old notifications
.
For example, the following v4.6.2 config:
1 2 3 4 5 6 7 8 |
|
becomes the following from v4.6.3:
1 2 3 4 5 6 7 8 |
|
v4.6.4¶
Database update¶
Run the following scripts:
1 |
|
1 |
|
v4.6.8¶
To avoid deprecations when updating from an older PHP version to PHP 8.2 or 8.3, run the following commands:
1 2 |
|
v4.6.9¶
No additional steps needed.
v4.6.10¶
A command to deal with duplicated database entries, as reported in IBX-8562, will be available soon.
v4.6.11¶
Ibexa Cloud¶
Update Platform.sh configuration for PHP and Varnish.
Generate new configuration with the following command:
1 |
|
Review the changes applied to .platform.app.yaml
and .platform/
,
merge with your custom settings if needed, and commit them to Git.