DEV Community: Jack Whiting

Lazy Loading Vanilla JS with WebPack (+ Laravel Mix)

Jack Whiting — Thu, 05 Aug 2021 01:22:48 +0000

I recently worked on a project where the site was incredibly JavaScript heavy, this caused the page to be requesting ~3mb of JavaScript every page load.

Since the site was a commerce site, this would have been killer and caused a lot of lost sales, so I had to find a way to optimise the script.

Installation

I use Webpack for pretty much all of my projects these days. Webpack is powerful but frankly a pain in the ass to configure, so to navigate this I use Laravel Mix which coats the config into a nice, user-friendly, script.

If you don't have these installed so far, you can ahead and get things kicked off by installing laravel-mix.

npm install laravel-mix --save-dev

Followed by creating a webpack.mix.js file to house our configuration.

touch webpack.mix.js

We can set up some barebones configuration by telling Mix what file we want to listen to and where we want it output.

const mix = require('laravel-mix')

mix.js('resources/js/site.js', 'public/assets/js')

If you've already got this set up on your end, you can ignore the above steps.

Lazy Loading

Sweet, we've got everything set up that we need in our webpack file. Next, we need to configure how we are going to lazy load things.

In the above config, we're looking for a site.js file, this will house our logic for importing JavaScript.

Let's first look at an example script we might want to import.

Imported Script

I like writing my components/partials as classes that house all of their logic, this stops there being any conflicts between classes relating to different components.

I then extract any common code into a helpers.js file, but this is an article for another day.

Back to our lazy loading. Let us say we had a script to handle a testimonial component. Our basic script may look something like the following:

class Testimonials {
  constructor() {
    console.log('i load')
  }
}

export default Testimonials

Perfect, we've got a class and we are exporting it for use.

Site.js

In our main file, if the JavaScript was global and used on every page we may do something like a simple import and initialise.

import Testimonials from  './partials/Testimonials'

new Testimonials()

This is fine if the JS is used on every page, but our partials won't. To only load this whenever the script is needed, we need to ensure the code is on the page.

We could do this one of many ways, but fundamentally we're just making sure an element exists in the DOM.

import Testimonials from  './partials/Testimonials'

if (document.querySelector('.testimonials')) {
    new Testimonials()
}

Okay, but we're not there yet. We're still bringing the JavaScript into our main bundle. Even if we aren't calling the code, it's still there taking up space.

To ensure we only load the JS when needed, we need to rewrite our import function.

if (document.querySelector('.testimonials')) {
  import(
    './partials/Testimonials'
  ).then((Testimonials) => {
    new Testimonials.default()
  })
}

You may notice the .default appended to the module here, this is because when using import() on ES6 modules you must reference the .default property as it's the actual module object that will be returned when the promise is resolved.

Great, now when compiled this will only include a small bit of code telling the browser that if it finds the element with a class of .testimonials then we need to load in another script.

Compiling

Great, if we run mix we should see the code compiling. Once done you should get something like the following.

This works, but this isn't exactly a clean output. I like to keep my partials neatly contained in their own folder, and with a better name than resources_js_partials_Testimonials_js.js.

Fortunately, we can fix this by including a small comment in the import function.

if (document.querySelector('.testimonials')) {
  import(
    './partials/Testimonials' /* webpackChunkName: "partials/testimonials" */
  ).then((Testimonials) => {
    new Testimonials.default()
  })
}

If we recompile, we should see the partial is compiled to js/partials/testimonials.js

How to Use

We don't need to import each of these partials into the page, as long as we are including our main output file, in this case site.js. It'll automagically know where and when to import the additional scripts.

If you take a look at the network tab in your browser, you should only see that chunk (partials/testimonials.js) loaded when the querySelector returns something.

Closing Words

I hope this helps you with optimising JavaScript bundles on your site, I know this has helped our websites load a lot better on mobile devices/slow connections especially.

There are so many ways we can optimise our sites on the modern web, however, we sometimes skip past these steps, and the user suffers. For a relatively small code change, you can achieve some big results.

Feel free to share this or reach out to me on Twitter to discuss this.

Creating a Marquee with Tailwind CSS

Jack Whiting — Tue, 29 Jun 2021 10:32:10 +0000

On a recent project, I was tasked with adding a marquee element to display a few key terms. This was required to be on an infinite loop.

Creating the Marquee

I managed to create something simple with just CSS and HTML. The first thing we need to do is get a collection of items that will be used in our Marquee.

<div class="overflow-x-hidden">
    <div class="py-12 animate-marquee whitespace-nowrap ">
        <span class="mx-4 text-4xl">Marquee Item 1</span>
        <span class="mx-4 text-4xl">Marquee Item 2</span>
        <span class="mx-4 text-4xl">Marquee Item 3</span>
        <span class="mx-4 text-4xl">Marquee Item 4</span>
        <span class="mx-4 text-4xl">Marquee Item 5</span>
    </div>
</div>

These items should always take up more space than the screen width otherwise there wouldn't be much point in turning them into a marquee.

Adding Animation

To get the element to move, we'll create an animation that moves the element from 0% (the default position) to -100% - ensuring the element moves off the screen until it reaches the end.

module.exports = {
  extend: {
    animation: {
      marquee: 'marquee 25s linear infinite',
    },
    keyframes: {
      marquee: {
        '0%': { transform: 'translateX(0%)' },
        '100%': { transform: 'translateX(-100%)' },
      }
    },
  }
}

View Demo

Looping the Marquee

Currently, there is a lot of white space that trails the last element until it gets to the edge of the screen and then jumps back to the first item.

We want our marquee to be smoother and look like it's repeating. To do this, we'll need to create a copy of the original marquee elements and add a slightly different animation to it.

Update our HTML

Let's add the second marquee and ensure it's spaced the same as the first one. We then set it as absolute so that we don't have an increase in parent element height. We also apply flex to the parent to ensure the elements sit nicely next to each other.

<div class="relative flex overflow-x-hidden">
  <div class="py-12 animate-marquee whitespace-nowrap">
    <span class="mx-4 text-4xl">Marquee Item 1</span>
    <span class="mx-4 text-4xl">Marquee Item 2</span>
    <span class="mx-4 text-4xl">Marquee Item 3</span>
    <span class="mx-4 text-4xl">Marquee Item 4</span>
    <span class="mx-4 text-4xl">Marquee Item 5</span>
  </div>

  <div class="absolute top-0 py-12 animate-marquee2 whitespace-nowrap">
    <span class="mx-4 text-4xl">Marquee Item 1</span>
    <span class="mx-4 text-4xl">Marquee Item 2</span>
    <span class="mx-4 text-4xl">Marquee Item 3</span>
    <span class="mx-4 text-4xl">Marquee Item 4</span>
    <span class="mx-4 text-4xl">Marquee Item 5</span>
  </div>
</div>

Update Tailwind

Then we can add the second animation for marquee2 to our tailwind.config.js.

