Skip to content

feat: implement newsletter page for pro users #179

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from
Closed

feat: implement newsletter page for pro users #179

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
64aa7fb
feat: implement newsletter page for pro users
Sandesh-Upadhyay Nov 16, 2025
32a54b4
fix merge conflicts
Sandesh-Upadhyay Nov 16, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
172 changes: 172 additions & 0 deletions NEXT_STEPS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,172 @@
# next steps - run and push your newsletter feature

## ✅ what's done

- environment files created (`apps/api/.env` and `apps/web/.env.local`)
- dependencies already installed
- newsletter feature code is ready

## 🚀 how to run

### step 1: update database url (if you have postgresql)

if you have postgresql installed, edit `apps/api/.env` and update:
```
DATABASE_URL="postgresql://YOUR_USER:YOUR_PASSWORD@localhost:5432/opensox?schema=public"
```

if you don't have postgresql, you can still test the newsletter ui (it doesn't require database).

### step 2: run the development servers

from the root directory (`opensox`):

```bash
pnpm dev
```

this will start:
- api server on `http://localhost:8080`
- web server on `http://localhost:3000`

### step 3: test the newsletter page

1. open `http://localhost:3000` in your browser
2. navigate to `http://localhost:3000/newsletters`
3. **note:** the page requires pro user authentication
4. if you're not logged in, you'll be redirected to login
5. if you're logged in but not a pro user, you'll be redirected to pricing

### testing without authentication (optional)

if you want to see the ui without full auth setup, you can temporarily modify:

`apps/web/src/app/(main)/newsletters/page.tsx`

comment out lines 17-35 (the useEffect that redirects):

```typescript
// temporarily comment this out for ui testing
// useEffect(() => {
// ...
// }, [status, isPaidUser, isSubscriptionLoading, router]);
```

and change line 50 to:
```typescript
if (false) { // temporarily always show content
```

remember to revert this before pushing!

## 📤 how to push your changes

### step 1: check your changes

```bash
git status
```

you should see:
- new newsletter files
- documentation files
- modified pnpm-lock.yaml

### step 2: create a feature branch

```bash
git checkout -b feature/newsletter-page
```

### step 3: stage your changes

```bash
git add apps/web/src/app/(main)/newsletters/
git add apps/web/src/components/newsletters/
git add apps/web/src/data/newsletters.ts
git add apps/web/NEWSLETTER_DOCUMENTATION.md
git add apps/web/PR_DESCRIPTION.md
git add pnpm-lock.yaml
```

or add everything:
```bash
git add .
```

**important:** don't commit the `.env` files (they're in .gitignore)

### step 4: commit

```bash
git commit -m "feat: add newsletter page for pro users

- implement newsletter listing page with date organization
- add newsletter detail page with rich content support
- support text, links, images, bold text, and headings
- add pro user protection and authentication
- include 3 sample newsletters
- add documentation for adding new newsletters

closes #155"
```
Comment on lines +64 to +112
Copy link
Contributor

@coderabbitai coderabbitai bot Nov 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Fix invalid git commit example and avoid brittle line-number references.

  • The git commit -m example uses a multi-line message with an opening quote but no closing quote. As written, this command will fail in the shell. Prefer a single-line message (or git commit to open an editor) and keep the detailed bullets only in the docs/PR description, e.g.:
