🚨 اگر All-in-One WP Migration داری، این پست مهمه

یک آسیب‌پذیری SQL Injection بدون نیاز به لاگین در افزونه‌ی محبوب All-in-One WP Migration and Backup گزارش شده که حدود ۵ میلیون سایت وردپرسی را تحت تأثیر قرار می‌دهد.

نکته‌ی جالب‌تر اینه که Wordfence اعلام کرده برای کاربران رایگانش، محافظت فایروال از ۱۵ سپتامبر ۲۰۲۶ فعال می‌شود.

یعنی امروز دقیقاً روزیه که اگر این افزونه روی سایتت نصبه، باید وضعیتش رو بررسی کنی.

🔐 همیشه اینو یادت باشه:

نصب یک افزونه‌ی محبوب ≠ امن بودن آن

قبل از هر چیز:

نسخه افزونه را بررسی کن
آپدیت موجود را نصب کن
افزونه‌های بلااستفاده را حذف کن
لاگ‌های امنیتی سایت را بررسی کن

@CodeVerse_dev

🚀 زبان TypeScript دیگه فقط یک زبان تایپ‌شده روی JavaScript نیست؛ Compiler خودش هم متحول شده

یکی از تغییرات مهم امسال، مهاجرت TypeScript به یک Compiler کاملاً Native بر پایه Go هست.

نسخه TypeScript 7 با این معماری جدید منتشر شده و مایکروسافت گزارش کرده که در Buildهای کامل، بسته به پروژه، سرعت‌هایی حدود ۸ تا ۱۲ برابر نسبت به Compiler قبلی دیده میشه.

اما نکته مهم فقط سرعت نیست.

در پروژه‌های بزرگ TypeScript، زمان صرف‌شده برای:

Type Checking
↓
Language Server
↓
Build
↓
IDE Feedback

می‌تونه روی تجربه توسعه‌دهنده تأثیر جدی بذاره.

وقتی این بخش‌ها سریع‌تر بشن، نتیجه فقط یک Build سریع‌تر نیست.

یعنی:

⚡عمل Feedback سریع‌تر داخل IDE
⚡ سریع‌تر شدن Type Checking
⚡ تجربه بهتر در Monorepoها
⚡ امکان کار راحت‌تر با Codebaseهای بزرگ

و این دقیقاً همون جاییه که TypeScript می‌خواد JavaScript رو برای پروژه‌های خیلی بزرگ مقیاس‌پذیرتر کنه.

💡 نکته جالب:

گاهی Performance یک زبان فقط به Runtime مربوط نیست؛ سرعت ابزارهای اطراف Developer هم بخشی از Performance واقعی اون اکوسیستمه.

@CodeVerse_dev

🚨 امروز چند آسیب‌پذیری جدی در افزونه‌های وردپرس گزارش شده

یکی از موارد امروز مربوط به افزونه Login with QR با شناسه CVE-2026-86710 هست.

مشکل از جایی میاد که افزونه کد ورود QR را به‌درستی اعتبارسنجی نمی‌کنه و در شرایطی مهاجم بدون احراز هویت می‌تونه به‌عنوان یک کاربر وارد سایت بشه؛ حتی اگر آن حساب Administrator باشه.

دو مورد دیگه هم امروز برای افزونه‌های Pressengine و PuppyFW گزارش شده:

🔴 Pressengine → امکان دور زدن احراز هویت و ایجاد Session معتبر

🔴 PuppyFW → ضعف در بررسی Permission در REST API و امکان تغییر تنظیمات سایت توسط کاربر دارای دسترسی پایین‌تر

نکته مهم برای توسعه‌دهنده‌های WordPress:

وقتی یک API یا Login Handler می‌نویسی، هیچ‌وقت نباید به داده‌ای که از Request میاد برای تعیین سطح دسترسی اعتماد کنی.

اشتباه خطرناک:

$capability = $_REQUEST['capability'];

current_user_can($capability);

چون کاربر عملاً داره تعیین می‌کنه:

«بررسی کن ببین من این دسترسی رو دارم یا نه!»

سطح دسترسی باید سمت سرور و از یک مقدار ثابت و قابل اعتماد تعیین بشه.

💡 خیلی از باگ‌های امنیتی پیچیده، در نهایت از یک اشتباه ساده شروع میشن:

اعتماد کردن به چیزی که کاربر خودش می‌تونه کنترلش کنه.

@CodeVerse_dev

