CodeVerse | دنیای برنامه نویسان

📌 فراخوانی امن داده‌های PHP در جاوااسکریپت بدون echo

همه ما تجربه کردیم که برای انتقال داده از PHP به JS، مستقیم از echo استفاده می‌کنیم و کد به‌هم‌ریخته و ناامن میشه. یه راه تمیز و استاندارد وجود داره.

✅ ترفند: استفاده از wp_add_inline_script در وردپرس

wp_enqueue_script('my-script', 'path/to/script.js', [], '1.0', true);

$data = [
    'ajax_url' => admin_url('admin-ajax.php'),
    'nonce'    => wp_create_nonce('my_nonce'),
    'user_id'  => get_current_user_id()
];

wp_add_inline_script('my-script', 'const MyData = ' . wp_json_encode($data) . ';', 'before');

حالا توی script.js به‌راحتی داری:

console.log(MyData.ajax_url);
console.log(MyData.nonce);

مزایا:

· کد تمیز و قابل نگهداری
· امنیت بالاتر با wp_json_encode و nonce
· بدون نیاز به دستکاری مستقیم قالب

⚠️ نکته مهم: همیشه از wp_json_encode استفاده کن، نه json_encode خالی. و برای درخواست‌های AJAX حتماً nonce رو چک کن.

@CodeVerse_dev

🔥 یک تصمیم معماری که می‌تونه هزاران خط کد Frontend رو کمتر کنه

فرض کن یه اپلیکیشن داری که چندین Component مختلف از اطلاعات یک کاربر استفاده می‌کنن.

راه ساده اینه که اطلاعات رو از بالا به پایین با Props پاس بدی:

App
 ↓
Layout
 ↓
Page
 ↓
Section
 ↓
Card
 ↓
User

بعد چند ماه:

<Card
  user={user}
  permissions={permissions}
  settings={settings}
  preferences={preferences}
/>

و بعد:

"چرا Prop Drilling اینقدر زیاد شد؟" 😐

ولی راه‌حل حرفه‌ای این نیست که برای هر چیزی سریع بری سراغ Global State.

اول باید سؤال درست رو بپرسی:

این Data واقعاً چه Scopeای داره؟

مثلاً:

Local UI State
→ Component

Feature State
→ Feature Boundary

Shared Client State
→ Store

Server State
→ Cache / Query Layer

URL State
→ URL

این تفکیک خیلی مهمه.

چون اگر Server State رو مثل Client State مدیریت کنی، کم‌کم خودت مسئول چیزهایی مثل:

Cache
Refetch
Stale Data
Loading
Error
Synchronization
Invalidation

می‌شی.

در حالی که ابزارهایی مثل Query Layer دقیقاً برای مدیریت Lifecycle داده‌های سمت سرور ساخته شدن.

💡 هر State که Global نیست.

و یکی از نشانه‌های معماری خوب اینه که قبل از اضافه کردن یک State Manager جدید، دقیقاً بدونی:

این داده متعلق به کجاست؟ چه کسی مالکشه؟ و Lifecycleش دست کیه؟


@CodeVerse_dev

🤯 زبان TypeScript داره از چیزی که فکر می‌کردیم فراتر میره

یه پروژه جدید از Vercel Labs به اسم scriptc سر و صدای جالبی ایجاد کرده.

ایده‌ش اینه:

زبان TypeScript رو به Native Executable تبدیل کن، بدون اینکه برای اجرای برنامه به Node یا V8 وابسته باشی.

یعنی معماری سنتی:

TypeScript
   ↓
JavaScript
   ↓
Node / V8
   ↓
Application

می‌تونه در این مدل به چیزی شبیه این تبدیل بشه:

TypeScript
   ↓
scriptc
   ↓
Native / C / WebAssembly

در نتیجه برنامه می‌تونه Startup سریع‌تر و مصرف حافظه پایین‌تری نسبت به اجرای مستقیم روی Node داشته باشه؛ البته پروژه هنوز experimental هست و در بعضی سناریوها سرعت اجرای خود برنامه پایین‌تر از Node گزارش شده.

