נבנה עם כלי אחר

יש בפרויקט התחברות משתמשים, תשלומים, או מידע שנשמר בין ביקורים?

להעתיק את ההנחיה ולהדביק אצל המנוע שבנה את האתר

Package the entire project into a single downloadable .zip file.
Put index.html at the root of the zip.
Inline the CSS and JavaScript into index.html, or include them as relative files inside the same zip.
If the project uses a build tool such as Vite or Parcel, keep package.json and package-lock.json together at the root of the zip, and make sure the build writes its output to a folder named dist/.
Run npm ci && npm run build yourself before packaging, and only package the project once that build succeeds. A project whose build fails cannot be hosted.
The site is hosted as a static site with exactly one platform service available: form submissions. There is no other backend: no server code, no environment variables, no API keys, no database.
Every clickable feature must actually work after upload. Any feature that needs a backend (login, payments, user accounts, comments, server-side search) must be adapted to work statically or removed, and every such decision must be listed in dynamicParts below. Never ship UI that silently does nothing.
Wire every form to the platform forms endpoint: POST the form fields to https://hosting.handsome.co.il/f/HH_FORM_TOKEN, as application/x-www-form-urlencoded or as JSON.
Submit every form with JavaScript, never with a plain form action attribute. In the submit handler call event.preventDefault(), send the fields with fetch(), and keep the visitor on the page. A form the browser navigates lands the visitor on a raw JSON page with no way back, which reads as broken even though the message was delivered.
The endpoint reads exactly two encodings. Either send application/x-www-form-urlencoded, built as new URLSearchParams(new FormData(form)), or send a JSON string with an explicit "Content-Type: application/json" request header.
Never pass a FormData object straight to fetch as the body: the browser then sends multipart/form-data, which this endpoint rejects with an error status and no mail, so the form shows its failure message on every single submission. A JSON string sent without that Content-Type header goes as text/plain and is rejected the same way.
Keep the placeholder HH_FORM_TOKEN exactly as written. Do not invent, guess, or configure a token: the platform replaces that placeholder with the real one at deploy time.
In every form, name the visitor's email field "email" so replies reach the person who wrote in, and add a hidden text input named "_gotcha" that is left empty.
Show the form's success message in place, on the same page, only when the response status is 200 and the parsed JSON body has an "ok" field that is true. On any other status, on a body whose "ok" is not true, and on a network error, show the form's failure message instead. Do not compare the whole response body against a fixed string: the response may gain fields later. Never show a success message without checking the response.
The endpoint accepts at most 30 fields per submission and at most 2000 characters per field value; anything past those limits is dropped without warning. Keep every form inside them.
If the site has no forms at all, use "services": [] and do not reference the endpoint anywhere.
Never ask the user questions. Make sensible choices yourself and record them in handsome.json so the user can correct them later.
Add a file named handsome.json at the root of the zip with exactly this shape:
{
  "manifestVersion": 1,
  "project": { "name": "<project name>", "type": "website", "audience": "one of: solo, small, unsure", "notes": "<one or two sentences worth knowing about this project>", "suggestedDomain": "<a realistic domain name for this project, or null>" },
  "runtime": { "static": true, "buildStep": null, "outputDir": null, "secretsPresent": false },
  "resources": { "cpu": 1, "storageGb": 1, "bandwidthProfile": "one of: low, medium, high", "reasoning": "<one line>" },
  "services": ["form-mail"],
  "dynamicParts": [ { "kind": "contact-form", "status": "one of: wired-to-platform, adapted, removed", "note": "<one short sentence, under 300 characters>" } ],
  "compliance": { "reportedBy": "builder", "docs": { "accessibility_statement": { "present": <true if this project has an accessibility statement page, else false>, "path": "<its path, or null>" }, "terms_of_use": { "present": <true or false>, "path": "<path or null>" }, "privacy_policy": { "present": <true or false>, "path": "<path or null>" } } }
}
Every "one of:" field above must be replaced with exactly one of the values listed for it. Never copy the list itself into the file, and never invent a value that is not listed.
Replace every <...> placeholder with a real value, or with null where the shape allows it.
List every interactive feature of the site in dynamicParts, one entry each.
For the "compliance" block, check honestly whether THIS project already contains each page: an accessibility statement, terms of use, and a privacy policy. Set "present" to true only when the page genuinely exists in the project and give its path; otherwise set "present" to false and the path to null. Never invent a document or a path that is not really there.
Include a basic accessibility layer so the site is usable with the keyboard and by assistive tech: at minimum visible keyboard focus, a skip-to-content link, adjustable text size, a high-contrast option, and correct ARIA landmarks. A baseline layer, not a substitute for an accessibility audit or statement.
The result must open correctly by double-clicking index.html.

משהו הוסר? זה יופיע לפני התשלום, ואפשר לחזור ולבחור 'כן'.

איך מוציאים את הקובץ

לאסוף את קבצי הפרויקט לתיקייה אחת ולארוז אותם לקובץ zip.
להעלות את הקובץ כאן, ואנחנו נבדוק מה אפשר לעשות איתו.

בחירת קובץ

יש בפרויקט התחברות משתמשים, תשלומים, או מידע שנשמר בין ביקורים?

איך מוציאים את הקובץ

הרשמה