Patrick Lumumba

WP Corner

jfcby

The plugin gives you the ability to create tickets within WordPress to keep a record of bug reports or feature requests from people authorised to contribute in the WP Triage system. It is designed to not be overly complicated and keep the focus on collaborative resolutions.
The current features include but are not limited to:
<ul>
<li>Create projects, tickets, components and notes</li>
<li>Customise ticket details and assign them to users</li>
<li>Discuss tickets in the form of short notes (comments)</li>
<li>Sends emails to people when a ticket is being worked on</li>
<li>Filter projects and tickets based on their attributes</li>
<li>Configure how the trackers work with the roles manager</li>
</ul>
<h4>Support</h4>
Please create a new thread in the <a href="https://wordpress.org/support/plugin/wp-triage/" rel="ugc">plugin support forums</a> for support issues and feedback or raise an issue in the <a href="https://github.com/wpcorner/wp-triage/issues" rel="nofollow ugc">GitHub repository</a> for any bugs you may find.

WP Triage

An issue tracker for things that haven't gone to plan.

James Luberda

The Y2K Bug Simulator partially mimics one of the potential y2k failures that could (and did) affect some systems after December 31, 1999. The specific failure it mimics is one which typically occurred in systems where years were represented using two digits rather than four. Thus, in an affected system, the day after December 31, 1999 might be rendered as January 1, 1900 (in this scenario, only the last two digits of the year roll over, the first two are hard-coded as “19”).
The bug that this plugin mimics was certainly not the only y2k bug, nor, arguably, a terribly significant one. It is, however, perhaps the most aesthetically interesting. The effect of this plugin on WordPress is to change 20xx dates into 19xx dates across page titles, posts, and comments, as well as archives and calendars.
Some things to note:
<ul>
<li>By default, on initial activation following install, only admin-level users will see the effects of the plugin. This can be opened to all users, including non-logged ones, through the new Y2K settings page (new in 1.2).</li>
<li>The date modification occurs immediately after the plugin is installed and activated. It disappears immediately after the plugin is deactivated/uninstalled.</li>
<li>The change is at the presentation layer only. This means, among other things, that all stored site content and data remain unchanged. Moreover, site navigation is not affected. If you click on a link to a post identified as being from February 14, 1914, it will bring you to the post for February 14, 2014 (but still say 1914).</li>
<li>Internal date references are not affected. If you create a post/add a comment while the plugin is active, that content will not be stored with the modified date, but with the actual date, and will show that date when the plugin is deactivated/uninstalled.</li>
<li>Any plugins/templates/other content that do not utilize WordPress core functions for date presentation will not have their dates modified.</li>
</ul>

Y2K Bug Simulator

The Y2K Bug Simulator adds filters to most core WordPress functions that report back a date, rendering 19xx in place of 20xx.

WP Triage vs Y2K Bug Simulator