Intl DateTime Calendar
| 开发者 | sigmarubyz |
|---|---|
| 更新时间 | 2026年8月29日 18:01 |
| PHP版本: | 8.1 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
详情介绍:
Intl DateTime Calendar changes how dates are written on your site without changing what is stored. You pick a calendar. Your posts, archives and comments then show dates the way your readers write them. Every date stays in the database exactly as WordPress saved it. The machine readable date that search engines look for stays untouched.
What it does
- Any calendar system including Buddhist, Hijri, Hebrew, Persian, Japanese, Indian, Coptic, Ethiopic and Chinese
- Native digits so a Thai site can show ๔ พฤษภาคม ๒๕๖๘ and an Arabic site can show ٦ ذو القعدة ١٤٤٦
- Your existing date format is respected, including any custom format set on an individual block
- Where it counts on post dates, modified dates, comments and archives, and nowhere else. What a plugin stores is never touched
- Correct for search engines because the underlying datetime attribute stays Gregorian and unambiguous
- No database changes at all. Switching calendars or removing the plugin leaves your content untouched
安装:
- Upload the
intl-datetime-calendarfolder to/wp-content/plugins/ - Activate the plugin through the Plugins menu
- Go to Settings, then Intl DateTime Calendar
- Choose a calendar, and choose your digits if you want something other than your language default
屏幕截图:
常见问题:
Does this change what is stored in my database?
No. Only the text a visitor reads changes. Every date is stored exactly as WordPress stored it. You can switch calendars whenever you like. Removing the plugin puts everything back the way it was.
Will this hurt my SEO?
No. Each date keeps its machine readable HTML datetime value in the Gregorian calendar. Search engines read this value. Only the wording a person sees is converted.
Does it work with the block editor?
Yes. Dates in the Date block, Query Loop, comments and archives are all covered. This includes any custom format set on an individual block.
Can I use it in my theme?
Yes.
<?php if ( function_exists( 'intl_datetime_calendar_format_date' ) ) { echo intl_datetime_calendar_format_date( '2026-08-19' ); } ?>
You can pass a date string, a Unix timestamp or a DateTime object, and a second argument to choose the format.
Or use the shortcode in your content.
[intl_datetime date="2026-08-19" type="date"]
Can different languages use different calendars?
Yes. On a multilingual site each language can have its own calendar, so a Thai reader sees Buddhist years while an English reader on the same site sees Gregorian ones. Use the intl_datetime_calendar_calendar filter to set this up.
Another plugin reads dates from my pages and now gets confused. What do I do?
Only dates on their way to a page are converted. Scheduled jobs, REST and AJAX requests, feeds and the admin are left alone, so anything another plugin stores or compares stays Gregorian. If you still need to exclude something, use the intl_datetime_calendar_should_convert filter, or turn off server rendering on the settings page.
Can this break another plugin's data?
No. Only dates on their way to a page are converted. A plugin that stores a date, compares one, or formats one during a scheduled job gets the ordinary Gregorian value. If you write a plugin, prefer current_datetime() or get_post_datetime() for anything you intend to store, since those are not display functions in the first place.
What is the intl extension and do I need it?
It is a standard PHP extension that most hosts already provide. You do not strictly need it. However, with it, your dates are written before the page is sent instead of in the reader's browser. This is faster and works without JavaScript. Site Health tells you whether you have it.
更新日志:
2.0.3
Fixes a bug that could corrupt dates another plugin had stored. Update if you run 2.0.0, 2.0.1 or 2.0.2.
- Fix: Conversion applied to every date WordPress formatted, not only dates on their way to a page. A plugin calling
wp_date( 'Y-m-d' )to build a database key received a Buddhist Era year, and one calling it for a retention cutoff compared that against its Gregorian rows and deleted them - Fix: Conversion now happens on the display filters, which say a date is meant to be read, rather than on
wp_date, which says nothing about intent. Filtering by format alone cannot tell the two apart, because a site may set its date format toY-m-d - Fix: Scheduled jobs, REST and AJAX requests, XML-RPC, WP-CLI and feeds are left alone, so a job writing a date into a table cannot write a converted one
- Improvement: The settings screen now says which dates conversion applies to
wp_date() or date_i18n() directly are no longer converted. Use intl_datetime_calendar_format_date() for those.
2.0.2
- Fix: The preview on the settings page showed dates in your own admin language rather than the language your visitors read. On a site whose language differs from the editor's, it previewed months no visitor would ever see
- Improvement: The preview now names the language it is showing, so there is no doubt which one it means
- Fix: Switching the site to a language ICU has no data for, such as South Azerbaijani, Saraiki, Hazaragi or Northern Kurdish, brought down the front end with a critical error. Those languages now keep the dates WordPress itself produces, which are already translated
- Fix: A failed date formatter is no longer reused for the rest of the request, so one bad locale cannot repeat the failure on every date
- Fix: A site with no language set no longer builds an invalid locale
- Fix: A language with a region ICU does not carry now falls back to the language rather than giving up
- Fix: Formatting can no longer raise out of the plugin at all. A date that cannot be converted is left as WordPress wrote it
- Dates are now written on the server where the PHP intl extension is available. There is no longer a flash of Gregorian dates while the page loads. Dates are correct without JavaScript.
- Added a choice of digits covering every decimal numbering system Unicode defines. Thai, Arabic, Persian, Bengali, Devanagari, Khmer and many other sites can use their own numerals.
- Relative dates such as "3 days ago" are now translated instead of being left in English
- Added the
intl_datetime_calendar_format_date()function, which the FAQ has described since 1.0.2 but which was never actually included - Added a Site Health check reporting whether dates are converted on the server or in the browser
- Added the
intl_datetime_calendar_calendar,intl_datetime_calendar_locale,intl_datetime_calendar_numbering_systemandintl_datetime_calendar_should_convertfilters - Different languages can now use different calendars on a multilingual site
- Removing the plugin now cleans up its settings
- Dates from the shortcode were up to a day out on any site not set to UTC. They published a timezone offset that did not match the time beside it.
- Custom date formats were ignored. A format of
Y-m-dand a format ofd/m/Yboth produced the same output, and any text or separator in a format was discarded - A 12 hour format such as
h:i Aproduced output like08 PM:5 PM - Minutes and seconds lost their leading zero, so five past showed as
5rather than05 - Buddhist and Hijri dates leaked an era marker into numeric formats, giving
04/05/พ.ศ. 2568instead of04/05/2568 - Custom block formats were silently dropped for dates inside a Query Loop
- Impossible dates such as 31 February were quietly changed to a real date instead of being reported
- A date of 1 January 1970 was treated as invalid
- Month names now take the correct grammatical form in Russian, Czech, Polish, Catalan and other languages that inflect them
- Rendering could stop the page with a fatal error on a server without PHP's DOM extension
- Block markup containing
<picture>or<source>could be corrupted while dates were being processed - Three of the four block filters had never run, because the blocks they named do not exist in WordPress
- Requires PHP 8.1 and WordPress 6.5
- Block markup is now edited with WordPress's own HTML API instead of a regular expression and an HTML4 parser
- The settings page no longer uses an inline script
- The browser script is only loaded when the server cannot convert dates itself
- The minified script is now generated by a build step and checked automatically, instead of being maintained by hand
- Compatibility: Tested and confirmed working with WordPress 6.9
- Performance: Added settings caching to reduce database queries
- Performance: Added minified JavaScript for production environments
- Performance: Removed jQuery dependency. It now uses vanilla JavaScript.
- Feature: Added live date preview on settings page
- Feature: Added 6 new calendar systems (Dangi, Ethiopic Amete Alem, Islamic variants)
- Feature: Skip conversion for human-diff format elements
- Fix: Prevent repeated date conversions (elements now processed only once)
- Fix: Always use WordPress site language instead of browser language
- Code Quality: Refactored regex patterns as class constants
- Security: Added direct access prevention checks to all PHP files
- Security: Fixed authenticated (Contributor+) stored XSS vulnerability via date parameter (CVE-2025-8293)
- Security: Added comprehensive input sanitization for all date inputs
- Security: Added proper output escaping for all HTML attributes and content
- Security: Implemented validation for shortcode parameters
- Improvement: Enhanced date validation to prevent malformed input
- Renamed main plugin file to match WordPress.org naming convention (
intl-datetime-calendar.php)
- Initial release
- Support for 12 different calendar systems
- WordPress block editor integration
- Automatic locale detection
- WordPress date/time format integration
- SEO-friendly implementation
- Thai Buddhist calendar special handling