SFignore: The .forceignore Salesforce SFDX Plugin

Salesforce SFDX projects are a great way to build both declaratively and through code for the Salesforce platform. It’s very common to want to ignore particular files from being pushed or pulled between Orgs and your local project, and this is achieved through .forceignore file. The file has some odd (and undocumented) syntax however, and the process is also known to have a few bugs, and getting the right entries in the file can be hard… and that’s where the SFignore SFDX plugin comes in.

The .forceignore file and the process behind it is sprinkled with black magic – Todd Halfpenny, 2020

I’ve created the SFignore plugin initially through an internal need for the work I’ve been doing with the Caddify project at MobileCaddy. A lot of this work has been around using Salesforce 2GP (second generation packaging) tools to create packages for our new product. Our workflow includes pushing, pulling, deploying to many different shape orgs and includes a fair bit of code and metadata that is used solely for non-production scenarios (test setup, demo data, org cleaning, etc) and we want to make sure that nothing accidentally gets put into our managed package releases. The .forceignore file that is used by the SFDX CLI tooling and tracking allows us to do this – or most of it at least… but it’s syntax is nuanced and is lacking in documentation.

The SFignore plugin gives me an easier way to add entries to the .forceignore file, by taking away the guessing of syntax and the need to remember the correct suffixes for the different metadata types. This is useful, as would you know (or remember) if the correct suffix for a SiteDotCom entry should be SiteDotCom, siteDotCom, or site? And what about AppMenu? Would you know whether to use appMenu, AppMenu, Menu, menu? Only one of these is right, and the syntax differs further depending on whether the change is local or remote. Oh you also need to encode (some) special characters too… if you didn’t know that then this could be why your entry for “Custom: Sales Profile.profile” isn’t working as you expected.

The initial release only supports entries for remote changes, and only a subset of metadata types that I’ve had to use so far… but the roadmap for it includes;

  • Support for local syntax
  • Wildcarding – currently only supports specific entries
  • An extension for vscode.

Here’s an example of using the plugin, where we’re wanting to add an entry to ignore pulls for the profile Custom: Sales Profile.

sfdx sfignore:add -n "Custom: Sales Profile" -m Profile

This results in the following entry being added;

Custom%3A Sales Profile.profile

The -m flag specifies the metadata type, and the valid values should match those as seen on Salesforce’s metadata coverage report and the output of a sfdx force:source:status command.

It should also be noted that something’s appear to be impossible to achieve with the .forceignore file, including;

  • Adding some tests – yeah, sorry
  • Specifying specific custom fields
  • Specifying specific custom metadata
  • Specifying specific record types

If you know how to achieve the above I’d be very happy to hear about it.

You can find the source for SFignore SFDX plugin on github, and you can download it from the npm registry too

sfdx plugins:install sfignore

If you use the plugin and need more metadata types added then please raise an issue on github, or even better fork the repo and create a PR.

sf-package-version-checker – SFDX Plugin to notify on completion of Salesforce Package Builds

If you’ve ever built Salesforce packages with the SFDX commands (in fact long before this) you’ll know that the creation of a package can take some time, especially if your package has dependencies.

At MobileCaddy we’ve been adopting the SFDX CLI as much as we can – and in fact embracing the SFDX ethos as a whole – and recently we’ve been working with the Salesforce second-generation packaging (2GP). During this I’ve found that the standard SFDX command to create a package version would continue to give me status updates every 30 seconds for 10 minutes by default, and even though I could set the overall timeout to a longer value (using the –wait flag, and specifying a number of minutes) I often forgot that the task was running and found myself forgetting to watch the terminal window. What I really wanted was something that would notify once the build had completed successfully (or erroneously).

So, during one of the package builds (~25 minutes in this case, if I remember correctly) I put together the basis for a new SFDX plugin that I could run to monitor the latest package build request, and then ping up a desktop notification when it had completed.

I was actually on the line-up for the (now postponed) CzechDreamin’ 2020, with a talk titled “Take your SFDX Plugins to the Next Level”. The talk covers many ways to interact with SFDX plugins other than via the CLI, and one of the topics included was the use of the node-notifier npm module to create native desktop notifications, and so I put this to good use.