چرا باید Destructuring در JavaScript رو بلد باشی؟ 🤔

فرض کن از API یک User گرفتیم:

const user = {
  name: "alex",
  age: 22,
  role: "Developer"
};

روش معمول:

const name = user.name;
const age = user.age;
const role = user.role;

اما با Destructuring:

const { name, age, role } = user;

همین! 😎

حالا مستقیم می‌تونی استفاده کنی:

console.log(name);
console.log(age);
console.log(role);

---

تغییر اسم متغیر هم میشه 👀

مثلاً:

const { name: username } = user;

console.log(username);
// alex

اینجا Property همچنان name هست، ولی متغیری که ساختیم username نام داره.

---

مقدار پیش‌فرض هم می‌تونی تعیین کنی:

const { name, country = "England" } = user;

console.log(country);
// England

اگر country داخل Object وجود نداشته باشه، مقدار پیش‌فرض استفاده میشه.

---

داخل Destructuring برای Array هم داریم 🔥

const colors = ["red", "blue", "green"];

const [first, second] = colors;

console.log(first);
// red

console.log(second);
// blue

حتی می‌تونی بعضی آیتم‌ها رو رد کنی:

const [first, , third] = colors;

console.log(third);
// green

---

کاربرد واقعی در پروژه

وقتی از یک تابع چند مقدار برمی‌گردونی:

function getUser() {
  return {
    name: "alex",
    age: 22
  };
}

const { name, age } = getUser();

یا هنگام کار با API:

const { data, status } = response;

کدت هم کوتاه‌تر میشه، هم خواناتر.

حالا Destructuring فقط برای کوتاه کردن کد نیست؛ کمک می‌کنه دقیقاً مشخص باشه از یک Object یا Array چه داده‌ای نیاز داری. 🚀

@CodeVerse_dev

یک اشتباه رایج بین توسعه‌دهنده‌ها:

npm install package

و تمام.

اما واقعاً چه چیزی نصب شد؟

ممکنه تو فقط اینو درخواست کرده باشی:

my-package

ولی پشت صحنه:

my-package
 ├── dependency-A
 │    ├── dependency-C
 │    └── dependency-D
 ├── dependency-B
 │    └── dependency-E
 └── ...

یعنی یک پکیج می‌تواند ده‌ها یا حتی صدها dependency دیگر وارد پروژه کند.

حملات زنجیره تأمین دقیقاً از همین نقطه خطرناک می‌شوند.

در سال ۲۰۲۶ چندین حمله بزرگ به npm رخ داده که حتی پکیج‌های محبوب را هدف گرفته‌اند؛ از جمله ChainDrop که بیش از ۴۰۰ پکیج npm را تحت تأثیر قرار داد.

پس قبل از اینکه یک پکیج را فقط به خاطر محبوب بودن نصب کنی، این سؤال را بپرس:

«این پکیج چه چیزهایی را با خودش وارد پروژه من می‌کند؟»

@CodeVerse_dev

توصیه مهم توی پروژه ها 🙂‍↕️

🚨 وقتی یک اسکریپت خارجی، تبدیل به نقطه ورود حمله می‌شود

یک حمله Supply Chain در سرویس‌های Brevo اخیراً باعث شد JavaScript مخرب از طریق بعضی Widgetها و Assetهای این سرویس به سایت‌های استفاده‌کننده منتقل شود.

گزارش‌های منتشرشده می‌گویند این حمله بیش از ۱۰۰ هزار سایت را در معرض خطر قرار داده است.

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

وقتی داخل سایتت این موارد را قرار می‌دهی:

<script src="external-service.js">

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

یعنی حتی اگر:

✅ سیستم محتوا WordPress به‌روز باشد
✅ همینطور Pluginها امن باشند
✅ سرور امن باشد

باز هم یک Third-Party Script آلوده می‌تواند سطح حمله را افزایش دهد.

برای همین در پروژه‌های حساس:

🔹 وابستگی‌های خارجی را Inventory کنید
🔹همچنین Scriptهای Third-Party را بررسی کنید
🔹 دسترسی Pluginها را محدود کنید
🔹موضوع CSP را جدی بگیرید
🔹 تغییرات غیرعادی فایل‌ها و درخواست‌ها را Monitor کنید

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


@CodeVerse_dev

💡 یک ترفند ساده HTML که می‌تواند تجربه کاربری سایتت را بهتر کند!

اگر در فرم سایت از input استفاده می‌کنی، ویژگی autocomplete را فراموش نکن.

