Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
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
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"
```

### 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
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
```

**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"
Comment on lines +11 to +28
Copy link
Contributor

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟠 Major

Replace hard-coded secrets with placeholders

The guide currently publishes concrete JWT_SECRET / NEXTAUTH_SECRET values. Even if they’re meant to be dummy, committing fixed secrets encourages copy‑pasting them into real deployments and trips secret scanners. Please switch to clearly marked placeholders and ask readers to supply their own values.

Use a diff like this:

-JWT_SECRET="3bb3238092da53f8ba9d1e02e15efe8ec84341252a11eff1b28ff742c292224e"
+JWT_SECRET="<set-your-own-jwt-secret>"
...
-NEXTAUTH_SECRET="3bb3238092da53f8ba9d1e02e15efe8ec84341252a11eff1b28ff742c292224e"
+NEXTAUTH_SECRET="<set-your-own-nextauth-secret>"

Optionally add a note explaining how to generate secure secrets.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
JWT_SECRET="3bb3238092da53f8ba9d1e02e15efe8ec84341252a11eff1b28ff742c292224e"
PORT=8080
CORS_ORIGINS=http://localhost:3000
NODE_ENV=development
```
**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"
JWT_SECRET="<set-your-own-jwt-secret>"
PORT=8080
CORS_ORIGINS=http://localhost:3000
NODE_ENV=development
🧰 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)


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

(generic-api-key)

🤖 Prompt for AI Agents
In QUICK_START.md around lines 11 to 28, replace the hard-coded JWT_SECRET and
NEXTAUTH_SECRET values in the environment examples with clearly marked
placeholders (e.g. JWT_SECRET="<YOUR_JWT_SECRET>" and
NEXTAUTH_SECRET="<YOUR_NEXTAUTH_SECRET>") and remove any concrete secret strings
from the file; update the frontend env example similarly (NEXTAUTH_SECRET
placeholder) and add a one-line note telling users how to generate secure
secrets (for example using openssl rand -hex 32 or a secrets manager) so readers
supply their own values rather than copying committed secrets.

```

**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