Skip to content

Commit 5b1d9a9

Browse files
Merge pull request #464 from magento/1.3.0-release
1.3.0 release
2 parents 229a8de + 7a3f05e commit 5b1d9a9

6 files changed

+52
-32
lines changed

docs_drafts/how-to/how-to-use-upgrade-library.md docs/how-to/how-to-use-upgrade-library.md

+52-32
Original file line numberDiff line numberDiff line change
@@ -1,25 +1,31 @@
1-
# How to use the content type upgrade library
1+
# How to upgrade content types
22

33
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.
44

55
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.
66

7-
## Example usage for Row
7+
## Example: Updating the Row content type
88

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!
1010

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.
1212

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:
1515

16-
![Example converter and upgrader classes](../images/upgrade-framework-example-pb.png)
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`)
1719

18-
### Converter class example
20+
For our Row example, the Page Builder team would add the following files to the `Magento/PageBuilder/Setup` directories:
1921

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+
![Example converter and upgrader classes](../images/upgrade-framework-example-pb.png)
2123

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:
2329

2430
```php
2531
<?php
@@ -82,11 +88,11 @@ class FixFullWidthRowPadding implements DataConverterInterface
8288
}
8389
```
8490

85-
### Data patch class example
91+
### Step 2: Create a Data Patch
8692

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.
8894

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:
9096

9197
```php
9298
<?php
@@ -151,9 +157,40 @@ class UpgradeFullWidthPadding implements DataPatchInterface
151157
}
152158
```
153159

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`.
155171

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+
![Additional entities](../images/upgrade-framework-additional-entities.png)
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`:
157194

158195
```xml
159196
<type name="Magento\PageBuilder\Model\UpgradableEntitiesPool">
@@ -194,23 +231,6 @@ The `UpgradableEntitiesPool` provides the locations in the database where Page B
194231
</type>
195232
```
196233

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-
214234
## How to upgrade your custom content types
215235

216236
To use Page Builder's content upgrade helpers for your own content-type configuration changes, follow these steps:
Loading
47.5 KB
Loading
42.6 KB
Loading
Binary file not shown.
Binary file not shown.

0 commit comments

Comments
 (0)