PHP 8.2 எச்சரிக்கைகள் எவ்வாறு WordPress கருவிகளை முடக்கின (மேலும் அதை எவ்வாறு சரிசெய்வது)

ஒரு ஏமாற்றமளிக்கும் சூழ்நிலையைக் கற்பனை செய்து பாருங்கள்: உங்கள் மல்டி-சைட் WordPress பராமரிப்பு கருவி அனைத்தும் சரியாக உள்ளது என்று புகாரளிக்கிறது—அனைத்து diagnostics-களும் தேர்ச்சி பெறுகின்றன, WP-CLI இணைப்பு வேலை செய்கிறது, பதிப்பு சரிபார்ப்பு பச்சையாகத் திரும்புகிறது—ஆனால் அது உண்மையான இயக்கத்தைச் செய்யும்போது, முழு விஷயமும் தோல்வியடைகிறது. "அனைத்து சோதனைகளும் தேர்ச்சி பெறுகின்றன, ஆனால் புரொடக்ஷன் முடங்குகிறது" என்பதை நீங்கள் காண்கிறீர்கள். ஜூலை 4, 2026 அன்று, இந்தச் சரியான சிக்கல் DEV Community-இல் உள்ள ஒரு பதிவில் ஆவணப்படுத்தப்பட்டது, மேலும் மென்பொருள் எவ்வாறு தோல்வியடைகிறது என்பதைப் பற்றி இது முக்கியமான ஒன்றை வெளிப்படுத்துகிறது: சில நேரங்களில் தேர்ச்சி பெறும் diagnostic-க்கும் தோல்வியடையும் இயக்கத்திற்கும் இடையிலான இடைவெளி ஒரு நுட்பமான கட்டமைப்புச் சிக்கலை மறைக்கிறது.

சிக்கல்: எச்சரிக்கைகள் உங்கள் JSON-ஐ மாசுபடுத்துகின்றன

பழைய WP-CLI 2.x ஆனது PHP 8.2 அல்லது புதிய பதிப்பில் இயங்கும்போது, எதிர்பாராத ஒன்று நடக்கிறது. PHP 8.2 ஒரு புதிய deprecation எச்சரிக்கையைச் சேர்த்துள்ளது: ஒரு கிளாஸ் வெளிப்படையாக அனுமதிக்காவிட்டால், அதில் உள்ள ஒரு டைனமிக் பிராப்பர்ட்டிக்கு உங்களால் மதிப்பை ஒதுக்க முடியாது, அதற்கான #[\AllowDynamicProperties] attribute தேவைப்படுகிறது. பழைய WP-CLI—இது இன்னமும் உட்புறமாக dynamic properties-ஐப் பயன்படுத்துகிறது—இந்த எச்சரிக்கைகளைத் தொடர்ந்து தூண்டுகிறது. அது மட்டுமே ஒரு பேரழிவு அல்ல. எச்சரிக்கைகள் வெறும் எச்சரிக்கைகளே. கோட் இன்னமும் இயங்குகிறது.

உண்மையான பிரச்சனை உங்கள் சர்வரின் php.ini configuration-லிருந்து வருகிறது. பொறுத்து display_errors அமைப்பைப் பொறுத்து, அந்த எச்சரிக்கைகள் நேரடியாக stdout-க்கு அச்சிடப்படுகின்றன—உங்கள் JSON தரவு தோன்றும் அதே வெளியீட்டு ஸ்ட்ரீம் தான் இது.

எனவே நீங்கள் இது போன்ற ஒரு கட்டளையை இயக்கும் போது wp plugin list --format=json சுத்தமான JSON-ஐ எதிர்பார்க்கிறீர்கள், ஆனால் அதற்கு பதிலாக இதுபோன்ற ஒன்றைப் பெறுகிறீர்கள்:

PHP Deprecated: Creation of dynamic property WP_CLI\Dispatcher\CompositeCommand::$longdesc is deprecated... [ {"name":"akismet","status":"active","update":"none"...}, ... ]

JSON வரிசைக்கு (array) முன் உள்ள அந்த எச்சரிக்கை வரி முறிக்கிறது json_decode(). உங்கள் கருவி அதை பாகுபடுத்த (parse) முயல்கிறது, தோல்வியடைந்து, செயலிழக்கிறது.

பரிசோதனைகள் (Diagnostics) ஏன் பொய் சொல்கின்றன

இதில் உள்ள தந்திரமான பகுதி இதுதான்: diagnostics-களும் உண்மையான இயக்கமும் வேறுபட்ட விஷயங்களைச் சோதிப்பதால், diagnostics தேர்ச்சி பெறக்கூடும் ஆனால் உண்மையான இயக்கம் தோல்வியடையும்.

