It is not mentioned as a dependency in the SSR page
> For v10 and above, SSR just works in Next.js.
>
> https://emotion.sh/docs/ssr
Tested by - yarn dev, yarn preview:photos
Came across this when trying to migrate off bootstrap in the few remaining
places, this code is unused and just removing it instead of doing a migration of
it to mui.
This is no longer needed for emotion > 10
> For v10 and above, SSR just works in Next.js.
>
> https://emotion.sh/docs/ssr#nextjs
Tested with
- yarn dev:*
- yarn preview:*
This change screws up the CSS in places in dev mode though.
This was accidentally an ancient version of axios when importing from the older
repo - update it to what the rest of the code uses (via the shared package).
- Use the shared yarn monorepo configuration
- styled-components => emotion (since that's what the rest of the code uses)
- Remove Sentry (since it's gone elsewhere)
Manav: To avoid accidentally spilling out any secrets, squash and
import. However, the overwhelming majority of the work in the original code was
done by Abhinav <abhinavk.grd@gmail.com> so set them as the author for the
commit.
## Description
When a customer whose Stripe subscription is past due (within the 30 day
window after expiry time and has not been cancelled) clicks on the
subscription modal, take them to the payment portal to complete the
subscription.
## Tests
- [x] Tested web
- [x] Tested mobile
Fix an infinite loop of navigation under the following conditions: key
is valid
but token is not present.
Fix is to match the condition used in both gallery
if (!key || !token) {
and the root page.
They seemed to have diverged in commit
c3304571a9.
Was able to reproduce this when launching the desktop app such that the
key was
picked up (possibly from a prior installation) from the secure keychain,
but the
token was not found. I feel this is also a fix for a similar navigation
loop
recently reported by QA but unreproducible so far.
Fix an infinite loop of navigation under the following conditions: key is valid
but token is not present.
Fix is to match the condition used in both gallery
if (!key || !token) {
and the root page.
They seemed to have diverged in commit c3304571a9.
Was able to reproduce this when launching the desktop app such that the key was
picked up (possibly from a prior installation) from the secure keychain, but the
token was not found. I feel this is also a fix for a similar navigation loop
recently reported by QA but unreproducible so far.
https://github.com/ente-io/ente/pull/1185 updated the file but in the accounts
app. That's not the file that's used as the source - this PR updates the one we
use as the source for Crowdin.
From discussions, it seems that it was pre-emptively added but not specifically
requested by a customer. We can bring this back later if needed, or at least
offer better options to clean it, but for now I'm pruning the IPC surface to
reduce the amount of work needed for handling contextIsolation and sandboxing.
Obtained these strings from 33faadf83e/apps/accounts/public/locales/en/translation.json (L632)
I didn't have a way of exhaustively ensuring that all strings are covered, but
I've tried to manually verify.
Once this is merged and translation files synced with Crowdin, I'll do another
PR to update the `local/**/translation.json` files within apps/accounts.
Fixes: Info button is not working when videos are playing in full screen mode.
**Tested by**
Wasn't working before, but it works now. Still doesn't work with the keybinding,
have left a note about that in the code.
The current approach wasn't working. Not sure what caused it to stop working,
but anyway that was an hacky import, as evidenced by the ungainly warning
webpack would print on `yarn dev`. So instead of taking the path, we just take
the JSON contents directly, sidestepping all that.
**Tested by**
Rerunning the upload tests
This was found useful by @Bramas when building a Dockerfile of the web app
itself. See https://github.com/ente-io/ente/pull/1065.
Now, the GIT_SHA environment variable can just be undefined if we're not in a
git repository, and the code using it deals with that case explicitly.
**Tested by**
Temporarily inverted the isDevBuild flag, tehn
1. Ran the build normally and verified that the SHA continued to appear in the logs.
2. Ran the build after copying to a standalone folder without an associated git
repository and verified that the SHA was skipped without causing the build to
fail.
Sentry has a measurable impact on page load, a metric that I'm keen to
improve. Apparently by default it loses us 8-9 page speed points, though that
can be reduced to 3-4
(https://github.com/getsentry/sentry-javascript/issues/9179).
All of this is doable, but there are bigger tasks to deal with. This is not to
say that Sentry won't be useful again at some point, when we have time to deal
with it better. But right now, we discussed that it's just better to remove
Sentry instead of piling on to the sunk cost.
This flow probably got broken when the select-all-for-a-day functionality got
added in https://github.com/ente-io/ente/pull/674 (haven't dug into this, I'm
just guessing since that's where this all got touched).
Thank you to @Bramas on our Discord for pointing this out, and also providing the fix:
https://github.com/ente-io/ente/compare/main...Bramas:ente:fix-error-on-shared-album
Tested by
---------
Run normal web app on one terminal
NEXT_PUBLIC_ENTE_ENDPOINT=http://localhost:8080 NEXT_PUBLIC_ENTE_ALBUMS_ENDPOINT=http://localhost:3002 yarn dev
Run the albums listener on another port (need to do this since we're running on
localhost, and need to bind to a different origin):
NEXT_PUBLIC_ENTE_ENDPOINT=http://localhost:8080 NEXT_PUBLIC_ENTE_ALBUMS_ENDPOINT=http://localhost:3002 yarn dev:albums
Create a shared album, copy its public link, and verify that
- Before the fix we were getting an error (trying to access properties of `galleryContext.selectedFile`)
- After the fix the shared album is visible
Not integrating GitHub deployments for now since creating a deployment
(anywhere) causes "This branch has not been deployed" message to appear on
unrelated branches.
Also, the Discord /github webhook doesn't support deployment status events
anyway - Discord accepts and responds to the webhook with a 204 but it doesn't
appear in the channel. This is not a big issue, we can easily massage the
payload ourselves, but just mentioning this for posterity. Refs:
* [Corresponding issue on Discord](https://github.com/discord/discord-api-docs/issues/6203#issuecomment-1608151265)
* [A general recipe](https://gist.github.com/jagrosh/5b1761213e33fc5b54ec7f6379034a22)
---
For deleting the existing deployment I had to
```
gh api /repos/ente-io/ente/deployments --jq=".[].id"
gh api --method DELETE -H "Accept: application/vnd.github+json" -H "X-GitHub-Api-Version: 2022-11-28" "/repos/ente-io/ente/deployments/1375794893"
```
This helpful hint taken from https://github.com/orgs/community/discussions/46375. Thanks!
This select-all checkbox was added in https://github.com/ente-io/ente/pull/674.
These are some changes to how it looks:
- Move the checkbox to the left
- Reduce the size of the checkbox
## Description
fixes https://github.com/ente-io/ente/issues/535
This PR will add checkbox to all select files on a day, this will also
handle manual selection of files and select all checkbox on a day.
