Forem: Ghost

Install Node on macOS, Windows, and Linux

Ryan Feigenbaum — Mon, 01 May 2023 13:40:20 +0000

As the saying goes, "Every journey begins with a single step." In the world of web development, that first step is often Node. This tutorial explains what Node is and how to install it on your system. Once installed, you’ll be ready to run Ghost locally and begin your journey of creating a custom Ghost theme.

What’s Node?

Usually, JavaScript runs in your browser, but in 2009, Ryan Dahl had the idea to create a runtime — Node — so that JavaScript could run independently of it. Today, nearly all modern web development uses Node in some way. Ghost runs entirely on Node, and, fun fact, when Ghost first came out in 2013, it ran on Node v0.10. Not even version 1!

Node Package Manager (NPM) is included with every installation of Node. It’s a command-line tool for installing, managing, and sharing JavaScript code. For example, use NPM to install Ghost or any of these other 3 million-plus packages.

Install Node on macOS

To install Node on macOS, open up a browser and navigate to the official Node website.

Click on the LTS version on the left and download the installer.

Run the installer, choosing the default options.

After the installer completes, confirm Node is installed by opening a terminal and running node -v. The terminal will output the current version of Node that’s installed.

That’s all there is to it. You’re now ready to start using Node 🥳

🏋️ If you’re looking for more control over your Node installation or foresee wanting to switch Node versions, check out the instructions for using nvm in the Linux section below.

Install Node on Windows

Go to Node’s official page. Click on the LTS version on the left and download the installer.

Follow the installer prompts. It’s recommended to check “Yes” on the Tools for Native Modules screen to ensure you don’t run into potential compatibility issues in the future. Checking this box runs an additional installation script.

After installation, confirm that Node is installed correctly by opening your terminal and running node -v. The command will output Node’s version number to the console.

You’re now ready to start using Node 🥳

Install Node on WSL

Windows users have another option for installing Node: Windows Subsystem for Linux or WSL. WSL allows you to run a Linux environment on your Windows machine. Because most web development happens in Linux environments, the benefits of using WSL are that you’ll have fewer problems, an easier time following tutorials, and more tools at your disposal. The downside is that it takes a few additional steps to configure and install.

Open a terminal as an administrator by right-clicking on the application and choosing “Run as administrator.”

In the terminal, run:

wsl --install

Windows will install WSL. After installation is complete, restart your machine. Open your terminal and select Ubuntu , the WSL distribution installed by default.

You’re now on Linux on Windows. Pretty cool! To install Node, follow the instructions in the next section.

Install Node on Linux

The best way to install Node on Linux is to use Node version manager(nvm). It’s a script that makes it easy to install up-to-date Node versions and switch between them.

Open a terminal and run:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.3/install.sh | bash

Close your terminal and reopen it. Check that nvm is installed correctly by running command -v nvm. This command should output nvm.

Finally, check which version of Node Ghost currently supports. Install it with the following command:

nvm install 18

Once installation is complete, close and reopen your terminal. Check that Node is installed correctly with node -v. If it returns the current version installed, then you’re in business and ready to start using Node 🥳

nvm works great when using Ghost locally, but it's not recommended for production. See our FAQ for more info.

Summary

It’s hard to overstate how omnipresent Node is in the current web development ecosystem. Name a website or app and somewhere along the line, they’re probably using Node. Installing it on your system is the first step in creating an amazing app or a super sick custom Ghost theme.

Your next step is to install Ghost locally, which should be a breeze now that Node is installed 😉

And we have lots more resources to help you build a custom theme:

How to debug your Ghost theme

Ryan Feigenbaum — Thu, 16 Feb 2023 20:21:10 +0000

Like a behind-the-scenes look at your favorite film, Ghost’s {{log}} helper lets you see the data that’s behind your theme, empowering you to debug your theme like a pro. In this tutorial, we’ll follow Jamie, as they work on their new Ghost site, Cats in Art. Using real-world examples, we'll show you everything you need to know about the log helper, from getting started to traversing contexts.

Start Ghost in development mode

