Generate Google Lighthouse Reports with Docker using PowerShell

While browsing Docker Hub, I came across this nifty Google Lighthouse Docker image (by Jay Moulin) which allows you to execute a Lighthouse audit against a given URL in a containerized application - made possible by the Google Chrome Headless Docker base image.  From a practical standpoint, this feels more reliable than running Lighthouse in the Chrome browser where extensions and other variables can easily interfere with the results of the audit. 

You can check out the Dockerfile for this image here: 

https://github.com/femtopixel/docker-google-lighthouse

Consuming it is pretty straightforward.  With Docker installed and running while switched to Linux containers, two commands are all you need:

Additional options for the Lighthouse audit, like controlling the emulated device form factor (mobile vs. desktop), controlling the throttling method (devtools, provided, simulate), or defining specific categories (Accessibility, Best Practices, Performance, PWA, or SEO) can be included after the URL.

 

However, that's quite a bit of text to remember, and memorizing a bunch of Lighthouse CLI options are not something I see myself doing.  😋 

BUT - we can make this tool more approachable by wrapping it in a PowerShell script. 😍

The name of the game is simplicity: execute .\LighthouseReport.ps1 from a PowerShell terminal, pass in a URL/standard Lighthouse options, and let it run. 

---

👨‍💻 A Little PowerShell

In a new PowerShell file, we'll add a mandatory string parameter called $Url. 

We'll also include non-mandatory string parameters:

