تاریخ شمسی در وردپرس و ووکامرس: کجا میلادی می‌ماند و چطور درستش کنی

وردپرس تقویم شمسی ندارد. اگر زبان پیشخوان را فارسی کنی، تاریخ فقط فارسی نوشته می‌شود و همچنان میلادی است: سفارشی که یازدهم شهریور آمده، در پنل «۲ سپتامبر ۲۰۲۶» نشان داده می‌شود. برای شمسی شدن یک افزونه تاریخ شمسی لازم است، و بیشتر فروشنده‌ها همین‌جا کار را تمام‌شده می‌دانند.

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

کدام افزونه تاریخ شمسی وردپرس را نصب کنی

اگر دنبال اسم آمده‌ای، دو افزونه در مخزن رسمی وردپرس از بقیه پرنصب‌ترند. تا امروز، ۹ مهر ۱۴۰۵، هر دو بیش از ۱۰۰ هزار نصب فعال دارند:

• پارسی دیت (Parsi Date) — تاریخ وردپرس را شمسی می‌کند و می‌گوید با ووکامرس هم کار می‌کند: سفارش‌ها، محصولات و اطلاعات مشتری.
• ووکامرس فارسی (Persian WooCommerce) — وردپرس و ووکامرس را فارسی و شمسی می‌کند و می‌گوید گزارش‌ها و بخش تجزیه و تحلیل ووکامرس را هم شمسی می‌کند.

یکی را انتخاب کن، نه هر دو. نصبش سه قدم است:

1. در پیشخوان به «افزونه‌ها» و بعد «افزودن» برو و اسم افزونه را جستجو کن.
2. «نصب» و بعد «فعال‌سازی» را بزن.
3. در «تنظیمات» و بعد «عمومی» (در بعضی ترجمه‌ها «همگانی»)، منطقه زمانی را روی «تهران» بگذار و ذخیره کن.

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

افزونه تاریخ شمسی وردپرس واقعا چه کار می‌کند

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

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

این معماری در واقع درست است. تاریخ باید یک‌جور ذخیره شود و چندجور نمایش داده شود. مشکل جای دیگری است: هر جایی که تاریخ را بدون آن تابع بسازد — در مرورگر با جاوااسکریپت، با کد مستقیم یک افزونه دیگر، یا در فایلی که برای دانلود ساخته می‌شود — از زیر دست افزونه در می‌رود. تاریخ شمسی یکی از چند قطعه‌ای است که ووکامرس برای بازار ایران از خودش ندارد؛ نقشه کامل ووکامرس برای بازار ایران بقیه قطعه‌ها را می‌شمارد.

کجاها میلادی می‌ماند

اگر این جدول را یک بار روی سایت خودت تیک بزنی، بیشتر غافلگیری‌های آخر ماه را جلوتر دیده‌ای:

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

جاهایی که باید عمدا میلادی بمانند

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

اگر افزونه‌ای این‌ها را هم شمسی کند، هیچ خطایی نمی‌بینی ولی همه چیز غلط می‌شود. ماشینی که تاریخ «۱۴۰۵-۰۷-۰۹» را بخواند، آن را سال ۱۴۰۵ میلادی می‌فهمد — ششصد و چند سال پیش — و بی‌صدا با همان کار می‌کند. سه آزمون یک‌دقیقه‌ای:

• نشانی سایتت را با /feed در انتهایش باز کن. تاریخ هر مطلب باید با اسم روز و ماه انگلیسی باشد.
• اگر افزونه سئو داری، سورس یک نوشته را باز کن و دنبال datePublished بگرد. سالش باید با «۲۰» شروع شود.
• اگر اپ یا پل حسابداری وصل است، آخرین سفارشی را که به آن رسیده ببین. تاریخش باید همان روز واقعی باشد، نه سالی عجیب.

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

تله اصلی: منطقه زمانی و سه ساعت و نیم بعد از نیمه‌شب

این جدی‌ترین بخش این نوشته است، چون خطایش در هیچ صفحه‌ای دیده نمی‌شود و فقط در جمع آخر ماه خودش را نشان می‌دهد.

