Microsoft had announced it was removing Publisher from Microsoft 365, and she, my aunt, and my cousin all had years of files made in it. Newsletters, wedding programs, labels, the family photo calendar we got every Christmas. She wanted to know if I could help them get their files out before the app went away.

I had not used Publisher in years. But I knew exactly what she meant, because I had used it for our own wedding program and thank-you cards. Publisher was the tool ordinary people used to make something that came out looking finished. And it was a tool you bought once.

The more I looked, the bigger the problem got. Church offices build the weekly bulletin from last week’s .pub file. Schools have years of newsletters and certificates. Nonprofits, small businesses, the volunteer who makes the monthly newsletter. The suggested replacements are good tools, but they are subscriptions, and none of them open the files people already have. Everyone was being told to start over.

So I started building.

First, save the files

The urgent problem was the archive. If Publisher was going away, people needed a way to turn years of .pub files into something they could always open.

The first thing I built was a converter: drop a whole folder of .pub files and get exact PDFs back, page for page. My family tried it the first day. My mom’s reply was “Oh hallelujah!”

That saved the past. It didn’t help with next week’s bulletin.

Then, keep editing

A PDF only saves what you’ve already made. The real question was why Publisher users should have to stop publishing at all.

So I built PubKeep, a desktop app for Windows and Mac that opens your .pub files and keeps them editable. The same text boxes, master pages, and fold-over booklets you already use, without Publisher on the computer. No converting first, and nothing to rebuild.

It’s a one-time purchase, not a subscription. You buy it once and it keeps working. And it saves to .pubk, an open format you can always get your work out of. After watching people lose access to their own work, I wasn’t going to build another lock-in.

The people who helped build it

Before launch, more than 1,100 organizations signed up for early access, most of them churches. They opened their own bulletins and newsletters, told us what was missing, and sent the files that didn’t come through right so we could fix them.

Some of what they wrote back has stuck with me. One church secretary said she got more done in 45 minutes than she had in other programs all week. An author told us she had thousands of Publisher files from 30 years of work, and that PubKeep was better than she had dared hope for.

Launch

PubKeep went on sale September 30, the day before Microsoft pulled Publisher from Microsoft 365, with a free 7-day trial.

What’s next

Support for the perpetual versions of Publisher ends October 13, so the next few weeks are about helping everyone who still depends on it. We keep widening what PubKeep opens, and the files people send us decide what we work on next.

If you or someone you know has a pile of .pub files, PubKeep is at pubkeep.com, and the free trial needs no card.

And if your mom calls about her Publisher files, now you know what to tell her.

The post Publisher is gone. Here’s why I built PubKeep. first appeared on Adam Anderly.

Here are some gists that tackle these concerns:

Caching Behavior (using ASP.NET Core IDistributedCache):

For caching, I’m using a separately defined CachePolicy similar to a FluentValidation Validator class.

Fallback Behavior (using Polly):

For Fallback and Retry behavior, I’m using separate interfaces IFallbackHandler and IRetryableRequest to get the behavior.

Retry Behavior (using Polly):

These can all be combined as well and work based on the order they’re registered in Startup.cs. In my case, I want my main Handle method to retry, then, optionally, fallback to my HandleFallback, then finally cache the result based on the defined CachePolicy.

I’m debating between using separately defined classes/policies (like FluentValidation Validators) vs. making Handlers implement the interfaces to get the behavior. On one hand, if they’re separate, I could move the Cache, Fallback and Retry policies to separate files, folders, etc. and keep my main MediatR handlers very lean and clean. If you want to see them in the same place, you could put them in the same file like many of Jimmy Bogard’s examples with Validators, etc. But if the files get too big and you want to separate them out, you could do that. However, with Retry and Fallback, it’s kind of nice seeing that with the main request handler.

Of course, all this gets wired-up and registered in Startup.cs. I’m using Scrutor to aid in discovery my Caching, Fallback and Retry policies. See below.

What do you think? Which approach do you prefer? Let me know in the comments.

The post Cross-Cutting Concerns with MediatR Pipeline Behaviors first appeared on Adam Anderly.

This trait is useful when you have dates on models that you need to display in the user’s timezone.

<pre class="lang:php decode:true">// app\Traits\UserTimezoneAware.php
namespace App\Traits;
trait UserTimezoneAware
{
    /**
     * The attribute name containing the timezone (defaults to "timezone").
     *
     * @var string
     */
    public $timezoneAttribute = 'timezone';
     
    /**
     * Return the passed date in the user's timezone (or default to the app timezone)
     *
     * @return string
    */
    public function getDateToUserTimezone($date, $timezone = null)
    {
        if ($timezone == null) {
            if (Auth::check()) {
                $timezone = Auth::user()->timezone;
            } else {
                $timezone = Config::get('app.timezone');
            }
        }
        $datetime = new DateTime($date);
        $datetime->setTimezone(new datetimezone($timezone));
        
        return $datetime->format('c');
    }   
}

</pre>

It’s a simple trait you can drop onto one of your eloquent models to add timezone support like so:

<pre class="lang:php decode:true">// app\Models\User.php
namespace App\Models;

use App\Traits\UserTimezoneAware

class User
{
    use UserTimezoneAware;

    public function getLastLoginAttribute()
    {
        return $this->getDateToUserTimezone($this->attributes['last_login']);
    }
}
</pre>

Now when you access the $user->lastLogin attribute anywhere in your app, you’ll get the date in the user’s timezone.

The UserTimezoneAware trait expects the model to have a timezone attribute. If your column/attribute is named something other than timezone simply override the $timezoneAttribute property on the UserTimezoneAware trait.

<pre class="lang:php decode:true">namespace App\Models;

use App\Traits\UserTimezoneAware
 
