This guide gives tips for creating a static copy (just dumb html files, no server or submission support) of an event for hosting on the Puzzle Archive.

0. Ideally, your puzzles have been created using the other guides on this wiki. This means that they're either PDFs or are webpages that only reference other files relative to their repo (and of course you have access to that entire repo), meaning no changes will need to be made to the puzzles themselves for hosting, and the puzzles won't need to all be saved individually from their online locations.
   
   
   • If that's not the case, be careful when saving the puzzles, since not all accompanying files will be saved automatically! In particular, src files for audio and video tags, or background-image files from CSS will need to be individually downloaded from the page as well.
   • Font files are also not downloaded, so if any pages use a custom font file, you'll likely need to obtain that elsewhere.
     
     
1. Besides the puzzles, you'll want to save all player-visible pages from the site that aren't for any individual team. That means the list of all teams is fine, but the info page for your specific team isn't necessary.
   
   
   • Any page that's filled with PII (personally identifiable information) like email addresses or individual names of players should be avoided. Author names are okay though, since we want to give credit to authors! Player submissions will also not be saved, since that simplifies not needing consent; the archive is mainly about the puzzles!
   • Most admin-only pages also aren't necessary, including the puzzle state map. When in doubt, just look at which pages have been saved in past years.
   • When saving the puzzle list page, if the event had embedding enabled and you have admin access, disable it. It will make the links to the puzzle files need less manual editing after the page is saved. This also means the puzzle links will be just the puzzles, not the embedded versions of the puzzles, since embedding makes no sense in an archive that doesn't have submission functionality! This does unfortunately mean that per-puzzle styling of the embedding page will be lost, though.
     
     
2. To save a page, just right-click and Save As. Don't worry about renaming, we'll do that in a minute. Make sure you do the "Webpage, Complete" HTML option, not any of the other options, since that will also download accompanying images, styles, etc.
   
   
   • For best compatibility, save from a Chromium-based browser like Chrome or Edge.
   • All pages should be placed in the root folder of whatever event you're saving. For example, Non-Intern Puzzleday uses the "year.5" nomenclature, so NIPD 2025 would be in puzzleday\2025.5.
     
     
3. Windows, when saving a webpage, will automatically link the folder containing all its supporting files to the HTML file. For example, when you save "Page.html", you will also see the "Page_files" folder created. We need to break that link since we'll be manually making all pages share the same set of resources instead of each page having a copy of its own. To do this, just rename the webpage, and when Windows warns that you're breaking that automatic link, click OK.
   
   
   • Although file names can have spaces in them, it's good practice to NEVER use spaces since they require escaping in URLs. For folders, multiple words are fine, combined however you want (camelCase, hyphens, etc.). For files, single words are best.
   • File extensions should be full; we don't need to stick to DOS 3 character limits. That means using "html" instead of "htm". They also don't need to be in all caps.
   • File names should also be all lowercase when possible since URLs are case-sensitive and this reduces possible errors.
   • The file names of the pages aren't too important, but following past convention is good (the list of puzzles is puzzles.html, etc.) Most important is naming the main landing page something like "home.html" since it will need to be linked to from the list of events, and having similar names between events makes mistakes less likely.
     
     
4. Once all the folder links are broken, make sure you scavenge any files out of them that you need. That will mostly be images like the event's logo or the pictures from the encodings and sample puzzles pages. You'll temporarily need other files like CSS files for reference, but eventually they can all be discarded, along with the folders and everything else in them. See the next section for more details.

