- this file doesn't have any tests and we don't test the
`fixDatesWhenFetch` function, so this commits adds tests for the
functionality, to ensure we don't break it in the future
ref AP-751
- Fixed the close button not working after typography settings opened
- Show table of contents only when there's more than one heading
- Added skeleton loader to the article to make it consistent with the
main screens
- Added `randomize` property to Skeleton component for easier random
placeholders
- Added Popover component to Shade and replaced the current one with
that
ref https://linear.app/ghost/issue/ENG-2030/
We had a couple spots where we could encounter race conditions with the way we emit and handle `DomainEvents` around the various subscriptions (`MemberCreatedEvent` + `SubscriptionActivatedEvent`). Instead of trying to always pull it from the created event in the db, we first try to grab it from memory/the subscription in the checkout session. This gives us more certainty before falling back to the event, in case the order is not as expected.
no issues
- the dark mode used to be applied only when refreshed — now it doesn't
require a refresh anymore
- also added dark mode support to the table of contents
- this plugin was written quite a while ago so it's written in
"old-style" JS, making it harder to read
- converted parameter extractions to object destructuring
- removed promise chaining to async-await
- pulled out bookshelfPrototype into a variable for brevity
- switched to some native array filter methods for brevity
ref AP-755
- this adds `dark` class to the root <html> element, so it acts as the
source of truth for the apps embedded in the admin
- this also gets rid of the `dark` class from the current design system
and Shade, so the apps wrapped within the corresponding providers don't
output nested `dark` classes
no issue
- To run Ghost itself in docker compose, you need to enable the `ghost`
compose profile by setting `COMPOSE_PROFILES=ghost`.
- This is done for you if you use the `yarn docker:*` commands, but if
you run any other `docker compose ...` commands manually, the `ghost`
profile won't be enabled by default.
- The easiest way to set `COMPOSE_PROFILES` is with a `.env` file in the
root of the repo. This `.env.example` file is a template than can be
easily copied to `.env` by running `cp .env.example .env`, which will in
turn enable the `ghost` profile.
- It also includes commented out environment variables that are useful
when running Ghost in Docker compose, such as stripe keys, app flags
(for running e.g. portal), and `DEBUG` modes.
This commit also includes some minor changes to the `dev.js` script:
- Adds a list of `availableFlags`, including all the app flags that it
will accept
- Adds validation to log an error and exit if any invalid flags are
passed. This will force us to keep this list up to date if/when we add
more app flags
- Adds a `show-flags` flag, which will print all the available flags,
along with a description, then immediately exit.
Ultimately this makes getting started with docker compose more straight
forward:
- Clone the repo
- Run `cp .env.example .env` to enable the `ghost` profile
- Run `docker compose up`
ref https://linear.app/ghost/issue/ENG-1561/
Depending on the path to upgrade a member, it was possible for the subscription attribution to not get set. This specifically patches the `SubscriptionCreatedEvent` missing the subscription attribution.
Note that we've identified other issues while exploring this causing subscription attribution to not display in certain cases, although it is being set appropriately. Those will be patched separately. See parent issue.
no issue
Problem:
- Running `yarn dev` with `--stripe` runs the `stripe listen ...`
command in a subprocess to forward webhook events to your local instance
of Ghost in development.
- Currently, you have to run `stripe login` manually before this will
work. If you fail to do so, the `yarn dev` script simply hangs
indefinitely without any logging to indicate why.
- Running `stripe login` manually is also a non-starter in Docker since
you'd have to do this for each new container instance, which isn't
practical.
Solution:
- Luckily the `stripe listen ...` command accepts an `--api-key`
argument, which expects your stripe secret key. This change updates the
`dev.js` script to read your stripe API key from the `STRIPE_SECRET_KEY`
environment variable if it's present. As long as `STRIPE_SECRET_KEY`
exists, you won't need to run `stripe login` anymore.
- It also adds a timeout of 5 seconds to the initial `stripe listen`
command and will exit the process if this step fails, indicating with a
clear log message that you need to either set the `STRIPE_SECRET_KEY`
variable or run `stripe login`
- I also added a bunch of debug statements to the dev script which were
useful in debugging this, and may prove useful for similar issues in the
future, so I'll leave them in there.
- the original implementation of this was wrong in that it would
calculate the init time from a static point in the boot process until
"now", which would be fine for the boot process
- however, if someone uploads a routes.yaml file much later, it would
still call `onFinished` and compare itself to the static time in the
boot process, resulting in huge "url service init" metrics
- to fix that, we can just collect the timestamp from `_onQueueStarted`, calculate
the diff in `_onQueueEnded` and then do logging/metrics
- as a result, we can then remove the `onFinished` function, as it's no
longer necessary
no issue
- Currently running any `git` commands in the docker container (i.e.
updating submodules) that use ssh are failing because the container
can't see your ssh keys. This commit adds a volume & environment
variable to enable forwarding your local ssh agent into the container.
As long as you've got an ssh agent running locally with your keys
enabled, this will allow you to e.g. push to a remote over ssh from
inside the container.
- It also mounts your local `.gitconfig` file into the container, so
your git configuration (i.e. name & email address) will also work inside
the container
- Finally, it adds githubs ssh keys to known_hosts in the development
target of the Dockerfile to avoid the prompt, which only works in
interactive environments and fails in any kind of script (like `yarn
main:submodules`).
ref https://linear.app/ghost/issue/ENG-2026/
This is being removed as the JobQueueManager is being removed. By
removing this, we can allow the queue to deplete itself before stripping
out that functionality.
- no implementation changes, just improving the JSDoc and comments to
make this more readable
- also switches some assertions in the tests to use the spy instance to
fix a typing issue
Ref https://linear.app/ghost/issue/PLG-337/create-cta-card-web-design
- The minimal layout version now changes to a column layout on mobile
- The sponsor label color now inherits the theme color so that it works
on any background color
- The spacing is adjusted for mobile
- due to how our test framework works, we end up running the boot
process many times
- each boot causes the Stripe service to re-add this handler
- that means we end up with like 100 handlers for `settings.edited`
- whilst it would be ideal if we could reset the event listener each
boot, the simplest thing for now is to just remove and re-add it
- I've pulled `stripeSettingsChanged` out of the init function because
`removeListener` only works on the specific instance of that function,
so it won't clean it up if it's a local function
- due to our testing framework, we run the boot over and over, but this
means we constantly add new xmlrpc listeners
- from profiling, this accounts for ~3% of the total test time, which is
minimal, but given it's an easy fix, this commit performs that
- ideally our test framework would reset the events between runs, or
keep them completely separate, but that's a while away yet without a
big refactor
ref AP-748
- The current structure of the AcitivyPub app makes it hard to scale and
extend, and it also lacks basic design heuristics. This PR adds a new header
and right sidebar for clear orientation and navigation.
no issue
- There is still some flaky behavior with the docker setup that seems to
be caused by the container not shutting down or cleaning up properly.
Sometimes `yarn dev` just hangs, or sometimes it only runs some of the
commands required. This seems to only happen when running `docker
compose up` after having previously run it and stopped it.
- Passing the `--force-recreate` option to docker compose recreates all
the containers, which seems to avoid this problem without incurring a
noticeable performance penalty.
no issue
- Port 4173 and 41730 are used to load a locally running version of
lexical into Ghost, and these ports were added to the Dockerfile and
compose.yml along with the ports for portal, admin, etc. However,
lexical runs _outside_ the container, so we don't really need to expose
these ports.
no issue
- This commit includes a few minor optimizations to the Dockerfile
- Removes `/var/lib/apt/lists` and runs `apt clean` to remove the apt
cache after each `apt install ...` command. This reduces the resulting
image size by about 100 MB
- Also moved the playwright install to after the `package.json` and
`yarn.lock` files are copied in, so we don't have to specifically pin
the version in the Dockerfile — it will instead just look at the version
specified in the `package.json` files.
no issue
- When running Ghost in docker compose, you need to set the database
connection, redis connection, and the server host to values that are
suitable for the environment.
- Previously this was done by automatically editing your
`config.local.json` file to update these parameters in the container's
entrypoint script. This made it somewhat annoying to switch from Docker
to local development because you have to remember to update your
`config.local.json` manually.
- This change adds a new static configuration file for running in docker
compose. The values set in this configuration file will override any of
the same keys in the `config.local.json` file, while still allowing the
use of `config.local.json` for any _other_ configuration keys. The
upshot of this is that you won't need to modify your `config.local.json`
file when switching back and forth between local and docker dev — you
can keep your local database, redis, etc configuration in
`config.local.json`, and they will simply be ignored when running in
docker.
- This also removes the script that updates your `config.local.json`
file from the entrypoint, since we no longer need to perform this step.
no issue
- Renamed the docker compose profile for Ghost from `full` to `ghost`,
because it is clearer and makes more sense this way
- Also added an explicit `GHOST_DEV_IS_DOCKER` environment variable to
the `compose.yml` file to make checking if running in docker less
fragile and more explicit.
no issue
- This fails when running the Ghost container alone (i.e. for unit
tests) since there is no database available.
- The database will be initialized when running `yarn dev` for the first
time anyhow, so this isn't really necessary here.
no issue
- Doing the submodule update in the Dockerfile doesn't work if you cloned Ghost via ssh,
because the Docker container doesn't have access to your ssh keys.
no issue
This commit is a fairly significant rework of the docker development
setup, with the goal of improving the performance of the Ghost container
and generally improving the DX of the docker development setup.
**Enumerating `node_modules` directories as volume exclusions for the
bind mount**
- The main source of performance overhead with the docker setup is the
bind mount, which mounts all the code into the container. Especially on
macOS, the bind mount introduces quite a bit of file system overhead.
Currently the bind mount includes all the `node_modules` directories,
which adds up to many thousands of files in the bind mount. This change
attempts to reduce this overhead by mounting in named volumes for each
`node_modules` directory in the monorepo, which effectively tells the
main bind mount to ignore these directories, thus reducing the
filesystem overhead.
**Removing the `yarn install` from the entrypoint script and the `yarn
setup:docker` step**
- This change has two more benefits: since all the `node_modules` are
installed into named volumes, we can now be confident that our local
`node_modules` won't conflict with the `node_modules` in the container.
Therefore, we can install `node_modules` at build time in the Dockerfile
instead of in the entrypoint script, and we can also get rid of the
`yarn setup:docker` setup command, which nukes your local `node_modules`
before building the container.
**Build optimization - enumerating all `package.json` files**
- In a typical node app's Dockerfile, you copy the `package.json` and
`yarn.lock` files into the container first, then run `yarn install`,
then copy the rest of the code in. This takes advantage of Docker's
build cache to avoid having to reinstall `node_modules` on every build
if you've only changed code files, but not any dependencies.
- This is more challenging to do with the monorepo since we have many
`package.json` files. This commit brute forces our way through that by
copying every single `package.json` file in the Dockerfile before
installing dependencies and copying the code in. The result is that
Docker builds become much faster, after the initial full build.
**Additional scripts**
- Since enumerating all the `node_modules` directories and
`package.json` files is tedious to do manually, this commit also
includes two new scripts to automate this work. Ideally we'll eventually
integrate these scripts with Slimer, so when you add a new package to
the monorepo it automatically updates the `Dockerfile` and
`compose.yml`, but for now we can manage that ourselves since it's a
fairly rare occurrence.
no issue
- No real code changes
- Added README.md to stripe service as a starting point to document some of the more complex stripe related flows
- Added typedefs and docstrings to most of the Stripe service code for improved type safety and clarity
I have completed the translation of the Slovak language for the missing
phrases and edited some of them for grammatical correctness, word order
and context.
---------
Co-authored-by: Peter Gonda <pipo@pipoline.com>
Co-authored-by: Cathy Sarisky <42299862+cathysarisky@users.noreply.github.com>
- this is slightly faster than the sync methods and brings it inline
with that we have in the E2E framework, so it'll be easier to switch
down the line
- this test needs to pass some time to make it work, and the current
method awaits a setTimeout, which means we're waiting in the real
world for it to finish
- we can just replace this with sinon to fake the clock jumping a second
ahead of time
- this saves 2s in tests
