Cloudflare صفحات پر Astro SSR کا استعمال کرتے ہوئے بغیر ہیڈ لیس ورڈپریس فرنٹ اینڈ کیسے بنایا جائے۔

یہ ٹیوٹوریل دکھاتا ہے کہ ورڈپریس کو بغیر ہیڈ لیس CMS کے بطور Cloudflare پیجز پر تعینات Astro فرنٹ اینڈ کا استعمال کرتے ہوئے کیسے چلایا جائے۔

ایک پراجیکٹ کی ضرورت جس پر میں حال ہی میں کام کر رہا تھا ورڈپریس کو سائٹ کے پسدید کے طور پر استعمال کرنا تھا۔ مواد کا نظم و نسق، بلاگ پوسٹس، اور میڈیا سبھی ورڈپریس ایڈمن کے ذریعے سنبھالے گئے تھے۔ سامنے والا سرا کھلا ہوا تھا۔ یہ ایک تھیم، ٹیمپلیٹ، یا Elementor کے ذریعے اپنی مرضی کے مطابق کیا جا سکتا ہے۔

میں Elementor میں وہی نتائج حاصل کر سکتا تھا، لیکن یہ عمل سست اور برقرار رکھنا زیادہ مشکل ہوتا۔ ڈریگ اینڈ ڈراپ اس وقت تک کام کرتا ہے جب تک کہ ڈیزائن تیار نہ ہو جائے، اور ہر چھوٹی ایڈجسٹمنٹ میں ضرورت سے زیادہ وقت لگتا ہے۔

ایک مکمل اسٹیک ڈویلپر کے طور پر، میں تیزی سے اور صاف نتائج کے ساتھ کوڈ لکھنے میں کامیاب رہا ہوں۔ کلاڈ کوڈ جیسے ٹولز تکرار سائیکل کو زیادہ سخت بناتے ہیں۔ لہذا میں نے ورڈپریس کو بیک اینڈ کے طور پر استعمال کرنے اور کوڈ میں فرنٹ اینڈ کو الگ سے بنانے کی ضرورت کو برقرار رکھنے کا فیصلہ کیا۔

میں یہ بتانا چاہتا تھا کہ میں نے یہ کیسے کیا تاکہ اگر آپ کو ایسی ہی ضرورت کا سامنا ہو تو آپ آگے جانے کا راستہ جان سکیں۔

اس ٹیوٹوریل کے آخر میں آپ کے پاس ہوگا:

• سب ڈومین سے REST API کے ذریعے ورڈپریس انسٹالیشن مواد پیش کرتی ہے۔

• Astro SSR فرنٹ اینڈ جو روٹ ڈومین سے مواد پیش کرتا ہے۔

• ہر گٹ پش کلاؤڈ فلیئر پیجز کی تعیناتی کو متحرک کرتا ہے۔

• ہیڈ لیس ورڈپریس سیٹ اپ کے لیے سیکیورٹی میں اضافہ

• ڈرافٹ پوسٹ کا پیش نظارہ جو دونوں سسٹمز پر کام کرتا ہے۔

شرائط: آپ کو کمانڈ لائن کے ساتھ آرام دہ اور پرسکون ہونا چاہئے، ورڈپریس ایڈمن کے بارے میں بنیادی علم ہونا چاہئے، اور سادہ افعال کو پڑھنے اور لکھنے کے قابل ہونے کے لئے کافی جاوا اسکرپٹ کو جاننا چاہئے.

جاری رکھنے کے لیے آپ کو ورڈپریس انسٹالیشن، ایک GitHub اکاؤنٹ، اور Cloudflare اکاؤنٹ کی ضرورت ہوگی۔

انڈیکس

ہیڈ لیس ورڈپریس کیوں؟

ہیڈ لیس ورڈپریس مواد کے انتظام کو مواد کی ترسیل سے الگ کرتا ہے۔ ورڈپریس وہ کام کرتا رہتا ہے جو وہ اچھی طرح کرتا ہے: مواد کو اسٹور کرتا ہے اور ایڈیٹر کے موافق مینجمنٹ انٹرفیس فراہم کرتا ہے۔ علیحدہ فرنٹ اینڈ رینڈرنگ، روٹنگ اور کارکردگی کو ہینڈل کرتے ہیں۔