نکته مهم اینجا Benchmark نیست.

مسئله معماریه:

ما سال‌ها TypeScript رو به‌عنوان:

«JavaScript با Type»

می‌دیدیم.

اما اکوسیستم داره کم‌کم TypeScript رو به‌عنوان یک زبان توسعه عمومی‌تر با Toolchain مستقل جدی‌تر می‌گیره.

همزمان خود TypeScript 7 هم با Compiler جدید Native/Go عرضه شده که هدفش جهش جدی در سرعت Tooling هست.

💡 شاید آینده TypeScript فقط این نباشه که:

JavaScript بهتر بنویسیم.

بلکه اینکه از TypeScript برای ساخت نرم‌افزارهایی استفاده کنیم که اصلاً در نهایت JavaScript اجرا نمی‌کنن.

@CodeVerse_dev

🚨 این یکی از اون باگ‌های وردپرسیه که فقط با «آپدیت کردم» نباید تمومش کنی

نسخه WordPress 7.1.2 یک آسیب‌پذیری Critical با شناسه CVE-2026-87902 رو برطرف کرد؛ مشکلی در Page Template Resolution که در شرایط مشخص می‌تونه به یک مهاجم بدون احراز هویت اجازه بده یک فایل PHP محلی رو خارج از مسیر Theme فعال وارد فرایند Template Resolution کنه و در شرایط خاص به RCE برسه.


موضوع مهم‌تر اینه که این آسیب‌پذیری در CISA KEV هم قرار گرفته و گزارش شده که در حملات واقعی مورد سوءاستفاده قرار گرفته.


پس اگر پروژه‌ای هنوز روی نسخه آسیب‌پذیر بوده، بعد از Update فقط اینو چک نکن:


WordPress → Updated ✅


این‌ها رو هم بررسی کن:

Admin Users
   ↓
Recently Modified Files
   ↓
PHP Files
   ↓
Access Logs
   ↓
Theme / Plugin Integrity

چرا؟


چون Patch کردن آسیب‌پذیری با Incident Response یکی نیست.


اگر مهاجم قبل از Patch شدن وارد سایت شده باشه، آپدیت فقط جلوی حمله بعدی رو می‌گیره؛ لزوماً آثار حمله قبلی رو پاک نمی‌کنه.


💡 توسعه‌دهنده حرفه‌ای فقط Vulnerability رو Patch نمی‌کنه؛ می‌پرسه:


«آیا ممکنه قبل از Patch ازش سوءاستفاده شده باشه؟»


@CodeVerse_dev

🏗️ یک Code Smell که در پروژه‌های بزرگ هزینه زیادی ایجاد می‌کند

فرض کن در پروژه PHP، منطق ارسال ایمیل، ثبت سفارش و پرداخت را همگی داخل یک متد قرار داده‌ای.

  public function checkout($data)
  {
      // Validate order
      // Save order
      // Process payment
      // Send email
      // Update inventory
  }
  

در نگاه اول همه‌چیز مرتب به نظر می‌رسد؛ اما با بزرگ‌شدن پروژه، تغییر هر بخش ممکن است روی بخش‌های دیگر اثر بگذارد.

راهکار این نیست که برای هر خط کد یک کلاس بسازیم.

بهتر است مسئولیت‌ها را متناسب با پیچیدگی پروژه جدا کنیم:

  CheckoutService
      |
      +-- OrderService
      |
      +-- PaymentService
      |
      +-- InventoryService
      |
      +-- NotificationService
  

حالا می‌توانیم پرداخت را مستقل‌تر تست کنیم یا روش ارسال اعلان را تغییر دهیم، بدون اینکه کل فرایند سفارش را بازنویسی کنیم.

البته اگر پروژه بسیار کوچک است، این میزان جداسازی ممکن است فقط پیچیدگی اضافه ایجاد کند.