நீங்கள் ஒரு SSH இணைப்புச் சோதனையை இயக்கும் போது—உதாரணத்திற்கு, echo ok—சோதனையானது வெளியீட்டில் எங்காவது "ok" தோன்றும் என்று மட்டுமே சரிபார்க்கிறது. கூடுதல் வரிகள் இருந்தாலும் பரவாயில்லை. நீங்கள் இயக்கும் போது wp --version, சோதனையானது ஒரு பதிப்பு எண்ணை மட்டுமே தேடுகிறது. அது கிடைத்துவிட்டதா? தேர்ச்சி.

ஆனால் நீங்கள் இயக்கும் போது wp plugin list --format=json, உண்மையான இயக்கம் பாகுபடுத்துகிறது (parses) வெளியீட்டை JSON ஆக. எளிய உரை சோதனைகள் புறக்கணிக்கும் எச்சரிக்கைகள் திடீரென்று முக்கியமாகின்றன. JSON-ஐ உண்மையாக JSON ஆக பாகுபடுத்தாத ஒரு diagnostic ஒருபோதும் இந்தச் சிக்கல் வருவதைக் காண்பதில்லை.

இதனால்தான் பயனர் "எனது அனைத்து சோதனைகளும் பச்சையாக உள்ளன, ஆனால் உண்மையான அழைப்பு தோல்வியடைகிறது" என்பதைக் காண்கிறார்—diagnostics எதைச் சரிபார்க்கிறது என்பதற்கும் உண்மையான இயக்கத்திற்கு என்ன தேவை என்பதற்கும் இடையே உள்ள ஏமாற்றமளிக்கும் சமச்சீரற்ற தன்மை இது.

மூன்று அடுக்கு பாதுகாப்பு

நீங்கள் அனைத்து எச்சரிக்கைகளையும் உலகளவில் அடக்க (suppress) முயற்சிக்கலாம், ஆனால் ஒவ்வொரு ஹோஸ்டிங் வழங்குநரின் PHP configuration-ஐயும் உங்களால் கணிக்க முடியாது. மாறாக, இந்தத் தீர்வு மூன்று சுயாதீனமான பாதுகாப்பு அடுக்குகளைப் பயன்படுத்துகிறது. ஒன்று சத்தத்தைப் பிடிக்கத் தவறினால், அடுத்தது பிடிக்கும்.

அடுக்கு 1: மூலத்திலேயே எச்சரிக்கைகளை அமைதியாக்குங்கள்

WP-CLI என்ற சுற்றுச்சூழல் மாறியை (environment variable) ஏற்கிறது WP_CLI_PHP_ARGS இது அடிப்படை PHP அழைப்புக்கு அனுப்பப்படுகிறது. இதைச் சரிசெய்ய நீங்கள் இதனைப் பயன்படுத்தலாம் error_reporting நிலையை, Deprecated மற்றும் User Deprecated எச்சரிக்கைகளைப் புறக்கணிக்குமாறு PHP-யிடம் கூறுகிறது:

php WP_CLI_PHP_ARGS="-d error_reporting='E_ALL ~E_DEPRECATED ~E_USER_DEPRECATED'"

இந்த தொடரியல் (syntax) ~E_DEPRECATED "Deprecated எச்சரிக்கைகளை விலக்கு" என்பதாகும். நீங்கள் இன்னமும் Parse Errors மற்றும் Fatal Errors-ஐக் காண்பீர்கள்—அவை உண்மையான தோல்விகள்—ஆனால் சத்தம் அடக்கப்படுகிறது.

இந்த அடுக்கு பெரும்பாலான ஹோஸ்டிங் சூழல்களுக்கு வேலை செய்கிறது. ஒரு ஹோஸ்ட் கூடுதல் ரன்டைம் மேலெழுதல்களை (runtime overrides) சேர்க்காத போது, எச்சரிக்கைகள் ஒருபோதும் stdout-க்கு வருவதில்லை.

அடுக்கு 2: பாகுபடுத்துவதற்கு முன் சத்த வரிகளை நீக்குங்கள்

ஆனால் சில ஹோஸ்ட்கள் தீவிரமானவை. அவை தங்கள் PHP ஸ்கிரிப்ட்களில் இயக்குகின்றன ini_set() , மேலெழுதி (overriding) error_reporting வழியாக அமைத்த பிறகு ரன்டைமில் WP_CLI_PHP_ARGS. எச்சரிக்கைகள் எப்படியோ ஊடுருவி விடுகின்றன.