یہاں کچھ ایسے حالات ہیں جہاں یہ تقسیم ادا کرتی ہے:

• آپ کے مواد کی ٹیم ورڈپریس پر تربیت یافتہ ہے، اور انہیں کہیں اور منتقل کرنے سے ہر ایک کے لیے چیزیں سست ہو جائیں گی۔ ہیڈ لیس آپ کے ورک فلو کو محفوظ رکھتا ہے اور ایک جدید فرنٹ اینڈ فراہم کرتا ہے۔

• آپ کی سائٹ کو ایک ڈیزائن یا تعامل کے پیٹرن کی ضرورت ہے جو ورڈپریس تھیم یا صفحہ بنانے والے کے لیے فراہم کرنا مشکل ہے۔ حسب ضرورت ڈیش بورڈز، انٹرایکٹو ٹولز، ڈیٹا سے چلنے والے لے آؤٹ، یا ورڈپریس کے علاوہ APIs کے ساتھ انضمام سب یہاں موزوں ہیں۔

• آپ اپنے مواد کے نظم و نسق کو شروع سے دوبارہ بنائے بغیر ایج ڈیلیوری اور جدید ٹولز چاہتے ہیں۔ ورڈپریس مواد اور میڈیا کو اچھی طرح سے ہینڈل کرتا ہے۔ CDN کا JavaScript فرنٹ اینڈ ڈیلیوری کو اچھی طرح سے ہینڈل کرتا ہے۔ ہیڈ لیس دونوں پارٹیوں کو اپنا کام کرنے کی اجازت دیتا ہے۔

• آپ کو متعدد سطحوں پر ایک ہی مواد کی ضرورت ہے۔ ورڈپریس کو ایک بار انسٹال کریں اور آپ کی مارکیٹنگ سائٹ، موبائل ایپ، اور اندرونی ڈیش بورڈ اسی REST API کے ذریعے پیش کیے جائیں گے۔

ہیڈ لیس تمام سائٹس کے لیے موزوں نہیں ہے۔ اگر آپ کی سائٹ صرف ایک بروشر ہے، ایک شخص تمام ایڈمن کے کام کرتا ہے، یا آپ کے پاس دوسرے کوڈ بیس کو برقرار رکھنے کے لیے ڈویلپر کا وقت نہیں ہے، اسے چھوڑ دیں۔ ایک باقاعدہ ورڈپریس تھیم ایک بہتر جواب ہے۔

فن تعمیر

"سر کے بغیر” کی اصطلاح کا مطلب ہے ورڈپریس سے فرنٹ اینڈ ذمہ داریوں کو ہٹانا۔ دیکھنے والوں کو HTML صفحات بنانے اور پیش کرنے کے بجائے، WordPress صرف REST APIs کے ذریعے مواد کو اسٹور اور پیش کرتا ہے۔ ایک علیحدہ فرنٹ اینڈ فریم ورک (اس معاملے میں ایسٹرو) وہی دیکھتا ہے جو دیکھنے والا اصل میں دیکھتا ہے۔

جب کوئی وزیٹر صفحہ لوڈ کرتا ہے، تو درخواست Cloudflare پیجز تک پہنچ جاتی ہے، جو Astro سرورز چلاتا ہے۔ Astro متعلقہ مواد کو ورڈپریس سے REST API کے ذریعے کھینچتا ہے، HTML لکھتا ہے اور وزیٹر کو واپس کرتا ہے۔ ورڈپریس کبھی بھی آپ کے وزٹرز کے براؤزرز تک رسائی حاصل نہیں کرتا ہے۔

مواد کے ایڈیٹرز آپ کے CMS ذیلی ڈومین کے لیے ورڈپریس ایڈمن میں لاگ ان ہوتے ہیں۔ معمول کے مطابق مواد بنائیں، شائع کریں اور ان کا نظم کریں۔ جس لمحے آپ شائع کرتے ہیں، آپ کا مواد لائیو ظاہر ہوتا ہے۔ چونکہ Astro ہر درخواست کے لیے نیا ڈیٹا لاتا ہے، اس لیے دوبارہ تعمیر کا کوئی مرحلہ نہیں ہے۔

