Title: Ichipen Page Fix Request Author: ichipen Published: August 13, 2026 Last modified: August 13, 2026 --- Search plugins ![](https://ps.w.org/ichipen-page-fix-request/assets/banner-772x250.png?rev=3644527) ![](https://ps.w.org/ichipen-page-fix-request/assets/icon-256x256.png?rev=3644527) # Ichipen Page Fix Request By [ichipen](https://profiles.wordpress.org/ichipen/) [Download](https://downloads.wordpress.org/plugin/ichipen-page-fix-request.1.3.1.zip) * [Details](https://wordpress.org/plugins/ichipen-page-fix-request/#description) * [Reviews](https://wordpress.org/plugins/ichipen-page-fix-request/#reviews) * [Installation](https://wordpress.org/plugins/ichipen-page-fix-request/#installation) * [Development](https://wordpress.org/plugins/ichipen-page-fix-request/#developers) [Support](https://wordpress.org/support/plugin/ichipen-page-fix-request/) ## Description Ichipen Page Fix Request adds a small floating button to the front end for logged- in staff. With one click they can open a panel and report a problem with the page they are currently viewing. By default the request is emailed to a configured address and no third-party service is contacted. Submissions are never stored (only a single settings option is kept). It is designed to consolidate scattered request channels (LINE, phone, chat) into a single, low-cost flow. **Sending to your own system (API delivery)** Instead of (or in addition to) email, you can have each submission POSTed as JSON to an HTTPS endpoint that you configure under Settings > Fix Request. This is optional and off by default – no data leaves the site unless you set it up. When enabled, the request is sent with an `Authorization: Bearer` token you provide, and the JSON includes the request type and message, the page title and URL, the submitter’s WordPress user ID, display name and email, the site name and URL, and a timestamp. The data goes only to the endpoint you configure and to no other third party. **Opening a GitHub issue (GitHub delivery)** You can also have each submission opened as an issue in a GitHub repository you configure under Settings > Fix Request. This is optional and off by default. The issue title is built from the request type and page title; the Markdown body holds the same details as the email (type, page, URL, submitter and date) plus the message, and pasted screenshots are shown as `[Image N]` placeholders. Authenticate with a **fine-grained personal access token** limited to the target repository with ** read and write access to Issues**; the token is stored in its own non-autoloaded option, separate from the other settings. Requests go only to api.github.com over HTTPS. Optionally, you can also embed the pasted images in the issue. When enabled, each image is committed to a dedicated asset branch (default `fix-request-assets`, created automatically if missing) via the GitHub Contents API and shown in the body – inline for public repositories, or as a link for private ones (whose raw URLs do not render for other members). Those `raw.githubusercontent.com` / github.com addresses are only written into the issue text as Markdown links; your WordPress site never loads anything from them. This requires the token to additionally have **read and write access to Contents**. If an upload fails the issue is still created, with the affected image degraded to a text note. **Privacy note:** with image embedding enabled, screenshots are committed to your repository and therefore stored permanently in its Git history. Leave embedding off (the default) if you do not want that. **Design principles** * Zero third-party dependencies (no CMB2, ACF, jQuery or external APIs). * No submission data is stored (only a single settings option is saved). * Privacy friendly by default: nothing leaves the site unless you enable API delivery to your own endpoint. * Drop-in: works immediately. If no recipient is set, it falls back to the site admin email. * Everything is overridable with filters, so a host platform can integrate it with its own settings layer. **Features** * Floating “Request a fix” button shown only to permitted, logged-in users on the front end. Nothing (HTML or assets) is output for everyone else. * Panel with a request type selector, a details field, a send button and a status indicator. Opens/closes on click and closes on Esc. * Paste screenshots from the clipboard (Ctrl/Cmd + V) straight into the details field; they appear inline where you paste them. Images are embedded inline in the email (and included in the API payload) and never stored on the server or in the media library. * The current page URL and title are attached automatically. * The email contains: type, page (title), URL, requester name and email, timestamp and the request details. Reply-To is set to the requester. When screenshots are pasted, the email is sent as HTML with the images embedded inline (with a plain- text alternative). * Optional API delivery: POST each submission as JSON (with a bearer token) to your own HTTPS endpoint – email only, API only, or both. The payload includes the plain-text message, an HTML version (message_html) and any pasted images base64-encoded under images[] (each images[].cid matches the cid: reference in message_html). * Optional GitHub delivery: open each submission as an issue in a repository you configure (title, Markdown body and optional labels), using a fine-grained access token with Issues write access. Independent of email and API – enable any combination. Pasted images can optionally be committed to an asset branch (Contents API) and embedded in the issue – inline for public repos, linked for private ones. * Optional file attachments: attach non-image files (PDF, log, CSV, JSON, ZIP, … by default) alongside the message. Files are validated by extension AND real MIME type (a renamed .php/.svg/.exe is rejected), held in memory only, and delivered as email attachments, base64 in the API payload (files[]), and – when image embedding is on – committed to the GitHub asset branch and linked from the issue. Default limit 5 files, 5 MB each (configurable via ichipafi_file_limits). * Per-user rate limiting to prevent rapid repeat submissions (15 seconds by default). * “Settings” link on the Plugins screen for quick access to the configuration page. **Filters for host integration** * `ichipafi_recipient` – override the notification recipient. * `ichipafi_can_display` – override whether the widget is shown/submission is allowed( bool). * `ichipafi_categories` – override the request type list (key => label array). * `ichipafi_mail_subject` – override the email subject. * `ichipafi_mail_body` – override the plain-text email body (also used as the HTML email’s plain-text alternative). * `ichipafi_mail_html_body` – override the HTML email body (used when screenshots are attached). * `ichipafi_mail_headers` – override the email headers. * `ichipafi_image_limits` – override the inline-image limits (max count, max bytes, allowed MIME types); set max_count to 0 to disable image pasting. * `ichipafi_file_limits` – override the file-attachment limits (max count, max bytes, and the extension => accepted MIME types whitelist); set max_count to 0 to disable attachments. * `ichipafi_delivery` – override the delivery method (’email’, ‘api’ or ‘both’). * `ichipafi_api_url` – override the API endpoint URL. * `ichipafi_api_token` – override the API bearer token. * `ichipafi_api_headers` – override the API request headers. * `ichipafi_api_payload` – override the JSON payload sent to the API. * `ichipafi_api_args` – override the wp_remote_post() arguments. * `ichipafi_api_success` – override whether an API response counts as success. * `ichipafi_github_owner` / `ichipafi_github_repo` – override the GitHub repository owner/name. * `ichipafi_github_token` – override the GitHub access token. * `ichipafi_github_labels` – override the labels applied to created issues. * `ichipafi_github_attach_enabled` – override whether images are committed and embedded (bool). * `ichipafi_github_branch` – override the branch that committed assets are pushed to. * `ichipafi_github_body` – override the Markdown issue body. * `ichipafi_github_payload` – override the issue payload (title/body/labels) sent to GitHub. * `ichipafi_github_headers` – override the GitHub request headers. * `ichipafi_github_args` – override the wp_remote_post() arguments. * `ichipafi_github_success` – override whether a GitHub response counts as success. * `ichipafi_rate_limit` – override the rate-limit window in seconds. Example: supply the recipient from your own settings system. ``` add_filter( 'ichipafi_recipient', function () { return 'team@example.com'; } ); ``` ### External services With its default configuration this plugin contacts no external service at all: requests are delivered with WordPress’ own `wp_mail()`. All CSS, JavaScript and images used by the plugin ship inside the plugin folder; nothing is loaded from a remote server. The two optional delivery channels below are off until a site administrator turns them on, and each one is described here so you know exactly what is sent, when, and to whom. **1. GitHub (optional – only when “GitHub” delivery is enabled)** What it is: GitHub is a source-code hosting service operated by GitHub, Inc. This plugin uses its REST API so that each fix request can be filed as an issue in a repository that you own and configure under Settings > Fix Request. An account with GitHub is required to use this channel: you must own or have write access to the target repository and create a fine-grained personal access token for it. Nothing is sent to GitHub unless you enable the GitHub channel and supply both a repository and that token. Where it connects: `https://api.github.com` (the REST API). No other GitHub host is contacted by your site. When image embedding is enabled, the created issue contains links to `https://raw.githubusercontent.com` or `https://github.com`; those are addresses inside the issue text that GitHub itself resolves when a person views the issue – your WordPress site never requests them. What is sent, and when: each time a permitted logged-in user submits a fix request while the GitHub channel is enabled, your site sends to api.github.com the request type, the title and URL of the page being reported, the submitter’s WordPress display name and email address, the submission date and time, and the message text. Before creating the issue the plugin also reads the repository’s visibility and default branch, and reads or creates the asset branch. If – and only if – you additionally tick “Commit pasted images to the repository and embed them in the issue”, any pasted screenshots and attached files are also uploaded to that repository through the GitHub Contents API, which stores them permanently in the repository’s Git history. Service terms: GitHub Terms of Service – https://docs.github.com/en/site-policy/ github-terms/github-terms-of-service – and GitHub Privacy Statement – https://docs. github.com/en/site-policy/privacy-policies/github-privacy-statement **2. Your own HTTPS endpoint (optional – only when “API” delivery is enabled)** What it is: not a third-party service chosen by this plugin, but any HTTPS endpoint that you enter yourself under Settings > Fix Request – typically your own helpdesk, ticket system or internal API. Nothing is sent unless you enable the API channel and enter an endpoint URL. What is sent, and when: each time a permitted logged-in user submits a fix request while the API channel is enabled, the submission is POSTed as JSON to exactly the URL you configured (and to no other host), with the bearer token you supply in an` Authorization` header. The payload contains the request type, the message in plain text and HTML, the page title and URL, the submitter’s WordPress user ID, display name and email address, the site name and URL, a timestamp, and any pasted screenshots and attached files base64-encoded. Service terms: because you choose the destination, the applicable terms and privacy policy are those of the operator of that endpoint. ## Screenshots [⌊The floating "Request a fix for this page" button on the front end.⌉⌊The floating" Request a fix for this page" button on the front end.⌉[ The floating “Request a fix for this page” button on the front end. [⌊The request panel with type selector and details field.⌉⌊The request panel with type selector and details field.⌉[ The request panel with type selector and details field. [⌊The Settings > Fix Request configuration screen.⌉⌊The Settings > Fix Request configuration screen.⌉[ The Settings > Fix Request configuration screen. ## Installation 1. Upload the `ichipen-page-fix-request` folder to `/wp-content/plugins/`, or install the plugin through the Plugins screen. 2. Activate the plugin through the “Plugins” screen in WordPress. 3. Go to **Settings > Fix Request** to enable one or more delivery channels (email, API and/or GitHub), set the recipient email, API endpoint or GitHub repository, the button label, audience and request types. 4. If you do not set a recipient, requests are sent to the site admin email automatically. 5. For GitHub delivery, enter the repository as `owner/repo`, optionally add labels, and paste a fine-grained personal access token scoped to that repository with read and write access to Issues. To also embed pasted images, enable “Commit pasted images…”, set an asset branch, and grant the token read and write access to Contents( images are then stored permanently in the repository’s Git history). ## FAQ ### Who can see the button? Only logged-in users who match the configured audience. By default every logged- in user can see it; you can restrict it to selected roles. Logged-out visitors never receive any HTML or assets. ### Where are the requests stored? Submissions are not stored at all. Each request is delivered immediately – by email via `wp_mail()` and/or POSTed to the HTTPS endpoint you configure (depending on your delivery setting) – and is then discarded. Pasted screenshots and file attachments are held in memory only for the duration of the request and are never written to disk or added to the media library. The plugin creates no custom database tables; it only saves its own settings, which are removed on uninstall. ### What personal data does it handle? When a logged-in user submits a request, their display name and account email are included in the notification email (set as Reply-To), together with the page URL, title and timestamp. This is sent only to the configured recipient through your site’s own mailer (`wp_mail()`), or – if you enable API delivery – to the HTTPS endpoint you configure. The plugin never stores this data. ### Can I change where the emails go without using the settings screen? Yes. Add a filter on `ichipafi_recipient` (and/or the other `ichipafi_*` filters) from your theme or a host plugin to integrate with your own configuration system. ### Is any data sent to an external service? Not by default – the plugin uses WordPress’ own `wp_mail()` to send the notification, and it loads no remote scripts, styles or images. Two optional channels can send data out once you turn them on: API delivery POSTs each submission to the HTTPS endpoint you configure (and to no other host), and GitHub delivery files each submission as an issue on `api.github.com`. Both are described in full, with the relevant terms of service and privacy policy, under “External services” above. ### What files can be attached, and are there size limits? By default up to 5 files of 5 MB each, with extensions pdf, txt, log, md, csv, json and zip. Executable or scriptable types (.php, .phtml, .svg, .exe, …) are rejected, and every file’s real content is checked against its extension so a renamed file is refused. Attachments are held in memory and never written to disk or the media library. Because they are uploaded through admin-ajax.php, the total request must also fit within your server’s PHP `upload_max_filesize` and post_max_size limits– raise those if you increase the per-file limit via the ichipafi_file_limits filter. ## Reviews There are no reviews for this plugin. ## Contributors & Developers “Ichipen Page Fix Request” is open source software. The following people have contributed to this plugin. Contributors * [ ichipen ](https://profiles.wordpress.org/ichipen/) [Translate “Ichipen Page Fix Request” into your language.](https://translate.wordpress.org/projects/wp-plugins/ichipen-page-fix-request) ### Interested in development? [Browse the code](https://plugins.trac.wordpress.org/browser/ichipen-page-fix-request/), check out the [SVN repository](https://plugins.svn.wordpress.org/ichipen-page-fix-request/), or subscribe to the [development log](https://plugins.trac.wordpress.org/log/ichipen-page-fix-request/) by [RSS](https://plugins.trac.wordpress.org/log/ichipen-page-fix-request/?limit=100&mode=stop_on_copy&format=rss). ## Changelog #### 1.3.1 * Rename every global to the unique `ichipafi` prefix (functions, classes, constants, options, transients, the AJAX action and nonce, script/style handles and the localised script object). The filters documented above are now `ichipafi_recipient`,` ichipafi_can_display` and so on; the old `pfr_*` names are gone. * Document the external services the optional delivery channels use, with links to their terms of service and privacy policy – see “External services”. * Stop bundling translation files. Translations are provided through translate. wordpress.org instead. #### 1.3.0 * Delivery is now a set of independent channel toggles (Email, API, GitHub) instead of a single method, so any combination can be enabled. Existing installs and the ichipafi_delivery filter keep working unchanged. * Add GitHub delivery: open each submission as an issue in a repository you configure( title, Markdown body, optional labels), authenticated with a fine-grained access token. New filters: ichipafi_github_owner, ichipafi_github_repo, ichipafi_github_token, ichipafi_github_labels, ichipafi_github_body, ichipafi_github_payload, ichipafi_github_headers, ichipafi_github_args, ichipafi_github_success. * Add optional GitHub image embedding: pasted images are committed to an asset branch via the Contents API and shown in the issue – inline for public repositories, linked for private ones – with graceful fallback to a text note on failure. Images committed this way are stored permanently in the repository’s Git history. New filters: ichipafi_github_attach_enabled, ichipafi_github_branch. * Add “Capture this page”: grab the current tab with the browser’s getDisplayMedia() and attach it as a screenshot (no external libraries). The plugin’s own panel is excluded from the shot; unsupported browsers simply hide the button. * Add file attachments: attach non-image files (PDF, log, CSV, JSON, ZIP, … by default) validated by extension and real MIME type, delivered as email attachments, base64 in the API payload (files[]), and GitHub commit links. New filter: ichipafi_file_limits. * New per-channel delivery action: ichipafi_delivery_result, and channel filters ichipafi_channels, ichipafi_available_channels. #### 1.2.0 * Add inline screenshot pasting: paste images from the clipboard (Ctrl/Cmd + V) directly into the details field. Images appear inline where pasted, are embedded inline in the email (HTML with a plain-text alternative) and included in the API payload as base64. Images are never stored on the server or in the media library. * API payload additions: message_html and an images[] array (base64; each images[]. cid matches the cid: reference in message_html). The existing fields are unchanged. * New filters: ichipafi_mail_html_body, ichipafi_image_limits. * Limits: up to 3 images, 2 MB each, PNG/JPEG/GIF/WebP (configurable via ichipafi_image_limits). * Add a “Settings” link to the plugin’s row on the Plugins screen. * Fix: saving the settings could replace the entire request-types list with a single“ Array” entry. The settings sanitizer is now idempotent (WordPress runs it twice when the option is first created), and the request-types list falls back to the defaults if it is ever stored empty. #### 1.1.0 * Add optional API delivery: POST submissions as JSON (Authorization: Bearer) to your own HTTPS endpoint, selectable as email, API or both. * New filters: ichipafi_delivery, ichipafi_api_url, ichipafi_api_token, ichipafi_api_headers, ichipafi_api_payload, ichipafi_api_args, ichipafi_api_success. * Remove the manual load_plugin_textdomain() call (translations load automatically on WordPress.org). #### 1.0.0 * Initial release. ## Meta * Version **1.3.1** * Last updated **9 hours ago** * Active installations **Fewer than 10** * WordPress version ** 6.4 or higher ** * Tested up to **7.0.4** * PHP version ** 8.1 or higher ** * Tags * [email](https://wordpress.org/plugins/tags/email/)[feedback](https://wordpress.org/plugins/tags/feedback/) [maintenance](https://wordpress.org/plugins/tags/maintenance/)[staff](https://wordpress.org/plugins/tags/staff/) * [Advanced View](https://wordpress.org/plugins/ichipen-page-fix-request/advanced/) ## Ratings No reviews have been submitted yet. [Your review](https://wordpress.org/support/plugin/ichipen-page-fix-request/reviews/#new-post) [See all reviews](https://wordpress.org/support/plugin/ichipen-page-fix-request/reviews/) ## Contributors * [ ichipen ](https://profiles.wordpress.org/ichipen/) ## Support Got something to say? Need help? [View support forum](https://wordpress.org/support/plugin/ichipen-page-fix-request/)