To use the {{log}} helper, start Ghost in development mode. In a terminal, navigate to the directory where Ghost is locally installed and run ghost run -D. This command tells Ghost to start and output logging information to the console.

ghost run -D

Open a browser and navigate to your local Ghost site. For every page load, requests for the page and its assets (like images) now appear in the console. Refresh the page to see the data logged in real-time. (Hit ctrl + c in the terminal to stop Ghost’s development mode.)

Open Ghost Admin, navigate to Settings, and set your theme. You’re now ready to start using the {{log}} helper 🏃‍♀️

To see real-time changes, be sure your theme folder is located in (or linked to) Ghost’s content/themes folder.

Use the `{{log}}` helper

The {{log}} helper shows which data is available at a particular place in your theme. Cats in Art is a site — you guessed it — featuring cats in art. It uses Ghost’s default theme, Casper. As we follow Jamie’s use of the {{log}} helper, know that the same techniques shown below work with all Ghost themes.

Log specific data

Jamie added a sweet gradient to use as the background image to their author profile, but the image isn’t appearing on the site. They open the author.hbs file, which Casper uses to render author profile pages, and find the code for the background image:

<img class="post-card-image"
        srcset="{{img_url feature_image size="s"}} 300w,
                {{img_url feature_image size="m"}} 600w,
                {{img_url feature_image size="l"}} 1000w,
                {{img_url feature_image size="xl"}} 2000w"
        sizes="(max-width: 1000px) 400px, 800px"
        src="{{img_url feature_image size="m"}}"
        alt="{{name}}"
/>

By running in development mode, Jamie already has a vague clue about what’s causing the bug. There’s a 404 error that tells them the image file isn’t being found.

Use the log helper by combining the log keyword with the property to be logged: {{log property_to_logged}}. To help investigate their missing image, Jamie log’s the value of feature_image by adding the log helper to the template and refreshing the page in the browser.

{{log feature_image}}
<img class="post-card-image"
        srcset="{{img_url feature_image size="s"}} 300w,
                {{img_url feature_image size="m"}} 600w,
                {{img_url feature_image size="l"}} 1000w,
                {{img_url feature_image size="xl"}} 2000w"
        sizes="(max-width: 1000px) 400px, 800px"
        src="{{img_url feature_image size="m"}}"
        alt="{{name}}"
/>

undefined now appears in the log. From here, Jamie guesses that they're likely not using the right image property, which is why the image is not coming through. To be sure, Jamie annotates the log helper with static text. This technique is particularly useful when using multiple log helpers.

{{log "feature image:" feature_image}}

Adding this bit of text confirms that the feature_image property is undefined — Jamie’s bummed the property value is wrong but relieved to know what the bug is 😅

Log all available data

If feature_image isn’t the right property, then what is? Jamie uses {{log this}} to show all available data in a context.

{{log this}}

Think of log this as saying “log this data right here.” Jamie now gets this output:

{
  slug: 'jamie',
  id: '1',
  name: 'Jamie Larson',
  profile_image: null,
  cover_image: 'http://localhost:2368/content/images/2023/01/mesh-gradient.png',
  bio: null,
  website: null,
  location: 'Berlin',
  facebook: null,
  twitter: '@jamie',
  meta_title: null,
  meta_description: null,
  url: 'http://localhost:2368/author/jamie/'
}

Each of the properties listed here — name, slug, url, bio, etc. — can be used in the theme template. For example, {{name}} renders as “Jamie Larson” on the live site.

Looking through the available data, the error becomes clear. feature_image is not the right property. It’s actually cover_image. Jamie can tell that’s the property they need because of its name (cover image) and because it’s the only one with an image URL.

Changing the property to cover_image returns Jamie’s author page with their sweet gradient image loading as expected!

You might be thinking that Jamie could’ve figured out their bug much quicker by just reading the docs for the author's context. That’s probably true, but Jamie’s mischievous cat had chewed through the ethernet cable, leaving Jamie without internet and without access to the docs. {{log}} was their saving grace.

Doing more with the log helper

Now that Jamie has a good handle on how the log helper works, they take it for a spin to see what else it can do.

