Added Advance guide doc

docs/advanced/architecture.mdx

@@ -0,0 +1,102 @@
+---
+title: Architecture
+description: "How CodeHarborHub’s documentation engine and architecture work together to build your site"
+---
+
+```mdx-code-block
+import Zoom from 'react-medium-image-zoom';
+import 'react-medium-image-zoom/dist/styles.css';
+```
+
+<Zoom>
+
+![Architecture overview](/img/architecture.png)
+
+</Zoom>
+
+This diagram explains how **CodeHarborHub’s documentation system** (powered by Docusaurus) works under the hood to build and serve your learning platform. Each **plugin** is responsible for collecting and processing content (like docs, tutorials, or blogs) and emitting structured JSON data.  
+
+The **themes** provide the layout and UI components that transform this JSON data into dynamic, interactive web pages.
+
+The **bundler** then takes care of packaging everything—building both the **server** and **client** bundles that power the entire site experience.
+
+---
+
+## Key Architectural Layers
+
+### 1. Plugin Layer
+
+Plugins manage content and configuration. Each plugin runs entirely in **Node.js**, processing Markdown, MDX, and metadata into structured JSON.  
+
+For example:
+- The **Docs Plugin** gathers all your course and guide files.  
+- The **Blog Plugin** handles educational blog content.  
+- The **Pages Plugin** renders custom pages like `/about`, `/events`, or `/community`.
+
+All plugin lifecycle methods run in **Node**. That means plugin code must be written in **CommonJS** (using `require`) or **ES Modules** (using `import/export`) that Node can execute.
+
+---
+
+### 2. Theme Layer
+
+Themes define how the content looks and feels. Theme components are written in **React**, built with **Webpack**, and rendered on the client side.  
+
+They receive the JSON output from plugins and render them as complete pages—  
+such as documentation layouts, course cards, contributor profiles, and interactive learning modules.
+
+**Themes and plugins don’t directly import or depend on each other.**  
+They communicate through **JSON data** and **route configuration**, ensuring modularity and scalability.
+
+A useful way to think about it:
+> Imagine plugins are written in another language (like Rust or Go) — they just output structured data.  
+> The theme is the visual layer that interprets and displays that data beautifully.
+
+---
+
+### 3. Configuration Layer
+
+Your `docusaurus.config.js` (or `docusaurus.config.mjs`) connects everything.
+
+It runs in **Node.js** and defines:
+- Global settings like `title`, `url`, `baseUrl`, and `favicon`
+- Plugin and theme configurations
+- Site metadata, SEO tags, and integration settings
+
+You can pass callbacks or dynamic logic to plugins here.  
+However, only **serializable values** (those that survive `JSON.stringify()`) make it to the client.
+
+This means:
+- ✅ Strings, numbers, arrays, and objects are preserved  
+- ⚠️ Functions, regexes, and complex data structures are lost in the browser bundle
+
+During bundling, the configuration file is serialized and injected into the client bundle, allowing the site to access global data via:
+
+```js
+import { useDocusaurusContext } from '@docusaurus/core';
+
+const { siteConfig } = useDocusaurusContext();
+console.log(siteConfig.themeConfig);
+```
+
+---
+
+## Summary of the Build Process
+
+| Stage | Environment | Responsibility |
+|--------|--------------|----------------|
+| **Plugins** | Node.js | Collect content and generate JSON data |
+| **Themes** | Browser + Webpack | Render JSON data into UI components |
+| **Bundler** | Build (Webpack/Vite) | Output optimized server and client bundles |
+| **Config** | Node.js | Define site structure and plugin options |
+
+---
+
+## Why This Matters for CodeHarborHub
+
+This architecture allows CodeHarborHub to be:
+- ⚡ **Fast and modular** — each content type (Docs, Blogs, Events) acts independently  
+- 🧠 **Extensible** — easily add new learning modules or plugins  
+- 🌐 **Universal** — supports versioning, localization, and custom themes  
+- 🔒 **Safe and scalable** — clean separation between content, configuration, and rendering
+
+---

docs/advanced/client.mdx