1. Past events have had all pages (besides for webified puzzles) share necessary images from an "images" folder located alongside them and other files like CSS files from a "resources" folder. Move any images from individual page folders into the images folder.
   
   
   • While you're looking at past events to see their file structure, go ahead and just copy the "resources" folder from a prior event of the same type. Specifically, Puzzleday events should only use resources from other Puzzleday events, etc. One slight exception is Non-Intern Puzzleday, which is so similar to Puzzleday, it can just copy the resources from the Puzzleday event of that same year.
   • At minimum, you should have site.js and site.css files in the resources. The JS file is necessary to make the dropdowns at the top of the page work and shouldn't need to be altered. The CSS file will need minor updates from year to year.
   • You may also need a copy of puzzle.js, which contains files puzzle.js, puzzle.css, and puzzle-basic-colors.css for the sample puzzle. Those can also live in the resources folder.
   • When keeping track of other resources you'll need content from but not the entire file, "site.(min.)css" and "style(s).(min.)css" are the only ones that matter. Framework files like blazor, jquery, popper, and bootstrap, as well as any javascript files, can be discarded entirely.
     
     
2. After you've accounted for all page resources, go ahead and copy the repo with all the puzzles into the folder as well. You can keep its internal structure unchanged.
   
   
   • The name of the folder doesn't matter; if your repo was called "event-webification-repo", you can just keep it like that.
   • In general, only puzzles will reference files inside the repo folder, and they won't reference anything outside of it. Conversely, only event webpages will reference files outside the repo folder, and they won't reference anything inside of it. That may mean occasional resource copying. For example, if a specific font is used on both webpages and puzzles, the font file will need to live in both the event/resources folder and in the event/puzzle-repo/resources folder.
   • Don't bother bringing over anything that isn't used directly by a puzzle though: old event libraries, GIT files (which are in a hidden folder), readme files, drafts or materials used to build final puzzle assets, etc. can all be removed.
   • In fact, as a good practice, nothing should be uploaded to the server if it isn't directly user accessible or needed by a page that is. That means you may also need to manually delete old files off the server if, for example, you replace a ZIP of an event's puzzles with the full site for that event.
   • As a good shortcut, events like NIPD can just copy over the repo directly from the Intern event as well. Just make sure to remove puzzle files for any puzzles that weren't run.
     
     
3. Now, we can focus on the CSS (if we need to; see the next section). Before that though, if the event is using custom homepage/faq/rules content files, you will see those inside the individual page folders. We won't be keeping the dual-page structure; that was only set up for easy site updates. Since these files will live forever as-is, we can just copy the content from the content file back into the main file (see the content editing section later).

Every non-puzzle page is going to use the same site.css file mentioned previously.

1. The site.css file copied from a prior event should keep most of its contents unchanged. Only at the bottom should you start to see certain classes with years in their name. Those can either be removed if this new event doesn't use anything similar, or updated if the class name just needs the year changed. When in doubt, you can always go back to the live website and use the F12 tools to see which classes are actually being used on a particular element if you need to debug the page while updating the CSS.
   
   
   • If there are no year-specific classes in the css file, you might be able to just move onto the next section about content editing! New events that use the custom home/rules/faq files no longer need to store their css in the main site.css file. Instead, you'll just need to make sure that when you copy the home content into the main home file, you also copy its css. Same for the rules, etc.
     
     
2. When adding new classes, the main ones you'll care about are the ones you specifically see used in the main body content of the pages you saved. You don't need to copy anything relating to the navbar at the top, the footer, or the basic site layout, since it should already be in the CSS file. For example, the container class that already exists adds padding to the left and right of the main content so it doesn't touch the very left and right of the screen. You can just use this class for the main content of all pages without re-defining it. You can see how past events edited the structure of the page and follow their example (more on this in the next section).
   
   
   • If there are any new CSS entries or updates to classes, they will likely be in the "-customizable" classes that are mentioned in the Customization Wiki.

This will be the most time-consuming part of the process, especially if the puzzles do end up needing individual editing.