تهران سه ساعت و نیم از زمان جهانی جلوتر است. یعنی از نیمه‌شب تا سه و نیم صبح، تاریخ تهران یک روز جلوتر از تاریخ جهانی است: سفارشی که ساعت یک بامداد دهم مهر ثبت شده، در زمان جهانی هنوز در نهم مهر است. تا وقتی همه قطعه‌ها این اختلاف را یک‌جور حساب کنند، مشکلی نیست. خرابی از جایی شروع می‌شود که یکی حساب خودش را بکند، و این دو شکل دارد:

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

نشانه هر دو یکی است: گزارش فروش ماه در پنل با حسابداری چند سفارش فرق دارد و هیچ‌کس نمی‌فهمد چرا، چون هر دو طرف «درست» کار کرده‌اند. و این اختلاف روز آخر ماه گران می‌شود، چون سفارش از یک ماه به ماه دیگر می‌رود. حسابداری ووکامرس نشان می‌دهد این اختلاف در پل حسابداری کجا می‌نشیند.

چرا «تهران»، نه یک اختلاف ثابت

در تنظیمات عمومی وردپرس، منطقه زمانی را می‌شود با اسم شهر انتخاب کرد یا با یک اختلاف ثابت. شهر تهران را انتخاب کن. ایران از ۱۴۰۲ ساعت تابستانی ندارد و امروز هر دو یک عدد می‌دهند، ولی تاریخ‌های سال‌های قبل در نیمه اول سال اختلاف چهار ساعت و نیم داشتند و فقط اسم شهر این تاریخچه را می‌شناسد.

همان صفحه کنار منطقه زمانی، «زمان محلی» را هم نشان می‌دهد. با ساعت گوشی‌ات مقایسه کن. اگر در شش ماه اول سال یک ساعت جلوتر بود، اطلاعات منطقه زمانی روی سرور قدیمی است و هنوز ساعت تابستانی حساب می‌کند. این را میزبان سایت باید درست کند، نه تو با عوض کردن عدد. اگر الان نیمه دوم سال است، ساعت ثبت یکی از سفارش‌های تابستان امسال را با رسید درگاهش مقایسه کن.

«ماه قبل» در گزارش، شاید ماه میلادی باشد

بازه‌های آماده گزارش‌های ووکامرس، مثل این ماه و ماه قبل و سه‌ماهه، در خود ووکامرس بر مبنای تقویم میلادی‌اند. شمسی شدنشان بسته به افزونه است؛ بعضی، مثل ووکامرس فارسی، می‌گویند تجزیه و تحلیل را هم شمسی می‌کنند — با آزمون پایین مطمئن شو. ماه میلادی حدود دهم ماه شمسی شروع می‌شود، پس اگر «ماه قبل» میلادی مانده باشد، بخشی‌اش یک ماه شمسی است و بخشی ماه بعدی.

آزمونش یک دقیقه است: بازه «ماه قبل» را بزن و ببین اولین روزش اول ماه شمسی است یا حدود دهم آن.

برای هر گزارشی که به حسابدار یا اداره مالیات می‌رود، بازه را دستی بده: اول و آخر ماه یا فصل شمسی را یک بار به میلادی تبدیل کن، یادداشتش کن، و هر بار همان را بزن.

تله دوم: دو افزونه که هر دو ترجمه می‌کنند

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

نتیجه‌اش تاریخ‌های عجیبی است که نه شمسی‌اند نه میلادی، و معمولا فقط در یک صفحه خاص دیده می‌شوند — مثلا فقط در فاکتور چاپی. پیدا کردنش سخت است چون بقیه سایت درست است.

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

تله سوم: تاریخی که به متن تبدیل شده

بعضی افزونه‌ها هنگام ساخت فاکتور، تاریخ را به‌شکل متن داخل سند ذخیره می‌کنند. از آن لحظه، آن تاریخ دیگر تاریخ نیست، یک رشته حروف است.

یعنی اگر بعدا افزونه تاریخ شمسی را عوض کنی یا منطقه زمانی را اصلاح کنی، آن سندهای قدیمی اصلاح نمی‌شوند. برای اسناد مالی این در واقع رفتار درستی است — فاکتور نباید بعدا عوض شود — ولی باید بدانی که هست، وگرنه دنبال باگی می‌گردی که وجود ندارد.