@@ -0,0 +1,197 @@
+---
+title: Client Architecture
+description: Understanding how the CodeHarborHub client system works
+---
+
+The **client architecture** of CodeHarborHub (built on Docusaurus) defines how the front-end interacts with React components, themes, and client-side modules. It focuses on modularity, performance, and extensibility — allowing you to customize your learning platform’s UI and logic.
+
+---
+
+## Theme Aliases {#theme-aliases}
+
+Themes in CodeHarborHub work by exporting a set of **React components** such as `Navbar`, `Layout`, and `Footer`. These components render structured data provided by plugins.  
+
+They are imported using the Webpack alias `@theme`:
+
+```js
+import Navbar from '@theme/Navbar';
+```
+
+### How it works
+
+The `@theme` alias points to several possible directories in this order of priority:
+
+1. `website/src/theme` — The **user’s custom theme directory** (highest priority).  
+2. `node_modules/@docusaurus/theme-*` — Theme package components.  
+3. Core fallback components provided by Docusaurus (least used).  
+
+This creates a **layered architecture** — higher layers override lower ones.  
+For example:
+
+```
+website
+├── node_modules
+│   └── @docusaurus/theme-classic
+│       └── theme
+│           └── Navbar.js
+└── src
+    └── theme
+        └── Navbar.js
+```
+
+Here, `website/src/theme/Navbar.js` takes precedence whenever you import `@theme/Navbar`. This concept is known as **swizzling** — overriding or extending existing components.
+
+### Wrapping and Extending Components
+
+If you want to extend a theme component instead of replacing it, use:
+
+- `@theme-original` — Imports the next component down the stack.
+- `@theme-init` — Imports the base implementation from the original theme.
+
+Example: enhancing a `CodeBlock` component with a live playground:
+
+```js
+import InitialCodeBlock from '@theme-init/CodeBlock';
+import React from 'react';
+import ReactLivePlayground from '@theme/ReactLivePlayground';
+
+export default function CodeBlock(props) {
+  return props.live ? (
+    <ReactLivePlayground {...props} />
+  ) : (
+    <InitialCodeBlock {...props} />
+  );
+}
+```
+
+:::warning
+Unless you’re building a reusable theme (like `@docusaurus/theme-live-codeblock`), you won’t usually need `@theme-init`.
+:::
+
+### Visualization of Theme Stack
+
+Internally, CodeHarborHub loads components as a “stack” of layers:
+
+```text
++-------------------------------------------------+
+|        website/src/theme/CodeBlock.js           | <-- @theme/CodeBlock
++-------------------------------------------------+
+| theme-live-codeblock/theme/CodeBlock/index.js   | <-- @theme-original/CodeBlock
++-------------------------------------------------+
+| plugin-awesome-codeblock/theme/CodeBlock.js     |
++-------------------------------------------------+
+| theme-classic/theme/CodeBlock/index.js          | <-- @theme-init/CodeBlock
++-------------------------------------------------+
+```
+
+The **site layer** (`src/theme`) always takes precedence since it’s loaded last.
+
+---
+
+## Client Modules {#client-modules}
+
+Client modules are **global scripts or styles** that run before React renders your site. They include JS and CSS that modify global state, register event listeners, or add global styling.
+
+Under the hood:
+
+```js title="@docusaurus/core/App.tsx"
+import '@generated/client-modules';
+```
+
+### Declaring Client Modules
+
+Plugins and sites can declare client modules using:
+
+- [`getClientModules`](https://docusaurus.io/docs/api/plugin-methods/lifecycle-apis#getClientModules)
+- [`siteConfig.clientModules`](https://docusaurus.io/docs/api/docusaurus-config#clientModules)
+
+These modules are imported globally and executed both during server-side rendering (SSR) and client-side hydration.
+
+Example of a client-side script:
+
+```js title="mySiteGlobalJs.js"
+import ExecutionEnvironment from '@docusaurus/ExecutionEnvironment';
+
+if (ExecutionEnvironment.canUseDOM) {
+  window.addEventListener('keydown', (e) => {
+    if (e.code === 'Period') {
+      location.assign(location.href.replace('.com', '.dev'));
+    }
+  });
+}
+```
+
+Example of global CSS:
+
+```css title="mySiteGlobalCss.css"
+/* Global stylesheet */
+.globalSelector {
+  color: #007bff;
+  font-weight: bold;
+}
+```
+
+---
+
+## Client Module Lifecycles {#client-module-lifecycles}
+
+Client modules can define **lifecycle functions** to handle route transitions in your single-page app (SPA).
+
+### Available Lifecycle Methods
+
+- `onRouteUpdate`: triggered when navigation starts  
+- `onRouteDidUpdate`: triggered after the new route has rendered  
+
+These functions receive `{ location, previousLocation }` as parameters.
+
+Example:
+
+```js title="myClientModule.js"
+export function onRouteDidUpdate({location, previousLocation}) {
+  if (location.pathname !== previousLocation?.pathname) {
+    const title = document.querySelector('h1');
+    if (title) title.innerText += ' 🚀';
+  }
+}
+
+export function onRouteUpdate({location, previousLocation}) {
+  if (location.pathname !== previousLocation?.pathname) {
+    const progress = setTimeout(() => {
+      nprogress.start();
+    }, 200);
+    return () => clearTimeout(progress);
+  }
+}
+```
+
+TypeScript version:
+
+```ts title="myClientModule.ts"
+import type {ClientModule} from '@docusaurus/types';
+
+const module: ClientModule = {
+  onRouteUpdate({location, previousLocation}) {
+    // Custom navigation logic
+  },
+  onRouteDidUpdate({location, previousLocation}) {
+    // DOM manipulations or analytics
+  },
+};
+
+export default module;
+```
+
+Both lifecycles run on the **client side only** and are safe for accessing browser globals.
+
+---
+
+:::tip Prefer React-based Implementations
+
+If your feature depends on **state**, **hooks**, or **context**,  
+it’s better to use [component swizzling](https://docusaurus.io/docs/swizzling#wrapping) instead of client modules.  
+Client modules are ideal for simple global effects, not for complex UI logic.
+:::
+
+---
+
+By understanding **theme aliases** and **client modules**, you can fully control CodeHarborHub’s front-end architecture — blending flexibility, modular design, and smooth client-side experiences.

docs/advanced/index.mdx

@@ -0,0 +1,26 @@
+---
+title: Advanced Tutorials
+---
+
+Welcome to the **Advanced Tutorials** section of CodeHarborHub!  
+Here, we dive deeper into the architecture, performance optimization, and real-world integrations that power modern web applications.
+
+This section may not be as structured as the beginner guides, but it will cover advanced and practical topics including:
+
+- Advanced component architecture  
+- Plugin and theme development  
+- Performance and SEO optimization  
+- Deployment strategies  
+- Integrations with AI and backend services  
+
+```mdx-code-block
+import DocCardList from '@theme/DocCardList';
+
+<DocCardList />
+```
+
+We assume you’ve completed the fundamental guides and understand the basics — such as configuring plugins, writing React components, and structuring Docusaurus pages.
+
+These tutorials are designed for **plugin authors**, **core contributors**, and **advanced developers**, so you’ll occasionally see references to internal APIs or low-level architecture details.  
+
+Don’t worry if everything doesn’t click right away — take your time, experiment, and explore! 🚀