REST API ورڈپریس ورژن 4.7 کے بعد سے بلٹ ان ہے۔ کوئی گراف کیو ایل پلگ ان، ادا شدہ ہیڈ لیس CMS سروسز، یا اضافی انفراسٹرکچر کی ضرورت نہیں ہے۔

ایسٹرو کیوں؟

آپ یہاں Next.js، Nuxt یا SvelteKit بھی استعمال کر سکتے ہیں۔ تاہم، میں نے ایسٹرو کا انتخاب کیا کیونکہ اس کے ڈیفالٹس اس استعمال کے معاملے کے لیے موزوں ہیں۔

Astro اپنے اجزاء کو سادہ HTML میں مرتب کرتا ہے اور جاوا اسکرپٹ کو براؤزر کو بطور ڈیفالٹ پیش نہیں کرتا ہے۔ کلائنٹ سائڈ JavaScript صرف اس جگہ شامل کریں جہاں اس کی واضح ضرورت ہو۔

CMS پر مبنی سائٹس کے لیے، زیادہ تر صفحات کو کسی چیز کی ضرورت نہیں ہوتی ہے۔ ایس ایس آر موڈ کا مطلب ہے کہ ہر درخواست رن ٹائم کے وقت ورڈپریس سے نیا ڈیٹا کھینچتی ہے، اس لیے مواد کی تبدیلیاں دوبارہ تعمیر کیے بغیر فوری طور پر لاگو ہوتی ہیں۔ Cloudflare کے پاس بلڈ آؤٹ پٹ کو ہینڈل کرنے کے لیے ایک آفیشل اڈاپٹر ہے۔ Tailwind v4 بغیر کسی کنفیگریشن فائلوں کے Vite پلگ ان کے ذریعے ضم ہوتا ہے۔

اگر ورڈپریس کی ضرورت نہ ہوتی تو میں پے لوڈ CMS کے ساتھ Next.js استعمال کرتا۔ پے لوڈ اسی Next.js پروجیکٹ کے اندر TypeScript میں بنایا ہوا مکمل طور پر تشکیل شدہ CMS فراہم کرتا ہے، جو آپ کو پہلے دن سے اپنے مواد کے اسکیما پر زیادہ کنٹرول فراہم کرتا ہے۔ تاہم، ضرورت ورڈپریس تھی اور ورڈپریس REST API فرنٹ اینڈ کے لیے، Astro ایک تیز اور صاف ستھرا انتخاب ہے۔

انفراسٹرکچر سیٹ اپ

میری ترتیبات یہ ہیں: Namecheap سے ڈومینز، WordPress نے Hostinger سے مشترکہ ہوسٹنگ، اور Google Workspace ای میل۔ نیچے دیے گئے اقدامات کسی بھی میزبان پر لاگو ہوتے ہیں، چاہے cPanel یا hPanel کے ساتھ مشترکہ ہوسٹنگ ہو، Apache یا Nginx کے ساتھ VPS، یا خود نظم کردہ سرور۔

مرحلہ 1: اپنے DNS کو Cloudflare میں منتقل کریں۔

سب سے پہلے، آپ کو اپنے ڈومین کے نیم سرورز کو Cloudflare میں منتقل کرنے کی ضرورت ہے۔ یہ مفت DDoS تحفظ، SSL، اور اپنی مرضی کے ڈومین کو آپ کے Cloudflare صفحات سے منسلک کرنے کی صلاحیت فراہم کرتا ہے۔

سوئچ کرنے سے پہلے، یقینی بنائیں کہ تمام DNS ریکارڈز درست طریقے سے منتقل ہوئے ہیں، بشمول آپ کی ویب سائٹ A یا CNAME ریکارڈز۔ ای میل کے لیے، اپنے ای میل فراہم کنندہ کے ایڈمن پینل سے MX، SPF، DKIM، اور DMARC اقدار حاصل کریں اور انہیں پہلے Cloudflare DNS میں شامل کریں۔ بصورت دیگر، آپ کی ای میل پروپیگنڈے کے دوران رکاوٹ بن جائے گی۔

