நீங்கள் ஒரு பதிவை நேரலையில் (live) வெளியிட்டவுடன், பொதுத் தளத்தில் அது “57 ஆண்டுகளுக்கு முன்பு” என்று காட்டப்படுவதையும், அதே சமயம் உங்கள் dashboard அது பத்து நிமிடங்களுக்கு முன்புதான் பதிவேற்றப்பட்டது என்று அமைதியாகக் கூறுவதையும் பார்த்திருந்தால், இந்த பிழையின் வேதனை உங்களுக்குத் தெரியும். இது தளத்தின் அமைப்பை (layout) சிதைப்பதில்லை. இது ஒரு মারাত্মক பிழையை (fatal error) உருவாக்குவதும் இல்லை. இது உங்கள் உள்ளடக்கத்தை (content) வெறும் அரை நூற்றாண்டு பழமையானதாக மாற்றிவிடுகிறது; உங்கள் theme கோப்புகளைத் தேடிப் பார்ப்பதன் மூலம் இந்த எண்ணை மாற்ற முடியாது.

இந்த சிக்கல் வழக்கமான சோதனைகளிலும் தப்பித்துவிடுகிறது. நீங்கள் single.php, archive.php, மற்றும் functions.php ஆகியவற்றில் சிதைந்த get_the_date() அழைப்பு ஏதேனும் உள்ளதா என்று grep மூலம் தேடுகிறீர்கள். அனைத்தும் சரியாகவே தெரிகின்றன. நீங்கள் நேரடிப் பக்கத்தைப் புதுப்பிக்கிறீர்கள் (reload). ஆனால் 1968-ன் நிழல் இன்னும் உங்கள் byline-இல்த் தொடர்கிறது. அந்த நிலையில், இந்தப் பிரச்சனை உங்கள் templates-உடன் எந்தத் தொடர்பும் இல்லை, மாறாக WordPress stack வழியாக நேரம் எவ்வாறு கடந்து செல்கிறது என்பதோடு மட்டுமே தொடர்புடையது.

அந்த குறிப்பிட்ட எண் ஏன் மீண்டும் மீண்டும் தோன்றுகிறது

“57 ஆண்டுகளுக்கு முன்பு” என்ற எண் தற்செயலானது அல்ல. WordPress themes பெரும்பாலும் human_time_diff() செயல்பாட்டின் மூலம் சார்பு நேரத்தை (relative time) காட்டுகின்றன. இது ஒரு பதிவின் timestamp-ஐ தற்போதைய நேரத்துடன் ஒப்பிட்டு, “2 hours ago” போன்ற ஒரு எளிமையான வாக்கியத்தை அச்சிடுகிறது. அந்த கணக்கீடு சரியாகச் செயல்பட, PHP-க்கு ஒரு சரியான Unix timestamp தேவை—அதாவது ஜனவரி 1, 1970 (Unix epoch) முதல் கடந்த வினாடிகளின் எண்ணிக்கை.

அந்தக் கணக்கீட்டிற்குச் செல்லும் முன் ஏதேனும் ஒன்று timestamp-ஐ நீக்கினாலோ அல்லது சிதைத்தாலோ, அந்தச் செயல்பாடு பெரும்பாலும் பூஜ்ஜியத்தை (அல்லது அது போன்ற ஒரு செல்லாத தொடக்கப் புள்ளியை) தற்போதைய நேரத்துடன் ஒப்பிடுகிறது. இதன் விளைவாக, சுமார் ஐந்து மற்றும் அரை தசாப்தங்கள் பின்னோக்கிச் செல்லும் ஒரு கால இடைவெளி உருவாகிறது, இது ஒவ்வொரு ஆண்டாக முன்னேறிச் செல்கிறது. இது ஒரு தரவுத்தளத்தில் பழைய பதிவுகள் இருப்பதன் அறிகுறி அல்ல, மாறாக ஒரு விடுபட்ட அல்லது தவறாகப் படிக்கப்பட்ட நேர மதிப்பின் அறிகுறியாகும்.

Dashboard ஏமாற்று வேலை