مثلاً:

<input
  type="email"
  name="email"
  autocomplete="email"
>

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

✅ فرم سریع‌تر پر می‌شود
✅ تجربه کاربری بهتر می‌شود
✅ مخصوصاً در موبایل کاربردی است

گاهی یک Attribute ساده می‌تواند UX سایت را بهتر کند. 🚀

@CodeVerse_dev

🔐 یک نکته امنیتی مهم برای توسعه‌دهندگان وب:

هیچ‌وقت API Key، پسورد دیتابیس یا Secretهای پروژه را مستقیماً داخل کد قرار نده!

❌ بد:

const API_KEY = "my-secret-key";

✅ بهتر:


const API_KEY = process.env.API_KEY;

و مقدار Secret را داخل فایل محیطی مثل .env نگهداری کن.

⚠️ مخصوصاً قبل از Push کردن پروژه به GitHub، حواست به اطلاعات حساس باشد.

یک API Key لو رفته می‌تواند دردسر بزرگی ایجاد کند.

@CodeVerse_dev

چرا ()Promise.all یکی از ابزارهای مهم JavaScript ـه؟ 🚀

فرض کن باید از ۳ API مختلف اطلاعات بگیری:

const users = fetch("/api/users");
const posts = fetch("/api/posts");
const comments = fetch("/api/comments");

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

اینجا ()Promise.all کاربرد داره:

const [users, posts, comments] = await Promise.all([
  fetch("/api/users"),
  fetch("/api/posts"),
  fetch("/api/comments")
]);

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

---

اما یک نکته خیلی مهم 👀

اگر حتی یکی از Promiseها reject بشه، کل Promise.all() reject میشه:

const result = await Promise.all([
  fetch("/api/users"),
  fetch("/api/posts"),
  fetch("/api/comments")
]);

مثلاً اگر درخواست posts شکست بخوره، result دریافت نمیشه؛ حتی اگر دو درخواست دیگه موفق شده باشن.

---

اگر می‌خوای نتیجه همه رو بگیری:

از ()Promise.allSettled استفاده کن:

const results = await Promise.allSettled([
  fetch("/api/users"),
  fetch("/api/posts"),
  fetch("/api/comments")
]);

حالا می‌تونی ببینی هر درخواست چه وضعیتی داشته:

[
  { status: "fulfilled", value: ... },
  { status: "rejected", reason: ... },
  { status: "fulfilled", value: ... }
]

🔥 خلاصه:

Promise.all()→
همه باید موفق بشن.

Promise.allSettled()→

نتیجه تک‌تک Promiseها رو می‌گیری، حتی اگر بعضی شکست بخورن.

پس وقتی چند عملیات مستقل داری، قبل از اینکه همه رو پشت سر هم await کنی، به ()Promise.all فکر کن.

@CodeVerse_dev

🚀 مدیریت Dependencyها داره وارد مرحله جدیدی میشه


یکی از اتفاقات جالب اکوسیستم JavaScript این روزها، ظهور ابزارهایی مثل vlt هست.


ابزار vlt نسخه 1.0 خودش رو منتشر کرده و هدفش اینه که به‌عنوان جایگزینی برای npm استفاده بشه.


اما قسمت جالبش فقط سرعت نیست.


ابزار vlt روی امنیت Supply Chain تمرکز زیادی داره.


مثلاً:


🔹 نصب مرحله‌ای Packageها

🔹 امکان Query کردن Dependency Graph

🔹 جلوگیری از اجرای بعضی Scriptهای مخرب

🔹همینطور Registryهایی با قابلیت مسدود کردن Packageهای مخرب


این موضوع مهمه چون امروزه پروژه تو فقط به کدی که خودت نوشتی وابسته نیست.


مثلاً:

Your App
   ↓
Package A
   ↓
Package B
   ↓
Package C
   ↓
Package D

ممکنه یک Package کوچک، ده‌ها Dependency دیگه داشته باشه.


پس حمله به Supply Chain می‌تونه بدون اینکه مستقیماً کد خودت مشکل داشته باشه، پروژه‌ات رو تحت تأثیر قرار بده.


جالب‌تر اینکه vlt توسط اعضای تیم اولیه npm ساخته شده و دقیقاً روی همین مسئله تمرکز داره.


💡 از این به بعد وقتی یک Package نصب می‌کنی، فقط نپرس:


«این Package چه کاری انجام میده؟»


