|
1 |
| -# How to use the content type upgrade library |
| 1 | +# How to upgrade content types |
2 | 2 |
|
3 | 3 | Before version 1.3, changes to a content-type configuration could (and usually would) break the existing content that was saved with the previous configuration. Why? Because a content type's configuration maps data from its source (the master format) to its display templates. So when the configuration mapping changes, the display of existing content might also change. With significant configuration changes, data (such as styles, attributes, and html) is lost. Such changes cause existing content to appear incorrectly, or not at all.
|
4 | 4 |
|
5 | 5 | To fix this limitation for versions 1.3+, Page Builder uses Magento's native upgrade mechanism, coupled with our content upgrade helpers. These helpers convert existing content so that it maps to new configurations and displays correctly.
|
6 | 6 |
|
7 |
| -## Example usage for Row |
| 7 | +## Example: Updating the Row content type |
8 | 8 |
|
9 |
| -The Page Builder team recently had to change the configuration of the Row's full-width appearance to fix a layout issue. The fix was simple. We moved a style attribute from one element in the Row's full-width appearance to another element. But without the upgrade helpers, our change to the Row's configuration would have broken all previously saved Page Builder content with Rows. And because all Page Builder content starts with a Row, all Page Builder content would be broken! |
| 9 | +Let's imagine that the Page Builder team needs to change the configuration of the Row's full-width appearance to fix a layout issue. The fix is simple. We need to move a style attribute from one element in the Row's full-width appearance to another element. But without the upgrade helpers, our change to the Row's configuration would break all previously saved Page Builder content that uses Rows. And because all Page Builder content is wrapped in a Row, changing the Row would break all Page Builder content! |
10 | 10 |
|
11 |
| -To fix this issue, we used the Page Builder DOM helper classes (`Magento\PageBuilder\Model\Dom\*`) to create a converter and a data patch for the native Row content type: |
| 11 | +To fix this issue, we created a set of Page Builder DOM helper classes (`Magento\PageBuilder\Model\Dom\*`) that we can use to update all our native content types (including the Row) that have already been stored in the database. |
12 | 12 |
|
13 |
| -1. **Converter** (See `FixFullWidthRowPadding.php`) |
14 |
| -2. **Data Patch** (See `UpgradeFullWidthPadding.php`) |
| 13 | +## Steps overview |
| 14 | +There are three steps to upgrading a content type when changing its configuration: |
15 | 15 |
|
16 |
| -  |
| 16 | +1. Create a Converter (Example: `FixFullWidthRowPadding.php`) |
| 17 | +2. Create a Data Patch (Example: `UpgradeFullWidthPadding.php`) |
| 18 | +3. Update the UpgradableEntitiesPool (for custom entities)(`Magento\PageBuilder\Model\UpgradableEntitiesPool`) |
17 | 19 |
|
18 |
| -### Converter class example |
| 20 | +For our Row example, the Page Builder team would add the following files to the `Magento/PageBuilder/Setup` directories: |
19 | 21 |
|
20 |
| -The converter class implements the `DataConverterInterface`. Specifically, it implements the `convert` function where it uses Page Builder's DOM helper classes to change the DOM of the Row content type within each master format it receives. |
| 22 | + |
21 | 23 |
|
22 |
| -Page Builder's `FixFullWidthRowPadding` converter class is provided here as an example implementation: |
| 24 | +### Step 1: Create a Converter |
| 25 | + |
| 26 | +For our Row example, the first task is to create a converter class that implements the `DataConverterInterface`. Specifically, it implements the `convert` function where it uses Page Builder's DOM helper classes to change the DOM of the Row content type within each master format it receives. |
| 27 | + |
| 28 | +Our converter class for fixing a row padding problem might be called `FixFullWidthRowPadding`, with the following example implementation: |
23 | 29 |
|
24 | 30 | ```php
|
25 | 31 | <?php
|
@@ -82,11 +88,11 @@ class FixFullWidthRowPadding implements DataConverterInterface
|
82 | 88 | }
|
83 | 89 | ```
|
84 | 90 |
|
85 |
| -### Data patch class example |
| 91 | +### Step 2: Create a Data Patch |
86 | 92 |
|
87 |
| -The data patch class implements the `DataPatchInterface`. Specifically, it uses the Page Builder `UpgradeContentHelper` class to apply the converter class to all the database entities where Page Builder content exists. These locations are provided by the `UpgradableEntitiesPool`, described later in this topic. |
| 93 | +Our second task for updating our example Row content type is to create a Data Patch class that implements the `DataPatchInterface`. Specifically, we need to use the Page Builder `UpgradeContentHelper` class to apply the converter class to all the database entities where Page Builder content exists. These locations are provided by the `UpgradableEntitiesPool`, described later in this topic. |
88 | 94 |
|
89 |
| -Page Builder's `UpgradeFullWidthPadding` class is provided here as an example implementation: |
| 95 | +For our Data Patch, we'll create a class called `UpgradeFullWidthPadding`, which fixes our row padding problem with the following example implementation: |
90 | 96 |
|
91 | 97 | ```php
|
92 | 98 | <?php
|
@@ -151,9 +157,40 @@ class UpgradeFullWidthPadding implements DataPatchInterface
|
151 | 157 | }
|
152 | 158 | ```
|
153 | 159 |
|
154 |
| -## UpgradableEntitiesPool |
| 160 | +### Step 3: Update the UpgradableEntitiesPool (for custom entities) |
| 161 | + |
| 162 | +The `Magento\PageBuilder\Model\UpgradableEntitiesPool` provides the locations in the database where Page Builder content exists by default. These entities include: |
| 163 | + |
| 164 | +- `cms_block` |
| 165 | +- `cms_page` |
| 166 | +- `catalog_category_entity_text` |
| 167 | +- `catalog_product_entity_text` |
| 168 | +- `pagebuilder_template` |
| 169 | + |
| 170 | +If your Magento installation does not have any additional entities for Page Builder content (beyond the defaults), you do not need to update the `UpgradableEntitiesPool`. |
155 | 171 |
|
156 |
| -The `UpgradableEntitiesPool` provides the locations in the database where Page Builder content exists. By default, these entities include: `cms_block`, `cms_page`, `catalog_category_entity_text`, `catalog_product_entity_text`, and `pagebuilder_template`. Page Builder defines these entities in `Magento/PageBuilder/etc/di.xml`, as shown here: |
| 172 | +However, if you have created additional database entities for storing Page Builder content, you _must_ add those entities to the `UpgradableEntitiesPool` type in your module's `etc/di.xml`. If you do not, the Page Builder content stored in your entity will not be updated, causing potential data-loss and display issues. |
| 173 | + |
| 174 | + |
| 175 | + |
| 176 | +For example, if you have created a blog entity that stores Page Builder content, you must add your blog entity to your `etc/di.xml` file as an `UpgradableEntitiesPool` type. This entry ensures that the upgrade library can update the Page Builder content types used in your blog. An entry for our blog example might look like this: |
| 177 | + |
| 178 | +```xml |
| 179 | +<type name="Magento\PageBuilder\Model\UpgradableEntitiesPool"> |
| 180 | + <arguments> |
| 181 | + <argument name="entities" xsi:type="array"> |
| 182 | + <item name="cms_blog" xsi:type="array"> |
| 183 | + <item name="identifier" xsi:type="string">blog_id</item> |
| 184 | + <item name="fields" xsi:type="array"> |
| 185 | + <item name="content" xsi:type="boolean">true</item> |
| 186 | + </item> |
| 187 | + </item> |
| 188 | + </argument> |
| 189 | + </arguments> |
| 190 | +</type> |
| 191 | +``` |
| 192 | + |
| 193 | +In such cases, your additional entity will be merged with the default entities from `Magento/PageBuilder/etc/di.xml`: |
157 | 194 |
|
158 | 195 | ```xml
|
159 | 196 | <type name="Magento\PageBuilder\Model\UpgradableEntitiesPool">
|
@@ -194,23 +231,6 @@ The `UpgradableEntitiesPool` provides the locations in the database where Page B
|
194 | 231 | </type>
|
195 | 232 | ```
|
196 | 233 |
|
197 |
| -If you have created additional database entities for storing Page Builder content, you need to add your custom entity to your `etc/di.xml` as shown in the following example: |
198 |
| - |
199 |
| -```xml |
200 |
| -<type name="Magento\PageBuilder\Model\UpgradableEntitiesPool"> |
201 |
| - <arguments> |
202 |
| - <argument name="entities" xsi:type="array"> |
203 |
| - <item name="my_custom_block" xsi:type="array"> |
204 |
| - <item name="identifier" xsi:type="string">custom_block_id</item> |
205 |
| - <item name="fields" xsi:type="array"> |
206 |
| - <item name="content" xsi:type="boolean">true</item> |
207 |
| - </item> |
208 |
| - </item> |
209 |
| - </argument> |
210 |
| - </arguments> |
211 |
| -</type> |
212 |
| -``` |
213 |
| - |
214 | 234 | ## How to upgrade your custom content types
|
215 | 235 |
|
216 | 236 | To use Page Builder's content upgrade helpers for your own content-type configuration changes, follow these steps:
|
|
0 commit comments