مرحلہ 2: ایک CMS ذیلی ڈومین بنائیں

ورڈپریس کو منتقل کریں۔ cms.yourdomain.com تو ایسٹرو کا روٹ ڈومین مفت ہے۔ Cloudflare DNS میں ایک ریکارڈ کی طرف اشارہ کرنا شامل کریں۔ cms سرور IP سے، یا CNAME سے اگر میزبان CDN میزبان نام استعمال کرتا ہے۔ پھر اسی ورڈپریس ڈائرکٹری کی طرف اشارہ کرتے ہوئے اپنے ہوسٹنگ پینل میں ایک ذیلی ڈومین بنائیں۔

ایک چیز جو لوگ یاد کرتے ہیں: Cloudflare اور آپ کی اصل کے درمیان کام کرنے کے لیے، آپ کے سرور کو اپنے SSL سرٹیفکیٹ کی ضرورت ہے۔ Cloudflare SSL کو کنارے پر ہینڈل کرتا ہے، لیکن اگر اصل میں سرٹیفکیٹ نہیں ہے، تو آپ کو 525 کی خرابی ملے گی۔

Hostinger اسے نئے ذیلی ڈومینز کے لیے خود بخود لاگو نہیں کرتا ہے۔ hPanel کے ذریعے دستی طور پر انسٹال کریں۔ cPanel کے لیے، Let’s Encrypt استعمال کریں۔ VPS کے لیے، Certbot استعمال کریں۔

ورڈپریس کو اپنے روٹ ڈومین سے ہٹانے کا مطلب ہے: /wp-admin چونکہ یہ اب آپ کے بنیادی ڈومین پر موجود نہیں ہے، اس لیے آپ کی نمائش کم ہو جائے گی۔ لیکن پہلے سے طے شدہ لاگ ان کا راستہ اب بھی ہے۔ /wp-admin ذیلی ڈومین میں۔ یہ پہلی چیز ہے جسے آپ کو تبدیل کرنے کی ضرورت ہے۔ اس بارے میں مزید معلومات کے لیے، آخر میں جاننے کے لیے اچھا سیکشن دیکھیں۔

ورڈپریس کنفیگریشن

ورڈپریس کو بتائیں کہ آپ سب ڈومین پر ہیں۔

میں wp-config.php"یہ بات ہے، ترمیم بند کرو!” تبصرہ:

define('WP_HOME',    'https://cms.yourdomain.com');
define('WP_SITEURL', 'https://cms.yourdomain.com');

موجودہ ورڈپریس ایڈمن یہاں واقع ہے: cms.yourdomain.com/wp-admin. روٹ ڈومین کے پرانے راستے کام کرنا چھوڑ دیتے ہیں۔ یہ جان بوجھ کر ہے۔

پلگ ان کا استعمال ضرور کریں: ری ڈائریکٹ اور پیش نظارہ

ورڈپریس میں درج ذیل فولڈرز ہیں: mu-plugins اندر wp-content. یہاں رکھی فائلوں کو پلگ ان سمجھا جاتا ہے جو استعمال کرنا ضروری ہے۔ وہ باقاعدہ پلگ ان سے پہلے درخواست پر خود بخود لوڈ ہو جاتے ہیں اور منتظم UI کے ذریعے انہیں فعال یا غیر فعال کرنے کا کوئی طریقہ نہیں ہے۔ یہ اس بات کو یقینی بنانے کے لیے ایک اچھی جگہ بناتا ہے کہ یہ حادثاتی طور پر بند نہ ہو جائے۔

بنانا wp-content/mu-plugins/headless-redirect.php:

post_type;
    return 'https://yourdomain.com/preview?type=" . (type . "&id=' . )post->ID . '&token=' . $token;
}, 10, 2);