ஆழமான பாதுகாப்பிற்கு, JSON-ஐ பாகுபடுத்த முயற்சிப்பதற்கு முன், வெளியீட்டிலிருந்து அங்கீகரிக்கப்பட்ட சத்த வரிகளை regex-match செய்து அகற்றலாம்:

python PHP_NOISE_LINE_RE = re.compile( r'^\sPHP\s+(Deprecated|Warning|Notice|Strict Standards):.$', re.MULTILINE | re.IGNORECASE )

def strip_php_noise(text): return PHP_NOISE_LINE_RE.sub('', text)

இந்த regex எதைப் பொருத்தவில்லை என்பதைக் கவனியுங்கள்: "Parse error" மற்றும் "Fatal error." அவை உண்மையான தோல்விகள், வெறும் சத்தம் அல்ல. இந்த நோக்கம் கொண்ட விடுபடல் முக்கியமானது. நீங்கள் தொந்தரவுகளை அகற்ற விரும்புகிறீர்கள், ஆனால் உண்மையான முறிவுகளை அனுமதிக்க விரும்புகிறீர்கள்.

அடுக்கு 3: எக்சிட் கோடுகளை நம்புவதற்கு முன் JSON பாகுபடுத்தலை முயற்சிக்கவும்

எச்சரிக்கைகள் வெளிவந்தது என்பதற்காக மட்டுமே சில ஹோஸ்ட்கள் எக்சிட் கோட் 1-ஐ (தோல்வி) திருப்புகின்றன—செல்லுபடியாகும் JSON stdout-இல் இருந்தாலும் கூட. சரிபார்க்காமல் பூஜ்ஜியமற்ற எக்சிட் கோடில் வெளியேறினால், அங்கு உள்ள தரவை நீங்கள் இழக்கிறீர்கள்.

மாறாக, முதலில் stdout-லிருந்து JSON-ஐ பாகுபடுத்த முயற்சி செய்யுங்கள், பிறகு எக்சிட் கோடைச் சரிபார்க்கவும்:

python stdout_clean = strip_php_noise(res.stdout or '').strip() plugins = None

if stdout_clean: try: plugins = json.loads(stdout_clean) except json.JSONDecodeError: plugins = None

if plugins is None: # Only here do we give up if not res.ok: return error_response(res.stderr or res.stdout)

JSON பாகுபடுத்தப்பட்டால், எக்சிட் கோட் வேறுவிதமாகக் கூறினாலும் அழைப்பை வெற்றிகரமாகக் கருதுங்கள். கட்டமைக்கப்பட்ட தரவே முக்கியமானது.

இதை உங்கள் கோடில் எவ்வாறு பயன்படுத்துவது

படி 1: அமைதியான PHP வாதங்களுடன் (Quiet PHP Args) WP-CLI அழைப்புகளை மடிக்கவும்

சுற்றுச்சூழல் மாறியை முன்னொட்டாகச் சேர்க்கும் ஒரு ஹெல்பரை உருவாக்கவும்:

python def wp_with_quiet_php(wp_cli_path): quiet_args = "-d error_reporting='E_ALL ~E_DEPRECATED ~E_USER_DEPRECATED'" return f"WP_CLI_PHP_ARGS='{quiet_args}' {wp_cli_path}"

படி 2: JSON பாகுபடுத்தலுக்கு முன் Stdout-ஐ சுத்தம் செய்யவும்

முயற்சிப்பதற்கு முன் எப்போதும் சத்த வரிகளை அகற்றவும் json.loads():

python output = run_command(wp_with_quiet_php(wp_path) + ' plugin list --format=json') clean_output = strip_php_noise(output.stdout).strip() if clean_output: plugins = json.loads(clean_output)

படி 3: எக்சிட் கோடிற்கு முன் JSON இருக்கிறதா எனச் சரிபார்க்கவும்

முதலில் பாகுபடுத்தலை முயற்சி செய்யுங்கள். பாகுபடுத்தல் தோல்வியடைந்தால் மட்டுமே எக்சிட் கோடை நம்புங்கள்:

python if plugins is None and not result.ok: raise Exception(result.stderr or result.stdout)

படி 4: அனைத்து அழைப்பு இடங்களையும் (Call Sites) சரிசெய்யவும்

அழைக்கும் ஒவ்வொரு இடத்தையும் உங்கள் கோட்பேஸில் தேடுங்கள் json.loads() WP-CLI வெளியீட்டில். எல்லா இடங்களிலும் அதே மூன்று அடுக்கு பாதுகாப்பைப் பயன்படுத்துங்கள். சரிசெய்யப்படாத ஒரு அழைப்பு இடம் வேறு கோட் பாதையில் பாதிப்பை ஏற்படுத்தக்கூடியதாக விட்டுவிடும்.