இந்த பிழையின் மிகவும் விரக்தியளிக்கும் அம்சங்களில் ஒன்று உங்கள் admin panel-ன் இரட்டைத் தன்மை (split personality) ஆகும். wp-admin உள்ளே, பதிவுகளின் பட்டியல் (Posts list) சரியான வெளியீட்டுத் தேதியைக் காட்டுகிறது, ஏனெனில் WordPress பெரும்பாலும் அதை நேரடியாக MySQL wp_posts அட்டவணையிலிருந்து எடுக்கிறது மற்றும் சார்பு நேர வடிகட்டி (relative-time filter) வழியாகச் செல்லாமல் சர்வர் பக்கத்திலேயே வடிவமைக்கிறது. இருப்பினும், frontend ஒரு theme அல்லது plugin-ஐச் சார்ந்து இருக்கலாம், அது human_time_diff() ஐ அழைக்கும், அல்லது அது தரவுத்தளத்தின் மூல மதிப்பை (raw database value) backend முற்றிலும் தவிர்த்துவிடும் PHP timezone மாற்றங்களின் தொடர்வழியாக அனுப்பலாம்.

எனவே தரவு பொதுவாகச் சரியாகவே இருக்கும். தரவுத்தளத்திற்கும் HTML உருவாக்கத்திற்கும் இடையிலான pipeline-இல் தான் ஒரு சிக்கல் ஏற்படுகிறது.

PHP பதிப்பு மற்றும் Timezone அமைப்புகள்

முதலில் PHP-யிலிருந்து தொடங்குங்கள். Hosting panels பதிப்பு மாற்றங்களைச் சாதாரணமானதாகக் காட்டலாம், ஆனால் PHP முக்கிய வெளியீடுகளில் (major releases) நேரப் பொருட்களை (time objects) வித்தியாசமாக கையாள்கிறது. திடீரென PHP 8.1 சூழலில் இயங்கும் ஒரு தளம், பழைய PHP 7.4 குறியீட்டைப் பயன்படுத்தும்போது, DateTime objects காலியான அல்லது சிதைந்த சரங்களை (strings) எவ்வாறு தொட khởiவுபடுத்துகின்றன என்பதில் நுட்பமான மாற்றங்களைச் சந்திக்கலாம். உங்கள் php.ini கோப்பில் date.timezone வரையறுக்கப்படவில்லை என்றால், PHP இயல்பாக UTC-ஐ எடுத்துக்கொண்டு, சர்வர் சொல்வதே சரியானது என்று கருதும். WordPress இதை ஏற்காமல் போகலாம்.

wp-config.php-க்குள் யாராவது timezone அறிவிப்பை hardcode செய்துள்ளார்களா என்று சரிபார்க்கவும். date_default_timezone_set( 'Asia/Kolkata' ); போன்ற ஒரு வரி உதவியாகத் தோன்றலாம், ஆனால் WordPress Settings > General என்பதன் கீழ் அமைக்கப்பட்ட மதிப்பின் மூலம் தனது சொந்தக் கடிகாரத்தை நிர்வகிக்க எதிர்பார்க்கிறது. PHP மட்டத்தில் ஒரு offset-ஐக் கட்டாயப்படுத்துவது ஒரு race condition-ஐ உருவாக்கலாம், அங்கு core நேரத்தை உள்ளூர் நேரமாகக் கருதும், ஆனால் PHP அதை உலகளாவிய நேரமாகக் கருதும். ஒரு timestamp மாற்றத்தின் போது இந்த மாற்றங்கள் மோதும்போது, உங்கள் template-க்குத் திரும்பக் கிடைக்கும் முடிவு பூஜ்ஜியமாகச் சுருங்கிவிடக்கூடும்.

சர்வர் Time Zone உள்ளமைப்புகள்

உங்கள் MySQL சர்வர் அதன் சொந்த உள்ளூர் நேரக் கருத்தைக் கொண்டுள்ளது. WordPress ஒவ்வொரு பதிவிற்கும் இரண்டு தேதிகளை எழுதுகிறது: தளத்தின் உள்ளூர் நேரத்தில் post_date, மற்றும் Universal Time-இல் post_date_gmt. ஒரு migration-க்குப் பிறகு தரவுத்தளத்தின் உலகளாவிய time_zone மாறினால்—உதாரணமாக, SYSTEM-லிருந்து +00:00-க்கு மாறினால்—PHP-யின் strtotime() சேமிக்கப்பட்ட சரத்தை அது எதிர்பார்க்கும் வடிவத்துடன் ஒத்திசைக்கத் தவறலாம். தரவுத்தளம் இன்னும் 2024-03-15 14:30:00 என்பதைச் சேமித்திருக்கலாம், ஆனால் அதைச் சுற்றியுள்ள சூழல் மாறுகிறது, இதனால் PHP-யில் parsed output தவறாக அல்லது null ஆக மாறுகிறது.

