Showing posts with label sitecore. Show all posts
Showing posts with label sitecore. Show all posts

Tuesday, December 4, 2018

Remove format on paste in SXA Experience Editor

The experience editor uses the contenteditable feature. To remove formatting on paste you cannot use the Telerik RTE feature, because that one isn't used.



To solve, I've created a new Editing Theme in the medialibrary\Base Themes:



Upload the editor.js file containing:

window.$xa(document).ready(function () {
    $('[contenteditable]').on('paste', function(e) {
     e.preventDefault();
     var text = '';
     if (e.clipboardData || e.originalEvent.clipboardData) {
       text = (e.originalEvent || e).clipboardData.getData('text/plain');
     } else if (window.clipboardData) {
       text = window.clipboardData.getData('Text');
     }
     if (document.queryCommandSupported('insertText')) {
       document.execCommand('insertText', false, text);
     } else {
       document.execCommand('paste', false, text);
     }
 });
});

Then add My Editing Theme to the Editing Theme of your site:




Now you can do paste from word without keeping the content. Happy content editors, happy developers!

Cheers, Luuk

Tuesday, November 6, 2018

Extend Sitecore SXA metadata with hreflang and better favicon support (pt. 2 - hreflang)

When you're creating a multi lingual site, you probably want to tell the search engines to tell where to find the content in a different language. The way to do this is using hreflang.

Using the hreflang from the MetadataExtended this is really easy peasy!

You'll only have to add the hreflang rendering to the metadata partial design (like with the FaviconExtension in the previous post) manually, the rest is in the config.

The idea is that you don't use the language cookie, but always use the language from the url. To do so we need to enable the custom link manager and add a pipeline to remove the language cookie:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <linkManager defaultProvider="sitecore">
      <providers>
        <add name="ExtendedLinkProvider" 
             type="SXA.Feature.MetadataExtended.Providers.ExtendedLinkProvider, SXA.Feature.MetadataExtended" 
             cacheExpiration="5" 
             addAspxExtension="false" 
             alwaysIncludeServerUrl="false" 
             lowercaseUrls="true" 
             encodeNames="true" 
             languageEmbedding="always" 
             languageLocation="filePath" 
             shortenUrls="false" 
             useDisplayName="true">
        </add>
      </providers>
      <patch:attribute name="defaultProvider">switchableLinkProvider</patch:attribute>
    </linkManager>
    <pipelines>
      <httpRequestProcessed>
        <processor type="SXA.Feature.MetadataExtended.Pipelines.HttpRequestProcessed.LanguageCookieRemover, SXA.Feature.MetadataExtended" resolve="true" />
      </httpRequestProcessed>
    </pipelines>
  </sitecore>
</configuration>

Then enable the ExtendedLinkProvider in your SXA site, and disable language cookie support. Browse to /sitecore/content/{tenant}/{site}/Settings/Site Grouping/{site} and update the Link Provider Name. You'll also need to set the disableLanguageCookie to true:


The ExtendedLinkProvider does a bit of magic, it adds the language to the url for all languages, except for 'en'. You can always modify this behavior, but I like it this way.

To get the right localized url which uses the displayname instead of the item name (see LinkManager config above 'useDisplayName'), you'll have to do something weird, I would expect that it works when you use the language switcher it will pick up the displayname in that language. Too bad it doesn't do that, you'll need to get the language item. But the language item itself doesn't add the language in front of the url, so wrapping it around a LanguageSwitcher does the magic:

var language = Language.Parse(languageCode);

// We have to get the language item for the right display-name
var languageItem = item.Database.GetItem(item.ID, language);

// And use the Language switcher to get the right language in the url
using (new LanguageSwitcher(language))
{
    return LinkManager.GetItemUrl(languageItem); 
    // NOTE: The actual code has an option to return the full server url
    // which is needed for hreflang
}

With this, you'll get the hreflang:


If you have any questions or issues, please hit me a message below or file a ticket on:
https://github.com/luuksommers/sitecore-sxa-metadataextended

[dutch]Computer ze![/dutch]

Luuk

Saturday, November 3, 2018

Extend Sitecore SXA metadata with hreflang and better favicon support

