Make WordPress Core

Opened 12 months ago

Closed 2 months ago

Last modified 2 months ago

#39165 closed enhancement (wontfix)

Add page to assist with debugging and support

Reported by: jorbin Owned by: Clorith
Milestone: Priority: normal
Severity: normal Version:
Component: General Keywords:
Focuses: Cc:


Often, there is information that we want to know from people reporting issues. A simple page that includes info such as versions of software, extensions, dropins used, mu-plugins, etc could help with debugging and support.

Attachments (15)

39165.patch (6.9 KB) - added by Clorith 3 months ago.
first pass sreenshot.png (190.8 KB) - added by Clorith 3 months ago.
39165.diff (7.7 KB) - added by flixos90 3 months ago.
39165.2.patch (9.8 KB) - added by Clorith 3 months ago.
39165.3.patch (10.5 KB) - added by birgire 3 months ago.
39165.4.patch (15.1 KB) - added by Clorith 2 months ago.
table-striped.JPG (39.2 KB) - added by birgire 2 months ago.
Example screenshot: striped + header
toc.jpg (37.5 KB) - added by birgire 2 months ago.
Example screenshot: table of content (by default the notice-box is using javascript for top position)
39165.5.patch (16.0 KB) - added by Clorith 2 months ago.
filter-example.jpg (48.6 KB) - added by birgire 2 months ago.
Filter example - Screenshot
39165.6.patch (22.4 KB) - added by Clorith 2 months ago.
39165.7.patch (24.0 KB) - added by michalzuber 2 months ago.
Add Filesystem permissions section and additional WP constants ABSPATH, WP_HOME and WP_SITEURL
39165.7.2.patch (22.7 KB) - added by birgire 2 months ago.
39165.8.patch (24.4 KB) - added by Clorith 2 months ago.
39165.9-cron-jobs.patch (25.3 KB) - added by michalzuber 2 months ago.
Try cron jobs https://i.imgur.com/HU7SA6u.jpg

Download all attachments as: .zip

Change History (64)

#2 @lukecavanagh
12 months ago


So something similar to WooCommerce has with System Status.

#3 @johnbillion
12 months ago

Query Monitor's Environment section also has some info that's probably useful too.

#4 @ideag
5 months ago

Any way I could help? We talked about this at WCEU contributions day, so I know there is some work being done on this. I'd like to help with this, because I think that's an awesome idea.

#5 @Clorith
5 months ago

  • Owner set to Clorith
  • Status changed from new to assigned

What information is of importance to you as a supporter, we're already looking at inspiration from plugins like WooCommerce and Query Monitor, but that may not cover all scenarios.

Also, what information is of relevance to you as a user that you may need in general (like checking on a requirement in an easier manner)

The idea is to create a directly (for admins) accessible info.php in core, much like the current options.php.

Thoughts for consideration, should the page be hookable so that plugins can use it as well for certain debug data, to avoid having multiple locations for looking up information when looked at from a users perspective?

#6 @Clorith
4 months ago

#41487 was marked as a duplicate.

#7 @michalzuber
4 months ago

I like the suggestions:

  1. info.php
  2. "should the page be hookable so that plugins can use it as well for certain debug data, to avoid having multiple locations for looking up information"

The subpage could contain Report a bug button and submit system data.

Last edited 4 months ago by michalzuber (previous) (diff)

This ticket was mentioned in Slack in #core-php by rabmalin. View the logs.

4 months ago

#9 follow-up: @SergeyBiryukov
3 months ago

#41763 was marked as a duplicate.

#10 in reply to: ↑ 9 @danieltj
3 months ago


Ah, I didn't see this ticket, sorry. Yeah I'm very much in support of this idea. Would be very useful to include this in Core so there is a central place for debugging etc.

I'll see if I can get some kind of mockup of some kind.

3 months ago

#11 @Clorith
3 months ago

First pass at an info page, the fields aren't finalized yet, as it's still of interest to get some input on what data is of interest (bringing this up in the weekly support chat as well), and an easy to use copy field should also be added I think, but it may require some more considerations as you may not want to copy all the information that you'd normally show to a site owner when it's meant to just be pasted for support without a second thought.

Screenshot attached as well showing the current output from the patch before the copy field is introduced.

Also adds in the proposed filter for plugins and themes to add their own information. I opted to not include the core information in this filter, as we don't want anything to change the base information for a site.