کہ template_redirect کام اس وقت شروع ہوتا ہے جب ورڈپریس صفحہ کو رینڈر کرنے کی کوشش کرتا ہے۔ اگر وزیٹر لاگ ان نہیں ہے اور درخواست CMS ذیلی ڈومین پر ہے، تو اسے ڈیفالٹ فرنٹ اینڈ پر بھیج دیا جائے گا۔ لاگ ان ایڈیٹرز کو حسب معمول ایڈمنسٹریٹر کو بھیج دیا جائے گا۔ REST API درخواست کا ہدف /wp-json/... پاس نہ کرو template_redirect یہ بالکل متاثر نہیں ہوتا ہے۔

کہ preview_post_link فلٹرز تبدیل کرتے ہیں کہ جب کوئی ایڈیٹر کسی ڈرافٹ پوسٹ پر پیش نظارہ پر کلک کرتا ہے تو کیا ہوتا ہے۔ پہلے سے طے شدہ طور پر، ورڈپریس اپنی تھیم کا استعمال کرتے ہوئے پیش نظارہ کرتا ہے، جسے بغیر ہیڈ لیس سیٹنگز میں خالی کر دیا جاتا ہے۔

یہ فلٹر اس یو آر ایل کو ایسٹرو کی درخواست سے بدل دیتا ہے۔ /preview صفحہ پوسٹ ID، پوسٹ کی قسم، اور خفیہ ٹوکن پاس کرتا ہے۔ ایسٹرو پیش نظارہ صفحہ آپ کے ڈرافٹ کو REST API کے ذریعے بازیافت کرنے کے لیے ان اقدار کا استعمال کرتا ہے اور اسے بالکل ویسا ہی پیش کرتا ہے جیسا کہ یہ حقیقی وقت میں ظاہر ہوتا ہے۔

پلگ ان کی صفائی

اب وقت آگیا ہے کہ کسی بھی چیز کو ہٹا دیا جائے جو فرنٹ اینڈ کو پیش کرتا ہے، بشمول صفحہ بنانے والے، کیشنگ پلگ ان، ہوسٹنگ آن بورڈنگ پلگ ان وغیرہ۔

لیکن آپ Akismet، Wordfence، اور Yoast SEO کو رکھنا چاہیں گے۔ Yoast ایس ای او میٹا اور اوپن گراف ڈیٹا کو براہ راست REST API جوابات میں شامل کرتا ہے جسے Astro صفحات پڑھتے ہیں۔ post.yoast_head_json.

اس کے بعد یہ ایکٹو تھیم کو ہلکے وزن کے ڈیفالٹ میں بدل دیتا ہے۔ ورڈپریس کو ایک فعال اکاؤنٹ کی ضرورت ہے، لیکن کوئی بھی اسے نہیں دیکھ سکتا۔

ایسٹرو فرنٹ اینڈ

سے شروع کریں۔ pnpm create astro@latestCloudflare اڈاپٹر اور Tailwind پر کلک کریں اور انسٹال کریں۔

pnpm add @astrojs/cloudflare
pnpm add -D @tailwindcss/vite tailwindcss

astro.config.mjs

import { defineConfig } from 'astro/config'
import cloudflare from '@astrojs/cloudflare'
import tailwindcss from '@tailwindcss/vite'

export default defineConfig({
  output: 'server',
  adapter: cloudflare({ imageService: 'passthrough' }),
  vite: { plugins: [tailwindcss()] },
})

output: 'server' Astro کو مکمل SSR موڈ میں ڈالیں۔ اس کے بغیر، ایسٹرو اس طرح کے متحرک راستوں کو توڑتے ہوئے، تعمیراتی وقت پر صفحہ کو پہلے سے رینڈر کرے گا: /blog/[slug] یہ ورڈپریس مواد پر انحصار کرتا ہے جو تعمیر کے وقت موجود نہیں تھا۔