நிஜ உலக உதாரணம்: ஒரு managed host உங்கள் தரவுத்தளத்தை SYSTEM நேரத்துடன் கூடிய MySQL 5.7 இயங்கும் ஒரு node-லிருந்து, கண்டிப்பான UTC-க்கு அமைக்கப்பட்ட MariaDB 10.11 இயங்கும் ஒரு cluster-க்கு மாற்றுகிறது. உங்கள் theme மாறவில்லை. உங்கள் WordPress அமைப்புகளும் மாறவில்லை. இருப்பினும், get_the_time( 'U' )—அதாவது Unix timestamp வடிவம்—சில பதிவுகளுக்குத் திடீரென ஒரு காலியான மதிப்பைத் தருகிறது, மேலும் சார்பு நேரச் செயல்பாடு அந்த epoch-zero கணக்கீட்டிற்குத் திரும்புகிறது. இதற்கான தீர்வு, application timezone, database timezone மற்றும் operating system clock ஆகியவற்றைச் சரியாகச் சீரமைப்பதாகும், இதனால் WordPress எந்தக் குறிப்புச் சட்டகத்தைப் (frame of reference) பயன்படுத்த வேண்டும் என்று யூகிக்க வேண்டிய அவசியம் இருக்காது.

Database Timestamp வடிவங்கள்

WordPress core, post dates-களை MySQL DATETIME காலம்களில் சேமிக்கிறது, TIMESTAMP புலங்களில் அல்ல. இந்த வேறுபாடு முக்கியமானது, ஏனெனில் பழைய MySQL பதிப்புகளில் DATETIME என்பது கால மண்டல விழிப்புணர்வு (timezone awareness) இன்றி ஒரு நாட்காட்டி மதிப்பை மட்டுமே கொண்டுள்ளது, ஆனால் TIMESTAMP பின்புலத்தில் அனைத்தையும் UTC-க்கு மாற்றுகிறது. ஒரு பிளகின் அல்லது இடம்பெயர்வு கருவி (migration tool) உங்கள் wp_posts ஸ்கீமாவை மாற்றியிருந்தால், அல்லது ஒரு பழைய காப்புப்பிரதி (backup) அட்டவணையில் தவறான பூஜ்ஜிய தேதிகளை மீட்டெடுத்திருந்தால், WordPress 0000-00-00 00:00:00 போன்ற ஒரு மதிப்பை வாசித்து அதை அமைதியாக உங்கள் தீமிற்கு (theme) அனுப்பிவிடும்.

நவீன MySQL முறைகள், குறிப்பாக NO_ZERO_DATE மற்றும் STRICT_TRANS_TABLES, அந்த பூஜ்ஜிய இடப்பற்றுகளை (zero placeholders) நிராகரிக்கின்றன. ஒரு இடம்பெயர்வின் போது காப்புப்பிரதி ஸ்கிரிப்ட் அவற்றைச் சேர்த்திருந்தால், இறக்குமதி செய்யும் போது தரவுத்தளம் அவற்றை வெட்டியிருக்கலாம் அல்லது null ஆக மாற்றியிருக்கலாம். இதை ஒரு நேரடி SQL வினவல் (query) மூலம் நீங்கள் விரைவாகச் சரிபார்க்கலாம்:

SELECT ID, post_title, post_date, post_date_gmt 
FROM wp_posts 
WHERE post_status = 'publish' 
ORDER BY post_date DESC 
LIMIT 10;

மூலக் காலம்கள் (raw columns) சரியாகத் தெரிந்தாலும், இணையதளம் இன்னும் பழைய காலத் தகவல்களைக் காட்டினால், அந்தச் சிதைவு வினவலுக்குப் பிறகு நிகழ்கிறது என்று அர்த்தம். காலம்களிலேயே பூஜ்ஜியங்கள் இருந்தால், நீங்கள் அதன் மூலப் பிழையைக் கண்டறிந்துவிட்டீர்கள்.

Plugin Conflicts with Date Functions