You can very easily support basic (and more advanced) notifications with node-notifier for Mac, Linux and Windows environments; here’s some sample code (similar to that used in my plugin);

First import node-notifier (after installing it with npm/yarn)

import * as notifier from 'node-notifier'

Then to use it have code similar to this;

notifier.notify({
 'title': 'Latest Packaging Version Creation Complete',
 'subtitle': ‘Success’,
 'message': SubscriberPackageVersionId: ' + res.SubscriberPackageVersionId
 'icon': iconPath,
 'sound': true,
 'timeout': 30
 });

This results in this type of experience;

The source code (with little over 100 lines of actual logic) can be found in the github repo, and the plugin can be installed as an SFDX CLI plugin and run with the following commands;

$ sfdx plugins:install sf-package-version-checker
$ 
$ sfdx pkgvsn:monitor

How I Archived sessions on London’s Calling site

Past conference sessions are a valuable asset for conference organisers, so for the London’s Calling Salesforce community event I came up with a way to archive them, and now you can too.

For the second year I was tasked with maintaining the website for Europe’s largest Salesforce community event – London’s Calling. And running up to the launch of the this years CFP for speakers and sponsorship registration I wanted to leverage the incredible resources that we had in the form of the sessions for the past two years.

Seeing that our site was powered by WordPress – using the Tyler conference theme – and that I have released a couple of WordPress plugins before (including the 5* rated Widgets on Pages) I wrote the Past Events Extension plugin to do just what was needed.

The free version enables site admins to archive sessions, which are then listed on a Past Sessions page. The Pro version includes support for a shortcode that can be used in any page or post to list these archived sessions for a given date range, meaning that you could for example create pages for each past event. The latter is what has been used on the London’s Calling site.

Running a not-for-profit event? Get 50% of the annual license now!

Other PRO features are;

  • Additional Video setting – Add embedded video for each past-session (e.g. from Vimeo, YouTube); ideal to show off past presentations.
  • Additional Slide-deck link setting – Add a link to slide-decks used for each session.
  • Enhanced Single-Session page – Shows the embedded video and slide links

So what are you waiting for? Go grab the free version now and use your previous events to help sell tickets and gain sponsors.

From a Problem to 100,000 Downloads

It was 1054 days ago that I first wanted to place a WordPress widget into a post I was writing. Whether it was for a client site or personal one I can’t remember… the important thing is that out of the solution I came up with emerged the Widgets On Pages WordPress plugin.

The plugin has undergone very little change since it’s 0.0.1 check-in to the WordPress.org plugin repository but since then it’s had very favourable reviews and been included in several blog posts and conference talks. But more importantly, for today at least, it’s now been downloaded over 100,000 times!

It has a current rating of 4.7/5 and at the time of writing sits as the 105th most highest rated plugin on the WordPress.org repository. 105th might not seem too good but it should be noted there are over 23,800 plugins in the repo.

Lanyrd Splat WordPress Widget Plugin

Last night I noticed that the Lanyrd event info that was meant to be listed in my blog sidebar was no longer working. I was, at the time, using the My Lanyrd Widget which was up to a time working well… but then I noticed it had just stopped working.

I had a quick browse on the Lanyrd site and noticed that had some official JS and code which could be used to display a badge on your site showing pretty much the same info as the above mentioned widget had been doing.

And so, after an hour or so of coding the Lanyrd Splat Widget plugin for WordPress was born. I immediately requested a repo on the WordPress.org site and as soon as this was approved my checked in the code and the Lanyrd Splat Widget was launched!

Lanyrd info as a WordPress widget
The Lanyrd Widget in action

The plugin has settings for the maximum number of events to show as well as the format and of course the Lanyrd username of the info to use.

Lanyrd Widget Settings
The Lanyrd Widget Settings

The plugin pulls the info from Lanyrd  every time the page is loaded, which is obviously not ideal. I had toyed with the idea of using the ics feed which Lanyrd provides and then using transient storage inside WordPress to temporarily cache the data. I decided to not use this for the time as the route I’ve taken pulls only the data needed and also supports richer data. My view on this may change in time… we will just have to see how this performs.

The Lanyrd Splat Widget can be downloaded from the official WordPress.org plugin repository.