اصل مهم معماری: کد را نه بیش از حد ساده نگه دار و نه بی‌دلیل پیچیده کن؛ مرزها را بر اساس مسئولیت‌های واقعی پروژه تعیین کن.

@CodeVerse_dev

⚡نسخه PHP 8.5.11 منتشر شد؛ یک به‌روزرسانی امنیتی مهم

تیم توسعه PHP در ۲۴ سپتامبر، نسخه 8.5.11 را منتشر کرد. این نسخه یک به‌روزرسانی امنیتی است و کاربران PHP 8.5 باید آن را جدی بگیرند.

اما یک نکته مهم وجود دارد:

هر بار که نسخه PHP را ارتقا می‌دهی، فقط نباید به اجرای موفق پروژه توجه کنی.

این موارد را هم بررسی کن:

▪️ خطاهای جدید در لاگ‌ها
▪️ سازگاری کتابخانه‌ها و پکیج‌ها
▪️ رفتار کدهای قدیمی
▪️ تست‌های خودکار پروژه

برای پروژه‌های واقعی، ارتقای نسخه باید بخشی از فرایند نگهداری باشد، نه کاری که فقط هنگام بروز مشکل انجام می‌دهیم.

یک پروژه سالم، فقط پروژه‌ای نیست که امروز کار می‌کند؛ باید بعد از به‌روزرسانی هم قابل اعتماد بماند.

@CodeVerse_dev

🚨 آسیب‌پذیری بحرانی وردپرس؛ سایتت را همین امروز بررسی کن!

در نسخه 7.1.2 وردپرس، یک آسیب‌پذیری امنیتی بحرانی برطرف شده که در شرایط خاص، امکان دسترسی به فایل‌های PHP محلی و حتی اجرای کد از راه دور را فراهم می‌کند.

نکته نگران‌کننده این است که گزارش‌هایی از سوءاستفاده واقعی از این آسیب‌پذیری منتشر شده است.

🔴 اگر وردپرس داری، این موارد را بررسی کن:

▪️ نسخه وردپرس را به 7.1.2 یا نسخه اصلاح‌شده جدیدتر ارتقا بده.
▪️ قالب‌های فعال و افزونه‌ها را بررسی کن.
▪️ لاگ‌های سرور را از نظر درخواست‌های مشکوک بررسی کن.

نکته حرفه‌ای: به‌روزرسانی وردپرس فقط برای اضافه‌شدن امکانات جدید نیست؛ گاهی مستقیماً از اجرای کد مخرب روی سرور جلوگیری می‌کند.

منبع: WordPress Security Team


@CodeVerse_dev

🧪داخل Performance Lab؛ چطور بفهمیم کدام بخش JavaScript کند است؟

یکی از اشتباهات رایج در بهینه‌سازی فرانت‌اند، حدس‌زدن محل مشکل است.

مثلاً تصور می‌کنیم حلقه‌های تو در تو عامل کندی هستند؛ درحالی‌که ممکن است زمان اصلی صرف درخواست‌های شبکه یا رندر مرورگر شود.

برای اندازه‌گیری بخش‌های مشخصی از کد، می‌توانیم از User Timing API استفاده کنیم.

  performance.mark("render-start");

  renderDashboard();

  performance.mark("render-end");

  performance.measure(
    "dashboard-render",
    "render-start",
    "render-end"
  );

  const result = performance
    .getEntriesByName("dashboard-render")
    .at(-1);

  console.log(result.duration);
  

با این روش می‌توانیم مدت اجرای بخش مشخصی از کد را اندازه‌گیری کنیم.

البته اگر renderDashboard عملیات ناهمگام داشته باشد، این اندازه‌گیری صرفاً زمان اجرای اولیه آن را نشان می‌دهد؛ نه لزوماً زمان تکمیل عملیات.

قاعده مهم: قبل از بهینه‌سازی، اندازه‌گیری کن؛ بعد تغییر بده و دوباره اندازه بگیر.

