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.
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'.
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 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.
ref https://linear.app/ghost/issue/PLG-235
- Any comments older than yesterday are now shown with the date instead of relative time
- Comments from the current year are now shown with just the month and day
---------
Co-authored-by: Kevin Ansfield <kevin@ghost.org>
ref https://linear.app/ghost/issue/ONC-594
We had a check to prevent showing the Analytics page link for email-only
posts (newsletters) if newsletters were disabled. I don't see a good
reason to remove this - users then have to re-enable newsletters just to
see the analytics.
ref 47b8161805
This ended up inverting the behavior, such that TZs far in advance of
GMT fouled up. This change builds the date by date components in the
local TZ so we should not run into further trouble...
ref https://linear.app/ghost/issue/ONC-590
When choosing dates to schedule a post in the future, it could end up
displaying the wrong selected date because it was accounting for local
TZ. This doesn't make sense as we're displaying the site TZ in the
picker itself, and that's the real TZ used for scheduling.
In short, this feels confusing and also is often incorrect/misleading,
even though the scheduler in the background is correct. This should
align those to make it more transparent.
ref https://linear.app/ghost/issue/PLG-230
When clicking "Reply" on a reply we now show an "In reply to" reference on the form and when saved show that reference in the rendered view, making it easier to follow discussions within comment replies.
- updated calls to `openCommentForm` action when opening a reply to add the in-reply-to data to the `openForm` instance
- updated Form comment to use the `openForm` instance data when rendering the in-reply-to reference
- updated Comment component to render the in-reply-to reference from the API-provided data
- includes click handler to scroll to the referenced comment
- added `getCommentInReplyToSnippet` helper function so strip a comment back to plaintext for display in the reply-to reference on the comment form (snippets on other comments are generated server-side)
---------
Co-authored-by: Sanne de Vries <sannedv@protonmail.com>
no ref
- Added all field translations from English to Nepali for
`newsletter.json` file.
"Thank you for creating Ghost and making it open source.": "Ghost
सिर्जना गरेर यसलाई ओपन सोर्स बनाउनु भएकोमा धन्यवाद।"
ref https://linear.app/ghost/issue/PLG-230
- the `inReplyTo` relationship was not being loaded for replies which meant the mapper never hit the code which adds `in_reply_to_snippet`
- moved all `in_reply_to` code behind the `commentImprovements` labs flag
- updated tests to correctly disable/enable the flag
- added test for browsing comments with replies-to-replies so `in_reply_to_snippet` is captured in the snapshot
no ref
Arabic locale done for search, comments, newsletter . once pulled I'll start translating the portal.
This translation is a part of ACLSS efforts to translate more open source projects to Arabic.
no ref
Added most no-brainer Hebrew translations but left the more complicated ones to people better equipped to translate them. Better something than nothing at all.
Also, Hebrew is an RTL language, so exclamation points and dots at the end of a sentence should appear at the leftmost part, but the translation files are LTR, as all JSON files are. Just putting it out there. This should be considered when using an RTL language translation.
---------
Co-authored-by: Steve Larson <9larsons@gmail.com>
no ref
- Changed _"Gói theo dõi"_ to _"Gói thành viên"_ for a better match to
the grammar and correct usage in Vietnamese
- Clarified the definition of **Subscription plan** (_"Gói thành viên"_
instead of _"Gói"_)
- Removed plural **emails** because it is not logical in Vietnamese
- Added _"Sort by"_ in comment.json
- Added _"Sorry, no recommendations are available right now."_ in
portal.json
- Changed placeholder text "and" to "&" for shorter and show full
sentence (mobile) in search.json
no ref
Added Prometheus metrics for the job queue throughput and email analytics throughput. We'll likely keep these around as good metrics to keep an eye on, though for the moment their primary function is to establish a baseline for users w/o the job queue enabled so we can observe the full impact once switching it on.
no ref
- [x] Created a new folder `ne` based on locale code for Nepali locale
inside `ghost/i18n/locales/`
- [x] Cloned 6 new JSON files pertaining to `en` folder from English
locale.
- [x] Added all field translations from English to Nepali for
`ghost.json` file.
- [x] Added all field translations from English to Nepali for
`search.json` file.
- [x] Added all field translations from English to Nepali for
`signup-form.json` file.
- [ ] TODO: Remaining 3 other files viz. `comments`, `newsletter`, and
`portal`.
"Thank you for creating Ghost and making it open source.": "Ghost
सिर्जना गरेर यसलाई ओपन सोर्स बनाउनु भएकोमा धन्यवाद।"
no ref
Suggestion to update the translation for 'A label for the thumbs-up response in member feedback at the bottom of emails' to 'I like it' and 'I don't like it,' as this phrasing sounds better and is more appropriate in Brazilian Portuguese. Thank you.
ref
https://linear.app/ghost/issue/ENG-1769/improve-pool-utilization-metric
- Currently the connection pool metrics are all point in time metrics,
and with a scrape interval of 15s this doesn't tell us a whole lot about
what's happening in the pool.
- This commit adds a Summary metric to track the elapsed time each
transaction has to wait to acquire a connection from the pool, which
should be a good indication of contention in the pool.
- Also moved the call to `prometheusClient.instrumentKnex` to after `initCore` in the boot process, because the metric depends on event listeners on `knex.client.pool`, and the pool gets destroyed and recreated in `initCore`, which removes the listeners
no issue
- Since we decided to use the pushgateway instead of running a metrics
server, this removes the metrics server and its e2e tests
- We may reintroduce it later, but for now this is a simpler setup
no issue
- The `instrumentKnex` method was directly accessing the `promClient`
instance to create custom metrics, and keeping track of them manually in
a `customMetrics` map. This isn't necessary, since the metrics are all
tracked within the `promClient` instance's registry. This method now
uses the `prometheusClient.register...()` methods to create the metrics,
and retrieves them with the `getMetric()` method to reduce duplication
of work and manual bookkeeping
- This also removes the query count metric, as there is a count already
included in the query duration Summary metric
