feat: add articles - #25
Conversation
Summary by BeetleThis PR introduces a comprehensive Articles system to the DevHub website, enabling community-driven content publishing with markdown-based articles. The implementation includes a full-stack article management system with server-side markdown parsing, client-side rendering with animations, and a caching layer for link previews. Additionally, the PR enhances the markdown parser to support images, case-insensitive callouts, and improved inline formatting (bold, italic, bold-italic). 📁 File Changes Summary (Consolidated across all commits):
Total Changes: 11 files changed, +1220 additions, -171 deletions 🗺️ Walkthrough:sequenceDiagram
participant User
participant ArticlesPage
participant ArticleLoader
participant MarkdownParser
participant ArticleClient
participant LinkPreview
participant LocalStorage
User->>ArticlesPage: Navigate to /articles
ArticlesPage->>ArticleLoader: Load all articles
ArticleLoader->>MarkdownParser: Parse markdown files
MarkdownParser-->>ArticleLoader: Return structured content
ArticleLoader-->>ArticlesPage: Return article cards
ArticlesPage-->>User: Display article grid
User->>ArticleClient: Click article
ArticleClient->>ArticleLoader: Fetch article by slug
ArticleLoader-->>ArticleClient: Return full article
ArticleClient-->>User: Render article with TOC
User->>LinkPreview: Hover over link
LinkPreview->>LocalStorage: Check cache
alt Cache hit
LocalStorage-->>LinkPreview: Return cached data
else Cache miss
LinkPreview->>LinkPreview: Fetch preview from API
LinkPreview->>LocalStorage: Store in cache
end
LinkPreview-->>User: Display preview overlay
🎯 Key Changes:
📊 Impact Assessment:
⚙️ SettingsSeverity Threshold: 📖 User Guide
|
![beetle-ai[bot]](https://avatars.githubusercontent.com/in/1636950?s=60&v=4){kind=small}
| {article.banner ? ( | ||
| <> | ||
| <img | ||
| src={article.banner} |
There was a problem hiding this comment.
The img tag uses article.banner directly without validation, which could lead to XSS attacks if banner URLs are user-controlled or come from untrusted sources. Consider using Next.js Image component which provides built-in security and optimization.
Confidence: 5/5
Suggested Fix
Replace the native img tag with Next.js Image component for better security and performance. Update the import at the top and modify the image rendering:
| src={article.banner} | |
| import Image from "next/image"; | |
Then replace the img tag with:
| src={article.banner} | |
| <Image | |
| src={article.banner} | |
| alt={article.title} | |
| fill | |
| className="object-cover transition-transform duration-500 group-hover:scale-105" | |
| unoptimized={article.banner.startsWith('http')} | |
| /> | |
This provides automatic image optimization, lazy loading, and better security against malicious URLs.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In app/articles/ArticlesListingClient.tsx around line 219, the native img tag uses article.banner directly without validation which could lead to XSS if banner URLs come from untrusted sources; replace it with Next.js Image component by importing Image from "next/image" at the top, then replace the img tag with an Image component using fill prop and object-cover className, adding unoptimized prop for external URLs, to provide built-in security and optimization.
|
Tip Make sure to check the following before pushing:
Then fix the issues, commit, and push again. Note This is just a friendly reminder and will not block the PR from being merged. |
| <img | ||
| src={article.banner} | ||
| alt={article.title} | ||
| className="w-full px-6 object-cover" | ||
| style={{ maxHeight: "260px" }} | ||
| /> |
There was a problem hiding this comment.
Similar to Comment #1 in ArticlesListingClient.tsx - the native img tag uses article.banner directly without validation, which could lead to XSS attacks if banner URLs come from untrusted sources. This is the same security vulnerability pattern.
Confidence: 5/5
Suggested Fix
Replace the native img tag with Next.js Image component for better security and performance:
| <img | |
| src={article.banner} | |
| alt={article.title} | |
| className="w-full px-6 object-cover" | |
| style={{ maxHeight: "260px" }} | |
| /> | |
| <Image | |
| src={article.banner} | |
| alt={article.title} | |
| fill | |
| className="object-cover px-6" | |
| style={{ maxHeight: "260px" }} | |
| unoptimized={article.banner.startsWith('http')} | |
| /> | |
Add the import at the top of the file:
import Image from "next/image";This provides automatic image optimization, lazy loading, and better security against malicious URLs.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In app/articles/[slug]/ArticleClient.tsx around lines 381-386, the native img tag uses article.banner directly without validation which could lead to XSS if banner URLs come from untrusted sources; replace it with Next.js Image component by importing Image from "next/image" at the top, then replace the img tag with an Image component using fill prop and appropriate styling, adding unoptimized prop for external URLs, to provide built-in security and optimization.
📍 This suggestion applies to lines 381-386
| <img | ||
| src={block.src} | ||
| alt={block.text || ""} | ||
| className="w-full object-cover" | ||
| style={{ | ||
| maxHeight: "480px", | ||
| border: `1px solid ${indigo(0.12)}`, | ||
| }} | ||
| /> |
There was a problem hiding this comment.
The img tag in the ContentBlock renderer for markdown images uses block.src directly without validation. If article content comes from user-generated markdown or external sources, this could be exploited for XSS attacks through malicious image URLs.
Confidence: 5/5
Suggested Fix
Replace with Next.js Image component for security:
| <img | |
| src={block.src} | |
| alt={block.text || ""} | |
| className="w-full object-cover" | |
| style={{ | |
| maxHeight: "480px", | |
| border: `1px solid ${indigo(0.12)}`, | |
| }} | |
| /> | |
| <Image | |
| src={block.src || ''} | |
| alt={block.text || ""} | |
| width={800} | |
| height={480} | |
| className="w-full object-cover" | |
| style={{ | |
| maxHeight: "480px", | |
| border: `1px solid ${indigo(0.12)}`, | |
| }} | |
| unoptimized={block.src?.startsWith('http')} | |
| /> | |
Add the import at the top if not already present.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In app/articles/[slug]/ArticleClient.tsx around lines 304-312, the img tag in the ContentBlock renderer uses block.src directly without validation which could lead to XSS if markdown content comes from untrusted sources; replace it with Next.js Image component by importing Image from "next/image" at the top, then replace the img tag with an Image component using appropriate width/height props and unoptimized prop for external URLs.
📍 This suggestion applies to lines 304-312
Summary by BeetleThis PR introduces a comprehensive Articles system to the DevHub website, enabling community-driven content publishing with markdown-based articles. The implementation includes a full-stack solution with server-side markdown parsing, client-side rendering with animations, and a link preview system with local storage caching for improved performance. 📁 File Changes Summary (Consolidated across all commits):
Total Changes: 16 files changed, +1,232 additions, -176 deletions 🗺️ Walkthrough:sequenceDiagram
participant User
participant Browser
participant ArticlesPage
participant ArticlesLoader
participant MarkdownParser
participant LinkPreview
participant LocalStorage
participant API
User->>Browser: Navigate to /articles
Browser->>ArticlesPage: Request articles listing
ArticlesPage->>ArticlesLoader: Load articles from filesystem
ArticlesLoader->>MarkdownParser: Parse markdown files
MarkdownParser-->>ArticlesLoader: Return structured content
ArticlesLoader-->>ArticlesPage: Return article metadata
ArticlesPage-->>Browser: Render article cards
User->>Browser: Click article card
Browser->>ArticlesPage: Navigate to /articles/[slug]
ArticlesPage->>ArticlesLoader: Get article by slug
ArticlesLoader-->>ArticlesPage: Return full article content
ArticlesPage-->>Browser: Render article with TOC
Note over Browser,LocalStorage: Link Preview Flow
User->>Browser: Hover over link
Browser->>LocalStorage: Check cache (1hr TTL)
alt Cache Hit
LocalStorage-->>Browser: Return cached preview
else Cache Miss
Browser->>API: Fetch preview metadata
API->>API: Validate origin & URL safety
API-->>Browser: Return preview data
Browser->>LocalStorage: Store in cache
end
Browser-->>User: Display preview overlay
🎯 Key Changes:
📊 Impact Assessment:
⚙️ SettingsSeverity Threshold: 📖 User Guide
|
| const regex = | ||
| /(`[^`]+`)|(\[[^\]]+\]\([^)]+\))|(#[\w-]+)|(\*\*\*[^*]+\*\*\*|___[^_]+___)|(\*\*[^*]+\*\*|__[^_]+__)|(\*[^*]+\*|_[^_]+_)/g; |
There was a problem hiding this comment.
The regex pattern for matching bold and italic markdown has a critical flaw: it uses [^*]+ and [^_]+ which means "match anything except asterisks/underscores". This will fail to match nested formatting and will break on text containing asterisks or underscores within the formatted text.
For example:
**text with * asterisk**will not match correctly*text_with_underscore*will not match correctly- Nested formatting like
**bold with *italic* inside**will fail
Additionally, the pattern doesn't account for escaped asterisks or underscores, and doesn't prevent matching across word boundaries incorrectly.
Confidence: 5/5
Suggested Fix
Use a more robust regex pattern that handles markdown formatting correctly:
| const regex = | |
| /(`[^`]+`)|(\[[^\]]+\]\([^)]+\))|(#[\w-]+)|(\*\*\*[^*]+\*\*\*|___[^_]+___)|(\*\*[^*]+\*\*|__[^_]+__)|(\*[^*]+\*|_[^_]+_)/g; | |
| const regex = | |
| /(`[^`]+`)|(\[[^\]]+\]\([^)]+\))|(#[\w-]+)|(\*\*\*(.+?)\*\*\*|___(.+?)___)|((?<!\*)\*\*(?!\*)(.+?)(?<!\*)\*\*(?!\*)|(?<!_)__(?!_)(.+?)(?<!_)__(?!_))|(\*(.+?)\*|_(.+?)_)/g; | |
This uses non-greedy matching (.+?) instead of negated character classes, which allows asterisks and underscores within formatted text. The negative lookbehind/lookahead assertions prevent matching triple asterisks as double asterisks.
However, note that you'll also need to update the destructuring on line 48 to handle the additional capture groups created by the parentheses in the pattern.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In app/pages/[slug]/PageClient.tsx around lines 37-38, the regex pattern for matching markdown bold and italic formatting uses negated character classes [^*]+ and [^_]+ which will fail on text containing asterisks or underscores within the formatted text and won't handle nested formatting; replace the pattern with non-greedy matching using .+? instead of [^*]+ and [^_]+, and add negative lookbehind/lookahead assertions to prevent incorrect matching of triple asterisks as double asterisks, then update the destructuring on line 48 to correctly extract the matched text from the new capture groups.
📍 This suggestion applies to lines 37-38
| } | ||
|
|
||
| function loadArticleFromFile(filePath: string): Article { | ||
| const raw = fs.readFileSync(filePath, "utf-8"); |
There was a problem hiding this comment.
Missing error handling for fs.readFileSync could crash the entire application if any article file is corrupted, has permission issues, or contains invalid UTF-8. This is a critical code quality issue that can cause build failures.
Confidence: 5/5
Suggested Fix
Wrap the file read operation in a try-catch block and handle errors gracefully:
| const raw = fs.readFileSync(filePath, "utf-8"); | |
| try { | |
| const raw = fs.readFileSync(filePath, "utf-8"); | |
| } catch (error) { | |
| console.error(`Failed to read article file: ${filePath}`, error); | |
| throw new Error(`Unable to load article from ${filePath}: ${error instanceof Error ? error.message : 'Unknown error'}`); | |
| } | |
This provides better error messages during build time and makes debugging easier when article files have issues.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In content/articles-loader.ts around line 53, the fs.readFileSync call has no error handling which could crash the application if any article file is corrupted or unreadable; wrap the file read operation in a try-catch block that logs the specific file path and error details, then throws a descriptive error that will help developers identify which article file is causing the problem during build time.
| return articles; | ||
| } | ||
|
|
||
| const _articles = buildArticles(); |
There was a problem hiding this comment.
buildArticles() is called at module load time and uses synchronous file operations (fs.readFileSync, fs.readdirSync), which blocks the entire Node.js event loop during application startup. If there are many articles or large markdown files, this could cause significant startup delays or timeouts in serverless environments.
Confidence: 5/5
Suggested Fix
Consider one of these approaches:
- If articles are needed at build time only: Keep the current approach but document the performance implications
- If articles can be loaded on-demand: Remove the module-level call and load articles lazily
- For better performance: Use async file operations with caching
For immediate improvement, at minimum add a comment documenting this is intentional:
| const _articles = buildArticles(); | |
| // Articles are loaded synchronously at module initialization (build time) | |
| // This is acceptable for build-time SSG but may cause delays in serverless environments | |
| const _articles = buildArticles(); | |
For a more robust solution, consider implementing lazy loading or async initialization.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In content/articles-loader.ts around line 96, buildArticles() is called at module load time using synchronous file operations which blocks the Node.js event loop and could cause startup delays with many articles; evaluate whether articles need to be loaded at module initialization or if they can be loaded lazily on-demand, and if synchronous loading is required for build-time SSG, add a comment documenting this design decision and its performance implications, or consider refactoring to use async file operations with proper caching.
| {article.banner ? ( | ||
| <> | ||
| <img | ||
| src={article.banner} |
There was a problem hiding this comment.
The img tag uses article.banner directly without validation, which could lead to XSS attacks if banner URLs are user-controlled or come from untrusted sources. Additionally, using native img instead of Next.js Image component misses out on automatic optimization.
Confidence: 5/5
Suggested Fix
| src={article.banner} | |
| import Image from "next/image"; | |
Replace the img tag with Next.js Image component for better security and performance. Update the banner rendering section to use:
<Image
src={article.banner}
alt={article.title}
fill
className="object-cover transition-transform duration-500 group-hover:scale-105"
sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw"
/>This provides automatic image optimization, lazy loading, and better security through Next.js's built-in protections.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In app/articles/ArticlesListingClient.tsx around line 219, the component uses a native img tag with article.banner directly which poses XSS risks and misses Next.js optimizations; replace the img tag with Next.js Image component, import Image from "next/image" at the top, update the banner div to use position relative, and replace the img with <Image src={article.banner} alt={article.title} fill className="object-cover transition-transform duration-500 group-hover:scale-105" sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw" />, ensuring the parent div maintains its height style.
|
Note Linting checks passed successfully 🎉 All formatting and code quality checks are clean. You're good to merge 🚀 |
| src={article.banner} | ||
| alt={article.title} | ||
| className="w-full px-6 object-cover" | ||
| style={{ maxHeight: "260px" }} | ||
| /> |
There was a problem hiding this comment.
Same issue as Comment #1 - The banner img tag uses article.banner directly without validation, which could lead to XSS attacks if banner URLs come from untrusted sources. Additionally, using native img instead of Next.js Image component misses out on automatic optimization and security protections.
Confidence: 5/5
Suggested Fix
Import Next.js Image component at the top of the file and replace the native img tag with the optimized Image component. This provides automatic image optimization, lazy loading, and better security through Next.js's built-in protections.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In app/articles/[slug]/ArticleClient.tsx around line 382-386, the banner img tag uses article.banner directly which poses XSS risks and misses Next.js optimizations; import Image from "next/image" at the top, update the parent div (line 377-380) to use position relative, and replace the img tag with <Image src={article.banner} alt={article.title} fill className="w-full px-6 object-cover" style={{ maxHeight: "260px" }} sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw" />, ensuring the parent div maintains its styling.
📍 This suggestion applies to lines 382-386
| <img | ||
| src={block.src} | ||
| alt={block.text || ""} | ||
| className="w-full object-cover" | ||
| style={{ | ||
| maxHeight: "480px", | ||
| border: `1px solid ${indigo(0.12)}`, | ||
| }} | ||
| /> |
There was a problem hiding this comment.
The img tag in the ContentBlock component uses block.src directly without validation, which could lead to XSS attacks if image sources come from untrusted markdown content. Using native img instead of Next.js Image component also misses automatic optimization.
Confidence: 5/5
Suggested Fix
Replace the native img tag with Next.js Image component for better security and performance. Import Image from "next/image" and update the figure element to use the Image component with proper sizing.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In app/articles/[slug]/ArticleClient.tsx around line 304-312, the ContentBlock img case uses block.src directly which poses XSS risks; import Image from "next/image" at the top if not already imported, wrap the Image in a div with position relative and appropriate height, and replace the img tag with <Image src={block.src} alt={block.text || ""} fill className="object-cover" style={{ maxHeight: "480px" }} sizes="(max-width: 768px) 100vw, (max-width: 1200px) 80vw, 60vw" />, maintaining the border styling on the parent container.
📍 This suggestion applies to lines 304-312
| href={linkMatch[2]} | ||
| newTab={ | ||
| linkMatch[2].startsWith("https") || | ||
| redirects[0].sources.includes(linkMatch[2]) |
There was a problem hiding this comment.
Accessing redirects[0].sources without checking if the redirects array has elements could cause a runtime error if the array is empty. This could crash the component when rendering links.
Confidence: 5/5
Suggested Fix
| redirects[0].sources.includes(linkMatch[2]) | |
| redirects[0]?.sources.includes(linkMatch[2]) | |
Add optional chaining to safely access the first element of the redirects array, preventing potential runtime errors if the array is empty.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In app/articles/[slug]/ArticleClient.tsx around line 75, the code accesses redirects[0].sources without checking if the redirects array has elements which could cause a runtime error; add optional chaining by changing redirects[0].sources to redirects[0]?.sources to safely handle empty arrays.
| } | ||
|
|
||
| export default async function ArticleRoute({ params }: Props) { | ||
| const { slug } = (await params) as { slug: string }; |
There was a problem hiding this comment.
The type assertion as { slug: string } bypasses TypeScript's type safety without validating that params actually contains a slug property. If the params structure is malformed or the slug is missing/undefined, this could cause runtime errors when accessing article.slug in line 11.
Confidence: 4/5
Suggested Fix
Add proper validation before the type assertion to ensure the slug exists:
const resolvedParams = await params;
if (!resolvedParams || typeof resolvedParams.slug !== 'string') {
notFound();
}
const { slug } = resolvedParams;This ensures that the slug is validated before use, preventing potential runtime errors from malformed params.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In app/articles/[slug]/page.tsx around line 10, the code uses a type assertion (as { slug: string }) without validating that params actually contains a valid slug property which could cause runtime errors; replace line 10 with proper validation: const resolvedParams = await params; if (!resolvedParams || typeof resolvedParams.slug !== 'string') { notFound(); } const { slug } = resolvedParams; to ensure the slug exists and is a string before proceeding.
| function writeCache(href: string, data: PreviewData | null) { | ||
| try { | ||
| if (data == null) return; | ||
| const entry: CachedPreview = { data, cachedAt: Date.now() }; | ||
| window.localStorage.setItem(CACHE_PREFIX + href, JSON.stringify(entry)); | ||
| } catch { | ||
| // storage unavailable or full, fall back to no persistence | ||
| } | ||
| } |
There was a problem hiding this comment.
The writeCache function silently skips caching when data == null (line 38), which means failed preview fetches are never cached. This causes the same failed URL to be re-fetched on every hover, wasting network resources and potentially causing rate limiting or performance degradation. Failed fetches should be cached with a shorter TTL to prevent repeated failed requests.
Confidence: 4/5
Suggested Fix
Remove the early return for null data and cache failures as well:
| function writeCache(href: string, data: PreviewData | null) { | |
| try { | |
| if (data == null) return; | |
| const entry: CachedPreview = { data, cachedAt: Date.now() }; | |
| window.localStorage.setItem(CACHE_PREFIX + href, JSON.stringify(entry)); | |
| } catch { | |
| // storage unavailable or full, fall back to no persistence | |
| } | |
| } | |
| function writeCache(href: string, data: PreviewData | null) { | |
| try { | |
| const entry: CachedPreview = { data, cachedAt: Date.now() }; | |
| window.localStorage.setItem(CACHE_PREFIX + href, JSON.stringify(entry)); | |
| } catch { | |
| // storage unavailable or full, fall back to no persistence | |
| } | |
This ensures both successful and failed preview fetches are cached, preventing repeated network requests for URLs that consistently fail.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In components/LinkPreviewCard.tsx around line 38, the writeCache function has an early return when data is null which prevents caching of failed preview fetches, causing the same failed URL to be re-fetched repeatedly on every hover; remove the "if (data == null) return;" check so that null values are also cached, preventing unnecessary repeated network requests for URLs that consistently fail to load previews.
📍 This suggestion applies to lines 36-44
| function loadArticleFromFile(filePath: string): Article { | ||
| const raw = fs.readFileSync(filePath, "utf-8"); | ||
| const { metadata, sections } = parseMarkdown(raw); |
There was a problem hiding this comment.
The loadArticleFromFile function lacks error handling for file read and parse operations. If any markdown file is corrupted, unreadable, or fails to parse, the entire build will crash without providing helpful debugging information about which file caused the failure.
Confidence: 5/5
Suggested Fix
Wrap the file operations in try-catch to handle errors gracefully and provide meaningful error messages:
| function loadArticleFromFile(filePath: string): Article { | |
| const raw = fs.readFileSync(filePath, "utf-8"); | |
| const { metadata, sections } = parseMarkdown(raw); | |
| function loadArticleFromFile(filePath: string): Article { | |
| try { | |
| const raw = fs.readFileSync(filePath, "utf-8"); | |
| const { metadata, sections } = parseMarkdown(raw); | |
Add error handling around the entire function body and provide context about which file failed:
function loadArticleFromFile(filePath: string): Article {
try {
const raw = fs.readFileSync(filePath, "utf-8");
const { metadata, sections } = parseMarkdown(raw);
// ... rest of the function
} catch (error) {
throw new Error(
`Failed to load article from ${filePath}: ${error instanceof Error ? error.message : String(error)}`
);
}This ensures that build failures provide clear information about which article file is problematic.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In content/articles-loader.ts around line 52-54, the loadArticleFromFile function lacks error handling which could cause the entire build to crash without helpful debugging information if any markdown file is corrupted or fails to parse; wrap the entire function body in a try-catch block that catches any errors and throws a new Error with a message like "Failed to load article from ${filePath}: ${error.message}" to provide context about which file caused the failure.
📍 This suggestion applies to lines 52-54
| slug: coming-soon | ||
| title: Coming Soon | ||
| description: Articles are coming soon!! | ||
| banner: https://shorturl.at/DWs97 |
There was a problem hiding this comment.
The banner URL uses a URL shortener (shorturl.at), which poses security risks. URL shorteners can be hijacked, changed after publication, or lead to malicious content. This is especially problematic since the banner image is rendered directly in the UI (as noted in previous comments about XSS risks with image sources).
Confidence: 5/5
Suggested Fix
Replace the shortened URL with the direct, full URL to the actual image resource. If you don't have the direct URL, upload the image to a trusted CDN or the repository's assets folder and reference it directly:
banner: /assets/articles/coming-soon-banner.jpg
Or use a direct URL from a trusted source:
banner: https://cdn.example.com/images/coming-soon-banner.jpg
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In content/articles/coming-soon.md at line 5, the banner field uses a URL shortener (https://shorturl.at/DWs97) which poses security risks as shortened URLs can be hijacked or changed; replace the shortened URL with the direct, full URL to the actual image resource, or upload the image to the repository's assets folder and use a relative path like /assets/articles/coming-soon-banner.jpg instead.
|
|
||
| A lot of useful knowledge about building on Discord ends up scattered across random threads, outdated docs, and tribal knowledge passed around in DMs. The goal here is to put that knowledge somewhere permanent, searchable, and easy to point people to. | ||
|
|
||
|  |
There was a problem hiding this comment.
Same issue as the banner - the "Under Construction" image uses a URL shortener (shorturl.at), which poses the same security risks. URL shorteners can be hijacked, redirected, or lead to malicious content after publication.
Confidence: 5/5
Suggested Fix
Replace the shortened URL with a direct URL to the actual image or use a local asset:
|  | |
|  | |
Or use a direct URL from a trusted source if hosting externally.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In content/articles/coming-soon.md at line 28, the Under Construction image uses a URL shortener (https://shorturl.at/CEn66) which poses security risks; replace the shortened URL with a direct URL to the actual image resource, or upload the image to the repository's assets folder and use a relative path like /assets/articles/under-construction.jpg instead.
| } | ||
|
|
||
| // Image embed:  | ||
| const imgMatch = trimmed.match(/^!\[([^\]]*)\]\(([^)]+)\)$/); |
There was a problem hiding this comment.
The image parsing extracts the URL directly from markdown without any validation or sanitization. The src value from imgMatch[2].trim() is stored directly in the block and will be used in the rendering layer (as seen in previous comments about XSS risks in ArticleClient.tsx). This parser should validate that URLs are safe or at least document that URL validation must happen in the rendering layer.
Related to Comments #1, #5, #6, and #13 which identified XSS risks and URL shortener security issues in the rendering components. The parser is the entry point where this validation could occur.
Confidence: 5/5
Suggested Fix
Add URL validation to ensure only safe protocols are allowed, or at minimum add a comment documenting that URL validation is required in the rendering layer:
// Image embed: 
// NOTE: URL validation must be performed in the rendering layer to prevent XSS
const imgMatch = trimmed.match(/^!\[([^\]]*)\]\(([^)]+)\)$/);
if (imgMatch) {
flushParagraph();
const src = imgMatch[2].trim();
// Basic protocol validation - only allow http(s) and relative URLs
if (src.startsWith('http://') || src.startsWith('https://') || src.startsWith('/')) {
blocks.push({ type: "img", text: imgMatch[1].trim(), src });
} else {
// Treat as paragraph if URL protocol is unsafe
blocks.push({ type: "p", text: trimmed });
}
i++;
continue;
}Alternatively, if validation should happen in the rendering layer, add a clear comment documenting this requirement.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In lib/markdown/parser.ts around lines 162-165, the image parsing extracts URLs directly without validation which creates security risks when combined with the rendering layer (see XSS issues in ArticleClient.tsx); add URL protocol validation by checking if src starts with 'http://', 'https://', or '/' before creating the img block, and if the protocol is unsafe, treat the line as a paragraph block instead, or at minimum add a comment documenting that URL validation must be performed in the rendering layer to prevent XSS attacks.
📍 This suggestion applies to lines 162-165
| function isAllowedOrigin(request: NextRequest): boolean { | ||
| const origin = request.headers.get("origin"); | ||
| if (origin) { | ||
| return ALLOWED_ORIGINS.includes(origin); | ||
| } | ||
| const referer = request.headers.get("referer"); | ||
| if (referer) { | ||
| try { | ||
| return ALLOWED_ORIGINS.includes(new URL(referer).origin); | ||
| } catch { | ||
| return false; | ||
| } | ||
| } | ||
| return false; | ||
| } |
There was a problem hiding this comment.
The isAllowedOrigin function has a logic flaw: it returns false when both origin and referer headers are missing (line 83). However, the caller at line 87 treats false as "forbidden". This means legitimate requests without these headers (e.g., direct API calls, some mobile clients, or privacy-focused browsers) will be blocked.
Additionally, if this is intended as CORS protection, the implementation is incomplete - it validates the origin but doesn't set CORS response headers, which means browsers will still block the response even if the origin is allowed.
Confidence: 4/5
Suggested Fix
Consider the intended behavior:
Option 1: If requests without origin/referer should be allowed (more permissive):
| function isAllowedOrigin(request: NextRequest): boolean { | |
| const origin = request.headers.get("origin"); | |
| if (origin) { | |
| return ALLOWED_ORIGINS.includes(origin); | |
| } | |
| const referer = request.headers.get("referer"); | |
| if (referer) { | |
| try { | |
| return ALLOWED_ORIGINS.includes(new URL(referer).origin); | |
| } catch { | |
| return false; | |
| } | |
| } | |
| return false; | |
| } | |
| function isAllowedOrigin(request: NextRequest): boolean { | |
| const origin = request.headers.get("origin"); | |
| if (origin) { | |
| return ALLOWED_ORIGINS.includes(origin); | |
| } | |
| const referer = request.headers.get("referer"); | |
| if (referer) { | |
| try { | |
| return ALLOWED_ORIGINS.includes(new URL(referer).origin); | |
| } catch { | |
| return false; | |
| } | |
| // Allow requests without origin/referer (e.g., server-side calls, direct API access) | |
| return true; | |
| } | |
Option 2: If this is meant to be strict CORS protection, add proper CORS headers in the response:
After line 89, add CORS headers to the response throughout the function:
const headers = {
'Access-Control-Allow-Origin': origin || referer ? new URL(referer!).origin : ALLOWED_ORIGINS[0],
'Access-Control-Allow-Methods': 'GET',
'Access-Control-Allow-Headers': 'Content-Type',
};And include these headers in all NextResponse.json() calls.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In app/api/link-preview/route.ts around lines 70-84, the isAllowedOrigin function returns false when both origin and referer headers are missing, which will block legitimate requests without these headers; decide on the intended behavior: if requests without origin/referer should be allowed, change line 83 to return true instead of false; if strict CORS protection is intended, keep the current logic but add proper CORS response headers (Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers) to all NextResponse.json() calls throughout the GET handler function.
📍 This suggestion applies to lines 70-84
Summary by BeetleThis PR implements a performance optimization by replacing real-time API calls for link previews with hardcoded preview data, using the API as a fallback mechanism. The change eliminates CORS restrictions, reduces server load, and improves page load times by serving preview metadata directly from a static configuration file. Additionally, the PR includes minor content updates across documentation pages, standardizing internal links and fixing capitalization inconsistencies. 📁 File Changes Summary (Consolidated across all commits):
Total Changes: 20 files changed, +279 additions, -101 deletions 🗺️ Walkthrough:sequenceDiagram
participant User
participant LinkPreviewCard
participant PREVIEWS
participant API
participant Cache
User->>LinkPreviewCard: Hover over link
LinkPreviewCard->>LinkPreviewCard: Normalize URL
LinkPreviewCard->>PREVIEWS: Check hardcoded data
alt Preview exists in PREVIEWS
PREVIEWS-->>LinkPreviewCard: Return preview data
LinkPreviewCard->>User: Display preview instantly
else Preview not found
LinkPreviewCard->>API: Fetch from /api/link-preview
API-->>LinkPreviewCard: Return fetched data
LinkPreviewCard->>User: Display preview
end
Note over Cache: localStorage caching removed
Note over PREVIEWS: Contains 150+ hardcoded previews
🎯 Key Changes:
📊 Impact Assessment:
⚙️ SettingsSeverity Threshold: 📖 User Guide
|
|
Note Linting checks passed successfully 🎉 All formatting and code quality checks are clean. You're good to merge 🚀 |
| - **Community guides** — practical walkthroughs for setting up bots, moderation, and server tooling | ||
| - **Dev culture stuff** — takes on tools, workflows, and things happening in the wider Discord dev ecosystem | ||
|
|
||
| > [!NOTE] Got a topic you want covered? Use the `/suggest` command in Panda to send it our way. Or if you'd rather write it yourself, fork [open-devhub/website](/r/website), add your article under `/content/articles/`, and open a PR — articles here are written by the people building DevHub, so community input actually shapes what gets published. |
There was a problem hiding this comment.
The GitHub repository link has been changed from a direct URL to an internal route /r/website, but this route likely doesn't exist in the application. Users clicking this link to fork the repository will encounter a 404 error or unexpected behavior. The original https://github.com/open-devhub/website URL should be preserved since it's a functional link for forking, not just a preview reference.
Confidence: 5/5
Suggested Fix
| > [!NOTE] Got a topic you want covered? Use the `/suggest` command in Panda to send it our way. Or if you'd rather write it yourself, fork [open-devhub/website](/r/website), add your article under `/content/articles/`, and open a PR — articles here are written by the people building DevHub, so community input actually shapes what gets published. | |
| > [!NOTE] Got a topic you want covered? Use the `/suggest` command in Panda to send it our way. Or if you'd rather write it yourself, fork [open-devhub/website](https://github.com/open-devhub/website), add your article under `/content/articles/`, and open a PR — articles here are written by the people building DevHub, so community input actually shapes what gets published. | |
Revert to the original GitHub URL. While the PR optimizes link previews by using internal routes elsewhere, this particular link serves a functional purpose (forking the repository) and must remain as a direct GitHub URL. If you want to use the preview optimization, you can keep the GitHub URL here and ensure it's included in the lib/previews.ts hardcoded preview data.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In content/articles/coming-soon.md at line 22, the GitHub repository link has been incorrectly changed from https://github.com/open-devhub/website to /r/website. This breaks the fork functionality since /r/website is not a valid route in the application. Revert this link back to the full GitHub URL https://github.com/open-devhub/website to ensure users can properly fork the repository. The link preview optimization should not affect functional links that users need to click to perform actions like forking.
| - Language and framework-specific channels | ||
| - Career and job hunting channels. | ||
| - An active [open source org](https://github.com/open-devhub) on GitHub. | ||
| - An active [open source org](/github) on GitHub. |
There was a problem hiding this comment.
The GitHub organization link has been changed to /github, but this route is incorrect. Based on the PR's preview optimization pattern (see lib/previews.ts), GitHub organization links should use the format /r/{org-name}. The correct internal route should be /r/open-devhub, not /github. Users clicking this link will encounter a 404 error.
This is similar to the issue in Comment #2 (coming-soon.md), where GitHub links need to either remain as full URLs or use the correct internal route format.
Confidence: 5/5
Suggested Fix
| - An active [open source org](/github) on GitHub. | |
| - An active [open source org](/r/open-devhub) on GitHub. | |
Use the correct internal route format /r/open-devhub to match the preview optimization pattern established in this PR. Alternatively, if this link serves a functional purpose beyond preview display, consider reverting to the full GitHub URL https://github.com/open-devhub.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In content/pages/community/join-guide.md at line 22, the GitHub organization link has been incorrectly changed to /github. Based on the preview optimization pattern in lib/previews.ts, GitHub organization links should use the format /r/{org-name}. Change /github to /r/open-devhub to match the established pattern, or revert to the full GitHub URL https://github.com/open-devhub if the link needs to be directly clickable for functional purposes.
Summary by BeetleThis PR introduces a comprehensive Articles system to the DevHub website, enabling community-driven content publishing with markdown support, link previews, and a polished reading experience. It also includes several quality-of-life improvements to the existing Pages system, including better navigation ordering, enhanced markdown formatting, and optimized image handling. 📁 File Changes Summary (Consolidated across all commits):
Total Changes: 20 files changed, +1,521 additions, -245 deletions 🗺️ Walkthrough:sequenceDiagram
participant User
participant ArticlesListing
participant ArticleReader
participant MarkdownParser
participant LinkPreview
participant PreviewData
User->>ArticlesListing: Visit /articles
ArticlesListing->>ArticlesListing: Load article cards (title, desc, banner, tags)
ArticlesListing->>User: Display grid with hover effects
User->>ArticleReader: Click article
ArticleReader->>MarkdownParser: Parse markdown content
MarkdownParser->>MarkdownParser: Extract h2/h3, paragraphs, lists, code, callouts, images
MarkdownParser->>ArticleReader: Return structured blocks
ArticleReader->>ArticleReader: Render banner, metadata, TOC
ArticleReader->>LinkPreview: Detect inline links
LinkPreview->>PreviewData: Check hardcoded previews
alt Preview exists
PreviewData->>LinkPreview: Return cached metadata
else No preview
LinkPreview->>API: Fetch from /api/link-preview
API->>LinkPreview: Return scraped metadata
end
LinkPreview->>User: Show hover card with title/desc/image
ArticleReader->>User: Display formatted article with navigation
🎯 Key Changes:
📊 Impact Assessment:
⚙️ SettingsSeverity Threshold: 📖 User Guide
|
| <> | ||
| <Image | ||
| src={article.banner} | ||
| alt={article.title} | ||
| fill |
There was a problem hiding this comment.
The <img> tag is using an unvalidated article.banner URL directly, which could lead to XSS attacks if the banner URL contains malicious content or points to an untrusted source. Additionally, using native <img> instead of Next.js Image component bypasses built-in security features and optimizations.
Confidence: 5/5
Suggested Fix
| <> | |
| <Image | |
| src={article.banner} | |
| alt={article.title} | |
| fill | |
| <Image | |
| src={article.banner} | |
| alt={article.title} | |
| width={600} | |
| height={200} | |
| className="w-full h-full object-cover transition-transform duration-500 group-hover:scale-105" | |
| unoptimized={article.banner.startsWith('http')} | |
| /> | |
- Import
Imagefromnext/imageat the top of the file - Replace the native
<img>tag with Next.jsImagecomponent - Add explicit width/height props for proper optimization
- Use
unoptimizedprop conditionally for external URLs if needed - Consider validating banner URLs server-side in
articles-loader.tsto ensure they come from trusted sources
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In app/articles/ArticlesListingClient.tsx around line 218, the native <img> tag is being used with an unvalidated external URL (article.banner) which poses security risks and bypasses Next.js optimizations; replace it with the Next.js Image component, add the necessary import statement at the top (import Image from "next/image"), include proper width and height props, and consider adding URL validation in the articles-loader to ensure banner URLs come from trusted sources only.
📍 This suggestion applies to lines 218-222
|
Note Linting checks passed successfully 🎉 All formatting and code quality checks are clean. You're good to merge 🚀 |
| /> | ||
| <p | ||
| className="text-sm" | ||
| style={{ | ||
| fontFamily: "var(--font-geist-mono)", | ||
| color: textColors.muted, | ||
| }} | ||
| > | ||
| <ApplySpecialClass text={block.text || ""} previews={previews} /> |
There was a problem hiding this comment.
The <img> tag in the ContentBlock component uses an unvalidated block.src URL directly, which could lead to XSS attacks or loading malicious content from untrusted sources. This is a security vulnerability that needs to be addressed.
Confidence: 5/5
Suggested Fix
Replace the native <img> tag with Next.js Image component and add URL validation:
| /> | |
| <p | |
| className="text-sm" | |
| style={{ | |
| fontFamily: "var(--font-geist-mono)", | |
| color: textColors.muted, | |
| }} | |
| > | |
| <ApplySpecialClass text={block.text || ""} previews={previews} /> | |
| <Image | |
| src={block.src} | |
| alt={block.text || ""} | |
| width={800} | |
| height={480} | |
| className="w-full object-cover" | |
| style={{ | |
| maxHeight: "480px", | |
| border: `1px solid ${indigo(0.12)}`, | |
| }} | |
| unoptimized={block.src?.startsWith('http')} | |
| /> | |
- Import
Imagefromnext/imageat the top of the file - Replace the native
<img>tag with Next.jsImagecomponent - Add explicit width/height props for proper optimization
- Use
unoptimizedprop conditionally for external URLs - Consider validating image URLs in the markdown parser to ensure they come from trusted sources
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In app/articles/[slug]/ArticleClient.tsx around line 304, the native <img> tag in the ContentBlock component is being used with an unvalidated external URL (block.src) which poses security risks and bypasses Next.js optimizations; replace it with the Next.js Image component, add the necessary import statement at the top (import Image from "next/image"), include proper width and height props, and consider adding URL validation in the markdown parser to ensure image URLs come from trusted sources only.
📍 This suggestion applies to lines 304-312
| function loadArticleFromFile(filePath: string): Article { | ||
| const raw = fs.readFileSync(filePath, "utf-8"); | ||
| const { metadata, sections } = parseMarkdown(raw); | ||
|
|
||
| const wordCount = sections | ||
| .flatMap((b) => | ||
| b.type === "p" || b.type === "h2" || b.type === "h3" | ||
| ? (b.text || "").split(/\s+/) | ||
| : b.items || [], | ||
| ) | ||
| .join(" ") | ||
| .split(/\s+/).length; | ||
| const readingTime = `${Math.max(1, Math.ceil(wordCount / 200))} min read`; | ||
|
|
||
| return { | ||
| slug: metadata.slug || path.basename(filePath, ".md"), | ||
| title: metadata.title || "Untitled", | ||
| description: metadata.description || "", | ||
| banner: metadata.banner || "", | ||
| author: metadata.author || "", | ||
| authorGithub: metadata.authorGithub || "", | ||
| date: metadata.date || "", | ||
| dateISO: parseDate(metadata.date || ""), | ||
| tags: parseTags(metadata.tags || ""), | ||
| readingTime: metadata.readingTime || readingTime, | ||
| content: sections, | ||
| }; | ||
| } |
There was a problem hiding this comment.
The loadArticleFromFile function lacks error handling for file system operations and markdown parsing. If fs.readFileSync fails (corrupted file, permission issues) or parseMarkdown throws an error (malformed markdown), the entire build will crash without a clear error message indicating which article file caused the problem.
Confidence: 5/5
Suggested Fix
Add try-catch error handling with informative error messages:
| function loadArticleFromFile(filePath: string): Article { | |
| const raw = fs.readFileSync(filePath, "utf-8"); | |
| const { metadata, sections } = parseMarkdown(raw); | |
| const wordCount = sections | |
| .flatMap((b) => | |
| b.type === "p" || b.type === "h2" || b.type === "h3" | |
| ? (b.text || "").split(/\s+/) | |
| : b.items || [], | |
| ) | |
| .join(" ") | |
| .split(/\s+/).length; | |
| const readingTime = `${Math.max(1, Math.ceil(wordCount / 200))} min read`; | |
| return { | |
| slug: metadata.slug || path.basename(filePath, ".md"), | |
| title: metadata.title || "Untitled", | |
| description: metadata.description || "", | |
| banner: metadata.banner || "", | |
| author: metadata.author || "", | |
| authorGithub: metadata.authorGithub || "", | |
| date: metadata.date || "", | |
| dateISO: parseDate(metadata.date || ""), | |
| tags: parseTags(metadata.tags || ""), | |
| readingTime: metadata.readingTime || readingTime, | |
| content: sections, | |
| }; | |
| } | |
| function loadArticleFromFile(filePath: string): Article { | |
| try { | |
| const raw = fs.readFileSync(filePath, "utf-8"); | |
| const { metadata, sections } = parseMarkdown(raw); | |
| const wordCount = sections | |
| .flatMap((b) => | |
| b.type === "p" || b.type === "h2" || b.type === "h3" | |
| ? (b.text || "").split(/\s+/) | |
| : b.items || [], | |
| ) | |
| .join(" ") | |
| .split(/\s+/).length; | |
| const readingTime = `${Math.max(1, Math.ceil(wordCount / 200))} min read`; | |
| return { | |
| slug: metadata.slug || path.basename(filePath, ".md"), | |
| title: metadata.title || "Untitled", | |
| description: metadata.description || "", | |
| banner: metadata.banner || "", | |
| author: metadata.author || "", | |
| authorGithub: metadata.authorGithub || "", | |
| date: metadata.date || "", | |
| dateISO: parseDate(metadata.date || ""), | |
| tags: parseTags(metadata.tags || ""), | |
| readingTime: metadata.readingTime || readingTime, | |
| content: sections, | |
| }; | |
| } catch (error) { | |
| throw new Error( | |
| `Failed to load article from ${filePath}: ${error instanceof Error ? error.message : String(error)}` | |
| ); | |
| } | |
This ensures that build failures clearly indicate which article file is problematic, making debugging much easier.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In content/articles-loader.ts around line 52, the loadArticleFromFile function lacks error handling for file system operations and markdown parsing which could cause cryptic build failures; wrap the entire function body in a try-catch block that catches any errors from fs.readFileSync or parseMarkdown, and throw a new Error with a clear message that includes the file path and the original error message to make debugging easier when article files are corrupted or malformed.
📍 This suggestion applies to lines 52-79
| slug: coming-soon | ||
| title: Coming Soon | ||
| description: Articles are coming soon!! | ||
| banner: https://shorturl.at/DWs97 |
There was a problem hiding this comment.
The banner URL uses a URL shortener service (https://shorturl.at/DWs97), which poses a security risk. URL shorteners obfuscate the actual destination, making it impossible to validate the content source. The shortened URL could be redirected to malicious content at any time, bypassing content security policies. This is the root cause of the security issues flagged in Comments #1 and #3.
Confidence: 5/5
Suggested Fix
Replace the shortened URL with a direct URL to a trusted image hosting service:
| banner: https://shorturl.at/DWs97 | |
| banner: https://images.example.com/articles/coming-soon-banner.jpg | |
Recommended approaches:
- Host images directly in the repository under
/public/images/articles/ - Use a trusted CDN or image hosting service with direct URLs
- If using external images, ensure they come from trusted domains only
- Update the
articles-loader.tsto validate banner URLs against an allowlist of trusted domains
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In content/articles/coming-soon.md on line 5, the banner field uses a URL shortener service (https://shorturl.at/DWs97) which poses security risks because the actual destination is obfuscated and could be redirected to malicious content; replace it with a direct URL to a trusted image source, either by hosting the image in the repository under /public/images/articles/ or using a trusted CDN with a direct URL, and consider implementing URL validation in articles-loader.ts to ensure all banner URLs come from an allowlist of trusted domains.
|
|
||
| A lot of useful knowledge about building on Discord ends up scattered across random threads, outdated docs, and tribal knowledge passed around in DMs. The goal here is to put that knowledge somewhere permanent, searchable, and easy to point people to. | ||
|
|
||
|  |
There was a problem hiding this comment.
The embedded image uses a URL shortener service (https://shorturl.at/CEn66), which poses the same security risk as the banner URL. This shortened URL could be redirected to malicious content, and there's no way to validate the actual destination without following the redirect.
Confidence: 5/5
Suggested Fix
Replace the shortened URL with a direct URL to a trusted image hosting service:
|  | |
|  | |
Recommended approaches:
- Host the image directly in the repository under
/public/images/articles/ - Use a trusted CDN or image hosting service with direct URLs
- Update the markdown parser to validate image URLs against an allowlist of trusted domains
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In content/articles/coming-soon.md on line 28, the embedded image uses a URL shortener service (https://shorturl.at/CEn66) which poses security risks because the actual destination is obfuscated and could be redirected to malicious content; replace it with a direct URL to a trusted image source, either by hosting the image in the repository under /public/images/articles/ or using a trusted CDN with a direct URL, and consider implementing URL validation in the markdown parser to ensure all image URLs come from an allowlist of trusted domains.
| } | ||
|
|
||
| // Image embed:  | ||
| const imgMatch = trimmed.match(/^!\[([^\]]*)\]\(([^)]+)\)$/); |
There was a problem hiding this comment.
The image URL parser extracts and stores URLs without any validation, creating a security vulnerability. This allows malicious URLs (javascript: URIs, data URIs, URL shorteners pointing to malicious content) to be embedded in markdown and rendered in the application. This is the root cause of the security issues flagged in Comments #1, #3, #9, and #10.
Confidence: 5/5
Suggested Fix
Add URL validation to ensure only safe, trusted image sources are allowed:
| } | |
| // Image embed:  | |
| const imgMatch = trimmed.match(/^!\[([^\]]*)\]\(([^)]+)\)$/); | |
| // Image embed:  | |
| const imgMatch = trimmed.match(/^!\[([^\]]*)\]\(([^)]+)\)$/); | |
| if (imgMatch) { | |
| flushParagraph(); | |
| const src = imgMatch[2].trim(); | |
| // Validate URL: only allow http(s) and relative paths, block javascript: and data: URIs | |
| if (src.startsWith('javascript:') || src.startsWith('data:')) { | |
| // Skip malicious URLs | |
| i++; | |
| continue; | |
| } | |
| // Warn about URL shorteners (optional - could also block them) | |
| if (src.match(/\b(bit\.ly|tinyurl\.com|shorturl\.at|t\.co)\b/i)) { | |
| console.warn(`Warning: URL shortener detected in image: ${src}`); | |
| } | |
| blocks.push({ type: "img", text: imgMatch[1].trim(), src }); | |
| i++; | |
| continue; | |
| } | |
Better approach: Implement a comprehensive URL validation function:
- Create a
validateImageUrl(url: string): booleanfunction - Maintain an allowlist of trusted domains for external images
- Block
javascript:,data:, and other dangerous URI schemes - Optionally block or warn about URL shorteners
- Only allow relative paths or URLs from trusted domains
This validation should be applied here in the parser to prevent malicious URLs from ever entering the content blocks.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In lib/markdown/parser.ts around line 162, the image URL parser (imgMatch[2]) extracts and stores URLs without any validation, allowing malicious URLs like javascript: URIs, data: URIs, and URL shorteners pointing to malicious content to be embedded in markdown; add URL validation to block dangerous URI schemes (javascript:, data:), optionally warn about or block URL shorteners (bit.ly, tinyurl.com, shorturl.at), and consider implementing an allowlist of trusted domains for external images to ensure only safe image sources are rendered in the application.
📍 This suggestion applies to lines 162-165
| return false; | ||
| } | ||
|
|
||
| export async function GET(request: NextRequest) { |
There was a problem hiding this comment.
CRITICAL SECURITY REGRESSION: The origin validation check has been removed from the link preview API endpoint. This removes CSRF protection and opens the endpoint to abuse from any origin, enabling potential SSRF attacks, internal network scanning, and rate limit bypass. This reverses the security improvement that was previously implemented.
Confidence: 5/5
Suggested Fix
| export async function GET(request: NextRequest) { | |
| export async function GET(request: NextRequest) { | |
| if (!isAllowedOrigin(request)) { | |
| return NextResponse.json({ error: "forbidden" }, { status: 403 }); | |
| } | |
| const { searchParams } = new URL(request.url); | |
Restore the origin validation check that was removed. This is essential for:
- CSRF Protection: Prevents malicious sites from using your API
- SSRF Prevention: Limits who can trigger server-side requests
- Rate Limit Protection: Prevents abuse from unauthorized origins
- Resource Protection: Ensures only your application can use this endpoint
If the origin check was removed intentionally, you MUST implement alternative security measures such as:
- API key authentication
- Rate limiting per IP address
- Strict URL allowlist validation
- Request signing/HMAC verification
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In app/api/link-preview/route.ts on line 86, the origin validation check (isAllowedOrigin) has been removed from the GET handler, creating a critical security vulnerability by allowing any origin to call this API endpoint and potentially exploit it for SSRF attacks or internal network scanning; restore the origin validation check by adding back the if (!isAllowedOrigin(request)) { return NextResponse.json({ error: "forbidden" }, { status: 403 }); } block immediately after the function declaration and before processing the request, or if this was intentionally removed, implement alternative security measures such as API key authentication, strict rate limiting, and URL allowlist validation.
Summary by BeetleThis PR integrates Vercel Analytics into the Next.js application to enable real-time web analytics tracking. The change adds the official Vercel Analytics package and incorporates the 📁 File Changes Summary (Consolidated across all commits):
Total Changes: 3 files changed, +6 additions, -6 deletions 🗺️ Walkthrough:graph TD
A["Next.js Application Root Layout"] --> B["Import Analytics Component"]
B --> C["@vercel/analytics/next"]
A --> D["Render Application Structure"]
D --> E["Navbar Component"]
D --> F["Main Content Children"]
D --> G["Footer Component"]
D --> H["Analytics Component"]
H --> I["Track Page Views"]
H --> J["Monitor User Interactions"]
H --> K["Collect Performance Metrics"]
I --> L["Vercel Analytics Dashboard"]
J --> L
K --> L
style H fill:#4CAF50,stroke:#2E7D32,color:#fff
style L fill:#00BCD4,stroke:#0097A7,color:#fff
🎯 Key Changes:
📊 Impact Assessment:
⚙️ SettingsSeverity Threshold: 📖 User Guide
|
| - **Community guides** — practical walkthroughs for setting up bots, moderation, and server tooling | ||
| - **Dev culture stuff** — takes on tools, workflows, and things happening in the wider Discord dev ecosystem | ||
|
|
||
| > [!NOTE] Got a topic you want covered? Use the `/suggest` command in Panda to send it our way. Or if you'd rather write it yourself, fork [open-devhub/website](/r/website), add your article under `/content/articles/`, and open a PR — articles here are written by the people building DevHub, so community input actually shapes what gets published. |
There was a problem hiding this comment.
The GitHub repository link has been changed from an absolute URL (https://github.com/open-devhub/website) to a relative path (/r/website), but there's no evidence that a /r/website route exists in this application. This breaks the user flow for forking the repository, as clicking this link will likely result in a 404 error instead of directing users to the GitHub repository.
Confidence: 5/5
Suggested Fix
| > [!NOTE] Got a topic you want covered? Use the `/suggest` command in Panda to send it our way. Or if you'd rather write it yourself, fork [open-devhub/website](/r/website), add your article under `/content/articles/`, and open a PR — articles here are written by the people building DevHub, so community input actually shapes what gets published. | |
| > [!NOTE] Got a topic you want covered? Use the `/suggest` command in Panda to send it our way. Or if you'd rather write it yourself, fork [open-devhub/website](https://github.com/open-devhub/website), add your article under `/content/articles/`, and open a PR — articles here are written by the people building DevHub, so community input actually shapes what gets published. | |
Revert to the original absolute GitHub URL. If you intended to create a redirect route at /r/website, ensure that:
- The route is implemented in the application
- It properly redirects to
https://github.com/open-devhub/website - The redirect is tested and functional
Alternatively, if you want to use a shorter internal link, implement a proper redirect handler first before changing the markdown content.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In content/articles/coming-soon.md on line 22, the GitHub repository link has been changed from an absolute URL (https://github.com/open-devhub/website) to a relative path (/r/website), but this relative path likely doesn't exist as a route in the application and will result in a 404 error when users try to fork the repository; revert the link back to the absolute GitHub URL https://github.com/open-devhub/website to restore the proper user flow, or if you intended to create a redirect route, implement the /r/website route handler first before changing the markdown content.
| - Language and framework-specific channels | ||
| - Career and job hunting channels. | ||
| - An active [open source org](https://github.com/open-devhub) on GitHub. | ||
| - An active [open source org](/github) on GitHub. |
There was a problem hiding this comment.
The GitHub organization link has been changed from an absolute URL (https://github.com/open-devhub) to a relative path (/github), but there's no evidence that a /github route exists in this application. This will likely result in a 404 error when users try to access the GitHub organization, breaking the user flow for discovering and contributing to open source projects.
Confidence: 5/5
Suggested Fix
| - An active [open source org](/github) on GitHub. | |
| - An active [open source org](https://github.com/open-devhub) on GitHub. | |
Revert to the original absolute GitHub URL. If you intended to create a redirect route at /github, ensure that:
- The route is implemented in the application (e.g., in
app/github/route.tsor similar) - It properly redirects to
https://github.com/open-devhub - The redirect is tested and functional before changing the markdown content
Alternatively, if this is part of a broader URL shortening strategy (similar to the/r/websitepattern in Comment feat: reorder pages #15), implement the redirect infrastructure first before updating the content.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In content/pages/community/join-guide.md on line 22, the GitHub organization link has been changed from an absolute URL (https://github.com/open-devhub) to a relative path (/github), but this relative path likely doesn't exist as a route in the application and will result in a 404 error when users try to access the GitHub organization; revert the link back to the absolute GitHub URL https://github.com/open-devhub to restore the proper user flow, or if you intended to create a redirect route, implement the /github route handler first (e.g., in app/github/route.ts with a redirect to the GitHub org) before changing the markdown content.
| ## Scope | ||
|
|
||
| This policy covers all repositories under the [DevHub GitHub org](https://github.com/open-devhub). It does not cover the Discord server itself (that's governed by Discord's own security processes) or third-party bots. | ||
| This policy covers all repositories under the [DevHub GitHub org](/github). It does not cover the Discord server itself (that's governed by Discord's own security processes) or third-party bots. |
There was a problem hiding this comment.
Same issue as Comment #15 - the GitHub organization link has been changed from an absolute URL to a relative path /github, which will likely result in a 404 error when users try to access the DevHub GitHub organization from the security notice page.
Confidence: 5/5
Suggested Fix
| This policy covers all repositories under the [DevHub GitHub org](/github). It does not cover the Discord server itself (that's governed by Discord's own security processes) or third-party bots. | |
| This policy covers all repositories under the [DevHub GitHub org](https://github.com/open-devhub). It does not cover the Discord server itself (that's governed by Discord's own security processes) or third-party bots. | |
Revert to the absolute GitHub URL. If /github is intended as a redirect route, implement it first before updating the markdown content.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In content/pages/legal/security-notice.md on line 38, the GitHub organization link has been changed from https://github.com/open-devhub to a relative path /github which will cause a 404 error; revert the link back to the absolute GitHub URL https://github.com/open-devhub, or if you're implementing a redirect system, create the /github route handler first before changing the markdown content.
|
✅ You're good to merge this PR! No issues found. Great job! Settings⚙️ SettingsSeverity Threshold: 📖 User Guide
|
|
|
||
| - Answer questions asked in channels and threads | ||
| - Review pull requests in our [GitHub org](https://github.com/open-devhub) | ||
| - Review pull requests in our [GitHub org](/github) |
There was a problem hiding this comment.
Same issue as Comment #14 - the GitHub organization link has been changed to a relative path /github which will likely cause a 404 error. This breaks the user flow for contributors trying to review pull requests.
Confidence: 5/5
Suggested Fix
| - Review pull requests in our [GitHub org](/github) | |
| - Review pull requests in our [GitHub org](https://github.com/open-devhub) | |
Revert to the absolute GitHub URL, or ensure the /github redirect route is implemented and functional before deploying this change.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In content/pages/open-source/contributing.md on line 15, the GitHub organization link has been changed from https://github.com/open-devhub to /github which will cause a 404 error; revert it back to the absolute URL https://github.com/open-devhub, or if implementing a redirect system, create the /github route handler first before changing the markdown content.
| ## Code Contributions | ||
|
|
||
| All DevHub projects live in the [GitHub org](https://github.com/open-devhub). To contribute code, fork the repo, make your changes on a feature branch, and open a PR. Include a clear description of what you changed and why. | ||
| All DevHub projects live in the [GitHub org](/github). To contribute code, fork the repo, make your changes on a feature branch, and open a PR. Include a clear description of what you changed and why. |
There was a problem hiding this comment.
Same issue as Comment #14 - duplicate /github relative path that will cause a 404 error when contributors try to access the GitHub organization.
Confidence: 5/5
Suggested Fix
| All DevHub projects live in the [GitHub org](/github). To contribute code, fork the repo, make your changes on a feature branch, and open a PR. Include a clear description of what you changed and why. | |
| All DevHub projects live in the [GitHub org](https://github.com/open-devhub). To contribute code, fork the repo, make your changes on a feature branch, and open a PR. Include a clear description of what you changed and why. | |
Revert to the absolute GitHub URL.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In content/pages/open-source/contributing.md on line 24, the GitHub organization link uses /github which will cause a 404 error; revert it to https://github.com/open-devhub to restore proper navigation for contributors.
| ## Documentation Contributions | ||
|
|
||
| [Docs](/pages) and [resources](/resources) are in the [website repo](https://github.com/open-devhub/website). If you find something confusing, out of date, or just missing, fix it. Small improvements compound into something really good over time. | ||
| [Docs](/pages) and [resources](/resources) are in the [website repo](/r/website). If you find something confusing, out of date, or just missing, fix it. Small improvements compound into something really good over time. |
There was a problem hiding this comment.
Same issue as Comment #13 - the website repository link has been changed to /r/website which will likely cause a 404 error when contributors try to access the repository for documentation contributions.
Confidence: 5/5
Suggested Fix
| [Docs](/pages) and [resources](/resources) are in the [website repo](/r/website). If you find something confusing, out of date, or just missing, fix it. Small improvements compound into something really good over time. | |
| [Docs](/pages) and [resources](/resources) are in the [website repo](https://github.com/open-devhub/website). If you find something confusing, out of date, or just missing, fix it. Small improvements compound into something really good over time. | |
Revert to the absolute GitHub URL, or ensure the /r/website redirect route is implemented and functional before deploying this change.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In content/pages/open-source/contributing.md on line 57, the website repository link has been changed to /r/website which will cause a 404 error; revert it to https://github.com/open-devhub/website, or if implementing a redirect system, create the /r/website route handler first before changing the markdown content.
| --- | ||
|
|
||
| The [DevHub GitHub org](https://github.com/open-devhub) is where community members build things together. It's not a showcase of finished work, it's an active space where contributors open issues, review PRs, and ship real software. | ||
| The [DevHub GitHub org](/github) is where community members build things together. It's not a showcase of finished work, it's an active space where contributors open issues, review PRs, and ship real software. |
There was a problem hiding this comment.
Same issue as Comments #11, #12, #13, #14 - the GitHub organization link has been changed from an absolute URL to a relative path /github which will cause a 404 error when users try to access the GitHub organization. See Comment #11 for full details.
Confidence: 5/5
Suggested Fix
| The [DevHub GitHub org](/github) is where community members build things together. It's not a showcase of finished work, it's an active space where contributors open issues, review PRs, and ship real software. | |
| The [DevHub GitHub org](https://github.com/open-devhub) is where community members build things together. It's not a showcase of finished work, it's an active space where contributors open issues, review PRs, and ship real software. | |
Revert to the absolute GitHub URL, or implement the /github redirect route first before deploying this change.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In content/pages/open-source/github-org.md on line 10, the GitHub organization link has been changed from https://github.com/open-devhub to /github which will cause a 404 error; revert it to the absolute URL https://github.com/open-devhub, or if implementing a redirect system, create the /github route handler first before changing the markdown content.
| --- | ||
|
|
||
| These guidelines apply to all projects under the [DevHub GitHub org](https://github.com/open-devhub). They're not bureaucracy, they're the things that make a project maintainable by multiple people over time. | ||
| These guidelines apply to all projects under the [DevHub GitHub org](/github). They're not bureaucracy, they're the things that make a project maintainable by multiple people over time. |
There was a problem hiding this comment.
Same issue as Comments #10, #11, #12, #13, and #15 - the GitHub organization link has been changed from an absolute URL (https://github.com/open-devhub) to a relative path (/github) which will cause a 404 error unless a redirect route is implemented. See Comment #10 for full details and fix guidance.
Confidence: 5/5
Suggested Fix
| These guidelines apply to all projects under the [DevHub GitHub org](/github). They're not bureaucracy, they're the things that make a project maintainable by multiple people over time. | |
| These guidelines apply to all projects under the [DevHub GitHub org](https://github.com/open-devhub). They're not bureaucracy, they're the things that make a project maintainable by multiple people over time. | |
Revert to the absolute GitHub URL, or implement the /github redirect route first before deploying this change.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In content/pages/open-source/project-guidelines.md on line 10, the GitHub organization link has been changed from https://github.com/open-devhub to /github which will cause a 404 error; revert it to the absolute URL https://github.com/open-devhub, or if implementing a redirect system, create the /github route handler first before changing the markdown content.
| --- | ||
|
|
||
| Built something useful? We'd love to help it reach more people. There are a few different ways to get your project connected with the [DevHub community](https://github.com/open-devhub). | ||
| Built something useful? We'd love to help it reach more people. There are a few different ways to get your project connected with the [DevHub community](/github). |
There was a problem hiding this comment.
Same issue as Comments #9, #10, #11, #12, #14, #15 - the GitHub organization link has been changed from an absolute URL to a relative path /github which will cause a 404 error unless a redirect route is implemented. See those comments for full details.
Confidence: 5/5
Suggested Fix
| Built something useful? We'd love to help it reach more people. There are a few different ways to get your project connected with the [DevHub community](/github). | |
| Built something useful? We'd love to help it reach more people. There are a few different ways to get your project connected with the [DevHub community](https://github.com/open-devhub). | |
Revert to the absolute GitHub URL.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In content/pages/open-source/submit-project.md on line 10, the GitHub organization link has been changed from https://github.com/open-devhub to /github which will cause a 404 error; revert it to the absolute URL https://github.com/open-devhub, or if implementing a redirect system, create the /github route handler first before changing the markdown content.
|
|
||
| - Feature Listing, We promote your personal project in this website. You keep full ownership. | ||
| - Org Transfer, Your project moves under the [DevHub GitHub org](https://github.com/open-devhub), and you'll be given admin rights over it (eg. [chorddb](https://github.com/open-devhub/chorddb) was built and transferred by [@imiakk](https://github.com/imiakk)). Community maintainers help keep it active. Good for projects you want to outlive your direct involvement. | ||
| - Org Transfer, Your project moves under the [DevHub GitHub org](/github), and you'll be given admin rights over it (eg. [chorddb](/r/chorddb) was built and transferred by [@imiakk](https://github.com/imiakk)). Community maintainers help keep it active. Good for projects you want to outlive your direct involvement. |
There was a problem hiding this comment.
Same issue as previous comments - two URLs changed to relative paths (/github and /r/chorddb) that will likely cause 404 errors. The /github pattern is addressed in Comments #9-15, and the /r/ pattern is addressed in Comments #8, #13.
Confidence: 5/5
Suggested Fix
| - Org Transfer, Your project moves under the [DevHub GitHub org](/github), and you'll be given admin rights over it (eg. [chorddb](/r/chorddb) was built and transferred by [@imiakk](https://github.com/imiakk)). Community maintainers help keep it active. Good for projects you want to outlive your direct involvement. | |
| - Org Transfer, Your project moves under the [DevHub GitHub org](https://github.com/open-devhub), and you'll be given admin rights over it (eg. [chorddb](https://github.com/open-devhub/chorddb) was built and transferred by [@imiakk](https://github.com/imiakk)). Community maintainers help keep it active. Good for projects you want to outlive your direct involvement. | |
Revert both URLs to their absolute GitHub URLs.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In content/pages/open-source/submit-project.md on line 15, two GitHub URLs have been changed to relative paths (/github and /r/chorddb) which will cause 404 errors; revert them to their absolute URLs https://github.com/open-devhub and https://github.com/open-devhub/chorddb respectively, or if implementing a redirect system, create the route handlers first before changing the markdown content.
| 2. Community members can react and comment under the suggestion thread. | ||
| 3. The admin team reviews the proposal, checks the project against the criteria, and votes internally. | ||
| 4. If approved, the project is added to the [website](/) and/or [GitHub org](https://github.com/open-devhub). The submitter is credited in the announcement. | ||
| 4. If approved, the project is added to the [website](/) and/or [GitHub org](/github). The submitter is credited in the announcement. |
There was a problem hiding this comment.
Same issue as Comments #9-15 - the GitHub organization link changed to /github relative path. See those comments for full details.
Confidence: 5/5
Suggested Fix
| 4. If approved, the project is added to the [website](/) and/or [GitHub org](/github). The submitter is credited in the announcement. | |
| 4. If approved, the project is added to the [website](/) and/or [GitHub org](https://github.com/open-devhub). The submitter is credited in the announcement. | |
Revert to the absolute GitHub URL.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In content/pages/open-source/submit-project.md on line 29, the GitHub organization link has been changed from https://github.com/open-devhub to /github which will cause a 404 error; revert it to the absolute URL https://github.com/open-devhub, or if implementing a redirect system, create the /github route handler first before changing the markdown content.
|
Note Linting checks passed successfully 🎉 All formatting and code quality checks are clean. You're good to merge 🚀 |
| alt={article.title} | ||
| fill | ||
| className="object-cover transition-transform duration-500 group-hover:scale-105" | ||
| unoptimized={article.banner.startsWith("http")} |
There was a problem hiding this comment.
The unoptimized={article.banner.startsWith("http")} prop disables Next.js image optimization for all external images, which defeats the purpose of migrating from <img> to <Image>. This causes performance issues: external images won't be resized, compressed, or converted to modern formats (WebP/AVIF), resulting in larger file sizes and slower page loads.
Confidence: 5/5
Suggested Fix
Instead of disabling optimization for external images, configure Next.js to allow external image optimization. Remove the unoptimized prop and add the external domains to your next.config.js:
// next.config.js
module.exports = {
images: {
remotePatterns: [
{
protocol: 'https',
hostname: '**', // Or specify exact domains for better security
},
],
},
}Then update the component to remove the unoptimized prop:
| unoptimized={article.banner.startsWith("http")} | |
| <Image | |
| src={article.banner} | |
| alt={article.title} | |
| fill | |
| className="object-cover transition-transform duration-500 group-hover:scale-105" | |
| /> | |
This allows Next.js to optimize all images (both local and external) while maintaining security through the remotePatterns configuration. If you need to support arbitrary external URLs, use hostname: '**', but for better security, explicitly list the allowed domains.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In app/articles/ArticlesListingClient.tsx on line 224, the unoptimized prop is set to true for all external images (those starting with "http"), which disables Next.js image optimization and causes performance issues by serving large unoptimized images; remove the unoptimized prop from the Image component and instead configure next.config.js to allow external image optimization by adding a remotePatterns configuration with the appropriate hostname patterns (either specific domains or '**' for all domains), ensuring all images benefit from Next.js's automatic optimization, resizing, and modern format conversion.
| maxHeight: "480px", | ||
| border: `1px solid ${indigo(0.12)}`, | ||
| }} | ||
| unoptimized={block.src?.startsWith("http")} |
There was a problem hiding this comment.
Same issue as Comment #15 - the unoptimized prop disables Next.js image optimization for all external images in content blocks. This causes performance degradation by serving large, unoptimized images without resizing, compression, or modern format conversion (WebP/AVIF).
Confidence: 5/5
Suggested Fix
Remove the unoptimized prop and configure next.config.js to allow external image optimization (see Comment #15 for the next.config.js configuration):
| unoptimized={block.src?.startsWith("http")} | |
| unoptimized={block.src?.startsWith("http")} | |
Delete this line entirely. After configuring remotePatterns in next.config.js, Next.js will automatically optimize all images (both local and external) while maintaining security.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In app/articles/[slug]/ArticleClient.tsx on line 330, remove the unoptimized prop that disables Next.js image optimization for external images in content blocks; instead, configure next.config.js with remotePatterns to allow external image optimization (see Comment #15 for the exact configuration), ensuring all markdown-rendered images benefit from automatic optimization, resizing, and modern format conversion regardless of whether they're local or external URLs.
| fill | ||
| className="object-cover px-6" | ||
| style={{ maxHeight: "260px" }} | ||
| unoptimized={article.banner.startsWith("http")} |
There was a problem hiding this comment.
Same issue as Comment #15 - the unoptimized prop disables Next.js image optimization for external article banner images. This is particularly problematic for banner images which are prominently displayed and significantly impact page load performance.
Confidence: 5/5
Suggested Fix
Remove the unoptimized prop and rely on the next.config.js configuration (see Comment #15):
| unoptimized={article.banner.startsWith("http")} | |
| unoptimized={article.banner.startsWith("http")} | |
Delete this line entirely. With proper remotePatterns configuration in next.config.js, Next.js will optimize all banner images automatically.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In app/articles/[slug]/ArticleClient.tsx on line 406, remove the unoptimized prop that disables Next.js image optimization for external article banner images; instead, rely on the remotePatterns configuration in next.config.js (see Comment #15 for setup details), ensuring banner images are automatically optimized for better page load performance regardless of whether they're hosted locally or externally.
| const pageOrder = new Map<string, number>(); | ||
| sidebarPageSections.forEach((section, sectionIndex) => { | ||
| section.pages.forEach((page, pageIndex) => { | ||
| pageOrder.set( | ||
| `${section.title}:${page.slug}`, | ||
| sectionIndex * 1000 + pageIndex, | ||
| ); | ||
| }); | ||
| }); |
There was a problem hiding this comment.
The pageOrder Map uses section.title from sidebarPageSections as part of the key (line 91), but the lookup later uses a.section and b.section from the page objects (lines 106-107). If the section titles in the sidebar configuration don't exactly match the section property in the page objects (e.g., different casing, spacing, or naming conventions), the lookup will fail and pages won't be found in the Map. This will cause pages to fall back to alphabetical sorting instead of respecting the intended sidebar order, breaking the page ordering feature.
Confidence: 4/5
Suggested Fix
Verify that section.title from sidebarPageSections exactly matches the section property in page objects. If they might differ, you should either:
- Normalize the keys by using a consistent property (e.g., use
section.slugif available in both places) - Add validation to ensure the keys match
- Use only the slug as the key if section matching is guaranteed by the file structure
Example fix using only slug as the key:
| const pageOrder = new Map<string, number>(); | |
| sidebarPageSections.forEach((section, sectionIndex) => { | |
| section.pages.forEach((page, pageIndex) => { | |
| pageOrder.set( | |
| `${section.title}:${page.slug}`, | |
| sectionIndex * 1000 + pageIndex, | |
| ); | |
| }); | |
| }); | |
| const pageOrder = new Map<string, number>(); | |
| sidebarPageSections.forEach((section, sectionIndex) => { | |
| section.pages.forEach((page, pageIndex) => { | |
| pageOrder.set( | |
| page.slug, | |
| sectionIndex * 1000 + pageIndex, | |
| ); | |
| }); | |
Then update the lookup to use only the slug:
// Later in the sort function (lines 106-109)
const aPosition = pageOrder.get(a.slug);
const bPosition = pageOrder.get(b.slug);This approach is simpler and avoids the section title mismatch issue, assuming page slugs are unique across all sections. If slugs might collide across sections, keep the composite key but ensure the section identifier is consistent between the sidebar config and page objects.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In content/pages-loader.ts around lines 87-95, the pageOrder Map construction uses section.title from sidebarPageSections as part of the composite key (line 91), but the lookup later uses a.section and b.section from page objects (lines 106-107), which may not match if the section naming differs between the sidebar configuration and the page metadata; verify that these section identifiers match exactly, or simplify the key to use only page.slug (assuming slugs are unique) by changing line 91 to just pageOrder.set(page.slug, sectionIndex * 1000 + pageIndex) and updating lines 108-109 to use pageOrder.get(a.slug) and pageOrder.get(b.slug), ensuring the page ordering feature works correctly.
📍 This suggestion applies to lines 87-95
1 participant
/articlespage (placeholder content)