@CodeVerse_dev

‏🤖 Paperclip؛ مدیریت و کنترل AI Agentها در یک محیط واحد

این پروژه برای ساخت و مدیریت سازمان‌هایی متشکل از AI Agentها طراحی شده؛ جایی که می‌تونی برای هر Agent وظایف، نقش‌ها و محدودیت‌های مشخصی تعریف کنی و عملکردشون رو از یک داشبورد واحد زیر نظر بگیری.

با Paperclip می‌تونی Agentهایی مثل Claude Code، Codex و Cursor رو در یک سیستم هماهنگ کنی، برای هرکدوم بودجه تعیین کنی و وظایف و هزینه‌هاشون رو زیر نظر بگیری. این پروژه متن‌باز و قابل نصب روی سرور شخصیه و برای ساخت سیستم‌های مبتنی بر چند Agent کاربرد داره.

📎 LINK

@CodeVerse_dev

🌐 چرا بعضی سایت‌ها با Refresh دوباره اطلاعات قدیمی نشون میدن؟

گاهی مشکل از Cache نیست؛ از Service Workerـه.

حالا Service Worker می‌تونه بین مرورگر و Network قرار بگیره و درخواست‌ها رو مدیریت کنه.

مثلاً:

Browser
   ↓
Service Worker
   ↓
Cache / Network

حالا اگر استراتژی Cache درست طراحی نشده باشه، ممکنه کاربر نسخه قدیمی یک فایل یا حتی یک Response رو دریافت کنه.

اینجاست که وقتی توسعه‌دهنده میگه:

«من فایل جدید رو Deploy کردم.»

کاربر جواب میده:

«برای من هنوز نسخه قبلیه!»

😐

برای Debug کردن PWAها، DevTools → Application یکی از مهم‌ترین جاهاست.

اونجا می‌تونی Service Worker، Cache Storage و وضعیت کنترل صفحه رو بررسی کنی.

نکته مهم:

موضوع Service Worker فقط یک فایل JS نیست؛ بخشی از معماری Delivery سایتته.

اگر Cache Strategy درست انتخاب نشه، چیزی که قرار بوده Performance رو بهتر کنه، تبدیل به منبع باگ میشه.

قبل از اینکه بگی:

«کاربر Cache رو پاک کنه!»

اول بررسی کن واقعاً چه چیزی داره Response قدیمی رو سرو می‌کنه.

@CodeVerse_dev

🛠 چرا بعضی Queryهای وردپرس بی‌دلیل meta_query دارن؟

یکی از قابلیت‌های جذاب WordPress اینه که می‌تونی بر اساس Metadata جستجو کنی:

'meta_query' => [
    [
        'key'   => 'price',
        'value' => 1000,
    ]
]

خیلی کاربردیه.

ولی وقتی حجم داده زیاد بشه، postmeta می‌تونه تبدیل به گلوگاه بشه.

چرا؟

چون WordPress بخش بزرگی از اطلاعات اضافی پست‌ها رو در ساختاری عمومی نگه می‌داره و Queryهای پیچیده روی Meta می‌تونن هزینه‌بر بشن.

مثلاً اگر مرتباً داری بر اساس:

price
stock
city
status

فیلتر می‌کنی، باید بررسی کنی آیا مدل ذخیره‌سازی فعلی واقعاً برای این Queryها مناسبه یا نه.

گاهی مشکل از WordPress نیست.

مشکل اینه که از یک ساختار عمومی، برای داده‌ای استفاده کردی که تبدیل به داده پرتکرار و قابل جستجو شده.

برای پروژه‌های بزرگ، گاهی Custom Table یا طراحی دیتای مناسب‌تر می‌تونه منطقی‌تر باشه.

البته این به معنی «همیشه Custom Table بساز» نیست.

اگر ۵۰۰ محصول داری، احتمالاً نیازی به معماری عجیب نداری. 😄

