RocketCake is a visual website editor for building responsive pages without writing the page layout by hand. A user places text, images, buttons, containers, menus and form controls on a canvas, then RocketCake generates the HTML and image files needed by a browser. The same project holds the desktop and mobile arrangements. RocketCake changes the placement and size of elements at selected screen widths instead of requiring a separate mobile site.
Design starts wide
The documented workflow begins at the largest screen width the site should support. The designer then narrows the editor and adds breakpoints where the layout stops fitting. A breakpoint can change an element’s width, position, font or visibility below that width. This makes a wide navigation bar become a compact mobile arrangement while the text and links still belong to one page.
RocketCake does not decide where those changes belong. A card that looks balanced on a large canvas can overlap another object after the canvas narrows. Hiding the wrong container at a breakpoint can also remove its children from the small-screen page. Each breakpoint therefore needs a visual check at widths just above and below it, followed by a test in a real browser. Adding many breakpoints can solve individual collisions, but it also leaves more states to inspect after a later edit.
Pages share structure
Master pages hold repeated parts such as a header, footer or navigation area. A normal page can use that master rather than carrying an independent copy of every repeated element. An edit to the master then reaches the pages that use it. This is useful when a site grows beyond a few pages, because a menu item does not need manual replacement on every page.
The page itself still controls its own content and filename. Renaming or moving a page changes how it should be linked, so internal navigation needs another check before publishing. RocketCake can preview the generated site locally, but that preview cannot reproduce every behavior of the hosting server.
Forms need a server
A contact form is more than a collection of text boxes. RocketCake requires a Web Form container, and the input controls must sit inside it. The button needs the Submit action, while the page needs server-side processing that receives the posted fields. The official contact-form procedure changes the page filename to PHP and adds a PHP code element for that work.
This creates an important testing limit. RocketCake’s Preview command displays PHP source rather than running it. The form works only after the page reaches a web server with PHP support. A hosting plan that serves static files alone can display the page but cannot process the submission. Using an email address directly as the form action is also unreliable, since it depends on the visitor’s local mail setup. The practical test must happen on the actual host, and the receiving script still needs validation and spam controls.
Publishing has two paths
Publish to local disk writes the generated HTML and images into a chosen folder. This route lets the owner inspect the output or upload it with a separate file-transfer client. Publish to the Internet sends the same output through RocketCake’s built-in connection. FTP, FTPS and SFTP addresses are accepted, with an optional remote folder and nonstandard port.
The upload command cannot infer the document root assigned by the hosting company. Choosing the wrong remote folder can leave the new files at an address the public site never uses, while publishing over an existing folder can replace files with matching names. RocketCake makes the page construction visual; domain setup, certificates, server-side form handling and backups remain separate hosting tasks.
