Byta till responsiv webbdesign

Är det dags att göra webbplatsen tillgänglig i mobilen? Då har ni säkert stött på termen responsiv design. Responsiv design innebär att innehållet på en webbplats anpassar sig efter vilken typ av enhet som besökaren använder när denne besöker webbplatsen. 

Funderar ni då på om ni ska anpassa den befintliga webbplatsen eller bygga nytt? Har ni idag en webbplats uppbyggd med WebForms (t.ex. EPiServer 6 och tidigare versioner), ska ni definitivt riva allting och bygga nytt med designmönstret MVC. Anledningarna till detta är många.

Repsonsiv webbdesign kräver att den html som renderas ut till webbläsaren följer standarden HTML5 och använder man WebForms så är den html som kommer från Microsofts standard-kontroller i ASP.Net lite ålderstigen och följer inte alltid HTML5-standarden. Det kan leda till en hel del kostsamma specialanpassningar på den äldre koden. Den grundläggande strukturen på html:en följer heller inte nödvändigtvis en struktur som är enkel att dela upp i ett responsivt ramverk.

MVC använder i sina vyer html-kod som är väldigt lik standard-html vilket gör att arbetet med att implementera den html-kod som frontend-utvecklare skapat utifrån er design till sidtyperna i EPiServer CMS går betydligt snabbare på en webbplats som bygger på MVC.

MVC-mönstret erbjuder möjlighet att skapa testbar kod då det grafiska gränssnittet är helt separerat från affärslogik och domänmodeller.

Den tydliga separationen av skikt skapar även bättre förutsättningar för förvaltningen av koden då ansvarsområden för olika specialister är mycket mer tydligt med MVC.

Så ska ni byta till responsivt, riv och bygg nytt på MVC, det ger en framtidssäker plattform som är enklare att testa, enklare att få in modern html i EPiServer, billigare att förvalta och som då i slutändan kommer ge en lägre total ägandekostnad för er webbplats.

Vill du veta mer? Klicka här 

Varför behöver man egentligen en testmiljö och stagemiljö?

Att man har en bra stagemiljö, d.v.s. en miljö som så mycket som möjligt liknar produktionsmiljön och där man ordentligt testar den kod som ska produktionssättas, är för oss givet. I den här artikeln ska vi göra ett försök att förklara varför det är så viktigt.

En del kunder vill att man driftsätter små ändringar direkt till deras produktionsmiljö och visst kan man göra det men då riskerar man en ostabil produktionsmiljö där det kanske krävs ytterligare en driftsättning för att få bort en bugg som dök upp från ingenstans vilket resulterar i onödig nedtid. Vi rekommenderar alltid våra kunder att testa ordentligt även den minsta av ändringar. Testning av kod är som ost i matlagning, det kan aldrig bli för mycket!

Hur många miljöer behövs?

Så hur många miljöer behöver man testa i då? Vår rekommendation är att man har tre olika miljöer. Test-, stage- och produktionsmiljö. Testmiljön ligger oftast hos den partner som utvecklar och sköter förvaltningen av webbplatsen. Ett bra tips är att alltid låta någon annan än den som utvecklat koden testa den nya funktionen i testmiljön innan man går vidare. Denna miljö är också lämplig att använda i utbildningssyfte för kundens redaktörer och ovanan användare eller om kunden vill prova att labba med idéer på block, sidor, personalisering osv.

Stagemiljön

Stagemiljön ska ligga på samma ställe som produktionsmiljön och vara så lik produktionsmiljön som möjligt. I och med att stage- och produktionsmiljön ligger på samma ställe är det lätt att upptäcka stora showstoppers innan driftsättning t.ex. att en port i en brandvägg måste öppnas för att man ska kunna kommunicera med en extern webbservice. I stagemiljön sker den slutgiltiga testningen av den nya koden och först när allt fungerar där och är godkänt lyfter man koden till produktionsmiljön.

I exemplet ovan för en publik webbplats krävs en EPiServer 7 CMS One Site-licens som gäller för en site på tre miljöer, dvs en produktionsmiljö och två testmiljöer. Beroende på vad du som kund har för krav för dina testmiljöer och produktionsmiljöer kan det krävas fler servers, t ex om man lastbalanserar sin webbplats. En lämplig set-up och licenskostnad är något som vi partners hjälper till med att ta fram.

Sammanfattning

Låter det som onödigt komplicerat med tester i två miljöer innan man driftsätter? Ja, det är några extra steg men vi lovar att i slutändan sparar du både tid och pengar. Nedan följer en sammanfattning på vad du ska tänka på:

  • Ha helst tre miljöer. Test-, stage- och produktionsmiljö.
  • Välj bort testmijön om du måste välja bort någon, stagemiljön är ett måste.
  • Se alltid till att någon annan än utvecklaren testar koden.
  • Driftsätt aldrig direkt till produktionsmiljön och undvik driftsättningar på fredagar. Ingen gillar onödigt helgarbete.
  • Se till att stagemijön är så lik produktionsmiljön som möjligt. Kopiera gärna produktionsmiljön till stagemijön en gång i månaden.
  • Testa, testa, testa! Och när du klar, testa en gång till.


Är du osäker på viken väg du ska välja så ta kontakt med oss så kan vi tillsammans hitta den lösning som är bäst för er.

EPiServer Search

If you are having problems indexing your EPiServer 7 site using Lucene search try to add your sites url to the servers host file. Then try to index your site again. We did our first deploy of an EPiServer 7 site which was using Lucene search to a stage server a while ago.

Everything was working well in everyone’s development environment, but on the stage server we couldn’t get search to work. The server was a Windows 2008 R2, and at first the indexingservice wasn't installed. But after some fixes we managed to get the indexingservice installed, but it still wouldn’t index any content.

If you want to try indexing your site manually you could trigger it on this url

http://[local.site.url]/episerver/cms/admin/indexcontent.aspx

Check that the url in the web.config is correct:

<episerver.search>
  <services>
     <add name="serviceName" ="http://[local.site.url]/IndexingService/IndexingService.svc" />
  </services>
</episerver.search>

Even though we changed [local.site.url] to the stage servers address, it would not index the site. Probably because the servers address will respond with the public ip-address. So to fix this just add the sites url in the servers host file, and try to index the site again. This was at least the solution for our problem.

Upgrading EPiServer CMS 6 to EPiServer CMS 7

According to EPiServer there shouldn't be any problem when upgrading an EPiServer CMS 6 R2 site to EPiServer CMS7, but I was running across this problem every time i tried on a specific site.

An unhandled error has occured: The path is not of a legal form.
When executing


At C:\Program Files (x86)\EPiServer\Framework\7.0.859.1\Install\System Scripts\


Install Module Package.ps1:157 char:16


+ Add-EPiXmlBlock <<<<  -TargetFilePath $packagesConfigPath -ElementXPath "/packages" –XmlBlock $packageRegistrationXml                 


True = Get-EPiIsBulkInstalling


An unhandled error has occured: The path is not of a legal form.


When executing


At C:\Program Files (x86)\EPiServer\Framework\7.0.859.1\Install\System Scripts\
Install Module Package.ps1:157 char:16


+ Add-EPiXmlBlock <<<<  -TargetFilePath $packagesConfigPath -ElementXPath "/packages" –XmlBlock $packageRegistrationXml

The sites path was containing Swedish character letter “ö” which I thought was the problem. Tried to remove those letters and gave the upgrade another try and still got the same problem.

The solution was to move the VPP that was on a share and was not containing any suspicious letters, to the local computer. Took me a couple of hours to figure it out, hope this saves some hours for someone else.