ولی وقتی تعداد داده و تعداد Query بالا میره، باید مدل داده رو هم مثل کد Performance Review کنی.


@CodeVerse_dev

این اشتباه Promise.all() می‌تونه API رو زمین بزنه!

متد Promise.all() فوق‌العاده‌ست، ولی یه نکته مهم داره.

فرض کن:

const users = await Promise.all(
    userIds.map(id => fetchUser(id))
);

اگر ۱۰ تا ID داشته باشی، مشکلی نیست.

ولی اگر ۵۰ هزار ID داشته باشی چی؟

یک‌دفعه ممکنه هزاران درخواست هم‌زمان ایجاد کنی.

نتیجه؟

💥 فشار روی API
💥 مصرف زیاد RAM
💥همچنین Connectionهای زیاد
💥 احتمال Rate Limit شدن

پس همیشه:

«هم‌زمان اجرا کردن» به معنی «بهترین Performance» نیست.

برای تعداد زیاد عملیات، معمولاً باید Concurrency رو محدود کنی.

مثلاً به جای اینکه ۱۰۰۰ درخواست رو هم‌زمان اجرا کنی، می‌تونی دسته‌های کوچک‌تر بسازی:

20 requests
↓
wait
↓
20 requests
↓
wait
↓
...

این تفاوت بین:

Parallelism بدون کنترل

و

Concurrency کنترل‌شده


گاهی سریع‌ترین سیستم، سیستمی نیست که همه‌چیز رو هم‌زمان اجرا کنه؛ سیستمیه که منابع رو درست مدیریت می‌کنه.


@CodeVerse_dev

🧠 چرا بعضی پروژه‌های React بعد از مدتی تبدیل به کابوس میشن؟

مشکل همیشه React نیست.

خیلی وقت‌ها مشکل از اینه که State بدون معماری مشخص پخش شده.

مثلاً یک پروژه رو تصور کن:

Component A
   ↓
useState

Component B
   ↓
Context

Component C
   ↓
Redux

Component D
   ↓
URL Params

Component E
   ↓
localStorage

همه‌چیز هم کار می‌کنه...

تا وقتی که یک Feature جدید اضافه بشه. 😐

بعد ناگهان باید بفهمی:

«منبع اصلی این Data کجاست؟»

اینجاست که یک اصل مهم وارد میشه:

State Ownership

هر State باید یک مالک مشخص داشته باشه.

مثلاً:

UI State

Component → نزدیک

Shared Client State
→ Store

Server State
→ Query Cache

URL State
→ URL

و نکته مهم‌تر:

اینکه Server State رو با Client State قاطی نکن.

اطلاعاتی که از API میاد الزاماً نباید داخل Redux ذخیره بشه.

چون Server State ویژگی‌هایی مثل:

* Cache
* Refetch
* Stale Data
* Synchronization
* Loading/Error State

داره.

برای همین ابزارهایی مثل TanStack Query دقیقاً برای همین مسئله ساخته شدن.

💡 معماری خوب یعنی قبل از اینکه State زیاد بشه، مشخص کنی هر داده متعلق به کجاست و چه کسی مسئول Lifecycle اون داده‌ست.


@CodeVerse_dev

🤖 هوش مصنوعی می‌تواند هم کد را امن‌تر کند، هم مشکل جدید ایجاد کند.

شرکت Google اخیراً درباره استفاده از Agentic AI برای بررسی و Patch کردن آسیب‌پذیری‌های کد در مقیاس بسیار بزرگ نوشته است.

ایده جالب است:

`Code Change`
↓
`AI Agent`
↓
`Vulnerability Detection`
↓
`Patch`
↓
`Verification`

شرکت Google می‌گوید این سیستم‌ها می‌توانند به‌صورت مداوم تغییرات کد را بررسی کنند و آسیب‌پذیری‌ها را قبل از رسیدن به Production شناسایی و اصلاح کنند.

