fix https://linear.app/ghost/issue/ONC-619/remove-code-that-deletes-assets-before-regeneration-in-ghost
- in our asset minification code, we delete asset files before
regenerating them
- on shared filesystems, we're seeing errors like `Unknown system error -116` where 116 is Stale NFS file handle
- this is probably happening because we delete files right before
creating them, and maybe there is some distributed filesystem delay
that's causing issues here
- to workaround that, we can just stop deleting the files, which means
we can delete code (yay!)
no issue
- repeated use of the same init data made tests longer than they needed to be, especially as the number of tests grows
- added `initializeTest()` function to remove unnecessary duplication
ref PLG-270
- Updated the getCommentByID service to filter out hidden and deleted
replies.
- Ensured all replies are loaded before applying the filter.
- Simplified logic to handle non-paginated routes by directly removing
unwanted replies.
- Wired up new Admin Endpoint that shows hidden replies but not deleted
replies.
- Updated comments-ui client.
ref https://linear.app/ghost/issue/ONC-613/
A little while back we changed to requiring a key when interacting with
member endpoints that are not authenticated. One request code path in
Portal was missed, causing some requests to fail. This should patch that
hole.
ref https://linear.app/ghost/issue/ONC-548/
We seem to occasionally get into a state where draft posts are stuck
with an untitled slug, which has been difficult to reproduce. It would
be helpful to gather some data on how frequently this is happening.
ref https://linear.app/ghost/issue/ONC-548/
There have been reported cases of the editor not updating the slug for
draft posts. The logic should be as follows: for a draft post, if the
title was updated and we do not detect a custom slug, update it.
This got out of sync due to actions where the save was triggered but the
title onBlur effect (which updates the slug) was not triggered. This has
been resolved by evaluating the slug in the before save actions.
closes#21439
On Windows 10/Chrome (but maybe nowhere else?), attempting to drag a
file into any of the drop targets in the admin panel resulted in
flickering behavior, and generally dropping didn't actually trigger the
upload.
I thought originally it was a problem with the size of the drop target,
but it actually appears to be a rerender bug. In brief, handleDragging
and handleStopDragging were firing repeatedly, and each fire triggered a
rerender, that added or removed a div from the file upload widget.
I suspect some browser-specific difference in how drag events fire is to
blame.
This PR moves the logic to change the classes applied to the div, rather
than changing whether the div is present.
I have manually tested with Windows 10 in the users import, theme
import, and content import widgets. Styles are preserved (although I
think they could be improved, as the grey outline is really faint) and
uploading now works consistently, instead of mostly triggering display
of the raw file most of the time.
ref https://linear.app/ghost/issue/ANAL-115/data-retention
- The bad news here is I didn't notice that the tinybird web analytics
starter kit included a TTL on the analytics_events datasource of 60 days
- This means any data older than 60days was automatically dropped from
the table
- I updated this in the UI when I noticed it a few days ago, this makes
sure it can't come back
- The good news is that we don't have to implement anything to make this
work when we do get to the point where we want a TTL!
ref
https://linear.app/ghost/issue/ENG-1783/add-time-to-create-connection-metric
- Since we've added the "time to acquire" metric to get visibility into
contention in the connection pool, we've seen some anomalies where it
takes a surprisingly long time to acquire a connection (~60ms) when not
under load. Hypothesis is that these anomalies occur when there aren't
any open connections, so Ghost has to establish a new connection with
the DB, and that's the part that's actually taking most of that time.
This new metric should help confirm/deny that hypothesis.
- This will also be an interesting metric to keep an eye on and/or alert
on — if Ghost can't create new connections with its database
performantly, it's not going to perform very well.
ref
https://linear.app/ghost/issue/ENG-1796/reuse-tcp-connections-when-sending-metrics-to-the-pushgateway
- When we rolled out the prometheus metrics collection, it overwhelmed
the pushgateway. Our hypothesis is that Ghost was creating too many new
TCP connections to the pushgateway.
- The prometheus client was creating a new connection with the
pushgateway each time it pushed metrics every 15 seconds.
- This commit changes the prometheus client to keep the connection
alive, and re-use it instead of creating a new one.
- It also limits the number of retries if pushing the metrics fails —
after 3 consecutive failures, Ghost will stop retrying and log an error.
ref
https://linear.app/ghost/issue/ENG-1508/add-custom-metrics-for-email-analytics-jobs
- With the experimental job queue, we're using email analytics as our
initial validation test case. We're hoping to see an improvement in
Ghost's throughput for ingesting email events. However, we don't
currently collect this data point, so it's kind of impossible to tell
right now if the job queue is making things better or not.
- This PR fixes that by adding two new prometheus metrics:
- `email_analytics_events_processed` — a counter incremented each time
an event is processed. Sometimes the event has already been processed in
the past, so this doens't always result in a new event being stored in
the DB.
- `email_analytics_events_stored` — a counter incremented each time an
event is stored in the DB. For example, if an email is opened 3 times by
the same recipient, this counter will only be incremented once.
- The metrics also have a label for the event type, so we can split out
opened events from delivered events. We can use the `rate()` function in
grafana to then get an `events ingested per second` metric, and compare
sites with/without the job queue enabled.
closes https://linear.app/ghost/issue/PLG-266
- the reply form is a child of the parent comment component but we have different comment components for published vs unpublished with the bug coming from the latter missing the logic to display the form
- added missing form display and added a regression test
no ref
Suggestions for updating the confirmation email pt-BR translation with
more everyday terms and addressing gender-specific issues by using 'no
site' instead of 'em'.
closes https://linear.app/ghost/issue/PLG-265
- wrapped the async part of `dispatchAction` in a Promise so code that calls it can await the action completion
- this was a regression introduced a long time ago when we switched to Typescript and React hooks
- added a `setDelay()` method to our `MockedApi` class to make it easier to test interstitial loading states
no ref
This fix adds an extra fallback to 'en' when a locale folder is missing one or more translation files, and a test for the fallback. Previously, Ghost would fail to boot if an expected file translation was missing.
ref PLG-227
- added the correct order params for admin replies to ensure they are
sorted oldest to newest.
- hardcoded since we want to ensure it remains that way.
ref PLG-227
- Updated logic that allows Admin Users on comments to interact with
some endpoints from a specific admin-only route.
- It pulls 2 admin specific routes:
- 1. an admin specific 'browse' route that includes hidden comments that
would otherwise be hidden from regular users and members.
- 2. A specific replies route, that would also include hidden comments
- This was needed in order to get accurate pagination.
- Additionally, it wires up the routes via `message-handler` that deal
with the potential cors issues.
- Includes style updates
---------
Co-authored-by: Sanne de Vries <sannedv@protonmail.com>
Co-authored-by: Kevin Ansfield <kevin@lookingsideways.co.uk>
ref https://linear.app/ghost/issue/AP-598
We want to make sure that webhooks for internal integrations are fired even
when the custom integrations limit has been hit. In order to test this we've
had to update the fixtureManager to allow passing the integration type when
inserting fixture webhooks into the db.
ref https://linear.app/ghost/issue/AP-598
This is not a change in functionality.
The ActivityPub integration is an `internal` integration, because we want it to
be available regardless of the plan a Ghost(Pro) site is on. However the
webhooks service is not able to differentiate between webhooks for a custom
integration and an internal one.
Rather than disable webhooks entirely when the custom integrations limit
active, we want to allow webhooks for internal integrations to work. The first
step towards that is keeping the listener for the model events and have the
limiting happen in the WebhookTrigger which allows us to be more specific as to
which webhooks should be triggered or not.
ref PLG-227
- Wired up a new endpoint that would be able to paginate replies as an
admin user.
- The difference compared to the members-api endpoint is that this
includes hidden comments and includes the html string which is normally
hidden from non-admin users
ref DES-982
- we're hiding font-related theme settings from official themes to make room for the new custom font settings
- this adds author name as an additional check on top of the existing ones (theme name and corresponding setting keys)
ref https://linear.app/ghost/issue/AP-598
We want to make sure that webhooks for internal integrations are fired even
when the custom integrations limit has been hit. In order to test this we've
had to update the fixtureManager to allow passing the integration type when
inserting fixture webhooks into the db.
ref https://linear.app/ghost/issue/AP-598
This is not a change in functionality.
The ActivityPub integration is an `internal` integration, because we want it to
be available regardless of the plan a Ghost(Pro) site is on. However the
webhooks service is not able to differentiate between webhooks for a custom
integration and an internal one.
Rather than disable webhooks entirely when the custom integrations limit
active, we want to allow webhooks for internal integrations to work. The first
step towards that is keeping the listener for the model events and have the
limiting happen in the WebhookTrigger which allows us to be more specific as to
which webhooks should be triggered or not.
ref https://github.com/TryGhost/Ghost/pull/15893
This got closed as stale long ago. Resurrecting this as it's a simple
change and will help our Windows-based theme devs in particular.