module.exports = {
  extend: {
    animation: {
      marquee: 'marquee 25s linear infinite',
      marquee2: 'marquee2 25s linear infinite',
    },
    keyframes: {
      marquee: {
        '0%': { transform: 'translateX(0%)' },
        '100%': { transform: 'translateX(-100%)' },
      },
      marquee2: {
        '0%': { transform: 'translateX(100%)' },
        '100%': { transform: 'translateX(0%)' },
      },
    },
  }
}

Our animation for marquee2 is translating the second element from 100% to 0 at the same speed as the first element, so they will smoothly follow each other.

When the first element reaches the edge of the screen it will snap back to 0% and begin to be translated again. Due to our second element being at the same point there will be no visual interference to the end user.

Demo

You can view a demo of the final code over on the Tailwind CSS Play.

That's it, we're all done. I hope this article helps you.

Creating a Modal with Tailwind & AlpineJS

Jack Whiting — Fri, 26 Mar 2021 00:55:56 +0000

If you haven't tried out Alpine before, it's a minimal JS framework with Vue like syntax that can be integrated into any website by just linking to the CDN.

Alpine combined with Tailwind allows for rapid development of websites - so it's understandable why I'm a fan.

In this article, we'll talk about how we can set up a modal that can be used anywhere on your site.

If you want, you can skip to the end for the full code.

Setting up the Modal

Firstly, we need to set up somewhere to instantiate our Alpine data, for this example we'll use a <div> but it could be any element that you wish as long as it wraps the whole content.

<div x-data="{ 'showModal': false }">

</div>

Inside of that, we need to add the basic structure of a modal. This will be the full-screen overlay background as well as the white box to contain the modal content itself.

We're also adding x-show to the modal so that this only shows when showModal is set to true in the Alpine wrapper.

<div x-data="{ 'showModal': false }">
  <!-- Modal -->
  <div
    class="fixed inset-0 z-30 flex items-center justify-center overflow-auto bg-black bg-opacity-50"
    x-show="showModal"
  >
    <!-- Modal inner -->
    <div class="max-w-3xl px-6 py-4 mx-auto text-left bg-white rounded shadow-lg">

    </div>
  </div>
</div>

Next, let's add a trigger so that we can open the modal. In this example, it's a button but it could also be any a tag as well.

<div x-data="{ 'showModal': false }">

  <!-- Trigger for Modal -->
  <button type="button" @click="showModal = true">Open Modal</button>

  <!-- Modal -->
  <div
    class="fixed inset-0 z-30 flex items-center justify-center overflow-auto bg-black bg-opacity-50"
    x-show="showModal"
  >

    ...

  </div>
</div>

When we press the button, we will see the modal popup but we don't have any way to close it. Let's deal with that.

add @keydown.escape to the wrapper of our modal.
add a @click.away event listener to the inner modal so that if we click outside of the white content it will also close.

<div
  x-data="{ 'showModal': false }"
  @keydown.escape="showModal = false"
>
  ...

  <!-- Modal -->
  <div
    class="fixed inset-0 z-30 flex items-center justify-center overflow-auto bg-black bg-opacity-50"
    x-show="showModal"
  >
    <!-- inner modal -->
    <div
        class="max-w-3xl px-6 py-4 mx-auto text-left bg-white rounded shadow-lg"
        @click.away="showModal = false"
    >

    </div>
  </div>
</div>

Next, we will set up some content for the inside. Inside of the modal, we will add a title and a close button to give the user an intuitive way to also get out of the modal.

...

<!-- inner modal -->
<div
  class="max-w-3xl px-6 py-4 mx-auto text-left bg-white rounded shadow-lg"
  @click.away="showModal = false"

>
  <!-- Title / Close-->
  <div class="flex items-center justify-between">
      <h5 class="mr-3 text-black max-w-none">Title</h5>

      <button type="button" class="z-50 cursor-pointer" @click="showModal = false">
          <svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="currentColor">
        <path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M6 18L18 6M6 6l12 12" />
      </svg>
      </button>
  </div>

  <!-- content -->
  <div>Content goes here</div>
</div>

...

Finally, let's add some animation to the opening using Alpine's transition methods. On the modal itself, we'll add some Tailwind classes that smooth in the entrance of the modal. We'll also add the motion-safe property to ensure that we adhere to the user's preferences.

  <!-- Modal -->
  <div
      class="max-w-3xl px-6 py-4 mx-auto text-left bg-white rounded shadow-lg"
      @click.away="showModal = false"
      x-transition:enter="motion-safe:ease-out duration-300"
      x-transition:enter-start="opacity-0 scale-90"
      x-transition:enter-end="opacity-100 scale-100"
  >

    ...

  </div>

You can find out more about why we use motion-safe variants by reading up on this awesome article from Smashing Magazine

Perfect, we have a modal built with Tailwind + Alpine JS.

Finished Code

Here is the finished code that you can copy & paste into your website.

<div
  x-data="{ 'showModal': false }"
  @keydown.escape="showModal = false"
>
    <!-- Trigger for Modal -->
    <button type="button" @click="showModal = true">Open Modal</button>

    <!-- Modal -->
    <div
        class="fixed inset-0 z-30 flex items-center justify-center overflow-auto bg-black bg-opacity-50"
        x-show="showModal"
    >
        <!-- Modal inner -->
        <div
            class="max-w-3xl px-6 py-4 mx-auto text-left bg-white rounded shadow-lg"
            @click.away="showModal = false"
            x-transition:enter="motion-safe:ease-out duration-300"
            x-transition:enter-start="opacity-0 scale-90"
            x-transition:enter-end="opacity-100 scale-100"
        >
            <!-- Title / Close-->
            <div class="flex items-center justify-between">
                <h5 class="mr-3 text-black max-w-none">Title</h5>

                <button type="button" class="z-50 cursor-pointer" @click="showModal = false">
                    <svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="currentColor">
                        <path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M6 18L18 6M6 6l12 12" />
                    </svg>
                </button>
            </div>

            <!-- content -->
            <div>Content goes here</div>
        </div>
    </div>
</div>

If there are any errors, please reach out to me on Twitter @jackabox

Deep Dive: Building a Shopify Add-on for Statamic

Jack Whiting — Tue, 23 Mar 2021 15:27:35 +0000

You may have seen it already, or not, but I recently launched a Shopify add-on for Statamic.

I wanted to breakdown a bit of the choices made when building the add-on as well as how I integrated Shopify with Statamic.

Hope you enjoy!

Background

I recently came into contact with a client who was looking at building a store for a rice company. They wanted to sell their products through Shopify but wanted a way to focus the site on content; recipes, careers, blogs, etc.

Shopify is great at doing what it does, e-commerce, however, it's plainly pitiful in handling anything outside of that. Sure, there are several add-ons that try to solve this - but they are the equivalent of band-aids on a wound.

They wanted something focused on content, relations between content, and something easy for the client to manage. Enter Statamic. It's absolutely awesome as a CMS, powerful out of the box, and easily extendable as it's built on top of Laravel.

I started playing around with the idea of how I could integrate the two. Shopify has two very extensive APIs - the Admin API and the Storefront API. After browsing the docs, and a little playing around, I decided the best way to go forward would be to integrate Shopify into the CMS.

