Update markdown files to be compatible with the latest Hugo

Signed-off-by: Marc Duiker <[email protected]>

Author: marcduiker

daprdocs/content/en/php-sdk-docs/_index.md

@@ -113,4 +113,4 @@ Congratulations, you've created your first Dapr service! I'm excited to see what
 ## More Information
 
 - [Packagist](https://packagist.org/packages/dapr/php-sdk)
-- [Dapr SDK serialization]({{< ref sdk-serialization.md >}})
+- [Dapr SDK serialization]({{% ref sdk-serialization.md %}})

daprdocs/content/en/php-sdk-docs/php-actors/_index.md

@@ -8,7 +8,7 @@ no_list: true
 ---
 
 If you're new to the actor pattern, the best place to learn about the actor pattern is in
-the [Actor Overview.]({{< ref actors-overview.md >}})
+the [Actor Overview.]({{% ref actors-overview.md %}})
 
 In the PHP SDK, there are two sides to an actor, the Client, and the Actor (aka, the Runtime). As a client of an actor,
 you'll interact with a remote actor via the `ActorProxy` class. This class generates a proxy class on-the-fly using one
@@ -109,9 +109,9 @@ class CountState extends \Dapr\Actors\ActorState {
 
 Dapr expects to know what actors a service may host at startup. You need to add it to the configuration:
 
-{{< tabs "Production" "Development" >}}
+{{< tabpane text=true >}}
 
-{{% codetab %}}
+{{% tab header="Production" %}}
 
 If you want to take advantage of pre-compiled dependency injection, you need to use a factory:
 
@@ -137,8 +137,8 @@ $app = \Dapr\App::create(
 $app->start();
 ```
 
-{{% /codetab %}}
-{{% codetab %}}
+{{% /tab %}}
+{{% tab header="Development" %}}
 
 ```php
 <?php
@@ -160,5 +160,5 @@ $app = \Dapr\App::create(configure: fn(\DI\ContainerBuilder $builder) => $builde
 $app->start();
 ```
 
-{{% /codetab %}}
-{{< /tabs >}}
+{{% /tab %}}
+{{< /tabpane >}}

daprdocs/content/en/php-sdk-docs/php-actors/php-actor-reference.md

@@ -22,21 +22,21 @@ weigh during development and in production.
 
 It can be set with `dapr.actors.proxy.generation` configuration key.
 
-{{< tabs "GENERATED" "GENERATED_CACHED" "ONLY_EXISTING" "DYNAMIC" >}}
-{{% codetab %}}
+{{< tabpane text=true >}}
+{{% tab header="GENERATED" %}}
 
 This is the default mode. In this mode, a class is generated and `eval`'d on every request. It's mostly for development
 and shouldn't be used in production.
 
-{{% /codetab %}}
-{{% codetab %}}
+{{% /tab %}}
+{{% tab header="GENERATED_CACHED" %}}
 
 This is the same as `ProxyModes::GENERATED` except the class is stored in a tmp file so it doesn't need to be
 regenerated on every request. It doesn't know when to update the cached class, so using it in development is discouraged
 but is offered for when manually generating the files isn't possible.
 
-{{% /codetab %}}
-{{% codetab %}}
+{{% /tab %}}
+{{% tab header="ONLY_EXISTING" %}}
 
 In this mode, an exception is thrown if the proxy class doesn't exist. This is useful for when you don't want to 
 generate code in production. You'll have to make sure the class is generated and pre-/autoloaded.
@@ -104,15 +104,15 @@ return [
 ];
 ```
 
-{{% /codetab %}}
-{{% codetab %}}
+{{% /tab %}}
+{{% tab header="DYNAMIC" %}}
 
 In this mode, the proxy satisfies the interface contract, however, it does not actually implement the interface itself
 (meaning `instanceof` will be `false`). This mode takes advantage of a few quirks in PHP to work and exists for cases
 where code cannot be `eval`'d or generated.
 
-{{% /codetab %}}
-{{< /tabs >}}
+{{% /tab %}}
+{{< /tabpane >}}
 
 ### Requests
 

daprdocs/content/en/php-sdk-docs/php-app/php-unit-testing.md

@@ -17,9 +17,9 @@ With actors, there are two things we're interested in while the actor is under t
 1. The returned result based on an initial state
 2. The resulting state based on the initial state
 
-{{< tabs "integration test with TestClient" "unit test" >}}
+{{< tabpane text=true >}}
 
-{{% codetab %}}
+{{% tab header="integration test with TestClient" %}}
 
 Here's an example test a very simple actor that updates its state and returns a specific value:
 
@@ -112,8 +112,8 @@ class TheTest extends \PHPUnit\Framework\TestCase
 }
 ```
 
-{{% /codetab %}}
-{{% codetab %}}
+{{% /tab %}}
+{{% tab header="unit test" %}}
 
 ```php
 <?php
@@ -162,18 +162,18 @@ class TheTest extends \PHPUnit\Framework\TestCase
 }
 ```
 
-{{% /codetab %}}
+{{% /tab %}}
 
-{{< /tabs >}}
+{{< /tabpane >}}
 
 ## Testing Transactions
 
 When building on transactions, you'll likely want to test how a failed transaction is handled. In order to do that, you
 need to inject failures and ensure the transaction matches what you expect.
 
-{{< tabs "integration test with TestClient" "unit test" >}}
+{{< tabpane text=true >}}
 
-{{% codetab %}}
+{{% tab header="integration test with TestClient" %}}
 
 ```php
 <?php
@@ -214,7 +214,7 @@ class TheTest extends \PHPUnit\Framework\TestCase {
     public function testTransactionFailure() {
         $client = $this->getClient();
 
-        // create a response from {{< ref state_api >}}
+        // create a response from {{% ref state_api %}}
         $client->register_post('/state/statestore/bulk', code: 200, response_data: [
             [
                 'key' => 'value',
@@ -247,8 +247,8 @@ class TheTest extends \PHPUnit\Framework\TestCase {
 }
 ```
 
-{{% /codetab %}}
-{{% codetab %}}
+{{% /tab %}}
+{{% tab header="unit test" %}}
 
 ```php
 <?php
@@ -280,6 +280,6 @@ class TheTest extends \PHPUnit\Framework\TestCase {
 }
 ```
 
-{{% /codetab %}}
+{{% /tab %}}
 
-{{< /tabs >}}
+{{< /tabpane >}}

daprdocs/content/en/php-sdk-docs/php-pubsub/_index.md

@@ -17,16 +17,16 @@ $app->post('/publish', function(\Dapr\Client\DaprClient $daprClient) {
 });
 ```
 
-For more information about publish/subscribe, check out [the howto]({{< ref howto-publish-subscribe.md >}}).
+For more information about publish/subscribe, check out [the howto]({{% ref howto-publish-subscribe.md %}}).
 
 ## Data content type
 
 The PHP SDK allows setting the data content type either when constructing a custom cloud event, or when publishing raw
 data.
 
-{{< tabs CloudEvent "Raw" >}}
+{{< tabpane text=true >}}
 
-{{% codetab %}}
+{{% tab header="CloudEvent" %}}
 
 ```php
 <?php
@@ -35,8 +35,8 @@ $event->data = $xml;
 $event->data_content_type = 'application/xml';
 ```
 
-{{% /codetab %}}
-{{% codetab %}}
+{{% /tab %}}
+{{% tab header="Raw" %}}
 
 ```php
 <?php
@@ -52,9 +52,9 @@ Only `application/octet-steam` is supported for binary data.
 
 {{% /alert %}}
 
-{{% /codetab %}}
+{{% /tab %}}
 
-{{< /tabs >}}
+{{< /tabpane >}}
 
 ## Receiving cloud events
 

daprdocs/content/en/php-sdk-docs/php-state/_index.md

@@ -8,7 +8,7 @@ no_list: true
 ---
 
 Dapr offers a great modular approach to using state in your application. The best way to learn the basics is to visit
-[the howto]({{< ref howto-get-save-state.md >}}).
+[the howto]({{% ref howto-get-save-state.md %}}).
 
 ## Metadata
 
@@ -26,7 +26,7 @@ $app->run(
 $app->run(fn(\Dapr\Client\DaprClient $daprClient) => $daprClient->saveState(storeName: 'statestore', key: 'key', value: 'value', metadata: ['port' => '112']))
 ```
 
-This is an example of how you might pass the port metadata to [Cassandra]({{< ref setup-cassandra.md >}}).
+This is an example of how you might pass the port metadata to [Cassandra]({{% ref setup-cassandra.md %}}).
 
 Every state operation allows passing metadata.
 
@@ -58,9 +58,9 @@ the load on the state store at the expense of performance. The default is `10`.
 Hardcoded key names are useful, but why not make state objects more reusable? When committing a transaction or saving an
 object to state, you can pass a prefix that is applied to every key in the object.
 
-{{< tabs "Transaction prefix" "StateManager prefix" >}}
+{{< tabpane text=true >}}
 
-{{% codetab %}}
+{{% tab header="Transaction prefix" %}}
 
 ```php
 <?php
@@ -76,8 +76,8 @@ $app->run(function (TransactionObject $object ) {
 });
 ```
 
-{{% /codetab %}}
-{{% codetab %}}
+{{% /tab %}}
+{{% tab header="StateManager prefix" %}}
 
 ```php
 <?php
@@ -94,6 +94,6 @@ $app->run(function(\Dapr\State\StateManager $stateManager) {
 });
 ```
 
-{{% /codetab %}}
+{{% /tab %}}
 
-{{< /tabs >}}
+{{< /tabpane >}}