imageService: 'passthrough' Cloudflare کارکنوں کے لیے خاص طور پر درکار ہے۔ ایسٹرو کی ڈیفالٹ امیج سروس شارپ کا استعمال کرتی ہے۔ child_process اور fs. یہ Node.js مقامی خصوصیات Cloudflare ورکرز کے رن ٹائم میں موجود نہیں ہیں۔ ماڈیول کی توثیق کی خرابی کی وجہ سے تعیناتی ناکام ہو جاتی ہے۔ پاس تھرو فعال ہونے پر، امیج پروسیسنگ کو مکمل طور پر چھوڑ دیا جاتا ہے اور معیاری کے طور پر پیش کیا جاتا ہے۔ اس کے بجائے، انہیں ٹیگ کریں۔

env

WORDPRESS_API_URL=https://cms.yourdomain.com

تعینات کرنے سے پہلے، اسی متغیر کو اپنے Cloudflare Pages پروجیکٹ کی ترتیبات میں Environment Variables کے تحت شامل کریں۔

src/lib/wordpress.js

یہ فائل واحد جگہ ہے جہاں سے تمام ورڈپریس API کالز گزرتی ہیں۔ اس کو سنٹرلائز کرنے کا مطلب ہے جب API URL یا توثیق تبدیل ہو جائے تو ایک فائل کو اپ ڈیٹ کرنا۔

کہ _embed پیرامیٹرز اہم ہیں۔ بطور ڈیفالٹ، پوسٹ کے جوابات میں صرف پوسٹ ڈیٹا ہوتا ہے۔ نمایاں تصویر، مصنف کی تفصیلات، اور زمرے منفرد IDs کے ساتھ الگ الگ آئٹمز ہیں۔ بغیر _embedہر ایک کو بازیافت کرنے کے لیے ایک اضافی API کی درخواست کی ضرورت ہے۔ اس کو شامل کرنے سے یہ یقینی ہو جائے گا کہ تمام متعلقہ ڈیٹا ایک ہی جواب میں شامل ہے۔

cache: 'no-store' یہ تمام درآمدی کالوں پر اختیاری نہیں ہے۔ Cloudflare ورکرز HTTP سے الگ، اندرونی طور پر ایک بازیافت کیش چلاتے ہیں۔ Cache-Control ہیڈر اسے غیر فعال کیے بغیر، Cloudflare ورڈپریس API کے جوابات کو کنارے پر کیش کرے گا۔ ایڈیٹرز ایک پوسٹ شائع کرتے ہیں اور فرنٹ اینڈ پر پچھلا ورژن دیکھتے ہیں کیونکہ کیشڈ جواب فراہم کیا جاتا ہے۔

const WP_URL = import.meta.env.WORDPRESS_API_URL

const fetchWP = (path) =>
  fetch(`({WP_URL}){path}`, { cache: 'no-store' }).then((r) => r.json())

export const getPosts = (page = 1, perPage = 10) =>
  fetchWP(`/wp-json/wp/v2/posts?_embed&per_page=({perPage}&page=){page}`)

export const getPostBySlug = async (slug) => {
  const posts = await fetchWP(`/wp-json/wp/v2/posts?_embed&slug=${slug}`)
  return posts[0]
}

export const getCategories = () =>
  fetchWP(`/wp-json/wp/v2/categories`)

export const getPostsByCategory = (categoryId, page = 1) =>
  fetchWP(`/wp-json/wp/v2/posts?_embed&categories=({categoryId}&page=){page}`)

export const getAllPostsForSitemap = () =>
  fetchWP(`/wp-json/wp/v2/posts?_fields=slug,modified&per_page=100`)

سائٹ میپ کی خصوصیت استعمال کرتی ہے: _fields اس کے بجائے _embed درخواست کو ہلکا رکھیں اور صرف وہی فیلڈز لائیں جن کی آپ کو ضرورت ہے۔

src/middleware.js

مڈل ویئر صفحہ ہینڈلر سے پہلے ہر درخواست کے لیے چلتا ہے۔ یہ اضافہ کرتا ہے۔ Cache-Control: no-store Cloudflare کو پیش کردہ HTML صفحات کو کیش کرنے سے روکنے کے لیے تمام SSR جوابات پر لاگو ہوتا ہے۔

export function onRequest(_context, next) {
  return next().then(response => {
    const newResponse = new Response(response.body, response)
    newResponse.headers.set('Cache-Control', 'no-store, no-cache, must-revalidate')
    newResponse.headers.set('CDN-Cache-Control', 'no-store')
    return newResponse
  })
}

