From 46dabcad86221a439343ad02ded41d1048c227d8 Mon Sep 17 00:00:00 2001 From: Tutku Can Yalcin Date: Thu, 11 Jan 2024 10:46:41 +0100 Subject: [PATCH 1/2] Grammar check 2 for blogpost 2024-01-15-Sitecore-10-problems-and-solutions --- ...01-15-sitecore-10-upgrade-problems-and-solutions.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/_posts/2024-01-15-sitecore-10-upgrade-problems-and-solutions.md b/docs/_posts/2024-01-15-sitecore-10-upgrade-problems-and-solutions.md index 881e015..3513584 100644 --- a/docs/_posts/2024-01-15-sitecore-10-upgrade-problems-and-solutions.md +++ b/docs/_posts/2024-01-15-sitecore-10-upgrade-problems-and-solutions.md @@ -119,7 +119,7 @@ In Sitecore 10, there was another change for each form field on the core databas Even though item names are the same, there are different items selected in Sitecore 10. You can put the following IDs on the ControlDefinitions field on Sitecore for each of these custom fields, then we will be able to see CSS classes on Sitecore Forms Editor: -{% highlight ruby %} +{% highlight yaml %} {98FB361E-3A7F-49F9–8789–8C169FB95B61}|{121B9875–2F7D-4D62-BD0F-35A7B909ECE8} {% endhighlight %} @@ -131,7 +131,7 @@ After the upgrade, we realized there were many field values not showing on the w ## Solution We searched on Glass Mapper release documentation and found this one: -[glass mapper](http://www.glass.lu/Mapper/Releases.html) on version 5.3.17 which mentions: +[Glass Mapper](http://www.glass.lu/Mapper/Releases.html) on version 5.3.17 which mentions: >ISSUE 370 The lazy object inceptor will now ignore class properties that don't have a setter or have the SitecoreIgnore attribute. @@ -163,9 +163,9 @@ We developed a custom SettingProvider and started using it instead of queries or ## Problem: System.OutOfMemory Exception -After we switched to Sitecore 10 and started using the databases from the production system, many developers in the team experienced this exception. +After we switched to Sitecore 10 with Docker and imported the databases from the production system, many developers in the team experienced this exception. -Either cm was unhealthy, or after some time it was becoming unhealthy. When we check logs on the docker or inspect container, we would always see this error popping up. Also, the Sitecore system needed to be faster to work on. +Either cm was unhealthy, or after some time it was becoming unhealthy. When we check logs on the docker or inspect the container, we would always see this error popping up. Also, the Sitecore system needed to be faster to work on. ## Solution @@ -191,4 +191,4 @@ DELETE FROM dbo.PublishQueue After this cleanup docker became fast, and we got rid of the exception. -Thanks to Fabian Geiger and Ramazan Yilmaz for their support.. \ No newline at end of file +Thanks to Fabian Geiger and Ramazan Yilmaz for their support... \ No newline at end of file From c6c815a0a8d4de646f4eca40c2c057524da2bc9f Mon Sep 17 00:00:00 2001 From: Tutku Can Yalcin Date: Thu, 11 Jan 2024 10:47:16 +0100 Subject: [PATCH 2/2] Grammar check 3 for blogpost 2024-01-15-Sitecore-10-problems-and-solutions --- .../2024-01-15-sitecore-10-upgrade-problems-and-solutions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/_posts/2024-01-15-sitecore-10-upgrade-problems-and-solutions.md b/docs/_posts/2024-01-15-sitecore-10-upgrade-problems-and-solutions.md index 3513584..2541fba 100644 --- a/docs/_posts/2024-01-15-sitecore-10-upgrade-problems-and-solutions.md +++ b/docs/_posts/2024-01-15-sitecore-10-upgrade-problems-and-solutions.md @@ -163,7 +163,7 @@ We developed a custom SettingProvider and started using it instead of queries or ## Problem: System.OutOfMemory Exception -After we switched to Sitecore 10 with Docker and imported the databases from the production system, many developers in the team experienced this exception. +After we switched to Sitecore 10 with Docker and imported the databases from the production system, several developers in the team experienced this exception. Either cm was unhealthy, or after some time it was becoming unhealthy. When we check logs on the docker or inspect the container, we would always see this error popping up. Also, the Sitecore system needed to be faster to work on.