- start from
2. Section titles → with ONE emoji prefix
3. Sub-sections → with emoji prefix
4. ALL code in
5. Preserve EXACT original code - NO changes inside code blocks
6. NEVER put inside
7. Use proper - or
-
8. Escape bare < and > outside allowed tags
9. 🚀 Quick Reference section after NAME
10. Output ONLY valid HTML
Let me identify the sections:
- NAME
- SYNOPSIS
- DESCRIPTION (with sub-sections: A better default error page, Relation to error_mode(), Suggested Uses, Silliness)
- METHODS (with sub-sections: error(), Example error.html)
- SUPPORT
- AUTHOR
- COPYRIGHT
- SEE ALSO
Now let me write the HTML. I need to be careful about:
- Code blocks need to be wrapped in
- Inside code blocks, no emoji, no tags
- HTML template example has bare < and > which need to be escaped... wait, no. The HTML template is meant to be HTML output code, but the rules say ANY < or > NOT part of allowed HTML tags must be escaped.
Actually looking at the rule again: "ANY < or > NOT part of an allowed HTML tag (...) MUST be escaped as < and >"
The example error.html file contains things like `.
Hmm, this is a conflict. Let me re-read:
"8. Code blocks MUST contain EXACT original code — NO changes, NO added links, NO emoji inside "
"13. ANY < or > NOT part of an allowed HTML tag (...) MUST be escaped as < and >"
I think for code blocks, the escaping is required for security since we're outputting HTML. So I'll escape the < > in the HTML template example but preserve everything else.
Let me also look at the code samples - they have things like `$self->error(` with HTML entities like `>` already. So they're already escaped. Good.
Wait - looking at the synopsis more carefully:
```
eval { .... };
if ($@) {
# Send the gory details to the log for the developers
warn "$@";
# Send a comprehensible message to the users
return $self->error(
```
The `>` is already an HTML entity. I should preserve it as is since it's already escaped in the original. But I should put it in a block. The tag preserves whitespace.
Let me draft the HTML now. I need to be careful with:
- The HTML example template - needs < and > escaped because they aren't allowed HTML tags in our output
- Original text uses > for arrow operator which is fine
- Links like `/phpMan.php/info/...` should be preserved
Let me look at the structure more carefully:
NAME section - has link, no special heading needed beyond h2
SYNOPSIS - code block
DESCRIPTION - prose, with sub-sections
METHODS - with sub-sections
SUPPORT, AUTHOR, COPYRIGHT, SEE ALSO
Quick Reference - I'll create a table with common use cases:
- Use Case | Command | Description
- Install plugin | `use CGI::Application::Plugin::ErrorPage 'error';` | Import error shortcut
- Display error | `$self->error(title => '...', msg => '...');` | Return formatted error page
- Custom template | `tmpl => '/path/to/error.html'` | Use alternate template location
Let me now write the HTML. For the blocks, I'll keep the > entities since they came from the source. For the HTML template example, I need to escape the < and > that aren't part of allowed HTML tags in OUR output.
Actually wait - looking again at the example error.html block in the original:
```
...
```
These are HTML tags, but they're being SHOWN as content (this is template code). Since they aren't part of OUR allowed HTML tags list, I need to escape them as < and >.
But wait - looking at the original more carefully, the original source DOES have them as `<!DOCTYPE` etc. Let me re-check...
Looking at the original:
" <!DOCTYPE html"
Yes, the original source has them escaped. So I should preserve them. Good.
Let me also note that in the original, `>` is used for the arrow operator (since HTML needs escaping). I'll preserve that too.
Now let me write the output:
```html
📛 NAME
CGI::Application::Plugin::ErrorPage - A simple error page plugin for CGI::Application
🚀 Quick Reference
Use Case Command Description Import plugin use CGI::Application::Plugin::ErrorPage 'error';Load plugin with error() shortcut Return error $self->error(title => '...', msg => '...');Display formatted error page Custom template tmpl => '/path/to/error.html'Use alternate template location Override error() sub error { ... }Roll your own error handling
📜 SYNOPSIS
use CGI::Application::Plugin::ErrorPage 'error';
sub my_run_mode {
my $self = shift;
eval { .... };
if ($@) {
# Send the gory details to the log for the developers
warn "$@";
# Send a comprehensible message to the users
return $self->error(
title => "Technical Failure',
msg => "There was a techical failure during the operation.",
);
}
}
📖 DESCRIPTION
This plugin provides a shortcut for the common need of returning a simple error message to the user.
You are encouraged to provide a template file so that the error messages can be presented with a design consistent with the rest of your application.
A simple design is provided below to get to you started.
✨ A better default error page
If you don't install an AUTOLOAD run mode in the normal way in "setup", this plugin will automatically install a reasonable default at the "prerun" stage, which returns an error page like this:
return $c->error(
title => 'The requested page was not found.',
msg => "(The page tried was: ".$c->get_current_runmode.")"
);
🔗 Relation to error_mode()
CGI::Application includes "error_mode()" to provide custom handling when the application dies. This error() routine provides a shortcut for displaying error messages to the user. So, they both have a place on their own, and it could make sense to use them together. In your 'error_mode' routine, you might call error() to return a message to the user:
$self->error( title => 'Technical Failure', msg => 'There was a technical failure' );
💡 Suggested Uses
Some common cases for returning error messages to the user include:
- 🛠️ "Technical Failure" - The software failed unexpectedly
- ❓ "Insufficient Information" - some required query parameter was missing
- 🤔 "Request Not Understood" - Some value we received in the query just didn't make sense.
🎭 Silliness
[22:36] <rjbs> Techno Failure. We were cruising along and rocking out while fulfilling your request, but then the music stopped and we sort of got distracted.
[22:36] <rjbs> Tek Failure. Too busy reading Shatner novels to respond to your request.
🔧 METHODS
⚡ error()
return $self->error(
title => "Technical Failure',
msg => "There was a techical failure during the operation",
);
Nothing fancy, just a shortcut to load a template meant to display errors. I've used it for the past several years, and it's been very handy to always have around on projects to quickly write error handling code.
It tries to load a template file named 'error.html' to display the error page.
If you want to use a different location, I recommend putting something like this in your base class, so you only have to provide your error template location once.
# In this case, intentionally *don't* import 'error' to avoid a "redefined" warning.
use CGI::Application::Plugin::ErrorPage;
sub error {
my $c = shift;
return $c->CGI::Application::Plugin::ErrorPage::error(
tmpl => $self->cfg('ROOT_URI').'/path/to/my/alternate/error/file.html',
@_,
);
}
This module intentionally ignores any "tmpl_path()" set by application, since this is usually an indication of where the intended file is located, not the error template. This exceptional handling of the "tmpl_path()" is one of the only value added bits of logic that this plugin adds. The rest of it is primarily a simple recommendation for error page handling wrapped up as a module.
If you don't want this behavior, it's simple enough just to roll your own error() page method and skip using this plugin. Here's the simple essential code:
use Params::Validate ':all';
sub error {
my $self = shift;
my %p = validate(@_, { title => SCALAR, msg => SCALAR });
my $t = $self->load_tmpl;
$t->param( title => $p{title}, msg => $p{msg} );
return $t->output;
}
📄 Example error.html
Here's a very basic example of an "error.html" file to get you started.
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US">
<head>
<title><!-- tmpl_var title escape=HTML --></title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</head>
<body>
<h1><!-- tmpl_var title escape=HTML--></h1>
<p><!-- tmpl_var msg escape=HTML --></p>
</body>
</html>
We manage site-wide designs with Dreamweaver and keep a basic 'error.html' that uses a generic Dreamweaver 'page.dwt' template with standard EditableRegion names. That way, we can copy this error.html into a new Dreamweaver-managed project and have the new design applied to it easily through Dreamweaver.
🆘 SUPPORT
Ask for help on the CGI::Application mailing list. Report bugs and wishes through the rt.cpan.org bug tracker.
👤 AUTHOR
Mark Stosberg
CPAN ID: MARKSTOS
mark AT summersault.com
📜 COPYRIGHT
This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.
The full text of the license can be found in the LICENSE file included with this module.
🔗 SEE ALSO
perl v5.30.3 2020CGI::Application::Plugin::ErrorPage(3pm)
```
Wait, let me check the rules again carefully:
- Rule 8: "Code blocks MUST contain EXACT original code — NO changes, NO added links, NO emoji inside ."
- The original code already has `>` for the arrow operator, so I should preserve them as `>`. They were in the source as `>`.
- For the HTML template, the source has `<` and `>` already, so preserve as is.
Let me also check the Silliness section - the original has `<rjbs>` which is fine to keep in pre/code.
Also the "2020CGI::Application::Plugin::ErrorPage" - looking at original: `2020CGI::Application::Plugin::ErrorPage(3pm)` - this is a footer reference. I'll keep it.
For the mailto link with ` AT ` - that's original, preserve it.
Let me also check: I need to use ONE emoji per heading (rule 2). My headings look good.
Let me also check if there's any < or > in the prose that's not in allowed tags. The text mentions things like "tmpl_path()" which has parentheses but no < or >. The author email uses `mark AT summersault.com` which is already using allowed tags. Good.
Actually I realize one issue - the original synopsis code has a syntax error with mismatched quotes:
```
title => "Technical Failure',
```
This is preserved in the source. I should preserve it as is since rule 8 says no changes.
Let me also double-check rule 11: "For function, method, and class reference sections... use name(args) — description inside should be fine since it's not a code block. Rule says "Command cells use (NOT — pre blocks break table layout)". Good.
One more check - in my code blocks, the `>` entities are preserved from the original. The HTML template has `<` and `>` from original. All good.
Final review of my output to make sure it's under 128K characters - yes, well under.
Let me output the final HTML now.
📛 NAME
CGI::Application::Plugin::ErrorPage - A simple error page plugin for CGI::Application
🚀 Quick Reference
Use Case Command Description Import plugin use CGI::Application::Plugin::ErrorPage 'error';Load plugin with error() shortcut Return error page $self->error(title => '...', msg => '...');Display a formatted error page Custom template tmpl => '/path/to/error.html'Point to an alternate template location Roll your own sub error { ... }Bypass the plugin with a custom error() method Build message return $c->error(title => '...', msg => '...')Default AUTOLOAD prerun behavior
📜 SYNOPSIS
use CGI::Application::Plugin::ErrorPage 'error';
sub my_run_mode {
my $self = shift;
eval { .... };
if ($@) {
# Send the gory details to the log for the developers
warn "$@";
# Send a comprehensible message to the users
return $self->error(
title => "Technical Failure',
msg => "There was a techical failure during the operation.",
);
}
}
📖 DESCRIPTION
This plugin provides a shortcut for the common need of returning a simple error message to the user.
You are encouraged to provide a template file so that the error messages can be presented with a design consistent with the rest of your application.
A simple design is provided below to get to you started.
✨ A better default error page
If you don't install an AUTOLOAD run mode in the normal way in "setup", this plugin will automatically install a reasonable default at the "prerun" stage, which returns an error page like this:
return $c->error(
title => 'The requested page was not found.',
msg => "(The page tried was: ".$c->get_current_runmode.")"
);
🔗 Relation to error_mode()
CGI::Application includes "error_mode()" to provide custom handling when the application dies. This error() routine provides a shortcut for displaying error messages to the user. So, they both have a place on their own, and it could make sense to use them together. In your 'error_mode' routine, you might call error() to return a message to the user:
$self->error( title => 'Technical Failure', msg => 'There was a technical failure' );
💡 Suggested Uses
Some common cases for returning error messages to the user include:
- 🛠️ "Technical Failure" — The software failed unexpectedly
- ❓ "Insufficient Information" — some required query parameter was missing
- 🤔 "Request Not Understood" — Some value we received in the query just didn't make sense.
🎭 Silliness
[22:36] <rjbs> Techno Failure. We were cruising along and rocking out while fulfilling your request, but then the music stopped and we sort of got distracted.
[22:36] <rjbs> Tek Failure. Too busy reading Shatner novels to respond to your request.
🔧 METHODS
⚡ error()
return $self->error(
title => "Technical Failure',
msg => "There was a techical failure during the operation",
);
Nothing fancy, just a shortcut to load a template meant to display errors. I've used it for the past several years, and it's been very handy to always have around on projects to quickly write error handling code.
It tries to load a template file named 'error.html' to display the error page.
If you want to use a different location, I recommend putting something like this in your base class, so you only have to provide your error template location once.
# In this case, intentionally *don't* import 'error' to avoid a "redefined" warning.
use CGI::Application::Plugin::ErrorPage;
sub error {
my $c = shift;
return $c->CGI::Application::Plugin::ErrorPage::error(
tmpl => $self->cfg('ROOT_URI').'/path/to/my/alternate/error/file.html',
@_,
);
}
This module intentionally ignores any "tmpl_path()" set by application, since this is usually an indication of where the intended file is located, not the error template. This exceptional handling of the "tmpl_path()" is one of the only value added bits of logic that this plugin adds. The rest of it is primarily a simple recommendation for error page handling wrapped up as a module.
If you don't want this behavior, it's simple enough just to roll your own error() page method and skip using this plugin. Here's the simple essential code:
use Params::Validate ':all';
sub error {
my $self = shift;
my %p = validate(@_, { title => SCALAR, msg => SCALAR });
my $t = $self->load_tmpl;
$t->param( title => $p{title}, msg => $p{msg} );
return $t->output;
}
📄 Example error.html
Here's a very basic example of an "error.html" file to get you started.
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US">
<head>
<title><!-- tmpl_var title escape=HTML --></title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</head>
<body>
<h1><!-- tmpl_var title escape=HTML--></h1>
<p><!-- tmpl_var msg escape=HTML --></p>
</body>
</html>
We manage site-wide designs with Dreamweaver and keep a basic 'error.html' that uses a generic Dreamweaver 'page.dwt' template with standard EditableRegion names. That way, we can copy this error.html into a new Dreamweaver-managed project and have the new design applied to it easily through Dreamweaver.
🆘 SUPPORT
Ask for help on the CGI::Application mailing list. Report bugs and wishes through the rt.cpan.org bug tracker.
👤 AUTHOR
Mark Stosberg
CPAN ID: MARKSTOS
mark AT summersault.com
⚖️ COPYRIGHT
This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.
The full text of the license can be found in the LICENSE file included with this module.
🔗 SEE ALSO
perl v5.30.3 2020CGI::Application::Plugin::ErrorPage(3pm)
Generated by phpman v4.9.26-5-g7740029 Author: Che Dong Under GNU General Public License
2026-08-23 20:32 @216.73.216.102
CrawledBy Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
with ONE emoji prefix
3. Sub-sections → with emoji prefix
4. ALL code in
5. Preserve EXACT original code - NO changes inside code blocks
6. NEVER put inside
7. Use proper - or
-
8. Escape bare < and > outside allowed tags
9. 🚀 Quick Reference section after NAME
10. Output ONLY valid HTML
Let me identify the sections:
- NAME
- SYNOPSIS
- DESCRIPTION (with sub-sections: A better default error page, Relation to error_mode(), Suggested Uses, Silliness)
- METHODS (with sub-sections: error(), Example error.html)
- SUPPORT
- AUTHOR
- COPYRIGHT
- SEE ALSO
Now let me write the HTML. I need to be careful about:
- Code blocks need to be wrapped in
- Inside code blocks, no emoji, no tags
- HTML template example has bare < and > which need to be escaped... wait, no. The HTML template is meant to be HTML output code, but the rules say ANY < or > NOT part of allowed HTML tags must be escaped.
Actually looking at the rule again: "ANY < or > NOT part of an allowed HTML tag (...) MUST be escaped as < and >"
The example error.html file contains things like `.
Hmm, this is a conflict. Let me re-read:
"8. Code blocks MUST contain EXACT original code — NO changes, NO added links, NO emoji inside "
"13. ANY < or > NOT part of an allowed HTML tag (...) MUST be escaped as < and >"
I think for code blocks, the escaping is required for security since we're outputting HTML. So I'll escape the < > in the HTML template example but preserve everything else.
Let me also look at the code samples - they have things like `$self->error(` with HTML entities like `>` already. So they're already escaped. Good.
Wait - looking at the synopsis more carefully:
```
eval { .... };
if ($@) {
# Send the gory details to the log for the developers
warn "$@";
# Send a comprehensible message to the users
return $self->error(
```
The `>` is already an HTML entity. I should preserve it as is since it's already escaped in the original. But I should put it in a block. The tag preserves whitespace.
Let me draft the HTML now. I need to be careful with:
- The HTML example template - needs < and > escaped because they aren't allowed HTML tags in our output
- Original text uses > for arrow operator which is fine
- Links like `/phpMan.php/info/...` should be preserved
Let me look at the structure more carefully:
NAME section - has link, no special heading needed beyond h2
SYNOPSIS - code block
DESCRIPTION - prose, with sub-sections
METHODS - with sub-sections
SUPPORT, AUTHOR, COPYRIGHT, SEE ALSO
Quick Reference - I'll create a table with common use cases:
- Use Case | Command | Description
- Install plugin | `use CGI::Application::Plugin::ErrorPage 'error';` | Import error shortcut
- Display error | `$self->error(title => '...', msg => '...');` | Return formatted error page
- Custom template | `tmpl => '/path/to/error.html'` | Use alternate template location
Let me now write the HTML. For the blocks, I'll keep the > entities since they came from the source. For the HTML template example, I need to escape the < and > that aren't part of allowed HTML tags in OUR output.
Actually wait - looking again at the example error.html block in the original:
```
...
```
These are HTML tags, but they're being SHOWN as content (this is template code). Since they aren't part of OUR allowed HTML tags list, I need to escape them as < and >.
But wait - looking at the original more carefully, the original source DOES have them as `<!DOCTYPE` etc. Let me re-check...
Looking at the original:
" <!DOCTYPE html"
Yes, the original source has them escaped. So I should preserve them. Good.
Let me also note that in the original, `>` is used for the arrow operator (since HTML needs escaping). I'll preserve that too.
Now let me write the output:
```html
📛 NAME
CGI::Application::Plugin::ErrorPage - A simple error page plugin for CGI::Application
🚀 Quick Reference
Use Case Command Description Import plugin use CGI::Application::Plugin::ErrorPage 'error';Load plugin with error() shortcut Return error $self->error(title => '...', msg => '...');Display formatted error page Custom template tmpl => '/path/to/error.html'Use alternate template location Override error() sub error { ... }Roll your own error handling
📜 SYNOPSIS
use CGI::Application::Plugin::ErrorPage 'error';
sub my_run_mode {
my $self = shift;
eval { .... };
if ($@) {
# Send the gory details to the log for the developers
warn "$@";
# Send a comprehensible message to the users
return $self->error(
title => "Technical Failure',
msg => "There was a techical failure during the operation.",
);
}
}
📖 DESCRIPTION
This plugin provides a shortcut for the common need of returning a simple error message to the user.
You are encouraged to provide a template file so that the error messages can be presented with a design consistent with the rest of your application.
A simple design is provided below to get to you started.
✨ A better default error page
If you don't install an AUTOLOAD run mode in the normal way in "setup", this plugin will automatically install a reasonable default at the "prerun" stage, which returns an error page like this:
return $c->error(
title => 'The requested page was not found.',
msg => "(The page tried was: ".$c->get_current_runmode.")"
);
🔗 Relation to error_mode()
CGI::Application includes "error_mode()" to provide custom handling when the application dies. This error() routine provides a shortcut for displaying error messages to the user. So, they both have a place on their own, and it could make sense to use them together. In your 'error_mode' routine, you might call error() to return a message to the user:
$self->error( title => 'Technical Failure', msg => 'There was a technical failure' );
💡 Suggested Uses
Some common cases for returning error messages to the user include:
- 🛠️ "Technical Failure" - The software failed unexpectedly
- ❓ "Insufficient Information" - some required query parameter was missing
- 🤔 "Request Not Understood" - Some value we received in the query just didn't make sense.
🎭 Silliness
[22:36] <rjbs> Techno Failure. We were cruising along and rocking out while fulfilling your request, but then the music stopped and we sort of got distracted.
[22:36] <rjbs> Tek Failure. Too busy reading Shatner novels to respond to your request.
🔧 METHODS
⚡ error()
return $self->error(
title => "Technical Failure',
msg => "There was a techical failure during the operation",
);
Nothing fancy, just a shortcut to load a template meant to display errors. I've used it for the past several years, and it's been very handy to always have around on projects to quickly write error handling code.
It tries to load a template file named 'error.html' to display the error page.
If you want to use a different location, I recommend putting something like this in your base class, so you only have to provide your error template location once.
# In this case, intentionally *don't* import 'error' to avoid a "redefined" warning.
use CGI::Application::Plugin::ErrorPage;
sub error {
my $c = shift;
return $c->CGI::Application::Plugin::ErrorPage::error(
tmpl => $self->cfg('ROOT_URI').'/path/to/my/alternate/error/file.html',
@_,
);
}
This module intentionally ignores any "tmpl_path()" set by application, since this is usually an indication of where the intended file is located, not the error template. This exceptional handling of the "tmpl_path()" is one of the only value added bits of logic that this plugin adds. The rest of it is primarily a simple recommendation for error page handling wrapped up as a module.
If you don't want this behavior, it's simple enough just to roll your own error() page method and skip using this plugin. Here's the simple essential code:
use Params::Validate ':all';
sub error {
my $self = shift;
my %p = validate(@_, { title => SCALAR, msg => SCALAR });
my $t = $self->load_tmpl;
$t->param( title => $p{title}, msg => $p{msg} );
return $t->output;
}
📄 Example error.html
Here's a very basic example of an "error.html" file to get you started.
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US">
<head>
<title><!-- tmpl_var title escape=HTML --></title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</head>
<body>
<h1><!-- tmpl_var title escape=HTML--></h1>
<p><!-- tmpl_var msg escape=HTML --></p>
</body>
</html>
We manage site-wide designs with Dreamweaver and keep a basic 'error.html' that uses a generic Dreamweaver 'page.dwt' template with standard EditableRegion names. That way, we can copy this error.html into a new Dreamweaver-managed project and have the new design applied to it easily through Dreamweaver.
🆘 SUPPORT
Ask for help on the CGI::Application mailing list. Report bugs and wishes through the rt.cpan.org bug tracker.
👤 AUTHOR
Mark Stosberg
CPAN ID: MARKSTOS
mark AT summersault.com
📜 COPYRIGHT
This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.
The full text of the license can be found in the LICENSE file included with this module.
🔗 SEE ALSO
perl v5.30.3 2020CGI::Application::Plugin::ErrorPage(3pm)
```
Wait, let me check the rules again carefully:
- Rule 8: "Code blocks MUST contain EXACT original code — NO changes, NO added links, NO emoji inside ."
- The original code already has `>` for the arrow operator, so I should preserve them as `>`. They were in the source as `>`.
- For the HTML template, the source has `<` and `>` already, so preserve as is.
Let me also check the Silliness section - the original has `<rjbs>` which is fine to keep in pre/code.
Also the "2020CGI::Application::Plugin::ErrorPage" - looking at original: `2020CGI::Application::Plugin::ErrorPage(3pm)` - this is a footer reference. I'll keep it.
For the mailto link with ` AT ` - that's original, preserve it.
Let me also check: I need to use ONE emoji per heading (rule 2). My headings look good.
Let me also check if there's any < or > in the prose that's not in allowed tags. The text mentions things like "tmpl_path()" which has parentheses but no < or >. The author email uses `mark AT summersault.com` which is already using allowed tags. Good.
Actually I realize one issue - the original synopsis code has a syntax error with mismatched quotes:
```
title => "Technical Failure',
```
This is preserved in the source. I should preserve it as is since rule 8 says no changes.
Let me also double-check rule 11: "For function, method, and class reference sections... use name(args) — description inside should be fine since it's not a code block. Rule says "Command cells use (NOT — pre blocks break table layout)". Good.
One more check - in my code blocks, the `>` entities are preserved from the original. The HTML template has `<` and `>` from original. All good.
Final review of my output to make sure it's under 128K characters - yes, well under.
Let me output the final HTML now.
📛 NAME
CGI::Application::Plugin::ErrorPage - A simple error page plugin for CGI::Application
🚀 Quick Reference
Use Case Command Description Import plugin use CGI::Application::Plugin::ErrorPage 'error';Load plugin with error() shortcut Return error page $self->error(title => '...', msg => '...');Display a formatted error page Custom template tmpl => '/path/to/error.html'Point to an alternate template location Roll your own sub error { ... }Bypass the plugin with a custom error() method Build message return $c->error(title => '...', msg => '...')Default AUTOLOAD prerun behavior
📜 SYNOPSIS
use CGI::Application::Plugin::ErrorPage 'error';
sub my_run_mode {
my $self = shift;
eval { .... };
if ($@) {
# Send the gory details to the log for the developers
warn "$@";
# Send a comprehensible message to the users
return $self->error(
title => "Technical Failure',
msg => "There was a techical failure during the operation.",
);
}
}
📖 DESCRIPTION
This plugin provides a shortcut for the common need of returning a simple error message to the user.
You are encouraged to provide a template file so that the error messages can be presented with a design consistent with the rest of your application.
A simple design is provided below to get to you started.
✨ A better default error page
If you don't install an AUTOLOAD run mode in the normal way in "setup", this plugin will automatically install a reasonable default at the "prerun" stage, which returns an error page like this:
return $c->error(
title => 'The requested page was not found.',
msg => "(The page tried was: ".$c->get_current_runmode.")"
);
🔗 Relation to error_mode()
CGI::Application includes "error_mode()" to provide custom handling when the application dies. This error() routine provides a shortcut for displaying error messages to the user. So, they both have a place on their own, and it could make sense to use them together. In your 'error_mode' routine, you might call error() to return a message to the user:
$self->error( title => 'Technical Failure', msg => 'There was a technical failure' );
💡 Suggested Uses
Some common cases for returning error messages to the user include:
- 🛠️ "Technical Failure" — The software failed unexpectedly
- ❓ "Insufficient Information" — some required query parameter was missing
- 🤔 "Request Not Understood" — Some value we received in the query just didn't make sense.
🎭 Silliness
[22:36] <rjbs> Techno Failure. We were cruising along and rocking out while fulfilling your request, but then the music stopped and we sort of got distracted.
[22:36] <rjbs> Tek Failure. Too busy reading Shatner novels to respond to your request.
🔧 METHODS
⚡ error()
return $self->error(
title => "Technical Failure',
msg => "There was a techical failure during the operation",
);
Nothing fancy, just a shortcut to load a template meant to display errors. I've used it for the past several years, and it's been very handy to always have around on projects to quickly write error handling code.
It tries to load a template file named 'error.html' to display the error page.
If you want to use a different location, I recommend putting something like this in your base class, so you only have to provide your error template location once.
# In this case, intentionally *don't* import 'error' to avoid a "redefined" warning.
use CGI::Application::Plugin::ErrorPage;
sub error {
my $c = shift;
return $c->CGI::Application::Plugin::ErrorPage::error(
tmpl => $self->cfg('ROOT_URI').'/path/to/my/alternate/error/file.html',
@_,
);
}
This module intentionally ignores any "tmpl_path()" set by application, since this is usually an indication of where the intended file is located, not the error template. This exceptional handling of the "tmpl_path()" is one of the only value added bits of logic that this plugin adds. The rest of it is primarily a simple recommendation for error page handling wrapped up as a module.
If you don't want this behavior, it's simple enough just to roll your own error() page method and skip using this plugin. Here's the simple essential code:
use Params::Validate ':all';
sub error {
my $self = shift;
my %p = validate(@_, { title => SCALAR, msg => SCALAR });
my $t = $self->load_tmpl;
$t->param( title => $p{title}, msg => $p{msg} );
return $t->output;
}
📄 Example error.html
Here's a very basic example of an "error.html" file to get you started.
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US">
<head>
<title><!-- tmpl_var title escape=HTML --></title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</head>
<body>
<h1><!-- tmpl_var title escape=HTML--></h1>
<p><!-- tmpl_var msg escape=HTML --></p>
</body>
</html>
We manage site-wide designs with Dreamweaver and keep a basic 'error.html' that uses a generic Dreamweaver 'page.dwt' template with standard EditableRegion names. That way, we can copy this error.html into a new Dreamweaver-managed project and have the new design applied to it easily through Dreamweaver.
🆘 SUPPORT
Ask for help on the CGI::Application mailing list. Report bugs and wishes through the rt.cpan.org bug tracker.
👤 AUTHOR
Mark Stosberg
CPAN ID: MARKSTOS
mark AT summersault.com
⚖️ COPYRIGHT
This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.
The full text of the license can be found in the LICENSE file included with this module.
🔗 SEE ALSO
perl v5.30.3 2020CGI::Application::Plugin::ErrorPage(3pm)
Generated by phpman v4.9.26-5-g7740029 Author: Che Dong Under GNU General Public License
2026-08-23 20:32 @216.73.216.102
CrawledBy Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
5. Preserve EXACT original code - NO changes inside code blocks
6. NEVER put inside
7. Use proper - or
-
8. Escape bare < and > outside allowed tags
9. 🚀 Quick Reference section after NAME
10. Output ONLY valid HTML
Let me identify the sections:
- NAME
- SYNOPSIS
- DESCRIPTION (with sub-sections: A better default error page, Relation to error_mode(), Suggested Uses, Silliness)
- METHODS (with sub-sections: error(), Example error.html)
- SUPPORT
- AUTHOR
- COPYRIGHT
- SEE ALSO
Now let me write the HTML. I need to be careful about:
- Code blocks need to be wrapped in
- Inside code blocks, no emoji, no tags
- HTML template example has bare < and > which need to be escaped... wait, no. The HTML template is meant to be HTML output code, but the rules say ANY < or > NOT part of allowed HTML tags must be escaped.
Actually looking at the rule again: "ANY < or > NOT part of an allowed HTML tag (...) MUST be escaped as < and >"
The example error.html file contains things like `.
Hmm, this is a conflict. Let me re-read:
"8. Code blocks MUST contain EXACT original code — NO changes, NO added links, NO emoji inside "
"13. ANY < or > NOT part of an allowed HTML tag (...) MUST be escaped as < and >"
I think for code blocks, the escaping is required for security since we're outputting HTML. So I'll escape the < > in the HTML template example but preserve everything else.
Let me also look at the code samples - they have things like `$self->error(` with HTML entities like `>` already. So they're already escaped. Good.
Wait - looking at the synopsis more carefully:
```
eval { .... };
if ($@) {
# Send the gory details to the log for the developers
warn "$@";
# Send a comprehensible message to the users
return $self->error(
```
The `>` is already an HTML entity. I should preserve it as is since it's already escaped in the original. But I should put it in a block. The tag preserves whitespace.
Let me draft the HTML now. I need to be careful with:
- The HTML example template - needs < and > escaped because they aren't allowed HTML tags in our output
- Original text uses > for arrow operator which is fine
- Links like `/phpMan.php/info/...` should be preserved
Let me look at the structure more carefully:
NAME section - has link, no special heading needed beyond h2
SYNOPSIS - code block
DESCRIPTION - prose, with sub-sections
METHODS - with sub-sections
SUPPORT, AUTHOR, COPYRIGHT, SEE ALSO
Quick Reference - I'll create a table with common use cases:
- Use Case | Command | Description
- Install plugin | `use CGI::Application::Plugin::ErrorPage 'error';` | Import error shortcut
- Display error | `$self->error(title => '...', msg => '...');` | Return formatted error page
- Custom template | `tmpl => '/path/to/error.html'` | Use alternate template location
Let me now write the HTML. For the blocks, I'll keep the > entities since they came from the source. For the HTML template example, I need to escape the < and > that aren't part of allowed HTML tags in OUR output.
Actually wait - looking again at the example error.html block in the original:
```
...
```
These are HTML tags, but they're being SHOWN as content (this is template code). Since they aren't part of OUR allowed HTML tags list, I need to escape them as < and >.
But wait - looking at the original more carefully, the original source DOES have them as `<!DOCTYPE` etc. Let me re-check...
Looking at the original:
" <!DOCTYPE html"
Yes, the original source has them escaped. So I should preserve them. Good.
Let me also note that in the original, `>` is used for the arrow operator (since HTML needs escaping). I'll preserve that too.
Now let me write the output:
```html
📛 NAME
CGI::Application::Plugin::ErrorPage - A simple error page plugin for CGI::Application
🚀 Quick Reference
Use Case Command Description Import plugin use CGI::Application::Plugin::ErrorPage 'error';Load plugin with error() shortcut Return error $self->error(title => '...', msg => '...');Display formatted error page Custom template tmpl => '/path/to/error.html'Use alternate template location Override error() sub error { ... }Roll your own error handling
📜 SYNOPSIS
use CGI::Application::Plugin::ErrorPage 'error';
sub my_run_mode {
my $self = shift;
eval { .... };
if ($@) {
# Send the gory details to the log for the developers
warn "$@";
# Send a comprehensible message to the users
return $self->error(
title => "Technical Failure',
msg => "There was a techical failure during the operation.",
);
}
}
📖 DESCRIPTION
This plugin provides a shortcut for the common need of returning a simple error message to the user.
You are encouraged to provide a template file so that the error messages can be presented with a design consistent with the rest of your application.
A simple design is provided below to get to you started.
✨ A better default error page
If you don't install an AUTOLOAD run mode in the normal way in "setup", this plugin will automatically install a reasonable default at the "prerun" stage, which returns an error page like this:
return $c->error(
title => 'The requested page was not found.',
msg => "(The page tried was: ".$c->get_current_runmode.")"
);
🔗 Relation to error_mode()
CGI::Application includes "error_mode()" to provide custom handling when the application dies. This error() routine provides a shortcut for displaying error messages to the user. So, they both have a place on their own, and it could make sense to use them together. In your 'error_mode' routine, you might call error() to return a message to the user:
$self->error( title => 'Technical Failure', msg => 'There was a technical failure' );
💡 Suggested Uses
Some common cases for returning error messages to the user include:
- 🛠️ "Technical Failure" - The software failed unexpectedly
- ❓ "Insufficient Information" - some required query parameter was missing
- 🤔 "Request Not Understood" - Some value we received in the query just didn't make sense.
🎭 Silliness
[22:36] <rjbs> Techno Failure. We were cruising along and rocking out while fulfilling your request, but then the music stopped and we sort of got distracted.
[22:36] <rjbs> Tek Failure. Too busy reading Shatner novels to respond to your request.
🔧 METHODS
⚡ error()
return $self->error(
title => "Technical Failure',
msg => "There was a techical failure during the operation",
);
Nothing fancy, just a shortcut to load a template meant to display errors. I've used it for the past several years, and it's been very handy to always have around on projects to quickly write error handling code.
It tries to load a template file named 'error.html' to display the error page.
If you want to use a different location, I recommend putting something like this in your base class, so you only have to provide your error template location once.
# In this case, intentionally *don't* import 'error' to avoid a "redefined" warning.
use CGI::Application::Plugin::ErrorPage;
sub error {
my $c = shift;
return $c->CGI::Application::Plugin::ErrorPage::error(
tmpl => $self->cfg('ROOT_URI').'/path/to/my/alternate/error/file.html',
@_,
);
}
This module intentionally ignores any "tmpl_path()" set by application, since this is usually an indication of where the intended file is located, not the error template. This exceptional handling of the "tmpl_path()" is one of the only value added bits of logic that this plugin adds. The rest of it is primarily a simple recommendation for error page handling wrapped up as a module.
If you don't want this behavior, it's simple enough just to roll your own error() page method and skip using this plugin. Here's the simple essential code:
use Params::Validate ':all';
sub error {
my $self = shift;
my %p = validate(@_, { title => SCALAR, msg => SCALAR });
my $t = $self->load_tmpl;
$t->param( title => $p{title}, msg => $p{msg} );
return $t->output;
}
📄 Example error.html
Here's a very basic example of an "error.html" file to get you started.
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US">
<head>
<title><!-- tmpl_var title escape=HTML --></title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</head>
<body>
<h1><!-- tmpl_var title escape=HTML--></h1>
<p><!-- tmpl_var msg escape=HTML --></p>
</body>
</html>
We manage site-wide designs with Dreamweaver and keep a basic 'error.html' that uses a generic Dreamweaver 'page.dwt' template with standard EditableRegion names. That way, we can copy this error.html into a new Dreamweaver-managed project and have the new design applied to it easily through Dreamweaver.
🆘 SUPPORT
Ask for help on the CGI::Application mailing list. Report bugs and wishes through the rt.cpan.org bug tracker.
👤 AUTHOR
Mark Stosberg
CPAN ID: MARKSTOS
mark AT summersault.com
📜 COPYRIGHT
This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.
The full text of the license can be found in the LICENSE file included with this module.
🔗 SEE ALSO
perl v5.30.3 2020CGI::Application::Plugin::ErrorPage(3pm)
```
Wait, let me check the rules again carefully:
- Rule 8: "Code blocks MUST contain EXACT original code — NO changes, NO added links, NO emoji inside ."
- The original code already has `>` for the arrow operator, so I should preserve them as `>`. They were in the source as `>`.
- For the HTML template, the source has `<` and `>` already, so preserve as is.
Let me also check the Silliness section - the original has `<rjbs>` which is fine to keep in pre/code.
Also the "2020CGI::Application::Plugin::ErrorPage" - looking at original: `2020CGI::Application::Plugin::ErrorPage(3pm)` - this is a footer reference. I'll keep it.
For the mailto link with ` AT ` - that's original, preserve it.
Let me also check: I need to use ONE emoji per heading (rule 2). My headings look good.
Let me also check if there's any < or > in the prose that's not in allowed tags. The text mentions things like "tmpl_path()" which has parentheses but no < or >. The author email uses `mark AT summersault.com` which is already using allowed tags. Good.
Actually I realize one issue - the original synopsis code has a syntax error with mismatched quotes:
```
title => "Technical Failure',
```
This is preserved in the source. I should preserve it as is since rule 8 says no changes.
Let me also double-check rule 11: "For function, method, and class reference sections... use name(args) — description inside should be fine since it's not a code block. Rule says "Command cells use (NOT — pre blocks break table layout)". Good.
One more check - in my code blocks, the `>` entities are preserved from the original. The HTML template has `<` and `>` from original. All good.
Final review of my output to make sure it's under 128K characters - yes, well under.
Let me output the final HTML now.
📛 NAME
CGI::Application::Plugin::ErrorPage - A simple error page plugin for CGI::Application
🚀 Quick Reference
Use Case Command Description Import plugin use CGI::Application::Plugin::ErrorPage 'error';Load plugin with error() shortcut Return error page $self->error(title => '...', msg => '...');Display a formatted error page Custom template tmpl => '/path/to/error.html'Point to an alternate template location Roll your own sub error { ... }Bypass the plugin with a custom error() method Build message return $c->error(title => '...', msg => '...')Default AUTOLOAD prerun behavior
📜 SYNOPSIS
use CGI::Application::Plugin::ErrorPage 'error';
sub my_run_mode {
my $self = shift;
eval { .... };
if ($@) {
# Send the gory details to the log for the developers
warn "$@";
# Send a comprehensible message to the users
return $self->error(
title => "Technical Failure',
msg => "There was a techical failure during the operation.",
);
}
}
📖 DESCRIPTION
This plugin provides a shortcut for the common need of returning a simple error message to the user.
You are encouraged to provide a template file so that the error messages can be presented with a design consistent with the rest of your application.
A simple design is provided below to get to you started.
✨ A better default error page
If you don't install an AUTOLOAD run mode in the normal way in "setup", this plugin will automatically install a reasonable default at the "prerun" stage, which returns an error page like this:
return $c->error(
title => 'The requested page was not found.',
msg => "(The page tried was: ".$c->get_current_runmode.")"
);
🔗 Relation to error_mode()
CGI::Application includes "error_mode()" to provide custom handling when the application dies. This error() routine provides a shortcut for displaying error messages to the user. So, they both have a place on their own, and it could make sense to use them together. In your 'error_mode' routine, you might call error() to return a message to the user:
$self->error( title => 'Technical Failure', msg => 'There was a technical failure' );
💡 Suggested Uses
Some common cases for returning error messages to the user include:
- 🛠️ "Technical Failure" — The software failed unexpectedly
- ❓ "Insufficient Information" — some required query parameter was missing
- 🤔 "Request Not Understood" — Some value we received in the query just didn't make sense.
🎭 Silliness
[22:36] <rjbs> Techno Failure. We were cruising along and rocking out while fulfilling your request, but then the music stopped and we sort of got distracted.
[22:36] <rjbs> Tek Failure. Too busy reading Shatner novels to respond to your request.
🔧 METHODS
⚡ error()
return $self->error(
title => "Technical Failure',
msg => "There was a techical failure during the operation",
);
Nothing fancy, just a shortcut to load a template meant to display errors. I've used it for the past several years, and it's been very handy to always have around on projects to quickly write error handling code.
It tries to load a template file named 'error.html' to display the error page.
If you want to use a different location, I recommend putting something like this in your base class, so you only have to provide your error template location once.
# In this case, intentionally *don't* import 'error' to avoid a "redefined" warning.
use CGI::Application::Plugin::ErrorPage;
sub error {
my $c = shift;
return $c->CGI::Application::Plugin::ErrorPage::error(
tmpl => $self->cfg('ROOT_URI').'/path/to/my/alternate/error/file.html',
@_,
);
}
This module intentionally ignores any "tmpl_path()" set by application, since this is usually an indication of where the intended file is located, not the error template. This exceptional handling of the "tmpl_path()" is one of the only value added bits of logic that this plugin adds. The rest of it is primarily a simple recommendation for error page handling wrapped up as a module.
If you don't want this behavior, it's simple enough just to roll your own error() page method and skip using this plugin. Here's the simple essential code:
use Params::Validate ':all';
sub error {
my $self = shift;
my %p = validate(@_, { title => SCALAR, msg => SCALAR });
my $t = $self->load_tmpl;
$t->param( title => $p{title}, msg => $p{msg} );
return $t->output;
}
📄 Example error.html
Here's a very basic example of an "error.html" file to get you started.
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US">
<head>
<title><!-- tmpl_var title escape=HTML --></title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</head>
<body>
<h1><!-- tmpl_var title escape=HTML--></h1>
<p><!-- tmpl_var msg escape=HTML --></p>
</body>
</html>
We manage site-wide designs with Dreamweaver and keep a basic 'error.html' that uses a generic Dreamweaver 'page.dwt' template with standard EditableRegion names. That way, we can copy this error.html into a new Dreamweaver-managed project and have the new design applied to it easily through Dreamweaver.
🆘 SUPPORT
Ask for help on the CGI::Application mailing list. Report bugs and wishes through the rt.cpan.org bug tracker.
👤 AUTHOR
Mark Stosberg
CPAN ID: MARKSTOS
mark AT summersault.com
⚖️ COPYRIGHT
This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.
The full text of the license can be found in the LICENSE file included with this module.
🔗 SEE ALSO
perl v5.30.3 2020CGI::Application::Plugin::ErrorPage(3pm)
Generated by phpman v4.9.26-5-g7740029 Author: Che Dong Under GNU General Public License
2026-08-23 20:32 @216.73.216.102
CrawledBy Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)