اما یک نکته مهم وجود دارد:

حالا AI Security نباید به معنی «اعتماد کامل به AI» باشد.

اگر Agent خودش کد را تغییر می‌دهد، باید بتوانیم بفهمیم:

🔹 چه چیزی تغییر کرده؟
🔹 چرا تغییر کرده؟
🔹 آیا Patch واقعاً مشکل را حل کرده؟
🔹 آیا رفتار دیگری را خراب نکرده؟
🔹 چه کسی تغییر را تأیید کرده؟

یعنی در آینده احتمالاً فقط داشتن AI Coding Agent مهم نیست؛

بلکه داشتن یک Pipeline برای:

Generate → Scan → Patch → Test → Review

اهمیت بیشتری پیدا می‌کند.


@CodeVerse_dev

⚙️ یک تغییر جالب در WordPress که Plugin Developerها باید بدانند

در توسعه WordPress، بعضی APIها و قابلیت‌ها از حالت Private به سمت APIهای عمومی‌تر حرکت می‌کنند.

یکی از نمونه‌های اخیر مربوط به DataViews است.

در Gutenberg، استفاده از بعضی Private APIها در DataViews در حال حذف شدن است و بخش‌هایی مثل:

Calendar

RangeCalendar

و

ValidatedInputControl

به مسیرهای عمومی‌تر منتقل شده‌اند.

این موضوع شاید در نگاه اول خیلی مهم به نظر نرسد، اما برای Plugin Developerها یک پیام مهم دارد:

❌ روی APIهای Private برای Plugin خودت حساب نکن.

چون Private API می‌تواند تغییر کند، جابه‌جا شود یا حتی حذف شود.

قاعده ساده:

Public API → قابل اتکاتر برای Plugin

Private API → وابستگی پرریسک‌تر

اگر Plugin حرفه‌ای می‌سازی، فقط به این فکر نکن که:

«الان کار می‌کند؟»

بلکه بپرس:

«بعد از آپدیت WordPress هم احتمالاً پایدار می‌ماند؟»


@CodeVerse_dev

چرا «همه‌چیز را Generic کنیم» می‌تواند معماری را بدتر کند؟

🧠 یک وسوسه خطرناک در پروژه‌های بزرگ:

«بیایید این را Generic کنیم تا بعداً قابل استفاده مجدد باشد.»

مثلاً:

GenericService
GenericRepository
GenericController
GenericResponse
GenericHandler

در ابتدا جذاب است.

اما چند ماه بعد ممکن است با یک سیستم مواجه شوید که:

❌ رفتارهای متفاوت را داخل یک کلاس جا داده.

❌ تغییر یک Feature روی چند بخش اثر می‌گذارد.

❌ فهمیدن جریان واقعی برنامه سخت شده.

موضوع Reusable بودن همیشه به معنی Generic بودن نیست.

گاهی دو کد مشابه، بهتر است واقعاً دو کد مستقل باشند.

🎯 حالا Abstraction باید از پیچیدگی کم کند؛ نه اینکه پیچیدگی را پشت یک لایه پنهان کند.

💡 قبل از ساختن Abstraction از خودت بپرس:

«آیا واقعاً دو چیز یک مفهوم هستند یا فقط الان شبیه هم به نظر می‌رسند؟»

@CodeVerse_dev

چرا AbortController یکی از مهم‌ترین ابزارهای API در Frontend است؟

⚡ فرض کنید کاربر داخل Search Box تایپ می‌کند:

l
la
lar
lara
laravel

اگر برای هر تغییر یک Request ارسال کنید، ممکن است چند درخواست هم‌زمان در حال اجرا باشند.

اینجا AbortController کاربرد پیدا می‌کند:

const controller = new AbortController();

fetch("/api/search?q=laravel", {
    signal: controller.signal
});

// Cancel request
controller.abort();

با این روش می‌توانید Requestهای قدیمی را لغو کنید.

مثلاً:

کاربر lar را جستجو کرده، اما قبل از دریافت پاسخ، laravel را نوشته است.

❌ لازم نیست پاسخ قدیمی را نگه دارید.

✅ در اینجا Request قبلی را Cancel کنید.

🎯 در اپلیکیشن‌های مدرن، مدیریت Requestهای غیرضروری بخشی از Performance است.

💡 گاهی سریع‌تر شدن سایت با سریع‌تر کردن Server اتفاق نمی‌افتد؛ با ارسال درخواست‌های کمتر اتفاق می‌افتد.


@CodeVerse_dev

🚨 فرض کنید API پرداخت این درخواست را دریافت می‌کند:

POST /payments

سرور عملیات پرداخت را انجام می‌دهد...

اما قبل از اینکه پاسخ به کاربر برسد، Connection قطع می‌شود.

Frontend فکر می‌کند:

❌ «پرداخت انجام نشد.»

پس دوباره Request می‌فرستد.

حالا Server دو Request دریافت کرده است.

اگر سیستم Idempotency نداشته باشد:

Request #1 → Payment
Request #2 → Payment

ممکن است یک عملیات دوبار اجرا شود.

راه‌حل:

Idempotency-Key: 8f4c...

اینجا Server این Key را ذخیره می‌کند.

اگر همان درخواست دوباره رسید:

✅ نتیجه قبلی برگردانده می‌شود.

❌ عملیات دوباره اجرا نمی‌شود.

🎯 در سیستم‌های حساس، Retry و Idempotency باید کنار هم طراحی شوند.

💡 «دوباره تلاش کردن» بدون اینکه بدانیم عملیات قابل تکرار است یا نه، می‌تواند خودش منبع Bug باشد.

@CodeVerse_dev

🚨 یک Query ساده می‌تواند پشت صحنه صدها Query تولید کند.

فرض کنید:

$posts = Post::latest()->take(20)->get();

foreach ($posts as $post) {
    echo $post->author->name;
}

ممکن است فکر کنید فقط یک Query برای گرفتن پست‌ها داریم.

اما اگر author را Eager Load نکرده باشید:

1 Query → دریافت Posts
20 Query → دریافت Authorها

یعنی:

21 Query برای فقط 20 پست!

راه بهتر:

$posts = Post::with('author')
    ->latest()
    ->take(20)
    ->get();

حالا داده‌های موردنیاز رابطه هم از قبل دریافت می‌شوند.

🎯 اما نکته مهم‌تر:

حالا N+1 فقط باعث کندی نیست؛ در سیستم پرترافیک می‌تواند تعداد Queryهای Database را به‌شدت افزایش دهد.

💡 همیشه بعد از نوشتن یک Feature از خودت بپرس:

«برای این صفحه واقعاً چند Query به Database ارسال می‌شود؟»


@CodeVerse_dev

ترفند حرفه‌ای - ساخت سیستم لاگ‌گیری اختصاصی برای وردپرس

خیلی وقتا برای دیباگ کردن یه مشکل خاص، باید کلی پلاگین سنگین نصب کنی. ولی یه راه ساده‌تر هست.

✅ ترفند: لاگ‌گیری در فایل جداگانه

function my_custom_log($message) {
    if (defined('WP_DEBUG') && WP_DEBUG) {
        $log_file = WP_CONTENT_DIR . '/custom-debug.log';
        $timestamp = date('Y-m-d H:i:s');
        error_log("[{$timestamp}] {$message}\n", 3, $log_file);
    }
}

// نحوه استفاده
my_custom_log('مشکل در کوئری مربوط به محصولات');
my_custom_log('متغیر دریافتی: ' . print_r($data, true));

مزایا:

· فایل لاگ جداگانه و تمیز
· فقط در حالت دیباگ فعال میشه
· بدون نیاز به پلاگین اضافی

⚠️ نکته مهم: فایل custom-debug.log رو بعد از رفع مشکل پاک کن.

@CodeVerse_dev