-```bash
-git commit -m "feat: add newsletter page for pro users
-
-- implement newsletter listing page with date organization
-- add newsletter detail page with rich content support
-- support text, links, images, bold text, and headings
-- add pro user protection and authentication
-- include 3 sample newsletters
-- add documentation for adding new newsletters
-
-closes #155"
-```
+```bash
+git commit -m "feat: add newsletter page for pro users"
+```
+
+You can include the detailed bullets and `closes #155` in the PR description instead.
  • The instructions that say “comment out lines 17–35” and “change line 50 to if (false) {” in page.tsx are fragile; line numbers will drift as the file changes. It’s safer to reference the specific useEffect that handles auth redirects and the condition guarding the newsletter content in prose (e.g., “comment out the auth redirect useEffect and temporarily force the content condition to false”) rather than hard-coded line numbers.

Also applies to: 46-60

🤖 Prompt for AI Agents 
In NEXT_STEPS.md around lines 64–112, fix the broken multi-line git commit
example by replacing it with a single-line git commit instruction (or instruct
to run git commit to open an editor) and advise putting the detailed bullets and
"closes #155" into the PR description instead; also remove brittle hard-coded
line-number instructions (e.g., “comment out lines 17–35” and “change line 50…”)
and replace them with a prose reference to the specific code elements to edit —
namely, say to comment out the auth-redirect useEffect and temporarily force the
newsletter content guard condition to false (or explain how to locate that
useEffect and condition) so the guidance remains stable as the file changes
(also apply the same replacement for the 46–60 range).


### step 5: push to your fork

if you haven't forked yet:
1. go to https://github.com/apsinghdev/opensox
2. click "fork" button
3. add your fork as remote:
```bash
git remote add fork https://github.com/YOUR_USERNAME/opensox.git
git push fork feature/newsletter-page
```

if you already have a fork:
```bash
git push origin feature/newsletter-page
```

### step 6: create pull request

1. go to https://github.com/apsinghdev/opensox/pulls
2. click "new pull request"
3. select your branch `feature/newsletter-page`
4. fill in the pr description (use content from `PR_DESCRIPTION.md`)
5. mention "closes #155" in the description
6. submit the pr

## 📝 pr requirements checklist

- [x] newsletter page implemented
- [x] date organization (month/year)
- [x] rich content support (text, links, images, bold, headings)
- [x] pro user protection
- [x] 3 sample newsletters included
- [x] documentation on how to add newsletters
- [ ] screen recording (you'll need to create this)
- [ ] pr description explaining approach

## 🎥 creating screen recording

for the pr submission, you'll need a screen recording showing:
1. navigating to the newsletter page
2. viewing the newsletter listing
3. clicking on a newsletter
4. viewing the full newsletter content
5. showing the date organization

you can use:
- windows: built-in screen recorder (win + g)
- or any screen recording tool

## 💡 tips

- test everything before pushing
- make sure there are no console errors
- verify the newsletter page works with pro user account
- keep the code clean and follow the lowercase convention
- document any issues or questions in the pr

good luck! 🚀

92 changes: 92 additions & 0 deletions QUICK_START.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,92 @@
# quick start guide - newsletter feature

## step 1: create environment files

### backend (`apps/api/.env`)

create the file `apps/api/.env` with this content:

```env
DATABASE_URL="postgresql://USER:PASSWORD@localhost:5432/opensox?schema=public"
JWT_SECRET="3bb3238092da53f8ba9d1e02e15efe8ec84341252a11eff1b28ff742c292224e"
PORT=8080
CORS_ORIGINS=http://localhost:3000
NODE_ENV=development
```
Comment on lines +9 to +15
Copy link
Contributor

@coderabbitai coderabbitai bot Nov 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Replace realistic-looking secrets with placeholders and fix the commit example.

  • The example values for JWT_SECRET and NEXTAUTH_SECRET are long random hex strings and have already been flagged by Gitleaks as potential secrets. Even if they are dummy, committing realistic-looking secrets will keep triggering leak scanners and encourages copy-pasting the same secret everywhere. Align this guide with SETUP_INSTRUCTIONS.md by using descriptive placeholders and instructing users to generate their own secret, e.g.:
-```env
-DATABASE_URL="postgresql://USER:PASSWORD@localhost:5432/opensox?schema=public"
-JWT_SECRET="3bb3238092da53f8ba9d1e02e15efe8ec84341252a11eff1b28ff742c292224e"
-PORT=8080
-CORS_ORIGINS=http://localhost:3000
-NODE_ENV=development
-```
+```env
+DATABASE_URL="postgresql://USER:PASSWORD@localhost:5432/opensox?schema=public"
+JWT_SECRET="replace-with-a-strong-random-secret"
+PORT=8080
+CORS_ORIGINS=http://localhost:3000
+NODE_ENV=development
+```
…
-```env
-NEXT_PUBLIC_API_URL="http://localhost:8080"
-GOOGLE_CLIENT_ID="dummy-client-id"
-GOOGLE_CLIENT_SECRET="dummy-secret"
-NEXTAUTH_SECRET="3bb3238092da53f8ba9d1e02e15efe8ec84341252a11eff1b28ff742c292224e"
-NEXTAUTH_URL="http://localhost:3000"
-```
+```env
+NEXT_PUBLIC_API_URL="http://localhost:8080"
+GOOGLE_CLIENT_ID="dummy-client-id"
+GOOGLE_CLIENT_SECRET="dummy-secret"
+NEXTAUTH_SECRET="replace-with-a-strong-random-secret"
+NEXTAUTH_URL="http://localhost:3000"
+```

Also add a short note showing how to generate the secret (e.g., using node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"), like you did in SETUP_INSTRUCTIONS.md.

  • The git commit -m example here has the same issue as in NEXT_STEPS.md: multi-line message inside an unterminated quoted string. Consider simplifying to a single-line -m (and move the detailed bullets into the PR description), for example:
-# commit
-git commit -m "feat: add newsletter page for pro users
-…
-closes #155"
+# commit
+git commit -m "feat: add newsletter page for pro users"

If you need a multi-paragraph commit message, recommend running git commit without -m so the editor can be used instead.

Also applies to: 23-29, 76-85

🧰 Tools
🪛 Gitleaks (8.29.0)

[high] 11-11: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.

(generic-api-key)


**update:** replace `USER` and `PASSWORD` with your postgresql credentials, or use a dummy value if you don't have postgresql yet.

### frontend (`apps/web/.env.local`)

create the file `apps/web/.env.local` with this content:

```env
NEXT_PUBLIC_API_URL="http://localhost:8080"
GOOGLE_CLIENT_ID="dummy-client-id"
GOOGLE_CLIENT_SECRET="dummy-secret"
NEXTAUTH_SECRET="3bb3238092da53f8ba9d1e02e15efe8ec84341252a11eff1b28ff742c292224e"
NEXTAUTH_URL="http://localhost:3000"
```

**note:** for testing the newsletter ui, dummy oauth values are fine. the newsletter page will still load.

## step 2: install dependencies (if not already done)

```bash
pnpm install
```

## step 3: run the development servers

from the root directory:

```bash
pnpm dev
```

this starts both api (port 8080) and web (port 3000) servers.

## step 4: test the newsletter page

1. open `http://localhost:3000` in your browser
2. navigate to `http://localhost:3000/newsletters`
3. **note:** the page requires pro user authentication
4. if you want to test the ui without auth, you can temporarily comment out the auth checks

## testing without full authentication

if you want to see the newsletter page ui without setting up full authentication, you can temporarily modify the pages:

1. open `apps/web/src/app/(main)/newsletters/page.tsx`
2. comment out or remove the `useEffect` that redirects users
3. change the condition to always show content: `if (false) { ... }`

## push your changes

once everything works:

```bash
# create a branch
git checkout -b feature/newsletter-page

# add all changes
git add .

# commit
git commit -m "feat: add newsletter page for pro users

- implement newsletter listing page with date organization
- add newsletter detail page with rich content support
- support text, links, images, bold text, and headings
- add pro user protection and authentication
- include 3 sample newsletters
- add documentation for adding new newsletters

closes #155"

# push to your fork
git push origin feature/newsletter-page
```

then create a pull request on github!

Loading