این رو هم بپرس:


«این Package چه چیزهایی با خودش وارد پروژه من می‌کنه؟»

@CodeVerse_dev

🚨 اگر سایت وردپرسی داری، WordPress 7.1.1 رو جدی بگیر


وردپرس ۷.۱.۱ در ۱۷ سپتامبر منتشر شده و یک Security & Maintenance Release محسوب میشه.


این نسخه علاوه بر اصلاحات Core و Block Editor، ۱۱ مشکل امنیتی رو برطرف کرده. یکی از موارد جالبش هم اینه که یک URL خاص می‌تونسته باعث نصب و Preview خودکار یک Theme غیرفعال از WordPress.org بشه. همچنین مشکلاتی در REST API، XML-RPC، XSS و کنترل دسترسی برطرف شده.


پس اگر پروژه وردپرسی داری:

Backup
   ↓
Update WordPress
   ↓
Test Theme
   ↓
Test Plugins
   ↓
Check Admin / REST API

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


مبحث Security Patch فقط برای رفع یک Bug نیست؛ گاهی نشون میده چه نوع فرض‌های اشتباهی در معماری Core وجود داشته.


مثلاً وقتی با REST API کار می‌کنی، هیچ‌وقت فقط به این اکتفا نکن که:

if ( is_user_logged_in() ) {
    // اجازه بده
}

احراز هویت با Authorization فرق داره.


کاربر لاگین‌شده لزوماً اجازه انجام اون عملیات رو نداره.


💡 توی Plugin و Theme حرفه‌ای همیشه این دو سؤال رو جدا از هم بپرس:


«این کاربر کیه؟»


و


«اجازه انجام این کار رو داره؟»

@CodeVerse_dev

🐘 همیشه try/catch کردن کار درستی نیست!

یکی از اشتباهات رایج در PHP اینه که هر جا احتمال خطا وجود داشت، سریع بنویسیم:

try {
    $user = createUser($data);
} catch (Exception $e) {
    return false;
}

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

مثلاً:

function createUser(array $data): bool
{
    try {
        // Database operation...
        return true;
    } catch (Throwable $e) {
        return false;
    }
}

حالا لایه‌ی بالاتر فقط می‌فهمه:

false

اما نمی‌دونه:

* Database مشکل داشته؟
* Validation شکست خورده؟
* Unique constraint نقض شده؟
* Connection قطع شده؟
* Bug واقعی اتفاق افتاده؟

راه بهتر 👇

اگر این لایه نمی‌تونه خطا رو واقعاً مدیریت کنه، معمولاً بهتره Exception رو بگیری و بی‌دلیل خفه‌اش نکنی:

function createUser(array $data): User
{
    // اگر خطایی رخ دهد، Exception به caller منتقل می‌شود
    return User::create($data);
}

بعد در لایه‌ای که واقعاً می‌تونه تصمیم بگیره، مدیریت کن:

try {
    $user = createUser($data);

    return response()->json($user);
} catch (Throwable $e) {

    logger()->error($e->getMessage());

    return response()->json([
        'message' => 'Something went wrong'
    ], 500);
}

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

⚠️ یک تفاوت مهم

Exception برای اتفاقات قابل مدیریت مناسبه.

اما این کار:

catch (Throwable $e) {
    return false;
}

می‌تونه یک Bug واقعی برنامه رو هم پنهان کنه.

یعنی:

Real Error
    ↓
catch
    ↓
false
    ↓
برنامه ادامه پیدا می‌کند
    ↓
Debugging nightmare 💀

🔥 قاعده حرفه‌ای:

مبحث Exception را فقط جایی Catch کن که واقعاً می‌دانی با آن چه کار کنی.

اگر فقط قرار است بگیری، false برگردانی و اطلاعات خطا را دور بریزی، احتمالاً Catch کردن در آن لایه تصمیم درستی نیست.

موضوع Error handling خوب یعنی خطا را پنهان نکنی؛ در لایه‌ی درست، آن را مدیریت کنی.


@CodeVerse_dev

🧠 یک تفاوت مهم بین برنامه‌نویس تازه‌کار و باتجربه:

تازه‌کار معمولاً می‌پرسد:

«چطور این قابلیت را کدنویسی کنم؟»

اما برنامه‌نویس باتجربه اول می‌پرسد:

«آیا اصلاً لازم است این قابلیت را بسازیم؟»

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

قبل از شروع هر Feature:

