Make this portfolio yours

1. Open your website

2. Change the words, details & contact

1. In the editor, choose Text & links.
2. Choose Portfolio identity & contact from Choose a chapter. Add your name, qualification, email, region and optional professional-profile URL. A blank email disables the email button; a valid email creates a button that opens the visitor’s email app. There is no form or message database.
3. Choose each of the twelve chapters. Replace the biography, school details, dates, lesson activities, reflections and other sample copy. Headings and quotations can be changed too.
4. Edit internship facts in both Home and My Internship. Their two fact panels are separate. Check sample grade details in My Learners as well.
5. Replace all three sample numbers on Home with verified counts. Replace the word “Sample” in their labels only when they represent genuine work.
6. Use blank lines (press Enter twice) in Reflective Summary → Introduction and Paragraphs, Teaching Philosophy → Body and the two My Learners → Profiles → Introduction fields to start new paragraphs. Text is displayed literally, not as HTML.
7. Select Preview changes. This opens a temporary preview, not a saved website. Some browsers block preview storage for local files; if that happens, use export instead.
8. Select Export content.js. Find the downloaded file, usually in Downloads. If your browser calls it content (1).js, rename it to content.js.
9. Move that file into the portfolio folder and replace the old content.js. Refresh index.html. Use Ctrl+Shift+R (Windows/Linux) or Cmd+Shift+R (Mac) if you still see the old text.

Save draft before closing; export regularly too. A downloaded file is your backup. Use Import content.js to continue from an earlier export. Reset to loaded content discards tab edits and returns to the file loaded when the editor opened; save afterward to replace your stored draft. It does not change the public website.

3. Replace every picture

There are seven fixed picture slots. The schoolLogo slot starts blank until your actual logo is supplied. Teaching in Action has its own photo and video controls under Text & links.

Easiest method: upload in the editor

1. Choose Pictures in editor.html.
2. Find the slot using the list below.
3. Choose Upload picture for… and select your JPG, PNG or WebP.
4. Write an accurate Image description, such as “Teaching materials for a lesson on action verbs”. Avoid unnecessary learner identities.
5. Export content.js and replace the old file, just as for text. Your uploaded picture is embedded in this file: you do not need to copy it separately.

The editor accepts up to 8 MiB per picture and resizes large pictures to a maximum of 1600 pixels. Aim for under 500 KB per photo where practical. Embedding many photos makes content.js larger; for a large gallery, use the manual method instead.

Alternative: copy picture files yourself

1. Copy your image to assets/. Use simple filenames like my-portrait.jpg, with lowercase letters and hyphens.
2. In the editor’s Pictures section, enter assets/my-portrait.jpg in that slot’s Optional local filename, then leave the field so it applies.
3. Edit the image description, export and replace content.js. Keep the image in assets when you publish.
4. For a code editor instead, open content.js, find "portrait" under "images", and change its "src" and "alt". Keep quotes and commas intact.

Do not overwrite an SVG with a JPG while keeping the .svg extension. Put the JPG in assets and change the filename. Do not delete fonts, book.svg, botanical.svg, paper.svg or watercolor.svg; those are design assets, not photo slots.

Picture-by-picture map

Pictures crop to their frames. Keep important content away from edges. Check every image on desktop and phone.

Captions and small notes are editable too

After replacing the demonstration images or resources, choose Portfolio identity & contact → Display Notes in the editor. Update the hero image label, school-photo label, sample-metrics note, gallery note and resource notes so they accurately describe your real material. Do not remove the sample warnings until the corresponding samples have been replaced.

Captions are separate from picture descriptions

Change Home’s polaroid captions in Home → Polaroids. Change Teaching in Action captions and modal explanations in Teaching in Action, alongside each uploaded photo or clip. Change the journal caption in Reflective Summary → Caption. Image descriptions are for accessibility; captions are the visible story.

4. Upload lesson PDFs and internship records

Lesson Plans has Week 01 through Week 06. Each row accepts one real PDF. Testimonials contains three sections: Classroom observation forms (two PDFs), Timetable (one PDF), and Internship completion letter (one PDF). No documents are supplied; blank rows have no download links.

1. Choose the chapter in Text & links. Use Upload PDF for the relevant slot; PDF files may be up to 15 MiB (15,728,640 bytes) each. Remove PDF clears a slot.
2. Alternatively set a Local PDF path such as resources/week-01.pdf and copy that actual file into the folder. Only safe local PDF paths are accepted.
3. Export content.js. Uploaded PDFs travel inside the export; local files must be copied/deployed separately. The public Download PDF button downloads the actual file.