Sitecore SXA only supports a simple favicon OOTB. Because we have a full blown mobile supported website, we want to support all the native font formats as generated by https://realfavicongenerator.net/. For this I've created MetadataExtended feature for SXA.

To use it add the _FaviconExtended template to the Settings template that has been generated for your website:


After adding this template, you'll get a lot more options in the favicon section of your settings:


Here you can upload all the files that are generated by https://realfavicongenerator.net/.

Please note that the site.webmanifest and browserconfig.xml contain a link to an icon. There files are not automatically generated in the initial version, so update them with the right media path.

Now all we need to do is add the right rendering to the medatdata partial design (/sitecore/content/{tenant}/{site}/Presentation/Partial Designs/Metadata). You can do this by adding the rendering to the /sitecore/content/{tenant}/{site}/Presentation/Available Renderings and add it using the experience editor, or directly using the Presentation Details. And voila on the favicon checker, all is green!


On the next post I'll explain the hreflang extension.

All code is available on https://github.com/luuksommers/sitecore-sxa-metadataextended

Happy faviconning,

Luuk

Friday, June 1, 2018

Patching Sitecore web.config on Azure using VSTS WebApp deploy

With Sitecore, it's a best practice to not copy the web.config to your project, but use transformations. This is a really nice idea, but when deploying Sitecore using the ARM templates to Azure and apply your solution on top of it, you cannot edit the web.config. With the solution below I want to show how to apply config transformations on Azure using the VSTS Web App Service Deploy task. The method is kinda easy once you know how to do it.

First, add the code from configtransfrom to your App_Data\tools folder, the binaries and postdeployment command are stored here. Secondly add a web.azure.config to the project, with the build action set to Content. Lastly, update the release definition and add the postdeployment task to the Web App Service Deploy.



The line in the postdeploy.cmd that does the magic is:
"%WEBROOT_PATH%\App_Data\tools\configtransform\SlowCheetah.Xdt.exe" "%WEBROOT_PATH%\web.config" "%WEBROOT_PATH%\web.azure.config" "%WEBROOT_PATH%\web.config"

To see all other available environment variables run 'set' from the kudu console.

Offcourse the source is available on Github: https://github.com/luuksommers/sitecore-azure-configtransform

Happy transforming!
Luuk

Friday, April 6, 2018

Transforming Unicorn files in a release pipeline using YmlTransform



When you use an automated deployment to different environments that also need changes in unicorn files (without having to update the sitecore configuration manually) you can use YmlTransform. This is an easy tool that uses an input Json file to update unicorn files before copying them to the server. Together with the ReplaceTokens task this is a very powerfull solution.

Our deployment process looks like this before we publish the web application to Azure.

First you'll need to create a Json file containing the fields you want to replace, it currently supports shared and language fields. In our case we call it unicorn.ymltransform with the following content:
[
    {
        "FieldId": "379de7bc-88f2-42ae-8d4a-50dd0b8796ea",
        "Languages": "",
        "Path": "/sitecore/content/Home/Item1",
        "Type": "Shared",
        "Value": "#{ApiUrl1}#"
    },
    {
        "FieldId": "379de7bc-88f2-42ae-8d4a-50dd0b8796ea",
        "Languages": "*",
        "Path": "/sitecore/content/Home/Item2",
        "Type": "Shared",
        "Value": "#{ApiUrl2}#"
    },
    {
        "FieldId": "86ee9731-e7fb-47c9-bab6-5cb282c3a920",
        "Languages": "*",
        "Path": "/sitecore/content/Home/Item3",
        "Type": "Shared",
        "Value": "#{OtherSetting}#"
    }
]

When you parse this file through the ReplaceTokens and run it over your *.ymltransform files, the unicorn files will be transformed using the actual value from the VSTS variables (which could also be loaded from a keyfault).

In the next step you can run a command with the following settings to transform the actual unicorn files:
ymltransform.exe -p "App_Data/unicorn" -r -t "unicorn.ymltransform" 