ایسٹرو کے اصل جواب میں ناقابل تغیر ہیڈر ہیں، اس لیے اسے نہیں کہا جا سکتا۔ .headers.set() براہ راست اس پر۔ ایک حل یہ ہے کہ اصل باڈی اور جواب کو بطور init آرگیومنٹ استعمال کرتے ہوئے ایک نیا جواب تیار کیا جائے۔ چونکہ نئے جواب میں تغیر پذیر ہیڈر ہیں، .set() فیکٹری CDN-Cache-Control Cloudflare کے لیے مخصوص ہیڈر جو معیارات سے آزادانہ طور پر کنارے پر کیشنگ کو کنٹرول کرتا ہے۔ Cache-Control ہیڈر

src/layouts/Layout.astro

تمام صفحات اس ترتیب کی پیروی کرتے ہیں۔ HTML ڈھانچہ، میٹا ٹیگز، اور عالمی درآمدات یہاں موجود ہیں لہذا آپ کو انہیں ہر صفحہ پر دہرانے کی ضرورت نہیں ہے۔

---
interface Props {
  title: string
  description?: string
}
const { title, description = '' } = Astro.props
---


  
    
    
    
    
  
  
    
    

    
  

نامزد سلاٹس آپ کو نیویگیشن بار اور فوٹر کو بیرونی طور پر پوزیشن میں رکھنے کی اجازت دیتے ہیں۔

---
import Layout from '../../layouts/Layout.astro'
import { getPosts, getCategories, getPostsByCategory } from '../../lib/wordpress'

const page = Number(Astro.url.searchParams.get('page') ?? 1)
const categoryId = Astro.url.searchParams.get('category')

const [posts, categories] = await Promise.all([
  categoryId ? getPostsByCategory(categoryId, page) : getPosts(page, 10),
  getCategories(),
])
---

  

  

    {posts.map((post) => {
      const image   = post._embedded?.['wp:featuredmedia']?.[0]?.source_url
      const imageAlt = post._embedded?.['wp:featuredmedia']?.[0]?.alt_text ?? ''
      return (
        

          {image && }
          
          
        
      )
    })}
  

  {page > 1 && Previous}
  Next

---
import Layout from '../../layouts/Layout.astro'
import { getPostBySlug } from '../../lib/wordpress'

const { slug } = Astro.params
const post = await getPostBySlug(slug)
if (!post) return Astro.redirect('/404')

const image    = post._embedded?.['wp:featuredmedia']?.[0]?.source_url
const imageAlt = post._embedded?.['wp:featuredmedia']?.[0]?.alt_text ?? ''
const author   = post._embedded?.author?.[0]?.name
const seoTitle = post.yoast_head_json?.title ?? post.title.rendered
const seoDesc  = post.yoast_head_json?.og_description ?? ''
---

  

    
    
{author} · {new Date(post.date).toLocaleDateString()}
    {image && }
    
  

import type { APIRoute } from 'astro'
import { getAllPostsForSitemap } from '../lib/wordpress'

export const GET: APIRoute = async () => {
  const posts = await getAllPostsForSitemap()

  const urls = [
    { loc: 'https://yourdomain.com/', lastmod: new Date().toISOString() },
    { loc: 'https://yourdomain.com/blog/', lastmod: new Date().toISOString() },
    ...posts.map((p) => ({
      loc: `https://yourdomain.com/blog/${p.slug}/`,
      lastmod: p.modified,
    })),
  ]

  const xml = `

({urls.map((u) => `  n    ){u.loc}n    ${u.lastmod}n  `).join('n')}
`

  return new Response(xml, { headers: { 'Content-Type': 'application/xml' } })
}

@import "tailwindcss";

@theme {
  --color-brand: #your-color;
  --font-sans: 'Your Font', sans-serif;
}

add_filter('rest_endpoints', function($endpoints) {
    unset($endpoints['/wp/v2/users']);
    unset($endpoints['/wp/v2/users/(?P[d]+)']);
    return $endpoints;
});