3 months ago

#12 @flixos90
3 months ago

39165.diff changes the following:

  • Add some information about the size of the setup (particularly for multisite): User Count, Site Count, Network Count
  • Wrap some strings into __()
  • Fix to deprecated notices when calling get_bloginfo( 'home' ) and get_bloginfo( 'siteurl' )

Let's keep in mind that the is_super_admin() check should also be replaced with an actual capability before eventual merge (see #37616). But I didn't bother doing that yet, since this is only a draft at this point.

Furthermore regarding the information, I think the array should be using actual keys and have the field labels translatable. But again, not yet important for the draft.

#13 @Clorith
3 months ago

I agree that the array should have keys (which will actually be somewhat needed to introduce a private, or similar, option to hide some fields from the copy-paste field.

I must admit that having the labels translatable hadn't crossed my mind, that one is a bit difficult, as in many situations you want debug information to be identical regardless of what language is used. I recall a discussion, I think it was the Japanese community, that mentioned that translating technical terms and jargon was a bad experience. Would love some input on that aspect of it but am totally open to making them translatable if there's a wish for it.

This ticket was mentioned in Slack in #forums by clorith. View the logs.

3 months ago

#15 @fierevere
3 months ago

transport can be fsockopen() as well, not just cURL, openssl version linked with PHP (extension openssl) is important then

and maybe add indication of FS_METHOD constant

3 months ago

#16 @Ipstenu
3 months ago

A language tweak:

'description' => __( 'The options shown below are relating to your server setup, and may require the help of your host if changes are required.' ),

Should be more like:

'description' => __( 'The options shown below relate to your server setup. If changes are required, you may need your web host's assistance.' ),

Breaking up the sentences for clarity :)

#17 @Clorith
3 months ago

So 39165.2.patch moves it over to an associated array as mentioned, and introduces the optional private boolean field which will prevent text from showing in the textarea for copy-pasting (in the example, site URLs and database information are set to private).

Some discussions on translations occurred as well, what are the thoughts on Label (Translated label), this ensures the field is understandable by as many as possible, yet helps the site owner with clarity as they can get the label in their own language as well?

#18 follow-up: @zodiac1978
3 months ago

I would like to see some more info. max_input_vars for example (there are issue with the small default value 1000 and it pops up from time to time in the forums) and I would like to see if the PHP is 32 Bit or 64 Bit, because it could cause issues too (try absint with a veeeery large id on a 32-bit PHP)

Would it be useful to collect plugins which already do this? There are plenty of those in the plugin directory ...

#19 @fierevere
3 months ago

Some people ask images related questions, it will be nice to see if "imagick" extension is present on their server, or WP_Image_Editor fallbacks to GD

#20 @rabmalin
3 months ago

I would like to see upload_max_filesize of PHP ini settings also.

#21 @birgire
3 months ago

Here are few suggestions:

  • Seperate the list of plugins into active- and inactive plugins. Usually when debugging we need to see list of active plugins, so I think this separation would make it easier for the user.
// List all available plugins
$plugins = get_plugins();

foreach ( $plugins AS $plugin_path => $plugin ) {

        $key = ( is_plugin_active( $plugin_path ) ) ? 'Active plugins' : 'Inactive plugins';

        $info[$key]['fields'][] = array(
                'label' => $plugin['Name'],
                'value' => sprintf( 'Version %s by %s', $plugin['Version'], $plugin['Author'] )
  • Change "Other themes" to "Available themes", because I understand "Other" to be the list of all themes, excluding the active theme.
  • I like how it's done in WooCommerce Status, where we get the number of active plugins too. So I suggest a show_count attribute:
'Available themes'     => array(
       'fields'        => array(),
       'show_count'    => true
'Must Use Plugins' => array(
       'fields'        => array(),
       'show_count'    => true
'Active plugins'          => array(
       'fields'        => array(),
       'show_count'    => true
'Inactive plugins'          => array(
        'fields'        => array(),
        'show_count'    => true

and then e.g. when printing out values:

if( isset( $details['show_count'] ) && (bool) $details['show_count'] ) {
        '<h2>%s (%d)</h2>',
        esc_html( $section ),
        count( $details['fields'] )
} else {
         esc_html( $section )

So instead of these headings:

Other themes
Must Use Plugins

we have:

Available themes (32)
Must Use Plugins (1)
Active plugins (15)
Inactive plugins (88)

I'm working on this patch.

I like the private fields, that are not available in the copy/paste code, since users might post this on public forums.

This means we could also add e.g. the installation path as a private field.

Last edited 3 months ago by birgire (previous) (diff)

3 months ago

2 months ago

#22 @Clorith
2 months ago

39165.4.patch implements proper keyed arrays, translatable strings (let's leave it up to the various languages to determine how to display technical terms and such).

It also includes the key count from @birgire, and the fields mentioned by others in the ticket as useful to include.

The is_super_admin() check has also been replaced with a capability check, in our case update_core, as a very reliable rule for someone who has the access expected when being privy to any technical information about the site setup.

2 months ago

Example screenshot: striped + header

#23 @birgire
2 months ago

Thanks for the update @Clorith

just few additional ideas/remarks that come to mind:

  • Table header (optional) ? See table-striped.JPG
  • Striped table for easier read, i.e. alternating odd/even background? See table-striped.JPG
  • "Not defined" vs "Undefined" (I like the latter more)
  • If multisite is active then what about an extra multisite table?
  • Table Of Contents - for easier navigation? (horizontal or vertical)
  • "Go to the top of the document" links?
  • How to close the copy&paste field again?
  • Mention that the private info is excluded in the copy&paste field?
  • Could we avoid constants like TEMPLATEPATH and WP_PLUGIN_DIR in favor of functions?
  • The "Active theme" is included in "Other themes" (exclude it there?)
Last edited 2 months ago by birgire (previous) (diff)

2 months ago

Example screenshot: table of content (by default the notice-box is using javascript for top position)

2 months ago

#24 @Clorith
2 months ago

Excellent feedback there.

  • Table headers I'm not super fond of, since the data is very varied in a listing such as this.
  • Multisite already does add a new table if enabled :)
  • Closing the copy-field again was left out to avoid having multiple actionable items at once (much like WooCommerce does it as well)

39165.5.patch addresses the changes I am on board with:

  • Striped tables are a must for distinguishing rows, that's going right in there.
  • I agree that Undefined sounds better, so replacing those strings.
  • I also like your inclusion here of a ToC like quick-link bar along the top, I was a bit skeptical at first but they actually seem rather useful and your concept image really helped nail that down.
  • Back to top links, if a ToC is added there will definitely need to be one of those to help with navigation.
  • Moved the memory limit field, it was shown in the WordPress section still
  • The TEMPLATEPATH constant we can use the function for instead, as it's filterable it makes sense, but WP_PLUGIN_DIR doesn't have a similarly associated function (unless I'm missing something)
  • Active theme should be filtered out from the general list of available themes, I agree, good catch.
  • I've added a little section outlining that some information may not be included in the copy-field as it is considered private and should not be posted on public forums, but I'm not the best at using my words. It has the string Some information may be filtered out from the list you are about to copy, this is information we consider private, and is not meant to be shared in a public forum.

This ticket was mentioned in Slack in #core by clorith. View the logs.

2 months ago

#26 @SergeyBiryukov
2 months ago

  • Milestone changed from Awaiting Review to 4.9

#27 @schlessera
2 months ago

Such a page would be hugely beneficial.

Some additional information I would love to see:

  • IPv6 support
  • active mysqli driver
  • active drop-ins
  • maybe permissions for the main folders?

Also, I was thinking it might be better still if the page could generate an expiring link that will display this at the frontend. This would allow you to copy this link and provide it to the support rep you're talking to. If the link contains an expiring token, the security risk should be minimal.

#28 @Clorith
2 months ago

What would IPv6 support look like, the only thing I could think of here is if you are browsing the site over IPv6 your self?

The other three points are very valid, adding those now.

As for expiring links, that doesn't help over time, having the copy and paste field at the top is better here when users can put information right into their support topic or whatnot without the support giver being tied in to a time limit (if you post on the forums looking for help for example, there's no guarantee someone will click your link in the next X hours for it to remain valid).

#29 in reply to: ↑ 18 @zodiac1978
2 months ago

Replying to zodiac1978:

Would it be useful to collect plugins which already do this? There are plenty of those in the plugin directory ...

Maybe this list is useful to find some more approaches on this topic:

Last edited 2 months ago by zodiac1978 (previous) (diff)

#30 @birgire
2 months ago

@Clorith thanks for the detailed feedback. Here are some minor adjustments:

  • I get extra indentation for the first section (because the PHP tags are not like <textarea><?php and ?></textarea>). Maybe this was the intention for the first section?:
    		### WordPress ###
    Version: 4.9-alpha-41375
    Language: en_US
  • The string 'version %1$s by %2$s' is not translatable for wp-themes, because of missing __().
  • We might want to wrap <p> tags around <?php esc_html_e( 'Some information may be filtered ...
  • In "### %s%S ###\n\n" I noticed the capital %S.
  • Sometimes AS and sometimes as in foreach loops.

Some other ideas:

  • Replace <a href="#system-information-table-of-contents">... with <a href="#">... to go to the top of the document?
  • Find a way to have the headings in view (hidden under the wp-admin-bar) when using named anchors
  • Float the "Return to table of contents" links to the right (or left for rtl)
  • Copy to clipboard without displaying the textarea? (might invovle cross-browser implementation issues?)
  • Maybe the string can be simplified to "Private information has been filtered out from the list you are about to copy." ?

Then there's the accessibility to consider (like screen-reader-text etc)

I played with the new filter:

$external_info = apply_filters( 'debug_information', array() );

// Merge the core and external debug fields
$info = array_merge( $external_info, $info );

with this demo:

add_filter( 'debug_information', 'warp_drive_debug_information' );

function warp_drive_debug_information ( $info ) {
	$info['warp-drive-info'] = array(
		'label'  	=> __( 'Warp Drive', 'startrek' ),
		'description' 	=> __( 'Data from the Enterprise Engine Room', 'startrek' ),
        	'show_count' 	=> true,
		'fields' 	=> array(
                		'label' => __( 'Core status', 'startrek' ),
                		'value' => __( 'Stable', 'startrek' )
        		        'label' => __( 'Warp factor', 'startrek' ),
                		'value' => rand( 1, 10 )
	return $info;	

and we can see in the screenshot here below how it's added on top of the core info.

Maybe some plugins will adjust the priority to stay on top?

I wonder if the external info should be added after the core info?

2 months ago

Filter example - Screenshot

#31 @birgire
2 months ago

Thanks for the links @zodiac1978

I just checked out the RS System Diagnostic plugin, it has some interesting info and features.

It showed additonally e.g.

  • Permalink Structure
  • Browser info for the current viewer
  • Both "WP Memory Limit" and "WP Admin Memory Limit"
  • Loaded PHP Extensions
  • PHP Allow URL File Open
  • PHP Allow URL File Incl
  • ... more

I also checked out the BSI System Info plugins, it showed additionally e.g.:

  • Default Timezone
  • Operating System
  • ... more

Regarding extending the System Information page:

  • Should there be extra hooks for those who want to extend it, with features like download CSV button or send by email (like offered in the RS System Diagnostic plugin ). Currently it's not possible to add HTML, like a download button, in a section via the debug_information filter. If we allow extra HTML sections to be added after the info, e.g. via some action, then wouldn't it be nice to have that extra section in the ToC too?
  • Should there be a private section, like private field?

This ticket was mentioned in Slack in #forums by mjassen. View the logs.

2 months ago

2 months ago

#33 @Clorith
2 months ago

in 39165.6.patch :

  • Get active drop-ins
  • Attempts to get server OS and architecture if possible
  • MySQL client is included when possible
  • Add check for function existing (being enabled) before using non-core functions, this avoids fatal errors
  • Fixed the priority ordering, core sections come first
  • Fixed text area indents on the first line
  • Added permalink structure
  • Added a private field to the section as well as single fields
  • Floated the back to ToC link based on language direction

I've also introduced a new section, *PHP Information*, this is essentially phpinfo() being output within wp-admin. It includes a notice about the information contained in that page, it is intended for all those weird edge cases where there's that one specific setting you need to know about that wouldn't make sense to include in the debug output in the first place.

Basically that new "page" is there to not overload the normal debugging process with edge case scenario data, and instead allow individual developers to request information from specific fields in those rare cases.

As for some of the input provided:
Automatically copying text to the clipboard isn't possible, or rather, the API for it isn't there yet, those sites that do have this feature use a flash-polyfill where the clipboard is populated by a flash-video, it's a terrible hack and not worth it.

Linking to just # takes you to the very top of the page, that's counter intuitive both for regular users, and screen reader users who might need it to jump between sections, it is much more logical to take you back to the table of contents list (although if I'm incorrect and there's a11y improvements to be had I'm all ears).

Extra hooks, I'm on the fence about, it's a debug page, the copy-field should really be enough for most situations, I'm not convinced the need to send them by email from within wp-admin is a legitimate purpose (and is more likely to get you picked up by a spam filter than anything else I'm afraid).

2 months ago

Add Filesystem permissions section and additional WP constants ABSPATH, WP_HOME and WP_SITEURL

2 months ago

#34 @birgire
2 months ago

I like the idea with phpinfo(), but some host providers and users, disable phpinfo() with disable_functions in php.ini.

In that case$phpinfo_raw contains:

Warning: phpinfo() has been disabled for security reasons in ...

39165.7.2.patch handles:

  • if phpinfo() is disabled
  • if it's disabled, the phpinfo link in the header is removed
  • if it's disabled, then /wp-admin/info.php?phpinfo shows the notice "The phpinfo() function is disabled.".
  • extra index checks on $styles[1][0]}} and {{{$phpinfo[1][0].

Here I used a function_exists( 'phpinfo' ) check, but I wonder if that's enough or if we need to check inside: ini_get( 'disable_functions' )? See e.g. here for discussions.

ps: I didn't noticed the last patch 39165.7.patch, so I didn't include it here.

Last edited 2 months ago by birgire (previous) (diff)

2 months ago

#35 @Clorith
2 months ago

Good catch on the phpinfo() being disabled in some scenarios @birgire, and good idea on the file system section @michalzuber

I've consolidated the two into a single patch (39165.8.patch) with some more verbiage and restructuring of some fields.

As for the function_exists(), this accounts for things disabled via ini files I thought, although I could be wrong?

#36 @birgire
2 months ago


That sounds useful.

I think your new wp-filesystem section should be all private, or at least those fields that contain paths.

The strings 'writable' and 'not writeable' (maybe 'unwriteable'?) would need to be translateable too.

@Clorith I just did a quick test on PHP 7.0.16 and it seems that function_exists() will spot disabled phpinfo().

#37 @michalzuber
2 months ago

Thank you. Nice job guys. Patch 39165.9-cron-jobs.patch contains my cron jobs listings try. I added cron jobs, because they are kinda hidden magic in WP for me and listing them is really revealing. Knowing what background actions are triggered.

While working on cron jobs I came across EMPTY_TRASH_DAYS constant which I also added.

#38 @ocean90
2 months ago

I'm not yet convinced that this should be part of core.

Idea: Get https://wordpress.org/plugins/health-check/ back to life and include such a page into the plugin. The plugin would be some sort of an official plugin by the support team which gets actively promoted in the support forums.
If it turns out that this is super helpful we still can consider adding this to core, even if it's only in a form of "Install the Health Check plugin to get information about your installation" button that automatically installs the plugin. Take importers as an example.

Pinging @pento since he's the only active person listed as a contributor and committer. Could we get this on GitHub so others can contribute?

Other related plugins are https://wordpress.org/plugins/background-update-tester/ and https://wordpress.org/plugins/core-control/ from @dd32. Maybe these can also be part of Health Check? 🤔

#39 @pento
2 months ago

  • Milestone 4.9 deleted
  • Resolution set to wontfix
  • Status changed from assigned to closed

I agree with @ocean90, this isn't right for core.

Putting it in the Health Check plugin is a good step, that was always the intention of that plugin.

I've put Health Check on GitHub, you should move the development work from this ticket over there. @Clorith, you can add collaborators to that repo as you see fit, and I've added you as a committer to the plugin on w.org. Go wild. :-)

#40 @knutsp
2 months ago

Agree with ocean90. Put the effort into a "all-in-one" plugin. Have a one-click install from a core page, that transforms into a real health check page once installed.

The core page should just check that plugins can be installed. If not, explain why and a way to rectify. Otherwise, just show the install button.

Because core should just do core things, useful for most users.
A plugin can be updated more frequently, even during a support session, a few hours or a day.

#41 follow-up: @zodiac1978
2 months ago

As a supporter/moderator I disagree. As a plugin we can't rely on it being there. That's bad and costs time.

And the WP importer is a good example that a plugin is not the best way. Forgotten, not reliable, missing features, etc.

Because core should just do core things, useful for most users.

According to this argument there shouldn't be a page like options.php and I don't think this is the case here BTW.

Frequent updates is an advantage, that's true, but the disadvantage of not included in core weighs much more IMHO.

#42 @Clorith
2 months ago

@zodiac1978 View it sort of like a feature project, we get to test the waters, a better way to see the needs. As @ocean90 mentioned we can always revisit the idea of core later, either by inclusion or as a single-click install.

It's not correct to directly compare it to the importer, the importer doesn't have a "team" behind it, while anything support related has a chunk of the community behind it to help move it forward and stay on top of things (fwiw: There are ideas floating around for the importer as well).

I would of course have preferred to have it as a part of core, so that everyone had a single location to reference for debug information, but I'm more than happy to approach it as a plugin first and take things from there as they appear (also gives us more flexibility with release and iterate, much better for ironing out what is needed for example).

#43 in reply to: ↑ 41 @ocean90
2 months ago

Replying to zodiac1978:

And the WP importer is a good example that a plugin is not the best way. Forgotten, not reliable, missing features, etc.

This can also apply to core features. I was also referring to the installation process not the plugins themselves.

#44 @Mte90
2 months ago

Many plugins implement a status page like WooCommerce to get stats about the system.
So this is an example that developers need to reimplement this things for their needs and improve the support or debug.
For me it will be better to have in the core and enabled (show) automatically when WP_DEBUG is turned on. In that way users doesn't need to install a plugin to use it only for fix a problem and developers need to ask to them to install another plugin (often there are systems where is not possible).
So developers can force the constant or with a new filter to show the panel and avoid another plugin.
After all is only showing systems stats that can be very helpful and we avoid to have a specific plugin for debugging when there are different and start a war about how is the best or is more standard for this feature.
Usually all the CMS or web software has a page included about internal stats like for permissions and WordPress is the only one without it.
Sure can be a feature plugin to develop with the plan to merge it in the future but not a separate plugin like for the importer that the use case are very few instead of a system page.

#45 @xkon
2 months ago

This wasn't just for developers AFAIC. The idea is to avoid simple users going into wp-config.php as well to enable WP_DEBUG since most of the times the next question would be 'What is FTP?'

If you see it clearly from a support point of view a 'user' needs to do 2 clicks and return with the information needed to the developer that supports him/her without having to go back and forth to enable a siple informational screen. I see it the same with the debug.log.

Having it as a Plugin for the time being ( even forever as well ) makes a lot more sense as more things could be easily implemented or changed and pushed on production for anyone to have access to. Plus a plugin has pretty much the same steps on getting it installed & activated than having it built in as well, no major difference there, it's just 1 extra click and a search nothing more.

#46 @zodiac1978
2 months ago

Of course we can go this feature plugin route, but without the intention of merging it into core, this makes no sense at all. Why should I build *another* plugin to do that task? There are already plenty of them: https://core.trac.wordpress.org/ticket/39165#comment:29

And imagine this support question:
"I have problems with installing plugins." - "Okay, we need more details about your setup, please inst..." Oops. ;)

#47 @PeterBooker
2 months ago

Looking through the top 10 plugins by active installs, half contain similar functionality. Those that do contain it have a clear interest in actively improving user experiences inside WordPress. As opposed to those which do not like Akismet which is mostly an external service and Limit Login Attempts which has not been updated in 5 years.

It seems like this functionality is important to pro-actively solving user problems and improving the WordPress experience, which would support it being in core from my perspective. Further, as @zodiac1978 points out, users having problems installing plugins would be barred from using this functionality if it is external.

The less resistance between users having problems and solving those problems the better for WordPress.

Would a more thorough analysis of the usage across the plugin/theme directories help discussions?

#48 @danieltj
2 months ago

This ticket does need revisiting for sure. This shouldn't be closed and put forward for a plugin only. I think it'd be good to put it up as a plugin to develop it and then at some point merge it into Core. This would be a vital page of information for debugging issues with sites and would be useful to a whole range of users.

Need to get this reopened.

This ticket was mentioned in Slack in #forums by clorith. View the logs.

2 months ago

Note: See TracTickets for help on using tickets.