படி 5: சோதனைகளை எழுதுங்கள்

இவற்றைச் சரிபார்க்கும் ரிஃக்ரெஷன் சோதனைகளை (regression tests) சேர்க்கவும்:

• சத்த வரி அகற்றுதல் சரியாகச் செயல்படுகிறது
• Parse errors மற்றும் Fatal errors ஆகியவை அகற்றப்படவில்லை என்பதையும்
• சுற்றுச்சூழல் மாறி மேற்கோள் (quoting) பாதுகாப்பானது
• மூன்று API எண்ட்பாயிண்ட்களும் இந்த தீர்வைப் பயன்படுத்துகின்றன

எதிர்கால டெவலப்பர் அழைக்கும் நான்காவது API-ஐச் சேர்த்தால் json.loads() நேரடியாக அசல் வெளியீட்டில் (raw output), சோதனைகள் உடனடியாகத் தோல்வியடைய வேண்டும்.

2026-இல் இது ஏன் முக்கியமானது

நாம் ஒரு மாற்றக் காலத்தில் இருக்கிறோம். PHP 8.2 மற்றும் 8.3 ஆகியவை இப்போது பல ஹோஸ்டிங் வழங்குநர்களில் தரநிலையாக உள்ளன, ஆனால் பல பழைய WordPress செருகுநிரல்களும் (plugins) கருவிகளும் இன்னமும் புதுப்பிக்கப்படவில்லை. WP-CLI 2.x பரவலாகப் பயன்படுத்தப்படுகிறது. "கோட் இன்னமும் இயங்குகிறது" என்பதற்கும் "வெளியீடு பாகுபடுத்துவதற்கு போதுமான அளவு சுத்தமாக இருக்கிறது" என்பதற்கும் இடையிலான இடைவெளி உண்மையானது, மேலும் இது எளிய diagnostics-க்கு புலப்படுவதில்லை. அதிகமான குழுக்கள் கட்டமைக்கப்பட்ட வெளியீடுகளை (JSON API-கள், பதிவுக் குழாய்கள் (logging pipelines), ஆட்டோமேஷன்) ஏற்றுக்கொள்ளும்போது, நூலகங்கள் நவீனமயமாக்கப்படும் வரை இந்த வகையான பிழை—எச்சரிக்கைகள் தரவு ஸ்ட்ரீமை நச்சுப்படுத்தும் இடம்—தொடர்ந்து வெளிப்படும்.

முடிவுரை

உண்மையான பாடம் WordPress அல்லது PHP 8.2-க்கு மட்டுமே உரியது அல்ல. இது சுயாதீனமான பாதுகாப்புகளை அடுக்குவது மற்றும் சரியான சுருக்க நிலையில் (abstraction level) சோதிப்பது பற்றியது. Diagnostics "சப்ஸ்ட்ரிங் தோன்றுகிறதா" என்பதை மட்டுமே சரிபார்க்கும்போது, பாகுபடுத்தும் கட்டத்தில் மட்டுமே தோன்றும் தோல்விகளை அவை இழக்கின்றன. நீங்கள் உலகளவில் எச்சரிக்கைகளை அமைதியாக்கும்போது, உண்மையான பிழைகளை மறைக்கும் ஆபத்து உள்ளது. தரவை விட எக்சிட் கோடுகளை நீங்கள் நம்பும்போது, இன்னமும் முக்கியத்துவம் வாய்ந்த செல்லுபடியாகும் வெளியீட்டை இழக்கிறீர்கள்.

மூன்று அடுக்கு தீர்வு—மூலத்திலேயே அடக்குதல், பாகுபடுத்துவதற்கு முன் வடிகட்டுதல், மற்றும் எக்சிட் கோடுகளை விட கட்டமைக்கப்பட்ட தரவுக்கு முன்னுரிமை அளித்தல்—வேலை செய்கிறது ஏனெனில் ஒவ்வொரு அடுக்கும் வெவ்வேறு தோல்விப் பயன்முறையைப் பிடிக்கிறது. ஒரு அடுக்கு தோற்றால், அடுத்தது அதைப் பிடிக்கும்.

நன்மைகள்