همین ماجرا در افزونه‌هایی که جدول خودشان را دارند — پیامک، باشگاه مشتریان، فرم، نوبت‌دهی — شکل بدتری دارد. بعضی‌شان تاریخ شمسی را به‌شکل متنی مثل «۱۴۰۵/۷/۹» ذخیره می‌کنند. متن را نمی‌شود درست مرتب کرد: «۱۴۰۵/۱۰/۱» در مرتب‌سازی متنی قبل از «۱۴۰۵/۷/۹» می‌آید، چون «۱» از «۷» کوچک‌تر است، و دی‌ماه قبل از مهر می‌نشیند. فیلتر بازه هم روی چنین ستونی جواب درست نمی‌دهد. قبل از اینکه به گزارش چنین افزونه‌ای تکیه کنی، یک بار خروجی‌اش را بگیر و ببین تاریخ در آن عدد استاندارد است یا متن.

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

هر جای ووکامرس که تاریخ وارد می‌کنی — انقضای کد تخفیف، زمان‌بندی انتشار محصول، بازه گزارش — یک تقویم دارد. افزونه‌های شمسی این تقویم‌ها را هم عوض می‌کنند، ولی نه همه‌شان را.

و یک رفتار آزاردهنده که در بعضی‌شان هست: وقتی تاریخی را وارد کردی، راهی برای خالی کردنش نداری. مثلا کد تخفیفی که یک بار تاریخ انقضا گرفته، دیگر نمی‌تواند بی‌انقضا شود مگر با پاک کردن و ساختن دوباره‌اش. قبل از ثبت انبوه کد تخفیف، این را یک بار تست کن.

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

افزونه تاریخ شمسی وردپرس را چطور امتحان کنی

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

1. فقط یکی. افزونه دوم را حذف کن، و ببین قالب و افزونه فاکتورت تبدیل داخلی دارند یا نه.
2. جاهایی که لازم داری. فهرست سفارش، صفحه یک سفارش، ایمیل سفارش، تقویم ویرایشگر، و تاریخ کد تخفیف و حراج را یکی‌یکی باز کن.
3. خروجی ماشینی دست‌نخورده. فید و داده ساختاریافته باید میلادی مانده باشند.
4. نشانی‌ها دست‌نخورده. گزینه شمسی کردن پیوند یکتا خاموش بماند.
5. آزمون خاموش کردن. افزونه را غیرفعال کن. جز شکل نمایش تاریخ نباید چیزی عوض شود. اگر نشانی‌ها عوض شدند یا جایی خطا داد، افزونه به چیزی بیش از نمایش دست زده است.
6. زنده بودن. ببین آخرین به‌روزرسانی‌اش کی بوده و با نسخه وردپرس و ووکامرس تو سازگار اعلام شده یا نه. صفحه سفارش‌های ووکامرس در نسخه‌های تازه بازنویسی شده، و افزونه رهاشده همین صفحه‌ها را جا می‌اندازد.

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

چک‌لیست

1. منطقه زمانی را روی شهر تهران بگذار، نه روی اختلاف عددی، و «زمان محلی» را با ساعت خودت مقایسه کن
2. فقط یک افزونه تاریخ شمسی داشته باش، و قالب و افزونه فاکتور را هم چک کن
3. یک خروجی اکسل بگیر و ببین تاریخش شمسی است یا میلادی
4. دو سفارش آزمایشی بده، یکی بعد از نیمه‌شب و یکی بعد از هشت و نیم شب، و تاریخ هر دو را در پنل، خروجی و حسابداری ببین
5. فید سایت و داده ساختاریافته را باز کن و مطمئن شو میلادی مانده‌اند
6. اگر پیوند یکتا سال و ماه دارد، مطمئن شو شمسی نشده
7. گزارش ماه را با بازه دستی شمسی بگیر، نه با بازه آماده
8. یک فاکتور قدیمی را باز کن و ببین تاریخش با تغییر تنظیمات عوض می‌شود یا نه

جمع‌بندی

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

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