Teaching in Action: photos and clips

Choose Teaching in Action under Text & links. Add up to 30 photos and 3 video clips. Upload JPG/PNG/WebP photos (8 MiB maximum, resized to 1600 px), or MP4/WebM clips (15 MiB / 15,728,640 bytes maximum, inclusive). Each item has an editable caption, description and details, local path and Remove button. Empty items are not shown as real media. Visitors can enlarge photos and play clips using real video controls. Include a useful text description/transcript for accessible video content; obtain captions for speech before publishing.

The local content budget is 100 MiB (104,857,600 bytes), inclusive, measured as UTF-8 bytes of compact JSON including all media, text, metadata and legacy archives. Base64 adds about one third: aim for roughly 70 MiB of combined original media. The theoretical 75 MiB base64-only ceiling leaves no space for text or metadata and is not a guarantee; large custom text/archives reduce available media space. Photos are resized/re-encoded, so selected original sizes do not map exactly. Per-file 8/15/15 MiB limits apply to original selected photos/PDFs/clips. Large drafts may be slow and need several times their serialized size in browser memory. Compress files, use short clips, or use assets/ paths for larger media. Export does not upload/copy local files. Browser quotas may be lower: keep portable exports. Preview uses session storage for small drafts and local IndexedDB for large ones; the public site never loads preview data without ?preview=1.

Import accepts a separate 101 MiB file envelope for assignment/comments and whitespace, but parsed and migrated content must each fit the 100 MiB compact-JSON budget. Exports automatically use compact JSON if pretty formatting would exceed that envelope. GitHub has a separate 100 MiB limit on the final file, including assignment and formatting; the editor refuses oversized files before sending a write. GitHub API limits may be lower. A maximum-sized local draft is not a promise of successful publication. Use local media paths or reduce embedded media.

Privacy warning: everything in content.js and deployed assets is public on GitHub Pages, including signatures, minors, signed consent, and archived legacy content. Keep original consent records private; use only authorised, properly redacted public copies. Never upload private originals merely to prove consent.

Older exports and saved drafts

The editor safely parses JSON only. Complete original fourteen-chapter exports and saved drafts migrate to twelve active chapters. Your other original data is retained in a non-rendered legacyArchive field. Custom legacy gallery photos are retained; stock illustration placeholders are not promoted to actual photos. Retired pages, old lesson/feedback copy and journal links remain only in the archive. Review/remove private archived data before publishing; exports include it. Old saved base versions are normalised for conflict checking, but original SHA guards remain. A changed remote base still requires an explicit reload; migration never silently publishes or overwrites remote content. Previous twelve-chapter exports and actual saved drafts with four Testimonials sections also migrate. The old second section (principal/teacher consent) and its PDF bytes are deliberately dropped, even when its titles were customised and even inside known legacyArchive portfolios. Other PDFs, titles, copy, pictures and clips remain. Keep your original export offline for your private backup; removed consent is not hidden in new exports. Migration cannot erase old deployed content, repository history, browser data or separately copied files: remove any sensitive public originals separately.

5. Publish the static folder

No installation, build command, database or server code is required. The site uses plain HTML, CSS and JavaScript. It can be hosted by any static host.

Update this GitHub website: save first, publish second