0. For webified puzzles, individual puzzles will only need editing if they did not set up their resource files such that all links are relative links that work both in local repos for testing and online. If that's the case, you'll see that their link to CSS files will be something like https://puzzlehunt.azurewebsites.net/css/pd2023/base-styles.css instead of ../../resources/base-styles.css, and you'll need to change all those web links to point to the local resources file at ../../resources instead.
1. For the rest of the pages, you'll want to start with copying the "supporting content" from a previous event. That basically means everything that's not the main "body content" of every page. First, copy the start of a file from the opening html tag down to the div with the body-content class or the div directly inside it with the container class. Then, you'll replace that exact same portion in every new file with that copied portion. If you look at multiple files from a past event, you can see exactly which portions were identically copied/pasted.
   
   
   • At minimum, you'll need to update the year in both the title tag (which appears in the browser's tab) and the homepage link text at the top left of the navbar with the year/event name for the new event.
   • Don't forget to also update the actual page name in the title too. Like, if you're copying the header from the "home" page, you'll want to make sure you update each individual page's title to be the Encodings page, Puzzles page, etc. after you paste it in. Feel free to also rename the page to something that makes more sense, like calling the home page "Homepage" or the puzzles page "Puzzles".
   • If the pages you saved this year are different in total from the previous year, you'll also need to update the navigation options. Like, if you named the sample puzzles page something different, you'll need to update that filename from the previous year in the navbar link, or if the event has no sample puzzles, you'll need to remove that link entirely from the navbar.
   • Be a little careful when getting rid of the old head content. For example, if the page had custom styles, you'll want to keep those. In general though, you will only be getting rid of links to javascript we don't need anymore and parts of the navbar like your personal email address that we don't want to keep.
     
     
2. Next, copy the closing tag of that container or body-content div down to the end of the file and replace that portion in the new files as well.
   
   
   • If you're doing this long after the fact, just update the copyright year to the current year.
   • If you're copying from a different type of event, make sure the contact email address in the footer is correct.
   • Don't forget to make sure the number of div tags you pasted at the top match the number of closing tags at the bottom!
     
     
3. If there are custom home/rules/faq pages, you can get rid of everything inside the body-content divs in them and replace it with everything inside the body tags of the associated home-content/rules-content/faq-content files. If those files have style content, don't forget to move that over as well!
   
   
   • One exception: if the content files have an overflow-y: hidden; property, don't copy that over. It was needed to make sure the embedded content didn't have double scrollbars.
   • There likely shouldn't be any other files linked to in those content files that you'll need to grab content from or links to. In other words, the content files should only contain basic html and maybe some css in a style tag as well.
     
     
