Download the PHP package busy-noggin/static-error-pages without Composer

On this page you can find all versions of the php package busy-noggin/static-error-pages. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package static-error-pages

Static Error Page Integration

This TYPO3 extension makes it possible to configure an error page (404, etc.) in TYPO3 which gets its content from either a local TYPO3 page or an external URL, but which stores the output of said page as a local file (this can be changed to store in any way you prefer, via TYPO3's caching framework).

The purpose of this is two-fold:

  1. Ensure maximum performance with the shortest possible path from error to delivering the error page.
  2. Make it possible to add the static file as an ErrorDocument in the HTTP server (possible when using the default storage method which writes a true .html file to the local filesystem).

The extension tries to be smart about how/when to re-write the cached file. Rather than checking and writing this file when errors happen, a console command (schedulable with EXT:scheduler) is used which can be executed with any frequency and only regenerates the static file when it is expired (TTL defined by command parameter).

Additionally, the extension will listen for page changes and if a page is changed which matches a configured page in a scheduler task that executes the command that writes the static file, it re-writes the static file immediately. Thus, any change you make to your error page in TYPO3 immediately causes a new error page to be written.

The extension utilizes the TYPO3 caching framework as storage to make it easier for you to change how/where the static file is stored.

Configuration

Configuring a TYPO3 site to use this feature is relatively simple:

This enables the handling of the particular type/types of errors. Then, in order to generate the static files of the pages/urls you configured:

You can set any frequency you like on the scheduled task. If you enable the "force" option you can use the frequency to determine how frequently the file is rewritten. If you use the "ttl" option (or just rely on the default TTL) you can set the frequency lower or higher than the TTL, but probably you would want to set it lower.

Note that one scheduled task is necessary for each error document as identified by either the full URL or the page UID. So, if you have 6 different TYPO3 pages for different error types on different page tree branches, you will need to create 6 scheduled tasks - one for each page. This will cause 6 different static files to be created.

Note about changing the cache backend

If for some reason your setup requires the error page to be stored in a different way - for example, if you are using a distributed setup with muliple servers and want to store the file in Redis - you'll need to change the cache backend to one that stores files in your preferred way. Do this by setting the cache backend like you normally would:

When you do this, it is important to configure the scheduler task or external cron to force recreation of the file and manage the frequency yourself. If you configured the "live-identifier" as a TYPO3 page then changes made to this page in the TYPO3 backend will still cause the file (cache entry) to be rewritten on every change.

Usage as ErrorDocument in HTTP server

This approach is only possible with the default storage (cache) backend shipped with the extension!

With a standard TYPO3 setup, some URLs are handled with TYPO3's page lookups while others (those in specific locations) are handled as normal files without a page lookup. An error code triggered by such a normal file will by default show a different error page than the one shown when a page lookup fails.

This extension provides a way to configure an ErrorDocument in the HTTP server and point this to the generated/cached static file which is saved as a proper HTML file. Because of the way the static file is regenerated, the static file is not removed when it expires - rather it is left in place and simply overwritten on the next command to regenerate it. This means that it is totally safe to point to this file from the HTTP server configuration to use it as error page.

Examples for common HTTP servers:

Apache

Nginx

The path to the static file is based on the full URL - either the full URL you entered, or the resolved full URL of the page as determined by the "base" defined in the site configuration that's active for the page that you entered (with any conditions applied, e.g. application context). This full URL is then processed to a format that works as a standard file name by replacing any invalid characters ([':', '/', '?', '=', '.', '%', '&']) with an underscore, and always has the .html suffix added. So, for example a full URL of https://mydomain.com/my-error-page becomes a local file name of https___mydomain_com_my-error-page.html. URLs that contain a file extension will also include the file extension in the converted name: https://mydomain.com/my-error-page.html becomes https___mydomain_com_my-error-page_html.html.

Because the filename is based on the full URL you can generate multiple static files - for example if your TYPO3 site contains multiple sites with different URLs. You then simply have to define error documents in your HTTP configuration within a "location" block or other rule that matches each site. Similarly, you can generate dedicated error documents for each type of error (404, 403, 500, etc.) which show different error messages. Or you can use the same static file for multiple different error types or domains.

PSR-14 Events

Several events are included with the extension:

These events are subscribed to the same way any other PSR-14 event is subscribed to in TYPO3.

In Services.yaml of your extension:

And the event listener class:


All versions of static-error-pages with dependencies

PHP Build Version
Package Version
Requires php Version ^8.2
typo3/cms-core Version ^11.5 || ^12.4
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package busy-noggin/static-error-pages contains the following files

Loading the files please wait ....