The integration was not looking to recreate what Shopify does with managing customers, marketing, etc. Shopify is great at this, so I wanted to leave it to do its thing. The client wanted to primarily extend the content provided on their products with ingredients, key features, related recipes, etc.

I needed to find a way to get the product data into Statamic.

Enter the Admin API.

The Admin API

The Admin API gives us access to a lot of data. It is not all needed in this integration, I mainly wanted access to:

Products
Variants
Images

Laravel has a great way of dealing with http requests. I could quite easily use this to ping the URLs and handle the requests, however, I wanted to integrate something a bit more battle-tested under the hood.

I had a look around at available solutions and how people integrated code. I then found the great library php-shopify on GitHub.

Setting Up Access

I didn't want to keep having to pass through the configuration values - DRYer code is better. In our ServiceProvider, we create the config and initialise it to use throughout the add-on.

private function setShopifyApiConfig(): void
{
    $config = [
        'ShopUrl' => config('shopify.url'),
        'ApiKey' => config('shopify.auth_key'),
        'Password' => config('shopify.auth_password'),
    ];

    ShopifySDK::config($config);
}

There are a few options wrapped up here to ensure that if a user wants to caches their config then things wouldn't break. These values are all pulled from the `env` file in the config.

Fetching The Products

When fetching products there are a few patterns a user can fit into:

They could have a small subset with limited variations.
The could have a large set of data with no real configurations.
The could have both a large set of data with a lot of configurations.

To ensure that the add-on could handle all of these configurations, I set up a way to pull in the paginated resources and dispatch them to the queue so that they can be worked on at their own pace.

The Shopify Admin API limits you to getting 250 products at once from the products endpoint.

When first integrating the solution, I bumped into a few issues with the paginated results. Fortunately, with a few stumbling, a bit of fiddling, and some lucky searches. I came to the following solution.

$shopify = new ShopifySDK;

$productResource = $shopify->Product();
$products = $productResource->get(['limit' => config('shopify.api_limit')]);
$next_page = $productResource->getNextPageParams();

// Initial Loop
ImportAllProductsJob::dispatch($products);

// Recursively loop.
while ($next_page) {
    $products = $productResource->get($productResource->getNextPageParams());
    $next_page = $productResource->getNextPageParams();

    ImportAllProductsJob::dispatch($products);
}

Shopify passes the pagination data through in the header. What this code does is fetches the data, checks if there are any headers, and then dispatches them to the job to handle the import. It then repeats this until the $next_page var comes back as null.

Saving the Products

Statamic is primarily a flat-file CMS and I didn't want to deviate away from this. Fortunately, I didn't need to.

Statamic provides a Entry facade, which allows us to fetch, update, and insert data. This works whether our data source is flat files or a database and made it great to expand upon.

In our ImportJob, we first check if the user has imported the product before and if not we instantiate it. This was a rather simple fetch and check if null.

$entry = Entry::query()
            ->where('collection', 'products')
          ->where('slug', $this->slug)
          ->first();

if (!$entry) {
    $entry = Entry::make()
                ->collection('products')
                ->slug($this->data['handle']);
}

This logic is used in both products and variants.

Next, to handle data coming from Shopify, I wanted to make sure that a user could set their preference on how they wanted the data to be pulled in. The user could have the following scenarios:

Did they want Shopify to be the source of truth and overwrite the data in our CMS?
Do we want the content edited in the CMS to be the source of truth and ignore any incoming overwrites?
Does the user want Shopify to overwrite some things and not others?

Pulling the main bulk of data for a product is relatively simple. I wrapped the main fields that a user could overwrite with a check for if the config values are set as true. If the config is set to overwrite, we use the Shopify data, if not we use the local data.

If the entry doesn't exist we always use the Shopify data.

For the actual data pulled, the add-on fetches the ID, date, content, vendor information, types, tags, variants, and images.

$data = [
    'product_id' => $this->data['id'],
    'published_at' => Carbon::parse($this->data['published_at'])->format('Y-m-d H:i:s'),
    'title' => (!$entry || config('shopify.overwrite.title')) ? $this->data['title'] : $entry->title,
    'content' => (!$entry || config('shopify.overwrite.content')) ? $this->data['body_html'] : $entry->content,
    'vendor' => (!$entry || config('shopify.overwrite.vendor')) ? $this->formatStrings($this->data['vendor']) : $entry->vendor,
    'type' => (!$entry || config('shopify.overwrite.type')) ? $this->formatStrings($this->data['product_type']) : $entry->type,
    'tags' => (!$entry || config('shopify.overwrite.tags')) ? $formatTags : $entry->tags,
];

Fetching the Variants

Variants were a little more complex. Each product can have, well a s!*t-tonne, of variants.

In the case of my client they didn't, but I wanted to make this versatile for any data you could throw at it. Alongside this, variants are the source of truth for the stock quantity and whether the product should be sold if it runs out of stock.

You could pull these in with JavaScript on the front-end, but I wanted to get these into Statamic so that a user could adapt with additional data with any specifics to the variant.

When using the products on the front-end some of this logic will be used to check if a product is in stock or not.

$entry->data([
    'variant_id' => $variant['id'],
    'product_slug' => $product_slug,
    'title' => $variant['title'],
    'inventory_quantity' => $variant['inventory_quantity'],
    'inventory_policy' => $variant['inventory_policy'],
    'price' => $variant['price'],
    'sku' => $variant['sku'],
    'grams' => $variant['grams'],
    'requires_shipping' => $variant['requires_shipping'],
    'option1' => $variant['option1'],
    'option2' => $variant['option2'],
    'option3' => $variant['option3'],
    'storefront_id' => base64_encode($variant['admin_graphql_api_id']),
])->save();

To identify the variants against the product we add the slug to each variant - we use this in a custom field for the front-end that shows the variants on the product and lets you edit them in the stack editor.

The problem with the Admin API (back-end) and the Storefront API (front-end) is that they require different IDs to interact with the data. This gave me a little bit of a headache at first but turns out - all that needed to be done was running a base64_encode on the admin_graphql_api_id that was returned in the Admin API.

Fetching The Images

Sweet, at this point I was getting there with a lot of the data I wanted to pull in. However, I needed the images which, again, caused a few problems of their own.

Firstly, Images came with data appended that we didn't want. So we had to clean this up.

$cleanUrl = strtok($url, '?');
$imageName = substr($url, strrpos($url, '/') + 1);

Secondly, we had to find a way to download the image from the Shopify CDN and store it locally, or on S3, or any other file system. To grab the download we use the Storage facade and the UploadedFile class. This lets us temporarily store the image.

Storage::disk('local')->put($imageName, file_get_contents($cleanUrl));

$file = new UploadedFile(realpath(storage_path("app/$name")), $name);

Thirdly, we needed to pass the image to the Statamic Asset container so it would appear in the admin, could be distributed to any filesystem the user has set up and could be utilised in any way the user wanted.