class User
{
    use UserTimezoneAware;

    public $timezoneAttribute= 'time_zone';
}</pre>

Enjoy!

The post Laravel User Timezone Aware Trait first appeared on Adam Anderly.

This first one I use quite often.

// app\Traits\HasGravatar.php
namespace App\Traits;

trait HasGravatar
{
    
    /**
     * The attribute name containing the email address.
     *
     * @var string
     */
    public $gravatarEmail = 'email';
    
    /**
     * Get the model's gravatar
     *
     * @return string
     */
    public function getGravatarAttribute()
    {
        $hash = md5(strtolower(trim($this->attributes[$this->gravatarEmail])));
        return "https://www.gravatar.com/avatar/$hash";
    }

}

It’s a simple trait you can drop onto one of your eloquent models to add gravatar support like so:

// app\Models\User.php
namespace App\Models;

use App\Traits\HasGravatar

class User
{
    use HasGravatar;
}

Now you can do something like this in your blade views:

<img src="{{ Auth::user()->gravatar }}">

And you’ll get the gravatar.com URL you’re expecting. No need to create a gravatar column, variable, method, or anything else.

The HasGravatar Trait expects the model to have an email attribute. If your column/attribute is named something other than email simply override the $gravatarEmail property on the HasGravatar trait.

namespace App\Models;

use App\Traits\HasGravatar

class User
{
    use HasGravatar;

    public $gravatarEmail = 'email_address';
}

Enjoy!

The post Useful Laravel Model Traits: Gravatar first appeared on Adam Anderly.

Hence, the Transformable trait was born. It’s a simple PHP trait that you drop into your model and then override the $transformation_map property to specify your consumable model attributes.

Here’s an example:

namespace App\Models;

use Illuminate\Database\Eloquent\Model;
use App\Traits\Transformable;

class Group extends Model
{
    use Transformable;

    protected $transformation_map = [
        'Group_ID' => 'id',
        'Name' => 'name',
        'PublicGroup' => 'public',
    ];
}

A quick explanation: we’re importing the Transformable trait (which I’ll cover shortly) and then we’re providing a database column name-to-consumable attribute name mapping. That’s it.

A consumer of this model will not see the underlying database column names on the left hand of the mapping such as “Group_ID”, “Name”, or “PublicGroup.” Instead, they’ll see the names on the right hand side: “id”, “name” and “public.” In essence, it’s a simple transformer. Here’s an example usage:

use App\Models\Group;

class GroupsController
{
    public function index()
    {
        return Group::all();
    }
}

With a call to the above GroupsController@index method, we’d end up with the following JSON:

[
    {
        "id": 1,
        "name": "Group 1",
        "public": "0"
    },
    {
        "id": 2,
        "name": "Group 2",
        "public": "0"
    }
}

Additionally, we can create the model specifying the consumable attribute names (not the database column names):

$group = new App\Models\Group(['name' => 'Group 3', 'public' => true]);

// Calling this
$group->toJson();

// Will yield this
{
    "id": 3,
    "name": "Group 3",
    "public":"1"
}

The magic of this is in the Transformable trait. Normally, to achieve this, we’d have to specify the $visible and $appends properties on our model and provide get and set mutators for each attribute mapping. Instead, with Transformable, we simply provide the $transformation_map and the Transformable trait takes care of the rest.

It does this by overriding several methods of the Eloquent model that determine if get and set mutators exist to include checking the $transformation_map property. This is how it can return you an instance of your model as well as create an instance of your model with the consumable attribute names without you needing to specify the source database column names.

I’m working on an enhancement to Transformable to allow queries (i.e. where* methods) on the models so that you can query with the consumable attribute names and not the database column names. As soon as I wrap up those changes, I’ll look at making this a composer package.

Here’s the entire trait implementation:

namespace App\Traits;

use Illuminate\Support\Str;

Trait Transformable
{
	protected $transformation_map = [];

    /**
     * Determine if a get mutator exists for an attribute.
     *
     * @param  string  $key
     * @return bool
     */
    public function hasGetMutator($key)
    {
        return $this->keyExistsInTransformationMap($key) || parent::hasGetMutator($key);
    }

    /**
     * Determine if a set mutator exists for an attribute.
     *
     * @param  string  $key
     * @return bool
     */
    public function hasSetMutator($key)
    {
        return $this->keyExistsInTransformationMap($key) || parent::hasSetMutator($key);
    }

    /**
     * Get the value of an attribute using its mutator.
     *
     * @param  string  $key
     * @param  mixed  $value
     * @return mixed
     */
    protected function mutateAttribute($key, $value)
    {
        if ($this->keyExistsInTransformationMap($key)) {
            return $this->{$this->getTransformationMapInverse()[$key]};
        }
        return parent::mutateAttribute($key, $value);
    }

    /**
     * Set a given attribute on the model.
     *
     * @param  string  $key
     * @param  mixed  $value
     * @return $this
     */
    public function setAttribute($key, $value)
    {
        if ($this->keyExistsInTransformationMap($key)) {
            if (method_exists($this, 'set'.Str::studly($key).'Attribute')) {
                parent::setAttribute($key, $value);
            }
            $key = $this->getTransformationMapInverse()[$key];
        }
        return parent::setAttribute($key, $value);
    }

    public function keyExistsInTransformationMap($key)
    {
        return array_key_exists($key, $this->getTransformationMapInverse());
    }

    public function getTransformationMapInverse()
    {
        return array_flip($this->transformation_map);
    }
}

This could certainly be enhanced further to support casting to/from datatypes and supporting compound properties via a Closure or similar.

Let me know what you think in the comments.

The post Laravel Transformable – An Eloquent Model Trait for Consumable Models first appeared on Adam Anderly.