4. When editing the actual body content of the pages, feel free to remove any extraneous content that is both irrelevant for the archive and also not important for understanding the overall feel of the event. For example, any announcements at the tops of pages can be removed. So can links to filters, like the link at the top of the Fastest Solves page to only show unsolved puzzles (they won't work anyway) or radio buttons to filter puzzles on the puzzles list, messages that puzzle solving has finished, etc.
5. The biggest and most important job is editing links. Everything that is a link (an a tag) or contains a link (like a src property) is going to be broken (thanks partially to us breaking those folder links when we saved these pages).
   
   
   • In CSS, pay careful attention to things like links to font files (they use a url() value) or background-images.
   • In HTML, images are going to be the most obvious broken things since you'll see the broken image placeholder if you try to view the page before it's fully edited.
   • Actual links will fall into a few categories. For emails (links that start with "mailto:"), you can leave the link alone if it's a full address (it ends with an @company.website) and is the contact email mentioned in the footer (for example, Puzzlehunt uses the [email protected] address). Any other email will need to have the link tag removed and just be in plaintext.
   • Links to other pages within this event (for example your rules or faq pages) can just link directly to those pages and don't need to open in a new tab. For example, "https://puzzlehunt.azurewebsites.net/pd2024/play/faq" can just become "faq.html" or whatever you named the faq file.
   • Links to any other site, including other events, need to open in a new tab (using the target="_blank" property). Additionally, all links to the puzzle archive should use the shortlink https://aka.ms/puzzles.
   • Links to things that don't exist anymore, like Teams meetings for opening ceremonies, can just be removed entirely.
   • Links at the top of tables, like to sort them by puzzle name, can also be removed and replaced with plaintext.
     
     
6. Other page cleanup is fine to perform as well. For example, style tags and link tags should really exist in the head tag instead of the body, so you can move those tags if they're in the wrong place. Or, improper spacing/indentation can be fixed.
7. If the sample puzzles page uses puzzle.js, saving the page won't save the puzzle.js properly. You'll need to rip out all of the actual table content and just use the main puzzle-entry div to define the puzzle content. Don't forget to make sure the links to the puzzle.js files in the resources folder are correct! Also, depending on the puzzle, puzzle.js may need its accompanying svg files for drawing borders and edges as well. For more information on puzzle.js, contact Kenny Young.
8. Some pages may need extra help to remove PII. For example, the fastest solves page may contain a column showing if your team specifically has solved that puzzle. That column can be removed entirely.
9. Finally, once all pages are sufficiently edited, don't forget to go back to the event list and update the link to this event to now point to the archived event's homepage! Some event types may also have a second link in the left bar as well.

1. You'll likely spend a lot of time editing the puzzle list if the puzzle files you have have file names that don't match the links on the webpage or the webpage links don't contain filenames at all. At minimum, you'll at least need to remove columns for things like the link to the submission page (the only links you'll need are for the puzzle files and answer files).
   
   
   • Regular expressions (regex) will definitely be your friend to be able to fix everything in a single find-replace operation. For example, to remove an entire empty column from every table row, you can just search for <td>\s+</td> and replace it with an empty string. Notice the \s+ in between: it will match any empty tags with any amount of whitespace (including newlines) in between them. Or, if you wanted to trim a column to have no white space between the tags, you'd search for <td>\s+(.+)\s+</td> and replace it with <td>\1</td>, where the (parentheses) capture whatever is between them, the .+ matches any characters, and the \1 in the replace throws back in whatever the text you wanted to keep was. Mozilla has a good regex cheatsheet you can use, and notepad++ has very good regex find-replace functionality.
2. Once all the links in the list match what should be the filenames you have, make sure you click every link and test it! Typos can happen, or if you left spaces in filenames, you may find that the url needs to be escaped or the spaces removed for the link to work properly. For convenience, you should also make every puzzle link open in a new tab.
3. While you're clicking the puzzles, you should at least make sure they look okay: all the references to their styles and scripts work as intended, download links to supporting materials work, etc. You're NOT responsible for making sure interactivity actually works though. Some puzzles may be built with old libraries that eventually break in newer browsers, or they may have relied on private servers that are now offline. This is most likely going to be the case for meta puzzles, but there isn't much we can do about it.
   
   
   • If the meta was token-based, it might be nice to download the list of tokens and add a link to it beside the puzzle name on the puzzle list.
   • If the puzzles were PDFs, you should also make sure that any links in them to supporting materials are downloaded and linked beside the puzzle as well.
   • Similarly, if a puzzle was delivered in multiple forms, like PDF and Excel file, you can make the PDF the main link and link to the Excel file beside it.
   • If the puzzle was a live event or physical puzzle and has no puzzle file, it's fine to leave it in the list and just remove the link to make it plaintext. Same thing if an answer file is missing for some reason.
     
     

1. Instead of logging into the Azure frontend to manage the files, it's much more convenient to use a program like WinSCP to be able to see the diff between the files on the server and on your local copy. Note that this assumption means you should have a full copy of the website's files on your machine, and you can just use the edit timestamps to be able to only upload files you've changed instead of just blindly updating everything all the time. Either way, you'll need to get the login info from somebody who has it since it can't be published here.
2. After uploaded, it's usually worth checking things out to make sure links work as expected and things look okay on the actual site. For reference, the archive is currently over 6GB uncompressed and growing, so you likely will want to get your initial copy offline instead of trying to grab it all from the live server.