• $FormFactor
• Valid options for the '--emulated-form-factor=' flag are 'none', 'desktop', or 'mobile'. 
  
  
• Default value when no parameter is provided will be 'desktop'
  
  
• $Throttling
• Valid options for the '--throttling-method=' flag are 'devtools', 'provided', or 'simulate'. 
  
  
• Default value when no parameter is provided will be 'provided.'
  
  
• $Categories (array of strings)
• Valid options for the '--only-categories=' flag are 'accessibility', 'best-practices', 'performance', 'pwa', 'seo'. 
  
  
• Default value when no parameter is provided will a comma-delimited string of all applicable categories 'accessibility,best-practices,performance,pwa,seo'
  
  
• $DestinationPath
• The local path to where the report will be 'dropped.' (used as a volume mapping to the container's '/home/chrome/reports' directory)
  
  
• Default value when no parameter is provided will be "C:/lighthouse"

We'll add the docker pull command for femtopixel/google-lighthouse first.  During the initial execution of the script,  all required images will be downloaded from Docker Hub.  If your image becomes stale or a newer version is available, this will automatically update the image. 

Then add the docker run command with the -v flag to mount a volume to map the local $DestinationPath to the /home/chrome/reports directory on the container. Include the $URL parameter at the end, and all options following:

When the docker run command is executed, Docker will take over, and Lighthouse will begin to execute on the container. Once completed, a .html file will be available in the $DestinationPath. 

To take it a step further, we can open the $DestinationPath in Windows Explorer by using an Invoke-Item command:

If we want to open the .html report, we can set the PowerShell location to the $DestinationPath, followed by an Invoke-Item where we pass in Get-ChildItem latest .html file.

Simple - yet effective!

---

🏁 Final Script

---

⌨ Example Usage

Desktop form factor auditing all categories:

Desktop form factor auditing Best Practices, Performance and SEO only:

 

Mobile form factor auditing Performance only:

 

  

💡 TIP: When setting a parameter (-FormFactor, -Throttling, -Categories), you can use Ctrl+Space to display valid options and hit enter to select it.

---

👍 Result

🙌 Feel free to grab a copy and modify it to your liking.

Read the full post →

Azure PaaS Sitecore Logs using AzureAILogs.html

When hosting Sitecore XP solutions on Azure PaaS – you’ll quickly find out that accessing and viewing Sitecore logs is different than you may be used to.

Sitecore has a great Knowledgebase article available (Access logs and diagnostics data in Sitecore XP on Azure Web Apps) which describes a couple approaches for obtaining the Sitecore logs on a PaaS environment using both Azure Application Insights or FTP.

Grabbing recent log files is pretty straightforward once you’ve configured FTP credentials to access your Sitecore instance.  Simply FTP into the instance (Filezilla is my favorite), navigate to /LogFiles/Application, sort by date, and download the relevant logs.

My preferred approach, however, is utilizing the AzureAILogs.html file that Sitecore provides within the “Using Azure Application Insights REST API” section of the KB article:

Enabling the API Key also requires a few clicks in the Azure portal, but the instructions for enabling this feature are outlined well – and it only takes a couple of minutes to complete.

If you download and open the HTML file locally, the output is pretty sweet:

Once you input the Sitecore app's App Insights App ID and API key, clicking the 'Update Roles' button retrieves the relevant roles for the application (CM, CD, Reporting, and Processing).

Having obtained the roles, you can select one or multiple roles, configure any specific options (recency // checkbox to only show errors // number of entries), and click the 'Get logs from AI' button to make the call.

You’ll end up with filtered and descending log entries you’d typically get from Sitecore logs:

The bonus here is the 'Download logs' button will download the log files – which are also compatible with Sitecore Log Analyzer.

This is super handy as-is, but I also wanted to make it a little easier to access online.  Specifically:

1. I don’t want to input in the App ID and API key every time I want to use this tool.
2. I want to access this from our CM environment, similar to any other admin page.

By adding a few old-fashioned lines of Javascript to my copy of the AzureAILogs.html file (just before the requestHandler function), the page was able to accept two URL query parameters (‘appid’ and ‘apikey’) to prefill the two input values.


For example:
AzureAILogs.html?appid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx&apikey=0000000000000000000000000000000000000000

In order to access this from our CM Authoring environment, I simply added the HTML page to the /sitecore/admin directory.

Once I was able to hit the page from the server, I tacked on our App ID and API Key to the URL and bookmarked the page.   Voila - simple yet effective.

Of course, this is just one of many ways to view Sitecore logs on a PaaS environment - but I found it to be one of the most useful.

Read the full post →

Basic Sitecore Audit Trail with Powershell

---

Update: This report has been included in the latest version SPE v5.0: 
https://github.com/SitecorePowerShell/Console/issues/1033

---

Here's a question posted to our internal Sitecore Slack channel yesterday:

The answer was 'no'.

This isn't the first time our clients have requested 'Audit Trail' functionality before, either. And we're talking about the basics here:

• • When did a user log in?
• • When did a user log out?
• • Who published what, and when?
• • When was this item's workflow executed and by whom?

Unfortunately, there isn't an 'out of the box' solution to easily obtain this data.
The most common "solution" has always been to utilize the Sitecore Log Analyzer's Audit tab - which is great for developers, but not for CMS users.

This tool has saved my sanity so many times. 

Others in the community have shared promising solutions in the past, most of which have become unsupported over time. The Sitecore Audit Trail Marketplace module, for example, was last updated in 2015 and only supports up to version 7.5 (fun fact: mainstream support for this version ended in December 2017!).  Additionally, the setup was heavy - requiring a custom database connection. It also, unfortunately,  had it some known issues associated with it.
While the feature set was fairly extensive, a simpler solution still wasn't available.

The Advanced System Reporter also has an audit feature, but again the last time this module was updated was in 2015 and supports up to version 8.0.

And then it hit me.

POWERSHELL!!!!

You've got to know this by now...my default reaction to any problem is to ask myself: "can this be done using Powershell?".

The idea was to create a Powershell report that consumes the accessible Sitecore log files which already contain the data we need.  The report should include all lines marked as 'AUDIT'' and split into columns.  The user should be able to provide a date range to narrow down the audit.  

Powershell would automatically provide the rest: keyword filtering, sorting, exporting, etc. 

Let's script it.

In order to allow a user to configure a date range, we need to create an interactive dialog: 

The result:

If the user clicks cancel, we'll want to abort the whole operation.
Otherwise, we'll proceed and create the properties needed for our final ListView.
We'll call a function named Get-Audit where our logic will process.

Within the Get-Audit function, we first obtain the location of the Sitecore log folder (UPDATE: We'll use $SitecoreLogFolder instead. SPE creates a variable $SitecoreLogFolder and resolves the path for you: https://doc.sitecorepowershell.com/working-with-items/variables).  We'll the pull the log files from the resolved log path and filter out everything but the standard log. files:

We'll make sure the user has selected a date range and filter the list of files using those inputs. If a user didn't set a date range, we'll simply use the original file set - which will display the most recent entries. While we're at it, we'll define a 'regex' string used to filter only AUDIT items, and an array object to hold our line objects:

We'll start a loop based on our file count. From there, we can get the contents of the file.

We need a way to include the date for each line object (specifically for our final sorting), so we'll build out a simple date string which we'll use later.

We'll now loop through each line in the file and check if it's marked as 'AUDIT'. If the condition matches, we'll append the simple date string we created previously to the beginning of the line string and sanitize the string by removing double-spaces. In some cases, the audit line will contain ManagedPoolThread #XX instead of an ID. We'll sanitize this as well.

The line now looks like this:
8/17/2018 8324 00:13:47 INFO AUDIT (sitecore\Anonymous): Logout

We'll use the space between each data point to our advantage and split each property into individual objects. The username requires some general sanitation, but more importantly, we'll build out one more DateTime object which we'll use to sort the lines before returning our array. 

Finally, we sort and return our array for the table to process.

Final Script

Putting it all together, our script looks like this:

When the script runs, we get a pretty clear view of who's been doing what:

As always, feel free to use, modify, and build on it as you see fit. This has only been tested on a handful of environments so far, so bugs are still possible.
If you do spot any issues, feel free to report them in the comments - or make the necessary changes and submit a pull request to https://github.com/strezag/sitecore-audit-trail-powershell.

Happy SitecorePowershelling!

Read the full post →