🔹 مشکل واقعی چیست؟
🔹 چند نفر از آن استفاده می‌کنند؟
🔹 آیا راه ساده‌تری وجود دارد؟
🔹 هزینه نگهداری آن چقدر است؟

برنامه‌نویسی فقط کدنویسی نیست؛
حل مسئله است. 🚀

@CodeVerse_dev

🚨 خبر مهم برای توسعه‌دهندگان WordPress

وردپرس در نسخه 7.1.1 یک آپدیت امنیتی مهم منتشر کرده است.

این نسخه شامل:

🔹 17 رفع باگ در Core
🔹 19 رفع باگ در Block Editor
🔹 11 اصلاح امنیتی

است.

تیم WordPress توصیه کرده سایت‌ها در اسرع وقت به این نسخه آپدیت شوند.

📌 اگر چند سایت وردپرسی مدیریت می‌کنی، امروز وقت خوبی است که وضعیت نسخه همه آن‌ها را بررسی کنی.



@CodeVerse_dev

🌐 یک تغییر جالب در دنیای Web Development

اتصال AI به محیط اجرای واقعی وب روزبه‌روز جدی‌تر می‌شود.

در حال حاضر ابزارها و استانداردهایی مثل MCP و WebMCP در حال ایجاد راه‌هایی هستند که Agentهای هوش مصنوعی بتوانند با ابزارها و سرویس‌های وب تعامل داشته باشند.

این یعنی آینده توسعه وب فقط ساخت صفحات و API نیست؛

بلکه احتمالاً باید یاد بگیریم:

🔹چگونه APIهای قابل استفاده توسط Agent بسازیم
🔹 ابزارهای قابل فراخوانی طراحی کنیم
🔹 دسترسی Agentها را امن کنیم
🔹چطور Workflowهای هوشمند بسازیم


@CodeVerse_dev

‏✨ اگه دنبال UIهای خاص برای پروژه‌ات هستی، اینو ببین!

سایت ObsidianUI یه مجموعه از کامپوننت‌های مدرن Reactـه که بیشتر تمرکزش روی انیمیشن، افکت‌های تعاملی، Cursor Effect، Scroll Interaction و طراحی‌های متفاوت و چشم‌گیره.

می‌تونی قبل از استفاده، کامپوننت‌ها رو به‌صورت زنده ببینی و بعد کدشون رو مستقیم وارد پروژه کنی و مطابق نیازت شخصی‌سازی کنی؛ مخصوصاً برای ساخت Landing Pageهای حرفه‌ای می‌تونه کلی ایده بهت بده. 🔥

📎 Website

@CodeVerse_dev

خبر مهم - React 19.2.8 منتشر شد

تیم React نسخه ۱۹.۲.۸ رو منتشر کرد که شامل چندین باگ‌فیکس مهم برای React Server Components (RSC) هست .

✅ تغییرات مهم:

· رفع مشکل Performance در RSC
· بهبود پایداری در Next.js 16.3
· رفع چندین باگ مربوط به Suspense

✅ آپدیت:

npm install react@19.2.8 react-dom@19.2.8

💡 اگر از Next.js 16.3 یا بالاتر استفاده می‌کنی، حتماً به این نسخه آپدیت کن. تیم Vercel هم تأکید کرده که این نسخه برای پروژه‌های پروداکشن توصیه میشه .

@CodeVerse_dev

ابزار کاربردی - معرفی tslog 5 برای لاگ‌گیری حرفه‌ای

ابزار tslog نسخه ۵ رو منتشر کرده، یه کتابخانه لاگ‌گیری سبک و بدون وابستگی که روی Node، Deno، Bun و حتی مرورگر کار می‌کنه .

✅ ویژگی‌های کلیدی:

· کاملاً ESM و TypeScript-first
· بدون هیچ وابستگی خارجی
· پشتیبانی از Structured Logging
· قابلیت Redaction برای اطلاعات حساس

✅ نصب و استفاده:

npm install tslog
typescript
import { Logger } from "tslog";
const log = new Logger({ name: "MyApp" });

log.info("سرور شروع به کار کرد", { port: 3000 });
log.error("خطا در اتصال به دیتابیس", { db: "users" });

💡 اگر از console.log خسته شدی و می‌خوای لاگ‌هات ساختارمند و حرفه‌ای باشن، tslog 5 یه انتخاب عالیه. برای پروژه‌های Node.js و Next.js فوقالعاده کار می‌کنه.

@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

🚨 یک 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