Merge pull request #155 from 10up/fix/callouts

Fix invalid format of callouts in md

guides/choose-your-adventure.md

@@ -51,7 +51,7 @@ You can easily enhance the editor experience by also adding a block pattern for
 
 :::caution
 As mentioned in the [block pattern reference](../reference/Blocks/block-patterns) patterns have no connection to what created them. So any updates you make to the pattern in the future will not update instances that were created before you updated it.
-:::caution
+:::
 
 ### 2.b Using Core Blocks + a Block Pattern with Restrictions
 
@@ -65,4 +65,4 @@ This Icon Card block can then be inserted inside the columns block with a headin
 
 :::info
 The custom block should also get a block pattern created to make it even easier to insert the entire design on the page. Since we build dynamic blocks at 10up we now also don't have the issue of not being able to update markup in patterns anymore. Because we can update the markup of our dynamic block which gets reflected everywhere.
-:::info
+:::

guides/data-api.md

@@ -55,7 +55,7 @@ import { store as packageStore } from '@wordpress/package';
 
 :::note
 `@wordpress/package` does not actually exist
-:::note
+:::
 
 You can then use this imported store object either by passing it to the `useDispatch` hook if you want to trigger actions on the store:
 

guides/extend-a-core-block.md

@@ -50,7 +50,7 @@ function generateClassName( attributes ) {
 
 :::caution
 If you extend dynamic blocks that don't store their markup in the database you will need to replicate the logic to add the class name on the frontend manually in php.
-:::caution
+:::
 
 ### Create Inline Style generator
 

guides/including-frontend-javascript-with-a-block.md

@@ -36,7 +36,7 @@ Every time the block gets used anywhere, WordPress will make sure to enqueue all
 
 :::note
 WordPress expects a file that is provided via a relative file path to also have a `.asset.php` file next to it with the script dependencies and generated version number. Both `@wordpress/scripts` and `10up-toolkit` do this automatically for you using the `@wordpress/dependency-extraction-webpack-plugin`.
-:::note
+:::
 
 ### Enqueueing additional external dependencies
 

guides/using-wordpress-packages-on-the-frontend.md

@@ -12,7 +12,7 @@ You can find a list of `@wordpress/` packages that are the exception to this rul
 The `@wordpress/` dependencies are first and foremost designed to be used within the editor. Therefore they are not necessarily optimized for frontend performance and size. Some packages rely on [`lodash`](https://lodash.com) or [`moment`](https://momentjs.com) and therefore come with a **lot** of code.
 
 _Starting in WordPress 6.1 a lot of packages have dropped their reliance of `lodash`._
-:::caution
+:::
 
 ## Bundle size
 
@@ -33,7 +33,7 @@ Speaking of [`lodash`](https://lodash.com) one pitfall is, that the [Dependency
 
 :::info
 There are some `@wordpress/` packages, like the [`@wordpress/icons`](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-icons/) package, that are not bundled in WordPress and therefore don't get externalized. You can view the [excluded list in the GitHub repo](https://github.com/WordPress/gutenberg/blob/b1f2064d64df4db70a379c690ee1e28ebef8b86d/packages/dependency-extraction-webpack-plugin/lib/util.js#L2-L6).
-:::info
+:::
 
 This means that even if any of your other frontend dependencies try to load something from lodash the [Dependency Extraction Webpack Plugin](https://www.npmjs.com/package/@wordpress/dependency-extraction-webpack-plugin) will pick that up and add [`lodash`](https://lodash.com) to your dependency array.
 
@@ -43,7 +43,7 @@ The [`@wordpress/packages`](https://developer.wordpress.org/block-editor/referen
 
 :::caution
 As a rule of thumb any package that includes _editor_ in it's name should **not** be used outside of the editor.
-:::caution
+:::
 
 ## Useful packages outside of the editor
 

reference/01-Fundamentals/a-block.md

@@ -84,7 +84,7 @@ This pattern of having a placeholder also allows you to make it easier for your
 
 :::info
 This actually is a pattern that you will see over and over again throughout this section. The settings sidebar should be treated as optional. Most editors should never have to open it and interact with the options in it. Everything they need to enter their content should be available inline.
-:::info
+:::
 
 ### Selected
 

reference/02-Themes/styles.md

@@ -28,7 +28,7 @@ The stylesheets that get added via the `add_editor_style` function get automatic
 
 :::tip
 If you need to load custom fonts from an external source you also need to add a separate `add_editor_style` call for the stylesheet loading the font.
-:::tip
+:::
 
 <details>
 <summary>Enqueueing order on the page:</summary>
@@ -104,7 +104,7 @@ Please note that if a stylesheet opts-in to get inlined, that is no guarantee th
 If for example on a page there are 30 stylesheets that are 1kb each, and they all opt-in to be inlined, then only 20 of them will be converted from `<link rel="stylesheet"/>` to `<style>` elements. When the 20th stylesheet gets inlined the 20kb limit is reached and the inlining process stops. The remaining 10 stylesheets will continue functioning like before and remain `<link>` elements.
 
 If your theme opts-in to the separate block-styles, core block styles by default have `path` defined so they can all be inlined.
-:::note
+:::
 
 ## Links
 

reference/03-Blocks/block-extensions.md

@@ -6,7 +6,7 @@ sidebar_position: 3
 
 :::note
 There is no core API for block extensions. When we refer to block extensions here, we actually mean using the hooks provided in the block editor to add our own custom attributes and UI to existing blocks.
-:::note
+:::
 
 The Block Editor Handbook has a full list of the [available block filters in the Block Editor Handbook](https://developer.wordpress.org/block-editor/reference-guides/filters/block-filters/).
 

reference/03-Blocks/block-locking.md

@@ -10,7 +10,7 @@ The Block Locking API was introduced in WordPress 5.9. With it blocks can be loc
 
 :::note
 Blocks can opt out of showing the block locking UI to the user via the `lock` block supports option. There also is a way to override what users are able to use the block locking UI via the `canLockBlocks` editor setting.
-:::note
+:::
 
 ## Locking the ability to remove / move a block
 
@@ -42,7 +42,7 @@ In a pattern you can set these attributes via the html comment of the block wher
 
 :::note
 You can also use these attributes in your custom blocks to set default values for the locking. For example if you have a page header block that should never get removed you can set the default value of the `lock` attribute to `{ remove: true }`
-:::note
+:::
 
 ## Restricting which inner blocks can be used
 
@@ -72,7 +72,7 @@ The core column, group, and cover block support the ability to restrict which bl
 
 :::tip
 Since these patterns are php files you can make the `allowedBlocks` list filterable via an `apply_filters` hook.
-:::tip
+:::
 
 ## Disabling the block locking UI
 

reference/03-Blocks/block-patterns.md

@@ -190,7 +190,7 @@ Starting in WordPress 6.1, Block patterns can also be specific to any post type.
 
 :::tip
 The ability to limit a pattern per post type ties in nicely with the option for page level patterns. When you **combine** the two you can present users with **different page level patterns** for **different post types**.
-:::tip
+:::
 
 ## Contextual Patterns
 
@@ -218,7 +218,7 @@ The WPEngine Blog has published a [great article about Contextual Patterns](http
 
 <iframe width="560" height="315" src="https://www.youtube.com/embed/fW4xhwjfyeY" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
 
-:::info
+:::
 
 ## Content Only locked Patterns
 
@@ -277,7 +277,7 @@ This is achieved by adding `"__experimentalRole": "content"` to the attribute de
 
 :::caution
 There is one item that you need to be aware about in regards to Block Patterns. Once they are inserted they have no link to the original block pattern that they were created by. On insertion they become regular blocks. Therefore it is not possible to adjust all occurrences of a block pattern after it has been used.
-:::caution
+:::
 
 If you find an issue with the markup of a pattern that you want to fix it is only going to impact new instances of the pattern that are created after you updated it. And you will have to manually go into every instance that was created using the pattern and make the update manually, or create an update script to update it in the database directly.
 

reference/03-Blocks/block-styles.md

@@ -10,7 +10,7 @@ Block styles are a relatively simple API that allows you to add different visual
 
 :::caution
 Block Styles come with many caveats though and should be used very sparingly. Instead [block extensions](block-extensions) should be used in most cases because of the increased flexibility.
-:::caution
+:::
 
 ## User Experience
 
@@ -20,7 +20,7 @@ In the editor, styles are the first thing a user sees in the blocks setting side
 Additionally the style options have one fatal flaw. Only one of them can be active at a time. And most things that end up becoming styles are things that you down the line would love to combine. And that is a downfall that happens very quickly.
 
 At the beginning of a project 2-4 styles get added to a block. And after using it for a moment the client comes back now wanting to combine the options from Style A and Style B. And at that point you would need to create a separate new style for the combination of A & B. And then someone else wants to use B & C and so on. Styles lead you into a corner very quickly.
-:::warning
+:::
 
 ## Developer Experience
 
@@ -61,12 +61,12 @@ unregisterBlockStyle( 'core/image', 'rounded' );
 
 :::caution
 Important: The PHP function `unregister_block_style` only unregisters styles that were registered on the server using `register_block_style`. The function does not unregister a style registered using client-side code.
-:::caution
+:::
 
 There is no actual API for checking which style is currently selected and there is no listener to subscribe to changes in the selected style.
 
 ## Alternative
 
 :::tip
 Most use-cases of Block Styles would be better suited as [block extensions](block-extensions).
-:::tip
+:::

reference/03-Blocks/block-transforms.md

@@ -20,7 +20,7 @@ You can solve this problem by essentially deprecating the two old blocks by sett
 
 :::info
 This is great because the old instances don't automatically get updated, but instead allow the editor to either leave them as is, or update them to the new variant whenever they want.
-:::info
+:::
 
 ## Adding Block Transformations
 

reference/03-Blocks/block-updates.md

@@ -114,11 +114,11 @@ With this every block that is newly created and also every existing block that g
 
 :::warning
 But be careful. Existing blocks on pages that don't get edited will still have the old attributes shape until they get updated. So your PHP markup will need to account for both instances.
-:::warning
+:::
 
 :::note
 the `isEligible` check is required since the block editor would use the saved markup by default. But since we don't save our markup this is the way we can tell the editor what deprecation needs to run.
-:::note
+:::
 
 ## Further reading
 

reference/03-Blocks/block-variations.md

@@ -18,7 +18,7 @@ Variations can be surfaced in three ways. They can be shown in the inserter, the
 
 :::note
 By default they are shown both in the inserter and the block.
-:::note
+:::
 
 Block variations can be declared during a block's registration by providing the `variations` key with a proper array of variations, as defined below. In addition, there are ways to register and unregister a `block variation` for a block, after its registration.
 
@@ -75,7 +75,7 @@ An object describing a variation defined for the block type can contain the foll
 
 :::info
 The main difference between block styles and block variations is that a block style just applies a CSS class to the block, so it can be styled in an alternative way. If we want to apply initial attributes or inner blocks, we fall in block variation territory.
-:::info
+:::
 
 To add a block variation use `registerBlockVariation()`.
 

reference/03-Blocks/custom-blocks.md

@@ -36,7 +36,7 @@ At 10up the majority of custom blocks we develop blocks as dynamic blocks. We al
 These best practices only apply to closely monitored custom client builds. Blocks for open source projects should use static rendering as the default and should ship in plugins only.
 
 In general. If a block provides functionality it is better suited in a plugin. If it is a design / layout element specific to a theme it should be bundled with the theme.
-:::info
+:::
 
 ### Dynamic Blocks
 

training/02-cta-lesson.md

@@ -68,11 +68,11 @@ Not sure what to use as values? Here you go:
 />
 ```
 
-:::tip
+:::
 
 :::note
 See that `setAttributes` call? That's a function that is provided by the block API to set attributes for the block you can read more about it [here](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-attributes/)
-:::note
+:::
 
 ### 3: Adding an optional field to the block
 
@@ -91,15 +91,16 @@ Add three more attributes to the `cta-starter/block.json` file for each of the n
 
 :::note
 **One of them is** NOT of the type `string`
-:::note
+:::
 
 :::tip
 Attributes we are adding:
 
 * `showCTALink`
 * `ctaLink`
 * `ctaText`
-:::tip
+
+:::
 
 **BONUS:** Let's set some defaults for these new attributes:
 
@@ -116,7 +117,7 @@ The `InspectorControls` component has already been added to the `cta-starter/edi
 
 :::tip
 place `ToggleControl` inside `PanelBody`:
-:::tip
+:::
 
 ```jsx
 <ToggleControl
@@ -142,7 +143,7 @@ Once that is in-place, we want to add a `URLInput` component to the Inspector Si
 />
 ```
 
-:::tip
+:::
 
 The next step is to add a new `RichText` component below the one for the `description` field that will manage the text of the CTA button. Be sure that this is only shown if the feature is enabled and that it sets and retrieves the associated attribute correctly.
 
@@ -155,7 +156,8 @@ The next step is to add a new `RichText` component below the one for the `descri
   * `placeholder={__('CTA here…', 'gutenberg-lessons')}`
   * `value={ctaText}`
   * `onChange={(ctaText) => setAttributes({ ctaText })}`
-:::tip
+
+:::
 
 **A quick note on block UX best practices:** Generally, speaking content such as text or setting a featured image should be input into the actual block and "settings" such as the CTA on/off toggle should be in the inspector toolbar.
 
@@ -168,11 +170,12 @@ The intention for any block we create at 10up is to have the Block Editor experi
 * Add `description`, and conditionally show `ctaLink`.
 * All data needed should be passed found in $attributes.
 * Don't forget class names.
-:::tip
+
+:::
 
 :::caution
 You may see in the primary div in the class declaration the following: `<?php echo isset( $attributes['className'] ) ? esc_attr( $attributes['className'] ) : ''; ?>`. When a block is selected, within the block inspector controls (right sidebar), you will see a toggle for `Advanced` and, within that, an input to optionally add `Additional CSS class(es)`. This code included in the markup will display any custom / additional classes added here.
-:::caution
+:::
 
 ## Next Steps
 

training/03-styles.md

@@ -4,7 +4,7 @@ In many of our projects at 10up, we need to change the style of some of the core
 
 :::tip
 A block should **never** have more than 4 block styles
-:::tip
+:::
 
 ## Learning Outcomes
 
@@ -44,7 +44,7 @@ Let's see how to add a new style — slightly-rounded!
 This is a fictional example that showcases the pitfalls of Block Styles pretty well. In the real world, this setting should probably be a block extension that allows the editor to change the Border Radius of the image.
 
 Because as soon as the client needs more different steps of rounded corners all you can do is add more and more block styles that all are very similar to one another. Leading to a worse user experience.
-:::caution
+:::
 
 ## Add a New Style
 
@@ -88,7 +88,7 @@ function registerImageStyles() {
 }
 ```
 
-:::tip
+:::
 
 1. Pass the function to the `domReady` function from the `@wordpress/dom-ready` package. Registering our styles only once the DOM is fully loaded avoids race conditions with WordPress Core:
 
@@ -107,7 +107,7 @@ And voila! We've added a new style for our custom block!
 
 :::note
 For training purposes, this replicates the custom styles already in place for the `cta-complete` block. This type of replication we would typically not do in a real-world environment.
-:::note
+:::
 
 ![alt text](../static/img/cta-block-thick-border.png "Thick border CTA style")
 

training/04-patterns.md

@@ -28,7 +28,7 @@ We need a way to "package up" all those elements so editors can easily insert th
 The approach taught in this lesson requires WordPress 6.0. In order to get it working before this, we have [polyfilled the core functionality into the `tenup-theme` of the gutenberg training](https://github.com/10up/gutenberg-lessons/blob/trunk/themes/tenup-theme/includes/blocks.php#L181-L316).
 
 In order to manually register patterns, you need to register each pattern using the [`register_block_pattern`](https://developer.wordpress.org/reference/functions/register_block_pattern/) function.
-:::info
+:::
 
 ## Breaking it Down
 

training/05-variations.md

@@ -28,7 +28,7 @@ The Columns block on the other hand sets the scope to `block` and uses the block
 
 :::note
 The default `scope` is both `block` and `inserter`
-:::note
+:::
 
 ## Exercise Overview
 
@@ -38,7 +38,7 @@ Of course, you could skip the setup and manually configure it to have 4 25% wide
 
 :::note
 If you get stuck, you can take a look at the completed example located in the [`includes/block-variations`](https://github.com/10up/gutenberg-lessons/blob/trunk/themes/tenup-theme/includes/block-variations/four-columns-variation-completed.js) folder of the tenup theme.
-:::note
+:::
 
 1. Create a new file in the `includes/block-variations` folder called `four-columns-equal.js`
 2. import that new file into the `index.js` file inside the same folder

training/06-inner-blocks.md

@@ -212,7 +212,7 @@ return (
 
 :::note
 Before continuing, be sure you have done the following for the `inner-blocks-two-card-starter` and the `inner-blocks-two-card-grid-starter.` (per our guidance above):
-:::note
+:::
 
 1. Add `editorScript` property in [`block.json`](https://github.com/10up/gutenberg-lessons/blob/trunk/themes/tenup-theme/includes/blocks/inner-blocks-two-card-grid-starter/block.json)
 2. Add `useInnerBlocksProps` to [`edit.js`](https://github.com/10up/gutenberg-lessons/tree/trunk/themes/tenup-theme/includes/blocks/inner-blocks-two-card-grid-starter/edit.js) (Don't forget to import `useInnerBlocksProps` at the top of the file).
@@ -254,7 +254,7 @@ const innerBlocksProps = useInnerBlocksProps(
 
 :::tip
 For the above, we have already included styles in the [`index.css`](https://github.com/10up/gutenberg-lessons/tree/trunk/themes/tenup-theme/includes/blocks/inner-blocks-two-card-grid-starter/index.css) to assist with our layout - more on this below.
-:::tip
+:::
 
 The second thing we need to do is make sure our "child" block, in this case, the "Card", doesn't appear in the regular inserter or that it cannot get moved anywhere outside of a "Card Grid". And for that, we can use the [`parent`](https://github.com/WordPress/gutenberg/blob/trunk/docs/reference-guides/block-api/block-registration.md#parent-optional) option in the `block.json` file. When you define a `parent` the block will no longer show up in the inserter and it also cannot get used anywhere outside of the defined parent.