DEV Community: Nick Frostbutter

How to derive Solana addresses

Nick Frostbutter — Thu, 12 Jan 2023 05:00:00 +0000

Every public address on the Solana blockchain uses a string of characters between 32 and 44 characters long. Each of these address follow the BIP44 standard and therefore use the base-58 character set.

These seemingly random string of letters and numbers are known as your "Public Key" (or pubkey for short), and are the addresses that people can share freely across the internet. It's your "wallet address".

These public address have a very specific set of one-way relationships that prevent any derived address from computing the secret that derived itself. Hence one-way. This one way relationship is one of the core fundamentals of most cryptography and all blockchains.

It is how us common folk on the internet can have true digital ownership and provenance.

Base-58 character set

Solana public addresses and transactions function on the base-58 character set. Essentially meaning, there are only 58 possible characters:

including uppercase A-Z, excluding uppercase O and I (as in Oscar and India)
lowercase letters A-Z, excluding lowercase l (as in letter)
digits 1-9, (which does NOT include 0)

These specific letters are excluded from the base-58 character set since they can very easily be mistaken for other characters. And if the wrong character is used, then the blockchain address is completely different!

How are Solana addresses derived?

mnemonic phase -> private key -> public key (aka your wallet's address)

For most people (not programs) the process to get a public address on the blockchain involved installing a web based "browser wallet" like Phantom or Solflare. Which then will generate a random list of words called your "mnemonic phrase" which is then used to derive (or compute ) a public address, in the form of one-way cryptography.

Below I will break down each of these steps:

Mnemonic phrases

Public addresses on the Solana blockchain are most commonly derived from a mnemonic phrase.

For most people, they will commonly use a mnemonic phrase that is a randomly generated list of words and is usually 12 or 24 words longs. For Solana, this phrase contains very specific words from the BIP39 wordlist.

The very specific combination of these words AND their specific order will allow the blockchain to "derive" (or "compute" ) a Private key using the Ed25519 algorithm. This private key can then be used to derive a public key, giving us a keypair (aka combination of a Private key and a Public key.)

In theory, the mnemonic phrase is used to essentially makes it easier for a human to read than a random string of characters, like a Private key. Thus making it easier for a human to write down this phrase, without mistakes , than a random character string.

Private keys

The derived Private key (or "secret key") is the special key that is the ONLY key that will be able to sign a transaction for its corresponding Public key, and therefore prove it own the public address.

A private key can always derive it's "child" public keys (and yes that is multiple, more on that in a moment), but a public key cannot derive its private key.

Derivation path

One of the most commonly misunderstood portion of generating a blockchains addresses is the derivation path. This special piece of information is what allows a single Private key to derive multiple Public keys that are impossible to tell they came from the same Private key. Only the owner of the Private key can tell.

These derivation paths are essentially a sequence that looks like this:

Sequence: m/<PURPOSE>/<COIN_TYPE>/<ACCOUNT>/<CHANGE>

each section is separated by a single /
m notes the root or "master" key
each of the other elements after m should be a zero or positive integer
each element may also end in a single ', noting it is "hardened"
- you can read more here about it, but it is not really necessary
- just know that Solana uses hardened elements and will enforce this automatically, regardless of if the 's are included.

With only specifying a derivation path of the m/<PURPOSE>/<COIN_TYPE>, like the one used by the Solana CLI, only the "root key" can be derived. Specifying the <ACCOUNT>/<CHANGE> will enable deriving multiple Public keys from the same Private key.

You can learn more about about the CLI with this guide on how to use the Solana CLI

Derivation paths on Solana

The "standard" derivation paths used on the Solana blockchain are:

m/44'/501' used by the Solana CLI to generate a "root key", and
m/44'/501'/0'/0' used by most web based or browser based wallets (like Phantom and Solflare)

These Solana derivation paths segments basically mean this:

44' - (required) uses the BIP44 standard
501' - (required) the identifier for coin type of the Solana blockchain
0' - (optional) define the account ID to derive. This is the value that browser wallets (like Phantom and Solflare) will change to enable users to generate new Public addresses on the fly, all while still using their single mnemonic phrase.
0' - (optional) an additional number that is basically always set to 0 for addresses that will be public

Public keys and wallet addresses

The Public key (aka pubkey) that is derived from a private key, using derivation path, is the public address that people have come to know as their "wallet address". This address will allow anyone on the blockchain to transfer tokens or otherwise interact with their account, securely.

Vanity addresses

Normally, a public Solana address appears as a random string of letters and numbers (like discussed above). But, there is a common technique used to try to generate addresses that start with certain characters in a row (like a word). These addresses are called Vanity Addresses.

24 things I learned deploying to Vercel

Nick Frostbutter — Tue, 22 Mar 2022 05:00:00 +0000

Recently, a friend turned me onto Vercel. Well, I guess it has been a few months now.

And I am loving it. But, like everything in life, it is not without it’s hiccups.

Both on the side of the platform having things that may work sub-optimally, and me as a new user to their platform trying to get acquainted and learning the ropes.

Quick background on Vercel

It’s a wonderful platform to automatically deploy your projects from a git repo.

Create an account, you connect your git repo, and push changes. Vercel handles the rest.

In the end, Vercel is basically a really fancy layer built on top of Amazon’s AWS platform. You can even use "serverless functions" built on top of AWS lambda functions. Giving your code very high scalability, right out of the box.

How does Vercel work?

They have a fairly comprehensive continuous deployment (CD) pipeline, Vercel automates the creation of unique builds for every commit to your git repo. Production, staging, or "preview" commits.

With each git commit you make, Vercel will automatically build your project and create a unique url to access each individual build. Turning every single git repo commit into a fully functional "preview" deployment.

Anyone on your team can access, use, and review your app from these unique urls. Even password protect the build urls.

Once satisfied with your project changes, you simply git commit or merge into to your "production" branch. Vercel will automatically build and make it available on your primary/production domain.

With that intro aside, here are 24 this I learned deploying my first project to Vercel (in no particular order):

PS: I am not affiliated with Vercel, other than as a happy user.

(but I would not mind a job offer 😇)

#1. Almost too easy to use...

The ease of use of using Vercel is just wonderful. Once you get setup* and your git repo connected, deploying your web app is stupid simple. Just git commit and git push and you are golden.

#2. Took me a bit to get a green build

Yeah... it did take me a bit of time to get properly setup with a successful build. I banged my head against the wall for a long time while trying to get my first project working.

I suspect at least some of this was user error (I do dumb things sometimes, who doesn't), some of it due to me using NuxtJS (which is not Vercel's best supported framework), and some due to the platform itself.

PS: To their full credit, multiple awesome people from Vercel did reach out to me on Twitter (@steph_dietz_ and @gudmundur) after me publicly talking about some of my struggles. So that was awesome!

#3. auto deployments = wonderful

Each git commit you make, Vercel will automatically build your project and create a unique url to access each individual build. Turning each repo commit into a "preview" deployment.

Anyone on your team can access, use, and review your app from these unique urls.

Once satisfied with your project changes, you simply git commit or merge into to your "production" branch, and Vercel will automatically build and make it available on your primary/production domain.

Then, after the successful build, Vercel's github bot will attach the link to the specific build url to view the preview or production build of that repo or PR. Very handy when others in your organization want to use GitHub for bug tracking.

#4. Deleting old builds?

As your project grows, the list of Vercel builds you have in your dashboard will grow.

At first, I could not find a way to manually clear the list of builds on the dashboard. Sad. I would have expected the option as part of the dropdown attached to each build.

But after more exploring, I found it. You can delete builds. But you have to go to the specific page for that build. From this page, and this page only, you can use the options dropdown to delete this specific build.

Navigate to the specific build page
click the 3 dot style "more options" dropdown in the top left corner
then you can delete the build

My opinion:
Users should be able to select the option from the project dashboard page. Where it lists out all of the recent builds anyway. Just add the same delete option to the more options menu.

To me, it seems like a better user experience. Plus, it would require at least 3 less page requests to delete a build. And that is just more efficient 😁

#5. vercel-build command

In your package.json file, you can define the vercel-build command to trigger any commands or build steps for each of the serverless functions that are built on Vercel.

This come in super handy when you have a certain package that may need to generate a configuration as part of the build, like Prisma for example. See the Prisma section below...

#6. "zero config" option

While Vercel has a "zero config" option (or at least that's what they used to call it).

You can create a vercel.json file in the root of your repo, then use that to define almost all of your project settings. Including routes, headers, and env variables. Quite nifty.

But, it seems like the good people of Vercel are moving away from this config file and trying to encourage developers to use the Vercel dashboard. Normally, I would be all for that. The dashboard is pretty great, and certainly very wholesome.

#7. Nuxt on Vercel

But, and this is a big butt: to use NuxtJS on Vercel, you have to define your project with a vercel.json file. At least to use NuxtJS SSR (which is kind of the whole reason Nuxt exists).

The only way that seems to work to deploy a Nuxt SSR app to vercel is using this "vercel-builder" project from the Nuxt community.

And on top of this, the built in "auto generate your API routes with Vercel from the 'api' folder" thing that Vercel markets also does not seem to work with Nuxt. So in order to create a serverless API for a Nuxt app, I have to manually define each of the API routes in my vercel.json file. Annoying, but not the end of the world.

PS: If anyone wants to talk about this, feel free to each out. I am more than happy to talk. Either to help guide you in getting your Nuxt app working on Vercel, or helping people make the process better. DM me on Twitter: @nickfrosty

#8. env vars up the wazoo

To add on to the different types of deployments Vercel can do (e.g. production, staging, etc), you can also specify specific env vars for each build type.

For example, in your production app you want to use your production "live mode" Stripe API keys to process your payments. Great. But on the staging app, you want to use the "test mode" keys to not monkey up your actual Stripe data. No problem.

Also by default, there are tons of env vars that are auto generated for each build. Some of them very useful, some of them less useful for me. But hey, they are available if you need them.

You can read all about them on the Vercel env variable docs: https://vercel.com/docs/concepts/projects/environment-variables

PS: Although you can set custom env vars for each build type, I did not see a easy way to copy the env variable names between build types. So you will have to manually add them for each build type.

Kind of annoying, but I can easily live with it. Especially since I only needed to set them up the one time.

#9. Are you using Axios on Vercel?

When using Axios (at least with Nuxt), you will likely need to specify the API_URL env variable. Without it, the Nuxt SSR request will fail (like those made via nuxt-auth).

From your Vercel project dashboard, navigate to your project settings -> environment variables page. For each of your build environments (e.g. production, staging, etc): add a new env variable names API_URL with a value of the base url you are using for the project.

For example: if your app's API is located at "https://my.other.link/api" -> your API_URL should be "https://my.other.link/".

PS: Doing this will also solve a problem with nuxt-auth on Vercel that appears to log the user out after any page refresh (aka not navigating by the client side rendering). I struggles for hours (maybe days) on this problem.

#10. All serverless functions = scale to infinity?

With the way that Vercel works, it seems like every single portion of your app will run on serverless functions (aka AWS lambdas). So in theory, your app code can scale to infinity. Which is super cool.

Honestly, I am not sure if all of the customer apps (or the entire platform) run on top of these serverless functions, but I would not be surprised.

At least for me using NuxtJS, all of my code for other.link is running on top of these serverless functions. At first, I did need to make some specific and calculated coding techniques to make my API run on these functions.

The biggest reason is because the serverless functions are limited to 50MBs (zipped) after their build is complete. Making them lightweight enough to run and "cold start" on the AWS lambdas. And I am pretty sure this 50MB is an AWS specific limit, not necessarily Vercel.

If you writing Node js code for your project, read this Vercel doc:

https://vercel.com/docs/runtimes#official-runtimes/node-js/node-js-request-and-response-objects

#11. Serverless functions and databases...

While the whole "serverless" architecture is very interesting to me, there is one big problem with it. Databases. Specifically database connections. Let me explain:

Each serverless function is basically a separate instance of your web app, or at least a portion of it. If that function makes a database connects to your database and makes a request, it is likely leaving that connection open. This way it can more easily connect again and get database records when needed.

But as the traffic to your app/website start to die off, these stateless serverless functions will turn off. Often not properly closing the database connections. If your site has frequent traffic spikes, then you may very quickly reach your database's connection limits. Forcing your database to a halt. Big problem.

From the research I have done, the best solutions to these known stale connection issues is using "connection pools". If you are using Prisma.io like me, I think there is some database connection pooling support built in (awesome). Postgres fans could try pgBounce (but I'm a MySQL kinda guy).

But if you are handing all your connections yourself, it might get hairy quick.

Right now, there are some VERY cool "serverless database" solutions coming out. Including Fauna DB and PlantScale. I am planning on using PlanetScale for an upcoming project where I think scaling might become an issue for me: my custom podcast playlist app.

#12. Vercel CLI

What kind of world would we live in in our hosting platforms did NOT have their own CLI. All the cool, hip platforms do. Vercel is no different.

Here are some of my high level thoughts on the Vercel CLI:

fairly simple and easy to use
you can link your terminal and git repo to a Vercel project (visible in the Vercel dashboard) directly from the CLI.
push your current project's code to be build on Vercel (without making a full git commit), you know, to test thing.
- by default, the CLI will create a development build for testing. But you can the CLI build directly to production with the --prod flag. Very handy for hot fixes.
after the build is complete, you will get clickable links to view the build on your domain

#13. I have had some issue with the Vercel CL though

When running vercel dev, if the vercel cli does not have access to your current working directory, then it may fail to actually build/launch your app locally. Makes sense I guess.

When this failure happens:

the CLI fails to create the node_modules_prod directory
which for some reason also deletes all the all the dev dependencies for your project from the ‘node_modules’ directory (weird, but okay I guess)
and then it removes the dev dependencies from your package.json file. (again, super weird)
all of these will likely result in a LOUD failure of your build command, and your local project

The real problem lies in this: since it deletes all the dev dependencies, you will have to reinstall them and add them back to your package.json...good thing we all use git right?

I was getting the listing of all my dev dependencies from my git changelog, since these changes were now all pending commits

#14. Build caches for speed!

The Vercel deployment/build system is pretty nice. It has a built in caching system that tries to make your builds faster by caching the node_modules folder after your first build. And yes, it does make the builds noticeably faster. Often by several minutes.

But it does have some limitations/drawbacks:

#15. Random failed/success builds?

Sometimes my builds will fail, sometimes they will pass. All from the same git commit. My only guess is that this is an issue with the Vercel build cache.

If you run into this sort of problem, check out these articles (they helped me): - https://stackoverflow.com/a/66841372/17609674- https://stackoverflow.com/a/61101087/17609674

#16. Old caches cause problems

When you push an update to your repo, Vercel will try to use the cached node_modules build files. Makes sense. Caching.

But this will always be from an older build. Which means it will likely use the older version of some packages or generated artifacts from packages. Like Prisma (see the Prisma section below)

This can become problematic and give errors if you have a npm package that needs to generate new code each build, or only for some builds when you make certain updates.

For most cases, I recommend adding that particular build step into the vercel-build script command to ensure it gets built every time. This will result in your builds taking longer though.

Or, you can also manually force the build without the cache from the Vercel dashboard (only for git repo pushes) or via the Vercel cli using vercel -f or vercel -f --prod

PS: If you use Prisma and Vercel, read the dedicated Prisma section at the bottom 👇

#17. npm vs yarn

Vercel will try to auto detect if you like using npm or yarn for your package manager.

if your repo has a package-lock.json, it will use npm
if not, then yarn

So if you want to use npm, like me, then make sure your package-lock.json file is committed with git.

This may not matter for your project, but it also might really matter. Here is why:

NPM does NOT allow installing global packages, permission denied.
yarn does allow installing global packages.

If you need to force the Vercel build engine to install a certain non-native dependency, like "bcrypt" (see below), then you will most likely need to install it as a global dependency. But you can only do that with yarn. At least as far as I can tell.

#18. Don't use bcrypt with Vercel

Don’t use bcrypt. Just don't.

It is not a native javascript library. So it will add lots of bloat to your project. Often making your builds fail.

I have been using the "scrypt" library that is built into Node. It is native, fast, and secure.

If you are already set on using it for an older project, switch to the "bcryptjs" npm package. Without using the javascript version, you will need to make some VERY hacky solutions to get it to work. And honestly, it is not worth the hassle.

Trust me. I tried it for my first project. Not worth it.

#19. Error logging in Vercel

Vercel does allow your projects to kick out errors and will "catch" then. In fact, each build will get their own error/warnings log. With one big caveat:

Vercel error logs are only visible if you are already viewing the logs.

By default, you will only be able to see any of your console log, warn, and error logs if you are actively viewing the specific builds logs page. They are _ ONLY _ realtime logs.

You can setup Vercel to send all your logs to a separate logger service, like LogRocket. But they you will likely need to pay for another service. Which is obviously unfortunate.

#20. console.log sometimes does not appear (sometimes?)

When you need to break into troubleshooting or debugging via the console.log method, you might miss some logs.

I have noticed that if any serverless function (or my NuxtJS app) sends any data to the console using console.log, then it may not get picked up by the realtime function logs. Specifically if my code triggers a log event closer to the beginning.

My best guess is that based on how the serverless functions are spun up from their "cold start" state, the Vercel logging catcher system is not spun up fast enough to catch the early ones. Sounds strange right?

My workaround: use console.warn instead of console.log. Every warn log seem to get captured by the Vercel realtime logs, no problem.

#21. Vercel and PrismaJS

I really like Prisma. And I really like Vercel. But... they seem to work kinda strangely together.

Yes Vercel can support Prisma JS. But, I have run into several hiccups while trying to do so.

If you are not familiar with Prisma JS, here is a quick snapshot of how it works:

turn a MySQL or Postgres database into a GraphQL style interface
you define your database schema in your prisma.schema
create a "migration" file of each database change (allowing you to track database changes via git)
after a migration, you need to "generate" a new "PrismaClient" (basically just a fancy type-safe adapter for your database)
you can make database calls like this: const user = await prisma.user.findUnique({where: {id:1} });

Prisma is super great to use. But...

#22. Vercel/Prisma cache issues...

When you update your schema, you must generate a new "PrismaClient". Normally not a problem, except when the Vercel build cache comes into play.

The Vercel build cache seems to save a copy of your node_modules folder after the most recent build (creating a cache of it). But, when Prisma generates its client (via the prisma generate command) the client gets stored in the node_modules folder. Which is cached.

The problem is here: if you push a schema change to your app (via git), the app gets deployed to Vercel. Who will use the current build cache (and therefore the old PrismaClient) in the new deployment of your app. So your app tries to use any of the updates database schema fields or tables, the older cached version of the client will not find them. Kicking and error and making your app not work. Sad.

This is obviously a problem for Prisma/Vercel users (like myself).

So this is what I have found works, you have two options:

#23. Option 1: what the PrismaJS team recommends

The wonderful people over at PrismaJS recommend adding the prisma generate command into your vercel-build command (in your pacakge.json file).

So every time your code is deployed, the newest PrismaClient will be generated. Good day right? Well....

This method will force the Vercel builder to run this command for every single one of your serverless functions it builds. Including each of your serverless API routes. Which add up quickly.

So in result, your builds will take WAY longer. Since it will generate the client multiple times in the same build. This is fine if you are making regular changes to your database schema. But be honest, how often do you update your database schema vs how often do your commit new code to your app???

I don't use this method.

#24. Option 2: what I think works the best

After making database changes and updating my prisma.schema file, I know I need to generate a new PrismaClient the next time I push to Vercel (either for production or staging environments).

Before committing my production ready code to the production git branch, I use the Vercel CLI to publish to production first. Why? Because the Vercel CLI can force regenerate the build cache. And push to production.

I run this command: vercel -f --prod

Then after that build is complete, I push to git. This does create another complete "production" build in Vercel, but I usually go in and cancel it.

While still being a bit subpar, I personally think this is the best option. Mainly because this only becomes an inefficient solution when you have made a database schema change. Which after the first bit of work on a project is not that often.

PS: I have talked with a Vercel developer advocate about this before, and he understand that it is suboptimal. And they are going to look into ways to make it better 😁 Go Vercel!

Some useful reads from the web

As I have journey around the Vercel platform (and the internet trying to figure things out), I have collected these very useful resources for people using Vercel. I hope they help you too:

Official posts and docs from the people of Vercel:

Assorted other places around the web

So the real question: is Vercel worth it?

In short, yes.

After my few odd months of using Vercel, including testing and deploying my first production app to Vercel (this url shortener service), I have to say: Vercel is great.

The platform is well built, the docs and developer experience is great, and the people of Vercel often reach out and try their best to help when users run into issues. (like I said early, several different employees reached out trying to help me already)

The biggest downside for me: NuxtJS. The support for Nuxt is a bit lacking on Vercel, both in documentation and out of the box support. Which I guess is understandable, considering Vercel runs/supports the competing javascript framework NextJS.

But in the end, I am a very happy user of Vercel. And plan to be for the foreseeable future.

And who knows, maybe I will work there one day... ✌

This article was originally posted to my personal site at frostbutter.com

Fix PHP fatal error "allowed memory size of"

Nick Frostbutter — Fri, 28 Jan 2022 00:00:00 +0000

This fatal error occurs when your web app or website is using too much memory. Plain and simple. Just like a local application running on your computer, your website takes some amount of memory to run. So at your site runs on your hosting provider's servers, you are using up some of that server's memory, known as RAM.

Once your website has reached the PHP memory limit that is set in your server's PHP configuration file, usually 8MB by default, you run out of your available memory limit.

Common Fixes for "fatal error allowed memory size of"

There are a couple of quick fixes for the PHP "fatal error allowed memory size of" error message. The basic gist of these different fixes: your website needs MORE memory and need to be more efficient. Maybe both.

Raise the PHP memory limit with code

The quickest and easiest way to fix the memory limit error is to raise your PHP memory limit. By default, the php.ini configuration file sets the memory limit to a whopping 8MB. This is usually enough for most websites, but not always.

If you don't have access to the server configuration files, like most people, you can add a single line of PHP code to your website to boost the memory limit of php. Just add the line of code below to any and all pages that are giving you the "php fatal error allowed memory size" error message. And adjust the amount of memory you need to get the website back up and running again.

<?php 
  ini_set("memory_limit", "16M");
?>

Raise the PHP memory limit for server via config files

Alternatively, if you want to boost your memory limit for the entire web server then you can update the php.ini configuration file. Browse over to your web server's php directory and find the php.ini file.

Browse around in the config file, with some Ctrl + F action, and locate the "memory_limit" setting. It will likely be set to "8MB". Just boost that sucker up to the amount needed to clear the fatal error.

NOTE: You want to keep the memory limit as low as needed to clear the "allowed memory size" error. It will help your site run faster since it will take up the least memory needed to successfully operate.

Set PHP memory limit in WordPress

If you are using a WordPress website, don't worry. You can also raise your PHP memory limit on WordPress too. Just need to make an update to the wp-config.php file for your website.

Browse on over to the script using your preferred FTP client, or directly from a cPanel file manager. Once you get it, load up the wp-config.php file into a text editor.

You need to add this one line of code into the WordPress config file. (I recommend adding it right after the similar line of code that sets the WP_DEBUG setting.)

  define( 'WP_MEMORY_LIMIT', '256M' );

This line of code will tell WordPress to set the PHP memory limit specifically for your WordPress website. After you add the new line of code, save your changes and upload the wp-config.php file back where you found it.

You can learn more about the WordPress configuration file from the official WordPress website.

Still not Enough Memory Limit??

If you are still getting the "php fatal error allowed memory size of" error message then your website has a much bigger problem. You for sure need to look into making your website more efficient and taking up less resources.

For those web developers, you need to figure out when the fatal error message started happening. What changed? Did you push an update to your site? Update some plugins? Install new services or code?

Try to backtrack in your code, if able, back to the most recent stable version. Then take a good comb though the newer code and see if you can find that memory leak!

This article was originally posted to my personal site at frostbutter.com

Create a custom Laravel Valet driver

Nick Frostbutter — Thu, 20 Jan 2022 00:00:00 +0000

Valet is the best! I mean it. Perfect for the a solid, lightweight, and minimal development environment. You can link your project's directory then browse to the project using a ".test" domain. So clean.

The problem that I faced was that I don't use Laravel. A sin for a php developer I know. So in order to be able to use Valet style ".test" domains for my custom web apps, I must create a custom Valet driver for your app. Luckily, if you write it once (or use mine) then you will be set until Valet or Laravel changes a bunch. So basically, forever 🤞

What is a Valet driver?

Just a single class. Specifically a custom class that extends the " LaravelValetDriver" class. The goal of these custom drivers enables developers to use Valet for other web apps or CMS that are not natively supported in Valet.

You can use these drivers to specifically handle the routes needed for your web app on your local dev environment to speed up and betterify (real word) your dev life.

Where to save your custom Valet driver?

Really you have a few options. Most of the default drivers that come with Valet are stored inside of the local default folder at ~/.config/valet/Drivers. This is where you can save all of your custom, reusable drivers. They will be automatically loaded by Valet when pages are rendered. No more setup needed.

You can also add the unique driver into your web app's working directory. Say you are building you app in your C:\xampp\htdocs\mysweetapp. You place the custom driver inside the root of your apps folder. It However, it must be named " LocalValetDriver.php". When you link this folder to Valet, it will automatically use this local driver for your site " mysweetapp".

For this article, I will be doing the second option.

Create a file named LocalValetDriver.php

This local valet driver will be loaded only for the current application. No more, no less.

class LocalValetDriver extends LaravelValetDriver {
    /** your code here */
}

Since we extend the built in Laravel class named LaravelValetDriver , we are required to have 2 functions.

serves(), and
frontControllerPath()

"serves" function

The serves() function is used to determine if the current web app should use the valet driver. It receives 3 parameters returns true or false. If serves() returns a true, then Valet will attempt to use the driver to actually load and process your website. We want true.

$sitePath : the absolute path that your linked site inside of valet (e.g. C:\xampp\htdocs\mysweetapp)
$siteName : the name that your valet site (e.g. mysweetapp); the same name used for your .test site (e.g. mysweetapp.test)
$uri : the actual uri from the browser request; say you visit mysweetapp.test/contact, the uri is "contact". If you browse to mysweetapp.test, the uri is empty

The logic inside the function is simple. We check for specific files that are specific to the web app or CMS you want to use this custom driver for. WordPress for example would check for wp-config.php.

/**
* Determine if the driver serves the request.
*
* @param string $sitePath
* @param string $siteName
* @param string $uri
* @return bool
*/
public function serves($sitePath, $siteName, $uri) {
    return ( file_exists($sitePath.'/init.php') && file_exists($sitePath.'/config.ini') );
}

For my app, I am checking for 2 files: init.php * and config.ini. These files then would need to exists inside If they exists my working directory, C:\xampp\htdocs\mysweetapp\this-file-here.php. If they are both found, then the driver will be loaded and used by Valet.

"frontControllerPath" function

The frontControllerPath function returns the full absolute path of the page being loaded on your website. Fully resolved, as they say. This function is the heart of your custom driver. It will perform all the logic to check if the file exists. Even use it to hide php file extensions with Valet (like I do).

The frontControllerPath() function takes the same parameters as the serves() function. The exact same. How convenient.

In my custom driver's function, I first check if the the request uri is the root of a directly (e.g. mysweetapp.test) and loading the index.php file by default.

Next checking if the request uri is an actual file that exits with the given extension (e.g. mysweetapp.test/page1.php).

Then checking if the the uri exists with the added php extension (e.g. mysweetapp.test/page_name turns into page_name.php). This will effectively hide php extensions inside of Valet. I love it and use it for every web app.

Finally defaulting to the 404 page that is located inside the public_html directory. If no 404.php file exists, then it will default to the default Valet 404 page.

/**
    * Get the fully resolved path to the application's front controller.
    * @param string $sitePath
    * @param string $siteName
    * @param string $uri
    * @return string
*/
public function frontControllerPath($sitePath, $siteName, $uri = 'index.php'){
    // add the public folder to the sitePath
    $sitePath .= '/public_html';

    // smart handle the requests, defaulting to index.php in directories and hiding php extensions
    if ( is_dir($sitePath . $uri) && file_exists ( $sitePath . $uri . '/index.php' ) )
        return $sitePath . $uri . '/index.php';
    else if ( file_exists ( $sitePath . $uri ) )
        return $sitePath . $uri;
    else if ( file_exists ( $sitePath . $uri . '.php') )
            return $sitePath . $uri . '.php';
    else
        return $sitePath . '/404.php';
}

Complete custom Valet driver for a custom web app

The complete working version of my custom Valet driver is below. Of course feel free to modify it to your hearts content. Source available on GitHub.

<?php
/**
* Local valet driver for a custom framework or web app
* by Nick Frostbutter (https://frostbutter.com)
* - loads index.php file by default in all directories
* - hides "php" extensions by default
* Tutorial: https://frostbutter.com/articles/create-a-custom-laravel-valet-driver-hide-php-extensions
*/

class LocalValetDriver extends LaravelValetDriver {
    /**
    * Determine if the driver serves the request.
    *
    * @param string $sitePath
    * @param string $siteName
    * @param string $uri
    * @return bool
    */
    public function serves($sitePath, $siteName, $uri) {
        return ( file_exists($sitePath.'/init.php') && file_exists($sitePath.'/config.ini') );
    }

    /**
    * Get the fully resolved path to the application's front controller.
    *
    * @param string $sitePath
    * @param string $siteName
    * @param string $uri
    * @return string
    */
    public function frontControllerPath($sitePath, $siteName, $uri = 'index.php'){
        // add the public folder to the sitePath
        $sitePath .= '/public_html';

        // smart handle the requests, defaulting to index.php in directories and hiding php extensions
        if ( is_dir($sitePath . $uri) && file_exists ( $sitePath . $uri . '/index.php' ) )
            return $sitePath . $uri . '/index.php';
        else if ( file_exists ( $sitePath . $uri ) )
            return $sitePath . $uri;
        else if ( file_exists ( $sitePath . $uri . '.php') )
                return $sitePath . $uri . '.php';
        else
            return $sitePath . '/404.php';
    }
}

?>

This driver has been a delight, just like Valet. Making your life as a developer easier is a must.

If you are interested, you can read more about custom Valet drivers from the Laravel docs here.

This article on how to create a custom laravel valet driver was originally by me, Nick Frostbutter, on my personal site.

Deploy NuxtJS SSG with Cloudflare Pages

Nick Frostbutter — Mon, 17 Jan 2022 05:00:00 +0000

After discovering the wonders of Cloudflare Pages and tinkering around a bit, I was hooked.

With the very straightforward "deployment pipeline" I could setup for each of my static NuxtJS websites, I made the move. I shifted all of my NuxtJS static websites over to Cloudflare Pages.

PS: This article is not sponsored by or affiliated with Cloudflare. They just make really awesome products, and give a very generous free plan to people. And I like free. 😁

What is Cloudflare Pages?

In case you have not heard about this newer amazing product from the folks at Cloudflare, Pages are a near effortless JAMstack platform to deploy static Git based websites.

Here's the gist:

connect your Git account (GitHub or GitLab)
select your repo to deploy
set your build steps (aka generate the static site)
get a live static website at "your-site-name.pages.dev"

Use Cloudflare Pages (for free)

To actually deploy any repo, you will need a Cloudflare account. If you don't already have one, you will can signup for one. Don't worry, it's free. Like actually free. Like no questions asked free.

Once in your Cloudflare account, navigate to the "Pages" page. (I know, this is like rocket science here.)

How to Deploy NuxtJS to Cloudflare Pages

From the Pages window, select the Create a Project button. You will then be able to connect your GitHub or GitLab account. Either allow access to your entire account, or select the specific repos. You can even select the repos from any of the organizations you are apart of.

Select the NuxtJS repo to deploy

From the list of repos, select the NuxtJS SSG repo you want to deploy. Then Begin Setup.

Name your project

The project name you choose will automatically give you a *.pages.dev url to access the production builds of your NuxtJS SSG site.

Select your repo's "production" branch

Next, select the "production" branch for your NuxtJS site. This can be any of the branches that your repo has. It is likely "master" or "main". Any pushes to this "production" branch will automatically build your site, and deploy it to your site's domain.

Note: At the time of me writing this article, Cloudflare does not currently allow removing this "pages.dev" url from the account.

This is because that "pages.dev" url will also allow you to view all your preview deployments for your repo. And "preview" meaning any other commits that are not on your production branch.

Enter your NuxtJS build settings

Inside of the Build Settings, select NuxtJS as the framework preset. This will auto populate the build settings to use the default nuxt gnerate build command, with a final output directory of dist. If you have manually changed these settings for your Nuxt app, then just update these here. Otherwise, the defaults are likely what you want.

Are you deploying a monorepo? No problem!

If you are using a monorepo setup, like I am for the nuxt-seo project, then you can also deploy that to Cloudflare Pages.

Inside the _ Build Settings _ area, click the Root directory (advanced) link to view the extra settings.

To build only the specific potion of your monorepo, like a "docs" site, then enter the name of that directory as the path:

In my case of the npm nuxt-seo package, the nuxt-seo docs site is located in the "docs" directory. So my path is set to "docs" to only generate the static docs site with Cloudflare Pages.

Nuxt generate with env vars

If you need to set specific env vars that affect your Nuxt SSG build, then you can enter them in Cloudflare Pages as well:

To read more about the specific ENV vars that Cloudflare automatically exposes, check their build configuration docs

Set a custom domain for Cloudflare Pages

Once you have a successful build for your new Cloudflare Pages site, you can set a custom domain.

From inside the Pages manager in the Cloudflare Dashboard, navigate to the _ Custom Domains _ tab. Enter the domain name you wish to use as your primary domain for your Cloudflare Pages static site.

You will then be prompted to update your DNS settings, creating a CNAME record for your custom domain.

PS: If your DNS is already managed by Cloudflare, you can update the settings with the one click "save" button. If not, then you will have to manually create a CNAME record with your DNS provider.

My final thoughts on Cloudflare Pages

With Cloudflare Pages being still fairly new, I have run into a few issues with deployments. Sometimes I will get build failures. Most of the time, these failures were because of Cloudflare Pages using using an older version of Node and NPM by default.

Fortunately, you can manually set the Node and NPM version using the build ENV settings, like I discussed above.

Sometimes the builds can be a bit slow, taking ~5-10 minutes to finish the build. But then again, it's free. So I am so very willing to wait for free 😁

With all that said: they are awesome, but still early on. I really like the way they are setup and how easy it is to setup an automated deployment pipeline for my static sites (including my blog here).

This article was originally posted to my personal site at frostbutter.com

Setup font awesome in Vue and NuxtJS

Nick Frostbutter — Wed, 12 Jan 2022 00:00:00 +0000

If you have been living under a rock for several years and don't know, Fontawesome a wonderful icon library. It's open source, SVG based, and can be used on any website like utility classes.

Two different options to get awesome

Before the setups steps you should know, there are two ways to use Fontawesome icons in a Vue or Nuxt project:

"component" based icons
or utility "class" based icons

Both options work well, and are really just a matter of preference. But they have very similar setups, so I'll show both methods here.

With "component" based icons, you can add icons like this:

<font-awesome-icon :icon="['fas', 'user']" />

With utility "class" based icons, you can icons like this

<i class="fa fas fa-user"></i>

With Vue being a componentized framework, some people really love being able to use Fontawesome icons just like any other component. Personally, I do not.

I really like the utility class method. I find it easier, and I can use other Tailwind utility classes or regular CSS to style icons further when I want to.

Install the "fortawesome" packages

That's right. The package is actually fortawesome. Not fontawesome. Don't ask me why...

Using your favorite package manager, install the fortawesome dependencies.

npm install @fortawesome/fontawesome-svg-core @fortawesome/free-solid-svg-icons

This will install the " core" package which you must add. As well as the "solid" icon pack. This will allow us to use the solid icons from Fontawesome.

If you want to add more icons into your project, then you can also install the "brands" and "regular" icon packs. (I end up using the same brand icons, like Twitter and GitHub a lot.)

npm install @fortawesome/free-brands-svg-icons @fortawesome/free-regular-svg-icons

You can see the official NPM package here: @fortawesome/fontawesome-svg-core

Setup Fontawesome in Vue JS

If you are using a regular Vue JS project, then open up your _ main.js _ project file, add add the following code to it:

/* Import all the font awesome goodness */
import { library } from '@fortawesome/fontawesome-svg-core'

// loads all the "solid" icons
import { fas } from '@fortawesome/free-solid-svg-icons'

// loads only the "twitter" brand icon
// import { faTwitter } from '@fortawesome/free-brands-svg-icons'

// add each of the imported icons into the app
library.add(fas); // can be a list of all the icons e.g. (fas, fab, faTwitter, etc)

// to use component based icons
//import { FontAwesomeIcon } from '@fortawesome/vue-fontawesome'

// to use class based icons
import { dom } from '@fortawesome/fontawesome-svg-core'
dom.watch();

Note: Specifically, you should add this code before you create your "app" object.

Here we are importing the library object from the fortawesome core. The library will allow us to specify which icons we want to use in our project. More on

Next, I import fas from the solid icon pack. This is how you import all of the solid icons from the solid icon pack. The same way works for the brand icons. To import all the brand icons, import fab from the brand icon pack.

Make sense?

If you want to only use a specific icon in your project, you can import only the desired icons from the each icon pack. For example, to only import that twitter icon from the brand pack, use this line:

import { faTwitter } from '@fortawesome/free-brands-svg-icons'

Note: the icon names are written in Pascal case. (e.g. "faTwitter", not"fa-twitter")

After importing all the icons you want for your project, we add them to the library.

library.add(fas); // can be a list of all the icons e.g. (fas, fab, faTwitter, etc)

// addd all solid icons and twitter
library.add(fas, faTwitter);

In the add function, you can pass the list of all the icons you imported and want to use in your project.

To use component based icons:

Import the FontAwesomeIcon component on each of your .vue pages you want to use the component. This way, you can use font awesome icons like any other vue component. Like this:

<font-awesome-icon :icon="['fas', 'user']" />

Just pass in an array into the icon prop. The first item in the array is the library you imported, the second item is the icon name itself.

To use the utility class icons:

We import dom from the fortawesome core. The dom will allow us to use the utility class method of using the icons. the dom.watch() function is where the magic happens for Vue to enable the normal font awesome classes to work properly.

Using this way, you will be able to add fontawesome icons like regular html:

<i class="fa fas fa-user"></i>

If you are going to use the component method for the icons, then you do not need to import dom or use dom.watch()

But like I said earlier, this is the method that I REALLY prefer. It seems cleaner.

Setup Fontawesome in NuxtJS

If you are trying to add Fontawesome icons into a Nuxt JS app, the setup is very similar. The only difference is that in order to actually tell Nuxt to use Fontawesome icons, you must create a plugin with the code from the section above, then load the plugin in your nuxt.config.js file.

Create the Fontawesome plugin

From inside your Nuxt app's root directory, create the new file ~/plugins/fontawesome.js.

If you do not already have a plugins folder, just create it now 🙂

In the exact way I explained above, import and add all the Fortawesome icons you want to use in your project:

/* Import all the font awesome goodness */
import { library, dom } from '@fortawesome/fontawesome-svg-core'
import { fas } from '@fortawesome/free-solid-svg-icons'
import { faTwitter } from '@fortawesome/free-brands-svg-icons'
library.add(fas, faTwitter);
dom.watch();

Save the code into your new fontawesome.js plugin file.

Add your new plugin into your "nuxt.config.js" file:

plugins: [
  '~/plugins/fontawesome.js',
],

All done. Reload your hot server, and give it a test. Enjoy the awesome that is Fontawesome!

This article on how to setup font awesome in vue was originally by me, Nick Frostbutter, on my personal blog.

Backup and restore MySQL databases (from the command line)

Nick Frostbutter — Mon, 10 Jan 2022 00:00:00 +0000

The last few days, I have been migrating my side projects between two different servers.

While doing so, I needed a quick way to also backup and restore the MySQL databases. The most simplest and most effective way to do is is with the command line. Using the mysqldump and mysql commands.

PS: Sometimes I do use phpMyAdmin to create a quick database backup. But sometimes, I will get some weird errors while trying to import the database later. Also, phpMyAdmin gets limited by your server's PHP file upload limit.

TLDR;

The quick and dirty version:

have your MySQL username, password, and database name on hand
ensure this MySQL user has the correct permission to create tables and records
upload your backup file to the new MySQL server (if it's different from the initial server)

Backup your MySQL database with mysqldump

To create a MySQL backup from the command line, use the mysqldump command:

mysqldump -u mysql_username -p datbase_name > /path/to/the/new/backup/file.sql

You will get prompted for your the password for the mysql_username account. Then, your database backup will begin.

This will create a full MySQL database backup to the same server in a new file located at /path/to/the/new/backup/file.sql.

Note: If this file already exists, it will be overridden. If your ssh account does not have write access to this file location, then the backup operation will fail.

Transfer the database backup to the new server

If you need to transfer the database backup to a different server, like I did, you can securely download it using the scp command from your local computer.

To download a file with scp, run this on your local computer:

scp remote_user_1@server_1_ip:/path/to/remote/file.sql /path/to/local/computer/save/directory

Then you can upload the file to the other server, run this on your local computer:

scp /path/to/local/computer/save/file.sql remote_user_2@server_2_ip:/path/to/upload/remote/file.sql

Restore a MySQL backup

With your backup file on the final server (or even the same server as the backup was taken from), you can restore the MySQL database backup from the command line using the mysql command:

mysql -u mysql_username -p database_name < /absolute/path/to/the/backup.sql

When prompted, enter your MySQL user account's password. Then you're off to the races! 🚀

Your database tables and records will begin to be created. The overall time for this to complete will vary based on the backup size, compression, and server specs.

How to backup and restore a MySQL database

To actually backup and restore the MySQL database backup using the command line, you will need:

the MySQL username and password for the database
command line access to your MySQL server
a database that your MySQL user has permissions to access, (or permissions to create one)

If you are using a MySQL provider like DigitalOcean, like me, then you should be able to SSH into the server and be ready to go. If you are using a MySQL provider like Bluehost or A2 hosting, then you may need to request SSH access from their support line.

Connect to your MySQL server

Using the command line, SSH into your MySQL server.

ssh server_username@ip_address
# or
ssh server_username@domain.tld

List your MySQL databases

If you do not already know the name of the database you want to create a backup of, then you can list the MySQL databases your MySQL user account has access to:

Using the mysql command line tool, aka cli, and a valid username and password:

mysql -u mysql_username -p

You will get prompted to enter this MySQL user's account password. Then this will connect to the database server, with the MySQL user mysql_username.

Note: The -p flag will let the terminal to prompt us for the password. Without the -p flag, then your connection will likely fail. Saying something like "password required"

When your connection was successful, you can list the MySQL databases the mysql_username account has access to:

show databases;

After you know the database name, exit from the mysql cli:

exit;

Create a MySQL database backup with mysqldump

In order to create our MySQL database backup, especially for a quick full backup, I like to use the mysqldump command. Not only is it installed with MySQL (and MariaDB) by default, but the command has basically the same syntax as the mysql command. But more on that in a bit.

With the name of your database on hand, run the mysqldump command like this:

mysqldump -u mysql_username -p datbase_name > /path/to/the/new/backup/file.sql

-u mysql_username - connects to the MySQL database with the MySQL user account names 'mysql_username'
-p - tells MySQL to prompt me to enter the user's password
datbase_name - simply the name of the MySQL database you want to backup
> /path/to/the/new/backup/file.sql - pipes the output from the command into a local file on the same server

Notice the direction of the > character. This tells the command to send the mysql database records into the specified file.

After running the command, you will get prompted for your the password for the mysql_username account. Then, your database backup will begin. Unfortunately, you will not see any change in the terminal while the backup is in progress. But once it is done, the terminal will drop back to the prompt. Allowing you to continue.

And naturally, the time to create the backup will vary based on the size of the database and the specs of the server. For a benchmark, my database was about 500k records and took ~2mins.

Securely download your database backup

If you need to transfer the database backup to a different server, like I did, you can securely download it using the "secure copy" command scp command from your local computer.

To download a file with scp, run this on your local computer:

scp remote_user_1@server_1_ip:/path/to/remote/file.sql /path/to/local/computer/save/directory

Securely upload your database backup

In order to actually restore the backup on your MySQL server, you will need to upload the backup file to the new server.

To upload the database backup from your local computer, use the "secure copy" command scp:

scp /path/to/local/computer/save/file.sql remote_user_2@server_2_ip:/path/to/upload/remote/file.sql

Note: Both of these scp command examples are run from my local computer since the SSH keys for each of these servers are on my computer. If you have the SSH keys setup to transfer files directly between these two servers, then you could simply scp between the two.

Create your MySQL database server

Now that we are connected, we can show the list of available MySQL databases:

show databases;

Delete MySQL database (as needed)

If you are restoring from a complete MySQL database backup from mysqldump, then you may need to delete the already existing database, then recreate it. Counter-productive, I know.

To delete a MySQL database, use this command:

drop database name_here;

Note: In order to DELETE new MySQL databases, you user account will need the DELETE permission item. If your account does not have it, you may need to DELETE the database from your hosting control panel.

Create a new MySQL database

If it does not already exist on the server, you can create a new MySQL database with this command:

create database name_here;

Note: In order to CREATE new MySQL databases, you user account will need the CREATE permission item. If your account does not have it, you may need to CREATE the database from your hosting control panel.

Select the MySQL database to restore

Once your database exists, you can select it with the use command:

use database_name;

You must select (aka use) the database to use in order to restore the backup.

Restore the MySQL database from the backup

Since we have uploaded our database backup, we are ready to restore this backup.

Exit from the mysql cli, using the exit; command. Then from the regular terminal prompt, restore your database backup:

mysql -u mysql_username -p database_name < /absolute/path/to/the/backup.sql

Notice the direction of the < character. This tells the command to read the contents of the file and send it to the mysql program. (aka import the backup)

Hope this article helped our. Happy backups! 😁

This article was on how to backup and restore a MySQL database was originally posted to my personal site at frostbutter.com

Add CSS Scroll Animation and Smooth Scrolling

Nick Frostbutter — Fri, 07 Jan 2022 14:42:20 +0000

The basic way to add smooth scroll animation is using anchors/indexes on your website. Those are the hashtag urls that you can set inside of a link. By default, if someone clicks on of the link their browser will jerk them down to the location of the anchor/id on the page. No so pretty looking. And certainly not a great user experience.

So, how to add the smooth scroll animation you ask?

add the anchor link on your page: <a href="#my_link">
create the anchor endpoint on the page element: <div id="my_link">
add the CSS scroll animation property, aka scroll-behavior
enjoy

Add the anchor for smooth scrolling

Assuming you have your website already setup, find whichever link you want to use as your action. Simply assign the href parameter with a hashtag ("#") link of the id the page element to stop scrolling at.



<a href="#myelement">click here to scroll to "myelement"</a>

Create the smooth scroll endpoint element

Next, assign an "id" attribute to the element you want your smooth scroll to stop at. Make sure you give it the exact same name as previously used in the anchor tag. But without the "#" in the id value.



<div class="whatever" id="myelement"></div>

Add CSS scroll animation with "scroll-behavior"

With your page's anchor and endpoint all setup on your website, you can add the smooth scrolling effect by adding this single line into your main CSS file for your website:



html{
  scroll-behavior: smooth;
}

Note: It is important to add the scroll-behavior style on to the html tag so your entire website will have the smooth scrolling effect.

Some people, including myself, have tried to set the smooth scrolling on the body tag. But that does not work for some reason.

Once you save your changes, and reload the CSS into the browser, your snazzy new smooth scrolling will be in effect.

CSS scroll animation on old browsers?

The downside of this UX tip, is that the CSS scroll animation does not work in older browsers. But anyone using any reasonable modern browser should be fine. And worst case, they won't get the added UX boost. But let's be honest, if they are using an older browser (cough internet explorer cough) then they already make poor life decisions. And obviously not looking for the best user experience on the web. Right?

The good news is that browser support for the CSS scroll-behavior property has been around for a bit. So that's a plus :)

This article on css scroll animation was originally posted to my personal site at frostbutter.com

JavaScript current year with getFullYear()

Nick Frostbutter — Sat, 01 Jan 2022 14:27:58 +0000

Did you hard code the year in your footer? New year, new problems.

With this one-liner, you can dynamically set the year with JavaScript:

let year = new Date().getFullYear();

If you are using VueJS or NuxtJS, you can add the current year code directly into your template section

<template>
    <footer>
        Copyright © {{ new Date().getFullYear() }}
    </footer>
</template>

You can find more useful dev articles on my site, frostbutter.com/articles

How to Install Ghost CMS on Windows localhost

Nick Frostbutter — Wed, 29 Dec 2021 20:19:56 +0000

The thing about trying to install Ghost CMS on Windows is that there a few, let's say nuances. Ghost CMS is actually designed to be run on a specific Ubuntu linux version. So you have to perform some extra steps to setup a Ghost blog on Windows. Fear not, it can and shall be done.

Quick overview to install Ghost CMS on Windows

(1) To actually install Ghost CMS on Windows, you will need to get the backend server setup. So you will have to install NodeJS server, if you don't already have it. Which most people on Windows don't already have a NodeJS server setup. Since most just using something like XAMPP for a localhost PHP/MySQL server.

(2) After NodeJS is installed, you can use the Node Package Manager (aka npm) to install Ghost blog on Windows. When installing Ghost locally, it will actually use a local SQLite database for you to perform your testing on. No need to worry about having a MySQL database installed and ready to use with Ghost CMS. How nice of them :)

(3) Once your localhost Ghost blog is installed, you can work your way through the very simple setup wizard to create your account and start getting to know Ghost CMS.

Let's get to it!

Install Node JS server on windows

Download the NodeJS installer from NodeJS.org. You can run through the generic Windows installer pretty smoothly. I recommend leaving all the defaults set as to where NodeJS will install to and the packages tit will install. This just makes things easier.

Note: If you are using Visual Studio Code, like most developers using Windows, then you should for sure install Chocolatey. It will also install the VS Code addons to enable better integration into VS Code for your Ghost CMS editing.

As you install Node JS on Windows, you will get a PowerShell prompt that will run through a portion of the installation. This PowerShell will install Python, Chocolatey, and Visual Studio Tools if you do not already have them installed. Do note, it can take a few minutes to install all of these thing. Totally okay. I think my installation took about 5 minutes.

So go get a fresh cup of coffee ☕

You should restart your computer after installing NodeJS in order for all of the new dependencies and software packages to work properly.

To verify Node is installed, run the node -v command and npm -v command in your windows terminal or PowerShell. (I prefer the terminal that is built into VS Code). The two commands should return the version number of your Node and node package manager (npm) version. If the return a number, then you are good to go. If not, then your installation was not successful and you might need to try again.

Install Ghost CMS on Windows

Once NodeJS is installed, you can either download the official Ghost source code from GitHub or use node package manager (npm) to install Ghost CMS. I prefer using npm since it is way faster and easier. So that is what I will show below.

Note: At the time of me writing article, Ghost 3.0 is the most up to date version of Ghost CMS. But the installation should be about the same with future versions.

Where to install Ghost CMS?

Honestly, chose any folder you would like. Since Ghost CMS runs on NodeJS, you are not required to use an particular directory to install Ghost to. Unlike other server software like Apache. But since I do loads of regular PHP development and have XAMPP installed on my Windows laptop, I am going to have my Ghost blog in my usual htdocs folder.

No matter where you want to install Ghost, use your terminal to navigate to that directory (using the cd command). Then create a new folder to actually install and be the home for your Ghost blog (e.g. "ghost-blog"). And finally navigate into that new folder ("cd ghost-blog").

cd C:\xampp\htdocs\
mkdir ghost-blog
cd ghost-blog

Install Ghost CMS in Windows with npm

Once inside of your newly created Ghost blog folder, you are ready to install Ghost CMS. It takes two steps.

Install the Ghost CLI (command line interface)
Then actually installing the Ghost blog website files

Possible error:"ghost.ps1 cannot be loaded because running scripts is disabled on this system."

If you are getting the "ghost.ps1 cannot be loaded because running scripts is disabled on this system" error message (or something similar), then you will need to run the two installation commands with the runas command prefix. This will force PowerShell to run the command as the administrator account you specify. Just include and update the command below to run each as an administrator. Like this:

runas "/user:usernamehere" "yourcommand_here"

Or you can run VS code/terminal as an administrator, then give VS code permission to run commands in terminal as an Admin with the following command:

Set-ExecutionPolicy Unrestricted

Install Ghost CLI in Windows

npm install -g ghost-cli@latest

With that single command, your Ghost CLI installation will begin downloading and installing, automatically. With the latest version of course. My install took about 23 seconds. So not to bad.

Actually Install Ghost CMS in Windows

ghost install local

While installing Ghost CMS, you may get a Windows firewall prompt to allow NodeJS to access the internet (or be accessed by other devices on your local network. You will need to allow at least the "private networks" option to be able to actually view your Ghost blog.

Once the install is complete, it will automatically start the Ghost server for you.

How nice of them :)

Enjoy your new Ghost blog on windows!

That's it. You are done installing Ghost CMS on Windows. Super easy right? Right! You can browser over to your Ghost blog by navigating to the localhost url that is given in your terminal window. Likely something like http://localhost:2368/ghost/.

From this url, you will be able to complete the Ghost CMS setup and customize your Ghost blog. Enjoy all the greatness and speed of Ghost CMS!

Finish the Ghost blog setup wizard

With your new Ghost blog created, you can work your way though the quick setup wizard. The quick steps will let you create the your first account and even invite other users to be Ghost CMS managers of your new Ghost blog.

This article on "how to install ghost CMS on Windows" was originally published to my site, frostbutter.com, where you can find more useful dev articles.

Fix "PHP executable not found" error in VS Code

Nick Frostbutter — Mon, 20 Dec 2021 15:54:42 +0000

Nobody likes errors, least of all computer programmers!

If you are a PHP developer and recently installed Visual Studio Code (VS Code), then you are most likely getting a pesky "PHP executable not found" error message every time you start the program.

Some of the other VS Code error message you will see with the PHP executable not found message includes:

Install PHP 7 and add to your PATH"
"set php.executablePath setting"
"Cannot validate since no PHP executable is set"
"Use the php.validate.executablePath to configure the PHP executable"

With every single one of these VS Code error messages, you simply need to update your Windows PATH setting for your PHP executable location. Doing that will fix all of these PHP executable errors!

How to fix PHP executable not found error in VS Code

Install php on your computer (e.g. with XAMPP)
Locate your php installation directory
Open Advanced System Settings on Windows
Update the Windows "PATH" environment variable
Close VS Code and reopen it

Step 1: Install php on your computer (e.g. with XAMPP)

The first and very most important step to fix the PHP executable not found error on Visual Studio Code is to actually have PHP installed on your computer. Now that might seem like an obvious starting point, but you would be surprised how many people don't have PHP installed on their local web dev environment (e.g. their localhost server).

Personally, I have always been a fan of the XAMPP suite by ApacheFriends.org. I have been using the XAMPP suite to install PHP, MySQL, and phpMyAdmin for my localhost web servers for years. I highly recommend.

Step 2: Locate your php installation directory

Once you have PHP installed on your local computer (as part of your localhost server), you need to find the PHP installation directory. As we need the folder path that holds your php.exe file.

If you installed XAMPP, simply browse to your XAMPP installation directory. The default location is at C:\xampp. From inside the XAMPP folder, open the PHP folder and locate the php.exe file. If you can find the php.exe file from in this folder, then this folder will be your php installation directory.

Step 3: Open Advanced System Settings on Windows

Now that we know your php installation directory, we need to open the actually add the folder path into the Windows' PATH. But to get there, you have to open a few different screens.

From the your file explorer or desktop, right click on "This PC". Then select "Properties" from the drop down. Doing this will open the Windows control panel menu for your system settings.

From the system settings menu, you will see all of your computer's basic information like RAM, CPU size, and your computer name.

On the left hand side of the program, you will see an option to open "Advanced System Settings". Go ahead and open the Windows advanced system settings program.

Please note: this WILL require you to have administrative permissions on your Windows computer. If you do not, then you will have to contact the person that does in order to update the Windows PATH variable.

Step 4: Update the Windows "PATH" environment variable

Once you have successfully found and opened the Windows advanced system settings popup, you can edit your Windows environment variables. While selected to the Advanced tab in the popup, click on the "Environment variables..." button at the bottom. This will open another program.

From here you can update all of your Windows environment variables. But in order to fix the PHP executable not found error message in VS Code, we really only care about the PATH variable.

So, from the list of User variables, select the "Path" option. Then click the Edit button. This will open the variable editor window.

Inside of the variable editor window, you can create a new PATH variable quite easily. Simply click the "New" button on the right hand side. Then enter in your PHP installation directory that we got from the step above.

Be sure to click away from the new path you created to ensure the updated PHP path is correctly saved into Windows.

Step 5: Close VS Code and reopen it

When you have successfully saved your PHP path location into the Windows PATH variable, you can close out of all of the Windows control panel windows.

You can now close VS code and reopen it. And you will notice that you have gotten rid of the the "PHP executable not found" error message that you get on VS code start up. Great success!

This article on how to fix "PHP executable not found" error in VS Code was originally published to my site, frostbutter.com, where you can find more useful dev articles.

Use Laravel Mix without Laravel (using npm)

Nick Frostbutter — Sat, 11 Dec 2021 11:43:33 +0000

Laravel Mix is a great tool to smooth out your development process. But I don't use Laravel. But you can still get the magic sauce of Laravel Mix without Laravel, using npm

After hours of trial and error, here is how to actually setup and use Laravel mix WITHOUT actually using the Laravel framework. Using npm.

Literally hours of struggle and errors. Hours trying to figure out how to setup Laravel mix for a Tailwind project, finally got a working result. Here is the most straightforward way to setup Laravel Mix using NPM. As well how to properly configure your webpack config file.

Side note: Even though I love what Taylor Otwell, and the great peeps over at Laravel do, I still don't use the Laravel framework in any of my PHP based web apps. It seems like a sin since it is such a popular framework. But that's cool. I just like vanilla PHP.

Install NodeJS and NPM

For starters, you will need to have node JS and npm installed on your system, whether you are running Windows (like me), Linux (sometimes like me), or Mac (never like me). Laravel Mix relies on npm.

You can find the official installer on the NodeJS website here. It's a very straightforward installer.

Create your package.json

Browse on over to your terminal window, and navigate to the directory you want to setup Laravel mix. You need to create your package.json file. Either with this command:

npm init -y

Or by using the sample package.json file below.

Add these "devDependencies" to package.json

Since we want to use Laravel Mix with NPM, we need to actually set it to be a dependency to use it in the project. But since I do not want it to load on my production site, I add as a dev dependency.

Mix needs a few other packages to be loaded as well. Listed below are the required devDependencies you should add (tailwind and browser sync are optional):

"devDependencies": {
    "cross-env": "^5.1",
    "laravel-mix": "^2.1",
    "laravel-mix-purgecss": "^2.0",
    "laravel-mix-tailwind": "^0.1.0",
    "tailwindcss": "^1.2.0",
    "browser-sync": "latest",
    "browser-sync-webpack-plugin": "^2.0.1"
}

Pro Tip: In order to get the most out of using Laravel Mix, I also use BrowserSync. And you should to! It will help you auto refresh your project while working on front end code.

Add the Mix "scripts" to package.json

The big reason to use Laravel Mix is really to use these sweet npm scripts. Each of these scripts (aka commands) have their specific uses, but you should add all of them for your current and/or future use:

"scripts": {
    "dev": "npm run development",
    "development": "cross-env NODE_ENV=development node_modules/webpack/bin/webpack.js --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js",
    "watch": "npm run development -- --watch",
    "watch-poll": "npm run watch -- --watch-poll",
    "hot": "cross-env NODE_ENV=development node_modules/webpack-dev-server/bin/webpack-dev-server.js --inline --hot --config=node_modules/laravel-mix/setup/webpack.config.js",
    "prod": "npm run production",
    "production": "cross-env NODE_ENV=production node_modules/webpack/bin/webpack.js --no-progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js"
},

If you are new to Laravel Mix and never used these scripts before, here is a brief description of what they do:

"development": compiles your CSS and JS into their final public resting place for your project. But in "dev" mode, the files are not minified. Making the build time much faster for your dev work (aka frequent changes)
"dev": just short hand for "development"
"watch": the same as dev, but you will get auto reload and rebuilds on your project (if you have browser sync setup)
"production": compiles your CSS and JS into their final public resting place for your project WITH minification
"prod": just short hand for "production"

And when you want to run each of these commands, you run them in the terminal using npm like so:

npm run dev
npm run watch

Install Laravel Mix with NPM

With your package.json file configured, we want to actually run the npm installer to download the correct versions for each of the packages we need for the project:

npm install

The download may take some time, but that is totally fine. Mine took about 8 minutes. Wowza!

Once your installation command is complete, you should see a new folder created named "node_modules". This is good! If you do not see the folder (and it full of files and folders) then something went wrong. Maybe try again?

Configure your webpack.mix.js file

Now is the time to configure your webpack script. It is SUPER important to get this script right, because if you do not then you will for sure get errors (I know from experience).

For the most part, this webpack.config.js file is pretty standard. We tell the processor to use the "laravel-mix" package as well as load up tailwind and purgeCSS.

But, you MUST update this file to your project!

let mix = require("laravel-mix");
require("laravel-mix-tailwind");
require("laravel-mix-purgecss");
/*
|--------------------------------------------------------------------------
| Mix Asset Management
|--------------------------------------------------------------------------
|
| Mix provides a clean, fluent API for defining some Webpack build steps
| for your Laravel applications. By default, we are compiling the CSS
| file for the application as well as bundling up all the JS files.
|
*/
mix.setPublicPath('update_to_your_source_folder');mix.js("location/of/your/site.js", "where/to/save/your/js")
    .postCss("location/of/your/tailwind.css", "where/to/save/your/css", [
    require('tailwindcss'),
]);

if (mix.inProduction()) {
    mix.version();
}

This config file tells webpack where to look for your CSS and JS files to actually process them for your web app. Be sure to update the following info for your:

update_to_your_source_folder: this location if the folder of your public site (relative to the location of your webpack.config.js file) (e.g. "public")
location/of/your/site.js: the relative location of your sites primary javascript file (where you can load the other javascript files as well) (e.g. "resources/js/site.js")
where/to/save/your/js: the relative location to save the new compiled JS file. this should most likely be somewhere inside of your public folder (e.g. "public/assets")
location/of/your/tailwind.css: the relative location of your sites primary CSS file (where you can load the other CSS libraries as well like tailwind) (e.g. "resources/js/tailwind.css")
where/to/save/your/css: the relative location to save the new compiled CSS file. this should most likely be somewhere inside of your public folder (e.g. "public/assets")

Enable BrowserSync via webpack? You should!

If you have made the productive decision to use browser sync, then good for you. It is a super straight forward process. You can add these lines of code directly into your webpack.config.js file (I like to put mine just above the "mix.setPublicPath" code):

let proxy_url = process.env.APP_URL;
    mix.browserSync({
        proxy: proxy_url,
        ghostMode: false,
        notify: {
        styles: {
        top: 'auto',
        bottom: '1rem'
    }
    },
    files: [
        './resources/**/*.js',
        './resources/**/*.css',
        './public/*'
    ]
});

Before you move on: update the files to auto detect!

You must update the array of "files" listed in the config. These wildcard enabled locations are all the possible locations and types of files that, when their source code is updated, browser sync will make its magic happen. Making the browser auto reload for your.

You will also need to make sure the "proxy_url" variable is correctly set to your site's local testing address. If you are using a tool like Laravel's Valet, then your "proxy_url" might be "project.test". (And yes, I also use Valet from Laravel too. Again, without using the actual Laravel framework...)

Now, with browser sync enabled with Laravel Mix you will be able to use the "npm run watch" command to get the most out of your dev environment.

Configure the tailwind.config.js file

Since for this article, and my future projects, I am setting up this project using Mix AND tailwind, we need to actually configure tailwind. I run the following command to create the scaffolding of the tailwind.config.js file for me:

npm tailwind init

This will auto-create the default (and pretty empty) tailwind.config.js file. Looking pretty darn near close to this:

// tailwind.config.js
module.exports = {
    purge: [],
    darkMode: false, // or 'media' or 'class'
    theme: {
        extend: {},
    },
    variants: {
        extend: {},
    },
    plugins: [],
}

This barebones structure is great, but you still most update the "purge" attribute. This is an array of all the locations of your source code files that use the tailwind library.

To make purgeCSS to load all the html files in your public folder, use something like this:

purge: ['./public/*.html'],

Listing out each of the folders and file type here will allow purgeCSS to auto search your source code to smartly find all the used tailwind CSS. In turn, smartly removing the unused CSS making your compiled CSS way small!

Create your CSS and HTML files

To make use the basic tailwind components and utilities, add this to your tailwind.css file:

@import "tailwindcss/base";
@import "tailwindcss/components";
@import "tailwindcss/utilities";

Let's test out Laravel Mix!

You should be ready to go and test out Laravel Mix.

In your terminal, go run the "dev" command to make sure you get no errors:

npm run dev

You should see some action in your terminal, showing you how far along webpack is at parsing and building out your compiled CSS and JS files. If all goes well, you should get a colored output stating the final file size of the compiled scripts.

Don't forget: when you are ready to move your project up to a production server, you need to run the "prod" command to actually build and minify your scripts. Or else, what was the point of all of this effort?!

Enjoy!

With these steps all completed, your fresh Laravel Mix install is complete. And looky there, no Laravel framework was used!

This article on using Laravel mix with Laravel was originally published to my site, frostbutter.com, where you can find more useful dev articles.