1. Use Save draft in the editor to keep text and embedded photos in this browser. Reopen the same editor address in the same browser profile to restore it. Save draft does not publish. Other people using that browser profile can see drafts; clearing browser data/private browsing can lose them. Export content.js regularly as a portable backup.
2. Sign into GitHub separately using your own account. The editor's convenience gate does not grant GitHub access. Your account needs write access to Sasiru382/teacher-portfolio.
3. Owner setup: in that repository, open Settings → Collaborators → Add people, invite the teacher's GitHub username and ask them to accept. No invitation is sent automatically.
4. In your GitHub account settings, choose Developer settings → Personal access tokens → Fine-grained tokens → Generate new token. Set a short expiry, choose the repository owner, then Only select repositories → teacher-portfolio. Set Repository permissions → Contents → Read and write. No Workflows write permission is needed. GitHub may require organisation approval or enforce branch rules.
5. GitHub currently does not support fine-grained tokens for outside/repository collaborators (GitHub limitations). If the teacher is a collaborator on this personal repository, stop at token setup. Ask the owner to publish with their own restricted token, or use a teacher-owned fork configured by a developer. Do not share an owner's token or broaden access as a workaround.
6. Paste the token only into the editor's masked GitHub token field. It is used in memory for this action and cleared after success, failure or cancellation; it is never put in drafts, exports, browser storage or URLs. Decline browser password-save prompts and revoke the token in GitHub when finished. Never put it into a portfolio text field. Use only the trusted site and browser.
7. Review the privacy checklist, save and export a backup, then click Publish to website. Confirm the public scope: content.js in Sasiru382/teacher-portfolio, main. Text and embedded photos, clips and PDFs are sent to GitHub. New local images/PDFs must be uploaded separately; this button only changes content.js.
8. If you see a conflict, export your draft first. Choose Reload remote content and confirm replacing your draft with GitHub's version. Reapply your edits carefully using the exported backup. The editor will not silently overwrite someone else's changes.
9. Changes committed; deployment pending is not a live-site confirmation. Open GitHub Actions and find the commit shown in the editor. Wait for Test and deploy portfolio to succeed, then refresh the public website and check it. If queued, wait. If failed, keep your draft and ask the owner to inspect the failed job. The editor does not poll CI or verify the live site.
10. 401 means the token is invalid/expired; 403 can mean missing permission or rate limits; 404 can mean missing repository access; 409/422 means a conflict or repository rule may block publishing. Export before reloading. For a network failure, check GitHub before retrying in case the commit already arrived.

Contents write permission covers repository files, not just content.js. Keep tokens short-lived, never share them and restrict them to this repository. Export/import and offline preview still work without GitHub. If browser storage fails, export immediately before closing.

Alternative: drag-and-drop with Netlify

1. Finish the privacy and demo-content checklist below before going online.
2. Create a clean publishing folder. Copy index.html, content.js, asset-policy.js, schema.js, app.js, styles.css, the full assets/ folder and the full resources/ folder. Copy editor.html, editor.js, editor.css, guide.html, guide.css, README and asset credits only if you want public editing/help pages. Omit tests, node_modules, screenshots and private backups. Remove the sidebar editor/help links in index.html if you omit those pages.
3. Open Netlify Drop and sign in / create your own account when asked. Drop the clean folder, not individual files. It must contain index.html at its top level.
4. Netlify gives you a website address. Open it and check every chapter, photo and resource.
5. To update, replace content.js locally, add any new assets/PDFs, then upload the updated publishing folder using the manual-deploy area for that same site. Do not create a new site each time unless you want a new address.
6. Keep a local backup. A custom domain is optional and managed separately through your host.

This portfolio is configured for GitHub Pages. You control when to publish edits. Hash links such as index.html#about-me work without server routing rules.

6. Before publishing: privacy & truthfulness

• Replace “Your Name”, placeholder qualifications, school details, dates, location and all sample biographies.
• Verify all three Home metrics. Remove “Sample” labels only when the numbers are genuine.
• Replace the seven fixed image slots or deliberately retain clearly labelled illustrations.
• Leave unsupplied documents, logo and gallery blank; never invent evidence.
• Review all uploaded PDFs and legacyArchive content for signatures, identities and private information.
• Read all twelve pages. Replace generic reflection claims with your own experiences; check headings, gallery captions and download descriptions.
• Obtain school approval, photographer permission and appropriate consent before publishing identifiable students. For minors, follow your school’s parent/guardian consent process and applicable law; learner assent may also be appropriate. A materials-only photo is often safer.
• Remove student names, grades, ID numbers, contact details, private feedback, signatures and unnecessary identifying information. Redact documents properly, not just with removable black boxes.
• Remove image location metadata. Do not publish a home address, private phone number or confidential school information.
• Use only images and files you own or have permission/licence to publish. Keep records of consent and be ready to remove material if permission is withdrawn.
• Test email and professional links. Email opens a mail application; it does not submit a message to the website.
• Check all resource links, mobile layout and spelling. Ask a trusted reader to review it.
• Only after every demo claim is replaced, change the demo-content notice in Portfolio identity & contact to an accurate statement. If any sample remains, retain a clear notice.

Publishing the editor does not expose a secret backend: anyone can open it and edit their own local draft, but only an authorised GitHub token can publish to your repository. However, every uploaded website file is public. Never include credentials, consent records or private backups in the publishing folder.

Quick fixes