The output of this command:
2018-04-06T06:28:47.6709328Z Updating file D:\a\r1\a\TestProject\drop\artifacts\Website\App_Data/unicorn\Project\serialization\Content\Home\Item1.yml section Shared id 379de7bc-88f2-42ae-8d4a-50dd0b8796ea to https://apiurl1.com
2018-04-06T06:28:47.6711423Z Transformed: D:\a\r1\a\TestProject\drop\artifacts\Website\App_Data/unicorn\Project\serialization\Content\Home\Item1.yml
2018-04-06T06:28:47.7732198Z Updating file D:\a\r1\a\TestProject\drop\artifacts\Website\App_Data/unicorn\Project\serialization\Content\Home\Item2.yml section Shared id 379de7bc-88f2-42ae-8d4a-50dd0b8796ea to https://apiurl2.com
2018-04-06T06:28:47.7735015Z Transformed: D:\a\r1\a\TestProject\drop\artifacts\Website\App_Data/unicorn\Project\serialization\Content\Home\Item2.yml
2018-04-06T06:28:47.9817169Z Updating file D:\a\r1\a\TestProject\drop\artifacts\Website\App_Data/unicorn\Project\serialization\Content\Home\Item3.yml section Shared id 86ee9731-e7fb-47c9-bab6-5cb282c3a920 to HelloWorld
2018-04-06T06:28:47.9819775Z Transformed: D:\a\r1\a\TestProject\drop\artifacts\Website\App_Data/unicorn\Project\serialization\Content\Home\Item3.yml

Now the yml files contain the correct information for your environment, you can upload the yml files and run a unicorn sync (automatically).

The full sourcecode is available on Github:
https://github.com/luuksommers/ymltransform 

Happy transforming!
Luuk

Friday, March 23, 2018

Using the Sitecore bootloader to add Redis to an Sitecore 8.2 XP0 installation

The Sitecore bootloader is a nifty little-underdocumented thing that can be used to easily extend a Sitecore installation. When you'll install EXM using the web deploy packages, you'll notice that it has to add some connection strings to the ConnectionStrings.config, but you cannot modify that file without restarting the application. So I was wondering, how does that work.
It appears that the bootloader scans directories and can apply xdt transforms to all configs. Just by placing a file called ConnectionStrings.config.xdt on the Azure WebApp in the following folder: App_Data\Transforms\Redis\Xdts\App_Config, the bootloader will try to match the filename without xdt and run the transformation. So the path after Xdts should match the folder structure from your site root.
The Redis package does exactly the same: I've created a WebDeploy package containing this file, so we can deploy Redis to Sitecore without any modifications to the Sitecore installation beforehand.

The content of the xdt file:
<?xml version="1.0"?>
<connectionStrings xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
 <add name="redis.sessions" connectionString="Redis Connection String" xdt:Transform="Insert" />
</connectionStrings>

By adding a parameter to the web deploy package called 'Redis ConnectionString' we can now push the Redis connection string to the web deployment package.
{
  "name": "[concat(variables('singleWebAppNameTidy'), '/', 'MSDeploy')]",
  "type": "Microsoft.Web/sites/extensions",
  "location": "[parameters('location')]",
  "apiVersion": "[variables('webApiVersion')]",
  "properties": {
    "addOnPackages": [
      {
        "packageUri": "[parameters('redisMsDeployPackageUrl')]",
        "setParameters": {
          "Application Path": "[variables('singleWebAppNameTidy')]",
          "Redis Connection String": "[concat(reference(resourceId('Microsoft.Cache/Redis', 
                   variables('redisCacheNameTidy')), variables('redisApiVersion')).hostName, ':', reference(resourceId('Microsoft.Cache/Redis', 
                   variables('redisCacheNameTidy')), variables('redisApiVersion')).sslPort, ',password=', listKeys(resourceId('Microsoft.Cache/Redis', 
                   variables('redisCacheNameTidy')), variables('redisApiVersion')).primaryKey, ',ssl=True,abortConnect=False')]"
        }
      }
    ]
  }
}

During the first hit of the site, the bootloader will scan the App_Data\Transforms directory. The bootloader then runs an installer in a separated process on the Web App to apply the transformation.

Supporting code:
https://github.com/luuksommers/sitecore-xp0-redis

Happy caching!
Luuk