This was handled by checking if the Image already existed (we don't need to double save) and then passing the temp file we created and uploading it.

// Check if it exists first - no point double importing.
$asset = Asset::query()
    ->where('container', 'shopify')
    ->where('path', 'Shopify/' . $name)
    ->first();

if ($asset) {
    return $asset->hydrate();
}

// If it doesn't exists, let's make it exist.
$path = Path::assemble('Shopify/', $file->getClientOriginalName());

$asset = Asset::make()
    ->container('shopify')
    ->path($path);

$asset->upload($file)->save();
$asset->hydrate();

Finally, we had to clean up the temporary file we created as we didn't want to clog things up.

Storage::disk('local')->delete($name);

Interacting With The Data

Great, we had most of the data stored in Statamic, but we didn't really have a great way to interact with it. Most of the fields utilised were standard text fields, content, and images.

This was great, but I wanted to see the variants inside of a product as they all have very unique IDs that a user would be confused by. To do this I took a bit of inspiration from the great commerce add-on Statamic Butik.

Jonas sets up a way to grab the variants per product and passes them to a Vue component. His variants are set in stone and defined in PHP however I was looking to give the user complete control.

Firstly, I set up a VariantBlueprint class which extends the Blueprint facade.

class VariantBlueprint extends Blueprint
{
    public function __invoke()
    {
        $bp = Blueprint::find('collections/variants/variant');

        if (! $bp) {
            return 'No variant data found';
        }

        return $bp;
    }
}

What this does is searches the filesystem for the variant YAML file and then interprets it and returns it.

I then set up a new FieldType named Variants.

public function preload()
{
    $product = $this->field()->parent();

    if (!$product->initialPath()) return;

    $variantBlueprint = new VariantBlueprint();
    $variantFields = $variantBlueprint()->fields()->addValues([])->preProcess();

    return [
        'action'             => cp_route('shopify.variants.store'),
        'variantIndexRoute'  => cp_route('shopify.variants.index', $product->slug()),
        'variantManageRoute' => cp_route('shopify.variants.store'),
        'variantBlueprint'   => $variantBlueprint()->toPublishArray(),
        'variantValues'      => $variantFields->values(),
        'variantMeta'        => $variantFields->meta(),
        'productSlug'        => $product->slug(),
    ];
}

Here, we fetch the parent product. If there is no parent we return void. This allows us to check if we are on a previously saved product or a new product that wouldn't have any variants.

We then grab the blueprint, process the fields, and then pass this along with the routes we need to edit any data.

This all is loaded into a Vue component that triggers the Stack to open and allows us to update the variant data.

Boom!

Handling Product Changes

After a bit of testing, I realised that the data was only updating when the user ran the importer. This could cause problems of stock being out of data or even having products deleted on Shopify and being listed on the CMS.

To handle this I looked at integrating Webhooks.

Integrating Webhooks

When you set up Shopify webhooks, the data being sent back contains a header that we need to verify against a secret.

To do this, I created a trait that could be integrated into any current, and future, webhooks.

protected function verify($data, $hmac_header): bool
{
    $calculated_hmac = base64_encode(hash_hmac('sha256', $data, config('shopify.webhook_secret'), true));

    return hash_equals($hmac_header, $calculated_hmac);
}

This calculates an HMAC based on the secret and data we want to check. It then verifies this against the HMAC that Shopify passes in the header.

Handling Stock Updates

If a product only has one stock left, and we don't update our products in Statamic on a regular basis, we might still be showing the products to the user as available - thus causing drop-offs in cart conversions.

Shopify has a webhook for when an order is placed. This seemed like the perfect point to listen out and update the stock of any products.

In our add-on, we have an endpoint for this, which we take back the data, process it against our verify function and then decode the data returned.

public function listen(Request $request)
{
    $hmac_header = $request->header('X-Shopify-Hmac-Sha256');
    $data = $request->getContent();
    $verified = $this->verify($data, $hmac_header);

    if (! $verified) {
        return response()->json(['error' => true], 403);
    }

    // Decode data
    $data = json_decode($data);

    // Fetch Single Product
    $shopify = new ShopifySDK;

    foreach ($data->line_items as $item) {
        $product = $shopify->Product($item->product_id)->get();
        ImportSingleProductJob::dispatch($product);
    }

    return response()->json([], 200);
}

If successful, the endpoint contains a breakdown of all the line_items purchased. We then trigger a single fetch on each product to update any data we need to.

This webhook is completely optional. If you aren't interested in stock or want to do handle this in other ways - you don't want to use it.

Handling Deleted Products

We do a similar thing when products are deleted, we check the webhooks integrity against our verify the request and then delete the product that is returned.

Wrapping Up

Hope you enjoyed this dive into the back-end of the Shopify add-on along with why a few decisions were made and how they were achieved. I'm hoping to get around to doing a dive in the front-end soon - look out for it!

If you want to find out more or ask me any questions, please reach out to me on @jackabox.

Replacing Dump & Die with Ray when Debugging

Jack Whiting — Thu, 21 Jan 2021 02:36:41 +0000

This post is not sponsored and covers my experience with using Ray.

Ray is a tool released by the wicked team Spatie. Ray aims to replace the dump & die method of debugging by using an interface to catch all the debug output. There are currently adaptors for:

Laravel,
WordPress
Yii2
Craft CMS
JavaScript
and more

Why Ray?

Since I started coding, Dump & Die has been the way I have debugged applications. I never enjoyed using xdebug as I found it clunky and a pain to set up - I hear this is less of a problem now.

When Spatie announced the release of Ray I wasn't completely sure what to think. Ray felt like it was just a UI that wrapped my debug statements and brought me out the browser.

Since they have a limited trial available I thought I would give it a spin anyway and see if it could help. After a few days I was happy to buy Ray and found it helped me out for a few reasons:

A history of debug statements. No more forgetting the last thing you dumped and having to redo it again. Statements can be grouped into different pages to make finding them easier.
When running tests you can send the output to ray. The same goes for console commands, jobs, events, and - well - any code in your application. No running through the terminal to find the output!
When calling ray($someData) it will work out the best way to interpret the data. Whether that is a model, image, string, or anything else. If you want the full log you can get that by using the ray->raw($someData) method.
Handy shortcuts to bring ray in and out of view - making debugging quick.
A lot of services integrate with ray (and it is growing every week). This makes it useful for collating debugging statements into one interface.
You can install ray to your production dependencies. When code is in a production environment any ray() statements will silently fail instead of displaying to the user.

How to use Ray

Showing Queries

To get all queries executed between lines of code you can use the showQueries method which begins tracking them.

ray()->showQueries();

User::find(3);

ray()->stopShowingQueries();

Capturing Models

The model() method prints out an array of the model's data to ray. You can also get the full output by using the raw() command.

ray()->model($user); // Shows an array of values.

ray()->raw($user); // prints out the full output of $user.

Viewing Mailables

To see the rendered version of a mailable you can use mailables().

ray()->mailable(new TestMailable());

Outputting Images

To check an image you can use the image() method to have it displayed in ray.

ray()->image('https://picsum.photos/200');

Conclusion

There are a lot of handy methods included within ray so far and more are being added as the team release updates. If you've been hesitating giving ray a try I'd highly recommend downloading the trial and giving it a play.

Generating Sitemap Entries For Nuxt Content

Jack Whiting — Thu, 03 Sep 2020 16:13:10 +0000

Whilst launching my new site (https://jackwhiting.co.uk) I chose to use Nuxt Content for managing my blog posts, works, and other content. Whilst generating the sitemap I noticed that any content created from @nuxt/content was not being added to my sitemap. In this article, we are going to look at how to solve this and get all of your entries listed.

Setup

Before we can do anything we need to make sure we have the @nuxtjs/sitemap module installed. Open up your project in the terminal and run the following.

yarn add @nuxtjs/sitemap

In your nuxt.config.js add the sitemap to your modules.

export default {
  modules: ['@nuxt/content', '@nuxtjs/sitemap']
}

This should always go after any other modules you've included to ensure all routes are caught.

Next, add some defaults for the sitemap configuration - add a hostname and set up an empty function which we will use later to fetch and return the paths of our content.

export default {
  sitemap: {
    hostname: process.env.BASE_URL || 'YOURSITEURL',
    routes: async () => {}
  }
}

For a full list of sitemap options, you can check out the readme.

Adding Your Routes

The way you have set up your content structure may be unique, you may use unique URLs, you may have multiple folders or only want to include one folder. Each of these may change how you need to define your routes, so I have included a few examples below which should let you get set up and run.

Adding Routes From One Directory

routes: async () => {
  const { $content } = require('@nuxt/content')

  const posts = await $content('posts')
    .only(['path'])
    .fetch()

  return posts.map((p) => p.path)
}

Adding Routes From Multiple Directories

routes: async () => {
  const { $content } = require('@nuxt/content')

  const posts = await $content('posts')
    .only(['path'])
    .fetch()
  const works = await $content('works')
    .only(['path'])
    .fetch()

  // Map and concatenate the routes and return the array.
  return []
    .concat(...works.map((w) => w.path))
    .concat(...posts.map((p) => p.path))
}

Expanding Routes With More Information

Sometimes you may want to add lastmod, priority, or other details to your sitemap - we can expand on our included routes by looping around them and adding additional properties.

routes: async () => {
  const { $content } = require('@nuxt/content')

  const posts = await $content('posts').fetch()
  const works = await $content('works').fetch()

  // Setup an empty array we will push to.
  const routes = []

  // Add an entry for the item including lastmod and priorty
  works.forEach((w) =>
    routes.push({
      url: w.path,
      priority: 0.8,
      lastmod: w.updatedAt
    })
  )

  posts.forEach((p) =>
    routes.push({
      url: p.path,
      priority: 0.8,
      lastmod: p.updatedAt
    })
  )

  // return all routes
  return routes
}

Testing Everything Out

After adding your routes to the nuxt.config.js file you can run yarn dev in your terminal. Once everything starts to compile, visit http://localhost:3000/sitemap.xml in your browser you should see all of the content entries listed.

If you don't want to compile your sitemap.xml every time you run yarn dev you can wrap the function in a conditional.

routes: async () => {
  if (process.env.NODE_ENV !== 'production') return

  // rest of the function here
}

I hope this article helped you. If you've found any issues with the content feel free to reach out to me on Twitter (@jackabox).

Installing Svelte & Integrating Tailwind CSS (and PostCSS)

Jack Whiting — Fri, 12 Jun 2020 13:15:52 +0000

Svelte is an awesome underdog in JavaScript frameworks and is climbing the ranks currently due to the way it compiles your scripts and HTML. Svelte is inherently a compiler and all of your components files get compiled into pure JavaScript. You can find out more about Svelte through their website.

Install Svelte

To get set up with Svelte, we will require the installation of Node.js and Degit. I won't cover how to get these set up in this article as it expects a bit of knowledge of Node and the Terminal, you can follow the installation of each at their respective sites beforehand.

Let's create a copy of the base template provided by Svelte, and install all the necessary libraries with the following.

npx degit sveltejs/template my-svelte-project
cd my-svelte-project

yarn # or npm install

To test everything is working properly, we can run yarn dev and we should be able to see the default page at https://localhost:5000. If you can't you may want to ensure nothing went wrong with the setup.

Set Up Tailwind

I'm a huge fan of Tailwind and use it on most projects, so working with Svelte would be no different. Staying in the directory we installed Svelte into, we will need to install a few dependancies, create a new postcss.config.js file and finally modify a couple of existing files.

Install Dependencies

Install the necessary development dependencies with the following command:

yarn add --dev postcss postcss-load-config svelte-preprocess tailwindcss

If you want to make sure unused styles are removed when in production (keeping our file size lean), you can also add the following dependency.

yarn add @fullhuman/postcss-purgecss

Generate Tailwind Config

To overwrite the default styles provided by Tailwind, we will need to make sure we have a tailwind.config.js in our route directory where we can put our necessary tweaks. You can do this by running the following command.

npx tailwind init

If you open up the file created you should see it looks similar to the below.

module.exports = {
  theme: {
    extend: {},
  },
  variants: {},
  plugins: [],
};

Creating our PostCSS Rules

We will need to tell Svelte how to interpret and compile our necessary code. We can do this by creating a postcss.config.js file in the route directory. Manually create one or run the following in the terminal.

touch postcss.config.js

Open the file in your favourite editor and copy in the following code.

const purgecss = require('@fullhuman/postcss-purgecss')({
  content: ['./src/**/*.svelte', './src/**/*.html'],
  whitelistPatterns: [/svelte-/],
  defaultExtractor: (content) => content.match(/[A-Za-z0-9-_:/]+/g) || [],
});

module.exports = {
  plugins: [require('tailwindcss'), ...(!process.env.ROLLUP_WATCH ? [purgecss] : [])],
};

To explain the above a little, we first create a ruleset for Purge CSS which will look through all Svelte and HTML files and remove any classes that do not match what is included. We'll also add a whitelist pattern to ensure that any Svelte generated classes are not removed unnecessarily.

We then watch on whether the process.env.ROLLUP_WATCH equates to true, if not, we purge, if true then we are in development and we just compile the Tailwind classes.

Integrating with Svelte

We'll need to include the Tailwind helpers somewhere so that all of the necessary styles can be pulled in. Open up the App.svelte file in the src/ folder, and add the following code to the bottom (replacing any styles that are already there).

<style global>
  @tailwind base;
  @tailwind components;
  @tailwind utilities;
</style>

Then we'll need to ensure Svelte runs the preprocessors on any code in our <style> tags. To do this, we'll need to open the rollup.config.js file in your editor and add the following at the top of the file.

import sveltePreprocess from 'svelte-preprocess';

Then modify the section which looks similar to the following

...
svelte({
  ...
  preprocess: sveltePreprocess({ postcss: true }),
  ...
})
...

We should now have Tailwind fully integrated into Svelte. If you rerun yarn dev in your terminal you should see it compile the styles before page load and you'll have a stripped back page to jump into.

Usage

You can now include any of the styles as class attributes for values that already exist as seen below, or you can integrate by using the @apply method throughout your Svelte components.

<h1 class="font-bold">Title</h1>

<style>
  h1 {
    @apply font-bold text-2xl;
  }
</style>

Parsing JSON Files from a Remote URL with Node, JSONStream and Hyperquest

Jack Whiting — Fri, 12 Jun 2020 13:13:16 +0000

Working with large data files can be tough and cause a bottleneck within your application. We can't just simply load the file all at once and expect everything to work. We need to iterate over the data and parse it in chunks.

Pre-requisites

For this project, we will look to use Node, Hyperquest, and JSON Stream to fetch the file from a remote URL, parse it and then handle the data retrieved.

This article assumes you know how to use the basics of node.

To get started, open up your working directory in your code editor and create a new file named parser.js in the root.

Fetching the JSON

To be able to have something to work with, we will need to fetch the data we want from a remote server. If you want to test this out with a JSON file I recommend using the Scyfall JSON Endpoint for all of the Magic! The Gathering cards which you can find at https://archive.scryfall.com/json/scryfall-default-cards.json.

Before we can start installing things you will need to set up a package.json to install our NPM packages. You can do this with Yarn or NPM.

yarn # or npm install

Next we will need to install hyperquest.

yarn add hyperquest

Hyperquest is a subset of request written to handle large payloads of data without breaking our server. It works by fixing a lot of issues with HTTP so that any pesky bugs don't get in the way.

Let's set things up, at the top of the parser.js file import hyperquest.

const hyperquest = require('hyperquest');

Next, create a new function which will house our logic. While we are here, set a variable for the URL to the location fo the JSON file.

const parser = async () => {
  const url = 'https://site.com/linktoyour.json';
};

Next, let us initialise hyperquest to fetch the data so that we can pass it through to our follow up functions. We are using await here to ensure that everything gets processed before moving on.

const parser = async () => {
  const url = 'https://site.com/linktoyour.json';

  await hyperquest(url);
};

Hyperquest allows you to create a pipeline so you can pass the data received to other functions by appending .pipe(func), we are going to utilise this in the next step.

Handling the Returned Data

We are going to lean on a few more packages here to handle the data returned and make sure it is processed correctly. These are:

JSONStream - Which allows us to stream the parsing of the results returned.
event-stream - Which allows us to process the parsed data

Install them into the project.

yarn add JSONStream event-stream

Import them at the top of the parser.js file.

const JSONStream = require('JSONStream');
const es = require('event-stream');

The first pipeline function we will add is for JSONStream. This will ensure everything is returned properly in a readable format. Update our code to the following.

await hyperquest(url).pipe(JSONStream.parse('*'));

The * passed through to the parse function is telling the JSONStream package that I wish to return every row in my JSON file. If all of your records were contained inside of a data object. You may adjust the code to something closer to JSONStream.parse('data.*').

Next, add a pipeline for processing the data with event-stream, update the code to add the following .pipe().

await hyperquest(url)
    .pipe(JSONStream.parse('*'))
    .pipe(es.map(async (data, callback) => {
        console.log(data);
        callback(null, data);
  })

To explain what we have so far, for every row we return with JSONStream it will be passed to the event-stream function and console.log the data (purely for testing this works). Finally we we call the callback() function which will drop current data and returns a data entry without the current record so we can loop back around.

Our full code should look like the following:

const hyperquest = require('hyperquest')
const JSONStream = require('JSONStream');
const es = require('event-stream');

const parser = async () => {
    await hyperquest(url)
        .pipe(JSONStream.parse('*'))
        .pipe(es.map(async (data, callback) => {
            console.log(data);
            callback(null, data);
      })
}

parser()

We won't go into the processing of the data as this can be done in a multitude of ways, but if you run node parser.js you should start to see the rows being logged in the console.

I've added a stripped down example of a project on GitHub.

I hope this helps you out in the future.

Using Firebase Admin SDK with Netlify Lambda Functions

Jack Whiting — Tue, 15 Oct 2019 13:37:43 +0000

I've been recently leaning into spinning up applications with Nuxt and Firebase. These are pretty straight forward applications that handle user authentication and creating/reading of data. However, I've recently come into a case where I needed to send out a request to a third party service and write that back to the database. You could do this within Firebase Functions, but it would require you to be signed up onto one of the paid plans - which I'm not quite ready for yet.

Enter Netlify Lambda Functions, on the free plan you're given a generous amount of resources and it allows you to send requests to third parties. This article is designed to run through a very basic setup of a Netlify Function and how to communicate with Firebase.

The following article covers the following:

Setting up the Structure
Integrating Firebase Admin SDK
Configuring your Netlify Deployment
Deploying to Netlify

Project Structure

We're going to use a very barebones project structure for this demo that has no frontend and only really is used to deploy the functions. These files can easily be transferred into your working directory and the setup would remain the same.

The structure will look a little something like the following:

.config
.gitignore
functions
  test
    test.js
    package.json
netlify.toml
package.json

To get started, create a new directory somewhere on your local machine. Inside of the directory we'll need to create a couple of folders.

First, the functions folder which is where any function you wish to run on Netlify will be housed.

mkdir functions

Next, let us make a directory for the function, the directory should be named whatever you want the endpoint URL to be accessed from. For this demo, we'll name this test. We'll also require two files, a JavaScript file named the same as the folder (which will be what Netlify tries to access) and a package.json to keep all of our requirements contained.

Create the folder and files like so:

mkdir functions/test
cd functions/test
touch package.json
touch test.js

Update your package.json with the following:

{
  "name": "functions",
  "version": "1.0.0",
  "description": "",
  "main": "test.js",
  "scripts": {},
  "author": ""
}

This is the basic scaffolding you'll need for any function your try and spin up (where you will use npm packages). If you don't plan to use any npm packages, you can not add a package.json.

Working with Firebase Admin

Now for the fun part, getting out function to communicate with the Firebase Admin SDK. The following example will feature a very basic creation of a document to show how everything would work, in your actual function you'll probably take this further.

In our functions/test add in the Firebase Admin SDK, like so:

yarn add firebase-admin

Which should add the following to your package.json

"dependencies": {
  "firebase-admin": "^8.6.0"
}

We can then call this in our test.js file by declaring it at the top of the document

const admin = require('firebase-admin')

Firebase Admin Authentication

To actually connect to Firebase we'll need to authenticate the account, this will require the generation of an authentication file from Firebase. This file should be kept private and never uploaded to a public Git repository.

To generate the authentication file, follow these steps:

Log in to the Google Console at https://console.firebase.google.com
Click into the project you want to use the Admin SDK with, or create a new project.
Head to the project settings.
Click the "Service Accounts" tab.
Click Firebase Admin SDK.
On this tab, you'll see "Admin SDK Configuration snippet". Check the node.js option and click "Generate new private key"
A modal should pop up, click "generate key" again and this will download a JSON file.
Move the JSON file into your project structure in the functions/test folder and rename it to serviceAccountKey.json.
Update your .gitignore if you have one to ensure that this file does not get tracked.

Writing our Script

To bring everything together and integrate the Firebase Admin SDK with our script we'll need to set up a few more things.

Firstly, we need to configure the script to authenticate the Admin SDK with our firebase credentials. To do this update our test.js file with the following:

const admin = require('firebase-admin')
const serviceAccount = require('./serviceAccountKey.json') // Update this to your file

// Initialise the admin with the credentials
admin.initializeApp({
  credential: admin.credential.cert(serviceAccount),
  databaseURL: 'https://<YOUR-APP-URL>.firebaseio.com'
})

Update <YOUR-APP-URL> with the actual URL of your app. If you don't know this it can be seen in the Firebase Console.

Next, we'll write a small script that adds a new record to the Firestore database and returns a message once complete. To ensure that data is processed before the response is returned we'll take advantage of async/await. See the example below:

// Set up an instance of the DB
const db = admin.firestore()

// exports.handler is required by netlify to process.
exports.handler = async (event, context, callback) => {
  // wait for the record to be added
  await db.collection('COLLECTION').add({
    name: 'Test'
  })

  // Return a callback witha 200 response and a message.
  return callback(null, {
    statusCode: 200,
    body: JSON.stringify({
      data: `Test data added successfully`
    })
  })
}

Don't forget to update the COLLECTION placeholder with the name of the collection you want to add a record to, if you are purely testing you can just use test here. The full code will look a little like this:

const admin = require('firebase-admin')
const serviceAccount = require('./serviceAccountKey.json')

admin.initializeApp({
  credential: admin.credential.cert(serviceAccount),
  databaseURL: 'https://<YOUR-APP-URL>.firebaseio.com'
})

const db = admin.firestore()

exports.handler = async (event, context, callback) => {
  await db.collection('COLLECTION').add({
    name: 'Test'
  })

  return callback(null, {
    statusCode: 200,
    body: JSON.stringify({
      data: `Test data added successfully`
    })
  })
}

Netlify Configuration

To make sure everything works when we deploy it to Netlify, we'll need to configure a few things and install a dependency in our main site directory. In the root folder, if you do not have a package.json create one with the following command. If you already have a package.json you can ignore this step

touch package.json

Netlify requires that your run npm install or yarn install for each function we create, this is due to the way we've set up the files to keep things contained within each folder. To do this we can create a simple script in our package.json and tell Netlify to use it when we deploy. Update your package.json with the following:

"scripts": {
  "functions": "cd functions/test && yarn install"
}

Note, this will cd into the functions/test folder, we created and then run yarn install to download all our dependencies (in this case just Firebase Admin SDK).

Netlify Configuration

To tell Netlify to run the command, we'll need to create or update a netlify.toml file. Create a new file in the root directory with the following:

touch netlify.toml

Inside the file add the following.

[build]
command = "yarn functions"
functions = "functions"

This will tell Netlify that the functions folder contains all of our functions we have set up (in this case just the test) and that we want to run the yarn functions command on initial deploy which will download all the assets.

If you have existing code in your repository, such as a react app, you may need to take a look at Concurrently which will allow you to run multiple commands.

Node Environment

Firebase Admin SDK requires Node v10 for it to work. By default, Netlify Lambda runs in Node v8 so we'll need to add an environment file that tells Netlify to use v10 on the Lambda instance instead. To set the variable, you'll need to do the following:

Log in to the Netlify Console. Click into (or create) the site you want.
Click into the Settings tab.
Click Build & Deploy in the sidebar.
Click Environment under the Build & Deploy tab.
Click Edit Variables.
Add the following key AWS_LAMBDA_JS_RUNTIME with the value nodejs10.x
Save

Deploy Your Code

Commit everything and push the code up to your preferred provider. If you have Netlify set to auto-deploy then everything will be processed and your functions will be created after deployment. You'll be able to see these by going to the Functions tab in the Netlify Console.

If you click the test.js function in the Netlify Console, it will provide you with an endpoint URL that you can visit in your browser to test that everything works and your Firebase DB gets updated.

Article was originally published at https://jackwhiting.co.uk/posts/using-firebase-admin-sdk-with-netlify-lambda-functions/

Handling Redirects in Nuxt.js through Middleware

Jack Whiting — Wed, 18 Sep 2019 09:19:20 +0000

I recently published an article about how to handle redirects in Laravel, since I also use Nuxt.js I thought it would be good to write up how to handle redirects simplistically through pure Nuxt (no server, no advanced configuration).

To do this we'll need to leverage the serverMiddleware, you can learn more about this from the official Nuxt.js docs, but in short, it allows for us to handle additional routes that aren't defined within the folder structure (for example an API). In our case, we will be using the serverMiddleware to read the redirects and take us to the appropriate route.

We are going to create a JSON file to hold all of our redirects and then let the middleware read the start destination and send us to the final destination.

Create JSON

Create a new JSON file in your project and place it in your desired location. For this example, place the file in the following destination /data/redirects.json.

Our JSON should contain an array of elements with a from and to, please see the below example and adjust this to your own needs.

[
  {
    "from": "/",
    "new": "/home"
  },
  {
    "from": "/get-in-touch",
    "to": "/contact"
  }
]

Create the serverMiddleware

Next, we need to create a file which can handle the reading of the JSON and the logic to handle the redirect. Create a new file in /serverMiddleware/redirects.js with the following code:

const redirects = require('../data/redirects.json') // update to your file path

export default function(req, rest, next) {
  // find the redirect if it exists where the from === the requested url
  const redirect = redirects.find(r => r.from === req.url)

  // If it exists, redirect the page with a 301 response else carry on
  if (redirect) {
    res.writeHead(301, { Location: redirect.to })
    res.end()
  } else {
    next()
  }
}

The above file checks that the URL exists and if so, redirects to the destination. If not, the Nuxt application will move on and return the requested page.

Add to Nuxt.config.js

Before anything will work, we need to add the newly created redirects middleware into the nuxt.config.js . Edit the nuxt.config.js file and add the following in:

...
serverMiddleware: [
    '~/serverMiddleware/redirects.js'
],
...

Recompile the code and check that everything is working.

Bonus

If you need to take the redirects a bit further or if you don't mind using third party packages there is an awesome package available at https://github.com/nuxt-community/redirect-module that can handle this for you.

Like what you read? You can find more articles on my blog at https://jackwhiting.co.uk

5 Awesome Laravel Nova Packages to Kickstart Your Next Project

Jack Whiting — Wed, 22 May 2019 09:58:37 +0000

I've been using Laravel Nova a lot since it's release and find myself using the same packages across projects just because they're awesome and work well. In this post I've compiled a list of my five favourite packages to include in your Laravel Nova install.

If you haven't used Nova before, it's an admin package written for Laravel and allows for rapid prototyping of a CRUD admin system quickly. It's also extensible and all written within Vue/Tailwind. I'd suggest checking it out for your projects at https://nova.laravel.com/.

Nova Flexible Content

Nova Flexible Content is a package written by Whitecube and allows for a way to build repeatable fields on your models. It generally allows for any subfield or other package to be passed through and will collate the data into JSON to be saved in your table.

The team have been awesome at fixing out a few bugs and providing updates. They've recently included the ability to have nested flexible content which takes this package to the next level.

GitHub Link: https://github.com/whitecube/nova-flexible-content

Advanced Nova Media Library

Advanced Nova Media Library takes the Spatie's Media Library and extends it to be integrated into Nova. I've been using Spatie's Media Library for several years and have found it to be an invaluable resource - especially with the generation of responsive images.

This package by Eduard Bess integrates all the Spatie goodies into Nova and allows for the defining of gallery, files or single images. It also allows for the clipping of images upon upload which makes package even nicer.

GitHub Link: https://github.com/ebess/advanced-nova-media-library

Nova Duplicate Field

Nova Duplicate Field is the first package I wrote for Nova and allows for the quick duplication of models and their relations. This package takes a few parameters and utilises them at the click of the button. It will then redirect you to the edit view so that you can make any necessary changes that you need.

It's currently at around ~2000 installs.

GitHub Link: https://github.com/jackabox/nova-duplicate-field

Nova Snowball

This one is a theme but Stephen Lake has generated a really clean interface on top of Nova which cleans up a few things to my personal preference such as collapsable field groups and reducing the white space around elements. It also provides some responsive elements which Nova does not do by default.

GitHub Link: https://github.com/stephenlake/nova-snowball

Nova Backup Tool

This one is direct from Spatie and provides a slick interface for monitoring the back ups of your site. It's crucially important to keep a solid backup and this package will allow you to trigger a manual backup or see the status of your scheduled backups.

GitHub Link: https://github.com/spatie/nova-backup-tool

That's all for this list, but if you have any packages your particularly fond of? Drop me a tweet @jackabox and let me know!

Originally written at https://jackwhiting.co.uk

Setting Up A Windows 10 Development Environment with WSL, PHP & Laravel

Jack Whiting — Thu, 21 Feb 2019 14:15:54 +0000

Originally published in 2018 on https://jackwhiting.co.uk/

Preface

Recently, I've been toying around with the use of WSL (Windows Subsystem for Linux) for development. I've used a Mac for development work over better part of the last decade and required the Windows setup to mimic my workflow.

Typically, I create Laravel applications along with the occasional WordPress site, using the following tools:

Nginx
PHP
MySql
Dnsmasq
Valet

After a bit of testing and reconfiguration, I managed to get WSL setup with the above in a few easy steps and I'm relatively happy with the workflow.

The rest of this article will cover the process undertaken.

Installing WSL & Ubuntu

First things first, you're going to need to enable the Windows Subsystem for Linux, to do this use "Turn Windows features on or off" and select "Windows Subsystem for Linux" to enable it, click OK, reboot, and use this app. For more information on this you can view the Microsoft Documentation.
Once rebooted, you're going to need to install a subsystem, for the purpose of this article I chose Ubuntu. You can find the Linux Subsystem and others in the Windows Store. Go a head and download Ubuntu.
When Ubuntu is installed, you're going to need to configure it a little, open up command prompt (or any other terminal emulator you have - such as Hyper/CMDer) and enter ubuntu. This will run the setup process and ask you to set a username and password. Do this.

WSL should now be installed, setup, and ready for us to use.

Setting Up Our Base Requirements

As of writing this, I'll be using PHP 7.1. To access and install PHP, we'll need to add the personal package archive so that Ubuntu can recognise the libraries. To do this run the following command.

   sudo add-apt-repository ppa:ondrej/php

Next, we'll need to update and upgrade Ubuntu to download the latest packages (and our newly added PHP packages).

   sudo apt-get update && sudo apt-get upgrade

Before we can install Valet we are required to install a few packages. I've tried to reduce the list to only the barebones I'd require, so if you find you need anymore feel free to add them here. Run the following command and go grab a drink (this one may take a while).

   sudo apt-get install php-fpm php-mysql php7.1-cli php7.1-curl php7.1-mbstring php7.1-mcrypt php7.1-xml php7.1-zip php7.1-intl curl git unzip php-cli

Download and install Composer.

   cd ~
   curl -sS https://getcomposer.org/installer -o composer-setup.php
   sudo php composer-setup.php --install-dir=/usr/local/bin --filename=composer

I found that the only way to get Valet working on the current release of WSL was to use a fork of the Linux Valet repository by valeryan. To install this, we'll need to modify the global composer file located at ~/.composer/composer.json. Add the following code:

   {
       "require": {
           "valeryan/valet-wsl": "dev-master"
       },
       "repositories": [
           {
               "type": "vcs",
               "url":  "git@github.com:valeryan/valet-wsl.git"
           }
       ]
   }

To install, run composer global update.

You may encounter a permissions error here, if you do, modify the ownership of the .composer/ directory by running the followingsudo chown -R $USER .composer/.

Next, run the valet install comand to set everything up for us.

If you browse to http://localhost through your Windows browser you should be presented with a Nginx 502 error bad gateway, this means everything is set up correctly, so far!

Creating our Sites Directory

WSL automatically mounts your Window drives so they are accessible via the command line. All directories will be mounted at /mnt/. To set up Valet to park/link one of our folders, you'll need to do the following.

Set up a folder on your Windows drive where you want to store the files, for me this was u/sites.

Within Ubuntu, create a symbolink for your destination drive to your home folder with the following

   cd ~
   ln -s /mnt/u/sites

Park valet in the directory so that all subdirectories are automatically read.

bash cd sites valet park

Create a subdirectory, e.g. mysite, and add a test file which presents some readable content to the browser, such as <?php phpinfo();

Note: If you try and access the in the browser at the minute this will not load, this is because we'll need to add it to our host file or setup wildcard domains on Windows, see the below steps.

Wildcard Domains on Windows

Windows, by default, does not allow the ability to use wildcards in a hosts file. Now, you could manually add each site that you create in valet to your hosts file and be fine, but this adds an extra manual step. To combat this, we'll automate this with a tool called Acrylic DNS Proxy.

Acrylic DNS Proxy is a tool which allows us to add an extra layer on our computer to catch and cache domains, it can be used for all sorts of purposes, but for our intent we want to set it up to read wildcard domains.

Download and install the software. Start the service from the start menu and double check that it is running through Windows Services. This can be disabled or enabled at will, either through the start menu or Windows Services.

Acrylic DNS Proxy uses a standalone hosts file on top of Windows, and you'll need to modify this with the wildcard parameters. In the start menu, find the Acrylic folder and open the hosts file. This will load a .txt file with comments providing examples of what you can do, add the following line at the bottom.

bash 127.0.0.1 *.test

Save and then restart Acrylic.

All .test domains should now be served to your local (WSL) stack.

Side Note: You may get a 404 when you try and load the URLs in the browser, and I found that this was because my computer was not reading the host file properly. To get it to read the Acrylic host, I needed to modify my adapter settings so that the dns server was set to 127.0.0.1 for ipv4 and ::1 for ipv6. You can read more about this here.

Everything should now be set up and working.

Happy Coding !