Logging post data

Jamie opens their post template (post.hbs). Inside the post context, they add {{log this}} and save the file.

{{#post}}
...
{{log this}}
...
{{/post

Loading a post outputs lots of data to the terminal, probably too much to fit on the screen all at once. This data represents everything available to use in the theme when inside the post context.

Jamie sees familiar properties like title and feature_image and a whole lot more.

But Jamie's really only interested in seeing the tags for the post. They update the log helper with the property name and annotate it to make it easier to recognize in the logs:

{{log "tags:" tags}}

In the terminal, Jamie sees that this post has one tag associated with it, “Print.” (On Cats in Art, each artwork is tagged with which kind of art it is.) They also see all the available tag data, which is editable on the tag page in Ghost Admin.

Jamie notices that each tag has an accent_color property, which gives them the idea of color-coding tags in a future design 🎨

Switching contexts

Jamie’s feeling pretty good now. There’s nothing they can’t log 💪

But just as they’re ready to sign off for the day, Jamie thinks it would be cool to include the number of posts they’ve written about cats in art on their author page.

They log author data only to see that publication count isn’t included. Jamie thinks about where this data might be available.

The author template (author.hbs) renders a collection of posts — everything an author’s published. In Ghost, this collection is paginated by default. The pagination object includes lots of useful data like the current page number, the number of posts per page, and the total number of posts available. This total property is exactly what Jamie needs: the total number of posts they’ve published about cats in art.

Jamie updates the author template to include this data, wrapped in a span to make it easier to style.

<header class="post-card-header">
  <h2 class="post-card-title">{{name}} <span class="author-post-count">{{pagination.total}}</span></h2>
</header>

They refresh the page, hoping to see their post count, but it doesn’t work. Jamie then tries logging it:

{{log "post count:" pagination.total}}

Undefined!? Jamie’s now been at this awhile, racking their brain for why this isn’t working, and just about ready to hurl their laptop out the window into the evening breeze. But instead, they pet their mischievous cat and get back to it.

Jamie knows they’re currently in the #author context, but pagination data is only available in the top-level context. That means Jamie needs to exit the current context and go up a level to get the post count, like if you were on the main floor but what you needed to get was upstairs.

Jamie goes up a level by prefixing the property with ../, similar to how you navigate the file system in the terminal. The log helper now looks like this:

{{log "post count:" ../pagination.total}}

In the terminal, the helper now logs the post count as 100. That’s promising. Jamie updates their template with this new syntax.

<header class="post-card-header">
  <h2 class="post-card-title">{{name}} <span class="author-post-count">{{../pagination.total}}</span></h2>
</header>

Aw, yeah. Looking great! Post count now displays correctly, and Jamie contemplates whether to write post 101 or to call it a night, for real this time.

Whatever Jamie decides, changing context is an indispensable tool when developing Ghost themes, and using it with the log helper gives the developer the ability to see which data is available, no matter where they are in the theme.

Summary

In this tutorial, you followed Jamie in their use of the log helper to output specific data, all available data by using this, and data from different contexts.

Knowing how to use the log helper unlocks a whole new perspective for custom theme development. You now have direct access to the data your templates are rendering. This new superpower will boost your ability to squash bugs and amplify your creative possibilities 🌈

Let us know what you find, what you create, and whether you’re getting stuck on our official Forum, where we talk about all things Ghost.

Create a Google News sitemap with Ghost

Ryan Feigenbaum — Tue, 25 Oct 2022 20:38:37 +0000

Add your content to Google News by adding a Google News sitemap to your Ghost site. The sitemap lets Google News know all the important details about your published content.

This tutorial walks you through how to create a Google News sitemap by implementing a new route on your Ghost site and by creating a custom template that is fully optimized for the Google News aggregator.

Add a new route for your sitemap

To make your sitemap accessible on the web, add a new route using Ghost's dynamic routing layer.

Download the most up-to-date version of your routes.yaml file from Ghost Admin. Go to Settings → Labs → Download current routes.yaml. Open the file in your code editor of choice.

Add the following route:

routes:
  /sitemap/:
    template: sitemap
    content_type: text/xml

This entry tells Ghost to create a route at yoursite.com/sitemap/, and on that route, to serve the sitemap template file and send an XML response (which is what Google News expects).

Your routes.yaml file should now look like the file below, plus any other changes you may have made to it.

routes:
  /sitemap/:
    template: sitemap
    content_type: text/xml

collections:
  /:
    permalink: /{slug}/
    template: index

taxonomies:
  tag: /tag/{slug}/
  author: /author/{slug}/

Save the file and upload it to Ghost Admin ( Settings → Labs → Upload routes YAML ).

Create a template for the Google News sitemap

The next step is to create a Handlebars template in your theme. This requires a little bit of coding, but the example in this tutorial provides a fully functional starting point.

Create a new file in the root of your theme called sitemap.hbs.

Add your posts

The code below tells Ghost to fetch your latest 1,000 posts and format the information for Google News. The template follows the specifications for a Google News sitemap like including the title and publication date as well as indicating if the content is for members only.

<?xml version="1.0" encoding="UTF-8"?>
  <urlset
    xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
    xmlns:news="http://www.google.com/schemas/sitemap-news/0.9"
  >
    {{#get "posts" limit="1000" include="tags"}}
      {{#foreach posts}}
        <url>
          <loc>{{url absolute="true"}}</loc>
          <news:news>
            <news:publication>
              <news:name>{{@site.title}}</news:name>
              <news:language>{{@site.locale}}</news:language>
            </news:publication>
            {{#has visibility="members"}}
            <news:access>Registration</news:access>
            {{/has}}
            {{#has visibility="paid"}}
            <news:access>Subscription</news:access>
            {{/has}}
            <news:publication_date>{{date published_at format="YYYY-MM-DDTHH:mm:ssZ"}}</news:publication_date>
            <news:title>{{title}}</news:title>
            <news:keywords>{{tags limit="5" autolink="false"}}</news:keywords>
          </news:news>
        </url>
      {{/foreach}}
    {{/get}}
  </urlset>

Copy and paste this code to the sitemap.hbs file or customize it to suit your needs. With customization, be aware that Google is stringent about attributes and formatting, so be sure to include all required fields.

Update your theme

Save the new template, zip up your theme, and upload it to your Ghost site. Check to see if your Google News sitemap is active by visiting yoursite.com/sitemap/. (We added a sitemap to this Tutorials site as an example: https://ghost.org/tutorials/sitemap/.)

Submit your Google News sitemap

Google Search Console is essential for monitoring your search performance in Google. See our guide on integrating it with Ghost. It's also the best way to let Google know about your new Google News sitemap.

In Google Search Console, go to Sitemaps and add your new URL to the Add a new sitemap box. Click Submit. The sitemap should be fetched immediately, but occasionally it can take some time for Google to crawl the URLs listed in it. A successful status indicates that Google has indexed all of your links submitted to Google News. That means your content is available to show up on Google News 📰

Summary

In this tutorial, you used Ghost's routing system and theme layer to create a custom Google News sitemap 🙌

Creating the sitemap helps your content show up in Google News, but Google also provides several other options for customization, monetization, and improved placement. See Google's guide to learn more.

Having trouble with this tutorial or seeing great success with your new Google News sitemap? Come share your experience in the official Ghost Forum, where developers, publishers, and content creators come together to discuss all things Ghost.

Hacktoberfest with Ghost: Help bring i18n to our app

Ryan Feigenbaum — Mon, 17 Oct 2022 14:40:05 +0000

Ghost is an industry-leading, open-source publishing platform built on Node. Creators (Ali Abdaal, Scatchy, DESK), publishers (The Lever, The Atlantic, The Browser), and companies (Unsplash, DuckDuckGo, OpenAI, Mozilla) use our platform to publish, share, and grow a business around their content.

Because our users are global, better translation support (i18n) has become our most-requested feature. Hacktoberfest seemed like the perfect opportunity to ask the dev community for help in shipping this much-wanted feature.

While developers have contributed to translating individual components in the past, we believe that i18n needs to be solved with a single solution. Therefore, we put together a plan that outlines the requirements for this solution.

i18n Milestone 2: Framework and build tools #15502

ErisDS posted on Sep 29, 2022

This issue represents a single milestone within our i18n project. The full project is documented on the Ghost forum.

Expected structure

A new ghost/locales folder in the monorepo contains namespaced JSON files e.g. locales/es/common.json, /ocales/es/portal.json, locales/es/email.json
For Node.js/email-templates we do one of:
- (Preferred) The correct path is loaded from config based on environment
- ghost/locales gets copied into ghost/core somehow
Then for react:
- Use code-splitting to generate individual versions of portal for each supported locale.

Goals:

[ ] Get the basic pieces of i18next in place & configured according to the tech spec
[ ] Implement the expected structure (see above)
[ ] Figure out if we need to switch to vitejs in Portal to achieve the desired build (may need help from Ghost team)
[ ] Have 1 interpolated string in each of email and Portal
[ ] Tooling for extracting strings & generating files

Tasks:

[ ] Move Portal into the monorepo (Ghost team to complete soon)
[ ] Demo/spike of the build tool for Portal - I think this is the hardest part so we should do it first
[ ] Demo/spike of how locale files get pulled into Node.js for email templates
[ ] Demo/spike of i18next wiring so that there's one interpolated string in Portal and one in an email template
[ ] Demo/spike of a tooling that can grab the 2 interpolated strings e.g. yarn translate es would create /locales/es/portal.js and /locales/es/email.js each containing one string.

I'm hoping to find people interested in the different parts to do initial spike implementations - then we can figure out the tasks more clearly.

Notes on participating & Hacktoberfest:

We aren't going to merge half-baked spikes or wiring that doesn't match the spec yet - so if you're just trying to get through Hacktoberfest as fast as possible, this is not the issue for you! (There are plenty of small bugs though!)

However, if you're using Hacktoberfest as a vehicle to find a cool & meaningful project to work on, this should be well up your street :)

We'll do our best to ensure that those who actively contribute value to this project get something merged and appropriately labelled by the end of Hacktoberfest 🎃

👉 If you're interested, drop a note to say Hi and which part you're interested in before getting stuck in, just in case we end up with multiple people trying to get the same things merged.

View on GitHub

Problem

At present, only our theme layer is translatable using a custom-built i18n framework (that we do not want to build on). Our native membership (Portal), email, comment, and search systems, however, are not translatable.

Since these systems only have one set of strings that need translating into each language, it makes sense to have these translations be part of Ghost core (that is, built into the product itself).

Solution

We want to be able to serve translated emails and widgets (membership, comments, search), based on the language defined by the user in general settings. Technically, the solution boils down to answering two key questions:

Where do the translated strings come from?
How do the replacement strings get interpolated?

The answer to (1) is “a JSON file” of some description. We do not want to manage translations in a 3rd party tool like transifex, but we’d like to keep all of the JSON files in GitHub. It needs to be possible to load the strings and pass them to all the places they’re needed.

The answer to (2) is a {{t}} helper that needs to exist in both React and email templates. We want to keep our existing pattern in themes of using the default string as the key. This means that when a default string is changed, it needs to be re-translated in all languages, which is desirable as changes are usually more than cosmetic.

We will also need a way to collect all the default strings and compile them into a new JSON file, ready to be translated.

For email templates, it makes sense for the interpolation to be dynamic, done at the time of sending as this is a server-side system. For our React widgets, we would like to create a custom build for each translation, so it becomes possible to load language-specific scripts, e.g. portal-es.min.js.

Several aspects of i18n will be made significantly easier by ensuring that all translatable components and the translations themselves live together in the Ghost monorepo. This was the first part of the process, which is already complete 🎉

Technical plan

Our basic requirements are:

Load a single set of translations + (maybe) a set of custom strings into React widgets
Load a single set of translations into Ghost core for emails
Future: Load translations for Admin
Interpolation tools for Handlebars and React
Be able to use the default string as the key
Be able to generate a new language file with all available keys
Not have to load all translations, e.g., all of Portal’s translations into comments
Have a single place, in GitHub, where locales are defined
Ideally: generate a build per locale for each JS widget, e.g., portal-es.min.js

That last requirement is the hardest, as we will need to figure out a build step for our react projects… but this should be a one-off piece.

The i18next 4 framework appears to support every single one of our requirements, including fallback-based keys, namespacing, and having tools for extracting translation strings. It’s also extensible with plugins and has links to tooling for managing the translation process—so we could have a yarn check-translations command to view what’s not translated.

Expected structure:

A new ghost/locales folder in the monorepo that contains namespaced JSON files, e.g., locales/es/common.json, locales/es/portal.json , locales/es/email.json
For Node.js/email-templates we do one of:
- (Preferred) The correct path is loaded from config based on environment
- ghost/locales gets copied into ghost/core somehow
Then for React:
- Use code-splitting to generate individual versions of portal, comments, and search for each supported locale.

Here are some details of using i18next with Webpack to create a a build step using “code splitting,” but it doesn’t quite achieve what we want. We are currently investigating switching to Vite for our build tool—and this may end up being an additional prerequisite.

Milestones

This project has prerequisites, is fairly complex, and has lots of different phases in which different community members may wish to get involved. Therefore, we’ve broken the project down into milestones and will keep this thread up to date with where we are.

Milestone 1: Monorepo

Portal needs to be merged into the monorepo ✅
Comments and search will follow later, but the project can continue without them.

Who: This milestone has been completed by the Ghost team.

Milestone 2: Framework and build tools

Implement the “expected structure” from above
Get the basic pieces of i18next in place
Figure out if we need to switch to Vite in Portal (may need help from Ghost team)
Have one interpolated string in email and Portal
Tools for extracting strings & generating files

Who: Looking for interested contributors, Ghost team will help and/or kick this off if needed.

Milestone 3: Interpolated Strings

All strings in Portal and Member emails (signup, signin, subscribe) are interpolated using the {{t}} helper and the default, existing US English string as the key.
comments-ui and SodoSearch should also be in the monorepo by now, and so these strings can also be interpolated.

Who: Looking for interested contributors

Milestone 4: Translations

Tooling for extracting strings into new locale files should be perfected
Getting all strings translated for additional languages.

Who: Looking for interested contributors

Check out the issue on GitHub for more info:

i18n Milestone 2: Framework and build tools #15502

ErisDS posted on Sep 29, 2022

This issue represents a single milestone within our i18n project. The full project is documented on the Ghost forum.

Expected structure

A new ghost/locales folder in the monorepo contains namespaced JSON files e.g. locales/es/common.json, /ocales/es/portal.json, locales/es/email.json
For Node.js/email-templates we do one of:
- (Preferred) The correct path is loaded from config based on environment
- ghost/locales gets copied into ghost/core somehow
Then for react:
- Use code-splitting to generate individual versions of portal for each supported locale.

Goals:

[ ] Get the basic pieces of i18next in place & configured according to the tech spec
[ ] Implement the expected structure (see above)
[ ] Figure out if we need to switch to vitejs in Portal to achieve the desired build (may need help from Ghost team)
[ ] Have 1 interpolated string in each of email and Portal
[ ] Tooling for extracting strings & generating files

Tasks:

[ ] Move Portal into the monorepo (Ghost team to complete soon)
[ ] Demo/spike of the build tool for Portal - I think this is the hardest part so we should do it first
[ ] Demo/spike of how locale files get pulled into Node.js for email templates
[ ] Demo/spike of i18next wiring so that there's one interpolated string in Portal and one in an email template
[ ] Demo/spike of a tooling that can grab the 2 interpolated strings e.g. yarn translate es would create /locales/es/portal.js and /locales/es/email.js each containing one string.

I'm hoping to find people interested in the different parts to do initial spike implementations - then we can figure out the tasks more clearly.

Notes on participating & Hacktoberfest:

However, if you're using Hacktoberfest as a vehicle to find a cool & meaningful project to work on, this should be well up your street :)

We'll do our best to ensure that those who actively contribute value to this project get something merged and appropriately labelled by the end of Hacktoberfest 🎃

👉 If you're interested, drop a note to say Hi and which part you're interested in before getting stuck in, just in case we end up with multiple people trying to get the same things merged.

View on GitHub

Find more info in our Forum

If you’re interested in helping with milestones 2-4 of this project, we’d love to hear from you in the comments below 👇

How to add a tip jar to a Ghost site

Ryan Feigenbaum — Fri, 22 Jul 2022 19:21:24 +0000

Offer your most engaged readers multiple ways to support your content by adding a tip jar to your Ghost membership site with Stripe.

This tutorial will walk you through the steps of setting up the payment link in Stripe and how to add the link to your Ghost site as a navigation item, a page, and a content snippet.

Create a payment link on Stripe

On the Create payment link page, select Let customers choose what to pay from the dropdown menu.

Fill in the details for your payment link. These details are entirely up to you. When everything looks good, click Create link.

Your payment link is now created. Click Copy to get the URL that we’ll use with Ghost.

When a visitor clicks the link, they’ll be taken to the Stripe checkout page, where they can enter their details and complete the payment.

Add the payment link to Ghost

Anywhere you can put a URL, you can use your payment link — we’re going to focus on adding it as a navigation item, a new page, and a snippet.

Navigation item

If you’ve ever added a navigation item to your Ghost site, then you’re already ahead of the curve on this one, because the process with a payment link is exactly the same.

Log into your Ghost site and go to Navigation. Add the link text and payment link URL. Click Save.

That’s it! Your tip jar is now live and active 🎉

Page

Maybe you want to make more of a case for a tip than just a navigation item. Another option to showcase your payment link is to create a new page in Ghost.

Go to Pages → New page. The design and content of the page are up to you. In the example below, we created a fictional publication, Coffee Talk. The page includes some copy along with a Button card that uses the Stripe payment link.

Publish the page and add it to the navigation bar, like in the previous section, or share it in newsletters, on social media, or wherever there’s an opportunity for support.

Create a content snippet

In Ghost, snippets are user-defined reusable bits of content. With them, you can easily copy and paste content across different posts and pages.

Here, they’re perfect for quickly adding a tip jar at opportune moments in your posts.

Using our Coffee Talk publication from above, let’s say we just shared a technique for brewing the most insane cup of coffee ever known. Now’s as good a time as any to make a call for action.

For this CTA, we used the Header card, which adds a beautiful, full-width element to the page with a customizable button (where we included the Stripe payment link).

To be able to use this on other posts and pages, we can turn the card into a snippet (which works for any post content — not just Header cards).

To create a snippet, select content and click the create snippet icon. Enter a name for your snippet and hit Save. Your snippet is now available on any post or page from the card menu 🤯

Summary

Tip jars offer your visitors a simple way to contribute to your content financially with a one-off payment, and thanks to Stripe and Ghost, this is easy to set up for your publication

How did you implement a tip jar on your website? Join the Forum to share your witty copy, ask questions, or just see what other Ghost users are up to.

Forem: Ghost

Install Node on macOS, Windows, and Linux

What’s Node?

Install Node on macOS

Install Node on Windows

Install Node on WSL

Install Node on Linux

Summary

How to debug your Ghost theme

Start Ghost in development mode

Use the {{log}} helper

Log specific data

Log all available data

Doing more with the log helper

Logging post data

Switching contexts

Summary

Create a Google News sitemap with Ghost

Add a new route for your sitemap

Create a template for the Google News sitemap

Add your posts

Update your theme

Submit your Google News sitemap

Summary

Hacktoberfest with Ghost: Help bring i18n to our app

i18n Milestone 2: Framework and build tools #15502

Tasks:

Problem

Solution

Technical plan

Milestones

i18n Milestone 2: Framework and build tools #15502

Tasks:

How to add a tip jar to a Ghost site

Create a payment link on Stripe

Add the payment link to Ghost

Navigation item

Page

Create a content snippet

Summary

Use the `{{log}}` helper