• புலப்படாத தோல்விகளைப் பிடிக்கிறது. Diagnostics இப்போது அறிகுறிகளை மட்டுமல்ல, உண்மையான சிக்கலையும் கண்டறிய முடியும்.
• ஆழமான பாதுகாப்பு (Defense in depth). எந்தவொரு ஒற்றை ஹோஸ்டிங் கோளாறும் கருவியை முடுக்காது; பல அடுக்குகள் வெவ்வேறு கசிவு பாதைகளைப் பிடிக்கின்றன.
• உண்மையான பிழைகளைப் பாதுகாக்கிறது. Parse errors மற்றும் Fatal errors இன்னமும் வெளிப்படும்; சத்தம் மட்டுமே வடிகட்டப்படுகிறது.
• ஏற்கனவே உள்ள WP-CLI உடன் இயங்குகிறது. பழைய கருவியைப் புதுப்பிக்கவோ அல்லது மாற்றவோ தேவையில்லை; தீர்வு அதைச் சுற்றி அடுக்கப்படுகிறது.
• சோதிக்கப்படக் கூடியது. ஒவ்வொரு அடுக்கையும் சுயாதீனமாக சோதிக்க முடியும்; பின்னடைவுகள் (regressions) ஆரம்பத்திலேயே கண்டறியப்படுகின்றன.

குறைபாடுகள்

• சிக்கலை அதிகரிக்கிறது. ஒன்றுக்கு பதிலாக மூன்று அடுக்குகள் என்பது பராமரிக்கவும் புரிந்துகொள்ளவும் அதிக கோட் தேவை என்பதைக் குறிக்கிறது.
• Regex நொறுங்கும் தன்மை (brittleness). சத்தத்தை வடிகட்டும் regex எதிர்கால PHP பதிப்புகளில் அறிமுகப்படுத்தப்படும் புதிய எச்சரிக்கை வடிவங்களைத் தவறவிடக்கூடும்.
• மூலக் காரணத்தை சரிசெய்யாது. இவை மாற்று வழிகள் (workarounds) மட்டுமே, நவீன WP-CLI அல்லது PHP இணக்கத்தன்மைக்கான புதுப்பிப்புகள் அல்ல.
• தவறான எதிர்மறைகள் (False negatives) சாத்தியம். எதிர்கால PHP பதிப்பு அதன் பிழை செய்தி வடிவத்தை மாற்றினால், regex அதை பொருத்திப் பார்க்காது.

எச்சரிக்கை

இந்த கட்டுரை கல்வி நோக்கத்திற்கானது. கோட் உதாரணங்களைப் பயன்படுத்தும் போது, ஏதேனும் பிளேஸ்ஹோல்டர் மதிப்புகளை (எடுத்துக்காட்டாக wp_cli_path அல்லது கட்டளை பாதைகள்) உங்கள் உண்மையான சுற்றுச்சூழல் மதிப்புகளுடன் மாற்றவும். முதலில் புரொடக்ஷன் அல்லாத சூழலில் முழுமையாகச் சோதிக்கவும். புரொடக்ஷனில் அவற்றை நம்புவதற்கு முன் DEV Community-இல் உள்ள அசல் மூலப் பொருளுடன் அனைத்து கோரிக்கைகளையும் உதாரணங்களையும் சரிபார்க்கவும். குறிப்பிட்ட error_reporting கொடிகள் (flags) மற்றும் regex வடிவங்கள் இணக்கத்தன்மையை உறுதிப்படுத்த உங்கள் சொந்த PHP மற்றும் WP-CLI பதிப்புகளுக்கு எதிராக சோதிக்கப்பட வேண்டும்.

அடிக்கடி கேட்கப்படும் கேள்விகள்

• PHP 8.2-இல் டைனமிக் பிராப்பர்ட்டி deprecation என்றால் என்ன?
• எனது ஹோஸ்டில் display_errors செயலாக்கப்பட்டுள்ளதா (enabled) என்பதை நான் எவ்வாறு சரிபார்ப்பது?
• இந்த மாற்று வழிகளைப் பயன்படுத்துவதற்குப் பதிலாக நான் WP-CLI-ஐ மேம்படுத்த முடியுமா?
• எளிய எக்சிட் கோட் சோதனைகள் ஏன் இந்தச் சிக்கலைப் பிடிப்பதில்லை?
• எனது JSON பாகுபடுத்தல் சத்தத்திற்கு எதிரானது (noise-resistant) என்பதை நான் எவ்வாறு சோதிப்பது?
• வேறு எந்த கட்டளை வெளியீடுகளில் அதே எச்சரிக்கை-மாசுபாடு சிக்கல் இருக்கக்கூடும்?
• அனைத்து PHP எச்சரிக்கைகளையும் நான் உலகளவில் முடக்க வேண்டுமா?
• ஒரு எச்சரிக்கையை வடிகட்டுவது பாதுகாப்பானதுதானா என்பதை நான் எவ்வாறு அறிவது?

குறிச்சொற்கள்

#php #wordpress #wpcli #json #devops #errors #automation #hosting