தேதி வெளியீட்டை வடிகட்டும் பிளகின்கள் பொதுவான காரணிகளாக இருக்கின்றன. WPML அல்லது Polylang போன்ற பலமொழி கருவிகள் மாதப் பெயர்களை மொழிபெயர்க்க get_the_date-உடன் இணைகின்றன. Caching பிளகின்கள் இறுதி HTML-ஐ இடைமறிக்கின்றன. இந்த இரண்டு அடுக்குகளில் ஏதேனும் ஒன்று, ஒரு Unix integer-ஐ எதிர்பார்க்கும் செயல்பாட்டிற்குத் தெரியாமல் ஒரு வடிவமைக்கப்படாத சரத்தை (unformatted string) அனுப்பக்கூடும்.

ஒரு மொழிபெயர்ப்பு பிளகின் “March 15, 2024” என்பதை அதன் உள்ளூர்மயமாக்கப்பட்ட வடிவத்திற்கு மாற்றலாம், ஆனால் ஒரு தீம் அந்த உள்ளூர்மயமாக்கப்பட்ட சரத்தை ஒரு தனிப்பயன் செயல்பாட்டிற்குள் (custom function) strtotime() மூலம் அனுப்பினால், ஆங்கிலம் அல்லாத எழுத்துக்களால் அந்தப் பகுப்பாய்வி (parser) தோல்வியடைந்து 'false' என்பதைத் திருப்பித் தரும். அந்த 'false' மதிப்பு human_time_diff() செயல்பாட்டிற்குச் செல்லும்போது, அது பூஜ்ஜியத்தை தற்போதைய நேரத்துடன் ஒப்பிட்டு, புகழ்பெற்ற அரை நூற்றாண்டு கால இடைவெளியை உருவாக்குகிறது.

Object cache அடுக்குகள் இதை மேலும் சிக்கலாக்குகின்றன. Redis அல்லது Memcached, தேதியை பகுப்பாய் செய்வதில் தற்காலிகமாகத் தோல்வியடைந்த ஒரு கோரிக்கையிலிருந்து (request) பெறப்பட்ட ஒரு serialized WP_Post ஆப்ஜெக்ட்டைச் சேமித்து வைக்கலாம். அதன் பிறகு வரும் ஒவ்வொரு பார்வையாளரும் தரவுத்தளத்தைத் தவிர்த்துவிட்டு, நேரடியாக RAM-லிருந்து அந்தச் சிதைந்த ஆப்ஜெக்ட்டையே பெறுவார்கள். உங்கள் production stack-ல் உள்ள cache உள்கட்டமைப்பு உங்கள் local install-ல் இல்லாததால், இந்தச் சிக்கல் நேரடித் தளத்தில் (live site) தொடர்கிறது.

A Practical Debugging Checklist

இந்த அறிகுறி மென்பொருள் அடுக்குகளின் ஆழத்தில் மறைந்திருப்பதால், தேதிகள் சரியான நிலைக்குத் திரும்பும் வரை நீங்கள் அடுக்குகளை முறையாக நீக்க வேண்டும்.

  1. தரவுத்தளத்தை நேரடியாகக் கண்டறியவும் (Query the database directly). phpMyAdmin-ஐத் திறக்கவும் அல்லது WP-CLI மூலம் இயக்கி, மூல post_date மதிப்புகளைச் சரிபார்க்கவும். அவை சரியாக இருந்தால், தரவுத்தளம் பிரச்சனை அல்ல.
  2. இயல்புநிலை தீமிற்கு மாறவும் (Switch to a default theme). Twenty Twenty-Four அல்லது Twenty Twenty-Three-ஐச் செயல்படுத்தவும். பிழை மறைந்துவிட்டால், உங்கள் தற்போதைய தீம் மற்றும் child theme-களில் நேர வெளியீட்டைச் சுற்றியுள்ள தனிப்பயன் செயல்பாடுகளைச் சரிபார்க்கவும்.
  3. பிளகின்களை முடக்கவும் (Silence the plugins). /wp-content/plugins கோப்புறையின் பெயரைத் தற்காலிகமாக மாற்றவும் அல்லது டேஷ்போர்டில் உள்ள அனைத்து பிளகின்களையும் முடக்கவும். அவற்றை ஒவ்வொன்றாக மீண்டும் செயல்படுத்தி, ஒவ்வொரு முறை செயல்படுத்திய பிறகும் இணையதளத்தின் முன் பகுதியை (frontend)ச் சரிபார்க்கவும்.
  4. பிழைப் பதிவைப் படிக்கவும் (Read the error log). Timezone எச்சரிக்கைகள், DateTime பிழைகள் அல்லது strtotime() தொடர்பான புகார்களைத் தேடவும். அவை பெரும்பாலும் துல்லியமான