Ichipen Page Fix Request

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

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). 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).

• Delivery test on the settings screen: send one sample request – with a small image and text file attached – through a single channel and see what happened. For GitHub the result is reported stage by stage, so a missing token permission points at the setting that causes it.

• 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.

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.

com (the REST API). No other GitHub host

is contacted by your site. When image embedding is enabled, the created issue

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

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 –

com/en/site-policy/github-terms/github-terms-of-service –

and GitHub Privacy Statement –

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.